서브에이전트로 병렬 처리하기

다섯 곳을 차례로 조사하면 다섯 배가 걸린다

진출 검토 중인 국가 다섯 곳의 규제 현황을 정리해야 한다. 각 나라는 서로 관계가 없다. 그런데 한 대화에서 순서대로 처리하면 다섯 번의 조사가 줄줄이 이어지고, 게다가 다섯 나라의 검색 기록과 중간 메모가 같은 대화에 전부 쌓인다. 마지막에 비교 문서를 쓸 때쯤이면 정작 중요한 요구사항이 그 잡음 아래 묻혀 있다.

서브에이전트(subagents)는 이 두 문제를 동시에 다룬다. 독립적인 일을 갈라서 동시에 처리하고, 각자의 중간 과정은 자기 갈래에 남기고 요약만 본 대화로 돌려보낸다.

서브에이전트 워크플로란

공식 문서의 정의는 이렇다. ChatGPT Work와 Codex는 특화된 에이전트를 병렬로 띄우고 그 결과를 하나의 응답으로 모으는 서브에이전트 워크플로를 실행할 수 있다. 용어 세 개를 구분해 두면 화면을 읽기 쉽다.

용어	뜻
서브에이전트 워크플로(subagent workflow)	병렬 에이전트를 돌리고 결과를 합치는 작업 방식 전체
서브에이전트(subagent)	특정 일을 맡기려고 시작된 위임 에이전트 하나
에이전트 스레드(agent thread)	서브에이전트가 일하는 갈래. 지원되는 화면에서 열어 진행과 결과를 볼 수 있다

ChatGPT Work에서는 독립적인 일을 서브에이전트에게 위임해 달라고 요청한다. 에이전트는 ChatGPT의 호스팅 환경에서 돌아가고, 대화에 그 활동과 결과가 표시된다. 대부분의 지능 수준(intelligence level)에서는 명시적으로 위임을 요청해야 한다. Ultra에서는 병렬 에이전트가 속도나 품질을 실질적으로 개선할 때 ChatGPT가 알아서 위임할 수 있다. Ultra는 자격을 갖춘 계정과 지원되는 모델에서만 제공된다.

오케스트레이션은 ChatGPT가 맡는다. 새 서브에이전트를 띄우고, 후속 지시를 전달하고, 결과를 기다리고, 끝난 스레드를 닫는 일이 여기 포함된다. 여러 에이전트가 돌고 있으면 요청된 결과가 모두 준비될 때까지 기다린 다음 통합된 응답을 돌려준다.

AI 생성 교육용 도해. 정확한 기능 조건과 세부 절차는 이 챕터의 본문 및 공식 참고 자료를 함께 확인한다

본 대화로 올라오는 것은 각 갈래의 검색 기록이나 중간 메모가 아니라 정리된 요약이다. 이게 서브에이전트의 절반짜리 가치다.

왜 도움이 되는가: 잡음을 본 대화에서 치운다

공식 문서는 컨텍스트 창이 커도 모델에 한계가 있다고 전제한 뒤 두 가지 실패 양상을 이름 붙여 설명한다.

• 컨텍스트 오염(context pollution): 쓸모 있는 정보가 잡음 섞인 중간 산출물 아래 묻힌다.
• 컨텍스트 부식(context rot): 덜 관련된 세부 내용으로 대화가 차면서 성능이 떨어진다.

서브에이전트는 잡음을 본 스레드 밖으로 옮겨서 이를 완화한다. 문서가 제시하는 구조는 세 줄로 요약된다. 본 에이전트는 요구사항·결정·최종 산출물에 집중하고, 탐색·확인·분석 같은 일은 특화된 서브에이전트가 병렬로 하고, 서브에이전트는 원문 대신 요약을 돌려준다.

시간도 절약된다. 그리고 큰 덩어리 작업을 경계가 명확한 조각으로 쪼개서 다루기 쉽게 만든다. 문서는 수백만 토큰 규모 문서의 분석을 작은 문제들로 나눠 정제된 시사점만 본 스레드로 돌려보내는 예를 든다.

언제 도움이 되고, 언제 해로운가

