멀티 에이전트 역할 분담: 작성·검수 분리 구조의 정의와 오해
작성·검수 분담은 멀티 에이전트 역할 분담의 한 형태입니다. 한 에이전트가 결과물을 만들면, 다른 에이전트가 미리 정한 기준으로 판정하고 고칠 점과 함께 되돌려 보냅니다. Microsoft 문서는 이 구조를 메이커-체커(maker-checker) 루프라고 부릅니다.
작성·검수 분담 구조는 정확히 무엇을 가리키나요?
Anthropic은 멀티 에이전트 시스템을 여러 LLM 에이전트가 함께 일하는 구조로 설명합니다. 여기서 에이전트는 도구를 반복해서 쓰는 LLM입니다.
Anthropic은 작성·검수 구조 자체는 워크플로의 하나인 평가자-최적화(evaluator-optimizer) 패턴으로 설명합니다. 워크플로는 미리 정한 코드 경로로 LLM 호출을 잇는 방식입니다. 한 LLM 호출이 응답을 만들고, 다른 호출이 평가와 피드백을 반복해 줍니다.
Microsoft 문서는 메이커-체커 루프를 여러 에이전트가 한 대화에서 협업하는 그룹 채팅 방식의 한 유형으로 정의합니다. 메이커는 결과물을 만들고, 체커는 정해진 기준에 비추어 그 결과를 평가합니다. 부족한 점이 있으면 체커가 구체적인 피드백을 붙여 메이커에게 되돌립니다. 메이커는 고친 결과를 다시 냅니다. 이 과정은 체커가 승인하거나 반복 횟수 상한에 이르면 끝납니다.
같은 문서는 평가자-최적화, 생성자-검증자, 비평 루프, 성찰 루프를 같은 구조의 다른 이름으로 적습니다. 이처럼 문서마다 분류는 다르므로, 실무에서는 이름보다 아래 세 요소를 갖추었는지로 판단합니다.
- 만드는 역할과 판정하는 역할이 나뉘어 있습니다.
- 판정하는 역할이 쓸 합격 기준이 미리 정해져 있습니다.
- 반복 상한과 상한에 이르렀을 때의 처리 방법이 정해져 있습니다.
비슷한 멀티 에이전트 구조와는 무엇이 다른가요?
에이전트가 여러 개라고 해서 모두 작성·검수 분담은 아닙니다. 공식 문서가 구분하는 구조와 나란히 놓고 보면 차이가 분명해집니다.
| 구조 | 에이전트 사이의 관계 | 작성·검수 분담과의 차이 |
|---|---|---|
| 순차 연결 | 앞 에이전트가 낸 결과를 다음 에이전트가 입력으로 받습니다. | 되돌림이 없습니다. Microsoft 문서는 앞 단계의 실패가 뒤로 번진다고 설명합니다. |
| 병렬 분할 | 서로 독립된 하위 작업을 동시에 처리합니다. | 각자 다른 부분을 맡을 뿐, 서로의 결과를 판정하지 않습니다. |
| 병렬 투표 | 같은 작업을 여러 번 실행해 여러 결과를 얻습니다. | 같은 일을 반복하는 방식이라 역할이 나뉘지 않습니다. |
| 오케스트레이터-워커 | 중앙 에이전트가 작업을 나누어 맡기고 결과를 종합합니다. | 하위 작업을 실행 도중에 정합니다. 검수 단계는 따로 설계해야 합니다. |
| 핸드오프 | 담당 에이전트가 더 맞는 전문 에이전트에게 작업을 넘깁니다. | 한 번에 한 에이전트만 일하며, 결과를 되돌려 고치는 고리가 없습니다. |
| 작성·검수 분담 | 메이커가 만들고 체커가 기준으로 판정해 되돌립니다. | 되돌림 고리와 합격 기준이 구조의 중심입니다. |
OpenAI 에이전트 SDK 문서는 코드로 순서를 정하는 방식의 예로, 작업 에이전트와 평가 에이전트를 반복 실행하는 방법을 소개합니다. 평가 에이전트가 기준을 통과했다고 판정하면 반복이 끝납니다. 같은 문서는 코드로 순서를 정하면 속도·비용·성능을 예측하기 쉽다고 설명합니다.
같은 문서는 관리자 에이전트가 전문 에이전트를 도구처럼 호출하는 방식도 소개합니다. 최종 답을 한 에이전트가 책임지게 하고 싶을 때 쓰는 방식이라고 합니다. Microsoft 문서는 단계마다 성격이 다르면 여러 패턴을 섞어 쓰라고 안내합니다. 실무에서는 자료 정리, 작성, 검수를 순차로 잇고 검수 단계에만 되돌림 고리를 두는 구성을 검토합니다.
한 에이전트로 충분한 일과 나눠야 하는 일은 어떻게 구분하나요?
Microsoft 문서는 요구사항을 안정적으로 충족하는 가장 낮은 복잡도를 고르라고 권합니다. 문서는 복잡도를 세 단계로 나눕니다. 오른쪽 열은 SEO·GEO 업무에 대입해 본 실무 예입니다.
| 단계 | 문서의 설명 | SEO·GEO 업무 예 |
|---|---|---|
| 모델 직접 호출 | 잘 다듬은 지시문 한 번으로 분류·요약·번역을 끝내는 수준입니다. | 검색어 목록을 의도별로 분류 |
| 단일 에이전트 | 도구를 쓰며 한 분야의 여러 요청을 처리합니다. 문서는 많은 기업 사례에서 이를 기본값으로 봅니다. | 검색 실적 자료를 받아 주간 변화를 정리 |
| 멀티 에이전트 | 지시문이 복잡하거나 도구가 너무 많거나 보안 요건이 있어 한 에이전트로는 안정적으로 처리하기 어려울 때 씁니다. | 공개할 글의 작성과 사실·출처 검수를 분리 |
Anthropic이 공개한 연구용 멀티 에이전트 사례에는 비용 기준도 나옵니다. 에이전트는 일반 대화보다 약 4배, 멀티 에이전트 시스템은 약 15배의 토큰(모델이 텍스트를 나누어 처리하는 단위)을 썼다고 합니다. 그래서 가치가 높은 작업에서만 경제성이 있다고 설명합니다.
같은 글은 멀티 에이전트가 맞지 않는 작업도 듭니다. 모든 에이전트가 같은 맥락을 공유해야 하는 작업과 에이전트끼리 의존 관계가 많은 작업입니다. 작성·검수 분담이 필요한지는 아래 질문으로 판단할 수 있습니다.
- 이 결과물이 외부에 공개되거나 고객에게 전달되는가?
- 합격 여부를 가를 기준을 문장으로 적을 수 있는가?
- 검수자가 작성 과정을 몰라도 결과물과 기준만으로 판정할 수 있는가?
- 오류가 나갔을 때의 손해가 반복 비용보다 큰가?
네 질문의 답이 모두 예라면 분담을 검토할 만합니다. 2번의 답이 아니요라면 에이전트를 나누기 전에 기준부터 정합니다. Anthropic 문서도 평가자-최적화가 효과적인 조건으로 명확한 평가 기준을 첫째로 듭니다.
작성·검수 분담에 대한 흔한 오해는 무엇인가요?
오해 1. 검수 에이전트를 더 붙일수록 품질이 오른다
Microsoft 문서는 뚜렷한 전문 역할이 없는 에이전트를 추가하는 것을 흔한 실수로 꼽습니다. 또 그룹 채팅 방식에 한해 에이전트를 세 개 이하로 두는 방안을 권합니다. 메이커-체커 루프도 이 방식에 속하며, 에이전트가 늘수록 흐름을 통제하기 어렵기 때문입니다. 실무에서는 검수자를 늘리기 전에 검수자마다 맡은 판정 항목이 겹치지 않는지부터 확인합니다.
오해 2. 검수자에게 작성 과정을 모두 넘겨야 정확하다
Microsoft 문서는 다음 에이전트에게 실제로 필요한 맥락이 무엇인지 정하라고 안내합니다. 쌓인 맥락 없이 새 지시만으로 일할 수 있다면 그 방식을 택하라고 합니다. 맥락이 커지면 응답 품질이 떨어질 수 있어 요약이나 선택적 삭제도 권합니다. 실무에서는 검수자에게 작성자의 추론 과정을 넘기지 않고 원고·원자료·기준만 전달합니다. 독자가 받는 것도 원고뿐이기 때문입니다.
오해 3. 검수자가 직접 고치면 더 빠르다
Microsoft 문서의 메이커-체커 루프에서 체커는 피드백을 붙여 되돌리고, 수정은 메이커가 맡습니다. 문서는 작성과 검증의 관심사를 분리한 콘텐츠 편집 검토를 이 방식의 적용 사례로 듭니다. 그룹 채팅 방식의 에이전트는 실행 중인 시스템을 바꾸는 도구를 쓰지 않는 읽기 전용 상태가 보통이라고도 적습니다. 실무에서는 검수자가 원고를 직접 고치면 고친 부분을 다시 판정할 주체가 사라지는 점을 고려합니다.
오해 4. 반복 상한에 이르면 마지막 원고를 쓰면 된다
Microsoft 문서는 반복 상한과 함께, 상한에 이르렀을 때의 대체 동작도 정하라고 안내합니다. 사람 검토자에게 넘기거나, 가장 나은 결과에 품질 경고를 붙이는 방법을 예로 듭니다. 실무에서는 상한 도달을 합격이 아닌 판정 보류로 기록합니다.
작성 에이전트와 검수 에이전트의 역할은 어떻게 적어 주나요?
Anthropic 문서는 하위 에이전트에게 목표, 출력 형식, 사용할 도구와 출처 안내, 작업 경계를 주라고 설명합니다. 지시가 모호했을 때는 에이전트들이 같은 조사를 중복했다고 밝힙니다. 실무에서는 두 역할의 경계를 한 표에 나란히 적는 방법을 권합니다.
| 항목 | 작성 에이전트 | 검수 에이전트 |
|---|---|---|
| 목표 | 질문에 답하는 원고 작성 | 원고가 합격 기준을 충족하는지 판정 |
| 받는 자료 | 질문, 원자료, 글 규칙 | 원고, 원자료, 합격 기준(작성 과정 기록은 넘기지 않음) |
| 권한 | 원고 수정 | 읽기 전용, 원고 수정 권한 없음 |
| 출력 | 원고 전문 | 통과 또는 반려, 항목별 지적 |
| 멈추는 조건 | 원자료로 답할 수 없는 질문 | 기준으로 판정할 수 없는 항목 |
검수 기준을 정할 때는 Anthropic 사례도 참고가 됩니다. 사람 시험자는 자동 평가가 놓친 문제를 찾아냈습니다. 에이전트가 권위 있는 출처보다 검색 노출을 노린 콘텐츠 농장(대량 생산형 사이트)을 먼저 고르는 경향이었습니다. Anthropic은 지시문에 출처 품질 기준을 넣어 이 문제를 고쳤다고 밝힙니다. 실무에서는 이 사례를 근거로 SEO·GEO 글의 검수 기준에 허용할 출처 종류를 적습니다.
예를 들어 가상의 ○○ 기업 블로그 글을 검수한다면, 검수 에이전트에게 아래처럼 역할을 줄 수 있습니다.
- 역할: 원고를 판정하는 검수자입니다. 원고를 직접 고치지 않습니다.
- 입력: 원고, 원자료 목록, 아래 합격 기준만 사용합니다.
- 합격 기준: 첫 문단이 질문에 답합니다. 모든 수치와 사실이 원자료에 있습니다. 출처는 공식 문서이며 홍보성 글이 아닙니다. 금지 표현이 없습니다.
- 출력: 첫 줄에 통과 또는 반려를 적습니다. 반려라면 기준 이름, 원고 위치, 원자료 근거, 고칠 방향을 한 줄씩 적습니다.
- 판정 불가: 기준으로 판정할 수 없는 항목은 판정 불가로 표시하고 이유를 적습니다.
Microsoft 문서는 출력이 매번 달라지는 에이전트를 시험할 때 채점 기준표나 모델 판정 평가를 쓰라고 안내합니다. Anthropic 사례에서는 모델을 한 번 호출해 0.0~1.0 점수와 통과·실패를 매기는 방식이 사람 판단과 가장 잘 맞았습니다. 다만 같은 글은 사람이 직접 하는 시험이 여전히 필요하다고 덧붙입니다.
사람이 개입할 지점도 함께 정합니다. Microsoft 문서는 사람이 참여하는 지점마다 꼭 거쳐야 하는지, 선택인지 정하라고 안내합니다. 그 응답이 다음 단계로 넘기는 승인인지, 되돌려 고치게 하는 피드백인지도 구분하라고 합니다.
정리
- 분담을 적용할 결과물 하나를 고르고, 앞의 네 판단 질문으로 분담이 필요한지 확인합니다.
- 검수 합격 기준을 4~6개 문장으로 적고, 허용할 출처 종류를 넣습니다.
- 작성·검수 역할표를 채우고, 검수 에이전트에게는 읽기 권한만 줍니다.
- 반복 상한과, 상한에 이르면 사람 검토자에게 넘기는 규칙을 정합니다.
- 처음 몇 건은 사람이 검수 결과를 다시 확인하고, 어긋난 판정을 근거로 기준 문장을 고칩니다.
참고 자료
- Building effective agents (Anthropic, 확인일 2026-10-20)
- How we built our multi-agent research system (Anthropic, 확인일 2026-10-20)
- Agent orchestration (OpenAI Agents SDK 문서, 확인일 2026-10-20)
- AI Agent Orchestration Patterns (Microsoft Learn Azure Architecture Center, 확인일 2026-10-20)