이 문서는 앤트로픽(Anthropic) 연구팀이 클로드(Claude) AI를 활용하여 장기 실행 애플리케이션을 개발하는 과정에서 겪었던 문제점과 이를 해결하기 위해 고안한 하네스(harness) 설계 방식에 대해 자세히 설명하고 있어요. 🧠 특히, 생성자(generator)와 평가자(evaluator) 에이전트의 다중 에이전트 구조를 통해 주관적인 품질 평가와 자율 코딩이라는 두 가지 어려운 문제를 어떻게 극복했는지 보여준답니다. 기존 방식의 한계를 넘어, 계획자(planner), 생성자, 평가자로 구성된 3단계 에이전트 아키텍처를 통해 더욱 풍부하고 완전한 기능을 갖춘 애플리케이션을 개발할 수 있었다는 점이 핵심이에요. 이 글을 통해 AI 에이전트의 성능을 최적화하고 복잡한 개발 작업을 효율적으로 수행하는 데 필요한 인사이트를 얻을 수 있을 거예요. ✨

1. 서론: AI 에이전트 개발의 도전과 새로운 접근 방식

앤트로픽의 연구원 프릿비 라자세카란은 지난 몇 달간 클로드를 이용해 고품질의 프론트엔드 디자인을 생성하고, 사람의 개입 없이 완전한 애플리케이션을 구축하는 두 가지 상호 연결된 문제에 몰두했어요. 초기에는 프롬프트 엔지니어링과 하네스 설계를 통해 클로드의 성능을 크게 향상시켰지만, 곧 한계에 부딪혔죠. 🚧

이러한 한계를 극복하기 위해 라자세카란은 새로운 AI 엔지니어링 접근 방식을 모색했어요. 그는 Generative Adversarial Networks (GANs)에서 영감을 받아 생성자(generator)와 평가자(evaluator) 에이전트로 구성된 다중 에이전트 구조를 설계했어요. 특히, "이 디자인이 좋은가?"와 같은 주관적인 판단을 구체적으로 평가 가능한 기준으로 바꾸는 것이 중요했는데, 이를 통해 평가자가 출력물을 신뢰성 있게 평가할 수 있도록 만들었답니다.

이 기술들은 장기 실행 자율 코딩에도 적용되었어요. 이전 하네스 작업에서 얻은 두 가지 교훈, 즉 작업을 관리 가능한 덩어리로 분해하고, 세션 간에 컨텍스트를 전달하기 위해 구조화된 아티팩트를 사용하는 방법을 활용했죠. 그 결과, 계획자(planner), 생성자, 평가자로 구성된 3단계 에이전트 아키텍처가 탄생했고, 이 아키텍처는 몇 시간 동안의 자율 코딩 세션을 통해 풍부한 풀 스택 애플리케이션을 생성할 수 있었어요. 🚀

2. 순진한 구현이 실패하는 이유

우리는 이전 연구에서 하네스 설계가 장기 실행 에이전트 코딩의 효율성에 상당한 영향을 미친다는 것을 보여줬어요. 초기 실험에서는 초기화 에이전트(initializer agent)를 사용하여 제품 사양을 작업 목록으로 분해하고, 코딩 에이전트(coding agent)가 각 기능을 구현한 다음, 아티팩트를 통해 세션 간 컨텍스트를 전달하도록 했죠. 하지만 몇 가지 문제가 여전히 남아 있었어요. 😥

더 복잡한 작업을 수행할 때 에이전트는 시간이 지남에 따라 엉뚱한 방향으로 나아가는 경향이 있었어요. 이 문제를 분해하는 과정에서 우리는 에이전트가 이러한 종류의 작업을 실행할 때 두 가지 일반적인 실패 모드를 관찰했어요.

첫째, 모델은 컨텍스트 창이 채워질수록 긴 작업에서 일관성을 잃는 경향이 있어요. 일부 모델은 "컨텍스트 불안(context anxiety)"을 보이기도 하는데, 이는 컨텍스트 한계에 가까워지면 작업을 조기에 마무리하려는 경향을 의미해요. 컨텍스트 리셋(context reset)은 컨텍스트 창을 완전히 지우고 새로운 에이전트를 시작하며, 이전 에이전트의 상태와 다음 단계를 전달하는 구조화된 핸드오프를 통해 이 두 가지 문제를 모두 해결할 수 있어요.

