책 한 권 이상 읽어야 탈 수 있는 Ride

• 직장에서는 상위권 엔지니어로 인정받아도, 실제 고수들과 비교하면 격차가 크게 벌어질 수 있으며 그 차이는 대체로 제대로 학습한 양에서 드러남
• 고등학교 이후 미술을 포기했던 경험은 Drawing On The Right Side Of The Brain 한 권과 몇 시간의 연습만으로 “적절한 자료”가 장벽을 낮출 수 있음을 보여줌
• 엔지니어링에서도 특정 주제에 대해 책 한 권 이상 읽은 사람과 거의 시도하지 않는 사람의 차이가 크며, 많은 직업군에서 후자가 다수를 이룸
• 전문성은 지역·국가·올림픽 수준의 펜싱처럼 층층이 갈라지고, 여러 권을 읽으며 깊게 파는 사람은 최상위 일자리 경쟁에 가까워짐
• 책을 읽는 것만으로는 부족하고, 좋은 자료를 고르며 나쁜 부분을 버리는 메타 스킬이 없으면 Scrum·Agile·리더십 자료를 붙잡고도 성과를 내기 어려움

---

“상위권이지만 동시에 부족하다”는 출발점

• 필자는 직업 환경에서 꾸준히 좋은 엔지니어로 인정받아 왔음
  • 주변 평균 엔지니어보다 최대 두 자릿수 배 더 공부한다고 표현함
  • 주 내 최고 수준 회사 중 한 곳에서 senior level 제안을 받은 적이 있음
  • “Serious People”이 다시 고용하려 하고, 게으른 커밋 메시지에 화를 냄
• 하지만 자신에게 이메일을 보내오는 많은 사람들과 비교하면 명확히 부족하다고 봄
  • 경력은 3~4년이고, 배경은 심리학임
  • 개인 프로젝트 외에는 테스트를 작성한 적이 거의 없고, 본인이 본 고용주들은 작동하는 테스트나 테스트 도입 의지가 없었음
  • 석사 논문 코드는 버전 관리 없이 작성했으며, 국내 최고 대학 중 하나가 버전 관리를 가르치지 않았다고 설명함
• 이 모순을 미술·엔지니어링·스포츠 사례로 풀어가며, “조금 제대로 배운 사람”과 “거의 시도하지 않은 사람” 사이의 간격을 강조함

미술에서 경험한 “적절한 책 한 권”의 효과

• 고등학교 시절 미술을 가장 싫어했고, 자신이 artsy하지 않다고 판단한 뒤 약 10년 동안 낙서 수준의 큐브 외에는 거의 그리지 않았음
• 2022년에 Drawabox 과정을 시도했지만, 매우 지루했고 진전도 없었다고 봄
• 이후 Hacker News 추천을 통해 Betty Edwards의 Drawing On The Right Side Of The Brain을 접함
  • 제목은 심리학을 떠난 필자에게 불편했지만, 추천과 before/after 사례가 있었음
  • after 그림은 너무 비현실적으로 보여 체중 감량 사기처럼 느껴졌음
• 책의 첫 과제는 자신의 손을 최대한 잘 그리는 것이었고, 필자는 30~45분 동안 그렸음
  • 당시 기준으로는 인생 최고의 그림이었지만 여전히 부족했다고 평가함
• 이후 거꾸로 된 그림의 선을 눈으로 따라 그리는 식의 연습을 했고, 몇 장을 더 그리면서 결과에 놀람
• 다시 손을 그렸을 때는 약 6시간의 독서와 연습만으로 이전보다 훨씬 나아졌음
• 이 경험은 평생 예술의 즐거움을 놓칠 뻔했지만, 맞는 책을 집어 든 뒤 장벽을 넘은 사례가 됨

“한 권의 책 장벽”과 엔지니어 분포

• 엔지니어는 크게 두 무리로 나뉨
  • 특정 주제에 대해 1권 이상 읽은 엔지니어는 대체로 매우 유능해 보임
  • 문자 그대로 책이어야 하는 것은 아니며, 충분한 양의 기술 블로그나 강의도 효율 차이는 있지만 비슷한 역할을 할 수 있음
