2부 9장. Evaluator-Optimizer 패턴: 스스로 검토하고 개선하는 구조

잘 만드는 것보다, 고쳐 가며 만드는 것이 현실적이다

앞 장에서 우리는 큰 일을 나누고 다시 합치는 Orchestrator-Workers 패턴을 살펴봤다. 중앙 조정자가 일을 분해하고, 여러 워커가 각자의 몫을 수행한 뒤, 결과를 다시 하나로 엮는 구조였다. 그런데 이렇게 일을 잘 나눴다고 해서 항상 결과가 만족스러울까. 대개는 아니다.

초안은 자주 어설프다. 중요한 항목이 하나 빠지기도 하고, 형식은 맞았는데 핵심이 흐리기도 하며, 논리는 좋아 보이는데 사용자의 요청과 미묘하게 어긋나기도 한다. 사람도 초고를 한 번에 완벽하게 쓰기 어렵다. 하물며 모델에게 "한 번에 정확하고, 빠짐없고, 읽기 좋고, 형식도 맞는 결과를 내라"고 기대하는 것은 지나치게 낙관적이다.

이 지점에서 등장하는 것이 Evaluator-Optimizer 패턴이다. 이름은 조금 딱딱하지만 생각은 단순하다. 먼저 무언가를 만든다. 그다음 그것이 충분히 좋은지 평가한다. 부족하면 왜 부족한지 피드백을 준다. 그리고 다시 고친다. 이 과정을 반복하다가, 기준에 도달하면 멈춘다.

즉, 이 패턴의 핵심은 한 번에 잘 만들기가 아니라 평가를 통해 점점 덜 틀리고 더 쓸 만하게 만들기다. 실전에서는 이쪽이 훨씬 현실적이다.

Evaluator와 Optimizer는 각각 무슨 일을 할까

이 패턴에는 두 역할이 있다.

Optimizer는 결과를 만들어내고 고치는 역할이다. 초안을 쓰고, 수정하고, 피드백을 반영한다. 어떤 시스템에서는 처음부터 끝까지 같은 모델이 맡을 수도 있고, 어떤 시스템에서는 초안 작성자와 수정자가 다를 수도 있다.

Evaluator는 결과를 평가하는 역할이다. 이 결과가 좋은지, 무엇이 부족한지, 다시 시도해야 하는지 판단한다. 중요한 점은 evaluator가 "마음에 안 든다" 같은 감상만 말하면 안 된다는 것이다. 가능하면 어디가 부족한지, 어떤 기준에 어긋났는지, 무엇을 고쳐야 하는지를 말해줘야 한다.

사람이 글을 쓰고 편집자가 교정하는 관계를 떠올리면 이해하기 쉽다. 작성자는 문장을 만든다. 편집자는 독자 입장에서 보고, 빠진 논점을 짚고, 구조를 다듬게 한다. 둘이 서로 다투는 관계가 아니라, 결과물을 더 낫게 만드는 협업 관계다.

여기서 중요한 것은 evaluator가 optimizer보다 "더 똑똑해야만" 하는 것은 아니라는 점이다. 오히려 evaluator는 더 좁고 선명한 기준을 가져야 한다. 예를 들어 초안 작성은 창의성이 필요하지만, 검토는 다음 항목만 보면 충분할 수 있다.

• 사용자의 요청을 모두 반영했는가

• 사실관계가 충돌하지 않는가

• 형식 제약을 지켰는가

• 누락된 항목은 없는가

• 너무 장황하거나 애매한 표현은 없는가

평가 기준이 분명할수록 이 패턴은 강해진다.

왜 이 패턴이 강한가

많은 설계가 처음에는 이렇게 출발한다. "프롬프트를 더 잘 쓰면 한 번에 좋은 결과가 나오지 않을까?" 물론 어느 정도는 맞다. 좋은 지시는 분명 도움이 된다. 하지만 실전의 문제는 대개 그렇게 단순하지 않다.

사용자는 조건을 뒤늦게 추가하고, 자료는 불완전하고, 모델은 가끔 형식을 놓치며, 작은 실수 하나가 전체 신뢰를 떨어뜨린다. 이런 환경에서는 한 번의 생성에 모든 기대를 몰아주는 것보다, 생성 후 검토와 개선을 구조에 넣는 것이 더 안정적이다.

이 패턴이 특히 강한 이유는 세 가지다.

