멀티 에이전트는 왜 병렬 호출이 아니라 실행 트리일까

• 카테고리: ai_dev
• 예상 읽기 시간: 10분
• 오늘의 질문: 하위 에이전트를 여러 개 띄우면 정말 품질과 속도가 좋아질까, 아니면 실패 지점만 늘어날까?
• 핵심 출처:
  • Multi-agent | OpenAI API - 게시일 미기재, 확인일 2026-07-26
  • Changelog | OpenAI API - 2026-07-09, 확인일 2026-07-26
  • What's new in Gemini 3.5 Flash - Interactions API - 2026-07-21, 확인일 2026-07-26
  • Gemini thinking - Interactions API - 게시일 미기재, 확인일 2026-07-26
  • Enabling Claude Code to work more autonomously - 2025-09-29, 확인일 2026-07-26

1. 왜 지금 봐야 하나

에이전트 기능은 이제 “도구 하나를 호출하는 챗봇”에서 “여러 작업을 나누고, 기다리고, 합치는 실행 환경”으로 이동하고 있다. OpenAI API changelog는 2026년 7월 GPT-5.6 계열에 Programmatic Tool Calling, persisted reasoning, max reasoning effort, Responses API용 Multi-agent orchestration beta가 추가됐다고 적고 있다. 별도 Multi-agent 문서는 루트 에이전트가 하위 에이전트 트리를 만들고, 메시지를 보내고, 기다리고, 최종 응답을 합성하는 구조를 설명한다.

Google 쪽도 비슷한 신호를 준다. Gemini 3.5 Flash 문서는 1M 토큰 컨텍스트, 65k 최대 출력, thinking, agentic·coding·long-horizon workflow 최적화를 강조하고, 기본 thinking effort가 high에서 medium으로 바뀌었다고 설명한다. Gemini thinking 문서는 thought step과 signature가 멀티턴 reasoning continuity를 유지하는 상태라는 점을 강조한다.

Anthropic은 Claude Code의 subagents, hooks, background tasks, checkpoints를 묶어 더 긴 개발 작업을 맡길 수 있게 했다고 설명한다. 여기서 중요한 점은 “AI를 여러 명 붙였다”가 아니다. 멀티 에이전트가 제품 기능이 되려면 실행 트리, 컨텍스트 경계, 도구 권한, 중간 상태, 최종 합성 규칙이 필요하다는 점이다.

2. 핵심 개념

멀티 에이전트는 병렬 API 호출이 아니라 실행 트리다.

단순 병렬 호출은 이렇게 생겼다.

request -> call A
        -> call B
        -> call C
        -> join results

실행 트리는 조금 다르다.

root agent
  ├─ subagent: 보안 검토
  │   ├─ tool call
  │   └─ local context
  ├─ subagent: 테스트 누락 검토
  │   ├─ tool call
  │   └─ local context
  └─ subagent: 성능 영향 검토
      ├─ tool call
      └─ local context
root agent -> 충돌 제거 -> 우선순위화 -> 최종 응답

차이는 세 가지다.

1. 누가 일을 나누는가: 애플리케이션 코드가 고정된 세 호출을 날리는 것이 아니라, 루트 에이전트가 하위 작업을 만들 수 있다.
2. 각 작업의 컨텍스트가 분리되는가: 하위 에이전트는 자기 작업에 필요한 정보만 들고 집중한다. 대신 전체 상황을 놓칠 수 있다.
3. 누가 합성 책임을 지는가: 각 하위 결과가 맞아도 최종 답변이 틀릴 수 있다. 루트 에이전트의 중복 제거, 충돌 해소, 근거 확인이 별도 품질 지점이 된다.

OpenAI Multi-agent 문서는 루트 에이전트가 subagent를 spawn하고, message를 보내고, wait하고, interrupt하며, 마지막 synthesis를 담당한다고 설명한다. 또한 개발자 정의 function call은 일반 Responses API와 같은 방식으로 애플리케이션이 실행해야 하고, Multi-agent의 hosted collaboration action은 애플리케이션이 직접 실행하거나 결과를 제출하면 안 된다고 구분한다. 이것은 “도구 호출이 늘었다”가 아니라 “실행 주체가 여러 층으로 나뉜다”는 뜻이다.

3. 최신 이슈와 연결

