말하지 않고 결정하는 AI, Jev 활용법

-입력은 state, 출력은 타입이 있는 확률

사용법은 단순하다. 판단할 대상을 state로 넘기고, 묻고 싶은 것을 questions로 적는다. state는 문자열, JSON 객체, 텍스트 배열 모두 된다. 질문은 세 가지 유형 중 하나로 정의한다.

눈여겨볼 대목은 여러 질문을 한 번에 던진다는 점이다. Jev는 state를 한 번 읽고 모든 질문을 병렬로 평가한다. 그래서 질문을 늘려도 응답 시간이 거의 늘지 않는다. 라우터처럼 한 요청을 여러 축에서 동시에 따져야 하는 자리에 잘 맞는 성질이다.

-핵심은 보정(Calibration)이다

Jev를 이해하는 열쇠는 속도보다 보정에 있다. 보정이 잘된 모델은 확률 0.8로 낸 판단 100건 가운데 약 80건이 맞는다. 모델이 말하는 확신과 실제 적중률이 일치한다는 뜻이다. TypeSafe는 이 성질을 목표로 한 학습법을 RLCD(Reinforcement Learning from Calibrated Decisions)라 부르고, 합성 데이터만으로 모델을 학습했다고 밝혔다.

독립 비교 사례 하나가 차이를 잘 보여 준다. 노르웨이 정부 문서를 분류한 실험에서 Jev가 0.8이라고 답한 판단은 기준 레이블과 약 80% 일치했다. 같은 조건에서 DeepSeek이 0.8이라고 적은 판단은 절반 정도만 맞았다. 흥미롭게도 정확도 자체는 거의 같았다. 둘을 가른 것은 정답률이 아니라 모를 때 모른다고 말하는가였다.

02 무엇이 좋고, 어디에 쓰나

같은 분류 작업을 저렴한 LLM에 JSON으로 시키는 방식과 비교하면 Jev의 성격이 선명해진다.

TypeSafe는 비슷한 LLM 대비 최대 200배 빠르고 400배 저렴하다고 주장한다. 다만 이 수치는 분류 작업에 한정된 벤더 측 주장이다. 앞의 비교 사례처럼 독립 실험에서는 1,000건 처리 비용이 $0.22 대 $1.31~3.08로, 격차가 수 배에서 십수 배 수준이었다. 실무 판단은 이쪽 숫자를 기준으로 하는 편이 안전하다.

-한계도 분명하다

Jev는 LLM을 대체하지 않는다. 공식 문서는 숫자·날짜 계산, 적대적 입력에 약하다고 밝히고 있다. 여러 단계를 건너야 하는 추론, 이미지 이해, 판단의 근거 설명은 여전히 LLM의 몫이다. 입력은 텍스트만 받고, 컨텍스트는 요청당 64k 토큰이며 그중 state와 가장 긴 질문의 합이 32k를 넘을 수 없다.

우리에게 가장 중요한 한계는 언어다. 공식 문서는 영어가 주력이고, 한국어를 포함한 CJK 문자도 처리는 하지만 같은 수준은 아니다라고 적고 있다. 한국어 업무 문장을 그대로 넣기 전에 반드시 자체 검증이 필요하다는 뜻이다. 이 점은 04절의 온프레미스 대안 논의로 이어진다.

-활용 방안 네 가지

• 모델·에이전트 라우팅 — 요청의 의도와 난이도를 판정해 어느 에이전트, 어느 크기의 모델로 보낼지 정한다
• 도구 호출 위험 게이팅 — bash, SQL 같은 도구를 실행하기 직전에 위험한 호출인지 판정해 차단하거나 승인을 요청한다
• 에이전트 감시와 종료 판정 — 에이전트 루프가 목표를 달성했는지, 같은 행동을 반복하며 헛돌고 있는지 매 스텝 저렴하게 판정한다
• 단계적 승급(Escalation) — 저가 모델이 먼저 처리하고, 확신이 낮은 건만 고가 모델이나 사람에게 넘긴다

네 가지 모두 “짧고 자주 반복되는 판단”이라는 공통점이 있다. LangChain은 이미 모델 라우팅용 미들웨어와 도구 위험 판정용 미들웨어를 예제로 공개했다. 요청 모양은 다음과 같다.

03 NAA 라우터에 Jev를 얹는 설계

여기서부터는 NAA의 적용 설계와 로드맵이다. 현재 NAA v0.2.0 라우터에 Jev가 들어가 있는 것은 아니다. 8월호에서 소개한 라우터의 판단 축을 결정 모델 관점에서 다시 나누어 보고, 어디까지를 확률에 맡기고 어디부터를 규칙으로 남길지 정리한다.

