장시간 자율 코딩을 뒷받침하는 하니스(에이전트 구조) 설계

https://www.anthropic.com/engineering/harness-design-long-running-apps

수행 시간이 긴 애플리케이션 개발에서 하니스(harness) 설계는 최첨단 에이전틱 코딩의 성능을 좌우하는 핵심 요소입니다. 이 글에서는 우리가 Claude를 활용해 프론트엔드 디자인과 장시간 자율 소프트웨어 엔지니어링 성능을 어떻게 끌어올렸는지 설명합니다.

지난 몇 달 동안 저는 두 가지 서로 연결된 문제를 다뤄왔습니다. Claude로 어떻게 하면 수준 높은 프론트엔드 디자인을 만들 수 있을지, 그리고 사람의 개입 없이 완전한 애플리케이션을 스스로 구축하게 만들 수 있을지입니다. 이 작업은 초기의 프론트엔드 디자인 스킬과 장시간 코딩 에이전트 하니스 연구에서 출발했습니다. 당시에는 프롬프트 엔지니어링과 하니스 설계를 통해 Claude의 성능을 기본값 대비 크게 끌어올리는 데 성공했지만, 결국 두 실험 모두 한계점에 부딪혔습니다.

이 한계를 넘기 위해, 저는 성격이 상당히 다른 두 영역—주관적 취향이 크게 작용하는 디자인과, 정답이 명확하고 사용성을 검증할 수 있는 소프트웨어 개발—모두에 통할 수 있는 새로운 AI 엔지니어링 접근법을 찾고자 했습니다. GAN(Generative Adversarial Networks)에서 영감을 받아, generator 에이전트와 evaluator 에이전트로 구성된 멀티 에이전트 구조를 설계했습니다. 여기서 핵심은, “이 디자인이 좋은가?” 같은 주관적인 질문을 “이 디자인이 좋은 디자인을 평가하기 위한 기준을 얼마나 잘 충족하는가?”처럼 구체적이고 점수화 가능한 기준으로 바꿔, 미묘한 취향까지 반영하면서도 일관되게 평가할 수 있는 evaluator를 만드는 것이었습니다.

이후 저는 이런 기법들을 장시간 자율 코딩에도 적용했고, 이전 하니스 실험에서 얻은 두 가지 교훈—빌드를 처리 가능한 작은 단위로 쪼개는 것, 그리고 세션 사이의 컨텍스트를 전달하기 위한 구조화된 아티팩트를 사용하는 것—을 그대로 가져왔습니다. 최종적으로는 플래너(planner), 제너레이터(generator), 이밸류에이터(evaluator) 세 가지 에이전트로 구성된 아키텍처를 구성했고, 이를 통해 여러 시간에 걸친 자율 코딩 세션 동안 풍부한 풀스택 애플리케이션을 만들어낼 수 있었습니다.

단순한 구현만으로는 왜 금방 한계가 드러나는가

우리는 이미, 수행 시간이 긴 에이전틱 코딩에서 하니스 설계가 성능에 큰 영향을 미친다는 사실을 보여준 바 있습니다. 이전 실험에서는, 제품 스펙을 태스크 목록으로 분해하는 initializer 에이전트와, 태스크를 하나의 기능(feature) 단위로 구현하고 세션 간 컨텍스트를 전달하기 위해 아티팩트를 넘겨주는 코딩 에이전트를 사용했습니다. 넓게 보면 개발자 커뮤니티도 비슷한 통찰에 도달했습니다. 예를 들어 “Ralph Wiggum” 방식처럼 훅이나 스크립트를 사용해 에이전트를 계속 반복 실행 상태로 두는 접근이 대표적입니다.

하지만 여전히 풀리지 않는 문제가 남아 있었습니다. 작업이 복잡해질수록, 시간이 지날수록 에이전트가 점점 엉뚱한 방향으로 흐르는 경향이 있다는 점입니다. 이 문제를 쪼개 분석해 보니, 이런 종류의 태스크를 수행하는 에이전트에게서 공통적으로 나타나는 두 가지 실패 패턴이 있었습니다.

첫 번째는, 컨텍스트 윈도우가 가득 차기 시작하면 모델이 긴 작업에서 점점 일관성을 잃는다는 점입니다(자세한 내용은 context engineering 글을 참고하세요). 일부 모델은 “컨텍스트 불안(context anxiety)”이라고 부를 만한 행동을 보이기도 하는데, 자신이 허용된 컨텍스트 한도에 가까워졌다고 판단하면 작업을 마무리하려는 쪽으로 성급히 움직이는 경향이 나타납니다. 이 문제는 컨텍스트 리셋(context reset)—컨텍스트 윈도우를 완전히 비우고 새로운 에이전트를 띄운 뒤, 이전 에이전트의 상태와 다음 단계를 담은 구조화된 핸드오프(handoff)를 함께 넘겨주는 방식—으로 어느 정도 해결할 수 있습니다. 리셋을 통해 컨텍스트를 깨끗하게 비우면, 컨텍스트 불안도 같이 해소됩니다.

컨텍스트 리셋은 “컴팩션(compaction)”과는 다릅니다. 컴팩션은 대화의 앞부분을 요약해 그 자리에서 치환함으로써, 같은 에이전트가 짧아진 히스토리를 가지고 계속 작업을 이어가도록 하는 방식입니다. 컴팩션은 연속성은 유지해 주지만, 에이전트 입장에서는 여전히 “과거의 대화가 남아 있는” 상태이기 때문에 컨텍스트 불안이 완전히 사라지지 않을 수 있습니다. 반면 리셋은 에이전트에게 완전히 새 출발을 허용하지만, 그 대신 다음 에이전트가 작업을 끊김 없이 이어갈 수 있을 만큼 충분한 상태를 핸드오프 아티팩트에 담아야 하는 부담이 생깁니다. 이전 테스트에서 우리는 Claude Sonnet 4.5가 컨텍스트 불안을 상당히 강하게 보여, 컴팩션만으로는 긴 태스크에서 충분한 성능을 내기가 어려웠고, 그 결과 컨텍스트 리셋이 하니스 설계에서 필수 요소가 되었다는 사실을 확인했습니다. 이 방식은 핵심 문제를 해결해 주지만, 그만큼 오케스트레이션 복잡도와 토큰 사용량, 그리고 각 하니스 실행에 필요한 지연(latency)이 늘어난다는 대가가 있습니다.

