지난 금요일 오후, quality-gate (품질 게이트) 에이전트가 backend-developer (백엔드 개발자)의 PR (Pull Request)을 검토하고 312단어 분량의 비판과 함께 거절했습니다. 정당한 피드백이었습니다. PR은 반려되었고, backend-developer는 세 개의 함수를 다시 작성하여 재제출했습니다. quality-gate는 다시 거절했습니다. 똑같은 312단어의 비판이었습니다. 똑같은 세 개의 함수였습니다. 저는 이 과정을 지켜보며 backend-developer가 이전 단계에서 quality-gate로부터 "테스트 커버리지 (test coverage)를 개선하라"는 지시를 받았고, 테스트를 작성했다는 사실을 깨달았습니다. 그런데 quality-gate의 두 번째 검토에서는, 해당 테스트가 backend-developer가 이전에 건너뛰라고 지시받았던 내용과 중복된다는 이유로 불평하고 있었습니다. 에이전트들이 루프 (loop)에 빠진 것입니다. 어느 쪽도 틀리지 않았습니다. 둘 다 자신들에게 주어진 명세 (spec)에 따라 작동하고 있었습니다. 이것이 바로 규칙 없이 35개의 전문화된 에이전트가 동일한 코드베이스 (codebase)에서 작동하게 했을 때 발생하는 현상입니다. 그들은 인간과 싸우지 않습니다. 그들은 서로 싸웁니다.

오케스트레이션 (orchestration) 문제
저는 35개의 에이전트를 ~/.claude/agents/ 폴더에 보관합니다. 여기에는 backend-developer, frontend-developer, postgres-pro, golang-pro, quality-gate, flow-architect, security-engineer, test-automator, client-communicator, cfo, cto, ceo, inbox-monitor 및 기타 22개가 포함됩니다. 대부분의 호출 (invocation)은 2개에서 4개의 에이전트가 체인 (chain) 형태로 연결되어 이루어집니다. 약 7번의 세션 중 1번꼴로 위와 같은 실제 충돌이 발생합니다. 문제는 어떤 에이전트가 틀렸다는 것이 아닙니다. 문제는 무엇을 결정할지 제약하지 않는다면, 35개의 명세를 가진 35명의 전문가가 코드베이스를 35개의 방향으로 끌어당길 것이라는 점입니다. 이 글은 대부분 효과가 있었던 세 가지 패턴, 효과가 없었던 세 가지 패턴, 그리고 제가 아직 해결하지 못한 한 가지 문제에 대한 기록입니다.

효과가 있었던 세 가지 패턴

1. 관심사별로 작성된 단일 진실 공급원 (Single source of truth)
   둘 이상의 에이전트가 관여하는 모든 관심사에 대해, 정답을 소유하는 파일은 정확히 하나만 존재합니다.
   프로젝트 루트 (root)에 있는 CLAUDE.md는 다음을 소유합니다: 빌드 명령 (build commands), 배포 폴더 컨벤션 (deploy folder convention), 테스트 프레임워크 (test framework). 모든 에이전트는 이를 읽습니다. 그들 중 누구도 이에 반박하지 않습니다.
   masterings/secure-code-patterns.md는 입력 검증 (input validation), 비밀 정보 처리 (secrets handling), SQL 안전성 (SQL safety)에 관한 40가지 규칙을 소유합니다.

security-engineer와 quality-gate는 모두 동일한 파일을 참조합니다. 이들은 동일한 체크리스트를 읽기 때문에 패턴에 대해 의견이 일치하지 않을 수 없습니다. FreelanceOS/baseline-form.md는 모든 양식이 통과해야 하는 22개의 테스트 케이스를 소유합니다. frontend-developer가 이를 구현하고, quality-gate가 이를 검증합니다. 이 22개의 목록이 곧 계약(contract)입니다. 위에서 설명한 원래의 무한 루프는 "백엔드 코드의 최소 테스트 커버리지는 무엇인가"에 대한 단일 진실 공급원(source of truth)이 없었기 때문에 발생했습니다. quality-gate는 나름의 의견이 있었고, backend-developer도 나름의 의견이 있었습니다. 제가 CLAUDE.md에 규칙("새 코드에 대한 문장 커버리지(statement coverage) 최소 85%, DB를 건드리는 경로에 대해서는 유닛 테스트(unit tests)보다 통합 테스트(integration tests) 우선")을 작성하자, 다음 세션부터 루프가 멈췄습니다.