• 반대편에는 커리어 전체에서 거의 시도하지 않는 엔지니어와 다른 직업군 사람들이 있으며, 이들이 대부분이라고 봄
  • 고수 엔지니어 Seth Newman은 평균적인 전문가를 “일하는 삶을 몽유병처럼 지나가는 사람”에 가깝게 묘사함
  • 움직임은 있지만, 계단에서 굴러떨어지는 일을 피할 인식은 부족하다는 비유가 붙음
• 필자 자신은 대부분의 직업 관련 주제에서 좋은 책 한 권 정도만 읽은 사람에 가깝다고 봄
  • Pro Git을 통해 Git 데이터 모델은 확실히 이해하지만, 그 밑의 알고리듬은 모른다고 함
  • 그래도 무작위로 고른 엔지니어를 압도하기에는 충분하다고 판단함
• Evennia 같은 프로젝트를 보면, 훨씬 깊은 수준의 사람들이 존재한다는 점도 인정함
• 여러 분야의 고성과자들과 대화한 결과, 거의 모든 분야에 제대로 시도조차 하지 않는 사람들이 많다는 반응을 들었다고 함

전문성은 끝없이 층층이 나뉨

• Seth와의 대화는 깊은 전문화가 어디까지 가는지로 이어짐
• 농구 사례로는 NBA 최하위권 선수 중 하나로 알려진 인물이 은퇴 10년 뒤 몸이 망가진 상태에서도 아마추어와 하위 프로급 선수를 압도하는 영상을 듦
• 필자의 펜싱 경험도 같은 구조를 보임
  • Melbourne에서 필자는 괜찮은 sabre fencer로 여겨졌고, 대부분의 아마추어를 이겼음
  • 그러나 주 챔피언십에 나가는 몇몇 선수들에게는 압도당함
  • 함께 훈련한 선수는 나중에 호주 Nationals에서 우승했지만, 올림픽 예선 도전 선수에게는 한 점도 따지 못했다고 함
  • Malaysia의 Yu Peng Kean은 2012년 올림픽에서 그해 우승자에게 15대 1로 졌음
• 이런 계층 구조는 Magnus Carlsen이 평생 훈련한 체스 플레이어들을 압도하는 사례처럼 낯설지 않지만, 직접 상대할 때는 전혀 다르게 느껴짐
• 상위권 선수는 항상 조금 더 멀고, 빠르고, 정확해 보이며, 상대는 어린아이가 어른에게 달려드는 느낌을 받는다고 표현함

인센티브와 “기술 업계에 잘못 들어온 사람들”

• 필자는 자신도 피아노 같은 영역에서는 몽유병 상태에 가깝다고 인정함
  • 재능 부족도 느끼지만, 실제로는 충분히 연습하지 않음
  • 다만 피아노를 직업으로 삼지 않고, 누구도 그에게 피아노 연주 대가를 지불하지 않음
• 기술 분야에서는 재능이나 관심이 없는 사람에게도 참여 인센티브를 주는 사회가 잘못됐다고 봄
  • 많은 사람은 스포츠·예술·수학 등 다른 영역에서는 깨어 있을 수 있음
  • 일부 분야에 돈이 넘치고, 대규모 조직 운영이 어렵고, 기업 자금을 개인 지위로 바꾸려는 움직임 때문에 나쁜 프로그래머와 나쁜 리더에게도 높은 임금이 지급된다고 봄
• PowerBI developer는 평균 이상 임금을 받으며 하루 6시간 이상 빈둥대기 쉬운 방법이라고 강하게 비판함
• Christopher Hitchens의 첫 직장 경험을 인용하며, 어떤 일에 계속 남아 있을 수 없을 정도로 못했기 때문에 다른 길로 나올 수 있었다는 점을 강조함

책 한 권이 만드는 경쟁 우위

