Anthropic 하네스 설계 번역 요약: 장기 실행 앱 개발에서 평가자 에이전트가 중요한 이유

한눈에 보기

• 공개 시점: Anthropic Engineering, 2026년 3월 24일
• 핵심 주장: frontier agentic coding의 성능은 모델만이 아니라 harness design이 크게 좌우
• 가장 중요한 구조: planner -> generator -> evaluator 3단 분리와 반복 피드백
• 프런트엔드 실험: 미적 품질도 기준을 잘게 쪼개면 반복 개선이 가능
• 장기 실행 코딩 실험: context reset, sprint contract, Playwright QA가 완성도 차이를 만듦
• 실무 결론: 모델이 좋아질수록 하네스는 무작정 더 복잡해지는 것이 아니라 필요한 부분만 남기는 방향으로 다시 설계돼야 함

서론

2026년 3월 24일, Anthropic Engineering은 Harness design for long-running application development라는 글을 공개했다. 작성자는 Labs 팀의 Prithvi Rajasekaran이며, 주제는 단순한 프롬프트 팁이 아니다. Claude가 몇 시간 동안 프런트엔드를 만들고, 더 나아가 사람 개입 없이 꽤 완성도 높은 애플리케이션을 짓게 하려면 어떤 하네스가 필요한지에 대한 실험 보고서에 가깝다.

이 글이 중요한 이유는 두 가지다. 하나는 AI 코딩이 길어질수록 모델이 어디서 무너지는지 꽤 솔직하게 보여 준다는 점이고, 다른 하나는 그 약점을 단순히 "모델이 더 좋아지면 해결될 문제"로 넘기지 않고 실제 구조를 바꿔 해결하려 한다는 점이다. 이번 글은 원문 전체를 줄줄 옮기는 방식보다, 핵심 문장을 한국어로 풀어 번역하고 실무자가 바로 이해할 수 있게 구조를 다시 짠 요약본이다.

1. 원문 핵심 번역: Anthropic가 실제로 말한 것

원문을 아주 짧게 옮기면 메시지는 아래로 압축된다.

• 출발 문제: Claude는 프런트엔드 디자인과 장기 실행 코딩에서 기본값만으로는 어느 지점부터 품질이 평범해지거나 흐트러짐
• 첫 번째 해결책: 긴 작업은 작은 덩어리로 쪼개고, 세션이 바뀌어도 이어서 일할 수 있게 구조화된 산출물을 남겨야 함
• 두 번째 해결책: 만든 사람과 채점하는 사람을 분리해야 자기 관대함을 줄일 수 있음
• 디자인 실험 결론: "예쁜가"처럼 추상적인 질문도 디자인 품질, 독창성, 완성도, 기능성처럼 구체 기준으로 바꾸면 개선 가능
• 코딩 실험 결론: 최종적으로는 planner, generator, evaluator의 3개 에이전트가 몇 시간짜리 전체 앱 빌드를 더 잘 수행
• 더 큰 교훈: 새 모델이 나오면 하네스는 더 쌓는 것이 아니라, 이제 필요 없어진 발판을 걷어내며 다시 설계해야 함

여기서 Anthropic가 끌어온 발상은 GAN처럼 생성자와 평가자를 분리하는 접근이다. 물론 이 글이 이미지 생성 모델 논문을 그대로 옮긴 것은 아니지만, "생성자와 비평가를 따로 두면 더 나은 피드백 루프를 만들 수 있다"는 감각은 분명히 닮아 있다. 이 글의 중심 문장도 결국 거기에 닿는다. 좋은 모델과 좋은 하네스는 별개이며, 모델이 똑똑해져도 긴 작업, 주관적 평가, 자기검열, 품질 검증 문제는 저절로 사라지지 않는다.

이번 글의 핵심은 에이전트를 많이 쓰는 데 있지 않다. 어떤 역할을 planner, generator, evaluator로 나눌 때 결과 품질이 가장 크게 오르는지를 찾는 데 있다

2. 왜 순진한 단일 에이전트 방식은 자꾸 무너지나

Anthropic는 이번 글에서 긴 작업을 망치는 대표 실패 패턴을 두 가지로 정리했다.