여기서 판단 기준이 하나 나온다. 공식 문서의 출발점 조언은 읽기 중심(read-heavy) 작업에 병렬 에이전트를 쓰라는 것이다. 탐색, 확인, 분류(triage), 요약이 그 예다. 반대로 쓰기 중심(write-heavy) 병렬 작업은 더 조심해야 한다. 여러 에이전트가 동시에 같은 대상을 고치면 충돌이 생기고 조율 비용이 늘어난다.

상황	병렬이 맞나	이유
국가·지역별 규제 현황 조사	맞다	서로 독립적인 읽기 작업이다
경쟁사 5곳의 최근 동향 정리	맞다	한 곳의 결과가 다른 곳에 영향을 주지 않는다
정책 문서 40건에서 충돌 조항 찾기	맞다	문서 묶음별로 나눠 읽고 요약만 모으면 된다
하나의 보고서 본문을 여러 갈래가 동시에 집필	아니다	같은 결과물을 고치므로 충돌한다
앞 단계 결론이 있어야 다음이 시작되는 작업	아니다	순서가 있으면 병렬 이득이 없다
짧은 단일 질문	아니다	오히려 토큰만 더 쓴다

비용도 판단에 넣어야 한다. 각 서브에이전트가 자기 모델 작업과 도구 작업을 하기 때문에, 서브에이전트 워크플로는 같은 일을 단일 에이전트로 하는 것보다 토큰을 더 쓴다. 공식 문서가 두 번 반복해서 밝히는 사실이다. 조사 다섯 갈래를 병렬로 돌리면 시간은 줄지만 소비는 늘어난다. 시간이 아까운 일에 쓰고, 급하지 않은 일에는 쓰지 않는다.

화면으로 보기

사이드바의 여러 대화는 서로 독립된 작업이다. 서브에이전트는 이와 달리 하나의 대화 안에서 갈라져 결과를 다시 합친다 · 출처: OpenAI 공식 문서

이 화면은 작업을 대화 단위로 나눈 모습이다. 병렬로 일하는 방법이 두 가지라는 점을 구분해 두면 좋다.

• 대화를 여러 개 연다: 각 대화가 자기 컨텍스트와 결과를 갖는다. 결과를 합치는 것은 사람이 한다.
• 서브에이전트를 쓴다: 하나의 대화 안에서 갈라지고, 합치는 것은 ChatGPT가 한다.

최종 결과물이 하나라면 서브에이전트가, 완전히 별개의 산출물 여러 개라면 별도 대화가 낫다.

ChatGPT Work 웹에서는 Subagents 항목을 열어 Active와 Done 목록을 볼 수 있다. 이 목록은 읽기 전용이다. 끝난 서브에이전트를 선택하면 세부 내용과 결과를 확인할 수 있지만, 개별 서브에이전트를 멈추거나 조종하는 제어는 웹 사이드바에서 제공되지 않는다. 데스크톱 앱은 본 스레드에 표시된 활동에서 서브에이전트 스레드를 열어 볼 수 있고, ChatGPT에게 직접 요청해 멈추거나 조종할 수 있다.

권한은 어떻게 적용되나

ChatGPT Work는 서브에이전트를 자체 호스팅 환경에서 돌리고, 로컬 샌드박스나 승인 모드 제어를 노출하지 않는다. 서브에이전트는 부모 대화가 쓸 수 있는 도구를 사용한다. 웹사이트와 커넥터 권한은 도구별로 그대로 유지된다. 즉 위임한다고 접근 범위가 넓어지지 않는다. 데스크톱 앱에서는 서브에이전트가 컴포저 아래에서 선택한 권한 모드를 물려받으므로, 위임을 요청하기 전에 부모 턴의 권한 모드를 먼저 정한다.

해보기

좋은 위임 프롬프트의 세 조각

공식 문서가 제시하는 기준은 명확하다. 좋은 서브에이전트 프롬프트는 일을 어떻게 나눌지, 모든 에이전트를 기다려야 하는지, 어떤 요약이나 산출물을 돌려줄지를 설명한다.

트리거 방식도 문서에 그대로 나와 있다. “에이전트 두 개를 띄워라”, “이 일을 병렬로 위임해라”, “항목마다 에이전트 하나씩 써라” 같은 직접적인 지시를 쓴다.

  ① 어떻게 나누나  →  기준을 명시 (국가별 / 경쟁사별 / 문서 묶음별)
  ② 기다리나        →  전부 끝난 뒤 합치나, 먼저 온 것부터 보나
  ③ 무엇을 돌려주나 →  항목별 요약? 표 한 장? 출처 포함?

