OpenAI Decisions API 공개 베타, 분류·선택·점수 답을 Responses보다 약 10배 빠르게 받습니다 | DAKER 커뮤니티

분류·라우팅·심각도 점수처럼 답이 정해진 형태인 작업에 Responses API 전체를 돌리면 지연과 토큰이 커집니다. OpenAI는 2026년 10월 6일 API 변경 기록에서 Decisions API를 gpt-6-luna와 함께 공개 베타로 내놓았습니다. 텍스트·이미지를 넣고 predicate·choice·score 형태의 답을 받으며, 가이드는 Responses API보다 약 10배 빠르다고 적습니다. 2026년 10월 13일 공식 가이드에서 확인한 엔드포인트·요금·제약을 정리합니다.

세 가지 질문 유형

Decisions API는 POST /v1/decisions 전용 엔드포인트를 씁니다. 현재 모델은 gpt-6-luna뿐입니다. 요청은 model, input(텍스트 또는 텍스트·이미지 사용자 메시지), questions 배열로 구성됩니다. predicate는 조건이 참일 확률(0~1), choice는 제시한 값 중 하나와 확률 분포·confidence, score는 순서 있는 레벨에 대한 확률 가중 평균 점수를 반환합니다. 가이드는 카테고리처럼 순서가 없으면 choice, 심각도처럼 순서가 있으면 score를 쓰라고 구분합니다. Structured Outputs나 함수 호출이 필요한 자유 형식 JSON·도구 요청에는 Decisions가 아니라 Responses API를 쓰라고 안내합니다.

Decisions는 출력 토큰을 거의 만들지 않는 쪽으로 설계되어, /v1/decisions에서는 입력 토큰만 과금합니다.

이미지·SDK·데이터 제어

이미지는 HTTP(S) URL이나 file_id가 아니라 인라인 base64 data URL만 지원합니다. 제품 파손 여부처럼 사진과 지시문을 같은 user 메시지에 넣을 수 있습니다. 공개 베타이며 수주 내 GA를 목표로 한다고 적혀 있습니다. SDK 예제는 Python 3.26.0, JavaScript 7.30.0, Go 3.73.0, Ruby 0.101.0, Java 4.78.0 이상을 요구합니다. Zero Data Retention과 HIPAA는 자격 있는 고객에게 지원되며, 데이터 레지던시·지역 처리는 미국과 유럽(EEA+스위스)입니다.

요금은 gpt-6-luna 기준 입력 100만 토큰당 0.10달러이고, 캐시 읽기·쓰기·출력 토큰 청구는 없습니다. 지역 처리 할증과 긴 컨텍스트 입력 배수 요금은 적용됩니다. 이 요금은 /v1/decisions에만 해당하고, 같은 모델을 다른 엔드포인트에서 쓰면 해당 모델·처리 등급 요금을 따릅니다. 변경 기록과 가이드는 https://developers.openai.com/api/docs/changelog, https://developers.openai.com/api/docs/guides/decisions입니다.

가이드는 같은 입력에 서로 다른 유형의 질문을 한 요청의 questions 배열에 넣을 수 있다고 설명합니다. 제품 사진에서 파손 여부와 카테고리를 동시에 묻는 식입니다. 다만 앞 답에 의존하는 분기는 요청을 나누라고 합니다. choice에는 other 같은 폴백 값을 두고, score 레벨은 인접 단계의 기준이 겹치지 않게 쓰라고 권합니다. 임계값은 라벨링된 예시로 잡고, false positive와 false negative 비용에 따라 라우팅·보류·거절을 나누는 편이 문서의 운영 가이드에 가깝습니다.

Live API의 client delegation과 연결하면 음성으로 받은 요청을 Decisions로 행동 선택에 넘긴 뒤 결과를 다시 사용자에게 보고하는 흐름도 안내되어 있습니다. 음성 접점이 있는 상담·현장 앱이라면 텍스트 Decisions 스키마를 먼저 고정한 다음 음성 계층을 얹는 순서가 실패 지점을 줄입니다.

한국 서비스에 붙일 때

고객 문의 부서 라우팅, 콘텐츠 모더레이션, 티켓 심각도, 에이전트 다음 단계 분기처럼 답이 닫힌 집합인 구간에 Decisions를 두고, 설명문 생성·도구 호출은 Responses에 남기는 이중 구조가 문서의 의도에 가깝습니다. 이미지가 많은 검수 파이프라인이라면 base64 인라인 제약과 요청 크기 한도를 먼저 재야 합니다. 임계값은 가이드가 말하듯 애플리케이션의 오탐·미탐 비용으로 정해야 하며, 예시 확률만 보고 운영 기준을 고정하지 않는 편이 안전합니다.

Playground에서 질문 스키마를 시험한 뒤 SDK 버전을 맞추고, ZDR·유럽 레지던시가 필요한 조직은 data controls 문서를 함께 확인하면 됩니다. Decisions로 바꾼 라우팅 구간의 지연·비용 전후를 측정한 팀이 있으면 댓글로 알려 주시면 다음에 비교표를 보강하겠습니다.