GAN에서 빌려온 하네스 설계: Claude로 몇 시간짜리 앱을 만드는 법

“브라우저에서 동작하는 DAW를 만들어줘”라고 한 번만 시키면, 모델은 20분 만에 그럴듯한 결과물을 내놓습니다. 그런데 실행해 보면 핵심 기능끼리 연결이 끊어져 있습니다.

Anthropic Labs는 몇 시간짜리 작업을 끝까지 완성하는 방법을 모델 성능보다 하네스(harness) 설계에서 찾았습니다. 생성적 적대 신경망(GAN)에서 아이디어를 빌려 “만드는 에이전트”와 “평가하는 에이전트”를 나눴습니다. 그 결과 에이전트 하나로 실행할 때 동작하지 않던 기능이 동작하는 앱을 얻었습니다.

이 글에서 다루는 내용:

• 장시간 작업에서 모델이 무너지는 두 가지 실패 모드
• 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 TD
    G["Generator<br/>결과물 생성"] --> E["Evaluator<br/>기준별 채점"]
    E -->|"기준 미달 → 피드백"| G
    E -->|"기준 충족"| D["완료"]

Evaluator는 “좋다/나쁘다”만 말하지 않고 기준별로 채점합니다. Anthropic은 프론트엔드 디자인 실험에서 주관적인 “품질”을 측정할 수 있는 기준 4가지로 나눴습니다.

가중치는 craft와 functionality보다 design quality와 originality에 더 줬습니다. 모델이 뻔한 결과물을 내지 않게 하기 위해서입니다. Anthropic의 설명 ↗에 따르면 Evaluator는 Claude Agent SDK와 Playwright MCP로 만들었습니다. 그래서 “채점 전에 실제로 렌더된 페이지를 직접 조작”할 수 있었습니다.

3-에이전트 아키텍처: Planner, Generator, Evaluator

풀스택 앱처럼 규모가 커지면 Generator와 Evaluator 둘로는 부족합니다. 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 하네스: 레트로 게임 메이커

같은 요청을 두 방식으로 실행한 결과입니다.

솔로 실행은 빠르고 저렴했지만 핵심 기능이 작동하지 않았습니다. 풀 하네스는 비용이 약 22배 들었지만 실제로 플레이할 수 있는 게임을 만들었습니다.

모델이 좋아지면 하네스도 바뀐다

원문의 마지막 부분은 하네스를 언제 줄일지 다룹니다.

하네스의 모든 구성 요소는 “모델이 혼자서는 못 하는 것”에 대한 가정을 담고 있으며, 그 가정은 스트레스 테스트할 가치가 있다.

Opus 4.6으로 실험을 다시 하면서 Anthropic은 스프린트 분해(sprint decomposition)를 통째로 뺐습니다. Planner와 Evaluator(빌드가 끝날 때의 QA)만 남겼습니다. Opus 4.6은 계획, 긴 에이전트 작업, 코드베이스 조작, 코드 리뷰, long-context retrieval이 나아져서 발판(scaffolding)이 덜 필요했습니다.

단순화한 하네스로 “Web Audio API로 브라우저 DAW를 만들어줘”를 실행한 결과입니다.

완성된 앱에서는 arrangement view, 믹서, transport가 동작했습니다. 에이전트가 도구 호출로 간단한 곡을 작곡할 수도 있었습니다. 그래도 Evaluator는 미완성 부분을 찾아냈습니다. 오디오 녹음은 stub 수준이었고, 클립 크기 조절과 분할은 없었고, 이펙트는 EQ 커브 없이 숫자 슬라이더로만 표시됐습니다. 하네스를 줄여도 Evaluator는 마지막 품질 검사 역할을 했습니다.

마무리

원문이 정리한 교훈은 네 가지입니다.

1. 현실적인 문제로 모델을 실험하고, 원하는 결과가 나올 때까지 조정합니다.
2. 복잡한 작업을 나누고, 측면마다 전담 에이전트를 둡니다.
3. 새 모델이 나올 때마다 하네스를 다시 점검하고, 더 이상 하중을 받지 않는(load-bearing) 부분은 걷어냅니다.
4. 모델이 좋아져도 하네스를 조합할 여지는 줄지 않고 옮겨 갑니다.

만드는 에이전트와 평가하는 에이전트를 나누고, 모델이 좋아질수록 발판을 덜어냅니다. 이 두 원리는 작업 규모와 관계없이 적용됩니다. 긴 자동화 작업을 설계할 때는 단계마다 “이 단계는 정말 모델이 혼자 못 하는가?”부터 확인합니다.

관련 내부 포스트:

• 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)

2026년 9월 26일 수정: 문장을 짧고 직접적으로 다듬었습니다. 솔로 실행 대비 하네스 비용 배수를 “30배 넘는”에서 “약 22배”($9 → $200)로 바로잡았고, 관련 글과 겹치던 참고 자료 두 항목을 정리했습니다.