역할 전문화(Role Specialization) — 플래너(Planner), 크리틱(Critic), 익스큐터(Executor), 베리파이어(Verifier)

2026년에 가장 흔히 쓰이는 멀티 에이전트(multi-agent) 분해 방식은 다음과 같습니다. 한 에이전트는 계획을 세우고, 한 에이전트는 실행을 담당하며, 또 한 에이전트는 비평하거나 검증을 수행합니다. MetaGPT(arXiv:2308.00352)는 이 구조를 역할 프롬프트(role prompt) 안에 인코딩된 표준 운영 절차(Standard Operating Procedures; SOP)로 형식화하며, 제품 책임자(Product Manager), 아키텍트(Architect), 프로젝트 매니저(Project Manager), 엔지니어(Engineer), QA 엔지니어(QA Engineer)를 두고 Code = SOP(Team) 원칙을 따릅니다. ChatDev(arXiv:2307.07924)는 디자이너(designer), 프로그래머(programmer), 리뷰어(reviewer), 테스터(tester)를 "채팅 체인(chat chain)"으로 연결하고 "의사소통 기반 환각 제거(communicative dehallucination)"를 도입합니다. 즉, 에이전트가 누락된 세부 사항을 임의로 지어내는 대신 명시적으로 질문하도록 만드는 기법입니다. 검증자(verifier)는 시스템 전체를 지탱하는 핵심 역할입니다. Cemri 외(MAST, arXiv:2503.13657) 연구는 모든 멀티 에이전트 실패가 검증의 부재 또는 결함으로 귀결될 수 있음을 보였습니다. PwC는 CrewAI의 구조화된 검증 루프(structured validation loop)를 통해 정확도가 10%에서 70%로 7배 향상되었다고 보고했습니다.

유형: Learn + Build 언어: Python(stdlib) 선수 지식: Phase 16 · 04(원시 멀티 에이전트 모델), Phase 16 · 05(슈퍼바이저(Supervisor)) 예상 시간: 약 60분

문제

평범한 멀티 에이전트 시스템은 평범한 결과물만 만들어냅니다. 단체 채팅방에 코더 세 명을 모아도, 결국 같은 수준의 평범한 코드가 세 가지 버전으로 나올 뿐입니다. 에이전트를 더 늘리고 라운드를 더 돌려도 품질 임계점을 넘기지 못할 수 있습니다.

해결책은 에이전트의 숫자를 늘리는 것이 아니라 서로 다른 종류의 에이전트를 두는 것입니다. 명확히 다른 역할을 부여하세요. 비평가(critic)에게는 플래너에게 없는 도구를 주고, 검증자(verifier)에게는 객관적인 테스트 스위트(test suite)를 쥐어주세요. 그러면 시스템은 단순히 병렬로 추측만 반복하는 것이 아니라, 근거에 기반한 교정(grounded correction)이 가능한 내부적 이견을 갖게 됩니다.

개념

네 가지 표준 역할

플래너(Planner). 목표를 읽고 단계 목록 또는 명세(spec)를 만듭니다. 사용하는 도구는 지식 검색(knowledge retrieval)과 문서입니다. 출력은 구조화된 계획입니다.

익스큐터(Executor). 계획의 한 단계를 읽고 실제 산출물을 만듭니다. 사용하는 도구는 실제 작업 도구(코드 컴파일러, 셸(shell), API 클라이언트)입니다. 출력은 산출물 그 자체입니다.

크리틱(Critic). 익스큐터의 산출물을 플래너의 의도에 비추어 검토합니다. 사용하는 도구는 산출물에 대한 읽기 전용 접근과 정적 분석(static analysis)입니다. 출력은 이유가 붙은 수락/거절(accept/reject) 판단입니다.

베리파이어(Verifier). 산출물을 읽고 결정론적(deterministic) 검사를 실행합니다. 사용하는 도구는 테스트 실행기(test runner), 타입 검사기(type checker), 스키마 검증기(schema validator)입니다. 출력은 증거가 붙은 통과/실패(pass/fail) 판정입니다.

크리틱은 주관적이고 의견을 가지며, 대개 LLM 기반입니다. 베리파이어는 객관적이고 결정론적이며, 대개 코드 기반입니다. 둘은 같은 역할이 아닙니다.

