Harness design for long-running application development 1

태그:

• “출처” url: “https://www.anthropic.com/engineering/harness-design-long-running-apps” created: 2026-03-27 status: false

---

Prithvi Rajasekaran, Anthropic Labs 팀원이 작성.

지난 몇 달 동안 저는 두 가지 상호 연결된 문제에 집중해 왔습니다. 하나는 Claude가 고품질 프런트엔드 디자인을 생성하도록 하는 것이고, 다른 하나는 인간의 개입 없이 완전한 애플리케이션을 구축하도록 하는 것입니다. 이 작업은 우리의 프런트엔드 디자인 스킬 및 장기 실행 에이전트용 허들 설계에 대한 이전 노력을 통해 시작되었으며, 여기서 동료들과 저는 프롬프트 엔지니어링과 허들 설계를 통해 Claude의 성능을 기준선보다 훨씬 더 향상시킬 수 있었지만, 결국 둘 다 한계에 부딪혔습니다.

돌파구를 마련하기 위해, 저는 두 가지 매우 다른 영역, 즉 주관적인 취향에 의해 정의되는 영역과 검증 가능한 정확성과 사용성에 의해 정의되는 영역에 걸쳐 적용될 수 있는 새로운 AI 엔지니어링 접근 방식을 모색했습니다. 생성적 적대 신경망 (GAN)에서 영감을 받아, 저는 생성자와 평가자 에이전트로 구성된 다중 에이전트 구조를 설계했습니다. 신뢰할 수 있고 취향에 맞는 출력물을 평가하는 평가자를 구축하려면, “이 디자인이 좋은가?”와 같은 주관적인 판단을 구체적이고 채점 가능한 용어로 변환할 수 있는 일련의 기준을 먼저 개발해야 했습니다.

그런 다음 저는 이러한 기술을 장기 실행 자율 코딩에 적용했으며, 이전 허들 작업에서 얻은 두 가지 교훈을 가져왔습니다. 하나는 빌드를 처리 가능한 청크로 분해하는 것이고, 다른 하나는 세션 간에 컨텍스트를 인계하기 위해 구조화된 아티팩트를 사용하는 것입니다. 최종 결과물은 플래너, 생성자, 평가자의 세 가지 에이전트 아키텍처였으며, 이는 몇 시간에 걸친 자율 코딩 세션에서 풍부한 풀스택 애플리케이션을 생성했습니다.

왜 단순 구현은 부족한가

우리는 이전에 허들 설계가 장기 실행 에이전트 코딩의 효과성에 상당한 영향을 미친다는 것을 보여주었습니다. 이전 실험에서 우리는 초기화 에이전트를 사용하여 제품 사양을 작업 목록으로 분해하고, 코딩 에이전트가 세션 간에 컨텍스트를 전달하기 위해 아티팩트를 인계하기 전에 한 번에 한 기능씩 작업을 구현하도록 했습니다. 더 광범위한 개발자 커뮤니티도 유사한 통찰력에 수렴하고 있으며, ” 랄프 위검 ” 방법과 같이 에이전트를 연속적인 반복 주기 내에 유지하기 위해 훅이나 스크립트를 사용하는 접근 방식이 있습니다.

하지만 일부 문제는 계속해서 발생했습니다. 더 복잡한 작업의 경우, 에이전트가 시간이 지남에 따라 탈선하는 경향이 여전히 있습니다. 이 문제를 분해하면서, 우리는 에이전트가 이러한 종류의 작업을 실행할 때 발생하는 두 가지 일반적인 실패 모드를 관찰했습니다.

첫 번째는 컨텍스트 창이 채워짐에 따라 모델이 긴 작업에서 일관성을 잃는 경향이 있다는 것입니다( 에이전트용 효과적인 컨텍스트 엔지니어링에 대한 게시물 참조). 일부 모델은 컨텍스트 한계에 가까워지면서 작업을 조기에 마무리하기 시작하는 “컨텍스트 불안”을 보이기도 합니다. 컨텍스트 재설정—컨텍스트 창을 완전히 지우고 새 에이전트를 시작한 다음 이전 에이전트의 상태와 다음 단계를 전달하는 구조화된 인계와 결합—은 이 두 가지 문제를 모두 해결합니다.

