AI 에이전트를 위한 생성자-평가자 루프 (Generator-Evaluator Loops)

요약(TL;DR): 생성자(Generator)와 평가자(Evaluator)를 분리하면 품질이 향상되고 성급한 자기 검증(self-validation)을 줄일 수 있습니다. 이 루프는 피드백이 명시적이고 명확한 루브릭(Rubrics)에 기반할 때, 특히 주관적이거나 복잡한 작업에서 가장 효과적으로 작동합니다. 가치가 높은 작업에는 유용하지만, 단순하거나 쉽게 테스트 가능한 작업의 경우 과잉 엔지니어링(overengineering)이 될 수 있습니다.

정답(Ground Truth)이 없는 작업에서 생산과 평가를 분리하는 방법

만약 자기 평가(self-evaluation)가 AI 에이전트에서 반복되는 실패 모드라면, 가장 자연스러운 해결책은 생산하는 역할과 평가하는 역할을 분리하는 것입니다. 이것이 생성자-평가자 루프(generator-evaluator loops)의 원리입니다. 하나의 에이전트가 출력을 생성하면, 다른 에이전트가 명시적인 기준에 따라 이를 평가하고, 피드백을 생성자에게 다시 보내며, 결과가 허용 가능한 임계값(threshold)에 도달할 때까지 시스템이 반복합니다. 이 패턴은 설명하기는 간단하지만, 안정적인 정답(ground truth)이 존재하지 않는 분야, 즉 디자인, 글쓰기, UX, 네이밍, 전략, 문서화, 소프트웨어 아키텍처, 복잡한 리팩토링(refactoring) 등의 영역에서 매우 강력합니다. 그러나 이러한 경우 모델에게 단순히 "더 잘해봐"라고 요청하는 것만으로는 부족합니다. 별도로 분리되고, 구조화되었으며, 반복 가능한 비판(critique)에 의해 개선이 유도되는 환경을 구축해야 합니다.

단일 에이전트에서 에이전트 시스템(Agentic System)으로

단일 에이전트는 세 가지 서로 다른 역할을 병합하는 경향이 있습니다. 즉, 작업을 계획하고, 출력을 생성하며, 마지막으로 결과를 평가합니다. 이러한 융합은 편리하지만 취약합니다. 짧은 작업에는 효과적일 수 있지만, 긴 작업에서는 종종 성급한 수렴(premature convergence)으로 이어집니다. 왜냐하면 동일한 에이전트가 방향을 선택하고, 이를 개발한 다음, 스스로 긍정적으로 자기 평가를 내리고 작업을 종료해 버리기 때문입니다. 더 견고한 시스템을 만들기 위해서는 이러한 역할들을 최소한 세 가지의 별도 에이전트로 분리해야 합니다: 요청을 관리 가능한 부분으로 나누고 우선순위, 제약 조건 및 작업 순서를 정의하는 플래너(planner); 결과물(artifact)을 생성하는 생성자(generator) (예:

코드, 인터페이스, 문서, 제안서, 전략, ...); 그리고 생성 과정에 참여하지 않고 결과물을 심사하는 평가자(evaluator)입니다. 이러한 분리는 마치 소규모 조직 구조와 매우 유사하며, 실제로 의사결정(decision-making), 생산(production), 승인(approval) 사이의 결합도(coupling)를 낮추는 데 도움을 줍니다. 기업과 마찬가지로 각 역할은 서로 다른 목표를 가지며, 이러한 차이는 유익한 마찰(friction)을 유발합니다.

GANs와의 비유
가장 즉각적인 유사점은 생성적 적대 신경망 (Generative Adversarial Networks, GANs)입니다. 전형적인 GAN에는 두 개의 신경망, 즉 생성자(generator)와 판별자(discriminator)가 존재합니다. 생성자는 이미지와 같은 합성 데이터(synthetic data)를 생성하고, 판별자는 실제 데이터와 생성된 데이터를 모두 받아 그 둘을 구별하려고 시도합니다. 이러한 방식으로 생성자는 판별자를 속일 수 있을 만큼 그럴듯한 결과물을 생성하려고 노력하며 개선되고, 판별자는 인위적인 결과물을 더 잘 탐지하게 되면서 개선됩니다. 이 아이디어는 이미지 생성, 얼굴 합성, 초해상도 (super-resolution), 컴퓨터 비전 (computer vision), 합성 데이터 생성 (synthetic data generation), 이미지 대 이미지 변환 (image-to-image translation), 음악, 비디오 등 많은 영역에 적용되었습니다. StyleGAN, CycleGAN, TextGAN, MuseGAN과 같은 모델들이 그 예이며, 이는 생성적 적대 원리 (generative-adversarial principle)가 어떻게 다양한 형태의 콘텐츠에 적응될 수 있는지를 보여줍니다.

