멀티 에이전트 루프 실패는 프롬프트 실패가 아닌 조직 설계 실패입니다

대부분의 멀티 에이전트 설정은 결국 같은 벽에 부딪힙니다. 에이전트들이 서로에게 계속 바운스되고, 리뷰어는 영원히 한 번 더 다듬자고 요청하며, 연구 워커는 끝없는 하위 주제를 생성하고, 도구 호출은 재귀 한도에 도달할 때까지 확대됩니다. 프레임워크 문서는 이를 '루프'라고 부르며 최대 반복 횟수 설정을 제공합니다. 점점 주목받는 가설은 이 설정이 증상만을 치료하며, 실제 문제는 에이전트가 어떻게 조직되는가에 있다는 것입니다.

자주 나타나는 패턴: 에이전트가 동료로 설계되면(연구자가 분석가와 대화, 분석가가 작가와 대화, 작가가 리뷰어에게 다시 전달) 누구도 결과를 명확히 소유하지 않습니다. 모든 에이전트는 다른 에이전트에게 더 많은 작업을 요청할 수 있습니다. 그래프는 이론상 중단 조건이 있지만, 어떤 에이전트도 '이것은 완료되었으니 실행을 중단하라'고 선언할 권한이 없습니다. 그 권한은 암묵적이며 동료 네트워크 전체에 분산됩니다.

해결책은 에이전트 네트워크를 동료들의 채팅방이 아닌 명시적인 보고 라인이 있는 조직도로 취급하는 것입니다. 제안된 계층:

• 의장 (최상위 권한, 종료 가능)
• 전략실
• 부서 관리자
• 팀 리드
• 전문 워커
• QA 및 정책은 별도의 스태프 부서로, 거부 및 에스컬레이션은 가능하지만 새로운 작업을 무제한 생성할 수 없음

핵심 메커니즘:

• 실행당 하나의 책임 미션 소유자
• 워크스트림당 하나의 소유자
• 유한한 위임 깊이
• 워커당 유형화된 반환 계약: 상태, 증거, 출력, 장애물, 다음 조치
• 관리자만 재개 또는 종료 권한
• 메모리는 권한 계층에 저장되고, 전문가는 범위 내 컨텍스트만 받음

특히 리뷰어-재귀 실패 모드는 검증자가 구조적으로 한 번의 거부 패스를 허용한 후 에스컬레이션해야 할 때 제거됩니다.

기존 프레임워크는 이미 기본 요소를 갖추고 있습니다:

• CrewAI — 관리자가 워커 출력을 검증하는 계층적 프로세스
• LangGraph — 감독자, 하위 에이전트, 명시적 재귀 한도
• OpenAI Agents SDK — 동료 핸드오프와 구별되는 관리자 스타일 오케스트레이션
• AutoGen — GroupChatManager
• Anthropic — 오케스트레이터-워커 연구 시스템

잘 활용되지 않는 아이디어: 관리자를 개방형 그룹 채팅의 중재자가 아닌 종료 권한이 있는 공식 보고 라인으로 취급하세요.

두 가지 공개된 우려사항:

1. 계층 구조 자체가 병목이 될 수 있습니다. 모든 결정이 상위로 올라가면 의장이 지연 및 실패의 단일 지점이 됩니다.
2. 에스컬레이션 기능은 최상위에 실제 중단 권한이 있을 때만 작동합니다. 의장이 더 많은 LLM을 호출하는 LLM을 호출하면 루프가 한 층 위로 이동했을 뿐입니다.

제안된 조직도 계층이 있는 저장소: github.com/jeongmk522-netizen/agentlas_org_chart