문장을 한 줄도 쓰지 않는 AI 모델이 나왔습니다. 미리 정해 둔 질문에 정해 둔 선택지 중 하나를 고르고, 옆에 확률을 붙여 돌려주는 게 전부입니다. 설명도 이유도 없고요. 대신 빠릅니다. 이름은 Jev, 만든 곳은 TypeSafe라는 회사입니다. 이 회사가 공개한 평가표를 보면 Jev와 앤트로픽 소네트 5는 정확도가 67.8%로 똑같습니다. 그런데 판단 한 건에 Jev는 0.4초, 소네트 5는 78.1초가 걸렸습니다.

공개된 지 일주일 남짓인데 벌써 시끄럽습니다. 한쪽에서는 Vercel의 AI 게이트웨이에서 역대 가장 빨리 채택됐다는 집계가 나왔고, 다른 쪽에서는 예전부터 쓰던 분류 모델과 뭐가 다르냐는 말이 같이 커졌죠. 그런데 Jev가 무엇인지 설명하는 글은 이미 많습니다. 그래서 여기서는 정의보다, 이걸 실제로 붙였을 때 내 파이프라인에서 뭐가 바뀌고 무엇을 신경 써야 하는지를 중심으로 정리했습니다.

이 글의 수치와 인용은 TypeSafe 공식 블로그·공식 문서·자체 평가 사이트, 그리고 외부에서 직접 재본 실측 기록에서 가져왔습니다.

1. 지금 무슨 일이 벌어지고 있나

공개는 9월 15일이었습니다. TypeSafe AI가 2년 동안 회사를 외부에 알리지 않다가, System One Model이라는 새 부류와 그 첫 모델 Jev를 함께 내놨는데요. CEO인 디오고 알메이다(Diogo Almeida)는 오픈AI에서 InstructGPT와 RLHF 연구에 참여했고 그 작업이 챗GPT의 바탕이 됐다고 블로그에 적었습니다.

증폭점은 사흘 뒤였죠. Vercel은 9월 18일 블로그에서 Jev가 자사 AI 게이트웨이 역사상 가장 빨리 채택된 모델이고 출시 24시간째에 유료 팀의 13% 가까이가 쓰고 있었다고 밝혔습니다. 다만 초기 채택이 지속되는지가 다음 시험이라고 덧붙였고요. 9월 20일에는 웨이트리스트가 없어져, 공개 닷새 만에 누구나 바로 쓸 수 있게 됐습니다.

같은 기간 반대편도 똑같이 커졌습니다. 해커뉴스 메인 스레드는 1,900점과 댓글 500개를 넘겼고 창업자는 자신이 CEO임을 밝히며 직접 답을 달았는데요. 그 스레드에서 “이거 그냥 제로샷 분류기 아니냐”는 요약이 나왔습니다. 나흘 앞선 9월 11일 글에서 회사가 표준 벤치마크 표를 내지 않겠다고 선언해 둔 터라, 점수가 좋았으면 공개했을 거라고 의심하는 댓글도 달렸고요.

한쪽 말만 옮겨서는 절반밖에 전하지 못합니다. 그래서 원문을 직접 열었습니다.

2. 문장을 쓰지 않는 모델이 겨냥한 자리

Jev가 무엇인지는 못 하는 일로 잡는 편이 빠릅니다. 왜 그렇게 판단했는지 물어볼 수 없고 답을 길게 풀어 달라고 할 수도 없습니다. 애초에 대화가 성립하지 않고요. 창업자는 해커뉴스에서 문자열과 모든 순차 자료구조가 아예 허용되지 않는다고 못 박았습니다. 할 수 있는 건 미리 정해 둔 질문에 정해 둔 선택지 중 하나를 고르는 일뿐이죠. 옆에 확률을 붙여서요.

소프트웨어는 문장을 읽을 줄 모릅니다. 문장을 읽는 건 사람이죠. 그런데 우리는 지금까지 소프트웨어가 쓸 판단을 굳이 문장으로 받아서 다시 코드로 뜯어 왔습니다.

회사가 낸 개발자용 문서를 보면 질문 유형은 셋뿐입니다. 여럿 중 하나를 고르는 Choice, 척도 위의 값을 매기는 Score, 예 또는 아니오를 묻는 Noul입니다. Noul은 참·거짓 대신 0에서 1 사이 확률값 하나를 돌려주고요. 입력은 텍스트만 받습니다.

