Jev는 LLM과 무엇이 다른가

어느 날 아침에 일어났더니 유튜브와 긱뉴스에 Jev라는 모델이 갑자기 핫이슈처럼 올라와 있었다. TypeSafe AI라는 샌프란시스코 회사가 2026년 9월 15일에 얼리 액세스로 공개한 모델이다. 공동 창업자이자 대표인 Diogo Almeida는 OpenAI에서 4년쯤 RLHF와 InstructGPT, ChatGPT 일을 하다 2024년에 나왔다고 한다.

비슷한 일을 하는 오픈소스 모델도 찾아봤다. 무료라서 끌렸는데, 훈련시키고 무거운 모델을 내 서버에 올려서 운영하는 게 부담이었다. Jev는 입력 100만 토큰에 0.042달러이고 출력은 받지 않는다. 그 정도면 서버를 직접 돌리는 비용보다 나을 것 같았다.

그 뒤로 내 사이트 두 곳에 Jev를 붙였다. 포트폴리오 사이트의 채용 공고 맞춤 보기와, 세계일주 사이트의 사진 주제와 말로 찾기다. 이 글은 붙이기 전후로 Jev가 LLM과 무엇이 다른지 정리한 것이고, 세계일주 사이트에 붙인 이야기는 다음 편에 따로 쓴다.

문장을 만들지 않는 모델

Jev에게 보내는 요청은 두 부분이다. 판단할 대상인 state(글이나 JSON)와, 그것에 대해 묻는 questions다. 질문은 세 가지 형식만 있다.

세계일주 사이트에서 사진 한 장에 보낸 요청은 이런 식이었다. 질문은 사진마다 열세 개였고 전부 noul이다.

{
  "model": "jev-latest",
  "state": { "city": "…", "local_time": "…", "apple_caption": "…", "scene": "…" },
  "questions": {
    "water": {
      "type": "noul",
      "instructions": "Does the photo described in the state show a large body of water, such as the sea, a lake, a river, a canal, a waterfall or a harbour, as a main part of the scene?"
    },
    "mountain": { "type": "noul", "instructions": "…" }
  }
}

답은 문장이 아니라 {"water": {"type": "noul", "noul": 0.96}, …} 같은 값이다. LLM에 같은 일을 시키면 "JSON으로만 답해"라고 부탁하고, 돌아온 글을 파싱하고, 형식이 깨졌으면 다시 부르는 일이 따라붙는다. Jev는 처음부터 정해 둔 형식 밖의 답을 낼 수가 없다. TypeSafe 문서도 스스로를 답장이나 코드, 추론 설명을 쓰는 모델이 아니라고 적어 둔다.

포트폴리오 사이트에 처음 붙일 때 이 점이 결정적이었다. 채용 공고를 붙여 넣으면 내 프로젝트 중 맞는 것을 골라 위로 올리는 기능인데, LLM이 공고에 맞춰 경력 문장을 그럴듯하게 고쳐 쓰면 곤란하다. 같이 검토하던 클로드 코드가 "Jev는 문장을 만들지 않아 경력 사실을 지어낼 수 없다"고 정리했고, 그 판단대로 붙였다.

한 글자씩 쓰는 것과 한 번에 매기는 것

LLM은 다음 토큰 하나를 예측하는 계산을 반복해서 글을 만든다. 토큰 하나가 나올 때마다 모델 전체를 한 번 통과하니까, 답이 길수록 그만큼 오래 걸린다. 열세 개 질문에 하나씩 예/아니오를 적게 하면 답의 길이만큼 계산이 이어진다.

Jev는 그렇게 돌지 않는다. TypeSafe 문서의 표현으로는 "state를 한 번 읽고 모든 질문을 그것에 대해 병렬로 평가한다." 정확한 구조와 가중치, 논문은 공개하지 않았다. 바깥에서는 위키피디아처럼 분류·회귀를 하는 판별(discriminative) 모델로 보거나, 선택지 전체를 한 번에 점수 매긴다고 설명한다.

아래에서 계산을 한 번씩 돌려 보면 차이가 보인다. 오른쪽은 세계일주 사이트의 이구아수 폭포 사진 한 장에 Jev가 실제로 매긴 값이고, 왼쪽은 LLM이 같은 열세 개 답을 써 나가는 방식을 그림으로 옮긴 것이다(실제 LLM 출력은 아니다).

그래서 빠르다고 하는데, 얼마나 빠른지는 재는 사람마다 많이 다르다. TypeSafe는 프런티어 LLM보다 40~200배 빠르다고 하고, 위키피디아는 그 수치를 회사 쪽 주장으로 적는다. Towards Data Science에 글을 쓴 Nhu Hoang은 은행 상담 문장 3,080개로 시험했는데, Jev가 요청당 중앙값 245ms, 로컬에서 돌린 Qwen3-Coder-Next-80B-A3B가 249ms로 거의 같았다. 몇 배 빠르다는 말은 무엇과 견주느냐에 따라 크게 달라지는 것 같다.

Jev는 사진을 보지 않는다

Jev의 입력은 글뿐이다. 이미지를 넣을 수 없다. 그러면 사진 1,944장에 어떻게 물었느냐 하면, 사진 대신 사진에 대한 글을 줬다. 도시, 주소, 현지 시각, 그리고 아이폰 사진 앱이 사진마다 만들어 두는 설명 문장과 장면 라벨이다.