두 번째 문제는, 지금까지 제대로 다루지 않았던 “자기 평가(self-evaluation)”입니다. 에이전트에게 자신이 만든 작업물을 평가하라고 하면, 실제로는 품질이 평범하거나 미흡해 보이는 경우에도 지나치게 자신만만하게 칭찬하는 경향이 있습니다. 특히 디자인처럼 소프트웨어 테스트처럼 명확한 이분법적 기준이 없는, 주관적 판단이 큰 비중을 차지하는 과제에서 이 문제가 두드러집니다. 레이아웃이 세련되게 느껴지는지, 아니면 어디서나 볼 수 있는 평범한 UI인지 같은 판단은 감각의 문제인데, 에이전트는 자신의 결과물에 점수를 매길 때 일관되게 후한 편으로 치우칩니다.

하지만 검증 가능한 정답이 있는 태스크에서도, 에이전트가 작업을 수행하는 동안 스스로의 결과를 잘못 판단해 성능을 떨어뜨리는 경우가 여전히 존재합니다. 이때 효과적인 해법은, 작업을 수행하는 에이전트와 그 결과를 평가하는 에이전트를 분리하는 것입니다. 이 둘을 분리한다고 해서 평가가 곧바로 엄격해지는 것은 아닙니다. evaluator 역시 LLM이기 때문에, LLM이 생성한 출력물에 관대해지려는 성향은 그대로 남아 있습니다. 다만 generator가 자기 작업을 가혹하게 비판하게 만드는 것보다, 독립된 evaluator를 “의심 많은 QA”로 튜닝하는 편이 훨씬 수월하다는 점이 중요합니다. 일단 외부에서 들어오는 피드백이 생기면, generator는 그 피드백을 기준 삼아 구체적으로 개선해 나갈 수 있기 때문입니다.

프론트엔드 디자인: 취향의 문제를 점수 매길 수 있는 문제로 바꾸기

우선 저는 자기 평가 문제가 가장 두드러져 보이던 프론트엔드 디자인에서 실험을 시작했습니다. 별도의 개입이 없으면, Claude는 보통 기능적으로는 문제 없지만 시각적으로는 평범한, 안전하고 예측 가능한 레이아웃을 만드는 쪽으로 기울었습니다.

제가 만든 프론트엔드 디자인 하니스에는 두 가지 핵심 통찰이 녹아 있습니다. 첫째, 미학적 완성도는 단 하나의 점수로 완전히 환원할 수 없고 사람마다 취향이 다르지만, 디자인 원칙과 선호를 점수 기준으로 encode하면 그 점수를 개선하는 방향으로 결과를 끌고 갈 수 있다는 점입니다. “이 디자인은 아름다운가?”라는 질문은 일관되게 답하기 어렵지만, “이 디자인이 우리가 정의한 좋은 디자인의 원칙을 얼마나 잘 따르고 있는가?”라는 질문은 Claude가 구체적으로 평가할 수 있습니다. 둘째, 프론트엔드 생성과 프론트엔드 평가를 분리하면, generator를 더 나은 결과로 이끄는 피드백 루프를 만들 수 있다는 점입니다.

이 관점을 바탕으로, 저는 generator와 evaluator 에이전트 모두에게 프롬프트로 전달할 네 가지 평가 기준을 작성했습니다.

• Design quality: 이 디자인이 그저 부품들을 나열한 집합이 아니라, 하나의 일관된 전체처럼 느껴지는가? 색상, 타이포그래피, 레이아웃, 이미지, 기타 요소들이 어우러져 독특한 분위기와 아이덴티티를 만들어 내는지 여부를 봅니다.
• Originality: 템플릿 레이아웃, 라이브러리 기본값, AI가 자주 만들어내는 패턴이 아니라, 의도적인 커스텀 결정의 흔적이 보이는가? 사람 디자이너라면 “고민한 흔적”이 보여야 합니다. 수정하지 않은 스톡 컴포넌트나, 보라색 그라디언트 위에 흰 카드 같은 전형적인 AI 생성 티가 나는 디자인은 감점 대상입니다.
• Craft: 타이포그래피 계층 구조, 간격의 일관성, 색 조화, 대비비 등 기술적인 완성도를 보는 항목입니다. 창의성보다는 기본기와 숙련도에 대한 체크에 가깝습니다. 대부분의 그럴듯한 구현이라면 기본적으로는 무난히 통과하지만, 이 항목에서 실패했다는 것은 기초가 무너져 있다는 뜻입니다.
• Functionality: 미적 요소와 별개로, 순수하게 사용성만을 평가합니다. 사용자가 인터페이스가 무엇을 하는지 이해하고, 주요 액션을 쉽게 찾고, 추측하지 않고도 태스크를 수행할 수 있는지를 봅니다.

저는 네 가지 중에서도 특히 design quality와 originality에 높은 가중치를 두었습니다. Claude는 기본 상태에서도 craft와 functionality 면에서는 비교적 좋은 점수를 받는 편이었습니다. 기술적인 기본기를 요구하는 영역은 모델에게 꽤 자연스럽게 따라왔기 때문입니다. 반면 디자인과 독창성 항목에서는, 결과물이 대체로 밋밋한 편이었습니다. 저는 이 기준이 템플릿 티가 나는 “AI 느낌”의 패턴에는 감점을 주고, 디자인과 독창성 항목의 비중을 더 높임으로써 모델이 심미적인 측면에서 더 과감한 시도를 하도록 유도했습니다.

evaluator의 판단이 제 취향에 맞게, 그리고 여러 번 반복해도 점수가 흔들리지 않도록 만들기 위해, 저는 few-shot 예시를 활용해 각 항목에 대한 세부 점수와 설명을 제공하며 캘리브레이션을 진행했습니다. 덕분에 evaluator의 평가 기준이 제 취향에 정렬되었고, 반복을 거듭해도 점수 기준이 조금씩 떠밀려 변해 버리는 현상을 줄일 수 있었습니다.

