Multi-Agent의 핵심은 Responsibility Boundary다

RUDA DIRECTOR · Architecture Note 01

30초 답변: Multi-Agent Architecture에서 가장 먼저 설계해야 할 것은 Agent 수가 아니라 Responsibility Boundary다. Direction, Orchestration, Execution, Independent Review를 분리하는 이유는 “조직처럼 보이게” 만들기 위해서가 아니라, 서로 다른 종류의 Decision과 Failure를 한 Context에 섞지 않기 위해서다.

핵심 정의: Multi-Agent의 목적은 역할 수 증가가 아니다

OpenAI Agents SDK는 Orchestration을 “어떤 Agent가 어떤 순서로 실행되고, 다음 Step이 어떻게 결정되는가”의 문제로 설명한다. Anthropic도 Multi-Agent system을 실제 운영하면서 Coordination, Evaluation, Reliability가 새로운 Engineering problem으로 등장한다고 설명한다.

즉 Multi-Agent의 질문은 “Agent를 몇 개 만들까?”가 아니다. 한 Agent로 두었을 때 충돌하는 Responsibility가 실제로 존재하는가?가 먼저다.

Responsibility Model

USER GOAL
   ↓
DIRECTION
무엇이 중요하고 어떤 결과를 통과로 볼까?
   ↓
ORCHESTRATION
어떤 Capability가 필요하고 무엇을 먼저 할까?
   ↓
EXECUTION
실제 Evidence / Artifact / Change를 만든다
   ↓
INDEPENDENT REVIEW
정확한가? 사용 가능한가? 무엇이 깨질 수 있는가?
   ↓
DECISION
Accept / Rework / Escalate

이 모델은 복잡한 Agent system에서 반복해서 등장하는 Responsibility를 이해하기 위한 개념 구조다.

왜 Direction과 Execution을 분리하나

Direction은 Goal, Priority, Trade-off, Quality Bar를 다룬다. Execution은 실제 Search, Analysis, Design, Code, Content 같은 Work를 수행한다.

둘을 한 Agent에 넣으면 Context 안에서 서로 다른 Optimization이 충돌할 수 있다. Execution은 “지금 주어진 Task를 끝내는 것”에 끌리고, Direction은 “이 Task가 정말 중요한가?”를 계속 물어야 한다. 둘이 섞이면 세부 작업을 많이 했다는 사실이 잘못된 방향을 정당화하는 경우가 생긴다.

왜 Orchestration을 별도 Responsibility로 보나

Orchestration은 직접 산출물을 만드는 것보다 Capability selection, Decomposition, Ordering, Handoff, Context boundary를 다룬다. OpenAI도 LLM-driven Orchestration과 Code-driven Orchestration을 구분하고, Manager-style Agent와 Handoff pattern을 상황에 따라 선택하도록 설명한다.

여기서 중요한 것은 Orchestrator가 “더 높은 Agent”라는 뜻이 아니라는 점이다. Orchestration은 작업을 어떻게 흐르게 할지에 책임이 있고, 최종 Quality Judgment와는 다른 문제다.

Worked Case: 하나의 Super Agent가 제품 출시 점검을 맡는다면

아래는 구조를 설명하기 위한 가상 예시다.

SUPER AGENT
“제품 출시 가능 여부를 점검해줘”
   ↓
Research
   ↓
UX Review
   ↓
Security 생각
   ↓
문구 수정
   ↓
자기가 만든 수정안을 자기가 다시 Review
   ↓
“대체로 출시 가능”

문제는 여러 Capability를 썼다는 데 있지 않다. Goal 설정, Work 수행, Review, Acceptance가 같은 Context와 같은 판단 주체 안에서 닫혔다는 데 있다.

Responsibility를 분리하면 질문 자체가 달라진다.

Direction
출시 기준과 중요 Risk를 먼저 정의
   ↓
Orchestration
필요한 검토 Capability와 순서를 선택
   ↓
Execution
각 영역 Evidence와 변경안 생성
   ↓
Independent Review
기능 / UX / Risk / Quality를 다른 질문으로 검증
   ↓
Decision
Accept / Rework / 추가 Evidence 요구