이것은 대화의 이전 부분을 요약하여 동일한 에이전트가 단축된 기록으로 계속 진행할 수 있도록 하는 압축(compaction)과는 달라요. 압축은 연속성을 유지하지만 에이전트에게 깨끗한 출발점을 제공하지 않아 컨텍스트 불안이 지속될 수 있죠. 리셋은 깔끔한 출발점을 제공하지만, 다음 에이전트가 작업을 깔끔하게 이어받을 수 있도록 핸드오프 아티팩트에 충분한 상태가 있어야 한다는 단점이 있어요. 초기 테스트에서 Claude Sonnet 4.5는 컨텍스트 불안을 강하게 보였기 때문에 압축만으로는 장기 작업 성능을 충분히 활성화할 수 없었답니다. 그래서 컨텍스트 리셋은 하네스 설계에 필수적인 요소가 되었어요. 이 방법은 핵심 문제를 해결하지만, 오케스트레이션 복잡성, 토큰 오버헤드, 그리고 각 하네스 실행에 대한 지연 시간을 추가해요. 😩

둘째, 이전에 다루지 않았던 문제인데, 바로 자기 평가(self-evaluation)예요. 에이전트가 자신이 만든 작업을 평가하도록 요청받으면, 인간 관찰자에게는 분명히 평범한 품질일지라도 자신감 있게 작업을 칭찬하는 경향이 있어요. 이 문제는 디자인과 같이 주관적인 작업에서 특히 두드러지는데, 검증 가능한 소프트웨어 테스트와 같은 이진 검사가 없기 때문이죠. 레이아웃이 세련되게 느껴지는지 아니면 평범하게 느껴지는지는 판단의 문제이며, 에이전트는 자신의 작업을 평가할 때 긍정적으로 치우치는 경향을 보여요.

하지만 검증 가능한 결과가 있는 작업에서도 에이전트는 때때로 작업 수행을 방해하는 부정확한 판단을 보여요. 작업을 수행하는 에이전트와 작업을 평가하는 에이전트를 분리하는 것이 이 문제를 해결하는 강력한 방법임이 입증되었어요. 이러한 분리가 즉시 이러한 관대함을 제거하지는 않지만, 독립적인 평가자를 비판적으로 튜닝하는 것이 생성자가 자신의 작업을 비판적으로 만들도록 하는 것보다 훨씬 더 현실적인 방법이에요. 그리고 일단 외부 피드백이 존재하면, 생성자는 이를 기반으로 구체적으로 반복할 수 있게 되는 거죠. 👍

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

가장 먼저 자기 평가 문제가 두드러졌던 프론트엔드 디자인 분야에서 실험을 시작했어요. 아무런 개입이 없으면 클로드는 기술적으로는 기능적이지만 시각적으로는 평범한, 안전하고 예측 가능한 레이아웃으로 향하는 경향이 있었어요. 🎨

프론트엔드 디자인을 위해 구축한 하네스에는 두 가지 통찰력이 반영되었어요. 첫째, 미학은 점수로 완전히 환원될 수 없으며 개인의 취향은 항상 다를 수 있지만, 디자인 원칙과 선호도를 코드화하는 평가 기준을 통해 개선될 수 있다는 점이에요. "이 디자인이 아름다운가?"는 일관성 있게 답하기 어렵지만, "이것이 좋은 디자인에 대한 우리의 원칙을 따르는가?"는 클로드에게 평가할 구체적인 기준을 제공해요. 둘째, 프론트엔드 생성과 프론트엔드 평가를 분리함으로써, 생성자가 더 강력한 결과물을 향해 나아가도록 하는 피드백 루프를 만들 수 있다는 점이에요.

이러한 점을 염두에 두고, 생성자와 평가자 에이전트 모두에게 프롬프트로 다음 네 가지 평가 기준을 제공했어요.

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

저는 기술력과 기능성보다 디자인 품질과 독창성을 강조했어요. 클로드는 기술력과 기능성에서 기본적으로 좋은 점수를 받았는데, 필요한 기술적 역량이 모델에 자연스럽게 내재되어 있었기 때문이에요. 하지만 디자인과 독창성에서는 클로드가 종종 기껏해야 평범한 결과물을 만들어냈어요. 이 기준들은 매우 일반적인 "AI 슬롭" 패턴을 명시적으로 불이익을 주었고, 디자인과 독창성에 더 큰 비중을 둠으로써 모델이 더 미학적인 위험을 감수하도록 유도했어요. 📈

