OpenAI Decisions API: 타입형 AI 판단이 소프트웨어를 바꾸는 방식

핵심 요약: AI 소프트웨어에 전용 판단 엔드포인트가 생긴다

OpenAI는 2026년 10월 6일 Decisions API를 베타로 발표했습니다. 이 API는 범용 생성 API보다 범위를 좁혀 텍스트, 이미지 또는 둘 다를 평가하고 소프트웨어가 사용할 수 있는 타입형 답을 반환합니다. 공식 가이드는 조건이 참일 확률을 반환하는 predicate, 고정 집합에서 고르는 choice, 순서가 있는 단계로 평가하는 score를 설명합니다. OpenAI는 이런 판단 작업이 Responses API보다 최대 10배 빠를 수 있다고 말합니다.

이는 모든 생성 API를 대체한다는 뜻이 아닙니다. 라우팅, 트리아지, 모더레이션, 우선순위 지정, 이미지 검사처럼 문단이 아니라 제한된 결과가 필요한 곳에 더 잘 맞을 수 있다는 뜻입니다. 공식 Decisions API 가이드를 확인하고, 관련 소프트웨어는 BTTC 소프트웨어 디렉터리에서 비교할 수 있습니다.

무엇이 출시되었나

새 엔드포인트는 POST /v1/decisions입니다. 요청에는 모델, 공유 입력, 이름이 있는 질문이 들어갑니다. 현재 공개 베타 가이드에는 gpt-6-luna만 사용할 수 있다고 적혀 있습니다. 질문마다 평가 대상을 설명하고 필요한 경우 선택지나 순서가 있는 점수 단계를 정합니다. 응답은 answers 배열로 돌아오며 질문 이름으로 결과를 구분할 수 있습니다.

핵심은 증거와 출력 형태를 분리한다는 점입니다. 고객 불만을 결제, 기술, 배송 큐로 보낼 수 있고 상품 사진의 손상을 판단할 수 있으며 문서를 심각도에 따라 점수화할 수 있습니다. 이런 작업에는 열린 문장보다 큐, 규칙, 대시보드가 바로 사용할 수 있는 값이 필요합니다.

조건 확인에는 predicate, 순서가 없는 범주에는 choice, 순서가 있는 수준에는 score를 사용합니다. 독립적인 질문은 한 요청에 넣을 수 있지만 앞의 답이 다음 질문을 결정한다면 별도 요청을 보내야 합니다.

애플리케이션 구조에 미치는 영향

많은 AI 제품은 모든 요청을 채팅처럼 처리합니다. 프로토타입에는 편하지만 운영 환경에서는 출력 파싱, 누락 필드, 대체 경로, 자연어를 업무 동작으로 바꾸는 안전성 문제가 생깁니다.

타입형 결과는 경계를 분명하게 합니다. 확률은 임계값과 비교하고 choice는 큐에 연결하며 score는 사람 검토 구간을 열 수 있습니다. 불확실성이 사라지는 것이 아니라 측정하고 관리할 수 있는 값으로 바뀌는 것입니다.

설명, 사용자 정의 JSON, 도구 호출, 긴 답변이 필요하면 Structured Outputs나 function calling을 사용하는 Responses API가 더 적합할 수 있습니다. 제한된 분류나 순위 신호만 필요하다면 전용 요청이 지연과 후속 코드를 줄일 수 있습니다.

운영 전에 확인할 네 가지

1. 관찰 가능한 질문을 작성하라

“좋은 고객이며 우선 처리해야 하나?”는 여러 판단을 섞습니다. “청구 문제를 설명하는가?”와 “기한을 명시했는가?”로 나누세요. 이미지도 모호한 총평 대신 보이는 기준을 제시해야 합니다.

2. 라벨 데이터로 임계값을 정하라

확률은 곧바로 업무 규칙이 아닙니다. 대표 샘플로 거짓 양성과 거짓 음성을 측정하고 오류 비용에 따라 임계값을 선택하세요. 트래픽, 언어, 제품, 악용 패턴이 바뀌면 다시 평가해야 합니다.

3. 근거와 검토 경로를 남겨라

입력, 질문, 모델 버전, 임계값, 사람의 수정 결과를 추적할 수 있어야 합니다. OpenAI의 데이터 제어 문서는 /v1/decisions의 보존과 지역 처리 조건, 자격 고객을 위한 Zero Data Retention을 설명합니다. 민감한 데이터를 보내기 전에 조직에 적용되는 조건을 확인하세요.

4. 실패와 대체 경로를 설계하라

속도 제한, 시간 초과, 잘못된 입력, 모호한 사례는 일반적인 문제입니다. API가 중단되거나 신뢰도가 낮거나 점수가 경계에 있을 때 처리할 방법을 정하세요. 사람 검토나 되돌릴 수 없는 작업을 하지 않는 큐가 안전한 기본값입니다.

빠르다고 자동으로 저렴한 것은 아니다

공식 가이드는 gpt-6-luna 입력 비용을 100만 토큰당 0.10달러로 설명하지만 지역 처리 비용과 긴 컨텍스트 배수가 적용될 수 있습니다. 재시도, 모니터링, 라벨링, 검토, 저장, 통합, 잘못된 라우팅 비용까지 계산하세요. 빠르지만 사건을 잘못된 팀으로 보내는 모델은 검토 장벽이 있는 느린 흐름보다 비쌀 수 있습니다.

주변 소프트웨어를 고를 때도 로그, 재실행, 임계값 관리, 내보내기, 권한, 모델 제공 여부를 확인하세요. 멋진 데모만으로는 부족합니다. 근거를 보여주고 부분 실패에서 복구하며 나중에 공급자를 바꿀 수 있어야 합니다.

작은 범위에서 시작하는 방법

첫 실험은 반품 이미지 분류, 지원 티켓 라우팅, 내부 문서 우선순위처럼 사람이 정답을 확인할 수 있는 작업으로 정하세요. 입력 예시와 기대 결과를 저장하고 기존 규칙이나 담당자의 판단과 비교해야 합니다. 자동 답장, 계정 정지, 결제 변경처럼 되돌리기 어려운 작업에 처음부터 연결하지 마세요.

운영 후에는 언어와 지역별 정확도도 확인하세요. 짧은 문의, 긴 설명, 이미지가 있는 요청은 입력 분포가 다르므로 전체 평균만 보면 문제를 놓칠 수 있습니다. 결과 분포, 낮은 신뢰도 사례, 수동 수정, API 오류, 지연을 대시보드에 기록하고 임계값 변경 이력도 남기세요.

자주 묻는 질문

베타 동작과 지원 모델은 공식 문서를 기준으로 확인하세요.

결론

Decisions API는 언어가 풍부한 작업은 생성 API로, 제한된 애플리케이션 로직은 타입형 판단으로 나누는 흐름을 보여줍니다. 라우팅과 트리아지를 단순화할 수 있지만 관찰 가능한 질문, 측정된 임계값, 추적 가능한 입력, 개인정보 검토, 안전한 대체 경로가 필요합니다.