OpenAI Decisions API를 에이전트 루프에 둘 때 정할 경계

OpenAI가 2026년 9월 29일 제한 프리뷰로 공개한 Decisions API를 에이전트 루프의 닫힌 판단 단계에 두고, 권한·상한·예외 처리는 직접 짠 정책 코드에 남기는 설계를 정리합니다.

LinkedIn 공유Threads 공유

반복하는 고리 모양 경로 위에 칸이 정해진 선택 틀과 잠금 장치가 놓인 그림

발표된 내용과 제공 상태

OpenAI는 2026년 9월 29일 DevDay 2026 정리 글에서 Decisions API를 발표했습니다. 발표문은 이 기능이 사용자가 정의한 질문과 미리 정해 둔 유한한 답 후보에 Luna 모델의 판단을 집중시켜 실시간으로 결정을 내린다고 설명합니다. 개발자가 텍스트나 이미지로 맥락을 넘기면 답을 받고, 그 답을 콘텐츠 분류, 요청 라우팅, 에이전트의 다음 행동 선택에 쓸 수 있다고 적혀 있습니다.

제공 상태는 제한 프리뷰(limited preview)입니다. 발표문은 며칠 안에 더 넓게 공개할 계획이라고만 밝혔고 날짜는 적지 않았습니다. Decisions API 단락에는 요금제나 지역 제한에 관한 문구도 없습니다.

2026년 10월 4일 OpenAI 개발자 문서의 변경 기록(changelog)을 확인했을 때, 9월 29일 항목에는 Agents API의 컴퓨터 사용 기능, GPT-6.1 Sol, GPT-6 Astra의 Ultrafast 모드가 올라와 있었고 Decisions API는 없었습니다. 엔드포인트 주소, 요청과 응답 형식, 가격도 공식 페이지에서 찾지 못했습니다. 그래서 이 글은 호출 방법은 다루지 않고, 에이전트 설계에서 이 기능을 어느 단계에 둘지만 다룹니다.

닫힌 판단은 어떤 판단인가

발표문 설명대로라면 Decisions API에서는 개발자가 질문과 답 후보를 미리 정해 두고, 모델은 그 후보 중 하나를 고릅니다. 이 글에서는 이런 판단을 '닫힌 판단'이라고 부르겠습니다.

예시로, 고객 문의를 처리하는 에이전트를 생각해 보겠습니다. '이 문의를 어느 담당으로 넘길까'라는 질문에 환불, 배송, 기술 지원, 기타의 답 후보 4개를 정해 두면 문의 본문과 첨부 사진을 맥락으로 넘겨 답 하나를 받을 수 있습니다. '이 사진에 주민등록번호가 보이는가'처럼 예와 아니오로 끝나는 질문도 같은 형태입니다.

작성자 판단으로는 답 후보를 미리 적을 수 없는 일에는 맞지 않습니다. 환불 금액을 계산하거나, 고객에게 보낼 답장을 쓰거나, 처음 보는 유형의 문의를 해석하는 일은 답이 열려 있습니다. 이런 일을 후보 목록에 억지로 넣으면 '기타'로 분류되는 건이 늘어나고, 결국 다른 단계에서 다시 판단해야 합니다.

에이전트 루프에서 닫힌 판단이 맡는 단계

에이전트는 맥락을 모으고, 다음 행동을 정하고, 실행하고, 결과를 기록한 뒤 다시 판단하는 과정을 반복합니다. 발표문이 에이전트의 다음 행동 선택을 용도로 든 만큼, Decisions API는 이 반복 가운데 다음에 무엇을 할지 고르는 단계에 넣을 수 있습니다.

작성자는 이 호출 바로 뒤에 정책 코드를 두는 구성을 권합니다. 모델이 고른 답은 다음 행동의 후보이고, 그 행동을 실제로 해도 되는지는 따로 확인해야 하기 때문입니다. 아래 도식은 이 순서를 예시로 그린 것입니다. Decisions API가 실제로 어떤 필드를 주고받는지는 공개되지 않아 도식에도 넣지 않았습니다.