자세한 점수 분석이 포함된 몇 가지 예시(few-shot examples)를 사용하여 평가자를 보정했어요. 이를 통해 평가자의 판단이 제 선호도와 일치하고, 반복 과정에서 점수 편차가 줄어들도록 했죠.

저는 Claude Agent SDK를 기반으로 이 루프를 구축하여 오케스트레이션을 간소화했어요. 생성자 에이전트는 사용자 프롬프트를 기반으로 HTML/CSS/JS 프론트엔드를 먼저 만들었어요. 평가자에게는 Playwright MCP를 제공하여 실제 페이지와 직접 상호 작용할 수 있도록 했고, 각 기준을 평가하고 상세한 비평을 작성하게 했어요. 실제로 평가자는 페이지를 자체적으로 탐색하고, 스크린샷을 찍고, 구현을 신중하게 연구한 다음 평가를 작성했어요. 그 피드백은 다음 반복을 위한 입력으로 생성자에게 전달되었죠.

각 생성당 5~15번의 반복을 실행했는데, 각 반복은 평가자의 비평에 반응하면서 생성자를 더욱 독특한 방향으로 이끌었어요. 평가자가 정적인 스크린샷을 평가하는 대신 페이지를 적극적으로 탐색했기 때문에 각 주기는 실제 시간이 소요되었고, 전체 실행은 최대 4시간까지 걸렸어요. 또한, 생성자에게 각 평가 후에 전략적인 결정을 내리도록 지시했어요. 점수가 좋으면 현재 방향을 개선하고, 접근 방식이 제대로 작동하지 않으면 완전히 다른 미학으로 전환하도록 말이죠. 🔄

실행 과정에서 평가자의 평가는 반복을 거치며 향상되었지만, 여전히 개선의 여지가 남아 있었어요. 어떤 생성은 점진적으로 개선되었고, 어떤 생성은 반복 사이에 급격한 미학적 변화를 보였어요.

평가 기준의 문구는 제가 완전히 예상하지 못했던 방식으로 생성자를 이끌었어요. "최고의 디자인은 박물관 수준이다"와 같은 문구가 포함되면서 디자인이 특정 시각적 수렴으로 나아가도록 유도되었고, 이는 기준과 관련된 프롬프트가 출력물의 특성을 직접적으로 형성했음을 시사해요.

점수가 반복을 거치면서 일반적으로 향상되었지만, 패턴이 항상 깨끗하게 선형적이지는 않았어요. 나중 구현이 전체적으로 더 나은 경향이 있었지만, 마지막 반복보다 중간 반복이 더 좋았던 경우도 자주 보였어요. 구현 복잡성 또한 라운드를 거치면서 증가하는 경향이 있었는데, 생성자가 평가자의 피드백에 반응하여 더 야심 찬 해결책을 찾았기 때문이에요. 첫 번째 반복에서도 출력물은 아무런 프롬프트가 없을 때보다 눈에 띄게 더 좋았는데, 이는 평가자 피드백이 추가적인 개선을 가져오기 전에 기준과 관련 언어가 모델을 일반적인 기본값에서 벗어나도록 유도했음을 시사해요. ✨

4. 풀 스택 코딩으로 확장: GAN에서 영감을 받은 패턴

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

4.1. 아키텍처 설계

이전의 장기 실행 하네스에서는 초기화 에이전트, 한 번에 하나의 기능씩 작업하는 코딩 에이전트, 그리고 세션 간 컨텍스트 리셋을 통해 다중 세션 코딩의 일관성을 해결했어요. 컨텍스트 리셋은 핵심적인 발전이었는데, 하네스는 앞서 언급된 "컨텍스트 불안" 경향을 보이던 Sonnet 4.5를 사용했기 때문이에요. 컨텍스트 리셋을 통해 잘 작동하는 하네스를 만드는 것이 모델이 작업을 계속 수행하도록 하는 데 중요했죠. Opus 4.5는 자체적으로 그러한 행동을 대부분 제거했기 때문에, 저는 이 하네스에서 컨텍스트 리셋을 완전히 제거할 수 있었어요. 에이전트들은 전체 빌드에 걸쳐 하나의 연속적인 세션으로 실행되었고, Claude Agent SDK의 자동 압축 기능이 그 과정에서 컨텍스트 증가를 처리했어요.

