결정 모델 다섯 편 묶어 읽기 — 확률이 무엇에 보정됐는가

9월 말부터 이 블로그에서 다섯 번 같은 주제를 다뤘다. 답이 정해진 작업에서 LLM에게 문장을 쓰게 하지 말고 확률만 받자는 이야기다. 그사이 범용 모델의 로짓을 읽는 방법부터 오픈웨이트 전용 모델, 국산 멀티모달 모델, 빅테크 API까지 다섯 갈래가 차례로 나왔다. 하나씩 볼 때는 안 보이던 것이 묶어 놓으니 보인다. 넷 다 확률을 돌려주지만, 그 확률이 무엇에 맞춰진 숫자인지는 전부 다르다. 임계값을 옮겨 쓸 수 없다는 뜻이다. (이 글은 Claude가 이 블로그의 앞선 다섯 편을 다시 읽고 정리했다.)

TL;DR: 결정 모델을 고를 때 먼저 볼 것은 속도가 아니라 확률의 출처다. SGLang 채점은 보정이 아예 없고, JEV-27B는 폐쇄 모델 Jev의 분포에 맞췄고(KL 0.017), Kanana-2-v-decide는 실제 정답률에 맞췄고(ECE 2.06% → 1.12%), Gemini Decision 1은 “교정 오차가 가장 낮다”고만 밝혔다. 실제 정답률을 기준으로 수치를 낸 건 Kanana 하나뿐이다. 둘째, 선택지 상한 255가 Jev에서 d3·Gemini까지 그대로 내려오는데 Kanana만 임베딩 비교로 그 벽을 넘었다. 셋째, 42ms·137ms·150~250ms는 측정 경계가 달라 나란히 못 둔다. 셋 다 결론은 같다 — 자기 데이터로 다시 재기 전에는 남의 임계값을 쓸 수 없다.

9월 말부터 무엇이 나왔나

출발점은 9월에 TypeSafe AI가 공개한 폐쇄 모델 Jev다. 용어가 그대로 퍼진 것이 계보를 보여 준다. 참·거짓 질문을 가리키는 noul, 다중선택 choice, 순서형 채점 score 세 타입이 JEV-27B·Kanana·Gemini에 똑같이 들어 있다. Gemini 발표를 본 Simon Willison이 Jev와 “거의 똑같다”고 적은 것도 이 때문이다.

곁가지로 두 가지가 더 있었다. 10월 16일 NVIDIA RTX 런치위크 정리에서 llama.cpp가 디시전 모델 지원을 넣었고, 11월 1일 주간 RAG·에이전트 정리에서는 결정 모델을 RAG 지식 충돌 분류에 적용한 논문이 나왔다. 실행 환경과 독립 측정이 뒤따라 붙은 셈이다.

축 1 — 그 확률은 무엇에 맞춰진 숫자인가

제일 중요한 축인데 제일 눈에 안 띈다. 네 방식 모두 “0.87” 같은 숫자를 돌려주고, 쓰는 쪽은 “0.9 넘으면 자동 승인, 아래면 사람에게” 같은 규칙을 얹고 싶어 한다. 그런데 그 0.9가 무엇을 근거로 0.9인지가 넷 다 다르다.

SGLang 채점은 보정 단계가 아예 없다. 범용 모델이 그 자리에서 낸 원점수에 softmax를 씌운 값이다. 숫자가 나오긴 하지만 0.9가 “열 번에 아홉 번 맞는다”는 뜻이라고 볼 근거가 없다.

JEV-27B는 보정을 학습으로 했는데, 맞춘 대상이 정답이 아니라 Jev다. 53개 도메인 홀드아웃 25,376문항에서 평균 KL이 약 0.017이고, 그 문항의 라벨도 Jev가 낸 답이다. “Jev처럼 답한다”는 보정이지 “맞게 답한다”는 보정이 아니다. 기준점의 오류까지 따라간다는 뜻이다. 그래서 같은 발표에서 6개 결정 벤치마크 평균 84.07로 폐쇄 모델 83.85를 앞섰다는 쪽이 더 단단한 근거다.

