블로그 | 모하지?

원문: Harness design for long-running application development — Anthropic Engineering, Prithvi Rajasekaran, 2026년 3월 24일

장기 실행 애플리케이션 개발에서 하네스(harness) 설계는 에이전트형 코딩 성능을 끌어올리는 핵심 요소다. Anthropic은 프런트엔드 디자인과 장시간 자율 소프트웨어 엔지니어링이라는 두 영역에서 Claude의 한계를 더 밀어붙이기 위해, 단순한 프롬프트 개선을 넘어 여러 에이전트가 역할을 나누어 협업하는 구조를 실험했다.

이 글은 그 실험의 흐름을 이해하기 쉽게 정리·번역한 것이다. 핵심은 간단하다. 일을 만드는 에이전트와 평가하는 에이전트를 분리하고, 작업을 적절한 단위로 나누며, 모델이 실제로 어디까지 혼자 잘할 수 있는지 계속 다시 점검해야 한다는 것이다.

배경: 두 가지 문제에서 출발하다

저자는 지난 몇 달 동안 서로 연결된 두 문제를 다뤘다.

첫째, Claude가 더 높은 품질의 프런트엔드 디자인을 만들도록 하는 문제. 둘째, 사람의 개입 없이 완성도 있는 애플리케이션을 끝까지 구축하도록 하는 문제다.

이 작업은 Anthropic의 기존 프런트엔드 디자인 스킬과 장기 실행 코딩 에이전트 하네스 연구에서 이어졌다. 당시 연구진은 프롬프트 엔지니어링과 하네스 설계만으로도 기본 성능보다 훨씬 좋은 결과를 얻었지만, 결국 한계에 부딪혔다.

한계를 넘기 위해 저자는 서로 성격이 다른 두 영역에 공통으로 적용될 수 있는 AI 엔지니어링 접근을 찾았다. 하나는 취향과 미감이 중요한 주관적 영역이고, 다른 하나는 정확성과 사용성처럼 검증 가능한 기준이 있는 영역이었다.

여기서 영감을 준 것은 GAN, 즉 생성적 적대 신경망이었다. 저자는 생성자(generator) 와 평가자(evaluator) 로 나뉜 멀티 에이전트 구조를 설계했다. 다만 평가자가 결과물을 믿을 만하게, 그리고 어느 정도의 안목을 가지고 평가하려면 먼저 “좋은 디자인인가?” 같은 주관적 질문을 구체적으로 채점 가능한 기준으로 바꿔야 했다.

이후 저자는 같은 기법을 장기 실행 자율 코딩에 적용했다. 이전 하네스 연구에서 얻은 두 가지 교훈도 함께 가져왔다.

큰 빌드를 다루기 쉬운 단위로 나눌 것
세션 사이의 맥락 전달을 위해 구조화된 산출물을 사용할 것

최종적으로는 플래너(planner), 생성자(generator), 평가자(evaluator) 로 구성된 3개 에이전트 아키텍처가 만들어졌다. 이 구조는 몇 시간에 걸친 자율 코딩 세션 동안 꽤 풍부한 풀스택 애플리케이션을 만들어냈다.

왜 순진한 구현은 한계에 부딪히는가

Anthropic은 이전 글에서 장기 실행 에이전트형 코딩에서 하네스 설계가 성능에 큰 영향을 준다는 점을 보였다. 당시 실험에서는 초기화 에이전트가 제품 사양을 작업 목록으로 분해하고, 코딩 에이전트가 기능을 하나씩 구현했다. 세션 사이에는 산출물을 넘겨 맥락을 이어갔다.

개발자 커뮤니티에서도 비슷한 통찰이 확산됐다. 예를 들어 “Ralph Wiggum” 방식처럼 훅이나 스크립트를 사용해 에이전트가 계속 반복 작업을 하도록 만드는 접근이 있다.

하지만 복잡한 작업에서는 여전히 문제가 남았다. 저자는 이런 장기 작업에서 에이전트가 자주 보이는 실패 양상을 크게 두 가지로 나눴다.

1. 긴 작업에서 맥락 일관성이 무너진다

첫 번째 문제는 컨텍스트 창이 차오르면서 모델이 긴 작업의 일관성을 잃는다는 점이다. 일부 모델은 이른바 컨텍스트 불안(context anxiety) 을 보인다. 자신이 컨텍스트 한계에 가까워졌다고 느끼면, 실제로는 더 해야 할 일이 남아 있어도 서둘러 마무리하려는 경향이다.

