풀 리퀘스트(Pull Request, PR)는 하나의 코딩 에이전트가 제대로 검사하기에는 너무 방대할 수 있지만, 군집(Swarm)을 추가한다고 해서 자동으로 더 안전해지는 것은 아닙니다. 병렬 에이전트는 실제 소요 시간(Wall-clock time)을 줄이고 관련 없는 컨텍스트(Context)를 분리할 수 있습니다. 하지만 토큰 소비, 도구 권한, 중복된 결과 발견, 그리고 쓰기 충돌(Write conflicts)을 배가시킬 수도 있습니다.

OpenAI의 새로운 GPT-5.6 멀티 에이전트(Multi-agent) 베타는 유용한 강제 기능(Forcing function) 역할을 합니다. 이는 루트 에이전트(Root agent)가 Responses API에서 하위 에이전트(Subagents)를 조정할 수 있게 해주지만, 프로덕션(Production) 결정은 여전히 사용자의 몫입니다. 진짜 질문은 "에이전트를 생성할 수 있는가?"가 아니라, "이 작업이 독립적이고 경계가 명확한 증거 수집 작업으로 분할되는가?"입니다.

좋은 첫 번째 사용 사례: 읽기 전용 PR 리뷰

에이전트가 저장소(Repository)를 수정하지 않는 풀 리퀘스트부터 시작하십시오. 세 명의 리뷰어에게 서로 다른 증거 계약(Evidence contracts)을 부여하십시오:

이러한 분할은 워크스트림(Workstreams)이 독립적이고 각 전문가가 집중된 컨텍스트를 유지할 수 있기 때문에 가치가 있습니다. 엄격한 순서에 의존하는 마이그레이션, 작은 패치, 또는 여러 에이전트가 동일한 브랜치에 쓰기를 수행하는 워크플로우에는 적합하지 않습니다. OpenAI의 멀티 에이전트 가이드에서도 동일한 구분을 하고 있습니다. 경계가 있고 독립적인 작업에는 멀티 에이전트를 사용하고, 순차적인 추론이나 공유된 가변 리소스(Shared mutable resources)가 필요한 경우에는 단일 에이전트를 선호하십시오.

최종 답변을 위한 단일 소유자 유지

루트 에이전트는 발견된 사항들을 종합(Synthesize), 중복 제거(Deduplicate) 및 순위 지정(Rank)해야 합니다. 하위 에이전트는 증거 수집가(Evidence collectors)이지, 자율적인 승인자(Autonomous approvers)가 아닙니다.

