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

• Anthropic이 프론트엔드 디자인 품질 향상과 장기 자율 코딩이라는 두 가지 문제를 동시에 해결하기 위해 GAN에서 영감을 받은 멀티 에이전트 구조를 개발
• 생성기(generator)와 평가기(evaluator) 를 분리하는 구조로, 주관적 디자인 품질을 구체적 기준으로 채점 가능하게 만들어 에이전트의 자기 평가 편향 문제를 해결
• 플래너-생성기-평가기의 3-에이전트 아키텍처로 멀티 시간 자율 코딩 세션에서 풀스택 애플리케이션을 완성하며, 스프린트 계약 협상과 Playwright 기반 QA를 포함
• Opus 4.5에서 Opus 4.6으로 전환하면서 스프린트 분할 없이도 2시간 이상 일관된 코딩이 가능해져, 하네스 복잡도를 줄이면서도 성능을 유지
• 모델 성능이 향상되더라도 흥미로운 하네스 조합의 공간은 줄어들지 않고 이동하며, AI 엔지니어의 핵심 과제는 새로운 조합을 찾아내는 것

---

단순 구현이 한계에 부딪히는 이유

• 이전 실험에서 초기화 에이전트가 제품 스펙을 태스크 리스트로 분해하고, 코딩 에이전트가 기능 하나씩 구현한 뒤 아티팩트를 통해 세션 간 컨텍스트를 전달하는 방식을 사용
  • 개발자 커뮤니티에서도 "Ralph Wiggum" 방식처럼 훅이나 스크립트로 에이전트를 지속 반복 루프에 유지하는 유사한 접근법이 등장
• 복잡한 태스크에서 에이전트가 시간이 지남에 따라 궤도를 이탈하는 문제가 지속되었으며, 두 가지 공통 실패 모드를 관찰
• 첫 번째 실패 모드: 컨텍스트 윈도우가 채워지면서 모델이 일관성을 잃고, 일부 모델은 "컨텍스트 불안(context anxiety)" 현상으로 자신의 컨텍스트 한계에 도달했다고 판단하면 작업을 조기에 마무리하려는 경향 발생
  • 컨텍스트 리셋(컨텍스트 윈도우 전체를 비우고 이전 에이전트 상태와 다음 단계를 포함한 구조화된 핸드오프로 새 에이전트를 시작)이 두 문제를 모두 해결
  • 이는 대화의 이전 부분을 요약하여 동일 에이전트가 계속 진행하는 컴팩션(compaction) 과 다른 접근법으로, 컴팩션은 연속성을 유지하지만 클린 슬레이트를 제공하지 않아 컨텍스트 불안이 지속될 수 있음
  • Claude Sonnet 4.5에서 컨텍스트 불안이 너무 강해 컴팩션만으로는 장기 태스크 성능을 보장할 수 없었기 때문에 컨텍스트 리셋이 하네스 설계의 핵심 요소가 됨
• 두 번째 실패 모드: 자기 평가(self-evaluation) 문제로, 에이전트가 자신이 만든 결과물을 평가하면 품질이 명백히 평범하더라도 자신감 있게 칭찬하는 경향
  • 특히 디자인 같은 주관적 태스크에서 심각하며, 검증 가능한 소프트웨어 테스트에 해당하는 이진 검사가 없음
  • 작업 에이전트와 평가 에이전트를 분리하는 것이 강력한 레버이며, 독립된 평가기를 회의적으로 튜닝하는 것이 생성기를 자기 비판적으로 만드는 것보다 훨씬 다루기 쉬움

프론트엔드 디자인: 주관적 품질을 채점 가능하게 만들기

• 개입 없이 Claude는 기술적으로 기능하지만 시각적으로 평범한 안전하고 예측 가능한 레이아웃을 기본 생성
• 두 가지 핵심 통찰이 하네스 설계를 이끔
  • 미학을 완전히 점수화할 수는 없지만, 디자인 원칙과 선호도를 인코딩한 채점 기준으로 개선 가능 — "이 디자인이 아름다운가?"보다 "이것이 좋은 디자인 원칙을 따르는가?"가 일관된 채점에 유리
  • 프론트엔드 생성과 채점을 분리하여 생성기를 더 강한 결과물로 이끄는 피드백 루프 생성
