멀티 에이전트 거버넌스: 모든 에이전트를 동일하게 취급하는 것이 코디네이터, 플래너, 워커 시스템을 망치는 이유

2026년 프로덕션 멀티 에이전트 (multi-agent) AI의 지배적인 패턴은 오케스트레이터-워커 (orchestrator-worker) 구조입니다. 즉, 코디네이터 (coordinator) 에이전트가 특정 작업을 처리하기 위해 전문화된 서브 에이전트 (subagents)를 파견하고, 결과가 체인을 따라 다시 상위로 흐르며, 시스템이 통합된 출력을 제시하는 방식입니다. 대부분의 거버넌스 (governance) 도구들은 각 에이전트가 어떤 역할을 수행하는지 신경 쓰지 않습니다.

가장 깊은 곳에 있는 워커 (worker)에게 적용되는 것과 동일한 입력 검증 규칙이 코디네이터에게도 적용됩니다. 플래너 (planner) 레이어에서 실행되는 비용 제한은 실행 (execution) 레이어와 동일합니다. 만약 당신의 거버넌스 정책이 "어떤 에이전트의 출력에서도 PII(개인정보)를 플래그 처리하라"고 명시한다면, 호출을 수행하는 에이전트가 다음에 무엇을 할지 결정하는 에이전트이든 실제로 수행하는 에이전트이든 동일하게 작동합니다. 그것은 거버넌스가 아니라, 보여주기식 보안 (coverage theater)에 불과합니다.

7개의 프로덕션 멀티 에이전트 프레임워크에 걸쳐 1,600개 이상의 주석이 달린 실행 트레이스 (execution traces)를 분석한 2025년 연구(Cemri et al., arXiv:2503.13657)는 14가지의 뚜렷한 실패 모드 (failure modes)를 식별했습니다. 연구진은 이를 시스템 설계 문제 (system design issues), 에이전트 간 불일치 (inter-agent misalignment), 작업 검증 실패 (task verification failures)의 세 가지 범주로 분류했습니다. 이 분류 체계가 주목할 만한 이유는 이러한 실패 범주들이 대부분의 거버넌스 도구가 동일하게 취급하는 세 가지 아키텍처 레이어인 코디네이터 (coordinator), 플래너 (planner), 워커 (worker)와 직접적으로 매핑되기 때문입니다.

**멀티 에이전트 거버넌스 (Multi-agent governance)**는 개별 에이전트 내부뿐만 아니라 협업하는 에이전트 시스템 전체의 행동을 관리하는 정책, 제어 및 감독 메커니즘의 집합입니다. 거버넌스 플레인 (governance plane)이 모든 에이전트를 교체 가능한 것으로 취급할 때, 구성 요소는 보호할 수 있을지 몰라도 아키텍처는 노출된 상태로 남게 됩니다.

동일한 취급을 받는 세 가지 레이어

오케스트레이터-워커 아키텍처는 기능적으로 구별되는 최소 세 가지의 에이전트 역할을 포함하며, 각 역할은 리스크 (risk)와 서로 다른 관계를 맺고 있습니다:

**코디네이터 (The coordinator)**는 실행 계획 (execution plan)을 소유합니다. 어떤 에이전트를, 어떤 순서로, 어떤 컨텍스트 (context)와 함께 실행할지 결정합니다. 작업을 할당하고, 결과를 합성하며, 하위 작업 (subtask)의 출력이 진행하기에 충분히 수용 가능한지 여부를 결정합니다. 코디네이터의 실패 모드 (failure mode)는 대개 해로운 행동이 아니라 해로운 결정입니다. 즉, 민감한 요청을 잘못된 하위 에이전트 (subagent)에게 라우팅하거나, 검증되지 않은 사용자 입력을 신뢰할 수 있는 것처럼 하류 (downstream)로 전달하거나, 시스템이 중단하고 에스컬레이션 (escalation)해야 할 시점에 계속해서 반복을 수행하는 것입니다.

