사례: Anthropic

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

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

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

해결하려는 문제

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

기술적 메커니즘

Anthropic식 하네스에서 중요한 것은 역할 이름이 아니라, 각 단계가 서로 다른 입력과 다른 판정 기준을 가진다는 점입니다.

왜 이게 엔지니어링인가

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도 생깁니다.

Anthropic 사례의 진짜 교훈은 "항상 복잡하게 하라"가 아니라 실험으로 load-bearing 구조만 남겨라입니다.

참고

• Anthropic, Harness design for long-running application development, 2026-03-24