• 생성기와 평가기 모두에게 제공한 4가지 채점 기준:
  • 디자인 품질(Design quality): 색상, 타이포그래피, 레이아웃, 이미지 등이 결합하여 뚜렷한 분위기와 정체성을 만드는 일관된 전체인지 여부
  • 독창성(Originality): 커스텀 결정의 증거가 있는지, 아니면 템플릿 레이아웃, 라이브러리 기본값, AI 생성 패턴인지 — 보라색 그래디언트 위 흰색 카드 같은 AI 생성 징후가 있으면 실패
  • 완성도(Craft): 타이포그래피 위계, 간격 일관성, 색상 조화, 대비 비율 등 기술적 실행 — 창의성이 아닌 역량 검사
  • 기능성(Functionality): 미학과 독립적인 사용성 — 사용자가 인터페이스가 무엇을 하는지 이해하고 주요 액션을 찾을 수 있는지
• 디자인 품질과 독창성을 완성도와 기능성보다 더 높게 가중치 설정 — Claude가 완성도와 기능성에서는 기본적으로 높은 점수를 받았지만, 디자인과 독창성에서 평범한 결과물을 내놓았기 때문
  • 기준이 매우 일반적인 "AI 슬롭" 패턴을 명시적으로 감점하여 모델이 미적 위험 감수를 하도록 유도
• Claude Agent SDK로 오케스트레이션을 구축, 생성기가 HTML/CSS/JS 프론트엔드를 생성하고, 평가기가 Playwright MCP로 라이브 페이지와 직접 상호작용하며 스크린샷을 찍고 구현을 꼼꼼히 살펴본 후 채점 및 상세 비평을 작성
  • 생성당 5~15회 반복, 각 반복에서 평가기의 비평에 응답하며 생성기가 더 독특한 방향으로 이동
  • 전체 실행이 최대 4시간까지 소요
  • 생성기에게 각 평가 후 전략적 결정을 내리도록 지시: 점수 추세가 좋으면 현재 방향 개선, 접근법이 작동하지 않으면 완전히 다른 미학으로 전환
• 기준의 문구가 생성기에 예상치 못한 방식으로 영향 — "최고의 디자인은 뮤지엄 퀄리티" 같은 문구가 특정 시각적 수렴을 유도, 기준과 연관된 프롬프팅이 산출물의 캐릭터를 직접 형성
• 점수가 일반적으로 반복에 걸쳐 향상되었지만 항상 선형은 아니었으며, 마지막 반복보다 중간 반복을 선호하는 경우도 빈번
  • 구현 복잡성이 반복에 걸쳐 증가하는 경향, 평가기 피드백에 응답하여 더 야심적인 솔루션을 추구
  • 첫 반복에서부터 프롬프팅 없는 기본선보다 눈에 띄게 좋은 결과, 기준과 관련 언어 자체가 평가기 피드백 이전에도 모델을 일반적 기본값에서 벗어나게 유도
• 네덜란드 미술관 웹사이트 사례: 9번째 반복까지 깔끔한 다크 테마 랜딩 페이지를 만들었다가, 10번째 반복에서 접근법을 전면 폐기하고 CSS 퍼스펙티브로 렌더링된 3D 룸, 체커보드 바닥, 벽에 자유롭게 걸린 작품, 문을 통한 갤러리 간 내비게이션이라는 공간 경험으로 재구상 — 단일 패스 생성에서 보지 못했던 유형의 창의적 도약

풀스택 코딩으로 확장

아키텍처

• 이전 장기 실행 하네스에서 초기화 에이전트, 기능별 코딩 에이전트, 세션 간 컨텍스트 리셋으로 일관된 멀티 세션 코딩을 해결
  • Sonnet 4.5의 컨텍스트 불안 때문에 컨텍스트 리셋이 핵심이었지만, Opus 4.5에서는 이 행동이 대부분 제거되어 컨텍스트 리셋 없이 하나의 연속 세션으로 전체 빌드를 수행
  • Claude Agent SDK의 자동 컴팩션이 컨텍스트 증가를 처리
• 3-에이전트 시스템 구성:
  • 플래너(Planner): 1~4문장의 간단한 프롬프트를 전체 제품 스펙으로 확장 — 세부 기술 구현보다 제품 컨텍스트와 상위 기술 설계에 집중하도록 프롬프팅, 세부 기술 사항을 사전 지정하면 오류가 다운스트림으로 전파될 우려 때문
    • AI 기능을 제품 스펙에 직조(weave) 할 기회를 찾도록 지시
  • 생성기(Generator): 스프린트 단위로 스펙에서 기능 하나씩 픽업, React/Vite/FastAPI/SQLite(이후 PostgreSQL) 스택으로 구현, 각 스프린트 종료 시 자기 평가 후 QA에 핸드오프, git으로 버전 관리
  • 평가기(Evaluator): Playwright MCP로 실행 중인 애플리케이션을 실제 사용자처럼 클릭스루하여 UI 기능, API 엔드포인트, 데이터베이스 상태를 테스트 — 제품 깊이, 기능성, 시각 디자인, 코드 품질 기준으로 채점, 기준별 하드 임계값 미달 시 스프린트 실패