**플래너 (The planner)**는 상위 수준의 의도 (high-level intent)를 구조로 변환합니다. 목표를 분해하고, 의존성 (dependencies)을 드러내며, 실행 순서를 제안합니다. 플래너의 실패 모드는 범위 확장 (scope expansion)입니다. 즉, 합산했을 때 원래 요청의 권한을 초과하는 하위 작업들을 생성하는 것입니다. 예를 들어, 플래너가 문서 검토 요청을 40개의 하위 에이전트 호출로 분해할 경우, 각 호출은 개별적으로 범위 내에 있더라도, 요청을 시작한 사람이 전혀 예상하지 못했거나 명시적으로 승인하지 않았을 비용 및 데이터 접근 흔적 (data-access footprint)을 남길 수 있습니다.

**워커 (The worker)**는 실행합니다. 도구 (tools)를 호출하고, 데이터를 읽고, 출력을 작성합니다. 워커는 프로덕션 시스템 (production systems)에 직접 접촉하는 에이전트이며, 이것이 바로 워커가 거버넌스 (governance)의 거의 모든 관심을 받는 이유입니다. 하지만 워커는 종종 검증되지 않은 코디네이터의 결정이나 지나치게 광범위한 플래너의 분해에서 시작된 체인의 마지막 에이전트인 경우가 많습니다. 코디네이터와 플래너를 통제하지 않은 채 워커 계층에서만 거버넌스를 수행하는 것은, 서버실 문에는 자물쇠를 채워두고 네트워크는 제한 없이 열어두는 것과 대략적으로 같습니다.

코디네이터 수준의 거버넌스가 왜 다른 문제인가

코디네이터의 역할은 결정하는 것입니다. 이는 행동하는 것과는 다르지만, 멀티 에이전트 시스템 (multi-agent systems)에서 결정은 행동보다 상류 (upstream)에 위치합니다. 잘못된 코디네이터의 결정은 그가 파견하는 모든 에이전트를 통해 전파됩니다.

금융 서비스 워크플로우를 예로 들어보겠습니다. 코디네이터 (coordinator)가 사용자 질의를 수신하고 이를 데이터 검색 서브에이전트 (data-retrieval subagent), 계산 서브에이전트 (calculation subagent), 그리고 보고서 생성 서브에이전트 (report-generation subagent)로 라우팅(routing)합니다. 각 워커 (worker)는 개별적으로 범위가 지정된 권한 내에서 실행됩니다. 하지만 데이터베이스 접근 권한을 가진 서브에이전트에게 무엇이 포함되어 있든 상관없이 원본 사용자 질의를 직접 전달하기로 한 코디네이터의 결정은 거버넌스 계층 (governance layer)에 의해 검토되지 않았습니다. 코디네이터는 거버넌스 시스템이 전혀 인지하지 못한 상태에서 신뢰 기반의 결정을 내린 것입니다.

이것이 멀티 에이전트 시스템 (multi-agent systems)에서 프롬프트 인젝션 (prompt injection)이 발생하는 구조적 메커니즘입니다. 악성 콘텐츠는 워커의 입력 필터를 우회할 필요가 없습니다. 대신 코디네이터를 설득하여 자신이 실행될 수 있는 곳으로 라우팅하도록 만들면 됩니다. Cooperative AI Foundation의 2025년 연구 보고서 (Hammond et al., arXiv:2502.14143)는 멀티 에이전트 AI 시스템의 세 가지 주요 실패 모드 (failure modes)로 미조정 (miscoordination), 충돌 (conflict), 공모 (collusion)를 식별했습니다. 이들은 각각 개별 실행 계층 (execution layer)이 아닌 오케스트레이션 (orchestration) 및 조정 계층 (coordination layer)에서 발생합니다.

에이전트 간 정책 집행 (Cross-agent policy enforcement)을 워커 계층에서만 적용한다면 이 세 가지 문제를 모두 놓치게 됩니다. 거버넌스 평면 (governance plane)은 워커 옆이 아니라 코디네이터 위에 위치해야 합니다. 즉, 워커가 이미 실행을 마친 후가 아니라, 조정 결정이 파견되기 전에 이를 평가해야 합니다.

