고객이 이렇게 문의했다.
어제 결제했는데 아직 기능이 안 열려요. 해결 안 되면 취소할게요.
이 문장에 친절한 답장을 쓰는 AI는 상상하기 쉽다. 그런데 서비스 내부에서 먼저 필요한 것은 답장보다 짧은 결정이다. 결제팀으로 보낼까, 기술지원팀으로 보낼까, 환불 요청으로 처리할까?
9월 29일 OpenAI가 DevDay 2026에서 공개한 Decisions API는 이런 종류의 문제를 겨냥한다. 개발자가 질문과 유한한 선택지를 정하고, 텍스트나 이미지 맥락을 제공하면 Luna의 지능을 활용해 답을 받는 방식이다. 공식 발표는 콘텐츠 분류, 요청 라우팅, 에이전트의 다음 행동 선택을 용도로 들었다. OpenAI 공식 발표
출시 발표 기준으로는 제한적 프리뷰다. 더 넓은 공개가 예정됐다는 안내와 모든 개발자가 지금 사용할 수 있다는 말은 구분해야 한다. 이 글은 실제 API를 테스트한 후기가 아니라, 공개된 제품 방향을 하나의 예시로 풀어본 해설이다.
첫 번째 설계: 선택지를 세 개로 줄이면 끝날까
앞의 문의를 분류하기 위해 다음 선택지를 만들었다고 가정하자.
1 2 3BILLING 결제 문제 TECH_SUPPORT 기능 오류 REFUND 환불 요청
이것은 실제 Decisions API의 요청 형식이 아닌 개념 예시다.
그럴듯해 보이지만 벌써 문제가 있다. 고객은 결제와 기능 오류를 함께 언급했고, 취소는 조건부로 말했다. 선택지를 제한했다고 분류 기준까지 명확해진 것은 아니다.
REFUND를 고르면 너무 이르다. TECH_SUPPORT를 고르면 결제가 실제로 반영됐는지 확인하지 못한다. BILLING을 고르는 편이 적절한지는 회사의 지원 절차에 달렸다. 결제팀이 이용 권한 활성화까지 담당하는 서비스도 있을 테고, 별도 운영팀이 처리하는 서비스도 있을 것이다.
모델이 회사의 업무 규칙을 알아서 발견해주기를 기대하기 전에, 우리가 어떤 질문을 하고 있는지 정해야 한다.
“이 문장에 어떤 주제가 들어 있는가?”와 “이 문의를 지금 누가 먼저 처리해야 하는가?”는 다른 질문이다. 전자는 여러 정답을 허용할 수 있고, 후자는 담당 조직과 처리 순서가 필요하다.
이 차이를 무시하면 팀원끼리도 답이 갈리는 데이터를 만들어놓고 모델의 정확도만 탓하게 된다.
선택지에 빠져 있던 답: 아직 고를 수 없다
두 번째 설계에서는 주제 분류 대신 다음 처리 단계를 묻기로 해보자.
1 2 3CHECK_PAYMENT_STATUS 결제 상태부터 확인 CHECK_ENTITLEMENT 이용 권한 반영 상태 확인 HUMAN_REVIEW 정보 부족 또는 예외로 담당자 검토
이 분류 역시 제안용 예시이며, 제품에 내장된 선택지 목록이 아니다.
이번에는 입력 맥락도 달라져야 한다. 문의 문장만 넘기는 대신, 적법하게 조회한 결제 상태나 이용 권한 반영 여부처럼 판단에 필요한 정보를 제공하는 것이다. 결제 확인이 끝났다면 같은 문장도 다음 단계가 달라질 수 있다.
여기서 HUMAN_REVIEW는 보기 좋은 안전 문구가 아니다. 어느 선택지도 정당화하기 어려울 때 시스템이 어디로 가야 하는지 정하는 실제 처리 경로다. 물론 선택지를 추가하는 것만으로 모델이 애매한 상황을 정확히 알아차린다고 보장되지는 않는다. 정보가 빠진 사례와 모순된 사례를 넣고 제대로 보류하는지 평가해야 한다.
반대로 모든 문의가 검토함으로 쌓인다면 자동화의 의미가 줄어든다. 무조건 보류하게 만드는 것과, 자동 처리해도 되는 범위를 구분하는 것은 다르다.
도입 전 평가에서는 전체 정답률 하나보다 이런 질문이 더 도움이 된다. 환불 의사가 없는 고객을 환불 요청으로 잘못 보냈는가? 필요한 정보가 없는데도 확정적으로 분류했는가? 쉬운 문의까지 사람이 다시 읽게 만들었는가?
이 질문들은 서로 다른 실패 비용을 드러낸다. 단순히 틀린 답의 개수를 세는 것보다 서비스가 감당할 수 있는 오류를 구체적으로 보여준다.
JSON이 잘 나온다는 것과 판단이 맞다는 것은 다르다
“기존 LLM에 정해진 값 중 하나를 JSON으로 반환하라고 하면 비슷하지 않나?”라는 질문은 자연스럽다.
맞다. 분류와 라우팅은 이 발표 전에도 만들 수 있었던 응용이다. Decisions API를 완전히 새로운 문제의 발명으로 볼 필요는 없다. 이번 발표에서 눈여겨볼 것은 범용 대화와 구분되는, 제한된 선택을 위한 제품 인터페이스가 전면에 나왔다는 점이다.
다만 공식 행사 요약만으로 기존 방식보다 얼마나 빠르고 저렴하거나 정확한지 결론 내릴 수는 없다. 이 글에서는 확인되지 않은 지연시간이나 비용 수치를 붙이지 않는다. 실제 선택은 같은 데이터와 같은 분류 기준을 놓고 비교해야 한다.
비교할 때도 세 가지를 따로 봐야 한다. 반환값이 허용된 형식인지, 내용상 올바른 선택인지, 그 선택 뒤에 실행하는 작업이 허용된 것인지다.
REFUND라는 문자열을 정확한 형식으로 받았다고 해서 환불해도 된다는 뜻은 아니다. 고객의 의사 확인, 주문 상태, 정책 조건, 실행 권한은 여전히 별도의 검증 대상이다. 모델의 분류 결과를 결제 취소 함수에 곧바로 연결하면 이 구분이 사라진다.
반대로 결제 반영 여부처럼 규칙으로 확실히 판정할 수 있는 부분은 굳이 AI에게 다시 묻지 않아도 된다. 자연어의 애매함을 해석하는 일과 시스템이 이미 알고 있는 사실을 확인하는 일을 나누는 편이 설계도 평가도 쉬워진다.
처음의 문의로 돌아가면, 고객은 멋진 답변을 기다리는 것이 아니다. 이미 결제한 기능을 쓸 수 있게 되기를 기다린다. 그 목표에 도움이 된다면 AI의 출력은 긴 설명 대신 선택지 하나여도 충분하다.
Decisions API가 던지는 개발 과제도 거기에 있다. 모델에게 말을 더 잘하게 만드는 것만큼, 우리가 고르게 할 선택지가 좋은지 살펴보는 일이다. 선택지에 업무의 기준이 빠져 있다면 더 똑똑한 모델을 붙여도 애매함은 그대로 남는다.
2026년 10월 1일 확인한 공식 발표 기준. 본문의 고객 문의·분류값·처리 흐름은 설명을 위한 가상 예시이며, 실제 SDK 명세나 성능 검증 결과가 아닙니다.