이는 압축과는 다릅니다. 압축에서는 대화의 이전 부분이 제자리에서 요약되어 동일한 에이전트가 단축된 기록으로 작업을 계속할 수 있습니다. 압축은 연속성을 유지하지만 에이전트에게 깨끗한 시작을 제공하지 않으므로 컨텍스트 불안이 계속될 수 있습니다. 재설정은 깨끗한 시작을 제공하지만, 다음 에이전트가 작업을 원활하게 인계받을 수 있을 만큼 충분한 상태를 인계 아티팩트에 포함해야 하는 비용이 발생합니다. 이전 테스트에서 우리는 Claude Sonnet 4.5가 컨텍스트 불안을 충분히 강하게 보였기 때문에 압축만으로는 강력한 장기 작업 성능을 지원하기에 불충분했으며, 따라서 컨텍스트 재설정이 허들 설계에 필수적이 되었습니다. 이것은 핵심 문제를 해결하지만, 각 허들 실행에 오케스트레이션 복잡성, 토큰 오버헤드 및 지연 시간을 추가합니다.

우리가 이전에 다루지 않았던 두 번째 문제는 자체 평가입니다. 에이전트에게 자신이 생성한 작업을 평가하도록 요청하면, 인간 관찰자에게 품질이 명백히 평범하더라도 작업에 대해 자신 있게 칭찬하는 경향이 있습니다. 이 문제는 디자인과 같이 검증 가능한 소프트웨어 테스트에 해당하는 이진 확인이 없는 주관적인 작업에서 특히 두드러집니다. 레이아웃이 세련되었는지 아니면 평범한 느낌인지는 판단의 문제이며, 에이전트는 자신의 작업을 평가할 때 일관되게 긍정적으로 편향됩니다.

그러나 검증 가능한 결과가 있는 작업에서도 에이전트는 작업을 완료하는 동안 성능을 저해하는 잘못된 판단을 보일 때가 있습니다. 작업을 수행하는 에이전트와 그것을 판단하는 에이전트를 분리하는 것이 이 문제를 해결하는 강력한 지렛임이 입증되었습니다. 분리가 그 자체로 즉시 관대함을 제거하지는 않습니다. 평가자는 여전히 LLM 생성 출력물에 대해 관대한 경향이 있는 LLM이기 때문입니다. 그러나 독립형 평가자를 회의적으로 조정하는 것이 자신의 작업에 비판적인 생성자를 만드는 것보다 훨씬 다루기 쉽다는 것이 밝혀졌으며, 외부 피드백이 존재하면 생성자는 반복할 구체적인 대상을 갖게 됩니다.

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

저는 자체 평가 문제가 가장 두드러지게 나타나는 프런트엔드 디자인 실험부터 시작했습니다. 개입 없이는 Claude는 일반적으로 기술적으로 기능적이지만 시각적으로 평범한 안전하고 예측 가능한 레이아웃으로 기울어집니다.

두 가지 통찰이 제가 프런트엔드 디자인을 위해 구축한 허들에 영향을 미쳤습니다. 첫째, 미학을 점수로 완전히 축소할 수는 없으며 개인적인 취향은 항상 다를 수 있지만, 디자인 원칙과 선호도를 인코딩하는 채점 기준을 사용하여 개선할 수 있다는 것입니다. “이 디자인이 아름다운가?”라는 질문에 일관되게 답하기는 어렵지만, “이것이 좋은 디자인을 위한 우리의 원칙을 따르는가?”는 Claude가 채점할 구체적인 대상을 제공합니다. 둘째, 프런트엔드 생성과 프런트엔드 채점을 분리함으로써 생성자를 더 강력한 출력물로 이끄는 피드백 루프를 만들 수 있습니다.

이를 염두에 두고, 저는 생성자 에이전트와 평가자 에이전트 모두에게 프롬프트에서 제공한 네 가지 채점 기준을 작성했습니다.

• 디자인 품질: 디자인이 부분들의 모음이 아니라 일관된 전체처럼 느껴지는가? 여기서 강력한 작업은 색상, 타이포그래피, 레이아웃, 이미지 및 기타 세부 사항이 결합되어 뚜렷한 분위기와 정체성을 만든다는 것을 의미합니다.
• 독창성: 사용자 정의 결정의 증거가 있는가, 아니면 템플릿 레이아웃, 라이브러리 기본값 및 AI 생성 패턴인가? 인간 디자이너는 의도적인 창의적인 선택을 인식해야 합니다. 수정되지 않은 스톡 구성 요소(또는 흰색 카드 위의 보라색 그라데이션과 같은 AI 생성의 뚜렷한 징후)는 여기서 실패합니다.
• 장인 정신: 기술적 실행: 타이포그래피 계층, 간격 일관성, 색상 조화, 대비 비율. 이것은 창의성 확인이라기보다는 역량 확인입니다. 대부분의 합리적인 구현은 기본적으로 잘 수행됩니다. 실패는 기본 사항이 깨졌음을 의미합니다.
• 기능성: 미학과 무관한 사용성. 사용자가 인터페이스가 무엇을 하는지 이해하고, 기본 작업을 찾고, 추측 없이 작업을 완료할 수 있는가?

저는 장인 정신과 기능성보다 디자인 품질과 독창성을 강조했습니다. Claude는 기본적으로 장인 정신과 기능성에서 이미 점수가 좋았는데, 필요한 기술적 역량이 모델에 자연스럽게 오는 경향이 있었기 때문입니다. 그러나 디자인과 독창성에 있어서 Claude는 종종 최고의 경우에도 평범한 출력물을 생성했습니다. 이 기준은 매우 일반적인 “AI 슬롭” 패턴을 명시적으로 처벌했으며, 디자인과 독창성에 더 많은 비중을 두어 모델이 더 미학적인 위험을 감수하도록 유도했습니다.

저는 상세한 점수 분석이 포함된 퓨샷 예제를 사용하여 평가자를 조정했습니다. 이는 평가자의 판단이 나의 선호도와 일치하도록 보장하고 반복에 따른 점수 편차를 줄였습니다.

저는 Claude Agent SDK를 기반으로 루프를 구축하여 오케스트레이션을 간단하게 유지했습니다. 생성자 에이전트는 먼저 사용자 프롬프트를 기반으로 HTML/CSS/JS 프런트엔드를 생성했습니다. 평가자에게 Playwright MCP를 제공하여 라이브 페이지와 직접 상호 작용하여 각 기준을 채점하고 자세한 비평을 작성할 수 있도록 했습니다. 실제로는 평가자가 자체적으로 페이지를 탐색하고, 구현을 스크린샷 찍고 주의 깊게 연구한 후 평가를 생성했습니다. 이 피드백은 다음 반복을 위한 입력으로 생성자에게 전달되었습니다. 각 세대는 일반적으로 평가자의 비평에 반응하여 생성자를 더 뚜렷한 방향으로 이끌었으므로, 세대당 5~15회 반복을 실행했습니다. 평가자가 정적 스크린샷을 채점하는 대신 페이지를 적극적으로 탐색했기 때문에 각 주기는 실제 경과 시간을 필요로 했습니다. 전체 실행은 최대 4시간까지 이어졌습니다. 또한 저는 생성자에게 각 평가 후 전략적 결정을 내리도록 지시했습니다. 점수가 잘 나오고 있다면 현재 방향을 개선하고, 접근 방식이 작동하지 않으면 완전히 다른 미학으로 전환하도록 했습니다.

실행 전반에 걸쳐 평가자의 평가는 반복되면서 개선되었고 이후 정체되었으며, 여전히 여지가 남아 있었습니다. 일부 세대는 점진적으로 개선되었습니다. 다른 세대는 반복 사이에 급격한 미학적 전환을 보였습니다.

기준의 문구는 제가 예상하지 못했던 방식으로 생성자를 유도했습니다. “최고의 디자인은 박물관 품질이다”와 같은 문구를 포함하면 디자인이 특정 시각적 수렴을 향해 나아가도록 유도했으며, 이는 기준과 관련된 프롬프트가 출력물의 특성을 직접적으로 형성했음을 시사합니다.

