TECH 으로 돌아가기
TECH HACKER NEWS 오늘 6분 읽기 26 READS

편집기보다 '무엇을 만드느냐'가 먼저다: 생산성의 신기루

편집기보다 '무엇을 만드느냐'가 먼저다: 생산성의 신기루
SOURCE IMAGE · HACKER NEWS

개발자라면 누구나 한 번쯤 '더 빠르게 일하는 법'에 빠져든다. 단축키를 외우고, 에디터를 손보고, 자동화 스크립트를 짜면서 우리는 그것이 곧 실력의 향상이라고 믿는다. 그러나 도구를 갈고닦는 일과 실제로 가치 있는 결과를 내는 일 사이에는 생각보다 큰 간극이 있다. 개발 블로그 frantic.im에 실린 글 'The Productivity Mirage'는 필자 자신의 경험을 통해 이 간극을 담담하게 짚는다. 한때 자신이 생산성에 대해 갖고 있던 생각이 틀렸다는 고백이다.

화려한 세팅과 평범한 도구

필자는 페이스북에서 일하던 시절, 'Bob'이라는 전설적인 엔지니어를 언급한다. Bob은 페이스북 그룹스(Groups)를 출시한 인물이자, 사내 해커톤에서 연이어 히트작을 내놓은 다작(多作)의 개발자였다. 반면 당시의 필자는 스스로를 '생산성 덕후'라 부를 만큼 도구에 몰두해 있었다. 페이스북의 PHP 방언인 Hack을 위해 직접 만든 문법 강조와 스니펫을 갖춘 Vim 설정, mosh 위에서 돌아가는 tmux, hphpd 디버거 단축키, 정교한 git 별칭까지, 그의 개발 환경은 상당히 공들여 구축돼 있었다.

그래서 한 해커톤에서 Bob의 옆자리에 앉게 됐을 때, 필자는 큰 깨달음을 기대했다. 저 전설적인 생산성의 비밀을 눈앞에서 배울 수 있으리라 여긴 것이다. 그런데 Bob이 노트북을 열고 실행한 것은 아무런 설정도 없는 기본 상태의 Sublime Text였다. 문법 강조조차 제대로 되지 않아 코드의 절반이 엉뚱한 색으로 표시되고 있었다. 라이브 리로딩도 쓰지 않았고, 디버거도 사용하지 않았다. Bob은 그저 코드 곳곳에 printf를 흩뿌려 넣고, 로그가 찍히기를 느긋하게 기다렸다.

놓치고 있던 진짜 변수

필자는 충격을 받았다. 이렇게 투박한 방식으로 어떻게 저토록 많은 성과를 낼 수 있단 말인가. 그리고 그날 해커톤에서도 Bob은 어김없이 우승했다. 흥미로운 대목은 필자의 회고다. 그는 Bob이 '어떻게' 작업하는지에만 온통 정신이 팔린 나머지, 정작 Bob이 '무엇을' 만들고 있었는지는 거의 놓쳤다고 털어놓는다. 필자의 기억으로 그것은 그룹스의 물건 사고팔기(buy/sell) 게시물 기능이었고, 이는 훗날 페이스북 마켓플레이스로 발전했다. 결국 그를 다작 개발자로 만든 것은 에디터 세팅이 아니라 제품에 대한 감각과 직관이었다는 것이다.

이 일화가 가리키는 지점은 분명하다. 도구의 완성도와 결과물의 가치는 반드시 비례하지 않는다는 것이다. Bob이 우승할 수 있었던 이유는 남들이 미처 보지 못한, 혹은 우선순위에 두지 못한 '풀어야 할 문제'를 정확히 골라냈기 때문이다. 어떤 문제를 붙잡느냐가 어떻게 코드를 짜느냐보다 앞서는 변수였던 셈이다.

실무자에게 남기는 질문

이 이야기는 오늘날 한국의 개발 실무자에게도 그대로 겹쳐 읽힌다. 필자는 X(옛 트위터)를 둘러볼 때마다 이 일화를 떠올린다고 말한다. 매일같이 누군가가 '모든 것을 바꿔놓을' 새로운 작업 방식을 발명하고, 그중 일부는 실제로 판도를 바꾸기도 한다. 최근의 AI 코딩 도구 열풍을 떠올리면 이 감각은 더욱 실감난다. 새로운 에디터, 새로운 워크플로, 새로운 자동화가 끊임없이 등장하고, 그것을 따라잡지 못하면 뒤처진다는 불안이 업계를 감돈다.

물론 좋은 도구를 부정할 이유는 없다. 잘 다듬은 개발 환경은 반복 작업의 마찰을 줄이고, 집중을 유지하는 데 분명히 도움이 된다. 이 글도 도구 자체가 무의미하다고 말하지는 않는다. 다만 도구를 손보는 만족감이 '일을 잘하고 있다'는 착각으로 이어질 때, 그것이 바로 제목이 말하는 신기루라는 점을 경계할 뿐이다. 세팅에 쏟는 시간은 눈에 잘 보이고 성취감도 즉각적이지만, 그 시간이 정작 문제 선택과 제품 판단에 쓰여야 할 몫을 갉아먹을 수 있다.

한 가지 유의할 점은, 이 글이 한 개발자의 개인적 회고와 관찰에 기반한 에세이라는 사실이다. 해커톤이라는 특수한 환경의 단면이며, 통계나 실험으로 뒷받침된 주장은 아니다. 또한 Bob의 투박한 방식이 곧 '올바른 개발법'이라는 뜻도 아니다. 요점은 방법론의 우열이 아니라 우선순위에 있다. 결국 가장 중요한 것은 올바른 문제를 푸는 일이라는 것, 도구는 그 목적에 봉사하는 수단일 때 비로소 값어치를 한다는 것이다. 새로운 워크플로에 마음이 흔들릴 때마다 '나는 지금 도구를 다듬고 있는가, 아니면 풀 만한 문제를 고르고 있는가'를 자문해 보는 것만으로도, 이 글이 말하는 신기루에서 한 걸음 벗어날 수 있다.

SOURCE · HACKER NEWS
원문 전체 보기 → https://frantic.im/mirage/
SHARE
처리 중...