이를 해결하는 방법 중 하나가 컨텍스트 리셋(context reset) 이다. 대화 기록을 완전히 비우고 새 에이전트를 시작하되, 이전 에이전트의 상태와 다음 단계가 담긴 구조화된 인수인계 문서를 함께 넘기는 방식이다.

이는 컴팩션(compaction) 과 다르다. 컴팩션은 이전 대화 일부를 요약해 같은 에이전트가 짧아진 히스토리 위에서 계속 작업하도록 한다. 연속성은 유지되지만, 에이전트에게 완전한 새 출발을 주지는 못한다. 그래서 컨텍스트 불안이 계속 남을 수 있다.

반면 리셋은 깨끗한 상태를 제공한다. 대신 다음 에이전트가 자연스럽게 이어받을 수 있을 만큼 인수인계 산출물이 충분히 좋아야 하고, 오케스트레이션 복잡도와 토큰 비용, 지연 시간이 늘어난다.

이전 테스트에서 Claude Sonnet 4.5는 컨텍스트 불안이 강하게 나타났고, 컴팩션만으로는 장기 작업 성능을 충분히 확보하기 어려웠다. 그래서 당시 하네스 설계에서는 컨텍스트 리셋이 필수 요소가 됐다.

2. 자기 평가가 지나치게 후하다

두 번째 문제는 자기 평가다. 에이전트에게 자신이 만든 결과물을 평가하라고 하면, 결과가 인간 눈에는 평범하거나 부족해 보여도 자신 있게 칭찬하는 경향이 있다.

이 문제는 디자인처럼 주관적인 작업에서 특히 두드러진다. 레이아웃이 세련됐는지, 너무 흔한지, 완성도가 있는지는 테스트 통과 여부처럼 이진적으로 판단하기 어렵다. 모델은 이런 상황에서 자신이 만든 결과물을 후하게 평가하기 쉽다.

검증 가능한 결과가 있는 작업에서도 비슷한 문제는 남는다. 에이전트가 작업 중 잘못된 판단을 해 성능을 떨어뜨리는 경우가 있다.

그래서 저자는 일을 하는 에이전트와 판단하는 에이전트를 분리하는 것이 강력한 레버라고 본다. 물론 평가자도 LLM이므로 처음부터 완전히 엄격하지는 않다. LLM이 만든 결과물에 관대해지는 경향은 여전히 있다. 그러나 독립된 평가자를 회의적으로 튜닝하는 일은, 생성자가 자기 작업을 스스로 냉정하게 보도록 만드는 것보다 훨씬 다루기 쉽다. 그리고 외부 피드백이 생기면 생성자는 그 피드백을 바탕으로 구체적으로 반복 개선할 수 있다.

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

저자는 먼저 프런트엔드 디자인에서 실험을 시작했다. 자기 평가 문제가 가장 잘 보이는 영역이었기 때문이다. 아무 개입이 없으면 Claude는 대체로 안전하고 예측 가능한 레이아웃을 만든다. 기능적으로는 돌아가지만 시각적으로는 특별하지 않은 결과가 나오기 쉽다.

이 실험의 핵심 통찰은 두 가지였다.

첫째, 미학은 완전히 점수로 환원할 수 없고 개인 취향도 다르지만, 디자인 원칙과 선호를 반영한 채점 기준을 만들면 개선할 수 있다. “이 디자인이 아름다운가?”는 일관되게 답하기 어렵지만, “이 디자인이 우리가 정한 좋은 디자인 원칙을 따르는가?”는 훨씬 구체적인 평가 질문이 된다.

둘째, 프런트엔드를 생성하는 에이전트와 평가하는 에이전트를 분리하면, 생성자를 더 강한 결과물로 밀어주는 피드백 루프를 만들 수 있다.

저자는 생성자와 평가자 모두에게 네 가지 채점 기준을 프롬프트로 제공했다.

디자인 품질

디자인이 여러 부품의 단순 조합이 아니라 하나의 일관된 전체처럼 느껴지는가? 좋은 결과물은 색, 타이포그래피, 레이아웃, 이미지, 세부 요소가 결합해 뚜렷한 분위기와 정체성을 만든다.

독창성

커스텀 의사결정의 흔적이 있는가, 아니면 템플릿 레이아웃과 라이브러리 기본값, AI가 자주 만드는 패턴에 머무르는가? 인간 디자이너가 봤을 때 의도적인 창의적 선택이 보여야 한다. 수정 없는 기본 컴포넌트나, 흰 카드 위 보라색 그라디언트처럼 AI 생성물에서 자주 보이는 클리셰는 감점 대상이다.

