Jev, 과연 게임체인저인가

3줄 요약
- Jev는 글을 쓰지 않고 고르기만 하는 모델이라 빠르고 쌉니다. 다만 형식 보장 같은 일부 내세움은 이미 있던 기능입니다.
- 진짜 차별점은 확률이 정직하다는 것(캘리브레이션)입니다. 아직 독립 검증은 없습니다.
- 모델 하나보다 중요한 건 자리입니다. 사람이 보지 않는 중간 판단 층에 처음 들어온 상품이라는 점입니다.
193배 빠르고 444배 싸다.
이런 숫자를 보면 보통 두 가지 반응이 나옵니다. 하나는 "드디어 뭔가 나왔구나", 다른 하나는 "저것도 자기들이 만든 벤치마크겠지"입니다. 저는 솔직히 두 번째였습니다.
최근 TypeSafe AI라는 회사가 Jev라는 모델을 내놨습니다. 그런데 회사는 이걸 LLM이라고 부르지도 않습니다. System One Model, 그러니까 완전히 새로운 종류의 모델이라고 주장합니다.
이 글에서는 이게 정말 새로운 것인지, 아니면 마케팅 언어인지를 따져 보겠습니다. 결론부터 말씀드리면 절반은 진짜고 절반은 이미 있던 것입니다. 그런데 그 절반이 생각보다 중요한 자리를 건드립니다.
누가 만들었나
만든 사람의 이력부터 그냥 넘길 수 없습니다. Diogo Almeida는 OpenAI에서 GPT-4와 ChatGPT, 그리고 RLHF 논문에 공동 저자로 참여했습니다. 지금 모든 LLM이 거치는 "post-training"이라는 개념을 만든 팀에 있었던 사람입니다. 2년 전 OpenAI를 나와 TypeSafe를 창업했습니다.
그가 Jev를 소개한 공개 트윗은 조회수 3,600만을 넘겼습니다(9월 19일 기준). 첫 문장은 이렇습니다. "ChatGPT를 공동 발명하고 나서, 왜 초인적인 챗 모델이 AGI로 이어지지 않는지 계속 자문했다."
특이한 점은 그가 OpenAI 출신 가운데 ChatGPT를 공개적으로 비판하는 몇 안 되는 사람이라는 것입니다. 제품이 싫다는 게 아니라, 그것을 만들 때 내린 작은 결정들이 지금 AI 판의 문제 상당수를 만들었다는 입장입니다. 자기가 만든 것을 자기가 비판하는 셈입니다.
모델 이름 Jev는 제번스 역설에서 따왔습니다. 어떤 자원이 싸지면 쓰는 양이 오히려 폭증한다는 이론입니다. 지능이 충분히 싸지면 지금은 상상하지도 못하는 곳에 AI가 들어간다는 뜻이니, 이름에서부터 야심이 보입니다.
뭐가 다른가: 말하는 기계와 고르는 기계
LLM은 말하는 기계, Jev는 고르는 기계입니다.
기존 LLM은 말을 하는 기계입니다. 앞 글자를 보고 다음 글자를 정하고, 또 그다음 글자를 정하면서 답을 한 글자씩 이어 붙입니다. 느릴 수밖에 없는 구조입니다.
Jev는 말을 하지 않습니다. 고르기만 합니다.
객관식 문제만 푸는 기계라고 생각하시면 됩니다. "이 이메일은 스팸인가?", "이 명령어의 위험도는 1점에서 5점 중 몇 점인가?" 같은 질문만 받습니다. 질문 형태도 선택지 중 고르기, 점수 매기기, 예/아니오의 세 가지뿐입니다. 그리고 한 글자씩 쓰는 대신 한 번에 답을 냅니다. 속도 차이의 대부분이 여기서 나옵니다.
실제 응답 시간은 0.07초에서 0.5초 사이로, 프론티어 모델보다 40배에서 200배 빠릅니다. 가격은 입력 100만 토큰당 약 4센트이고, 출력 토큰은 아예 무료입니다. 출력이 어차피 짧기 때문입니다.
여기까지만 보면 꽤 그럴듯합니다. 그런데 제가 처음 든 생각은 이것이었습니다.
의심 하나: GPT에게 예/아니오로만 답하라고 하면 되지 않나
다들 한 번쯤 해 보셨을 겁니다. 프롬프트에 "예/아니오로만 답해"를 넣고, 추론 노력을 낮추고, 출력 토큰을 제한하는 방법입니다. 그렇다면 Jev는 무엇이 다를까요. 세 군데가 다릅니다.
첫째, 출력을 줄여도 기계는 그대로입니다. "한 단어로만 답해"라고 해도 LLM은 여전히 프롬프트 전체를 읽고 그 거대한 모델을 통째로 한 번 돌립니다. 비용은 답이 길어서가 아니라 모델이 커서 나옵니다. 소설가에게 한 단어만 쓰라고 해도 일당은 그대로 나가는 것과 같습니다. Jev는 애초에 다른 기계라서 싼 것입니다.
둘째, 형식 보장은 사실 별것 아닙니다. 회사는 "타입 에러가 구조적으로 불가능하다"는 점을 크게 내세웁니다. 그런데 이건 요즘 LLM API에서도 structured output이나 JSON 스키마 강제로 이미 됩니다. 차별점이라기보다 기본기에 가깝고, 솔직히 이 부분은 마케팅이라고 봅니다.
셋째, 여기가 진짜입니다. 확률의 품질입니다. 이걸 설명하려면 RLHF 이야기를 먼저 해야 합니다.
RLHF, 그리고 LLM이 자신만만한 이유
RLHF(사람 피드백 강화학습)는 ChatGPT를 갑자기 쓸 만하게 만든 훈련 방법입니다. 지금 쓰는 거의 모든 LLM이 이 과정을 거칩니다.
왜 필요했을까요. 인터넷 글을 통째로 먹고 다음 단어 맞히기만 배운 모델은 아는 건 많은데 질문에 답할 줄을 모릅니다. "프랑스 수도가 어디야?"라고 물으면 답 대신 "그리고 독일 수도는 어디야?"를 이어 씁니다. 인터넷에 그런 패턴이 많기 때문입니다. 그래서 사람이 가르칩니다. 세 단계입니다.
RLHF는 사람의 취향을 채점기로 만들어 모델을 그쪽으로 조정합니다.
- 모범 답안 쓰기. 사람이 "질문이 오면 이렇게 답하는 것"이라는 모범 답안을 몇만 개 씁니다.
- 순위 매기기와 채점기. 모델이 같은 질문에 답을 네 개쯤 내면 사람이 순위를 매깁니다. 이 순위 데이터로, 답을 넣으면 "사람들이 이걸 몇 점 줄까"를 예측하는 채점기를 따로 만듭니다.
- 채점기로 조정. 모델이 답을 낼 때마다 채점기가 점수를 매기고, 점수가 올라가는 쪽으로 모델을 계속 조정합니다. 사람이 일일이 채점하면 끝이 없으니 채점기로 자동화한 것입니다.
여기까지는 좋습니다. 문제는 그다음입니다.
채점기는 "사람이 좋아할 답"에 높은 점수를 줍니다. 그런데 사람은 우물쭈물하는 답보다 자신 있는 답을 좋아합니다. 그러다 보니 모델은 애매할 때도 단정적으로 말하는 버릇이 듭니다.
Almeida가 발표에서 든 예시가 있습니다. 방귀 효과음 파일을 ChatGPT에 보내고 "내가 만든 음악 어때?"라고 물으면 "으스스한 분위기가 인상적인 작품이네요" 같은 답이 돌아온다는 것입니다. 모델이 멍청해서가 아닙니다. 잘 모를 때 사람이 좋아할 것 같은 쪽으로 기우는 것이고, 그렇게 훈련됐기 때문입니다. Almeida의 표현을 빌리면 우리가 말 그대로 사람을 루프 안에 넣었기 때문입니다. RLHF라는 이름 자체가 Human Feedback이니, 목표가 정답이 아니라 사람의 만족이었던 셈입니다.
그래서 이런 일이 생깁니다. LLM에게 "이거 스팸이야?"라고 물으면 "네, 스팸입니다"라고 자신 있게 답합니다. 확률을 뽑아 보면 90퍼센트라고 나오는데, 실제로 맞는 건 60퍼센트 정도입니다. 숫자가 거짓말을 하는 것입니다. GPT-4 기술 보고서에도 이 그래프가 실려 있습니다. 사전학습만 한 모델은 확률이 정직했는데, RLHF를 거치고 나서 무너졌습니다.
캘리브레이션, 이게 진짜 차별점입니다
Jev는 답과 함께 확률을 줍니다. "스팸입니다"가 아니라 "스팸일 확률 93퍼센트"라고 답하고, 그 93퍼센트가 실제 적중률과 맞도록 훈련했다고 주장합니다. RLHF 대신 RLCD라는 방법을 썼다고 합니다. 훈련 목표가 "사람이 좋아할 답"이 아니라 "정직한 확률"인 것입니다.
여기서 제가 처음에 헷갈렸던 부분을 짚고 가겠습니다. "추론을 덜 하는데 어떻게 신뢰도가 더 높을 수 있지?"
정확도와 캘리브레이션(확률 보정)은 서로 다른 축입니다.
정확도와 캘리브레이션은 다른 축입니다. 정확도는 몇 퍼센트를 맞히느냐이고, 캘리브레이션은 자기가 몇 퍼센트를 맞힐지 스스로 아느냐입니다.
일기예보로 생각하면 쉽습니다. 강수확률 70퍼센트라고 한 날만 모았을 때 실제로 열 번 중 일곱 번 비가 왔다면, 그 예보는 잘 맞춘 것입니다. 예보 실력이 대단해서가 아니라 자기 한계를 정확히 알아서입니다. 그러니 60퍼센트밖에 못 맞히는 모델도 스스로 "60퍼센트"라고 정직하게 말하면 캘리브레이션은 만점입니다.
이게 실무에서 중요한 이유는 개발자가 선을 그을 수 있게 되기 때문입니다.
확률이 정직하면 "95% 이상만 자동 처리" 같은 규칙을 세울 수 있습니다.
확신도가 95퍼센트를 넘으면 자동으로 처리하고, 그 아래는 큰 모델이나 사람에게 넘기는 식입니다. 쉬운 90퍼센트는 싸게 처리하고 애매한 10퍼센트만 비싸게 처리하는 구조가 나옵니다. 이 기준선은 뒤에서 다시 나옵니다.
실제 사례도 있습니다. Vercel의 한 엔지니어는 명령어 안전성 분류기를 Jev로 바꿔 5배에서 18배 빨라졌고 정확도도 올랐다고 했습니다. Bryo AI의 CTO는 이메일 분류에서 Gemini가 근소하게 더 정확했지만 10배에서 20배 비쌌다면서, 진짜 확률을 돌려주는 유일한 모델이라는 점을 더 높이 샀습니다.
X에서 반응이 컸던 데모도 하나 있습니다. Jarrod Watts라는 개발자가 Jev로 트레이딩 봇을 만들었습니다. 자산 가격 피드를 넣으면 Jev가 사야 할지 팔아야 할지를 확률과 함께 판단하고 실제로 거래를 실행합니다. 조회수는 100만을 넘겼습니다.
이 데모가 돈을 벌었다는 이야기는 아닙니다. 10초짜리 영상이고 수익률 검증 같은 것도 없습니다. 다만 구조는 흥미롭습니다. 트레이딩 판단은 초 단위로 계속 내려야 하고, 매번 확신도가 다르고, 애매할 때는 그냥 하지 않는 게 답인 경우가 많습니다. 확률이 정직하다면 "85퍼센트 이상일 때만 진입" 같은 규칙을 세울 수 있습니다. LLM에게 매 틱마다 물어보는 것보다는 이쪽이 맞을 가능성이 조금은 있어 보입니다. 다만 "조금"입니다. 시장 데이터로 학습한 적이 없는 모델이 시장을 잘 읽을 이유는 없으니까요.
그런데 진짜 경쟁자는 따로 있습니다
여기서 조금 냉정해질 필요가 있습니다. Jev의 진짜 비교 대상은 "GPT에게 예/아니오 시키기"가 아니라 직접 만든 작은 분류 모델입니다.
스팸 분류 하나라면 작은 모델을 파인튜닝하는 쪽이 더 싸고 더 빠릅니다. 그리고 이건 예전부터 다들 하던 일입니다. 새로운 것이 아닙니다.

