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를 빌드하라"는 프롬프트로 테스트
1 day ago
3
English (US) · 