제작 완성도

타이포그래피 계층, 여백 일관성, 색 조화, 대비 비율 같은 기술적 실행 품질을 본다. 이는 창의성보다 기본기 체크에 가깝다. 대부분의 합리적 구현은 기본적으로 괜찮은 점수를 받지만, 실패한다면 기초가 무너진 것이다.

기능성

미학과 별개로 사용 가능한가? 사용자가 인터페이스의 목적을 이해하고, 주요 행동을 찾고, 추측 없이 과업을 완료할 수 있는가?

저자는 제작 완성도와 기능성보다 디자인 품질과 독창성을 더 강조했다. Claude는 기본적으로 제작 완성도와 기능성에서는 잘하는 편이었지만, 디자인 품질과 독창성에서는 밋밋한 결과가 자주 나왔다. 그래서 기준은 일반적인 “AI 슬롭” 패턴을 명시적으로 벌점 처리하고, 더 미적인 위험 감수를 하도록 유도했다.

평가자는 few-shot 예시와 상세한 점수 분해를 통해 보정했다. 이를 통해 평가자의 판단이 저자의 선호와 맞도록 했고, 반복 과정에서 점수가 흔들리는 문제도 줄였다.

생성자-평가자 루프는 어떻게 동작했나

저자는 Claude Agent SDK 위에 루프를 만들었다. 생성자 에이전트는 사용자 프롬프트를 바탕으로 HTML/CSS/JS 프런트엔드를 만든다. 평가자에게는 Playwright MCP를 제공해 실제 페이지를 탐색하도록 했다.

평가자는 정적인 스크린샷만 보고 점수를 매기지 않았다. 직접 페이지를 열고, 상호작용하고, 스크린샷을 찍고, 구현을 주의 깊게 살펴본 뒤 각 기준에 점수를 주고 상세한 비평을 작성했다. 이 피드백은 다시 생성자에게 전달되어 다음 반복의 입력이 됐다.

하나의 생성 과정에서는 보통 5~15번의 반복이 이루어졌다. 반복이 진행될수록 생성자는 평가자의 비평에 반응하며 더 독특한 방향으로 이동하는 경우가 많았다. 평가자가 실제 페이지를 탐색했기 때문에 각 사이클은 실제 시간도 꽤 걸렸다. 전체 실행은 최대 4시간까지 늘어났다.

저자는 생성자에게 평가 후 전략적 결정을 하라고 지시했다. 점수가 좋아지는 추세라면 현재 방향을 다듬고, 접근이 잘 먹히지 않는다면 완전히 다른 미적 방향으로 전환하라는 것이다.

실험 전반에서 평가자의 점수는 반복을 거치며 좋아지다가 어느 지점에서 정체됐다. 일부 결과물은 점진적으로 다듬어졌고, 어떤 결과물은 반복 사이에 과감한 미적 전환을 보였다.

흥미로운 점은 채점 기준의 문구 자체가 생성자를 예상 밖의 방향으로 이끌었다는 것이다. 예를 들어 “최고의 디자인은 박물관 수준이어야 한다” 같은 표현은 결과물을 특정한 시각적 경향으로 수렴시켰다. 즉, 기준에 포함된 언어가 출력물의 성격까지 형성한 셈이다.

점수는 대체로 반복하면서 좋아졌지만 항상 선형적으로 개선된 것은 아니었다. 뒤쪽 구현이 전체적으로 더 나은 경우가 많았지만, 저자는 중간 반복이 마지막 결과보다 더 마음에 드는 경우도 자주 봤다. 구현 복잡도도 라운드가 지날수록 늘어났다. 생성자가 평가자의 피드백에 반응해 더 야심 찬 해결책을 시도했기 때문이다.

한편 첫 번째 반복 결과부터, 아무 프롬프트 기준이 없는 기본 생성보다 눈에 띄게 좋았다. 이는 평가 피드백이 들어가기 전부터 채점 기준과 그 언어 자체가 모델을 흔한 기본값에서 멀어지게 했다는 뜻이다.

네덜란드 미술관 예시

한 예에서 저자는 네덜란드 미술관 웹사이트를 만들라고 요청했다. 9번째 반복까지 모델은 가상의 미술관을 위한 깔끔한 다크 테마 랜딩 페이지를 만들었다. 시각적으로 세련됐지만 예상 가능한 범위 안에 있었다.