• Dan Luu의 글 very little effort를 연결해, 고성과자가 되는 데 아주 적은 노력만 필요한 경우가 있다고 봄
  • 고성과자는 백플립처럼 명확한 작업을 할 수 있는 사람일 수도 있고, 다른 사람 대비 성과가 높은 사람일 수도 있음
• 책 한 권은 보통 “기술 부채를 만들지 않고 React 앱에 새 기능을 추가하는” 수준까지 데려갈 수 있음
  • 사회가 보상하는 일을 지능적으로 고르면 윤리적으로 생계를 유지하기에 충분하다고 봄
• 여러 권을 읽으면 최고 연봉 일자리 경쟁에 가까워짐
  • 같은 일을 하루에 할 수 있느냐, 일주일에 하느냐가 중요해지는 영역임
  • 경쟁자가 N권을 읽는다면 N+1권을 읽어야 하는 군비 경쟁이 됨
• Deloitte와 평균 개발자가 아무 책도 읽지 않기 때문에, 이들은 상대하기 쉽다고 봄
  • 정규직으로 조직 안에 묶이면 이런 사람들과 일해야 해서 무력감을 느낄 수 있음
  • 더 mercenary하게 움직이면 인터뷰와 미팅에서 이들을 압도할 수 있다고 판단함
• 기술 인터뷰에서는 후보자에게 좋아하는 기술책을 묻고, 면접관이 내용을 검증할 수 있는 책을 말한 사람만 대화해도 대부분의 dud candidate를 걸러낼 수 있다고 제안함
  • 면접관이 모르는 훌륭한 책을 읽은 후보자는 false negative가 될 수 있음
  • false positive는 거의 없을 것이라고 추측함

노력하지만 성과가 없는 사람들과 자료 선별 능력

• 더 복잡한 경우로, 실제로 열심히 하지만 결과를 내지 못하는 팀 운영자들이 있음
  • 엔지니어를 괴롭히고, 당황하고, 채용을 모르며, 자기 실력을 과대평가하지만 진심으로 노력함
  • 계속 Scrum을 제대로 하려고 시도하지만, 결과적으로 호수로 걸어 들어가는 몽유병자처럼 보인다고 함
• 이들에게 부족한 능력은 어떤 책을 읽을지 아는 메타 스킬임
• Drawabox와 Betty Edwards 책의 차이가 대표 사례임
  • Drawabox는 겉으로 그럴듯했지만, 필자의 목표에는 Edwards의 책이 훨씬 나았음
  • Drawabox는 Edwards가 강조한 핵심 요령을 이미 알고 있다고 가정하고 기계적 기술로 넘어갔다고 봄
  • 빠진 조각 때문에 전체 과정을 마쳐도 진전이 거의 없었을 수 있음
• 기술 분야에서는 보통 인상적인 것을 직접 만든 사람의 자료를 더 신뢰함
  • 오픈소스 유지나 가짜로 꾸미기 어려운 지식의 신호가 있으면 높은 점수를 줌
  • “큰 회사”처럼 더 흐릿한 성과는 운이나 허세로 얻을 수 있으므로 점수가 낮아짐
  • 코드는 컴파일 여부를 속이기 어렵다고 봄
• 자료 평가에 쓰는 느슨한 규칙도 제시함
  • 지나치게 눈에 띄는 이름은 감점 요소가 됨
  • 좋은 책은 표지가 지루하거나 세련된 경우가 많다고 봄
  • 제목에 “leadership”이 들어가면 대체로 헛소리일 가능성이 높다고 판단함
  • 저자가 수상을 많이 자랑할수록 거짓말처럼 느낀다고 함
  • 구어체 문체는 감점이지만, 주제가 섬세하면 결정적 결함은 아니라고 봄

Agile, The Phoenix Project, LinkedIn 학습에 대한 비판

• 직장에 Agile consultant가 들어왔고, 경영진은 좋아했지만 엔지니어에게 “Agile training을 1~5점으로 평가하라”고 물었음
  • 필자는 이 질문 자체가 의미 없다고 봄
  • 그 세션을 좋아한 사람들과 잘못된 책을 읽는 사람들 사이에 거의 100% 상관관계가 있다고 표현함
