하네스 엔지니어링이 잘 되려면 — 앤쓰로픽 장시간 에이전트 글 종합 정리

이 글은 두 가지를 겹쳐 정리합니다.

Threads에서 돌던 하네스 엔지니어링 요약 스레드(cursormatfia)의 골자
공식 원문 Harness design for long-running application development(2026-03-24, Prithvi Rajasekaran)을 읽고 어떤 설계가 실제로 통했는지까지 이어 붙인 것

주장·구조는 원문을 우선합니다. 선행 글: Effective harnesses for long-running agents, Effective context engineering for AI agents.

하네스 엔지니어링이란 무엇인가

원문에서 다루는 범위를 한 줄로 잡으면 이렇습니다.

모델이 “한 번에 잘한다”에만 기대지 않고, 역할·도구·산출물·검증 루프를 설계해서 장시간·복잡한 작업에서도 품질과 일관성을 뽑아내는 일.

프롬프트만으로는 한계가 있었고, 그 위에 frontend-design 스킬·장시간 코딩 하네스 같은 시도가 있었지만 결국 천장이 있었다고 합니다. 돌파는 GAN에 영감을 받은 생성자(generator)·평가자(evaluator) 분리와, 이전 하네스에서 쓰던 작업 분해 + 세션 간 구조화된 인수인계를 풀스택 쪽으로 확장한 planner / generator / evaluator 삼각 구조로 이어집니다.

나이브한 구현이 망가지는 두 가지 이유

1) 컨텍스트가 차면 일관성이 무너진다 — 그리고 “컨텍스트 불안”

긴 작업에서는 맥락이 길어질수록 응집력이 떨어지고, 어떤 모델은 **맥락 한계에 가까워졌다고 느낄 때 일을 성급히 끝내려는 “context anxiety”**도 보였다고 합니다.

압축(compaction) 은 대화를 요약해 같은 에이전트가 이어가게 하는 방식인데, 연속성은 살아도 완전한 심리적 리셋은 아니어서 불안이 남을 수 있습니다.

컨텍스트 리셋은 창을 비우고 새 세션을 열되, 이전 상태·다음 단계가 담긴 구조화된 인수인계 산출물로 이어 받게 하는 방법입니다. 원문 실험에서는 Claude Sonnet 4.5에서 압축만으로는 부족했고 리셋이 필수에 가까웠다고 하며, 반면 Opus 4.5 쪽 실험에서는 불안이 줄어 리셋 없이 연속 세션 + 자동 압축으로도 갔다고 합니다.
→ 하네스는 모델·버전에 따라 “리셋이 필요한지”가 달라진다는 점이 중요합니다.

대가는 분명합니다. 오케스트레이션 복잡도, 토큰, 지연이 늘어납니다.

2) 자가 평가는 믿기 어렵다

자기가 만든 결과를 물으면 과하게 긍정하는 경향이 있고, 디자인처럼 이진 테스트가 없는 영역에서 더 두드러집니다. 검증 가능한 코드라도 판단이 흐려 구현을 망치는 경우가 있습니다.

대응은 일을 하는 에이전트와 채점하는 에이전트를 분리하는 것. 평가자도 LLM이라 관대해질 수 있지만, “의심 많은 평가자”를 따로 튜닝하는 것이 생성자를 자기비판적으로 만드는 것보다 훨씬 다루기 쉽다고 합니다. 외부 피드백이 생기면 생성자는 구체적인 반복 대상을 갖게 됩니다.

프론트엔드 실험에서 나온 “잘 되는” 패턴

주관적 품질을 채점 가능한 문장으로 바꿉니다. “예쁜가?” 대신 **“우리가 정한 원칙을 따르는가?”**처럼요.

원문에 나온 네 가지 기준(생성자·평가자 프롬프트 모두에 제공)은 대략 다음과 같습니다.

기준	한 줄 요약
Design quality	색·타이포·레이아웃 등이 한 덩어리의 무드·정체성으로 묶이는가
Originality	템플릿·라이브러리 기본값·뻔한 AI 패턴에 머무는가
Craft	계층·간격·대비 등 기술적 실행이 성실한가
Functionality	미적 요소와 별개로 과업 완수·주요 행동 발견이 되는가

