본문으로 건너뛰기

네이티브 멀티 에이전트 API: OpenAI의 Responses 멀티 에이전트 베타 vs 직접 구축하기

고급

18개월 동안 "멀티 에이전트"란 당신이 팬아웃을 작성한다는 뜻이었습니다. 코디네이터 프롬프트를 작성하고, N개의 호출을 병렬로 스폰하고, JSON을 병합하고, 재시도를 처리했습니다. 2026년 7월 9일, OpenAI는 이 모든 것을 요청 파라미터 하나로 압축했습니다. Responses API의 **multi_agent.enabled: true**이며, Sol Ultra Mode라는 컨슈머 기능으로 포장되었습니다. 모델 자체가 스폰할 서브에이전트 수를 결정하고, 병렬로 실행하고, 결과를 종합합니다. 모두 단일 HTTP 호출 내부에서 이루어집니다. 다른 어떤 프런티어 벤더도 대칭적인 프리미티브를 출시하지 않았습니다. 이 페이지는 실제로 출시된 것, 그 뒤의 숫자, Anthropic이 제공하는 대안, 그리고 가장 중요한 부분인 네이티브 프리미티브가 비용을 정당화하는 세 가지 워크로드와 DIY 팬아웃이 여전히 이기는 두 가지 워크로드를 매핑합니다.

What you'll learn
  • 정확한 Responses API 멀티 에이전트 요청 본문을 읽고 max_concurrent_subagents가 실제로 무엇을 제한하는지 이해합니다
  • 비용 계산: '모델이 4개의 서브에이전트를 스폰'하는 것이 Sol 가격으로 실제로 얼마인지 파악합니다
  • Anthropic 측의 동일한 영역 — Cowork, Managed Agents, Claude Code 서브에이전트 — 를 매핑하고 프리미티브 격차를 확인합니다
  • 워크로드별 올바른 프리미티브 선택: 네이티브 멀티 에이전트, DIY 팬아웃, A2A, 또는 단일 긴 턴
  • 4-에이전트 Ultra 호출을 정확도 향상 없이 4배 청구서로 만드는 네 가지 실패 모드를 피합니다

한 문장 요약​

Ultra Mode는 Responses API의 multi_agent.enabled: true에 대한 컨슈머 스킨입니다 — 모델이 하나의 요청 내부에서 서브에이전트를 병렬로 스폰하고, 출력을 종합하고, 단일 응답을 반환할 수 있게 하는 네이티브 프리미티브입니다. 병렬화 가능한 작업에서 작지만 실질적인 정확도 향상(Terminal-Bench 2.1: 88.8% → 91.9%)을 얻을 수 있으며, 토큰 청구서는 모델이 스폰하기로 선택한 서브에이전트 수에 대략 선형적으로 비례합니다.

2026년 7월 9일 실제로 출시된 것​

같은 출시에 두 가지가 함께 도착했으므로 구분할 가치가 있습니다.

  • Ultra Mode — ChatGPT와 Codex 내부의 제품 토글. 플래그십 티어(Sol)에서 사용 가능합니다. 활성화되면 어려운 작업이 종합 전에 병렬 서브에이전트 실행으로 분해됩니다. "4개 이상의 에이전트를 스폰"으로 마케팅되며, OpenAI 자체 GA 벤치마크 차트 몇 개는 BrowseComp 및 SEC-Bench Pro에서 16-에이전트 구성도 보여주지만, 기본 작동값은 4입니다.
  • Responses API 멀티 에이전트 베타 — 개발자 프리미티브. 동일한 기저 기능이 client.beta.responses.create()의 multi_agent.enabled: true로 노출됩니다. 자체 Ultra 유사 경험을 구축할 때 사용하는 것입니다.

마케팅이 남긴 혼란은 실재합니다. 빌더들은 계속 "API에서 Ultra Mode를 어떻게 호출하나요?"라고 묻습니다. 답은 호출하지 않는다는 것입니다 — 제품 기능 아래의 프리미티브인 멀티 에이전트 베타를 활성화하는 것입니다.

