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

- 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 에러 반환 - 평가기 튜닝에 상당한 노력 필요