장기 실행 앱 개발을 위한 하네스 설계

게시일: 2026년 3월 25일 | 원문 작성일: 2026년 3월 24일 | 저자: Prithvi Rajasekaran | 원문 보기

• • •

들어가며

저는 몇 달에 걸쳐 서로 맞물린 두 가지 과제를 연구했어요. 하나는 Claude가 고품질 프론트엔드 디자인을 만들게 하는 것이고, 다른 하나는 완성도 높은 애플리케이션을 자율적으로 구축하게 하는 것이었어요. 프론트엔드 디자인 스킬과 장기 실행 코딩 에이전트, 두 분야의 이전 연구를 기반으로 했지만, 두 접근법 모두 결국 성능 한계에 막혔죠.

이 한계를 넘기 위해 다양한 도메인에 적용할 수 있는 새로운 AI 엔지니어링 접근법을 탐구했어요. GAN(Generative Adversarial Networks)2에서 영감을 받아 생성자(generator)와 평가자(evaluator)로 구성된 멀티 에이전트 시스템을 설계했어요. 핵심 통찰은 “이 디자인이 좋은가?”와 같은 주관적 판단을 구체적이고 측정 가능한 기준으로 바꾸는 것이었죠.

이후 이 기법을 자율 풀스택 코딩에 적용했어요. 플래너(planner), 생성자(generator), 평가자(evaluator)의 3-에이전트 아키텍처가 수 시간에 걸친 세션에서 정교한 애플리케이션을 만들어냈어요.

• • •

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

이전 연구에서 하네스1 설계가 장기 실행 에이전틱 코딩의 효과를 크게 좌우한다는 점이 확인되었어요. 초기 실험에서는 초기화 에이전트(initializer agent)가 스펙을 작업 목록으로 분해하고, 코딩 에이전트가 기능을 순차적으로 구현한 뒤 컨텍스트 아티팩트를 넘기는 방식을 사용했죠.

하지만 근본적인 문제들이 남아 있었어요.

컨텍스트 관리 문제

모델은 긴 작업을 하다 보면 컨텍스트 윈도우3가 채워지면서 일관성을 잃는 경향이 있어요. 어떤 모델은 “컨텍스트 불안(context anxiety)“을 보여서, 한계에 다가간다고 느끼는 순간 서둘러 마무리 짓으려 해요. 컨텍스트 리셋(체계적인 인수인계와 함께 윈도우를 완전히 비우는 방식)이 단순 압축보다 두 문제 모두에 더 효과적이었어요. Claude Sonnet 4.5는 이런 행동이 특히 심해서 압축만으로는 부족했죠.

자기 평가의 함정

에이전트가 자기 작업을 평가하면, 사람 눈에는 품질 문제가 뻔한데도 에이전트 스스로는 자신 있게 칭찬해요. 디자인처럼 맞고 틀림을 이진적으로 확인할 수 없는 주관적 작업에서 특히 심하죠.

생성 에이전트와 평가 에이전트를 분리하면 매우 효과적이에요. 평가자도 LLM 특유의 관대한 평가 편향은 있지만, 독립된 평가자 하나를 회의적인 성향으로 조정하는 게 생성자 자체를 자기비판적으로 만드는 것보다 훨씬 수월해요.

• • •

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

프론트엔드 디자인부터 실험을 시작했어요 — 자기 평가 문제가 가장 뚜렷하게 드러나는 영역이었거든요. 별다른 개입 없이 놔두면, Claude는 기술적으로는 문제없지만 시각적으로는 특색 없는 레이아웃을 만들어요.

두 가지 통찰이 접근법을 형성했어요.

• 미적 감각을 완벽히 점수로 환원할 순 없지만, 디자인 원칙을 반영한 채점 기준이 있으면 결과의 일관성을 높일 수 있어요
• 생성과 평가를 분리하면 더 나은 출력을 이끌어내는 피드백 루프가 만들어져요

4가지 채점 기준

네 가지 기준을 개발해 생성자와 평가자 모두에게 적용했어요.

• 디자인 품질(Design Quality) — 디자인이 응집력 있게 느껴지는가? 색상, 타이포그래피, 레이아웃, 이미지가 결합되어 독특한 분위기와 정체성을 만드는가?
• 독창성(Originality) — 의도적인 창작 결정의 증거가 있는가, 아니면 템플릿과 기본값뿐인가? 인간 디자이너라면 의도적인 창의적 선택임을 알아볼 수 있어야 해요. “보라색 그래디언트 위 화이트 카드” 같은 기성 컴포넌트와 AI 기본 패턴은 감점 대상이에요.
• 완성도(Craft) — 타이포그래피 위계, 간격 일관성, 색상 조화, 대비 비율 등 기술적 실행 수준. 웬만큼 합리적으로 구현하면 기본적으로 통과하고, 여기서 떨어진다면 근본적인 무언가가 깨진 거예요.
• 기능성(Functionality) — 미적 요소와 무관한 사용성. 사용자가 인터페이스 목적을 이해하고, 주요 동작을 찾고, 추측 없이 작업을 완료할 수 있는가?