• 책 안에서도 가치 없는 부분을 버릴 수 있어야 함
  • The Phoenix Project는 좋은 아이디어가 있지만, 조직 변혁 이야기에서 나쁜 행위자를 한 명만 두고 나머지를 매우 유능하고 성실하게 만든 점이 대기업 현실과 다르다고 봄
  • 좋은 아이디어를 얻되 나머지는 “leadership fanfic”에 가깝다는 점을 알아차려야 함
• 이 선별 능력이 없으면 학습과 자기 개선이 크게 막힘
• 임원이 읽는 자료를 공개할 때, 그 사람이 일을 잘할 가능성이 낮아 보이는 경우가 즉시 드러난다고 봄
• 리더가 LinkedIn으로 학습한다고 말하면, 필자는 강한 거부감을 느낀다고 함

결론: 책을 열면 효과적이지만, 경쟁자에게 권할 필요는 없음

• 처음에는 YouTube 시대에 책을 펼치는 일의 비정상적으로 큰 효과를 되돌아보는 글이 될 예정이었음
• 실제 결론은 반어적으로, 어떤 상황에서도 사람들에게 책을 읽으라고 권하지 말라는 쪽에 가까움
• 다른 사람들이 읽지 않는 상태로 남아 있으면, 책을 읽는 사람에게는 쉬운 돈이 됨
• 다음 글은 anti-Git propaganda와 Scrum 자료 링크로 채우겠다는 농담으로 마무리함

[ndrgrd]

기술을 가져다 쓸래도 일단 그게 존재하는지는 알아야 시도라도 해 볼 테니 얕게라도 아는 것이 중요하죠.

[GN⁺]

Hacker News 의견들

• 글은 잘 쓰지만, 초보자에게 없는 숙련 엔지니어의 암묵지를 과소평가하는 듯함
  때로는 그냥 상식처럼 보이지만 실제로는 그렇지 않고, 그 결과 공감 부족으로 이어지기 쉽다. 아이나 노인과 시간을 보내거나, 힘들어하는 친척을 같은 편에서 도와보면 그런 공감이 쌓일 수 있음. 모국어 화자가 그냥 자연스럽게 말하는 것과, 언어를 배우며 고생하는 사람의 차이를 떠올리면 비슷함

  • 8살에 프로그래밍을 시작했고 형은 20대에 시작했는데, 형에게 C를 가르치면서 내가 얼마나 감각과 느낌에 의존하는지 깨달았음
    일관된 들여쓰기나 컴파일러 오류 메시지를 실제로 읽고 디버깅에 쓰는 것처럼 당연하게 여긴 부분에서 형이 어려워했다. 형이 프로그래머로 취업할 수준까지 가는 데 몇 년이 걸렸고, 사실 나도 몇 년이 걸렸는데 내 출발점을 잊고 있었던 것뿐임
  • 암묵적 기술은 중요하지만, 넓게 보면 책을 읽는 습관은 능력의 강한 지표이자 좋은 출발점임
    컨설팅 회사에서 가장 뛰어난 엔지니어는 심한 ADHD 때문에 책은 거의 읽지 않지만, 실전 경험이 엄청나고 문서와 수준 높은 블로그 글을 충분히 읽어서 어느 정도 등가성이 있어 보인다. 아주 뛰어난 사람이 “책은 별로 도움이 안 됐다”고 하면서도 그해 읽은 책 다섯 권을 줄줄이 말한 적이 있었는데, 책 자체가 그 사람에게는 크게 유용하지 않았더라도 다섯 권을 펼친 규율이 그를 정상으로 데려간 듯함
  • 체스 마스터와 비슷해 보임. 이론을 알고 있고 이론도 도움이 되지만, 종종 어느 수가 더 맞는지 그냥 “느낌”으로 안다
    그 느낌은 엄청난 양의 의도적 연습에서 나온다
  • 이런 공감은 어떻게 키울 수 있을까? 나보다 교육 수준이 낮은 사람들과 시간을 보내면 극도로 답답함을 느낌

