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

Anthropic은 이전 연구에서 하네스 설계가 장기 실행 에이전틱 코딩의 효과에 상당한 영향을 미친다는 것을 보여준 바 있다. 초기 실험에서는 초기화 에이전트(initializer agent)가 제품 스펙을 작업 목록으로 분해하고, 코딩 에이전트가 한 번에 하나의 기능씩 구현한 뒤 세션 간 아티팩트를 넘기는 방식을 사용했다. 개발자 커뮤니티에서도 "랄프 위검(Ralph Wiggum)" 방법론처럼 훅이나 스크립트로 에이전트를 지속적 반복 사이클에 묶어두는 유사한 접근법이 등장했다.

그러나 몇 가지 문제는 끈질기게 남았다. 복잡한 작업에서 에이전트는 시간이 지날수록 방향을 잃는 경향이 있었다. 이 문제를 분해해 보면 두 가지 공통된 실패 모드가 관찰된다.

첫째, 모델은 컨텍스트 윈도우가 채워지면서 장시간 작업의 일관성을 잃는다. 일부 모델은 컨텍스트 불안(context anxiety)이라는 현상을 보이는데, 자신이 컨텍스트 한계에 다가가고 있다고 판단하면 작업을 조기에 마무리하려 한다. 컨텍스트 리셋(context reset) — 컨텍스트 윈도우를 완전히 비우고 이전 에이전트의 상태와 다음 단계를 담은 구조화된 핸드오프와 함께 새 에이전트를 시작하는 것 — 이 이 두 문제를 모두 해결한다. 이전 테스트에서 Claude Sonnet 4.5는 컨텍스트 불안이 강해서 컴팩션(compaction)만으로는 충분하지 않았고, 컨텍스트 리셋이 하네스 설계의 필수 요소가 되었다.

둘째, 이전에 다루지 않았던 문제로 자기 평가(self-evaluation)가 있다. 자신이 만든 결과물을 평가하라고 하면, 에이전트는 인간 관찰자에게 품질이 명백히 평범해 보이는 경우에도 자신감 넘치는 칭찬으로 응답하는 경향이 있다. 이 문제는 디자인처럼 검증 가능한 소프트웨어 테스트에 해당하는 이진 검사가 없는 주관적 작업에서 특히 두드러진다. 그러나 검증 가능한 결과가 있는 작업에서도 에이전트는 여전히 좋지 않은 판단을 보일 때가 있다. 작업을 수행하는 에이전트와 판단하는 에이전트를 분리하는 것이 이 문제를 해결하는 강력한 레버가 된다.

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

저자는 자기 평가 문제가 가장 두드러지는 프론트엔드 디자인에서 실험을 시작했다. 아무런 개입 없이 두면 Claude는 기술적으로 기능하지만 시각적으로 눈에 띄지 않는 안전하고 예측 가능한 레이아웃으로 수렴한다.

두 가지 통찰이 하네스를 형성했다. 첫째, 미학을 완전히 점수로 환원할 수는 없지만, 디자인 원칙과 선호를 인코딩하는 채점 기준으로 개선할 수 있다. "이 디자인이 아름다운가?"는 일관되게 답하기 어렵지만, "이것이 우리의 좋은 디자인 원칙을 따르는가?"는 Claude에게 구체적으로 채점할 거리를 준다. 둘째, 프론트엔드 생성과 채점을 분리함으로써 생성기를 더 강한 결과물로 몰아가는 피드백 루프를 만들 수 있다.

이를 바탕으로 생성기와 평가기 에이전트 모두에게 주어지는 네 가지 채점 기준을 작성했다:

디자인 품질(Design Quality): 색상, 타이포그래피, 레이아웃, 이미지 등이 결합되어 뚜렷한 분위기와 정체성을 만들어내는가. 독창성(Originality): 의도적인 창의적 결정이 보이는가, 아니면 템플릿 레이아웃과 라이브러리 기본값, AI 생성 패턴인가. 보라색 그라데이션 위 흰색 카드 같은 "AI 슬럽" 패턴은 여기서 감점이다. 기술력(Craft): 타이포그래피 위계, 간격 일관성, 색상 조화, 대비비 같은 기술적 실행. 기능성(Functionality): 미학과 독립적인 사용성.

