Harness Engineering Series — Vol.3

측정할 수 있어야,
개선할 수 있다

평가 지표를 수치화하고, 3명의 독립 심사위원이 채점하면 —
어디가 부족한지, 얼마나 나아졌는지가 숫자로 보인다.

평가자 분리 일러스트 — 팩트체커, 스타일감사, 구조평가 세 개의 평가 스테이션
01 — 지난 이야기

Vol.1-2 리캡:
행동을 제한하고, 역할을 나눴다

1편에서는 Hook으로 "뭘 할 수 있는지"를, 2편에서는 서브에이전트로 "누가 하는지"를 제어했습니다.
그런데 한 가지 빠진 게 있어요.

01
Vol.1 — Hook

행동 제한

outline.md 없이 draft.md를 작성하면 exit 2로 물리적 차단.

02
Vol.2 — Sub-agent

역할 분리

researcher는 WebSearch만, creator는 Write만, editor는 Edit만. tools 필드가 강제.

그런데 Vol.2의 editor는 뭘 기준으로 고쳤을까요?
감이에요. "이 문장이 좀 어색한 것 같으니까 고치자" — 이건 하네스가 아니라 그냥 판단이에요.
3편에서는 이 "감"을 객관적 채점 기준(rubric)으로 바꿉니다.
Vol.1 보기 Vol.2 보기
02 — 자기채점의 함정

평가자를 분리하는가

Anthropic 엔지니어링 팀의 실험 결과, AI 에이전트가 자기 작업물을 평가하면 품질이 뻔히 부족해도 "잘했다"고 칭찬하는 경향이 확인됐어요.

01
자기 채점

Generator = Evaluator

글을 쓴 에이전트가 자기 글을 평가하면, "합니다 10번 반복? 문체 일관성 좋습니다!" 이렇게 나와요. 자기 작업에 대한 편향이 작용하거든요.

02
분리 채점

Generator ≠ Evaluator

별도의 평가 에이전트가 채점하면, "합니다 10번 반복 → 문어체 위반 10회 → 3/5점 fail" 이렇게 객관적으로 나와요. 회의적인 평가자를 만드는 게 자기비판적인 생성자를 만드는 것보다 훨씬 쉽거든요.

Anthropic 블로그 핵심 원칙: "회의적인 독립 평가자를 튜닝하는 것이, 생성자를 자기비판적으로 만드는 것보다 훨씬 더 다루기 쉽다." 그리고 여기에 한 가지를 더 합니다 — 평가자를 3명으로 분리해서 교차 검증까지 거치면, 단일 평가자의 편향까지 상쇄돼요.
03 — 채점 설계

채점 기준을 설계하다

평가자가 있어도 "그냥 좋은 것 같아요"라고 답하면 소용없어요.
구체적인 rubric — 무엇을, 어떻게 측정하고, 몇 점 이하면 fail인지 — 이 있어야 해요.

먼저 3명의 채점 결과를 어떻게 종합할지 정해야 해요. 세 가지 방식이 있어요.

A
점수 합산
각 평가자 5점 만점,
총 15점 중 threshold 이상이면 통과
B
전원 통과제
3명 모두 4/5점 이상이어야 통과.
하나라도 미달이면 재작성.
C
다수결
3명 중 2명 이상 pass면 통과.
주관적 평가자 1명이 fail해도 OK.

실전에서는 상황에 맞게 A, B, C 중 선택하면 돼요. 이번 편에서는 가장 엄격한 B. 전원 통과제를 적용합니다.

3명의 평가자와 Rubric

평가자 전문 영역 도구 검증 방식
fact-checker 팩트 정확성 Read, Grep 원본 자료와 Grep 대조 (기계적)
style-auditor 문체 품질 Read, Grep 패턴 카운트 (기계적)
structure-reviewer 구조/가독성 Read 구조적 판단 (판단 기반)
도구가 다르면 검증 방식 자체가 달라져요. fact-checker와 style-auditor는 Grep으로 패턴을 세는 기계적 검증이라 감이 낄 여지가 없어요. structure-reviewer만 판단 기반이지만, 3명 중 2명이 기계적이니까 전체 신뢰도가 확보돼요.
04 — 에이전트 설정

3명의 Evaluator 설정하기

Vol.2에서 배운 .claude/agents/ 파일에 평가자 3명을 추가합니다.
기존 researcher, creator, editor는 그대로 재활용해요.

.claude/agents/
  ├── researcher.md  ← Vol.2 재활용
  ├── creator.md  ← Vol.2 재활용
  ├── editor.md  ← Vol.2 재활용
  ├── fact-checker.md  ← NEW
  ├── style-auditor.md  ← NEW
  └── structure-reviewer.md  ← NEW
.claude/agents/fact-checker.md
---
name: fact-checker
description: 원본 조사자료와 본문을 대조하여 팩트 정확성을 검증
tools: Read, Grep
model: haiku
---

research-notes.md와 mini-pc-top5.md를 Grep으로 대조한다.

## 채점 기준 (5점 만점)
- 5점: 팩트 오류 0개
- 4점: 팩트 오류 1개
- 3점 이하: 팩트 오류 2개 이상 → fail

## 검증 항목
1. 제품명 일치 여부
2. CPU 스펙 (모델명, 코어 수)
3. RAM 용량
4. 저장장치 종류/용량
5. 가격 정보
.claude/agents/style-auditor.md
---
name: style-auditor
description: 문체 품질을 기계적 패턴 카운트로 검증
tools: Read, Grep
model: haiku
---

mini-pc-top5.md의 문체를 Grep 패턴 카운트로 채점한다.

## 채점 기준 (5점 만점)
- 5점: 위반 0회
- 4점: 위반 1-2회
- 3점 이하: 위반 3회 이상 → fail

