Jev의 경쟁자가 늘었다: Decisions API와 Microsoft-Decision-1 비교

에이전트가 다음 행동을 고를 때 긴 설명은 항상 필요하지 않습니다. 고객 문의를 어느 큐로 보낼지, 도구 호출을 허용할지, 검색 결과를 채택할지처럼 선택지가 정해진 작업에는 선택지별 확률과 점수가 더 직접적인 입력입니다.

Jev가 이 영역을 먼저 보여 줬다면, 이제 OpenAI는 Decisions API ↗를 공개 베타로 제공하고, Microsoft는 Microsoft-Decision-1 ↗을 내놨습니다. 이들은 생성 모델을 더 빠르게 돌리는 방식보다, 결정 공간을 먼저 고정하고 앱이 후속 정책을 실행하게 만드는 방식에 가깝습니다.

기준: 2026-10-13 확인. Jev, OpenAI Decisions API, Microsoft-Decision-1의 공개 문서와 각 발표 자료를 기준으로 합니다. 벤치마크와 지연 시간은 공급자별 환경·평가 방식이 달라 절대 순위로 읽지 않습니다.

세 도구는 같은 문제를 다른 경계에서 풉니다

입력과 운영 경계로 고르는 후보

앱 상태와 이름 붙인 질문을 확률 정책에 연결하기: Jev제품 데이터에서 확률 보정과 선택지 안정성을 검증합니다.
텍스트·이미지를 predicate·choice·score로 평가하기: OpenAI Decisions API공개 베타의 지원 모델과 엔드포인트 조건을 확인합니다.
텍스트의 닫힌 선택지를 평가하기: Microsoft-Decision-1라우팅·품질 평가에 맞습니다. 낮은 확신도와 중대한 사람 대상 판단에는 검토 경로를 남깁니다.

세 도구 모두 “무엇을 쓸까”보다 “어떤 행동을 허용할까”를 모델에 묻습니다. 그래서 출력은 글이나 JSON 객체가 아니라, 애플리케이션이 바로 읽을 수 있는 확률·선택지·점수입니다.

OpenAI는 범용 API 안에 결정 전용 경로를 만들었습니다

OpenAI Decisions API는 텍스트와 이미지를 평가해 세 유형의 답을 반환합니다.

predicate: 조건이 참일 확률을 0~1로 돌려줍니다.
choice: 고정된 선택지 중 하나와 선택지별 확률을 돌려줍니다.
score: 순서가 있는 단계의 확률 가중 평균을 점수로 돌려줍니다.

OpenAI 문서는 고객 문의 분류, 요청 라우팅, 작업 우선순위를 대표 사례로 듭니다. 자체 JSON 구조를 만들거나 설명을 생성해야 하면 Structured Outputs를, 도구 인자를 만들어야 하면 함수 호출을 쓰라고 구분합니다. Decisions API는 답의 형태가 이미 정해진 경우를 위한 별도 경로입니다.

예를 들어 “결제 문제인가?”와 “어느 담당 큐로 보낼까?”는 같은 입력을 공유하지만 서로 독립적인 판단입니다. 하나의 요청에 여러 질문을 넣고, 응답 후에는 코드가 자동 라우팅·보류·사람 검토를 선택합니다.

9월 DevDay에서 공개된 Luna 기반 Decision API ↗는 일반 모델의 서술형 응답과 별도 분류기 학습 사이의 선택지로 소개됐습니다. 현재 공개 문서 기준으로는 GPT-6 Luna만 지원하며, API는 공개 베타입니다.

Microsoft는 빠른 닫힌 선택지 평가에 더 좁게 집중합니다

Microsoft-Decision-1은 생성·번역·요약·열린 질의응답을 범위 밖으로 명시합니다. 모델이 근거를 새로 찾거나 설명을 만들어 주는 도구가 아니라, 제공된 입력 안에서 닫힌 질문과 정의된 선택지를 평가하는 도구입니다.

Microsoft Foundry 모델 카드는 다음 용도를 제시합니다.

AI 응답을 기준에 따라 채점하는 품질 평가
요청 분류와 라우팅, 작업 우선순위 지정
에이전트가 제안한 행동·도구 호출의 가드레일
검색·문서 관련성 판단과 신뢰도 기반 자동화

