713 ／ 714
생성하지 않고 판단하는 모델, Jev와 오픈소스 대안 Laya
보통의 대화형 언어모델은 “확신도 90%”를 하나의 문장으로 써 낸다. 그런데 그 문장을 만들어 낼 확률이 곧 답이 맞을 확률 90%를 뜻하지는 않는다. 그런데도 우리는 사기 탐지, 콘텐츠 검수, 문의 배정, 위험 평가 같은 일을 정확히 이 패턴 위에 올려 두고 있다. 토큰을 한 개씩 생성하는 비용을 치른 뒤, 검증되지 않은 확신 표현을 소프트웨어가 그대로 믿고 행동에 옮기는 것이다.
TypeSafe가 내놓은 Jev는 이 지점을 겨냥한다. 자유로운 문장을 생성하는 대신, 사전학습 언어모델이 가진 지식을 유지하면서 내부 표현에서 곧바로 읽어 낸 결정 확률을 돌려준다. 그 확률은 실제 결과(outcome)에 맞춰 학습된다. 자료와 질문, 허용된 답의 범위를 주면 텍스트를 만들지 않고 여러 질문의 분포를 병렬로 반환한다. 회사는 이런 모델을 System One 모델이라고 부른다.
이 글은 세 자료를 하나로 묶은 정리다. 첫째는 Jev를 실제 업무 자동화에 붙일 때 무엇을 확인해야 하는지 짚은 문서, 둘째는 약 1만 번의 API 호출로 Jev의 내부 구조를 추정한 리버스 엔지니어링 에세이, 셋째는 같은 개념을 오픈소스로 구현했다고 주장하는 Laya다. 세 자료 모두 한 가지 태도를 공유한다. 빠른 판단은 출발점일 뿐이고, 그 판단을 신뢰할 수 있는지는 따로 확인해야 한다는 것이다.
Jev가 맡는 일과 맡기지 못하는 일
Jev는 텍스트 입력을 받아 짧은 판단을 수행하도록 설계됐다. 문의를 담당 부서에 배정하거나, 검색한 문서의 관련성을 평가하거나, 에이전트가 다음에 쓸 도구를 고르는 일에 쓸 수 있다. 현재 버전은 텍스트만 다루며 자유로운 문장이나 코드는 생성하지 않는다.
입력은 두 부분으로 나뉜다. state에는 판단할 자료를 담는다. 고객 메시지, 검색 결과, 현재 게임 상태 같은 것들이다. questions에는 무엇을 판단할지 적고, 선택형이라면 가능한 답의 이름과 각 답의 의미도 함께 전달한다. 같은 자료를 두고 질문만 바꾸면 다른 문제가 된다. 예컨대 “지금 고객의 의도는 무엇인가”라고 물으며 절차 문의·환불 신청·신청 취소·정보 부족을 선택지로 줄 수도 있고, “어느 부서가 처리해야 하는가”라고 물으며 반품팀과 결제팀을 놓을 수도 있다.
질문 유형은 세 가지다.
| 유형 | 반환값 | 쓰임 |
|---|---|---|
| Choice | 선택된 답 + 선택지별 확률 분포 | 여러 후보 중 하나 고르기 |
| Noul | 특정 진술이 참일 확률 P(true) | 예·아니오 판단 |
| Score | 순서 있는 등급의 분포 + 점수 | 낮음·보통·높음 같은 단계 평가 |
Score가 소수를 돌려주는 것은 등급 번호를 확률로 가중 평균했기 때문이다. 소수를 낸다고 해서 정확한 수치 계산 능력이 있다는 뜻은 아니다. TypeSafe도 숫자 계산과 날짜 비교를 Jev의 약점으로 공개하며, 계산 가능한 작업은 코드에서 처리하라고 권한다.
이 방식의 장점 하나는 업무마다 별도 모델을 학습시키지 않아도 된다는 점이다. 고객마다 미세조정하거나 LoRA를 붙이지 않고 같은 가중치를 제공하며, 사용자는 자료와 기준을 요청 안에 넣어 모델을 자기 업무에 맞춘다. 다만 업무를 설명할 수 있다는 사실이 그 업무를 잘한다는 증거는 아니다. “환불을 원하지 않는다는 뜻은 아닙니다”라는 문장이 즉시 환불 실행 요청과 같은 뜻인지는 정책에 따라 달라진다. 모델을 시험하기 전에 사람이 이 경계를 먼저 정해야 한다.
형식이 맞는 답과 내용이 맞는 답
정해진 형식으로 답을 받으면 프로그램이 긴 답변에서 값을 다시 추출할 필요가 줄고, 존재하지 않는 부서명 같은 출력도 막을 수 있다. 그러나 형식이 맞는다는 것과 내용이 맞는다는 것은 다르다. 승인·거절 중 하나만 고르게 해도, 거절해야 할 주문에 승인을 고르는 오류는 여전히 가능하다. 형식 오류가 없다는 설명을 환각이나 업무 오류가 없다는 주장으로 바꿔 쓰면 안 된다.
확률과 confidence도 구분해야 한다. Choice 응답에는 선택 결과, 선택지별 확률, 그리고 별도의 confidence가 들어 있다. 공식 문서에서 confidence는 확률 분포가 한쪽으로 얼마나 집중됐는지를 요약한 0~1 사이의 통계량이다. 선택된 답의 확률과 같은 값이 아니고, 정답일 확률을 따로 측정한 값도 아니다. 가장 높은 선택 확률이 0.9를 넘는 경우와 confidence가 0.9를 넘는 경우는 서로 다른 집합이 될 수 있어서, 두 값을 섞어 쓰면 시험에서 정한 기준과 실제 동작이 어긋난다.
저렴한 호출과 저렴한 업무 처리는 다르다
2026년 9월 19일 확인한 공식 요금은 Jev 1.13.0 기준 입력 100만 토큰당 0.042달러이며 출력 토큰은 무료다. 같은 자료에 여러 질문을 묶어 보낼 수 있어 상태를 반복 전송하는 방식보다 입력 비용을 줄일 여지가 있다. 그러나 단가만으로 전체 업무 비용을 계산하면 안 된다. 자료를 추출하고 요약하는 모델, 검색과 저장, 외부 도구 실행, 오류 확인과 재처리에도 비용이 든다. 특히 잘못 처리한 건을 사람이 복구해야 한다면 그 비용이 호출료보다 훨씬 클 수 있다. 유용한 비교 단위는 같은 품질 기준을 지키면서 업무 한 건을 끝내는 데 드는 비용이다.
모델의 답을 받는 지점에서 평가를 끝내면 안 된다는 것이 이 문서의 핵심이다. 필요한 자료가 빠지지 않았는지, 적절한 후보를 제공했는지, 오류를 감당할 수 있는 범위에서 자동 처리했는지, 최종 업무가 제대로 끝났는지까지 확인해야 한다. 입력을 준비하고 모델을 호출하고 결과를 실행으로 잇고 실패를 처리하는 이 바깥 코드를 하네스(harness)라고 부른다. 빠른 판단은 자동화의 출발점이고, 실제 성과는 하네스를 어떻게 설계하고 검증하느냐에 달려 있다.
1만 번의 호출로 추정한 아키텍처
TypeSafe는 가중치도 연구 내용도 공개하지 않는다. 그래서 한 연구자는 여러 조건에서 지연 시간이 어떻게 변하는지, 질문 순서를 바꾸면 무엇이 달라지는지를 관찰하며 약 1만 번의 API 호출로 Jev의 구조를 추정했다. 그의 결론은 공개된 사실, 실험으로 관측한 결과, 관측에서 추정한 가설을 뚜렷이 나눠 읽어야 한다는 전제 위에 서 있다.
추정한 구조는 대략 이렇다.
- 디코딩 루프 대신 판독부(readout). 마지막 은닉 표현을 곧바로 선택지 확률로 바꾸는 작은 함수를 붙인다. API가 보고하는
output_tokens는 생성량이 아니라 응답을 직렬화한 뒤 계산하는 과금용 숫자로 보인다. 선택지가 200개인 질문이 2개인 질문만큼 빠르게 돌아왔고, 서버 시간은 입력 길이에 따라서만 늘었다. - 상태는 공유하고 질문은 격리한다. 여러 질문이 같은 상태 표현(KV 캐시로 추정)을 함께 읽고, 각 질문은 자기 지시문과 선택지만 덧붙인다. 한 요청은 대략 6만 5천 토큰까지, 질문 한 갈래는 3만 2천 토큰까지 허용되는데, 상태는 한 번만 센다. 질문끼리는 서로의 답을 읽지 못한다. “고객이 화났는가”라는 질문이 “어느 부서로 보낼까”라는 판단을 바꾸지 않는다는 뜻이다.
- 인과적(causal) 백본, 아마도 희소 MoE. MMLU-Pro 84.6%라는 지식 폭은 프런티어급 사전학습을 요구하고, 그 규모의 모델은 대부분 인과적 디코더다. 약 3만 토큰을 160밀리초 안팎에 처리한 측정치는 활성 파라미터가 100억 개 정도인 희소 전문가 혼합(MoE) 구성과 맞아떨어진다. 다만 이 부분이 가장 불확실한 추정이다.
- 선택지는 함께 읽힌 뒤 결정된다. 무관한 선택지 하나를 더 넣자 기존 두 선택지 사이의 승률이 바뀌었다. 각 선택지에 독립적인 점수를 매기고 정규화만 한다면 일어날 수 없는 일이다. 선택지 순서를 뒤집자 어떤 분류의 확률이 0.84~0.89에서 0.93~0.96으로 움직이기도 했다. 0.9 근처를 기준으로 자동 처리를 결정한다면, 같은 근거인데도 순서만으로 행동이 달라질 수 있다.
훈련 목표는 확률 분포 자체를 맞추는 데 있다. TypeSafe는 이 방식을 RLCD(Reinforcement Learning for Calibrated Decisions)라고 부른다. 보정(calibration)이란 0.8 확률을 준 사례들을 충분히 모았을 때 그중 약 80%가 실제로 맞는 성질이며, 개별 예측 하나가 보정됐는지는 알 수 없다. 공개 기록으로 다시 계산한 MMLU 1,200문항의 기대 보정 오차(ECE)는 0.0313이었다. 다만 갓 만든 두 단계 문장제 문제에서는 정확도가 32%로 떨어졌다. 벤치마크 점수 하나가 모델이 아는 것 전부를 대변하지는 않는다는 뜻이다.
에세이 저자 스스로 강조하듯, 직접 확률을 출력한다는 사실은 공개돼 있지만, KV 공유·인과적 어텐션·희소 전문가는 갈수록 구체적인 추정에 가깝다. 블랙박스 API 바깥에서 얻은 그림은 유령 위에 천을 덮어 대략의 윤곽을 본 것에 지나지 않는다.
오픈소스 대안, Laya
Laya는 같은 개념을 오픈소스로 구현했다고 밝힌 모델군이다. 개발자는 자신이 2025년 3월에 이미 강화학습 기반의 비자동회귀 판단 모델을 만들어 arXiv 논문과 Hugging Face 가중치, 공개 데이터셋으로 내놓았다고 말한다. 그리고 2026년 9월 TypeSafe가 논문·가중치·훈련 데이터 공개 없이 Jev를 발표하자, 옛 접근의 한계를 고쳐 완전히 개방된 System 1 판단 모델을 새로 만들었다는 것이 Laya의 출발점이다.
Laya는 양방향 인코더(bidirectional encoder) 위에 세워졌다. 단일 GPU에서 한 질문을 32.8밀리초에, 배치 처리 시 질문당 7.2밀리초에 처리하며, Apache 2.0 라이선스로 가중치를 공개하고 100개 이상 언어 지원을 목표로 한다. 질문 유형은 Jev와 같은 choice·score·noul 세 가지다. 출력이 확률과 숫자뿐이라 텍스트를 생성하지 않고, 그래서 환각이나 형식 파괴가 구조적으로 일어나지 않는다고 설명한다.
세 개의 특화 체크포인트를 하나의 저장소에 묶었다.
| 체크포인트 | 백본 | 파라미터 | 강점 |
|---|---|---|---|
| laya | ModernBERT-large | 421M | 영어 분류·가드레일·이메일 분류 |
| laya-multilingual | mmBERT-base | 322M | 100여 개 언어, 교차언어 추론 |
| laya-typed-decisions | ModernBERT-large | 421M | 에이전트 관측·고객 응대·보안 경보 |
한 모델이 모든 언어를 감당하지 못하기 때문에 입력 문자를 먼저 감지해 모델을 고르는 라우터를 둔다. 영어 모델의 5만 토큰 BPE 어휘는 비라틴 문자를 잘게 부수는데, 51개 언어를 훑은 실험에서 크메르어는 정확도 0.000에 평균 확신도 0.952를 기록했다. 한 건도 못 맞히면서 95% 확신을 보고한 것이다. 이 대목이 두 모델 계열이 공유하는 교훈을 잘 보여 준다. 모델의 확신도만으로는 입력을 못 읽는 상황을 걸러 낼 수 없어서, 어떤 모델을 쓸지는 판단 이전에 정해야 한다.
Laya는 약점도 함께 공개한다. 선택지가 20개를 크게 넘으면 성능이 떨어지고(라벨이 토큰 예산을 나눠 갖기 때문이다), 기본 모델의 제로샷 성능은 제한적이라 업무별 파인튜닝이 필요하며, 업무 도메인에 맞춘 temperature 보정을 해야 기대 보정 오차가 0.466에서 0.081로 내려간다. 다음은 Laya가 제시한 Jev와의 비교로, Laya 수치는 자체 측정이고 Jev 수치는 외부 공개치를 가져온 것이라 특정 환경에서의 결과로 읽어야 한다.
| 항목 | TypeSafe Jev 1.13.0 | Laya(라우팅) |
|---|---|---|
| 지연 P50(질문 1개) | 236~276ms | 32.8ms |
| 지연 P50(질문 10개 배치) | 약 1,500ms | 72.3ms |
| 보정 오차(ECE) | 0.246 | 0.081 |
| 100만 토큰당 비용 | 0.042달러(과금 API) | 0달러(self-host) |
| 가중치·코드 | 비공개 API | 오픈소스 |
세 자료를 겹쳐 보면
세 자료가 겨냥하는 문제는 같다. 모든 AI 판단에 생성형 LLM이 필요하지는 않다는 것이다. 문의 분류, 가드레일, 라우팅, 검수처럼 반복되는 구조화된 결정이라면, 긴 답변을 스트리밍하고 정규식으로 라벨을 뽑아내는 대신 확률형 판단 모델을 쓰는 편이 빠르고 값싸다.
동시에 세 자료는 같은 한계를 짚는다. 확률이 잘 보정돼 있어도 그 확률이 정답을 보장하지는 않으며, 어디까지 자동으로 처리하고 어디서 사람에게 넘길지는 모델이 아니라 시스템을 만드는 쪽이 정해야 한다. 빠른 판단은 문제의 절반이고, 나머지 절반은 그 판단을 실제 업무에 얼마나 안정적으로 연결하느냐에 있다.
출처
- Jev와 업무 자동화의 조건 (개인 문서, 2026-09-19 기준). TypeSafe 공식 문서(docs.typesafe.ai)와 관련 연구를 근거로 정리한 자료.
- Archer Hume, “Jev’s Architecture Unmasked” (archerhume.com, 2026-09-17). 약 1만 번의 API 호출에 기반한 리버스 엔지니어링 에세이.
- Laya 공식 소개 (laya.convaiinnovations.com). 오픈소스 System 1 판단 모델. GitHub: github.com/NandhaKishorM/laya