Anthropic - Harness design for long-running application development 정리

들어가며

이 글은 Anthropic에서 작성한 ‘The AI-Native SDLC playbook’ 을 번역한 글입니다. 원본은 다음 링크를 통해 확인할 수 있습니다: https://claude.com/blog/the-ai-native-sdlc-playbook

장시간 애플리케이션 개발을 위한 하네스 설계

Anthropic은 Claude가 더 좋은 프론트엔드를 만들고, 사람의 개입 없이 장시간 애플리케이션을 개발하도록 만드는 방법을 실험함.

• 기존 프롬프트 엔지니어링과 하네스만으로도 성능을 크게 높일 수 있었지만 한계가 있었음.
• 특히 주관적인 디자인 품질과 검증 가능한 소프트웨어 품질이라는 서로 다른 문제에서 공통으로 통하는 접근을 찾고자 함.
• GAN에서 아이디어를 얻어 작업을 수행하는 Generator와 결과를 비판적으로 검증하는 Evaluator를 분리함.
• 장시간 개발에서는 여기에 제품 범위를 설계하는 Planner까지 추가함.

단순한 구현이 부족한 이유

• 긴 작업에서는 컨텍스트가 쌓일수록 모델의 일관성이 떨어질 수 있음.
• 일부 모델은 컨텍스트 한계가 가까워졌다고 판단하면 일을 일찍 마무리하는 context anxiety를 보임.
• Sonnet 4.5에서는 compaction만으로 이를 해결하기 어려워, 상태를 파일로 넘기고 새로운 컨텍스트에서 다시 시작하는 context reset이 필요했음.
• 대신 reset은 오케스트레이션 복잡도, 토큰 비용, 지연시간을 증가시킴.
• 커뮤니티에서도 Ralph Wiggum 방식처럼 에이전트를 반복 실행하는 접근이 비슷한 방향으로 발전함.

또 다른 문제는 자기평가임.

• 모델은 자신이 만든 결과를 평가할 때 지나치게 관대한 경향이 있음.
• 객관적 테스트가 어려운 디자인에서는 이 문제가 특히 큼.
• Generator와 Evaluator를 분리해도 Evaluator가 자동으로 엄격해지는 것은 아니지만, Evaluator를 회의적으로 튜닝하는 편이 Generator에게 자기 결과를 냉정하게 평가하도록 만드는 것보다 쉬웠음.

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

Anthropic은 디자인 평가를 네 기준으로 분해함.

• Design quality
  • 색상, 타이포그래피, 레이아웃, 이미지 등이 하나의 정체성을 만드는지 평가함.
• Originality
  • 템플릿·라이브러리 기본값·전형적인 AI 디자인에서 벗어난 의도적인 선택이 있는지 확인함.
• Craft
  • 타이포그래피 계층, 간격, 대비, 색 조화 등 기본적인 구현 완성도를 평가함.
• Functionality
  • 사용자가 기능과 주요 행동을 자연스럽게 이해하고 사용할 수 있는지 평가함.

Claude는 Craft와 Functionality는 기본적으로 잘 수행했기 때문에 Design quality와 Originality에 더 높은 비중을 둠.

Evaluator는 예시와 점수 기준을 제공하는 few-shot 방식으로 보정해 평가 성향을 일정하게 유지함.

Generator가 페이지를 만든 뒤 Evaluator가 Playwright를 이용해 실제 페이지를 탐색하고 스크린샷과 동작을 확인함. 이후 평가 결과를 Generator에게 넘겨 다시 수정하게 함.

• 일반적으로 5~15회 반복함.
• 전체 과정은 최대 약 4시간까지 이어짐.
• 평가가 좋으면 기존 방향을 개선하고, 좋지 않으면 디자인 콘셉트 자체를 바꾸도록 함.
• 반복하면서 점수가 대체로 상승했지만 항상 선형적으로 좋아진 것은 아님.
• 최종 결과보다 중간 결과가 더 좋은 경우도 있었음.
• 반복이 진행될수록 구현 역시 더 복잡하고 야심차지는 경향이 나타남.