첫째, 목표를 더 현실적으로 다룬다. 처음부터 완벽함을 요구하는 대신, 초안을 허용하고 개선 경로를 준비한다.

둘째, 품질 기준을 분리할 수 있다. "잘 써라"라는 막연한 요구 대신, 정확성, 완전성, 형식 준수, 안전성 같은 기준으로 나눠 점검할 수 있다.

셋째, 실패를 숨기지 않는다. 결과가 부족하면 그냥 통과시키는 대신, 다시 시도하거나 사람에게 넘기는 선택을 할 수 있다.

쉽게 말해, Evaluator-Optimizer 패턴은 모델을 천재로 믿는 구조가 아니라, 초안을 만들고 다듬는 과정을 시스템으로 만든 구조다.

프롬프트 체이닝과는 무엇이 다를까

앞에서 다룬 프롬프트 체이닝도 단계를 나누는 방식이었다. 그래서 둘이 비슷해 보일 수 있다. 하지만 초점이 다르다.

프롬프트 체이닝은 보통 미리 정한 순서대로 단계를 거치는 구조다. 예를 들어 분석하고, 초안을 쓰고, 요약하고, 형식을 맞추는 식이다. 흐름이 비교적 선형적이다.

반면 Evaluator-Optimizer는 결과를 보고 다시 돌아오는 루프 구조다. 초안을 만들고, 평가하고, 부족하면 같은 단계를 다시 수행할 수 있다. 즉, 단순한 순서가 아니라 반복 개선이 핵심이다.

둘은 경쟁 관계가 아니라 자주 함께 쓰인다. 먼저 체이닝으로 초안을 만들고, 마지막에 evaluator가 검토해서 optimizer가 다시 다듬는 식이다. 순차 구조 위에 개선 루프를 얹는 셈이다.

좋은 평가 기준이 없으면 루프는 금방 망가진다

이 패턴을 처음 설계할 때 가장 흔한 실수는 evaluator에게 너무 추상적인 일을 시키는 것이다. 예를 들어 "결과가 좋은지 평가해줘"라고만 하면, 그 평가는 들쭉날쭉해진다. 어떤 때는 엄격하고, 어떤 때는 후하며, 어떤 때는 근거 없이 "조금 아쉽다"로 끝난다.

좋은 evaluator는 취향이 아니라 기준으로 말해야 한다. 평가 기준은 가능한 한 관찰 가능해야 한다. "좋은 글인가?"보다 "핵심 요구 세 가지가 모두 포함되었는가?"가 더 낫다. "전문적인가?"보다 "용어 설명이 있는가, 문단 흐름이 자연스러운가, 불필요한 반복이 없는가?"가 더 낫다.

평가 기준은 보통 다음 층위로 나눌 수 있다.

• 목표 충족: 사용자의 요청을 제대로 해결했는가

• 내용 품질: 사실관계, 논리, 누락 여부는 어떤가

• 형식 품질: 길이, 구조, 출력 포맷, 문체를 지켰는가

• 운영 제약: 금지된 행동이나 위험한 출력을 피했는가

• 실용성: 사용자가 바로 쓸 수 있는 결과인가

이 기준이 정리되어 있어야 evaluator의 피드백도 유용해진다. 그래야 optimizer가 무엇을 고쳐야 할지 안다.

좋은 evaluator는 점수만 주지 않는다

평가자가 "72점"이라고 말하는 것은 생각보다 쓸모가 적다. 숫자는 상태를 알려줄 수는 있지만, 행동을 만들어내지는 못한다. optimizer가 필요로 하는 것은 대개 더 구체적이다.

좋은 evaluator는 최소한 세 가지를 알려주는 편이 좋다.

첫째, 무엇이 문제인지를 말해야 한다. 예를 들어 "결론은 있지만 근거가 두 개뿐이라 설득력이 약하다"처럼 말이다.

둘째, 왜 문제인지를 말해야 한다. 단순히 "짧다"가 아니라 "사용자가 비교 근거를 요청했는데 경쟁사별 비교가 빠져 있다"처럼 기준과 연결되어야 한다.

셋째, 어떻게 고칠지를 말해야 한다. "경쟁사별로 가격, 핵심 기능, 타깃 고객을 표 형식으로 추가하라" 같은 식의 수정 방향이 필요하다.

즉, evaluator의 출력은 판결문보다는 수정 지시서에 가까워야 한다.

루프는 어떻게 돌아가는가