• 맥락 붕괴: 작업이 길어질수록 컨텍스트 창이 차고, 모델이 앞뒤 흐름을 놓치기 쉬운 문제
• 조기 종료 성향: 컨텍스트 한계가 다가온다고 느끼면 스스로 일을 서둘러 마무리하려는 context anxiety
• 자기 채점 관대함: 스스로 만든 결과를 스스로 평가하게 하면, 사람이 보기엔 평범한 결과도 좋다고 쉽게 통과시킴
• 주관적 과업의 어려움: 디자인처럼 정답이 없는 문제에서는 이런 관대함이 더 심하게 나타남

여기서 Anthropic가 강조한 포인트는 compaction만으로는 충분하지 않을 수 있다는 점이다. 이전 2025년 글 Effective harnesses for long-running agents에서는 새 세션으로 넘어갈 때 구조화된 산출물을 남기는 방식이 중요하다고 설명했다. 이번 글은 그다음 단계로 나아가, 아예 작업 에이전트와 평가 에이전트를 분리하는 편이 더 강한 레버가 된다고 본다.

문제	원문에서 관찰한 현상	Anthropic가 제시한 해결책	실무 해석
긴 컨텍스트	작업 흐름이 길어질수록 일관성 약화	작업 쪼개기, handoff artifact, 필요 시 context reset	긴 실행은 메모리 관리가 설계 문제라는 뜻
조기 마무리	아직 덜 끝났는데 "거의 됐다"고 결론	다음 세션이 이어받을 명확한 상태 기록	진행률 보고와 실제 완료를 분리해야 함
자기 평가 관대함	생성자가 자기 결과를 쉽게 칭찬	evaluator를 독립시켜 비판적 피드백 부여	QA를 생성 단계 밖으로 빼는 구조 필요
디자인 품질 저하	안전하지만 밋밋한 기본 레이아웃 반복	미적 기준을 점수화 가능한 rubric으로 전환	주관적 품질도 운영 기준으로 바꿀 수 있음

이 표가 중요한 이유는 문제를 "모델 능력 부족"으로만 보지 않게 만들기 때문이다. Anthropic는 긴 작업이 흔들리는 이유를 메모리, 역할 분리, 검증 구조의 문제로 다시 설명한다. 즉 프롬프트를 더 세게 쓰는 것보다, 어떤 상태를 남기고 누가 무엇을 평가할지를 먼저 정하는 편이 더 효과적일 수 있다.

3. 프런트엔드 디자인 실험: 미적 품질도 점수화할 수 있을까

Prithvi Rajasekaran은 먼저 프런트엔드 디자인에서 evaluator 루프를 시험했다. 이유는 명확하다. 기본 상태의 Claude는 기능은 맞지만 시각적으로는 안전하고 평범한 결과에 자주 머문다는 것이다.

Anthropic가 generator와 evaluator 모두에게 준 기준은 네 가지였다.

• 디자인 품질: 색, 타이포, 레이아웃, 이미지가 하나의 분위기로 묶이는가
• 독창성: 템플릿과 라이브러리 기본값을 벗어난 의도적 선택이 보이는가
• 완성도: 간격, 대비, 타이포 계층, 색 조합 같은 기본기가 무너지지 않는가
• 기능성: 보기 좋기만 한 화면이 아니라 실제 사용 흐름이 자연스러운가

여기서 흥미로운 대목은 디자인 품질과 독창성의 가중치를 더 높였다는 점이다. Anthropic는 Claude가 기본적으로 완성도와 기능성은 어느 정도 맞출 수 있다고 봤다. 문제는 그 결과가 너무 자주 익숙한 카드 레이아웃, 안전한 흰 배경, 흔한 그라디언트로 흐른다는 것이다. 그래서 evaluator는 흔한 AI 스타일을 더 강하게 감점하는 방향으로 조정됐다.

"예쁜가"를 직접 묻기보다, 어떤 기준에서 왜 좋은지 나눠 묻는 편이 에이전트에게 훨씬 더 잘 먹힌다는 것이 프런트엔드 실험의 핵심이다

실험 흐름도 꽤 구체적이었다.

