배경 및 문제 의식

Anthropic Labs의 Prithvi Rajasekaran이 2026년 3월 24일 공개한 이 엔지니어링 블로그 포스트는, Claude가 장시간에 걸쳐 복잡한 애플리케이션을 자율적으로 구축할 때 발생하는 두 가지 핵심 문제를 다룬다.

첫 번째 문제는 컨텍스트 손실이다. 모델이 긴 작업을 수행하면서 컨텍스트 윈도우가 채워질수록 초기 설계 의도와의 일관성을 잃게 된다. 두 번째는 자기 평가의 한계로, 모델이 자신이 생성한 결과물을 평가할 때 과도하게 긍정적으로 평가하는 경향이 있다는 점이다.

이 두 문제를 해결하기 위해 저자는 GAN(Generative Adversarial Network)에서 영감을 받은 멀티 에이전트 하네스 구조를 제안한다.

핵심 아키텍처: 3단 에이전트 시스템

Planner (기획자)

사용자의 1~4문장 입력을 상세한 제품 사양서로 확장한다. 단순 프롬프트를 구조화된 요구사항으로 변환하는 역할.

Generator (생성자)

React + Vite + FastAPI + SQLite/PostgreSQL 스택을 기반으로 실제 코드를 작성한다. 스프린트 단위로 기능을 구현하며, 각 스프린트마다 평가자와 '계약 협상'을 통해 완료 기준에 합의한다.

Evaluator (평가자)

Playwright MCP를 사용하여 실행 중인 애플리케이션과 실제로 상호작용하면서 테스트한다. 4가지 기준으로 채점:

• Design Quality — 색상, 타이포그래피, 레이아웃의 통일성
• Originality — 템플릿/기본값이 아닌 맞춤형 결정의 증거
• Craft — 타이포그래피 계층, 간격 일관성, 색상 조화 등 기술적 실행력
• Functionality — 사용자가 주요 작업을 완료할 수 있는지

계약 협상(Contract Negotiation) 시스템

이 글에서 가장 독창적인 개념 중 하나다. 코드 생성 전에 평가자와 생성자가 "완료"의 정의에 대해 합의하는 과정을 거친다. 저자에 따르면 "스프린트당 27개 기준 같은 세부적 계약으로 구체적 발견이 가능"하다고 한다.

이는 단순히 "잘 만들어라"가 아니라, 무엇이 "잘 만든 것"인지를 사전에 정량화하는 접근이다. 인간 소프트웨어 개발에서의 Definition of Done과 유사하지만, AI 에이전트 간에 자동으로 협상된다는 점이 다르다.

성능 비교: 단일 에이전트 vs 하네스

Retro Game Maker 사례를 통한 비교:

비용은 22배 증가했지만, 결과물의 품질 차이는 "사용 불가 vs 완전한 제품" 수준이다.

Opus 4.6에서의 하네스 단순화

모델이 개선되면서 하네스도 진화했다. Opus 4.6 기반에서는:

• 스프린트 구조 제거: 모델 자체의 장기 일관성이 개선되어 불필요해짐
• 평가자 단일 패스: 종료 시점에만 1회 실행
• 2시간 연속 빌드: 컨텍스트 리셋 없이 연속 작업 가능

DAW(디지털 오디오 워크스테이션) 빌드 결과: 3시간 50분, $124.70으로 완전한 음악 제작 프로그램(녹음, 믹싱, AI 작곡 지원)을 생성했다. 다만 평가자가 클립 드래그, 악기 UI 패널, 시각적 이펙트 편집기 부재 등 기능 격차를 여전히 적발했다.

핵심 설계 교훈

1. 간단한 솔루션으로 시작, 필요할 때만 복잡성 추가 — 각 하네스 구성요소는 모델의 부족함을 나타내는 지표
2. 분리된 평가자가 통합 자체평가보다 효과적 — 실시간 반복 피드백의 강력함
3. 모델 개선에 따른 하네스 재평가 필요 — Opus 4.6은 Sonnet 4.5보다 더 적은 스캐폴딩 필요
4. 구체적 기준의 은연중 영향 — "박물관 품질 같은 디자인" 같은 언어 선택이 출력 특성을 형성

저자의 결론: "모델이 개선됨에 따라 흥미로운 하네스 조합의 공간이 축소되지 않고 이동한다." AI 엔지니어의 역할은 이 이동하는 공간에서 새로운 최적 조합을 계속 발견하는 것이다.