Claude가 완성도와 기능성에서는 이미 잘해내고 있었기 때문에 디자인 품질과 독창성에 더 높은 가중치를 부여했어요. 채점 기준에서 뻔한 “AI 슬롭(AI slop)“4 패턴을 명시적으로 감점하게 해서, 미적으로 모험을 감수하도록 밀어붙였죠.

구현과 결과

Claude Agent SDK로 루프를 구축했어요. 생성자가 사용자 프롬프트로부터 HTML/CSS/JavaScript 프론트엔드를 만들고, 평가자는 Playwright MCP5를 통해 라이브 페이지를 직접 탐색한 뒤 채점과 상세 피드백을 제공했어요. 피드백이 생성자에게 돌아가 반복이 진행됐죠.

생성마다 5~15회 반복을 실행했는데, 각 사이클이 보통 더 독특한 방향으로 이끌었어요. 평가자 점수는 반복을 거듭하며 개선되다가 일정 시점에서 안정화됐죠. 어떤 생성은 점진적으로 다듬어졌고, 어떤 것은 급격한 미적 전환을 보였어요.

기준의 문구 자체가 결과물의 방향을 예상치 못하게 움직였어요. 흥미로운 발견이었죠. “최고의 디자인은 박물관 수준”이라는 표현을 넣자 특정한 시각적 수렴이 나타났죠. 첫 번째 반복부터 베이스라인보다 눈에 띄게 나은 결과가 나왔어요. 채점 기준의 언어 자체가 모델을 뻔한 기본값에서 벗어나게 만든 거예요 — 평가자 피드백이 돌아오기도 전에요.

• • •

풀스택 코딩으로 확장하기

프론트엔드 실험의 성과를 손에 쥐고, GAN 영감 패턴을 풀스택 개발에 적용했어요. 생성자-평가자 루프는 소프트웨어 개발 라이프사이클에서 코드 리뷰와 QA가 맡는 구조적 역할에 자연스럽게 대응돼요.

3-에이전트 아키텍처

이전 장기 실행 하네스에서는 초기화 에이전트, 기능을 하나씩 처리하는 코딩 에이전트, 세션 간 컨텍스트 리셋으로 멀티 세션 일관성 문제를 해결했어요. Opus 4.5가 나오면서 컨텍스트 불안 행동이 대부분 사라져 컨텍스트 리셋을 없앨 수 있었어요. 이후 에이전트는 연속 세션 방식으로 운영됐고, 컨텍스트 증가는 Claude Agent SDK6의 자동 압축(compaction)7이 처리했죠.

3-에이전트 시스템은 이전 실행에서 관찰된 특정 격차를 해결해요.

플래너(Planner): 이전 하네스는 상세한 사전 스펙을 요구했어요. 그래서 1~4문장의 간단한 프롬프트를 전체 제품 사양으로 변환하는 플래너 에이전트를 만들었어요. 야심 찬 범위를 목표로 하되, 세부 구현 사항이 아닌 제품 맥락과 고수준 기술 설계에 집중하도록 프롬프트했어요. 잘못된 스펙에서 비롯된 오류가 하위 구현으로 연쇄되는 것보다, 에이전트가 스스로 구현 경로를 찾게 두는 편이 낫다고 봤거든요. 또한 플래너가 AI 기능을 스펙에 녹여 넣도록 지시했어요.

생성자(Generator): 이전 하네스에서 한 번에 기능 하나씩 만드는 방식이 범위 관리에 효과적이었어요. 여기서도 비슷한 구조를 적용해 스프린트 단위로 작업하면서, 스펙에서 한 번에 하나의 기능을 구현하도록 했어요. 각 스프린트에서는 React, Vite, FastAPI, SQLite(이후 PostgreSQL) 스택을 사용했고, 생성자가 QA에 넘기기 전에 자체 평가를 수행하며 git으로 버전을 관리했어요.

평가자(Evaluator): 이전 하네스로 만든 앱은 겉보기엔 인상적이었지만, 실제로 써 보면 진짜 버그가 있었어요. 평가자는 Playwright MCP를 써서 실행 중인 앱을 실제 사용자처럼 클릭하며 UI 기능, API 엔드포인트, 데이터베이스 상태를 테스트했어요. 발견된 버그와 함께 프론트엔드 실험에서 가져온 제품 깊이, 기능성, 시각 디자인, 코드 품질을 아우르는 기준으로 각 스프린트를 채점했죠. 각 기준마다 하드 임계값이 있어서, 미달하면 스프린트 실패로 처리되고 생성자에게 상세 피드백이 돌아갔어요.