시장별로 나누기

시장별로 갈래를 나누는 위임 프롬프트다.

[제품명]의 진출 검토를 위해 다음 5개 시장을 조사해 달라.
[시장1], [시장2], [시장3], [시장4], [시장5]

시장마다 서브에이전트 하나씩 병렬로 띄워 달라.
각 에이전트는 같은 항목을 채워 달라.
- 관련 규제와 최근 6개월 변화
- 주요 경쟁 사업자 2~3곳
- 진입 시 예상되는 걸림돌

다섯 개가 모두 끝난 뒤에, 시장을 행으로 하고 위 세 항목을 열로 하는
비교표 한 장으로 합쳐 달라. 모든 수치에는 출처를 붙여 달라.

관점별로 나누는 방식도 유용하다. 같은 자료를 서로 다른 눈으로 읽게 한다.

첨부한 [계약서 또는 제안서]를 세 관점에서 동시에 검토해 달라.
에이전트 하나는 비용과 정산 조건, 하나는 일정과 책임 범위,
하나는 해지·분쟁 조항만 본다.

셋 다 끝날 때까지 기다린 다음, 관점별로 나눠 발견 사항을 정리해 달라.
각 항목에 문서의 해당 조항 번호를 표시해 달라.
판단이 갈리는 부분은 "확인 필요"로 남기고 임의로 결론 내지 말아 달라.

문서가 많을 때는 묶음으로 나눈다.

첨부한 사내 정책 문서 [N]건에서 서로 충돌하는 조항을 찾아 달라.
문서를 [M]개 묶음으로 나눠 서브에이전트에게 병렬로 읽게 하고,
각 에이전트는 원문을 그대로 올리지 말고 요약만 돌려 달라.

마지막에 충돌 후보를 표로 정리해 달라. 열은 다음과 같다.
쟁점 · 충돌하는 문서와 조항 · 어느 쪽이 최신인지 · 확인이 필요한 이유

커스텀 에이전트(custom agents)는 어디까지 알면 되나

로컬 Codex 클라이언트에서는 작업 종류마다 다른 모델 설정과 지시를 갖는 커스텀 에이전트를 직접 정의할 수 있다. 기본 제공되는 에이전트는 범용 default, 실행 중심 worker, 읽기 중심 탐색용 explorer 세 가지다.

정의 방식은 설정 파일을 다루는 개발자용 작업이라 이 강의의 범위를 넘는다. 비개발 업무에서 기억할 것은 하나다. 에이전트마다 역할을 좁게 잡는 것이 좋다. 공식 문서의 표현대로, 좋은 커스텀 에이전트는 좁고 분명한 성격을 가진다. 프롬프트로 위임할 때도 같은 원칙이 적용된다. “알아서 나눠 달라”보다 “시장마다 하나”가 낫다.

기능 가용성은 플랜·플랫폼·지역·롤아웃·워크스페이스 설정에 따라 다르다. 서브에이전트 워크플로와 그 활동 표시는 자격을 갖춘 계정에 제공되며, Ultra 지능 수준에서의 자동 위임은 지원되는 모델에서만 동작한다.

정리

• 서브에이전트 워크플로는 독립적인 일을 병렬로 처리하고 결과를 하나의 응답으로 합친다.
• 본 대화에는 원문 대신 요약이 올라온다. 덕분에 컨텍스트 오염과 부식을 줄인다.
• 읽기 중심 작업(탐색·확인·분류·요약)에 쓴다. 쓰기 중심 병렬은 충돌 위험이 크다.
• 대부분의 지능 수준에서는 위임을 명시적으로 요청해야 한다.
• 좋은 위임 프롬프트에는 분할 기준, 대기 여부, 반환 형식이 들어간다.
• 단일 에이전트보다 토큰을 더 쓴다. 시간이 아까운 일에 쓴다.

여기까지가 에이전트와 함께 일하는 방식이다. 다음 섹션에서는 그 모든 것의 입력이 되는 프롬프트와 컨텍스트를 정면으로 다룬다.

이해도 점검

퀴즈를 불러오는 중…