이 작업에서는 원래 하네스의 기반 위에 3단계 에이전트 시스템을 구축했으며, 각 에이전트는 이전 실행에서 관찰했던 특정 격차를 해결하도록 설계되었어요. 이 시스템은 다음과 같은 에이전트 페르소나로 구성되었답니다.

• 계획자 (Planner): 이전 장기 실행 하네스는 사용자에게 상세한 사양을 미리 제공하도록 요구했어요. 이 단계를 자동화하고 싶어서, 간단한 1~4문장 프롬프트를 받아서 완전한 제품 사양으로 확장하는 계획자 에이전트를 만들었어요. 계획자에게는 범위에 대해 야심 차게 접근하고, 상세한 기술 구현보다는 제품 컨텍스트와 높은 수준의 기술 설계에 집중하도록 지시했어요. 이러한 강조는 계획자가 미리 세분화된 기술적 세부 사항을 지정하려고 시도하다가 잘못될 경우, 사양의 오류가 하위 구현으로 이어질 수 있다는 우려 때문이었어요. 에이전트들에게 생산될 결과물에 대한 제약을 두고, 그들이 작업하면서 경로를 스스로 찾도록 하는 것이 더 현명하다고 생각했어요. 또한, 계획자에게 제품 사양에 AI 기능을 통합할 기회를 찾도록 요청했어요.
• 생성자 (Generator): 이전 하네스에서 사용된 "한 번에 하나의 기능" 접근 방식은 범위 관리에는 잘 작동했어요. 여기에도 유사한 모델을 적용하여, 생성자에게 스프린트 방식으로 작업하도록 지시하고, 사양에서 한 번에 하나의 기능을 선택하도록 했어요. 각 스프린트는 React, Vite, FastAPI, SQLite (나중에 PostgreSQL) 스택으로 앱을 구현했고, 생성자는 각 스프린트가 끝날 때 자신의 작업을 자체 평가한 후 QA에 인계하도록 지시받았어요. 또한, 버전 관리를 위해 Git도 사용했어요.
• 평가자 (Evaluator): 이전 하네스에서 만들어진 애플리케이션들은 인상적으로 보였지만, 실제로 사용하려고 하면 여전히 실제 버그가 있었어요. 이러한 버그를 잡기 위해, 평가자는 Playwright MCP를 사용하여 사용자가 할 것처럼 실행 중인 애플리케이션을 클릭하며 UI 기능, API 엔드포인트 및 데이터베이스 상태를 테스트했어요. 그런 다음, 발견된 버그와 프론트엔드 실험을 기반으로 모델링된 기준 세트에 따라 각 스프린트를 평가했으며, 이 기준은 제품 깊이, 기능성, 시각적 디자인, 코드 품질을 포함하도록 조정되었어요. 각 기준에는 엄격한 임계값이 있었고, 하나라도 이 임계값 아래로 떨어지면 스프린트는 실패하고 생성자는 무엇이 잘못되었는지에 대한 상세한 피드백을 받았답니다.

각 스프린트 전에, 생성자와 평가자는 스프린트 계약(sprint contract)을 협상했어요. 코드를 작성하기 전에 해당 작업의 "완료"가 어떤 모습일지에 대해 합의하는 것이었죠. 이것은 제품 사양이 의도적으로 높은 수준이었기 때문에 존재했으며, 사용자 스토리와 테스트 가능한 구현 사이의 간극을 메우는 단계가 필요했기 때문이에요. 생성자는 무엇을 구축할지, 그리고 성공 여부를 어떻게 확인할지 제안했고, 평가자는 생성자가 올바른 것을 구축하고 있는지 확인하기 위해 그 제안을 검토했어요. 두 에이전트는 합의에 도달할 때까지 반복했어요. 🤝

통신은 파일 기반으로 처리되었어요. 한 에이전트가 파일을 작성하면, 다른 에이전트가 그 파일을 읽고 그 파일 안에서 응답하거나 이전 에이전트가 차례로 읽을 새 파일을 작성하는 방식이었죠. 그런 다음 생성자는 합의된 계약에 따라 빌드를 수행한 후 QA에 작업을 인계했어요. 이는 구현을 너무 일찍 구체화하지 않고도 사양에 충실하게 작업을 유지할 수 있도록 해주었답니다.

4.2. 하네스 실행 및 결과

이 하네스의 첫 번째 버전에서는 Claude Opus 4.5를 사용하여 전체 하네스와 비교를 위한 단일 에이전트 시스템 모두에 사용자 프롬프트를 실행했어요. 이 실험을 시작할 때 Opus 4.5가 우리의 최고의 코딩 모델이었기 때문이죠.