최근 문서들이 공통으로 보여주는 변화는 “모델이 오래 생각하고 여러 도구를 쓰는 동안 상태를 어떻게 보존할 것인가”다.

• OpenAI Multi-agent beta는 하위 에이전트 트리, 동시 subagent 수, WebSocket 기반 function output injection, agent-attributed event, trace/replay용 output item 보존을 다룬다.
• Gemini 3.5 Flash 문서는 thought preservation이 멀티턴 대화에서 자동으로 유지되고, stateless GenerateContent에서는 thought signature가 포함된 전체 대화 기록을 그대로 보내야 reasoning context가 이어진다고 설명한다.
• Gemini thinking 문서는 thought signature가 암호화된 내부 reasoning state이며, stateless mode에서는 thought block을 제거하거나 수정하지 말아야 한다고 말한다.
• Anthropic Claude Code의 checkpoints는 코드 변경 전 상태를 자동 저장하고 rewind할 수 있게 한다. subagents와 hooks가 강력해질수록 되돌릴 수 있는 상태 경계가 더 중요해진다는 신호다.

즉 멀티 에이전트의 최신 포인트는 “몇 개를 동시에 돌릴 수 있나”보다 “각 실행 단위가 만든 상태를 어떻게 보존·검증·되돌릴 수 있나”에 가깝다.

4. 개발자 관점 해석

멀티 에이전트를 붙이면 좋아지는 경우가 분명히 있다.

• 큰 코드베이스에서 보안, 테스트, 성능, 문서 검토처럼 관점이 독립적인 경우
• 여러 문서나 후보를 비교해야 하는 경우
• 한 에이전트가 모든 컨텍스트를 읽으면 오히려 집중력이 떨어지는 경우
• 벽시계 시간이 중요하고, 하위 작업들이 서로 거의 기다리지 않아도 되는 경우

하지만 실패 모드도 명확하다.

실패 모드 1: 병렬화할 수 없는 일을 억지로 나눈다

한 단계의 결과가 다음 단계 입력을 결정하는 작업은 멀티 에이전트로 나눠도 빨라지지 않는다. 오히려 루트가 중간 결과를 해석하고 다시 지시하는 비용이 늘어난다. “독립적인 하위 질문인가?”를 먼저 봐야 한다.

실패 모드 2: 공유 리소스가 충돌한다

여러 하위 에이전트가 같은 파일을 수정하거나 같은 외부 시스템에 write하면 race condition이 생긴다. 멀티 에이전트에서 write 권한은 특히 보수적으로 줘야 한다. 읽기·분석 subagent와 쓰기 executor를 분리하는 편이 안전하다.

실패 모드 3: 합성 단계가 eval 없이 감으로 끝난다

하위 에이전트가 각각 그럴듯한 답을 가져오면 루트 에이전트는 평균적인 요약을 만들기 쉽다. 하지만 제품에서는 “무엇을 버렸는가”, “서로 충돌하는 결론은 무엇인가”, “근거가 없는 주장은 무엇인가”가 더 중요하다. 최종 합성에는 별도 루브릭이 필요하다.

실패 모드 4: trace가 없어서 재현할 수 없다

OpenAI 문서가 multi_agent_call, multi_agent_call_output, agent_message 같은 item 보존을 언급하는 이유가 여기에 있다. 나중에 “왜 이 답이 나왔나”를 보려면 루트의 최종 문장만 저장하면 부족하다. 하위 작업 지시, 도구 결과, 합성 판단을 최소한의 실행 그래프로 남겨야 한다.

실패 모드 5: reasoning state를 일반 로그처럼 다룬다

Gemini의 thought signature는 사람이 읽는 로그가 아니라 reasoning continuity를 위한 상태 토큰에 가깝다. stateless mode에서 이를 제거하거나 수정하면 다음 턴 품질이 흔들릴 수 있다. 반대로 thought summary는 디버깅 힌트일 수 있지만 항상 존재하지 않으며, 내부 reasoning 전체를 대표한다고 보면 안 된다.

5. 내 프로젝트에 적용할 체크포인트

멀티 에이전트를 도입하기 전에 아래 질문을 먼저 통과시키자.