루프는 Claude Agent SDK를 기반으로 구현해, 오케스트레이션 자체는 비교적 단순하게 유지했습니다. 먼저 generator 에이전트가 사용자 프롬프트를 바탕으로 HTML/CSS/JS 프론트엔드를 생성합니다. evaluator 쪽에는 Playwright MCP를 붙여서, 실제로 구동 중인 페이지를 직접 조작하고 관찰한 뒤 각 평가 기준에 대한 점수와 상세한 평을 작성하도록 했습니다. 실제 실행에서는 evaluator가 스스로 페이지를 탐색하고, 스크린샷을 찍고, 구현을 꼼꼼히 살펴본 다음에야 평가를 내렸습니다. 이 피드백은 다음 반복(iteration)의 입력으로 generator에게 전달되었습니다. 저는 한 번의 생성에 대해 보통 5~15번 정도 반복을 돌렸고, 각 반복에서 generator는 evaluator의 평을 반영해 점점 더 개성 있는 방향으로 디자인을 발전시켜 나갔습니다. evaluator가 정적인 스크린샷만 보고 평가하는 게 아니라 실제 페이지를 탐색하면서 검토하다 보니, 각 사이클마다 실제 시간이 꽤 걸렸고 전체 실행은 최대 네 시간 정도까지 길어졌습니다. 또 각 평가가 끝난 뒤에는 generator가 전략적 선택을 하도록 했습니다. 점수가 잘 올라가고 있으면 같은 방향을 더 다듬고, 반대로 별로라면 아예 다른 미학적 방향으로 갈아타도록 한 것입니다.

실험을 거듭하면서, evaluator의 평가는 반복을 거듭할수록 개선되고, 어느 시점 이후에는 점차 상향 평준화된 상태에서 정체되는 패턴을 보였습니다. 다만 아직도 여유는 남아 있었습니다. 어떤 경우에는 구현이 반복될수록 조금씩 개선되었고, 어떤 경우에는 중간 단계에서 갑자기 큰 미적 전환이 일어나기도 했습니다.

평가 기준의 문구 자체도 generator를 생각보다 강하게 이끌었습니다. 예를 들어 “가장 뛰어난 디자인은 박물관에 전시될 수준이어야 한다(museum quality)” 같은 표현을 넣어두면, 디자인이 특정 시각적 방향으로 수렴하는 경향이 생겼습니다. 즉 이 기준에 사용된 문장들이 결과물의 캐릭터를 직접적으로 규정하고 있는 셈입니다.

점수는 전반적으로 반복을 거듭할수록 좋아지는 경향을 보였지만, 항상 깔끔하게 단조 증가하는 것은 아니었습니다. 마지막 결과가 전체적으로는 더 낫지만, 제가 주관적으로는 중간 정도의 반복을 더 선호하는 경우도 자주 있었습니다. 반복을 거듭할수록 구현 복잡도 또한 증가하는 경향이 있었고, evaluator의 피드백에 반응해 generator가 더 야심 찬 해결책을 시도하는 상황이 자주 보였습니다. 흥미롭게도, 아무런 추가 피드백이 없는 1회차 출력조차도 “아예 기준 없이 프롬프트만 던졌을 때”와 비교하면 눈에 띄게 개선된 모습이었습니다. 이는 평가 기준과 그에 딸린 서술형 문장 자체가, evaluator의 피드백을 받기 전에 이미 모델을 템플릿 같은 기본값에서 벗어나게 만드는 역할을 했다는 뜻입니다.

특히 기억에 남는 사례로, 저는 모델에게 네덜란드 미술관 웹사이트를 만들어 달라고 프롬프트를 줬습니다. 9번째 반복까지는 깔끔한 다크 테마의 랜딩 페이지가 나왔고, 전체적으로 잘 다듬어진 디자인이긴 했지만 예상 범위 안에 있었습니다. 그런데 10번째 반복에서, 모델은 이전 접근을 완전히 버리고 사이트를 공간적 경험(spatial experience)으로 재구성했습니다. CSS 퍼스펙티브를 활용해 체커보드 바닥과 함께 3D 공간처럼 보이는 방을 만들고, 벽면에는 자유롭게 배치된 작품들을 걸어두었으며, 스크롤이나 클릭 대신 갤러리 방 사이를 이동하는 문을 통해 내비게이션을 구성했습니다. 단일 패스 생성에서는 본 적이 없는 종류의 창의적인 도약이었습니다.

풀스택 개발까지 확장하기

이렇게 얻은 결과를 바탕으로, 저는 (GAN)¹에서 영감을 받은 이 패턴을 풀스택 개발에도 확장해 보았습니다. 생성-평가(generator-evaluator) 루프는 원래 소프트웨어 개발 라이프사이클과도 자연스럽게 맞아떨어집니다. 코드 리뷰와 QA가 디자인 실험에서의 evaluator와 같은 구조적 역할을 하기 때문입니다.

아키텍쳐

이전 장기 실행용 하니스에서는, initializer 에이전트, 한 번에 하나의 기능을 구현하는 코딩 에이전트, 그리고 세션 간 컨텍스트 리셋을 조합해, 여러 세션에 걸쳐 일관된 코딩을 수행하는 구조를 만든 바 있습니다. Sonnet 4.5는 앞서 언급한 “컨텍스트 불안”을 강하게 보여, 이 모델과 잘 맞는 하니스를 만들기 위해서는 컨텍스트 리셋이 필수였습니다. 새로운 하니스에서는 이 문제를 먼저 다시 살펴봤습니다. Opus 4.5는 모델 자체에서 이런 행동이 많이 개선되었기 때문에, 이번에는 컨텍스트 리셋을 완전히 제거할 수 있었습니다. 에이전트들은 전체 빌드 동안 하나의 연속된 세션으로 실행되었고, 컨텍스트 증가에 따른 관리는 Claude Agent SDK의 자동 컴팩션에 맡겼습니다.

이번 작업에서는 기존 하니스를 기반으로, 제가 이전 실행에서 관찰했던 구체적인 빈틈을 각각 메우는 세 개의 에이전트로 시스템을 재구성했습니다. 각 에이전트는 다음과 같은 페르소나를 갖습니다.