Responses API 멀티 에이전트 요청​

구체적으로 형태는 다음과 같습니다(Python SDK).

최소 멀티 에이전트 Responses API 호출

from openai import OpenAI

client = OpenAI()

resp = client.beta.responses.create(
  model="gpt-5.6-sol",
  input="Audit this repo for auth-bypass patterns and write a report.",
  multi_agent={
      "enabled": True,
      "max_concurrent_subagents": 3,
  },
  tools=[...],  # your MCP tools, function tools, etc.
  extra_headers={"OpenAI-Beta": "responses_multi_agent=v1"},
)

이 형태에서 뻔하지 않은 네 가지:

  • max_concurrent_subagents는 총 예산이 아닙니다. 이는 주어진 순간에 전체 트리(루트와 자손 포함)에서 활성 서브에이전트 턴을 제한합니다. 모델은 요청 수명 동안 훨씬 더 많은 총 서브에이전트를 스폰할 수 있으며, 단지 동시에 N개 이상을 실행할 수 없을 뿐입니다.
  • 깊이는 무제한입니다. 서브에이전트가 스스로 서브에이전트를 스폰할 수 있습니다. 트리 깊이나 실행당 총 서브에이전트 수에 고정된 제한이 없습니다. 비용 표면은 "N개 호출"이 아니라 모델이 런타임에 형성하는 트리입니다.
  • 루트가 종합합니다. 루트 에이전트가 서브에이전트 응답을 최종 답변으로 병합할 책임이 있습니다. 구조화된 {subagents: [...]} 객체를 돌려받지 않습니다. 하나의 응답을 받게 되며, 중간 에이전트 턴은 코드에 불투명합니다.
  • 일부 파라미터는 조용히 비활성화됩니다. reasoning.summary와 max_tool_calls는 멀티 에이전트가 활성화된 상태에서 지원되지 않으며, compaction 엔드포인트는 멀티 에이전트 응답에 대해 지원되지 않습니다. 관측성을 위해 추론 요약에 의존한다면, 이를 켜는 순간 잃게 됩니다.

마케팅 페이지에 인쇄되지 않은 비용 계산​

Sol의 GA 가격인 입력 백만 토큰당 $5 / 출력 백만 토큰당 $30에서 산술은 냉혹합니다. 실제 Ultra 실행을 리버스 엔지니어링한 빌더 문서에서:

  • Ultra가 2개의 서브에이전트로 분해하는 작업은 단일 Sol 호출의 출력 토큰 비용의 약 2배입니다 — 두 서브에이전트 모두 출력을 생성하고, 루트가 그 위에 종합을 생성하기 때문입니다.
  • Ultra가 5개의 서브에이전트를 스폰하는 작업은 약 5배입니다 — 같은 추론에 트리 전체에 걸친 비례적으로 더 많은 입력 토큰 재생이 더해집니다.
  • 16-에이전트 구성을 보여주는 BrowseComp / SEC-Bench 차트는 공짜가 아닙니다. 이는 연구용 시연이지 기본값이 아닙니다. Sol에서 16개의 동시 서브에이전트를 사용하면, 어려운 쿼리당 출력 토큰만으로 두 자릿수 중반 달러 수치를 보게 됩니다.

이렇게 생각하는 방법: 당신은 Sol 호출의 몬테카를로와 그 위에 하나의 종합 패스에 대해 지불하고 있습니다. 때로는 그것이 중요한 정확도를 살 만큼입니다. 때로는 단일 호출로 해결될 작업에 대한 4배 청구서일 뿐입니다.

정확도가 실제로 사는 것​

병렬화 가능한 평가 — Ultra Mode가 설계된 워크로드 — 에 대한 게시된 델타는 실재하지만 완만합니다.