레트로 비디오 게임 메이커를 생성하기 위해 다음과 같은 프롬프트를 작성했어요.

레벨 에디터, 스프라이트 에디터, 엔티티 동작, 플레이 가능한 테스트 모드 등의 기능을 포함하는 2D 레트로 게임 메이커를 만들어줘.

아래 표는 하네스 유형, 실행 시간, 그리고 총 비용을 보여줘요.

하네스는 비용이 20배 이상 더 들었지만, 출력 품질의 차이는 즉시 분명했어요.

저는 레벨과 그 구성 요소(스프라이트, 엔티티, 타일 레이아웃)를 구성한 다음 "플레이"를 눌러 실제로 레벨을 플레이할 수 있는 인터페이스를 기대했어요. 단독 실행의 출력물을 열어보니, 초기 애플리케이션은 이러한 기대에 부합하는 것처럼 보였어요.

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

단독 실행을 평가한 후, 하네스 실행에 집중했어요. 이 실행은 동일한 한 문장 프롬프트에서 시작했지만, 계획 단계에서 해당 프롬프트를 10개의 스프린트에 걸쳐 16가지 기능을 포함하는 사양으로 확장했어요. 이는 단독 실행이 시도했던 것보다 훨씬 더 많은 내용을 담고 있었죠. 핵심 에디터와 플레이 모드 외에도, 사양에는 스프라이트 애니메이션 시스템, 동작 템플릿, 음향 효과 및 음악, AI 지원 스프라이트 생성기 및 레벨 디자이너, 그리고 공유 가능한 링크가 있는 게임 내보내기 기능이 포함되었어요. 저는 계획자에게 우리의 프론트엔드 디자인 스킬에 접근하도록 허용했고, 계획자는 이를 읽고 사양의 일부로 앱을 위한 시각적 디자인 언어를 만들었어요. 각 스프린트마다 생성자와 평가자는 스프린트의 특정 구현 세부 사항과 완료를 확인하기 위해 테스트될 테스트 가능 동작을 정의하는 계약을 협상했어요.

앱은 단독 실행보다 즉시 더 세련되고 부드러운 모습을 보였어요. 캔버스는 전체 뷰포트를 사용했고, 패널은 합리적인 크기였으며, 인터페이스는 사양의 디자인 방향을 따르는 일관된 시각적 아이덴티티를 가지고 있었죠. 단독 실행에서 보았던 약간의 어색함은 여전히 남아 있었는데, 워크플로우가 레벨을 채우기 전에 스프라이트와 엔티티를 만들어야 한다는 것을 명확히 보여주지 않았고, 저는 직접 이것저것 해보면서 알아내야 했어요. 이는 기본 모델의 제품 직관력에 대한 격차로 읽혔지만, 하네스가 해결하도록 설계된 것은 아니었답니다. 하지만 하네스 내부에서 목표화된 반복을 통해 출력 품질을 더욱 향상시킬 수 있는 여지를 시사했어요.

에디터를 통해 작업을 진행하면서, 새 실행이 단독 실행에 비해 가진 장점이 더욱 분명해졌어요. 스프라이트 에디터는 더 풍부하고 완전한 기능을 갖추고 있었으며, 더 깔끔한 도구 팔레트, 더 나은 색상 선택기, 그리고 더 사용하기 쉬운 확대/축소 컨트롤을 제공했죠. 🤩

계획자에게 AI 기능을 사양에 통합하도록 요청했기 때문에, 앱에는 프롬프트를 통해 게임의 다양한 부분을 생성할 수 있는 내장된 클로드 통합 기능도 함께 제공되었어요. 이는 워크플로우를 크게 가속화했답니다.

가장 큰 차이는 플레이 모드에서 나타났어요. 저는 실제로 엔티티를 움직이고 게임을 플레이할 수 있었어요. 물리에는 약간의 거친 부분이 있었지만(캐릭터가 플랫폼 위로 점프했지만 플랫폼과 겹쳐져 직관적으로 잘못된 느낌을 주었어요), 핵심 기능은 작동했고, 이는 단독 실행에서는 불가능했던 부분이죠. 조금 움직이다 보니 AI의 게임 레벨 구성에 몇 가지 한계가 있다는 것을 알게 되었어요. 뛰어넘을 수 없는 큰 벽이 있어서 갇히게 되었죠. 이는 하네스가 앱을 더욱 개선하기 위해 처리할 수 있는 몇 가지 상식적인 개선 사항과 예외 상황이 있음을 시사했어요.

