GPT-Live 에 Decisions 붙이기, 말 끝나기 전 분류하는 native 위임 설계

GPT-Live 음성 에이전트가 사용자 말이 다 끝나기 전에 할 일을 고르게 하려면 어디를 바꾸면 되나. 2026년 10월 15일(현지 시각)부터는 세션 설정의 delegation.type 을 decisions 로 두면, Live 가 앱을 거치지 않고 대화 전사본을 Decisions API 에 넘겨 미리 정한 선택지 가운데 하나를 받아 온다. 판단 요금은 입력 100만 토큰당 0.10달러뿐이다. 다만 Decisions 는 라벨만 고르고 날짜·예약 번호 같은 인자는 만들지 않아서, 그 몫은 여전히 앱이나 Responses API 가 맡는다.

01 GPT-Live 는 판단을 백엔드에 맡기도록 만든 음성 모델이다

GPT-Live 1(gpt-live-1)은 듣기와 말하기를 동시에 하는 전이중(full-duplex) 음성 모델이다. 추론과 도구 실행은 직접 하지 않고 백엔드 에이전트에 넘기도록 설계됐으며, 2026년 9월 10일 API 에 정식 출시됐다. 넘기는 방식은 그동안 둘이었다. responses 위임은 Live 가 지정된 Responses 모델을 직접 부르는 길이고, client 위임은 앱이 자기 에이전트나 워크플로를 돌려 결과를 돌려주는 길이다.

client 위임에서 앱이 받는 session.delegation.created 이벤트에는 사용자가 한 말이 담겨 있지 않다. 위임 ID 와 대상만 오기 때문에 앱은 전사 이벤트와 자기 상태를 모아 무슨 요청인지 다시 맞춰 봐야 한다. 그렇게 내린 판단은 session.commentary.append 로 Live 에 돌려준다.

Decisions API 는 10월 6일 공개 베타로 나왔다. 엔드포인트는 POST /v1/decisions 이고 모델은 gpt-6-luna 하나뿐이다. 글을 생성하지 않고 형태가 정해진 답만 돌려준다. 질문은 세 종류다. 조건이 참일 확률을 내는 predicate, 준 선택지 중 하나를 고르는 choice, 순서 있는 단계로 점수를 매기는 score 가 있다. 라벨과 확률을 돌려주는 결정 모델의 일반 구조는 결정 모델 Jev 와 Laya, 장단점과 고르는 법 에서 따로 정리했다.

이 연동 전에도 음성 봇에서 Decisions 를 쓸 수는 있었다. 다만 client 위임 경로를 밟아 Live → 앱 → Decisions → 앱 → Live 로 한 바퀴를 돌아야 했다. AI타임스가 짚은 변화도 이 중계 단계가 빠진다는 점이다.

02 10월 15일부터 Live 가 Decisions 를 직접 부르고, 전사 도중에도 판단한다

OpenAI 개발자 변경 이력의 10월 15일 항목에 GPT-Live 의 네이티브 Decisions 연동이 올라왔다. AI타임스는 19일 이 소식을 전하면서 선을 그었다. 챗GPT 이용자에게 새 음성 기능을 주겠다는 발표가 아니라 개발자용 API 기능이라는 것이다. 쓰는 길은 두 갈래다.

첫째는 위임이다. session.delegation 에 Decisions 질문을 적고, 세션 지시문(instructions)으로 언제 위임할지 알려 준다. 그러면 Live 는 앱이 처리할 수 있는 요청을 알아챈 순간 대화 전사본을 Decisions 로 직접 보낸다. 둘째는 전사 트리거다. session.triggers 에 사용자 발화 전사(session.input_transcript.delta)나 Live 응답 전사(session.output_transcript.delta)를 걸어 두면 전사 조각이 들어올 때마다 판단이 돈다. 트리거는 위임과 상관없이 따로 돈다.

준비물은 많지 않다. 동작하는 Live 연결과 API 키의 api.decisions.write 권한이면 된다. 공식 가이드는 평소 쓰던 Live 연결 헤더를 그대로 쓰면 되고, Decisions 전용 알파 헤더는 필요 없다고 적었다.

속도 주장은 걸러 읽는다. OpenAI 는 Decisions 가 Responses API 보다 약 10배 빠르다고 하지만, Decisions 가이드와 음성 연동 가이드 어디에도 지연 시간 수치는 없다. AI타임스도 이 대목을 회사 측 설명으로 전했다. Decisions API 는 아직 공개 베타이고, 가이드는 몇 주 안에 정식 출시(GA)를 예상한다고만 밝혔다.