우리의 사례인 AI 에이전트의 경우, 이 비유는 구조적 직관을 포착한다는 점에서 유용합니다. 즉, 생성 시스템은 별도의 판단에 노출될 때 개선된다는 것입니다. 그러나 생성자-평가자 루프가 기술적인 의미에서의 GAN은 아니기 때문에, 이 비교와 혼동해서는 안 될 중요한 측면들이 있습니다. 실제 GAN에는 수학적 손실 함수 (loss function)가 존재합니다. 판별자는 실제 데이터로 학습되는 반면, 생성자는 그래디언트 (gradients)를 통해 최적화 신호를 받습니다. 반면 AI 에이전트에서 피드백은 언어적이고 휴리스틱 (heuristic)입니다. 평가자가 생성자의 가중치 (weights)를 직접 업데이트하지 않으며, 반드시 실제 사례 데이터셋에 접근할 수 있는 것도 아닙니다.

평가자가 랜딩 페이지, 글쓰기, 또는 전략을 판단할 때, 이는 GAN (Generative Adversarial Networks)의 관점에서 "참"과 "거짓"을 구별하는 것이 아닙니다. 대신 출력물이 일련의 선호도, 기준, 그리고 관습(conventions)에 얼마나 밀접하게 부합하는지를 추정하는 것입니다.

주관성을 평가 가능하게 만들기 (Making Subjectivity Evaluatable)
핵심 과제는 모호한 판단을 관찰 가능한 기준으로 전환하는 것입니다. "이 UI는 못생겼다"라고 말하는 것은 에이전트의 개선에 도움이 되지 않습니다. 이는 인간 디자이너에게 똑같이 말해도 도움이 되지 않는 것과 같습니다. 대신 "시각적 계층 구조 (visual hierarchy)가 주요 동작 (primary action)과 보조 콘텐츠 (secondary content)를 충분히 구분하지 못한다"라고 말하는 것이 훨씬 더 유용합니다. 효과적인 평가자에게는 흔히 평가 루브릭 (evaluation rubrics)이라 불리는 것이 필요합니다.

예를 들어 프론트엔드 디자인에서 루브릭은 다음과 같은 네 가지 차원을 포함할 수 있습니다:

1. 디자인 품질 (Design quality): 결과물이 일관된 시스템처럼 느껴지는지, 아니면 단순히 컴포넌트들의 집합에 불과한지를 측정합니다. 시각적 정체성 (visual identity), 창의적 방향성 (creative direction), 색상 사용, 타이포그래피 (typography), 리듬, 그리고 레이아웃을 평가합니다.
2. 독창성 (Originality): 의도적인 선택이 반영되었는지, 아니면 출력이 템플릿, 라이브러리 기본값, 그리고 일반적인 패턴에서 파생된 것처럼 보이는지를 측정합니다 (여기에는 AI 슬롭 (AI slop): 예측 가능한 그라데이션, 흰색 카드, 교체 가능한 히어로 섹션 (hero sections), 스톡 아이콘, 개성 없는 구성 등을 식별하는 것이 포함됩니다).
3. 숙련도 (Craft): 실행력을 측정합니다: 간격 (spacing), 대비 (contrast), 정렬 (alignment), 타이포그래피 계층 구조 (typographic hierarchy), 색상 일관성, 그리고 세부 사항에 대한 주의력을 평가합니다.
4. 기능성 (Functionality): 사용성을 측정합니다: 사용자가 무엇을 해야 하는지 이해하는지, 주요 동작을 찾을 수 있는지, 모호함 없이 탐색할 수 있는지, 그리고 의도된 작업을 완료할 수 있는지를 평가합니다.