로그를 읽어보니, 평가자가 구현을 사양과 일치하도록 유지했음이 분명했어요. 각 스프린트마다 스프린트 계약의 테스트 기준을 따라가고 Playwright를 통해 실행 중인 애플리케이션을 테스트하며, 예상되는 동작과 다른 모든 것에 대해 버그를 제출했어요. 계약은 세분화되어 있었고(스프린트 3만 해도 레벨 에디터를 다루는 27개의 기준이 있었어요), 평가자의 발견은 추가 조사 없이도 조치할 수 있을 만큼 구체적이었죠. 아래 표는 평가자가 식별한 몇 가지 문제의 예시를 보여줘요.

평가자가 이 수준에서 작동하도록 만드는 데는 노력이 필요했어요. 초기에는 클로드가 형편없는 QA 에이전트였죠. 초기 실행에서는 합법적인 문제를 식별한 다음, 대수롭지 않게 여겨 작업을 승인하는 모습을 보였어요. 또한, 가장자리 사례를 탐색하기보다는 피상적으로 테스트하는 경향이 있어서 미묘한 버그들이 종종 놓치기 쉬웠어요. 🕵️‍♀️ 튜닝 루프는 평가자의 로그를 읽고, 판단이 제 것과 다른 예시를 찾아내어, QA 프롬프트를 업데이트하여 이러한 문제를 해결하는 것이었어요. 평가자가 합리적인 방식으로 등급을 매기기까지는 여러 번의 개발 루프가 필요했죠. 그럼에도 불구하고, 하네스 출력물은 모델의 QA 능력의 한계를 보여주었어요. 작은 레이아웃 문제, 일부 직관적이지 않은 상호 작용, 그리고 평가자가 철저히 테스트하지 않은 더 깊이 중첩된 기능에서 발견되지 않은 버그 등이 있었죠. 추가 튜닝을 통해 잡을 수 있는 검증의 여지가 분명히 더 많았어요. 하지만 애플리케이션의 핵심 기능이 작동하지 않았던 단독 실행과 비교하면 그 향상은 분명했답니다.

4.3. 하네스 반복 개선

하네스의 첫 번째 결과는 고무적이었지만, 부피가 크고 느리며 비용이 많이 들었어요. 다음 논리적인 단계는 성능 저하 없이 하네스를 단순화할 방법을 찾는 것이었어요. 이는 부분적으로 상식적인 문제였고, 부분적으로는 더 일반적인 원칙의 기능이었어요. 즉, 하네스의 모든 구성 요소는 모델이 자체적으로 할 수 없는 것에 대한 가정을 담고 있으며, 이러한 가정은 잘못될 수도 있고, 모델이 개선됨에 따라 빠르게 구식이 될 수 있기 때문에 스트레스 테스트를 해볼 가치가 있다는 거죠.

단순화를 위한 첫 시도에서 하네스를 대폭 축소하고 몇 가지 창의적인 새로운 아이디어를 시도했지만, 원래 성능을 재현할 수 없었어요. 또한, 하네스 설계의 어떤 부분이 실제로 중요한 역할을 하는지, 어떤 방식으로 중요한지 파악하기 어려워졌죠. 이러한 경험을 바탕으로, 한 번에 하나의 구성 요소를 제거하고 최종 결과에 미치는 영향을 검토하는 보다 체계적인 접근 방식으로 전환했어요. 🧪

이러한 반복 주기 동안, Opus 4.6도 출시되었는데, 이는 하네스 복잡성을 줄여야 하는 추가적인 동기를 제공했어요. 4.6은 4.5보다 더 적은 스캐폴딩이 필요할 것이라는 합리적인 기대가 있었죠.

**[Opus 4.6]**은 더 신중하게 계획하고, 에이전트 작업을 더 오랫동안 유지하며, 더 큰 코드베이스에서 더 안정적으로 작동할 수 있고, 자체 실수를 잡아내는 더 나은 코드 검토 및 디버깅 기술을 가지고 있습니다. 또한, 장기 컨텍스트 검색 능력도 크게 향상되었습니다.

이러한 모든 기능은 하네스가 보완하기 위해 구축된 기능들이었답니다.

4.4. 스프린트 구조 제거