에이전트 루프의 다섯 단계 가운데 닫힌 판단 호출 단계와 그 뒤의 정책 코드 확인 단계를 표시한 순환 도식
작성자 구성 예시입니다. 닫힌 판단의 용도(분류, 라우팅, 다음 행동 선택)는 OpenAI 발표문 기준이고, 단계 순서와 정책 코드의 위치는 작성자 해석입니다. 이미지를 열어 확대할 수 있습니다. 화면이 좁으면 도식을 가로로 스크롤해 글자를 확인하세요.

정책 코드와 사람 검토에 남길 판단

모델이 답 후보 중 하나를 골랐다고 해서 그 답대로 실행해도 되는 것은 아닙니다. 작성자는 아래 표의 둘째 줄부터를 Decisions API 결과와 상관없이 직접 짠 코드나 사람 검토로 처리하기를 권합니다. Decisions API의 정확도와 오류 처리 방식이 아직 공개되지 않았으므로 더욱 그렇습니다.

권한 확인을 모델에게 묻는 질문으로 만들어 두면, 모델의 답이 틀렸을 때 권한 확인도 함께 틀립니다. 질문 목록에는 '어느 쪽인가'만 넣고, '해도 되는가'는 코드에서 확인하면 모델이나 API 형식이 바뀌어도 규칙은 그대로 유지됩니다.

판단처리 위치예시
문의 유형 분류, 담당 라우팅Decisions API 호출환불, 배송, 기술 지원, 기타 중 하나
이 사용자가 그 작업을 요청할 권한이 있는가정책 코드계정 등급, 담당 고객 여부 확인
금액과 횟수 상한정책 코드자동 환불은 정해 둔 금액 이하만 허용
후보 밖 답이나 빈 응답정책 코드'기타'로 처리하고 사람 대기열에 등록
되돌릴 수 없는 작업사람 검토결제 취소, 외부 발송, 데이터 삭제

공식 문서가 나오기 전까지 미룰 것

2026년 10월 4일 기준으로 엔드포인트 주소, 요청과 응답 형식, 가격, 넓은 공개 날짜는 공식 페이지에 적혀 있지 않아 확인하지 못했습니다. 발표문은 Luna라는 모델 이름만 언급하고 모델 설명 페이지는 연결하지 않았습니다. 'OpenAI Decisions API'를 이름에 쓴 외부 사이트도 여럿 있지만, 스스로 OpenAI와 관계없는 서비스라고 밝히고 있어 근거로 쓰지 않았습니다.

작성자 판단으로는 지금 특정 필드 이름에 맞춘 연동 코드를 짜기보다, 우리 코드 안에 질문과 답 후보와 맥락을 받아 답 하나를 반환하는 함수를 정의해 두는 정도가 적당합니다. 당장은 이 함수 안에서 기존 모델 호출이나 규칙으로 답을 만들고, 공식 문서가 나오면 함수 안쪽만 바꾸면 됩니다. 정책 코드는 이 함수 밖에 있으므로 고칠 필요가 없습니다.

이번 주에 해 볼 첫 단계

지금 운영하거나 만들고 있는 에이전트 하나를 골라, 실행 기록에서 모델이 다음에 무엇을 할지 고른 단계를 모두 적어 보십시오. 그중 답 후보를 5개 안팎으로 미리 적을 수 있는 단계에 표시하고, 표시한 단계마다 답 후보 목록과 '기타'로 분류됐을 때 넘길 곳을 적습니다.

마지막으로 각 답 뒤에 붙는 권한 확인, 상한, 사람 검토 조건을 한 줄씩 적으면 됩니다. 이 목록이 있으면 Decisions API가 넓게 공개됐을 때 어느 단계부터 바꿔 볼지 바로 정할 수 있습니다.

확인한 공식 출처

  1. OpenAI DevDay 2026 recap (OpenAI, 2026년 9월 29일)
  2. OpenAI API Changelog, 2026년 9월 29일 항목 (OpenAI 개발자 문서, 2026년 10월 4일 확인)