Devlery
Blog/AI

OpenAI Realtime 2, 음성 에이전트가 도구를 부른다

OpenAI의 GPT-Realtime-2는 음성 AI를 답변형 인터페이스에서 도구 호출형 에이전트 런타임으로 옮기는 업데이트입니다.

OpenAI Realtime 2, 음성 에이전트가 도구를 부른다
AI 요약
  • 무슨 일: OpenAI가 GPT-Realtime-2, GPT-Realtime-Translate, GPT-Realtime-Whisper를 Realtime API에 공개했습니다.
    • 발표일은 2026년 5월 7일이며, 핵심 메시지는 음성 모델이 대화 중 추론하고 도구를 호출하며 작업을 끝내는 인터페이스가 된다는 점입니다.
  • 의미: 음성 AI의 경쟁축이 자연스러운 목소리에서 latency, 도구 호출, 맥락 유지, 비용 제어가 결합된 에이전트 런타임으로 이동합니다.
  • 주의점: GPT-Realtime-2는 토큰 과금이고 통역·전사는 분 단위 과금이라, production voice agent에는 별도 cost model과 fallback 설계가 필요합니다.

OpenAI가 2026년 5월 7일 Realtime API용 새 음성 모델 3종을 발표했습니다. 이름만 보면 음성 품질 업데이트처럼 보입니다. 하지만 이번 발표의 중심은 더 선명합니다. OpenAI는 음성을 단순한 입출력 채널이 아니라, 사람이 제품을 조작하고 에이전트가 도구를 실행하는 실시간 작업 인터페이스로 밀어 올리고 있습니다.

새 모델은 세 가지입니다. GPT-Realtime-2는 실시간 음성 대화 안에서 추론하고 도구를 호출하는 주력 모델입니다. OpenAI는 이 모델을 "GPT-5급 추론"을 갖춘 첫 음성 모델이라고 설명합니다. GPT-Realtime-Translate는 70개 이상 입력 언어를 13개 출력 언어로 통역하는 live translation 모델입니다. GPT-Realtime-Whisper는 말하는 동안 전사를 생성하는 streaming speech-to-text 모델입니다. 한 문장으로 줄이면, OpenAI는 음성 대화, 통역, 전사를 각각 별도 제품 기능이 아니라 Realtime API의 agent surface로 묶고 있습니다.

이 뉴스가 개발자에게 중요한 이유는 "더 자연스러운 목소리" 때문만은 아닙니다. 음성 AI 제품을 만들어 본 팀이라면 병목이 목소리만이 아니라는 것을 압니다. 사용자가 말을 시작하고, 음성 인식이 끝나고, LLM이 추론하고, 도구를 호출하고, 다시 음성 합성으로 돌아오는 파이프라인 전체가 사용자 경험입니다. 각 단계의 지연이 누적되고, 중간 오류가 대화 전체를 망가뜨리며, 도구 호출 중 침묵이 길어지면 사용자는 시스템이 멈췄다고 느낍니다. 이번 발표는 그 파이프라인을 음성 에이전트 런타임 관점에서 다시 포장한 업데이트입니다.

OpenAI 발표를 바탕으로 재구성한 Realtime voice agent 흐름. voice-to-action, systems-to-voice, voice-to-voice 패턴이 GPT-Realtime-2 제어 루프로 연결됩니다.

음성은 이제 입력 방식이 아니라 작업 표면입니다

OpenAI 공식 발표는 음성 AI를 세 가지 패턴으로 나눕니다. 첫째는 voice-to-action입니다. 사용자가 "내 예산 안에서 조용한 동네의 집을 찾아 주고 토요일 투어를 잡아 달라"고 말하면, 모델은 의미를 파악하고 검색 도구, 캘린더, 예약 시스템을 호출해 작업을 진행합니다. 둘째는 systems-to-voice입니다. 항공편 지연, 게이트 변경, CRM 상태, 고객 지원 티켓 같은 시스템 맥락이 실시간 음성 안내로 바뀝니다. 셋째는 voice-to-voice입니다. 서로 다른 언어를 쓰는 사람들이 대화를 이어가도록 모델이 통역과 전사를 동시에 처리합니다.

