측정이 가설을 기각할 때

AI 협업의 비용은 체감으로 판단하기 쉽고, 체감은 자주 틀립니다. 세션 로그 전수에서 숫자를 뽑아 계획을 검증한 사례들입니다. 절감 대상은 예상한 곳에 없었고, 예상하지 않은 곳에 있었습니다.

01사례

1. TM04-1

   훅 토큰 절감 가설 — 0.003%

   문제

   린트·타입체크·테스트 결과를 모델이 읽는 것이 낭비로 보였습니다. 훅이 대신 돌리고 요약만 넘기면 컨텍스트가 줄 것이라는 가설로, '측정 → 훅' 순서로 시작했습니다.

   설계

   세션 기록 전수에서 검증성 셸 호출을 골라 결과 크기를 재고 전체 토큰 대비 비율을 구했습니다.

   결과

   호출 383회 · 결과 총량 149,649자(약 37K 토큰) · 중앙값 217자 · 최대 3,306자. 전체 1,185M 토큰의 0.003%. 부르는 쪽이 이미 tail로 잘라 부르고 있어 절감할 양이 처음부터 없었습니다. 훅은 남기고 목적을 '토큰 절감'에서 '검증 누락 방지'(세션 종료 시 검증 스크립트 강제 실행)로 바꿨습니다.

2. TM04-2

   컨텍스트 기준선 — 이후 변경은 이 숫자 대비로만

   문제

   '컨텍스트가 무겁다'는 체감만 있고 얼마나 무거운지, 어디서 무거운지 숫자가 없었습니다.

   설계

   응답 1회당 컨텍스트 크기의 분포와 턴당 증가량, 세션별 점유율을 세션 로그에서 집계해 기준선으로 저장했습니다.

   결과

   응답 1회당 컨텍스트 중앙값 286,743 · p90 685,794 · 최대 999,602 토큰, 턴당 증가 중앙값 989. 상위 세션 1개가 전체의 34%(399.4M)였고 원인은 한 화면 파일에 대한 Edit 48회와 Read 17.5M자 — 절감 대상은 훅이 아니라 여기 있었습니다.

3. TM04-3

   레퍼런스 라이브러리 조회 비용 — 1/12

   문제

   10개 도메인 512개 레퍼런스의 색인 파일 하나가 11만 토큰. 자료 하나 찾으려고 색인을 통째로 읽고 있었습니다.

   설계

   각 항목에 '누가 어떤 상황에서 드는지'와 '이럴 땐 아니다'를 붙이고, 상황 문장으로 검색하는 스크립트로 색인 전체 읽기를 대체했습니다.

   결과

   1회 조회 토큰 10,547~31,478 → 2,487 (약 1/12).

4. TM04-4

   스킬 발동 — 횟수가 아니라 직전 요청을 본다

   문제

   스킬이 존재하는 것과 발동하는 것은 다릅니다. 발동률 숫자만으로는 과발동과 미발동을 구분할 수 없었습니다.

   설계

   세션 기록에서 스킬 호출과 스킬 문서 읽기를 세고, 그 옆에 직전 요청 문장을 함께 출력해 사람이 판정하는 스크립트를 만들었습니다.

   결과

   세션 30개 기준 발동 — 설계 판단 3·레퍼런스 7·충돌 해결 6·브랜치 최신화 1·파이프라인 0. 파이프라인 0은 프로젝트 문서에 규칙 사본이 남아 스킬을 부를 필요가 없었기 때문이었습니다. 정밀도·재현율은 아직 없습니다 — 정답 집합을 만드는 비용이 현재 오발동 비용보다 크다는 판단이고, 이 판단도 측정값이 바뀌면 바뀝니다.

02남은 규칙