오픈AI, 결정 전용 Decisions API 공개

오픈AI가 9월 29일 데브데이 2026에서 결정 전용 API인 Decisions API를 공개했다. 개발자가 질문과 미리 정한 답 목록, 텍스트나 이미지로 된 맥락을 넣으면 GPT-6 Luna가 그 목록 안에서 답 하나를 골라 돌려주는 방식이다. 오픈AI 개발자 계정은 X 게시물에서 "Decisions API로 앱에 실시간 의사결정 능력을 더하라"고 밝혔다. 지금은 일부 고객에게만 열린 제한 프리뷰이고, 오픈AI는 며칠 안에 광범위 출시를 하겠다고 예고했다.

오픈AI는 데브데이 정리 글에서 이 API가 "사용자가 정한 특정 질문과 미리 정해 둔 유한한 답에 Luna의 지능을 집중해 실시간 의사결정을 가능하게 한다"고 설명했다. 회사가 꼽은 쓰임새는 콘텐츠 분류, 요청 라우팅, 에이전트의 다음 행동 선택 세 가지다. 대화형 모델처럼 문장을 써 주는 대신 개발자가 정의한 선택지 가운데 하나만 내놓기 때문에, 앱은 응답을 해석하는 과정 없이 결과를 곧바로 분기 조건으로 쓸 수 있다. 보도에 따르면 결과에는 답과 함께 확신도 점수가 붙는다.

메탈이 확인한 28초 분량의 공식 시연 영상은 속도 비교에 집중한다. 고객 요청 1만 건이 담긴 스프레드시트를 결제(Billing)·기술(Technical)·영업(Sales) 세 갈래로 나누는 작업을 기존 Responses API와 Decisions API로 나란히 돌렸다. 화면에 표시된 처리 시간은 Responses API가 요청당 1.6초, Decisions API가 요청당 150밀리초였다. 15배속으로 보여 준 화면에서 Decisions API가 1만 건을 모두 끝냈을 때 Responses API는 2,000건을 처리하고 있었고, 영상은 "약 10배 빠른 결정"이라는 문구로 끝난다. 보도에 따르면 오픈AI는 같은 150밀리초 대 1.6초 비교를 기자들에게도 제시했다. 측정 지역과 입력 크기, 동시 요청 수 같은 조건은 영상과 발표 어디에도 나오지 않는다.

엔진인 GPT-6 Luna는 9월 22일 공개된 GPT-6 계열의 가장 작은 모델이다. 메탈은 오픈AI가 GPT-6 Sol과 Luna를 공개한 소식을 보도한 바 있다. 오픈AI 개발자 문서는 Luna를 "집중적이고 대량인 작업을 위한 가장 효율적인 모델"로 소개한다. 문서에 따르면 Luna의 컨텍스트 창은 105만 토큰, 최대 출력은 12만 8,000토큰, 지식 기준일은 2026년 5월 18일이다. 입력은 텍스트와 이미지를 받고 출력은 텍스트만 낸다. 같은 문서에서 Luna의 미세조정 항목은 지원하지 않음으로 표시돼 있다.

결정 모델이라는 범주를 먼저 연 쪽은 오픈AI가 아니다. 타입세이프 AI는 9월 15일 문장을 쓰지 않고 정해진 형식의 답과 확신도만 돌려주는 모델 Jev를 내놨고, 9월 21일 정식 출시했다. 메탈은 타입세이프가 결정 모델 Jev를 공개한 소식을 보도한 바 있다. 보도에 따르면 Decisions API는 Jev의 급부상에 대한 대응일 가능성이 높고, 오픈AI가 데브데이에 맞춰 발표를 서둘렀다는 분석도 나왔다. 오픈AI에도 비슷한 전례는 있다. 유해 콘텐츠를 가려내는 Moderation API는 오래전부터 문장 대신 범주별 점수를 돌려줬다. 다만 그 범주는 오픈AI가 정했고, Decisions API에서는 범주를 개발자가 직접 쓴다.

오픈AI 대변인은 추가 세부 사항을 "광범위 출시 시점에" 공유하겠다고 밝혔다고 보도됐다. 호출당 요금, 한 요청에 넣을 수 있는 후보 답의 개수, 자체 데이터로 조정할 수 있는지는 아직 나오지 않았다. 요청 한도와 제공 지역도 공개되지 않았다. 메탈이 9월 30일 오픈AI 개발자 문서 색인을 확인한 결과 Decisions API를 다룬 가이드나 API 참조 항목은 아직 없었다. 지금 이 API에 대한 공식 정보는 X 게시물과 데브데이 정리 글, 시연 영상이 전부다.

테크 변호사의 눈으로 보면 이 API의 무게는 속도보다 답의 목록이 닫혀 있다는 데 실린다. 허용되는 답이 모두 미리 정해져 있으니 앱은 정의하지 않은 답을 거부하고, 갈래마다 다른 권한 수준을 걸고, 맥락이 모자랄 때 사람에게 넘기는 구조를 짤 수 있다는 분석이 개발자 업계에서 나왔다. 테스트 사례마다 정답 범주가 있어 오답의 비용을 미리 재 볼 수 있다는 점도 장점으로 꼽혔다. 같은 분석은 제약된 모델도 틀린 유효 답을 고를 수 있고, 오도하는 맥락에 휘둘리거나 개발자가 쓴 범주의 편향을 그대로 물려받을 수 있다고 짚었다. 그래서 목록에 검토 필요나 모름 같은 보류 선택지를 넣어 별도 절차로 돌리라는 권고가 붙었다. 결정은 모델이 고르지만 선택지의 목록을 쓴 쪽은 개발자다. 요금과 서비스 수준 약정이 나오기 전까지 이 API가 가장 먼저 자리 잡을 곳은 결제나 고객 응대가 아니라 문의 분류처럼 잘못 골라도 되돌릴 수 있는 갈림길이다.