Multi-agent Responses API 활용법: PR 리뷰와 코드베이스 탐색을 병렬화하는 기준

요약: Multi-agent 기능은 하나의 루트 모델이 여러 subagent를 병렬로 실행하고 결과를 종합하게 한다. PR 리뷰, 대형 코드베이스 탐색, 원인 후보 조사처럼 독립 작업으로 나뉘는 문제에는 유용하지만, 공유 상태를 동시에 수정하는 작업에는 위험하다.

Multi-agent가 필요한 상황

개발 자동화에서 가장 오래 걸리는 구간은 모델의 문장 생성이 아니라 탐색이다. 큰 코드베이스에서 인증 로직, 결제 로직, 테스트 헬퍼, 배포 설정을 모두 확인해야 한다면 한 에이전트가 순서대로 훑는 동안 시간이 길어진다. 컨텍스트도 섞인다. 인증에서 본 내용을 결제 판단에 과하게 끌고 오거나, 테스트 파일을 읽다가 원래 목적을 잊는 일이 생긴다.

OpenAI의 Responses API Multi-agent beta는 이 문제를 병렬 작업으로 풀도록 설계됐다. 루트 에이전트가 하위 에이전트를 만들고, 각 에이전트가 독립된 작업을 수행한 뒤, 루트가 결과를 종합한다. 문서에 따르면 GPT-5.6 모델에서 사용할 수 있고, 기본 max_concurrent_subagents는 3으로 권장된다.

실무적으로는 “AI에게 팀을 붙인다”는 표현보다 “컨텍스트 충돌을 줄이고 독립 탐색을 동시에 돌린다”는 표현이 정확하다. 모든 작업이 빨라지는 것은 아니다. 병렬화 가능한 작업만 빨라진다.

PR 리뷰에 잘 맞는 이유

PR 리뷰는 Multi-agent의 좋은 예시다. 하나의 diff를 보고도 관점이 나뉜다.

• correctness: 실제 로직이 요구사항을 만족하는가
• security: 권한, 입력 검증, 민감정보 노출 문제가 있는가
• tests: 실패할 수 있는 경로를 테스트했는가
• maintainability: 변경이 과하게 복잡하거나 중복을 늘리는가

이 관점들은 어느 정도 독립적이다. 보안 리뷰어가 테스트 누락을 모두 볼 필요는 없다. 테스트 리뷰어가 인증 위협 모델 전체를 기억할 필요도 없다. 각각 다른 subagent에 맡기면 컨텍스트가 좁아지고, 루트가 마지막에 중복과 충돌을 정리하면 된다.

중요한 것은 subagent에게 “좋은 리뷰 해줘”라고 맡기지 않는 것이다. 각 agent의 범위를 파일, 관점, 출력 형식으로 제한해야 한다. 예를 들어 security agent는 인증, 인가, 입력 검증, 비밀값 노출만 보고, 결과는 severity, file, line, evidence, fix suggestion 형식으로 내게 한다. 이렇게 해야 루트가 결과를 병합할 수 있다.

코드베이스 탐색에서는 파일 소유권을 나눠라

대형 코드베이스 조사에도 유용하다. 예를 들어 “로그인 후 결제 페이지에서 403이 나는 원인”을 찾는다고 하자. 한 에이전트가 전체를 보면 인증 미들웨어, 라우팅, API handler, 프론트 상태 관리, 배포 환경 변수를 모두 순서대로 봐야 한다.

Multi-agent 방식에서는 다음처럼 나눌 수 있다.

1. 인증과 세션 처리 담당
2. 결제 API와 권한 검사 담당
3. 프론트 라우팅과 상태 전달 담당
4. 테스트와 최근 변경 이력 담당

각 agent는 자신의 영역만 깊게 본다. 루트는 마지막에 “403을 만드는 가장 가능성 높은 경로”를 정리한다. 이 방식은 탐색 범위가 넓을수록 효과가 있다.

다만 파일을 동시에 수정하게 하면 문제가 생긴다. 여러 agent가 같은 파일을 바꾸면 충돌이 생기고, 서로의 가정을 모른 채 수정할 수 있다. 따라서 탐색은 병렬, 수정은 직렬이 안전하다. 먼저 각 agent가 근거와 제안을 내고, 루트 또는 별도 구현 단계가 하나의 패치 계획으로 합쳐야 한다.

쓰면 안 되는 경우

Multi-agent는 만능 가속기가 아니다. 다음 상황에서는 오히려 손해다.

첫째, 작업이 작다. 작은 버그 하나를 고치는 데 subagent 3개를 띄우면 조율 비용이 더 크다. 둘째, 단계 의존성이 강하다. 앞 단계 결과가 나와야 다음 단계가 결정되는 마이그레이션 작업은 병렬화가 어렵다. 셋째, 공유 상태 변경이 많다. 여러 agent가 같은 DB 스키마, 같은 파일, 같은 배포 설정을 동시에 바꾸면 검증이 복잡해진다.

또 하나는 토큰 비용이다. subagent는 각자 컨텍스트와 출력을 갖는다. 벽시계 시간은 줄어도 전체 토큰은 늘 수 있다. 따라서 사용자 대기 시간이 중요한 작업인지, 품질 향상이 비용을 정당화하는지 봐야 한다.

운영 설계: root는 관리자, subagent는 전문가

루트 에이전트의 역할은 직접 모든 것을 해결하는 것이 아니다. 작업을 나누고, 중간 결과를 받고, 충돌을 해소하고, 최종 답을 만드는 관리자 역할이다. subagent는 특정 관점만 깊게 보는 전문가다.

프롬프트도 이 역할에 맞춰야 한다. 루트에는 다음을 지시한다.

• 작업을 독립 workstream으로 나눌 수 있을 때만 subagent를 사용한다.
• subagent별 범위와 산출물 형식을 명확히 지정한다.
• 같은 파일 수정은 동시에 맡기지 않는다.
• 결과가 충돌하면 근거가 강한 쪽을 선택하고 불확실성을 표시한다.
• 최종 답변에는 중복을 제거하고 우선순위를 붙인다.

subagent에는 더 좁은 지시를 준다. “이 diff에서 security 이슈만 찾아라. 스타일 의견은 제외한다. 각 항목은 file, line, risk, evidence, suggested fix로 작성하라”처럼 제한한다.

실행 체크리스트

• 작업이 독립된 2개 이상 workstream으로 나뉘는지 확인한다.
• max_concurrent_subagents는 기본 3에서 시작한다.
• 각 subagent에 관점, 파일 범위, 제외할 항목, 출력 스키마를 지정한다.
• 탐색과 분석은 병렬로 돌리되 실제 파일 수정은 하나의 계획으로 합친다.
• 결과 병합 시 중복 제거, 충돌 표시, severity 정렬을 강제한다.
• 토큰 비용과 전체 완료 시간을 함께 측정한다.
• 작은 작업에는 Multi-agent를 쓰지 않는 기준을 둔다.
• PR 리뷰에서는 correctness, security, tests처럼 관점을 분리한다.

Multi-agent의 가치는 에이전트 수가 많다는 데 있지 않다. 복잡한 작업을 서로 간섭하지 않는 작은 조사 단위로 나누고, 마지막에 사람이 읽을 수 있는 하나의 판단으로 합치는 데 있다.