• “커리어 내내 한 번도 제대로 시도하지 않는 엔지니어”라는 대목은 내 경험과 100% 맞음
  나는 천재 개발자는 아니고, 맡겨진 저규모 문제에 괜찮은 해법을 만들 정도의 역량은 있으며, 옳고 그른 접근에 대한 감각도 있다고 생각하지만 FAANG 면접을 볼 수 있을지도 확신이 없다. 일할 때는 늘 경계 상태인데, 잠깐만 눈을 돌리면 그렘린이 기어들어올 것 같음
  두 시니어 엔지니어가 이미 승인한 PR을 30초만 보고도 치명적 보안 결함을 발견하거나, 테스트한 5개 레코드에서는 괜찮지만 실제 데이터셋에서는 페이지당 300개 데이터베이스 질의를 날리는 로딩 패턴을 보거나, 곧바로 버릴 타임스탬프에서 날짜 객체를 복원하느라 CPU 시간의 75%를 쓰는 코드를 보는 식이다. 결국 프로그래밍에 대한 타고난 호기심·관심·열정 부족으로 보임
  나에게 좋은 프로그래밍은 장인정신에 가깝다. 비즈니스 요구 때문에 임시 땜질을 배포해야 하면 말로 표현하기 어려운 불편함이 생기고, 내가 만든 작업물이면 제품 자체에 큰 애착이 없더라도 좋게 만들고 싶다. “어떻게 동작하게 할지 몰라서 그냥 이렇게 했다”는 말을 자주 듣는데, 실제 의미는 늘 “처음 시도한 게 작은 장애물에 막히자 더 시도하지 않았다”에 가깝다. 코드베이스가 나빠질수록 자부심을 가질 수 있는 기여가 더 어려워진다
  내가 유난히 별로인 회사들만 다닌 건지, 업계 전체가 정말 이 정도인지 궁금함

  • 같이 일하는 엔지니어가 “나는 록스타 엔지니어는 아니지만, 내가 하는 일에 신경을 쓰고 그게 록스타가 아닌 부분을 메워준다고 생각한다”고 했음
    본인은 모르지만, 우리 팀의 록스타는 바로 그 사람이다. 예시를 보면 동료들이 자기 일에 별로 신경을 쓰지 않은 듯함
  • 그런 성향이라면 아마 조직의 IT 구조에서 맨 위쪽에 있게 됐을 가능성이 큼. 일을 신경 써서 하고 결과를 내니 사람들이 건드리지 않는 위치가 됨
    나는 일이 터졌을 때, 의견 충돌을 정리해야 할 때, 고칠 수 없어 보이는 걸 고쳐야 할 때, 뭔가 알아내야 할 때 모두가 부르는 사람이다. 자격이 있다고 느낀 적은 없고, Facebook 같은 곳에서는 하루도 못 버틸 것 같다. 팀에 잘 맞추고 정치 구조를 견디는 능력은 없어서 어두운 구석이 좋다
    업계 전체가 이 정도냐고 하면, 실제로는 훨씬 심함. 업계 인원이 그 어느 때보다 많아졌고, 실제로 뭔가 아는 사람을 찾기가 거의 불가능하다. 5~10년에 걸쳐 믿을 만한 사람 목록을 만들고, 절대 놓지 말고 관계를 유지해야 함
  • 보편적인 건 아니지만, 많이 찾아야 할 수 있음. 개인적으로는 작은 회사에서 맞는 사람을 찾기가 더 쉽다고 봄
    군중 속에 숨기 어렵기 때문이고, 물론 모든 규모의 회사에 똑똑하고 헌신적인 사람은 있다. 계속 불을 꺼뜨리지 말고, 원칙을 공유하거나 존중하는 사람들을 찾아가면 괜찮을 것임
  • 맞는지 틀린지는 모르겠지만, 내 경험도 비슷함
    별 관심·주의·호기심 없이 이슈에 코드를 던져 넣고 괜찮다고 여기는 사람을 너무 많이 봤다. 예전 매니저는 “불꽃”이 있는 사람을 찾았고, 나를 채용한 걸 보면 그때는 나에게도 있었던 듯함
    그런 불꽃이 없는 개발자도 갈 곳은 있고, 반대로 그런 사람만 모으려다 고생한 조직도 봤다. 하지만 돈이나 안정적일 거라 생각한 직업 때문에 들어온 부트캠프 졸업생도 많고, 그 외에는 별 관심이 없는 경우도 많다
  • 대부분의 기준으로는 뛰어난 개발자일 가능성이 크고, 다만 자기 자신과 상위 0.0001% Linux 커널 기여 천재 사이의 격차를 이해하는 저주를 가진 듯함
    2025년에 매출이 충분해서 2026년에 채용할 수 있게 되면 컨설팅 회사로 이메일을 보내보면 좋겠다