평가 기준의 문구 자체도 생성 결과에 영향을 줌.

즉 Evaluator의 피드백뿐 아니라 무엇을 좋은 결과라고 정의하느냐 자체가 Generator의 행동을 바꿈.

Dutch art museum 실험에서는 9번째까지 비교적 전통적인 어두운 랜딩 페이지를 만들다가, 10번째 반복에서 기존 방향을 폐기하고 CSS perspective를 이용한 3D 갤러리 공간으로 전환하기도 함.

풀스택 개발로 확장하기

아키텍처

프론트엔드에서 얻은 Generator–Evaluator 구조를 전체 소프트웨어 개발에 적용함.

Opus 4.5에서는 Sonnet 4.5에서 나타났던 context anxiety가 크게 줄었기 때문에 context reset을 제거함.

• 전체 개발을 하나의 긴 세션으로 수행함.
• 컨텍스트 증가는 Claude Agent SDK의 automatic compaction에 맡김.

구조는 세 에이전트로 구성함.

Planner

• 사용자가 입력한 1~4문장의 요구사항을 전체 제품 명세로 확장함.
• 제품의 목적과 범위, 상위 수준 설계에 집중함.
• 초기에 세부 구현을 지나치게 지정하면 잘못된 결정이 이후 구현 전체에 전파될 수 있기 때문에 구체적인 구현 방법은 Generator에게 맡김.
• 가능하면 제품 안에 AI 기능을 자연스럽게 포함하도록 요구함.

Generator

• 제품 명세에서 기능을 가져와 구현함.
• 초기 버전에서는 sprint 단위로 개발함.
• React, Vite, FastAPI, SQLite/PostgreSQL 등을 사용함.
• Git으로 변경 사항을 관리함.
• sprint가 끝나면 QA에 넘기기 전에 먼저 자기 결과를 검토함.

Evaluator

• Playwright를 통해 실제 사용자처럼 애플리케이션을 조작함.
• UI뿐 아니라 API와 데이터베이스 상태까지 확인함.
• Product depth, Functionality, Visual design, Code quality 등의 기준으로 평가함.
• 기준 하나라도 임계점에 미달하면 sprint를 실패 처리하고 Generator에게 구체적인 피드백을 전달함.

Sprint Contract

코드를 작성하기 전 Generator와 Evaluator가 해당 sprint의 완료 조건을 협상함.

• Generator가 무엇을 만들 것인지와 검증 방법을 제안함.
• Evaluator가 명세와 일치하는지 검토함.
• 둘이 합의할 때까지 반복함.
• 에이전트 간 상태 전달은 파일을 통해 이루어짐.

실제 하네스 실행

Retro Game Maker를 만드는 동일한 프롬프트로 단일 에이전트와 전체 하네스를 비교함.

• Solo
  • 약 20분
  • 약 $9
• Full harness
  • 약 6시간
  • 약 $200

Full harness가 20배 이상 비쌌지만 결과 차이는 컸음.

Solo 결과는 겉보기에는 정상적인 에디터였지만:

• 화면 공간 사용이 비효율적이었고
• sprite → entity → level 순서를 사용자가 알아서 추론해야 했으며
• 가장 중요한 게임 실행 기능 자체가 제대로 연결되지 않았음.

Full harness에서는 Planner가 한 문장짜리 요구를 10개의 sprint와 16개 기능으로 확장함.

기본 에디터 외에도:

• sprite animation
• behavior template
• 음악과 효과음
• AI sprite 생성
• AI level design
• 게임 export와 공유 링크

등이 포함됨.

Planner에는 Anthropic의 frontend design skill도 제공해 제품 명세 안에 디자인 언어까지 포함하도록 함.