Planner: 이전 장기 실행용 하니스에서는 사용자가 상세한 스펙을 미리 제공해야 했습니다. 저는 이 단계를 자동화하고 싶었기 때문에, 1~4문장 정도의 간단한 프롬프트를 받아 전체 제품 스펙으로 확장하는 planner 에이전트를 만들었습니다. 이 플래너에게는 범위를 과감하게 넓게 잡되, 세부 구현보다는 제품 맥락과 고수준 기술 설계(high level technical design)에 집중하도록 지시했습니다. 이렇게 한 이유는, 플래너가 너무 이른 시점에 구현 수준의 세세한 기술 사항까지 박아 넣다가 틀리면, 그 오류가 이후 구현 전반에 도미노처럼 전파될 위험이 있었기 때문입니다. 처음부터 구현 경로를 촘촘히 박아 두기보다는, 어떤 결과물을 만들어야 하는지에 제약을 두고, 실제 구현 과정과 세부 결정은 에이전트가 일하면서 점차 찾아가도록 맡기는 편이 더 합리해 보였습니다. 또한 플래너에게 제품 스펙 곳곳에 AI 기능을 녹일 수 있는 기회를 적극적으로 찾아보라고 요청했습니다(예시는 글 맨 아래 Appendix에 있습니다).

Generator: 이전 하니스에서 사용했던 “한 번에 한 기능씩” 접근 방식은 범위 관리 측면에서 상당히 효과적이었습니다. 이번에도 비슷한 모델을 적용해, generator가 스프린트 단위로 일하도록 설계했습니다. 스펙에서 기능을 하나씩 가져와 한 스프린트에 하나씩 구현하도록 한 것입니다. 각 스프린트는 React, Vite, FastAPI, SQLite(나중에는 PostgreSQL로 교체) 스택을 사용해 앱을 구현했고, 스프린트가 끝날 때마다 generator는 QA에 넘기기 전에 먼저 스스로 결과물을 평가하도록 지시했습니다. 버전 관리를 위해 git도 사용했습니다.

Evaluator: 이전 하니스로 만든 애플리케이션은 겉으로 보기에는 인상적이었지만, 실제로 사용해 보면 여전히 버그가 꽤 있었습니다. 이를 잡아내기 위해, evaluator에는 Playwright MCP를 붙였습니다. evaluator는 실제 사용자처럼 실행 중인 애플리케이션을 클릭해 보며 UI 기능, API 엔드포인트, 데이터베이스 상태 등을 테스트했습니다. 이후 평가 기준을 프론트엔드 실험에서 사용한 것과 유사한 형태로 확장해, 이번에는 제품 깊이, 기능성, 시각 디자인, 코드 품질 네 가지 항목으로 구성했습니다. 각 기준에 대해 최소 합격선을 설정했고, 하나라도 기준에 못 미치면 그 스프린트는 실패로 간주하고, 무엇이 잘못됐는지 구체적인 피드백을 generator에게 전달했습니다.

각 스프린트 시작 전에는 generator와 evaluator가 스프린트 계약(sprint contract)을 협상했습니다. 어떤 코드를 작성하기에 앞서, 이번 스프린트에서 “완료(done)”의 의미가 무엇인지 먼저 합의하는 단계입니다. 제품 스펙은 의도적으로 상위 수준에서만 제약을 걸어 두었고, 사용자 스토리와 테스트 가능한 구현 사이의 간극을 메우기 위해 이 단계가 필요했습니다. generator는 이번 스프린트에서 무엇을 어떻게 구현하고, 어떤 방식으로 성공 여부를 검증할지를 제안했고, evaluator는 그 제안이 올바른 방향인지 검토했습니다. 둘은 합의가 될 때까지 몇 차례 왕복하며 내용을 다듬었습니다.

에이전트 간 커뮤니케이션은 파일을 매개로 이뤄졌습니다. 한 에이전트가 파일을 작성하면, 다른 에이전트가 그 파일을 읽고 같은 파일에 응답을 적거나 새로운 파일을 만들어 이전 에이전트가 다시 읽도록 했습니다. generator는 이렇게 합의된 계약을 기준으로 구현을 진행한 뒤, 작업 결과를 QA에 넘겼습니다. 이런 구조 덕분에, 구현은 스펙에 충실하지만 너무 이른 시점에 구현을 과하게 규정해 버리지는 않도록 균형을 맞출 수 있었습니다.

하니스 실행

첫 번째 버전의 하니스에서는 Claude Opus 4.5를 사용했고, 비교를 위해 동일한 사용자 프롬프트를 전체 하니스와 단일 에이전트 시스템에 각각 넣어 실행했습니다. 이 실험을 시작할 당시 Opus 4.5는 우리가 보유한 모델 중 가장 강력한 코딩 모델이었습니다.

저는 레트로 비디오 게임 제작툴을 만들기 위해 다음과 같은 프롬프트를 작성했습니다:

2D 레트로 스타일 게임을 만들 수 있는 툴을 만들어 주세요. 타일 기반 레벨 에디터, 픽셀 스프라이트 에디터, 엔티티 행동(로직) 설정 기능, 그리고 직접 플레이해 볼 수 있는 테스트 모드까지 갖춘 올인원 게임 제작 도구를 목표로 합니다.

아래 표에는 사용한 하니스 유형, 실행 시간, 총 비용을 정리했습니다.

하니스는 비용 면에서 20배 이상 비쌌지만, 결과물의 품질 차이는 눈에 띄게 컸습니다.

제가 기대한 인터페이스는, 하나의 레벨과 그 구성 요소(스프라이트, 엔티티, 타일 레이아웃)를 조합해서 만들고, “재생(play)”을 눌러 실제로 그 레벨을 플레이해 볼 수 있는 형태였습니다. 먼저 단일 에이전트 결과물을 열어봤을 때, 처음 화면에 나온 애플리케이션은 그런 기대에 부합하는 것처럼 보였습니다.

하지만 몇 번 클릭해 보니 문제들이 하나씩 드러나기 시작했습니다. 레이아웃은 공간을 비효율적으로 쓰고 있었고, 고정 높이 패널 때문에 뷰포트 대부분이 비어 있는 상태였습니다. 워크플로우도 경직돼 있었습니다. 레벨을 채우려 하면 먼저 스프라이트와 엔티티를 만들어야 했는데, UI 어딜 봐도 그런 순서를 안내해 주는 요소가 없었습니다. 더 큰 문제는, 게임이 실제로는 제대로 동작하지 않는다는 점이었습니다. 엔티티는 화면에 나타났지만, 아무 입력에도 반응하지 않았습니다. 코드를 자세히 들여다보니, 엔티티 정의와 게임 런타임 사이의 연결이 끊겨 있었고, UI 상으로는 어디가 잘못됐는지 드러나지 않았습니다.