그러니까 위의 "물가 0.96"은 사진 앱이 쓴 설명을 읽고 매긴 값이다. 폭포가 보이는지는 Jev가 아니라 사진 앱이 먼저 판단한 셈이고, 설명이 빈약하거나 잘못돼 있으면 Jev도 그대로 따라간다.

0.96은 96%라는 뜻인가

Jev가 내세우는 건 확률이 믿을 만하다는 점이다. 학습 방식의 이름부터 RLCD, 보정된 결정을 위한 강화학습이다. 사람이 좋아하는 답을 보상하는 RLHF와 달리, 내놓은 확률이 실제 결과와 맞아떨어지도록 학습했다고 한다.

보정(calibration)이 잘 됐다는 건 이런 뜻이다. 모델이 0.8이라고 답한 것들을 모아 보면 실제로 80%쯤 맞아야 한다. 하나하나의 답이 맞는다는 보장이 아니라, 묶어서 봤을 때의 성질이다. TypeSafe 문서도 이걸 분명히 적는다. 보정은 예측 여러 개를 묶어서 재는 것이고, 개별 답이 맞는다는 보장은 아니라고.

그런데 바깥에서 측정한 결과는 구간마다 달랐다. 앞의 Nhu Hoang의 시험에서 확신도를 구간별로 나눠 보면 이렇다.

1.00이라고 한 답은 거의 맞았지만, 0.7~0.9 구간은 평균 0.81이라고 해 놓고 절반을 조금 넘겨 맞았다. 다른 측정들도 보정 오차(ECE)가 0.002에서 0.246까지 데이터와 질문 형식에 따라 크게 갈린다. 그래서 0.96을 96%로 읽기보다, 같은 질문 안에서 사진들을 줄 세우는 순서로 읽는 게 안전한 것 같다.

맞는 답이 없어도 고른다

Nhu Hoang은 어느 범주에도 속하지 않는 문장 30개를 넣어 보기도 했다. Jev는 30개 모두에서 목록에 있는 범주 하나를 골랐고, 확신도는 전부 0.99 이상이었다. 선택지 밖의 답을 낼 수 없다는 장점이 뒤집히면 이렇게 된다. "해당 없음"이라는 선택지를 주지 않으면 해당 없음이라고 말할 길이 없다.

포트폴리오 사이트에서 같은 일을 겪었다. 붙여 넣은 글이 채용 공고인지 먼저 묻는 noul 질문을 두고 0.5를 넘어야 다음으로 넘어가게 했다. 날씨 기사는 잘 걸러졌는데, 회사 소개글과 자기소개서는 공고로 통과해 버렸다. 채용과 가까운 글이라 그랬던 것 같다. 둘 다 맞는 프로젝트가 0개로 나와서, 일치하는 게 하나도 없으면 화면을 바꾸지 않고 입력창에서 안내하도록 고쳤다.

TypeSafe는 자기 모델이 약한 곳을 문서에 따로 정리해 두었다. 그중 내가 신경 쓴 건 이런 것들이다.

• 날짜를 크기가 있는 값이 아니라 글자로 읽는다
• 계산기가 아니다. 세거나 더하는 일에 약하다
• choice에서는 선택지 순서가 답에 영향을 주고, 앞에 있는 것으로 기운다
• state 안의 글을 적대적인 입력으로 취급하지 않는다. 글 속에 지시문을 심으면 답이 움직일 수 있다
• state에 관계없는 내용이 많을수록 정확도가 떨어진다

세계일주 사이트의 "밤" 질문은 설명 속의 어둠이나 조명 단서와 함께 현지 시각도 보고 판단하게 되어 있다. 시각을 글자로 읽는다면 그 부분은 기대만큼 작동하지 않았을 수도 있다. 시각만 바꾼 같은 설명을 몇 개 넣어 보면 알 수 있을 것 같다.

한국어로 물어도 되나

TypeSafe 문서에는 영어가 주 학습 언어이고 한국어를 포함한 다른 언어는 다루기는 하지만 똑같이 잘하지는 않는다고 적혀 있다. 포트폴리오 사이트에는 국문 공고가 들어올 테니 붙이기 전에 시험을 해 봤다.

시험은 클로드 코드가 했다. 가상 채용 공고 세 개(에이전트 백엔드, NLP 연구, 모바일 앱)를 국문과 영문으로 쓰고, 내 프로젝트 14개를 score 질문으로 매기게 했다. 영문 공고로 매긴 순위와 국문 공고로 매긴 순위의 일치도는 0.89~1.00이었고, 공고는 국문·프로젝트 설명은 영문으로 섞었을 때 0.97~1.00으로 가장 가까웠다. 이 결과로 붙였다.

지금 보면 이 시험은 쉬웠다. 공고 세 개를 쓴 것도, 어느 프로젝트가 맞는지 정답을 매긴 것도 같은 에이전트였고, 공고의 키워드가 노골적이었다. 실제 채용 공고 몇 개를 넣어서 내가 직접 정답을 매겨 보면 한국어에서 얼마나 버티는지 알 수 있을 것 같다.

무엇을 물을지, 어떤 선택지를 줄지, 몇 이상을 "예"로 칠지는 결국 쓰는 쪽이 정해야 한다. 세계일주 사이트에서는 그 판정선을 사진 열세 주제마다 따로 정했고, 그 이야기를 다음 편에 쓴다.

끝