‘LLM에게’는 자연어 지시로 route: fast_mode를 반환하는 예시, ‘Jev에게’는 JSON 스키마 질의로 fast_mode 0.97·full_agent 0.03 확률을 반환하는 예시를 나란히 비교 — 왼쪽은 사람에게 설명하는 글이고, 오른쪽은 기계에 거는 계약이다. 돌아오는 답도 다르다. 한쪽은 고른 값 하나뿐이고, 다른 쪽은 선택지마다 확률이 붙어 온다 <출처: 작가>

이런 출력이 쓰이는 데는 소프트웨어 안에 널려 있습니다. 스팸인가, 이 티켓은 어느 팀으로 보낼까, 이 건은 사람이 다시 봐야 하나. 아무도 그 문장을 읽지 않는 판단들이죠. 원래 이런 판단은 파인튜닝한 분류기가 맡던 일입니다. 일본 supa Lab은 라벨 붙은 데이터가 수천 건 있으면 직접 학습이 빠르고 싼 경우가 많지만 라벨이 없고 채점 기준이 자주 바뀌면 Jev가 맞는다고 갈랐습니다.

그럼 “그냥 분류기 아니냐”는 반론은 어떻게 될까요. 해커뉴스에서 한 이용자가 Jev를 제로샷 분류기라고 요약했습니다. 예시를 따로 학습시키지 않고 원시 텍스트를 받아 바로 분류하는데 프런티어급 LLM만큼 정확하다는 뜻인데요. 그 정확도는 어디까지나 회사 주장이라는 단서도 붙였습니다. 창업자는 여기에 두 단어로 답했습니다. “정확히 맞습니다.”라고요. 반면 공식 FAQ는 “Jev는 작지도 않고 LLM도 아닙니다.”라고 적습니다. 모순처럼 보이지만 앞은 하는 일에 대한 답이고 뒤는 만듦새에 대한 답이죠.

그러면 기존 LLM 대신 이걸 쓸 이유는 뭘까요. 흔히 꼽히는 답은 타입이 보장된다는 쪽입니다. 답의 형식과 값의 범위를 미리 못 박아 둔 규격, 그러니까 스키마를 벗어나는 답이 나올 수 없다는 얘기죠. 그런데 실측은 그 답을 뒷받침하지 않았습니다. supa Lab이 4개 과제 208건을 경량 LLM 5종과 함께 돌렸더니 스키마 위반은 다섯 모델 모두 0건이었거든요. JSON 스키마를 강제하니 LLM 쪽도 라벨 밖의 값을 돌려주지 않았습니다.

환각을 안 한다는 건 결국 스키마를 지킨다는 뜻이고, 스키마는 기존 LLM에 강제해도 지켜집니다. 그러니 Jev만 가진 차별점으로 남는 건 하나뿐입니다. 자기가 얼마나 맞힐지를 안다는 것.

3. 빠른 이유는 성능이 아니라 포기한 것에 있다

그 말이 사실인지 따지려면 이 모델이 왜 빠른지부터 봐야 합니다.

LLM은 글자 하나를 고른 다음 그 글자를 보고 다음 글자를 고릅니다. 순서대로 쌓는 구조라 답이 길어질수록 시간도 늘어나죠. Jev는 그 일을 아예 하지 않습니다. 창업자 설명대로 문자열과 모든 순차 자료구조가 금지돼 있어서 출력을 전부 병렬로 계산할 수 있고 그래서 출력 토큰 비용이 없습니다. 가격표에도 입력 100만 토큰당 0.042달러, 출력은 무료라고 적혀 있고요.

그럼 학습은 뭐가 달랐을까요. 지금 우리가 쓰는 모델은 대부분 RLHF(사람 피드백 기반 강화학습)를 거쳤습니다. 사람이 선호하는 응답을 내도록 학습시켜 사전학습 모델을 챗봇으로 바꿔 놓은 방식이죠. 이 회사가 쓴 건 RLCD(보정된 결정을 위한 강화학습)인데, 생성된 텍스트 대신 결정과 보정된 확률을 돌려주도록 학습시킨다고 적혀 있습니다.