Jev의 실제 자리는 그 중간입니다. 데이터를 모으고 라벨링하고 학습시키는 수고 없이 LLM처럼 API로 불러 쓰는데, 값은 작은 분류기에 가까운 것입니다.
Armin Ronacher의 말이 정곡을 찌릅니다. "LLM이 워낙 싸고 보조금까지 받다 보니 우리가 창의적일 필요가 없었을 뿐." 즉 Jev가 놀라운 게 아니라, 우리가 그동안 게을렀던 것입니다.
유보할 지점들
지금까지가 실(實)이었다면 허(虛)도 짚어야 합니다.
- 벤치마크를 자기들이 만들었습니다. 회사도 인정하는 부분입니다. 워크플로를 자사 모델 팀이 설계했으니 편향 가능성이 있고, 정답 기준을 GPT-6와 Fable 5.1의 평균으로 잡았으니 기준 자체가 특정 모델 쪽으로 기울어 있습니다. 공개 벤치마크 비교도 없습니다. 193배라는 숫자도 "실제 이득의 상단에 가까울 것"이라고 회사가 직접 써 두었습니다.
- 가격이 보조금이 아니라는 걸 증명할 수 없다고 역시 회사가 직접 밝힙니다.
- 환각을 없앤 게 아니라 사용자에게 넘긴 면이 있습니다. 확률을 준다는 건 판단을 개발자에게 넘긴다는 뜻이기도 합니다. 임계값을 잘못 잡으면 조용히 틀린 결정이 파이프라인 깊숙이 흘러갑니다. 에러가 나지 않으니 더 무섭습니다.
- 아키텍처를 공개하지 않습니다. 오픈웨이트 LLM 위에 올린 것 아니냐는 의심이 있고, 아직 반박이 없습니다.
- 할 수 있는 일이 좁습니다. 코드 생성, 글쓰기, 설명은 못 합니다. 선택지도 255개까지이고, 이미지도 아직 받지 못합니다.
4번의 의심에 무게를 싣는 일이 공개 사흘 만에 벌어졌습니다. Vercel CTO Jared Palmer가 Kev라는 것을 올렸습니다. Qwen2.5의 0.5B 모델 위에 Jev와 호환되는 API를 얹은 오픈소스 결정 모델로, 맥북에서 학습하고 돌릴 수 있는 크기입니다.
물론 Jev만큼 잘한다는 이야기는 아닙니다. 5억 파라미터짜리 장난감 버전입니다. 하지만 두 가지를 보여 줍니다. 첫째, "API 모양"은 며칠이면 따라 만들 수 있다는 것. 둘째, 앞에서 말한 "진짜 경쟁자는 작은 모델"이라는 말이 이론에 그치지 않는다는 것. 벌써 누군가 만들고 있습니다.
이 정도면 쓰지 않을 이유가 꽤 많습니다. 그런데 이 모델이 왜 지금 나왔는지를 생각하면 이야기가 조금 달라집니다.
사람이 보는 일, 사람이 안 보는 일
Almeida는 Jev 공개 전 한 발표에서 재미있는 질문을 던졌습니다. AI가 미해결 수학 문제를 푼다면서, 왜 고객 응대에서 실제 결정을 내리는 데는 여전히 사람이 필요할까요. 수학이 훨씬 어려운 일인데 말입니다.
그의 답은 두 일의 종류가 다르다는 것입니다. 수학 문제 풀기나 코딩 돕기는 사람이 옆에서 보면서 만족하는 게 목표인 일입니다. 반면 고객 응대 결정은 서버에서 조용히 돌아가면서 아무도 보지 않는 게 목표인 일입니다. 앞의 것을 assistance(보조), 뒤의 것을 automation(자동화)이라고 부릅니다.
대체가 아니라 분리입니다. 사람이 보는 일과 안 보는 일은 목표가 다릅니다.
RLHF로 만든 LLM은 앞의 일만 잘합니다. 사람의 만족이 목표 함수였으니 당연합니다. 사람이 보지 않는 일에는 애초에 목표가 맞지 않습니다. 여기서 그가 던진 도발적인 문장이 있습니다. Claude Code도 여전히 assistance 시대다. 코드가 돌아가게 하는 것만이 목표였다면 지금 같은 대화 방식이 아니었을 것이고, 그것도 결국 사람을 만족시키는 일이라는 것입니다.
다만 오해하시면 안 되는 점이 있습니다. RLHF가 틀렸다는 이야기가 아닙니다. 디자인이나 글쓰기, 대화처럼 "사람이 좋아하느냐"가 곧 정답인 일이 있습니다. 이런 일에는 사람의 선호 말고 다른 기준이 없습니다. 웹 디자인에 정답지가 있을 리 없으니까요. 그러니 이 영역은 계속 RLHF 계열이 맞습니다. Almeida 본인도 RLHF는 잘못이 아니라 예상하지 못한 우회로였다고 했고, ChatGPT는 계속 남을 것이며 자신도 Claude Code를 계속 쓴다고 했습니다. 그가 말하는 건 대체가 아니라 분리입니다. 사람이 보는 일은 지금처럼 가고, 사람이 안 보는 일만 다른 방식으로 가자는 것입니다.
굳이 하나 덧붙이면, RLHF가 취향 영역에서도 완벽한 건 아닙니다. AI가 만든 웹사이트가 다 비슷하게 생긴 것, 보라색 그라데이션에 둥근 카드를 떠올려 보시면 됩니다. 채점기가 다수가 무난하게 좋아할 것에 점수를 주니 모델이 평균 취향으로 수렴하는 것입니다. 다만 이건 이 글의 주제가 아니니 여기까지만 하겠습니다.
이 관점으로 우리 시스템을 다시 보면 층이 세 개로 보입니다.
비어 있던 가운데 층에 Jev가 들어갑니다.
- 맨 위는 사람과 대화하는 층입니다. LLM의 자리입니다. 비싸고 느리지만 사람이 보고 있으니 괜찮습니다.
- 맨 아래는 0.01초 단위로 반응하는 층입니다. 로봇 컨트롤러나 게임 폴리시 네트워크의 자리로, 그 일만 할 줄 압니다.
- 문제는 가운데입니다. 아무도 보지 않는데 초 단위로 내려야 하는 판단입니다. 이 메일은 스팸인가, 이 요청을 사람에게 넘길까, 이 명령어를 실행해도 되나. 지금은 이 일을 위층의 LLM이 억지로 떠맡고 있습니다.
LLM에게 시키자니 목표도 맞지 않고 비쌉니다. 전용 모델을 만들자니 학습 데이터가 없습니다. 매번 새로운 상황이라 라벨을 모을 수 없기 때문입니다. 그래서 다들 어쩔 수 없이 비싼 어시스턴트에게 "이거 스팸이야?"를 백만 번 묻고 있었던 것입니다. Jev가 들어가는 자리가 정확히 여기입니다.
중요한 건 Jev가 아는 게 많다는 점이 아닙니다. 학습 데이터도 전부 합성 데이터라고 하고, 세상 지식으로 치면 LLM 근처에도 못 갑니다. 중요한 건 판단을 내놓는 모양입니다. 빠르고, 선택지 중에서 고르고, 확신도를 숫자로 줍니다. 그리고 그 확신도가 사람의 눈치를 보지 않습니다. 사람이 보지 않는 일에 맞게 훈련됐기 때문입니다.
중간층의 본질은 사실 위아래로 나누는 일입니다. 확실하면 바로 실행하고, 애매하면 위층에 묻습니다. 그 판단을 하려면 자기가 얼마나 확신하는지를 정직하게 알아야 합니다. 앞에서 본 95퍼센트 기준선, 즉 캘리브레이션이 여기서 값을 합니다.
그래서 저는 Jev를 이렇게 정리했습니다. 성능이 뛰어난 모델이 아니라, 비어 있던 층에 처음 들어온 상품입니다.
지금 운영하는 서비스에서 큰 모델에게 예/아니오만 묻는 호출이 몇 개나 되는지 한번 세어 보시길 권합니다. 그게 다 이 중간층입니다.
이 층이 자라면 어떻게 될까
여기부터는 제 추측입니다. 근거보다 상상이 많으니 감안하고 읽어 주시기 바랍니다.
게임으로 생각해 보면 이 세 층이 잘 보입니다. 롤에서 0.007초 만에 스킬을 피하는 건 맨 아래층입니다. 이건 지금도 Jev가 못 하고, 앞으로도 전용 모델의 몫일 가능성이 높습니다. 상황을 텍스트로 적어 API를 부르는 순간 이미 늦기 때문입니다. 반대로 "이번 판 조합상 우리는 후반을 봐야 한다"는 맨 위층입니다. LLM이 하면 됩니다. 그렇다면 가운데는 "지금 이 각에 들어가도 되나", "이 아이템을 지금 사는 게 맞나" 같은 판단입니다. 3초 안에만 답이 오면 되고, 애매하면 안 하면 되는 판단들입니다. 사람으로 치면 경험에서 나오는 감에 해당합니다.
실제로 이걸 해 본 사람이 있습니다. Phil Youssef라는 개발자가 1998년 원조 스타크래프트를 브라우저에서 돌리고 Jev에게 조종을 맡겼습니다. 게임 상태를 구조화해서 넘기면 Jev가 명령을 고르고, 하네스가 실제 마우스 클릭과 단축키로 실행하는 구조입니다(코드). 미션 하나를 클리어했습니다.
그런데 제가 가장 눈여겨본 건 성공 자체보다 설명 맨 끝의 한 줄이었습니다. "추론 중에는 게임을 일시정지한다." 즉 실시간은 아직 안 됩니다. 반응 속도가 느려서라기보다 게임 화면을 텍스트로 옮기고 API를 왕복하는 구조 자체의 한계입니다. 맨 아래층에는 여전히 못 들어가고, 중간층에서 "다음에 뭘 할지"를 고르는 역할까지가 지금 Jev의 자리라는 게 실사용으로 확인된 셈입니다.
기계가 실시간 게임에서 사람을 못 이긴다는 건 옛날 이야기입니다. 도타도 스타크래프트도 2019년에 이미 사람을 넘었습니다(OpenAI Five, AlphaStar). 그런데 우리는 그걸 특이점이라고 느끼지 않습니다. 그 모델들이 자기 게임 밖으로 한 발짝도 나가지 못했기 때문입니다. 알파고는 체스를 두지 못합니다.
그러니 진짜 질문은 "언제 사람을 넘을까"가 아니라 "언제 하나의 모델이 여러 판을 넘을까"입니다.
만약 Jev 같은 중간층 모델이 텍스트를 넘어 화면이나 상태를 직접 받게 된다면, 게임마다 새로 만들지 않아도 되는 판단 계층이 생깁니다. 모든 게임에서 프로를 이기는 물건은 아닐 겁니다. 대신 누구나 학습 없이 갖다 쓸 수 있는 바닥선이 생깁니다. 지금은 그런 걸 만들려면 OpenAI급 자본이 필요합니다. 그게 API 호출 한 줄이 된다면 게임보다 로봇이나 업무 자동화 쪽에서 먼저 터질 것입니다. Almeida가 말한 바로 그 "사람이 안 보는 일"입니다.
정리하며

Almeida는 발표에서 SaaS가 2019년 이후 챗봇 하나 옆에 붙은 것 말고는 바뀐 게 없다고 했습니다. AI가 이렇게 발전했는데 소프트웨어 자체는 더 똑똑해지지 않았고, 만드는 비용만 싸졌다는 것입니다.
그러니 중요한 건 Jev를 쓰느냐 마느냐가 아니라, 내 시스템에 사람이 안 보는 판단이 몇 개나 있는지를 알아차리는 것입니다. 아마 많을 겁니다. 지금은 사람 보라고 만든 모델이 억지로 떠맡고 있을 뿐입니다.
저도 이번 주에 분류기 하나를 Jev로 바꿔 직접 돌려 볼 생각입니다. 결과가 나오면 다시 정리해서 올리겠습니다.
참고 자료
- Diogo Almeida의 Jev 공개 트윗과 소개 영상
- Jarrod Watts의 Jev 트레이딩 봇 데모
- Jared Palmer의 Kev-0.5B 공개 트윗 · GitHub: jaredpalmer/kev
- Phil Youssef의 StarCraft 데모 · GitHub: phyous/tsai-sc
- Jev 벤치마크 워크플로 원자료 (evals.typesafe.ai)
더 읽어 볼 만한 글: