Jev는 싼 LLM이 아니라 생성을 버린 분류기다

TypeSafe AI가 낸 Jev를 "훨씬 싼 프런티어 모델"로 읽으면 틀린다. 문자열 생성을 버린 모델이다. 원문에 그렇게 적혀 있다.

"While Jev gives up string generation, it's optimized for structured outputs"

— TypeSafe AI 발표

그래서 이 소식이 바꾸는 건 "어떤 모델을 쓸까"가 아니라 "내 LLM 호출 중 생성이 실제로 필요한 건 몇 퍼센트인가" 다.

확인된 것

• Jev는 미리 정의된 타입의 값과 확률만 출력한다. 텍스트 생성은 하지 않는다.
• 가격: 입력 $0.042/MTok, 출력 무료("too cheap to meter"). 비교 대상으로 든 기존 LLM은 $0.20–$10/MTok.
• 지연: 종단 간 70ms–500ms. 비교 대상은 3–329초.
• 속도 주장의 정확한 문장은 이렇다. "40x-200x faster for the same levels of frontier intelligence for System One shaped queries." 조건이 붙어 있다.
• 홈페이지의 193.6배·444.6배에 대해 벤더가 직접 단서를 달았다. "we expect that these are on the higher end of real world gains."
• 타입 오류는 "mathematically impossible"이라고 한다. 스키마 일치가 보장되기 때문이다.
• 환각에 대해서는 "can't hallucinate"라고 쓰면서, 동시에 **"Our number is not empirical"**이라고 적어뒀다.
• 제약: 선택지 최대 255개(cardinality up to 255), 입력은 구조화된 텍스트 상태, 이미지 미지원("not on images (yet…)"), 가중치 비공개, 현재 얼리 액세스.

한 가지 짚어둘 것 — 한국어로 도는 제목에는 "비용 40~400배, 속도 20~200배"로 적혀 있는데, 원문에서 확인되는 문장은 속도에 대해 40x-200x다. 범위가 뒤바뀐 채 퍼진 것으로 보인다. 아래 판단은 원문 문장 기준으로 했다.

내 판단

1. 벤더가 스스로 상단이라고 적은 숫자를 내가 더 깎을 필요는 없다. 대신 그 숫자가 적용되는 범위를 봐야 한다.

444배는 "같은 코드 워크플로"에서 나온 수치고 TypeSafe가 먼저 "higher end"라고 밝혔다. 이건 벤더 발표 중에서는 정직한 축에 든다.

문제는 배수가 아니라 분모다. 저 이득은 내 워크로드 중 "System One 형태의 질의" — 분류하고, 라우팅하고, 점수 매기고, 값 하나를 고르는 호출 — 에만 붙는다. 내 LLM 비용의 90%가 긴 코드 생성이면 444배든 40배든 전체 절감은 미미하다.

그래서 먼저 할 일은 모델 비교가 아니라 내 호출을 두 통으로 나눠보는 것이다. 출력이 열거형 하나거나 점수 하나거나 불리언이면 A통, 자유 텍스트가 필요하면 B통. A통이 호출 수와 비용에서 몇 퍼센트인지부터 세어야 이 소식이 나한테 의미가 있는지 없는지 판단된다. 세어보면 생각보다 A통이 큰 경우가 많다 — 라우팅, 의도 분류, 관련성 점수, 필터링은 전부 A통인데 다들 프런티어 모델로 돌리고 있다.

2. "타입 오류 0%"와 "정답률"은 다른 말이다.

스키마에 맞는 값을 내보내는 것이 수학적으로 보장된다는 건, 잘못된 값을 고르지 않는다는 뜻이 아니다. 255개 선택지 중 하나를 반드시 내놓지만 그게 맞는 선택지인지는 별개다.

TypeSafe도 이 경계를 흐리지 않았다 — "can't hallucinate"라고 쓰고 바로 옆에 "Our number is not empirical"을 붙였다. 읽는 쪽이 앞 문장만 가져가면 안 된다. 파싱 실패가 사라지는 것이지 오판이 사라지는 게 아니다. 실무에서 이 둘을 섞으면, JSON 파싱 에러가 없어졌다는 이유로 출력 검증을 걷어내는 실수를 한다.

3. 닫힌 모델인데도 교체 비용이 낮다. 출력 계약이 좁아서다.

가중치 비공개, API 전용, 얼리 액세스 대기 명단. 평소 같으면 여기서 경고를 달았을 조건이다.

그런데 이 경우는 다르다. 주고받는 게 "이 상태에서 다음 중 하나를 확률과 함께 고르라"뿐이면, 교체할 때 옮겨야 할 것도 그것뿐이다. 프롬프트 튜닝이 쌓이지 않고, 대화 형식에 대한 의존이 생기지 않고, 출력 파서가 벤더별로 갈리지 않는다. 같은 인터페이스를 작은 오픈 모델에 constrained decoding으로 얹어도 되고, 안 되면 다시 프런티어 LLM으로 되돌려도 된다.

일반화하면 이렇다. 락인은 벤더가 닫혀 있느냐보다 인터페이스가 넓으냐로 결정된다. 좁은 계약이면 닫힌 모델도 갈아끼울 수 있고, 넓은 계약이면 오픈 모델도 못 떠난다.

모르는 것

• 직접 써보지 않았다. 얼리 액세스이고 대기 명단 단계다.
• 정확도 수치가 없다. 속도와 가격은 표가 있는데, "같은 수준의 지능"이라는 전제를 뒷받침하는 정확도 비교는 내가 확인하지 못했다. 이게 이 발표의 가장 큰 공백이다.
• 255개 선택지 제한이 실무에서 어디서 걸리는지 모른다. 태그 분류처럼 후보가 수천 개인 작업은 2단계로 쪼개야 할 텐데, 그때도 배수 이득이 유지되는지는 나와 있지 않다.
• 평가 워크플로를 만든 주체가 TypeSafe 내부라는 점은 감안해야 한다. 자체 평가다.