GPT-6.1 Sol Multi-Agent: Subagent를 늘리면 정말 더 잘할까?

GPT-6.1 Sol에는 눈에 잘 띄지 않지만 꽤 중요한 기능이 하나 같이 들어왔습니다.

Responses API의 Multi-agent beta입니다.

한 모델이 모든 일을 순서대로 처리하는 대신 root agent가 필요할 때 subagent를 만들고 일을 나눌 수 있습니다.

그림으로 보면 간단합니다.

Single Agent

Task
 ↓
Agent
 ↓
조사
 ↓
분석
 ↓
구현
 ↓
검토
 ↓
완료

Multi-Agent에서는:

                    ┌→ Researcher
Task → Root Agent ──┼→ Implementer
                    └→ Reviewer
                         ↓
                    결과 취합
                         ↓
                     Final

가 됩니다.

하지만 여기서 바로 이런 결론을 내리면 위험합니다.

"Agent를 세 개 쓰면 세 배 빨라지겠네."

실제로는 그렇지 않을 수 있습니다.

Multi-Agent가 좋은 작업에는 조건이 있습니다

핵심은 독립적으로 나눌 수 있는가입니다.

예를 들어 Pull Request review는 꽤 잘 나눌 수 있습니다.

Agent A
정확성 / bug

Agent B
Security

Agent C
Missing tests

셋이 같은 diff를 보더라도 서로 기다릴 필요가 적습니다.

반대로 이런 작업은 병렬화가 어렵습니다.

1. API 설계
2. 1의 결과를 사용해 DB schema 설계
3. 2의 결과를 사용해 migration 작성

앞 단계 결과가 다음 단계 입력이므로 subagent를 여러 개 띄워도 기다리는 시간이 생깁니다.

즉 Multi-Agent가 유리한 조건은:

Parallelizable
+
결과를 나중에 합칠 수 있음

입니다.

OpenAI의 Multi-agent는 Root가 조정합니다

Responses API 문서에서는 최상위 agent를 /root라고 부릅니다.

subagent가 만들어지면 이런 hierarchical path를 가질 수 있습니다.

/root
├── /root/researcher
├── /root/reviewer
└── /root/reviewer/tester

subagent도 다시 자신의 subagent를 만들 수 있습니다.

즉 단순한 "3개의 API 요청"보다 agent tree에 가깝습니다.

root agent는 작업을 분해하고, subagent 결과를 받아 충돌이나 중복을 정리한 뒤 최종 답을 만듭니다.

Responses API에서는 기본 동시 Subagent 수가 3입니다

현재 Responses API Multi-agent beta에서 max_concurrent_subagents의 기본값은 3입니다.

예시는 다음처럼 생겼습니다.

from openai import OpenAI

client = OpenAI()

response = client.beta.responses.create(
    model="gpt-6.1-sol",
    input="""
    이 PR을 세 관점에서 리뷰해줘.
    1. correctness
    2. security
    3. missing tests

    중복 의견은 합치고,
    마지막에는 우선순위 순으로 정리해줘.
    """,
    multi_agent={
        "enabled": True,
        "max_concurrent_subagents": 3,
    },
    betas=["responses_multi_agent=v1"],
)

이 코드는 현재 beta 문서를 이해하기 위한 축약 예입니다.

beta API이므로 실제 적용 전에는 최신 SDK와 문서를 다시 확인하는 편이 좋습니다.

Agent를 늘리면 비용도 같이 늘어납니다

병렬 처리의 가장 쉬운 함정입니다.

Single Agent라면:

Context
→ 한 번 분석
→ 한 번 답

Multi-Agent에서는 같은 context가 여러 agent에 들어갈 수 있습니다.

              ┌→ Context + reasoning A
Shared input ─┼→ Context + reasoning B
              └→ Context + reasoning C

                + Root synthesis

즉 wall-clock time은 줄어도 token 사용량은 늘 수 있습니다.

그래서 비교할 지표는 최소 네 개가 필요합니다.

Quality
Time
Tokens
Cost

"더 빨랐다"만 보면 절반만 본 것입니다.

중복 작업도 비용입니다

세 Agent에게 역할을 정확히 나누지 않으면 이런 일이 생깁니다.

Agent A: 전체 repo 조사
Agent B: 전체 repo 조사
Agent C: 전체 repo 조사

병렬화는 됐지만 같은 일을 세 번 했습니다.

좋은 분할은:

A → auth 모듈
B → billing 모듈
C → test / integration

처럼 범위가 겹치지 않게 하거나,

A → correctness
B → security
C → test coverage

처럼 같은 대상을 서로 다른 관점으로 보게 합니다.

이것이 task decomposition이 중요한 이유입니다.

