한 번의 프롬프트로 “브라우저에서 동작하는 DAW를 만들어줘”라고 시키면, 모델은 20분 만에 그럴듯해 보이는 결과물을 내놓습니다. 그런데 막상 실행해 보면 핵심 기능의 배선이 끊어져 있습니다. 왜 이런 일이 벌어지고, 몇 시간짜리 작업을 끝까지 완성도 있게 끌고 가려면 무엇이 필요할까요?
먼저 결론부터 말하면, 열쇠는 더 똑똑한 모델이 아니라 하네스(harness) 설계입니다. Anthropic Labs는 생성적 적대 신경망(GAN)에서 아이디어를 빌려와 “만드는 에이전트”와 “평가하는 에이전트”를 분리했고, 이 구조 하나로 솔로 실행과는 차원이 다른 결과물을 얻었습니다.
2026-07-08 · Anthropic Engineering 글 "Harness design for long-running application development"(2026-03-24 게시, 저자 Prithvi Rajasekaran) 기준. 글에 등장하는 성능·비용 수치와 모델 버전(Opus 4.6)은 해당 시점의 실험 결과입니다.
이 글에서 다루는 내용:
- 장시간 작업에서 모델이 무너지는 두 가지 실패 모드
- GAN에서 빌려온 generator-evaluator 루프가 품질을 끌어올리는 원리
- Planner–Generator–Evaluator 3-에이전트 아키텍처의 역할 분담
- 모델이 좋아지면 하네스를 어떻게 덜어내야 하는가
배경: 왜 하네스가 필요한가?
하네스는 모델을 감싸는 바깥 구조입니다. 프롬프트, 컨텍스트 관리, 도구, 에이전트 간 통신처럼 모델이 혼자서는 안정적으로 못 하는 일을 보조하는 장치의 총합입니다. 이 개념 자체는 2026년 AI 엔지니어링의 5계층에서 “하네스” 계층으로 다룬 적이 있습니다. 이 글은 그 계층을 실제 앱을 몇 시간 동안 만드는 구체적 사례로 풀어냅니다.
에이전트를 여러 개 엮는 이야기는 Agent Teams 가이드에서, 며칠 단위로 비동기 작업을 이어가는 흐름은 Claude Fable 5의 장기 실행 에이전트에서 이미 소개했습니다. 이번 글의 차별점은 generation과 evaluation을 의도적으로 분리해 품질을 끌어올리는 설계 원리에 있습니다.
Anthropic Labs가 관찰한 바에 따르면, 작업 시간이 길어질수록 모델은 두 가지 방식으로 무너집니다.
- 컨텍스트가 채워지며 일관성을 잃는 문제 — 대화가 길어지면 앞부분 맥락을 놓칩니다.
- 컨텍스트 불안(context anxiety) — 모델이 컨텍스트 한계에 다다랐다고 믿으며 작업을 조급하게 마무리해 버리는 현상입니다.
핵심 개념: 생성과 평가를 분리하다
가장 근본적인 문제는 자기 평가의 실패입니다. 글에 따르면 “자신이 만든 결과물을 평가하라고 하면, 에이전트는 사람 눈에는 명백히 평범한 품질인데도 자신 있게 칭찬하는 경향”이 있습니다. 만드는 주체와 평가하는 주체가 같으면 품질 게이트가 작동하지 않는 셈입니다.
여기서 GAN(Generative Adversarial Network)의 아이디어가 등장합니다. GAN이 생성자와 판별자를 경쟁시키듯, 이 하네스는 Generator(생성)와 Evaluator(평가)를 별개 에이전트로 분리합니다.
flowchart LR
G["Generator<br/>결과물 생성"] --> E["Evaluator<br/>기준별 채점"]
E -->|"기준 미달 → 피드백"| G
E -->|"기준 충족"| D["완료"]이 루프의 핵심은 Evaluator가 단순히 “좋다/나쁘다”를 말하지 않는다는 점입니다. Anthropic은 프론트엔드 디자인 실험에서 주관적인 “품질”을 측정 가능한 4가지 기준으로 쪼갰습니다.
| 기준 | 무엇을 보는가 |
|---|---|
| Design quality | 통합된 시각 정체성을 가진 하나의 완결된 결과물인가 |
| Originality | 템플릿·기본값이 아니라 직접 내린 결정의 흔적이 보이는가 |
| Craft | 타이포그래피 위계, 여백, 색 조화, 명도 대비 |
| Functionality | 실제로 쓸 수 있고 작업이 완료되는가 |
흥미롭게도 루프는 craft와 functionality보다 design quality와 originality를 더 높게 가중했습니다. 모델을 뻔한 결과물에서 밀어내기 위해서입니다. Anthropic의 설명 ↗에 따르면 이 평가는 Claude Agent SDK 위에서 Playwright MCP로 구현되어, Evaluator가 “채점 전에 실제로 렌더된 페이지를 직접 조작”할 수 있었습니다.
3-에이전트 아키텍처: Planner, Generator, Evaluator
풀스택 앱처럼 규모가 커지면 Generator–Evaluator 2자 구조만으로는 부족합니다. Anthropic은 여기에 Planner를 앞에 붙인 3-에이전트 구조를 사용했고, 에이전트들은 파일 기반 핸드오프로 소통했습니다. 서로의 응답을 파일로 읽고 쓰면서, 구현을 너무 이르게 못박지 않으면서도 스펙에 충실하도록 만든 것입니다.
flowchart TD
P["Planner<br/>짧은 브리프를 전체 스펙으로 확장"] --> G["Generator<br/>기능을 하나씩 구현 · git 버전 관리"]
G --> E["Evaluator<br/>Playwright로 사용자처럼 테스트"]
E -->|"sprint contract 미충족 → 피드백"| G
E -->|"충족"| Done["빌드 완료"]각 에이전트의 역할은 다음과 같습니다.
- Planner — 짧은 브리프를 완전한 스펙으로 확장합니다. “스코프에 야심을 가지라(ambitious about scope)“는 지시와 함께 AI 기능까지 스펙에 엮되, 오류가 연쇄될 수 있는 세부 기술 결정은 미루도록 했습니다.
- Generator — 기능을 한 번에 하나씩(one-at-a-time) 구현합니다. 스택은 React, Vite, FastAPI, SQLite(이후 PostgreSQL)였고, QA로 넘기기 전 스스로 점검합니다.
- Evaluator — Playwright MCP로 실행 중인 앱을 “사용자가 하듯” 테스트합니다. 구현 착수 전에 “done이 어떤 모습인지”를 협상하는 sprint contract를 먼저 맺었습니다.
솔로 vs 하네스: 레트로 게임 메이커
두 방식의 차이는 수치로 명확히 드러납니다.
| 구분 | 시간 | 비용 | 결과 |
|---|---|---|---|
| 솔로 실행 | 20분 | $9 | 엔티티 정의와 게임 런타임 사이 배선이 끊김 |
| 풀 하네스 | 6시간 | $200 | 물리 엔진, 스프라이트 애니메이션, 행동 템플릿, AI 기반 생성이 동작하는 플레이 가능한 게임 |
솔로 버전은 빠르고 저렴하지만 핵심 기능이 작동하지 않았습니다. 하네스 버전은 30배 넘는 비용을 치르는 대신 실제로 플레이할 수 있는 완성품을 만들어냈습니다. 트레이드오프가 분명합니다.
모델이 좋아지면 하네스도 바뀐다
이 글에서 가장 중요한 통찰은 마지막에 있습니다.
하네스의 모든 구성 요소는 “모델이 혼자서는 못 하는 것”에 대한 가정을 담고 있으며, 그 가정은 스트레스 테스트할 가치가 있다.
Opus 4.6로 실험을 다시 돌리자, Anthropic은 sprint decomposition(스프린트 분해)을 통째로 제거하고 Planner와 Evaluator(빌드 종료 시점 QA)만 남겼습니다. Opus 4.6가 계획, 지속적 에이전트 작업, 코드베이스 조작, 코드 리뷰, long-context retrieval에서 나아지면서 그만큼 발판(scaffolding)이 덜 필요해졌기 때문입니다.
단순화한 하네스로 “Web Audio API로 브라우저 DAW를 만들어줘”를 실행한 결과입니다.
| 항목 | 값 |
|---|---|
| 소요 시간 | 3시간 50분 |
| 비용 | $124.70 |
| 연속 빌드 시간 | 2시간 이상 (스프린트 분해 없이) |
작동하는 arrangement view·믹서·transport를 갖췄고, 에이전트가 도구 호출로 간단한 곡을 스스로 작곡할 수도 있었습니다. 그럼에도 Evaluator는 오디오 녹음이 stub 수준에 그친 점, 클립 리사이즈/분할 미구현, EQ 커브 없이 숫자 슬라이더로만 표현된 이펙트 시각화 같은 미완성 지점을 잡아냈습니다. 하네스를 덜어내도 평가자는 여전히 마지막 품질 게이트로 작동한 셈입니다.
마무리
이 사례가 주는 실천적 교훈은 네 가지입니다.
- 현실적인 문제로 모델을 실험하고 원하는 결과가 나오도록 성능을 튜닝하라.
- 복잡한 작업을 쪼개고, 각 측면에 특화된 에이전트를 배치하라.
- 새 모델이 나올 때마다 하네스를 다시 뜯어보고, 더 이상 하중을 받지 않는(load-bearing) 조각은 걷어내라.
- 하네스 조합의 공간은 모델이 좋아진다고 줄어들지 않는다. 다만 이동한다.
만드는 주체와 평가하는 주체를 분리하는 것, 그리고 모델이 커질수록 스캐폴딩을 덜어내는 것—이 두 원리는 규모와 무관하게 적용됩니다. 여러분이 다음에 긴 자동화 작업을 설계한다면, “이 단계는 정말 모델이 혼자 못 하는가?”를 먼저 물어보는 것에서 시작할 수 있습니다.
관련 내부 포스트:
- From Code to System: 2026년 AI 엔지니어링의 5계층 — 하네스를 5계층 중 하나로 조망한 큰 그림
- Claude Code Agent Teams 완벽 가이드 — 여러 에이전트를 역할별로 협업시키는 실전 도구
- Claude Fable 5: 며칠 동안 일하는 AI 에이전트 — 장기 비동기 작업으로 관점을 넓힌 사례
참고 자료
- Harness design for long-running application development ↗ — Anthropic Engineering, 본문 전 구간의 1차 출처 (2026-03-24)
- From Code to System: AI 엔지니어링의 5계층 — 하네스 계층의 개념적 배경
- Claude Code Agent Teams 가이드 — 다중 에이전트 협업 실전