Production Harness Engineering
프로덕션 하네스 — 평가·이식성·팀 협업
혼자 쓰는 하네스와 팀이 쓰는 하네스는 다르다 — git으로 버전 관리되고, CI로 검증되고, 새 컴퓨터에 5분 안에 재현 가능한 하네스가 진짜 프로덕션 하네스다.
Overview
개인 하네스를 넘어 팀과 조직 수준의 하네스를 구축하는 것이 최종 목표다. 혼자 쓰는 CLAUDE.md 하나가 아니라, git으로 버전 관리되고 CI로 검증되고 신입 팀원이 온보딩 첫날에 자동으로 적용받는 하네스.
이것이 가능한 이유: Claude Code의 모든 설정이 파일 시스템에 있다. ~/.claude/ 디렉토리를 백업하고 새 컴퓨터에 복원하면 된다. MCP 서버 재설치가 필요하지만 명령어 2-3개로 완료된다.
동시에, 하네스 투자의 ROI를 측정해야 한다. '느낌적으로 더 효율적'이 아니라 PR 병합 속도, 코드 재작업률, 버그 이탈률 같은 정량적 지표로. 94%의 엔지니어링 리더가 'AI 투자 측정 지표가 없다'고 말하는 현실에서, 측정하는 팀이 이긴다.
- Anthropic의 4-component eval 프레임워크로 에이전트 품질을 측정할 수 있다
- 자신의 하네스를 새 컴퓨터에 5분 안에 재현하는 이식성 패키지를 만들 수 있다
- Week 1→Month 3 구현 로드맵으로 우선순위를 정할 수 있다
- 에이전트 ROI를 정량적으로 측정하는 메트릭을 정의하고 추적할 수 있다
Sections
Eval Harness — 에이전트를 평가하는 방법
Anthropic의 4-component eval 프레임워크:
하네스 자체 — 에이전트가 행동할 수 있는 인프라 2.
태스크 — 무엇이 요청되었는가 3.
트래젝토리 — 어떤 행동이 취해졌는가 (최종 답만이 아니라!) 4.
결과 — 검증 가능한 결과
단위 테스트 방식 eval이 에이전트에서 실패하는 이유: 최종 출력만 체크하지만, 에이전트가 효율적인 경로로 갔는지, 제약을 존중했는지, 에지 케이스를 올바르게 처리했는지를 놓친다.
LLM Readiness Harness 패턴:
gates:
- name: task_resolution_rate
threshold: 0.85
blocks_deploy: true
- name: code_churn_rate
threshold: 0.15 # 2주 내 재작업 < 15%
blocks_deploy: false
- name: pass_at_1_rate
threshold: 0.70 # 첫 시도 성공률
blocks_deploy: true
- name: verification_tax
threshold: "2h" # 첫 커밋→PR 승인 시간
blocks_deploy: false
검증된 벤치마크:
- Azure SRE 에이전트: 35,000+ 사고 자율 처리, 완화 시간 40.5시간 → 3분
- LangChain: 하네스 개선만으로 +13.7%p
- Terminal Bench 2.0: 하네스 변경으로 30위 → 5위
이식성 패키지 — 새 컴퓨터 5분 설정
백업해야 하는 것 (모두 ~/.claude/ 안에 있음):
# 백업 스크립트
tar -czf harness-backup.tar.gz \
~/.claude/CLAUDE.md \
~/.claude/settings.json \
~/.claude/hooks/ \
~/.agents/skills/
# 주의: .env (API 키)는 절대 백업 파일에 포함하지 말 것!
새 컴퓨터 복원 순서:
# 1. Claude Code 설치
npm install -g @anthropic-ai/claude-code
# 2. 하네스 복원
tar -xzf harness-backup.tar.gz -C ~
# 3. API 키 설정 (직접 입력)
echo "GEMINI_API_KEY=..." >> ~/.claude/.env
echo "GITHUB_TOKEN=..." >> ~/.claude/.env
# 4. MCP 서버 재설치 (settings.json에 기록된 것들)
claude mcp add filesystem -- npx -y @modelcontextprotocol/server-filesystem ~
claude mcp add github -- npx -y @modelcontextprotocol/server-github
# 5. Plugins 재활성화 (Claude Code UI에서)
# Settings → Plugins → superpowers, karpathy-skills 활성화
# 6. 검증
bash ~/.claude/hooks/harness-audit.sh
팀 공유 전략:
- CLAUDE.md, .claude/settings.json, .claude/hooks/ → git에 커밋
- API 키 (.env, settings.local.json) → .gitignore
- 개인 설정 → ~/.claude/settings.json (개인 파일, git 제외)
Week 1→Month 3 구현 로드맵
우선순위 기반 단계적 구현 계획:
Week 1: Minimum Viable Harness
- ~/.claude/CLAUDE.md 수동 작성 (50줄 이내)
- .claude/settings.json 기본 deny 리스트 작성
- 민감 파일 PreToolUse 훅 1개 추가
- PostToolUse 자동 포맷 훅 추가 (Oxlint/Ruff)
- git에 커밋 → 팀 공유
Week 2-4: 핵심 기능 확장
- MEMORY.md 아키텍처 상태 추적 시작
- Plan → Approve → Execute 워크플로우 정착
- 에이전트 실수 발생 시마다 테스트/린터 규칙 추가
- Playwright CLI로 E2E 검증 훅 추가
- Stop 훅으로 완료 전 테스트 통과 강제
Month 2-3: 고도화
- ADR 링크가 있는 커스텀 린터 에러 메시지 작성
- PreCompact 훅으로 중요 정보 보호
- .claude/commands/ 슬래시 명령어 플레이북
- JSONL 감사 트레일 설정
Month 3+: 팀/조직 수준
- 컨테이너 안에서 Pattern C (Sandboxed Full-Auto) 배치 작업 평가
- 복잡 태스크를 위한 멀티에이전트 PEV 아키텍처
- 정량적 ROI 측정: PR/일, 재작업률, 코드 변경률
- 조직 Managed settings 배포
ROI 측정 — 가장 중요한 메트릭
AI 도구 ROI를 측정하는 가장 중요한 3가지 메트릭:
Verification Tax (가장 중요):
- 정의: 첫 커밋 → PR 승인까지 걸린 시간
- 왜 중요: AI 생성 코드가 실제로 팀에 받아들여지는지 측정
- 목표: < 2시간
Actual Shipment Rate:
- 정의: AI 생성 코드 중 실제로 프로덕션에 배포된 비율
- 왜 중요: '아 Claude가 그 코드 다 버렸어' 를 측정
- 목표: > 70%
Code Churn Rate:
- 정의: AI 생성 코드 중 2주 내에 재작업된 비율
- 왜 중요: 처음부터 올바른 코드인지 측정
- 목표: < 15%
보조 메트릭:
- Pass@1 Rate: 첫 시도 성공률 (목표: > 70%)
- Tool Call Efficiency: 태스크당 평균 도구 호출 수 (낮을수록 좋음)
- Context Utilization: 평균 컨텍스트 사용률 (목표: < 60%)
측정 방법: PostToolUse JSONL 감사 로그 + git 통계 + PR 타임스탬프를 결합해서 주간 대시보드를 만든다.
프로덕션 하네스를 음식점 운영 시스템으로 생각해보자.
개인 셰프(개인 하네스)는 머릿속에 레시피가 있다. 혼자 요리할 때는 완벽하다. 하지만 직원이 10명이 되면? 레시피가 머릿속에만 있으면 아무도 같은 요리를 만들 수 없다.
프로덕션 음식점(팀 하네스)은 표준화된 레시피북(CLAUDE.md), 위생 체크리스트(Hooks), 식재료 관리 시스템(MCP), 품질 검사 프로세스(Eval)가 있다. 어떤 직원이 요리해도 같은 품질이 나온다.
이식성이란 음식점 프랜차이즈다 — 새 지점을 열 때 같은 매뉴얼, 같은 시스템, 같은 품질. ~/.claude/ 백업이 그 매뉴얼 패키지다.
ROI 측정은 '테이블 회전율'과 '반품률' — 어떤 요리가 얼마나 빨리 나가고, 얼마나 돌아오는지. 이걸 측정하지 않으면 무엇을 개선해야 할지 모른다.
팀의 하네스 ROI를 측정하는 대시보드 생성 스크립트. git 통계와 JSONL 감사 로그를 분석해서 주요 메트릭을 계산한다.
#!/usr/bin/env python3
"""harness-roi.py — 하네스 ROI 측정 대시보드"""
import subprocess
import json
from pathlib import Path
from datetime import date, timedelta
import re
def get_git_stats(days: int = 14) -> dict:
"""git 히스토리에서 코드 변경률(churn) 계산"""
since = (date.today() - timedelta(days=days)).isoformat()
result = subprocess.run(
['git', 'log', '--since', since, '--oneline', '--stat'],
capture_output=True, text=True
)
commits = result.stdout.count('commit') if 'commit' in result.stdout else result.stdout.count('\n\n')
insertions = sum(int(m) for m in re.findall(r'(\d+) insertion', result.stdout))
deletions = sum(int(m) for m in re.findall(r'(\d+) deletion', result.stdout))
churn_rate = deletions / max(insertions, 1)
return {
'period_days': days,
'commits': commits,
'insertions': insertions,
'deletions': deletions,
'churn_rate': round(churn_rate, 2),
'churn_status': '✅' if churn_rate < 0.15 else '⚠️' if churn_rate < 0.30 else '❌'
}
def analyze_audit_logs(days: int = 7) -> dict:
"""JSONL 감사 로그에서 도구 사용 패턴 분석"""
audit_dir = Path.home() / '.claude' / 'audit'
if not audit_dir.exists():
return {'error': '감사 로그 없음 — PostToolUse JSONL 훅을 먼저 설정하세요'}
total_tool_calls = 0
tool_counts = {}
blocked_calls = 0
for i in range(days):
log_date = (date.today() - timedelta(days=i)).isoformat()
log_file = audit_dir / f'{log_date}.jsonl'
if not log_file.exists():
continue
for line in log_file.read_text().split('\n'):
if not line.strip():
continue
try:
entry = json.loads(line)
payload = entry.get('event', {})
tool_name = payload.get('tool_name', 'unknown')
total_tool_calls += 1
tool_counts[tool_name] = tool_counts.get(tool_name, 0) + 1
if payload.get('exit_code') == 2:
blocked_calls += 1
except json.JSONDecodeError:
pass
top_tools = sorted(tool_counts.items(), key=lambda x: x[1], reverse=True)[:5]
return {
'period_days': days,
'total_tool_calls': total_tool_calls,
'blocked_calls': blocked_calls,
'block_rate': round(blocked_calls / max(total_tool_calls, 1) * 100, 1),
'top_tools': top_tools,
'calls_per_day': round(total_tool_calls / days, 1)
}
def generate_dashboard():
print("=" * 50)
print("HARNESS ROI DASHBOARD")
print(f"Date: {date.today().isoformat()}")
print("=" * 50)
print("\n📊 Code Churn (14일):")
git_stats = get_git_stats(14)
if 'error' not in git_stats:
print(f" Insertions: {git_stats['insertions']:,} lines")
print(f" Deletions: {git_stats['deletions']:,} lines")
print(f" Churn Rate: {git_stats['churn_rate']} {git_stats['churn_status']} (목표: <0.15)")
print(f" Commits: {git_stats['commits']}")
print("\n🔧 Tool Usage (7일):")
audit_stats = analyze_audit_logs(7)
if 'error' not in audit_stats:
print(f" Total calls: {audit_stats['total_tool_calls']:,}")
print(f" Blocked: {audit_stats['blocked_calls']} ({audit_stats['block_rate']}% block rate)")
print(f" Daily avg: {audit_stats['calls_per_day']} calls/day")
print(" Top tools:")
for tool, count in audit_stats['top_tools']:
print(f" {tool}: {count}")
else:
print(f" {audit_stats['error']}")
print("\n📋 Next Actions:")
if 'churn_rate' in git_stats and git_stats['churn_rate'] > 0.15:
print(" ⚠️ 높은 코드 변경률 — CLAUDE.md 규칙 강화 또는 더 구체적인 태스크 분해")
if 'block_rate' in audit_stats and audit_stats['block_rate'] > 5:
print(" ⚠️ 높은 블록률 — 허용 규칙 범위 확인 (너무 제한적)")
print(" 💡 Verification Tax 측정: PR 첫 커밋→승인 시간 추적 시작 권장")
if __name__ == '__main__':
generate_dashboard() git 히스토리에서 코드 변경률(Churn Rate)을 계산하고, JSONL 감사 로그에서 도구 사용 패턴과 블록률을 분석한다. 14일 코드 변경률과 7일 도구 사용 통계를 종합해서 대시보드를 출력한다.
✅ 시니어가 보는 것
- 하네스 설정이 git으로 버전 관리되고 팀 전체에 적용되는가
- Verification Tax, Churn Rate 같은 ROI 메트릭을 추적하는가
- 새 팀원이 온보딩 첫날에 자동으로 하네스를 받는가
- CI에서 하네스 설정 유효성을 자동 검증하는가
⚠️ 레드 플래그
- 하네스가 개인 컴퓨터에만 있고 팀 공유 불가
- API 키가 git에 커밋됨 (.env 파일)
- ROI 측정 없이 '느낌적으로 효율적'
- 하네스 변경 시 이유와 효과 문서화 없음
🎤 예상 인터뷰 질문
- Verification Tax를 가장 중요한 AI ROI 메트릭으로 보는 이유는?
- 팀의 CLAUDE.md를 git으로 관리할 때 공유 설정(.claude/settings.json)과 개인 설정(settings.local.json)을 어떻게 분리하는가?
- LangChain의 3가지 하네스 개선이 Terminal Bench 30→5위로 올린 것에서 배울 수 있는 팀 수준의 교훈은?
Key Takeaways
팀 하네스 = git + 버전관리
.claude/CLAUDE.md, .claude/settings.json, .claude/hooks/ → git에 커밋. API 키는 절대 포함 안 됨.
4-component eval
하네스, 태스크, 트래젝토리, 결과. 최종 출력만 보는 단위 테스트 방식은 에이전트에서 실패한다.
이식성 = ~/.claude/ 백업
이 디렉토리 하나를 백업하면 어떤 컴퓨터에서도 5분 안에 재현 가능.
3가지 핵심 ROI 메트릭
Verification Tax(<2h), Actual Shipment Rate(>70%), Code Churn Rate(<15%).
Week 1 MVH
CLAUDE.md + deny 리스트 + 민감 파일 훅 + 자동 포맷 + git 커밋 — 이것만으로도 극적인 개선.
측정하는 팀이 이긴다
94%의 엔지니어링 리더가 AI 투자 측정 지표가 없다고 말한다. 측정이 개선을 이끈다.
하네스는 팀의 자산
한 사람이 만든 하네스가 팀 전체를 높인다. 개인 생산성 → 팀 인프라로 스케일.
로드맵 따라가기
Week 1(MVH) → Week 2-4(핵심 기능) → Month 2-3(고도화) → Month 3+(팀/조직). 한 번에 다 하려 하지 말 것.