MetaGPT의 표준 운영 절차(SOP) 패턴

MetaGPT(arXiv:2308.00352)는 소프트웨어 엔지니어링의 표준 운영 절차를 역할 프롬프트로 인코딩합니다.

• 제품 책임자(Product Manager) 는 제품 요구 명세서(Product Requirements Document; PRD)를 작성합니다.
• 아키텍트(Architect) 는 시스템 설계도를 만듭니다.
• 프로젝트 매니저(Project Manager) 는 작업을 분할합니다.
• 엔지니어(Engineer) 는 구현을 담당합니다.
• QA 엔지니어(QA Engineer) 는 테스트를 실행합니다.

각 역할은 엄격한 입출력 스키마(I/O schema)를 갖습니다. 역할 프롬프트는 그 역할이 무엇인지, 그리고 무엇을 반드시 산출해야 하는지를 명시합니다. Code = SOP(Team)이라는 정식화는 결정론적인 표준 운영 절차가 LLM으로 이루어진 팀을 예측 가능한 파이프라인으로 바꿔준다는 의미입니다.

ChatDev의 의사소통 기반 환각 제거(communicative dehallucination)

ChatDev는 핵심적인 한 가지 동작을 추가합니다. 익스큐터가 계획에 없는 구체적인 세부 사항이 필요할 때, 작업을 계속하기 전에 디자이너에게 명시적으로 질문하는 것입니다. 이는 LLM이 그럴듯하게 세부 사항을 지어내는 전형적인 실패를 방지합니다.

구현은 역할 프롬프트에 다음과 같은 규칙을 넣는 형태입니다. "받지 못한 구체적 정보가 필요하면, 산출물을 만들기 전에 관련 역할의 이름을 지목해 질문하라."

베리파이어가 가장 중요한 이유

Cemri 외 연구진(MAST)은 1,642건의 멀티 에이전트 실행 실패를 추적했습니다. 그 중 21.3%는 검증 공백(verification gap)에 해당했습니다. 즉, 누구도 확인하지 않은 답을 시스템이 그대로 내보낸 경우입니다. 나머지 79%의 실패 또한 "검사 단계가 있긴 했지만 조용히 실패했거나 아예 실행되지 않았다"는 원인으로 귀결되는 경우가 많습니다. 검증은 시스템 전체를 지탱하는 핵심 역할입니다.

PwC는 CrewAI 배포 사례(2025)에서 구조화된 검증 루프를 추가한 결과 정확도가 10%에서 70%로 올라갔다고 보고했습니다. 역할 하나로 7배의 향상을 거둔 셈입니다.

크리틱과 베리파이어의 차이

• 크리틱은 산출물의 품질을 검토하는 LLM입니다. 주관적이며, 그럴듯한 산문(prose)에 속을 수 있습니다.
• 베리파이어는 산출물 위에서 실행되는 결정론적 프로그램입니다. 객관적이며, 증거가 함께 붙은 통과/실패 판정을 제공합니다.

두 가지를 모두 사용하세요. 크리틱은 베리파이어가 말로 표현하기 어려운 취향 차원의 문제를 잡아냅니다. 베리파이어는 런타임(runtime)에서만 드러나는 버그를 잡아냅니다. 크리틱은 이런 버그를 미처 보지 못할 수 있습니다.

안티패턴(Anti-pattern)

시스템 안의 모든 역할이 LLM이고, 모든 역할의 출력이 "looks good to me(보기엔 괜찮음)"라면, 이것이 바로 MAST에서 말하는 전형적인 실패 양상입니다. 통과/실패 판정이 LLM이 아니라 코드로 결정되는 베리파이어를 최소한 하나는 추가하세요.

프레임워크(Framework) 매핑

• CrewAI — Agent(role, goal, backstory)가 교과서적인 전문화 인터페이스입니다.
• LangGraph — 노드(node)마다 전문화된 프롬프트를 부여할 수 있으며, 엣지(edge)가 파이프라인 흐름을 강제합니다.
• AutoGen — GroupChat 안의 역할별 ConversableAgent에 한 단어짜리 이름을 부여합니다.
• OpenAI Agents SDK — 역할 전문화된 Agent 사이를 잇는 핸드오프(handoff) 도구를 사용합니다.

만들어보기

code/main.py는 간단한 Python 함수 하나를 만들어내는 네 역할 파이프라인을 구현합니다.