Craft·Functionality는 기본적으로 모델이 잘하는 편이라, Design quality·Originality에 가중을 두어 안전한 범용 레이아웃에서 벗어나게 했다고 합니다.

추가로 원문이 강조하는 실무 포인트는 다음과 같습니다.

평가자 보정: 상세 점수 breakdown이 있는 few-shot 예시로 채점 기준을 내 취향에 맞춤
정적 스크린샷만이 아니라 Playwright MCP로 실제 페이지를 돌아다니며 평가
5~15회 정도 반복; 매 평가 뒤 방향 유지 vs 미학적 피벗을 생성자가 전략적으로 선택
기준 문구 자체가 출력을 의도치 않게 수렴시킬 수 있음(예: “museum quality” 같은 표현)
점수는 대체로 오르지만 항상 마지막이 최선은 아님; 복잡도는 라운드가 갈수록 늘 수 있음

네덜란드 미술관 사이트 예시에서는 9회차까지는 기대에 맞는 다크 랜딩이었다가, 10회차에 CSS 원근·벽 걸린 작품·문으로 방 이동하는 공간형 경험으로 갈아탄 사례가 나옵니다.

풀스택 하네스: 삼 에이전트와 “스프린트 계약”

생성–평가 루프를 코드 리뷰·QA에 대응시킨 구조입니다.

Planner: 사용자의 짧은 프롬프트(1~4문장)를 풀 스펙으로 확장. 범위는 야심 있게, 다만 초기에 구현 세부를 과하게 찍으면 틀린 전제가 아래로 전파되므로 제품 맥락·상위 기술 설계에 머무르도록 했다고 합니다. 필요 시 스펙에 AI 기능을 녹이도록 요청.
Generator: 스펙에서 한 번에 한 기능(스프린트 단위). React·Vite·FastAPI·DB 스택, git 사용. 스프린트 끝에 자기 점검 후 QA(평가자)로 인계.
Evaluator(QA): Playwright로 실제 앱을 사용자처럼 클릭·API·DB까지 확인. 제품 깊이·기능·비주얼·코드 품질 등 기준을 프론트 실험과 비슷한 철학으로 두고, 기준마다 하드 threshold — 하나라도 미달이면 스프린트 실패, 생성자에게 구체 피드백.

특히 하네스를 견고하게 만든 장치가 스프린트 계약(sprint contract) 입니다.

스펙은 의도적으로 고수준이므로, 코드를 쓰기 전에 생성자가 “이번에 무엇을 만들고 성공을 어떻게 검증할지”를 제안하고, 평가자가 올바른 것을 만들고 있는지 검토해 합의할 때까지 왕복합니다.

에이전트 간 소통은 파일로: 한쪽이 파일을 쓰면 다른 쪽이 읽고 같은 파일 또는 새 파일로 답합니다. 이렇게 해서 스펙에 충실하면서도 이른 구현 세부 고정을 피한다고 합니다.

비용·품질 트레이드오프(원문 수치)

같은 한 줄 프롬프트(레트로 게임 메이커)로 비교했을 때, 단일 에이전트는 대략 20분·약 $9, 풀 하네스는 약 6시간·약 $200 — 20배 이상 비쌌지만 체감 품질 차이는 크다고 합니다. 플레이 모드가 실제로 동작하는지 등 핵심 기능 완성도에서 차이가 났다는 서술입니다.

QA 에이전트도 튜닝이 필요하다

기본 상태의 Claude는 QA에 약하다고 직설합니다. 실제 이슈를 찾아놓고 스스로 “별일 아니다”라며 통과시키거나, 표면만 테스트하는 경향을 로그로 잡고 QA 프롬프트를 고치는 루프를 여러 번 돌렸다고 합니다.

모델이 좋아지면 하네스는 어떻게 바뀌나

원문의 중요한 원칙입니다.

하네스의 각 구성요소는 “모델이 스스로 못 한다”는 가정을 코드화한 것이고, 그 가정은 틀릴 수도 있고 모델이 나오면 낡을 수도 있습니다. 그래서 Building Effective Agents 에 맞춰 가능한 한 단순하게 시작하고, 필요할 때만 복잡도를 올리되, 한 번에 다 갈아엎기보다 한 덩어리씩 제거해 무엇이 하중을 받는지 보라고 합니다.

