AI(Artificial Intelligence) 에이전트에게 자기가 만든 결과를 평가하라고 하면 품질이 뻔히 평범한데도 자신 있게 칭찬하는 경향이 있다(자기평가 편향). Anthropic은 장기 실행 앱 개발 하네스에서 이를 피하려고 GAN(Generative Adversarial Network, 생성적 적대 신경망)이 생성자와 판별자를 나누는 구조에서 착안해 역할을 셋으로 나눴다.
- 계획자(Planner): 짧은 요청을 자세한 스펙으로 펼친다
- 생성자(Generator): 스펙을 기능 단위로 구현한다
- 평가자(Evaluator): 생성자와 다른 컨텍스트에서 실제로 앱을 써 보며 판정하고 피드백을 돌려준다. 이 사례에서는 Playwright MCP(Model Context Protocol)로 사용자처럼 화면을 눌러 보고 API(Application Programming Interface)와 DB 상태까지 확인했다
flowchart TD
U[짧은 요청] --> P[계획자]
P -- 자세한 스펙 --> G[생성자]
G -- 구현 결과 --> E{평가자}
E -- 피드백 --> G
E -- 통과 --> D[완료]
Opus 4.6에서 같은 하네스의 스프린트 분해는 빠졌지만 계획자와 평가자는 남았다. 글쓴이는 둘 다 여전히 분명한 가치를 더한다고 봤다. 특정 모델의 약점을 메우던 우회책과 달리, 만든 쪽이 스스로 채점하는 편향은 모델이 좋아져도 쉽게 사라지지 않는다 → 하네스 엔지니어링
루브릭
평가자에게 "좋은지 봐 줘"라고 막연히 묻지 않고, 항목과 수준을 미리 정한 채점 기준표(Rubric)를 준다. 그 사례의 프런트엔드 평가 기준은 디자인 품질, 독창성, 완성도(Craft), 기능성 넷이었다. 기준이 명시돼야 평가가 재현 가능하고, 어느 항목에서 떨어졌는지를 생성자에게 구체적인 피드백으로 돌려줄 수 있다. 면접에서 답을 듣기 전에 시그널을 정해 두는 구조적 면접와 같은 생각이다.
평가자도 처음부터 엄격하지 않다. 글쓴이는 평가자의 로그를 읽고 자기 판단과 어긋난 지점을 찾아 프롬프트를 고치는 일을 여러 번 반복했다.
결정론적 검증기 먼저
- 테스트·타입 검사·린터처럼 코드로 확인할 수 있는 것은 코드로 확인한다. 비용이 거의 없고 편향도 없다 → 자가 테스트 코드, 테스트 피라미드
- LLM(Large Language Model) 평가자는 설계 적합성, 가독성, 디자인 감각처럼 기계로 확인하기 어려운 품질에만 쓴다
- 평가자에게는 생성자의 의도나 변명이 아니라 결과물과 기준만 넘긴다
- 평가자는 공짜가 아니다. Anthropic 실험에서 혼자 도는 에이전트는 9달러, 전체 하네스는 200달러였다. 작업이 현재 모델이 혼자 안정적으로 해내는 범위를 넘을 때 붙인다
사람이 하는 코드 리뷰도 같은 구조다. 코드를 쓴 세션과 검토하는 세션을 나누고, 검토하는 쪽은 diff와 기준만 본다. 남이 짠 코드를 리뷰하는 일이 쓰는 일보다 어렵다는 점은 인지 부채와 이해 병목, 리뷰어가 던질 질문은 AI 시대 변경에 대한 책임 질문에서 다룬다. 이 판정 단계가 끼어드는 반복 구조 자체는 에이전트 루프에서 다룬다.
출처: Harness design for long-running application development Prithvi Rajasekaran, Anthropic(2026-03-24)