분리의 가치는 Agent 이름이 늘어나는 데 있지 않다. 같은 결과를 다른 질문으로 다시 보게 만드는 것에 있다.

Independent Review도 하나의 Reviewer로 뭉치면 안 되는 이유

Review Lens	핵심 질문	놓치기 쉬운 것
QA	요구사항대로 실제로 동작하는가?	Experience quality
UX Critic	사용자에게 이해되고 자연스러운가?	Functional regression
Red Team	어떤 Assumption·Misuse·Failure path가 깨뜨릴 수 있는가?	일상적인 정상 경로의 품질
Evaluation	의도한 Quality Bar에 도달했는가?	세부 Defect ownership

이 네 Lens는 서로 대체 관계가 아니다. “Review Agent 하나”로 합치면 Prompt가 길어지는 것보다 더 큰 문제가 생긴다. 어떤 질문이 실패했는지 분해하기 어려워진다.

Multi-Agent가 오히려 나빠지는 5가지 Failure Mode

Failure Mode	왜 발생하나	Control
Role Inflation	새 이름은 많지만 Responsibility가 겹침	Distinct Input / Output / Authority 확인
Coordination Tax	Handoff와 Context packaging 비용이 Work보다 커짐	작은 Task는 Single Agent 유지
Context Loss	Handoff마다 중요한 Constraint가 빠짐	명시적 Handoff contract
Authority Collision	여러 Agent가 같은 Decision을 동시에 소유	Decision owner 명확화
Review Theater	Reviewer가 있지만 Maker와 같은 기준·Context만 반복	독립 질문과 Evidence 요구

Trade-off: Multi-Agent는 Context와 Token을 ‘분리’하지만 Coordination을 ‘추가’한다

Anthropic의 Multi-Agent research system 사례에서도 여러 Agent를 쓰면 병렬 탐색과 별도 Context window를 활용할 수 있지만, Token 사용과 Coordination complexity가 크게 증가한다. 모든 Domain에 적합한 것도 아니다. 서로 강하게 의존하는 Task나 같은 Context를 계속 공유해야 하는 일은 Multi-Agent 이점이 작을 수 있다.

Multi-Agent가 유리한 조건	Single Agent가 유리한 조건
독립적으로 병렬화 가능한 Subtask	Task 간 Dependency가 강함
서로 다른 Tool/Skill boundary	같은 Context를 계속 공유해야 함
분리된 Review lens가 필요	짧고 되돌리기 쉬운 Task
Context window 분리가 가치 있음	Latency / Cost budget이 작음
Handoff contract를 명확히 만들 수 있음	Responsibility가 사실상 하나임

언제 굳이 분리하지 말아야 하나

한 번의 Search와 한 번의 Rewrite로 끝나는 작업, 실패해도 쉽게 되돌릴 수 있는 작업, 같은 Context를 계속 공유해야 하는 짧은 Task는 Single Agent가 더 낫다. Multi-Agent는 “성숙한 Architecture의 증거”가 아니라 Responsibility conflict를 해결하기 위한 비용 있는 선택이다.

Design Checklist

새 Agent를 만들기 전에 기존 역할과 다른 Responsibility가 있는가?
그 역할만의 Input / Output이 정의되는가?
그 역할이 소유하는 Decision이 하나 이상 명확한가?
Handoff할 때 잃을 수 있는 Context는 무엇인가?
Agent 추가로 생기는 Coordination Cost가 실제 Benefit보다 작은가?
Maker와 Reviewer가 같은 질문을 반복하고 있지는 않은가?
더 작은 Architecture로 같은 Quality를 낼 수는 없는가?

Design Rule: Multi-Agent의 핵심은 Agent 수가 아니라 Responsibility Boundary다. 분리는 서로 다른 Decision이 실제로 존재할 때만 정당화된다.

이전 글
AI Agent와 Workflow의 차이: 언제 Agent가 필요한가

이어 읽기
Agent Loop란 무엇인가: AI Agent가 한 번의 답변으로 끝나지 않는 이유

공식 참고 자료
OpenAI Agents SDK — Agent orchestration
Anthropic — Building effective agents
Anthropic — How we built our multi-agent research system

Multi-Agent에서 Direction·Orchestration·Execution을 왜 분리하는가