AIDive인트로: 절약이 아니라 힌트
Jev는 Claude Code를 더 저렴하게 만들지 않는다. 게이트웨이 자체 벤치마크가 그렇게 말한다. 이 글은 jev-gateway의 코드와 그 벤치마크 저장소를 읽은 뒤, 실제 Claude Code 세션 앞에 로깅 프록시를 놓아 라우터가 실제로 무엇을 받는지 확인한다.
Jev는 TypeSafe의 결정 모델이다: 밀리초 단위로 반환되는 확률이며, 한 주 동안 영상 6개가 이를 Claude Code에 연결했다. 광고 문구는 "가장 저렴한 에이전틱 코딩 루프"다. 게이트웨이 자체 수치를 보면, 라우팅을 켰을 때 기능 작업에서 Opus 5가 요청을 47% 더 보내고 시간을 83% 더 썼다.
밀리초 단위로 답하는 라우터가 어떻게 Claude Code를 더 느리게 만들까? 답은 코드 한 줄에 있다. Claude Code 내부에서 Jev가 받는 건 정확히 두 문장뿐이고, 일반적인 세션은 호출마다 40개의 도구를 함께 넘긴다.
Jev란 무엇이고, 이 흐름이 파는 것
Jev는 TypeSafe의 결정 모델이다. 텍스트를 생성하지 않는다. 타입이 지정된 질문을 던지면 선택지, 점수, 또는 예/아니오 확률로 답한다. 벤더가 제시하는 수치는 다음과 같다:
| 항목 | 값 |
|---|---|
| 입력 가격 | 백만 토큰당 $0.04 |
| 출력 가격 | 무료 ("측정하기엔 너무 저렴함") |
| 지연 시간 | 70~500ms |
| 홈페이지 헤드라인 | 194배 더 빠르고, 445배 더 저렴 |
그 헤드라인 아래 블로그 글에는, 이 두 배수가 실제 사례 중 상위권 수치이며 두 프런티어 모델의 평균과 비교해 측정한 것이라고 적혀 있다. 저자들 스스로도 이 비교가 해당 모델들에 유리하게 편향돼 있음을 인정한다.
5일 동안 영상 6개가 Jev를 Claude Code에 연결했다. 가장 조회수가 높은 영상은 13만 9천 회를 기록하며 이를 지금까지 가장 저렴한 에이전틱 코딩 루프라고 부른다. 이 흐름을 이끄는 저장소는 둘이다. 닷새 전 만들어진 Claude Code와 Codex용 로컬 프록시 jev-gateway(스타 181개), 그리고 그 전날 만들어진 컴팩션 플러그인 fast-jev-compaction(스타 6,400개)이다. Claude Code가 연결되는 곳은 게이트웨이이므로, 여기서부터 코드를 읽어 나간다.
환경 변수 하나, 코드 한 줄: 힌트 모드
jev-gateway는 Claude Code와 Anthropic API 사이에 자리한다. 로컬 포트를 가리키는 환경 변수 ANTHROPIC_BASE_URL 하나만으로 Claude Code를 실행한다. 그 외엔 아무것도 바뀌지 않는다. 소스 코드의 주석에는 게이트웨이 자격 증명이 따로 없다고 적혀 있어, Pro나 Max 로그인은 그대로 작동한다.
어댑터(src/adapters/messages.ts, 99행) 안에서, 한 줄이 Jev에게 허용되는 일을 결정한다:
steer: thinking || cached ? "hint" : "tool_choice"
확장 사고(extended thinking)가 켜져 있거나 대화가 캐시돼 있으면 게이트웨이는 힌트만 줄 수 있다. 그렇지 않으면 도구를 강제한다. 이 줄 위의 주석이 이유를 설명한다: API는 확장 사고가 켜진 동안 강제된 도구를 거부하며, tool_choice를 바꾸면 Claude Code가 매 턴마다 다시 읽는 캐시된 대화가 무효화된다.
실제 요청이 어떤 모습인지 확인하기 위해, 60줄짜리 로깅 프록시를 같은 종류의 포트에서 게이트웨이 자리에 앉히고 그걸 통해 Claude Code를 실행한 뒤 실제 저장소에서 요청 하나를 보냈다. 이 요청은 thinking: adaptive와 캐시 마커 3개를 담고 있었고, tool_choice는 없었으며, 클린 설치 상태에서 도구 24개가 함께 실려 있었다. 게이트웨이의 그 한 줄을 이 요청에 적용하면 강제 경로는 절대 실행되지 않는다. Claude Code의 모든 호출이 힌트 모드로 귀결된다. README도 그렇게 말한다: 큰 도구 목록에서 더 나은 도구 선택을 기대하되, 비용이나 지연 시간이 낮아지는 건 기대하지 말라고.
힌트: 두 문장, 그리고 닿지 못하는 곳
Claude Code 안에서 Jev가 할 수 있는 일은 마지막 메시지에 두 문장을 덧붙이는 것뿐이다. "라우팅 모델은 지금 이 도구가 가장 적절한 선택이라고 제안합니다. 맞지 않다면 무시하세요." 이것이 개입의 전부다. 모델은 이를 얼마든지 무시할 수 있고, tool_choice는 계속 auto로 남는다.
Anthropic 문서에 따르면 도구를 강제하는 건 선택지가 아니다: 강제된 도구는 Opus 5.5와 Fable 5.1에서 400 에러를 반환하고, 나머지 모델에서는 수동 사고(manual thinking)와 함께 쓰면 에러가 난다. tool_choice를 바꾸는 것도 안 된다: 프롬프트 캐싱 문서에 따르면 이는 긴 세션에서 가장 큰 비중을 차지하는 messages 캐시를 무효화한다. 도구 설명을 수정하면 tools, system, messages 캐시 전체가 무효화된다.
| 요청에 대한 변경 | 프롬프트 캐시에 미치는 영향 |
|---|---|
| 마지막 사용자 메시지에 힌트 추가 | 캐시된 prefix 변화 없음 |
tool_choice 변경 |
messages 캐시 무효화 |
| 도구 정의 수정 | tools, system, messages 무효화 |
게이트웨이의 주석은 힌트가 왜 마지막에 붙는지 설명한다: 그래야 캐시된 prefix가 Claude Code가 다음 턴에 다시 보내는 것과 바이트 단위로 동일하게 유지된다. 그 앞에는 가드가 하나 있다: 마지막 메시지가 사용자의 것이 아니면 요청은 그대로 통과한다. 이번에 포착한 두 요청 모두 Claude Code 자신이 덧붙이는 system 블록으로 끝났다. 하나는 환경 리마인더였고 다른 하나는 훅(hook)의 출력이었다. 이런 형태에서는 힌트가 붙을 자리가 없다. 다른 턴에서는 붙는다. 도구 결과가 사용자 메시지로 돌아오기 때문이며, 벤치마크는 Jev가 Claude Code 요청의 3분의 1에서 절반을 조종한다고 집계한다.
아무도 인용하지 않는 벤치마크
게이트웨이 자체 벤치마크인 jev-gateway-bench가 첫 질문에 답한다. 이 벤치마크는 모두가 쓰는 것과 같은 Claude Code, 같은 구독으로 MCP 서버나 플러그인, 스킬 없이 셀당 5회씩 총 120개 세션을 돌렸다. 작은 체스 엔진에 대한 작업 두 가지였다: 버그 5개를 심어 둔 버그 찾기, 그리고 대수 표기법(algebraic notation)을 추가하는 기능 작업.
| 모델, 작업 | 라우팅 켬 vs 끔 |
|---|---|
| Opus 5, 기능 | 입력 토큰 +61%, 요청 +47%, 시간 +83% (그래도 5/5 해결) |
| Sonnet 5, 기능 | 입력 토큰 +16%, 시간 +37% |
| Sonnet 5, 버그 찾기 | 입력 토큰 −48%, 시간 −25% |
저자들의 말을 빌리면, 라우팅이 득이 되는 곳은 디버깅이다. 그들의 설명이 곧 처음 질문의 답이다: 게이트웨이는 Claude 모델에는 힌트만 줄 수 있으므로, 맞지 않는 힌트는 공짜로 무시되는 대신 우회 비용을 만든다.
Codex는 강제 버전을 받는다. Jev는 Codex 요청의 76~100%를 결정했다. Claude Code에서는 3분의 1에서 절반 수준이었던 것과 대비된다. 다른 하네스(harness)에 있던 한 모델은 더 저렴해졌지만 틀렸다. 다섯 개 중 다섯 개가 아니라 세 개만 풀었다. 저렴하지만 틀린 건 절약이 아니다.
한계는 분명하다: 셀당 5회는 작은 표본이고, 장난감 수준의 엔진 하나뿐이며, 아무도 이를 재현하지 않았다. 입력의 대부분도 캐시돼 있으므로, 입력 절약은 출력 절약보다 가치가 낮다.
내 세션이 건네는 것: 클린 24개, 풀 40개
일반적인 Claude Code 세션은 호출마다 라우터에 무엇을 넘길까? 프록시 로그가 답한다: 도구 40개. 같은 저장소, 같은 한 단어짜리 프롬프트, 두 가지 설정으로 확인했다: 빈 설정에 MCP 서버가 없는 클린 설치, 그리고 서버와 플러그인이 있는 평소 설정.
| 클린 설치 | 평소 설정 | |
|---|---|---|
| 요청에 담긴 도구 수 | 24 | 40 (MCP 서버와 플러그인에서 16개) |
| 청구된 prefix 토큰 | 47,411 | 57,277 |
| 출력 토큰 | 4 | 4 |
| "ok" 한 번의 API 환산 비용 | $0.07 | $1.15 |
이 목록 자체가 곧 비용이다. 가장 무거운 정의는 기본 내장돼 있다: shell 도구 하나만 12,000자, agent 도구는 거의 9,000자에 달한다.
벤치마크의 각주에서는 클린 설치에서 도구 6개, 토큰 7,000개를, 로드된 한 설정에서는 도구 285개를 확인했다. 오늘날의 클린 Claude Code는 기본 내장 도구가 훨씬 더 많고, 로드된 경우는 오히려 더 드물다. 대부분의 MCP 도구는 검색 도구 뒤에 지연(deferred) 상태로 숨어 있어서, 라우터가 보는 목록은 작게 유지된다. 크기가 어떻든 게이트웨이는 그 목록을 매 요청마다 Jev에게 보낸다. 저장소의 열린 이슈 하나는 대부분의 답이 버려지기 전에 이미 전체 비용을 치른다고 지적한다. 이 중 어느 것도 Jev의 잘못이 아니며, Jev가 고칠 수 있는 것도 아니다.
용도별 결론
Claude Code 안에서의 라우팅: 아니오. 모델이 무시할 수 있는 힌트일 뿐이고, 두 Claude 모델 모두에서 기능 작업을 더 느리게 만들었으며, 유일한 이득은 디버깅뿐이다. 예외는 매우 큰 도구 목록에서 하루 종일 버그를 찾는 경우이며, 이는 README 자체가 명시하는 사례다.
컴팩션 플러그인 fast-jev-compaction: 아직 아니다. 얼리 액세스 훅 플래그가 필요하고, 열린 이슈들은 일부 빌드에서 훅이 등록되지 않는다고 지적하며, 한 번의 컴팩션 이후 모델이 작업이 끝났다고 말하는 보고서를 아홉 개나 작성했는데 전부 조작된 내용이었다. 실무자들이 먼저 이를 짚었다: 이 플러그인을 다룬 최상위 스레드는 491점을 받았고, 가장 큰 반론은 속도가 아니라 트랜스크립트를 제3자에게 보내는 것에 대한 서비스 약관 문제였다.
Codex: 여기가 진짜 타깃이다. 여기서는 게이트웨이가 도구를 강제하고, Jev는 최대 모든 요청을 조종했으며, 버그 찾기는 출력 토큰을 57% 덜 써서 끝났다.
| 용도 | 판정 |
|---|---|
| Claude Code 안의 라우팅 | 아니오, 단 매우 큰 도구 목록에서의 버그 찾기는 예외 |
| fast-jev-compaction | 아직 아님 |
| Codex | 예 |
이 흐름이 제대로 짚은 것 하나: 구독 로그인은 전혀 건드리지 않는다. 게이트웨이는 URL만 바꿀 뿐이다. 이 분석의 한계: 셀당 5회, 체스 엔진 하나, 아무도 재현하지 않은 벤치마크 저장소, 그리고 내가 직접 라우팅을 건 세션은 없었다는 점. 내가 측정한 건 도구 목록과 요청이지, Jev 자체가 아니다. Jev 자체는 저렴하다. 우회로는 그렇지 않다.
