OpenAI Decisions API란: Jev와 비교한 판단 모델 활용법

여러분, “이 문의는 어느 팀으로 보낼까” 같은 작은 선택만 맡는 판단 모델(decision model)이 새 카테고리로 떠올랐고, OpenAI가 2026년 9월 29일 DevDay에서 TypeSafe Jev의 대항마로 OpenAI Decisions API를 내놓았습니다. 결론부터 말하면 Decisions API는 정해 둔 선택지 중 하나를 0.15초 만에 고르는 API이고, 2026년 10월 3일 기준 확신도(confidence)와 가격은 공개되지 않았습니다.

일반 LLM API로는 답이 생성될 때까지 기다렸다가 파싱해야 하고, 얼마나 확신하는지도 알기 어렵죠. 2주 먼저 나온 Jev와 무엇이 다른지 짚고, 오픈소스 Kev로 실제 메일을 분류해 보며 잘 맞힌 질문과 막힌 질문이 어디서 갈렸는지 보겠습니다.

OpenAI Decisions API 핵심 요약

• 판단 모델은 글을 쓰지 않고 정해 둔 선택지 중 하나를 고르는 모델입니다.
• Decisions API는 텍스트나 이미지를 받는 GPT-6 Luna 기반 판단 API로, 공개 데모에서 일반 API로 건당 1.6초 걸리던 분류를 0.15초에 끝내 10배 빨랐습니다.
• Decisions API는 2026년 10월 3일 기준 제한 프리뷰이고, 가격, 확신도, 한 요청의 선택지 수는 미공개입니다.
• Jev는 텍스트만 받지만 답에 확률을 붙이고 Choice·Score 답에는 확신도까지 주며, 입력 100만 토큰당 0.042달러에 출력은 무료입니다.
• 오픈소스 판단 모델 Kev로 메일 종류를 판단하니 30건 중 28건을 맞혔지만, “이 메일은 내가 직접 봐야 하나?”는 65~70%에서 멈췄습니다. 답이 본문에 없는 질문이었습니다.
• 역할은 세 갈래로 나눕니다. 본문에 드러난 사실은 판단 모델이, 업무 기준은 코드 규칙이, 확신도가 낮은 건 더 큰 모델이나 사람이 맡습니다.

판단 모델(decision model)이란 무엇인가

판단 모델은 상황과 질문, 허용할 답 목록을 받아 미리 정한 타입의 답만 돌려주는 모델입니다. TypeSafe는 이 계열을 System One 모델이라고 부르는데요, 대니얼 카너먼(Daniel Kahneman)이 말한 빠르고 직관적인 System 1 사고에서 따온 이름입니다.

지금까지는 채팅 모델에 프롬프트로 고르게 하거나 작은 분류기를 학습시켰습니다. 프롬프트는 라벨을 쉽게 바꾸지만 확신도를 토큰 확률로 흉내 내는 수준이고, 분류기는 라벨이 바뀔 때마다 다시 학습해야 하죠. The New Stack은 판단 모델이 그 사이에 있다고 설명합니다. 선택지는 요청마다 바꿔 넣고, 결과는 코드가 바로 쓰는 점수로 받는 방식입니다.

OpenAI Decisions API로 할 수 있는 것

질문과 허용할 답 목록을 정해 두고 텍스트나 이미지로 상황을 넘기면, GPT-6 Luna가 그중 하나를 골라 줍니다. OpenAI는 용도로 콘텐츠 분류, 요청 라우팅, 에이전트의 다음 행동 선택을 꼽았습니다.

공개 데모는 고객 문의 1만 건을 결제, 기술, 영업으로 나누는 장면이었습니다. 일반 API의 건당 1.6초가 0.15초로 줄어 10배 빨랐습니다.

2026년 10월 3일 기준 공개되지 않은 것

