[보관] 평가 지표 스펙 v0 (L2 산출물 초안)

본 실험에서 측정할 8개 지표(I1~I8)를 6칸으로 정의한다. probe 시리즈 종료 시점(P9 L1 통합 분석)에 4종 반증 조건(민감도·신뢰성·타당성·실용성)을 통과한 것만 v1으로 격상. 일정·각 probe의 사전 plan은 experiments/00-plan.md. 6칸 구조는 의도적: 한 칸이라도 비면 그 지표는 “측정 불가”로 간주, 실험 시작 전 채워야 함. 평가자 1명 운영(C5) 이라 평가자 2명 κ 산출 불가 → 자가 재측정 ICC 로 신뢰성 측정 (각 probe 종료 직후 또는 다음 probe 진입 전).

6칸 구조 정의

칸	질문	비면 발생할 위험
W1. 무엇을 잡는가	정성 평가가 못 잡는 어떤 신호?	다른 지표와 중복돼 죽임 가치 없음
W2. 조작적 정의	누가 측정해도 같은 숫자가 나오게 하는 정확한 룰	측정자마다 다르게 셈 → 신뢰성 실패
W3. 계측 방법	수동? hook 자동? 로그 파싱?	채집 자체가 페르소나에 부담 → 실용성 실패
W4. 신뢰성 검증	같은 결과물에 대해 평가자 2명이 같은 값을 내는가	사후 분석 시 결과 못 믿음
W5. 민감도	도구 차이를 실제로 드러내는가, 노이즈에 묻히는가	”둘 다 비슷”으로 죽음
W6. 편향 위협	이 지표만의 함정	결론이 본질 아닌 노이즈를 따라감

각 지표는 위 6칸을 모두 채운다.

I1. TTC (Time-To-Completion, 도달 시간)

W1: “도구가 자연어 지시를 받아 완료까지 가는 절대 속도” — 사용자 체감 답답함의 1차 근사
W2: 사용자가 자연어 지시를 첫 번째로 입력한 시각 ~ 도구가 최종 결과물(메일·메시지·표 등)을 출력한 시각(초 단위). 중간 개입은 시간에 포함하되 사용자가 다른 작업으로 자리 이탈한 시간(예: 화장실)은 제외 → 사용자가 매 태스크 시작 시 타이머(scripts/timer.sh) 시작·종료 클릭으로 통제.
W3: 사용자 수동 + Claude Code hook의 UserPromptSubmit/Stop 타임스탬프(보조). 두 값이 ±10초 이상 어긋나면 사용자 수동 우선.
W4: 다음 probe 진입 전 raw 1건 무작위 추출, 같은 평가자가 raw로그만 보고 타임스탬프 재추출 → 첫 측정과 ±5% 이내면 통과 (ICC ≥ 0.7).
W5: 같은 도구 같은 태스크 1회차 vs 다른 도구 같은 회차 평균이 표준편차 이상 차이날 것. 같은 값이면 죽임. (probe 시리즈 운영에선 1회차 + P3 pass^3 = 4회 데이터로 충분)
W6: 타이핑 속도·자리 이탈 같은 외부 요인이 들어옴 → 자리 이탈 통제 + 같은 사용자(민지) 단독으로 흡수. 또 도구 응답 길이가 길수록 TTC 길어짐 → 결과물 품질(I5)과의 상관 분석 필수.

I2. 개입 횟수 (Interventions)

W1: “도구가 자연어 지시를 한 방에 이해했는가” — 자연어 이해도의 직접 측정
W2: 첫 지시 이후 사용자가 추가로 입력한 수정·재지시·구체화 메시지 수. 단순 확인(“응”, “그래”) 제외. 도구 측 clarifying question에 답한 것은 포함(=도구가 한 방에 못 알아들었다는 뜻).
W3: raw 로그에서 사용자 발화 카운트. 카운팅 룰을 다음 probe 진입 전 자가 재적용해 일치도 측정.
W4: 자가 재측정 ±1 이내 일치 (ICC ≥ 0.9 기대 — 단순 카운트라).
W5: 같은 태스크 1회차 vs P3 pass^3의 3회차에서 횟수가 줄어드는 패턴이 도구별로 갈리는가.
W6: 사용자 성향(꼼꼼함)에 영향받음 → 단일 사용자라 흡수. 단, 도구가 자체 clarifying을 자주 하는 스타일이면 점수가 부풀려짐 — clarifying-driven은 하위분류로 별도 카운트.

I3. 셋업 비용 (Setup Cost, 분)