• 생성 단계: generator가 HTML, CSS, JavaScript 기반 프런트엔드 생성
• 검증 단계: evaluator가 Playwright MCP로 실제 페이지를 돌아다니며 화면을 살핌
• 피드백 단계: 항목별 점수와 비판을 generator에게 돌려줌
• 전략 분기: generator는 현재 방향을 다듬을지, 아예 다른 미감으로 갈지 스스로 선택
• 반복 횟수: 보통 5회에서 15회, 전체 실행 시간은 길게는 약 4시간

원문에서 특히 인상적인 사례는 네덜란드 미술관 웹사이트 실험이다. 초기 결과물은 충분히 깔끔했지만 예상 가능한 어두운 랜딩 페이지에 가까웠다. 그런데 10번째 사이클에서는 그 접근을 버리고, CSS 원근과 방 구조를 활용해 갤러리 방을 이동하는 듯한 3D 공간형 인터페이스로 방향을 틀었다. Anthropic는 이 지점을 단순한 수정이 아니라, 단일 패스 생성에서 보기 힘들었던 창의적 도약으로 본다.

이 대목은 한국 실무자에게도 꽤 중요하다. 디자인 QA를 사람이 전부 손으로 하던 조직이라면, 앞으로는 디자인 원칙을 채점 가능한 문장으로 바꿔 evaluator에게 맡기는 구조를 먼저 실험해 볼 수 있기 때문이다.

4. 장기 실행 앱 개발로 가면 planner, generator, evaluator는 이렇게 나뉜다

프런트엔드에서 통했던 generator-evaluator 패턴은 풀스택 앱 개발로 그대로 확장됐다. 이번에는 planner가 추가되면서 3개 에이전트 구조가 만들어졌다.

• planner: 1~4문장짜리 짧은 사용자 요청을 더 긴 제품 명세로 확장
• generator: 명세를 바탕으로 한 번에 전부 만들지 않고, 기능 단위로 구현을 진행
• evaluator: Playwright로 UI를 실제로 눌러 보고, API와 데이터베이스 상태까지 확인하며 QA 수행

Anthropic가 planner를 따로 둔 이유도 설득력이 있다. 사용자가 처음부터 매우 자세한 명세를 줄 것이라고 가정하지 않았기 때문이다. 대신 planner는 제품 맥락과 높은 수준의 기술 설계를 잡되, 너무 이른 시점에 세세한 구현을 못박아 downstream 오류를 퍼뜨리지 않도록 조정됐다. 쉽게 말해 "무엇을 만들지"는 넓게 적고, "정확히 어떻게 만들지"는 generator와 evaluator가 협상하게 만든 셈이다.

초기 하네스에서는 sprint 개념도 들어갔다.

• sprint 계약: generator와 evaluator가 먼저 이번 라운드에서 무엇을 만들고 무엇이 완료 기준인지 합의
• 파일 기반 소통: 한 에이전트가 파일을 쓰면 다른 에이전트가 읽고 응답
• 스택: React, Vite, FastAPI, SQLite에서 시작해 이후 PostgreSQL까지 확장
• 검증 범위: UI 클릭, API 엔드포인트, 데이터 상태, 시각 품질, 코드 품질

여기서 실제 성능 차이는 꽤 컸다. Anthropic는 같은 한 줄 프롬프트로 2D 레트로 게임 메이커를 만들어 보며 단일 에이전트와 풀 하네스를 비교했다.

구분	단일 에이전트 실행	1차 풀 하네스 실행	읽어야 할 포인트
시작 프롬프트	같은 한 줄 프롬프트	같은 한 줄 프롬프트	입력은 같고 구조만 달랐음
실행 시간	약 20분	약 6시간	긴 시간과 비용을 성능으로 바꾼 실험
토큰 비용	약 9달러	약 200달러	품질 향상은 공짜가 아님
명세 확장	거의 없음	16개 기능, 10개 sprint로 확장	planner가 범위를 넓혀 줌
결과물 상태	플레이 모드 핵심 기능이 깨짐	실제로 캐릭터를 움직이며 플레이 가능	evaluator가 마지막 마일 오류를 잡아냄

원문에서 단일 에이전트 결과물은 겉보기엔 그럴듯했지만 핵심 게임 루프가 망가져 있었다. 반면 풀 하네스 결과물은 여전히 투박한 부분이 남아 있었어도, 실제로 레벨 편집과 플레이가 가능했다. 이 차이는 "더 많은 기능을 넣었다"보다 "핵심 기능이 실제로 동작했다"는 데 있다.