• 각 스프린트 전에 생성기와 평가기가 스프린트 계약(sprint contract)을 협상 — 코드 작성 전에 해당 작업 청크의 "완료" 정의에 합의
  • 제품 스펙이 의도적으로 상위 수준이었기 때문에, 사용자 스토리와 테스트 가능한 구현 사이의 간극을 메우는 단계
  • 커뮤니케이션은 파일 기반으로 처리 — 한 에이전트가 파일을 쓰면 다른 에이전트가 읽고 응답

하네스 실행 결과: 레트로 게임 메이커

• "레벨 에디터, 스프라이트 에디터, 엔티티 행동, 플레이 가능한 테스트 모드를 포함한 2D 레트로 게임 메이커를 만들어라"는 프롬프트로 테스트
• 솔로 에이전트: 20분 / $9 vs 풀 하네스: 6시간 / $200 — 하네스가 20배 이상 비쌌지만 결과물 품질 차이가 즉각적으로 명확
• 솔로 실행 결과: 초기 화면은 기대에 부합했으나 클릭하면서 문제 노출 — 레이아웃이 공간 낭비, 워크플로우 경직, 스프라이트와 엔티티를 먼저 만들어야 하지만 UI가 안내하지 않음, 핵심인 실제 게임이 작동하지 않음(엔티티가 화면에 나타나지만 입력에 반응 없음, 엔티티 정의와 게임 런타임 간 배선이 끊어짐)
• 하네스 실행 결과: 플래너가 한 문장 프롬프트를 10개 스프린트에 걸친 16개 기능 스펙으로 확장 — 스프라이트 애니메이션 시스템, 행동 템플릿, 사운드 이펙트와 음악, AI 보조 스프라이트 생성기와 레벨 디자이너, 공유 가능한 링크로 게임 내보내기 포함
  • 프론트엔드 디자인 스킬을 읽고 앱의 시각 디자인 언어를 스펙의 일부로 생성
  • 캔버스가 전체 뷰포트 활용, 패널 크기 합리적, 스펙의 디자인 방향을 따르는 일관된 시각적 정체성
  • 스프라이트 에디터가 더 풍부하고 완전한 기능, 더 깔끔한 도구 팔레트, 더 나은 색상 선택기, 더 사용 가능한 줌 컨트롤
  • AI 통합으로 프롬프팅을 통해 게임의 다양한 부분을 생성하여 워크플로우 가속
• 플레이 모드에서의 핵심 차이: 솔로 실행은 게임이 작동하지 않았지만, 하네스 실행에서는 실제로 엔티티를 이동하고 게임을 플레이 가능 — 물리 엔진에 약간의 거칠함(플랫폼과 캐릭터 겹침)과 AI 레벨 구성 한계(점프할 수 없는 큰 벽)가 있었으나 핵심 기능은 작동
• 평가기가 구현을 스펙에 맞게 유지하는 역할 수행 — Sprint 3만 해도 레벨 에디터에 대해 27개 기준을 커버하는 세분화된 계약
  • 발견한 이슈 예시: 사각형 채우기 도구가 드래그 시작/끝 지점에만 타일을 배치, 엔티티 삭제 키 핸들러의 조건 오류, FastAPI 라우트 순서 문제로 reorder를 정수로 파싱하여 422 에러 반환
• 평가기 튜닝에 상당한 노력 필요 — 기본 상태에서 Claude는 열악한 QA 에이전트로, 정당한 이슈를 발견하고도 스스로를 설득하여 "별 문제 아니다"고 승인하는 경향, 피상적 테스트로 미묘한 버그를 놓침
  • 평가기 로그를 읽고 판단이 diverge하는 사례를 찾아 QA 프롬프트를 업데이트하는 개발 루프를 수 차례 반복 후에야 합리적 채점 달성

하네스 반복 개선

• 초기 결과가 고무적이었지만 크고, 느리고, 비쌌기 때문에 성능 저하 없이 하네스를 단순화하는 것이 다음 단계
  • 하네스의 모든 구성 요소는 모델이 혼자 할 수 없는 것에 대한 가정을 인코딩하며, 이런 가정은 스트레스 테스트할 가치가 있음 — 모델이 향상되면 빠르게 낡을 수 있기 때문
  • "가능한 가장 단순한 해결책을 찾고, 필요할 때만 복잡성을 증가"시키라는 원칙