Opus 4.6 이후 실험에서는 스프린트 구조 전체를 제거해 봤습니다. Planner·Evaluator는 가치가 분명해 남겼고, 스프린트 없이도 빌더가 오래 일관되게 돌아갔다고 합니다. 평가자는 빌드 끝 한 번만 도는 식으로 바꾸기도 했습니다.

실용적 결론: 평가자는 항상 켜두는 고정 비용이 아니다. 현재 모델이 단독으로 안정적으로 못 하는 난이도에 걸친 작업일수록 비용 대비 이득이 크고, 이미 모델이 혼자 잘하는 구간에서는 오버헤드에 가깝다는 뜻입니다.

한눈에: 하네스 엔지니어링이 “잘” 되려면

원문과 실험 서술을 합쳐 체크리스트로 쓸 수 있는 정리입니다.

실패 모드를 먼저 이름 붙인다
맥락 포화·불안인지, 자가평가 편향인지, 스펙 전파 오류인지. 대응이 다릅니다.
생성과 평가의 책임을 나눈다
같은 머리가 채점까지 하면 관대해지기 쉽습니다. 평가자는 의심·구체적 근거 쪽으로 튜닝합니다.
주관을 “채점 루브릭”으로 깬다
모호한 찬사 대신 항목·설명·가중치. 모델이 이미 잘하는 항목과 약한 항목을 나눠 가중합니다.
가능하면 환경 안에서 검증한다
스크린샷 한 장보다 브라우저·API·DB처럼 실제와 가까운 도구(원문은 Playwright MCP)가 유리합니다.
작업을 씹을 수 있는 단위로 나누고, 인수인계 산출물을 만든다
한 번에 올인보다 기능 단위·스프린트(또는 모델이 버티면 그보다 큰 덩어리). 세션을 바꿀 때는 상태와 다음 액션이 다음 에이전트에게 충분히 전달되게 합니다.
“코드 쓰기 전 계약”으로 스펙과 구현 사이를 잇는다
고수준 스펙만으로는 완료 정의가 흐릿합니다. 무엇을 만들고 어떻게 검증할지를 생성자·평가자가 합의한 뒤 구현합니다.
에이전트 간 비동기 협업에는 파일이 단순하다
채팅 한 줄씩보다 읽고 쓰는 공유 산출물이 맥락을 고정합니다.
모델이 바뀔 때마다 하네스를 다시 스트레스 테스트한다
복잡도는 필요할 때만 유지하고, 더 이상 짐이 아닌 부품은 제거합니다. 흥미로운 조합의 공간은 줄지 않고 이동한다는 말로 글을 맺습니다.
현실적인 기대와 비용
반복·도구 호출·긴 QA는 벽시계 시간과 비용이 큽니다. “항상 풀 하네스”가 정답은 아니고, 난이도 대비 이득을 보며 켜고 끕니다.

컨텍스트 엔지니어링 vs 하네스 (짧게)

컨텍스트 엔지니어링: 무엇을 넣고, 어떻게 요약·전달할지 — 맥락의 내용과 형태.
하네스: 역할 분리, 도구, 루프, 인수인계, 계약, (필요 시) 리셋 — 에이전트가 시간을 넘겨 일하게 만드는 시스템.

겹치는 부분도 많고, 원문도 서로 링크합니다. 실무에서는 둘 다 손대는 경우가 많습니다.

사람이 스레드에서 강조했던 두 가지 (여전히 맞는 말)

내가 원하는 바를 정확히 말할 것
작업을 적절한 단위로 쪼갤 것

원문은 여기에 검증 루프·역할 분리·모델 버전에 맞는 단순화까지 얹어 줍니다.

원문·관련 링크

Harness design for long-running application development — Anthropic Engineering, 2026-03-24
Effective harnesses for long-running agents
Effective context engineering for AI agents
Building Effective Agents
Claude Agent SDK
frontend-design skill (Claude Code 플러그인)

읽어 주셔서 감사합니다.