Anthropic가 말하고 싶은 핵심은 비용이 늘었다는 사실 자체가 아니라, 어디까지가 단일 실행으로 가능한 범위이고 어디부터 evaluator가 실제 가치를 내는 경계선인지다

5. Opus 4.6에서는 왜 하네스가 오히려 단순해졌나

이번 글에서 가장 실무적인 교훈은 여기에 있다. 새 모델이 나오면 하네스는 더 커지는 것이 아니라, 이제 없어도 되는 구성요소를 걷어내며 다시 균형을 잡아야 한다는 점이다.

Anthropic는 2025년 하네스에서 중요했던 context reset과 sprint 분해를 Opus 4.6 기반의 업데이트 버전에서는 상당 부분 제거했다. 이유는 4.6이 더 오래 coherent하게 달리고, 더 큰 코드베이스에서도 안정적으로 버티며, 스스로 검토하는 능력도 좋아졌기 때문이다. 그래서 4.5에서 필수였던 발판이 4.6에서는 과한 오버헤드가 될 수 있었다.

업데이트 버전의 핵심 변화는 아래와 같다.

• sprint 제거: 중간 sprint 구조 없이도 2시간 이상 비교적 일관되게 빌드 가능
• context reset 제거: 자동 compaction만으로도 긴 실행을 이어갈 수 있는 수준으로 개선
• evaluator 역할 재조정: 매 sprint 채점이 아니라, 전체 빌드 끝단에서 QA 라운드를 돌리는 방향으로 단순화
• planner 유지: raw prompt만 주면 범위가 좁아지는 문제는 여전히 남아 있어서 planner는 계속 필요
• evaluator 재해석: 항상 필요한 존재가 아니라, 현재 모델이 혼자 안정적으로 못 넘는 경계 바깥의 작업에서 비용 값을 함

Anthropic는 이 업데이트 하네스로 브라우저 기반 DAW, 즉 디지털 오디오 워크스테이션도 실험했다.

• 총 실행 시간: 약 3시간 50분
• 총 비용: 약 124.70달러
• 1차 QA에서 걸린 문제: 클립 드래그, 악기 패널, 이펙트 시각화처럼 핵심 인터랙션의 빈약함
• 2차 QA에서 다시 걸린 문제: 오디오 녹음이 실동작하지 않음, 클립 분할 미구현, EQ 곡선 부재

이 실험이 말하는 바는 꽤 현실적이다. 생성자는 이제 꽤 긴 시간 동안 앱을 밀고 나갈 수 있다. 하지만 여전히 세부 기능을 건너뛰거나, 겉만 만든 뒤 핵심 상호작용을 비워 두는 경향은 남는다. 그래서 evaluator는 "전체를 계속 감시하는 경찰"이라기보다, 마지막 20퍼센트의 디테일을 잡아내는 비싼 QA 장치로 보는 편이 더 정확하다.

6. 실무자가 바로 가져갈 수 있는 교훈

Anthropic 글을 한국 개발팀 관점에서 다시 읽으면, 당장 쓸 만한 교훈은 다섯 가지로 정리된다.

• 역할 분리: 생성과 평가를 같은 에이전트에게 동시에 맡기지 말 것
• 완료 기준 문서화: 코드를 쓰기 전에 evaluator와 generator가 "이번 라운드의 done"을 합의하게 만들 것
• 긴 작업의 상태 보존: 세션을 넘길 때는 대화 요약보다 파일 기반 산출물이 더 강한 경우가 많음
• 주관적 품질의 운영화: 디자인, UX, 글 품질 같은 영역도 rubric으로 쪼개면 자동 평가가 가능
• 모델 업그레이드 후 재설계: 새 모델이 나오면 하네스를 덧대기보다, 어떤 구성요소가 아직도 load-bearing인지 다시 검증할 것

이 다섯 가지는 AI 코딩 도구를 이미 쓰는 팀일수록 더 중요하다. 많은 조직이 지금은 "좋은 프롬프트를 많이 모아 두는 단계"에 머물러 있지만, 긴 작업으로 넘어가면 병목은 프롬프트보다 운영 구조에서 더 자주 생긴다. 누가 범위를 잡고, 누가 구현하고, 누가 검증하는지 구분되지 않으면 결과는 빠르게 흔들린다.

