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

이 글은 Harness design for long-running application development의 한글 번역입니다.

핵심 요약

원문 작성일: 2026년 3월 24일

작성자: Prithvi Rajasekaran (Anthropic Labs 팀)

지난 몇 달 동안 저는 두 가지 서로 연결된 문제를 다뤄왔습니다. 첫째는 Claude가 고품질 프론트엔드 디자인을 만들도록 하는 것이고, 둘째는 인간의 개입 없이 완전한 애플리케이션을 구축하도록 하는 것입니다. 이 작업은 이전의 프론트엔드 디자인 스킬과 장기 실행 코딩 에이전트 하네스에서 출발했습니다. 당시 동료들과 함께 프롬프트 엔지니어링과 하네스 설계를 통해 Claude의 성능을 기준선 대비 크게 높였지만, 두 영역 모두 결국 한계에 부딪혔습니다.

돌파구를 찾기 위해 서로 다른 두 영역—주관적 취향이 지배하는 영역과 검증 가능한 정확성·사용성이 지배하는 영역—에서 공통으로 적용할 수 있는 새로운 AI 엔지니어링 접근법을 탐색했습니다. 생성적 적대 신경망(GAN)에서 영감을 받아, 생성자(generator) 와 평가자(evaluator) 에이전트로 구성된 멀티 에이전트 구조를 설계했습니다. 신뢰할 수 있으면서도 안목 있는 평가자를 만들려면, “이 디자인이 좋은가?”처럼 주관적인 판단을 구체적으로 채점 가능한 기준으로 전환하는 작업이 선행되어야 했습니다.

이후 이 기법을 장기 자율 코딩에 적용하면서, 이전 하네스 작업에서 얻은 두 가지 교훈도 함께 가져왔습니다. 빌드를 다루기 쉬운 단위로 분해하고, 세션 간 컨텍스트를 구조화된 자료로 전달하는 방식입니다. 최종 결과물은 플래너·생성자·평가자로 구성된 세 에이전트 아키텍처로, 수 시간의 자율 코딩 세션에 걸쳐 풍부한 풀스택 애플리케이션을 만들어냈습니다.

단순한 구현이 부족한 이유

장기 실행 에이전트 코딩에서 하네스 설계가 성능에 큰 영향을 미친다는 사실은 이전에 보여드렸습니다. 앞선 실험에서 초기화 에이전트가 제품 스펙을 작업 목록으로 분해하고, 코딩 에이전트가 기능 하나씩 구현한 뒤 세션 간 컨텍스트를 자료로 전달하는 방식을 사용했습니다. 더 넓은 개발자 커뮤니티도 유사한 인사이트에 도달해, “Ralph Wiggum” 방식처럼 훅이나 스크립트로 에이전트를 지속적인 반복 주기에 묶어두는 접근법이 등장했습니다.

하지만 몇 가지 문제는 여전히 남아 있었습니다. 복잡한 작업에서 에이전트는 시간이 지나면 궤도를 벗어나곤 합니다. 이 문제를 파고들면서 두 가지 공통된 실패 패턴을 발견했습니다.

첫째, 컨텍스트 윈도우가 채워질수록 모델은 긴 작업에서 일관성을 잃는 경향이 있습니다(에이전트용 컨텍스트 엔지니어링(context engineering) 포스트 참조). 또한 일부 모델은 “컨텍스트 불안(context anxiety)” 현상을 보이는데, 자신이 생각하는 컨텍스트 한계에 가까워지면 작업을 섣불리 마무리하려 합니다. 컨텍스트 리셋은 이 두 문제를 모두 해결합니다. 컨텍스트 윈도우를 완전히 비우고 새 에이전트를 시작하되, 이전 에이전트의 상태와 다음 단계를 구조화된 인계로 함께 넘기는 방식입니다.

이 방식은 압축(compaction)과 다릅니다. 압축은 대화의 앞부분을 요약해 동일한 에이전트가 줄어든 이력으로 계속 작업하는 방식입니다. 연속성은 유지되지만 백지 상태를 주지는 못하므로, 컨텍스트 불안이 여전히 남을 수 있습니다. 반면 리셋은 백지 상태를 주되, 다음 에이전트가 작업을 이어받을 수 있도록 인계 자료에 충분한 상태 정보를 담아야 합니다. 실제 테스트에서 Claude Sonnet 4.5는 컨텍스트 불안이 뚜렷해 압축만으로는 긴 작업 성능을 끌어올리기 어려웠고, 컨텍스트 리셋이 하네스 설계의 핵심 요소가 되었습니다. 근본 문제는 해결되지만, 오케스트레이션 복잡성과 토큰 오버헤드, 지연이 추가되는 트레이드오프가 있습니다.

두 번째 문제는 자기 평가입니다. 자신이 만든 작업을 스스로 평가하도록 요청하면, 에이전트는 인간 관찰자가 보기에 품질이 명백히 평범한 경우에도 자신만만하게 작업을 칭찬하는 경향이 있습니다. 특히 디자인처럼 테스트를 돌려 통과/실패로 판별할 수 없는 주관적 작업에서 이 문제가 두드러집니다. 레이아웃이 세련된지 뻔한지는 사람마다 다른데, 에이전트는 자기 작업을 채점할 때 항상 관대하게 평가합니다.