W1: “비개발자가 도구를 쓸 수 있는 상태로 만드는 데 드는 진입 비용” — 페르소나에 결정적
W2: P1 진입 전 셋업 단계에 스킬 추가·통합 설정·프롬프트 정비에 쓴 분 단위 시간. 도구 사용 자체(태스크 실행)는 제외. 스톱워치 수동 기록.
W3: 사용자 수동 기록 + 셋업 세션 화면 녹화(사후 검증용).
W4: 다음 probe 진입 전 화면 녹화 보고 자가 재측정한 값과 ±10% 이내 (ICC ≥ 0.5만 통과 — 자가 추정이라 신뢰성 낮음 명시).
W5: 도구별로 0분 vs N분 같은 큰 차이가 기대되는 지표 — 차이가 안 나면 그 자체가 강한 신호.
W6: “셋업”의 정의가 모호 → 사전 정의: ① 스킬/명령어 등록 ② 외부 통합(API 키, OAuth) ③ 프롬프트/페르소나 설정. 그 외(도구 학습·시행착오)는 셋업 아님. Hermes는 자동 학습이라 셋업 시간이 0으로 잡히지만 학습 시간이 다른 곳에 숨음 → I7(누적 자산)과 묶어 해석 필수.

I4. 셋업 가능 여부 (Setup Self-Sufficiency)

W1: “비개발자 단독으로 도구가 진입 가능한가” — 진입장벽의 이진 표현
W2: P1 진입 전 셋업 완료 시점에 다음 셋 중 하나로 라벨:
- Y: 사용자 단독으로 셋업 완료, 외부 도움 0회
- 도움: 1~3회 외부 도움 받음 (검색·문서 외엔 없으면 Y로 강등 가능)
- N: 단독 셋업 실패, 개발자 직접 개입 필요
W3: 사용자가 셋업 세션 끝에 자기 평가. “도움” 케이스는 누구·몇 분 도움받았는지 정성 메모 동반 필수.
W4: 자가 평가 + 다음 probe 진입 전 화면 녹화 재시청해 라벨 재확인. 1명 평가라 외부 검증 어려움 → 일기(framing D)로 보완.
W5: 두 도구가 같은 라벨이면 정보가치 0. 갈리면 강력한 발견.
W6: “도움” 라벨이 가장 모호 → 사전 정의된 도움 카탈로그(08 §4)에 따라 라벨링. 단순 검색은 Y, 사람에게 채팅 질문은 도움.

I5. 결과물 품질 (Output Quality, 1~5)

W1: “도구의 결과물을 실사용할 수 있는가” — 절대 속도(I1)가 빨라도 품질 나쁘면 무가치
W2: 1~5 루브릭 (reports/detailed.md §2.4):
- 5: 그대로 발송 가능 / 4: 1~~2어절 다듬기 / 3: 1~~2문단 재작성 / 2: 절반 이상 재작성 / 1: 폐기
W3: 결과물에서 도구 식별 정보 제거 후 평가자 1명이 즉시 채점. 다음 probe 진입 전, 직전 probe의 결과물 5건 무작위 추출, 익명화·셔플 후 자가 재채점 → ICC 산출.
W4: 자가 재측정 ICC ≥ 0.7 미만이면 루브릭 재정의 후 재채점. (평가자 2명 κ는 본 파일럿에선 불가 — v2 본 운용 시 도입)
W5: 같은 태스크에 두 도구가 같은 점수 분포면 죽임. 이 지표는 가장 죽을 가능성이 높음 — H-L2-2.
W6: “정성을 정량으로 가장한” 가장 위험한 지표. 사실 오류 빈도(객관) + 톤 적합성(주관)을 합산한 것이라 한 척도로 합치면 정보 손실. v2에서 분해 후보.

I6. pass^3 일관성 (probe 시리즈 — 원래 “반복 가속”의 대체. 정의는 P3에서 검증)

W1: “같은 태스크 반복 시 결과가 일관되게 나오는가” — 학습 량 측정은 단일 probe에서 불가, 학습의 징후(일관성)로 대체. τ-bench의 pass^k 개념 차용.
W2: **P3 (pass^3 boolean 재정의)**에서 핵심 5태스크 중 2개를 도구별로 3회 연속 실행 (30분 내). 매 회 I5 점수 기록. 지표 값 = std(3회 점수) (보조) + P3 채택 시 pass^3 boolean (3회 모두 ≥ 4) 비율 (주)
W3: I5(품질) 데이터에서 자동 계산. 3회 모두 채점되면 유효.
W4: I5의 자가 재측정 ICC에 의존. 별도 검증 없음.
W5: 도구별 pass^3 비율 차이가 의미 있으면 도구 차이 PASS. 둘 다 pass^3 = 100%면 “둘 다 일관” 강한 발견. (2주 학습 곡선은 본 운용 v2에서 측정)
W6: 같은 태스크 반복 시 평가자가 익숙해져 채점이 후해지는 carry-over → 매 회 raw 결과물만 보고 채점, 이전 점수 차단. 사용자 자체 학습 효과도 들어옴 — 도구 미사용 대조군 없어 분리 불가, 한계로 명시.