디자인 품질과 독창성에 더 높은 가중치를 부여했다. Claude는 기본적으로 기술력과 기능성에서 이미 좋은 점수를 받고 있었기 때문이다.

Claude Agent SDK 위에 루프를 구축했다. 생성기 에이전트가 사용자 프롬프트에 기반해 HTML/CSS/JS 프론트엔드를 만든다. 평가기에는 Playwright MCP를 부여하여, 점수를 매기기 전에 실제 페이지와 직접 상호작용하고 스크린샷을 캡처할 수 있게 했다. 그 피드백이 다시 생성기의 다음 반복 입력으로 흘러간다. 생성당 5~15회 반복을 실행했으며, 전체 실행은 최대 4시간까지 소요되었다.

인상적인 사례가 하나 있다. 네덜란드 미술관 웹사이트를 만들라는 프롬프트에서, 9번째 반복까지는 깔끔한 다크 테마 랜딩 페이지를 세련되게 다듬었다. 그런데 10번째 사이클에서 기존 접근을 완전히 폐기하고 사이트를 공간적 경험으로 재구상했다. CSS 원근법으로 렌더링된 체크무늬 바닥의 3D 방, 벽면에 자유로운 위치로 걸린 작품, 스크롤이나 클릭 대신 출입구 기반 갤러리 탐색. 단일 패스 생성에서는 본 적 없는 종류의 창의적 도약이었다.

풀스택 코딩으로의 확장

3-에이전트 아키텍처

이전 하네스에서는 초기화 에이전트, 한 번에 한 기능씩 작업하는 코딩 에이전트, 세션 간 컨텍스트 리셋으로 일관성 있는 멀티 세션 코딩을 해결했다. Opus 4.5는 컨텍스트 불안을 대부분 자체적으로 제거했기 때문에 이 하네스에서는 컨텍스트 리셋을 완전히 삭제할 수 있었다. 에이전트들은 전체 빌드에 걸쳐 하나의 연속 세션으로 실행되었고, Claude Agent SDK의 자동 컴팩션이 컨텍스트 성장을 처리했다.

기획자(Planner): 이전 하네스는 사용자가 상세한 스펙을 직접 제공해야 했다. 이 단계를 자동화하기 위해 1~4문장의 간단한 프롬프트를 전체 제품 스펙으로 확장하는 기획자 에이전트를 만들었다. 세부적인 기술 구현이 아닌 제품 컨텍스트와 고수준 기술 설계에 집중하도록 프롬프팅했다. 기획자가 세분화된 기술 세부사항을 미리 지정하다 잘못되면, 스펙의 오류가 하위 구현으로 연쇄 전파될 수 있기 때문이다. AI 기능을 제품 스펙에 엮어 넣을 기회를 찾도록 지시하기도 했다.

생성기(Generator): 이전 하네스의 한 번에 한 기능 접근법이 범위 관리에 효과적이었기에 유사한 모델을 적용했다. 생성기에게 스프린트(Sprint) 단위로 작업하며 스펙에서 한 번에 하나의 기능을 가져오도록 지시했다. 각 스프린트는 React + Vite + FastAPI + SQLite(후에 PostgreSQL) 스택으로 앱을 구현했다.

평가기(Evaluator): 이전 하네스의 애플리케이션은 인상적으로 보였지만 실제로 사용해 보면 진짜 버그가 있었다. 이를 잡기 위해 평가기가 Playwright MCP로 실행 중인 애플리케이션을 사용자처럼 클릭하며 탐색하고, UI 기능·API 엔드포인트·데이터베이스 상태를 테스트했다. 각 스프린트를 프론트엔드 실험에서 적용한 기준(제품 깊이, 기능성, 시각 디자인, 코드 품질)으로 채점했고, 어떤 기준이라도 경계값 아래로 떨어지면 해당 스프린트는 실패 처리되어 생성기에 상세 피드백이 전달되었다.