• “올바른 책”을 읽는다는 부분이 중요함. 고등학교 때 자기계발서를 몇 권 읽어봤는데, 몇 권만 읽어도 저자가 말하듯 대부분 팬픽에 가깝다는 걸 깨닫게 된다
  읽는 동안 “이건 당연한가? 이미 알고 있던 건가?”라고 계속 자문하게 되고, 예시나 이야기가 많으며, “skin in the game” 같은 단순한 은유나 구호를 삶 전체의 철학으로 확장하려는 패턴이 자주 보임

  • 정보 회상 실험을 한 대학 교수 얘기를 본 적이 있는데, 첫 번째 그룹은 원자료만 받았고 두 번째 그룹은 각각 단순한 하나의 아이디어를 담은 이야기 형태로 정보를 받았다고 함
    두 번째 그룹이 정보를 훨씬 잘 기억했다. 사람은 이야기에 이끌리는 존재이고, 가장 오래된 서사시들이 이야기인 데는 이유가 있다. 자기계발서가 그 공식을 따르는 것도 효과가 있기 때문임. 무언가를 읽는 것, 이해하는 것, 적용하는 것, 그리고 그 적용을 숙달하는 것은 서로 큰 차이가 있다
  • 자기계발이나 철학에서는 아는 것과 적용하는 것이 완전히 다름
    어떤 아이디어·루틴·과정을 완전히 받아들이고, 상황이 왔을 때 거의 본능처럼 적용할 수 있는 능력을 만드는 것이 이런 책들의 핵심이라고 봄. 어떤 책은 블로그 글이어도 충분하고, 페이지 수를 늘리기 위한 최악의 장광설도 있지만, 많은 이야기와 서사는 독자가 그중 하나에서 자신을 발견하고 교훈을 강하게 기억하게 하려는 장치다. 적절한 제목을 붙였다고 책을 탓할 수는 없음
  • 어릴 때 Taleb부터 읽은 게 도움이 됐음. Taleb은 서사 오류를 소개했는데, 깔끔한 이야기로 인과 사슬을 제시하면 사람 대부분이 비판 없이 받아들인다는 내용이다
    Cal Newport를 읽느냐는 질문을 자주 받지만, 좋은 지적과 진부한 지적을 섞은 뒤 예시와 이야기에 기대는 방식이 별로라 견디기 어렵다. 예시와 이야기가 필요한 곳은 있지만 그 방식은 설득력 있게 느껴지지 않는다. 앞의 세 가지 항목을 글 쓸 때 떠올리지 못해 아쉽고, “Skin In The Game”이 바로 Taleb의 책이라는 점도 웃김. 그 책이 나쁘다는 뜻은 아니고, 나를 이런 패턴에서 면역시킨 저자의 책이 예시로 나온 게 재미있다
  • 자기계발서와 대중 비즈니스서의 가장 큰 문제는 늘 너무 길다는 점임. “책”은 일정 분량이어야 한다는 기대 때문에 그렇게 될 수밖에 없음
    보통 초반에 좋은 아이디어 한두 개가 나오고, 나머지는 반복과 채우기다. 이 문제가 워낙 흔해서 대부분은 YouTube 요약 영상만 들어도 괜찮다고 본다. 또 하나의 요령은 항상 초판을 구하는 것인데, 대체로 더 짧고 명확함
  • If Books Could Kill 팟캐스트가 맞을 수 있음. 주로 자기계발서, 대중 비즈니스서, 대중 과학서를 다루며 반복되는 패턴과 때로는 놀라울 정도로 겹치는 주제를 많이 이야기함

