생산성의 신기루

• Facebook의 전설적인 엔지니어 Bob은 정교한 개발 환경 없이도 Facebook Groups를 출시하고 해커톤에서 연이어 성과를 냈음
• 기본 Sublime Text와 printf 로그만 사용했으며, 구문 강조가 부정확하고 라이브 리로딩과 디버거도 없는 환경이었음
• 반면 주변 개발자들은 Vim 구문 강조와 스니펫, tmux, mosh, hphpd 단축키, Git 별칭 등 복잡한 도구 구성을 생산성의 핵심으로 여겼음
• Bob의 해커톤 우승에는 편집기 설정보다 제품 감각과 직관, 즉 무엇을 만들지 판단하는 능력이 더 크게 작용했음
• 새로운 작업 방식이 변화를 만들 수는 있지만, 궁극적인 성과는 올바른 문제를 해결하는 일에서 나옴

---

복잡한 도구와 실제 성과의 차이

• Bob은 Facebook Groups를 출시한 다작 엔지니어이자 해커톤에서 연이어 결과물을 내놓은 전설적인 인물이었음
• 당시 생산성에 몰두하던 동료는 Facebook의 PHP 방언인 Hack을 위해 직접 만든 Vim 구문 강조와 스니펫을 사용했음
  • mosh 위에서 tmux를 실행하고, 맞춤형 hphpd 단축키와 Git 별칭까지 구성했음
• Bob의 작업 방식은 이와 대조적으로 매우 단순했음
  • 별도 설정 없는 Sublime Text를 사용해 코드 색상의 절반가량이 잘못 표시됐음
  • 라이브 리로딩이나 디버거 대신 코드에 printf를 넣고 로그가 나오기를 기다렸음
• 그날 해커톤에서 Bob은 우승했으며, 작업물은 Facebook Groups에서 구매·판매 게시물을 지원하는 기능이었던 것으로 기억됨
  • 이 기능은 이후 Facebook Marketplace로 발전했음

어떻게보다 무엇을 만들 것인가

• 복잡한 도구에 집중하면 작업 방식인 어떻게에 매몰돼 작업 대상인 무엇을 놓칠 수 있음
• Bob의 높은 생산성을 만든 핵심은 편집기 설정이 아니라 제품 감각과 직관이었음
• X에는 매일 모든 것을 바꿀 듯한 새로운 작업 방식이 등장하며, 그중 일부는 실제 변화를 만들 가능성도 있음
• 그러나 가장 중요한 것은 도구나 작업 방식 자체가 아니라 올바른 문제를 푸는 일임

[GN⁺]

Hacker News 의견들

• 도구를 아끼는 장인과 도구에 집착하는 사람을 양분하는 건 잘못임. 좋은 도구는 장난감이 아니라 목적을 위한 수단이며, 나도 작업 흐름에 맞춘 셸 스크립트, Emacs 함수, 창 배치 도구 등을 만드는 데 여러 날을 썼음
  그 결과 구문 강조, 코드 탐색·분석, 화면 배치, Git 조작이 몇 번의 키 입력만으로 되고 집중을 깨는 요소가 사라졌음. 의자, 셸 프롬프트, 편집기 같은 작업 환경에 투자하되 편안해진 뒤에는 잊고 실제 문제에 집중하면 됨
  다만 끝없는 도구 조정은 버겁고 재미없는 과제를 피하려는 신호일 수 있으며, 이는 도구 자체의 잘못처럼 단순한 문제는 아님

  • 새 직장에서 새로운 기술 스택과 Windows 노트북을 받으면 어떻게 할 것인가? 경력 초기에 주어진 환경의 기본 도구만으로 효율적으로 일하는 법을 익혔고, 실제로 도구를 직접 선택할 수 있는 경우는 드물었음. 크로스 플랫폼 도구도 JetBrains 제품군을 제외하면 일관성이 떨어지는 편임
  • 사무라이와 닌자의 차이처럼 보임. 사무라이는 검을 영혼의 연장으로 여겼지만 닌자는 필요하면 검으로 물건도 비틀어 열었음. 오늘날 경제에서는 사무라이식 도구관이 맞지 않음
  • 도구를 즐겁게 사용하는 건 중요함. 생산성이 10배가 되지 않더라도 작업에 집중하고 과정을 즐기는 게 핵심임
    특히 LLM 시대의 도구는 여러 에이전트와 터미널 사이를 계속 오가게 함. 이런 잦은 문맥 전환은 즐거움과 몰입 상태를 빼앗으므로 누군가 해결책을 찾았으면 함
  • 초보자가 인정받고 진지하게 받아들여지고 싶어서 필요한 단계를 건너뛰는 경우가 많아 보임. 그렇게 보이는 것과 실제로 그렇게 되는 것은 다르며, 실력을 쌓는 동안 생계도 감당해야 함
  • 기술을 숙달한 뒤에는 좋은 도구 자체가 큰 즐거움이 됨. 반대로 숙련자는 때때로 부적합한 도구로도 놀랄 만큼 좋은 결과를 낼 수 있음

