생성 에이전트(Maker)와 별도의 검증 에이전트(Critic)를 분리하는 패턴이 코드·문서 워크플로의 표준 구조로 정착하고 있다. 같은 모델에 '스스로 검토하라'고 시키면 자기 출력에 관대해지는 self-evaluation 편향이 생기지만, Critic을 별도 프롬프트·별도 호출로 떼어내면 결함 검출률이 눈에 띄게 오른다. 관건은 Critic의 출력을 자연어 코멘트가 아니라 구조화된 판정(PASS/REVISION_NEEDED + 사유 + 수정 지점)으로 강제하는 것. 그래야 Maker가 다음 반복에서 기계적으로 반영하고, 2~3회 반복 후 수렴 여부를 라우터가 판단할 수 있다. 다만 Critic이 Maker와 동일한 맥락 오류를 공유하면 둘 다 같은 버그를 놓치므로, Critic에는 의도적으로 다른 관점(보안·과설계·비즈니스)을 주입해야 한다.
원문 출처
LangChain Blog
다수 에이전트를 느슨하게 풀어놓는 swarm 패턴이 실무에서 깨지는 이유를 정량적으로 짚은 논의가 늘었다. 핵심은 두 가지다. 첫째, 단계마다 에이전트 성공률이 95%여도 직렬 10단계면 전체 성공률은 0.95^10≈60%로 주저앉는다. 에이전트를 늘릴수록 핸드오프 경계가 늘고 오류는 곱해진다. 둘째, 에이전트 수 N이 늘면 조정·합의에 드는 통신 비용은 대략 N^2로 증가하지만 실제 유효 작업량은 그만큼 늘지 않는다. 결국 검증 가능한 중간 산출물과 명시적 핸드오프 계약(스키마·완료 정의)이 없는 swarm은 토큰만 태우고 발산한다. 대안으로 떠오른 건 자유 방임 swarm이 아니라 라우터가 단계를 통제하는 supervised 그래프 구조다.
실무에선 에이전트 수를 늘리기 전에 '단계별 성공률 × 단계 수'를 먼저 계산해야 한다. 검증 게이트 없는 핸드오프가 3단계만 넘어가도 체감 신뢰도가 무너지므로, 각 경계에 스키마 검증과 명시적 완료 조건을 두는 설계가 선결이다.
Anthropic이 자사 Research 기능의 오케스트레이터-서브에이전트 구조를 공개했다. 리드 에이전트가 질의를 분해해 병렬 서브에이전트에 위임하고 결과를 종합하는 구조인데, 핵심은 성능이 아니라 비용 곡선이다. 단일 에이전트 대비 토큰을 약 15배 더 쓰며, 내부 평가에서 성능 분산의 80%가 토큰 총량으로 설명됐다. 즉 멀티에이전트는 '많이 읽고 많이 쓰는' 워크로드(넓은 탐색·병렬 검색)에서만 비용을 정당화하고, 의존성이 강하거나 공유 컨텍스트가 필수인 작업에선 오히려 손해다. 프롬프트에 위임 범위와 종료 조건을 명시하지 않으면 서브에이전트가 중복 검색을 폭주시킨다는 운영 교훈도 함께 실렸다.
이 브리핑에서 궁금한 점이 있다면 먼저 질문을 남겨보세요.
첫 댓글을 남겨보세요.
매일 쏟아지는 소식 중 꼭 봐야 할 것만 골라 실무 가이드와 함께 보냅니다.
핵심 뉴스 5 · 추천 가이드 3 · 인기 Q&A