Kanana만 정답률을 기준으로 수치를 냈다. validation 데이터셋으로 confidence를 보정했고, 보정에 쓰지 않은 테스트셋에서 정확도는 유지한 채 보정 오차(ECE)가 2.06%에서 1.12%로 내려갔다. 임계값 운영을 하려는 입장에서는 이게 KL 0.017보다 직접적인 숫자다.

Gemini는 흥미로운 간접 증거가 있다. 발표는 교정 오차가 벤치마크에서 가장 낮았다고만 적고 수치를 안 냈다. 그런데 Willison이 자기 영상을 넣고 던진 yes/no 네 개에서 로봇 0.923, 미국 0.923, 용 0.050, 프랑스 0.083이 돌아왔다. 방향은 다 맞는데 1.0이나 0.0으로 붙지 않는다. 같은 질문에 Jev와 OpenAI는 1.0이나 0.0을 준다.

여기서 해석이 갈린다. 11/12 글에서는 이걸 “임계값을 다시 잡아야 한다”는 이주 주의사항으로 적었는데, 묶어 놓고 보면 확신을 덜어 내는 쪽이 보정된 모델의 정상 거동으로 읽는 편이 맞다. 네 개짜리 표본으로 단정할 일은 아니지만, 적어도 yes/no에 1.0을 돌려주는 모델을 보고 “확신이 강하다”고 읽으면 안 된다는 것은 분명하다. 보정된 분류기는 자기가 틀릴 몫을 남긴다.

실무에서 이게 왜 중요한가

임계값은 모델 사이에서 이식되지 않는다. Jev에서 0.95로 걸러 내던 게이트를 Gemini로 옮기면 같은 입력에 0.92가 돌아와 전부 사람에게 넘어간다. 반대로 Gemini 임계값을 미보정 모델에 걸면 아무것도 안 걸러진다.

그리고 Kanana에는 이 함정이 하나 더 있다. 저장소 코드가 돌려주는 confidence는 1위 확률 자체가 아니라 1위에서 나머지 선택지 확률의 평균을 뺀 값(margin)이다. 같은 정답이라도 선택지가 둘일 때와 열일 때 값이 달라진다. 임계값을 선택지 목록과 한 묶음으로 관리해야 한다.

결국 네 경우 모두 결론이 같다. 자기 업무의 임계값을 정하려면 라벨링된 평가셋이 필요하다. 차이는 출발점이 얼마나 앞에 있느냐뿐이다. 9/28 글에서 “실제 작업량의 대부분은 스코어링 연동이 아니라 평가셋 구축과 보정이 될 가능성이 크다”고 적었는데, 모델이 넷으로 늘어난 지금도 그 문장은 그대로다.

축 2 — 255라는 숫자의 계보

선택지를 몇 개까지 놓을 수 있느냐가 두 번째 축이다. 여기서 숫자 하나가 계보를 따라 그대로 내려온다.

SGLang 쪽 제약은 질이 다르고, 한국어에서 특히 아프다. 모든 선택지가 같은 출력 위치의 어휘 항목 하나여야 한다. Qwen2.5에서 A·B·C가 32·33·34번인 것은 좋은데, “주차 민원” 같은 카테고리명은 단일 토큰이 아니다. 그래서 기호를 레이블로 쓰고 기호-카테고리 대응은 프롬프트에 적는 구조가 된다. 선택지가 늘면 단일 토큰으로 남는 기호를 확보할 수 있는지부터 확인해야 한다.

Kanana는 구조를 바꿔 이 벽을 넘었다. 입력과 질문을 벡터 q로, 선택지를 하나씩 따로 벡터로 만들어 코사인 유사도를 재고 softmax를 씌운다. 벡터를 추가하면 되므로 class가 1,000개인 분류도 한 번에 된다. 선택지마다 따로 점수를 매기니 앞쪽 보기를 더 고르는 쏠림도 줄어든다.

다만 공짜가 아니다. 세 가지를 같이 봐야 한다.