점수는 일반적으로 반복을 통해 개선되었지만 패턴이 항상 명확하게 선형적이지는 않았습니다. 후기 구현이 전체적으로 더 나은 경향이 있었지만, 마지막 반복보다 중간 반복을 더 선호하는 경우를 정기적으로 보았습니다. 구현 복잡성도 라운드를 거치면서 증가하는 경향이 있었고, 생성자는 평가자의 피드백에 대한 반응으로 더 야심 찬 해결책을 찾았습니다. 평가자의 피드백으로 인한 추가적인 개선이 있기 전에 심지어 첫 번째 반복에서도 출력물은 기본 프롬프팅만 사용했을 때보다 눈에 띄게 더 나았습니다. 이는 기준과 관련 언어 자체가 모델을 일반적인 기본값에서 벗어나도록 유도했음을 시사합니다.

한 가지 주목할 만한 예에서, 저는 모델에게 네덜란드 미술관 웹사이트를 만들도록 요청했습니다. 9번째 반복에서는 가상 박물관을 위한 깔끔하고 어두운 테마의 랜딩 페이지를 생성했습니다. 페이지는 시각적으로 세련되었지만 내 예상 범위 내에 있었습니다. 그런 다음 10번째 주기에서 접근 방식을 완전히 폐기하고 사이트를 공간적 경험으로 재구상했습니다. CSS 원근법으로 렌더링된 체크무늬 바닥이 있는 3D 방, 자유로운 위치에 걸린 예술 작품, 스크롤이나 클릭 대신 갤러리 방 사이를 이동하기 위한 문 기반 탐색이었습니다. 이는 단일 패스 생성에서는 이전에 볼 수 없었던 종류의 창의적인 도약이었습니다.

풀스택 코딩으로 확장

이러한 발견을 바탕으로, 저는 이 GAN에서 영감을 받은 패턴을 풀스택 개발에 적용했습니다. 생성자-평가자 루프는 코드 검토 및 QA가 디자인 평가자와 동일한 구조적 역할을 수행하는 소프트웨어 개발 수명 주기에 자연스럽게 매핑됩니다.

아키텍처

이전의 장기 실행 허들에서는 초기화 에이전트, 한 번에 한 기능씩 작업하는 코딩 에이전트, 세션 간의 컨텍스트 재설정을 통해 일관된 다중 세션 코딩을 해결했습니다. 컨텍스트 재설정은 핵심적인 잠금 해제 요소였습니다. 허들은 앞서 언급한 “컨텍스트 불안” 경향을 보인 Sonnet 4.5를 사용했습니다. 컨텍스트 재설정을 잘 수행하는 허들을 만드는 것이 모델이 작업에 집중하도록 유지하는 데 중요했습니다. Opus 4.5는 그 자체로 해당 동작을 크게 제거했으므로, 저는 이 허들에서 컨텍스트 재설정을 완전히 생략할 수 있었습니다. 에이전트는 전체 빌드에 걸쳐 단일 연속 세션으로 실행되었으며, Claude Agent SDK의 자동 압축 기능이 컨텍스트 증가를 처리했습니다.

이 작업을 위해 저는 이전 실행에서 관찰한 각 간격을 해결하는 세 가지 에이전트 시스템으로 원래 허들의 기반을 구축했습니다. 이 시스템은 다음과 같은 에이전트 페르소나를 포함했습니다.

플래너: 이전의 장기 실행 허들은 사용자가 처음에 상세한 사양을 제공하도록 요구했습니다. 저는 이 단계를 자동화하고 싶었고, 간단한 1~4문장 프롬프트를 받아 전체 제품 사양으로 확장하는 플래너 에이전트를 만들었습니다. 저는 이 에이전트에게 범위에 대해 야심차게 생각하고, 세부적인 기술 구현보다는 제품 컨텍스트와 높은 수준의 기술 설계에 집중하도록 프롬프트를 지정했습니다. 이러한 강조는 플래너가 사전에 세부적인 기술 세부 사항을 지정하려고 시도하고 무언가를 잘못했을 경우 사양의 오류가 다운스트림 구현으로 퍼질 것이라는 우려 때문이었습니다. 에이전트에게 생성해야 할 산출물을 제약하고 작업하면서 경로를 스스로 파악하도록 하는 것이 더 현명해 보였습니다. 또한 플래너에게 제품 사양에 AI 기능을 엮어 넣을 기회를 찾도록 요청했습니다. (아래 부록에서 예시 참조.)