Evaluator-Optimizer 패턴은 겉보기보다 단순한 흐름으로 설계할 수 있다. 기본 루프는 보통 이렇다.

1. optimizer가 초안을 만든다.

2. evaluator가 정해진 기준으로 검토한다.

3. evaluator가 통과 여부와 수정 피드백을 남긴다.

4. 통과하지 못하면 optimizer가 피드백을 반영해 다시 만든다.

5. 종료 조건을 만족할 때까지 반복한다.

중요한 점은 이 루프가 무한히 돌아서는 안 된다는 것이다. "더 좋아질 수도 있지 않을까?"라는 생각으로 계속 돌리면 품질은 조금 오를 수 있어도 비용과 시간이 빠르게 늘어난다. 때로는 같은 실수를 맴돌기도 한다. 그래서 이 패턴에서 진짜 설계 포인트는 반복 그 자체가 아니라 언제 멈출지 결정하는 기준이다.

종료 조건은 이 패턴의 브레이크다

많은 사람이 이 패턴을 "스스로 고쳐 가는 똑똑한 구조"로만 이해한다. 하지만 운영 관점에서 보면 더 중요한 질문이 있다.

"언제 그만 고치게 할 것인가?"

브레이크가 없는 개선 루프는 멋져 보여도 위험하다. 계속 비용을 쓰고, 응답 시간을 늘리고, 경우에 따라서는 오히려 결과를 망칠 수도 있다. 처음 초안은 괜찮았는데 수정이 반복되면서 문장이 부자연스러워지거나, 원래 맞던 내용까지 손상되는 일도 있다.

종료 조건은 보통 여러 개를 함께 둔다.

• 품질 기준 도달: evaluator가 통과 판정을 내리면 멈춘다.

• 최대 반복 횟수 도달: 예를 들어 2회나 3회까지만 수정한다.

• 개선 폭 부족: 직전 결과에 비해 나아진 점이 거의 없으면 멈춘다.

• 예산 한도 도달: 호출 수, 토큰 수, 도구 사용 비용이 한도를 넘으면 멈춘다.

• 시간 한도 도달: 응답 지연이 허용 범위를 넘기기 전에 종료한다.

• 위험 감지: 애매하거나 민감한 작업이면 사람 검토로 넘긴다.

실전에서는 이 중 하나만 쓰지 않고, 여러 조건을 동시에 건다. 그래야 품질과 운영성을 함께 지킬 수 있다.

"더 좋아졌다"를 어떻게 판단할까

종료 조건 중에서도 어려운 것은 "개선 폭 부족"을 판단하는 일이다. evaluator가 매번 새 피드백을 주더라도, 실제로 결과가 나아졌는지는 별개의 문제이기 때문이다.

예를 들어 1차 수정에서 누락된 항목을 채웠고, 2차 수정에서 형식을 정리했으며, 3차 수정에서 표현만 조금 매끈해졌다고 해보자. 이쯤 되면 추가 개선의 이득이 작을 수 있다. 반대로 3차가 되었는데도 여전히 핵심 요구를 놓치고 있다면, 단순 반복보다 전략 변경이 필요하다.

그래서 evaluator는 가능하면 단순한 총평만 하지 말고, 어떤 기준이 해결되었고 어떤 기준이 아직 남았는지를 구조적으로 남기는 편이 좋다. 그러면 시스템은 다음과 같이 판단할 수 있다.

"남은 문제는 사소한 표현 수정뿐이니 멈춘다."

혹은 이렇게 판단할 수도 있다.

"같은 지적이 두 번 반복되었으니, optimizer가 이해하지 못하고 있다. 다른 프롬프트로 바꾸거나 사람에게 넘긴다."

즉, 개선 루프의 핵심은 반복 횟수가 아니라 상태를 보고 전략을 바꾸는 판단이다.

Evaluator가 보는 것은 결과만이 아니다

초보 설계에서는 evaluator가 최종 텍스트만 보게 하는 경우가 많다. 하지만 때로는 결과만으로는 충분하지 않다. 왜 이런 답이 나왔는지, 어떤 자료를 참고했는지, 어떤 도구 호출이 있었는지를 함께 봐야 할 때가 있다.

예를 들어 코드 수정 제안이라면 결과 코드만 봐서는 테스트가 누락됐는지 알기 어렵다. 고객 환불 승인 초안이라면 문장만 읽어서는 정책 확인을 거쳤는지 모를 수 있다. 이런 경우 evaluator는 결과뿐 아니라 중간 근거도 확인해야 한다.

