Anthropic이 공개한 GAN 영감 멀티 에이전트 하네스 — AI가 혼자 앱을 만들고, 혼자 QA하는 시대

AI 코딩 에이전트에게 "앱 하나 만들어줘"라고 시켰더니 20분 만에 $9로 결과물이 나왔습니다. 근데 핵심 기능이 안 돌아가더라고요. 같은 프롬프트인데 다른 방식으로 돌렸더니 6시간, $200이 들었지만 진짜 작동하는 게임이 나왔습니다. 뭐가 달랐을까요?

🔧 하네스(Harness)가 뭔가요?

Anthropic 엔지니어링 블로그에서 3월 24일 공개한 Harness design for long-running application development가 AI 엔지니어링 커뮤니티에서 큰 반향을 일으키고 있습니다.

하네스란 AI 에이전트가 장시간 자율적으로 작업할 때 감싸는 실행 환경입니다. 프롬프트 엔지니어링이 "무엇을 시킬까"에 집중한다면, 하네스 엔지니어링은 "어떤 환경에서 일하게 할까"에 집중합니다. 쉽게 말해 에이전트가 일하는 사무실을 설계하는 거죠.

🤖 GAN에서 영감을 받은 3-에이전트 아키텍처

Anthropic의 Labs팀 엔지니어 Prithvi Rajasekaran이 설계한 핵심 구조는 GAN(Generative Adversarial Network)에서 영감을 받았습니다. GAN이 생성자와 판별자를 대립시켜 품질을 높이듯, 이 하네스도 역할을 분리합니다.

3-에이전트 구성

1. Planner (기획자) — 사용자의 1~4문장짜리 간단한 프롬프트를 받아 상세한 제품 스펙으로 확장합니다. 여기서 핵심은 세부 기술 구현보다 제품 맥락과 고수준 설계에 집중하는 것. 기획자가 구현 세부사항을 잘못 지정하면 하류 작업에 오류가 전파되니까요.

2. Generator (생성자) — 스프린트 단위로 기능을 하나씩 구현합니다. React + Vite + FastAPI + SQLite 스택으로 작업하고, 각 스프린트 끝에 자체 평가 후 QA에 넘깁니다.

3. Evaluator (평가자) — 가장 혁신적인 부분입니다. Playwright MCP를 사용해 실제 앱을 클릭하고 테스트합니다. UI 기능, API 엔드포인트, DB 상태까지 직접 확인하죠. 마치 실제 QA 엔지니어처럼요.

💡 왜 평가자를 분리해야 하나?

여기서 정말 흥미로운 발견이 있었습니다. AI 모델은 자기가 만든 결과물을 평가하면 거의 항상 후하게 평가합니다. 분명히 버그가 있는데 "별 문제 아니네요"라고 넘기는 거죠. 저도 이거 공감되는 게, Claude한테 "이 코드 괜찮아?"라고 물으면 거의 항상 "좋아 보입니다"라고 하거든요 ㅋㅋ

Anthropic은 이걸 해결하기 위해 생성과 평가를 완전히 분리했습니다. 그리고 중요한 발견:

"별도의 평가자를 엄격하게 튜닝하는 것이, 생성자를 자기비판적으로 만드는 것보다 훨씬 쉽다."

평가자는 Playwright로 앱을 직접 탐색하면서 스크린샷을 찍고, 기능을 테스트한 후 구체적인 점수와 비평을 제공합니다. 한 스프린트에서 평가자가 발견한 버그 예시를 보면:

Contract criterion: 사각형 채우기 도구로 드래그하여 영역을 채울 수 있어야 함
Evaluator finding: FAIL — 도구가 드래그 시작/끝 지점에만 타일을 배치함.
fillRectangle 함수는 존재하지만 mouseUp 이벤트에서 트리거되지 않음.

Contract criterion: 배치된 엔티티 스폰 포인트를 선택하고 삭제할 수 있어야 함
Evaluator finding: FAIL — Delete 키 핸들러(LevelEditor.tsx:892)가
selection과 selectedEntityId 모두 설정되어야 동작.
조건을 selection || (selectedEntityId && activeLayer === 'entity')로 수정 필요.

Contract criterion: API를 통해 애니메이션 프레임 순서를 변경할 수 있어야 함
Evaluator finding: FAIL — PUT /frames/reorder 라우트가 /{frame_id} 이후에 정의됨.
FastAPI가 'reorder'를 frame_id 정수로 파싱하려다 422 에러 반환.

이 수준의 구체적인 버그 리포트라면, 생성자가 즉시 수정할 수 있겠죠.

📊 실제 결과: Solo vs 하네스

Anthropic은 "2D 레트로 게임 메이커를 만들어줘"라는 동일한 프롬프트로 두 가지 방식을 비교했습니다.