초기 진입 화면
단일 에이전트로 만든 앱을 처음 실행했을 때 보이는 시작 화면입니다.

픽셀 스프라이트 편집기
단일 에이전트로 만든 스프라이트 에디터에서 스프라이트를 하나 만들어 보는 화면입니다.

게임 플레이
제가 만든 레벨을 실제로 플레이해 보려 했지만, 끝내 제대로 동작하지 않는 모습입니다.

단일 에이전트 실행 결과를 평가한 뒤, 저는 하니스 실행 결과를 살펴봤습니다. 하니스 실행은 동일한 한 줄 프롬프트에서 출발했지만, 플래너 단계에서 이 한 줄을 10개 스프린트에 걸친 16개 기능 스펙으로 확장했습니다. 솔로 실행이 시도한 범위를 훨씬 넘어서는 스펙이었습니다. 코어 에디터와 플레이 모드 외에도, 이 스펙에는 스프라이트 애니메이션 시스템, 행위 템플릿(behavior templates), 사운드 이펙트와 음악, AI 기반 스프라이트 생성기와 레벨 디자이너, 공유 가능한 링크를 통한 게임 내보내기 기능이 포함돼 있었습니다. 저는 플래너에게 프론트엔드 디자인 스킬에 접근할 수 있는 권한을 주었고, 플래너는 이를 읽은 뒤 앱을 위한 시각적 디자인 언어를 스펙의 일부로 정의했습니다. 각 스프린트마다 generator와 evaluator는 해당 스프린트의 구체 구현 사항과, 구현이 완료되었는지 확인할 수 있는 테스트 가능한 행동들을 정의하는 계약을 협상했습니다.

하니스가 만든 앱은 첫 인상부터 단일 에이전트 실행 결과보다 훨씬 다듬어져 있고 부드러웠습니다. 캔버스가 전체 뷰포트를 활용하고 있었고, 패널 크기도 적절했으며, 스펙에서 정의한 디자인 방향과 일관된 시각적 아이덴티티를 유지하고 있었습니다. 솔로 실행에서 느꼈던 미묘한 어색함이 일부 남아 있긴 했습니다. 예를 들어, 여전히 스프라이트와 엔티티를 먼저 만든 뒤에 레벨을 채워야 한다는 점을 워크플로우에서 명확히 드러내지 못해, 저는 이 부분을 직접 탐색하며 알아내야 했습니다. 이는 하니스 설계보다는 기본 모델의 제품 감각(product intuition)에서 비롯된 한계로 읽혔지만, 이 지점 또한 하니스 내에서 타겟팅된 반복을 통해 개선할 수 있는 여지가 있어 보였습니다.

에디터들을 차근차근 사용해 보면서, 하니스 실행의 장점이 더 분명해졌습니다. 스프라이트 에디터는 더 풍부한 기능을 제공했고, 툴 팔레트도 정돈돼 있었으며, 색상 선택기와 줌 컨트롤도 더 사용하기 좋았습니다.

플래너에게 스펙 전반에 AI 기능을 녹이라고 요청한 덕분에, 앱에는 Claude와의 통합 기능이 내장되어 있어, 프롬프트를 통해 게임의 다양한 요소를 생성할 수 있었습니다. 이는 전체 워크플로우를 크게 가속해 주었습니다.

초기 진입 화면
풀 하니스로 만든 앱에서, 새 게임을 생성할 때 처음 마주치는 시작 화면입니다.

픽셀 스프라이트 편집기
스프라이트 에디터가 훨씬 정돈돼 보이고, 실제로 쓰기도 한결 편했습니다.

게임 디자인 AI 기능
내장된 AI 기능을 써서 레벨을 자동으로 만들어 보고 있는 모습입니다.

게임 디자인 AI 기능
내장된 AI 기능을 활용해 레벨을 자동 생성해 보고 있는 모습입니다.

게임 플레이
제가 방금 AI로 생성한 게임을 실제로 플레이해 보고 있는 장면입니다.

가장 큰 차이는 플레이 모드에서 나타났습니다. 저는 실제로 엔티티를 움직이며 게임을 플레이할 수 있었습니다.

스프라이트 에디터는 도구 팔레트가 더 깔끔하게 정리되어 있었고, 색상 선택기와 줌 컨트롤도 훨씬 쓰기 좋았습니다.

또 제가 플래너에게 스펙 안에 AI 기능을 녹이라고 요청했던 덕분에, 이 앱에는 Claude 연동이 기본으로 포함되어 있어 프롬프트만으로 게임의 여러 요소를 생성할 수 있었습니다. 이 기능 덕분에 전체 워크플로우 속도가 크게 빨라졌습니다.

가장 큰 차이는 플레이 모드에서 나타났습니다. 이번에는 실제로 엔티티를 움직이며 게임을 플레이할 수 있었습니다. 물리 엔진에는 여전히 거친 부분이 있었는데, 캐릭터가 플랫폼 위로 점프하면 살짝 겹쳐 보이는 등 직관적이지 않은 행동이 눈에 띄었습니다. 그래도 단일 에이전트 실행에서는 아예 구현되지 않았던 핵심 기능이, 하니스 실행에서는 기대한 수준으로 동작하고 있었습니다. 조금 더 움직여 보니, AI가 만든 게임 레벨 구성에도 한계가 있다는 점이 보였습니다. 예를 들어, 점프로는 절대 넘을 수 없는 큰 벽이 있어서 더 이상 진행할 수 없는 구간이 생기곤 했습니다. 이런 점을 보면, 하니스 내부에서 이런 “상식적인 개선”과 엣지 케이스를 다루는 로직을 조금만 더 추가해도 앱을 한 단계 더 다듬을 수 있겠다는 생각이 들었습니다.

