조율세(Joining Tax): Claude 코드를 다루며 보낸 1년

2026년 1월, Anthropic은 멀티 에이전트 시스템에 대한 회고록을 발표했는데, 이는 제가 지난 1년간 운영해 온 것을 설명하며 그것을 실수라고 규정했습니다. 그들의 표현은 거의 다음과 같았습니다: 팀들은 계획(planning), 실행(execution), 검토(review), 반복(iteration)을 위한 별도의 에이전트를 가진 정교한 멀티 에이전트 시스템을 구축하지만, 각 핸드오프(handoff)에서 컨텍스트 손실(lost context)을 겪고 실행하는 것보다 조정(coordinating)하는 데 더 많은 토큰을 사용한다는 것을 발견합니다. 이는 이전에 멀티 에이전트 설정이 단일 에이전트를 90% 능가했다고 보고한 같은 회사의 게시물과 같아서, 그 회고록은 일종의 철회처럼 읽힙니다. 그리고 2026년 4월의 프리프린트(preprint)는 더 나아가서: 추론 토큰 예산(reasoning-token budget)을 일정하게 유지하면 단일 에이전트가 멀티 에이전트 설정을 일치하거나 능가하며, 보고된 멀티 에이전트 승리는 대부분 아무도 계산하지 않은 추가적인 컴퓨팅이라고 주장합니다.

저에게는 리드(lead), 비즈니스 분석가(business analyst), 아키텍트(architect), 개발자(developer), QA, 상반되는 입장을 가진 두 명의 검토자(reviewers), 그리고 문서 업데이트 담당자가 있습니다. 그들은 2025년 5월부터 저의 실제 제품과 경쟁해 왔기 때문에, 저는 매달 회고록이 설명하는 세금을 지불했습니다. 하지만 저는 그래도 이 시스템을 유지했습니다. 비판은 비용에 대해서는 맞지만, 구조가 무엇을 위한 것인지에 대해서는 틀렸다고 생각합니다.

제가 구축한 것

어떤 작업은 리드에게 전달됩니다. 리드는 비즈니스 분석가와 이야기하고, 두 사람은 비즈니스 측면에서 질문과 논의 항목을 정리하여 계획이 확실해질 때까지 작업합니다. 그런 다음 아키텍트에게 넘어가고, 여기서 기술적인 측면에서도 같은 루프가 다시 실행됩니다. 각 단계에는 제2의 의견을 제시하는 것이 유일한 임무인 검토 동료(review companion)가 있으며, 검토 좌석에 있는 모든 것에 대한 기본 지침은 '항상 의심하고, 결코 믿지 않으며, 항상 사실 확인을 한다'입니다.

그 후 TDD 단계가 진행됩니다. QA 또는 리드가 비즈니스 분석가(BA)와 합의한 유스케이스를 기반으로 '완료 정의(definition of done)'를 테스트 동작으로 작성합니다. 그러면 개발자는 해당 단위 테스트(unit), 통합 테스트(integration), 그리고 엔드투엔드 테스트(end-to-end test)에 맞춰 작업하며, 모든 테스트가 녹색(green)이 될 때까지 진행합니다. 만약 개발자가 이 테스트를 수정해야만 녹색으로 만들 수 있다면 이는 위험 신호(red flag)입니다. 이때 리드가 개입하여 실제 문제가 무엇인지 파악하고, 그 답변에 따라 BA 또는 아키텍트와 상의하게 됩니다.

개발자가 '녹색'임을 확인하면 검토 단계로 넘어가고, 이 과정에서 여러 차례 논의를 거쳐 최종적으로 녹색이 될 때까지 진행됩니다. 한동안 저는 두 명의 리뷰어(reviewer)를 거쳤는데, 한 명은 모든 것을 리팩터링해야 한다고 주장했고 다른 한 명은 단 하나의 라인도 건드리지 말아야 한다고 주장했습니다. 이때 아키텍트가 그 사이에서 판단을 내렸습니다. 그다음에는 저 차례이고, 제 검토 후 테스트를 거칩니다. 제가 피드백이 있으면 리드가 이를 기록하고 개발자에게 되돌려주거나, 사소한 문제라면 리드가 처리하거나, 둘 다 감당하지 못할 경우 제가 직접 처리합니다. 이때 리드의 주요 임무는 이슈 목록(issue list)을 관리하는 것입니다. 여기서 '이슈'란 코드 리뷰에서 발견된 사항이나 버그, 또는 '완료 정의'에 명확히 도달하지 못한 모든 것을 의미합니다.

