35일의 클로드 코드: 3개의 병렬 에이전트가 진정한 한계인 이유

35일 동안 1,800회 이상의 Claude Code 턴을 사용한 후, r/ClaudeAI의 한 개발자는 병렬 에이전트 작업이 약 3개의 동시 스레드에서 단단한 한계에 부딪히는 이유를 발견했습니다. 근본 원인은 컨텍스트 제한, 프롬프트 품질, 작업 분해가 아니라 — 다양한 작업을 병합하는 데 드는 인간의 비용입니다.

모델: N ≈ 1 / (당신을 기다리는 시간 비율)

저자는 유지 가능한 최대 병렬 에이전트 수(N)가 각 에이전트가 인간의 입력을 기다리는 시간 비율의 역수에 가깝다는 사실을 발견했습니다. 에이전트가 결정, 검토 또는 지침을 기다리며 시간의 3분의 1을 유휴 상태로 보낸다면, 실질적인 한계는 약 3개 에이전트입니다. 이는 관찰된 경험과 일치합니다: 에이전트 1개는 쉽고, 2개는 아주 좋으며, 3개는 한계점이고, 그 이상은 병렬 작업을 실행하는 것이 아니라 혼란스러운 자신의 버전을 위한 대기열을 운영하게 됩니다.

실제 부담: 조인 단계

가장 시간이 많이 걸리는 부분은 에이전트를 시작하는 것이 아니라 — 그들의 출력물을 조정하는 것입니다. 저자는 이것을 조인(join)이라고 부릅니다. 에이전트 A는 인증을 건드리고, 에이전트 B는 UI 흐름을 변경하며, 에이전트 C는 공유 유틸리티를 리팩터링합니다. 누군가는 이 모든 것을 하나로 합쳐야 합니다: 중복을 해결하고, 가정을 다시 읽고, 어떤 버전이 승리할지 결정하며, 코드베이스가 세 개의 거의 호환되는 형태 대신 하나의 일관된 형태를 갖도록 보장해야 합니다. 이 조인 단계가 대부분의 오버헤드를 소비합니다.

일반적인 해결책은 한계를 제거하지 못했습니다:

• 더 작은 작업 — 약간 도움이 되었지만 조인 수가 증가했습니다.
• 더 명확한 지침 — 작업이 진정으로 분리 가능할 때만 효과적이었습니다.
• 더 나은 요약 — 요약은 코드를 병합하거나 상충되는 결정을 통합하지 못합니다.

접근 방식의 변화: 에이전트를 값비싼 브랜치로 취급

저자는 이제 병렬 에이전트를 계획된 병합 전략이 필요한 값비싼 브랜치처럼 취급하며, 무료 추가 두뇌가 아닙니다. 조인이 실제로 해결해야 할 문제입니다. 전체 스레드에서는 다른 개발자들이 수동으로, 하나의 에이전트를 통합자로 사용하거나, 작업 경계를 더 좁게 강제하거나, 다른 방법으로 병합을 처리하는 방법에 대해 논의합니다.

Claude Code에서 진지한 다중 에이전트 작업을 하고 있다면, 조인이 병목 현상일 가능성이 높습니다. 이 게시물은 이를 식별하기 위한 프레임워크를 제공하고 커뮤니티의 해결책을 초대합니다.