03 native 위임은 앱을 거치는 왕복 한 번을 줄인다

세 쓰임새를 나란히 놓으면 차이가 보인다.

custom 위임에서는 Live 가 앱에 알리고, 앱이 전사를 모아 Decisions 를 부른 뒤 답을 해석해 Live 로 돌려보낸다. native 에서는 Live 가 곧장 Decisions 를 부르고 앱은 답만 받는다. 요청을 짜는 단계와 앱을 경유하는 왕복이 빠지는 대신, 전사본을 보내는 일은 Live 가 알아서 한다. 앱이 판단에 보탤 수 있는 것은 아래에서 볼 상태 스냅샷이다.

위임 종류는 세션을 만들 때 정하고, 그 세션이 끝날 때까지 바꾸지 못한다. 질문 목록은 session.update 로 고칠 수 있지만, 짝이 되는 session.updated 를 받은 뒤에야 그 단계의 decision 항목을 넣을 수 있다. 그래서 native 와 custom 을 견주는 실험은 통화 안이 아니라 세션 단위로 나눠야 한다.

04 선택지는 세션 설정에 적고, 답은 delegation_id 로 짝짓는다

공식 가이드의 예시는 차량 실내 온도와 김서림 제거를 정하는 음성 비서다. 아래는 같은 키 구조에 식당 예약 상담을 얹어 본 session 설정이다. 질문 이름과 선택지는 이 글에서 지은 것이고, 연결 방식(transport) 같은 나머지 필드는 뺐다.

{
  "model": "gpt-live-1",
  "instructions": "예약 변경·취소·상담원 연결 요청이면 위임하고, 앱의 보고를 받은 뒤 답한다.",
  "delegation": {
    "type": "decisions",
    "decisions": {
      "model": "gpt-6-luna",
      "questions": [
        {
          "type": "choice",
          "name": "intent",
          "instructions": "요청 종류를 고른다. 예약과 무관하면 none.",
          "choices": [{ "value": "change" }, { "value": "cancel" }, { "value": "agent" }, { "value": "none" }]
        },
        { "type": "choice", "name": "needs_response",
          "instructions": "예약 처리를 넘어 설명이나 검색이 필요하면 yes.",
          "choices": [{ "value": "yes" }, { "value": "no" }] }
      ]
    }
  }
}

질문은 저마다 따로 답을 받지만 요청은 한 번에 묶여 나간다. 가이드 예시처럼 선택지마다 none·no 같은 '할 일 없음' 값을 두고, 그 값이 오면 해당 동작을 건너뛴다. needs_response 는 분류만으로 끝나지 않는 요청을 골라내는 질문이다.

세션이 열린 뒤에는 이 순서로 흐른다.

1. Live 가 위임할 요청을 알아채면 session.delegation.created 가 오고, 앱은 delegation.id 를 저장한다.
2. Live 가 전사본을 Decisions 에 보내고, 답은 decision.event 로 돌아온다. delegation_id 로 짝을 맞추고, event.type 이 decision.completed 이면 event.decision.answers 에서 질문 이름별 값을 읽는다.
3. 앱이 실제 동작을 실행하고 시스템 상태를 다시 읽는다.
4. 상태가 바뀌었을 때만 decision.item.create 로 현재 상태 스냅샷을 사용자 메시지로 덧붙인다.
5. decision.item.created 를 받은 뒤, 같은 delegation_id 로 session.commentary.append 를 보내 결과를 Live 에 알린다.

가장 최근 스냅샷이 현재 상태로 읽힌다. 가이드는 앞선 입력을 그대로 두면 프롬프트 캐싱에 유리하다고 설명하므로, 바뀐 것만 뒤에 덧붙이는 편이 낫다. 4·5단계의 메시지는 아래 모양이다.

{ "type": "decision.item.create", "event_id": "evt_after_cancel_1",
  "item": { "type": "message", "role": "user",
    "content": [{ "type": "input_text", "text": "현재 상태: 10월 24일 19시 예약 취소 완료" }] } }

{ "type": "session.commentary.append", "delegation_id": "del_resv_1",
  "content": "예약을 취소했고 예약 시스템에서 취소 상태를 확인했다." }

