사례: Anthropic

Anthropic 사례는 하네스를 "역할을 많이 두는 법"으로 보지 않습니다. 핵심 질문은 오히려 이겁니다.

어떤 scaffolding이 실제로 품질을 떠받치고 있는가?

이게 중요한 건 장시간 작업의 실패가 대개 모델 지능 부족이 아니라 스코프 과소추정, 자기평가 편향, 부실한 handoff에서 나오기 때문입니다.

2026년 3~5월 업데이트로 추가된 관점

Anthropic 사례는 이제 planner/evaluator만으로 읽으면 부족합니다. 2026년 3월 25일 Claude Code auto mode와 4월 8일 Managed Agents 글이 하네스를 다음 세 경계로 넓혔습니다.

그래서 Anthropic의 최신 흐름은 "역할을 나눠라"보다 넓습니다. 역할, 실행 환경, 세션 로그, credential, 승인 정책을 서로 다른 실패 경계로 분리하라에 가깝습니다.

해결하려는 문제

• builder가 너무 빨리 "끝났다"고 판단함
• 작업이 길어질수록 목표와 현재 상태가 어긋남
• 브라우저 검증 전에 구현이 완료 처리됨
• 역할이 많아도 실제 load-bearing 단계가 불명확함

기술적 메커니즘

Anthropic식 하네스에서 중요한 건 역할 이름이 아니라 각 단계가 입력도 판정 기준도 다르다는 점입니다.

Managed Agents: brain, hands, session을 분리한다

Managed Agents 글에서 곧장 가져올 점은 agent를 하나의 긴 프로세스로 보지 않는다는 것입니다.

핵심 인터페이스는 단순합니다.

type Hand = {
  execute(name: string, input: unknown): Promise<string>
}

type SessionStore = {
  getSession(id: string): Promise<Event[]>
  emitEvent(id: string, event: Event): Promise<void>
}

이렇게 나누면 실무에서 세 가지를 얻습니다.

• sandbox나 container가 죽어도 harness는 실패를 tool result로 받아 재시도할 수 있습니다.
• harness가 죽어도 session log에서 다시 시작할 수 있습니다.
• credential은 sandbox 안의 생성 코드가 아니라 vault나 MCP proxy 뒤에 둘 수 있습니다.

장시간 에이전트의 상태는 "현재 컨텍스트 창"이 아니라 복구 가능한 이벤트 로그에 있어야 합니다.

auto mode: 권한 승인을 classifier로 바꿀 때의 조건

Claude Code auto mode는 permission prompt를 없애자가 아니라 모든 승인을 사람 팝업으로 처리하는 방식의 피로를 줄이자에 가깝습니다.

설계 포인트:

• 도구 출력이 agent context에 들어가기 전에 prompt injection probe가 의심 신호를 붙입니다.
• tool call 실행 전 transcript classifier가 사용자 의도와 실제 행동의 blast radius를 비교합니다.
• broad shell access, wildcard interpreter, package manager run처럼 임의 코드 실행으로 빠지는 blanket allow는 auto mode 진입 시 유지하지 않는 방향입니다.
• subagent handoff도 위임 시점과 반환 시점에 따로 검사합니다.
• 차단되면 즉시 세션을 죽이기보다 safer path를 찾게 하고, 반복 차단 후 사람에게 넘깁니다.

왜 이게 엔지니어링인가

Anthropic 방식은 품질을 "모델이 잘 하겠지"로 떠넘기지 않고 역할별 편향을 분리하는 제어 루프로 다룹니다.

전형적인 시스템 설계 문제입니다.

• planner는 초기 오판을 줄입니다.
• evaluator는 builder의 낙관을 깨뜨립니다.
• QA는 텍스트 기반 판정과 실제 동작을 분리합니다.
• handoff는 상태 손실을 줄입니다.

하네스는 reasoning enhancement가 아니라 control-loop engineering에 가깝습니다.

sprint contract가 왜 중요한가

builder와 evaluator가 서로 다른 역할을 하려면 둘이 같은 계약을 참조해야 합니다.

sprint_contract:
  objective: "사용자에게 보이는 검색 패널 개선"
  done_when:
    - "모바일/데스크톱 모두 렌더링"
    - "keyboard navigation 동작"
    - "lint/typecheck/build 통과"
  non_goals:
    - "검색 API 구조 개편"
  failure_budget:
    max_fix_loops: 3
  escalation:
    - "접근성 회귀 발견"
    - "데이터 스키마 변경 필요"

이 계약이 있어야 evaluator가 "뭘 더 잘했는가"가 아니라 "무엇이 아직 증명되지 않았는가"를 판정할 수 있습니다.

load-bearing scaffolding을 판정하는 방법

Anthropic 관점에서 planner나 evaluator는 있다는 것 자체가 목적이 아닙니다. 아래 중 하나라도 반복된다면 load-bearing일 가능성이 큽니다.

• builder가 같은 누락을 계속 반복함
• 브라우저에서만 드러나는 문제가 자주 있음
• release 직전 결함 발견 비율이 높음
• 사람 리뷰가 사실상 마지막 안전장치가 됨

retry budget과 handoff 규칙

장시간 작업은 수정 루프가 길어지기 쉽습니다. 그래서 하네스는 보통 무한 반복 대신 제한된 반복 + 명시적 handoff를 둡니다.

type EvaluationResult = {
  status: 'pass' | 'retry' | 'handoff'
  gaps: string[]
}

function nextStep(failCount: number, highRisk: boolean): EvaluationResult['status'] {
  if (highRisk) return 'handoff'
  if (failCount >= 3) return 'handoff'
  return 'retry'
}

사소한 디테일 같지만 중요합니다. retry budget이 없으면 하네스는 품질 시스템이 아니라 토큰 소모 장치가 됩니다.

우리 팀으로 옮길 것

그대로 복제하면 안 되는 점

• planner/evaluator가 많다고 항상 좋은 것은 아닙니다.
• 작은 작업까지 full pipeline으로 돌리면 비용만 늘어납니다.
• 모델 성능이 좋아질수록 줄일 수 있는 scaffolding도 생깁니다.
• auto mode나 Managed Agents가 있다고 고위험 도메인의 HITL이 사라지는 것은 아닙니다.

Anthropic 사례의 진짜 교훈은 "항상 복잡하게 하라"가 아니라 실험으로 load-bearing 구조만 남기고 상태·실행·권한 경계를 분리하라입니다.

참고

• Anthropic, Harness design for long-running application development, 2026-03-24
• Anthropic, Claude Code auto mode: a safer way to skip permissions, 2026-03-25
• Claude Code docs, Choose a permission mode / Configure auto mode, 2026-05-23 열람 기준
• Anthropic, Scaling Managed Agents: Decoupling the brain from the hands, 2026-04-08
• Claude Managed Agents docs, Overview / MCP connector, 2026-05-23 열람 기준
• Anthropic, Agents for financial services, 2026-05-05