철학이 있는 프로그래머가 된다는 것
Lex Fridman의 DHH(rails 창시자)편 팟캐스트를 듣고.
ChatGPT로 생성한 DHH 이미지.우연히 유튜브에서 Lex Fridman의 팟캐스트를 들었습니다.
인생을 바꿀만한 경험이었고, 제 커리어와 미래의 할 일들을 정리하게 된 계기가 되었습니다.
미래의 제가 이 신선한 충격을 잊지 않도록,
그리고 이 기억을 토대로 인생을 바꾸기 위해 브런치 글로 정리했습니다.
0. Ruby on rails의 창시자의 이야기를 듣다.
웹 개발에서 "설정보다 관례"로 MVC 패턴을 매우 직관적으로 만든 사람.
ActiveRecord ORM과 Scaffolding의 개념으로 웹 개발 생산성에 일조한 사람.
클라우드(AWS)에서 탈출하고, Typescript를 프로젝트에서 과감히 걷어냈으며,
Ruby라는 프로그래밍 언어가 가장 인간 친화적이라고 주장하는 사람.
별종이기도 한 이 사람은 스타트업의 성지인 실리콘밸리에서 거의 표준이 된 풀스택 프레임워크
Ruby on rails를 만든 사람인 David Heinemeier Hansson(이하 DHH)입니다.
덴마크에서 태어난 프로그래머인 그는 어렸을 때는 프로그래밍에 재주가 없었다고 생각했지만
컴퓨터와 프로그래밍 언어를 접하면서 웹 사이트를 런칭하며 개발자가 되었습니다.
살면서 한 번쯤은 들어본 이름이긴 한데, 왜 IT업계에서 유명한 사람인지는 잘 몰랐고
Ruby on rails라는 프레임워크가 이 정도로 유명한 프레임워크인지도 몰랐습니다.
이것을 기반으로 수많은 큰 기업들이 탄생했다는 것도 잘 몰랐고요.
영상을 보면서 프로그래밍뿐만 아니라 인생을 사는 방향을 다시 결정할 수 있는 빛과 소금 같은 인사이트가 많았습니다. 교훈도 많이 얻었고, 전체적으로 6시간짜리 팟캐스트를 전부 듣기를 잘했다고 생각합니다.
여러 문구가 기억에 남습니다.
- 웹은 복잡해지고 있다. 리액트와 같은 프레임워크는 그 조직을 대변한다. 예전의 PHP로 개발하는 시대에서는 FTP에 파일만 올리면 배포가 끝이었다. 지금은 너무 복잡해지고 있다.
- 웬만한 조직에 MSA는 필요 없다고 생각한다. 소수의 인원으로 구성된 조직이야말로 혁신을 일으킨다. 프로젝트에 사람들이 많아질수록 소통에 대한 비용이 기하급수적으로 급증한다.
- 잦은 회의는 안 좋다. 홈 오피스에서 원격 근무하는 것을 매우 추천하며 그것이 좋은 방법이라고 생각한다.
- 모놀리식 프로젝트를 진행해야 하는 이유는 그것이 전체 프로젝트를 이해하는 데에 가장 좋기 때문이다. 프로그래머는 전체 프로젝트의 구성과 동작을 이해해야 한다.
- 하나의 프로젝트를 할 때는 각자의 전문성이 있는 사람끼리 해야 한다. 비슷한 프로그래머 둘이서 프로젝트를 끌어나간다면 성공하기 매우 어렵다. 한 명의 디자이너와 한 명의 프로그래머가 프로젝트를 진행하는 것이 훨씬 더 나을 것이다. 물론 프로그래머 입장에서 디자인에 대한 의견이 다를 수 있지만 서로를 존중하고 믿는다면 반대하는 의견이 있지만 그것에 대해서 믿고 내버려 두는 방법으로 업무를 진행한다.
- 혼자서 근무하는 것이 외롭다고 느낀다면, 진심으로 말하는데, 아내를 구하고 아이를 둘 낳아라. 이건 진실된 조언이다. 예전에는 매트릭스와 꺼진 TV 앞에서 일만 했는데 그렇게 좋지 않았다. 인간은 인간을 필요로 한다. 삶에는 다른 관계가 필요하다. 가족이 있다는 것은 스타트업의 스프린트(전력질주)를 마라톤으로 바꾼다. 지속 가능한 회사로서 존속할 수 있도록 돕는다. 어떤 면에서는 정착한다고 할 수 있다.
- 사무실에서 일하는 것은 90년대에는 작동하는 업무 형태였다. 하지만 나(DHH)와 사업파트너 Jason은 일주일에 40시간 정도만 일하는 것이 더 좋다고 합의했다. 그것이 더 길고 장기적인 비즈니스를 이끌어가는 데 좋은 형태이고, 삶에서 다른 관계를 갖고, 함께할 파트너(아내)를 찾고, 취미를 갖는 것이 수년 안에 VC에게 투자받아서 엑싯하는 형태가 아닌 장기간의 안정된 비즈니스를 이끌어가는 데에 더 좋은 방식이라고 생각한다.
- 우리는 클라우드가 서버를 관리하는 비용을 아낄 수 있다고 믿었다. 그게 더 저렴하다고 믿었다. 하지만 그렇지 않다는 것을 알게 되었다. 당신이 받는 AWS 청구서에는 그들이 40%의 마진을 붙인 것들이다. 우리는 현대의 CPU가 얼마나 크게 발전했는지 잘 체감하지 못한다. AMD가 만든 CPU를 최근에 보고 깜짝 놀랐다. 예전에 내가 알던 CPU와는 너무도 달랐기 때문이다. 지금의 CPU는 너무나도 훌륭하고 빨라서 홈 서버로 여러 프로젝트를 실험하기에 좋은 시대이다.
- 인생에서 돈은 중요하다. 하지만 주변의 부자들 누구에게 물어봐도 지금 일군 것보다 항상 2배를 원했다. 돈 보다 인생에서 더 중요한 것들을 먼저 추구하라. 그것이 가족이든, 파트너든, 인생의 철학이든.
1. 유명세가 아니다, 철학이다.
누군가를 존경하고 싶거나 닮고 싶은 것은 그 사람이 유명해서가 아니라 철학이 있는 사람이기 때문입니다.
DHH는 오픈소스를 만든 사람으로 자신만의 철학으로 똘똘 뭉친 사람이죠.
유명해져서 철학이 있어 보이는 게 아니라, 철학이 있기 때문에 유명해진 것이라고 생각하게 되었습니다.
인생을 살면서 모두 성공하고 싶고, 세상에 이로운 영향을 미치고 싶어합니다.
그런데 모두 어떻게 할 지에 대해서는 구체적으로 생각해보지 않습니다.
단순히 "성공", "Exit"와 같은 단어들을 머릿속에 박아 넣을 뿐입니다.
DHH의 영상을 보면서 처음으로 진지하게 철학을 가진 사람이 되고 싶다는 생각을 했습니다.
단순히 멋있는 말과 수많은 형용사로 나를 설명하는 것이 아니라,
분명하고 구체적인 비전을 제시하며 그것을 달성하기 위해 발걸음을 옮기는 그런 사람이요.
2. "프로그래머"를 존중한다는 것. "인간 중심"의 사고를 한다는 것
영상 전반적으로 꽤나 재미있는 이야기입니다.
'왜 Python, Java, Javascript가 아닌 "Ruby"일까?'
저도 궁금했습니다.
그는 Ruby 언어를 좋아합니다. 좋아한다는 단어로도 부족합니다. 거의 "광신도"이다.
Ruby 그 자체를 종교처럼 열정적으로 설명합니다.
DHH는 예전에 PHP 파일을 FTP로 업로드하는 것으로 웹 개발을 경험했습니다.
HTML 파일 자체를 만들 수 있다는 경험 자체를 좋아했던 것 같아요. 하지만 PHP라는 언어 자체는 좋아하지 않았다고 합니다. 단지 HTML를 서빙하기 위한 수단으로써 사용했던 것이라고 합니다.
당시에 그와 함께 창업한 Jason과 같이 프로젝트를 준비하면서 프로그래밍할 언어를 찾고 있는데,
마침 본인이 읽고 있던 IEEE 잡지에서 Ruby를 소개한 것이 계기가 되었다고 합니다.
그 잡지에는 루비 프로그래밍의 선구자인 Dave Thomas와 소프트웨어 디자인 전문가인 Martin Fowler가 글을 쓰고 있었고, 더 나은 코드를 작성하는 방법과 같은 글이었는데 저자인 둘 다 Ruby를 통해서 그런 개념들을 설명했습니다.
당시 DHH는 Ruby라는 언어를 보면서 의사코드와 같이 단순해 보인다는 느낌을 받았는데, C든 Java든 PHP든 어떤 언어로 개발하는 사람이든 Ruby 언어를 보면 단 번에 이해할 수 있었다고 합니다. 그만큼 Ruby는 언어 문법 자체가 단순했기 때문입니다.
그들(IEEE 저자들)이 설명하는 컴퓨터 개념을 이해하면서 Ruby라는 언어에 대해서 배워보고 싶어졌고, 좀 더 깊게 배우게 되었다고.
당시 Ruby 언어의 창시자인 일본인 Matz는 93년도부터 이 언어를 작업했는데 꽤나 숨겨져 있어서 유명하지는 않았습니다. Ruby의 문법은 PHP가 사용하는 달러($) 표시도 없었고, 줄이 끝난다는 의미의 세미콜론(;)도 없습니다. 그곳에는 "오직 인간을 위한, 친화적인 언어 표현식"만 있습니다.
DHH가 Ruby를 설명하면서 가져온 예제DHH는 위의 예제로 Ruby의 심플함과 철학을 설명합니다.
코드를 보면 인간에게 매우 친화적인 것을 알 수 있습니다.
파이썬과 같이 def로 함수를 만들지만 파라미터를 호출할 필요가 없는 경우 괄호마저 생략합니다.
DHH는 이 자체가 매우 중요하다고 말합니다.
"세미콜론을 없애고, 괄호를 없애는 것은 컴퓨터 입장에서는 매우 해석하기 어려워진다.
Ruby 언어를 파싱 해서 컴파일해야 하기 때문에 컴파일러는 더욱더 복잡해진다. 문법이 일정하지 않을수록 더 많은 규칙 속에서 언어를 파싱 해야 하기 때문이다."
DHH는 이것에서 완전히 Ruby에 매료됐습니다.
컴퓨터가 더 복잡해지는 것을 택함으로써 인간에게 더 친화적으로 보이겠다는 언어의 철학 말이죠.
Ruby는 이런 추악하고 못생긴 것들을 없애면서,
순수한 본질 그 자체로 압축한다.
동시에 Ruby는 단어를 축약하지 않는다.
Python의 __init__과 같은 것 말이다.
Python은 초기자에서 __init__을 통해 언더바와 축약된 4글자 단어를 사용하지만, Ruby에서는 initialize라는 전체 단어를 씁니다. 훨씬 더 단어가 길지만 인간에게는 확실하게 단어 의미를 전달하면서 모호하지 않게 보인다는 것이죠.
그는 또 다른 예시를 설명합니다.
위의 코드는 대부분의 프로그래밍 언어에서 제공하는 조건문입니다.
"객체를 호출한다고 가정하면, user.isadmin(){} 이렇게 작성한다.
하지만 Ruby는 그렇게 하지 않는다.
Ruby는 모든 것을 끊어낸다. if로 시작하지만 괄호는 필요없고, user.admin뒤에 물음표를 붙인다.
열린 괄호도 없고, 소괄호도 없으며 아무 것도 없다."
그는 특히 이 부분을 보면서 거의 광기에 가까운 태도로 설명합니다.
Ruby가 이정도로 좋다는 것을 강조하는 느낌입니다.
"실제로 물음표는 컴퓨터에게 아무 의미도 가지지 않지만, 오로지 인간을 위해서 추가된 문구이다.
Ruby는 오로지 사람들 간의 의사 소통 도구로서 사용될 수 있는 언어로 설계됐다는 것이다."
DHH는 이런 Ruby의 문법에 놀라운 아름다움을 느꼈다고 합니다.
그 뒤로도 그의 Ruby 언어에 대한 찬양이 계속돼요.
너무 길어서 몇 줄로 요약하자면, Ruby는 다음과 같은 특징이 있습니다.
- 요약 1. Ruby는 그 자체로 메타프로그래밍이 가능하다.
메타프로그래밍이란, 자기 자신 혹은 다른 컴퓨터 프로그램을 데이터로 취급하여 프로그램을 작성할 수 있다는 뜻이다. 프로그래밍 언어 자기 자신 자체를, 하나의 데이터로 처리해서 변경할 수 있다는 뜻이다.
Ruby를 만든 Matz는 지구 반대편의 사람을 믿는다고 했다. 메타프로그래밍을 언어단에서 허용함으로써 더 좋은 확장된 단위나 프로그래밍 문법을 사용할 수 있게 된다. 프로그래머의 무한한 능력을 믿는다는 것이다.
Ruby를 사용하면 기본 클래스를 확장할 수 있다.
예를 들어 Ruby에서 5번 반복은 5.times라고 적는다. 5는 명백하게 Ruby의 기본 클래스이다.
하지만 이것을 확장할 수 있다.
Rails에서 제공하는 Active Support라는 것이 있는데 거기에선 이 5를 제공하는 클래스를 확장해서 day, month와 같은 것을 제공한다.
그래서 이것으로 5일 후에 캐시가 만료된다를 cache expires in 5.day라고 작성할 수 있다.
https://guides.rubyonrails.org/active_support_core_extensions.html#extensions-to-numeric-time
- 요약 2. 1번과 같은 메타프로그래밍을 통해 Ruby에 키워드를 추가할 수 있다.
Rails에서 제공하는 기능 중에 has_many :comments이다.
데이터베이스에서 의존성을 추가할 때 사용자들이 많은 포스트와 댓글들을 가질 수 있게 하는 것이다.
Ruby에서는 특정 도메인에 맞게 키워드를 추가하여서 해당 프로그램이 원하는 방식대로 프로그래밍 언어를 가져갈 수 있게 허용한다.
그래서 rails에서는 개체 수준에서 데이터베이스의 관계를 자신만의 키워드로 작성하여 연결할 수 있게 되었다. 이런 것을 도메인 특정 언어라고 부른다.
- 요약 3. 메타프로그래밍이 안되거나, 정적 타이핑을 싫어하는 이유
https://news.hada.io/topic?id=10779
그는 이런 이유로 Typescript를 Turbo라는 프론트엔드 프레임워크에서 Typescript를 빼냈다.
DHH는 반복을 싫어하고, 압축된 표현을 좋아하는 것을 얘기했다.
그가 Typescript를 싫어하는 예제 중 하나는, User, user, user = new User와 같은 타입을 선언하고 그것을 반복해야하는 상황입니다.
그는 이런 시간도 없고, 이런 것들로 내 Ruby 언어가 오염되는 것을 원치 않는다고 합니다.
"타입을 강력하게 해서 자동완성과 특정 종류의 버그를 더 쉽게 찾을 수 있다는 것에 동의하지만,
상관없다.
나는 도구를 사용해서 코드를 작성하지 않고, 자동완성도 사용하지 않는다.
모든 프로그래밍 언어에서, 훌륭한 툴 지원이 있으면 허용 오차가 훨씬 더 높아진다.
나는 내가 작업하고 있는 원단이 어떤 것인지를 알고 싶다."
동시에 그는 덕 타이핑을 허용하는 것에 대해 긍정적으로 이야기합니다.
런타임에 동적으로 메서드를 추가하는 이 개념은, 정말로 흥미로운 일을 많이 한다고 설명합니다.
실제로 그는 Typescript를 Turbo에서 꺼내오면서 엄청난 비판을 받았습니다.
Typescript는 오류를 줄여주고, Javascript로 변환하기 전에 수많은 것들을 막아주지만
그는 "Things that should be easy become hard, and things that are hard become `any`"
라는 문장으로 블로그에 글을 쓰면서 Typescript를 강제로 프로젝트에서 빼냈습니다.
(오픈소스 기여자들과 상의 없이 자신의 PR를 Merge하면서.)
그는 타입을 강하게 가져가면서 "nullpointerException을 줄여준다거나 더 많은 이점이 있다"라는 말에
나는 이미 그런 오류들이 없다고 항변했습니다.
이런 의견에 파이썬을 만든 귀도 반 로썸의 의견도 궁금해지네요..
3. 철학이 있다면, 반대하라.
정적 타입에 대한 반대를 하는 그의 주장을 솔직히 받아들이기 어렵습니다.
저도 프론트엔드를 개발해봤고, Typescript로 미리 정의해둔 타입이 어긋나는 상황을 많이 목격했습니다.
그리고 그런 오류들을 미리 잡아낼 수 있었고요.
인간 중심의 생각과 유연한 사고까지는 이해했습니다만,
어쨌든 그것은 그것이고, 다음 내용으로 넘어가겠습니다.
Ruby에 대한 생산성에서도 많은 이야기가 있었습니다. 그 중에 가장 논란이 되는 이야기죠.
바로 scale에 대한 이야기입니다.
2009년 twitter에서는 Rails에서 확장성 문제가 발생해서 다른 언어로 옮겨가게 되었습니다.
이 것에 대해서 DHH는 이렇게 이야기합니다.
"그 이후 10년 간 어떤 혁신도 없었다. 다른 스택으로 변환하는 데에 너무 긴 시간이 걸렸기 때문이다. 확장성이라는 환상은 거짓이다. shopify는 블랙 프라이데이에 1초당 1백만개의 request를 소화했다."
"Ruby는 더 많은 생산성을 가져갈 수 있는 언어이다.
더 많은 생산성은 더 많은 비용 지출을 이긴다.
개별 프로그래머들의 능력이 좋다면 훨씬 더 많은 이익과 기능을 창출한다.
Ruby는 고급 언어이다. 언어 중에서 코코 샤넬이다.
모든 사람들이 감당할 수는 없다.
만약 개별 Client Request의 가치가 너무 저렴한 경우에는 Ruby를 견뎌낼 수가 없다.
그 때는 C언어와 Go, Rust 같은 것으로 처리해야한다.
하지만 만약 하나의 요청이 엄청난 가치를 가지는 경우,
Ruby로 생산성을 높이는 것이 훨씬 운영하는 데에 도움이 된다.
Shopify와 basecamp 사례에서 알 수 있듯이, 대부분의, 99%의 웹 개발에서 문제가 되는 것은
CPU cores의 비용이 아니라 Web cores, Human cores의 문제이다."
그는 Ruby와 같은 언어들은 너무 고급 언어이기 때문에,
1건의 request의 가치가 매우 높아야한다고 합니다.
클라이언트의 요청이 가치가 높을 수록,
생산성이 높은 것이 더 좋은 웹 프레임워크가 될테니까요.
그는 개인의 생산성이 중요하지 하나의 요청을 더 저렴하고 빠르게 처리하는 것이 문제가 아니라고 합니다.
이것은 곧 더 low-level 언어로 가는 것, 비용을 시스템 측면에서 줄이려고 하는 것이 생산성과는 반대되는 행위라고 생각하는 것을 보여주는 것 같네요.
자신만의 철학으로 사람들의 주장을 반대합니다.
어떤 것들은 이해하기 어렵고, 어떤 것들은 공감되는 부분이 있습니다.
하지만 그의 목소리와 철학에는
20년이 넘는 시간동안의 Rails를 구축해온 시간과 코드가 뒷받침하고 있습니다.
그것이 곧 영향력의 원천이 되는 것이겠죠.
4. 제프 베조스에서 배운 것
Basecamp인 두 창업자(DHH, Jason)는 아마존 창업자 Jeff bezos에게 직접 지분을 매도했습니다. VC처럼 외부 투자를 유치해서 회사의 자본금을 확충한 것이 아니라, 원래 가지고 있던 지분을 매도하는 방식으로 사업 파트너를 늘렸죠.
직접 각자 개인의 계좌로 돈을 받은 이유는, 성장하는 데에 돈이 필요하지 않았기 때문입니다.
이것이 매우 중요한 이유는 벤처 캐피털로부터 투자를 받아서 테이블에서 조금씩 뺏기지 않는다는 것입니다.
큰 돈을 투자 받으면 그만큼 수익(리턴)을 원하기 때문에 창업자들은 하고 싶지 않은 엄청난 일들을 해야합니다. Jeff는 DHH와 Jason이 필요한 돈을 정확히 주었다고 합니다.
Jeff는 이들이 훌륭한 프로젝트를 하고 있다면서 경영에 큰 영향을 미치지는 않는다고 하네요.
다른 곳에서는 이들이 원하는 만큼의 돈을 절대 주지 않았을 거라고 합니다. 수익은 적었고, 그만큼의 멀티플을 인정해줄만한 곳이 없었으니까요.
하지만 Jeff에게는 푼돈이기 때문에 투자를 결정했다고 합니다. DHH와 Jason은 이 과정에서 수백만 달러를 받았습니다.
그(Jeff)는 두 창업자에게 경제적 자신감과 CEO로서의 자신감을 심어줬다고 했습니다.
DHH는 아마존에서의 장기적 플랜은 자신의 장기 플랜과는 차원이 다르다고 했습니다. DHH는 스스로를 장기적으로 사고하는 사람이라고 생각했지만 아마존은 그 수준보다 몇 배는 훨씬 더 장기적인 안목으로 플랜을 짰다고 합니다.
그리고 Jeff에게 배운 것 중 하나가 "disagree and commit"라는 것입니다.
무언가가 결정되기 전까지는 열정적으로 토론하고 반대하되 한 번 결정된 것에 대해서는 최선의 지원을 한다는 것이죠. 이는 디자이너와 함께 프로젝트를 구성할 때 큰 도움이 되는 마인드로 정착했다고 합니다.
5. 야망 있는 자에게 은퇴란 없다.
그는 특정 목표(-엑싯)를 두고 달려가는 삶은 행복하지 않다고 말합니다.
"자신의 역량을 최대한 발휘하고 확장하는 곳에서 행복하다.
여러 마주치는 문제들을 해결해나가면서 시간을 보내는 것이 좋은 것이지,
세상에 있는 모든 고찰할 수 있는 문제들을 삶에서 없애버린다면 곧 우울해질 것이다."
야망이 있는 자에게 은퇴라는 것은 없다는 말이 와닿았습니다.
그는 프로그래머들 중에서도 매니저로 승진한 사람들이
정말로 빠른 시간 내에 코드에 대한 감을 잃어버리고,
프로그래밍에 대한 감각을 잃어버린다는 것을 설명했습니다.
각자가 잘할 수 있는 영역에서 발견할 수 있는 문제들을 해결해나가는 능력은
나이와 상관없이 중요하다고 느끼게 됩니다.
6. 열심히 일한다는 것
Lex: "프로그래밍과 같은 학문의 "최고"가 된다는 것은 그 사람의 일생의 끝에 가서야 알 수 있는 것 같다."
DHH: "0.5%, 0.1%에 드는 것은 어렵지만, 특정 영역에서 5%안에 드는 것은 생각보다 쉽다. 다섯 개의 영역에서 5% 안에 드는 것도 마찬가지다. 회사를 운영하거나, 글을 쓰거나, 가족을 갖거나, 레이싱을 하거나, 프로그래밍을 하거나 등. 여러가지를 할 수 있다."
집중할 것은 딱 하나야라고 생각하면 너무 소외감을 느낀다고 합니다.
물론 프로그래밍을 할 때 몇 주나 몇 달을 집중해서 하는 것도 있지만, 공기를 마시러 올라와야 할 때가 있어야 한다고 합니다. 그리고 다른 일을 하죠.
그리고는 "이게 올해까지의 프로그래밍이었어"라고 이전에 하던 일을 끝마친다고 합니다.
하나의 일만 죽어라하는 삶보다, 다양한 영역에서 적당히 탁월함을 얻는 것이
좀 더 활력있는 삶이 아닐까 싶습니다.
7. 가족을 만들어라. 그것이 좀 더 장기적으로 생각하게 만든다.
그는 아버지가 된다는 것. 가족을 갖는 것에 대해서 구체적으로 생각해 본 적이 없다고 합니다. 물론 먼 미래에 결혼하고 아이를 가질 수 있다고 생각은 했지만 당시의 여자친구가 결혼과 임신을 이야기할 때는 "어, 어, 어, 그래 해보자" 정도로 가볍게 생각했다고 합니다.
그리고는 결혼과 육아를 이렇게 설명합니다.
"이것은 너무 진부한 이야기처럼 들리지만 아이를 갖는다는 것은 우리가 상상하는 것 그 이상의 기쁨을 줍니다. 젊었을 때 1부터 10까지의 척도로 행복을 끼워넣을 수 있었다면, 결혼하고 아이를 낳으면 1부터 100까지 기쁨이 있다는 것을 알게 됩니다. 이전에는 이렇게 낮은(1-10) 단계의 기쁨만 즐기고 있었다는 것을 알게되죠."
30대 초반에 인생의 경계에 대해 상당한 이해를 가지고 있다고 생각했는데, 근데 깨닫게 된다고 합니다.
"모르겠다"라고요. 척도가 훨씬 더 넓다는 것을 알게된다고 합니다.
동시에 아이를 통해 자신의 DNA를 보는 것으로 아이를 갖는 기쁨을 이야기했는데,
이 자리에 나라는 존재가 앉아있기까지는 30,000년 전에 어떤 네안데르탈인이 나와 같은 깨달음을 가졌는데 말 그대로 그것이 인류의 시작부터의 인간의 추구였기 때문에 이런 경험들이 매우 놀라웠다고 합니다.
그리고 아이를 가지고 나서 좀 더 체계적으로 살게 되었다고 합니다.
아이를 가지기 전에는 저녁에 개발하거나 하는 등 업무를 했지만, 이제는 좀 더 장기적으로 체계적으로 업무를 하게 되었다고 합니다. 오전 9시부터 오후 5시, 혹은 오후 6시까지 집중해서 일하고 그 다음에는 아이들과 놀아준다거나 하는 것처럼요.
8. 클라우드를 나와라, 나는 AWS를 나와서 물리 서버를 직접 샀다.
그는 처음에 클라우드를 적용하는 것에 대해서 매우 적극적인 찬성론자였습니다.
클라우드를 도입하면 더 쉬워질 것이고, 더 저렴해질 것이고, 더 빨라질 것이라고 생각했습니다.
하지만 클라우드는 엄청나게 비쌌고, AWS는 세팅 그 자체도 점점 복잡해지고 있다고 합니다.
차라리 서버를 새로 세팅하는 것이 더 낫다고 느낄 정도라죠.
이에 인터뷰어인 Lex도 AWS 세팅은 굉장히 복잡하다고 이야기합니다.
DHH는 물리 서버를 데이터센터에서 사서 넣었고,
직접 세팅하면서 많은 것을 느꼈다고 합니다.
최근에 생산되는 CPU의 성능에 감탄한다는 이야기도 덧붙였습니다.
우리가 물리적인 컴퓨터를 직접 보는 경험을 많이 못했다고 말하면서도,
동시에 엄청난 비용을 절약할 수 있다고 지적합니다.
일정 규모 이상이 되었을 때는 기업이 자체적으로 서버와 인프라를 소유해서 유지하는 온프레미스 방식이 더 낫다고 주장합니다.
9. Apple 컴퓨터와 현재. 그리고 DHH의 프로그래밍 세팅
그는 Apple의 혁신이 끝났다고 생각합니다. 오히려 역으로 안 좋게 봅니다.
30% 수수료 싸움 이후로 Apple은 '다른 비즈니스의 30%를 가져가는 기업'의 이미지로 바라보는 것 같습니다.
DHH는 Apple이 이전 스티브잡스와 같은 엄격한 리더가 이끌던 과거로는 돌아갈 수 없고,
"물류전문가"인 팀 쿡은 Apple의 혁신을 제대로 만들지 못하는 리더라고 말합니다.
최근에 나온 VR 기반 제품이 실패하면서, Apple 생태계에서 개발자들은 굉장히 중요한 역할을 하고 있다는 것을 강조했습니다. 절대로 Apple 플랫폼과 개발자가 일방적인 관계가 아닌, 상호 보완적인 관계라는 것을 덧붙이면서요.
DHH 본인은 맥을 20년 이상 사용했고, 심지어 예전 Apple 광고에도 출연했을 정도로 광팬이었다고 합니다.
지금은 리눅스를 기반으로 Lazyvim으로 개발하고, Apple의 XDR display 모니터를 사용하고 있다고 합니다.
Apple은 앞으로도 혁신을 유지할 수 있을까요?
10-1. 오픈소스에 뭘 요구하지마라. 당신은 구매자가 아니다.
Rails를 구성하면서 들었던 요구사항 중에 오라클 데이터베이스에 대한 연결 관련 요청이었다고 합니다.
"오라클 데이터베이스를 지원하지 않는 이상 이것은 토이 프로젝트일 뿐"이라는 의견도 있었고요.
DHH는 그에 대한 반응으로, Rails 컨퍼런스가 생기고 나서 가장 먼저 발표한 것이 "Fuck You"였습니다.
"나는 당신이 원하는 방향으로 움직이지 않을 것이다. 당신은 내 코드를 그대로 가져가서 써도 된다. 그리고 그것으로 수익을 창출해도 된다. 하지만 나에게 뭘 요구하거나 강제할 수 없다. 나는 내가 시간을 쏟아서 작성한 코드를 무료로 공유하는 것이다."
DHH의 이야기를 들으면서 많은 사람들의 예제가 떠올랐습니다.
공짜인 유튜브를 보면서 험담과 까내리는 댓글을 적는 사람들, 성공이나 동기부여의 영상에 "저 사람만 가능했던 예외다"라고 비하하는 것들, 도움이 되려는 글과 영상에 일반화 할 수 없다며 내려치기하는 모든 사람들.
우리는 공짜를 소비하는 시대에서 너무 많은 것을 요구하고 있습니다.
필요하면 본인들이 꺼지면 되는 일들인데, 콘텐츠 생산자들이 악플에 신경쓰면서 살아가는 세상이 된게 아닌가 싶네요.
또한 DHH는 Rails 프레임워크에서의 자비로운 독재자로서, 안티 팬들이나 너무 극성 슈퍼팬들 양쪽 이야기에 너무 귀기울이지 말라고 조언합니다.
당신이 지향하는 바에 따라, 당신이 원하는 대로, 당신이 좋아하는 대로 지침을 정하라고 말하면서요.
10-2. 동시에, 오픈소스로 나중에 영수증을 청구하지마라. (WP engine 논란)
워드프레스와 WP Engine의 갈등 이슈에서, DHH는 오픈소스는 세상에게 주는 선물이기 때문에
"선물을 줬다가 나중에 청구서를 발행하면 안된다."라고 했습니다.
"Rails에 왜 과금을 하지 않았냐고 묻는 사람들도 있다.
Shopify의 사례만 봐도 Rails는 수백 만 달러의 가치를 지니고 있지만, 나는 억만장자가 아니다.
그래서 도대체 뭐가 문제인데? 라고 말한다."
그는 충분히 자기 몫을 챙겼고, 그 이상 충분한 것들을 얻었다고 합니다.
선물을 주고서는 나중에 청구서를 들이밀지 말라는 이야기가 인상 깊었습니다.
본인은 basecamp 창업 과정에서 ruby on rails로 굉장한 돈을 벌었고, 그 외의 것은 자신의 것이 아니라고
하네요.
끝으로 내가 배운 것들, '프로그래머도 결국 한 명의 사람'이다.
- AI 시대에서도 결국 학습을 위해서는 직접 코드를 작성해봐야한다.
- 자동완성으로 코드를 작성하는 것보다, 정확하게 익히기 위해서는 텍스트 에디터로 코드를 작성해야한다.
- AI 시대에도 좋은 현상이 있다. 원래 프로그래머는 요구사항을 명확하게 해주는 사람이었다. 기획자가 말하는 것을 프로그래머가 다시 정의해서 주면 최초 기획자는 "그것은 제가 원하는 게 아니었어요"라며 피드백을 해줬다. AI 모델은 극한적으로 확장된다면 그와 같이 피드백을 계속 줄 수 있는 긍정적인 것이 될 것이다. 하지만 결국은, 최종적으로는, AI가 생산한 코드에 대해서 동작하는지 아닌지 누군가는 판단해줘야하기 때문에 결국 프로그래머는 필요할 것이다.
- 우선 순위가 중요하다. 사랑하는 파트너나 사랑하는 아이들을 떠올린다면 그것은 이미 보상을 받은 것이다. 인생에서 가장 중요한 것에 대해 우선순위를 두세요. 그런 것들은 놓치기가 쉽다.
- 인간 중심의 프로그램을 생각해보자. 그리고 인생은 흘러가고 있다. 돈이 전부가 아니다.
돈이 있으면 즐겁습니다.
하지만, 당신이 생각하는 것만큼
그냥 그렇게 오랫동안 재밌거나 깊지는 않습니다.
- DHH
영상 링크 제공해드립니다.
1. 인터뷰 전체 영상
2. Turbo 8 is dropping Typescript
https://world.hey.com/dhh/turbo-8-is-dropping-typescript-70165c01
3. 인터뷰 전체 스크립트
https://lexfridman.com/dhh-david-heinemeier-hansson-transcript