이 세 패턴은 겉으로는 익숙합니다. 콜센터 자동화, 내비게이션 안내, 통역 앱은 오래전부터 있었습니다. 달라진 점은 LLM이 단순 분류기나 스크립트 엔진이 아니라 대화 중간의 작업 조정자가 된다는 점입니다. OpenAI는 GPT-Realtime-2가 요청을 처리하는 동안 "잠시 확인하겠습니다" 같은 짧은 preamble을 말할 수 있고, 여러 도구를 병렬 호출하며, 어떤 도구를 확인하는지 음성으로 드러낼 수 있다고 설명합니다. 이것은 작은 UX 장치처럼 보이지만, 실시간 에이전트에서는 중요합니다. 침묵은 실패로 해석됩니다. 모델이 무엇을 하는지 짧게 말해 주는 기능은 latency를 없애지는 못해도 latency를 사용자가 이해할 수 있는 상태로 바꿉니다.

또 하나의 변화는 recovery behavior입니다. OpenAI는 모델이 실패 상황에서 조용히 멈추거나 흐름을 깨는 대신, "지금은 그 작업에 문제가 있습니다"처럼 회복 가능한 방식으로 응답하도록 개선했다고 말합니다. 음성 에이전트는 텍스트 챗봇보다 실패 비용이 큽니다. 사용자는 화면을 훑으며 이전 답변을 다시 읽을 수 없고, 모델이 머뭇거리는 동안 다음 행동을 예측하기 어렵습니다. 따라서 회복 문구, 재시도, fallback, 사람 상담원 전환 같은 설계가 모델 성능만큼 중요해집니다.

GPT-Realtime-2의 핵심은 128K와 도구 호출입니다

공식 발표에서 가장 눈에 띄는 숫자는 context window입니다. OpenAI는 GPT-Realtime-2의 컨텍스트를 기존 32K에서 128K로 늘렸다고 밝혔습니다. 개발자 문서도 gpt-realtime-2를 128,000 context window와 32,000 max output tokens를 가진 모델로 표시합니다. 긴 상담, 긴 회의, 여행 일정 변경, 복잡한 구매 상담처럼 음성 세션이 길어지는 시나리오에서는 이 차이가 큽니다. 모델이 이전 조건, 중간 수정, 도구 결과, 사용자 선호를 더 오래 붙잡을 수 있기 때문입니다.

하지만 128K가 곧 제품 품질을 보장하지는 않습니다. 실시간 음성에서는 컨텍스트가 길어질수록 비용, 지연, 개인정보 관리가 함께 커집니다. 특히 고객지원이나 의료, 금융 같은 도메인에서는 긴 세션이 민감한 정보를 많이 포함합니다. 개발자는 모든 음성 대화를 그대로 모델 맥락에 쌓을지, 중간 요약을 만들지, 일부 필드를 구조화해 별도 상태로 보관할지 결정해야 합니다. 긴 컨텍스트는 편리한 메모리처럼 보이지만, 운영에서는 보존 정책과 삭제 정책을 함께 요구합니다.

도구 호출도 마찬가지입니다. OpenAI 개발자 문서는 gpt-realtime-2가 function calling을 지원한다고 표시합니다. 공식 발표는 parallel tool calls와 tool transparency를 강조합니다. 이 조합은 음성 에이전트가 "말하면서 일하는" 경험을 만들 수 있게 합니다. 예를 들어 여행 agent가 항공편 상태, 호텔 예약, 교통편, 번역을 동시에 확인하면서 사용자에게 각 단계를 짧게 말할 수 있습니다. 텍스트 에이전트에서는 사용자가 중간 로그를 읽을 수 있지만, 음성에서는 중간 상태를 어떤 말로 드러낼지가 제품 설계의 일부가 됩니다.

평가 수치는 개선을 말하지만, 제품 평가는 더 복잡합니다