-판단 축을 질문 유형으로 옮긴다

표의 다섯 번째 줄이 이 설계의 원칙을 요약한다. 확률은 모델이, 권한은 규칙이 맡는다. 권한처럼 틀리면 사고가 나는 판단은 아무리 잘 보정된 확률이라도 맡기지 않는다. 8월호의 Safe by Design 원칙, 즉 권한에 맞는 데이터만 사용한다는 약속은 결정 모델을 얹은 뒤에도 규칙 계층이 지킨다.

-배열 route_plan은 Noul 묶음으로 만든다

NAA의 route_plan[]은 배열이다. “지난 분기 매출 추이를 경쟁사 동향과 비교해 정리해 줘” 같은 요청은 SQL 데이터 에이전트와 검색·RAG 에이전트를 모두 거쳐야 한다. Choice 하나로는 이런 복합 경로가 나오지 않는다. 선택지 중 하나만 고르기 때문이다.

그래서 경로마다 Noul을 하나씩 둔다. needs_sql, needs_rag처럼 에이전트별로 “이 요청에 이 경로가 필요한가”를 따로 묻는 방식이다. 확률이 기준을 넘는 경로가 모두 계획에 들어가고, 주 경로를 정하는 Choice는 실행 순서와 결과 종합의 기준으로 쓴다. 질문을 여러 개 던져도 한 번의 호출로 끝나므로 지연 부담은 거의 없다.

-confidence를 보정된 확률에서 계산한다

지금까지 confidence는 라우터가 자기 판단을 보고하는 값이었다. 설계를 바꾸면 이 값은 결정 모델이 낸 확률들에서 계산된다. 예를 들어 선택된 경로들의 Noul 확률과 주 경로 Choice의 confidence 가운데 가장 낮은 값을 계획 전체의 confidence로 삼을 수 있다. 가장 약한 고리가 계획의 신뢰도를 정한다는 보수적인 규칙이다.

이렇게 하면 ask_user 임계값을 로그 기반으로 조정할 수 있다. 임계를 올리면 되묻기가 늘고 오실행이 줄며, 내리면 반대가 된다. 이 교환 관계를 숫자로 보고 고객사별 운영 정책으로 정한다. 금융·공공 고객은 높게, 사내 생산성 도구는 낮게 두는 식이다.

-라우터 밖으로 넓힐 자리

• SQL 데이터 에이전트 — 조회 전용 관문 앞에 쓰기·삭제 의도 Noul을 사전 필터로 둔다. 구조적 관문은 그대로 유지하고, 관문에 도달하기 전에 위험 요청을 걸러 사용자에게 먼저 알린다
• 응답 검증기 — 여러 에이전트 결과가 서로 어긋나는지 판정하는 충돌 확인에 Noul을 쓴다. 생성과 검증을 분리한다는 원칙에도 맞는다
• 모델 크기 선택 — 복잡도 Score가 낮으면 작은 모델 Endpoint로, 높으면 큰 모델 Endpoint로 보낸다. Xster Ops가 MIG 조각별로 띄운 Endpoint와 바로 연결된다
• 심층 리서치 종료 판정 — Subagent들이 모은 근거가 질문에 답하기에 충분한지 매 라운드 판정해 비용이 튀기 전에 멈춘다

04 온프레미스 Private 환경의 대안

여기까지 읽고 나면 자연스럽게 떠오르는 질문이 있다. NAA를 쓰는 공공·금융 고객이 Jev를 쓸 수 있는가. 답은 대부분 쓸 수 없다이다. Jev는 SaaS API다. 라우터가 판단하려면 사용자 질문 원문과 맥락 요약을 state로 보내야 하고, 그 순간 데이터가 외부로 나간다. 한국어 성능이 검증되지 않았다는 점까지 더하면, 온프레미스 고객에게는 같은 역할을 사내에서 해낼 대안이 필요하다.

-오픈소스의 반격

Jev가 유료 API로 나오자 오픈소스 진영은 곧바로 반격에 나섰다. 공개 일주일 남짓 만에, 이미 있는 모델을 활용해 Jev의 역할을 재현하는 접근법이 여럿 나왔다. 방향은 크게 셋으로 갈린다. 전용 경량 인코더를 새로 만드는 길, LLM의 구조를 고쳐 보정 학습을 입히는 길, 아예 학습하지 않고 서빙 중인 모델에서 확률을 읽는 길이다.