새 학습 알고리즘이 왜 필요했냐는 FAQ 질문에 회사는 어느 랩이든 RLHF로는 결국 같은 걸 잘하게 만든다고 답했는데요. 사람 평가자가 선호하는 텍스트를 만드는 일인데, 채팅 제품에는 맞았지만 자동화에는 틀린 목표라는 겁니다. 문서의 경고 박스에는 더 직접적으로 적혀 있습니다. “사람에게 설득력 있는 출력이라고 해서, 사람이 지켜보지 않는 자동화에 쓸 만큼 믿을 만한 건 아닙니다.”

여기서 캘리브레이션(calibration), 우리말로 보정이라는 말이 나옵니다. 회사 문서의 정의는 이렇습니다. 잘 보정된 모델의 예측을 많이 모아 놓고 보면 확률 0.2가 매겨진 결과는 20%쯤 일어나고 0.8이 매겨진 결과는 80%쯤 일어납니다. 일기예보와 같은 이야기죠. 비 올 확률 70%라고 한 날들을 모았을 때 그중 일곱 번쯤 비가 왔다면 그 예보는 잘 보정된 겁니다. 오늘 비가 왔는지만 봐서는 예보가 좋은지 알 수 없고요.

그래서 보정이 잘된 모델은 잘 맞히는 모델과 다릅니다. 0.8이라고 말한 판단들이 실제로 열 번에 여덟 번쯤 맞는 모델이죠. 맞히는 능력과 자기가 얼마나 맞힐지를 아는 능력은 서로 다릅니다. 회사도 같은 말을 직접 적어 뒀습니다. 이 비율은 예측 묶음을 설명하는 것이지 개별 답 하나를 보증하지는 않는다고요.

확률 0.8이라 말한 판단 10개 중 8개가 맞은 표와, 말한 확률 0.8과 실제 적중 0.8이 같아 ‘잘 보정된 상태’로 표시된 Jev 보정 개념도 — 보정이 잘됐다는 건 자기가 얼마나 맞힐지를 안다는 뜻이다. 확률 0.8이라고 말한 판단들을 모았을 때 실제로 열에 여덟쯤 맞으면 잘 보정된 상태다 <출처: 작가>

정확도만 놓고 보면 Jev는 최상위가 아닙니다. 회사가 직접 공개한 평가에서도 다른 회사 모델 셋보다 낮고요. 속도는 포기한 것에서 나왔습니다.

4. 0.1초와 8초 사이에 있는 것

한 번 물어보고 8초를 기다리는 건 그냥 조금 기다리는 일입니다. 커피를 한 모금 마시면 끝나죠. 회사도 그 점은 인정하고 시작합니다. 공식 블로그 비교표에는 프런티어 모델이 묻고 답을 받기까지 3초에서 329초가 걸린다고 적혀 있고 바로 옆에 “사람과 주고받기에는 충분히 빠르지만, 코드에 통합하면 큰 병목”이라는 문장이 붙어 있습니다.

반복되면 이야기가 달라집니다. 노르웨이의 한 개발자가 정부 공청회에 제출된 의견서 24건을 놓고 같은 질문을 돌려 보니 Jev의 중앙값 지연은 0.32초였는데 비교한 DeepSeek V4.1 Flash는 추론을 끄면 2.7초, 켜면 26초였습니다. 1,000건당 비용은 0.22달러 대 1.31달러, 추론을 켠 쪽은 3.08달러였고요. 오픈소스 프로젝트 notra도 들어온 대화를 어느 모델에 넘길지 고르는 라우터를 Jev로 바꾼 뒤 지연이 1.3초에서 307밀리초로 줄었다고 PR에 적었습니다. 다만 이 노르웨이 개발자는 문서 24건과 얼리액세스 모델로는 첫인상이지 벤치마크가 아니라고 못 박았습니다.

어떤 일에서는 느리면 아예 못 씁니다. 게임에서 대사 하나를 고르는 데 몇 초가 걸리면 그 장면은 성립하지 않습니다. 신호가 바뀐 지 한참 뒤에 출발해도 된다고 알려주는 보조 장치도 마찬가지고요. 회사도 환각한 도구 호출이 에이전트에서는 불편한 정도지만 지연 보증이 걸린 시스템의 일부라면 완전히 치명적이라고 문서에 적었습니다.