가장 먼저 스프린트 구조를 완전히 제거하는 것부터 시작했어요. 스프린트 구조는 모델이 일관성 있게 작업하도록 작업을 덩어리로 분해하는 데 도움이 되었죠. Opus 4.6의 개선 사항을 고려할 때, 모델이 이러한 종류의 분해 없이도 작업을 자체적으로 처리할 수 있을 것이라는 합리적인 이유가 있었어요.

계획자와 평가자는 계속해서 분명한 가치를 더했기 때문에 유지했어요. 계획자가 없으면 생성자는 범위를 너무 작게 설정했어요. 원시 프롬프트가 주어지면, 작업을 미리 지정하지 않고 빌드를 시작하여 계획자가 만든 것보다 기능이 덜 풍부한 애플리케이션을 만들게 되었죠.

스프린트 구조가 제거되면서, 평가자는 스프린트별 평가 대신 실행이 끝날 때 한 번만 평가하도록 변경했어요. 모델이 훨씬 더 유능해졌기 때문에, 특정 실행에서 평가자의 역할이 얼마나 중요한지는 모델이 자체적으로 얼마나 안정적으로 작업을 수행할 수 있는지에 따라 달라졌죠. 4.5에서는 그 경계가 가까웠어요. 우리의 빌드는 생성자가 단독으로 잘 할 수 있는 한계에 있었고, 평가자는 빌드 전반에 걸쳐 의미 있는 문제를 잡아냈어요. 4.6에서는 모델의 원시 능력이 증가하여 그 경계가 밖으로 이동했어요. 이전에는 평가자의 확인이 필요했던 작업들이 이제는 생성자가 자체적으로 잘 처리할 수 있는 범위 내에 들어왔고, 그 범위 내의 작업에서는 평가자가 불필요한 오버헤드가 되었죠. 하지만 생성자의 능력 한계에 있는 빌드 부분에서는 평가자가 여전히 실제적인 도움을 주었어요.

실제적인 의미는 평가자가 고정된 예-아니오 결정이 아니라는 거예요. 현재 모델이 단독으로 안정적으로 수행할 수 있는 범위를 넘어서는 작업일 때 그 비용을 지불할 가치가 있다는 뜻이죠.

구조적 단순화와 더불어, 각 앱에 AI 기능을 구축하는 방식을 개선하기 위해 프롬프팅을 추가했어요. 특히, 앱의 기능을 도구를 통해 구동할 수 있는 적절한 에이전트를 생성하도록 만들었죠. 이는 관련 지식이 충분히 최근이라 클로드의 훈련 데이터에 거의 포함되어 있지 않아 실제 반복 작업이 필요했어요. 하지만 충분한 튜닝을 통해 생성자는 에이전트를 올바르게 구축할 수 있었답니다. 🛠️

4.5. 업데이트된 하네스 결과

업데이트된 하네스를 테스트하기 위해 다음 프롬프트를 사용하여 DAW(Digital Audio Workstation), 즉 노래 작곡, 녹음, 믹싱을 위한 음악 제작 프로그램을 생성했어요.

Web Audio API를 사용하여 브라우저에서 모든 기능을 갖춘 DAW를 구축해줘.

이 실행은 여전히 길고 비쌌으며, 약 4시간이 걸렸고 토큰 비용은 $124였어요.

대부분의 시간은 빌더에 사용되었는데, Opus 4.5에 필요했던 스프린트 분해 없이 2시간 이상 일관성 있게 실행되었어요.

이전 하네스와 마찬가지로, 계획자는 한 줄짜리 프롬프트를 완전한 사양으로 확장했어요. 로그를 통해 생성자 모델이 앱과 에이전트 설계를 잘 계획하고, 에이전트를 연결하고, QA에 인계하기 전에 테스트했음을 알 수 있었어요.

그럼에도 불구하고, QA 에이전트는 여전히 실제 격차를 발견했어요. 첫 번째 피드백에서 다음과 같이 언급했죠.

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

두 번째 피드백에서도 여러 기능적 격차를 발견했어요.

남은 격차:

• 오디오 녹음은 여전히 스터브 전용입니다 (버튼은 토글되지만 마이크 캡처는 없음).
• 가장자리 드래그를 통한 클립 크기 조정 및 클립 분할이 구현되지 않았습니다.
• 효과 시각화는 숫자 슬라이더이며, 그래픽이 아닙니다 (EQ 곡선 없음).