물론 그렇다고 모든 로그와 모든 문서를 다 넘기면 evaluator도 산만해진다. 여기서 중요한 것은 평가에 필요한 최소한의 맥락만 주는 것이다. 즉, evaluator도 optimizer와 마찬가지로 적절한 컨텍스트 설계가 필요하다.

평가자는 모델일 수도 있고, 규칙일 수도 있다

Evaluator라고 해서 반드시 또 다른 LLM일 필요는 없다. 오히려 실전에서는 규칙 기반 검사와 모델 기반 평가를 섞는 편이 더 안정적이다.

형식 준수 여부, 필수 항목 포함 여부, JSON 구조 일치, 금지어 포함 여부처럼 비교적 분명한 문제는 코드나 규칙으로 검사하는 편이 낫다. 이런 것은 모델에게 묻지 않는 것이 더 빠르고 더 싸고 더 일관적이다.

반면 논리 흐름, 설득력, 문맥 적합성, 질문 의도와의 정렬처럼 애매한 판단은 모델 기반 evaluator가 잘할 수 있다. 즉, 실전의 evaluator는 종종 한 명이 아니라 작은 심사위원단에 가깝다. 어떤 항목은 규칙이 보고, 어떤 항목은 모델이 본다.

이 조합이 좋은 이유는 분명하다. 규칙은 흔들리지 않고, 모델은 유연하다. 둘을 적절히 섞으면 평가 품질과 운영 비용 사이의 균형이 좋아진다.

예시 1: 보고서 초안을 더 쓸 만하게 만들기

예를 들어 사용자가 "회의용 전략 메모를 써 달라"고 요청했다고 해보자. optimizer는 먼저 초안을 쓴다. 그런데 초안을 읽어보면 핵심 주장은 그럴듯하지만, 근거가 빈약하고 액션 아이템이 빠져 있을 수 있다.

이때 evaluator는 이렇게 판단할 수 있다. 결론은 있으나, 경쟁사 비교 표가 없고, 우선순위 기준이 부족하며, 회의에서 바로 논의할 질문이 빠져 있다. 그러면 optimizer는 이 피드백을 반영해 다시 쓴다.

2차 초안에서는 표와 액션 항목이 생겼지만, 이번에는 내용이 너무 길어져 회의용 메모답지 않게 되었을 수 있다. evaluator는 이번에는 분량과 구조를 지적한다. 그러면 optimizer는 핵심만 남기고 압축한다.

이 과정은 아주 인간적이다. 초안을 쓰고, 검토받고, 다시 줄이고, 핵심을 살리는 것이다. 중요한 것은 처음 결과가 완벽해야 하는 것이 아니라, 검토를 통해 회의에서 바로 쓸 수 있는 문서로 수렴해 가는 것이다.

예시 2: 코드 수정 제안을 안전하게 다듬기

코드 관련 작업에서는 이 패턴이 특히 유용하다. 모델이 처음부터 완전히 안전한 코드를 제안할 것이라고 믿는 것은 위험하다. 문법은 맞아도 예외 처리가 빠질 수 있고, 기능은 되지만 성능이 나쁠 수 있으며, 겉보기에는 멀쩡하지만 기존 인터페이스를 깨뜨릴 수도 있다.

이럴 때 optimizer는 먼저 패치를 제안한다. evaluator는 그 결과를 다음 기준으로 본다. 테스트가 추가되었는가, 기존 함수 계약을 어기지 않았는가, 예외 입력에서 안전한가, 불필요하게 큰 변경은 아닌가.

만약 evaluator가 "기능은 구현했지만 실패 케이스 테스트가 없고, 에러 메시지가 모호하다"고 판단하면 optimizer는 그 부분만 보강할 수 있다. 또 두세 번 반복해도 같은 결함이 계속 남는다면, 시스템은 자동 수정을 멈추고 개발자 검토로 넘겨야 한다.

즉, 코드 에이전트에서 이 패턴은 단지 품질을 높이는 장치가 아니라, 위험을 통제하는 장치이기도 하다.

예시 3: 고객 응답 초안을 더 안전하게 만들기