2. 명시적 소유권: 작업 클래스당 하나의 에이전트
   만약 두 명의 에이전트가 어떤 작업을 소유할 가능성이 있다면, 결과적으로 아무도 그 작업을 소유하지 않게 됩니다. 저는 그 작업을 한 단계 상위 계층에 있는 제3의 에이전트에게 할당합니다. 구체적인 예로, Postgres 성능은 누가 소유할까요? backend-developer가 소유할 수도 있습니다(SQL이 API 코드의 일부이므로). 혹은 postgres-pro가 소유할 수도 있습니다(데이터베이스 관련 문제이므로). 만약 제가 느린 쿼리 조사를 backend-developer에게 지시하면, 애플리케이션 계층의 캐싱(application-layer caching)을 포함한 답변이 돌아옵니다. 만약 postgres-pro에게 지시하면, 인덱스 재작성(index rewrite)을 포함한 답변이 돌아옵니다. 둘 다 맞습니다. 하지만 둘 다 적절한 수준은 아닙니다. 해결책은 질문을 flow-architect에게 먼저 전달하는 것입니다. flow-architect는 트레이스(trace)를 읽고, 이것이 앱 계층의 수정 사항인지 데이터베이스 계층의 수정 사항인지를 결정한 다음, 명확한 범위(scope)와 함께 적절한 전문가에게 구체적인 작업을 할당합니다. 전문가들은 서로 겹치지 않는 작업을 받기 때문에 절대 싸우지 않습니다. 이것은 조정 패턴(coordination pattern)이 아니라 라우터 패턴(router pattern)입니다. 라우터 자체가 하나의 에이전트입니다.

에이전트 호출당 컨텍스트 잠금 (Locked context per agent invocation)

코드베이스에 내용을 작성할 에이전트를 디스패치(dispatching)하기 전에, 저는 명시적인 키를 사용하여 관련 컨텍스트를 Redis에 캐싱합니다:

redis-cli SET "agent:ctx:backend-developer:2026-05-20-feature-x" "$( cat current-task.md schema.sql relevant-files.txt )" EX 3600

에이전트는 실행 시작 시 해당 키로부터 데이터를 읽습니다. 만약 병렬 에이전트 디스패치가 발생하더라도, 그들은 동일하게 고정된(frozen) 컨텍스트를 보게 됩니다. 과거에 에이전트들이 서로 충돌했던 이유는 그들이 걷고 있는 바닥이 움직였기 때문입니다. 충돌을 막아주는 것은 바닥이 움직이지 않는 것입니다.

이 패턴은 2026년 4월에 발생한 사고에서 비롯되었습니다. 당시 quality-gate가 refactor-agent와 동시에 실행되었는데, refactor-agent가 리팩토링 중이던 파일을 quality-gate가 리팩토링 중간에 검토하게 되었습니다. quality-gate는 미완성된 코드를 결함이 있는 것으로 플래그(flag)했습니다. 실제로 결함이 있는 상태였습니다. 컨텍스트 잠금(locked-context)이 강제된 이후, 이러한 종류의 버그는 사라졌습니다.

작동하지 않는 세 가지 패턴

1. "에이전트들이 협상하게 두기 (Let the agents negotiate)"
   이 방식을 2주 동안 시도해 보았습니다. backend-developer가 제안하고, quality-gate가 검토하며, 합의에 도달할 때까지 서로 의견을 주고받습니다. 이론적으로는 깔끔합니다. 하지만 실제로는 에이전트들이 협상하지 않습니다. 그들은 원래의 입장을 더 정중하게 재진술할 뿐입니다. 서너 번의 턴(turn)이 지나면, 논리가 더 우수해서가 아니라 컨텍스트 윈도우(context window)가 바닥나기 때문에 둘 중 하나가 굴복합니다. "지친 에이전트가 굴복하는 것"에서 나오는 결정의 품질은 "라우터 에이전트가 사전에 결정하는 것"의 결정 품질보다 낮습니다. 협상은 손해를 보는 비싼 방법입니다.

2. "여러 에이전트를 병렬로 실행하고 최선의 결과물을 선택하기 (Run multiple agents in parallel and pick the best output)"
   이 방식이 더 안전해 보입니다. backend-developer-A, backend-developer-B, backend-developer-C를 병렬로 실행하고, quality-gate 점수가 가장 높은 버전을 선택하는 것입니다. 여기에는 세 가지 문제가 있습니다. 첫째, 토큰 비용이 3배로 듭니다. 둘째, 품질이 제한되지 않습니다(unbounded). 세 번의 실행이 대부분 동일한 편향(bias)을 공유하기 때문입니다(동일한 에이전트가 동일한 명세(spec)를 읽고 있으므로, 답변이 발산하기보다는 유사한 답변으로 수렴하는 경향이 있습니다). 셋째, 선택기(picker)가 단일 장애점(single point of failure)이 됩니다.