## 검증 패턴 (Grep)
1. 문어체 반복: 합니다, 됩니다, 있습니다
2. 콜론+목록: ":" 뒤 즉시 불릿 목록
3. AI 투: 다양한, 획기적인, 혁신적인
4. 동일 종결어미 연속 3문장 반복
.claude/agents/structure-reviewer.md
---
name: structure-reviewer
description: 글의 구조와 가독성을 판단 기반으로 검증
tools: Read
model: sonnet
---

mini-pc-top5.md의 구조와 가독성을 채점한다.

## 채점 기준 (5점 만점)
- 5점: 모든 항목 충족
- 4점: 사소한 개선점 1-2개
- 3점 이하: 구조적 결함 → fail

## 필수 검증 항목
1. 도입부 hook 유무
2. 순위 산정 기준 명시 (필수)
3. TOP 5 각 항목 비교 근거
4. 제품별 장단점 균형 (필수)
5. 결론 명확성

fact-checker와 style-auditor는 model: haiku로 가볍고 빠르게, structure-reviewer는 판단이 필요해서 model: sonnet으로 설정해요. Vol.2에서 배운 모델 차등 배치의 연장선이에요.

05 — 1차 평가

1차 평가 워크스루

researcher → creator를 거쳐 초고가 완성되면, 3명의 evaluator가 동시에(병렬로) 채점합니다.
서로의 점수는 볼 수 없어요 — 독립 채점이 핵심이니까요.

CLAUDE CODE — 오케스트레이터 세션
U
"가성비 미니PC TOP 5 추천 블로그 글 써줘"
AI
researcher에게 조사를 위임합니다... 조사 완료. creator에게 초고 작성을 위임합니다... mini-pc-top5.md 생성 완료.
── evaluator 3명 병렬 실행 ──
AI
초고를 3명의 평가자에게 동시에 전달합니다. 각 평가자는 서로의 결과를 볼 수 없습니다.
EVALUATOR 결과 (병렬 수신)
FC
fact-checker: 4/5
Beelink 저장장치 중간 옵션(512GB) 누락 — 조사자료에는 "256GB~512GB/1TB"이지만 본문에는 "256GB~1TB"로 기재. 팩트 오류 1건.
SA
style-auditor: 5/5
"합니다" 0회, 구어체 어미 4종 (에요/거든요/죠/예요) 고르게 분포. AI 투 표현 0회. 콜론+목록 0회. 위반 0건.
SR
structure-reviewer: 4/5
도입부 hook 우수, 장단점 균형 양호. 단, 순위 산정 기준이 본론 시작 전에 명시되지 않음 — 필수 항목 누락으로 1점 감점.

1차 점수 요약

fact-checker
4점 기준
4/5
style-auditor
5/5
structure-reviewer
4/5
평가자점수판정감점 사유
fact-checker4/5pass저장장치 옵션 1건 누락
style-auditor5/5pass
structure-reviewer4/5pass순위 기준 미명시
전원 4점 이상이라 기술적으로는 통과(pass)예요. 하지만 만점이 아니라는 건 개선 여지가 있다는 뜻이에요. 오케스트레이터는 감점 사항을 수집해서 evaluation-report.md에 기록하고, editor에게 수정을 요청합니다.
06 — 피드백 루프

수정하고, 다시 채점하다

evaluation-report.md의 감점 사항을 editor에게 전달하고, 수정 후 다시 3명이 동시에 채점합니다.

1차 vs 2차 점수 비교 인포그래픽
EDITOR 수정 과정
AI
evaluation-report.md의 감점 사항 2건을 editor에게 전달합니다.
ED
수정 1: Beelink 저장장치 "256GB~1TB" → "256GB~512GB/1TB"로 중간 옵션 추가
수정 2: 비교표 위에 "가격 대비 실사용 성능, 국내 구매 가용성을 종합해 선정했어요" 기준 문장 추가
── evaluator 3명 2차 병렬 실행 ──

1차 vs 2차 점수 비교

평가자1차2차변화
fact-checker 4/5 5/5 +1 (저장장치 옵션 수정)
style-auditor 5/5 5/5 유지
structure-reviewer 4/5 5/5 +1 (순위 기준 추가)
평균 4.3/5 5.0/5 +0.7

2차 평가 — 전원 만점

fact-checker
5/5
style-auditor
5/5
structure-reviewer
5/5
1차에서 잡힌 2건의 감점이 정확히 수정되고, 수정 과정에서 기존 문체와 구조의 장점은 훼손되지 않았어요. 이게 "평가 → 피드백 → 수정 → 재평가" 루프의 힘이에요.
07 — 마무리

전체 오케스트레이션 흐름

사용자
"미니PC 추천 글 써줘"
researcher
웹 조사 → research-notes.md
creator
초고 작성 → mini-pc-top5.md
fact-checker
4/5
style-auditor
5/5
struct-reviewer
4/5
editor
피드백 기반 수정
fact-checker
5/5
style-auditor
5/5
struct-reviewer
5/5
최종 판정
전원 만점 통과

하네스는 층층이 쌓인다

Vol.1에서 Hook으로 행동을 제한하고,
Vol.2에서 서브에이전트로 역할을 분리하고,
Vol.3에서 평가자 분리로 품질을 객관화했어요.

이 세 가지를 조합하면 — 누가, 무엇을, 얼마나 잘 했는지를 모두 인프라 수준에서 강제하는 프로덕션 하네스가 됩니다.

행동 차단x역할 분리x평가 객관화=프로덕션 하네스
Dante Labs 자료실에서 보기

마크다운 전문 + 시리즈 전체 링크가 포함된 블로그 버전