• convaiinnovations/laya — 전용 경량 인코더. Convai는 이미 2025년 3월 PPO로 의사결정 확률을 뽑는 선행 논문을 낸, 말하자면 Jev의 원조격 팀이다. Jev 출시 사흘 만인 9월 19일, ModernBERT-large 기반 421M 파라미터 모델 Laya를 Apache-2.0으로 허깅페이스에 공개했다. T4 GPU에서 질문 하나를 약 33ms에 처리한다. Jev API의 236ms 이상보다 7배 넘게 빠르다. 자체 벤치마크 정답률도 76.6%로 Jev의 72.7%를 앞섰고, 9월 말 현재 허깅페이스 모델 트렌드 1위를 달리고 있다.
• 다만 숫자를 읽을 때 주의할 점이 있다. 76.6%는 해당 벤치마크의 학습 데이터로 파인튜닝한 체크포인트의 결과이고, 파인튜닝 없이 바로 쓰면 정답률이 크게 떨어진다. 선택지가 수십 개인 과제(BANKING77)에서는 Jev가 크게 앞선다. 확률 보정도 기본 상태에서는 대형 백본인 Jev가 우세하다. Laya는 과제별로 온도를 다시 맞춰야 쓸 만한 보정에 이른다. Convai 스스로도 Laya를 “바로 쓰는 판정 엔진이 아니라 특화하기 좋은 빠른 출발점”으로 소개한다.
• harshatheg/Qwen-2.5-1B-RLCD — 아키텍처 개조와 RLCD. 사전학습이 충분히 된 LLM인 Qwen의 인과 마스크를 풀어 결정 모델로 개조하고, Brier Score 손실로 확률 보정(RLCD)을 직접 구현한 사례다. 모델이 틀리면서도 99%를 확신하는 과신(Overconfidence) 문제를 오픈 레시피로 잡을 수 있음을 보여 줬다. TypeSafe가 논문 없이 이름만 밝힌 RLCD를 공개 코드로 재현하려는 흐름의 대표 격이다.
• nokia-applied-research/AnyJev — 학습 없는 접근. “새로 학습할 필요 없이 이미 서빙 중인 LLM의 로짓만 영리하게 읽자”는 노키아 응용연구팀의 GitHub 프로젝트다(Apache-2.0). 로짓을 그대로 읽으면 선택지 순서만 바꿔도 답이 바뀌는 위치 편향이 생긴다. AnyJev는 선택지를 한 칸씩 돌려 가며 모든 자리에 한 번씩 놓고 결과를 합치는 순환 순열(Cyclic Shift)로 이 편향을 지웠다. Qwen3-8B로 20개 선택지 분류(BANKING77)를 시험했을 때, 추가 학습 없이 온도 보정만 얹어서 오류율 5% 이하로 자동 처리할 수 있는 트래픽 비율을 7.7%에서 52.0%로 6.8배 끌어올렸다. 필요한 것은 레이블 100~500건 정도다.

-10B급 오픈 모델로 Jev에 다가서기

세 접근법은 서로 배타적이지 않다. 조합하면 Jev와 대등한 오픈 결정 모델까지 내다볼 수 있다. Qwen3.5 9B나 Gemma 4 12B 같은 10B급 오픈 모델을 먼저 AnyJev 방식의 결정 모델로 바꾸고, 그 위에서 증류와 RLCD 보정 학습을 진행하는 경로다. 10B급 백본은 Laya 같은 소형 인코더가 약했던 지식형 판단과 선택지가 많은 과제를 받쳐 주고, RLCD는 기본 상태의 보정을 끌어올린다.

증류의 교사로는 Jev를 쓸 수도 있고, 사내에서 더 큰 LLM이 낸 판단이나 사람이 검수한 라우팅 로그를 쓸 수도 있다. 다만 Jev 출력을 학습 데이터로 쓰려면 먼저 TypeSafe 이용 약관이 이를 허용하는지 확인해야 한다. 온프레미스 고객 데이터를 외부 API로 보낼 수 없다는 제약도 그대로 남는다. 현실적인 교사는 공개 데이터에 대한 Jev 판단과 사내 로그의 조합이 될 가능성이 크다.

-단계별 도입 경로

NAA 온프레미스 환경에서는 이 흐름을 세 단계로 나눠 밟는다. 새 모델 없이 시작해 로그를 쌓고, 그 로그로 전용 모델을 만드는 순서다.