• 다시 책을 읽기 시작하니 주의 지속 시간과 집중력이 크게 늘었고, 둠스크롤 욕구도 줄어들었음

  • 과소평가된 습관임. 진단받은 ADHD가 없는 사람에게도 깊은 집중은 경험과 규율로 길러지는 기술이고, 습관은 규율로 가는 지름길이다
    많은 사람이 자신에게서 ADHD처럼 보는 부분은 집중 능력이 덜 발달했거나 의도적으로 방치된 것과도 겹친다. 모두가 그렇다는 뜻은 아니다. 스스로 또는 전문가에게 ADHD 진단을 받았다면, 집중이 필요한 일을 하며 정기적으로 집중 근육을 단련하는지, 둠스크롤이나 짧은 영상 같은 쓰레기에서 스스로를 떼어놓는지 돌아볼 필요가 있다. 고통의 하인처럼 어려운 건 피하고 문제를 강화하는 행동에 빠져드는 건 아닌가. 집중력은 모두에게 소모되는 능력임

• 다소 과장됐고 현실은 더 복잡하지만, 일반 원칙으로는 동의함. 하는 일에 진심으로 신경만 써도 월급만 받으러 나오는 사람들보다 훨씬 앞설 수 있음

• “재능이나 관심이 없는 사람들을 기술 분야로 유도하기 시작한 사회가 뭔가 크게 잘못됐다”는 취지에는 상당 부분 동의하지만, 그 사고방식은 흥미로운 결론으로 이어짐
  첫째, 기술 채용 과정 전반은 업계 내부에서 불평하는 것보다도 몇 단계 더 비효율적일 수 있다. 신입 재능을 찾을 때조차 회사들이 잘못된 것을 선별하고 있을지 모른다
  둘째, 프로 스포츠나 예술처럼 긴 꼬리를 가진 직업에는 재정적 유인이 매우 나쁘다. 저자가 보는 문제를 다루려면 이 문제도 같이 다뤄야 하는데, 그 자체가 깊은 토끼굴이다
  셋째, 상황이 그렇게 나쁘다면 왜 회사들이 직원을 현장에서 직접 훈련하지 않는가
  넷째, 이 기회비용이 기본소득보다 비싼지 우리는 거의 묻지 않는다. 요즘 민간과 공공 부문의 의사결정이 서로 직교하는 경향이 있기 때문임

  • 대학에서 소프트웨어 공학을 가르치는데, 입문 수업에서 돈 때문에 들어왔고 소프트웨어 개발에 재능이나 진짜 관심이 없는 학생은 확실히 구분됨
    그들이 과정을 끝까지 통과한다고 해도, 실제로 소프트웨어 개발 직장을 얻는다고 가정했을 때 커리어에서 어떻게 될지는 아무도 모름
  • 회사가 현장에서 직원을 훈련하지 않는 이유는 단기적이고 잘못된 사고 때문임
    대부분의 곳은 모든 직원을 사실상 “완전히 훈련된 상태”로 간주하고, 이상하게도 직무 중 훈련을 직원에게 베푸는 호의처럼 취급한다. 이는 기술 노동자가 회사마다 짧게 머무는 문화와 연결되어 있을 가능성이 큼
  • https://en.wikipedia.org/wiki/Price_signal
    기술 분야 임금 상승은 프로그래머가 충분하지 않다는 신호다. 미국 경제 성장의 대부분은 이제 프로그래밍과 기술에 기반하고 있음