그러나 검증 가능한 결과가 있는 작업에서도 에이전트는 때로 잘못된 판단을 내려 작업 완수를 방해합니다. 작업을 수행하는 에이전트와 작업을 판단하는 에이전트를 분리하면 이 문제를 효과적으로 해결할 수 있습니다. 분리만으로 그 관대함이 사라지지는 않습니다. 평가자 역시 LLM이라 LLM이 생성한 결과물에 너그러운 경향이 있기 때문입니다. 하지만 독립된 평가자를 회의적으로 조율하는 편이 생성자 스스로를 자기 비판적으로 만드는 것보다 훨씬 수월합니다. 외부 피드백이 생기면 생성자는 그에 맞춰 반복적으로 개선할 구체적인 기준이 생깁니다.

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

프론트엔드 디자인부터 실험을 시작했습니다. 자기 평가 문제가 가장 눈에 띄는 영역이었기 때문입니다. 아무런 개입이 없으면 Claude는 기술적으로는 작동하지만 시각적으로 평범한 레이아웃—안전하고 예측 가능한—을 선호합니다.

프론트엔드 디자인 하네스를 구성하는 데 두 가지 인사이트가 중요했습니다. 첫째, 미적 감각을 완전히 점수로 환원할 수는 없고 개인 취향도 항상 다르지만, 디자인 원칙과 선호도를 반영한 채점 기준으로 개선할 수 있습니다. “이 디자인이 아름다운가?”는 일관되게 답하기 어렵지만, “우리의 좋은 디자인 원칙에 부합하는가?”는 Claude가 채점할 구체적인 기준이 됩니다. 둘째, 프론트엔드 생성과 평가를 분리하면 생성자가 더 나은 결과물을 내도록 밀어주는 피드백 루프를 만들 수 있습니다.

이를 바탕으로 생성자와 평가자 에이전트 프롬프트에 모두 포함되는 네 가지 채점 기준을 작성했습니다.

• 디자인 품질: 디자인이 부품들의 모음이 아니라 하나의 유기적인 전체처럼 느껴지는가? 색상, 타이포그래피, 레이아웃, 이미지, 기타 세부 요소가 조화를 이루어 뚜렷한 분위기와 정체성을 만드는가.
• 독창성: 독자적인 결정의 흔적이 보이는가, 아니면 템플릿 레이아웃, 라이브러리 기본값, AI 생성 패턴인가? 인간 디자이너라면 의도적인 창작 선택을 알아볼 수 있어야 합니다. 수정 없는 기성 컴포넌트나 흰 카드 위 보라색 그라디언트처럼 AI 생성의 전형적 흔적은 감점 대상입니다.
• 기교(Craft): 기술적 실행력—타이포그래피 계층, 간격 일관성, 색상 조화, 명암 대비. 창의성보다 역량을 확인하는 항목입니다. 합리적인 구현이면 기본적으로 통과하며, 실패는 기본기가 무너진 경우입니다.
• 기능성: 미적 요소와 무관한 사용성. 사용자가 인터페이스의 목적을 파악하고, 주요 기능을 찾고, 추측 없이 작업을 완료할 수 있는가.

기교와 기능성보다 디자인 품질과 독창성을 더 중시했습니다. Claude는 기본적으로 기교와 기능성에서 이미 좋은 점수를 냈는데, 기술적 역량이 모델에게 자연스럽게 발현되었기 때문입니다. 반면 디자인과 독창성에서는 기껏해야 평범한 결과를 냈습니다. 기준은 뻔한 “AI 슬롭(AI slop)” 패턴에 명시적으로 감점을 부여했고, 디자인과 독창성에 더 큰 가중치를 두어 모델이 더 과감한 미적 선택을 하도록 밀어붙였습니다.

상세한 점수 분석이 담긴 예시 몇 개를 주고 평가자를 조율했습니다. 덕분에 평가자의 판단이 제 선호에 맞게 정렬되었고, 반복 과정에서 점수가 흔들리는 현상도 줄었습니다.

이 루프는 Claude Agent SDK로 구현했고, 덕분에 오케스트레이션은 간단했습니다. 생성자 에이전트가 먼저 사용자 프롬프트를 기반으로 HTML/CSS/JS 프론트엔드를 만들었습니다. 평가자에는 Playwright MCP를 주어 점수를 매기기 전에 실제 페이지와 직접 상호작용하게 했습니다. 실제로 평가자는 페이지를 직접 열어 구석구석 스크린샷을 찍고 살핀 뒤 평가를 내렸습니다. 그 피드백이 다음 반복의 입력으로 생성자에게 전달되었습니다. 생성당 5~15회 반복을 실행했으며, 각 반복마다 평가자의 비평에 반응해 생성자는 더 독특한 방향으로 나아갔습니다. 평가자가 정적 스크린샷이 아니라 실제 페이지를 탐색하며 채점했기 때문에 각 주기는 실제로 상당한 시간이 걸렸습니다. 전체 실행은 최대 4시간이 소요되었습니다. 또한 각 평가 후 생성자가 전략적으로 판단하도록 했습니다. 점수가 오르고 있으면 현재 방향을 다듬고, 효과가 없으면 완전히 다른 미적 방향으로 전환하도록 한 것입니다.