1. 분해 가능성: 하위 작업들이 서로 독립적인가, 아니면 순차 의존성이 강한가?
2. 컨텍스트 경계: 각 subagent가 읽어야 하는 최소 문서는 무엇인가? 전체 컨텍스트를 다 줄 필요가 있는가?
3. 도구 권한: subagent가 write 도구를 직접 호출해야 하는가, 아니면 root가 승인 후 실행해야 하는가?
4. 동시성 한도: 최대 subagent 수를 몇 개로 제한할 것인가? 기본값을 무제한처럼 다루지 않는가?
5. 합성 루브릭: 루트 에이전트가 결과를 합칠 때 중복, 충돌, 근거 누락, 위험도를 어떻게 표시할 것인가?
6. 상태 보존: 하위 지시, 도구 호출, function output, final synthesis를 나중에 재현할 수 있게 저장하는가?
7. 되돌리기: 코드 변경이나 외부 write가 있다면 checkpoint, dry-run, diff review, human approval 중 무엇을 둘 것인가?
8. 비용 지표: 성공률만 보지 말고 wall-clock time, total tokens, tool calls, retry 수, cached tokens 또는 thought tokens를 같이 보는가?

6. 오늘 10분 액션

오늘은 멀티 에이전트를 구현하지 말고, 기존 AI 기능 하나를 실행 트리로 그려보자.

기능: PR 리뷰 자동화

root agent의 책임:
- diff를 읽고 하위 검토 작업을 만든다.
- 하위 결과의 중복과 충돌을 정리한다.
- 최종 코멘트 우선순위를 매긴다.

subagent A: correctness
- 입력: diff 중 로직 변경 파일
- 도구: read-only repository search
- 출력: file, line, issue, confidence, evidence

subagent B: security
- 입력: auth, permission, input handling 관련 diff
- 도구: read-only repository search
- 출력: file, line, risk, exploit path, evidence

subagent C: tests
- 입력: 변경 파일과 테스트 디렉터리 목록
- 도구: read-only repository search
- 출력: missing test case, reason, suggested test file

합성 루브릭:
- 같은 파일·원인의 중복 제거
- security > correctness > tests 순서로 우선순위화
- evidence 없는 항목은 “확인 필요”로 강등
- write 작업은 하지 않음

마지막으로 eval 세 줄을 적는다.

성공 기준: 사람이 남긴 주요 리뷰 코멘트의 70% 이상을 포착한다.
실패 기준: 근거 없는 high severity 코멘트가 2개 이상이면 실패다.
비교 기준: 단일 에이전트 대비 wall-clock time과 총 토큰을 같이 비교한다.

이 10분 액션의 목적은 “멀티 에이전트가 멋져 보이는가”가 아니라 “내 작업이 실행 트리로 나눌 가치가 있는가”를 확인하는 것이다.

7. 더 볼 자료

• OpenAI Multi-agent 문서: Responses API에서 root/subagent 트리, hosted collaboration actions, WebSocket function output injection을 어떻게 다루는지 확인하기 좋다.
• OpenAI API Changelog: GPT-5.6 계열의 persisted reasoning, max reasoning effort, Multi-agent beta가 어떤 릴리스 맥락에서 나왔는지 확인할 수 있다.
• Gemini 3.5 Flash 문서: thinking_level, thought preservation, function response matching처럼 agentic workflow 운영 시 깨지기 쉬운 규칙을 볼 수 있다.
• Gemini thinking 문서: thought step, signature, stateless/stateful mode의 차이를 이해하는 데 유용하다.
• Anthropic Claude Code autonomous work 글: subagents, hooks, background tasks, checkpoints가 개발 워크플로에서 어떤 안전장치와 함께 묶이는지 볼 수 있다.

중복 회피 메모

로컬 content/generated와 Supabase 최근 ai_dev 글을 확인했다. 최근 글은 fine-grained tool streaming의 JSON 검증 지점, LLM-as-a-judge 측정기 설계, MCP Sampling 권한 요청, 임베딩 차원 스키마, 멀티모달 토큰 예산, 서비스 티어, 프롬프트 인젝션 신뢰 경계, Programmatic Tool Calling 실행 경계, 서브에이전트 컨텍스트 격리를 다뤘다. 이번 글은 특정 도구 호출·권한·서브에이전트 소개 반복이 아니라 OpenAI Multi-agent beta와 Gemini/Claude의 최근 agentic 기능을 묶어, 멀티 에이전트를 실행 트리와 합성 책임으로 운영할 때 어떤 경계·상태·실패 모드를 설계해야 하는지에 집중한다.