그런데 10번째 사이클에서 모델은 기존 접근을 완전히 버리고, 사이트를 공간적 경험으로 재구성했다. CSS perspective로 렌더링한 체크무늬 바닥의 3D 방, 벽에 자유롭게 걸린 작품들, 스크롤이나 클릭 대신 문을 통해 갤러리 룸 사이를 이동하는 내비게이션이 등장했다.

저자는 이것이 단일 패스 생성에서는 보기 어려웠던 창의적 도약이었다고 평가한다.

풀스택 코딩으로 확장하기

프런트엔드 실험에서 얻은 결과를 바탕으로 저자는 같은 GAN식 패턴을 풀스택 개발에 적용했다. 생성자-평가자 루프는 소프트웨어 개발 생명주기에도 자연스럽게 대응된다. 코드 리뷰와 QA가 디자인 평가자와 같은 구조적 역할을 하기 때문이다.

3개 에이전트 구조

이전 장기 실행 하네스에서는 초기화 에이전트, 기능 단위로 작업하는 코딩 에이전트, 세션 사이 컨텍스트 리셋을 통해 여러 세션에 걸친 일관된 코딩을 해결했다. 컨텍스트 리셋은 핵심이었다. 당시 사용한 Sonnet 4.5는 앞서 말한 컨텍스트 불안 경향을 보였고, 리셋을 잘 다루는 하네스가 작업 지속성의 열쇠였다.

하지만 Opus 4.5에서는 이 행동이 상당 부분 사라졌다. 그래서 저자는 이 하네스에서 컨텍스트 리셋을 완전히 제거할 수 있었다. 모든 에이전트는 전체 빌드 동안 하나의 연속 세션으로 실행됐고, Claude Agent SDK의 자동 컴팩션이 컨텍스트 증가를 처리했다.

새 하네스는 세 가지 에이전트 페르소나로 구성됐다.

플래너

이전 장기 실행 하네스는 사용자가 상세한 제품 명세를 미리 제공해야 했다. 저자는 이 단계를 자동화하고 싶었다. 그래서 플래너 에이전트가 1~4문장의 간단한 프롬프트를 받아 전체 제품 사양으로 확장하도록 했다.

플래너에게는 범위를 야심 있게 잡되, 세부 기술 구현보다 제품 맥락과 상위 수준 기술 설계에 집중하라고 지시했다. 플래너가 지나치게 세부 구현을 정했다가 틀리면, 그 오류가 이후 구현 전체로 전파될 수 있기 때문이다. 산출물의 목표는 제한하되, 구체적인 경로는 에이전트들이 작업하면서 찾아가게 하는 편이 더 낫다고 판단했다.

또한 플래너에게 제품 명세 안에 AI 기능을 자연스럽게 엮을 기회를 찾으라고 했다.

생성자

이전 하네스에서 기능을 하나씩 구현하는 방식은 범위 관리에 효과적이었다. 저자는 비슷한 모델을 적용해 생성자가 스프린트 단위로 작업하도록 했다. 생성자는 명세에서 기능 하나를 골라 구현하고, 각 스프린트에서 React, Vite, FastAPI, SQLite 또는 나중에는 PostgreSQL 스택으로 앱을 만들었다.

생성자는 스프린트가 끝날 때 자기 평가를 한 뒤 QA에게 넘기도록 지시받았다. 버전 관리를 위해 git도 사용할 수 있었다.

평가자

이전 하네스에서 만들어진 앱은 겉보기에는 인상적이어도 실제로 사용해보면 버그가 남는 경우가 많았다. 이를 잡기 위해 평가자는 Playwright MCP를 사용해 실제 사용자처럼 실행 중인 애플리케이션을 클릭하고 테스트했다. UI 기능, API 엔드포인트, 데이터베이스 상태를 확인했다.

그 후 프런트엔드 실험에서 가져온 기준을 앱 개발에 맞게 바꿔 각 스프린트를 평가했다. 기준은 제품 깊이, 기능성, 시각 디자인, 코드 품질을 포함했다. 각 기준에는 엄격한 통과 기준이 있었고, 하나라도 기준 이하이면 스프린트는 실패했다. 생성자는 무엇이 잘못됐는지에 대한 상세 피드백을 받았다.

스프린트 계약

각 스프린트 전에 생성자와 평가자는 스프린트 계약(sprint contract) 을 협상했다. 즉, 코드를 쓰기 전에 해당 작업 단위에서 “완료”가 무엇인지 합의했다.