고객 지원에서도 Evaluator-Optimizer 패턴은 실용적이다. 예를 들어 환불 요청에 대한 답변 초안을 자동으로 작성한다고 해보자. optimizer는 예의 바르고 자연스러운 문장을 만들 수 있다. 하지만 실전에서 중요한 것은 친절함만이 아니다. 정책과 맞는지, 과도한 약속을 하지 않았는지, 누락된 확인 절차는 없는지가 중요하다.

이때 evaluator는 말투보다 먼저 정책 준수와 리스크를 본다. 고객 감정 공감 문구는 좋지만, 환불 조건 확인 없이 확정적으로 보상 약속을 했다면 통과시키면 안 된다. 그러면 optimizer는 표현을 다시 조정하고, 필요한 확인 절차를 포함한 초안으로 수정해야 한다.

이 사례에서 evaluator는 단순 문장 교정자가 아니다. 운영 정책의 문지기에 가깝다.

Orchestrator-Workers와 어떻게 연결될까

앞 장의 Orchestrator-Workers 패턴과 이번 장의 Evaluator-Optimizer 패턴은 자주 함께 등장한다. 다만 질문이 다르다.

Orchestrator-Workers가 "일을 어떻게 나누고 다시 합칠까?"를 다룬다면, Evaluator-Optimizer는 "지금 나온 결과가 충분히 좋은가, 아니라면 어떻게 더 나아지게 할까?"를 다룬다.

즉, 하나는 작업 구조의 문제이고, 다른 하나는 품질 개선의 문제다.

실전에서는 오케스트레이터가 여러 워커의 결과를 모은 뒤, evaluator에게 최종 산출물을 검토하게 할 수 있다. 또는 각 워커 단계마다 evaluator를 붙여 중간 결과를 정제할 수도 있다. 예를 들어 조사 워커의 결과가 부실하면 분석 워커로 넘기기 전에 먼저 다시 조사하게 만들 수 있다.

이렇게 보면 evaluator는 마지막 단계의 검수자일 수도 있고, 전체 파이프라인 곳곳에 놓이는 품질 게이트일 수도 있다. 어디에 둘지는 비용, 중요도, 실패 위험에 따라 달라진다.

상태를 잘 남겨야 루프가 똑똑해진다

이 패턴도 결국 루프이기 때문에 상태 관리가 중요하다. 적어도 다음 정도는 기록해 두는 편이 좋다.

• 현재 초안의 버전

• 반복 횟수

• evaluator의 점검 결과

• 수정해야 할 항목 목록

• 직전 반복 대비 개선 여부

• 중단 이유 또는 최종 통과 이유

이 정보가 없으면 시스템은 금방 비슷한 피드백을 반복하거나, 이미 해결된 문제를 다시 지적하거나, 왜 멈췄는지 설명하지 못하게 된다.

특히 운영 환경에서는 "왜 이 답변이 이렇게 나왔나"가 중요하다. evaluator가 어떤 기준으로 통과시켰는지, 몇 번 수정했는지, 왜 사람 승인으로 넘겼는지 남아 있어야 디버깅과 개선이 가능하다.

쉽게 말해, 개선 루프는 기억이 있어야 발전한다.

자주 하는 설계 실수

이 패턴은 개념은 쉬워 보여도 실제로는 몇 가지 함정이 반복된다.

첫 번째 실수는 evaluator의 기준이 너무 모호한 것이다. 기준이 흐리면 같은 결과도 그때그때 다르게 판정된다.

두 번째 실수는 피드백이 추상적인 것이다. "더 자연스럽게 써라", "더 좋아지게 고쳐라" 같은 말은 optimizer에게 거의 도움이 되지 않는다.

세 번째 실수는 같은 눈으로 계속 보는 것이다. optimizer와 evaluator가 사실상 같은 프롬프트, 같은 관점, 같은 맹점을 공유하면 반복은 늘어나도 품질은 잘 안 오른다.

네 번째 실수는 무한 반복이다. 종료 조건이 약하면 시스템은 작은 흠집을 끝없이 다듬다가 비용만 쓴다.

다섯 번째 실수는 잘못된 지표를 최적화하는 것이다. 예를 들어 evaluator가 형식만 지나치게 엄격하게 보면, 내용은 빈약한데 모양만 깔끔한 답이 통과할 수 있다.

즉, 이 패턴은 루프만 만든다고 되는 것이 아니라, 무엇을 보고 무엇을 고치게 할지를 설계해야 한다.

평가를 잘못 설계하면 '검사 통과용 답'이 나온다