벤치마크Sol (단일)Sol Ultra델타평가 측정 대상
Terminal-Bench 2.188.8%91.9%+3.1다단계 커맨드라인 계획, 도구 조율
BrowseComp87.5%92.2%+4.7다중 소스 웹 리서치 및 종합
SEC-Bench Pro—74.3%(단일 모드 숫자 미공개)대규모 코퍼스 전반의 규제 문서 추론

이 표에 대한 세 가지 지점:

  • +3–5점 대역은 병렬 샘플링이 다른 프런티어에서 역사적으로 얻어온 것(best-of-N, self-consistency)과 일치합니다. 프리미티브는 진정으로 유용하지만, 델타는 단계적 변화가 아닙니다.
  • 이는 최선의 경우입니다 — 모드를 돋보이게 하기 위해 선택된 평가입니다. 순차적 작업(선형 코드 편집, 단일 파일 재작성, 짧은 대화)에서 Ultra는 정확도를 움직이지 않고 종합 지연과 비용을 추가합니다.
  • 동일한 Terminal-Bench 2.1 차트에서 Anthropic의 Opus 4.8은 78.9%를 기록했습니다 — 즉, Sol Ultra의 우위는 더 나은 기저 모델과 그 위에 쌓인 멀티 에이전트 부스트 양쪽에서 나옵니다. Opus에서 Sol Ultra로 마이그레이션한다면, 전체 격차를 멀티 에이전트 프리미티브에만 귀속시키지 마세요.

Anthropic의 대안​

Anthropic은 대칭적인 API 프리미티브를 출시하지 않았습니다. 가장 가까운 유사물들은 각각 같은 문제의 다른 조각을 해결합니다.

  • Cowork — 제품 표면. 에이전트가 사용자와 함께 지속적인 다단계 작업을 수행하는 에이전틱 데스크톱 워크스페이스입니다. Ultra Mode와 기능으로서는 비교 가능하지만 API 프리미티브로서는 아닙니다.
  • Managed Agents 및 managed-agents 메모리 스토어 — 지속적 상태와 스케줄링이 있는 호스팅된 에이전트 루프. "장기 실행 백그라운드 에이전트" 슬롯을 채우지, "4개를 병렬로 스폰하고 병합" 슬롯은 아닙니다.
  • Claude Code 서브에이전트 및 서브에이전트 플릿 제한 — 최상위 서브에이전트 프리미티브이지만, Claude Code CLI로 범위가 지정됩니다. 문서화되어 있고, 병렬로 스폰 가능하며, multi_agent.enabled에 가장 가까운 유사물입니다 — 다만 코디네이터 프롬프트를 직접 작성해야 한다는 중요한 차이가 있습니다.
  • Messages API의 에이전트 구축 — DIY 경로. N개의 messages.create 호출을 병렬로 팬아웃하고, 종합 프롬프트를 작성하고, 재시도를 처리합니다. 같은 결과, 더 많은 코드.

격차는: 현재 Anthropic API 표면 중 단일 불리언을 뒤집는 것만으로 모델 자체가 스폰할 서브에이전트 수를 결정하고 작업을 병합하도록 하는 것은 없습니다. Claude에서 그 동작을 원한다면 직접 구축하세요 — 제품 측 스토리는 Cowork 및 에이전트 팀을, 호스팅 루프 프리미티브는 Managed Agents를 참조하세요.

워크로드별 올바른 프리미티브 선택​

Guided walkthrough1 of 5
  1. 서브태스크가 서로의 결과를 기다리지 않고 실행될 수 있다면 — 리포지토리 감사, 여러 소스에 걸친 주제 리서치, N개의 파일을 독립적으로 리팩터링 — 팬아웃 형태가 비용을 정당화합니다. 작업이 순차적이라면(A 편집, A의 결과 읽기, B 편집), 모든 멀티 에이전트 프리미티브는 이득 없이 종합 오버헤드를 추가합니다.

Ultra를 아무런 이유 없이 4배 청구서로 만드는 네 가지 실패 모드​

  • 순차 작업에 대해 켜기. 작업이 병렬화되지 않을 때에도 모델은 여전히 분해하고 종합합니다. 필요하지 않았던 작업에 대한 조율 오버헤드를 지불합니다. 경험칙: 첫 번째가 실행되는 동안 두 번째 서브에이전트가 무엇을 할지 명확히 말할 수 없다면, 멀티 에이전트를 활성화하지 마세요.
  • 대시보드에 추론 요약 관측성을 남기기. reasoning.summary는 멀티 에이전트로 조용히 지원되지 않습니다. 모니터링이 이에 의존한다면, 빈 필드를 얻고 모델이 생각하지 않는다고 오해할 것입니다. 플래그를 뒤집기 전에 스키마 변경을 배포하세요.
  • max_tool_calls를 안전 제한으로 사용. 멀티 에이전트로 마찬가지로 조용히 비활성화됩니다. 있다고 생각했던 안전 스토리 — "요청당 최대 20개의 도구 호출" — 는 사라졌습니다. 요청 파라미터가 아닌 도구 어댑터 계층에서 도구 호출 상한을 강제하세요.
  • max_concurrent_subagents가 비용 상한이라고 가정. 이는 한 순간의 활성 서브에이전트를 제한하지, 요청 전반에 걸쳐 스폰된 총합을 제한하지 않습니다. 단일 Ultra 호출은 수십 개의 서브에이전트를 순차적으로 스폰하면서도 max_concurrent_subagents: 3 제한을 존중할 수 있습니다. 비용이 상한이라면, 요청 수준 max_output_tokens를 추가하세요.

"네이티브 멀티 에이전트"가 아닌 것​

두 가지 인접 프리미티브가 종종 이와 혼동됩니다.

  • n > 1 샘플링이 아닙니다. OpenAI의 이전 n 파라미터는 여러 컴플리션을 샘플링하고 모두 반환합니다. 그중 하나를 선택합니다. 멀티 에이전트는 다른 작업을 하는 다른 서브에이전트를 실행하고 그 출력을 종합합니다. 전자는 온도 샘플링이고, 후자는 작업 분해입니다.
  • 배치 추론이 아닙니다. 배치 API는 백그라운드에서 여러 독립적인 요청을 처리합니다. 멀티 에이전트는 하나의 인터랙티브 요청 내부에 있는 여러 조율된 서브에이전트입니다. 배치는 처리량 지향이고, 멀티 에이전트는 결과 지향입니다.

향후 방향​

A2A 프로토콜(참조: A2A: 에이전트 간 프로토콜)은 벤더 간 멀티 에이전트를 다룹니다. multi_agent.enabled: true는 모델 내부 멀티 에이전트를 다룹니다. 채워지지 않은 슬롯은 크로스 벤더 프리미티브입니다 — 벤더 A의 모델이 벤더 B의 서브에이전트를 스폰하고 결과를 병합하는 것 — 이에 대한 공개 사양은 아직 없습니다. 도착한다면 어느 쪽의 새로운 API가 아니라 A2A + 네이티브 핸드오프 동사로 도착할 것입니다. 그 공간을 주시하세요.

Check yourself

0/4
  1. Responses 멀티 에이전트 베타에서 max_concurrent_subagents는 무엇을 제한합니까?
  2. 멀티 에이전트를 활성화했는데 모니터링 대시보드가 갑자기 추론 요약 필드를 비어있게 표시합니다. 무엇이 일어났나요?
  3. 두 벤더에 걸쳐 서로 다른 고객 계정에서 실행되는 병렬 서브에이전트가 필요합니다. 어떤 프리미티브가 정확합니까?
  4. 다음 중 Ultra Mode / multi_agent.enabled에 적합하지 않은 후보는 무엇입니까?
아직 카드가 없습니다 — 추가해서 학습을 시작하세요. 🃏

출처 및 추가 자료​