만약 품질 게이트(quality-gate)에 사각지대가 있다면, 세 명의 "승자" 모두가 그 사각지대를 공유하게 됩니다. 저는 작업당 한 명의 전문가를 유지합니다. 이것이 더 저렴합니다. 제가 진행하는 프로젝트들에서 병렬 실행 후 선택(parallel-and-pick) 방식과 비교했을 때 출력 품질의 차이는 오차 범위 내에 있었습니다. 3. "에이전트 투표 (Agent voting)": 병렬 실행 후 선택 방식과 동일한 문제가 발생하며, 추가적인 조정 비용(coordination cost)이 발생합니다. 일주일 만에 이 방식은 제외했습니다.

제가 틀렸던 점: 저는 에이전트 수가 증가함에 따라 조정 오버헤드(coordination overhead)가 선형적으로 증가할 것이라고 가정했습니다. 에이전트가 많아지면 = 작성해야 할 규칙이 많아지고 = 중재해야 할 충돌이 많아진다는 논리였습니다. 하지만 실제 곡선에는 굴곡(kink)이 있습니다. 약 10개의 에이전트까지는 평면적인 디스패처(flat dispatcher)가 작동합니다. 디스패치 로직을 머릿속에 담아두고 직관에 따라 업무를 할당할 수 있습니다. 하지만 12개의 에이전트를 넘어가면 더 이상 명단을 작업 기억(working memory)에 유지할 수 없으며, 이때부터는 평면적인 디스패처가 라우팅 에이전트(routing agent)에게 밀리게 됩니다. 따라서 조정 오버헤드는 에이전트 수에 따라 선형적으로 상승하지 않습니다. 1개에서 10개까지는 거의 평탄하다가, 라우팅 에이전트 임계값에서 단계적으로 상승한 뒤, 12개부터는 다시 상한선에 도달할 때까지 거의 평탄하게 유지됩니다. 저는 8개에서 22개로, 그리고 35개의 에이전트로 세 번의 [단계에 걸쳐 도약했습니다]

그것이 목록에 있습니다. 나타난 형태는, 겉보기에는 35개의 독립적인 에이전트처럼 보이지만 실제로는 계층화된 시스템입니다. 1개의 라우터 (router, flow-architect)가 작업의 종류를 결정합니다. 계층당 57개의 전문가 (specialists; 백엔드 (backend), 프론트엔드 (frontend), DB, 보안 (security), 데브옵스 (devops), 테스트 (testing))가 범위가 지정된 작업을 수행합니다. 1개의 검토자 (reviewer, quality-gate)가 합의된 체크리스트를 기준으로 검증합니다. 세 명의 직교하는 C-레벨 (C-levels; cto, cfo, ceo)은 엔지니어링 루프 (engineering loop)를 방해해서는 안 되는 횡단적 (cross-cutting) 전략 질문들을 처리합니다. 나머지 1820개는 드물게 파견되는 도메인 에이전트 (domain agents)입니다 (예: 어려운 DB 문제에만 투입되는 postgres-pro, 인증서 문제가 발생할 때만 투입되는 tls-config-agent). 충돌을 방지하는 패턴은 "더 많은 규칙"이 아닙니다. 그것은 "더 적은 중복 책임, 명시적인 라우터, 파견당 하나의 고정된 컨텍스트 (frozen context)"입니다. 기록된 세 가지입니다. 그렇지 않았다면 일주일 동안 디버깅(debugging)에 소비했을 대부분의 충돌이 발생하지 않습니다. 만약 오늘 에이전트 스택 (agent stack)을 시작한다면, 제가 권장하는 구축 순서는 다음과 같습니다: 먼저 CLAUDE.md를 작성하고, 그다음 5개의 전문가를 만든 뒤, 그다음 하나의 라우터를 추가하고, 마지막으로 나머지를 추가하는 것입니다. 라우터와 기록된 진실의 원천 (source of truth) 없이 35명의 전문가를 조정하려고 시도하는 것은, 똑같은 교훈을 얻기 위해 느리게 돌아가는 방식입니다.