UI와 전체 완성도는 Solo보다 크게 향상됐지만, sprite와 entity를 먼저 만들어야 한다는 사용 흐름이 여전히 명확하지 않은 문제는 남았음. 이는 하네스보다는 기본 모델의 제품 설계 감각에서 비롯된 문제로 해석함.

AI 기능을 이용해 게임 요소를 자연어로 생성할 수 있어 실제 제작 과정도 빨라짐.

게임 플레이 자체도 동작했지만:

• 캐릭터가 플랫폼과 겹치는 physics 문제
• AI가 만든 벽을 넘을 수 없어 진행이 막히는 문제

등은 남아 있었음.

Evaluator는 매우 세부적인 계약까지 검증했음. 예를 들어 Sprint 3의 level editor만 27개의 검증 기준을 가짐.

실제로 다음과 같은 문제를 발견함.

• rectangle fill이 실제 영역 전체를 채우지 않는 문제
• entity 삭제 조건이 잘못된 문제
• FastAPI route 순서 때문에 reorder endpoint가 잘못 매칭되는 문제

다만 Claude를 QA agent로 만드는 것 자체도 별도의 튜닝이 필요했음.

초기 Evaluator는:

• 버그를 발견하고도 중요하지 않다고 스스로 합리화하거나
• 정상적인 happy path만 확인하고
• edge case를 충분히 탐색하지 않는

문제를 보임.

따라서 사람이 QA 로그를 확인하면서 사람의 판단과 다른 사례를 찾아 프롬프트를 계속 수정함.

튜닝 이후에도 작은 레이아웃 문제, 직관적이지 않은 interaction, 깊숙한 기능의 미발견 bug 등이 남아 있었기 때문에 QA 성능에도 추가 개선 여지가 있었음.

하네스를 다시 단순화하기

첫 번째 Full harness는 강력했지만 너무 복잡하고 느리고 비쌌음.

여기서 중요한 원칙이 등장함.

하네스의 각 구성 요소는 모델이 스스로 하지 못한다고 가정한 능력을 보완하기 위해 존재함.

따라서 모델이 발전하면 기존 하네스의 가정 역시 다시 검증해야 함.

Anthropic의 Building Effective Agents에서 이야기하는 것처럼 가능한 가장 단순한 방법에서 시작하고, 필요한 경우에만 복잡성을 추가하는 방향을 따름.

처음에는 하네스를 대폭 줄이고 새로운 구조를 한꺼번에 시도했지만 기존 성능을 재현하지 못함.

무엇이 실제 성능에 중요한지 파악하기도 어려웠기 때문에 이후에는 한 번에 하나의 구성 요소만 제거하면서 영향을 측정하는 방식으로 변경함.

마침 Opus 4.6이 등장함.

Opus 4.6은 이전보다:

• 계획 능력
• 장시간 agent 작업
• 대규모 코드베이스 처리
• 코드 리뷰
• 디버깅
• 긴 컨텍스트에서 필요한 정보 검색

등이 개선됨.

기존 하네스가 보완하던 능력 상당수가 모델 자체에 들어오기 시작한 셈임.

Sprint 구조 제거

가장 먼저 sprint 구조를 제거함.

Opus 4.6은 큰 작업을 스스로 장시간 유지할 수 있었기 때문에 인위적인 작업 분할의 필요성이 줄어듦.

Planner와 Evaluator는 유지함.

Planner를 제거하면 Generator가 바로 구현부터 시작하면서 제품 범위를 지나치게 작게 잡는 문제가 나타났음.

Evaluator는 sprint마다 실행하는 대신 전체 구현이 끝난 뒤 한 번 수행하는 방식으로 변경함.

여기서 중요한 사실이 드러남.

Evaluator가 항상 필요한 것은 아님.

• 모델이 이미 안정적으로 수행할 수 있는 영역에서는 Evaluator가 비용만 증가시킴.
• 반대로 모델 능력의 경계에 있는 문제에서는 여전히 큰 효과가 있음.