마지막으로 문서 업데이트 담당자가 리드가 남긴 기록들을 읽고 문서를 강화하며 스크립트를 개선하여 다음 세션이 더 나은 상태에서 시작되도록 합니다. 저는 본류가 되기 전부터 이미 '명세 기반 개발(spec-driven development)'을 진행해 왔는데, 이는 매우 무거운 과정이라 그렇지 않다고 가장하는 것은 가치가 없습니다. 이를 수행하는 런너는 GitHub에 agentweft로 있습니다. 여기서 흐름(flow)은 명세이며, 역할(role)은 마크다운 파일이고, 모든 단계의 출력물은 기록되므로, 실패한 실행이 어디서 중단되었는지 파악하여 재개할 수 있습니다.

비판이 맞는 부분

우선 비용이 많이 듭니다. 이 작업에 2시간을 쓰면 최대 5배 할당량(quota) 전체를 소진하며, 바쁜 날에는 단지 90분 만에 그 정도입니다. 그리고 조정(coordination) 자체가 그 안에 실질적인 항목으로 포함됩니다. 또한 느려서는 안 되는 부분에서 오히려 느립니다. 한때는 이 기능 하나를 위해 34일간의 계획 수립이 필요했고, 그다음은 주로 부실한 부분을 복구하는 데 쓰이는 45일간의 검토(review)가 있었고, 그 후에 테스트가 이어졌습니다. 지난 1년간 규칙과 예시들을 조정하면서 검토 시간이 절반으로 줄었습니다. 이제는 깊이 있는 탐색 및 검증에 12일만 필요할 뿐, 복구해야 할 것이 적기 때문입니다. 계획 수립은 여전히 약 2일 정도 걸리지만, 주로 예시, 일반적인 질문, 그리고 일반적인 접근 방식들이 문서화되어 있기 때문에 제가 그것들을 다시 설명할 필요가 없어 더 빨라졌습니다. 그리고 테스트와 버그 수정에 또 12일이 필요하며, 이 부분은 항상 존재했고 그대로 유지됩니다. 왜냐하면 최종 승인(final sign-off)을 하는 것은 저이기 때문에 그 부분은 위임될 수 없기 때문입니다.

때로는 문서 기록 자체(paper trail)가 문제가 되기도 했습니다. 저는 결정 추적 파일(decision-track files)을 2k, 3k, 5k 라인으로 운영했고, 몇몇은 10k에 달했습니다. 이럴 경우 제가 그것들을 분할하고 반복 처리해야 했습니다. 일부 좋지 않은 기능들은 각각 2k 또는 3k 라인의 파일 수십 개를 남겼고, 그 모든 것은 무엇을 수정해야 하는지에 대한 메모였습니다. 저는 그렇게 하면서도 그것이 잘못되었다는 것을 알고 있었습니다. 도구가 오작동하고 있었고, 저는 더 많이 쓰면서 대응하고 있었습니다. 그 과정은 결국 제가 이 도구를 사람으로 대하는 것이 아니라 도구로 다루도록 가르쳐주었습니다.

그리고 솔직히 말하자면: 이 워크플로우는 상당히 주관적입니다(opinionated). 저는 계획 수립에 많은 시간을 들이고 검토에도 많은 시간을 씁니다. 그리고 이것은 제가 AI 없이 작업하던 방식대로 작동하기 때문에, 무엇보다도 저의 동반자 역할을 합니다. 따라서 제 설정에서 다른 곳으로 전이되는 것은 아마 정확한 구성(configuration)은 아닐 것입니다.

제가 이 방식을 유지한 이유

저는 그 역할들이 두 가지 기계적인 작업을 수행하며, 단일하고 장시간 실행되는 에이전트(agent)로는 둘 중 어느 것도 스스로 할 수 없기 때문에 이 방식을 유지했습니다.