여러 실행에 걸쳐 평가 점수는 반복이 쌓일수록 올랐다가 어느 시점에 정체되었고, 그 뒤에도 개선 여지는 남아 있었습니다. 어떤 결과물은 점진적으로 다듬어졌고, 어떤 것은 반복 중간에 급격한 미적 전환을 보였습니다.

채점 기준을 어떤 말로 적느냐가 예상치 못한 방향으로 생성자를 이끌었습니다. “최고의 디자인은 미술관 수준”이라는 문구를 넣자 디자인이 특정 시각적 방향으로 수렴했습니다. 기준에 쓴 표현 자체가 결과물의 성격을 직접 형성한다는 의미입니다.

점수는 대체로 회를 거듭할수록 올랐지만, 항상 꾸준히 오르지는 않았습니다. 뒤쪽 반복의 결과물이 전반적으로 더 나은 경향이 있었지만, 마지막 결과물보다 중간 반복물을 더 선호하는 경우도 종종 있었습니다. 구현 복잡도 역시 라운드가 쌓일수록 높아지는 경향이 있었는데, 평가자의 피드백에 반응해 생성자가 더 야심찬 해결책을 시도했기 때문입니다. 첫 번째 반복에서도 아무런 프롬프트 없는 기준선보다 눈에 띄게 나은 결과가 나왔습니다. 채점 기준과 그 표현 자체가, 평가자 피드백이 더해지기 전부터 이미 모델을 평범한 기본값에서 벗어나게 했다는 의미입니다.

한 인상적인 사례로, 네덜란드 미술관 웹사이트 제작을 요청한 적이 있습니다. 아홉 번째 반복에서 가상의 미술관을 위한 깔끔하고 어두운 테마의 랜딩 페이지가 나왔습니다. 시각적으로 완성도는 있었지만 예상 범위 안이었습니다. 그런데 열 번째 사이클에서 방향을 완전히 바꿔 사이트를 공간적 경험으로 새로 그렸습니다. CSS 원근감으로 렌더링한 체크무늬 바닥의 3D 공간, 자유롭게 벽에 걸린 작품들, 스크롤이나 클릭 대신 입구를 통해 갤러리 방 사이를 이동하는 방식이었습니다. 반복 없이 한 번에 나온 결과로는 본 적 없는 창의적 도약이었습니다.

열 번째 반복에서 생성된 네덜란드 미술관 웹사이트의 공간적 경험 데모.

풀스택 코딩으로 확장

이 결과를 바탕으로 GAN에서 영감을 받은 패턴을 풀스택 개발에 적용했습니다. 생성자-평가자 루프는 소프트웨어 개발 생명주기에 자연스럽게 맞아떨어지는데, 코드 리뷰와 QA가 디자인 평가자와 동일한 구조적 역할을 담당하기 때문입니다.

아키텍처

이전의 장기 실행 하네스에서는 초기화 에이전트, 기능 하나씩 작업하는 코딩 에이전트, 세션 간 컨텍스트 리셋으로 일관된 멀티세션 코딩 문제를 해결했습니다. 컨텍스트 리셋은 핵심 돌파구였습니다. 당시 사용한 Sonnet 4.5가 앞서 언급한 “컨텍스트 불안” 경향을 보였고, 컨텍스트 리셋이 잘 작동하는 하네스를 만드는 것이 모델을 작업에 집중시키는 핵심이었습니다. Opus 4.5는 그 경향을 자체적으로 거의 제거했기 때문에 이 하네스에서는 컨텍스트 리셋을 완전히 제거했습니다. 에이전트는 전체 빌드 과정을 하나의 연속 세션으로 진행했고, Claude Agent SDK의 자동 압축이 컨텍스트 증가를 처리했습니다.

이 작업에서는 기존 하네스의 토대 위에 3개의 에이전트 시스템을 구축했습니다. 각 에이전트는 이전 실행에서 관찰된 특정 문제점을 해결하도록 설계되었습니다.

플래너(Planner): 이전 장기 실행 하네스에서는 사용자가 상세한 스펙을 미리 제공해야 했습니다. 그 단계를 자동화하기 위해 1~4문장의 간단한 프롬프트를 완전한 제품 스펙으로 확장하는 플래너 에이전트를 만들었습니다. 스코프를 야심차게 잡되, 세부 기술 구현보다 제품 맥락과 고수준 기술 설계에 집중하도록 지시했습니다. 플래너가 세밀한 기술 세부사항을 미리 명세하려다 잘못되면 스펙의 오류가 하위 구현으로 파급되기 때문입니다. 에이전트에게는 만들어낼 결과물을 제약하고 경로는 스스로 찾도록 하는 것이 더 현명해 보였습니다. 플래너에게 AI 기능을 제품 스펙에 자연스럽게 녹여낼 기회를 찾도록 요청하기도 했습니다. (부록에 예시 포함)

