멀티 에이전트 파이프라인 포스트모템: 서브에이전트 오케스트레이션이 망가지는 5가지 방식 (2026)

들어가며 #

멀티 에이전트 오케스트레이션은 Claude Code에서 가장 강력하면서도 가장 은밀하게 위험한 패턴이다. 잘 작동하면 코드베이스를 병렬로 훑고, 독립적 검토를 받고, 컨텍스트 윈도우 하나로는 결코 담을 수 없는 문제를 해결할 수 있다. 실패할 때는 조용히 실패한다: 파이프라인은 성공을 보고하고, 당신은 배포하고, 잡았어야 할 버그는 이미 프로덕션에 들어가 있다.

이 글은 프로덕션에서 에이전트 파이프라인을 돌리며 실제로 맞닥뜨린 다섯 가지 실패 유형에 대한 포스트모템이다. 각각에는 당신이 보게 될 증상, 그 아래에 깔린 근본 원인, 그리고 해결책이 함께 담겼다. 서브에이전트 패턴과 커스텀 에이전트 작성을 읽었고 이제 실제 오케스트레이션을 돌리고 있다면, 이 글이 당신을 도랑에 빠지지 않게 지켜줄 것이다.

실패 1: 신뢰의 함정 #

증상. 오케스트레이터가 “인증 모듈 리팩터링 완료, 모든 테스트 통과"라고 보고한다. 당신은 배포한다. “통과한 테스트"가 한 번도 다룬 적 없는 경로에서 런타임이 즉시 깨진다.

근본 원인. 서브에이전트는 요약을 반환한다 — 자기가 무엇을 하려 했는지에 대한 설명일 뿐, 실제로 무엇을 했는지에 대한 검증된 기록이 아니다. “모든 테스트 통과"는 실제로 테스트를 돌렸다는 뜻일 수도, 통과할 거라고 믿는다는 뜻일 수도 있다. 오케스트레이터는 산문을 실제 근거로 취급한 것이다.

해결책. 요약이 아니라 산출물에 대조해 검증하라. 서브에이전트가 변경을 주장한 뒤 오케스트레이터는 실제 git diff를 읽고, 테스트 명령의 종료 코드를 확인하거나, 파일을 다시 읽는다. 우리는 이걸 호되게 배웠다 — 그래서 번역 서브에이전트로 4개 언어 글을 작성했을 때, 에이전트의 “YAML 유효: 예"를 믿는 대신 실제 근거로 npm run build를 돌렸다. 요약은 주장이다. 빌드는 증거다.

실패 2: 컨텍스트 누출 #

증상. 두 서브에이전트가 병렬로 돈다. 한쪽의 수정이 사라지거나, 파일이 양쪽에서 온 반쯤 병합된 뒤죽박죽으로 끝난다.

근본 원인. 두 에이전트가 같은 파일에 썼거나, 각자 다른 쪽이 몰래 바꿔버린 작업 트리 상태를 가정했다. 하나의 작업 트리를 공유하는 병렬 작성자는 단계만 더 붙은 경쟁 상태일 뿐이다.

해결책. 겹치지 않는 범위와 워크트리 격리. 에이전트 A를 /auth/로, 에이전트 B를 /payments/로 겹침 없이 범위를 정하라. 에이전트가 사소하지 않은 수정을 할 때는 각자에게 자기 git 워크트리를 줘서 독립된 체크아웃에서 작업하게 하고 나중에 의도적으로 병합하라. 두 작성자가 하나의 트리를 공유하게 절대 두지 마라.

실패 3: 폭주하는 팬아웃 #

증상. 몇천 토큰이면 끝났어야 할 실행이 그 10배가 든다. 아니면 파이프라인이 영영 끝나지 않는다 — 계속 에이전트를 띄운다.

근본 원인. 수렴 조건 없는 루프 안에서 에이전트를 생성하거나, 작업량이 정당화하는 것보다 훨씬 많은 작업자를 팬아웃한 것이다. 모든 서브에이전트는 컨텍스트 하나치의 토큰이다; 반사적 팬아웃은 비용을 빠르게 곱한다.

해결책. 예산과 정지 조건. 단계별 에이전트 수에 상한을 둬라. 탐색 루프(“모든 버그를 찾아라”)에는 끝없는 “계속 진행” 대신 “새로운 것이 없는 라운드가 K번 연속되면 정지"를 쓰라. 의도적으로 고른 숫자로 팬아웃하라. 비용을 지켜보고 있다면 이 점이 두 배로 중요하다 — 파이프라인을 스케일하기 전에 토큰 계산이 실제로 어떻게 돌아가는지 보라.

실패 4: 조용한 절단 #

증상. 파이프라인이 “보안 감사 완료 — 문제 없음"이라고 보고한다. 일주일 뒤 그 감사가 다뤘다는 코드에서 뻔한 인젝션 버그가 드러난다.