제가 더 중요하게 보는 건 비어 있는 부분입니다. OpenAI는 선택된 API 고객 대상의 제한 프리뷰로 시작해 며칠 안에 확대하겠다고 했지만, 아직 공개된 가이드나 레퍼런스를 찾을 수 없고, 가격 페이지에도 항목이 없습니다. 가격, 한 요청의 선택지 수, 자체 데이터 튜닝 여부는 공개되지 않았고, OpenAI는 확대 출시 때 더 자세히 공유하겠다고 했습니다. 확신도는 공식 리캡에 없고, 이를 언급한 보도도 OpenAI 문서로는 확인되지 않습니다.

Jev가 먼저 연 판단 모델 시장

Jev는 OpenAI에서 ChatGPT의 바탕이 된 연구에 참여했던 Diogo Almeida가 세운 TypeSafe의 첫 System One 모델로, 2026년 9월 15일 공개됐습니다. 개발자가 얼마나 몰렸냐면, 신규 가입을 한동안 닫아야 할 정도였죠.

TypeSafe는 새 아키텍처, 병렬 샘플러와 함께 RLCD(Reinforcement Learning for Calibrated Decisions)라는 학습법을 내세웁니다. 확신도 0.8인 답들이 실제로 약 80% 맞으면 보정(calibration)됐다고 하고, TypeSafe는 이를 확신도가 높을수록 정확도도 높다고 설명합니다. 95% 맞히는 모델이라도 틀리는 5%가 어느 건지 말해 주지 못하면 자동화할 수 없고, 일반 LLM은 확신도를 물어도 과신하거나 일관성이 떨어진다는 거죠.

Jev의 세 가지 답 타입

타입	묻는 것	돌려주는 값
Choice	선택지 중 하나 (최대 255개)	고른 답, 전체 확률 분포, 확신도
Score	2~10단계 척도	확률 가중 값, 확신도
Noul	예/아니오	예일 확률

OpenAI Decisions API와 Jev 비교

항목	OpenAI Decisions API	TypeSafe Jev
속도	0.15초 (OpenAI 데모)	0.07~0.5초 (TypeSafe 발표)
입력	텍스트와 이미지	텍스트만
답 형태	정해 둔 선택지 중 하나	선택지 중 하나, 점수, 예/아니오
선택지 수	미공개	Choice당 최대 255개
확신도	공식 발표에 아직 없음	답마다 확률, Choice·Score에는 확신도도 제공
언어	공식 문서 미공개	영어 중심, 한중일은 같은 수준 아님
기반 모델	GPT-6 Luna	TypeSafe 자체 아키텍처
자체 데이터 튜닝	미공개	고객 데이터로 파인튜닝하지 않음
가격	미공개	입력 100만 토큰당 0.042달러, 출력 무료
사용	제한 프리뷰 (발표 당시 며칠 내 확대 예정)	누구나 가입 가능 (신규 무료 크레딧 일시 중단)

비교표를 읽을 때 주의할 점

• 두 속도는 같은 조건에서 잰 값이 아닙니다. OpenAI의 0.15초는 조건을 밝히지 않은 데모 수치이고, TypeSafe 수치는 주로 미국 서부의 노트북에서 잰 end-to-end 응답 시간입니다. 한국에서는 네트워크 왕복을 더해 직접 재 봐야 합니다.
• 한국어 성능은 직접 재 봐야 합니다. Jev는 영어 정확도가 가장 높다고 밝혔고, Decisions API는 언어별 자료가 아직 없습니다. Kev README도 다른 언어라면 짧은 파인튜닝을 권합니다.

확신도가 낮은 건만 큰 모델이나 사람에게 넘기려면 확신도 값이 있어야 하는데, 2026년 10월 3일 기준 Decisions API 공식 발표에는 이 값이 없습니다.

결국 갈리는 건 확신도입니다.

일반 LLM API로 분류할 때와 무엇이 다른가

“GPT-6 Luna에 Structured Outputs로 선택지를 걸면 되지 않나?” 싶으실 수 있습니다. Structured Outputs는 제약 디코딩(constrained decoding)으로 토큰을 하나 생성할 때마다 스키마에 맞는 토큰만 허용하니, enum 스키마를 걸면 선택지 밖 답은 나오지 않습니다. 차이는 그다음입니다. 모델은 여전히 답을 토큰 단위로 순서대로 써 내려가고, 확신도는 기본으로 주지 않습니다.

