OpenAI Decisions API와 Jev: 텍스트 대신 선택지를 돌려주는 결정 모델

문의 메일 한 통을 받아서 결제, 배송, 기타 중 어디로 보낼지 정하는 코드가 있다고 해 보겠습니다. 요즘 이 코드는 대개 LLM을 부릅니다. 프롬프트에 선택지 셋을 적고, JSON으로 답하라고 시키고, 돌아온 문자열을 파싱합니다. 필요한 것은 단어 하나인데 모델은 그 단어를 한 토큰씩 만들어 냅니다.

9월에 이 자리를 겨냥한 제품이 두 개 나왔습니다. 9월 15일 TypeSafe AI가 Jev를, 9월 29일 OpenAI가 DevDay에서 Decisions API를 발표했습니다. 둘 다 문장을 쓰는 대신 정해진 선택지 중 하나를 돌려줍니다. 이 글은 두 회사의 발표와 보도를 근거로 씁니다. 두 API를 직접 호출해 본 기록은 아닙니다.

JSON 스키마만 걸면 된다는 오해

분류나 라우팅에 LLM을 쓰는 팀은 이미 구조화 출력을 씁니다. 응답이 스키마를 벗어나지 않게 막아 주니 문제가 해결됐다고 보기 쉽습니다.

구조화 출력이 막아 주는 것은 형식뿐입니다. 모델은 여전히 문장을 생성하는 방식으로 답을 만들고, 스키마는 그 생성 경로를 좁힐 뿐입니다. 그래서 선택지 하나를 고르는 데도 대화형 모델과 같은 지연과 같은 과금 구조를 치릅니다. 답이 얼마나 확실한지도 알려 주지 않습니다. "결제"라는 문자열은 99% 확신일 때와 40% 확신일 때 똑같이 생겼습니다.

제가 보기에 결정 모델이 겨냥한 것은 형식 오류가 아니라 이 두 가지, 속도와 확신의 부재입니다.

문장을 만들지 않는 모델, Jev

TypeSafe AI는 OpenAI 출신 연구자 Diogo Almeida가 세운 회사입니다. 발표문에서 Jev를 System One 모델이라는 새 부류의 첫 모델로 소개합니다.

Jev는 문자열 생성을 아예 포기했습니다. 요청에는 지금 상태(이벤트, 텍스트, 도구 사용 이력 같은 맥락)와 판단할 질문들을 담습니다. 질문은 세 가지 타입 중 하나입니다. 참과 거짓의 확률을 주는 noul, 여러 선택지 중 하나를 고르면서 전체 분포를 함께 주는 choice, 순서가 있는 척도에서 점수를 매기는 score입니다.

발표문이 내세운 숫자는 응답 70~500ms, 입력 100만 토큰당 0.042달러이고 출력은 과금하지 않습니다. 출력 토큰을 만들지 않으니 과금할 것이 없다는 논리입니다. 시연으로는 초당 10번 가까이 판단을 내리며 Doom을 플레이하는 영상을 보여 줬습니다.

2주 뒤에 나온 OpenAI Decisions API

OpenAI의 Decisions API는 저가 모델 GPT-6 Luna 위에 만들어졌습니다. 개발자가 질문과 가능한 답의 목록을 정하고, 텍스트나 이미지로 맥락을 넘기면 답 하나가 돌아옵니다. The Decoder 보도에 따르면 응답은 약 150ms로, 일반 API로 Luna를 부를 때의 1.6초보다 10배가량 빠릅니다. 제한된 프리뷰로 시작했고 곧 넓게 연다고 했습니다.

	TypeSafe Jev	OpenAI Decisions API
발표	2026년 9월 15일	2026년 9월 29일
기반	전용 System One 모델	GPT-6 Luna 변형
입력	상태 + 타입 있는 질문	질문과 답 목록 + 텍스트·이미지 맥락
출력	질문별 답과 보정된 확률	선택된 답
속도	70~500ms	약 150ms
가격	입력 100만 토큰당 $0.042, 출력 무료	공개되지 않음
상태	얼리 액세스	제한된 프리뷰

표에서 제가 가장 크게 보는 칸은 출력입니다. Jev는 모든 답에 보정된 확률을 붙인다고 밝혔고, 확신이 높을수록 실제 정확도도 높도록 맞췄다고 합니다. OpenAI 쪽은 제가 찾은 자료에서 확률을 돌려주는지 확인하지 못했습니다.

타입 오류가 없다는 말과 틀리지 않는다는 말의 구분

TypeSafe의 발표문에는 Jev가 환각을 일으킬 수 없다는 문장이 있습니다. 근거는 모델이 타입 오류를 내지 않는다는 것입니다. 선택지 밖의 답이나 파싱할 수 없는 문자열이 나올 수 없다는 뜻이고, 이것은 구조상 맞는 말입니다.

그런데 결제 문의를 배송으로 보내는 것도 오류입니다. 형식은 완벽하고 판단만 틀린 답입니다. 타입 안전성은 이 오류를 막지 못합니다. 저는 환각이 없다는 표현보다 확률을 돌려준다는 점이 이 문제에 대한 진짜 답이라고 봅니다. 확신이 70% 아래면 사람에게 넘긴다는 규칙을 코드에 쓸 수 있기 때문입니다. 확률이 실제 정확도와 맞게 보정돼 있다는 주장이 사실일 때만 성립하는 이야기이고, 그 검증은 써 본 사람들의 기록을 기다려야 합니다.

큰 모델이 계획하고 작은 모델이 고르는 구조

두 제품이 같은 달에 나온 것은 에이전트 설계의 방향과 맞물려 있습니다. The Decoder는 GPT-6 Astra가 전체 계획을 세우고 Jev가 매 순간의 행동을 고르는 Minecraft 에이전트 사례를 소개했습니다.

에이전트는 한 작업 안에서 판단을 수백 번 내립니다. 다음에 어떤 도구를 부를지, 이 결과가 충분한지, 사람에게 물어야 하는지. 이 판단을 전부 큰 모델에 맡기면 판단마다 초 단위 지연이 쌓입니다. 계획은 큰 모델이, 갈림길마다의 선택은 결정 모델이 맡는 구조가 자연스러운 이유입니다. 제품 쪽에서 보면 분류, 라우팅, 스팸 판정, 긴급도 점수처럼 지금 LLM을 부르고 있는 코드의 상당 부분이 이 구조로 옮겨 갈 후보입니다.

아직 공개되지 않은 것

OpenAI Decisions API의 가격과 응답 형식은 아직 공개 문서로 확인되지 않습니다. 확률을 함께 주는지가 Jev와의 가장 큰 차이가 될 수 있는데, 지금은 알 수 없습니다. Jev의 속도와 가격도 회사 발표 기준이고 독립적인 측정은 아직 보지 못했습니다.

둘 중 무엇을 고를지는 이 두 가지가 밝혀진 뒤에 판단할 일입니다. 저라면 그 전에 할 일이 따로 있다고 봅니다. 우리 코드에서 LLM에게 단어 하나를 받으려고 문장 생성 비용을 치르는 호출이 몇 군데인지 세어 보는 것입니다.