생성자(Generator): 이전 하네스의 기능 하나씩 접근하는 방식은 스코프 관리에 효과적이었습니다. 여기서도 비슷한 방식을 적용해, 생성자가 스프린트(sprint) 단위로 작업하며 스펙에서 기능 하나씩 집어들도록 지시했습니다. 각 스프린트는 React, Vite, FastAPI, SQLite(이후 PostgreSQL) 스택으로 앱을 구현했고, 생성자는 QA에 넘기기 전에 각 스프린트 종료 시 스스로 작업을 평가하도록 지시받았습니다. 버전 관리를 위한 git도 사용했습니다.

평가자(Evaluator): 이전 하네스의 결과물은 인상적으로 보이지만 실제로 사용해보면 버그가 있는 경우가 많았습니다. 이를 잡기 위해 평가자는 Playwright MCP로 실제 사용자처럼 실행 중인 애플리케이션을 클릭하며 UI 기능, API 엔드포인트, 데이터베이스 상태를 테스트했습니다. 그런 다음 발견된 버그와 프론트엔드 실험에서 가져온 기준을 바탕으로 각 스프린트를 채점했는데, 여기서는 제품 깊이, 기능성, 시각 디자인, 코드 품질을 평가하도록 기준을 수정했습니다. 각 기준에는 하드 임계값이 있어 하나라도 미달하면 스프린트가 실패하고 생성자는 무엇이 잘못되었는지 상세한 피드백을 받았습니다.

각 스프린트 전에 생성자와 평가자는 스프린트 계약(sprint contract)을 협의했습니다. 코드를 작성하기 전에 해당 작업의 “완료” 기준을 합의하는 것입니다. 제품 스펙이 의도적으로 고수준이었기 때문에 사용자 스토리와 테스트 가능한 구현 사이의 간극을 메우는 단계가 필요했습니다. 생성자가 무엇을 어떻게 만들고 어떻게 성공을 검증할지 제안하면, 평가자가 그 제안을 검토해 생성자가 올바른 것을 만들고 있는지 확인했습니다. 둘은 합의에 이를 때까지 반복했습니다.

소통은 파일로 이루어졌습니다. 한 에이전트가 파일을 작성하면 다른 에이전트가 읽고, 같은 파일에 응답하거나 상대 에이전트가 읽을 새 파일을 작성했습니다. 생성자는 합의된 계약을 기반으로 작업한 뒤 QA에 넘겼습니다. 덕분에 구현을 너무 일찍 세세하게 정하지 않으면서도 스펙에 충실한 작업이 가능했습니다.

하네스 실행

첫 번째 버전에서는 Claude Opus 4.5를 사용하며 전체 하네스와 단일 에이전트 시스템을 동일한 프롬프트로 비교 실행했습니다. 이 실험을 시작할 당시 가장 뛰어난 코딩 모델이 Opus 4.5였기 때문입니다.

레트로 비디오 게임 제작 도구를 만들기 위해 다음 프롬프트를 작성했습니다.

Create a 2D retro game maker with features including a level editor, sprite editor, entity behaviors, and a playable test mode.

(레벨 에디터, 스프라이트 에디터, 엔티티 행동, 플레이 가능한 테스트 모드를 포함한 2D 레트로 게임 제작 도구를 만들어라.)

아래 표는 하네스 유형, 실행 시간, 총 비용을 정리한 것입니다.

하네스는 20배 이상 비쌌지만, 결과물의 품질 차이는 즉시 명백했습니다.

레벨과 그 구성 요소(스프라이트, 엔티티, 타일 배치)를 조립하고 플레이 버튼을 누르면 실제로 플레이할 수 있는 인터페이스를 기대했습니다. 먼저 단일 에이전트 실행 결과물을 열었을 때 초기 애플리케이션은 그 기대에 부합하는 것처럼 보였습니다.

그러나 클릭하며 탐색하다 보니 문제들이 드러났습니다. 레이아웃은 공간 낭비가 심했고, 고정 높이 패널들이 뷰포트 대부분을 비워두었습니다. 워크플로우도 경직되어 있었습니다. 레벨을 채우려 하면 먼저 스프라이트와 엔티티를 만들라는 안내가 나왔지만, UI 어디에도 그 순서를 안내하는 요소가 없었습니다. 더 근본적으로는 실제 게임이 동작하지 않았습니다. 엔티티가 화면에 나타났지만 어떤 입력에도 반응하지 않았습니다. 코드를 들여다보니 엔티티 정의와 게임 런타임 사이의 연결이 끊어져 있었고, 표면에서는 어디가 문제인지 알 수 없었습니다.

단일 에이전트 하네스로 만든 앱: 초기 화면.