판단 모델은 이 두 지점을 다르게 풉니다. Jev는 문자열 생성을 포기하고 모든 답을 한 번의 쿼리로 병렬 생성한다고 밝혔습니다. 오픈소스 Kev는 언어 모델에 선택지마다 점수를 매기는 층인 포인터 헤드(pointer head)를 붙이고, 소프트맥스(softmax)로 점수를 확률로 바꿉니다. 답 토큰은 하나도 생성하지 않습니다. Decisions API의 내부 방식은 공개되지 않았습니다.

구분	LLM + Structured Outputs	판단 모델
선택지 밖 답	enum 스키마로 막을 수 있음	구조상 나오지 않음
지연 요인	답 토큰을 순서대로 생성	답 토큰 없이 선택지 점수 계산 (Kev 기준)
확신도	토큰 확률로 근사	선택지별 확률 (Jev, Kev)

오픈소스 판단 모델 Kev 써 보기

Kev는 Jared Palmer가 2026년 9월 GitHub에 공개한 판단 모델입니다. Qwen3.5와 Qwen3.8 기반의 Apache-2.0 오픈소스이고, Jev와 API 형식이 같아 엔드포인트와 모델 이름만 바꾸면 Jev용 코드가 그대로 붙습니다. 2026년 10월 1일에는 0.8B부터 27B까지 네 가지 크기를 묶은 Kev 1.0이 나왔습니다.

메일 분류 체험 결과

Kev 1.0이 나오기 전 저장소 버전을 맥북에 띄워 메일 분류에 붙여 봤습니다. 메일 종류를 나누는 판단은 실제 메일 30건 중 28건을 맞혔고, 응답은 0.2초 안팎이었습니다. Jared Palmer가 밝힌 32GB M5 측정치는 짧은 텍스트에 질문 다섯 개 기준 Kev-4B 721ms(텍스트 캐시 시 136ms), Kev-0.8B 149ms입니다. 다만 30건은 작은 표본이라 방향을 보는 정도로 읽어 주세요.

그런데 “이 메일은 내가 직접 봐야 하나?”는 65~70%에서 더 안 올라가더라고요. 같은 질문을 Claude Haiku 4.5에 물어도 65%였습니다.

이유는 질문에 있었습니다. 메일 종류는 본문에 답이 드러나 있지만, “내가 봐야 하나?”는 본문에 없는 제 업무 기준을 묻습니다. 애초에 모델이 풀 문제가 아니었던 겁니다. Kev 개발자도 판단에 필요한 정책이나 근거는 사용자가 넣어야 한다고 적어 두었습니다.

Kev 로컬 실행 방법 (2026년 10월 3일 README 기준)

Kev-0.8B는 모든 Apple Silicon 맥, Kev-4B는 32GB 맥에서 MLX로 돌아가고, Python 3.12 또는 3.13과 uv가 필요합니다.

git clone https://github.com/jaredpalmer/kev.git && cd kev
uv sync --extra serve
uv run --extra serve python -m kev.serve --run jaredpalmer/kev-4b --port 8009

판단 모델 역할 분담: 사실, 규칙, 확신도

1. 본문에 드러난 사실은 판단 모델이 판단합니다. 메일 종류, 본문에 기한이 있는지 같은 질문입니다. TypeSafe 문서도 넓은 판단은 작은 질문으로 쪼개고 결과를 코드에서 조합하라고 권합니다.
2. 업무 기준은 코드 규칙으로 겁니다. “이 발신자는 무조건 내가 본다” 같은 기준은 모델에게 추측시키지 말고 규칙으로 고정합니다. 규칙은 같은 입력에 늘 같은 결과를 내고 나중에 추적하기도 쉽습니다. Kev README는 고유 라우팅 범주나 에스컬레이션 규칙이라면 프롬프트 수정보다 짧은 파인튜닝이 대개 낫다고 안내하지만, 자주 바뀌는 업무 기준은 바뀔 때마다 재학습해야 하니 코드 규칙이 낫다고 봅니다.
3. 확신도가 낮은 건 더 큰 모델이나 사람에게 넘깁니다. 낮은 건만 위로 올리는 단계적 호출(cascade)이라 비싼 호출은 꼭 필요한 건에만 씁니다.