• 결국 “지배적인 Matlab 파일드라이버” 같은 이야기로 보임
  책 한 권 이상 읽기, 기타 치기, 이상한 취미 하나 갖기, 준프로 체조 선수 되기 등 자기 삶의 경험에서 아무거나 끼워 넣어, 별 노력 없이 자신이 얼마나 뛰어난지 또는 남들이 얼마나 멍청한지에 대한 긴 rant를 정당화하는 이야기 틀을 만드는 식이다
  독서는 촉진제이자 시작점에 가깝고, 실제로 맞아떨어지게 만드는 건 연습이다. 그리고 충분히 흥미를 느껴 찾아보고 여러 가지를 직접 시도하는 것이 중요함
  https://ludic.mataroa.blog/blog/i-will-fucking-piledrive-you...

• 이 전제에 매우 동의함. 내 기술은 세 부류로 나뉜다: 제1원리에서 직접 발명한 것, 책 한 권을 읽은 것, 그리고 못하는 것
  내가 못하는 것 중 하나가 좋은 책 찾기다. 책은 어디에나 있고 대부분은 쓰레기지만, 추천받은 책은 전부 훌륭했다. 좋은 책을 찾는 법에 대한 좋은 책이 있을까?

  • Gnod는 오래된 추천 엔진이고, 잘 동작하며 데이터를 수확하지 않음. 책 검색도 있음
    https://www.gnooks.com/faves.php
    일반 Gnod: gnod.com
  • Literature Map이 맞을 수도 있음
    https://www.literature-map.com/
    책 목록을 모아둔 사이트들도 있다
    https://www.goodreads.com/review/list/21394355-william-adams...
    https://www.goodreads.com/review/list/21394355-william-adams...
  • 관련 책은 떠오르지 않지만, 그냥 추천을 통해 찾는 것도 문제없다고 봄
    자연스럽게 추천이 들어오지 않는다면, 읽고 좋아했던 책의 추천·참고문헌, 좋아했던 저자의 다른 책, 또는 한 권을 읽고 마음에 들었던 시리즈의 다른 책에서 찾을 수 있음
  • 훌륭하다고 느낀 책의 각주와 참고문헌은 평균보다 좋은 책을 찾는 좋은 방법임
  • 책 추천에 대규모 언어 모델을 쓰기 시작했음. 원하는 것을 아주 구체적으로 말할 수 있고, 추천도 극도로 개인화된다
    Gemini처럼 대규모 언어 모델과 실시간 데이터를 결합한 도구를 쓰면 결과가 더 좋아짐

• “다른 사람이 오랫동안 생각해 준비한 것에서 배우고, 나는 훨씬 짧은 시간에 그걸 익히려 한다”는 문장과 연결됨
  https://news.ycombinator.com/item?id=40147526

• HN을 읽는 것도 자기계발에 들어갈까? 이 사이트에서 시간을 보내며 얻은 기술이나 아이디어의 “실마리”가 얼마나 많은지 셀 수 없음
  이곳의 이야기들이 아니었다면 직장을 그만두고 1인 창업자가 되지도 않았을 것 같다. 그게 좋은 선택이었는지는 아직 말하기 이르다

  • 나에게 HN은 책 읽기보다는 확실히 덜 가치 있지만, Reddit이나 소셜 미디어를 스크롤하는 것보다는 훨씬 가치 있음
    다른 방식으로는 얻지 못했을 지식을 삼투압처럼 많이 얻는다. 실제로 써본 기술은 극히 일부지만, 프로그래밍 생태계 전반에 대해서는 꽤 잘 알게 됐다. “세상에 뭐가 있는지”와 “무엇을 검색해야 하는지”를 아는 데 도움이 됨
    다만 그 삼투압 지식의 95%는 스크롤 시간의 10%만으로도 얻을 수 있을 것이다. 대체로 HN은 시간을 잘 쓰는 편이지만, 보통 나는 일부러 시간을 낭비하고 있는 중임