14. 이 리서치를 우리는 이렇게 활용한다

한 줄: 01–13장에서 본 13개 평가 어휘 중 실제로 본 실험에 박을 8개를 추리고, 각 패치를 하루치 작은 실험 P1–P9로 쪼갠 결정 요약.

비유: 13권 짜리 매뉴얼을 다 읽은 다음, 우리 케이스에 진짜 필요한 8개 도구만 골라 작업 순서를 짠 격. 모든 어휘를 다 쓰진 않음 — 일부는 v2에 보류.

이 문서에서 챙길 3가지

패치 8개를 P1–P9로 쪼개 하루 1패치 검증 — 통과한 것만 v2(본 운용)에 들고 감
도입 안 한 어휘(Agent-as-Judge·GAIA·평가 플랫폼)는 “왜 안 했는가”의 근거가 명시됨 — 이게 L3 메타평가의 핵심 데이터
이 문서는 결과만 — 왜 그렇게 결정했나의 진단 과정은 각 study 장에서, 액션 단위는 experiments/00-plan.md에서

study 시리즈 01–13장의 어휘를 우리 실험에 어떻게 박았는가. 이 페이지는 과정 (어떻게 진단했나) 이 아니라 결과 (그래서 어떻게 쓰기로 했나) 만 적는다. 액션 단위로 묶어 보면 → experiments/00-plan.md.

1. 활용 방식 한 줄

리서치에서 검증된 8개 패치를 9개의 작은 실험(P1–P9)으로 분할, 하루에 한 패치씩 검증해 통과한 것만 본 운용(v2)에 들고 간다.

2. 리서치 항목 → 실제 활용

각 학습 장의 핵심 어휘를 어디에 어떻게 박았는지.

학습 장	가져온 어휘	우리 실험에서의 쓰임	실험
01. Trajectory vs Outcome	trajectory 메트릭 (tool_calls·unique_tools·call_sequence)	hook 로그에서 자동 추출. OpenClaw 통합 강점(H3) 의 직접 증거로 사용.	P1
02. LLM-as-Judge	Spearman ρ ≥ 0.7 임계, 4 차원 rubric 프롬프트, position-bias 회피 (순서 swap)	codex 자동 채점이 민지 점수와 일치하는지 부산물로 측정. v2 자동화 근거.	P7
03. Agent-as-Judge	(도입 안 함)	본 실험 N이 작아 비용 대비 가치 부족. v2 후속에서 H2 학습 흔적 검증 시 재검토.	—
04. 다층 Rubric (7-25-130)	단일 1–5 → 차원 분해	I5(품질 1–5)를 정확성 + 즉시 사용성 2 차원으로 분해.	P5
05. τ-bench / pass^k	pass^k 정확한 정의 (모두 성공의 곱확률)	I6(반복 일관성)을 std 대신 pass^3 boolean 으로 재정의. H2′(학습 징후) 직접 측정.	P3
06. GAIA / AgentBench	(도입 안 함)	모델 능력 평가지 에이전트 설계 평가가 아님. 외부 contextualization 용 어휘만.	—
07. SWE-bench	F2P + P2P 정신 (회귀 검사)	“이미 잘 되던 태스크가 여전히 잘 되나” 회귀 검사로 차용.	(운영 룰)
08. OSWorld / WebArena	상태 비교 검증 사고방식	”공지 발송 trajectory 에 함수호출 0회 = 실제로 안 보냈다 → 자동 fail”.	P2
09. Memory Benchmarks	MemoryAgentBench 4축 중 1축	”1회차 교정 사항이 2회차에 자발 반영됐나” boolean. H2′ 보강.	P8
10. Tool-use Benchmarks	BFCL 의 함수 선택 정확도·Relevance	함수호출 정확도를 trajectory 분석 부산물로 산출.	P1·P2
11. 평가 플랫폼	(도입 안 함)	280 trial 규모엔 과투자. hook + CSV + history/ 로 충분. Langfuse는 v2 후보.	—
12. 평가 파이프라인	Offline → Online → Monitoring 3단 사고	Day 0–3 = offline gate, Day 4~ = online sampling, 일일 plot = monitoring 으로 축소판 적용.	(운영 룰)
13. 벤치마크 함정	Goodhart’s Law, single-metric 회피, fork 트리거 임계 완화	TTC × 품질 페어 분석(Goodhart 가드) + fork 트리거 5+ → 3+ 완화.	P4·P6