플래너의 범위 문제 (The Planner's Scope Problem)

작업을 공격적으로 분해하는 플래너 (planner)가 반드시 안전하지 않은 개별 결정을 내리는 것은 아닙니다. 각 서브태스크 (subtask)는 개별적으로 권한을 부여받았을 수 있습니다. 문제는 범위 검증 (scope validation)이 거의 보편적으로 툴 호출 (tool-call) 수준에서 구현된다는 점입니다. 즉, "이 에이전트가 이 API를 호출할 수 있는가?"라는 질문에는 답하지만, "모든 서브태스크의 합이 원래 승인된 범위에 비례하는가?"라는 플랜 (plan) 수준의 질문에는 답하지 못합니다.

이것이 중요한 이유는 플래너 (planner)의 범위 (scope) 결정이 누적되고 복리로 작용하기 때문입니다. Cemri 등의 분류 체계에 따르면, 에이전트의 범위가 어떻게 설정되는지 및 태스크가 어떻게 분해(decomposition)되는지를 포함하는 "시스템 설계 문제 (system design issues)"는 연구된 1,600개 이상의 트레이스 (trace) 전반에서 가장 큰 실패 범주였습니다. 가장 흔한 실패는 워커 (worker)가 범위를 벗어나 행동하는 것이 아니었습니다. 그것은 플래너에게 태스크를 어디까지 분해할 수 있는지에 대한 효과적인 제약 (constraint)을 주지 않은 시스템 설계였습니다.

플래너 수준의 거버넌스 (governance)는 단순히 실행 시점뿐만 아니라 플랜 (plan) 구조 단계에서 정책을 강제할 것을 요구합니다. 이것이 없다면, 플래너는 멀티 에이전트 거버넌스의 두 번째 사각지대가 됩니다. 코디네이터 (coordinator) 프롬프트 인젝션 (prompt injection)만큼 극적이지는 않지만, 프로덕션 시스템에서 통제 불능의 비용 발생과 의도치 않은 범위 확장 (scope expansion)의 더 큰 비중을 차지합니다.

워커의 신뢰 문제와 부모-자식 트레이스 격차 (The Worker's Trust Problem and the Parent-Child Trace Gap)

오케스트레이터-워커 (orchestrator-worker) 시스템의 워커들은 코디네이터와 플래너로부터 지침을 받습니다. 이들은 독립적으로 인증할 수 있는 메커니즘이 없는 에이전트들입니다. 만약 코디네이터가 프롬프트 인젝션에 의해 침해되었다면, 그 출력을 신뢰하는 모든 워커는 해당 침해를 상속받게 됩니다. 거버넌스 계층 (governance layer)은 이 신뢰 체인 (trust chain) 밖에 위치하며 각 핸드오프 (handoff) 지점에서 지침을 검증할 수 있는 시스템 내 유일한 구성 요소입니다.

이는 두 번째 구조적 요구 사항을 만들어냅니다: 거버넌스 평면 (governance plane)은 시스템의 진입점과 최종 출력뿐만 아니라, 모든 에이전트 간 경계 (inter-agent boundary)에서 관찰하고 강제해야 합니다.

또한 이는 부모-자식 트레이스 (parent-child trace) 문제를 야기합니다. 대부분의 트레이싱 (tracing) 및 옵저버빌리티 (observability) 도구는 어떤 에이전트가 어떤 순서로 호출되었는지는 알려줄 수 있습니다. 하지만 이들이 어려움을 겪는 부분은 하위 워커의 행동을 이를 승인한 코디네이터의 결정과 연결하여 귀속시키는 것입니다. 특히 디스패치 (dispatch) 결정이 코드에 미리 정해져 있지 않은 동적 라우팅 (dynamic routing) 시스템에서는 더욱 그러합니다.

각 에이전트의 권한(authority), 역할(role), 계보(lineage)를 기록하는 에이전트 레지스트리 (agent registry)는 이러한 귀속(attribution)을 위한 전제 조건입니다. 이것이 없다면, 멀티 에이전트 실행 로그 (execution log)는 인과 구조가 없는 단순한 연대기적 이벤트 목록에 불과합니다. 로그를 읽을 수는 있겠지만, 사고 후 검토(post-incident review)에서 가장 중요한 질문, 즉 "어떤 코디네이터(coordinator)의 결정이 이 결과로 이어진 일련의 행동 체인을 승인했는가?"라는 질문에 답하는 데는 사용할 수 없습니다.

추적(trace) 문제는 외부 에이전트 — 벤더가 구축한 도구, 제3자 MCP 서버, 다른 팀이 구축한 오케스트레이터(orchestrator) — 를 포함하는 멀티 에이전트 시스템에서 특히 심각합니다. 이러한 에이전트들은 당신이 제어하는 SDK 외부에서 작동합니다. 이들의 동작은 당신이 구축한 구성 요소 주변뿐만 아니라, 전체 시스템 상단에 위치하는 거버넌스 계층(governance layer)이 있어야만 관찰 가능합니다.

Waxell이 이를 처리하는 방식

Waxell Runtime은 정책 집행(policy enforcement)을 워커(worker)와 나란히 하는 것이 아니라, 코디네이터(coordinator) 상위 단계인 거버넌스 평면(governance plane) 수준에서 적용합니다. 이는 에이전트 계층 구조의 서로 다른 지점에 서로 다른 규칙을 적용할 수 있음을 의미합니다. 코디네이터 수준의 결정, 플래너(planner)의 분해(decomposition), 그리고 워커의 도구 호출(tool call)은 서로 다른 리스크 프로필(risk profiles)을 가지며, Waxell Runtime이 기본적으로 제공하는 50개 이상의 정책 카테고리는 재구축 없이도 실행 전(pre-execution), 실행 중(mid-execution), 실행 후(post-execution) 집행을 모두 커버합니다.

당신이 직접 구축하지 않은 에이전트 — 벤더가 구축한 오케스트레이터, 제3자 서브 에이전트(subagent), MCP를 통해 통합된 외부 도구 — 를 포함하는 멀티 에이전트 시스템의 경우, Waxell Connect는 외부 시스템의 SDK 인스트루멘테이션(instrumentation)이나 코드 변경 없이도 당신이 구축하지 않은 에이전트들을 관리합니다. 이는 당신이 제어하는 에이전트와 제어하지 않는 에이전트 사이의 경계에서 거버넌스를 집행하며, 바로 이 지점이 오케스트레이터-워커 시스템에서 신뢰 격차(trust gap)가 가장 큰 곳입니다.

Waxell이 캡처하는 멀티 에이전트 실행 로그는 시스템의 인과 구조(causal structure)를 보존합니다: 코디네이터(coordinator)의 결정 → 플래너(planner)의 분해(decomposition) → 워커(worker)의 실행, 그리고 각 전환 지점에서의 거버넌스 점검(governance check) 결과가 포함됩니다. 이것이 바로 멀티 에이전트 감사 추적(audit trail)이 실제로 포함해야 할 내용입니다. 즉, 단순한 평면적 이벤트 목록(flat event list)이 아니라, 각 작업을 이를 승인한 권한(authority)에 다시 매핑하는 인과적으로 정렬된 기록이어야 합니다.

FAQ

왜 대부분의 거버넌스 도구는 멀티 에이전트 시스템에서 모든 에이전트를 동일하게 취급하나요?
LangSmith, Arize, Braintrust와 같은 지배적인 도구들이 단일 에이전트 관측성(observability)을 위해 설계된 후 멀티 에이전트 용도로 확장되었기 때문입니다. 이 도구들은 LLM 호출(LLM call) 또는 도구 호출(tool call) 수준에서 계측(instrument)을 수행하는데, 이는 각 에이전트가 무엇을 했는지는 포착하지만 각 에이전트의 역할에 따라 서로 다른 규칙을 강제하지는 못합니다. 역할에 따라 차별화하는 거버넌스를 구현하려면 각 개별 에이전트 내부가 아닌, 오케스트레이션 프레임워크(orchestration framework) 상위에 위치하는 레이어가 필요합니다.

코디네이터 레이어에서 구체적으로 어떤 실패 모드(failure modes)가 나타나나요?
프롬프트 인젝션 라우팅(prompt injection routing, 악성 콘텐츠가 코디네이터를 설득하여 민감한 에이전트에게 작업을 할당하게 만드는 경우), 권한 우회(authorization bypass, 코디네이터가 검증되지 않은 사용자 입력을 마치 신뢰할 수 있는 시스템 지침인 것처럼 전달하는 경우), 그리고 통제되지 않는 반복(uncontrolled iteration, 코디네이터가 사람이 중단했을 시점을 지나 계속해서 하위 에이전트(subagents)를 생성하는 경우) 등이 있습니다. 이 중 그 어느 것도 워커 레이어의 정책 집행(policy enforcement)으로는 잡아낼 수 없습니다.

플래너(planners)의 "범위 확장(scope expansion)" 문제란 무엇인가요?
오케스트레이터-워커 시스템에서 플래너는 상위 수준의 목표를 하위 작업(subtasks)으로 분해합니다. 각 하위 작업은 개별적으로 승인될 수 있지만, 전체적인 발자국(aggregate footprint) — 즉, API 호출 횟수, 액세스된 데이터의 양, 발생한 총 비용 — 은 사용자나 운영자가 의도한 범위를 훨씬 초과할 수 있습니다. 플래너 수준의 거버넌스는 단순히 개별 실행에 대한 제약을 거는 것이 아니라, 계획 구조(plan structure) 자체에 대한 제약을 강제하는 것을 필요로 합니다.

Waxell Connect는 멀티 에이전트 시스템(multi-agent system)에서 외부 에이전트를 거버넌스하는 데 어떻게 도움을 주나요?
Waxell Connect는 귀하가 직접 구축하지 않은 에이전트들 — 제3자 오케스트레이터(third-party orchestrators), 벤더 에이전트(vendor agents), MCP 네이티브 통합(MCP-native integrations) — 에 대해, 해당 시스템이 귀하의 SDK를 계측(instrument)하거나 코드를 변경할 필요 없이 거버넌스를 수행합니다. 이는 귀하의 시스템이 외부 에이전트와 상호작용하는 경계(boundary)에서 거버넌스를 강제하며, 이 경계는 모든 오케스트레이터-워커(orchestrator-worker) 아키텍처에서 신뢰 체인(trust chain)의 간극이 가장 넓은 지점입니다.

대부분의 로그가 놓치는 멀티 에이전트 감사 추적(audit trail)에는 무엇이 포함되어야 하나요?
인과 구조(Causal structure): 어떤 코디네이터(coordinator)의 결정이 어떤 플래너(planner)의 행동을 승인했는지, 어떤 플래너의 분해(decomposition)가 어떤 워커(worker) 호출로 이어졌는지, 그리고 각 핸드오프(handoff) 시점에 어떤 정책 검사(policy checks)가 실행되었는지를 포함해야 합니다. 대부분의 트레이싱(tracing) 도구는 타임스탬프 순으로 정렬된 평면적인 이벤트 목록(flat event lists)을 생성합니다. 활용 가능한 멀티 에이전트 감사 추적은 모든 결과를 그것을 발생시킨 오케스트레이션 결정(orchestration decision)까지 추적할 수 있게 해주는 인과적으로 구조화된 기록입니다.

EU AI Act 요구 사항이 멀티 에이전트 시스템에 대해 다르게 적용되나요?
EU AI Act 부속서 III(EU 디지털 옴니버스 수정안에 따라 2027년 12월 발효)에 따라, 고위험 AI 시스템은 인간의 감독(human oversight), 상세한 로깅(logging), 그리고 의사결정에 대한 투명성을 유지해야 합니다. 규제 대상 섹터의 멀티 에이전트 시스템의 경우, 이는 실행(execution) 단계뿐만 아니라 코디네이션(coordination) 및 플래닝(planning) 계층에서의 거버넌스 적용을 실질적으로 요구합니다. 왜냐하면 컴플라이언스 리스크(compliance risk)를 생성하는 결정은 워커(worker)가 아니라 오케스트레이터(orchestrator)에서 시작되기 때문입니다.

출처