response = client.beta.responses.create(
    model="gpt-5.6-sol",
    input=(
...

이는 문서화된 API 형태를 따릅니다. 기본 권장 동시성 (concurrency)은 3이며, 제한 사항은 에이전트 트리 내의 하위 요소(descendants)를 포함하지만 루트(root)는 포함하지 않습니다. 또한 베타 버전에서는 트리의 모든 에이전트가 요청에 대해 구성된 도구 (tools)에 접근할 수 있는 권한을 부여합니다. 이것이 바로 권한 범위 (permission scope)가 막연한 프롬프트 (prompt)가 아닌 요청 설계 단계에서 다뤄져야 하는 이유입니다.

병렬 처리에 예산 설정하기

GPT-5.6의 출시와 함께 매력적인 헤드라인이 추가되었습니다. 바로 ultra 모드가 기본적으로 4개의 에이전트를 병렬로 조정한다는 점입니다. 하지만 병렬 처리는 지연 시간 (latency)과의 트레이드오프 (trade-off)이지, 공짜로 얻는 기능이 아닙니다. OpenAI는 서브 에이전트 (subagents)가 토큰 사용량을 증가시킬 수 있으며, 작업이 가변 상태 (mutable state)를 공유하거나 하나의 느린 외부 작업에 의해 지배되는 경우에는 도움이 되지 않을 수 있다고 명시적으로 언급했습니다.

기능을 활성화하기 전에 작은 예산 범위 (budget envelope)를 사용하세요:

적격 작업?       독립적 + 읽기 전용 + 증거 중심
동시성 (concurrency)          리뷰어 3명, 루트 1명
도구 정책 (tool policy)          저장소 읽기, 테스트 러너; 배포/쓰기 도구 제외
...

단순한 토큰 비용만이 아니라, **수락된 발견 사항 (accepted finding)**당 비용과 개발자가 실제로 사용하는 리뷰까지 걸리는 시간을 추적하세요. GPT-5.6 Sol은 입력 토큰 100만 개당 $5, 출력 토큰 100만 개당 $30로 책정되어 있으며, 캐시된 입력 (cached input)은 100만 개당 $0.50입니다. 272K 입력 토큰을 초과하는 긴 문맥 프롬프트 (long-context prompts)는 더 높은 가격이 책정되므로, 모든 에이전트에게 저장소 전체를 무작정 넘겨주는 것은 기대했던 효율성 이득을 상쇄할 수 있습니다. 현재 제한 사항 및 가격은 GPT-5.6 Sol 모델 페이지를 참조하세요.

하네스 (harness) 설계를 변경하게 만드는 제한 사항들

이것은 베타 기능이며, 광범위한 배포 전에 테스트해 볼 가치가 있는 까다로운 부분들이 있습니다:

• Multi-agent 기능이 활성화된 경우 max_tool_calls 및 reasoning.summary는 지원되지 않습니다.
• 서버 측 압축 (Server-side compaction)이 암시적으로 활성화되며, 루트 (root) 및 하위 에이전트 (subagent) 컨텍스트에 각각 별도로 적용됩니다.
• 단순한 실행에는 HTTP를 사용할 수 있지만, OpenAI는 도구 (tool) 사용이 많거나 실행 시간이 긴 작업의 경우 함수 결과가 도착하는 즉시 주입될 수 있는 WebSocket 사용을 권장합니다.
• API는 하위 에이전트의 총 개수나 깊이 (depth)에 대한 고정된 제한을 두지 않으므로, 의도적인 동시성 제한 (concurrency cap)을 설정하고 추적 (trace) 과정에서 에이전트 트리 (agent tree)를 캡처해야 합니다.

모델 출시와 함께 프로그래밍 방식의 도구 호출 (Programmatic Tool Calling)도 도입되었으며, 이는 중간 도구 데이터를 모델로 반환하기 전에 처리할 수 있습니다. 이를 통해 불필요한 컨텍스트 (context)를 줄일 수 있지만, 최소 권한 도구 정책 (least-privilege tool policy)이나 검토 가능한 감사 추적 (audit trail)을 대체할 수는 없습니다.

지금 해야 할 일

1. 자율 코딩 워크플로우가 아닌, 읽기 전용 (read-only) PR 리뷰 워크플로우를 하나 선택하세요.
2. 중복되지 않는 세 개의 리뷰어 계약 (reviewer contracts)과 하나의 루트 소유자 (root-owner) 계약을 정의하세요.
3. max_concurrent_subagents: 3으로 시작하세요. 입력값, 도구 호출 (tool calls), 에이전트 경로 (agent paths), 토큰 사용량, 경과 시간, 그리고 수락된 결과물 (accepted findings)을 기록하세요.
4. 5개에서 10개의 대표적인 PR을 대상으로 단일 에이전트 (single-agent) 기준점 (baseline)과 비교하세요.
5. 제한된 비용 범위 내에서 수락된 결과물이나 처리 시간 (turnaround time)이 개선되는 경우에만 이를 도입하세요.

해당 파일럿 테스트에서 발생한 실패 사례를 지속 가능한 커버리지로 전환할 방법이 필요하다면, 이 trace-to-regression testing playbook을 사용하세요. 동일한 원칙이 팀 설계에도 적용됩니다. 공유 컨텍스트 (shared context)가 더 많은 서브 에이전트 (subagents)보다 유리한 경우에 관한 당사의 이전 가이드는 무조건적으로 작업자 (workers)를 추가하는 것에 대한 유용한 대조점이 됩니다. 그리고 더 많은 도구 (tool) 액세스를 활성화하기 전에, Claude Code의 7월 프로덕션 에이전트 체크리스트 (production-agent checklist)에 담긴 운영상의 교훈을 검토하십시오.

Sources

• OpenAI: GPT-5.6 launch
• OpenAI: Multi-agent in the Responses API
• OpenAI: GPT-5.6 Sol model, pricing, and limits
• OpenAI: Programmatic Tool Calling

병렬 리뷰 (parallel review)가 귀하의 팀에 가장 도움이 될 분야는 어디인가요: 정확성 (correctness), 보안 (security), 테스트 설계 (test design), 아니면 다른 무엇인가요?