브라우저에서 WebRTC 이벤트를 걸러 받고 있다면 session.delegation.created·decision.event 와 전사 이벤트를 허용 목록에 넣는다. 빠지면 위임 결과나 트리거 결과가 앱에 닿지 않는다. 확률도 확인할 거리다. 단독 Decisions API 의 choice 답은 고른 값과 함께 선택지별 확률과 confidence 를 주는데, 음성 가이드 예시는 answers 에서 고른 값만 읽는다. 확률로 문턱을 걸 생각이라면 이벤트에 어떤 필드가 실려 오는지 먼저 찍어 보고 정한다.

05 인자가 필요한 요청은 Responses 로 넘기고, 같은 판단은 한 번만 실행한다

Decisions 는 함수 호출 인자나 임의 JSON 을 만들지 않는다. 가이드는 도구 인자가 필요하면 function calling 을, 내 JSON 스키마를 따르는 객체가 필요하면 Responses API 의 Structured Outputs 를 쓰라고 안내한다. 음성 가이드는 이 경계를 질문 하나로 처리한다. needs_response 가 yes 면 서버가 api.responses.write 권한으로 Responses API 를 부르고, strict 를 켠 start_navigation(destination) 같은 도구를 돌려 최종 답을 얻는다. Live 에는 그 가운데 짧은 결과만 session.commentary.append 로 넘긴다.

예약 봇에 옮기면 역할이 이렇게 갈린다. "취소할게요" 를 cancel 로 분류하는 일은 Decisions 가 말 도중에 끝낸다. 어느 예약을 취소할지는 발신 번호로 찾은 예약 기록처럼 앱이 이미 가진 정보로 정하고, 그런 정보가 없으면 Responses 의 함수 호출로 넘긴다. 단계마다 날짜·인원·연락처를 받아야 하는 흐름이라면 어차피 Responses 를 거치므로 native 위임으로 아끼는 시간이 크지 않다.

결과를 Live 에 넘기는 session.commentary.append 도 성격을 알고 써야 한다. 위임 가이드에 따르면 Live 는 받은 글을 그대로 읽지 않고 바꿔 말하도록 학습됐고, 한 번에 넣을 수 있는 글은 500토큰까지다. 곧바로 말하지 않고 나중 답에만 참고할 사실은 session.thinking.append 로 보낸다. 한 글자도 바뀌면 안 되는 고지 문구라면 commentary 에만 맡기지 않는 편이 안전하다.

실행 안전장치는 앱이 챙긴다. AI타임스는 오판으로 같은 동작이 거듭 실행되지 않게 막고, 실행 가능한 동작의 범위도 좁혀 두라고 덧붙였다. OpenAI 서버 제어 가이드 역시 한 번만 실행돼야 하는 함수 호출처럼 동작마다 처리 주체를 하나로 정하라고 권한다. 위임 결과는 delegation_id, 트리거 결과는 source_event_id 를 키로 실행 기록을 남기면 같은 판단이 두 번 와도 한 번만 처리된다.

트리거 결과는 도착 순서를 믿지 않는다. Live 는 쌓인 전사 델타를 합쳐 보내기도 하고, 결과가 뒤바뀌어 올 수도 있다. 가이드가 입력·출력 방향마다 가장 최근의 관련 결과만 적용하라고 한 까닭이다. 아바타 입 모양처럼 시점이 정확해야 하는 움직임은 판단 결과가 아니라 오디오에 맞춰 움직이라는 안내도 함께 있다.

06 비용은 판단보다 통화 시간이 좌우한다

2026년 10월 공식 문서 기준으로 값을 모으면 아래와 같다.

가정을 하나 두고 셈해 본다. 판단 한 번의 입력을 2,000토큰으로 잡으면 비용은 0.0002달러다. 한 통화에서 20번을 판단해도 0.004달러에 그친다. 같은 통화가 3분이면 음성 요금만 0.15달러이고, 판단 비용은 그 3%에도 못 미친다.

다만 native 위임은 대화 전사본을 넘기므로, 통화가 길어질수록 판단 한 번의 입력도 커진다고 보는 편이 안전하다. 실제 청구서를 키우는 쪽은 needs_response 경로에서 부르는 Responses 모델과 도구다. 이 요금은 Live·Decisions 와 별도로 해당 모델 요금대로 매겨진다. 동시에 수백 통을 받는 상담 창구라면 등급별 동시 세션 수부터 맞춰 봐야 한다.