스프린트 계약

각 스프린트에 들어가기 전에 생성자와 평가자가 스프린트 계약을 맺어 “완료(done)“의 기준을 협상했어요. 이 과정이 고수준 사용자 스토리와 테스트 가능한 구현 사이의 간극을 메워줬죠. 생성자가 무엇을 만들고 어떻게 성공을 검증할지 제안하면, 평가자가 올바른 것을 만들고 있는지 확인하고, 합의에 이를 때까지 반복했어요.

에이전트 간 통신은 파일을 통해 이루어졌어요. 한 에이전트가 파일에 쓰면 다른 에이전트가 읽고, 같은 파일에 응답하거나 새 파일을 만들어서 앞선 에이전트가 참조하게 했죠. 생성자는 합의된 계약에 맞춰 빌드한 뒤 QA에 넘겼는데, 이렇게 하면 구현을 너무 일찍 세세하게 지정하지 않으면서도 스펙에 충실한 작업이 가능했어요.

• • •

하네스 실행: 솔로 vs 풀 하네스

첫 버전에서는 Claude Opus 4.5를 사용해 풀 하네스와 단일 에이전트 시스템을 비교했어요.

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

비용은 $9 → $200으로 20배 이상 비쌌지만, 품질 차이는 한눈에 분명했어요.

솔로 에이전트의 한계

기대했던 건 레벨을 구성 요소(스프라이트, 엔티티, 타일 레이아웃)로 조립한 뒤 게임플레이를 테스트하는 인터페이스였어요. 솔로 실행 결과물은 처음 보기엔 기대에 들어맞는 것 같았어요.

하지만 직접 클릭해 보니 문제가 속속 드러났어요. 레이아웃은 고정 높이 패널 때문에 뷰포트 대부분이 비어 있었고, 공간을 낭비하고 있었어요. 워크플로우가 경직되어 있어서, 레벨을 채우려면 먼저 스프라이트와 엔티티를 만들어야 했는데, 그 순서를 안내해 주는 건 아무것도 없었어요. 가장 치명적인 건, 게임 자체가 깨져 있다는 거였어요. 엔티티가 화면에 나타나긴 했지만 입력에 전혀 반응하지 않았죠. 코드를 뜯어보니 엔티티 정의와 게임 런타임 사이 연결이 완전히 끊겨 있었어요. 겉으로는 아무 이상도 보이지 않았는데도요.

초기 화면스프라이트 에디터게임 플레이

풀 하네스의 결과

풀 하네스는 같은 프롬프트에서 시작했지만 플래너가 10개 스프린트에 걸쳐 16개 기능을 담은 스펙으로 확장했어요. 핵심 에디터와 플레이 모드 외에 스프라이트 애니메이션 시스템, 행동 템플릿, 사운드 이펙트와 음악, AI 지원 스프라이트/레벨 생성기, 공유 링크가 포함된 게임 내보내기까지 포함했죠. 플래너는 프론트엔드 디자인 스킬을 불러와 시각적 디자인 언어를 스펙에 직접 녹여냈어요.

앱은 즉각적인 완성도와 매끄러움의 차이를 보여줬어요. 캔버스가 전체 뷰포트를 활용하고, 패널 크기가 합리적이며, 인터페이스는 스펙의 디자인 방향을 따르는 일관된 시각적 정체성을 갖추고 있었어요.

결정적으로, 게임을 실제로 플레이할 수 있었어요. 엔티티가 입력에 반응했어요. 솔로 실행이 완전히 실패한 핵심 기능이 작동했죠.

초기 화면스프라이트 에디터AI 레벨 생성 (1)AI 레벨 생성 (2)게임 플레이

• • •

하네스 반복 개선: Opus 4.6으로의 전환

초기 결과는 고무적이었지만, 하네스가 무겁고 느리고 비싸다는 점도 드러냈어요. 하네스의 모든 구성 요소에는 모델 능력에 대한 가정이 깔려 있는데, 이 가정들은 모델이 개선되면 반드시 검증해볼 필요가 있어요. 금방 낡아지거든요.

한꺼번에 과감하게 잘라봤더니 결과를 재현할 수 없었어요. 그래서 구성 요소를 하나씩 체계적으로 제거하면서 영향을 살피는 방향으로 가닥을 잡았어요. Opus 4.6 출시와 함께 복잡성을 줄여야 할 동기가 더 커졌어요. 출시 블로그에서 이렇게 언급했거든요.

스프린트 구조 제거

Opus 4.6의 향상된 능력을 고려해 먼저 스프린트를 완전히 제거했어요. 모델이 작업 분해를 명시적 구조 없이도 스스로 해낼 수 있어야 했거든요.