생성자: 이전 허들의 한 번에 한 기능씩 접근 방식은 범위 관리에 효과적이었습니다. 저는 여기서 유사한 모델을 적용하여, 생성자가 스프린트로 작업하고 사양에서 한 번에 한 기능씩 가져오도록 지시했습니다. 각 스프린트는 React, Vite, FastAPI 및 SQLite(나중에 PostgreSQL) 스택을 사용하여 앱을 구현했으며, 생성자는 각 스프린트가 끝날 때 작업을 자체 평가하고 QA에 인계하도록 지시받았습니다. 또한 버전 관리를 위해 Git을 사용했습니다.

평가자: 이전 허들에서 나온 애플리케이션은 종종 인상적으로 보였지만 실제 사용 시 실제 버그가 있었습니다. 이를 잡기 위해 평가자는 Playwright MCP를 사용하여 실행 중인 애플리케이션을 사용자가 하는 것처럼 클릭하여 UI 기능, API 엔드포인트 및 데이터베이스 상태를 테스트했습니다. 그런 다음 각 스프린트를 발견한 버그와 프런트엔드 실험을 모델링하여 제품 깊이, 기능성, 시각적 디자인 및 코드 품질을 다루도록 조정된 일련의 기준에 따라 채점했습니다. 각 기준에는 엄격한 임계값이 있었고, 하나라도 이 임계값 미만으로 떨어지면 스프린트가 실패하고 생성자는 무엇이 잘못되었는지에 대한 자세한 피드백을 받았습니다.

각 스프린트 전에 생성자와 평가자는 스프린트 계약을 협상했습니다. 코드가 작성되기 전에 해당 작업 청크에 대해 “완료”가 무엇을 의미하는지에 동의했습니다. 이는 제품 사양이 의도적으로 높은 수준이었기 때문에 사용자 스토리와 테스트 가능한 구현 사이의 격차를 해소할 단계가 필요했기 때문입니다. 생성자는 구축할 내용과 성공을 확인할 방법을 제안했고, 평가자는 생성자가 올바른 것을 구축하고 있는지 확인하기 위해 해당 제안을 검토했습니다. 두 에이전트는 동의할 때까지 반복했습니다.

통신은 파일을 통해 처리되었습니다. 한 에이전트가 파일을 작성하면 다른 에이전트가 해당 파일을 읽고 해당 파일 내에서 응답하거나 이전 에이전트가 차례로 읽을 새 파일을 작성했습니다. 그런 다음 생성자는 합의된 계약에 따라 구축한 다음 QA에 인계했습니다. 이는 구현을 너무 일찍 세부적으로 지정하지 않으면서 작업을 사양에 충실하게 유지했습니다.

허들 실행

이 허들의 첫 번째 버전을 위해 저는 사용자 프롬프트를 전체 허들과 비교를 위한 단일 에이전트 시스템 모두에 대해 실행하기 위해 Claude Opus 4.5를 사용했습니다. 이 실험을 시작했을 때 최고의 코딩 모델이었기 때문에 Opus 4.5를 사용했습니다.

복고풍 비디오 게임 제작기를 생성하기 위해 다음 프롬프트를 작성했습니다.

레벨 편집기, 스프라이트 편집기, 엔티티 동작 및 재생 가능한 테스트 모드를 포함한 기능을 갖춘 2D 복고풍 게임 제작기를 만드세요.

아래 표는 허들 유형, 실행된 길이 및 총 비용을 보여줍니다.

허들	기간	비용
단독	20분	$9
전체 허들	6시간	$200

허들이 20배 이상 비쌌지만, 출력 품질의 차이는 즉시 분명해졌습니다.

저는 사용자가 레벨과 그 구성 요소(스프라이트, 엔티티, 타일 레이아웃)를 구성한 다음 재생을 눌러 실제로 레벨을 플레이할 수 있는 인터페이스를 예상했습니다. 단독 실행의 출력을 열어보았을 때 초기 애플리케이션은 이러한 기대치와 일치하는 것처럼 보였습니다.