단일 에이전트 하네스로 만든 앱: 스프라이트 에디터.

단일 에이전트 하네스로 만든 앱: 게임 플레이.

단일 에이전트 실행 평가를 마친 후 하네스 실행 결과물을 살펴봤습니다. 이 실행은 동일한 한 문장 프롬프트에서 시작했지만, 플래너 단계가 해당 프롬프트를 10개의 스프린트에 걸쳐 16개의 기능 스펙으로 확장했습니다. 단일 에이전트가 시도한 것을 훨씬 넘어서는 범위였습니다. 핵심 에디터와 플레이 모드 외에도 스프라이트 애니메이션 시스템, 행동 템플릿, 효과음과 음악, AI 기반 스프라이트 생성기와 레벨 디자이너, 공유 링크를 포함한 게임 내보내기 기능이 스펙에 포함되었습니다. 플래너에게 저희 프론트엔드 디자인 스킬 접근 권한을 주었고, 플래너는 이를 읽어 스펙의 일부로 앱의 시각 디자인 언어를 만들었습니다. 각 스프린트마다 생성자와 평가자는 스프린트의 구체적인 구현 세부사항과 완료 검증을 위한 테스트 가능한 행동을 정의하는 계약을 협의했습니다.

앱은 즉시 단일 에이전트 실행보다 더 완성도 있고 매끄러웠습니다. 캔버스는 전체 뷰포트를 사용했고, 패널 크기는 적절했으며, 스펙의 디자인 방향에 맞는 일관된 시각적 정체성이 있었습니다. 단일 에이전트 실행에서 보였던 어색함 중 일부는 남아 있었습니다. 레벨을 채우기 전에 스프라이트와 엔티티를 먼저 만들어야 한다는 게 여전히 명확하지 않아 이리저리 눌러봐야 했습니다. 모델 자체의 제품 감각에서 오는 한계로, 하네스가 해결하려던 문제는 아니었습니다. 다만 하네스 안에서 이 부분을 집중적으로 다듬으면 결과물 품질을 더 높일 수 있는 지점이기도 했습니다.

에디터들을 살펴보면서 단일 에이전트 대비 새 실행의 강점이 더 분명해졌습니다. 스프라이트 에디터는 더 풍부하고 완성도 높았으며, 툴 팔레트가 더 깔끔했고 컬러 피커와 줌 컨트롤도 더 쓰기 편했습니다.

플래너에게 AI 기능을 스펙에 녹여내도록 요청했기 때문에, 앱에는 프롬프트로 게임의 여러 부분을 생성할 수 있는 Claude 통합 기능도 포함되었습니다. 덕분에 게임 제작 과정이 훨씬 빨라졌습니다.

전체 하네스로 만든 앱: 새 게임 생성 초기 화면.

전체 하네스로 만든 앱: 스프라이트 에디터.

전체 하네스로 만든 앱: AI 기반 게임 디자인.

전체 하네스로 만든 앱: 게임 플레이.

가장 큰 차이는 플레이 모드에서 나타났습니다. 실제로 엔티티를 움직이며 게임을 플레이할 수 있었습니다. 물리 구현이 다소 거칠었습니다. 캐릭터가 플랫폼에 올라타면 겹쳐 보이는 등 부자연스러운 부분이 있었지만, 핵심 기능은 동작했습니다. 단일 에이전트는 이걸 해내지 못했습니다. 잠시 돌아다니다 AI의 게임 레벨 구성에서 한계도 발견했습니다. 점프로 넘어갈 수 없는 큰 벽이 있어 막혔습니다. 하네스가 더 다듬어야 할 상식적인 개선 사항과 엣지 케이스가 있음을 시사했습니다.

로그를 살펴보니 평가자가 구현을 스펙에 맞게 잡아주고 있었습니다. 매 스프린트마다 계약의 테스트 기준을 점검하고 Playwright로 실행 중인 앱을 돌려보면서, 기대 동작에서 벗어나는 부분을 모두 버그로 기록했습니다. 계약은 세밀했습니다. 스프린트 3만 해도 레벨 에디터를 다루는 27개의 기준이 있었으며, 평가자의 발견 사항은 추가 조사 없이 바로 조치할 수 있을 만큼 구체적이었습니다. 아래는 평가자가 발견한 이슈 예시입니다.

평가자가 이 수준으로 작동하게 만드는 데는 공이 들었습니다. 기본 상태에서 Claude는 QA 에이전트로서 성능이 좋지 않습니다. 초기 실행에서 분명한 문제를 발견하고도 그게 큰 문제가 아니라고 스스로를 설득하고 작업을 승인하는 것을 여러 번 목격했습니다. 또한 엣지 케이스를 파고들기보다 표면적으로만 테스트하는 경향이 있어 더 미묘한 버그들이 빠져나갔습니다. 조율 과정은 평가자의 로그를 읽고, 제 판단과 다른 부분을 찾아내고, 그 문제를 해결하도록 QA 프롬프트를 업데이트하는 반복이었습니다. 평가자가 합리적으로 채점한다는 확신이 들기까지 여러 번의 이 개발 루프가 필요했습니다. 그렇게 조율한 뒤에도 하네스 결과물에는 모델의 QA 역량의 한계가 드러났습니다. 작은 레이아웃 문제, 곳곳에서 직관적이지 않은 상호작용, 평가자가 충분히 검증하지 못한 더 깊이 중첩된 기능의 미발견 버그들이 있었습니다. 추가 조율을 통해 잡아낼 검증 여지가 분명히 더 있었습니다. 하지만 앱의 핵심 기능이 아예 동작하지 않았던 단일 에이전트 실행과 비교하면, 개선 효과는 명백했습니다.