OpenAI는 GPT-Realtime-2 (high)가 Big Bench Audio에서 GPT-Realtime-1.5보다 15.2% 높고, GPT-Realtime-2 (xhigh)가 Audio MultiChallenge에서 13.8% 높다고 밝혔습니다. 두 평가는 각각 오디오 입력을 받는 모델의 추론 능력과 다중 턴 음성 대화에서의 지시 수행, 맥락 통합, 자기 일관성, 자연스러운 수정 처리 등을 측정합니다. 발표문에 인용된 Zillow 사례도 강합니다. Zillow는 가장 어려운 adversarial benchmark에서 prompt optimization 후 call success rate가 69%에서 95%로 올랐다고 말했습니다.

이 수치들은 방향을 보여 줍니다. 음성 모델이 단순히 말을 잘 알아듣는 수준을 넘어, 말 속의 조건과 예외를 추론하고 도구 호출 흐름을 유지하는 쪽으로 개선되고 있다는 뜻입니다. 그러나 제품 팀은 벤치마크를 그대로 도입 근거로 삼기 어렵습니다. 실제 음성 agent는 배경 소음, 억양, 끼어들기, 통화 품질, 대기 시간, 도구 장애, 개인정보 동의, 상담원 전환 같은 변수를 동시에 만납니다. 모델이 instruction following에서 좋아졌더라도, 사용자가 말을 끊거나 도구가 3초 이상 지연될 때 어떤 음성 UX를 제공할지는 별도 실험이 필요합니다.

특히 reasoning effort는 양날의 검입니다. OpenAI는 개발자가 minimal, low, medium, high, xhigh 같은 reasoning level을 고를 수 있고 기본값은 low라고 설명합니다. 복잡한 요청에는 높은 reasoning effort가 도움이 될 수 있지만, 실시간 음성에서는 지연과 비용이 즉시 체감됩니다. 고객지원 첫 응답, 예약 확인, 단순 FAQ에는 낮은 reasoning이 맞을 수 있고, 보험 약관 비교나 의료 triage 같은 작업에는 높은 reasoning이 필요할 수 있습니다. 이제 voice agent 설계는 모델 하나를 고르는 일이 아니라, 발화 유형별 reasoning budget을 배분하는 일이 됩니다.

모델역할공식 가격 단위개발자 쟁점
GPT-Realtime-2실시간 음성 추론과 도구 호출audio input $32/1M, output $64/1M tokensreasoning effort, context length, tool latency
GPT-Realtime-Translate실시간 음성 통역$0.034/min언어쌍, 전문 용어, 동시 발화 처리
GPT-Realtime-Whisper스트리밍 음성 전사$0.017/mincaption latency, 요약 파이프라인, 저장 정책

통역과 전사는 에이전트의 감각기관이 됩니다

이번 발표에서 통역과 전사를 별도로 봐도 의미가 있습니다. GPT-Realtime-Translate는 70개 이상 입력 언어와 13개 출력 언어를 지원한다고 공개됐습니다. 발표문은 Deutsche Telekom과 Vimeo 사례를 언급하며, 고객지원과 제품 교육 콘텐츠가 각자의 언어로 실시간 제공되는 장면을 제시합니다. BolnaAI는 Hindi, Tamil, Telugu 평가에서 다른 모델보다 12.5% 낮은 Word Error Rate를 기록했다고 OpenAI 발표문에서 말했습니다.

GPT-Realtime-Whisper는 더 조용하지만 실무적으로 중요합니다. 실시간 전사는 회의록, 고객 상담 요약, 방송 자막, 교육 접근성, 의료 기록 보조, 채용 인터뷰 후속 처리에 바로 연결됩니다. 기존 Whisper 계열은 이미 개발자 생태계에서 널리 쓰였지만, "녹음 후 처리"와 "말하는 동안 처리"는 제품 구조가 다릅니다. 후자는 transcript가 생기는 즉시 검색, 요약, 경고, CRM 업데이트, 후속 agent action을 시작할 수 있습니다. 음성 에이전트가 제대로 작동하려면 듣는 능력 자체가 이벤트 스트림이 되어야 합니다.

