병목 현상은 결코 코드가 아니었다

지난달, 저는 .txt에서 1년 넘게 미뤄왔던 실험을 마침내 실행했습니다.

목표는 우리의 구조화된 생성 (structured-generation) 알고리즘과 그 오픈 소스 (open-source) 대응물들을 테스트하는 것이었습니다. 단순히 "이 문자열을 수용하는가?"라는 단순한 질문을 대신하여, 실제 문제에 더 가까운 "올바른 토큰 분포 (token distribution)를 생성하는가?"를 검증하고자 했습니다.

이 실험은 대화 중에 계속 언급되었고, 다시 로드맵 (roadmap)으로 돌아왔습니다. 지난달, 저는 Codex에게 이 방법론을 설명하는 데 30분을 썼습니다. 몇 시간 후, 그것은 작동하는 첫 번째 버전을 만들어냈습니다. 그게 전부였습니다.

코딩 에이전트 (Coding agents)는 개인이 코드를 작성하는 방식을 변화시키고 있습니다. 어떤 면에서 그것은 이미 일어난 일입니다. 하지만 저는 사람들이 보통 이 현상이 소프트웨어 산업에 무엇을 의미하는지에 대해 말하는 이야기, 즉 개인의 생산성 향상이 산업 전체의 상당한 속도 향상으로 이어질 것이라는 이야기에 대해서는 여전히 회의적입니다. 저는 몇 달 동안 그 긴장 상태에 머물러 있었습니다.

이제 고전을 다시 읽을 시간입니다.

영향력 있는 소프트웨어는 협업이 필요한 많은 인간에 의해 작성되는 경향이 있습니다.

코딩 에이전트에 대한 논의는 거의 예외 없이 개인의 생산성 향상에만 집중합니다. 하지만 협업 (collaboration)이야말로 흥미로운 분석 단위입니다.

이것은 결코 새로운 아이디어가 아닙니다. Fred Brooks는 1975년 The Mythical Man Month에서 이에 대해 썼고, 그때도 새로운 것이 아니었습니다. Gerald Weinberg는 1971년 The Psychology of Computer Programming에서 이 개념을 소개했습니다. 소프트웨어란 인간 집단이 시스템이 무엇을 해야 하는지에 대해 서로 협상(negotiating)을 마친 후 남겨진 잔여물입니다. 코드는 중요하지만, 그것은 더 어려운 작업의 결과물(residue)일 뿐, 작업 그 자체는 아닙니다.

지난 50년 동안 그 잔여물은 우리의 주의를 집중시키기에 충분할 만큼 비용이 많이 들었습니다. 타이핑 속도, 언어 설계 (language design), 프레임워크 선택 (framework choice), IDE 플러그인, 코드 리뷰 도구 (code review tooling)는 모두 이 잔여물의 비용을 줄이기 위한 것이었습니다. 코딩 에이전트와 함께라면 그 비용이 충분히 낮아져서, 그 밑에 무엇이 있는지 볼 수 있게 됩니다. 바로 사람들이 합의하려고 노력하는 모습입니다.

협상하고, 합의하고, 우리가 무엇을 만들고 있는지에 대한 공유된 그림을 전달하는 것이 바로 핵심적인 업무가 되었습니다. 그리고 이는 예전만큼이나 어렵습니다.

로드맵(Roadmap)이 한계다

에이전트(Agents)가 구현을 담당하는 팀에서 속도를 늦추는 것은, 에이전트가 바로 가져가서 실행할 수 있을 만큼 정밀한 사양(Specifications)을 만들어내는 일입니다. 문서화된 로드맵(Roadmap). 문서화된 수락 기준(Acceptance criteria). 테스트 스위트(Test suite), 티켓(Ticket), 또는 서면 설계(Written design)를 통해서든,