하네스 반복 개선

첫 번째 하네스 결과는 기대 이상이었지만, 무겁고 느리고 비쌌습니다. 다음 단계는 성능 저하 없이 하네스를 간소화하는 방법을 찾는 것이었습니다. 상식적인 판단이기도 했고, 더 보편적인 원칙에서 비롯된 것이기도 했습니다. 하네스의 모든 구성 요소는 ‘모델이 모든 것을 혼자서는 못 한다’는 가정을 담고 있는데, 반드시 따져봐야 하는 내용입니다. 애초에 틀렸을 수도 있고, 모델이 발전하면서 금세 낡아버릴 수도 있기 때문입니다. Anthropic의 블로그 포스트 효과적인 에이전트 구축은 핵심 아이디어를 이렇게 정의합니다: ‘가능한 한 단순한 해결책을 찾되, 복잡성이 필요할 때만 높여라.’ 이는 에이전트 하네스를 유지하는 누구나 마주치는 일관된 패턴입니다.

처음에는 하네스를 대폭 줄이고 몇 가지 창의적인 새 아이디어를 시도했지만, 원래 성능을 재현하지 못했습니다. 또한 하네스 설계에서 실제로 핵심적인 부분이 어디이고 어떤 이유인지 파악하기도 어려워졌습니다. 그 경험을 거쳐 더 체계적인 방법으로 전환했습니다. 구성 요소를 하나씩 제거하며 최종 결과에 어떤 영향을 미치는지 검토했습니다.

이 반복 주기를 진행하는 동안 Opus 4.6도 출시되었는데, 이는 하네스 복잡성을 줄일 추가 동기가 되었습니다. 4.6이 4.5보다 스캐폴드가 덜 필요하리라 기대할 이유가 충분했습니다. 출시 블로그에 따르면 “[Opus 4.6은] 더 신중하게 계획하고, 에이전트 작업을 훨씬 오래 지속하며, 큰 코드베이스에서도 안정적으로 작동하고, 스스로 실수를 잡아내는 코드 리뷰·디버깅 능력이 향상되었습니다.” 긴 컨텍스트 검색 능력도 크게 개선되었습니다. 이 모든 역량은 애초에 하네스가 보완하려고 구축한 것들입니다.

스프린트 구조 제거

스프린트 구조를 완전히 제거하는 것부터 시작했습니다. 스프린트 구조는 모델이 일관성 있게 작업하도록 분해하는 역할을 했습니다. Opus 4.6의 개선사항을 고려하면 모델이 이런 분해 없이도 작업을 스스로 처리할 수 있다고 볼 충분한 이유가 있었습니다.

플래너와 평가자는 각각 분명한 가치를 계속 더했기에 유지했습니다. 플래너가 없으면 생성자는 범위를 좁게 잡았습니다. 프롬프트를 그대로 받으면 작업 범위를 먼저 정하지 않고 바로 빌드를 시작해, 플래너가 만드는 것보다 기능이 적은 앱으로 끝났습니다.

스프린트 구조를 제거하자 평가자도 스프린트마다 채점하는 대신 실행 마지막에 한 번만 평가하도록 옮겼습니다. 모델의 역량이 훨씬 높아지면서 평가자의 기여도가 달라졌습니다. 평가자가 얼마나 유용한지는 해당 작업이 모델이 혼자 잘할 수 있는 범위에 들어가느냐에 달렸습니다. 4.5에서는 생성자가 혼자 감당하기 빠듯한 빌드에서 평가자가 작업 전반에 걸쳐 의미 있는 문제를 잡아냈습니다. 4.6에서는 모델이 훨씬 더 많은 것을 혼자 처리할 수 있게 되었습니다. 이전에는 평가자가 봐줘야 제대로 나오던 작업도 이제는 생성자가 혼자 잘해내는 경우가 많아졌고, 그런 작업에서는 평가자가 불필요한 비용이 되었습니다. 다만 생성자가 여전히 버거워하는 부분에서는 평가자가 계속 큰 도움이 되었습니다.

결국 평가자는 무조건 쓰고 안 쓰고의 문제가 아닙니다. 현재 모델이 혼자서 안정적으로 처리하지 못하는 범위의 작업일 때 비용을 들일 가치가 있습니다.