이 지점에서 음성 AI와 에이전트 인프라가 만납니다. 텍스트 에이전트는 사용자가 입력한 prompt를 시작점으로 삼습니다. 음성 에이전트는 계속 들어오는 audio stream, 부분 transcript, 도구 결과, 사용자 끼어들기, 통역 output을 동시에 다룹니다. 따라서 개발자는 단순한 request-response API가 아니라 session state, interruption handling, backpressure, audit log, human handoff를 설계해야 합니다. OpenAI가 Realtime API를 중심에 두는 이유도 여기에 있습니다. 음성 agent는 모델 호출 하나가 아니라 세션 운영 문제입니다.

가격은 쉬운 비교를 허락하지 않습니다

가격 구조는 이번 발표의 실무적 핵심입니다. OpenAI 공식 발표 기준 GPT-Realtime-2는 audio input이 100만 토큰당 32달러, audio output이 100만 토큰당 64달러입니다. cached input은 100만 토큰당 0.40달러입니다. 반면 GPT-Realtime-Translate는 분당 0.034달러, GPT-Realtime-Whisper는 분당 0.017달러입니다. 같은 Realtime API 안에서도 하나는 토큰 과금이고, 다른 둘은 시간 과금에 가깝습니다.

이 차이는 조달팀보다 개발팀이 먼저 이해해야 합니다. 음성 agent의 비용은 대화 시간만으로 결정되지 않습니다. 사용자가 말하는 비율, 모델이 답하는 길이, 도구 호출 중 preamble과 중간 설명을 얼마나 하는지, 긴 컨텍스트를 얼마나 유지하는지, cached input을 활용하는지, reasoning effort를 어디까지 올리는지에 따라 달라집니다. 통화 시간이 같아도 상담원이 개입하는 흐름과 완전 자동화 흐름의 output token은 다를 수 있습니다.

Reddit 쪽 반응도 이 지점에서 갈렸습니다. 표본은 작지만, 일부 개발자는 128K context와 live translation을 긍정적으로 평가했고, 다른 사용자는 실제 비용과 vendor lock-in을 더 신중히 봐야 한다고 말했습니다. 이것은 당연한 반응입니다. 음성 AI는 데모가 빠르게 좋아 보이는 영역입니다. 그러나 production에서는 minute당 비용, fallback 비용, 실패 후 재시도 비용, 인간 상담원 전환 비용까지 모두 합쳐야 합니다. "통화 성공률이 올라간다"는 가설을 검증하려면 모델 가격뿐 아니라 평균 처리 시간, 전환율, 고객 만족도, 규제 리스크까지 함께 봐야 합니다.

안전장치는 모델 바깥에서도 필요합니다

OpenAI는 Realtime API에 active classifiers를 적용하고, 유해 콘텐츠 정책 위반이 감지되면 특정 대화를 중단할 수 있다고 설명합니다. 또한 개발자가 자체 guardrail을 추가할 수 있고, 최종 사용자에게 AI와 상호작용한다는 사실을 명확히 해야 한다고 밝힙니다. EU Data Residency와 enterprise privacy commitments도 언급됐습니다.

하지만 음성 에이전트의 안전은 모델 제공자의 정책만으로 끝나지 않습니다. 음성은 설득력이 강하고, 사용자는 텍스트보다 더 쉽게 상대를 사람처럼 받아들입니다. 고객지원 agent가 결제 정보를 요청하거나, 의료 상담 agent가 증상을 묻거나, 채용 agent가 후보자와 통화할 때는 녹음 동의, 보관 기간, 민감정보 마스킹, 상담원 전환 조건이 명확해야 합니다. 특히 실시간 통역은 발화가 잘못 번역될 때 책임 소재가 복잡해집니다. 통역 결과를 사용자가 바로 듣는 구조에서는 사후 로그 수정만으로는 충분하지 않습니다.

개발팀의 체크리스트는 구체적이어야 합니다. 첫째, 어떤 발화 유형에서 모델이 도구를 호출할 수 있는지 제한해야 합니다. 둘째, 결제, 예약 변경, 개인정보 수정처럼 되돌리기 어려운 행동에는 확인 단계를 넣어야 합니다. 셋째, 모델이 낮은 확신도를 보이거나 도구가 실패할 때 사람에게 넘기는 기준을 정해야 합니다. 넷째, transcript와 audio의 보관 정책을 분리해야 합니다. 텍스트 로그만 보관해도 되는지, 음성 원본까지 필요한지, 규제 산업에서는 누가 접근할 수 있는지 결정해야 합니다.

