Jev 같은 결정 모델을 “스킬 라우터” 로 앞에 세우는 게 이득인지 재 보려다가, 재기 전에 막혔다. 분모가 없었다. 라우터의 정확도가 90% 냐 99% 냐를 따지려면 먼저 라우팅이 1년에 몇 번 일어나는지를 알아야 하는데, 나는 그 숫자를 가진 적이 없었다. 이 글은 그 숫자를 만든 기록이다. 결론부터 적으면, 내 기계에서 라우터의 기대 이득은 30일에 0.6건 미만이었다.

앞선 두 글의 연장이다 — 지연 로딩은 이미 하고 있다, 스킬 설명은 요약이 아니라 색인이다.

1. 라우터 평가식에는 항이 세 개 있다

벤치마크 점수는 이 중 하나밖에 안 말해 준다.

\[\text{도입 이득} = (\text{결정 빈도}) \times (\text{정확도 개선 여지}) \times (\text{오선택 비용})\]

세 항 중 하나라도 0이면 곱은 0이다. 벤더가 파는 건 가운데 항이고, 나머지 둘은 벤더가 알 수 없다. 내 로그에만 있다. TypeSafe 자신도 eval 사이트에서 우열이 아니라 파레토를 주장한다 — “nothing is both cheaper and more accurate”.1 싸고 빠른 게 사실이어도, 곱할 빈도가 없으면 이득은 여전히 0이다. 이 구도는 전에 배수를 따져 볼 때와 같다 — 배수에는 분모가 있다.

2. 원장 만들기

Claude Code 의 세션 기록은 ~/.claude/projects/**/*.jsonl 에 줄 단위 JSON 으로 남는다. 최근 30일치를 통째로 읽어 세었다. 299개 파일, 681.6MB, 289,913줄.

항목 30일 실측
사용자 턴 (툴 결과 제외) 2,592
그중 텔레그램에서 들어온 것 1,275
어시스턴트 턴 75,478
툴 결과 턴 42,675
Skill 툴 호출 6
서로 다른 스킬 5
상주 중인 개인 스킬 57

호출된 5종은 고블(2회), 레오파드·깃블·이믹·artifact-design(각 1회)이다.

3. 이 숫자를 평가식에 넣으면

라우터는 스킬을 고르려고 프롬프트마다 돈다. 그래서 분모는 2,592 이고 분자는 6 이다.

\[\frac{6}{2{,}592} \approx 0.23\%\]

바꿔 말해 라우팅 432번당 실제 선택이 1번이다. 그리고 그 6번 중 4번(깃블·고블·이믹과 레오파드)은 내가 CLAUDE.md 에 박아 둔 한국어 예약어로 문자열 일치로 걸리는 것들이다. 확률 모델이 판단할 자리가 아니다. 남는 표본은 30일에 2건이다.

가운데 항도 비어 있다. 앞 글에서 쟀듯 내 57개 설명은 앞 30자가 겹치는 혼동쌍이 0쌍이고 목록에서 잘리지도 않는다. 개선 여지를 관대하게 10%p 로 가정해도

\[6 \times 0.10 = 0.6\ \text{건} / 30\text{일}\]

이 최대치다. 실제로 관측된 오탑재는 0건이라, 이 0.6 조차 가정이 만든 숫자다.

세 번째 항, 오선택 비용도 작다. 스킬 선택이 틀리면 스킬이 안 걸릴 뿐이고 기본 동작이 그대로 돌아간다. 되돌릴 수 없는 게 아니다. 세 항이 각각 작아서 곱은 사실상 사라진다.

4. Jev 고유의 값 — 신뢰도 게이트는 이 자리에서 의미가 있나

Jev 가 파는 건 속도가 아니라 캘리브레이션이다. 확신도를 임계값에 걸어 “모르겠으면 기권” 을 만드는 것. 그러면 이 용도에서 기권이 무엇인지 따져야 한다.

스킬 선택에서 기권 = 아무 스킬도 안 거는 것 = 원래 동작이다. 즉 게이트가 지켜 주는 손실이 없다. 게이트는 오선택 비용이 클 때(잘못 분류하면 환불이 나가거나 티켓이 엉뚱한 팀으로 가는 상황) 값이 나오는 장치인데, 여기서는 세 번째 항이 이미 작다. 같은 물건이라도 자리에 따라 값이 0이 된다.