스프린트를 없애도 플래너와 평가자는 유지했어요. 각각이 분명한 가치를 제공했기 때문이에요.

• 플래너 없이: 생성자가 뭘 만들지 먼저 명세하지 않고 바로 구축에 들어가면서, 범위가 좁아지고 기능이 빈약한 앱이 만들어졌어요.
• 평가자: 실행 종료 후 한 번만 채점하는 단일 패스 방식으로 전환했어요. Opus 4.5에서는 빌드 자체가 모델 능력의 경계선에 걸쳐 있어서, 평가자가 전체 구현에 걸쳐 의미 있는 문제를 잡아냈어요. Opus 4.6에서는 기본 능력이 올라가면서 그 경계가 바깥으로 밀려났죠. 전에는 평가자 검수가 필요했던 작업도, 이제는 생성자 혼자 충분히 해낼 수 있게 됐어요. 다만 여전히 능력의 경계에 걸리는 작업에서는 평가자가 실질적인 도움이 됐어요.

여기서 얻은 시사점이 있어요. 평가자는 “쓸 것인가 말 것인가”를 고정적으로 결정하는 게 아니라, 현재 모델이 혼자 안정적으로 처리하기 어려운 작업을 만날 때 비로소 가치를 발휘해요.

또한 앱에 AI 기능을 더 잘 녹여내도록 프롬프팅을 개선했어요. 구체적으로는, 생성자가 도구를 활용해 앱 기능을 구동하는 제대로 된 에이전트를 만들도록 유도했죠. 에이전트 구축이 비교적 최근에 등장한 주제라 학습 데이터에는 드물게만 반영되어 있었지만, 충분히 튜닝하면 생성자가 에이전트를 제대로 구축해낼 수 있었어요.

업데이트된 하네스 결과

업데이트된 하네스를 다음 프롬프트로 테스트했어요: “Web Audio API를 사용해 브라우저에서 완전한 기능의 DAW를 만들어줘.”

실행 시간은 약 4시간, 토큰 비용은 약 $125였어요.

대부분의 시간은 빌더에 투입되었는데, Opus 4.5와 달리 스프린트 분해 없이도 2시간 넘게 일관되게 작업을 이어갔어요.

플래너는 한 줄짜리 프롬프트를 전체 사양으로 확장했어요. 생성자 로그에는 계획 수립, 에이전트 설계, 도구 연결, 핸드오프 전 테스트가 충실히 담겨 있었어요.

QA는 여전히 실질적인 격차를 잡아냈어요.

생성자는 감독 없이 놔두면 여전히 세부 사항을 놓치거나 기능을 스텁 상태로 남겨두었어요. QA가 이런 마지막 마일의 문제를 잡아내고 생성자에게 수정하게 하는 데서 가치를 더했죠. 튜닝을 거친 뒤에도 하네스 출력에는 모델 QA 능력의 한계가 드러났어요. 사소한 레이아웃 문제, 직관적이지 않은 인터랙션, 평가자가 깊이 들여다보지 않은 기능 속에 숨은 버그 같은 것들이었어요.

최종 앱은 브라우저에서 작동하는 어레인지먼트 뷰, 믹서, 트랜스포트 등 풀스택 DAW의 핵심 요소를 모두 갖추고 있었어요. 프롬프팅만으로 짧은 곡을 작곡해볼 수 있었죠: 에이전트가 템포와 키를 설정하고, 멜로디를 깔고, 드럼 트랙을 만들고, 믹서 레벨을 조정하고, 리버브를 입혔어요. 핵심 작곡 요소들이 모두 갖춰져 있었고, 에이전트가 도구를 스스로 다루며 처음부터 끝까지 완수해냈어요.

• • •

앞으로의 방향

모델이 발전하면서 더 오래, 더 복잡한 작업을 해낼 수 있게 돼요. 때로는 스캐폴딩이 덜 중요해져서, 다음 모델을 기다리면 문제가 저절로 풀리기도 하죠. 반대 방향도 있어요. 더 나은 모델과 하네스가 결합되면, 기본 능력만으로는 닿을 수 없었던 새로운 영역이 열려요.

앞으로 가져갈 핵심 교훈들이에요.

• 대상 모델로 직접 실험하세요: 실제 문제 → 트레이스 읽기 → 성능 튜닝의 사이클을 돌리세요
• 분해와 전문화가 효과적이에요: 작업 분할 → 전문 에이전트 투입 → 상당한 여유 공간 확보
• 새 모델이 나오면 하네스를 재검토하세요: 쓸모없어진 부분 제거 → 새로운 능력 활용 요소 추가

흥미로운 하네스 조합의 공간은 모델이 발전해도 줄어들지 않아요. 옮겨 갈 뿐이에요. 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에게도 감사해요.

• • •

부록: 플래너 출력 예시