Context Vault

장기 실행 애플리케이션 개발을 위한 하네스 설계 (Anthropic)

8 min read

장기 실행 애플리케이션 개발을 위한 하네스 설계

Anthropic이 GAN에서 영감을 받은 멀티 에이전트 구조로 프론트엔드 디자인 품질 향상과 장기 자율 코딩을 동시에 해결.

핵심 아이디어

  • 생성기(Generator) + 평가기(Evaluator) 분리
  • 주관적 디자인 품질을 구체적 기준으로 채점
  • 에이전트의 자기 평가 편향 문제 해결

두 가지 실패 모드

1. 컨텍스트 불안 (Context Anxiety)

  • 컨텍스트 윈도우가 채워지면 모델이 일관성 상실
  • 컨텍스트 한계에 도달했다고 판단하면 작업을 조기 마무리하려는 경향

해결:

  • 컨텍스트 리셋 — 윈도우 전체를 비우고 구조화된 핸드오프로 새 에이전트 시작
  • 컴팩션(compaction)과 다름 — 컴팩션은 연속성 유지하지만 클린 슬레이트 제공 안 함

2. 자기 평가 문제 (Self-evaluation)

  • 에이전트가 자신의 결과물을 평가하면 품질이 평범해도 자신감 있게 칭찬
  • 디자인 같은 주관적 태스크에서 특히 심각

해결:

  • 작업 에이전트와 평가 에이전트 분리
  • 독립된 평가기를 회의적으로 튜닝하는 게 생성기를 자기 비판적으로 만드는 것보다 쉬움

프론트엔드 디자인: 4가지 채점 기준

기준설명가중치
디자인 품질색상, 타이포그래피, 레이아웃이 결합하여 일관된 전체인지높음
독창성커스텀 결정의 증거 vs 템플릿/AI 생성 패턴 (보라색 그래디언트 등은 실패)높음
완성도타이포그래피 위계, 간격 일관성, 색상 조화, 대비 비율중간
기능성사용자가 인터페이스를 이해하고 주요 액션을 찾을 수 있는지중간

핵심: “이 디자인이 아름다운가?”보다 “이것이 좋은 디자인 원칙을 따르는가?”가 일관된 채점에 유리

실행 방식

  • Claude Agent SDK로 오케스트레이션
  • 생성기: HTML/CSS/JS 프론트엔드 생성
  • 평가기: Playwright MCP로 라이 페이지와 상호작용, 스크린샷, 채점, 비평
  • 생성당 5~15회 반복
  • 전체 실행 최대 4시간

결과

  • 점수는 일반적으로 반복에 걸쳐 향상되지만 항상 선형은 아님
  • 중간 반복을 선호하는 경우도 빈번
  • 창의적 도약 — 네덜란드 미술관 사례: 10번째 반복에서 CSS 퍼스펙티브 3D 룸으로 전면 재구상

풀스택 코딩: 3-에이전트 아키텍처

Planner → Generator → Evaluator

플래너 (Planner)

  • 1~4문장의 간단한 프롬프트를 전체 제품 스펙으로 확장
  • 제품 컨텍스트와 상위 기술 설계에 집중
  • 세부 기술 사항을 사전 지정하면 오류가 다운스트림으로 전파될 우려
  • AI 기능을 제품 스펙에 직조할 기회를 찾도록 지시

생성기 (Generator)

  • 스프린트 단위로 스펙에서 기능 하나씩 픽업
  • React/Vite/FastAPI/SQLite 스택으로 구현
  • 각 스프린트 종료 시 자기 평가 후 QA에 핸드오프
  • git으로 버전 관리

평가기 (Evaluator)

  • Playwright MCP로 실행 중인 앱을 실제 사용자처럼 클릭스루
  • UI 기능, API 엔드포인트, DB 상태 테스트
  • 제품 깊이, 기능성, 시각 디자인, 코드 품질 기준으로 채점
  • 기준별 하드 임계값 미달 시 스프린트 실패

스프린트 계약 (Sprint Contract)

  • 각 스프린트 전에 생성기와 평가기가 “완료” 정의에 합의
  • 제품 스펙이 상위 수준이었기 때문에 사용자 스토리와 테스트 가능한 구현 간극 메우는 단계

실험 결과: 레트로 게임 메이커

항목솔로 에이전트풀 하네스
시간20분6시간
비용$9$200
결과게임 작동 안 함실제 플레이 가능

하네스 결과 상세

  • 플래너가 한 문장 프롬프트를 10개 스프린트, 16개 기능 스펙으로 확장
  • 스프라이트 애니메이션, 행동 템플릿, 사운드, AI 보조 스프라이트 생성기, 게임 내보내기 포함
  • 캔버스가 전체 뷰포트 활용, 일관된 시각적 정체성
  • 플레이 모드에서 실제로 엔티티 이동하고 게임 플레이 가능

평가기 튜닝의 중요성

  • 기본 상태에서 Claude는 열악한 QA 에이전트
  • 정당한 이슈를 발견하고도 “별 문제 아니다”고 승인하는 경향
  • 피상적 테스트로 미묘한 버그를 놓침
  • 평가기 로그를 읽고 판단이 diverge하는 사례를 찾아 QA 프롬프트를 업데이트하는 개발 루프 필요

Opus 4.6으로 단순화

변화이유
스프린트 구조 제거Opus 4.6이 분해 없이도 작업을 일관되게 처리 가능
플래너 유지없으면 스코프 부족, raw 프롬프트로 스펙 없이 빌드 시작
평가기 → 종료 시 단일 패스태스크가 모델 단독 능력 범위 내면 불필요한 오버헤드

업데이트된 하네스: 브라우저 DAW

  • 프롬프트: “Web Audio API로 브라우저에서 완전한 기능의 DAW를 빌드하라”
  • 결과: 4시간, $124.70
  • 빌더가 스프린트 분해 없이 2시간 이상 일관되게 실행
  • 작동하는 어레인지먼트 뷰, 믹서, 트랜스포트 포함
  • 프롬프팅만으로 짧은 곡 스니펫 제작 가능

핵심 교훈

  1. 빌드 대상 모델을 실험 — 현실적 문제에서 트레이스를 읽고 튜닝
  2. 복잡한 태스크는 분해 — 각 측면에 특화된 에이전트 적용
  3. 새 모델 출시 시 하네스 재검토 — 더 이상 부하를 지탱하지 않는 부분 제거, 새 부분 추가
  4. 모델이 향상되어도 흥미로운 하네스 조합의 공간은 줄어들지 않고 이동

그래프 뷰