그러니까 8초대는 느린 게 아니라 그 자리에 못 들어가는 겁니다. 0.3초대는 빠른 게 아니라 그 자리에 들어갈 수 있게 된 것이고요. 비용도 마찬가지입니다. 한 건에 몇십 원 차이는 아무 일도 아니지만 같은 판단이 요청마다 한 번씩 돌면 예산이 달라집니다.

5. 벤더가 내민 숫자를 어떻게 읽어야 할까

배수부터 보죠. 같은 회사가 채널마다 다른 숫자를 씁니다.

Jev 배속 표: 창업자 X 트윗 20~200배, 공식 블로그 비교표 40~200배, 홈페이지 헤드라인 193.6배·444.6배 저렴·빠름으로 채널마다 다른 배수 제시

셋이 서로 다른 비교를 하고 있어서 벌어지는 일입니다. 홈페이지의 193.6배·444.6배에는 회사가 스스로 단서를 달아 뒀는데요. 이 숫자는 자사 워크플로 평가에서 나온 것이고, 현실에서 얻는 이득의 위쪽 끝에 가깝다고 본다는 겁니다. 공개된 평가 표의 값으로는 그대로 나오지도 않고요.

배수 대신 볼 만한 건 정확도를 맞춰 놓고 잰 비용과 지연입니다. 회사 자체 평가에서 Jev와 앤트로픽 소네트 5는 평균 정확도가 67.8%로 같은데, 건당 시간은 0.4초 대 78.1초, 건당 비용은 0.0004달러 대 0.1174달러입니다. 여기서 67.8%는 워크플로 네 개의 평균값입니다. 같은 표에서 정확도 1위는 Jev가 아닙니다. 위에 다른 회사 모델이 셋 있는데 sol 74.1%, 앤트로픽 오퍼스 5 73.1%, terra 67.9% 순입니다. 속도와 비용을 보고 고르는 모델이라는 얘기죠.

측정 조건도 봐야 합니다. 회사는 공개한 평가를 어디서 돌렸는지 블로그에 적어 뒀습니다. “우리는 정말로 그만큼 빠릅니다. 다만 우리가 공개한 평가는 대체로 서해안에 있는 우리 랩톱에서 돌린 것이고요.” 한국에서 부르면 여기에 네트워크 왕복이 더해지는데, 얼마가 붙는지는 직접 재보지 않으면 알 수 없습니다. 언어도 걸립니다. 회사 문서는 영어가 주된 학습 언어이고 CJK를 포함한 다른 언어는 처리는 되지만 동등하게 잘되지는 않는다면서, 영어가 아닌 작업을 맡기기 전에 자기 콘텐츠로 테스트하고 라우팅할 때는 확신도를 면밀히 보라고 적었습니다.

그렇다고 한국어로는 못 쓴다고 단정할 근거도 없습니다. 일본어 4개 과제 208건 실측에서는 영어와 차이가 나지 않았고 노르웨이어 24건에서도 읽기 자체는 문제가 없었거든요. 회사 말과 실측이 어긋나는 겁니다. 호스팅 API가 미국 리전뿐이라는 supa Lab 기사도 있어, 국내 보관 요건이 있는 팀이라면 현재 구성으로는 맞추기 어려울 수 있고요.

결과는 과제마다 다릅니다. notra는 라우터를 바꾼 뒤 수동 라벨 153건 기준 정확도가 81.7%에서 90%로 올랐다고 적었고, 반대로 공개 저장소에 올라온 피싱 메일 2,000건 벤치마크에서는 Jev가 클로드 하이쿠 4.5에 졌습니다.

회사도 공개 벤치마크 점수를 내지 않는 대신 사용자가 자기 용례에 맞는 평가를 직접 만들도록 권한다고 FAQ에 적었습니다. 물론 이 정직함 자체가 마케팅이라는 반론도 해커뉴스에 있고요. 그래서 직접 봐야 할 건 셋입니다. 내 대표 태스크로 작은 평가 세트를 만드는 것, 배수 대신 정확도를 맞춰 놓고 비용과 지연을 비교하는 것, 내 리전에서 한국어로 재보는 것. 이 셋은 남의 숫자로 채울 수 없습니다.