로그를 읽어 보면, evaluator가 구현을 스펙에 맞게 유지하는 데 중요한 역할을 했다는 점이 분명했습니다. 각 스프린트마다 evaluator는 스프린트 계약에 적힌 테스트 기준을 하나씩 따라가면서, Playwright를 통해 실제로 동작 중인 애플리케이션을 살펴보고, 기대한 동작과 조금이라도 다르면 버그로 기록했습니다. 스프린트 3만 해도 레벨 에디터와 관련된 기준이 27개나 있었고, evaluator가 남긴 피드백은 별도의 추가 조사가 필요 없을 만큼 구체적이었습니다. 아래 표는 evaluator가 실제로 찾아낸 문제들 일부를 요약한 것입니다.

이 정도 수준으로 evaluator를 동작하게 만들기까지는 꽤 많은 작업이 필요했습니다. 초기 상태의 Claude는 좋은 QA 에이전트라고 보기는 힘들었습니다. 초기 실행에서는, evaluator가 분명히 실제 문제를 발견해 놓고도, 마지막에는 “크게 중요하지는 않다”고 스스로 설득한 뒤 작업을 통과시켜 버리는 사례가 반복해서 보였습니다. 또 테스트를 할 때도 피상적으로만 클릭해 보고, 엣지 케이스를 깊이 파고들지는 않아, 조금만 복잡한 버그는 그대로 지나치는 경우가 많았습니다. 이를 고치기 위해, 저는 evaluator의 로그를 직접 읽으면서 제 판단과 다르게 움직인 부분을 찾아내고, 그때마다 QA용 프롬프트를 조금씩 수정하는 작업을 반복했습니다. 이런 튜닝 사이클을 여러 차례 반복한 끝에야 evaluator가 제가 보기에도 “합리적”이라고 느낄 수 있을 만한 기준으로 평가를 내리기 시작했습니다. 그럼에도 불구하고, 최종 결과물에는 여전히 모델 QA 능력의 한계가 드러났습니다. 미묘한 레이아웃 문제나 어딘가 직관적이지 않은 인터랙션, evaluator가 깊이 테스트하지 못해 놓친 버그들이 곳곳에 남아 있었습니다. 아직 더 엄격히 검증할 수 있는 여지가 충분히 있다는 뜻입니다. 하지만 단일 에이전트 실행에서 애플리케이션의 핵심 기능이 아예 동작하지 않았던 것과 비교하면, 하니스가 가져온 품질 향상은 분명했습니다.

하니스를 계속 다듬어 나가기

첫 번째 하니스 결과는 상당히 고무적이었지만, 동시에 무겁고 느리고 비쌌습니다. 다음 자연스러운 단계는, 성능을 유지하면서 하니스를 얼마나 단순하게 줄일 수 있는지 탐색하는 것이었습니다. 이는 한편으로는 상식적인 리팩터링이기도 했고, 한편으로는 좀 더 일반적인 원칙에서 나온 고민이기도 했습니다. 하니스의 모든 구성 요소는 “모델이 스스로는 잘 하지 못하는 무엇인가”에 대한 가정을 하나씩 코드로 고정한 것이고, 이런 가정들은 모델이 개선될수록 빠르게 낡아갈 수 있기 때문에 주기적으로 검증할 가치가 있습니다. 우리 블로그 글 Building Effective Agents에서는 이 아이디어를 “가능한 한 가장 단순한 해법을 찾고, 꼭 필요할 때만 복잡도를 추가하라”는 원칙으로 설명하고 있고, 실제로 에이전트 하니스를 유지하는 모든 사람에게서 반복적으로 등장하는 패턴이기도 합니다.

처음에는 하니스를 과감히 대폭 축소하고 몇 가지 실험적인 아이디어를 시도해 봤지만, 원래 하니스가 보여줬던 성능을 재현하는 데는 실패했습니다. 또 이렇게 여러 요소를 한 번에 바꿔 버리니, 어떤 구성 요소가 실제로 얼마나 “하중(load-bearing)”을 지탱하고 있는지, 그리고 어떤 방식으로 영향을 주는지 파악하기 어려워졌습니다. 이런 경험을 바탕으로, 저는 접근 방식을 보다 체계적으로 바꾸었습니다. 한 번에 하나의 구성 요소만 제거해 보고, 그 영향이 결과물에 어떻게 나타나는지 직접 확인하는 방식입니다.

이런 반복을 진행하던 시기에 맞춰, 마침 Opus 4.6도 출시되었습니다. 이는 하니스 복잡도를 줄이려는 동기를 더 강하게 만들어 주었습니다. 4.6은 4.5에 비해 훨씬 더 적은 스캐폴딩만으로도 같은 작업을 수행할 수 있을 것이라는 기대를 품게 만들었습니다. 실제로 출시 블로그에서도 이렇게 설명하고 있습니다. “Opus 4.6은 계획을 더 치밀하게 세우고, 에이전트형 작업을 더 오래 안정적으로 이어 가며, 큰 코드베이스에서도 훨씬 믿을 수 있게 동작합니다. 또 스스로 만든 실수를 잡아낼 수 있을 정도로 코드 리뷰와 디버깅 능력도 한층 강화되었습니다.” 또 긴 컨텍스트에서의 정보 검색 능력도 크게 개선되었습니다. 모두 하니스가 기존에 보완하던 영역과 겹치는 능력들입니다.

스프린트 구조를 걷어내기

먼저, 스프린트 구조 자체를 제거하는 것부터 시도했습니다. 스프린트는 작업을 모델이 다루기 쉬운 작은 덩어리로 쪼개, 일관성 있게 처리하도록 돕는 역할을 했습니다. 하지만 Opus 4.6의 개선 사항을 고려하면, 이제는 모델이 이런 분할 없이도 상당히 큰 작업 단위를 스스로 처리할 수 있을 것이라는 기대가 생겼습니다.

저는 플래너와 evaluator는 그대로 유지했습니다. 둘 다 여전히 분명한 가치를 제공하고 있었기 때문입니다. 플래너를 빼고 실행해 보면, generator는 처음 받은 프롬프트만을 기준으로 곧바로 구현을 시작해 버리고, 결과적으로 플래너가 만들어낸 스펙에 비해 훨씬 범위가 좁은 애플리케이션을 만들었습니다.