각 스프린트 전에 생성기와 평가기는 스프린트 계약(Sprint Contract)을 협상했다. 코드를 한 줄도 작성하기 전에 해당 작업 단위의 "완료"가 무엇인지 합의하는 것이다. 에이전트 간 커뮤니케이션은 파일을 통해 처리됐다. 한 에이전트가 파일을 쓰면 다른 에이전트가 읽고 응답하는 방식이었다.

하네스 실행 결과: 레트로 게임 메이커

프롬프트: "레벨 에디터, 스프라이트 에디터, 엔티티 행동, 플레이 가능한 테스트 모드를 포함한 2D 레트로 게임 메이커를 만들어라."

단일 에이전트(Solo)는 20분에 $9로 완성했지만, 풀 하네스는 6시간에 $200가 소요됐다. 비용은 20배 이상 차이 났지만, 결과물의 품질 차이는 즉각적으로 드러났다.

단일 에이전트 결과: 초기 화면은 기대에 부합하는 것처럼 보였으나, 실제로 클릭해 보니 레이아웃이 공간을 낭비하고 워크플로우가 경직되어 있었다. 가장 중요한 문제는 게임 자체가 작동하지 않았다는 것이다. 엔티티는 화면에 나타났지만 입력에 반응하지 않았다. 코드를 살펴보니 엔티티 정의와 게임 런타임 간의 배선이 끊어져 있었다.

풀 하네스 결과: 기획자가 원래의 한 문장 프롬프트를 10개 스프린트에 걸친 16개 기능 스펙으로 확장했다. 코어 에디터와 플레이 모드 외에도 스프라이트 애니메이션 시스템, 행동 템플릿, 사운드 효과, AI 지원 스프라이트 생성기와 레벨 디자이너, 공유 가능 링크를 통한 게임 내보내기까지 포함되었다. 실제로 캐릭터를 움직이고 게임을 플레이할 수 있었다. 물리 엔진에 거친 부분이 있었지만 핵심은 작동했다.

평가기가 실제로 잡아낸 버그들

평가기의 발견은 구체적이고 실행 가능했다. 스프린트 3에서만 레벨 에디터에 대한 27개 기준이 있었다. 예를 들어: 사각형 채우기 도구가 드래그 시작/끝 지점에만 타일을 배치하고 영역을 채우지 않는 버그, 엔티티 삭제 핸들러의 조건문 오류, FastAPI의 라우트 순서 문제로 'reorder'를 정수로 파싱하려다 422 오류가 발생하는 문제 등이었다.

평가기가 이 수준으로 작동하게 하려면 상당한 튜닝이 필요했다. 기본 상태의 Claude는 형편없는 QA 에이전트다. 초기 실행에서 정당한 문제를 식별해 놓고도 별 문제가 아니라고 스스로를 설득한 뒤 작업을 승인하는 것을 목격했다. 평가기의 로그를 읽고, 저자의 판단과 차이가 나는 예시를 찾아 QA 프롬프트를 업데이트하는 과정을 여러 차례 반복한 뒤에야 합리적인 채점이 가능해졌다.

하네스의 반복 개선

첫 번째 하네스 결과는 고무적이었지만, 부피가 크고 느리고 비쌌다. 논리적 다음 단계는 성능을 저하시키지 않으면서 단순화하는 방법을 찾는 것이었다. 하네스의 모든 컴포넌트는 "모델이 스스로 할 수 없는 것"에 대한 가정을 인코딩하며, 그 가정은 스트레스 테스트할 가치가 있다 — 틀렸을 수도 있고, 모델이 개선되면서 금방 낡아질 수도 있기 때문이다.

스프린트 구조 제거

Opus 4.6의 출시와 함께 하네스 복잡도를 줄일 동기가 더 강해졌다. 출시 블로그에서 언급된 것처럼 "Opus 4.6은 더 신중하게 계획하고, 에이전틱 작업을 더 오래 지속하며, 더 큰 코드베이스에서 안정적으로 작동하고, 자체 실수를 잡아내는 코드 리뷰 및 디버깅 능력이 향상되었다." 이 모든 것이 하네스가 보충해 왔던 역량이었다.