구조를 간소화하면서 각 앱에 AI 기능을 넣는 방식도 개선했습니다. 생성자가 앱의 기능을 도구로 직접 조작할 수 있는 제대로 된 에이전트를 만들도록 프롬프트를 조율한 것입니다. 관련 지식이 워낙 최근이라 Claude의 학습 데이터에 얕게 담겨 있어서, 실제로 상당한 반복이 필요했습니다. 하지만 충분한 조율을 거치자 생성자가 에이전트를 올바르게 구축하게 되었습니다.

업데이트된 하네스의 결과

업데이트된 하네스를 검증하기 위해 다음 프롬프트로 DAW(Digital Audio Workstation), 즉 브라우저 기반 음악 제작 프로그램을 생성했습니다.

Build a fully featured DAW in the browser using the Web Audio API.

(Web Audio API를 사용해 브라우저에서 완전한 기능을 갖춘 DAW를 만들어라.)

실행은 여전히 길고 비쌌으며, 약 4시간에 토큰 비용 124달러가 들었습니다.

대부분의 시간은 빌더가 소요했는데, Opus 4.5에서 필요했던 스프린트 분해 없이 2시간 이상 일관되게 실행했습니다.

이전 하네스와 마찬가지로 플래너가 한 줄 프롬프트를 완전한 스펙으로 확장했습니다. 로그를 보니 생성자 모델이 앱과 에이전트 설계를 잘 계획하고, 에이전트를 연결하고, QA에 넘기기 전에 테스트를 잘 했습니다.

그렇다고 해도 QA 에이전트는 실제 빠진 부분을 잡아냈습니다. 1라운드 피드백에서 다음과 같이 언급했습니다.

이 앱은 디자인 충실도, 견고한 AI 에이전트, 좋은 백엔드를 갖춘 강력한 앱입니다. 주요 실패 지점은 기능 완성도입니다. 앱이 인상적으로 보이고 AI 통합이 잘 작동하지만, 핵심 DAW 기능 여러 개가 표시만 되고 실제 상호작용이 없습니다. 클립을 타임라인에서 드래그/이동할 수 없고, 악기 UI 패널(신스 노브, 드럼 패드)이 없으며, 시각적 이펙트 에디터(EQ 커브, 컴프레서 미터)가 없습니다. 이는 엣지 케이스가 아니라 DAW를 사용 가능하게 만드는 핵심 상호작용이며, 스펙에서 명시적으로 요구하는 사항입니다.

2라운드 피드백에서도 몇 가지 기능적 빠진 부분을 잡아냈습니다.

남은 문제:

• 오디오 녹음이 여전히 스텁(stub)만 구현됨 (버튼이 토글되지만 마이크 캡처 없음)
• 클립 가장자리 드래그 크기 조정과 클립 분할 미구현
• 이펙트 시각화가 그래픽이 아닌 숫자 슬라이더 (EQ 커브 없음)

생성자는 혼자 두면 여전히 세부사항을 빠뜨리거나 기능을 껍데기만 만들어두는 경향이 있었고, QA는 생성자가 놓친 마지막 문제를 잡아내는 데 계속 큰 도움이 되었습니다.

프롬프트를 기반으로 멜로디와 화음, 드럼 패턴을 만들고, 이를 곡으로 편곡하고, 통합 에이전트의 도움을 받을 수 있는 프로그램을 기대했습니다. 결과는 아래 영상에서 확인할 수 있습니다.

브라우저에서 실행되는 DAW 앱 데모.

이 앱은 전문 음악 제작 프로그램과는 거리가 멀고, 에이전트의 작곡 역량도 아직 갈 길이 멉니다. 더불어 Claude는 실제로 소리를 들을 수 없기 때문에 음악적 취향에 관한 QA 피드백 루프가 효과적으로 작동하지 않았습니다.

그럼에도 최종 앱은 기능하는 음악 제작 프로그램의 핵심 요소들을 모두 갖췄습니다. 브라우저에서 동작하는 어레인지 뷰, 믹서, 트랜스포트가 있었습니다. 그뿐만 아니라 프롬프트만으로 짧은 곡 구간을 만들 수 있었습니다. 에이전트가 템포와 조성을 설정하고, 멜로디를 깔고, 드럼 트랙을 만들고, 믹서 레벨을 조정하고, 리버브를 추가했습니다. 작곡의 기본 요소들이 갖춰져 있었고, 에이전트가 도구를 사용해 처음부터 끝까지 간단한 프로덕션을 자율적으로 만들 수 있었습니다. 아직 음정이 완벽하진 않지만—그 방향으로 가고 있습니다.

앞으로의 방향

모델이 계속 발전하면서 더 오래, 더 복잡한 작업을 처리하는 능력이 향상되리라 예상할 수 있습니다. 어떤 경우에는 모델을 감싸는 스캐폴드가 시간이 지나면서 덜 중요해지고, 개발자들은 다음 모델을 기다리며 특정 문제가 저절로 해결되는 것을 볼 수 있습니다. 반면 모델이 발전할수록, 이전보다 훨씬 복잡한 작업을 처리하는 하네스를 만들 여지도 함께 넓어집니다.