이 패턴에는 한 가지 재미있고도 위험한 현상이 있다. optimizer가 evaluator의 취향을 학습해 버리는 것이다. 그러면 실제로 더 좋은 결과를 만드는 대신, 검사만 통과하는 결과를 만들 수 있다.

예를 들어 evaluator가 "소제목이 있으면 좋다"는 기준을 강하게 보게 만들면, optimizer는 내용이 부실해도 소제목만 잔뜩 붙여 통과하려 들 수 있다. 또는 "정중한 표현"을 과하게 중시하면, 핵심이 흐린데도 말만 점잖은 답변이 살아남을 수 있다.

그래서 evaluator는 겉모습만 보지 말고, 가능한 한 실제 목적 달성을 기준으로 삼아야 한다. 회의 메모라면 회의에 바로 쓸 수 있는가가 중요하고, 고객 응답이라면 정책에 맞으면서도 오해를 줄이는가가 중요하다. 평가 기준은 언제나 형식보다 목적에 가까워야 한다.

처음에는 짧은 루프로 시작하라

처음부터 복잡한 개선 시스템을 만들 필요는 없다. 오히려 대부분의 팀은 아주 작은 루프만으로도 큰 효과를 본다. 예를 들어 초안 작성 한 번, 평가 한 번, 수정 한 번 정도만 넣어도 품질 차이가 꽤 난다.

처음에는 이런 식이 좋다.

• 필수 형식 검사는 규칙으로 처리한다.

• 내용 품질은 간단한 evaluator가 본다.

• 수정은 최대 1회나 2회로 제한한다.

• 애매하거나 위험한 작업은 사람에게 넘긴다.

이렇게 시작하면 과도한 복잡성 없이도 개선 루프의 장점을 확인할 수 있다. 이후 실제 실패 사례를 보면서 평가 기준을 더 정교하게 다듬고, 반복 횟수나 중단 조건을 조정하면 된다.

좋은 설계는 처음부터 완벽한 구조도를 그리는 것이 아니라, 실제 실패를 줄이는 최소한의 루프를 만드는 것에서 출발한다.

언제 특히 잘 맞는가

Evaluator-Optimizer 패턴은 모든 곳에 필요한 것은 아니다. 하지만 다음과 같은 문제에서는 특히 잘 맞는다.

결과의 품질 차이가 크고, 한 번 더 다듬는 것만으로 체감 가치가 크게 올라가는 작업이다. 보고서 초안, 코드 변경 제안, 고객 응답, 요약문, 기획 문서, 검토 메모 같은 것들이 여기에 속한다.

또한 정답이 완전히 하나로 고정되어 있지는 않지만, 분명한 품질 기준은 있는 작업에 잘 맞는다. 완전히 자유로운 창작보다는, 목적과 제약이 있는 생성 작업에서 강하다.

반대로 아주 짧은 질의응답이나, 답이 분명한 단일 계산 작업에는 과할 수 있다. 이런 경우에는 evaluator를 붙이는 비용이 얻는 이익보다 클 수 있다.

한 문장으로 정리하면

Evaluator-Optimizer 패턴은 결과를 한 번에 완벽하게 만들려 하기보다, 평가 기준에 따라 검토하고 다시 고치게 함으로써 더 현실적으로 품질을 끌어올리는 반복 개선 구조다.

핵심은 "생성"이 아니라 "생성 뒤의 판단"에 있다. 초안은 흔들릴 수 있다. 중요한 것은 그 흔들림을 보고 멈출지, 고칠지, 사람에게 넘길지를 결정하는 시스템을 만드는 일이다.

다음 장과의 연결

이번 장에서는 결과를 평가하고, 피드백을 바탕으로 다시 개선하는 루프를 살펴봤다. 좋은 에이전트는 처음부터 완벽해서 강한 것이 아니라, 부족한 결과를 알아차리고 더 나은 방향으로 수렴하게 만들 수 있어서 강하다.

그렇다면 다음 질문이 생긴다. 일을 나누는 구조도 있고, 평가하고 고치는 구조도 있다면, 이제 여러 에이전트를 따로 두고 협업시키면 더 강해질까? 아니면 오히려 복잡성만 늘어날까?

다음 장에서는 바로 그 지점을 다룬다. 멀티에이전트는 언제 필요하고 언제 과한가를 살펴보며, 에이전트를 늘리는 일이 정말 문제를 해결하는지 차분히 따져보자.