제품 명세가 의도적으로 상위 수준이었기 때문에, 사용자 스토리와 테스트 가능한 구현 사이의 간극을 메우는 단계가 필요했다. 생성자는 무엇을 만들고 어떻게 성공을 검증할지 제안했고, 평가자는 이 제안이 올바른 것을 만들고 있는지 검토했다. 둘은 합의할 때까지 반복했다.

에이전트 간 커뮤니케이션은 파일로 처리됐다. 한 에이전트가 파일을 쓰면 다른 에이전트가 읽고, 같은 파일에 응답하거나 새 파일을 만들어 이전 에이전트가 읽도록 했다. 생성자는 합의된 계약을 기준으로 구현한 뒤 QA에 넘겼다. 이 방식은 구현을 너무 일찍 과도하게 명시하지 않으면서도 명세에 충실하게 유지하는 데 도움이 됐다.

첫 번째 실험: 레트로 게임 제작기

하네스의 첫 버전에서는 Claude Opus 4.5를 사용했다. 저자는 전체 하네스와 단일 에이전트 시스템을 같은 사용자 프롬프트로 비교했다.

프롬프트는 다음과 같았다.

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

결과는 비용과 시간이 크게 달랐다.

하네스 유형	실행 시간	비용
단일 에이전트	20분	9달러
전체 하네스	6시간	200달러

전체 하네스는 20배 이상 비쌌지만, 결과 품질 차이는 즉시 드러났다.

저자는 레벨과 스프라이트, 엔티티, 타일 배치를 만들고 실행 버튼을 눌러 실제로 플레이할 수 있는 인터페이스를 기대했다. 단일 에이전트 결과물은 처음 보기에는 기대와 비슷했다.

하지만 클릭해보자 문제가 드러났다. 레이아웃은 고정 높이 패널 때문에 화면 대부분을 낭비했다. 워크플로도 경직돼 있었다. 레벨을 채우려면 먼저 스프라이트와 엔티티를 만들어야 했지만, UI는 그 순서를 안내하지 않았다. 더 중요한 문제는 게임 자체가 깨져 있었다는 점이다. 엔티티는 화면에 나타났지만 입력에 반응하지 않았다. 코드를 살펴보니 엔티티 정의와 게임 런타임 사이의 연결이 끊겨 있었고, 표면적으로는 어디가 문제인지 알 수 없었다.

반면 전체 하네스 실행은 같은 한 문장 프롬프트에서 시작했지만, 플래너가 이를 10개 스프린트와 16개 기능으로 이루어진 명세로 확장했다. 핵심 에디터와 플레이 모드 외에도 스프라이트 애니메이션 시스템, 동작 템플릿, 사운드 효과와 음악, AI 보조 스프라이트 생성기와 레벨 디자이너, 공유 가능한 링크를 통한 게임 내보내기까지 포함됐다.

플래너는 프런트엔드 디자인 스킬도 읽고 사용해 앱의 시각 디자인 언어를 명세에 포함했다. 각 스프린트에서는 생성자와 평가자가 구현 세부 사항과 테스트 가능한 완료 조건을 계약으로 합의했다.

전체 하네스 결과물은 단일 에이전트보다 훨씬 더 매끄러웠다. 캔버스는 화면을 잘 활용했고, 패널 크기는 합리적이었으며, 인터페이스는 명세에서 정한 디자인 방향과 일관된 정체성을 가졌다.

물론 불편함이 완전히 사라진 것은 아니었다. 여전히 레벨을 채우기 전에 스프라이트와 엔티티를 만들어야 한다는 워크플로가 명확하지 않았고, 사용자가 직접 만져보며 알아내야 했다. 저자는 이를 하네스 자체의 실패라기보다 기본 모델의 제품 감각 한계로 봤다. 다만 하네스 안에서 이 부분을 더 타깃팅해 반복 개선할 수 있는 지점이기도 했다.

스프라이트 에디터는 더 풍부하고 완성도가 높았다. 도구 팔레트, 색상 선택기, 줌 컨트롤이 더 깨끗하고 사용하기 쉬웠다. 플래너가 AI 기능을 넣도록 지시받았기 때문에, 앱에는 프롬프트로 게임 일부를 생성할 수 있는 Claude 통합 기능도 들어갔다. 이는 작업 흐름을 크게 빠르게 했다.

가장 큰 차이는 플레이 모드였다. 전체 하네스 결과물에서는 실제로 엔티티를 움직이고 게임을 플레이할 수 있었다. 물리 처리에는 거친 부분이 있었다. 캐릭터가 플랫폼 위로 점프한 뒤 플랫폼과 겹치는 식의 직관적으로 이상한 현상이 있었다. 그래도 핵심 기능은 작동했다. 단일 에이전트는 이 부분을 달성하지 못했다.