첫 번째는 작업 단위별로 경계가 지정된 컨텍스트(bounded context)를 갖는 것입니다. 에이전트가 코드를 생성하는 동안 세션 내에서 명령어 준수율은 감소하는데, 제가 찾은 하나의 통제 연구에서는 함수당 몇 퍼센트 정도의 확률로 떨어진다고 합니다. 따라서 신선한 컨텍스트를 가진 작은 작업 단위는 표류할 여지가 적습니다. 이것이 대략적으로 역할 경계(role boundary)가 제공하는 이점입니다. 아키텍트는 다른 모든 것이 생각하듯이 생각하지만, 깨끗하게 시작하며 표류하기 전에 끝납니다. 또한 2025년 ACL에서 발표된 동료 검토 논문은 제 경험보다 제가 이것에 대해 좀 더 확신을 갖게 했습니다. 흥미로운 점은 저자들이 자신들의 시스템으로 실행한 테스트인데, 시스템의 한 부분을씩 꺼가며 테스트했습니다. 여기서 얻은 이득은 작업을 분할하는 것에서 온 것이 아니라, 이전 단계를 에이전트로부터 숨기는 것에서 왔습니다.

두 번째는 쓰기 범위(write scope)입니다. 읽기 작업은 계속 개방되어 있으며 저는 그것을 지지합니다. 에이전트가 모든 것을 뒤지고 조사하기를 바랍니다. 하지만 쓰기 작업은 역할별로 분할되는데, agentweft에서는 단계에 선언된 도구 범위(tool scope)이며, QA가 그 이유입니다. 아키텍처 문서와 완료 정의는 자체적인 쓰기 작업에 폐쇄되어 있는데, 이는 개발자가 테스트를 녹색으로 만들 때까지 편집하는 것과 같은 실패이기 때문입니다. 그들은 최단 경로를 찾으려고 했고 요청을 속이려고 했습니다.

단일 에이전트로는 이것을 제공할 수 없습니다. 왜냐하면 스스로 강제할 경계가 없기 때문입니다. 직무 분리(Separation of duties)는 이 모든 것보다 백 년이나 오래되었으며, 같은 이유로 존재합니다. 그래서 제가 다중 에이전트 시스템이 매번 핸드오프(handoff)에서 컨텍스트를 잃고 실행보다는 조정에 더 많은 비용을 지출한다는 것을 읽었을 때, 저는 동의하지 않습니다. 이 핸드오프는 설계상의 버그가 아니라 경계의 대가이며, 그 경계가 바로 그러한 역할들이 존재하는 전체 이유입니다.

세금(The tax), 그리고 그것을 납부하는 방법

전문가들 사이에 작업을 분할하는 것은 새로운 문제가 아닙니다. 프론트엔드와 백엔드가 팀 내에서 별도로 존재할 때 각 측면의 소유권이 더 명확해지지만, 그 대가를 '결합세(joining tax)'로 지불하게 됩니다. 이 결합세는 매우 현실적이어서 저는 수년간 팀에서 이를 피하려고 노력했습니다. 에이전트를 역할별로 분리하면 같은 이유로 동일한 세금이 발생합니다. 즉, 원래의 컨텍스트 축소 문제(context-narrowing problem)는 해결되지만, 비용은 다른 곳으로 이동하고 최종 목표에 도달하는 거리는 그리 가깝지 않습니다. 따라서 작업은 '접합부(seam)'를 저렴하게 만드는 데 있으며, 다섯 가지 요소가 이 작업을 대부분 수행해 주었습니다.

첫 번째는 논쟁을 제한하는 것이었습니다. 각 검토자에게는 2차례의 피드백 라운드가 주어지는데, 원래 리뷰와 명확화(clarification)를 포함하며, 아키텍트는 정말로 더 많은 논증이 필요할 경우 최대 3사이클까지 연장할 수 있습니다. 개발자는 제가 개입하기 전에 2~3번의 반복 기회를 얻으며, 최대 상한선은 5회입니다. 제한이 없다면 검토자들은 토큰이 남아있는 한 계속 논쟁을 벌일 것이고, 이것이 agentweft가 플로우 스펙(flow spec)에 그들을 포함하는 이유입니다. 즉, 검토자는 기껏해야 두 번 작업물을 되돌려 보내야 하고, 그다음에는 돌아온 것을 살펴봐야 합니다.