• 플래너(Planner) 는 명세를 만듭니다.
• 익스큐터(Executor) 는 코드 문자열을 생성합니다.
• 크리틱(Critic) 은 LLM을 흉내내어 명백한 문제만 표시합니다.
• 베리파이어(Verifier) 는 샌드박스(sandbox)(exec) 안에서 생성된 코드를 테스트 케이스로 실행합니다.

데모는 두 번 실행됩니다. 첫 번째는 익스큐터가 올바른 코드를 만들고, 크리틱과 베리파이어가 모두 통과시키는 경우입니다. 두 번째는 익스큐터가 명세에서 벗어난 코드를 만드는 경우입니다. 크리틱은 코드가 그럴듯해 보여 버그를 놓치지만, 베리파이어는 테스트 실패로 잡아냅니다.

실행 방법:

python3 code/main.py

사용해보기

outputs/skill-role-designer.md는 어떤 과제를 받아 역할 명단(role roster)(3~5개의 역할), 역할별 입출력 스키마, 베리파이어 점검 항목을 만들어냅니다. 에이전트를 프레임워크에 실제로 배선하기 전에 사용해보세요.

산출물 만들기

체크리스트입니다.

• 최소 하나의 결정론적 베리파이어. 모든 역할을 LLM으로만 두는 구성은 피하세요.
• 역할별 명시적 입출력 스키마. 플래너는 산문이 아니라 명세를 반환하고, 익스큐터는 그 스키마를 읽고 동작합니다.
• 의사소통 기반 환각 제거. 정보가 부족하면 익스큐터는 플래너에게 반드시 질문해야 하며, 세부 사항을 임의로 지어내선 안 됩니다.
• 크리틱과 베리파이어 실행 순서. 크리틱을 먼저 실행하세요. 저렴하고 설계 차원의 문제를 잡아냅니다. 베리파이어를 다음에 실행하세요. 느리지만 실제 버그를 잡아냅니다.
• 루프 예산(loop budget). 사람에게 에스컬레이션(escalation)하기 전, 크리틱-익스큐터 사이의 수정 라운드는 최대 2회로 제한하세요.

연습문제

1. (쉬움) code/main.py를 실행하고, 크리틱이 놓친 버그를 베리파이어가 어떻게 잡아내는지 관찰하세요. 그리고 정적 분석 점검(예: return 등장 횟수 세기)을 추가 베리파이어로 넣어보세요. 런타임 테스트가 놓치는 어떤 문제를 잡아냅니까?
2. (중간) 다섯 번째 역할로 "요구사항 분석가(requirements analyst)"를 추가하세요. 사용자의 막연한 바람을 플래너가 바로 사용할 수 있는 명세로 옮기는 역할입니다. 어떤 의사소통 기반 환각 제거 질문이 이 역할로 올라가야 합니까?
3. (중간) MetaGPT 논문 3장("Agents")을 읽고, MetaGPT의 다섯 역할 각각의 입출력 스키마를 나열하세요.
4. (어려움) ChatDev의 채팅 체인 도식(arXiv:2307.07924 Figure 3)을 살펴보세요. 의사소통 기반 환각 제거가 없었다면 무한 루프가 되었을 지점을, 어떻게 끊어내고 있는지 식별하세요.
5. (어려움) PwC의 7배 정확도 향상은 검증 루프에서 나왔습니다. 베리파이어를 추가해도 도움이 되지 않을 과제 세 가지를 가정해 보세요. 결정론적 정답 검증이 불가능하거나 비용이 지나치게 큰 경우입니다.

핵심 용어

더 읽을거리

• Hong et al. — MetaGPT: Meta Programming for Multi-Agent Collaboration — 역할 프롬프트로서의 표준 운영 절차(SOP-as-role-prompt) 개념을 정립한 기준 논문입니다.
• Qian et al. — Communicative Agents for Software Development (ChatDev) — 채팅 체인(chat chain)과 의사소통 기반 환각 제거를 다룹니다.
• Cemri et al. — Why Do Multi-Agent LLM Systems Fail? — MAST 분류 체계를 제시합니다. 검증 공백은 실패의 21.3%를 차지합니다.
• CrewAI docs — Agent roles — 실서비스 수준의 역할 명세 인터페이스입니다.