Ryan Dahl - I hate almost all software

Ian·2020년 12월 16일
1

ETC

목록 보기
1/2
post-thumbnail

이 포스팅을 하게 된 계기

존경하는 개발자는 누구인가요? 개발자로서의 role model 이 있으신가요?

오늘 본 면접의 마지막 쯤 이런 질문을 받았다. 나는 주저없이 Ryan Dahl(이하 '라이언 달') 이라고 대답했다.

라이언 달은 일단은 Node.js 라는 runtime 을 만들어 Javascript 라는 언어의 새로운 세상을 열었고, 그 Node.js 가 package dependency 가 너무 커지고 또 사용자가 많다보니 발전하는 기술들을 반영할 수 없어 Deno 라는 새로운 runtime 을 만든다. C++ 로 만들었던 Node.js 와 달리 메모리 관리가 더욱 안정적인 Rust 로 Deno 를 설계하였고, Javascript 만 구동할 수 있던 과거와는 달리 TypeScript를 "native 에 준하게" 돌리려는 시도를 하고있다. 기존 Node.js 의 문제점으로 여겨진 package 의 dependency 도 낮추려는 노력을 하고있다.

난 그게 너무 멋졌다. 이유는 세 개다. Node.js 로 세상이 조금 더 편리해지는 데 기여한 게 첫 번째. 그리고 본인이 제시한 Node.js 라는 방법이 적절하지 않은 방향으로 흘러가자, 고민한 끝에 더 나은 Deno 라는 대안을 제시했다는 게 두 번째. 그리고 꾸준하게 그 활동을 하여, "개발자라면 말보다는 결과물로 말하는 게 세 번째다.

그래서 내 존경하는 개발자이자 role model 은 라이언 달이라고 생각했었고, 그래서 라이언 달이라고 대답했다.

오늘의 포스팅은 라이언 달의 소개 페이지에 있는 글 중, 여러 번 읽으면서 많은 생각을 했던 글인 "I hate almost all software" 의 번역이다. 매끄러운 번역을 위해 의역을 조금 가미하였고, 생략한 부분도 조금 있다. 이 글을 읽는 사람 중 내가 잘못 번역한 부분이 있으면 피드백을 남겨주었으면 한다.


나는 대부분의 소프트웨어들을 싫어합니다

왜냐면 불필요하고, 복잡하기 떄문입니다. 누군가가 그 똥같은 것들을 활용해서 빠르고 간단하게 문제를 풀어냈다 한들, 나는 그냥 "아 예, 뭐, 네 잘하셨어요" 정도로 말 할 수 밖에 없어요.

내가 좋아하는 소프트웨어요? 내가 쉽게 이해할 수 있고, 내가 가진 문제들을 해결해주는 소프트웨어요. 어느정도까지 복잡하면 되냐구요? 해결할 그 문제만큼만 복잡하면 돼요. 그 이상은 용납이 안 됩니다.

예전에 나는 Unix 의 이상적인 방향을 드디어 이해했다고 생각했던 적이 있었습니다. Unix 를 C로 다 짜는거에요. file descriptor 든 process 든 뭐든간에. 멋지죠? 하지만 우리가 그걸 통해서 뭔갈 하기는 쉽지 않을겁니다. 복잡하진 않겠지만요. 대신에 저는 DBus 랑 /usr/lib, Boost, iocls, SMF 와 signals, 그리고 volatile variable 등등의 도구들을 사용하는 걸로 합의를 봤습니다.

우리들은 계속해서 더더욱 시스템들을 복잡하게 만들어 나가고 있어요. 어떻게 돌아가는지도 모르면서요. 당신은 $LD_LIBRARY_PATH 를 통해서 시스템을 작동하는 방법 뿐만 아니라 NODE_PATH 가 어떻게 돌아가는 지도 알아야 할 필요가 있습니다 (음 이건 제가 정작 더 복잡하게 만들었네요)

그렇지만 사용자들은 그냥 웹페이지만 잘 켜지면 장땡입니다. 다른 건 신경 안써요.