다만 AI가 만든 레벨 구성에는 한계도 있었다. 점프로 넘을 수 없는 큰 벽이 있어 진행이 막혔다. 이는 하네스가 더 다듬을 수 있는 상식적 개선과 엣지 케이스가 남아 있음을 보여줬다.

평가자가 잡아낸 구체적 문제들

로그를 읽어보면 평가자가 구현을 명세에 맞게 유지하는 데 큰 역할을 했다는 점이 분명했다. 매 스프린트마다 평가자는 계약의 테스트 기준을 따라 실행 중인 애플리케이션을 Playwright로 조작했고, 기대 동작과 다른 부분에 버그를 기록했다.

계약은 매우 세밀했다. 예를 들어 스프린트 3 하나만 해도 레벨 에디터에 대해 27개의 기준이 있었다. 평가자의 지적은 추가 조사 없이도 바로 조치할 수 있을 정도로 구체적이었다.

계약 기준	평가자 발견 사항
사각형 채우기 도구가 클릭-드래그로 선택한 타일의 직사각형 영역을 채울 수 있어야 한다	실패 — 도구가 영역을 채우지 않고 드래그 시작/끝 지점에만 타일을 배치한다. `fillRectangle` 함수는 있지만 `mouseUp`에서 제대로 호출되지 않는다.
사용자가 배치된 엔티티 스폰 포인트를 선택하고 삭제할 수 있어야 한다	실패 — `LevelEditor.tsx:892`의 Delete 키 핸들러가 `selection`과 `selectedEntityId`가 모두 설정된 경우를 요구한다. 하지만 엔티티 클릭은 `selectedEntityId`만 설정한다. 조건은 `selection
API를 통해 애니메이션 프레임 순서를 바꿀 수 있어야 한다	실패 — `PUT /frames/reorder` 라우트가 `/{frame_id}` 라우트 뒤에 정의돼 있다. FastAPI가 `reorder`를 정수형 `frame_id`로 해석해 422 오류를 반환한다.

하지만 이 수준의 평가자를 얻는 데도 작업이 필요했다. 기본 상태의 Claude는 좋은 QA 에이전트가 아니었다. 초기 실행에서 Claude는 실제 문제를 찾아낸 뒤에도 스스로 “큰 문제는 아니다”라고 합리화하고 작업을 승인하곤 했다. 테스트도 얕게 하는 경향이 있어 더 미묘한 버그가 빠져나갔다.

튜닝 루프는 평가자의 로그를 읽고, 평가자의 판단이 저자의 판단과 어긋나는 사례를 찾은 뒤, QA 프롬프트를 업데이트하는 방식이었다. 평가자가 합리적으로 채점하도록 만들기까지 여러 라운드가 필요했다.

그래도 한계는 남았다. 작은 레이아웃 문제, 어색한 상호작용, 깊게 중첩된 기능에서 평가자가 충분히 건드리지 못한 버그가 있었다. 검증 측면에서는 아직 더 끌어올릴 여지가 있었다. 그러나 단일 에이전트 결과에서는 핵심 기능 자체가 작동하지 않았던 것과 비교하면, 하네스의 효과는 명확했다.

하네스를 다시 단순화하기

첫 결과는 고무적이었지만, 하네스는 무겁고 느리고 비쌌다. 자연스러운 다음 단계는 성능을 떨어뜨리지 않으면서 하네스를 단순화하는 것이었다.

여기에는 더 일반적인 원칙도 있다. 하네스의 모든 구성 요소는 모델이 혼자서는 무엇을 못한다고 가정한다. 이 가정은 계속 스트레스 테스트해야 한다. 틀렸을 수도 있고, 모델이 개선되면서 금방 낡을 수도 있기 때문이다.

Anthropic의 “Building Effective Agents” 글도 같은 생각을 말한다. 가능한 가장 단순한 해결책을 찾고, 필요할 때만 복잡도를 늘리라는 것이다. 에이전트 하네스를 유지하는 사람이라면 계속 마주치는 패턴이다.

저자는 처음에는 하네스를 급격히 줄이고 몇 가지 창의적 아이디어를 시도했지만, 원래 성능을 재현하지 못했다. 또한 어떤 구성 요소가 실제로 핵심인지 파악하기 어려워졌다. 그래서 더 체계적인 방식으로 바꿨다. 구성 요소를 하나씩 제거하고 최종 결과에 어떤 영향을 주는지 검토했다.

이 반복 과정 중 Anthropic은 Opus 4.6도 출시했다. 4.6은 4.5보다 적은 스캐폴딩만으로도 잘 작동할 가능성이 컸다. 출시 글에 따르면 Opus 4.6은 더 신중하게 계획하고, 에이전트형 작업을 더 오래 지속하며, 큰 코드베이스에서 더 안정적으로 작동하고, 자신의 실수를 잡는 코드 리뷰와 디버깅 능력이 좋아졌다. 장문맥 검색도 크게 개선됐다.

즉, 기존 하네스가 보완하려 했던 능력 중 일부를 모델 자체가 더 잘하게 된 것이다.

스프린트 구조 제거하기

저자는 먼저 스프린트 구조를 완전히 제거했다. 스프린트는 작업을 덩어리로 나눠 모델이 일관되게 처리하도록 도왔다. 하지만 Opus 4.6의 개선을 고려하면, 모델이 이런 분해 없이도 기본적으로 작업을 처리할 수 있을 가능성이 있었다.

플래너와 평가자는 유지했다. 둘 다 여전히 명확한 가치를 더했기 때문이다. 플래너가 없으면 생성자는 범위를 너무 작게 잡았다. 원시 프롬프트만 받고 곧바로 구현을 시작해, 플래너가 만든 것보다 기능이 적은 앱을 만들었다.

스프린트 구조를 없애면서 평가자는 각 스프린트마다 평가하는 대신, 실행 끝에 한 번 평가하도록 바뀌었다.

모델 능력이 좋아지면서 평가자의 중요도도 작업에 따라 달라졌다. 4.5에서는 빌드가 생성자 단독 능력의 경계에 가까웠고, 평가자가 전체 빌드에서 의미 있는 문제를 잡아냈다. 4.6에서는 모델의 기본 능력이 올라가 경계가 바깥으로 이동했다. 예전에는 평가자 확인이 있어야 일관되게 구현되던 작업도 이제는 생성자가 혼자 잘 처리하는 경우가 많아졌다. 그런 작업에서는 평가자가 불필요한 오버헤드가 됐다.

하지만 여전히 생성자의 능력 경계에 있는 부분에서는 평가자가 실제 가치를 더했다. 실용적 결론은 평가자가 고정된 예/아니오 선택지가 아니라는 것이다. 현재 모델이 단독으로 안정적으로 처리하지 못하는 과제라면 평가자 비용을 쓸 가치가 있다.

구조 단순화와 함께 저자는 각 앱에 AI 기능을 더 잘 넣도록 프롬프트도 개선했다. 특히 앱 자체 기능을 도구로 조작할 수 있는 제대로 된 에이전트를 생성자가 만들게 하는 데 초점을 맞췄다. 이 지식은 비교적 최신이라 Claude의 훈련 데이터에 얇게 포함돼 있었고, 실제로 제대로 만들기까지 많은 튜닝이 필요했다. 충분히 조정하자 생성자는 에이전트를 올바르게 만들기 시작했다.

두 번째 실험: 브라우저 기반 DAW

업데이트된 하네스를 시험하기 위해 저자는 다음 프롬프트를 사용했다.

Web Audio API를 사용해 브라우저에서 실행되는 완전한 기능의 DAW, 즉 음악 제작 프로그램을 만들어라.

이 실행도 여전히 길고 비쌌다. 약 4시간이 걸렸고 토큰 비용은 124달러였다.

대부분의 시간은 빌더에 들어갔다. Opus 4.5에서 필요했던 스프린트 분해 없이도 빌더는 2시간 넘게 일관되게 실행됐다.

에이전트 및 단계	시간	비용
플래너	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달러
V2 하네스 전체	3시간 50분	124.70달러

이전 하네스와 마찬가지로 플래너는 한 줄 프롬프트를 전체 명세로 확장했다. 로그상으로 생성자 모델은 앱과 에이전트 설계를 잘 계획했고, 에이전트를 연결하고 QA에 넘기기 전 자체 테스트도 수행했다.

그럼에도 QA 에이전트는 실제로 중요한 빈틈을 잡아냈다.

1차 피드백에서는 다음과 같은 지적이 있었다.

이 앱은 디자인 충실도, AI 에이전트, 백엔드가 훌륭한 강한 앱이다. 주요 실패 지점은 기능 완성도다. 앱은 인상적으로 보이고 AI 통합도 잘 작동하지만, 여러 핵심 DAW 기능이 인터랙티브한 깊이 없이 표시만 된다. 클립을 타임라인에서 드래그하거나 이동할 수 없고, 신스 노브나 드럼 패드 같은 악기 UI 패널이 없으며, EQ 커브나 컴프레서 미터 같은 시각적 이펙트 편집기도 없다. 이것들은 엣지 케이스가 아니라 DAW를 실제로 쓸 수 있게 만드는 핵심 상호작용이며, 명세가 명시적으로 요구한 부분이다.

2차 피드백에서도 기능 공백을 잡았다.

오디오 녹음은 여전히 스텁에 가깝다. 버튼은 토글되지만 마이크 캡처가 없다.
클립 가장자리 드래그로 크기 조정하기와 클립 분할이 구현되지 않았다.
이펙트 시각화가 그래픽이 아니라 숫자 슬라이더다. EQ 커브가 없다.

생성자는 혼자 두면 여전히 세부 사항을 놓치거나 기능을 스텁으로 남길 수 있었다. QA는 마지막 마일 문제를 잡아 생성자가 고치게 하는 데 여전히 가치가 있었다.

저자는 이 프롬프트에서 멜로디, 화성, 드럼 패턴을 만들고, 이를 곡으로 배열하며, 통합된 에이전트의 도움을 받을 수 있는 프로그램을 기대했다.

최종 앱은 전문 음악 제작 프로그램과는 거리가 있었다. 에이전트의 작곡 능력도 더 개선될 여지가 컸다. 또한 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 Retro Game Maker라는 웹 기반 창작 스튜디오다.

RetroForge는 2D 레트로 스타일 게임을 설계하고 만들기 위한 웹 기반 창작 도구다. 8비트와 16비트 게임의 향수를 현대적이고 직관적인 편집 도구와 결합해, 취미 창작자부터 인디 개발자까지 전통적인 코딩 없이 게임 아이디어를 구현할 수 있게 한다.

플랫폼은 네 가지 통합 창작 모듈을 제공한다.

타일 기반 레벨 에디터
픽셀 아트 스프라이트 에디터
게임 로직을 정의하는 시각적 엔티티 동작 시스템
실시간 게임플레이 테스트를 위한 즉시 실행 가능한 테스트 모드

여기에 Claude 기반 AI 지원을 전반에 엮어, 사용자가 자연어로 스프라이트를 생성하고, 레벨을 설계하고, 동작을 구성할 수 있게 한다.

RetroForge의 대상 사용자는 레트로 게임 미학을 좋아하지만 현대적 편의성을 원하는 창작자다. 어린 시절의 플랫폼 게임, RPG, 액션 게임을 재현하거나 레트로 제약 안에서 완전히 새로운 경험을 만들고 싶은 사용자가 빠르게 프로토타입을 만들고, 시각적으로 반복 개선하고, 결과물을 공유할 수 있도록 한다.

예시 기능 중 첫 번째는 프로젝트 대시보드와 관리다. 사용자는 새 게임 프로젝트를 만들고, 기존 작업을 다시 열고, 각 프로젝트가 무엇을 포함하는지 한눈에 이해할 수 있어야 한다.

사용자 스토리는 다음과 같다.

이름과 설명을 입력해 새 게임 프로젝트를 만들 수 있어야 한다.
기존 프로젝트를 카드 형태로 볼 수 있어야 한다. 카드에는 프로젝트 이름, 마지막 수정일, 썸네일 미리보기가 표시된다.
어떤 프로젝트든 열어 전체 게임 에디터 작업 공간으로 들어갈 수 있어야 한다.
필요 없는 프로젝트를 삭제할 수 있어야 하며, 실수 방지를 위해 확인 대화상자가 있어야 한다.
기존 프로젝트를 복제해 새 게임의 출발점으로 삼을 수 있어야 한다.

프로젝트 데이터 모델에는 프로젝트 메타데이터, 캔버스 설정, 타일 크기 설정, 색상 팔레트 선택, 그리고 관련 스프라이트·타일셋·레벨·엔티티 정의가 포함된다.

원문에는 이후 세부 계획이 생략 표시로 이어진다.

한 줄 요약

좋은 장기 실행 에이전트 시스템은 단순히 “더 똑똑한 모델”에 기대는 것이 아니라, 계획·생성·평가를 어떻게 나누고, 언제 단순화하며, 어떤 기준으로 반복 개선할지 설계하는 문제다.