기관에서 “주민 대상 AI 교육 제안서를 다음 주까지 준비해 주세요”라는 요청을 받았다고 해봅시다. 기존 강의안과 기관 요구를 찾고, 제안서를 쓰고, 시간표와 예산을 점검해야 합니다. 이 일을 한 AI 에이전트가 모두 맡을 수도 있습니다. 여러 에이전트를 쓴다면 조사, 작성, 검토를 나누고 누가 결과를 합칠지 정해야 합니다. 역할을 늘리는 것보다 인계와 책임을 설계하는 일이 먼저입니다.

멀티 에이전트 시스템은 하나의 목표 아래 여러 에이전트가 하위 과업을 맡는 구조입니다. 관리자 에이전트가 전문 에이전트를 도구처럼 호출해 결과를 돌려받는 방식과, 대화의 주도권을 다른 에이전트에게 넘기는 방식이 있습니다. OpenAI Agents SDK 문서는 이 둘을 대표적인 오케스트레이션 패턴으로 구분합니다. OpenAI Agents SDK, Agent orchestration

교육 제안서 한 건을 세 역할로 나눕니다

가상의 업무를 설계해 보겠습니다. 관리자 에이전트는 기관의 요청문을 읽고 산출물 형식, 마감일, 필수 항목을 정리합니다. 조사 에이전트는 승인된 교육 자료에서 강의 사례와 대상자 특성을 찾습니다. 작성 에이전트는 그 근거를 받아 제안서 초안을 만듭니다. 검토 에이전트는 요청서와 초안을 대조해 빠진 내용과 확인되지 않은 수치를 표시합니다.

관리자기관 요청 → 목적·범위·필수 항목·마감 정리과업 정의
조사승인된 자료 → 근거 목록·원본 링크·기준일자료 반환
작성요청 조건 + 조사 결과 → 강의 구성·일정·제안 문안초안 반환
검토요청서 + 초안 + 근거 → 누락·충돌·확인 필요 항목검토 반환
담당자최종 결과와 미확인 사항 확인 → 수정·제출 결정최종 책임

조사는 기관 요구와 기존 강의 자료를 동시에 살펴볼 수 있지만, 최종 검토는 초안이 나온 뒤에야 할 수 있습니다. 한꺼번에 병렬로 돌리면 빠를 듯해도 작성 에이전트가 아직 확정되지 않은 근거를 추측해 채울 수 있습니다. 필요한 의존 관계를 먼저 그려야 합니다. Anthropic이 공개한 연구 시스템은 관리자와 전문 하위 에이전트를 쓰는 사례이지만, 그 구조를 모든 소규모 업무에 그대로 적용해야 한다는 뜻은 아닙니다. Anthropic, How we built our multi-agent research system

좋은 인계에는 답뿐 아니라 빈칸도 들어갑니다

“조사 끝”이라는 한 줄로 다음 역할에 넘기면 작성자는 무엇을 믿어야 할지 알 수 없습니다. 조사 결과에는 사용한 문서, 최신성, 적용 대상, 인용 가능한 근거, 찾지 못한 항목을 함께 담아야 합니다. 예컨대 “작년 주민 교육 강의안은 찾았지만 올해 예산 단가는 확인되지 않음”이라고 반환하면, 작성 에이전트는 단가를 지어내지 않고 빈칸으로 남길 수 있습니다.

넘길 정보예시필요한 이유
목표와 완료 기준기관용 3쪽 제안서, 요청 항목 모두 포함역할마다 다른 결과물을 만들지 않게 함
근거와 출처강의안 파일명·승인일·원본 링크초안의 사실을 다시 확인할 수 있음
제약과 권한개인정보 제외, 예산 입력은 담당자 확인허용 범위를 넘지 않게 함
불확실성과 실패올해 단가 자료 없음, 기관 대상 연령 불명추측 대신 확인 요청을 남김

관리자형과 인계형은 책임의 위치가 다릅니다

관리자형에서는 하나의 에이전트가 전문 역할을 호출하고 결과를 다시 받아 최종 답변을 만듭니다. 사용자는 같은 창구에서 진행 상황과 결과를 봅니다. 위 제안서 사례처럼 하나의 산출물로 합쳐야 할 때 이해하기 쉽습니다. 인계형은 접수 담당이 전문 담당에게 대화의 주도권을 넘기는 방식입니다. 문의 유형에 따라 다른 전문 응답자가 계속 대화해야 할 때 쓸 수 있습니다. 두 방식은 섞을 수도 있습니다. OpenAI Agents SDK, manager and handoff patterns

세 에이전트가 항상 더 좋은 것은 아닙니다

업무가 짧고 자료가 적으면 한 에이전트와 명확한 도구, 사람의 검토로 충분할 수 있습니다. 역할이 늘면 호출 비용과 대기, 결과 충돌, 책임 추적이 늘어납니다. 분리의 이익이 이런 복잡성을 넘어설 때만 팀 구조를 선택하세요.

검토 역할도 사람의 승인을 대신하지 않습니다

검토 에이전트는 초안의 누락을 찾는 보조 역할입니다. 같은 잘못된 원본을 조사와 작성이 공유했다면 검토도 오류를 놓칠 수 있습니다. 대외 제안서의 최종 수치, 가격, 제출 여부는 담당자가 확인해야 합니다. 외부 발송이나 파일 수정 권한을 모든 에이전트에 줄 필요도 없습니다. 조사 역할은 읽기만, 작성 역할은 초안만, 제출은 담당자 승인 후처럼 최소 권한을 나눌 수 있습니다.

  1. 담당자 지정 — 누가 업무 목표와 최종 승인 기준을 정하는가?
  2. 출처 유지 — 전문 에이전트의 근거가 최종 문서까지 따라오는가?
  3. 충돌 처리 — 서로 다른 수치가 나오면 누구에게 되돌리는가?
  4. 권한 분리 — 읽기·초안·수정·제출 권한이 역할별로 다른가?
  5. 기록 확인 — 각 역할이 무엇을 받고 무엇을 반환했는지 볼 수 있는가?

첫 실험은 ‘조사와 검토’만 분리해 보세요

기존에 사람이 작성하는 제안서 업무를 그대로 두고, 조사 에이전트에 승인된 강의 자료 목록을 찾게 해 보세요. 다른 검토 역할에는 완성된 초안과 기관 요청서를 비교하게 합니다. 누락 발견률과 근거 확인 시간, 잘못된 수치의 수정을 기록합니다. 그다음에 작성 역할까지 분리할 가치가 있는지 판단하면 됩니다. 평가할 때는 속도만 보지 말고 잘못된 근거를 다음 단계로 넘겼는지도 확인해야 합니다.

여러 에이전트의 협업은 사람 조직의 협업과 닮았습니다. 일을 나누는 순간 명확한 과업, 근거가 담긴 인계, 결과를 합치는 책임, 마지막 승인이 필요해집니다. 좋은 팀은 구성원이 많은 팀이 아니라 결과의 출처와 책임을 끝까지 추적할 수 있는 팀입니다.

참고 자료

OpenAI Agents SDK, Agent orchestration · OpenAI, A practical guide to building AI agents · Anthropic, How we built our multi-agent research system