3. 활용 결과 — Before / After

진단 전후 우리 실험 측정 설계가 어떻게 달라지는가.

3.1 측정 지표

항목	Before (cascade로 박힌 상태)	After (P1–P9 모두 채택 시)
품질	I5 단일 1–5	I5a 정확성 + I5b 즉시 사용성 2 차원
반복 일관성	I6 = std(3회 점수)	I6 = pass^3 boolean (3회 모두 ≥ 4), std 보조
Trajectory	”raw 보존” 만	tool_calls·unique_tools·has_external_call 자동 추출
함수호출 정확도	(없음)	0회 호출 = 자동 fail 룰
LLM-as-judge	(없음)	codex 자동 채점, 민지와 ρ 측정
Goodhart 가드	(없음)	TTC × 품질 페어 산점도 1장
Memory	I7 누적 자산 (사망 예정)	“1회차 교정 → 2회차 자발 반영” 1축

3.2 운영 룰

항목	Before	After
Fork 트리거	5+ 사망	3+ 사망 또는 정성↔정량 정반대 1건
익명 채점	정성에만 적용	정량도 D2 저녁 익명 재채점
회귀 검사	(없음)	“이전 잘 되던 T1·T8 재실행” 추가 (SWE-bench P2P 정신)
Offline gate	암묵	Day 0–3 명시적 5게이트 (smoke·회귀·수용·안전·latency)

3.3 산출물

산출물	Before	After
L1 결정	결정 매트릭스 5 시나리오 (21일용 텍스트 잔존)	P9 통합 분석에서 조건부 결정 매트릭스
L2 프레임	7 지표 W1–W6 spec	7 지표 + trajectory + 2-차원 품질 + pass^3 + 함수호출 fail
L3 메타	A·B·D 3 프레이밍 비교	동일 + LLM-as-judge ρ를 부산물로 (자동화 가능성 평가)

4. 활용 안 한 항목과 그 이유

리서치에서 봤지만 의도적으로 도입 안 한 것들. 후속자가 같은 함정에 빠지지 않도록 명시.

항목	출처	도입 안 한 이유
Agent-as-Judge	03장	본 실험 N이 작고 텍스트 산출물 위주 — 코드/DB 도메인이 아님. v2 후속에서 H2 검증 시만 검토.
GAIA / AgentBench	06장	모델 능력 평가지 에이전트 설계 평가가 아님. 우리는 워크플로 적합성 측정.
SWE-bench 자체	07장	코딩 도메인 직접 무관. F2P/P2P 정신만 회귀 검사로 차용.
OSWorld/WebArena 자체	08장	우리는 MCP·플러그인 통합이라 GUI 조작이 아님. 상태 비교 사고방식만 차용.
산업 평가 플랫폼	11장	280 trial 규모엔 과투자. 도입한다면 v2의 Langfuse self-host.
Memory 4축 전부	09장	4축 모두는 채점 부담 폭증. 1축(자발 반영) 만 P8에.
7-25-130 다층 rubric 풀버전	04장	130 항목은 비현실. 1단 분해(2 차원) 만 P5에.
Multi-model judge consensus	02장	비용 3배. 단일 codex judge 만 P7에.

5. 다음 단계

이 활용 계획의 실행 은 experiments/ 폴더로:

experiments/README.md — 시리즈 소개 + 현재 상태
experiments/00-plan.md — P1–P9 시퀀스·의존·진입 규칙
experiments/P*-{slug}.md — 각 probe 페이지 (시작 직전 작성)

각 probe의 결과·결정은 history commit 으로 누적된다. P1–P9 중 5건 이상 채택 + P4 결정 + P9 잠정 결론까지 도달하면 본 운용 v2 진입 검토.

체크리스트

§2 표를 보고 어느 학습 장의 어떤 어휘가 어느 probe에 박혔는지 즉시 답할 수 있다
§3 Before/After 표에서 가장 큰 변화 3개를 떠올릴 수 있다
§4 활용 안 한 항목과 그 이유를 안다 (후속자에게 같은 길을 가지 말라고 말할 수 있는 수준)
본 페이지가 과정 이 아니라 결과 라는 점을 인식한다 — 진단 어떻게 했는지 궁금하면 history/, 실행은 experiments/