6. 바뀌는 건 모델이 아니라 파이프라인 모양이다

지금까지 우리 코드는 모델이 준 답을 전부 같은 무게로 받아 왔습니다. 확신에 차서 고른 답이든 간신히 고른 답이든 코드 입장에서는 똑같은 문자열이었으니까요. LLM에 물어보고 문장을 받아 파싱한 다음 분기하는데 그 분기는 무엇으로 판정했느냐만 봅니다.

확률이 함께 오면 분기가 하나 더 생깁니다. 그 판정을 그대로 써도 되느냐를 묻는 분기죠. 모델을 갈아 끼우는 선에서 끝나지 않고 파이프라인을 다시 그리게 되는 이유입니다.

회사도 이 구조를 문서로 권합니다. 확신도가 높으면 자동 처리, 중간이면 사용자 확인이나 검토 표시, 낮으면 행동하지 말고 사람에게 넘기라고 적혀 있고, 그 경계를 어디에 그을지는 걸린 것이 무엇이냐에 달렸다는 문장이 바로 뒤에 붙어 있습니다. 같은 문서의 의도 분류 편에는 더 구체적으로 적혀 있고요. 메시지를 먼저 분류해 보내면 비싼 자원은 그게 정말 필요한 요청에만 불려 나온다는 겁니다. 쉬운 다수를 싸게 처리하고 어려운 소수에 예산을 몰아 주니, 비용이 한 덩어리에서 계단 몇 개로 나뉘는 셈이죠.

확률값이 함께 오면 높음은 자동 처리, 중간은 사용자 확인·검토 표시, 낮음은 사람에게 넘기는 3단 분기 파이프라인 구조도 — 확률이 함께 오면 신뢰도에 따라 경로가 나뉜다. 경계를 어디에 그을지는 걸린 것이 무엇이냐에 달렸으므로 그림의 세 구간은 예시일 뿐이다 <출처: 작가>

다만 이 구조 전체가 확률이 정직하다는 전제 위에 서 있습니다. 확률이 정직하지 않으면 그 분기는 아무 의미가 없고요. 그래서 밖에서 직접 재본 기록을 찾아봤습니다.

먼저 모델이 스스로 붙인 확신도입니다. supa Lab이 4개 과제 208건을 돌린 실측 가운데 라우팅 과제를 보면, 확신도 0.9 이상만 자동 처리로 남겼을 때 정확도는 100%가 되는데 그러고도 건수의 92.5%가 통과했습니다. 반대로 같이 비교한 Gemini 3.5 Flash-Lite와 Qwen3.7 Flash는 틀린 답에도 0.95에서 1.0의 확신도를 스스로 신고했고, ECE는 0.12에서 0.16으로 나왔고요. ECE는 기대 보정 오차를 줄인 말인데, 모델이 말한 확률과 실제 정답률이 평균 얼마나 벌어지는지를 재는 값이고 낮을수록 좋습니다. 자기 신고 확신도는 임계값으로 쓰기 어렵다는 게 필자의 결론이었습니다. 경량 LLM에 같은 분기 구조를 짜면 무너진다는 뜻입니다.

다음은 모델이 내놓은 확률 자체입니다. 앞서 나온 노르웨이 실측에서 예·아니오 판정 192건을 확률 구간별로 묶으면 이렇게 나왔습니다.

Jev 확률 구간별 판정 수와 실제 yes 비율 표: 0~0.1구간 14건 0%, 0.7~0.9구간 38건 97%, 0.9~1.0구간 43건 98%로 양끝은 신뢰도 높고 0.3~0.7 중간 구간 41건은 34%로 불확실 — Jev가 확실하다고 한 판정은 거의 그대로 맞았다. 애매하다고 한 41건은 실제로도 애매했다. 다만 정답을 사람이 아니라 다른 AI 모델이 매겼으니, 그 모델과 얼마나 같았는지로 읽어야 한다 <출처: lindfors.no>