그러나 클릭하면서 문제가 나타나기 시작했습니다. 레이아웃은 고정 높이 패널이 뷰포트 대부분을 비워 두어 공간을 낭비했습니다. 워크플로가 경직되었습니다. 레벨을 채우려고 하면 먼저 스프라이트와 엔티티를 만들도록 알려주었지만 UI에서는 해당 순서를 안내하는 것이 전혀 없었습니다. 더 중요한 것은 실제 게임이 작동하지 않았다는 것입니다. 내 엔티티는 화면에 나타났지만 아무것도 입력에 반응하지 않았습니다. 코드를 자세히 살펴보니 엔티티 정의와 게임 런타임 간의 연결이 끊어져 있었고, 어디가 끊어졌는지에 대한 표면적인 표시는 없었습니다.

단독 허들이 생성한 앱을 열었을 때의 초기 화면.

단독 실행을 평가한 후, 저는 허들 실행에 관심을 돌렸습니다. 이 실행은 동일한 한 문장 프롬프트에서 시작했지만, 플래너 단계는 해당 프롬프트를 10개의 스프린트에 걸쳐 16개 기능 사양으로 확장했습니다. 이는 단독 실행이 시도한 것을 훨씬 뛰어넘었습니다. 핵심 편집기 및 재생 모드 외에도 사양에는 스프라이트 애니메이션 시스템, 동작 템플릿, 음향 효과 및 음악, AI 지원 스프라이트 생성기 및 레벨 디자이너, 공유 가능한 링크를 통한 게임 내보내기가 포함되었습니다. 저는 플래너가 프런트엔드 디자인 스킬에 액세스하도록 하여, 이를 읽고 앱의 시각적 디자인 언어를 사양의 일부로 만드는 데 사용했습니다. 각 스프린트에 대해 생성자와 평가자는 스프린트의 특정 구현 세부 사항과 완료 확인을 위해 테스트할 테스트 가능한 동작을 정의하는 계약을 협상했습니다.

앱은 단독 실행보다 즉시 더 세련되고 매끄러워 보였습니다. 캔버스는 전체 뷰포트를 사용했고, 패널은 합리적으로 크기가 조정되었으며, 인터페이스는 사양의 디자인 방향을 따르는 일관된 시각적 정체성을 가졌습니다. 단독 실행에서 본 일부 거칠함은 남아 있었습니다. 워크플로가 여전히 스프라이트와 엔티티를 먼저 구축한 다음 레벨을 채우려고 시도해야 하는 이유를 명확하게 보여주지 않았고, 주변을 살펴보면서 이를 파악해야 했습니다. 이는 허들이 해결하도록 설계된 것이 아닌 기본 모델의 제품 직관의 격차로 해석되었지만, 허들 내에서 대상으로 지정된 반복을 통해 출력 품질을 추가로 개선할 수 있는 위치를 시사했습니다.

편집기를 살펴보면서, 새 실행이 단독 실행보다 더 많은 이점을 가졌음이 분명해졌습니다. 스프라이트 편집기는 더 깔끔한 도구 팔레트, 더 나은 색상 선택기 및 더 사용하기 쉬운 확대/축소 제어를 통해 더 풍부하고 완전한 기능을 갖추고 있었습니다.

플래너에게 사양에 AI 기능을 엮어 넣도록 요청했기 때문에 앱에는 프롬프팅을 통해 게임의 다양한 부분을 생성할 수 있는 내장된 Claude 통합 기능도 포함되었습니다. 이는 워크플로를 크게 가속화했습니다.

초기 화면: 전체 허들로 구축된 앱에서 새 게임 생성 중

가장 큰 차이점은 재생 모드였습니다. 실제로 내 엔티티를 이동하고 게임을 플레이할 수 있었습니다. 물리는 약간 거칠었습니다. 내 캐릭터가 플랫폼 위로 점프했지만 그 위에 겹쳐져 직관적으로 잘못된 느낌이 들었지만, 핵심 기능은 작동했으며 단독 실행은 이를 달성하지 못했습니다. 잠시 돌아다닌 후 AI의 게임 레벨 구성에 대한 몇 가지 한계를 발견했습니다. 점프할 수 없는 큰 벽이 있어서 갇혔습니다. 이는 허들이 앱을 추가로 개선하기 위해 처리할 수 있는 상식적인 개선 사항과 엣지 케이스가 있음을 시사했습니다.