CodeBridge Mini Lab: Single vs 3-Agent PR Review

가장 간단한 비교 실험입니다.

실제 PR diff 하나를 준비합니다.

A. Single Agent

이 PR을 리뷰하고
bug, security issue, missing test를 찾아줘.

B. Multi-Agent

세 역할로 나눠 리뷰해줘.

1. correctness
2. security
3. missing tests

각 결과의 중복을 제거하고
심각도 순으로 정리해줘.

그리고 세 번씩 반복합니다.

mode,run,valid_findings,false_positives,time_sec,input_tokens,output_tokens,cost
single,1,6,2,80,0,0,0
single,2,5,1,73,0,0,0
multi,1,8,2,55,0,0,0
multi,2,7,3,49,0,0,0

비교할 질문은 다음입니다.

1. 실제로 더 많은 유효 문제를 찾았는가?
2. false positive가 늘었는가?
3. wall-clock time은 줄었는가?
4. 총 token / 비용은 얼마나 늘었는가?
5. 세 run에서 결과가 일관적인가?

Multi-Agent가 좋다면 "Agent가 많아서"가 아니라 내 task가 잘 분해됐기 때문이어야 합니다.

모든 Subagent가 같은 도구를 가진다는 점도 고려해야 합니다

Responses API Multi-agent에서는 root와 subagent들이 같은 tool set에 접근할 수 있습니다.

편리하지만 permission 측면에서는 생각할 점이 있습니다.

Reviewer에게도 write tool이 필요한가?
Researcher에게 shell write 권한이 필요한가?

가능하다면 역할 자체를 명확히 주고, 실제 애플리케이션의 중요한 side effect에는 별도의 permission boundary를 두는 편이 좋습니다.

Multi-Agent는 작업 분해 기능이지 자동으로 최소 권한을 설계해주는 기능은 아닙니다.

Context도 Agent별로 따로 관리됩니다

현재 Multi-agent가 켜지면 server-side compaction이 root와 각 subagent context에 독립적으로 적용됩니다.

장기 작업에서 이것은 중요한 특징입니다.

/root context

/root/researcher context

/root/reviewer context

가 완전히 같은 history를 무한히 공유하는 구조가 아니라, agent별로 자신의 작업 문맥을 유지합니다.

반대로 현재 beta에는 제약도 있습니다.

예를 들어 Multi-agent 사용 시:

reasoning.summary 미지원
max_tool_calls 미지원
/responses/compact endpoint 직접 사용 미지원

같은 제한이 있습니다.

beta 기능은 production architecture에 넣기 전에 이런 제약을 먼저 확인해야 합니다.

Multi-Agent와 Graph Engineering은 자연스럽게 연결됩니다

에이전트 수가 늘어나면 곧 이런 질문이 생깁니다.

누가 먼저 실행되는가?
누가 누구에게 결과를 넘기는가?
실패하면 어디로 돌아가는가?
두 의견이 충돌하면 누가 결정하는가?

이 순간부터 단순 prompt 문제가 아니라 graph 문제가 됩니다.

Planner
  ├─ Researcher A
  ├─ Researcher B
  └─ Implementer
          ↓
       Reviewer
       ↙      ↘
    pass      fail
     ↓         ↓
    end    Implementer

Multi-Agent에서 중요한 능력은 모델을 여러 개 부르는 방법보다 이 흐름을 설계하는 능력입니다.

결론: Subagent 수가 아니라 Task Decomposition을 먼저 보세요

GPT-6.1 Sol의 Multi-agent beta는 API 레벨에서 agent delegation을 훨씬 쉽게 사용할 수 있게 만들었습니다.

하지만 좋은 결과를 만드는 공식이:

Agent 1개
→ 3개
→ 10개
→ 더 좋음

은 아닙니다.

오히려 다음이 더 가깝습니다.

좋은 작업 분해
+
적절한 병렬성
+
명확한 역할
+
중복 제거
+
최종 검증
=
유용한 Multi-Agent

처음에는 agent 수를 늘리는 대신 한 작업을 독립적인 두세 조각으로 정확히 나눌 수 있는지부터 확인하는 편이 좋습니다.

그게 안 된다면 Single Agent가 더 싸고, 더 단순하고, 더 안정적일 수 있습니다.

참고 자료

이 주제를 직접 따라가며 배우고 싶다면

Multi-Agent에서 핵심은 에이전트 수가 아니라 작업을 나누고, 결과를 합치고, 실패 경로를 다시 연결하는 하네스·루프·그래프 설계입니다. 이 구조를 실습 중심으로 이어가고 싶다면 아래 강의가 가장 가깝습니다.

하네스·루프·그래프 엔지니어링 강의 보기