필자는 확신이 높은 판정을 받아들이고 나머지는 더 느리더라도 나은 모델이나 사람에게 보내는 게 실무에서 Jev를 쓰는 방식이라고 적었습니다. 물론 본인이 문서 24건짜리 첫인상이라고 못 박았으니 벤치마크로 읽어서는 안 됩니다. 뜻밖의 결과도 하나 있습니다. 같은 필자가 질문 문구를 더 정교하게 다듬었더니 보정 오차가 두 배 넘게 나빠졌거든요. 그래서 Jev에 쓸 질문은 책상 건너편 동료에게 묻듯이 쓰고 깨알 같은 단서는 자기 코드에 두라고 권했습니다. 질문 문구 하나로도 보정이 흔들린다는 겁니다.

그리고 새 책임이 하나 생깁니다. 임계값을 누가 정하느냐죠. 0.95로 할지 0.85로 할지는 모델이 정해 주지 않습니다. 회사 문서도 올바른 임계값은 도메인과 용례에 달렸으니 보수적인 값으로 시작해 자기 데이터로 시험하고 조정하라고 적었고요. 같은 문서 안에서도 예시 숫자가 제각각이니 권장값이 아니라는 뜻입니다. 해커뉴스에서는 이걸 다르게 읽었습니다. 한 이용자는 무엇을 허용하고 무엇을 막을지는 여전히 자기가 정해야 하고 어떤 잘못된 동작이 워크플로를 통과하는지도 자기 데이터로 시험해야 하는데, 그렇게 개발자에게 도로 넘어오는 일이 적지 않다고 적었습니다. 회사는 유연함이라 부르고 이용자는 떠넘겨진 일이라 부르지만 둘 다 같은 것을 가리킵니다.

직접 봐야 할 건 여기서도 셋입니다. 임계값은 코드에 박아 두기보다 설정으로 빼 두는 편이 낫지 않을까 싶습니다. 회사 문서 안에서도 숫자가 서로 다르고 회사 자신이 조정하라고 썼으니까요. 확신도와 정확도를 그래프로 같이 놓고 임계값을 시험하라는 게 회사 권고인데, 그러려면 경로별 통과 건수부터 기록해 둬야 합니다. 마지막은 질문 문구를 바꿨을 때 보정을 다시 재보는 일이고요.

7. 그래서 신경 써야 할 것들

임계값을 잘못 잡으면 어떻게 되는지부터 봐야 합니다. 이 모델은 틀려도 티가 나지 않습니다. 형식이 멀쩡하니 에러가 뜨지 않고 잘못된 결정이 로그에 정상으로 남습니다. 승인하면 안 될 건을 승인해도 스키마는 통과하고 모니터링 화면에는 아무 일도 없는 것처럼 보이고요.

회사도 이 부분은 솔직하게 적었습니다. 출시 글의 환각 그래프에 0%를 적은 근거를 두고 “우리 수치는 실증적인 게 아닙니다. 스키마 일치는 보장되니, 그래프에 0%를 자신 있게 넣을 수 있는 거죠.”라고 썼거든요. 창업자도 해커뉴스에서 이 모델들은 확률적이라 확신에 차서 틀리는 것도 가능하다고 인정했습니다. 한 해커뉴스 이용자는 같은 지점을 더 날카롭게 짚었습니다. 해서는 안 될 동작을 승인해도 스키마는 지켜진다고요.

회사 문서에는 더 구체적인 예가 있습니다. 같은 티켓에 같은 질문을 두 형식으로 물었더니 한쪽은 확률 0.22로 애매하다고 하고 다른 쪽은 0.99로 아니라고 단언했다는 예시입니다. 두 응답 모두 형식은 완벽한데 서로 안 맞고 에러도 뜨지 않죠. 회사는 이런 식으로 어긋나는 경우들을 표로 공개해 뒀습니다. 그러니 낮은 확률 구간을 사람이 따로 보는 절차가 없으면 그 판단들도 그대로 실행됩니다.

내 파이프라인에 넣을 수 있는지를 가르는 한계도 있습니다. 한 Choice 질문은 선택지를 255개까지 받는데, 회사는 후보를 추려 주기보다 전체 목록을 그대로 건네고 다 덮지 못할 것 같으면 ‘어느 것도 아님’ 선택지를 더하라고 권합니다. 입력은 텍스트뿐이고 문자열을 만들어 내지도 못하고요. Jev를 브라우저 에이전트에 붙인 한 해커뉴스 이용자는 입력 칸에 넣을 텍스트를 초소형 모델이 대신 썼다고 적었는데, 한 파이프라인 안에 모델이 둘 필요해진다는 뜻이죠. 판단 대상으로 한 번에 넣을 수 있는 본문도 3만 2천 토큰까지라, 긴 문서를 통째로 넣는 설계는 여기서 막힙니다.