로그를 읽어보면 평가자가 구현을 사양과 일치시켰다는 것이 분명했습니다. 각 스프린트마다 스프린트 계약의 테스트 기준을 검토하고 Playwright를 통해 실행 중인 애플리케이션을 실행하여 예상 동작에서 벗어난 모든 항목에 대해 버그를 기록했습니다. 계약은 세부적이었습니다. (스프린트 3만 해도 레벨 편집기를 다루는 27가지 기준이 있었습니다.) 평가자의 발견 사항은 추가 조사 없이도 조치할 수 있을 만큼 구체적이었습니다. 아래 표는 우리 평가자가 식별한 문제의 몇 가지 예를 보여줍니다.

계약 기준	평가자 발견 사항
사각형 채우기 도구는 클릭-드래그를 통해 선택한 타일로 직사각형 영역을 채울 수 있도록 함	실패 — 도구가 드래그 시작/종료 지점에만 타일을 배치하고 영역을 채우지 않습니다. fillRectangle 함수는 존재하지만 mouseUp에서 제대로 트리거되지 않습니다.
사용자는 배치된 엔티티 스폰 지점을 선택하고 삭제할 수 있음	실패 — LevelEditor.tsx:892의 삭제 키 처리기는 selection 및 selectedEntityId가 모두 설정되어 있어야 하지만 엔티티를 클릭하면 selectedEntityId만 설정됩니다. 조건은 selection || (selectedEntityId && activeLayer === 'entity')이어야 합니다.
사용자는 API를 통해 애니메이션 프레임을 재정렬할 수 있음	실패 — PUT /frames/reorder 경로는 /{frame_id} 경로 뒤에 정의되어 있습니다. FastAPI는 ‘r eorder ‘를 프레임_id 정수로 일치시키고 422: “문자열을 정수로 구문 분석할 수 없습니다”를 반환합니다.

평가자가 이 수준에서 수행하도록 하려면 노력이 필요했습니다. 기본적으로 Claude는 열악한 QA 에이전트입니다. 초기 실행에서 합법적인 문제를 식별한 다음, 그것들이 큰 문제가 아니라고 스스로 설득하고 작업을 승인하는 것을 보았습니다. 또한 엣지 케이스를 조사하기보다는 피상적으로 테스트하는 경향이 있어 더 미묘한 버그가 종종 지나갔습니다. 튜닝 루프는 평가자 로그를 읽고, 판단이 나와 다른 예를 찾아 해당 문제를 해결하기 위해 QA의 프롬프트를 업데이트하는 것이었습니다. 평가자가 내가 합리적이라고 생각하는 방식으로 채점할 때까지 이 개발 루프를 여러 번 거쳐야 했습니다. 그래도 허들 출력물은 모델의 QA 기능의 한계를 보여주었습니다. 작은 레이아웃 문제, 상호 작용이 때때로 직관적이지 않게 느껴지는 점, 평가자가 철저히 실행하지 않은 더 깊이 중첩된 기능의 발견되지 않은 버그가 있었습니다. 추가 튜닝으로 캡처할 검증 여지가 더 있다는 것은 분명했습니다. 그러나 애플리케이션의 핵심 기능이 작동하지 않았던 단독 실행과 비교했을 때 그 향상은 분명했습니다.

허들 반복

첫 번째 허들 결과 세트는 고무적이었지만, 또한 무겁고, 느리고, 비쌌습니다. 논리적인 다음 단계는 성능을 저하시키지 않으면서 허들을 단순화할 방법을 찾는 것이었습니다. 이는 상식적인 부분도 있었고, 더 일반적인 원칙의 일부이기도 했습니다. 허들의 각 구성 요소는 모델이 스스로 할 수 없는 것에 대한 가정을 인코딩하며, 이러한 가정은 틀릴 수 있고 모델이 개선됨에 따라 빠르게 쓸모없어질 수 있으므로 테스트해 볼 가치가 있습니다. 저희 블로그 게시물 효과적인 에이전트 구축은 근본적인 아이디어를 “가능한 가장 단순한 해결책을 찾고, 필요할 때만 복잡성을 증가시키십시오”로 구성하며, 이는 에이전트 허들을 유지 관리하는 모든 사람에게 일관되게 나타나는 패턴입니다.