• 급진적 단순화 시도는 원본 성능을 복제하지 못했고, 어떤 조각이 실제로 부하를 지탱하는지 파악하기 어려워 한 번에 하나의 구성 요소를 제거하는 체계적 접근으로 전환
• Opus 4.6 출시가 하네스 복잡도 감소의 추가 동기 — 더 신중하게 계획하고, 에이전틱 태스크를 더 오래 유지하며, 더 큰 코드베이스에서 안정적으로 작동하고, 자체 실수를 잡는 코드 리뷰/디버깅 스킬이 향상되었으며, 긴 컨텍스트 검색도 크게 향상

스프린트 구조 제거

• 스프린트 구조를 완전히 제거 — Opus 4.6의 향상된 능력으로 모델이 분해 없이도 작업을 일관되게 처리 가능
• 플래너와 평가기는 유지 — 플래너 없이는 생성기가 스코프 부족, raw 프롬프트만으로 스펙 없이 빌드를 시작하여 기능이 적은 애플리케이션 생성
• 평가기를 스프린트별 채점에서 실행 종료 시 단일 패스로 이동
  • 태스크가 모델의 단독 능력 범위 내이면 평가기는 불필요한 오버헤드가 되지만, 모델 능력의 경계에 있는 태스크에서는 여전히 실질적 향상 제공
  • 따라서 평가기는 고정된 예/아니오가 아니라, 현재 모델이 단독으로 안정적으로 수행하는 범위를 넘어설 때 비용의 가치가 있음
• AI 기능 빌드 개선을 위한 프롬프팅도 추가 — 생성기가 앱 자체 기능을 도구를 통해 구동하는 적절한 에이전트를 빌드하도록 하는 데 상당한 반복 필요, 관련 지식이 최근이라 Claude의 학습 데이터가 얇게 커버

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

• "Web Audio API를 사용하여 브라우저에서 완전한 기능을 갖춘 DAW를 빌드하라"는 프롬프트로 테스트
• 총 약 4시간, $124.70 소요
  • 플래너 4.7분/$0.46, 빌드 라운드1 2시간7분/$71.08, QA 라운드1 8.8분/$3.24, 빌드 라운드2 1시간2분/$36.89, QA 라운드2 6.8분/$3.09, 빌드 라운드3 10.9분/$5.88, QA 라운드3 9.6분/$4.06
• 빌더가 스프린트 분해 없이 2시간 이상 일관되게 실행
• QA 에이전트의 1차 피드백: 디자인 충실도와 AI 에이전트, 백엔드는 우수하나 기능 완전성이 주요 실패 지점 — 타임라인에서 클립 드래그/이동 불가, 악기 UI 패널(신스 노브, 드럼 패드) 없음, 시각적 이펙트 편집기(EQ 커브, 컴프레서 미터) 없음
• QA 2차 피드백: 오디오 녹음이 스텁 상태, 클립 리사이즈와 분할 미구현, 이펙트 시각화가 그래픽이 아닌 숫자 슬라이더
• 최종 앱: 전문 음악 제작 프로그램에는 미치지 않으며 에이전트의 곡 작곡 능력에 개선 필요, Claude가 실제로 소리를 들을 수 없어 QA 피드백 루프가 음악적 취향 면에서 덜 효과적
  • 그러나 작동하는 어레인지먼트 뷰, 믹서, 트랜스포트를 포함한 기능적 음악 제작 프로그램의 핵심 요소를 갖춤
  • 프롬프팅만으로 짧은 곡 스니펫 제작 가능 — 에이전트가 템포와 키를 설정하고, 멜로디를 배치하고, 드럼 트랙을 만들고, 믹서 레벨을 조정하고, 리버브를 추가

향후 전망

• 모델이 개선되면 더 오래, 더 복잡한 태스크를 수행할 수 있을 것으로 예상되며, 일부 경우 모델을 둘러싼 스캐폴드의 중요성이 감소하여 다음 모델을 기다리면 특정 문제가 자연히 해결될 수 있음
• 반면 모델이 좋아질수록 기본선 이상의 복잡한 태스크를 달성하는 하네스를 개발할 수 있는 공간도 더 넓어짐
• 핵심 교훈:
  • 빌드 대상 모델을 실험하고, 현실적 문제에서 트레이스를 읽고, 성능을 원하는 결과에 맞게 튜닝하는 것이 항상 좋은 실천
  • 더 복잡한 태스크에서 태스크를 분해하고 각 측면에 특화된 에이전트를 적용하면 여유 공간 확보 가능
  • 새 모델이 출시되면 하네스를 재검토하여, 더 이상 성능에 부하를 지탱하지 않는 부분을 제거하고 이전에 불가능했던 더 큰 역량을 달성하기 위한 새 부분을 추가하는 것이 좋은 실천
• 모델이 향상되더라도 흥미로운 하네스 조합의 공간은 줄어들지 않고 이동하며, AI 엔지니어의 과제는 다음의 새로운 조합을 계속 찾아내는 것