I7. 누적 자산 (Cumulative Assets)

W1: “도구가 시간이 지남에 따라 자체 자산을 얼마나 축적하는가 vs 사용자가 직접 채워넣는가” — 학습형 vs 셋업형의 본질
W2: (study/14 R1 권고: probe 시리즈에선 측정 안 하고 v2 후보로 보존) — 조작적 정의만 남김:
- Hermes 자동 생성 스킬·메모리·패턴 수
- OpenClaw 사용자 수동 추가 스킬·통합 수
W3: (v2 본 운용에서 측정) 도구 자체 디렉토리 스캔(~/.hermes/skills/, ~/.openclaw/skills/)으로 카운트. 카운트 룰 사전 명시(빈 파일·테스트 파일 제외). 셋업 baseline diff.
W4: (v2 본 운용에서 측정)
W5: 두 도구가 다른 형태로 자산을 쌓아 직접 비교 어려움 — 절대 수보다 “이 자산이 실제 태스크 시간 단축에 기여했는가” 의 상관이 본 신호.
W6: 자산 수가 많다고 좋은 게 아님 (=노이즈 자산 가능). I6(반복 가속)과 곱해 단위 자산당 시간 단축으로 정규화 권장.

I8. 컨컬런시 견고성 (Concurrency Robustness)

W1: “한 메시지에 다른 카테고리 태스크 N개를 동시에 던졌을 때 도구가 어떻게 무너지는가” — 민지 페르소나 핵심 고통(컨텍스트 스위칭)에 직결. Hermes(학습형) vs OpenClaw(셋업형)이 컨컬런시에서 다르게 무너지는지 변별축
W2: T_concurrent — Track A·B 각각 1 probe에서 도구별 1회. 한 메시지로 다른 카테고리 태스크 3개 묶어 지시 (예: T1+T3+T7). 4단계 라벨:
- C1: 모두 완료 — 3개 태스크 모두 결과물 발송 가능 수준
- C2: 직렬 처리 — 도구가 자기 의지로 순서대로 처리, 최종적으로 모두 완료
- C3: 일부 누락·혼동 — 1~2개 누락 또는 컨텍스트 섞임
- C4: 실패 — 처리 못 함, 또는 첫 번째만 처리하고 나머지 무시
W3: 평가자가 결과물 보고 라벨 결정. runs/runs.csv에 concurrency_label 컬럼 추가, T_concurrent 행에만 채움
W4: 자가 재측정. 4단계 라벨이라 일치도 ICC ≥ 0.7 기대 (단순 분류)
W5: 두 도구가 같은 라벨(예: 둘 다 C2 직렬)이면 변별 못함. 갈리면 강한 발견 — 컨텍스트 스위칭에서 학습형이 우세인지 셋업형이 우세인지 답
W6: 평가자가 “직렬 처리”를 “혼동”으로 잘못 라벨링하기 쉬움 — 도구가 사용자에게 명시적으로 “순서대로 처리할게요” 했으면 C2, 그런 안내 없이 결과만 섞여 나오면 C3. 정성 메모로 동반 보강 강제

(별도) T_burst — 인프라 측정 (도구 비교 외)

I8과 분리. 모든 probe·main 측정·L1·L2·L3 작성 종료 후 마지막에 1회. 도구별로:

1분간 N=10·20·50개 동일 요청을 병렬 송신
측정: 성공률, 첫 429 도달 시점, latency p50/p95
기록: runs/burst.csv (도구·백엔드·N·success_n·error_429_n·p50·p95·note)
결과는 리포트 부록에만 — L1 결정에 반영 안 함

종합 — 죽이기·살리기 사전 약속

각 probe 종료 직후(1차 판정)와 P9 통합 분석 (최종 판정) 시 각 지표를 다음 룰로 분류:

분류	조건	액션
생존(Keep)	W4·W5 모두 통과	v1에 그대로
수정(Fix)	W4·W5 중 하나라도 실패하지만 W6에서 명시한 함정에 의한 것	정의 보정 후 다음 probe 또는 Track B 사용 probe에서 재시도
사망(Drop)	W4·W5 둘 다 실패, 또는 정성 메모와 정반대	v1에서 제거, 사망 사유 `03` §5.1에 기록
승격(Promote)	사전 정의에 없었지만 정성 메모·raw에서 반복 등장	v2 후보로 `03` §5.3에 등록

이 분류는 각 probe 종료 직후·다음 probe 진입 전·P9 통합 분석 시 매번 갱신한다. probe 종료 직후 5개 이상 사망하면 fork 분기 트리거 발동 → 다음 probe를 qual 트랙 70%로 재분배 (08 §5). P4 임계 완화 채택 시 3+ 또는 정성↔정량 정반대 1건으로.