한 문장짜리 프롬프트로 레트로 게임 메이커를 만들어달라고 요청했을 때, 솔로 에이전트는 20분에 $9를 쓰고 핵심 기능이 작동하지 않는 결과물을 냈습니다. 하네스를 갖춘 멀티에이전트는 6시간에 $200를 쓰고 16개 기능이 모두 동작하는 앱을 완성했습니다.
Anthropic Labs 팀의 Prithvi Rajasekaran이 장기 실행 에이전트 개발에서 하네스(Harness) 설계가 결과를 어떻게 바꾸는지 실험한 과정을 공유했습니다. 프론트엔드 디자인 자동 생성부터 풀스택 앱 자율 개발까지, 에이전트가 혼자 실패하는 두 가지 패턴을 진단하고 이를 구조적으로 해결한 내용입니다.
출처: Harness design for long-running application development – Anthropic Engineering Blog
하네스란 무엇인가
하네스는 에이전트가 작동하는 환경 전체를 설계하는 것입니다. 어떤 도구를 쓸 수 있는지, 컨텍스트를 어떻게 관리하는지, 결과를 누가 검증하는지, 에이전트 간에 어떻게 상태를 전달하는지까지 포함합니다. 모델 자체의 능력이 아니라, 모델을 둘러싼 시스템 설계가 출력 품질을 결정한다는 것이 이 실험의 핵심 전제입니다.
에이전트가 혼자 실패하는 두 가지 이유
Rajasekaran은 긴 작업을 에이전트에게 맡겼을 때 반복적으로 나타나는 실패 패턴 두 가지를 정리했습니다.
첫 번째는 컨텍스트 불안(Context Anxiety)입니다. 컨텍스트 창이 가득 차면 에이전트는 작업이 끝나지 않았는데도 마무리하려는 경향을 보입니다. 컨텍스트를 요약해서 압축하는 방식(compaction)은 이 문제를 완전히 해결하지 못합니다. 압축은 같은 에이전트가 이어가기 때문에 불안이 그대로 남아 있기 때문입니다. 이에 비해 컨텍스트 리셋은 이전 에이전트의 상태를 구조화된 파일로 정리해 새 에이전트에게 넘기고 완전히 깨끗한 상태에서 재시작하는 방식으로, Sonnet 4.5에서는 이 리셋이 필수적이었습니다.
두 번째는 자기평가 편향입니다. 에이전트에게 자신이 만든 결과물을 평가하게 하면, 품질과 무관하게 긍정적으로 채점합니다. 코드처럼 테스트로 검증 가능한 작업에서도 이 경향이 나타나지만, “이 디자인이 아름다운가?”처럼 주관적 판단이 필요한 영역에서는 더욱 두드러집니다. 해결책은 생성과 평가를 담당하는 에이전트를 완전히 분리하는 것입니다. 별도 평가기(Evaluator)는 여전히 관대해질 수 있지만, 독립적인 에이전트를 회의적으로 조율하는 것이 생성기 스스로를 비판적으로 만드는 것보다 훨씬 현실적입니다.
GAN에서 영감 받은 생성기-평가기 구조
Rajasekaran은 GAN(생성적 적대 신경망)에서 아이디어를 가져와 생성기(Generator)와 평가기(Evaluator)를 분리한 멀티에이전트 루프를 설계했습니다. 평가기는 Playwright MCP를 통해 정적 스크린샷이 아닌 실제 페이지를 직접 탐색하며 채점하고, 그 피드백이 생성기에게 다음 반복의 입력으로 들어갑니다.
프론트엔드 디자인 실험에서는 디자인 품질, 독창성, 완성도, 기능성 네 가지 기준을 명문화해 평가기에게 부여했습니다. 특히 독창성에 가중치를 두어 “흰 카드 위 보라색 그라디언트” 같은 AI 클리셰를 명시적으로 패널티 항목으로 지정했습니다. 5~15회 반복을 거친 한 실험에서는 9번째까지 무난한 다크테마 미술관 사이트를 만들던 에이전트가 10번째 사이클에 CSS 원근감으로 구현한 3D 갤러리 공간으로 방향을 완전히 전환했습니다. 단일 생성에서는 나오지 않을 도약이었습니다.
풀스택 앱으로 확장: 플래너-생성기-평가기 3에이전트
같은 원리를 풀스택 개발에 적용하면서 구조는 세 에이전트로 확장됩니다.
- 플래너: 짧은 프롬프트를 받아 상세한 제품 스펙으로 확장. 구체적 구현 방법보다 범위와 방향을 정의하는 데 집중하며, AI 기능을 자연스럽게 녹여 넣는 역할도 맡습니다.
- 생성기: 스펙 기반으로 한 번에 한 기능씩 스프린트 단위로 구현. 각 스프린트 종료 후 평가기에게 넘깁니다.
- 평가기: Playwright로 실제 앱을 사용자처럼 탐색하며 UI, API, 데이터베이스 상태를 테스트. 기준치 미달 항목이 있으면 스프린트를 반려하고 생성기에게 구체적인 피드백을 전달합니다.
스프린트마다 생성기와 평가기가 먼저 “완료 기준”을 협의하는 스프린트 계약 단계도 있었습니다. 코드가 한 줄도 작성되기 전에 무엇을 어떻게 검증할지 합의하는 방식으로, 스펙과 구현 사이의 간극을 줄이는 역할을 했습니다.
레트로 게임 메이커 실험에서 솔로 에이전트 결과물은 게임 자체가 작동하지 않았습니다. 엔티티가 화면에 나타났지만 아무 입력에도 반응하지 않았고, 코드 내부 배선이 끊겨 있었습니다. 하네스 결과물은 스프라이트 에디터, 레벨 에디터, 플레이 모드가 모두 작동했고, Claude 통합으로 프롬프트만으로 게임 요소를 생성하는 기능까지 포함했습니다.
모델이 발전하면 하네스도 달라진다
Anthropic이 강조하는 또 다른 교훈은 하네스가 고정된 정답이 아니라는 점입니다. 하네스의 각 구성 요소는 “모델이 혼자 할 수 없는 것”에 대한 가정을 담고 있고, 모델이 발전하면 그 가정도 검토해야 합니다.
Opus 4.5로 설계된 하네스에서는 컨텍스트 리셋이 필수였지만, Opus 4.6은 컨텍스트 불안이 크게 줄어 리셋 없이 2시간 이상 일관성을 유지하며 작업할 수 있었습니다. 스프린트 구조도 제거했는데, Opus 4.6에서는 분할 없이도 모델이 자체적으로 작업을 관리했습니다. 평가기는 여전히 유효했지만, 모델 역량이 높아질수록 에이전트가 충분히 처리할 수 있는 영역에서는 불필요한 오버헤드가 되기도 했습니다.
DAW(디지털 오디오 워크스테이션) 앱을 만든 두 번째 실험에서 업데이트된 하네스는 3시간 50분, $124.70으로 브라우저에서 작동하는 음악 제작 프로그램을 만들어냈습니다. 전문 수준에는 미치지 못하지만, 에이전트가 템포와 조성을 설정하고 멜로디와 드럼 트랙을 구성하고 믹서 레벨을 조정하는 과정 전체를 프롬프트만으로 처리할 수 있었습니다.
Rajasekaran은 이렇게 마무리합니다. 하네스 설계의 흥미로운 조합 공간은 모델이 발전해도 줄어들지 않는다고요. 단지 이동할 뿐이며, AI 엔지니어의 일은 그 다음 조합을 계속 찾는 것이라고.
원문에는 평가기가 실제로 잡아낸 버그 로그, 각 에이전트 단계별 비용 분석, 플래너가 생성한 스펙 전문이 수록되어 있습니다. 에이전트 시스템을 직접 설계하거나 개선하려는 분들에게 특히 유용한 내용입니다.
답글 남기기