근본 원인. 탐색 에이전트가 결과를 상위 N개로 잘랐거나, 전체 표면을 훑는 대신 표본만 봤는데 — 아무도 무언가 누락됐다는 것을 로그에 남기지 않았다. 오케스트레이터는 60% 커버리지를 100%로 제시한 것이다.

해결책. 절단을 시끄럽게 만들어라. 에이전트가 자기 커버리지를 제한했다면 — 상위 N개, 표본 추출, 시간 상한 — 보고에 반드시 명시적으로 밝혀야 한다: “엔드포인트 30개 중 18개 검사; 12개 미확인.” 오케스트레이터는 그 공백을 삼키는 대신 드러낸다. 완료인 양 제시된 부분 결과는 솔직한 “나는 못 끝냈다"보다 나쁘다.

실패 5: 방치된 워크트리 #

증상. 낡은 git 워크트리가 쌓인다. 더 나쁘게는, 나중의 에이전트가 절반만 끝난 워크트리를 정본 메인 트리인 양 읽고 허구 위에 작업을 쌓는다.

근본 원인. 격리를 위해 만든 워크트리를 범위가 정해진 자원으로 다루지 않은 것이다. 완료 시 정리도 없고, 어느 트리가 정본인지에 대한 명확한 소유권도 없다.

해결책. 모든 워크트리를 라이프사이클이 있는 자원으로 다뤄라. 에이전트가 변경을 하지 않으면 자동 정리하라. 변경이 있으면 명시적으로 검토 후 병합하거나 폐기하라 — 매달린 채로 두지 마라. 그리고 하류 에이전트가 다른 에이전트의 워크트리를 실제 근거인 양 절대 읽지 못하게 하라; 정본 상태는 메인 트리다, 끝. (우리는 파이프라인 도중에 방치된 워크트리를 직접 정리한 적이 있다 — 5초짜리 git worktree remove가 “이 파일이 왜 틀렸지"로 보낼 한 시간을 아껴준다.)

원칙 #

이 모든 실패는 하나의 뿌리를 공유한다: 에이전트의 주장을 검증된 현실인 양 취급하는 것. 확인되지 않은 요약, 격리되지 않은 범위, 한계가 정해지지 않은 루프, 로그되지 않은 절단, 소유되지 않은 워크트리. 멀티 에이전트 오케스트레이션은 에이전트가 멍청해서 실패하는 게 아니다 — 오케스트레이터가 검증 없이 신뢰해서 실패한다. 모든 이음매에 검증과 명시적 한계를 내장하라, 그러면 파이프라인은 강력한 만큼 신뢰할 만해진다.

프로덕션 준비된 Claude Code 세팅 #

신뢰할 만한 파이프라인은 자기 스스로 실패를 더하지 않을 인프라를 원한다:

1. 긴 파이프라인과 CI 게이트를 위한 안정된 호스트. 오케스트레이션 도중 끊긴 SSH 세션은 그 자체로 하나의 실패 유형이다. HTStack — 홍콩 VPS, 저지연 중국 본토 접근, 안정적 BGP. dibi8.com을 호스팅하는 바로 그 IDC로, 우리가 이 파이프라인들을 돌리는 곳이다. 월 $5-12.

2. 병렬 팬아웃을 위한 클라우드 여유 공간. (의도적으로, 예산을 두고) 작업자를 팬아웃할 때 여유 CPU가 경합을 막아준다. DigitalOcean — 60일간 $200 무료 크레딧, 14개 이상 리전.

3. 스킬 번들. 이 다섯 가지 실패를 피하는 것은 대부분 프롬프트 규율의 문제다 — 검증 단계, 정지 조건, 범위가 정해진 자원. 우리는 검증을 거친 다섯 개의 스킬을 Gumroad에서 $19 번들로 패키징했다 — 모서리에 떠 있는 CTA를 보라 — 검증 이음매가 이미 내장된 오케스트레이터 프롬프트를 포함한다.

함께 읽기 #

• 서브에이전트 패턴 — 이 실패들이 숨어 있는 다섯 가지 워크플로.
• 커스텀 에이전트 작성 — 출력 계약으로 신뢰할 만한 작업자 만들기.
• 서브에이전트 vs MCP vs 스킬 — 과하게 만들지 않도록 올바른 확장 고르기.
• AI 코딩 에이전트 월 청구서 — 폭주하는 팬아웃 뒤의 토큰 계산.

결론 #

멀티 에이전트 오케스트레이션은 작업이 진짜로 컨텍스트 윈도우 하나를 넘어서거나 독립적 검증이 필요할 때 그만한 가치가 있다 — 하지만 반사적으로가 아니라 의도적으로 손을 뻗어라. 잘 프롬프트된 단일 에이전트는 버그투성이 5-에이전트 파이프라인을 매번 이긴다. 오케스트레이션을 할 때, 강력함과 재앙을 가르는 차이는 하나의 습관이다: 모든 주장을 실제 근거에 대조해 검증하고, 모든 루프에 한계를 둬라. 검증할 수 없는 복잡성은 검증할 수 있는 단순함보다 나쁘다.