덧붙여 “환각 0%” 는 이 판단에 쓸 수 없는 수치다. 벤더 각주가 직접 밝힌 대로 그 0% 는 측정치가 아니라 스키마 보장에서 나온 단정이고2, 보장의 범위는 모양이지 내용이 아니다. 스킬 이름 57개 중 하나를 반드시 뱉는다는 건 진짜지만, 그중 틀린 걸 고르는 건 그대로 가능하다.

5. 측정하면서 밟은 함정 두 개

함정 1 — 오염된 사용 지표. 처음엔 “스킬 경로가 로그에 몇 번 나오나” 로 셌다. 38종 529회가 나왔다. 틀린 수치다. CLAUDE.md 본문이 ~/.claude/skills/이믹/SKILL.md 같은 경로를 직접 적고 있고 그 파일은 모든 세션에 상주한다. 그래서 세션 수를 센 것에 가깝다(이믹 100회가 1등으로 나온 이유). 신호처럼 생긴 값이 실은 상수였다.

함정 2 — 호출 0회를 “안 쓰는 스킬” 로 읽는 것. 그림·메모·일정 은 Skill 툴 호출이 0인데 실제로는 자주 쓴다. CLAUDE.md 에 실행 절차가 통째로 적혀 있어서 툴을 거치지 않고 바로 실행되기 때문이다. 그러니 이 원장이 말해 주는 건 “스킬이 안 쓰인다” 가 아니라 “선택이 이미 결정적이다” 이다. 결론은 오히려 강해지지만, 두 문장은 전혀 다른 뜻이라 섞으면 안 된다.

6. 그래서 일반화

이건 Jev 평가가 아니라 선택을 대신해 주는 모든 모델의 평가 절차다. 도입 전에 물어야 할 건 세 가지고, 전부 남의 벤치마크가 아니라 내 로그에 있다.

  1. 이 결정이 실제로 몇 번 일어나는가 — 원장을 뽑는다. 내 경우 30일에 6번이었다.
  2. 지금 얼마나 틀리는가 — 관측된 오선택을 센다. 0이면 가운데 항이 0이다.
  3. 틀리면 얼마나 아픈가 — 되돌릴 수 있으면 세 번째 항이 작다.

셋 다 재고 나면 정확도 몇 %p 짜리 논쟁은 대개 필요가 없어진다. 내 경우 1번에서 이미 끝났다. 그리고 1번은 벤더가 대신 재 줄 수 없는 유일한 항이다.

근거의 한계

  • 전부 이 맥 한 대, 최근 30일이다. 스킬을 많이 굴리는 환경이면 1번 항이 커져 결론이 뒤집힌다.
  • Skill 툴 호출 6회는 그 툴을 거친 것만 센 값이다. 5절 함정 2대로 실제 스킬 사용량은 이보다 많다. 이 글의 주장은 “사용량” 이 아니라 “모델이 고르는 횟수” 에 대한 것이다.
  • 2,592라는 사용자 턴 수는 JSONL 을 문자열로 훑어 센 값이라 ±몇 %의 오차가 있을 수 있다. 자릿수 판단에는 영향이 없다.
  • “정확도 개선 여지 10%p” 는 내가 관대하게 잡은 가정이지 측정치가 아니다. 관측된 오탑재는 0건.
  • Jev 의 캘리브레이션 품질은 여기서 재지 않았다(그럴 키가 없다). 4절은 성능 평가가 아니라 용도 적합성 판단이다.

References

  1. “Workflow evals”, TypeSafe AI. https://evals.typesafe.ai/ — “frontier: nothing is both cheaper and more accurate” (파레토 주장). ↩

  2. “Introducing System One Models and Jev”, Diogo Almeida (founder, TypeSafe AI), 2026-09. https://typesafe.ai/blog/introducing-system-one-models-and-jev — “Our number is not empirical. Schema matching is guaranteed…” 및 RLCD 명명. 벤더 1차. ↩