이러한 기준들이 모두 동일한 가중치를 가질 필요는 없습니다. 많은 경우, 모델들은 이미 숙련도와 기능성 측면에서 상당히 강력합니다. 즉, 정돈된 레이아웃, 읽기 쉬운 텍스트, 이해 가능한 구조를 생성해냅니다. 반복되는 문제는 종종 독창성과 방향성의 결여입니다. 이러한 이유로, 진정한 품질에 집중하는 평가자는 오류뿐만 아니라 단조로움 (blandness)에 대해서도 페널티를 부여해야 합니다. 동일한 원칙이 다른 도메인에도 적용될 수 있습니다.

글쓰기의 경우, 루브릭 (rubric)은 논지의 강도, 논증 구조, 정보 밀도, 리듬, 구체성, 목소리 (voice), 중복성, 그리고 반론을 예상하는 능력을 평가할 수 있습니다. AI가 생성한 텍스트는 정확하고 유창하며 형식이 잘 갖춰져 있을 수 있지만, 여전히 기억에 남는 내용을 말하는 데 실패할 수 있습니다. 이 경우, 유용한 평가자는 피상적인 명확성과 실제 논증적 가치를 구분할 수 있어야 합니다. 전략의 경우, 루브릭은 진단 품질, 명시적 가정, 트레이드오프 (trade-offs), 실행 가능성, 우선순위 지정, 리스크, 의존성, 지표, 그리고 맥락적 정렬 (contextual alignment)을 평가할 수 있습니다. 그렇다면 코드는 어떨까요? 테스트를 넘어, 루브릭은 단순성, 유지보수성, 코드베이스와의 일관성, 에러 처리, 확장성, 도입된 기술 부채 (technical debt), 가독성, 그리고 기존 추상화에 미치는 영향을 평가해야 합니다.

운영 루프 (The Operational Loop)
전형적인 생성자-평가자 루프는 다음과 같은 단순한 순서를 따릅니다: 시스템이 사양 (specification)을 수신합니다; 플래너 (planner)가 이를 하위 작업으로 나누고 성공 기준을 정의합니다; 생성자 (generator)가 출력물의 첫 번째 버전을 생성합니다; 평가자 (evaluator)가 명시적인 기준을 사용하여 결과물을 검사하며, 가능한 경우 브라우저, 테스트 러너 (test runners), 스크린샷, 파서 (parsers), 린터 (linters), 지표, 문서, 또는 코드베이스에 대한 접근 권한과 같은 실제 도구를 사용합니다; 평가자는 점수를 할당하고, 문제를 식별하며, 실행 가능한 피드백 (actionable feedback)을 생성합니다; 생성자는 피드백을 받고 반복 (iterate)합니다. 이 사이클은 출력이 임계값을 초과하거나, 예산이 소진되거나, 또는 시스템이 인간의 개입이 필요하다고 판단할 때까지 계속됩니다. 루프의 핵심은 실행 가능한 피드백입니다. 왜냐하면 평가자는 실패를 감지할 뿐만 아니라, 그것을 수정 가능하게 만들어야 하기 때문입니다. 생성자-평가자 루프는 근본적으로 하네스 엔지니어링 (harness engineering)의 문제인데, 이는 평가자가 적절한 도구에 접근할 수 있어야 하기 때문입니다. 그렇다고 해서, 평가자가 생성자와 분리되어 있다는 사실만으로 자동으로 개선되는 것은 아닙니다.

이것이 제대로 작동하려면 명시적인 기준 (explicit criteria), 점수 척도 (scoring scales), 잠재적인 퓨샷 예시 (few-shot examples), 임계값 (thresholds) 및 이와 유사한 메커니즘을 사용하여 보정 (calibrated)되어야 합니다. 이 패턴을 사용해야 하는 시점: 생성자-평가자 루프 (generator-evaluator loop)에는 비용이 따릅니다. 더 많은 모델 호출 (model calls), 더 많은 토큰 (tokens), 더 높은 지연 시간 (latency), 더 많은 오케스트레이션 (orchestration), 그리고 더 높은 복잡성 (complexity)이 발생합니다. 결과적으로, 이를 모든 곳에 적용하는 것은 불가능합니다. 경험 법칙 (rule of thumb)에 따르면, 신뢰할 수 있는 자동화된 테스트가 존재한다면 대개 그것을 사용하는 것이 더 좋습니다. 그리고 작업이 단순하거나 가치가 낮다면, 복잡한 루프는 진정으로 과잉 엔지니어링 (overengineering)이 될 수 있습니다.