• 많은 기술자가 실제로 만드는 것보다 환경 설정 최적화에 더 많은 시간을 쓰는 모습을 봤고, 나도 그런 적이 있음. 코딩 시간의 90%가 타이핑이니 입력 속도를 높여야 한다는 생각은 잘못됐으며, 시간의 90%는 사고에, 그중 대부분은 읽기에 써야 함

  • 소프트웨어는 문제에 대한 해법이 구체화된 것이므로 먼저 풀 문제를 정의해야 함. 코드는 현재의 문제 이해도와 해법의 명확성·적절성을 미래의 자신을 포함한 모두에게 보여주는 스냅숏임
    적절한 시점의 코딩은 이미 이해한 해법을 구체화하는 타이핑 작업에 가까움
  • 예전에는 설정에 집착했지만 AI를 사용한 뒤로는 전에는 만들지 못했을 멋진 것들을 만들고 있음. 반면 기반 코드에 대한 이해와 기존 실력은 서서히 약해지고, 새로운 기법에 감탄하면서도 깊이 배우지는 못하는 듯함
    AI가 시작할 때 넘어야 할 문턱을 낮춰 줬다는 점에서 또 다른 형태의 환경 개선이기도 함. 예전에 QA 역할에서 개발자로 옮기려 유럽을 여행하며 InterviewCake를 공부할 때도 문제 풀이보다 편집기 설정을 다듬는 데 시간을 낭비했음
    이것이 ADHD의 증상일 수도 있음. 최근 약물 치료 후 생산성이 크게 달라졌고, 실제 일을 하기보다 설정을 완벽하게 만드는 데 인생의 절반을 허비했다는 생각에 눈물이 날 정도였음
  • 실제 생산성과 체감 생산성 사이에는 괴리가 있음. Vim이나 Emacs로 코드를 능숙하게 누르면 해커가 된 기분은 들지만 생산적이라는 뜻은 아님. 막대한 토큰으로 AI 에이전트 수십 개를 지휘해도 결과물이 작동하거나 문제를 해결한다는 보장은 없음
  • 평범한 CRUD 애플리케이션 개발자 대부분에게 시간의 90%를 사고와 읽기에 써야 한다는 비율이 정확한지는 모르겠음
  • 사고와 타이핑은 흔히 동시에 일어남. 많은 사람은 코드를 작성하고 수정하면서 문제를 더 쉽게 추론하며, LLM이 만든 코드를 전부 읽더라도 코드 이해도가 크게 낮아질 수 있는 이유이기도 함

• 실제 사용하거나 돈을 내는 제품을 만들지 못하는 VC 투자 기업들이 존재함. 이들은 기업가치를 정당화하려고 얼마나 바쁘고 생산적인지를 보여 주며, AI 열풍도 무엇을 만들 것인가보다 생산성과 방법에만 집중한다는 점에서 같은 맥락일 수 있음
  https://components.news/the-gamer-and-the-nihilist/는 이런 허무주의적 스타트업과 사람들이 돈을 내고 사용하는 제품을 만드는 게임 개발사를 비교함. 생산성 앱이 Product Hunt 결과물의 거의 40%를 차지하는 경제에서는 실제 무언가를 만들기보다 만드는 것처럼 보이는 데 노동이 투입되기도 함

  • 게임 개발자도 도구 제작에 막대한 노력을 들이지만, 주된 대상이 텍스트 편집기는 아닐 뿐임
  • 게임보다 완벽한 게임 환경을 만드는 데 수없이 많은 시간을 쓰는 사람이나, 음악보다 완벽한 장비를 평생 찾아다니는 오디오 애호가는 이 비유에서 어디에 속하는지 궁금함
  • 거품이라기보다 오래전부터 반복된 신호 조작에 가까움. 늘 있었고 앞으로도 계속될 것임