• STAGE 1 · 학습 없이 확률 읽기 — NAA가 이미 쓰는 사내 LLM Endpoint에 AnyJev 방식을 적용한다. 순환 순열로 위치 편향을 지운 확률로 라우팅하고 로그를 쌓기 시작한다
• STAGE 2 · 보정과 검증 — 실행 결과로 정답 레이블을 붙인 로그에서 온도 T를 맞춘다(temperature scaling). 신뢰도 도표와 ECE로 보정 상태를 확인하고 ask_user 임계값을 정한다
• STAGE 3 · 전용 결정 모델 — 지연이 중요하면 Laya 같은 경량 인코더를 사내 로그로 특화하고, 정확도가 중요하면 10B급 모델에 증류와 RLCD를 입힌다. Xster Ops에서 MIG 조각을 떼어 결정 모델 전용 Endpoint로 서빙한다

STAGE 1의 핵심은 아래 정도의 코드다. vLLM의 logprobs 기능으로 첫 토큰 후보의 로그 확률을 받고, 선택지를 한 칸씩 돌려 가며 같은 질문을 선택지 수만큼 던진다. 자리별 로그 확률을 평균하면 특정 위치를 선호하는 편향이 상쇄된다. 토큰을 하나만 만들기 때문에 여러 번 물어도 일반 생성보다 빠르다.

STAGE 2에서는 이렇게 얻은 확률이 실제로 믿을 만한지 잰다. 라우팅 로그에서 확신도와 정답 여부를 모아 ECE를 계산하고, 온도 T를 바꿔 가며 ECE가 가장 작아지는 값을 찾는다. 코드는 짧지만 이 단계가 없으면 앞의 확률도 LLM이 적어 준 숫자와 다를 바 없다.

-한국어 업무 환경에서의 주의점

05 결론 — 생성과 결정을 분리한다

Jev가 던진 메시지는 모델 하나의 성능보다 크다. 에이전트 시스템 안에는 문장을 만드는 일과 갈림길을 고르는 일이 섞여 있는데, 지금까지는 둘 다 같은 LLM에게 맡겨 왔다. 갈림길에서 필요한 것은 긴 추론이 아니라 빠르고 믿을 수 있는 확률이다. Jev는 그 역할을 떼어 낼 수 있다는 것을 보여 줬다.

이 방향은 NAA가 걸어온 길과 겹친다. 8월호에서 생성과 검증을 분리했듯, 이번에는 생성과 결정을 분리한다. 라우터는 보정된 확률로 경로를 고르고, 권한과 예산은 규칙이 지키며, 확신이 부족하면 여전히 사람에게 묻는다. 달라지는 것은 그 “확신이 부족하다”는 판단이 이제 측정 가능한 숫자 위에 선다는 점이다.

온프레미스 고객에게도 길은 열려 있다. 외부 API 대신 사내 LLM에서 확률을 읽는 것으로 시작하고, 로그로 보정하고, 전용 결정 모델을 Xster Ops의 MIG 조각 하나에 올린다. NAAX가 인프라부터 에이전트까지 한 흐름으로 설계된 덕분에, 결정 모델 하나를 더하는 일은 Endpoint 하나를 더 띄우는 일과 크게 다르지 않다.

나무에이엑스는 이 설계를 NAA 라우터 로드맵에 반영해 검증을 이어 간다. 결과는 다음 호들에서 숫자로 공유하겠다.

-참고 자료

• TechCrunch, “A new kind of AI model from a ChatGPT inventor is thrilling developers” (2026.09.18)
• Simon Willison, “Jev introduces a new shape of LLM — System One, aka Decision Models” (2026.09.21)
• TypeSafe AI 공식 문서 docs.typesafe.ai/models · OpenRouter Jev 문서
• LangChain Blog, “What Is Jev? A Guide to TypeSafe AI’s System One Model”
• APIMaster.AI, “Jev vs LLMs: Where a Decision Model Beats Prompting a Cheap Model”
• Convai Innovations, Laya 모델 카드(huggingface.co/convaiinnovations/laya) · AI Weekly, “Convai ships Laya” (2026.09)
• harshatheg, Qwen-2.5-1B-RLCD 모델 카드(huggingface.co/harshatheg/Qwen-2.5-1B-RLCD)
• Nokia Applied Research, AnyJev 저장소(github.com/nokia-applied-research/AnyJev) · MarkTechPost (2026.09.23)

NAA 라우터의 결정 모델 적용 설계와 NAAO · NAAX 배포 형태에 대한 문의는 나무에이엑스 AI부문으로 연락하면 된다.