스프린트 구조를 제거하면서, evaluator의 역할도 스프린트별 평가에서 전체 실행이 끝난 뒤 한 번에 평가하는 방식으로 바꾸었습니다. 모델 자체가 훨씬 강력해졌기 때문에, evaluator가 특정 실행에서 얼마나 “필수적인지”는 태스크가 모델의 현재 능력에 비해 어느 정도 난이도에 위치하느냐에 따라 달라졌습니다. 4.5에서는 그 경계가 모델 바로 근처에 있었습니다. 우리가 실행하던 빌드들이 generator가 단독으로 처리하기에는 조금 버거운 난이도에 있었고, evaluator는 빌드 거의 전 영역에서 유의미한 문제를 잡아내고 있었습니다. 4.6에서는 모델 자체의 성능이 올라가면서, 이 경계가 바깥쪽으로 밀려났습니다. 예전에는 evaluator가 없으면 어긋났을 구현들도, 이제는 generator가 혼자서도 꽤 안정적으로 처리할 수 있게 된 것입니다. 이런 경우, evaluator는 비용만 늘리고 실질적인 가치는 크지 않은 오버헤드로 바뀌었습니다. 반대로, 여전히 모델의 능력 경계 근처에 있는 작업들에서는 evaluator가 여전히 의미 있는 개선 효과를 보여주었습니다.

실무적으로 보면, evaluator를 쓸지 말지는 “항상 예/아니오로 정해진 사실”이라기보다, “현재 모델이 혼자서 안정적으로 처리할 수 있는 범위 밖의 작업인가?”라는 질문에 대한 답에 따라 달라지는 선택지에 가깝습니다. 태스크가 그 범위 밖에 있다면 evaluator는 충분히 비용을 들일 가치가 있습니다.

구조를 단순화하는 것과 동시에, 저는 각 앱에 AI 기능을 넣는 방식을 개선하기 위한 프롬프트도 손봤습니다. 특히 generator가 앱 내부 기능을 도구(tool)로 노출하고, 그 도구들을 호출해 앱을 실제로 조작할 수 있는 “제대로 된 에이전트”를 구현하도록 유도하는 부분을 강화했습니다. 이는 꽤 많은 반복이 필요한 작업이었습니다. 관련 지식이 비교적 최신이어서, Claude의 학습 데이터에 충분히 넓고 깊게 포함되어 있지는 않았기 때문입니다. 하지만 프롬프트를 충분히 다듬고 예시를 보강해 가며 튜닝한 끝에, generator는 도구를 제대로 정의하고 연결하는 에이전트를 안정적으로 만드는 수준에 도달했습니다.

업데이트된 하니스를 적용했을 때 어떤 결과가 나왔는가

업데이트된 하니스를 본격적으로 시험해 보기 위해, 저는 이번에는 디지털 오디오 워크스테이션(DAW), 즉 음악을 작곡·녹음·믹싱할 수 있는 프로그램을 생성하도록 프롬프트를 작성했습니다.

Web Audio API를 활용해, 작곡·녹음·믹싱까지 가능한 풀 기능 DAW를 브라우저용으로 구현해 주세요.

이번 실행 역시 여전히 길고 비쌌습니다. 총 실행 시간은 약 4시간, 토큰 비용은 약 124달러였습니다.

대부분의 시간은 빌더 단계에서 소요되었고, 스프린트 분할 없이도 Opus 4.6이 두 시간 넘게 일관되게 작업을 이어 갔습니다.

이전과 마찬가지로, 플래너는 한 줄짜리 프롬프트를 받아 전체 스펙으로 확장했습니다. 로그를 보면, generator는 앱과 에이전트 구조를 잘 계획하고, 에이전트를 연결하고, QA에 넘기기 전에 스스로 테스트하는 과정을 비교적 안정적으로 수행했습니다.

그럼에도 불구하고, QA 에이전트는 여전히 중요한 빈틈들을 찾아냈습니다. 1차 라운드 피드백에서 evaluator는 이렇게 적었습니다.

이 앱은 디자인 완성도, 에이전트 구성, 백엔드 측면에서 매우 탄탄합니다. 하지만 기능 완성도(Feature Completeness)에 결정적인 문제가 있습니다. 앱은 보기에는 인상적이고 AI 통합도 잘 작동하지만, 핵심 DAW 기능 몇 가지가 “표시만 있고 실제로는 비어 있는 상태”입니다. 예를 들어, 타임라인에서 클립을 드래그하거나 이동할 수 없고, 악기 UI(신스 노브, 드럼 패드) 패널이 없으며, 이펙트 편집기(EQ 곡선, 컴프레서 미터)도 시각적으로 제공되지 않습니다. 이것들은 사소한 기능이 아니라, DAW의 사용성을 좌우하는 핵심 인터랙션이자, 스펙에서 명시적으로 요구한 기능들입니다.

2차 라운드에서도 evaluator는 몇 가지 기능상의 빈틈을 다시 짚었습니다.

남은 문제들:

• 오디오 녹음은 여전히 스텁만 있는 상태입니다(버튼은 토글되지만 실제 마이크 캡처는 없음).
• 타임라인에서 클립을 가장자리 드래그로 리사이즈하거나, 클립을 분할하는 기능이 구현되지 않음.
• 이펙트 시각화는 그래픽이 아니라 숫자 슬라이더만 제공됩니다(EQ 곡선 없음).

generator는 여전히, 혼자 둘 경우 세부 사항을 빠뜨리거나 기능을 스텁으로 남겨두는 경향이 있었고, QA는 이런 “마지막 10%”를 채우는 데 여전히 실제 가치를 더해 주었습니다.

프롬프트만 보고 기대했던 것은, 멜로디·하모니·드럼 패턴을 만들고, 이를 곡으로 배열한 뒤, 필요하면 통합된 에이전트의 도움을 받으며 작업할 수 있는 프로그램이었습니다. 실제 결과는 아래와 같은 모습이었습니다.

이 앱은 아직 전문적인 음악 제작 프로그램이라고 부르기에는 부족합니다. 에이전트의 작곡 실력도 분명히 더 다듬을 수 있을 것입니다. 그리고 Claude는 소리를 “들을” 수 없기 때문에, 음악적 취향과 관련된 부분에서는 QA 피드백 루프의 효과가 제한적일 수밖에 없습니다.