경쟁은 음성 모델보다 음성 운영체제로 번질 것입니다

이번 발표를 OpenAI 단독 이벤트로만 보면 시야가 좁아집니다. Google, Microsoft, Amazon, Deepgram, ElevenLabs, AssemblyAI 같은 플레이어들도 음성 인식, 합성, 통역, LLM 연결을 빠르게 결합하고 있습니다. Microsoft는 Azure AI Foundry 블로그에서 OpenAI의 새 realtime 모델들이 Foundry에 롤아웃된다고 설명했습니다. 클라우드 사업자 입장에서는 음성 agent가 contact center, meeting, field work, education, healthcare, travel workflow에 들어가는 입구가 됩니다.

경쟁의 초점은 "누가 더 사람 같은 목소리를 내는가"에서 "누가 더 안정적인 실시간 작업 루프를 제공하는가"로 옮겨갈 가능성이 큽니다. 음성 품질은 중요하지만, 기업 구매자는 결국 도구 연동, 감사 로그, 지역별 데이터 거주, latency SLA, 비용 예측, 장애 대응, human handoff를 봅니다. OpenAI가 GPT-Realtime-2에서 parallel tool calls, tone control, recovery behavior, reasoning effort를 강조한 것도 같은 맥락입니다. 음성은 감성 기능이 아니라 운영 기능이 되고 있습니다.

개발자에게 남는 질문은 분명합니다. 내 제품에서 음성은 꼭 필요한 인터페이스인가, 아니면 데모를 멋지게 만드는 부가 기능인가. 실시간성이 진짜 가치를 만드는가, 아니면 비동기 전사와 요약으로 충분한가. 모델이 도구를 직접 호출해야 하는가, 아니면 음성은 intent capture까지만 맡기고 중요한 행동은 화면에서 확인해야 하는가. 이번 OpenAI 발표는 이 질문들을 더 미룰 수 없게 합니다.

당장 실험한다면 작은 agent loop부터 봐야 합니다

실무적으로는 거창한 콜센터 자동화보다 작은 loop부터 보는 편이 낫습니다. 예를 들어 고객지원 제품이라면 "주문 상태 확인"처럼 도구 호출이 하나이고 실패 시 사람에게 넘기기 쉬운 흐름을 고를 수 있습니다. 생산성 도구라면 회의 중 action item을 잡아 캘린더 초안을 만드는 수준이 적당합니다. 교육 제품이라면 사용자가 말을 끊고 질문을 바꾸는 상황에서 모델이 얼마나 자연스럽게 회복하는지 봐야 합니다.

측정 항목도 텍스트 챗봇과 달라야 합니다. 첫 응답 시간, interruption 처리율, 도구 호출 성공률, 회복 발화의 자연스러움, 평균 통화 길이, 사람 전환율, 사용자가 같은 말을 반복한 횟수, 분당 비용을 함께 봐야 합니다. 특히 GPT-Realtime-2는 reasoning effort를 조절할 수 있으므로, low와 high를 같은 플로우에서 비교해야 합니다. 높은 reasoning이 항상 좋은 결과를 만들지 않습니다. 실시간 음성에서는 조금 덜 똑똑해도 빠르고 예측 가능한 모델이 더 나은 사용자 경험을 줄 수 있습니다.

OpenAI의 이번 발표는 음성 AI가 다시 중요한 인터페이스가 됐다는 신호입니다. 다만 이번에는 스마트 스피커 시절의 "말로 명령하기"와 다릅니다. Realtime voice agent는 사용자의 말을 듣고, 맥락을 유지하고, 도구를 부르고, 실패를 설명하고, 필요하면 통역과 전사를 동시에 수행합니다. 이것은 모델 데모보다 시스템 설계에 가까운 문제입니다. 그래서 개발자에게 이 뉴스의 의미는 간단합니다. 음성은 이제 프론트엔드 기능이 아니라 agent infrastructure의 일부로 다뤄야 합니다.