• 처음 보는 선택지는 최초 한 번 임베딩해야 한다. class 1,000개 분류를 처음 돌리면 그 호출에서 선택지 연산이 1,000번 일어난다
• 캐시는 4,096개 LRU이고 키가 (dtype, device, 토큰 ID)다. 분류 체계가 그보다 크면 밀려난 선택지는 다시 계산된다
• 순서와 완전히 무관하지는 않다. 기본 설정에서는 선택지 목록이 질문 프롬프트 안에도 들어가므로, 선택지 벡터 쪽은 몰라도 질문 벡터 q는 순서의 영향을 받을 여지가 남는다. 선택지가 255개를 넘으면 질문 쪽에서는 목록을 자동으로 숨긴다

실제 서비스에서는 분류 체계나 도구 목록이 고정되고 입력만 바뀌는 경우가 많으니, 선택지 임베딩을 미리 계산해 두는 쪽이 맞다.

축 3 — 지연 수치 넷은 나란히 못 둔다

표로 모아 놓으면 비교하고 싶어지지만, 측정 경계가 다 다르다.

42ms와 150~250ms를 나란히 두면 안 된다. 앞은 로컬 GPU의 모델 연산이고 뒤는 네트워크를 포함한 왕복이다. 그나마 같은 선에 둘 수 있는 건 Kanana의 42ms와 Gemini가 따로 밝힌 모델 연산 50~100ms 정도이고, 이것도 하드웨어와 입력 길이가 달라 참고값이다.

배치 거동도 같이 봐야 한다. Gemini는 컨텍스트 16K 토큰까지는 질문을 1개에서 100개로 늘려도 지연이 거의 늘지 않는다고 밝혔다. 공통 입력을 한 번만 처리하기 때문이고, 과금도 요청당 한 번만 붙는다. 반면 Kanana는 한 요청에 질문을 여러 개 묶을 수 있지만 저장소 코드가 질문을 배치로 처리하지 않아 질문 쪽 연산이 N번 일어난다. 42ms는 판단 1건 기준이라는 단서가 여기서 의미를 갖는다.

같은 입력에 물을 게 여럿인 구성 — 문의 하나에 파손 여부·문의 유형·고객 감정을 함께 묻는 식 — 이 결정 모델의 전형적인 사용 형태라, 이 차이는 실제 지연에 그대로 반영된다.

그래서 무엇을 고르나

앞의 세 축을 업무 조건으로 바꾸면 이렇게 갈린다.

오늘 당장 붙여 볼 때 — SGLang 채점. 학습도 계약도 필요 없다. 다만 나온 확률을 임계값으로 쓰기 전에 반드시 재야 하고, 한국어 카테고리라면 기호 치환 구조를 감수해야 한다.

GPU를 들고 있지 않을 때 — Gemini Decisions API 또는 OpenAI Decisions API. Gemini는 입력 1M 토큰당 $0.10에 출력은 받지 않는다. OpenAI Luna도 같은 값이고, 셋 중 가장 싼 쪽은 여전히 Jev(1M당 4.2센트)다. Gemini만 텍스트·이미지·오디오·비디오·PDF를 한 입력에 섞을 수 있다. 통화 녹음이나 스캔 PDF가 입력에 들어오는 업무라면 선택지가 사실상 하나다.

한국어 업무이고 이미지가 섞일 때 — Kanana-2-v-decide. 한국어 중심 평가셋에서 상용 모델과 비슷한 수준이 확인된 유일한 선택지다. Kanana Decision Bench 텍스트 72.62점으로 Microsoft-Decision-1(71.98), Jev 1.14.0(71.66)을 앞섰는데, 차이가 1점 안팎이라 “앞섰다”보다 “3B로 비슷한 수준에 올라섰다”로 읽는 편이 맞다. 모델 카드 기준으로는 Decision Index public에서 Joey-1이 63.31점으로 더 높아 모든 지표 1위는 아니다.

분류 체계가 고정돼 있고 양이 많을 때 — JEV-27B, 또는 그 레시피. H100 한 장에 bf16으로 올라가 초당 약 100결정이 나온다. 더 중요한 건 모델이 아니라 레시피다. 백본을 얼린 채 0.4%(1억 890만 파라미터)만 학습해 B200 한 장 9.2시간이면 끝났고, HumanEval 164개 완성 결과가 학습 전후로 바이트 단위까지 같았다. 기존 생성 능력을 안 깨고 결정 능력만 얹을 수 있다는 뜻이다. 자기 라벨로 같은 걸 만드는 쪽이 현실적인 경로일 수 있다.

