코드가 병목이 아니었다

코딩이 병목이었던 적은 없습니다

코딩 에이전트가 빠르게 일을 합니다. 클로드 코드, 커서, 코덱스가 한 사람의 생산성을 몇 배로 끌어올립니다. 그래서 소프트웨어 산업 전체가 그만큼 빨라지고 있느냐. 의외의 답이 나옵니다. 그렇지 않습니다.

오픈소스 구조화 생성 라이브러리 `.txt`의 창업자가 4월 29일에 쓴 글이 이 역설을 정면으로 다룹니다. 제목이 "코드가 병목이었던 적은 없다(The bottleneck was never the code)". 직접 코덱스에게 1년 넘게 미뤄왔던 실험을 시켰는데 몇 시간 만에 결과가 나왔다는 경험에서 출발한 글입니다.

개인의 생산성은 분명히 폭발적으로 늘었습니다. 그런데 회사 전체의 진척은 왜 그만큼 빨라지지 않을까. 이 질문에 대한 답이, 1인 사업자에게도, 팀 리더에게도, 경영자에게도 시사하는 바가 큽니다.

50년 전 브룩스의 통찰

프레드 브룩스가 1975년에 쓴 『맨먼스 미신(The Mythical Man-Month)』은 소프트웨어 공학의 고전입니다. 그가 한 말이 있습니다.

소프트웨어는 사람들이 무엇을 만들지 협상하고 남은 잔여물이라고. 코드가 중요하지 않다는 게 아니라, 코드는 더 어려운 작업의 결과물이라는 겁니다. 진짜 어려운 작업은 사람들이 모여서 "우리가 뭘 만들어야 하는가"를 합의하는 일입니다.

지난 50년 동안 우리는 이 잔여물(코드)이 너무 비쌌기 때문에 거기에 관심이 쏠려 있었습니다. 타이핑 속도, 언어 설계, 프레임워크 선택, IDE 플러그인, 코드 리뷰 도구. 전부 코드 작성 비용을 줄이는 도구였습니다.

코딩 에이전트가 등장하면서 그 비용이 충분히 떨어졌습니다. 그러자 그 아래에 깔려 있던 것이 보이기 시작했습니다. 사람들이 합의에 이르려고 애쓰는 모습.

새로운 병목: 명세를 만드는 능력

에이전트가 구현을 담당하는 팀에서 무엇이 속도를 늦추는가. 답은 명세입니다. 에이전트가 받아서 실행할 수 있을 만큼 정밀한 명세.

로드맵이 적혀 있어야 합니다. 수용 기준이 적혀 있어야 합니다. "우리가 진짜 원하는 것"이 테스트 슈트나 티켓이나 디자인 문서로 정밀하게 표현되어야 합니다.

원글의 표현이 정확합니다. "기능이 엄청난 속도로 구현되고, 엔지니어는 더 이상 다른 엔지니어를 기다리지 않는다. 그들은 다음 잘 만들어진 명세를 기다린다. 병목이 코드를 쓰는 사람에서, 어떤 코드가 존재해야 하는지 결정하는 사람으로 옮겨간다. 즉, 매니지먼트로."

이건 1인 사업자에게도 똑같이 적용됩니다. 클로드 코드가 8시간을 일해도, 그날 아침에 "오늘 무엇을 만들 것인가"를 명확히 정의하지 못한 만큼만 결과물이 나옵니다. 도구가 빨라질수록 의사결정의 느림이 더 두드러집니다.

제번스의 역설이 코드에 적용됩니다

19세기 경제학자 제번스가 발견한 패러독스가 있습니다. 어떤 것이 싸지면 사용량이 줄지 않고 늘어난다는 것. 석탄 효율이 좋아지자 오히려 석탄 소비가 늘었습니다. 더 많은 곳에서 석탄을 쓸 만하게 됐기 때문입니다.

코드도 마찬가지입니다. 코드가 10배 싸지면 같은 결과물에 10분의 1의 노력을 쓰는 게 아니라, 이전에는 만들 가치가 없었던 것에 같은 노력을 씁니다. "시간 낭비라 안 만들던 프로토타입"이 오후에 만들어집니다. "딱히 누가 필요로 하지도 않는 사내 도구"가 만들어졌다가 잊힙니다.

원글의 한 문장이 핵심을 찌릅니다. "12개 기능이 들어간 모든 바이브 코딩 제품은 위대해지기까지 11개 기능이 모자란다."