이런 배경에서 가져갈 교훈이 몇 가지 있습니다. 사용하는 모델을 직접 실험하고, 실제 문제에서 실행 기록을 읽고, 원하는 결과가 나오도록 성능을 조율하는 것이 항상 중요합니다. 복잡한 작업에서는 작업을 쪼개고 각 부분에 전문 에이전트를 붙여 개선 여지를 얻을 수도 있습니다. 새 모델이 나오면 하네스를 다시 들여다보는 것도 좋습니다. 더 이상 필요 없는 부분은 덜어내고, 이전에는 불가능했던 새로운 역량을 넣을 수 있기 때문입니다.

이 작업을 통해 확신한 것이 있습니다. 모델이 발전해도 하네스 설계의 가능성은 줄어들지 않습니다. 단지 다른 곳으로 옮겨갈 뿐입니다. AI 엔지니어에게 남은 일은 그 다음의 새로운 조합을 계속 찾아내는 것입니다.

감사의 말

Mike Krieger, Michael Agaby, Justin Young, Jeremy Hadfield, David Hershey, Julius Tarng, Xiaoyi Zhang, Barry Zhang, Orowa Sidker, Michael Tingley, Ibrahim Madha, Martina Long, Canyon Robbins의 기여에 감사드립니다.

포스트를 다듬는 데 도움을 주신 Jake Eaton, Alyssa Leonard, Stef Sequeira에게도 감사드립니다.

부록

플래너 에이전트가 생성한 계획 예시입니다.

RetroForge - 2D 레트로 게임 제작 도구

개요
RetroForge는 2D 레트로 스타일 비디오 게임을 설계하고 구축하기 위한 웹 기반 창작 스튜디오입니다.
클래식 8비트, 16비트 게임 미학의 향수와 현대적이고 직관적인 편집 도구를 결합하여,
취미 창작자부터 인디 개발자까지 누구나 전통적인 코딩 없이 게임 아이디어를 실현할 수 있도록 합니다.

플랫폼은 네 가지 통합 창작 모듈을 제공합니다: 게임 세계를 설계하는 타일 기반 레벨 에디터,
시각적 에셋을 만드는 픽셀 아트 스프라이트 에디터, 게임 로직을 정의하는 시각적 엔티티 행동 시스템,
실시간 게임플레이 테스트를 위한 즉각적인 플레이 가능 테스트 모드.
AI 지원(Claude 기반)을 전반에 걸쳐 통합함으로써 RetroForge는 창작 과정을 가속합니다—
자연어 상호작용으로 스프라이트를 생성하고, 레벨을 설계하고, 행동을 구성할 수 있습니다.

RetroForge는 레트로 게임 미학을 사랑하지만 현대적 편의를 원하는 창작자를 대상으로 합니다.
어린 시절의 플랫포머, RPG, 액션 게임을 재현하든 레트로 제약 안에서 완전히 새로운 경험을 만들든,
사용자는 빠르게 프로토타입을 만들고 시각적으로 반복하며 다른 사람들과 창작물을 공유할 수 있습니다.

기능
1. 프로젝트 대시보드 및 관리
프로젝트 대시보드는 RetroForge의 모든 창작 작업의 홈 베이스입니다.
사용자는 게임 프로젝트를 명확하고 체계적으로 관리할 방법이 필요합니다—
새로운 것을 만들고, 진행 중인 작업으로 돌아오고, 각 프로젝트의 내용을 한눈에 파악해야 합니다.

사용자 스토리: 사용자로서 저는:

- 이름과 설명으로 새 게임 프로젝트를 만들어 게임 설계를 시작할 수 있어야 합니다
- 모든 기존 프로젝트를 프로젝트 이름, 최종 수정 날짜, 썸네일 미리보기를 보여주는 시각적 카드로 볼 수 있어야 합니다
- 프로젝트를 열어 전체 게임 에디터 작업공간으로 진입할 수 있어야 합니다
- 더 이상 필요 없는 프로젝트를 실수 방지 확인 대화상자와 함께 삭제할 수 있어야 합니다
- 기존 프로젝트를 새 게임의 출발점으로 복제할 수 있어야 합니다

프로젝트 데이터 모델: 각 프로젝트는 다음을 포함합니다:

프로젝트 메타데이터 (이름, 설명, 생성/수정 타임스탬프)
캔버스 설정 (해상도: 예, 256x224, 320x240, 또는 160x144)
타일 크기 설정 (8x8, 16x16, 또는 32x32 픽셀)
컬러 팔레트 선택
관련된 모든 스프라이트, 타일셋, 레벨, 엔티티 정의

...

참고 자료

• Harness design for long-running application development - 원문
• Effective harnesses for long-running agents - 이전 하네스 작업
• Effective context engineering for AI agents - 컨텍스트 엔지니어링 포스트
• Building Effective Agents - 효과적인 에이전트 구축
• Claude Agent SDK 공식 문서
• 프론트엔드 디자인 스킬
• 생성적 적대 신경망 (Wikipedia)
• Claude Opus 4.6 출시 블로그