[보관] 메타 평가 — 접근 자체에 대한 평가 (L3 산출물)

이 프로젝트가 채택한 접근 = “평가 지표를 사전에 정의하고 측정한다” (이하 A). 이 접근이 다른 4종 대안 대비 우월한가? 같은 raw 데이터를 5종 프레이밍으로 재해석해 답한다.

L3가 가능하려면 실험 운영 방식 자체가 달라야 한다 — “끝나고 회고로 떠올리자”로는 답이 안 잡힘. 본 문서는 그 운영 방식을 정의한다.

1. 5종 프레이밍

프레이밍	정의	측정 시점	본 파일럿에서의 역할
A. 지표 사전정의	7개 지표를 정의·측정·집계	실시간	본 실험이 채택한 방법
B. 사후 코딩 ★	raw 로그만 쌓고 끝나고 패턴을 사후 추출 (지표 미정의)	사후 (P9 통합 분석)	본 실험 raw로 재해석 — 채택
C. 결과 도달률	”그 태스크를 결국 했냐” Y/N만	매 태스크	본 파일럿에선 보류 (v2 후보)
D. 사용자 일기 ★	매일 자유 서술, 사후 코딩	매일 저녁	정성 메모를 일기 형식으로 추가 채집 — 채택
E. 행동 추적	재사용·이탈 등 passive metric만	사후	본 파일럿에선 보류 (v2 후보)

★ 본 probe 시리즈에서 B와 D만 채택. C·E는 시간/도구 부족으로 보류, v2 본 운용에서 도입.

각 프레이밍은 같은 P1~P8 누적 raw에서 독립적으로 결론을 뽑은 뒤, A의 결론과 비교한다 (P9 통합 분석 시점).

1.1 프레이밍별 “결론” 형식

A: 지표 8개(I1~I8, I7은 v2 후보) + 결정 매트릭스 → “민지에겐 X 추천”
B: raw 코딩으로 발견된 패턴 N개 → “민지의 워크플로에서 Y 도구가 Z 상황에서 막혔다” (도구 권고는 부산물)
C: 도달률 표 → “X가 Y%, Y가 Z%로 더 많이 완료”
D: 일기 코딩으로 빈도·정서 분석 → “사용자가 X를 더 자주 좋다고 적었다”
E: 자동 추출 metric → “X가 더 자주 재호출됨, Y는 N일째 사용 중단”

5개의 결론이 같은 도구를 가리키면 A의 정당성 강함, 갈리면 L3의 핵심 데이터(어디서 왜 갈렸나).

2. 체크포인트 — probe 단위 (`experiments/00-plan.md` 운영)

각 probe 종료 직후 / 다음 probe 진입 전에 같은 3개 질문.

Q1. 지표 민감도

지표 8개 중 도구 차이를 실제로 드러낸 건 몇 개?

두 도구 값의 차이가 표준편차 이상 → 살아있음
표준편차 이내로 겹침 → 죽이기 후보 (W6 함정 보정 후 부활 가능)

Q2. 정성 vs 정량 정합성

정성 메모가 말하는 결론과 지표가 말하는 결론이 같은가?

일치: 정량 신호 보강
불일치: 어디서 왜 어긋났는지 raw 들어가 분석 — L3의 핵심 데이터

Q3. 채집 부담

지표 기록이 페르소나(민지) 작업의 30% 이상 차지하는가?

네: 도구가 도구가 아닌 게 됨 → 지표 단순화 필수
아니오: 그대로 유지

각 체크포인트 결과는 runs/checkpoints.md에 한 페이지씩 기록.

probe별 추가 점검 (probe 시리즈 운영)

시점	추가 점검
각 probe 종료 직후	채집 부담 + 1차 민감도. fork 분기 트리거: 해당 probe에서 quant 5+ 사망 시 다음 probe를 qual 70%로 재분배 (P4 채택 시 3+로 임계 완화)
다음 probe 진입 전	정성↔정량 정합성 검토 + 직전 probe의 결과물 5건 무작위 자가 재채점(ICC). I6은 P3 종료 시 산출. Track B 사용 probe 진입 직전 V1~V4 사전 점검
P9 (L1 통합 분석)	최종 — A vs B/D 통합 비교(C·E 보류 명시). L1·L2 v1·L3 사후 비교 동시 작성. 본 운용(v2)으로 갈지 멈출지 결정

3. 채집 양식 — 3단

02-constraints.md C7과 동일. 여기선 양식 상세.

3.1 정량 — `runs/runs.csv`

date,probe_id,track,tool,task_id,ttc_seconds,intervention_count,setup_minutes,setup_help,quality_score,quality_accuracy,quality_usability,pass3_repeat,tool_calls_count,unique_tools_used,has_external_call,concurrency_label,memory_label,note_id,note
2026-05-XX,P1,A,hermes,T1,420,2,0,Y,4,4,4,,5,3,Y,,,note_2026-05-XX_001,

probe_id: P1 | P2 | … | P9
track: A | B
tool: hermes | openclaw
setup_help: Y | help | N (I4)
quality_score: 1~5 종합 (사후 블라인드 채점 후 채움 — 실시간엔 빈칸). P5 채택 시 quality_accuracy·quality_usability 분해 컬럼 사용
pass3_repeat: P3 한정. boolean (3회 모두 ≥ 4) 또는 std(3회 점수) — P3 §6 결정에 따라
tool_calls_count·unique_tools_used·has_external_call: P1 채택 시 scripts/parse-trajectory.py로 자동 채움
concurrency_label: T_concurrent 행만. C1~C4 (I8)
memory_label: P8 한정. 1회차 교정이 2회차에 자발 반영됐나 boolean (Y/N) — P8 §6에서 정의 확정
note_id: notes.jsonl의 entry id로 조인
note: 자유 텍스트 (notes.jsonl과 별개로 csv에서 빠른 검색용 1줄 요약)