• 뒤처지지 않을 정도로만 생산성 도구를 만들거나 사용하고, 그 이상은 함정으로 봄. 예전에는 분기마다 한 번 점검했지만 AI 이후에는 주 1~2일을 도구 개선이라는 메타 작업에 쓰고 있으며, 관련 도구가 표준화되면 줄어들 것으로 예상함
  도구 전문가라는 이미지가 강해지면 실제 가치 있는 일을 놓칠 뿐 아니라 비밀스러운 생산성 비법을 가진 사람으로 평가받게 됨. 기대만큼 차이가 나지 않으면 다른 판단까지 신뢰받지 못할 수 있음

• 컴퓨터 앞에 있는 시간이 줄수록 더 많은 일을 처리했고, 모니터를 3대에서 1대로 줄이자 생산성이 크게 높아졌음. 채소를 썰거나 잔디를 깎을 때 대부분의 문제를 해결하며, 빛나는 기술 앞에 앉아 있다고 더 빠르고 좋은 판단이 나오는 건 아님
  고객사 개발팀보다 좋은 성과를 내는 이유도 정규직이 아니라 충분히 멈춰서 천천히 생각할 수 있기 때문임. Teams의 상태 표시를 녹색으로 유지하려는 압박 같은 생산성 연극이 많은 조직에서 어리석은 결정을 만들어냄

  • 15년 동안 캘리포니아 La Jolla의 바다가 내려다보이는 절벽에 사무실을 둔 두 회사에서 일했음. 절벽과 공원을 걸으며 업무를 생각했고, 화이트보드가 필요 없는 진지한 논의라면 동료에게 함께 걷자고 했음. Rich Hickey의 hammock talk를 다시 들어볼 만함
  • 사용자 이름을 보니 글에 등장한 Bob인지 궁금함

• 생산성이 존재하는 이유를 생각해 보니 고통을 줄이려는 시도라는 가설에 도달했음. 프로그래머 생산성을 포함한 여러 성능 최적화는 문제 영역의 모호함, 조직 정치, 불명확성, 실패 위험 같은 고통을 피하려는 엔지니어의 도피처가 되곤 함
  하지만 현실의 문제를 해결하려면 사용자 작업 흐름을 지루할 만큼 세밀하게 검토하고, 공동 전략을 명확히 제안해 다른 사람의 협력을 얻는 등 현실과 맞서야 함. 고통 자체를 미화할 필요는 없지만 좋은 결과물에는 운동선수 같은 훈련이 내재하며, 경기장에서 필요한 고통을 관리하는 능력을 길러야 함

• 핵심은 인정받기 쉬운가에 있음. 반짝이는 도구는 누구나 보고 감탄할 수 있지만 빈 편집기나 뼈대 코드에서 훌륭한 신제품·기능을 알아보는 사람은 드묾. 그래서 눈에 잘 보이는 도구에는 관심이 몰리고, 어렵고 불분명한 무엇을 만들 것인가는 외면받음
  도구에는 Marie Kondo식 기준을 적용함. 사용이 즐겁지도 않고 삶을 편하게 하지도 않으면 버리고, 그렇다면 유지함

• 2004년, 대부분 초급 개발자로 구성된 작은 팀이 훌륭하고 방대한 Java 교육을 받게 됐음. 교육 전에 IntelliJ와 Eclipse 설정에 집착하며 치열하게 토론했지만, 강사는 놀랍게도 기본 JDK 도구와 Notepad만 쓰라고 권했음
  내부에서 무슨 일이 일어나는지 배우게 하려는 목적이었고, 생산성도 아마 큰 차이가 없을 것이라고 했음

• 환경 최적화에 집착하는 이유는 집중한 노력과 보상의 연결이 눈에 보이고 구체적이며 물리적이기 때문임. 반면 추상적 학습은 그렇지 않음. 의자를 최적화할 일보다 학습 과제가 훨씬 많으니, 추상적 학습도 더 구체적으로 느끼게 만들 방법이 있으면 좋겠음

• 생산성이 아니라 장난감을 갖고 노는 재미에 관한 것임