두 번째는 모든 역할에 우선순위 순서를 부여한 것입니다. 단순히 무엇을 하는지뿐만 아니라, 무엇을 우선시해야 하는지, 스스로 결정할 수 있는 영역은 어디인지, 그리고 어떤 순서로 해야 하는지를 명시한 것입니다. 제가 예전에 손으로 처리하던 중재(arbitration) 작업 대부분은 저의 머릿속에 아무도 사본이 없는 우선순위 목록을 가지고 있었고, 이를 역할별로 문서화하는 것이 많은 파이프라인이 저 없이 돌아가게 했습니다.

세 번째는 인계(handoff)를 구조화한 것입니다. 그 결과물과 판결(verdict)이 경계를 넘어가야 하며, 다음 역할이 다시 읽고 해석해야 하는 붙여넣기 텍스트의 벽이 되어서는 안 됩니다. 그리고 네 번째는 이슈 목록에 대한 단일 소유자를 유지하는 것이었습니다. 기능 하나를 검토하는 과정에서 10번의 리뷰 반복과 쉽게 100개의 발견 사항(finding)을 갖는 것은 저에게는 상당히 정상적인 일입니다. 만약 어떤 역할도 그 목록을 소유하지 않으면, 소유되지 않은 이슈 목록이 결국 1만 줄짜리 결정 추적 기록(decision track)으로 변질되기 때문입니다.

다섯 번째는 마지막에 루프를 닫는 것이었습니다. doc updater가 존재하기 때문에 이번 실행에서 얻은 교훈들이 다음 실행이 시작되기 전에 문서와 스크립트로 변환됩니다. 이것이 규칙 코퍼스가 시간이 지나면서 증가하는 대신 줄어든 유일한 이유입니다. 현재 크기는 예전의 약 5분의 1 정도입니다. 문제점들은 시간이 지남에 따라 반복적이 되었고, 반복적인 문제는 하나의 스크립트가 맡을 수 있는 종류입니다. agentweft에서는 이것들이 게이트(gate) 역할을 하는데, 정규 표현식(regex)이나 명령어로, 통과하거나 통과하지 않는 것만 결정합니다. 그리고 흐름은 작업하는 역할과 그 역할을 확인하는 게이트에 동일한 약속들을 전달합니다.

하나의 에이전트가 승리할 때

어떤 파일들이 변경될지, 그리고 어떻게 변경될지 이미 알고 있다면, 이 전체 장치(apparatus)는 마이너스 가치를 가집니다. 단일 작업을 수행하는 단일 에이전트가 모든 주고받음 없이 더 잘 처리합니다. 전환점은 하나의 작업이 한 개의 헤드에 담기지 못할 때쯤입니다. 만약 단일 에이전트가 무언가를 끝내기 위해 자신의 컨텍스트를 압축하고 요약하며 20번 또는 50번을 반복해야 한다면, 그것은 시작했던 내용을 조용히 잊은 채 끝에 도달합니다. 그 지점에서는 '조율세(joining tax)'를 내는 것이 에이전트가 잊어버리는 것에 대한 비용을 지불하는 것보다 저렴해집니다. 그리고 범위가 클수록 이 거래는 더 좋아지는데, 이는 조정 오버헤드(coordination overhead)에서 추측할 수 있는 내용과는 다소 반대되는 것입니다.

만약 제가 오늘 이것을 재구축한다면, 쓰기 파티셔닝(write partitioning), 완료의 정의로서의 테스트, 캡(caps), 그리고 doc-updater 루프는 유지할 것입니다. 하지만 몇 개의 역할이 존재해야 하는지에 대해서는 더 깊이 생각할 것 같습니다. 왜냐하면 제가 가진 일부 역할들은 인간 팀이 조직된 방식과의 대칭성 때문에 존재하는 것이고, 인간 팀과의 대칭성은 기술적인 주장이 아니기 때문입니다. 이 비판은 저 자신에게 돌아옵니다.

저는 여전히 이것에서 나오는 모든 줄을 읽고, 계속 그렇게 할 것으로 기대합니다. 하지만 제가 1년 동안, 그리고 저보다 더 나은 데이터를 가진 사람들에게서도 이 구조를 변호할 이유는, 대안이 더 저렴한 시스템이 아니기 때문입니다. 그것은 같은 비용이며, 제가 볼 수 없는 어딘가에 자리 잡고 있습니다.