그럼에도 불구하고, 최종 앱에는 음악 제작 도구로서 갖춰야 할 핵심 구성 요소들이 모두 들어 있었습니다. 브라우저에서 돌아가는 편집 뷰(Arrangement view), 믹서, 트랜스포트(재생·정지·루프 등)까지 제대로 구현되어 있었습니다. 그 밖에도, 내장된 에이전트만으로 간단한 곡 조각을 하나 만드는 것도 가능했습니다. 에이전트는 템포와 곡의 조성(key)를 설정하고, 멜로디를 만들고, 드럼 트랙을 구성하고, 믹서 레벨을 조정하고, 리버브를 추가하는 작업까지 수행했습니다. 완성도 면에서는 갈 길이 멀지만, 곡을 구성하기 위한 기본 프리미티브들이 갖춰져 있고, 에이전트가 이 도구들을 연달아 호출해 하나의 단순한 프로덕션을 처음부터 끝까지 조립할 수 있는 상태까지는 나아간 셈입니다. 아직 완벽한 피치는 아니지만, 점점 더 맞춰 가는 중이라고 말할 수 있겠습니다.

앞으로의 방향

모델이 계속 발전할수록, 일반적으로는 더 긴 시간 동안, 더 복잡한 작업을 수행할 수 있게 될 것입니다. 어떤 경우에는, 이로 인해 모델을 둘러싼 스캐폴딩의 중요성이 점점 줄어들어, 개발자가 다음 세대 모델을 기다리는 것만으로도 특정 문제가 “저절로” 해결되는 상황이 생길 수도 있습니다. 반대로, 모델이 강력해질수록, 그 모델을 중심으로 더 복잡한 작업을 수행하는 하니스를 설계할 수 있는 여지도 커집니다. 즉, 베이스라인 모델이 할 수 있는 일을 넘어서는 작업 공간이 넓어지는 것입니다.

이런 관점에서 볼 때, 이번 작업에서 얻은 몇 가지 교훈은 앞으로도 유효할 것 같습니다. 우선, 어떤 모델을 대상으로 하니스를 설계하든, 그 모델을 직접 실험해 보고, 실제 문제에 적용한 실행 로그를 읽어 보면서, 원하는 결과를 얻기 위해 모델이 어떤 방식으로 튜닝돼야 하는지 파악하는 과정은 항상 중요합니다. 더 복잡한 태스크를 다루는 경우에는, 작업을 적절히 분해한 뒤, 문제의 각 측면에 특화된 에이전트를 붙여줌으로써 성능을 끌어올릴 수 있는 여지가 종종 존재합니다. 또 새로운 모델이 출시되면, 기존 하니스를 다시 들여다보며 더 이상 성능에 결정적으로 기여하지 않는 구성 요소를 걷어내고, 이전에는 불가능했던 더 큰 능력을 실현하기 위해 새로운 구성 요소를 추가하는 것도 좋은 습관입니다.

이번 작업을 통해 제가 갖게 된 확신은 이것입니다. 모델이 좋아질수록 “흥미로운 하니스 조합”의 공간이 줄어드는 것이 아니라, 단지 그 위치가 옮겨갈 뿐이라는 점입니다. AI 엔지니어에게 중요한 일은, 이 이동하는 공간 안에서 계속해서 새로운 조합을 찾아내는 일입니다.

Appendix

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

RetroForge - 2D 레트로 게임 메이커

Overview
RetroForge는 2D 레트로 스타일 비디오 게임을 디자인하고 제작하기 위한 웹 기반 크리에이티브 스튜디오입니다. 이 도구는 고전 8비트·16비트 게임 미학의 향수를 현대적이고 직관적인 편집 도구와 결합하여, 취미 창작자부터 인디 개발자에 이르기까지 누구나 전통적인 코드를 작성하지 않고도 자신의 게임 아이디어를 현실로 옮길 수 있게 해 줍니다.

이 플랫폼은 네 가지 통합 크리에이티브 모듈을 제공합니다. 게임 월드를 설계하는 타일 기반 레벨 에디터, 시각 자산을 제작하는 픽셀 아트 스프라이트 에디터, 게임 로직을 정의하는 시각적 엔티티 행동 시스템, 그리고 실시간 게임플레이 테스트를 위한 즉시 실행 가능한 플레이어블 테스트 모드입니다. 전체에 걸쳐 AI 지원(Claude 기반)을 얽어 넣음으로써, RetroForge는 창작 과정을 가속화하여 사용자가 자연어 상호작용을 통해 스프라이트를 생성하고, 레벨을 디자인하고, 행동을 설정할 수 있게 도와줍니다.

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

Features

1. Project Dashboard & Management
Project Dashboard는 RetroForge에서 이루어지는 모든 크리에이티브 작업의 홈 베이스입니다. 사용자는 자신의 게임 프로젝트를 관리하기 위해 — 새 프로젝트를 만들고, 진행 중인 작업으로 돌아가며, 각 프로젝트에 무엇이 들어 있는지 한눈에 파악하기 위한 — 명확하고 잘 정리된 방식이 필요합니다.

User Stories: 사용자 입장에서, 나는 다음을 하고 싶다:
- 새 게임 프로젝트를 이름과 설명과 함께 만들어, 게임 디자인을 시작할 수 있도록 하고 싶다.
- 내 모든 기존 프로젝트가 프로젝트 이름, 마지막 수정 날짜, 썸네일 미리보기를 보여 주는 시각적 카드 형태로 표시되어, 내가 빠르게 찾아서 작업을 이어갈 수 있기를 원한다.
- 어떤 프로젝트든 열어서 전체 게임 에디터 작업 공간으로 들어가, 내 게임을 작업할 수 있기를 원한다.
- 더 이상 필요 없는 프로젝트는, 실수 방지를 위한 확인 대화 상자와 함께 삭제하여, 내 작업 공간을 정돈된 상태로 유지하고 싶다.
- 기존 프로젝트를 새 게임의 출발점으로 삼을 수 있도록, 프로젝트를 복제해 이전 작업을 재사용하고 싶다.

Project Data Model: 각 프로젝트는 다음을 포함한다:
- 프로젝트 메타데이터(이름, 설명, 생성/수정 타임스탬프)
- 캔버스 설정(예: 해상도 256x224, 320x240, 또는 160x144)
- 타일 크기 설정(8x8, 16x16, 또는 32x32 픽셀)
- 색상 팔레트 선택
- 연관된 모든 스프라이트, 타일셋, 레벨, 엔티티 정의

…