OpenAI가 텍스트와 이미지를 평가해 정형화된 답을 돌려주는 디시전(Decisions) API를 공개 베타로 내놓았다. 핵심은 자유로운 문장을 생성하는 것이 아니라, 애플리케이션이 곧바로 분기 처리에 쓸 수 있는 '판단값'을 반환한다는 데 있다. OpenAI는 이 API가 응답(Responses) API 대비 약 10배 빠르게 결과를 돌려준다고 설명한다. 조건이 참일 확률, 고정된 선택지 중 하나, 루브릭 기준 점수라는 세 가지 형태의 답을 받아 콘텐츠를 분류하거나 요청을 라우팅하고 작업 우선순위를 매기는 용도다. 현재는 공개 베타 단계이며 정식 출시는 수 주 내로 예정돼 있다.
세 가지 답변 유형
디시전 API가 제공하는 답은 크게 세 종류다. 첫째는 조건이 참일 확률을 돌려주는 술어(predicate)형이다. 예를 들어 제품 사진에 균열·찢어짐·찌그러짐 같은 손상이 보이는지를 묻고, 모델이 추정한 '참일 확률'을 받는다. 개발자는 이 확률에 자신이 정한 임계값을 걸어 사람이 검토할 사진을 걸러낼 수 있다. 둘째는 고정된 선택지에서 하나를 고르는 choice형으로, 부서 구분처럼 순서가 없는 범주에 적합하다. 고객 불만을 라우팅하는 예시에서는 'billing' 같은 값과 함께 각 선택지의 확률 배열, 그리고 별도의 신뢰도(confidence) 값을 돌려준다. 셋째는 루브릭의 순서가 있는 단계를 평가하는 score형이다.
score형은 단계마다 기준을 정의하고 낮은 등급에서 높은 등급 순으로 배열한다. 인덱스는 0부터 시작하며, 예시에서는 0이 '겉보기 손상', 1이 '우회 방법 존재', 2가 '완전 차단'을 뜻한다. 반환되는 점수는 각 단계 확률을 가중평균한 값이라 단계 사이에 떨어질 수 있다. 가령 확률이 각각 0.1, 0.7, 0.2이면 점수는 1.1이 된다. 순서가 없는 범주 분류에는 choice를, 심각도처럼 순서가 있는 수준 평가에는 score를 쓰라는 것이 OpenAI의 권고다.
언제 쓰고, 언제 다른 API를 쓰나
디시전 API는 응답을 직접 생성하는 도구가 아니라는 점을 분명히 할 필요가 있다. 추출한 필드나 서술형 설명처럼 개발자가 정의한 JSON 스키마를 따르는 객체를 만들어야 한다면 응답 API의 구조화 출력(Structured Outputs)을, 모델이 인자를 담아 도구 호출을 요청해야 한다면 함수 호출(function calling)을 쓰는 편이 맞다. 디시전 API는 어디까지나 위의 세 가지 판단값 중 하나가 필요할 때 선택하는 전용 도구다. 서로 독립적인 질문은 하나의 questions 배열에 묶어 같은 입력을 한 번에 평가할 수 있고, 질문마다 유형을 다르게 지정할 수도 있다. 다만 앞선 답에 따라 다음 판단이 달라지는 경우라면 요청을 분리해야 한다. 먼저 손상 여부를 확인한 뒤 그 결과로 수리 범주를 물어보는 식이다.
이미지를 다룰 때는 제약이 있다. 입력 이미지는 반드시 base64 인라인 데이터 URL이어야 하며, 호스팅된 HTTP·HTTPS 주소나 file_id 입력은 이 엔드포인트에서 지원하지 않는다. 지시문이나 맥락과 함께 이미지를 평가하려면 사용자 메시지 안에서 input_text와 input_image 파트를 조합한다. 질문 설계 원칙도 함께 제시됐다. 관찰 가능한 기준을 중심으로 질문을 쓰고, 서로 다른 관심사는 별개 질문으로 나누며, 선택지는 뜻이 겹치지 않게, 점수 단계는 인접 단계끼리 기준이 구별되도록 정의하라는 것이다. 임계값은 실제 데이터에 라벨을 붙여가며 거짓 양성과 거짓 음성의 비용을 저울질해 정하도록 안내한다.
가격과 적용 조건
현재 사용할 수 있는 모델은 gpt-6-luna 하나이며, 전용 POST /v1/decisions 엔드포인트를 호출한다. SDK는 파이썬 3.26.0, 자바스크립트 7.30.0, Go 3.73.0, 루비 0.101.0, 자바 4.78.0 이상에서 예제가 동작한다. 가격 구조가 특징적이다. 입력 토큰에 대해 100만 토큰당 0.10달러만 부과되고 캐시 읽기·쓰기나 출력 토큰 요금은 없다. 다만 지역 처리 프리미엄과 장문맥 입력 배수가 적용되며, 이 요율은 /v1/decisions에 한한다. 같은 gpt-6-luna라도 다른 요청은 해당 모델과 처리 등급의 일반 가격을 따른다. 운영 측면에서는 적격 고객에 한해 무데이터보존(ZDR)과 HIPAA 활용을 지원하고, 데이터 레지던시와 지역 처리는 미국과 유럽(EEA 및 스위스)에서 제공된다. 코드 작성 전에 플레이그라운드에서 질문과 입력을 먼저 실험해볼 수 있고, 라이브(Live) API와의 클라이언트 위임을 통해 음성 요청에서 행동을 선택하고 그 결과를 사용자에게 보고하는 활용도 가능하다.
실무자 입장에서 눈여겨볼 지점은 '빠른 분류'를 별도 엔드포인트로 떼어냈다는 설계 자체다. 라우팅·필터링·우선순위 판정처럼 대량·저지연이 중요한 작업을 생성형 API에 맡기던 관행을, 확률 분포와 신뢰도를 명시적으로 돌려주는 전용 경로로 대체할 수 있게 됐다. 다만 지원 모델이 하나뿐이고 아직 베타라는 점, 호스팅 이미지 URL을 못 받고 상태 의존 판단은 요청을 쪼개야 한다는 제약은 설계 단계에서 미리 감안해야 한다. 임계값을 자체 라벨 데이터로 보정하라는 권고는, 이 API가 즉시 쓰는 '정답기'가 아니라 확률값을 어떻게 끊어 쓸지 사용자가 책임지는 도구임을 시사한다.