07 한국 개발자에게: 상담·예약 봇의 의도 분기부터 옮겨 볼 만하다

가장 먼저 얻을 게 있는 쪽은 이미 GPT-Live 를 client 위임으로 쓰면서 의도 분류를 직접 돌리는 팀이다. 상담 유형, 담당 부서, 상담원 연결 여부처럼 선택지가 닫혀 있는 분기는 질문 몇 개로 옮길 수 있다. 전화 상담이라면 GPT-Live 가 SIP 전화 연결을 지원하고, 서버는 사이드밴드 WebSocket 으로 진행 중인 세션에 붙어 이벤트를 받고 명령을 보낼 수 있다. 판단 결과를 브라우저가 아니라 서버에서 받아 처리하는 콜센터 구조도 이 위에서 짤 수 있다.

Realtime API 로 만든 봇은 바로 쓰지 못한다. gpt-live-1 이 지원하는 엔드포인트는 Live 세션(v1/live/sessions) 하나이고, Realtime 엔드포인트는 지원 목록에 없다. 이 기능이 필요하면 Live 세션으로 옮기는 일이 먼저다.

개인정보는 따로 따져야 한다. Decisions 가이드가 밝힌 데이터 상주·지역 처리 선택지는 미국과 유럽(EEA·스위스)뿐이고, 국내 리전은 문서에 없다. ZDR(데이터 무보존)과 HIPAA 용도는 자격을 갖춘 고객에게만 열려 있다. 통화 전사에는 이름이나 전화번호가 섞이기 쉬우니, 출시 전에 국외 처리 여부를 개인정보 검토에 올려 두는 것이 순서다.

한국어 성능은 직접 재야 한다. 공식 문서에는 한국어 판단 정확도도, 지연 시간 수치도 없다. 위임 가이드는 방식을 비교할 때 백엔드가 끝난 시점이 아니라, 사용자가 처음으로 쓸모 있는 답을 듣는 시점을 재라고 권한다. 자기 상담 전사 샘플로 custom 과 native 를 이 기준에서 나란히 재 보면 옮길지 말지가 나온다.

서두르지 않아도 되는 경우도 있다. 말이 끝난 뒤 답해도 충분한 질의응답형 봇, 모든 단계가 인자 수집인 흐름, 베타 API 에 기대기 어려운 서비스라면 Decisions 의 GA 공지를 보고 움직여도 늦지 않다.

08 지금 확인할 것은 권한, 이벤트 필터, 중복 실행이다

1. API 키 권한에 api.decisions.write 가 있는지, Responses 로 넘기는 경로가 있다면 api.responses.write 도 있는지 본다.
2. WebRTC 이벤트 필터에 session.delegation.created·decision.event·전사 이벤트를 넣는다.
3. 질문마다 '할 일 없음' 선택지를 두고, 인자가 필요한 요청은 needs_response 같은 질문으로 Responses 에 넘긴다.
4. 실행 기록을 delegation_id·source_event_id 기준으로 남겨 같은 판단을 두 번 실행하지 않는다.
5. 위임 종류를 세션 생성 설정값으로 빼 두고, custom 과 native 를 세션 단위로 번갈아 재 본다.
6. Decisions GA 공지가 나오면 요금·한도·데이터 상주 범위를 다시 확인한다.

09 자주 묻는 질문

통화 도중에 native 위임을 custom 으로 바꿀 수 있나

아니오. 위임 종류는 세션을 만들 때 정하고 그 세션 동안 고정된다. 세션 안에서 고칠 수 있는 것은 session.update 로 바꾸는 질문 목록이다.

Realtime API 로 만든 음성봇에 바로 붙일 수 있나

아니오. gpt-live-1 은 Live 세션 엔드포인트만 지원하므로 Live 세션으로 먼저 옮겨야 한다.

챗GPT 음성 모드에도 들어가는 기능인가

아니오. 이번 연동은 개발자용 API 기능이고, 챗GPT 이용자용 음성 기능으로 발표된 것은 아니다.

판단 비용은 답이 길어지면 늘어나나

아니오. Decisions 는 입력 토큰에만 100만 토큰당 0.10달러를 매기고 출력 요금은 없다. 다만 통화가 길어 전사본이 커지면 입력이 늘어난다.