Solo 방식은 겉보기엔 괜찮았지만 실제로 게임을 플레이하려 하면 엔티티가 입력에 반응하지 않았습니다. 반면 하네스 방식은 Planner가 16개 기능 스펙을 짜고, Generator가 스프린트별로 구현하고, Evaluator가 매 스프린트마다 Playwright로 실제 테스트를 수행했습니다.

🚀 Opus 4.6으로의 진화: 더 단순하게, 더 강력하게

흥미로운 건 모델이 좋아지면서 하네스도 단순해질 수 있다는 점입니다. 초기 하네스는 Sonnet 4.5용이었는데, 이 모델에는 "컨텍스트 불안(context anxiety)"이라는 문제가 있었습니다. 컨텍스트 윈도우가 차면 작업을 조기에 마무리하려는 경향이죠. 그래서 컨텍스트 리셋이 필수였습니다.

하지만 Opus 4.6에서는 이 문제가 크게 개선되어 스프린트 분해 없이도 2시간 이상 연속 코딩이 가능해졌습니다. 업데이트된 하네스로 "브라우저 기반 DAW(디지털 오디오 워크스테이션)를 만들어줘"라는 프롬프트를 실행한 결과:

에이전트 & 단계        시간         비용
Planner             4.7분       $0.46
Build (Round 1)     2시간 7분    $71.08
QA (Round 1)        8.8분       $3.24
Build (Round 2)     1시간 2분    $36.89
QA (Round 2)        6.8분       $3.09
Build (Round 3)     10.9분      $5.88
QA (Round 3)        9.6분       $4.06
────────────────────────────────────────
Total               3시간 50분   $124.70

결과물은 실제로 멜로디, 드럼 패턴을 만들고, 믹서를 조작하고, Claude 에이전트를 통해 프롬프트로 작곡까지 할 수 있는 DAW였습니다.

🧠 하네스 엔지니어링이 주는 교훈

이 글에서 가장 인상적인 인사이트를 정리하면:

1. "모델이 좋아지면 하네스가 불필요해지는가?" — No.
하네스의 복잡도가 줄어들 수는 있지만, 더 어려운 작업에 도전할 수 있는 공간이 생깁니다. 흥미로운 하네스 조합의 공간은 줄어드는 게 아니라 이동합니다.

2. 하네스의 각 구성요소는 "모델이 혼자 못 하는 것"에 대한 가정이다.
새 모델이 나올 때마다 이 가정을 재검증해야 합니다. 불필요한 부분은 제거하고, 새로운 가능성을 탐색해야 하죠.

3. 프론트엔드 디자인의 주관적 품질도 평가 가능하다.
Anthropic은 4가지 기준(디자인 품질, 독창성, 완성도, 기능성)을 정의하고, 디자인 품질과 독창성에 가중치를 더 줬습니다. "이 디자인이 아름다운가?"보다 "우리의 디자인 원칙을 따르는가?"가 더 일관성 있게 평가할 수 있었습니다.

🔗 실무에 적용하려면?

당장 이 아키텍처를 써볼 수 있는 방법이 있습니다. Anthropic이 이 하네스를 구축한 도구가 바로 Claude Agent SDK입니다. 오케스트레이션을 간단하게 유지하면서도 Generator→Evaluator 피드백 루프를 구현할 수 있죠.

핵심 패턴을 요약하면:

# 개념적 구조 (실제 SDK 사용 시)
# 1. Planner: 간단한 프롬프트 → 상세 스펙
planner_result = run_agent("planner", prompt=user_input)

# 2. Generator + Evaluator 루프
for sprint in planner_result.sprints:
    # Generator가 기능 구현
    build_result = run_agent("generator", spec=sprint)
    
    # Evaluator가 Playwright로 실제 테스트
    qa_result = run_agent("evaluator", app_url=build_result.url)
    
    # 기준 미달이면 피드백 후 재시도
    if not qa_result.passed:
        run_agent("generator", feedback=qa_result.critique)

Mitchell Hashimoto(Terraform 창시자)가 정리한 원칙이 여기서도 통합니다: "에이전트가 실수할 때마다, 그 실수를 다시는 할 수 없도록 하네스를 개선하라."

마무리

프롬프트 엔지니어링 → 컨텍스트 엔지니어링 → 하네스 엔지니어링. AI 엔지니어링의 패러다임이 빠르게 이동하고 있습니다. 이제 "더 좋은 프롬프트를 쓰자"가 아니라 "더 좋은 실행 환경을 만들자"가 핵심이 된 거죠.

$200이 비싸다고요? 진짜 작동하는 풀스택 앱을 4시간 만에 만들어준다면, 저는 기꺼이 지불하겠습니다. 여러분은 어떠신가요?

참고 자료:

• Anthropic Engineering — Harness design for long-running application development (원문)
• Anthropic — Building Effective Agents
• Epsilla — Why Harness Engineering Replaced Prompting in 2026
• Claude Agent SDK (Python)
• GeekNews — 장기 실행 애플리케이션 개발을 위한 하네스 설계