스티브 잡스가 1997년에 한 말이 다시 인용됩니다. "포커스는 거절하는 것이다." 잡스는 그 해에 애플 제품 라인의 약 70%를 죽였고, 돌아온 회사는 빼는 법을 배운 회사였습니다.

에이전트와 함께 일하면 이 규율이 더 어려워집니다. 새 기능을 출시할 때의 짜릿함을 누구나 좋아합니다. 코드를 쓰는 비용이 거의 없으니, 만들지 말아야 할 것을 안 만드는 절제가 더 필요해집니다.

컨텍스트가 금이 됩니다

협상과 합의는 무엇 위에서 굴러가는가. 공유된 컨텍스트입니다.

컨텍스트는 조직이 굴러가는 원료입니다. 우리가 무엇을 만들고 있는지, 왜 중요한지, 무엇이 시도되었는지, 누가 무엇을 결정했는지, 무엇이 핵심이고 무엇이 흔적인지에 대한 공유된 이해. 사람들은 이걸 삼투(osmosis)로 쌓습니다. 같은 방에 있어서, 같은 슬랙 채널을 읽어서, 새벽 2시에 같은 장애를 디버깅해서.

대부분은 절대 글로 쓰이지 않습니다. 시니어 엔지니어가 PR 리뷰에서 "이거 마이그레이션 깨겠는데"라고 할 때, 그는 문서가 없는 컨텍스트를 끌어다 쓰는 겁니다.

에이전트는 삼투를 못 합니다. 방 안에 있어서 컨텍스트를 얻지 못하고, 기획 회의를 어렴풋이 듣지 못하고, 지난 장애의 기억을 갖고 있지 못합니다. 프롬프트, 파일 트리, 도구, 명시적 지시에 담지 못한 것은 에이전트가 갖지 못합니다.

원글이 정확히 짚었습니다. "컨텍스트 없이 에이전트는 약간 잘못된 버전의 질문에 그럴듯한 답을 내놓는다."

이게 1인 창업자의 특별한 도전입니다. 1인 사업에서는 모든 컨텍스트가 본인의 머릿속에 있습니다. 본인이 에이전트와 일할 때는 그 컨텍스트가 자연스럽게 흐릅니다. 그런데 두 번째 사람이 들어오는 순간, 또는 본인이 며칠 후 같은 작업으로 돌아오는 순간, 그 컨텍스트가 사라져 있습니다.

에이전트가 바꾸는 문서화

문제는 명확합니다. 컨텍스트가 율속 단계가 되었지만, 그걸 글로 쓰는 일은 사람들이 가장 안 하는 일입니다.

옛날에 "진짜 프로그래머는 자기 프로그램을 문서화하지 않는다"는 농담이 있었습니다. 농담이 아니라 사실에 가까웠습니다. 읽을 사람이 없는 문서를 쓰지 않는 게 합리적이었기 때문입니다.

여기서 흥미로운 반전이 나옵니다. 에이전트는 비합리적으로 잘 읽습니다. 모든 PR 코멘트, 모든 닫힌 이슈, 모든 커밋 메시지, 모든 묵힌 디자인 문서, 모든 슬랙 아카이브를 다 읽고, 아무도 글로 쓰지 않은 패턴을 추출합니다.

원글의 저자가 .txt에서 만들고 있다는 시스템이 이걸 보여줍니다. 코드베이스, 이슈, PR, 스레드를 크롤링해서 암묵적 결정, 관습, "왜 이렇게 했는지"를 모은 지식 베이스를 만드는 에이전트. 그 지식 베이스를 다른 에이전트가 코드에 작업할 때 사용합니다.

"이 모듈이 존재한다"가 아니라 "이 모듈이 이상한 이유는 마이그레이션이 옛 동작을 보존해야 했기 때문이다"라거나 "이 벤치마크가 중요한 이유는 이전 최적화가 분포를 조용히 바꿨기 때문이다" 같은 정보가 추출됩니다.

사람들이 비공식적으로 했던 삼투가, 에이전트도 읽을 수 있고 사람도 읽을 수 있는 형태로 외부화됩니다. 컨텍스트를 소비하는 에이전트가 컨텍스트를 생산하는 에이전트를 필요로 한다는 겁니다. 이 루프가 돌기 시작하면, 조직이 스스로는 만들지 못했을 글로 된 기반을 갖게 됩니다.

새로운 해자는 기술이 아니라 조직입니다

