35개 에이전트가 같은 코드베이스를 건드리는데 서로 충돌하지 않는다면, 그건 에이전트들이 똑똑해서가 아니다. 규칙이 먼저 잠겨 있어서다.
dev.to의 baodev-studio가 공개한 Claude Code 35개 에이전트 오케스트레이션 실전기는 멀티 에이전트 시스템의 핵심 난제를 정확히 짚는다. quality-gate 에이전트가 PR을 312단어짜리 리뷰로 거절한다. backend-developer 에이전트가 수정해서 재제출한다. quality-gate가 같은 312단어로 다시 거절한다. 루프다. 두 에이전트 모두 틀리지 않았다. 각자 자신이 받은 스펙을 충실히 따랐을 뿐이다. 문제는 '테스트 커버리지 최솟값'에 대한 단일 정답이 존재하지 않았다는 것이다.
이 루프를 끊은 방법은 의외로 단순했다. CLAUDE.md에 한 줄 쓰는 것이었다. "신규 코드 statement coverage 85% 이상, DB 접근 경로는 unit test보다 integration test 우선." 규칙이 문서화된 순간, 충돌은 사라졌다. 에이전트들이 더 나빠진 게 아니다. 의사결정의 근거가 단일화된 것이다.
이것이 멀티 에이전트 오케스트레이션의 본질이다. 에이전트 간 협상 프로토콜이나 투표 메커니즘이 아니라, 누가 무엇을 결정하는지 사전에 명시하는 구조다. baodev-studio는 이를 세 가지 작동하는 패턴으로 정리한다. 관심사별 단일 진실 소스(Single Source of Truth), 작업 클래스별 명시적 소유권, 그리고 에이전트 호출 시 컨텍스트 잠금이다.
특히 Router Pattern은 주목할 만하다. Postgres 성능 문제를 backend-developer에게 보내면 애플리케이션 캐싱 솔루션이 나온다. postgres-pro에게 보내면 인덱스 재작성이 나온다. 둘 다 맞다. 둘 다 맞기 때문에 문제다. flow-architect라는 라우터 에이전트가 먼저 트레이스를 읽고 '이건 앱 레이어 문제인가, DB 레이어 문제인가'를 판단한 뒤 적절한 전문가에게 비중복 범위를 넘긴다. 전문가들은 겹치지 않는 일을 받기 때문에 싸울 이유가 없다.
반면 작동하지 않는 패턴들은 인상적이다. 에이전트들끼리 협상하게 놔두면, 논리가 더 나아서가 아니라 컨텍스트 윈도우가 소진되어 한 쪽이 항복한다. 병렬 실행 후 최선 결과를 선택하는 방식은 토큰 비용이 3배인데 품질 차이는 노이즈 수준이다. 같은 스펙을 읽은 같은 에이전트는 수렴하지 발산하지 않기 때문이다.
Spec-Driven Development(SDD)와의 연결이 여기서 중요해진다. dev.to의 Robert Douglass가 정리한 SDD 접근법은 '스펙은 단순한 프롬프트가 아니라 합의의 지점'이라는 명제를 중심으로 전개된다. What(무엇을 만드는가)과 How(어떻게 바꾸는가)를 구분하고, 구현 전에 의도를 명시적으로 문서화하는 것이 팀 소프트웨어 개발의 전제 조건이라는 주장이다.
멀티 에이전트 맥락에서 이 주장은 더욱 날카로워진다. 에이전트는 주어진 질문을 탁월하게 실행한다. 질문을 교정하지 않는다. 의도가 모호하면 출력이 모호하다. 스펙이 없으면 에이전트마다 해석이 다르고, 해석이 다른 에이전트들은 필연적으로 충돌한다. baodev-studio의 루프 사례가 정확히 이 경우다. 스펙의 빈 구멍이 에이전트 충돌로 나타난 것이다.
여기에 세 번째 시각이 더해진다. AI는 약점을 숨기지 않는다, 증폭시킨다. dev.to의 Whetlan이 쓴 이 통찰은 멀티 에이전트 구조 설계에 직격으로 적용된다. 스펙이 불분명하면 에이전트는 자신 있게 한 가지 해석을 골라 깔끔하게 구현한다. 백테스트 엔진에서 short_signal = False를 하드코딩한 채 에러 없이 돌아간 사례처럼, 문제는 런타임이 아니라 의도 수준에서 조용히 발생한다. AI가 생성한 테스트로 검증하면 버그가 스펙이 된다.
멀티 에이전트 환경에서 이 리스크는 선형으로 늘지 않는다. baodev-studio가 경험한 것처럼 에이전트 수가 10개를 넘는 순간 플랫 디스패처는 한계를 드러내고, 라우터 에이전트 임계값이 작동하기 전까지의 구간이 가장 고통스럽다. 8개에서 22개로 점프했을 때가 22개에서 35개로 늘렸을 때보다 훨씬 힘들었던 이유가 여기 있다. 라우팅 인프라가 갖춰지기 전의 에이전트 증가는 불명확한 스펙을 가진 전문가를 무작위로 늘리는 것과 같다.
세 기사를 조합하면 하나의 설계 원칙이 나온다. 멀티 에이전트 워크플로우의 품질은 에이전트의 성능이 아니라 스펙의 명확성과 결정 구조의 선명도로 결정된다.
실무적 시사점은 세 가지다.
첫째, 두 개 이상의 에이전트가 건드리는 모든 관심사는 단일 파일로 소유권을 선언해야 한다. CLAUDE.md가 build convention을 소유하고, secure-code-patterns.md가 보안 룰셋을 소유하는 방식이다. 에이전트가 다를 수 없는 유일한 이유는 같은 파일을 읽기 때문이다.
둘째, 구현 전에 스펙을 잠가라. SDD에서 말하는 What과 How의 분리는 멀티 에이전트 컨텍스트에서 에이전트 간 충돌을 사전에 차단하는 계약서다. 스펙이 구현 중에 움직이면, Redis에 컨텍스트를 캐싱해도 바닥이 흔들린다.
셋째, AI가 자신 있게 생성한 결과물을 스펙 기준으로 검증하는 레이어를 분리해야 한다. 에이전트가 쓴 테스트로 에이전트가 쓴 코드를 검증하면 공증일 뿐이다. 품질 게이트는 에이전트의 해석이 아니라 원본 스펙을 기준으로 판단해야 한다.
해결되지 않은 문제도 솔직하게 봐야 한다. baodev-studio가 아직 풀지 못한 것은 에이전트 간 리그레션이다. 2주 후 새로 호출된 backend-developer 인스턴스가 이전 인스턴스가 추가한 load-bearing workaround를 dead code로 판단해 삭제한다. git blame을 읽지 않는 에이전트는 맥락 없이 현재 파일만 본다. 구조화된 커밋 메시지와 workaround를 검증하는 테스트로 부분 완화했지만, 근본 해결은 아직이다.
이 문제는 스펙 선행으로도 커버되지 않는 영역이다. 시간 축 위에서 에이전트의 결정이 축적되는 방식, 즉 에이전트의 '기억' 문제다. 멀티 에이전트 워크플로우를 진지하게 운용하는 팀이라면 컨텍스트 지속성 설계를 별도 레이어로 다뤄야 한다는 신호다.
전망은 구조에 투자한 팀이 가져간다. AI 에이전트의 성능은 빠르게 올라가고 있다. 하지만 에이전트가 똑똑해질수록, 모호한 스펙이 만드는 충돌도 더 자신 있게, 더 깔끔하게 나타난다. 약점이 숨겨지는 것이 아니라 증폭된다는 통찰은 단일 에이전트에도 맞지만 멀티 에이전트에서는 제곱으로 작동한다.
내일 당장 써먹을 수 있는 출발점은 하나다. 지금 팀의 에이전트 워크플로우에서 두 개 이상의 에이전트가 의견을 달리할 수 있는 관심사를 목록으로 뽑아라. 그리고 그 각각에 대해 '단일 진실 소스 파일'이 존재하는지 확인하라. 없다면, 에이전트를 더 늘리기 전에 그 파일부터 만드는 것이 우선이다.