장기 실행 애플리케이션 개발을 위한 하네스 설계
Anthropic Engineering 블로그 상세 해설
원문: Harness design for long-running application development
저자: Prithvi Rajasekaran (Anthropic Labs 팀)
게재일: 2026년 3월 24일
해설 작성일: 2026년 3월 30일
목차
- 글의 배경과 맥락
- 핵심 문제의식: 왜 단순한 구현은 실패하는가
- GAN에서 영감을 받은 멀티 에이전트 구조
- 프론트엔드 디자인 실험: 주관적 품질을 점수화하다
- 풀스택 코딩으로 확장: 3-에이전트 아키텍처
- 레트로 게임 메이커 실험: 단독 실행 vs 하네스 비교
- 하네스 반복 개선: 단순화와 성능 유지
- 업데이트된 하네스 결과: DAW 빌드
- 핵심 교훈과 앞으로의 방향
- 부록: Planner가 생성한 스펙 예시 (RetroForge)
- 종합 해석: AI 엔지니어링 관점에서의 시사점
1. 글의 배경과 맥락
이 글은 Anthropic Labs 팀의 Prithvi Rajasekaran이 몇 달간의 실험 끝에 정리한 엔지니어링 연구 보고서다. 핵심 주제는 에이전틱 코딩(agentic coding) 의 성능 한계를 어떻게 돌파할 것인가이며, 이를 위해 두 가지 매우 다른 도메인에서 동시에 실험을 수행했다.
첫 번째 도메인은 프론트엔드 디자인 품질 향상이다. Claude가 기본적으로 생성하는 UI는 기능적으로는 동작하지만 시각적으로는 단조롭고 예측 가능한 경향이 있다. 저자는 어떻게 하면 Claude가 더 독창적이고 미적으로 뛰어난 디자인을 생성하도록 만들 수 있는지 탐구했다.
두 번째 도메인은 장기 자율 코딩(long-running autonomous coding) 이다. 인간의 개입 없이 Claude 스스로 완전한 애플리케이션을 처음부터 끝까지 빌드하게 만드는 것이 목표였다. 단순히 코드 스니펫을 생성하는 것이 아니라, 여러 시간에 걸쳐 일관된 방향으로 복잡한 소프트웨어를 완성하는 수준이다.
저자는 이 두 도메인이 표면적으로는 매우 달라 보이지만, 동일한 핵심 문제들을 공유하고 있음을 발견했다. 그리고 그 문제들을 해결하기 위해 GAN(Generative Adversarial Network, 생성적 적대 신경망)에서 영감을 받은 생성자(Generator)와 평가자(Evaluator)의 멀티 에이전트 구조를 설계했다.
2. 핵심 문제의식: 왜 단순한 구현은 실패하는가
2.1 이전 연구에서 출발하다
저자는 이전에도 장기 실행 에이전틱 코딩 하네스를 구축한 경험이 있었다. 그 당시의 접근 방식은 다음과 같았다.
- 초기화 에이전트(initializer agent): 제품 명세(product spec)를 받아 태스크 목록으로 분해한다.
- 코딩 에이전트(coding agent): 한 번에 하나의 기능씩 구현하고, 세션 간에 컨텍스트를 이어가기 위해 구조화된 아티팩트(artifacts)를 핸드오프 수단으로 활용한다.
이 방식은 성능을 기준선(baseline) 대비 상당히 끌어올리는 데 성공했다. 개발자 커뮤니티에서도 비슷한 인사이트에 도달한 사례들이 있었는데, 예컨대 “Ralph Wiggum” 방법처럼 훅(hooks)이나 스크립트를 활용해 에이전트를 지속적인 반복 사이클에 가두는 방식이 그것이다.
그러나 이 방식에도 두 가지 고질적인 실패 패턴이 남아 있었다.
2.2 첫 번째 실패 패턴: 컨텍스트 불안(Context Anxiety)
첫 번째 문제는 모델이 컨텍스트 창(context window)이 가득 차오르면서 점차 일관성을 잃어가는 현상이다. 특히 일부 모델은 “컨텍스트 불안(context anxiety)” 이라 부를 수 있는 현상을 보이는데, 자신의 컨텍스트 한계에 다가왔다고 판단하면 아직 완료되지 않은 작업을 조기에 마무리 짓는 행동을 보인다.
이를 해결하기 위한 방법이 컨텍스트 리셋(context reset) 이다. 이는 단순히 이전 대화 내용을 요약해서 압축하는 컴팩션(compaction) 과는 개념적으로 다르다.
- 컴팩션: 이전 대화를 요약하여 같은 에이전트가 짧아진 히스토리로 계속 작업한다. 연속성은 유지되지만 컨텍스트 불안이 여전히 잔존할 수 있다.
- 컨텍스트 리셋: 컨텍스트 창을 완전히 비우고 새로운 에이전트를 시작한다. 에이전트에게 깨끗한 슬레이트를 제공하지만, 그 대신 이전 에이전트의 상태와 다음 단계를 담은 충분한 핸드오프 아티팩트가 필요하다.
실험에서 Claude Sonnet 4.5는 컨텍스트 불안을 매우 강하게 보여, 컴팩션만으로는 장기 작업 성능이 충분히 나오지 않았다. 따라서 컨텍스트 리셋이 하네스 설계의 핵심 요소가 되었다. 다만 이는 오케스트레이션 복잡성, 토큰 오버헤드, 지연 시간을 늘리는 트레이드오프를 수반한다.
2.3 두 번째 실패 패턴: 자기 평가(Self-Evaluation)의 편향
두 번째 문제는 에이전트가 자신이 만든 결과물을 평가할 때 발생하는 자화자찬 편향(sycophancy) 이다. 인간 관찰자가 보기에 명백히 평범하거나 버그가 있는 결과물임에도 불구하고, 에이전트는 자신의 작업을 자신 있게 칭찬하는 경향이 있다.
이 문제는 특히 주관적 판단이 필요한 작업, 즉 디자인 품질 평가에서 두드러진다. 레이아웃이 세련되게 느껴지는지 아닌지는 주관적 판단의 영역이고, 이진적 검증(binary test)이 존재하지 않기 때문이다. 에이전트는 자기 작업에 대해 일관되게 후한 점수를 매긴다.
흥미롭게도 이 문제는 검증 가능한 소프트웨어 버그를 다루는 작업에서도 나타난다. 에이전트가 버그를 발견하고도 “별로 중요한 문제가 아니다”라며 스스로 납득하여 승인해버리는 패턴이 관찰되었다.
저자가 발견한 핵심적인 해결책은 작업을 수행하는 에이전트와 그것을 판단하는 에이전트를 분리하는 것이다. 평가자 에이전트도 결국 LLM이므로 LLM이 생성한 결과물에 관대한 경향이 있다. 그러나 독립적인 평가자 에이전트를 의심하도록 튜닝하는 것이, 생성자 에이전트 스스로 비판적으로 자기 작업을 바라보게 만드는 것보다 훨씬 다루기 쉽다(tractable)는 사실이 핵심 발견이다.
3. GAN에서 영감을 받은 멀티 에이전트 구조
저자는 이 두 가지 문제를 하나의 통합된 프레임워크로 해결하기 위해, 딥러닝의 고전적 아이디어인 GAN(Generative Adversarial Network, 생성적 적대 신경망) 에서 영감을 얻었다.
GAN은 두 개의 신경망이 서로 경쟁하며 발전하는 구조다.
- 생성자(Generator): 가능한 한 진짜처럼 보이는 데이터를 만들어낸다.
- 판별자(Discriminator): 입력된 데이터가 진짜인지 생성자가 만든 가짜인지 구분한다.
이 두 네트워크가 서로 적대적으로 경쟁하면서 생성자의 품질이 지속적으로 향상된다.
저자는 이 구조를 AI 에이전트 하네스에 적용했다. 생성자 에이전트(Generator Agent)가 결과물을 만들면, 평가자 에이전트(Evaluator Agent)가 그것을 비판적으로 평가하고 피드백을 준다. 이 피드백이 다시 생성자에게 입력되어 더 나은 결과물을 만들어내는 피드백 루프(feedback loop) 가 형성된다.
단, GAN과의 핵심 차이가 있다. 딥러닝의 GAN에서는 두 네트워크가 동시에 학습하면서 가중치(weights)가 업데이트된다. 반면 여기서의 에이전트 구조는 프롬프트와 명시적 피드백을 통해 반복적으로 개선되는 구조다. 모델 가중치가 바뀌는 것이 아니라, 에이전트가 받는 입력(피드백)이 점진적으로 품질을 끌어올린다.
이 GAN 영감 구조는 두 도메인 모두에서 핵심 레버로 작동했다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
[사용자 프롬프트]
↓
[생성자 에이전트]
결과물 생성
↓
[평가자 에이전트]
기준에 따라 채점
상세 비평 작성
↓
점수가 임계값 이상? ──→ 완료
↓ (아니오)
피드백을 생성자에게 전달
↓
생성자: 개선 또는 방향 전환 결정
↓
(다음 반복으로)
4. 프론트엔드 디자인 실험: 주관적 품질을 점수화하다
4.1 왜 프론트엔드 디자인부터 시작했는가
저자가 프론트엔드 디자인 실험을 먼저 시작한 이유는 자기 평가 편향이 가장 극명하게 드러나는 영역이기 때문이다. 아무 개입 없이 Claude에게 UI를 만들게 하면, 기술적으로는 동작하지만 시각적으로는 무난하고 예측 가능한 레이아웃을 생성한다. 이것이 “AI 슬롭(AI slop)”이라 불리는 패턴이다.
4.2 핵심 인사이트 두 가지
실험을 통해 저자가 얻은 두 가지 핵심 인사이트가 있다.
첫 번째: 미학(aesthetics)은 완전히 점수로 환원할 수 없지만, 디자인 원칙을 반영한 채점 기준을 통해 개선할 수 있다. “이 디자인은 아름다운가?”라는 질문에는 일관되게 답하기 어렵지만, “이 디자인은 좋은 디자인 원칙을 따르는가?”라는 질문은 Claude가 구체적으로 채점할 수 있는 형태다.
두 번째: 프론트엔드 생성과 프론트엔드 채점을 분리함으로써, 생성자를 더 강력한 결과물로 이끄는 피드백 루프를 만들 수 있다.
4.3 네 가지 채점 기준
저자는 생성자 에이전트와 평가자 에이전트 모두의 프롬프트에 다음 네 가지 채점 기준을 제공했다.
① 디자인 품질 (Design Quality) 이 디자인이 부품들의 집합이 아니라 하나의 일관된 전체처럼 느껴지는가? 색상, 타이포그래피, 레이아웃, 이미지 등 세부 요소들이 결합하여 독특한 분위기와 정체성을 만들어내는지가 핵심이다.
② 독창성 (Originality) 커스텀한 결정의 흔적이 있는가, 아니면 템플릿 레이아웃, 라이브러리 기본값, AI가 생성한 패턴의 나열인가? 의도적인 창의적 선택을 인간 디자이너가 알아볼 수 있어야 한다. 수정되지 않은 스톡 컴포넌트, 혹은 흰 카드 위의 보라색 그라데이션 같은 AI 생성의 전형적인 패턴은 이 기준에서 낮은 점수를 받는다.
③ 장인 정신 (Craft) 타이포그래피 계층 구조, 간격 일관성, 색상 조화, 명암비 등 기술적 실행력이다. 창의성보다는 역량을 확인하는 기준이다. 합리적인 구현이라면 대부분 기본적으로 통과하며, 실패는 근본적인 기초의 붕괴를 의미한다.
④ 기능성 (Functionality) 미학과 독립적인 사용성이다. 사용자가 인터페이스의 기능을 이해하고, 주요 동작을 찾고, 추측 없이 작업을 완료할 수 있는가?
저자는 디자인 품질과 독창성을 장인 정신과 기능성보다 높게 가중치를 두었다. Claude는 이미 기술적 역량과 기능성은 기본적으로 잘 수행하기 때문이다. 문제는 디자인과 독창성이었으므로, 이 기준들이 Claude를 더 미적인 위험을 감수하는 방향으로 밀어붙이도록 설계되었다.
4.4 구체적인 실험 구조
저자는 Claude Agent SDK 위에 루프를 구축했다. 구체적인 동작 방식은 다음과 같다.
- 생성자 에이전트: 사용자 프롬프트를 받아 HTML/CSS/JS 프론트엔드를 생성한다.
- 평가자 에이전트: Playwright MCP를 통해 실제 동작하는 페이지와 직접 상호작용한다. 즉, 정적 스크린샷을 채점하는 것이 아니라 페이지를 직접 탐색하고 스크린샷을 찍으면서 구현을 면밀히 검토한 후 각 기준에 점수를 매기고 상세한 비평을 작성한다.
- 반복 횟수: 생성당 5~15회 반복. 각 반복에서 생성자는 평가자의 비평에 반응하여 점점 더 독특한 방향으로 나아간다.
- 전략적 결정: 각 평가 후 생성자는 전략적 결정을 내리도록 지시받았다. 점수가 상승 추세라면 현재 방향을 개선하고, 접근 방식이 효과가 없다면 완전히 다른 미적 방향으로 피벗한다.
- 소요 시간: 평가자가 실제로 페이지를 탐색하기 때문에 실제 시간이 소요된다. 전체 실행에 최대 4시간이 걸리기도 했다.
4.5 눈에 띄는 결과들
몇 가지 흥미로운 관찰이 있었다.
채점 기준의 언어가 생성 방향을 조종한다: “최고의 디자인은 미술관 수준이다”와 같은 문구를 포함시키자, 디자인들이 특정 시각적 방향으로 수렴하는 경향이 나타났다. 이는 채점 기준과 연관된 프롬프팅이 결과물의 성격을 직접적으로 형성한다는 것을 시사한다.
점수 향상은 항상 선형적이지 않다: 후반 반복의 결과물이 전체적으로는 더 나은 경향이 있었지만, 중간 반복의 결과물이 더 마음에 드는 경우도 있었다. 구현 복잡성도 반복이 거듭될수록 증가하여, 생성자가 평가자의 피드백에 반응해 더 야심찬 해결책을 시도했다.
첫 번째 반복도 이미 기준선보다 낫다: 평가자의 피드백이 없더라도 채점 기준과 관련 언어 자체가 모델을 일반적인 기본값에서 벗어나게 했다.
가장 주목할 만한 사례 — 네덜란드 미술관 웹사이트: 모델이 네덜란드 미술관 웹사이트를 만들도록 프롬프트를 받았을 때, 9번째 반복까지는 어두운 테마의 깔끔한 랜딩 페이지를 만들어냈다. 시각적으로 세련되었지만 예상 범위 안에 있었다. 그런데 10번째 사이클에서 접근 방식 전체를 폐기하고 공간 경험으로 재상상했다. CSS 원근법으로 렌더링된 체크무늬 바닥이 있는 3D 방, 자유롭게 배치된 벽의 예술 작품들, 스크롤이나 클릭 대신 출입문 기반의 갤러리 룸 간 내비게이션. 이는 단일 패스 생성에서는 이전에 본 적 없는 수준의 창의적 도약이었다.
5. 풀스택 코딩으로 확장: 3-에이전트 아키텍처
5.1 디자인 실험의 교훈을 코딩으로 가져오다
프론트엔드 디자인에서 얻은 발견들을 풀스택 개발에 적용하는 것은 논리적 확장이었다. 생성자-평가자 루프는 소프트웨어 개발 생명주기에 자연스럽게 매핑된다. 코드 리뷰와 QA가 디자인 평가자와 동일한 구조적 역할을 한다.
5.2 3-에이전트 시스템의 구성
이전 하네스를 기반으로 세 개의 에이전트로 구성된 시스템을 구축했다.
플래너 에이전트 (Planner Agent)
이전 하네스에서는 사용자가 상세한 명세를 미리 제공해야 했다. 이 단계를 자동화하기 위해 플래너 에이전트를 만들었다. 플래너는 1~4문장의 간단한 프롬프트를 받아 완전한 제품 명세로 확장한다.
플래너에게 주어진 지침의 핵심은 다음과 같다:
- 범위에 대해 야심차게 접근할 것
- 세부 기술 구현이 아니라 제품 컨텍스트와 고수준 기술 설계에 집중할 것 (세부 사항을 미리 틀리면 하위 구현 전체에 에러가 전파될 수 있음)
- 에이전트들이 무엇을 만들지는 제약하되 어떻게 만들지는 스스로 결정하게 할 것
- 제품 명세에 AI 기능을 자연스럽게 엮어 넣을 것
제너레이터 에이전트 (Generator Agent)
이전 하네스에서 효과적이었던 “한 번에 하나의 기능” 접근 방식을 이어받았다. 생성자는 명세에서 한 번에 하나의 기능을 선택하여 스프린트 방식으로 작업한다.
기술 스택: React, Vite, FastAPI, SQLite (나중에 PostgreSQL). 각 스프린트 완료 시 QA로 넘기기 전에 스스로 작업을 자체 평가하도록 지시받았다. 버전 관리를 위해 git도 사용할 수 있었다.
평가자 에이전트 (Evaluator Agent)
이전 하네스에서 구축된 앱들은 인상적으로 보였지만 실제로 사용해보면 실제 버그가 존재했다. 이를 잡아내기 위해 평가자는 Playwright MCP를 사용해 실제 사용자처럼 실행 중인 애플리케이션을 클릭해 다닌다. UI 기능, API 엔드포인트, 데이터베이스 상태를 테스트한다.
각 스프린트는 발견된 버그와, 프론트엔드 실험에서 유래한 기준들(제품 깊이, 기능성, 시각 디자인, 코드 품질에 맞게 조정)에 따라 채점된다. 각 기준에는 하드 임계값이 있으며, 하나라도 임계값 아래로 떨어지면 해당 스프린트는 실패이고 생성자는 무엇이 잘못되었는지에 대한 상세한 피드백을 받는다.
5.3 스프린트 계약 (Sprint Contract)
각 스프린트 시작 전에 생성자와 평가자는 코드가 작성되기 전에 해당 작업의 “완료”가 무엇을 의미하는지에 합의한다. 이것이 스프린트 계약이다.
제품 명세는 의도적으로 고수준으로 작성되었기 때문에, 사용자 스토리와 테스트 가능한 구현 사이의 간극을 메우는 단계가 필요했다. 생성자가 무엇을 만들고 성공이 어떻게 검증될지를 제안하면, 평가자가 그 제안을 검토하여 생성자가 올바른 것을 만들고 있는지 확인한다. 둘이 합의할 때까지 반복한다.
에이전트 간 통신은 파일을 통해 이루어진다. 한 에이전트가 파일을 작성하면 다른 에이전트가 그것을 읽고 동일한 파일 내에서, 또는 이전 에이전트가 읽을 새 파일로 응답한다. 이는 너무 일찍 구현을 과도하게 명세화하지 않으면서도 명세에 충실한 작업을 보장한다.
6. 레트로 게임 메이커 실험: 단독 실행 vs 하네스 비교
6.1 실험 설정
첫 번째 버전의 하네스에는 Claude Opus 4.5를 사용했다. 다음 프롬프트를 단독 실행과 전체 하네스 모두에 실행했다.
“레벨 에디터, 스프라이트 에디터, 엔티티 동작, 플레이 가능한 테스트 모드를 포함한 기능을 갖춘 2D 레트로 게임 메이커를 만들어라.”
결과는 다음과 같았다:
| 하네스 유형 | 실행 시간 | 비용 |
|---|---|---|
| 단독 실행 (Solo) | 20분 | $9 |
| 전체 하네스 (Full Harness) | 6시간 | $200 |
비용은 20배 이상 차이 났지만, 결과물의 품질 차이는 즉각적으로 명백했다.
6.2 단독 실행 결과: 핵심 기능이 동작하지 않다
단독 실행 결과물을 열었을 때 초기 화면은 기대에 부합하는 것처럼 보였다. 하지만 클릭해보면서 문제들이 드러나기 시작했다.
- 레이아웃 낭비: 고정 높이 패널로 인해 뷰포트 대부분이 비어 있었다.
- 워크플로우 경직성: 레벨을 채우려면 먼저 스프라이트와 엔티티를 만들어야 했지만, UI는 그 순서를 안내하지 않았다.
- 핵심 기능 고장: 엔티티들이 화면에 보이지만 어떤 입력에도 반응하지 않았다. 코드를 파고들어 보면 엔티티 정의와 게임 런타임 사이의 연결이 끊어져 있었는데, 표면에서는 전혀 알 수 없었다.
6.3 전체 하네스 결과: 동일한 한 문장에서 출발, 완전히 다른 결과
하네스 실행은 같은 한 문장 프롬프트에서 시작했지만, 플래너 단계에서 이를 10개 스프린트에 걸친 16개 기능 명세로 확장했다. 단독 실행이 시도한 것을 훨씬 뛰어넘었다.
코어 에디터와 플레이 모드 외에도 명세는 다음을 포함했다:
- 스프라이트 애니메이션 시스템
- 동작 템플릿 (behavior templates)
- 효과음과 음악
- AI 지원 스프라이트 생성기 및 레벨 디자이너
- 공유 가능한 링크를 통한 게임 내보내기
플래너에게 프론트엔드 디자인 스킬에 대한 접근권도 부여했는데, 플래너는 이를 읽어 명세의 일부로 앱의 시각 디자인 언어를 만들었다.
결과물은 다음 면에서 단독 실행보다 명확히 우수했다:
- 풀 뷰포트 캔버스: 공간을 효율적으로 활용했다.
- 일관된 시각 정체성: 명세의 디자인 방향이 일관되게 반영되었다.
- 더 풍부한 스프라이트 에디터: 더 깔끔한 도구 팔레트, 더 나은 색상 선택기, 더 사용하기 편한 줌 컨트롤.
- 내장 Claude 통합: 플래너가 AI 기능을 명세에 엮도록 요청받았기 때문에, 앱에는 프롬프팅으로 게임의 다양한 부분을 생성할 수 있는 내장 Claude 통합이 포함되었다.
- 플레이 가능한 게임: 가장 큰 차이점은 플레이 모드였다. 실제로 엔티티를 움직이고 게임을 플레이할 수 있었다. 물리 엔진에 거친 부분이 있었지만(플랫폼과 겹치는 현상 등), 핵심 기능은 동작했다.
6.4 평가자가 잡아낸 구체적인 버그들
하네스 실행의 로그를 보면 평가자가 얼마나 상세하게 검증했는지 알 수 있다. Sprint 3 하나에만 레벨 에디터를 다루는 27개의 기준이 있었다. 다음은 평가자가 식별한 이슈 예시들이다:
| 스프린트 계약 기준 | 평가자 발견 사항 |
|---|---|
| 사각형 채우기 도구는 클릭-드래그로 선택된 타일로 사각형 영역을 채울 수 있어야 한다 | FAIL — 도구가 드래그 시작/끝 지점에만 타일을 배치. fillRectangle 함수는 존재하지만 mouseUp 시 제대로 트리거되지 않음. |
| 사용자가 배치된 엔티티 스폰 포인트를 선택하고 삭제할 수 있어야 한다 | FAIL — LevelEditor.tsx:892의 Delete 키 핸들러가 selection과 selectedEntityId 모두 설정되어야 하지만, 엔티티 클릭 시 selectedEntityId만 설정됨. 조건이 selection \|\| (selectedEntityId && activeLayer === 'entity')이어야 함. |
| 사용자가 API를 통해 애니메이션 프레임을 재정렬할 수 있어야 한다 | FAIL — PUT /frames/reorder 라우트가 /{frame_id} 라우트 이후에 정의됨. FastAPI가 ‘reorder’를 frame_id 정수로 매칭하여 422: “unable to parse string as an integer” 반환. |
이처럼 평가자의 발견은 추가 조사 없이도 바로 조치할 수 있을 만큼 구체적이었다.
6.5 평가자 튜닝의 어려움
평가자가 이 수준으로 작동하게 만드는 것은 상당한 작업이 필요했다. 기본 상태에서 Claude는 QA 에이전트로서 성능이 낮다. 초기 실행에서는 정당한 이슈를 발견하고도 스스로를 납득시켜 중요하지 않다고 판단하고 작업을 승인하는 패턴이 반복적으로 관찰되었다. 또한 엣지 케이스를 탐색하지 않고 피상적으로 테스트하는 경향이 있어 미묘한 버그들이 종종 놓쳤다.
튜닝 루프는 다음과 같았다: 평가자의 로그를 읽고, 평가자의 판단이 저자의 판단과 다른 사례를 찾고, 그 문제를 해결하도록 QA 프롬프트를 업데이트한다. 이 개발 루프를 여러 번 반복한 후에야 평가자가 합리적으로 채점하기 시작했다.
그래도 하네스 출력물은 모델의 QA 역량의 한계를 보여주었다. 작은 레이아웃 이슈, 직관적이지 않은 상호작용, 평가자가 충분히 검증하지 않은 더 깊이 중첩된 기능의 미발견 버그 등이 있었다. 하지만 핵심 기능 자체가 동작하지 않았던 단독 실행에 비하면 명백히 나은 결과였다.
7. 하네스 반복 개선: 단순화와 성능 유지
7.1 단순화의 원칙
첫 번째 하네스 결과는 고무적이었지만 크고, 느리고, 비쌌다. 다음 단계는 성능 저하 없이 하네스를 단순화하는 것이었다.
이는 단순히 비용 절감의 문제만이 아니라 더 근본적인 원칙에 기반한다: 하네스의 모든 컴포넌트는 모델이 스스로 할 수 없다는 가정을 인코딩한다. 그 가정들은 잘못되었거나 모델이 개선됨에 따라 빠르게 낡아갈 수 있다. Anthropic의 “Building Effective Agents” 포스트는 이 아이디어를 “가능한 가장 단순한 해결책을 찾고, 필요할 때만 복잡성을 높여라”로 표현한다.
저자의 첫 번째 단순화 시도에서는 하네스를 급진적으로 축소하고 몇 가지 새로운 아이디어를 시도했지만, 원래 성능을 재현하지 못했다. 어떤 부분이 실제로 성능에 중요한지 알기 어려웠다. 그 경험을 바탕으로 한 번에 하나의 컴포넌트를 제거하고 최종 결과에 미치는 영향을 검토하는 방법론적 접근법으로 전환했다.
7.2 Claude Opus 4.6 출시가 가져온 변화
반복 사이클 중에 Opus 4.6이 출시되면서 하네스 복잡성을 줄일 추가적인 동기가 생겼다. Opus 4.6은 Opus 4.5가 보완이 필요했던 영역들에서 개선되었다:
- 더 신중한 계획 수립
- 더 긴 에이전틱 작업 지속
- 더 큰 코드베이스에서의 신뢰성 향상
- 자체 실수를 잡아내는 코드 리뷰 및 디버깅 역량 향상
- 긴 컨텍스트 검색 능력의 실질적 개선
이는 모두 하네스가 보완하도록 구축된 역량들이다.
7.3 스프린트 구조 제거
저자는 스프린트 구조를 완전히 제거하는 것으로 단순화를 시작했다. 스프린트 구조는 모델이 일관되게 작업하기 위한 청크 단위 분해를 도왔다. Opus 4.6의 향상된 능력을 감안하면, 모델이 이런 분해 없이도 작업을 처리할 수 있을 것이라는 근거가 있었다.
플래너와 평가자는 명백한 가치가 있어 유지했다.
- 플래너 없이는: 생성자가 범위를 축소했다. 원시 프롬프트만 주면 명세 작업 없이 빌드를 시작하여 플래너가 만든 것보다 기능이 적은 애플리케이션을 생성했다.
- 평가자의 역할 변화: 스프린트 구조를 제거하면서 평가자를 각 스프린트마다 채점하는 대신 실행 끝에 단일 패스로 옮겼다.
중요한 통찰이 있다. Opus 4.5에서는 하네스 경계가 모델이 혼자 잘 할 수 있는 것의 한계에 가까웠고, 평가자는 빌드 전반에서 의미 있는 이슈를 잡아냈다. Opus 4.6에서는 모델의 원시 역량이 증가하면서 경계가 바깥쪽으로 이동했다. 이전에는 평가자의 확인이 필요했던 작업들이 이제는 종종 생성자가 혼자 잘 처리했고, 그 경계 내에서는 평가자가 불필요한 오버헤드가 되었다. 하지만 빌드에서 생성자 역량의 한계에 있는 부분에서는 평가자가 여전히 실질적인 리프트를 제공했다.
실용적인 함의: 평가자는 고정된 예/아니오 결정이 아니다. 현재 모델이 혼자 신뢰할 수 있게 처리하는 것을 넘어서는 태스크일 때 비용이 정당화된다.
7.4 AI 기능 통합 개선
구조적 단순화와 함께, 하네스가 각 앱에 AI 기능을 빌드하는 방식도 개선했다. 구체적으로는 생성자가 앱 자체의 기능을 도구를 통해 구동할 수 있는 적절한 에이전트를 빌드하도록 프롬프팅을 추가했다. 관련 지식이 Claude의 훈련 데이터에 얇게 반영될 만큼 최신이어서, 충분한 튜닝이 필요했다. 하지만 충분한 튜닝 후 생성자는 에이전트를 올바르게 빌드하고 있었다.
8. 업데이트된 하네스 결과: DAW 빌드
8.1 실험 설정
업데이트된 하네스를 테스트하기 위해 다음 프롬프트로 브라우저 기반 DAW(Digital Audio Workstation, 디지털 오디오 워크스테이션)를 생성했다.
“Web Audio API를 사용하여 브라우저에서 완전한 기능을 갖춘 DAW를 빌드하라.”
8.2 비용 및 시간 분석
실행은 여전히 길고 비쌌다 — 약 4시간, $124의 토큰 비용.
| 에이전트 & 단계 | 소요 시간 | 비용 |
|---|---|---|
| 플래너 | 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 |
대부분의 시간은 빌더가 소요했으며, Opus 4.5가 필요로 했던 스프린트 분해 없이도 2시간 이상 일관되게 실행되었다. 이는 Opus 4.6의 향상된 장기 지속 역량을 직접적으로 보여준다.
8.3 QA 에이전트의 피드백
플래너는 한 줄 프롬프트를 전체 명세로 확장했다. 로그에서 생성자 모델이 앱과 에이전트 설계를 잘 계획하고, 에이전트를 연결하고, QA에 넘기기 전에 테스트한 것을 볼 수 있었다.
그럼에도 QA 에이전트는 실질적인 격차를 잡아냈다.
1라운드 피드백 요약: 훌륭한 디자인 충실도, 견고한 AI 에이전트, 좋은 백엔드를 갖춘 강력한 앱이지만, 핵심 실패 지점은 기능 완성도다. 클립을 타임라인에서 드래그/이동할 수 없고, 악기 UI 패널(신디사이저 노브, 드럼 패드)이 없으며, 시각적 이펙트 에디터(EQ 곡선, 컴프레서 미터)가 없다. 이것들은 엣지 케이스가 아니라 DAW를 사용 가능하게 만드는 핵심 상호작용이다.
2라운드 피드백 요약: 오디오 녹음이 여전히 스텁 수준(버튼 토글만 있고 마이크 캡처 없음), 클립 가장자리 드래그 리사이즈 및 클립 분할 미구현, 이펙트 시각화가 그래픽이 아닌 숫자 슬라이더.
생성자는 혼자 내버려 두면 세부 사항을 놓치거나 기능을 스텁으로 처리하는 경향이 있었고, QA는 생성자가 수정할 “라스트 마일” 이슈를 잡아내는 데 여전히 가치를 발휘했다.
8.4 최종 결과물의 특성
결과물은 전문 음악 제작 프로그램에는 미치지 못하며, 에이전트의 곡 작곡 실력도 분명히 개선의 여지가 있다. 또한 Claude는 실제로 음악을 들을 수 없어, 음악적 취향과 관련한 QA 피드백 루프의 효과가 제한적이었다.
그러나 최종 앱은 기능적인 음악 제작 프로그램의 모든 핵심 요소를 갖췄다: 브라우저에서 동작하는 어레인지먼트 뷰, 믹서, 트랜스포트. 나아가 프롬프팅만으로 짧은 곡 스니펫을 조합할 수 있었다. 에이전트가 템포와 키를 설정하고, 멜로디를 깔고, 드럼 트랙을 빌드하고, 믹서 레벨을 조정하고, 리버브를 추가하는 것을 도구를 통해 자율적으로 수행했다.
9. 핵심 교훈과 앞으로의 방향
9.1 모델 개선과 하네스의 관계
모델이 계속 개선됨에 따라, 에이전트를 둘러싼 스캐폴드(scaffold)가 덜 중요해지는 경우가 있다. 개발자들은 다음 모델을 기다리면 특정 문제들이 저절로 해결되는 것을 볼 수 있다.
하지만 반대 방향도 있다. 모델이 더 좋아질수록, 기준선에서 모델이 할 수 없는 복잡한 작업을 달성하는 하네스를 개발할 공간이 더 넓어진다. 하네스 조합의 공간은 모델이 개선될수록 줄어드는 것이 아니라 이동한다. AI 엔지니어의 흥미로운 작업은 계속해서 다음 새로운 조합을 찾는 것이다.
9.2 실용적 교훈 세 가지
교훈 1: 모델과 실험하고 트레이스를 읽어라 현재 빌드하고 있는 모델에 대해 실험하고, 현실적인 문제에서의 트레이스를 읽고, 원하는 결과를 달성하도록 성능을 튜닝하는 것이 항상 좋은 실천이다.
교훈 2: 복잡한 태스크에는 전문화된 에이전트를 사용하라 더 복잡한 태스크에서는 태스크를 분해하고 문제의 각 측면에 전문화된 에이전트를 적용하는 데서 헤드룸이 생기는 경우가 있다.
교훈 3: 새 모델이 나오면 하네스를 재검토하라 새 모델이 출시되면 하네스를 재검토하는 것이 일반적으로 좋은 실천이다. 성능에 더 이상 기여하지 않는 부분을 제거하고, 이전에는 불가능했던 더 큰 역량을 달성하기 위한 새로운 부분을 추가한다.
10. 부록: Planner가 생성한 스펙 예시 (RetroForge)
글의 부록에는 플래너 에이전트가 생성한 실제 제품 명세 예시가 포함되어 있다. “2D 레트로 게임 메이커를 만들어라”는 짧은 프롬프트에서 플래너가 어떤 수준의 명세를 생성했는지 보여준다.
플래너는 “RetroForge” 라는 이름의 웹 기반 창작 스튜디오를 구상했다.
개요: RetroForge는 2D 레트로 스타일 비디오 게임을 디자인하고 빌드하기 위한 웹 기반 창작 스튜디오다. 클래식 8비트/16비트 게임의 향수를 현대적이고 직관적인 편집 도구와 결합하여, 취미 창작자부터 인디 개발자까지 누구나 기존 코드 작성 없이 게임 아이디어를 실현할 수 있게 한다.
4개의 통합 창작 모듈:
- 타일 기반 레벨 에디터 (게임 세계 디자인)
- 픽셀 아트 스프라이트 에디터 (시각 자산 제작)
- 시각적 엔티티 동작 시스템 (게임 로직 정의)
- 즉각적인 플레이 가능한 테스트 모드 (실시간 게임플레이 테스트)
Claude를 통한 AI 지원이 플랫폼 전반에 걸쳐 통합되어 있다.
예시 기능 명세 - 프로젝트 대시보드 & 관리:
사용자 스토리로 구성된 상세한 명세를 포함한다:
- 이름과 설명으로 새 게임 프로젝트 만들기
- 기존 프로젝트를 프로젝트 이름, 마지막 수정 날짜, 썸네일 미리보기가 있는 시각적 카드로 보기
- 프로젝트를 열어 전체 게임 에디터 워크스페이스 진입
- 확인 다이얼로그로 사고 방지하며 프로젝트 삭제
- 새 게임의 시작점으로 기존 프로젝트 복제
프로젝트 데이터 모델:
- 프로젝트 메타데이터 (이름, 설명, 생성/수정 타임스탬프)
- 캔버스 설정 (해상도: 256x224, 320x240, 160x144 등)
- 타일 크기 설정 (8x8, 16x16, 32x32 픽셀)
- 색상 팔레트 선택
- 연관된 모든 스프라이트, 타일셋, 레벨, 엔티티 정의
이 명세 수준의 상세함이 플래너 에이전트가 자동으로 생성한 것이다. 한 문장 프롬프트가 16개 기능, 10개 스프린트의 상세 제품 명세로 변환되었다.
11. 종합 해석: AI 엔지니어링 관점에서의 시사점
11.1 이 연구가 말하는 것
이 글은 표면적으로는 하네스 설계에 관한 기술적 보고서이지만, 그 안에는 여러 층위의 의미가 담겨 있다.
첫째, 하네스 설계는 모델 선택만큼 중요하다. 동일한 프롬프트를 단독 실행하면 20분/$9, 하네스를 통해 실행하면 6시간/$200이 든다. 그런데 단독 실행의 결과물은 핵심 기능이 동작하지 않고, 하네스의 결과물은 실제로 플레이 가능한 게임이다. 이는 하네스 설계가 모델 자체의 역량만큼이나 실제 결과물의 품질을 결정한다는 것을 보여준다.
둘째, 자기 평가 편향은 근본적인 LLM 문제다. 에이전트가 자신의 작업을 평가할 때 보여주는 자화자찬 경향은 단순히 프롬프트로 해결할 수 없는 근본적인 편향이다. 외부 평가자 에이전트를 통한 구조적 분리가 더 효과적인 해결책이다.
셋째, 채점 기준의 언어 자체가 생성 방향을 조종한다. “최고의 디자인은 미술관 수준이다”라는 문구가 실제로 모델의 생성 방향을 특정 미적 수렴으로 이끌었다. 이는 프롬프트 엔지니어링이 단순한 지시 전달을 넘어, 모델의 창의적 공간 자체를 재형성한다는 것을 의미한다.
넷째, 하네스의 복잡성과 모델의 역량은 역의 관계를 가진다. Opus 4.5에서 필요했던 컨텍스트 리셋과 스프린트 구조가 Opus 4.6에서는 불필요해졌다. 모델이 발전할수록 하네스의 일부 구성요소는 불필요한 오버헤드가 된다. 따라서 새 모델 출시 시마다 하네스를 재검토하는 것이 중요하다.
11.2 LxM (Ludus Ex Machina) 프레임워크와의 연결
이 하네스 설계 원칙은 AI 게임 아레나처럼 다중 AI 에이전트가 경쟁하는 플랫폼에도 직접 적용 가능하다.
플래너-제너레이터-평가자 구조는 게임 AI 시스템에서도 유사한 역할 분담으로 활용될 수 있다. 플래너는 게임 전략을 계획하고, 제너레이터는 실제 수를 생성하며, 평가자는 수의 품질을 평가한다. 특히 평가자 에이전트의 독립성 원칙—자신의 수를 스스로 평가하면 편향이 생긴다—은 AI 게임 에이전트의 자기 평가 설계에 중요한 시사점을 준다.
11.3 한국 AI 생태계에 대한 함의
이 연구는 한국 소프트웨어 기업들에게 중요한 신호를 보낸다. AI 에이전트를 단순히 “Claude에게 물어보기”가 아닌, 목적에 맞게 설계된 하네스 위에서 운영할 때 결과물의 품질이 질적으로 달라진다. 한국 기업들이 AI 도입을 추진할 때, 모델 선택만큼이나 하네스 설계 역량을 내재화하는 것이 핵심 경쟁력이 될 것이다.
또한 이 연구는 AI 엔지니어링이 단순한 프롬프트 작성이 아님을 보여준다. 에이전트 아키텍처 설계, 평가 기준 정의, 반복적 튜닝, 모델 역량 변화에 따른 하네스 재검토 — 이 모든 것이 하나의 전문 기술 영역으로 자리잡고 있다.
이 문서는 Anthropic Engineering의 “Harness design for long-running application development” (2026년 3월 24일)를 기반으로 작성된 상세 해설입니다.