다음 10년의 승자는 누구일까. 원글의 결론이 명확합니다. "최고의 모델이나 최고의 에이전트 인프라를 가진 회사가 아니다. 50명, 200명, 2000명이 줄어드는 의사결정 집합에 정렬된 채로, 머리당 더 많은 산출을 낼 수 있는 회사다."

이게 문화와 관리의 문제입니다. 항상 그랬습니다.

이전 세대의 모든 도구가 같은 약속을 했습니다. IDE, 버전 관리, CI, 마이크로서비스, 데브옵스. 모두 더 나은 도구를 통해 협력 문제를 해결하겠다고 했습니다. 결과적으로 모두가 이미 존재하는 조직의 일관성을 곱하는 승수였습니다. 조직이 일관되어 있으면 도구가 그걸 증폭시켰고, 일관되어 있지 않으면 도구가 혼란을 증폭시켰습니다.

작은 팀은 일관성이 공짜로 있습니다. 그래서 가장 큰 에이전트 옹호자들이 작은 팀이고, 자기 맥락에서는 대부분 옳습니다. 일정 규모를 넘으면 일관성을 만들고 유지해야 합니다. 그러면 승수가 양방향 모두에서 날카로워집니다. 좋은 조직은 더 좋아지고, 나쁜 조직은 더 빠르게 망가집니다.

원글의 마지막 통찰이 이 글의 진짜 메시지입니다. "에이전트는 개인이 코드를 더 빨리 쓰게 하는 방법으로는 과대평가되었고, 조직이 알고 있는 것을 외부화하게 하는 방법으로는 과소평가되었다."

1인 사업자가 가져갈 것

이 글은 50명 회사 이상을 염두에 두고 쓰였지만, 1인 사업자에게도 직접적인 시사점이 있습니다.

자기 머릿속의 컨텍스트를 외부화하는 시점이 빨라져야 합니다. 1인 사업도 결국 두 번째 사람이 들어오는 날이 옵니다. 그 시점이 되어서야 컨텍스트를 글로 정리하기 시작하면 늦습니다. 지금부터 CLAUDE.md, AGENTS.md, 디자인 문서를 쌓아가는 것이 미래의 자신을 위한 일이고, 미래의 동료를 위한 일입니다.

기능을 추가하는 즐거움을 경계해야 합니다. 클로드 코드가 오후에 새 기능을 만들어줍니다. 그게 정말 만들어져야 했던 기능인지는 다른 문제입니다. 1인 사업의 가장 비싼 자원은 시간이고, 잘못된 기능에 쓴 시간은 돌아오지 않습니다. "거절하는 능력"이 1인 사업의 코어 역량이 됩니다.

명세를 쓰는 데 더 많은 시간을 써야 합니다. "에이전트한테 시키면 한 시간이면 끝나니까"라는 생각으로 명세 작성을 건너뛰면, 잘못된 한 시간짜리 결과물이 쌓입니다. 명세에 30분 쓰고 구현에 30분 쓰는 게, 명세 없이 두 시간 동안 헤매는 것보다 빠릅니다.

그리고 무엇보다, 자신이 뭘 만들고 있는지에 대한 일관된 그림을 유지해야 합니다. 이건 어떤 도구도 대신해주지 못하는 일입니다. 이 일관성이 1인 사업의 진짜 해자입니다.

코드가 싸지면 보이는 것

원글의 가장 인상적인 통찰 한 가지가 있습니다. 코드가 비쌌던 50년 동안 우리는 거기에 집중하느라 다른 것을 못 봤습니다. 코드가 싸지자, 그 아래 깔려 있던 진짜 작업이 드러났습니다. 사람들이 합의에 이르려고 하는 일.

이건 슬픈 소식이 아니라 오히려 좋은 소식입니다. 코딩 에이전트가 강력해질수록, 코드를 잘 쓰는 능력이 아니라 무엇을 만들지 명확히 정의하는 능력이 차별점이 됩니다. 의사결정을 명확하게 하고, 컨텍스트를 글로 남기고, 일관성을 유지하는 일. 이건 도구로 환원되지 않는, 사람의 일입니다.

코드를 쓰는 사람에서 코드가 무엇이어야 하는지 결정하는 사람으로의 이동. 이게 모든 규모의 조직에서, 모든 1인 사업자에서 동시에 일어나고 있는 변화입니다.

병목은 한 번도 코드였던 적이 없습니다. 50년 동안 코드처럼 보였을 뿐입니다.