Anthropic가 2024년 Building effective agents에서 강조했던 "가장 단순한 해법에서 시작하고 필요할 때만 복잡성을 올려라"는 원칙도 이번 글에서 그대로 이어진다. 이번 포스트는 복잡한 하네스를 자랑하는 글이 아니라, 복잡성이 진짜로 값을 만드는 순간만 남겨 보려는 과정을 기록한 글로 읽는 편이 맞다.

7. 한국 시장에서는 어떻게 봐야 하나

한국에서도 이 글은 꽤 빠르게 실험 대상이 될 가능성이 크다.

• SaaS 팀: 회원가입, 결제, 관리자 화면처럼 긴 사용자 플로우를 evaluator 기반 QA로 묶기 쉬움
• 내부 플랫폼 팀: 사내 도구 생성과 점검을 planner, generator, evaluator 구조로 분리하기 좋음
• 게임 툴링 팀: 레벨 에디터, 자산 생성기, 운영 툴처럼 긴 UI 작업에서 harness 효용이 큼
• 디자인 조직: 컴포넌트 조합이 아니라 브랜드 감도까지 포함한 rubric 설계 수요가 커질 수 있음

같이 볼 국내 회사도 역할 중심으로 보면 더 잘 읽힌다. 아래는 공개된 도입 사실을 단정하는 목록이 아니라, 이런 하네스 설계가 특히 의미 있어질 법한 국내 기업 유형 예시다.

• 네이버클라우드: 기업용 개발 플랫폼과 사내 도구 자동화 관점
• 비바리퍼블리카, 토스: 복잡한 금융 UX와 품질 검증 자동화 관점
• 크래프톤: 제작 도구, 콘텐츠 워크플로, AI 보조 툴링 관점
• 엔씨소프트: 라이브 서비스 운영 툴과 게임 UI, 시스템 제작 관점

한국 시장에서 특히 눈여겨볼 부분은 비용 대비 성능 경계선이다. Anthropic 실험처럼 4시간 가까이 돌리고 100달러가 넘는 하네스는 모든 팀에 바로 맞지 않는다. 다만 사람이 직접 수동 QA를 반복하거나, 엉성한 결과물을 고치느라 며칠을 쓰는 팀이라면 이야기가 달라질 수 있다. 결국 핵심은 "에이전트를 몇 개 쓰느냐"가 아니라, 어떤 문제에서 evaluator가 사람 시간을 진짜로 줄여 주느냐다.

결론

Anthropic의 2026년 3월 24일 글은 AI 코딩의 미래를 과장해서 말하지 않는다. 대신 꽤 현실적인 사실을 보여 준다. 긴 작업에서는 모델 하나를 오래 붙잡는 것만으로는 품질이 잘 안 오른다. 범위를 설계하는 planner, 구현을 밀어붙이는 generator, 냉정하게 오류를 잡는 evaluator가 서로 다른 역할을 맡을 때 결과가 좋아진다.

동시에 이 글은 멀티 에이전트 만능론도 아니다. Opus 4.6이 나오자 Anthropic는 오히려 sprint와 context reset 같은 일부 장치를 걷어냈다. 이 태도가 중요하다. 하네스 설계는 고정된 교과서가 아니라, 현재 모델이 어디까지 혼자 잘하고 어디서부터 외부 구조가 필요한지 계속 다시 재는 작업에 가깝다.

한 줄로 요약하면 이렇다. AI 코딩의 성능을 끌어올리는 것은 모델 업그레이드만이 아니다. 어떤 상태를 남기고, 누가 판단하고, 언제 QA를 끼워 넣는지 정하는 하네스 설계가 생각보다 더 큰 차이를 만든다.

참고 자료

• Harness design for long-running application development - Anthropic Engineering, 2026년 3월 24일
• Effective harnesses for long-running agents - Anthropic Engineering, 2025년 11월 26일
• Effective context engineering for AI agents - Anthropic Engineering, 2025년 9월 29일
• Building agents with the Claude Agent SDK - Anthropic Engineering, 2025년 9월 29일
• Building effective agents - Anthropic Research, 2024년 12월 19일