생산성 도구보다 중요한 건 결국 ‘무슨 문제를 푸느냐’라는 이야기

글쓴이는 한때 생산성 도구에 꽤 진심이었던 개발자였음

• Facebook의 PHP 방언인 Hack을 위해 Vim 문법 강조와 스니펫을 직접 만들었음
• tmux를 mosh 위에서 돌리고, hphpd 단축키와 git alias까지 갖춘 꽤 빡센 세팅을 쓰고 있었음

그러다 Facebook에서 전설처럼 회자되던 엔지니어 밥 옆자리에 앉게 됨

• 밥은 Facebook Groups를 비롯해 굵직한 기능을 많이 출시한 엔지니어였고, 해커톤에서도 계속 히트작을 내던 사람임
• 글쓴이는 당연히 엄청난 개발 환경이나 작업 비법을 보게 될 거라고 기대함

그런데 밥이 연 건 화려한 IDE도, 튜닝된 Vim도 아니고 거의 기본 상태의 Sublime Text였음

• 문법 강조도 제대로 안 돼서 코드 색이 여기저기 틀리게 보였음
• 라이브 리로딩도 안 쓰고, 디버거도 안 쓰고, 그냥 printf를 뿌린 뒤 로그를 기다리는 방식으로 디버깅함

더 웃긴 건, 그렇게 일한 밥이 그날 해커톤에서 우승했다는 점임

• 글쓴이는 밥이 ‘어떻게’ 일하는지에 너무 꽂혀 있다가, 정작 밥이 ‘무엇을’ 만들고 있는지는 놓쳤다고 함
• 아마 Groups의 buy/sell posts 지원이었고, 이 기능은 나중에 Facebook Marketplace로 발전한 것으로 보인다고 회상함

글의 핵심은 생산성의 본질을 도구에서 찾으면 놓치는 게 많다는 얘기임

• 밥의 강점은 에디터 세팅이 아니라 제품 감각과 직관이었음
• 어떤 기능이 사용자에게 먹힐지, 지금 풀어야 할 문제가 뭔지 보는 능력이 개발 속도보다 더 큰 차이를 만든 셈임

요즘 X를 보면 매일 ‘모든 걸 바꿀 새 작업 방식’이 등장한다는 말도 붙음

• 어떤 방식은 실제로 큰 변화를 만들 수도 있음
• 그래도 마지막에 남는 질문은 똑같음. 이 도구로 더 빨리 치는 게 중요한가, 아니면 애초에 맞는 문제를 풀고 있는가임

개발자 입장에서는 꽤 찔리는 글임

• 새 에디터, 새 플러그인, 새 AI 코딩 워크플로우를 만지는 건 재미있고 실제로 효율도 올려줌
• 다만 그게 제품 판단, 사용자 이해, 문제 선택을 대신해주지는 못함. 결국 공유하고 싶은 한 줄은 이거임. 생산성은 속도가 아니라 방향까지 포함함