스프린트 구조를 완전히 제거했다. 기획자와 평가기는 유지했다. 기획자 없이는 생성기가 범위를 축소했고, 평가기 없이는 여전히 빈틈이 남았다. 평가기를 스프린트별이 아닌 빌드 마지막에 한 번만 실행하는 것으로 변경했다.

모델 역량이 높아지면서 평가기의 부하 지지(load-bearing) 정도가 작업에 따라 달라졌다. 4.5에서는 빌드가 생성기의 한계 근처에 있었기에 평가기가 의미 있는 문제를 잡았다. 4.6에서는 모델의 기본 역량이 높아져 그 경계가 바깥으로 이동했다. 이전에 평가기의 검증이 필요했던 작업이 이제 생성기 혼자서도 충분히 잘 처리하게 되었지만, 여전히 생성기 역량의 경계에 있는 부분에서는 평가기가 실질적 개선을 제공했다.

결과: 브라우저 기반 DAW

프롬프트: "Web Audio API를 사용하여 브라우저에서 완전한 기능을 갖춘 DAW(디지털 오디오 워크스테이션)를 만들어라."

실행 시간은 약 4시간, 토큰 비용은 $124.70이었다. 대부분의 시간은 빌더가 차지했으며, 스프린트 분해 없이도 2시간 넘게 일관되게 작동했다. 기획자는 4.7분에 $0.46, 1차 빌드는 2시간 7분에 $71.08, 1차 QA는 8.8분에 $3.24 식으로 진행되었다.

QA 에이전트는 여전히 실질적 빈틈을 발견했다. 1차 피드백에서 "앱이 인상적으로 보이고 AI 통합도 잘 작동하지만, 핵심 DAW 기능 여럿이 인터랙티브 깊이 없이 표시만 되고 있다"고 지적했다. 클립 드래그/이동, 악기 UI 패널(신스 노브, 드럼 패드), 시각적 이펙트 에디터(EQ 커브, 컴프레서 미터) 등이 빠져 있었다. 2차 피드백에서도 오디오 녹음 스텁, 클립 리사이즈, 이펙트 시각화 등의 누락을 잡아냈다.

최종 앱은 전문 음악 프로그램과는 거리가 있고, 에이전트의 작곡 능력도 미흡했다. 또한 Claude는 실제로 소리를 들을 수 없어서 QA 피드백 루프가 음악적 취향에 관해서는 덜 효과적이었다. 하지만 작동하는 어레인지먼트 뷰, 믹서, 트랜스포트가 모두 브라우저에서 구동되었고, 프롬프팅만으로 짧은 곡 스니펫을 만들 수 있었다. 에이전트가 템포와 키를 설정하고, 멜로디를 깔고, 드럼 트랙을 구성하고, 믹서 레벨을 조정하고, 리버브를 추가했다.

앞으로의 방향

모델이 계속 개선되면 더 오래, 더 복잡한 작업을 수행할 수 있게 된다. 어떤 경우에는 모델 주변의 스캐폴딩이 시간이 지나면서 덜 중요해지고, 다음 모델을 기다리면 특정 문제가 저절로 해결될 것이다. 반면, 모델이 나아질수록 기본 성능으로는 불가능했던 복잡한 작업을 하네스로 달성할 수 있는 공간도 넓어진다.

이 작업에서 얻은 교훈들: 작업 대상 모델을 실제 문제에 대해 실험하고, 트레이스를 읽고, 원하는 결과를 달성하도록 성능을 튜닝하는 것이 항상 좋은 관행이다. 복잡한 작업에서는 과제를 분해하고 각 측면에 특화된 에이전트를 적용함으로써 추가적인 성능 향상 여지가 있다. 새 모델이 나오면 하네스를 재검토하여, 더 이상 성능에 필수적이지 않은 부분을 걷어내고 이전에는 불가능했던 새로운 역량을 추가하는 것이 일반적으로 좋은 관행이다.

흥미로운 하네스 조합의 공간은 모델이 개선됨에 따라 줄어드는 것이 아니다. 이동할 뿐이다. AI 엔지니어에게 흥미로운 일은 다음의 새로운 조합을 계속 찾는 것이다.