assets_n(I7 누적 자산)·repeat_speedup_pct(반복 가속)는 v2 후보로 보류. probe 시리즈에선 측정 안 함.

3.2 정성 — `runs/notes.jsonl`

{"id":"note_2026-05-XX_001","date":"2026-05-XX","track":"A","tool_id":"tool_X","task":"T1","note":"공지 톤이 너무 격식적. 디스코드용으로 다시 시켰는데 두 번째도 비슷."}

tool_id: tool_X / tool_Y (블라인드용 익명) — 어떤 게 어느 도구인지 매핑은 별도 파일(runs/.tool_map.json, gitignore)
note: 1~3줄. 도구명·“Hermes”·“OpenClaw” 같은 식별 단어 금지

3.3 Raw — `logs/`, `~/.{hermes,openclaw}/logs/`

자동 수집 (Claude Code hook 기존)
Track A·B 종료 시 logs/snapshot-track-{A,B}-YYYY-MM-DD.tar.gz로 동결 (해당 트랙의 마지막 probe 종료 직후)
동결 후 변경 금지 — 사후 B/D 재해석의 원천 (C·E는 v2 후보로 보류)

3.4 사용자 일기 — `runs/diary.md` (D 프레이밍용)

매일 저녁 5~15줄 자유 서술. 도구별로 분리하지 않고 그날 전체 경험을 적음. 사후에 평가자가 도구별 코딩.

## 2026-05-XX
오늘은 행사 공지 + 신청자 정리 + 회고 초안 셋. 첫 도구는 빨랐는데 톤이 어색해서 두 번 더 시켰다. 두 번째 도구는 처음부터 톤이 맞았지만 셋업하느라 30분 까먹은 게 컸다. 회고 초안은 둘 다 그저 그랬다. ...

4. 도움 카탈로그 (I4용)

I4의 “도움” 라벨 모호성 해결을 위한 사전 정의:

도움 종류	라벨
검색(Google·Stack Overflow·공식 문서)	Y (단독 셋업 성공)
공식 문서·README 정독	Y
LLM(ChatGPT·Claude.ai)에 자연어 질문	도움
사람에게 채팅으로 질문 (지인 개발자)	도움
사람이 화면 보면서 같이 셋업	N
사람이 직접 셋업 대신 해줌	N

각 셋업 세션의 도움 라벨은 정성 메모에 종류·횟수·소요 시간 기록.

5. 반증 조건 — 사전 약속

02-constraints.md C8과 동일. 여기선 도달 시 액션 명시.

조건	도달 시 액션
8개 중 5개 이상이 4종 실패 중 하나에 걸림 (probe 종료 직후, P4 채택 시 3+)	fork 분기 트리거 발동 — A 자체 의문, 다음 probe를 B/D 프레이밍 70%로 재분배 (지표 측정은 보조)
B 또는 D 재해석이 A 결론과 정반대 (P9 통합 분석 시점)	최종 리포트의 결정 한 줄을 “A 단독으로는 결정 불가, B/D 병행 필요”로 기록
자가 재측정 ICC < 0.5 (어떤 지표든, 다음 probe 진입 전 검증)	그 지표 즉시 v1에서 제거, 사망 사유 기록
정성 메모와 지표 결론 정반대 케이스 ≥ 1건	그 케이스를 `03` §6.2에 통째로 인용 — L3 핵심 증거
Track A vs B 결과 대분기 (지표 3개 이상이 트랙별로 다른 도구를 가리킴)	“도구 비교”가 아니라 “도구×LLM 조합 비교”로 결론 재포장
채집 부담이 30% 초과 (probe 종료 직후 검증)	지표 셋 즉시 5개 이하로 압축, 살아남은 것만 다음 probe부터 운영

중요: 위 액션은 발견 시 즉시 적용. “끝나고 보자”가 아님. 체크포인트 운영자(meta 세션의 Claude)는 매번 위 조건을 검사할 책임이 있음.

6. L3 최종 리포트 작성 절차 (P9 통합 분석 — probe 시리즈 운영)

3종 프레이밍(A·B·D) 각각의 결론을 독립적으로 작성. A 결과를 보고 B/D를 작성하면 오염. C·E는 v2 후보로만 명시.
세 결론 비교표 작성 → 03 §6.1 (C·E 행은 빈칸 + v2 표시)
어긋난 곳마다 raw 들어가 “왜 어긋났는가” 한 단락씩
접근 A에 대한 한 줄 결론(03 §6.4) — 어떤 조건에서 유효한지 명시 + probe 시리즈 한계 명시
v2 후보 등록(03 §6.5)
본 운용(v2) 진행 여부 결정 — probe 시리즈 결과로 L2/L3 산출물이 가능해 보이는가? P1~P8 중 5+ 채택 + P4 결정 + P9 잠정 결론 통과 시 검토

L3 리포트는 의사결정자용이 아니라 다음 실험을 설계할 사람용이다. 따라서 A를 변호하지 말고, 발견된 한계를 그대로 기록.

7. 본 문서 자체에 대한 메타

이 문서(08)도 사전에 박아두는 약속이지 사후 합리화의 도구가 아니다. 실험 중 본 문서를 수정한다면:

수정 사유와 시점을 history/에 별도 항목으로 남김
수정 전 버전을 git/스냅샷으로 보존
사후 리포트에서 “08은 D-N에 X 항목이 추가/변경됐다”를 명시

이렇게 해야 L3 결론이 사후 짜맞춤이 아닌, 사전 약속에 대한 검증임을 보장할 수 있다.