생성자는 자체적으로 작업을 수행할 때 세부 사항을 놓치거나 기능을 스터브 처리하는 경향이 여전히 있었고, QA는 생성자가 수정해야 할 마지막 단계의 문제들을 잡아내는 데 여전히 가치를 더했어요.

프롬프트를 바탕으로 저는 멜로디, 화음, 드럼 패턴을 만들고, 그것들을 노래로 배열하고, 그 과정에서 통합 에이전트의 도움을 받을 수 있는 프로그램을 기대했어요. 🎵 아래 비디오는 그 결과를 보여줍니다.

이 앱은 전문적인 음악 제작 프로그램과는 거리가 멀고, 에이전트의 작곡 능력은 분명히 많은 개선이 필요해 보였어요. 게다가 클로드는 실제로 소리를 들을 수 없었기 때문에, 음악적 취향과 관련하여 QA 피드백 루프의 효율성이 떨어졌답니다.

하지만 최종 앱은 작동하는 배열 보기, 믹서, 그리고 브라우저에서 실행되는 전송 기능 등 기능적인 음악 제작 프로그램의 모든 핵심 요소를 갖추고 있었어요. 그 이상으로, 저는 프롬프팅을 통해서만 짧은 노래 조각을 만들 수 있었어요. 에이전트는 템포와 키를 설정하고, 멜로디를 깔고, 드럼 트랙을 만들고, 믹서 레벨을 조정하고, 리버브를 추가했죠. 작곡을 위한 핵심 요소들이 존재했고, 에이전트는 도구를 사용하여 간단한 프로덕션을 처음부터 끝까지 자율적으로 구동할 수 있었어요. 아직 완벽하지는 않지만, 점점 나아지고 있는 중이라고 할 수 있겠죠! 🤩

5. 다음 단계: 하네스 설계의 지속적인 진화

모델이 계속 발전함에 따라, 우리는 모델이 더 오랫동안, 그리고 더 복잡한 작업을 수행할 수 있을 것으로 예상할 수 있어요. 어떤 경우에는 모델을 둘러싼 스캐폴드(scaffold)의 중요성이 시간이 지남에 따라 줄어들 것이고, 개발자들은 다음 모델을 기다리면서 특정 문제들이 저절로 해결되는 것을 볼 수도 있을 거예요. 반면에, 모델이 더 나아질수록, 모델이 기본적으로 할 수 있는 것을 넘어 복잡한 작업을 달성할 수 있는 하네스를 개발할 수 있는 여지는 더욱 커진답니다. 🚀

이러한 점을 염두에 두고, 이 연구에서 얻은 몇 가지 교훈은 계속해서 중요하게 작용할 거예요. 모델과 함께 실험하고, 실제 문제에 대한 트레이스를 읽고, 원하는 결과를 얻기 위해 성능을 튜닝하는 것은 항상 좋은 습관이에요. 더 복잡한 작업을 수행할 때는 작업을 분해하고 문제의 각 측면에 특화된 에이전트를 적용함으로써 개선의 여지가 있을 수 있어요. 그리고 새로운 모델이 출시되면, 일반적으로 하네스를 재검토하여 더 이상 성능에 중요한 역할을 하지 않는 부분을 제거하고, 이전에는 불가능했을 더 큰 기능을 달성하기 위해 새로운 부분을 추가하는 것이 좋답니다.

이 연구를 통해, 저는 모델이 개선됨에 따라 흥미로운 하네스 조합의 공간이 줄어드는 것이 아니라는 확신을 얻었어요. 대신, 그 공간이 이동하고 있으며, AI 엔지니어들에게 흥미로운 작업은 다음 새로운 조합을 계속 찾아내는 것이라고 생각해요. 💡

마무리

이 글은 AI 에이전트, 특히 클로드를 활용하여 복잡한 애플리케이션 개발을 진행하면서 마주하는 난제들을 하네스 설계라는 독창적인 접근 방식으로 해결해나가는 과정을 흥미롭게 보여주고 있어요. 주관적인 디자인 평가에서부터 실제 작동하는 풀 스택 애플리케이션 구축에 이르기까지, 생성자-평가자-계획자로 이어지는 다중 에이전트 시스템은 AI 에이전트의 잠재력을 최대한 끌어내는 방법을 제시하고 있습니다. 앞으로도 모델의 발전과 함께 하네스 설계의 영역은 더욱 확장될 것이며, AI 엔지니어들의 창의적인 노력이 더욱 빛을 발할 것이라는 점이 매우 기대됩니다! ✨