/usr 을 우리가 어떻게 구성했는지, 쓰잘데 없는 로직이 돌아가든지 말든지 신경을 안 쓴단 말입니다. 어떻게 구성됐는지 관심도 없어요. 그러다보니 소프트웨어가 갈수록 복잡해지고, 언젠가 더 복잡해진 새로운 소프트웨어가 나왔을 때 그 이전의 소프트웨어로 만든 작업물들은 다 쓰레기가 되어 버립니다.

프로그래밍 언어의 자세한 부분을 배우면서 좋아하는 당신들, NaN 이 null 이랑 같으니 아니니 하는 너네들요. 당신들은 지금 이 모든게 얼마나 쳐 망했는지 아직 몰라서 희희덕 거리는겁니다. 부질없이 디렉토리 정리를 하거나 테스트 코드에 unicode check mark 를 다는 당신들, 그냥 어찌됐든 문제만 해결하면 되는건데, 뭐하러 그렇게 복잡한 일들을 하시냐구요.

소프트웨어를 만들 때 사용자나 신경쓰면 되는거지, 안 그래요?


글을 읽고 느낀 소감

처음에는

솔직히 팡션부장생각났다. 왜냐면, 나는 복잡성과 편리성은 결국 Trade Off 인데 복잡성을 줄인다는 명목 하에 편리성을 과할 정도로 포기하는 건 미련한 행위라고 생각하기 떄문이다.

그리고 저 논리대로라면 프로그래밍 언어는 필요가 없다. 어셈블리어도 필요가 없다. 기계어를 사용한 이진법으로 그냥 다 코딩하면 얼마나 컴퓨터 친화적이고 좋은가? 더 복잡할 필요도 없다. 라이브러리니 그런 것도 다 필요가 없다. 이론상으로 기계어만 잘 배우면 뭐든지 할 수 있다.

그러나 개발하는 사람들 입장에선 이야기가 다르다. 바퀴를 굳이 만들지 마라는 이야기가 격언처럼 내려오는 것처럼, "굳이" 라이브러리니 그런 거 없이 프로그래밍 언어 그 자체로 구현할 수 있는 건 다 구현한다? 조금 시간이 아깝다고 생각한다.

I don't get it? If he really hates the situation so much, why did he choose a language that makes it notoriously difficult to write quality software in and chose a concurrency style that is notoriously difficult to reason about?

라이언 달이 이 글을 올린 사이트 해커뉴스에는 이런 댓글도 있었다. 요약하자면, "추상화, 복잡화 그렇게 극혐하시는 분이 왜 자바스크립트씀? ㅋㅋ" 이라는 내용이다.

생각해보니

그런데 이걸 기술의 수명을 기준으로 생각해본다면 조금 이야기가 달라지긴 한다. 더 낫고 편한 방법은 존재하고, 그리고 계속해서 생긴다. 그러면 이전의 방법을 통해서 구성한 소프트웨어는 갈아엎어야 한다. 물론, 개인이 만든 조그마한 프로젝트를 그렇게 리팩토링 하는 건 할 만 하다. 그러나, 그게 기업 스케일이 된다면? 그 자체가 엄청난 일이다. 저렇게 단순히 팡션부장 정도로 넘길 일은 또 아니라는 생각이 들었고, 라이언 달이 왜 Deno 를 만들었는 지도 이해가 갔다.


결론

정말 이론적인 이야기로 끝맺을 수 있을 거 같다. 라이브러리든 뭐든 꼭 필요한 게 아니라면, 가급적이면 쓰지 마라. 그러나 꼭 필요하다면, 그 때는 써라. 다만, 그걸 쓰지 않고도 구현하는 경우보다 써서 구현하는 게 더 낫다는 확실한 근거에 기반해서 써라.

아직까지는 내 식견이 좁아서 이 정도의 결론밖에 내릴 수 없을 거 같다...

profile
правда и красота, truth and beauty

0개의 댓글