평가·게이트에 쓸 때 — 설명이 필요한지부터 본다. Jev 심판 글에서 정리한 기준이 그대로 적용된다. CI에서 “이 PR이 정책을 어겼는가”를 막는 자동 게이트라면 확률 하나로 충분하다. 사람이 고쳐야 하는 자리라면 설명이 필요하고, 그건 결정 모델이 주지 않는다.

여기서 캐스케이드가 나온다. 값싼 결정으로 먼저 거르고 걸린 것만 비싼 설명을 받는 구성인데, 측정된 사례가 둘 있다. Carnegie Mellon 연구진의 JEV-as-a-Judge는 확신한 판정만 받고 나머지를 에스컬레이션하는 구성에서 홀드아웃 1,610쌍 기준 GPT-6보다 0.9점 더 정확하면서 요금은 41%였다. 11월 1일 주간 정리에서 본 RAG 지식 충돌 분류 논문도 결정 모델이 가장 확신하지 못하는 4분의 1만 상위 모델로 넘기는 캐스케이드로 비용을 크게 줄였다.

싸게 가려다 정확도를 깎는 거래가 아니다. 두 측정 모두 캐스케이드가 단독 LLM보다 정확하면서 싸다. 결정 모델을 비용 절감 수단으로만 보면 이 지점을 놓친다.

남는 것

한국어 성능을 실제로 잰 건 Kanana 하나뿐이다. JEV-27B 발표의 벤치마크 6종 중 다국어 성격이 있는 건 MASSIVE-en인데 이름 그대로 영어다. Gemini 발표에도 한국어 항목이 없다. 한국어 민원·티켓 분류에 쓰려면 직접 재야 하고, 재면서 만든 라벨이 그대로 학습 데이터가 된다.

안전성을 따로 다룬 것도 Kanana뿐이다. Safety 데이터로 학습한 모델을 가중치 합으로 합치면 다른 판단 능력이 같이 떨어졌는데, 학습 데이터 행마다 따라 할 teacher를 고르는 MOPD로 합치자 trolley 형식 평가에서 불필요한 손해 선택이 최대 73%, 같은 상황에서 답이 뒤바뀌는 모순이 최대 37% 줄었다. 결정 모델의 판단은 서비스 로직으로 곧장 넘어가므로 이 축은 앞으로 더 중요해진다.

비교의 기준점이 계속 폐쇄 모델이다. JEV-27B의 핵심 지표는 Jev와의 KL이고, Kanana의 비교 대상에도 Jev가 들어 있고, Gemini는 Jev의 용어까지 가져왔다. 오픈 모델이 따라잡았다고 말할 때 흔한 방식이지만, 그만큼 기준점의 오류를 함께 물려받는다. 자기 업무 라벨로 재는 것 말고 이 고리를 끊을 방법이 지금은 없다.

참고

• 생성 대신 채점 — SGLang /v1/score로 오픈 LLM을 분류 엔진으로 쓰기 (2026-09-28)
• OpenAI DevDay 2026 정리 (2026-10-02) — Decisions API
• 결정 전용 모델이 오픈웨이트로 — autotrust/JEV-27B (2026-10-06)
• 심판도 글을 써야 하나 — Jev로 에이전트 평가 만들기 (2026-10-06)
• 카카오, AI 에이전트용 멀티모달 의사결정 모델 ‘Kanana-2-v-decide’ 오픈소스 공개 (2026-11-07)
• Gemini Decisions API: 멀티모달 결정 모델을 API로 바로 쓰기 (2026-11-12)
• NVIDIA RTX 런치위크 소프트웨어 스택 (2026-10-16) — llama.cpp 디시전 모델 지원
• 주간 RAG·에이전트 논문 정리 (2026-11-01) — 지식 충돌 분류에 쓴 결정 모델