목차
이 글은 Anthropic 엔지니어링 블로그에 2026년 3월 24일 게재된 “Harness design for long-running application development” 를 읽고, 내용을 정리한 글입니다. 원문: https://www.anthropic.com/engineering/harness-design-long-running-apps
한 줄로 말하면 #
한 명의 에이전트가 자기 일을 평가하면 다 잘했다고 한다. 생성자와 평가자를 따로 두니 진짜 앱이 나왔다.
어떤 문제를 해결하려 했나 #
#15(Effective harnesses)에서 봤듯, 장기 작업엔 인수인계 구조가 필요합니다. 그런데 거기엔 또 하나의 함정이 있었어요.
에이전트에게 “네가 만든 거 점검해줘” → “잘 만들었어요. 완벽합니다.” (실제로는 절반 망가짐)
원문 인용: “에이전트는 자기 작업을 자신 있게 칭찬하는 경향이 있다 — 명백히 평범한 품질일 때도.”
자기 평가는 못 합니다. 그래서 이 글은 GAN(생성 적대 신경망)에서 영감 받은 Planner-Generator-Evaluator 3에이전트 구조를 제안합니다.
해결책: 세 에이전트 + 스프린트 계약 #
1. 세 에이전트의 역할 #
| 에이전트 | 하는 일 | 만들지 말아야 할 것 |
|---|---|---|
| Planner(기획자) | 짧은 요청 → 상세 제품 스펙 변환 | 너무 세부적인 구현 디테일 (밑단에 오류 전파) |
| Generator(생성자) | 기능을 단계적으로 구현. Opus 4.6은 2시간 이상 일관성 유지 가능 | 자기 코드 자가 평가 |
| Evaluator(평가자) | Playwright MCP로 실제 사용자처럼 앱을 만져보며 검증 | 구현에 끼어들기 |
핵심 패턴: “스프린트 계약” — 구현 시작 전에 성공 기준을 평가자가 명시합니다. 그래야 나중에 “다 됐다고 칭찬해줘"가 안 통해요.
2. 상태 관리 — 파일 기반 통신 #
세 에이전트가 같은 컨텍스트를 공유하지 않습니다. 대신 파일로 소통해요.
specs/feature-x.md ← Planner가 작성
contracts/sprint-1.md ← Evaluator가 작성 (성공 기준)
implementations/... ← Generator가 작성
feedback/sprint-1.md ← Evaluator가 검증 후 작성다음 에이전트는 그 파일을 읽고 다음 단계를 진행합니다. 컨텍스트는 가볍게 유지하면서 인수인계는 명확해요.
3. 모델이 바뀌면 하네스도 바뀐다 #
흥미로운 발견: Sonnet 4.5에는 ‘context anxiety’ 가 있어 도중에 일을 일찍 마무리하려 합니다. 그래서 스프린트로 잘게 쪼개야 했어요. 그런데 Opus 4.6에는 그 행동이 거의 없어, 스프린트 구조를 빼는 게 더 잘 동작했습니다.
원문 인용: “하네스는 모델이 발전하면서 정기적으로 재검토해야 한다. 한 번 만든 디자인을 박제하면 곧 비효율이 된다.”
결과 / 효과 #
| 비교 | 시간 | 비용 | 결과물 |
|---|---|---|---|
| 단독 에이전트 (retro game maker) | 20분 | $9 | 입력에 반응 안 하는 비기능 게임 |
| 풀 하네스 (Planner+Gen+Eval) | 6시간 | $200 | 스프라이트 에디터, 애니메이션, 사운드, AI 레벨 생성까지 동작하는 게임 |
추가 예시: 브라우저 기반 디지털 오디오 워크스테이션(DAW). 평가자가 잡아낸 누락 — 오디오 녹음 스텁, 클립 리사이즈 미구현, 그래픽 이펙트 시각화 없음.
“좋은 디자인인가?” 같은 주관적 질문을 평가자가 다룰 수 있게 한 비결: 채점 원칙(디자인 품질, 독창성, 완성도, 기능성)을 명시해 “이게 아름다운가?” 를 “우리 원칙을 따르는가?” 로 변환.
핵심 결론 #
긴 작업을 자율 에이전트로 끝까지 가게 하려 할 때 사람들은 본능적으로 “더 똑똑한 단일 에이전트"를 떠올립니다. 이 글의 답은 다릅니다.
“품질이 모델 능력인 줄 알았는데, 사실은 자기 평가의 무능이 문제였다.”
생성자와 평가자를 분리하고, 구현 전에 성공 기준을 적어두고, 모델 발전에 따라 하네스 자체를 재검토하는 것 — 이 세 가지가 6시간짜리 앱을 가능하게 했습니다.
내 작업에 적용한다면 #
시나리오 1 — 일반적인 데이터 분석 과정 #
분석에서도 같은 패턴이 강력합니다. 분석가가 자기 분석을 검증하면 거의 항상 통과시킵니다.
[Before — 한 에이전트가 분석·검증 다]
"이 데이터 분석하고 결과 검토해줘"
→ "분석 잘 됐어요" (실은 데이터 누수 있음)
[Planner-Generator-Evaluator 적용]
[Planner]
- 분석 질문 → 상세 분석 계획서 작성
- "어떤 가설, 어떤 검증 절차, 어떤 결과 기준" 명시
[Generator]
- 계획에 따라 실제 분석 수행
- 자기 결과를 평가하지 않음
[Evaluator]
- 별도 에이전트가 결과 검토
- 사전에 합의된 기준 (데이터 누수 체크, 통계 검정 적절성 등)으로 점수화
- 통과 못하면 Generator에게 피드백 전달핵심: 분석 자동화의 신뢰성은 “생성자와 평가자 분리” 에서 옵니다. 자가 평가는 거의 항상 후하게 나옵니다.
시나리오 2 — 웹 사이트를 자동으로 운영할 때 #
자동 콘텐츠 생성·발행에도 같은 구조를 적용할 수 있습니다.
[Before — 한 에이전트가 작성·검수]
"글 쓰고, 본인이 검수도 해줘"
→ "잘 썼어요" (실은 톤 어긋남)
[3-agent 적용]
[Planner]
- 콘텐츠 기획 → 상세 스펙 (주제, 톤, 길이, 키워드, 인용 출처)
[Generator]
- 스펙에 따라 글 작성
[Evaluator]
- 다른 에이전트가 발행 전 검수
- 사전 합의된 기준 (톤 가이드, SEO, 사실관계, 법적 리스크) 적용
- 통과 못하면 피드백 전달, 재작성
[파일 기반 통신]
- specs/, drafts/, feedback/, published/ 디렉토리로 단계 분리핵심: 자동 운영의 품질은 “같은 모델이라도 다른 역할로 분리되어 일하는 구조” 에서 옵니다. 그리고 모델이 바뀌면 이 구조도 재검토하세요.
Anthropic 엔지니어링 블로그를 오래된 순서대로 읽고 정리합니다.