단순화하려는 첫 번째 시도에서 저는 허들을 급격히 줄이고 몇 가지 창의적인 새로운 아이디어를 시도했지만 원래의 성능을 복제할 수는 없었습니다. 또한 허들 설계의 어떤 부분이 실제로 지지하고 있는지, 그리고 어떤 면에서 지지하고 있는지 파악하기 어려워졌습니다. 그 경험을 바탕으로, 저는 한 번에 한 구성 요소를 제거하고 최종 결과에 미치는 영향을 검토하는 보다 체계적인 접근 방식으로 전환했습니다.

이러한 반복 주기를 거치는 동안 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 에이전트는 여전히 실제 격차를 발견했습니다. 첫 번째 피드백에서 다음과 같이 언급했습니다.

이것은 훌륭한 디자인 충실도, 견고한 AI 에이전트 및 좋은 백엔드를 갖춘 강력한 앱입니다. 주요 실패 지점은 기능 완성도입니다. 앱은 인상적으로 보이고 AI 통합은 잘 작동하지만 몇 가지 핵심 DAW 기능은 대화형 깊이 없이 표시 전용입니다. 타임라인에서 클립을 드래그/이동할 수 없고, 악기 UI 패널(신디사이저 노브, 드럼 패드)이 없고, 시각 효과 편집기(EQ 곡선, 컴프레서 미터)가 없습니다. 이는 엣지 케이스가 아니라 DAW를 사용할 수 있게 만드는 핵심 상호 작용이며 사양에 명시되어 있습니다.

두 번째 피드백 라운드에서는 다음과 같은 몇 가지 기능적 격차를 다시 발견했습니다.

남은 격차:
- 오디오 녹음은 여전히 스텁 전용입니다(버튼이 토글되지만 마이크 캡처는 안 됨).
- 클립 가장자리 드래그로 인한 크기 조정 및 클립 분할이 구현되지 않음.
- 효과 시각화는 그래픽(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 복고풍 게임 메이커

개요
RetroForge는 2D 복고풍 스타일 비디오 게임을 설계하고 구축하기 위한 웹 기반 창작 스튜디오입니다. 클래식 8비트 및 16비트 게임 미학의 향수를 현대적이고 직관적인 편집 도구와 결합하여 취미 제작자부터 인디 개발자에 이르기까지 코드를 작성하지 않고도 게임 아이디어를 실현할 수 있도록 지원합니다.

이 플랫폼은 타일 기반 레벨 편집기, 픽셀 아트 스프라이트 편집기, 시각적 엔티티 동작 시스템, 즉각적인 재생 가능한 테스트 모드라는 네 가지 통합 창작 모듈을 제공합니다. Claude에서 제공하는 AI 지원을 전체적으로 엮어 RetroForge는 자연어 상호 작용을 통해 스프라이트 생성, 레벨 디자인 및 동작 구성을 지원하여 창작 프로세스를 가속화합니다.

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

기능
1. 프로젝트 대시보드 및 관리
프로젝트 대시보드는 RetroForge의 모든 창작 활동의 기반입니다. 사용자는 자신의 게임 프로젝트를 관리하는 명확하고 정리된 방식을 필요로 합니다. 새 프로젝트를 만들고, 작업 중인 프로젝트로 돌아가고, 각 프로젝트에 포함된 내용을 한눈에 파악해야 합니다.

사용자 스토리: 사용자는 다음을 원합니다.

- 이름과 설명을 사용하여 새 게임 프로젝트를 생성하여 게임 디자인을 시작할 수 있습니다.
- 모든 기존 프로젝트를 프로젝트 이름, 최종 수정 날짜 및 썸네일 미리보기를 보여주는 시각적 카드로 표시하여 신속하게 작업을 찾아 계속 진행할 수 있습니다.
- 모든 프로젝트를 열어 전체 게임 편집기 작업 공간으로 이동하여 게임 작업을 진행할 수 있습니다.
- 실수 방지를 위한 확인 대화 상자를 통해 더 이상 필요하지 않은 프로젝트를 삭제하여 작업 공간을 정리할 수 있습니다.
- 기존 프로젝트를 복제하여 새 게임의 시작점으로 사용하여 이전 작업을 재사용할 수 있습니다.

프로젝트 데이터 모델: 각 프로젝트에는 다음이 포함됩니다.

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

...