컨텍스트(Context)는 조직이 운영되는 데 필요한 핵심 자산입니다. 그것은 우리가 무엇을 만들고 있는지, 그것이 왜 중요한지, 무엇이 시도되었는지, 누가 무엇을 결정했는지, 무엇이 핵심적인 지지 구조(load-bearing)이고 무엇이 퇴화한 부분(vestigial)인지에 대한 공유된 이해입니다. 팀 내의 인간은 삼투 현상(osmosis)을 통해 이를 축적합니다. 같은 공간에 있음으로써, 같은 Slack 채널을 읽음으로써, 혹은 새벽 2시에 같은 장애(outage)를 디버깅함으로써 말입니다. 그중 대부분은 결코 문서로 기록되지 않습니다. 시니어 엔지니어가 PR(Pull Request)을 리뷰하며 "이것은 마이그레이션(migration)을 깨뜨릴 것입니다"라고 말할 때, 그들은 문서화되지 않은 컨텍스트를 활용하고 있는 것입니다.

에이전트(Agents)는 삼투 현상을 할 수 없습니다. 그들은 같은 공간에 있다고 해서, 계획 회의를 어렴풋이 들었다고 해서, 혹은 지난 장애의 기억을 가지고 있다고 해서 컨텍스트를 얻지 못합니다. 프롬프트(prompt), 파일 트리(file tree), 도구(tools), 또는 명시적인 지침(explicit instructions) 안에 담아내지 못한 것은 무엇이든, 에이전트는 이를 안정적으로 보유하지 못합니다. 컨텍스트가 없다면, 에이전트는 질문의 미세하게 잘못된 버전에 대해 그럴듯한 답변을 내놓을 뿐입니다.

따라서 제가 .txt에서 유용한 일을 해낸 에이전트를 보고 흥분할 때, 솔직한 계산을 해보면 우리가 컨텍스트 작업을 수행한 것입니다. 다음 10명의 엔지니어는 기본적으로 그 그림을 가지고 있지 않을 것입니다. 우리가 그것을 기록하는 데 진지해지는 정도만큼만 그들은 그것을 가질 수 있을 것입니다.

조직이 항상 기반으로 삼아온 기록되지 않은 기질(substrate)인 컨텍스트는 이제 속도 제한 요소(rate-limiting input)가 되었습니다. 그리고 인간이 하는 자연스러운 행동은 그것을 암묵적(implicit)으로 남겨두는 것입니다. 왜냐하면 명시적인(explicit) 버전을 읽을 사람이 결코 없었기 때문입니다.

진정한 프로그래머들은 자신의 프로그램을 문서화하지 않습니다.

소비하기 쉬운 컨텍스트를 생성하는 것은 정확히 인간이 하기 싫어하는 일입니다.

우리를 구할 수 있는 것은 에이전트가 철저하게 읽는 데 비정상적으로 뛰어나다는 점일지도 모릅니다. 에이전트는 모든 PR 코멘트, 모든 종료된 이슈(closed issue), 모든 커밋 메시지(commit message), 모든 오래된 설계 문서(stale design doc), 모든 Slack 아카이브를 읽고, 아무도 읽지 않을 것이기에 아무도 굳이 기록하지 않았던 패턴들을 추출해낼 것입니다.

우리는 이를 .txt에서 구축하기 시작했습니다. 코드베이스, 이슈(Issues), PR(Pull Requests), 스레드(Threads)를 크롤링하여, 아무도 문서화할 시간이 없었던 암묵적인 결정들, 관습들, 그리고 '우리가 왜 이렇게 했는지'에 대한 지식 베이스(Knowledge base)를 생성하는 에이전트(Agents)들입니다. 단순히 "이 모듈이 존재한다"가 아니라, "이 모듈은 마이그레이션 과정에서 이전 동작을 보존해야 했기 때문에 특이하다"라거나, "이 벤치마크(Benchmark)가 중요한 이유는 이전의 최적화가 분포를 조용히 변경했기 때문이다"와 같은 정보를 제공합니다. 다른 에이전트들은 코드베이스에서 작업을 수행해야 할 때 이 지식 베이스를 사용합니다. 인간이 비공식적으로 수행하는 삼투 현상(Osmosis)이 에이전트가 읽을 수 있고 인간도 읽을 수 있는 무언가로 외부화되는 것입니다.

컨텍스트(Context)를 소비하는 에이전트에게는 컨텍스트를 생성하는 에이전트가 필요합니다. 일단 이 루프(Loop)가 돌아가기 시작하면, 조직은 스스로는 결코 만들어낼 수 없었을 기록된 기질(Substrate)을 갖게 됩니다. 이전 섹션에서 속도를 제한하던 제약 사항은 더 이상 상수가 아니게 됩니다. 컨텍스트는 더 많이 생산할 수 있는 대상이 됩니다.