가격도 고정된 값으로 보면 안 됩니다. 회사는 가격을 투명하게 공개한다면서도 이게 보조금이 아니라는 걸 증명할 수는 없다고 직접 적었고, 레이트 리밋 역시 수요가 몰리는 동안 예고 없이 바뀔 수 있다고 경고 박스에 적혀 있거든요. 지금 가격과 지금 한도를 전제로 단가 모델을 고정해 두면 흔들릴 수 있습니다.

락인은 생각보다 약해 보입니다. 공개 여덟 시간 만에 한 개발자가 재현 모델을 예고했고, 이틀 뒤에는 또 다른 개발자가 Kev를 내놨고요. Kev를 만든 사람은 API가 TypeSafe의 System One과 같아서 공식 파이썬 SDK를 그대로 로컬 서버로 향하게 할 수 있다고 적었습니다. 그렇다면 Jev를 코드 여기저기서 직접 부르기보다 ‘결정 호출’이라는 인터페이스 하나로 감싸 두는 편이 안전하지 않을까 싶습니다.

다만 갈아탈 수 있다는 것과 지금 갈아타도 같다는 건 다른 이야기입니다. Kev 문서의 대조표를 보면 정확도는 근접했는데 확률의 품질을 재는 지표에서는 아직 Jev가 앞서 있거든요. 제작자도 Jev가 어떤 데이터셋으로 학습됐는지 모르니 통제된 비교는 아니라고 단서를 달았습니다.

마치며

이름에 회사의 생각이 그대로 들어 있습니다. 회사는 FAQ에서 작명 이유를 직접 밝혔는데요. 대니얼 카너먼의 『생각에 관한 생각』에서 빠르고 직관적인 시스템 1과 느리고 숙고하는 시스템 2의 구분을 가져와 모델 부류 이름을 지었다고요. 모델 이름은 윌리엄 스탠리 제번스에게서 따왔습니다. “증기기관 효율이 오른 뒤 석탄 수요가 늘었던 것처럼, 기계 지능도 비슷한 길을 갈 거라고 보거든요. 지능 비용이 한 자릿수 내려갈 때마다 그만큼 더 많은 쓰임새가 열립니다.” 경제학에서 제번스 역설이라고 부르는 관찰입니다.

그 말대로라면 지금 벌어지는 건 모델 교체라기보다, 비싸서 여태 안 물어보던 판단을 물어보기 시작하는 일에 가깝습니다.

그래서 게임체인저냐고 물으면 조건부로만 답할 수 있습니다. 확률을 분기 조건으로 쓸 데가 이미 있는 팀에게는 파이프라인 모양이 달라지는 일입니다. 그런 데가 없다면 아직은 아니고요. Vercel도 첫날 채택 속도는 역대 가장 빨랐지만 그게 이어지는지가 다음 시험이라고 적었습니다. 아키텍처도 논문도 아직 없고, 학습 데이터에 대해 회사가 밝힌 건 전부 직접 만든다는 한 줄뿐입니다. 국내에서도 직접 돌려 본 저장소가 막 올라오기 시작했는데, 결과를 정리해 공개한 글은 아직 눈에 띄지 않습니다.

남는 건 습관입니다. 배수를 보면 어느 채널 숫자이고 무엇과 비교한 건지부터 묻는 습관, 정확도를 맞춰 놓고 비용과 지연을 보는 비교 방식, 모델이 준 확신도를 믿기 전에 내 데이터로 확신도와 정확도를 같이 그려 보는 절차 같은 것들이요.

오늘 당장 해볼 만한 건 하나입니다. 지금 내 서비스에서 큰 모델한테 사실상 예/아니오만 묻고 있는 호출이 몇 개인지 세어 보는 겁니다. 그 숫자를 세어 보면 이 모델이 내게 필요한지 아닌지가 꽤 빨리 드러날 겁니다.

이 글은 AI의 도움을 받아 작성했습니다.