도구의 망각 - 개발자 생산성의 본질에 관하여

# 도구의 망각 — 개발자 생산성의 본질에 관하여 도구를 많이 아는 개발자가 빠른 것은 아니다. 정작 빠른 개발자는 자신이 어디에서 시간을 흘리고 있는지를 안다. 언젠가 사내 데이터 파이프라인을 정리하다 6천만 행이 넘는 로그 테이블 앞에 앉은 적이 있다. 동료가 새로 나온 분석 도구를 추천했고, 나는 일주일 동안 그 도구의 문서를 파고들었다. 결과는 초라했다. 진짜 병목은 도구가 아니라, 매일 아침 같은 SQL을 다섯 번 복사해 다섯 개의 환경에 붙여 넣던 내 손가락에 있었다. 도구 이전에 의식(儀式)이 있었고, 그 의식을 알아채는 데 일주일이 걸린 셈이다. ## 반복의 냄새를 맡는 법 생산성에 관한 책은 대부분 "무엇을 쓸 것인가"부터 말한다. 그러나 정말 중요한 것은 그 앞 단계, 곧 **무엇을 자동화할지 결정하는 단계**다. 도구는 답이지 질문이 아니다. 질문은 작업 흐름 안에 숨어 있다. 반복은 세 가지 형태로 나타난다. 같은 동작의 반복, 같은 판단의 반복, 같은 대기의 반복. 표면적으로 비슷해 보이지만 처방은 전혀 다르다. - **동작의 반복**은 셸 별칭, 스니펫, 매크로로 해결된다. 가장 단순하고 즉각적인 효과를 낸다. - **판단의 반복**은 체크리스트와 린터, 코드 리뷰 자동화로 흡수된다. 매번 같은 결정을 내리고 있다면, 그 결정은 이미 규칙이다. - **대기의 반복**은 가장 까다롭다. CI 파이프라인이 7분 걸린다면, 그 7분 동안 컨텍스트를 잃는 것이 진짜 비용이다. 빌드 캐시, 병렬 테스트, 사전 검증 훅이 이 영역에 속한다. 자기 작업의 어느 지점에서 어떤 반복이 일어나는지 분류하지 않은 채 도구만 고르면, 망치를 사놓고 못을 찾는 일이 벌어진다. 156개의 인터페이스를 다루는 프로젝트에서 한동안 그렇게 살아본 적이 있다. 도구는 늘었지만 시간은 줄지 않았다. ### 측정되지 않는 낭비 낭비의 가장 무서운 형태는 측정되지 않는 낭비다. 빌드 시간은 누구나 잰다. 그러나 "빌드를 기다리며 트위터를 여는 시간"은 아무도 재지 않는다. 컨텍스트 스위칭의 비용은 빌드 로그 어디에도 찍히지 않는다. 일주일에 하루를 정해, 자신이 무엇을 했는지 30분 단위로 기록해본 적이 있는가. 처음 해보면 대부분의 개발자는 충격을 받는다. 실제 코드를 쓴 시간은 두세 시간 남짓이고, 나머지는 환경 설정, 자료 검색, 동기 회의, 알림 확인이다. 진짜 자동화 대상은 코드를 쓰는 일이 아니라, 코드를 쓰기 위해 거쳐야 하는 그 모든 변두리다. ## AI에게 판단을 맡기지 않는 기술 지난 2년 사이 생산성 논의는 거의 전부 AI 보조 도구로 수렴했다. 이 흐름 자체는 정당하다. 그러나 흐름을 인정하는 것과, 흐름에 자신을 맡기는 것은 다른 일이다. AI 보조 코딩 도구는 두 가지를 잘한다. **이미 알고 있는 패턴을 빠르게 타이핑하는 일**, 그리고 **모르는 영역의 초안을 던져주는 일**. 둘 다 가치 있다. 그러나 어느 쪽도 판단을 대체하지는 않는다. AI가 판단을 대체한다고 믿는 순간 두 가지 사고가 일어난다. 하나는 **검증되지 않은 코드의 누적**이다. 그럴듯해 보이는 코드가 리뷰를 통과하고, 6개월 뒤 새벽 3시에 알 수 없는 예외로 깨어나는 일. 다른 하나는 **개발자 자신의 근육 손실**이다. 매일 답을 받기만 하면 질문을 만드는 능력이 퇴화한다. 질문하는 능력이야말로 시니어와 주니어를 가르는 거의 유일한 척도다. 그래서 나는 AI 도구를 두 가지 방식으로만 쓴다. 1. **조기 정보 제공자로서.** 라이브러리 시그니처, 에러 메시지의 일반적 원인, 마이그레이션 시 흔한 함정. 미리 알면 30분의 삽질이 3분으로 줄어든다. 2. **초안 작성자로서.** 보일러플레이트, 테스트 케이스 골격, 문서 초안. 이 영역에서 AI는 의심할 여지 없이 탁월하다. 판단은 여전히 내가 한다. AI가 제안한 코드를 그대로 커밋한 적은 거의 없다. 변수명, 에러 처리, 경계 조건은 거의 항상 손을 댄다. 그 손길이 곧 책임의 표식이다. > 도구가 똑똑해질수록, 그 도구를 다루는 인간은 더 명확한 판단 기준을 가져야 한다. 그렇지 않으면 똑똑한 도구는 어리석은 결정을 빠르게 양산하는 기계로 전락한다. ## 도구 스택을 설계하는 세 가지 원칙 도구를 추가할 때마다 세 가지 질문을 던진다. 답하지 못하는 도구는 설치하지 않거나, 설치했더라도 한 달 안에 제거한다. **첫째, 이 도구가 사라지면 무엇이 무너지는가.** 사라져도 아무것도 무너지지 않는 도구는 사실 쓰이지 않는 도구다. 디스크 위에 누워 알림만 보내는 유령들이다. VS Code 확장을 47개 깔아두고 그중 일곱 개만 실제로 쓰는 동료를 본 적이 있다. 나머지 마흔은 시동 시간만 잡아먹는다. **둘째, 이 도구의 학습 비용이 절약되는 시간을 넘지 않는가.** 어떤 도구는 익히는 데 일주일이 들고, 일 년에 두 시간을 절약한다. 그것은 도구가 아니라 취미다. 취미를 부정하는 것이 아니라, 취미와 생산성 도구를 구분하자는 것이다. **셋째, 이 도구가 팀과 충돌하지 않는가.** 개인의 도구 선택은 자유이지만, 그 선택이 팀의 코드베이스에 흔적을 남긴다면 합의가 필요하다. 포매터, 린터, 커밋 훅이 그렇다. 개인의 효율을 위해 만든 규칙도 팀 전체의 균형을 깨면 결국 모두의 효율을 떨어뜨린다. ### 도구를 잊는 단계 가장 좋은 도구는 그 존재를 잊게 만드는 도구다. 매일 쓰는 셸의 자동완성, 저장과 동시에 도는 포매터, 의식하지 않아도 흘러가는 CI. 작동하고 있다는 사실조차 의식하지 않을 때, 도구는 비로소 환경이 된다. 장자(莊子)는 포정해우(庖丁解牛)의 우화에서 19년 동안 같은 칼을 쓰면서도 칼날이 무뎌지지 않은 백정의 이야기를 적었다. 그는 소를 보지 않고 결을 보았고, 도구를 쓰지 않고 흐름을 따랐다. **"도(道)가 기예에 앞선다(道進乎技矣)"**는 말은, 2,300년이 지난 지금도 개발자의 책상 위에서 유효하다. 도구가 환경이 되면, 의식은 비로소 본질적인 문제로 향한다. 어떤 자료구조가 옳은가. 이 추상화는 정당한가. 이 사용자는 무엇을 원하는가. 도구를 의식하는 한, 이런 질문에 쓸 인지 자원은 남지 않는다. ## 생산성의 다른 이름 오랫동안 생산성은 "단위 시간당 산출"로 정의되어 왔다. 그러나 그 정의는 공장의 언어이지, 사유의 언어가 아니다. 개발자의 산출물은 대개 코드가 아니라 **결정**이다. 어떤 기능을 만들지, 어떤 부채를 갚을지, 어떤 사용자를 포기할지 결정하는 일. 이 관점에서 보면 생산성은 결정의 질과 속도의 곱이다. 도구는 속도를 올린다. 그러나 질을 올리는 것은 도구가 아니라, 도구가 비워준 시간 속에서 자라난 사유다. 도구를 통해 절약한 시간을 더 많은 도구를 익히는 데 쓴다면 그 절약은 무의미하다. 절약한 시간은 결국 사유에 쓰여야 한다. 논어는 "지지자불여호지자, 호지자불여낙지자(知之者不如好之者, 好之者不如樂之者)"라 했다. 아는 자가 좋아하는 자만 못하고, 좋아하는 자가 즐기는 자만 못하다. 도구의 단계도 그러하다. 도구를 아는 단계, 도구를 잘 쓰는 단계, 그리고 도구를 잊고 일에 몰입하는 단계. 세 번째 단계에 도달한 개발자의 책상은 의외로 단순하다. 화려한 대시보드도, 최신 확장 팩도 없다. 그 자리에는 손에 익은 몇 개의 도구와, 그 도구들이 만든 침묵이 있을 뿐이다. 결국 생산성이란 무엇을 더하는 일이 아니라, 무엇을 덜어내고도 충분한지를 아는 일이다. 어제의 나에게 필요했던 도구가 오늘의 나에게도 필요한지. 이 질문을 분기마다 정직하게 던질 수 있다면, 도구는 늘 가벼울 것이다. 그리고 가벼운 도구만이 멀리 간다.