물론, 이 루프는 언제나 부분적인 그림만을 만들어낼 것입니다. 마이클 폴라니(Michael Polanyi)의 말을 빌리자면, 우리는 우리가 말할 수 있는 것보다 더 많은 것을 알고 있습니다. 어떤 핵심적인 컨텍스트는 정확히 말로 표현되지 않았기 때문에 존재하며, 그것을 글로 적는 것 자체가 그 본질을 변화시키기도 합니다. 인간이 대면하여 축적하는 삼투 층(Osmosis layer)은 기록된 배출물(Written exhaust)로부터 완전히 복구될 수 없습니다. 그 결과물은 완전한 복구라기보다는 유용한 시작점에 더 가깝습니다. 이것이 복리 효과를 일으킬 만큼 충분한지는 제가 여전히 테스트 중인 경험적 질문입니다. 저는 충분하다고 생각합니다. 하지만 확신할 수는 없습니다.

새로운 해자(Moat)는 기술적인 것이 아니라 조직적인 것입니다.

다음 10년을 승리할 기업들이 반드시 최고의 모델이나 최고의 에이전트 인프라를 가진 기업은 아닐 것입니다. 승리하는 기업은 50명, 200명, 그리고 2,000명으로 규모가 커지더라도, 1인당 더 많은 결과물을 내면서 동시에 줄어드는 결정 세트(Set of decisions)에 대해 정렬(Aligned) 상태를 유지할 수 있는 기업일 것입니다. 그들은 에이전트가 등장하기 전부터 자신들의 가장 어려운 문제가 일관성(Coherence)이라는 것을 이미 알고 있었던 기업들일 것입니다.

그것은 문화와 경영의 문제입니다. 언제나 그러했습니다.

IDE, 버전 관리 (Version Control), CI, 마이크로서비스 (Microservices), 또는 DevOps를 포함한 이전의 모든 도구 세대들은 더 나은 도구를 통해 조정 (Coordination) 문제를 해결하겠다고 약속했습니다. 하지만 그들 모두는 이미 존재하던 조직적 일관성 (Organizational Coherence)이 무엇이든 간에 그것을 증폭시키는 승수 (Multiplier) 역할을 할 뿐임이 드러났습니다. 규모가 작은 팀은 일관성을 거저 얻으며, 그곳에서 승수는 일관되게 양(+)의 값을 가집니다. 이것이 가장 목소리 큰 에이전트 (Agent) 찬성론자들이 주로 소규모 팀인 이유이며, 그들이 자신의 맥락에 대해서는 대부분 옳기 때문입니다. 일정 규모를 넘어서면 일관성은 생산되고 유지되어야 하며, 승수는 양방향으로 날카로워집니다. 좋은 조직은 더 좋아졌고, 나쁜 조직은 일을 망치는 속도가 더 빨라졌습니다.

에이전트는 그 어떤 것보다 훨씬 더 큰 승수입니다. 신호는 양방향 모두에서 더 커질 것입니다. 에이전트는 개인이 코드를 더 빨리 작성하게 만드는 수단으로서는 과대평가되어 있고, 조직이 자신들이 알고 있는 것을 외재화 (Externalize)하는 수단으로서는 과소평가되어 있습니다.

에이전트는 마치 자신의 정신의 확장처럼 느껴질 수 있으며, 그 느낌은 매우 짜릿합니다. 더 어려운 과제는 에이전트를 회사 문화의 확장으로 만드는 것입니다. 그것은 다른 문제이며 다른 형태의 작업입니다. 그것은 기록하는 문화 (Writing culture)를 필요로 합니다. 에이전트가 여전히 맥락의 병목 (Context bottleneck)으로 남아 있는 지점을 식별할 수 있을 만큼 사려 깊은 경영진이 필요합니다. 일관성을 유지해야 할 실제 산출물 (Artifact)로 취급하는 사람들이 필요합니다. 새로운 점은 이러한 요소 중 일부를 이제는 구축할 수 있다는 것입니다. '읽고 추출하는 루프 (Read-and-extract loop)'가 그 한 가지 형태이며, 다른 형태들도 나타날 것입니다.

실험 결과에 대해서는 다시 보고하겠습니다.