또한 낮은 확신도나 모호한 결과는 추가 검토로 올리는 흐름을 권장합니다. 특히 고용, 신용, 주거, 의료, 법적 권리처럼 사람에게 중대한 영향을 주는 판단의 단독 자동 결정자로 쓰지 말아야 한다고 명시합니다.

Microsoft 발표를 정리한 자료 ↗는 Decision-1의 비교 수치와 가격을 소개합니다. 이 수치는 Microsoft가 정한 벤치마크·동일 리전 조건의 자체 평가이므로, Jev나 OpenAI API의 일반적인 우열로 읽지 않습니다. 실제 선택에서는 자신의 지연 시간, 오탐·누락 비용, 라벨 데이터에서 다시 측정합니다.

Jev의 차별점은 API보다 확률을 운영하는 방식에 있습니다

Jev의 기존 구조 ↗는 상태와 이름 붙인 질문을 받아 예/아니오, 선택지, 순서형 점수를 반환합니다. 출력은 앱의 정책이 읽는 입력으로 설계됐습니다.

예를 들어 고객 메시지를 받아 다음 세 질문을 둡니다.

긴급한가?
어느 팀이 처리해야 하는가?
사람이 먼저 검토해야 하는가?

다음은 고객 문의를 처리하는 설명용 흐름입니다.

flowchart TD
  A["고객 문의 + 정해 둔 선택지"] --> B["결정 모델: 확률·점수"]
  B --> C["앱 정책: 임계값·허용 행동"]
  C --> D{"자동 처리 조건 충족?"}
  D -->|예| E["담당 큐로 전달"]
  D -->|아니오| F["사람 검토"]
  E --> G["입력·확률·후속 행동 기록"]
  F --> G

자동화 규칙은 애플리케이션이 소유합니다. 특정 선택지 확률이 임계값을 넘으면 라우팅하고, 낮거나 서로 비슷하면 검토 큐로 보냅니다. 감사 로그에는 입력 상태, 선택지, 확률, 적용한 임계값, 실제 후속 행동을 남깁니다.

Jev 아키텍처 글에서 다룬 것처럼 타입 안전한 출력은 업무 판단의 정확성을 보장하지 않습니다. 경쟁자가 늘어도 이 조건은 같습니다. 공급자를 바꿔도 임계값·선택지 표현·선택지 순서가 결과에 미치는 영향을 회귀 테스트해야 합니다.

모델을 고르기 전에 결정 정책부터 만듭니다

세 도구 가운데 하나를 고르는 일은 모델 벤치마크로 끝나지 않습니다.

결정 공간을 닫습니다. 가능한 행동과 금지된 행동을 선택지로 적습니다. 열린 설명이 필요하면 생성 모델 경로로 분리합니다.
실패 비용을 정합니다. 잘못 자동 실행하는 비용과 사람이 검토하는 비용을 비교합니다.
임계값을 데이터로 정합니다. 과거 사례를 보류 집합으로 두고 확률 구간별 정확도와 오탐·누락을 확인합니다.
사람 검토 경로를 남깁니다. 낮은 확신도, 새 선택지, 고위험 작업은 자동 실행하지 않습니다.
변화를 기록합니다. 모델 버전, 프롬프트, 선택지, 임계값이 바뀌면 같은 사례군에서 다시 평가합니다.

결정 모델은 에이전트의 계획·검색·생성 단계를 없애지 않습니다. 대신 그 사이의 작지만 빈번한 “다음에 무엇을 할까”를 더 빠르고 구조화된 방식으로 처리합니다.

기록해 둘 내용

Jev의 경쟁자 등장으로 확률 기반 결정은 특정 제품의 패턴이 아니라 API와 모델 카탈로그의 한 범주가 되고 있습니다. OpenAI는 이미지까지 포함한 범용 API 경로를, Microsoft는 텍스트 기반 닫힌 판단과 운영 가드레일을 강조합니다.

선택의 기준은 가장 높은 벤치마크 점수가 아닙니다. 내 업무의 선택지가 충분히 정의됐는지, 확률을 검증할 데이터가 있는지, 사람에게 넘길 경계가 있는지가 먼저입니다.

참고 자료

2026년 10월 14일 수정: 도구 비교를 입력·운영 경계별 선택 도식으로 바꾸고 설명용 정책 흐름을 추가했습니다.