따라서 Evaluator의 필요성은 고정된 설계 선택이 아니라 현재 모델 능력과 문제 난이도의 상대적인 관계에 따라 결정해야 함.

또한 AI 기능을 추가하는 방식도 개선함.

단순히 Claude API를 호출하는 기능이 아니라, 애플리케이션 자체 기능을 tool로 사용해 작업할 수 있는 실제 agent를 만들도록 Generator에게 지시함.

관련 기술이 비교적 최신이어서 모델 학습 데이터가 충분하지 않았기 때문에 이 부분 역시 상당한 프롬프트 튜닝이 필요했음.

개선된 하네스의 결과

새 하네스를 검증하기 위해 Web Audio API 기반 DAW를 만들도록 함.

전체 결과:

• 총 약 3시간 50분
• 비용 약 $124.70

단계별로 보면 대부분의 시간과 비용은 Builder가 차지함.

특히 첫 Builder는 sprint 분해 없이도 2시간 이상 연속으로 작업함.

Planner는 한 문장의 요구를 전체 제품 명세로 확장했고, Generator는 앱뿐 아니라 내장 agent의 설계·연결·테스트까지 수행한 뒤 QA로 넘김.

그럼에도 QA는 중요한 누락을 발견함.

첫 번째 검증에서는:

• timeline에서 clip 이동 불가
• instrument UI 부족
• EQ 등 시각적인 effect editor 부족

등을 발견함.

두 번째 검증에서도:

• 실제 microphone recording 미구현
• clip resize 미구현
• clip split 미구현
• effect가 그래픽 UI가 아닌 숫자 slider 수준으로만 구현된 문제

등을 찾아냄.

즉 Opus 4.6에서도 Generator 혼자 작업하면 세부 기능을 빠뜨리거나 stub으로 남기는 문제가 있었고, 마지막 완성도를 높이는 과정에서는 Evaluator가 여전히 가치가 있었음.

최종 DAW는 전문적인 음악 제작 프로그램과 비교할 수준은 아니었음.

또한 Claude는 실제 소리를 들을 수 없기 때문에 음악적 취향이나 결과물의 청각적 품질을 QA하는 데 근본적인 한계가 있었음.

그럼에도:

• arrangement view
• mixer
• transport

등 핵심 기능이 실제로 동작함.

내장 agent 역시 tool을 이용해:

• tempo 설정
• key 설정
• melody 작성
• drum track 생성
• mixer level 조절
• reverb 추가

등을 수행해 간단한 음악을 처음부터 끝까지 만들 수 있었음.

앞으로의 방향

모델이 발전하면 더 긴 시간 동안 더 복잡한 문제를 해결할 수 있게 됨.

그 결과 기존 하네스의 일부 구성 요소는 더 이상 필요하지 않게 될 수 있음.

하지만 모델이 강해질수록 그 모델만으로는 해결하기 어려운 더 복잡한 문제를 대상으로 새로운 하네스를 만들 수 있는 공간 역시 커짐.

따라서 중요한 것은 특정 하네스 구조를 정답처럼 유지하는 것이 아님.

• 실제 문제를 모델에게 수행시켜 보고
• trace를 관찰하고
• 실패하는 지점을 찾고
• 필요한 부분만 하네스로 보완해야 함.

새로운 모델이 출시되면 기존 하네스도 다시 검토해야 함.

• 더 이상 필요하지 않은 구조는 제거하고
• 새로운 모델 능력을 활용할 수 있는 구조를 추가해야 함.

결국 모델이 발전한다고 하네스 설계가 사라지는 것은 아님.

좋은 하네스를 만들 수 있는 영역이 계속 이동할 뿐임.

AI 엔지니어에게 중요한 일은 현재 모델의 능력 경계를 파악하고, 그 경계를 넘어설 수 있는 다음 조합을 계속 찾아내는 것임.

원문

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