라우팅 코드 예시

Kev README의 요청 형식에 맞춘 예시로, 업무 규칙, 판단 모델, 확신도 분기 순서입니다.

import httpx

VIP_SENDERS = {"ceo@example.com"}

def route(mail: dict) -> str:
    if mail["from"] in VIP_SENDERS:
        return "me"
    answer = httpx.post("http://127.0.0.1:8009/v1/systemone", json={
        "model": "kev-latest",
        "state": mail["body"],
        "questions": {"mail_type": {"type": "choice", "instructions": "이 메일은 어떤 종류인가?",
                                    "criteria": {"billing": None, "support": None, "sales": None}}},
    }).json()["answers"]["mail_type"]
    if answer["confidence"] < 0.6:
        return "review"
    return answer["choice"]

0.6은 예시일 뿐입니다. Kev README는 확률을 기본으로 보정했다면서도 confidence는 확률 분포에서 계산한 값이지 측정된 정확도가 아니라고 밝히고, 대표 예시로 임계값을 정한 뒤 별도 표본으로 다시 재 보라고 합니다. Jev의 보정 주장도 내 데이터로 확인해야 합니다.

에이전트에 붙일 때

에이전트에서는 큰 모델이 계획을 세우고 판단 모델이 매 단계의 행동을 고르게 나눌 수 있습니다. 비싼 모델을 지시와 검증 자리에 두는 Advisor 전략과 같은 구조죠.

판단 모델을 붙일 곳과 붙이면 안 되는 곳

작업	판단 모델	이유
문의·메일 종류 분류	적합	답이 본문에 있습니다
요청 라우팅	적합	선택지가 닫혀 있고 양이 많습니다
에이전트의 다음 행동 선택	적합	작은 선택이 반복돼 지연이 쌓입니다
정답이 선택지 밖일 수 있는 판단	조건부	”판단 불가” 선택지와 사람 검토를 함께 둡니다
”내가 봐야 하나?” 같은 업무 기준	부적합	답이 본문에 없으니 코드 규칙으로 겁니다
설명, 요약, 답장 초안	부적합	글쓰기는 일반 LLM의 몫입니다

프론티어 모델 접근 제한을 다룬 글에서 분류와 태깅부터 대안 모델로 옮기자고 했는데요, 판단 모델이 그 자리의 가장 구체적인 후보라고 봅니다.

Decisions API, Jev, Kev 중 무엇을 쓸까

상황	선택	이유
이미지로 판단해야 할 때	Decisions API	셋 중 유일하게 이미지를 받습니다 (프리뷰 접근 필요)
확신도로 사람 검토를 분기해야 할 때	Jev 또는 Kev	Choice 답에 확신도가 붙습니다
지금 바로 API로 써야 할 때	Jev	누구나 가입할 수 있고 가격이 공개돼 있습니다
로컬 실행, 자체 튜닝이 필요할 때	Kev	Apache-2.0이고 맥에서 돌며, 자기 라벨로 파인튜닝할 수 있습니다

마무리

판단 모델은 범용 LLM 호출을 대체하지 않습니다. “고르기만 하면 되는” 판단을 떼어내 빠르게, 코드가 바로 받는 형태로 처리하는 부품입니다.

실무에서는 선택지가 닫혀 있고 답이 본문에 있는 판단부터 골라 보면 좋겠습니다. 과거 데이터에 정답을 달고, 정확도를 재고, 확신도 임계값을 정한 뒤, 본문에 없는 업무 기준은 규칙 레이어로 얹는 순서입니다. 저도 Decisions API 프리뷰가 풀리면 바로 한 번 붙여 보겠습니다. Decisions API든 Jev든 Kev든, 먼저 정할 건 역할 분담입니다.