OpenAI와 Perplexity, Realtime API 기반 voice agent 운영 교훈 공개

OpenAI와 Perplexity가 설명한 내용

OpenAI Developers는 2026년 3월 30일, Perplexity가 Realtime API로 voice agent를 대규모 운영하며 얻은 교훈을 정리한 사례를 공개했다고 밝혔다. 공식 글인 OpenAI Developers 블로그에 따르면 Perplexity는 Perplexity Comet과 Perplexity Computer 같은 제품에서 Realtime-1.5를 production에 사용하고 있으며, 현재 매월 수백만 건의 voice session을 처리하고 있다. 글의 핵심은 voice를 부가 기능이 아니라 실제 작업을 위임하는 핵심 인터페이스로 보고 있다는 점이다.

이 사례가 유용한 이유는 단순 출시 소개가 아니라 운영상의 난점을 구체적으로 다루기 때문이다. Perplexity가 부딪힌 문제는 speech input과 output을 연결하는 것 자체보다, context가 길어지고, 클라이언트마다 native audio buffer가 다르고, 사용자가 noisy environment에서 interruption과 hesitation을 섞어 말하는 상황에서도 agent가 안정적으로 동작하도록 만드는 것이었다.

Production에서 바뀐 설계

대표적인 교훈은 context management다. Perplexity는 초기에 큰 transcript 덩어리를 한 번에 넣는 방식을 시도했지만, 이 방법은 실패할 때 너무 크게 무너졌다고 설명한다. 예를 들어 10,000-token 업데이트를 넣으려는데 모델에 남은 여유가 5,000 token뿐이면, 이전 history 전체가 한 번에 사라질 수 있었다. 그래서 팀은 더 작은 2,000-token chunk 단위로 나눠 점진적으로 넣는 방식으로 바꿨고, 약간의 오버헤드를 감수하는 대신 truncation이 훨씬 부드럽게 일어나도록 만들었다.

또 하나의 포인트는 message semantics다. 브라우징 중 화면의 문맥을 모두 user role로 넣으면 모델이 사용자가 페이지의 모든 문장을 직접 말한 것처럼 행동했고, 반대로 너무 많은 내용을 system으로 넣으면 모델이 본래 지식, 주입된 맥락, 현재 질문의 경계를 흐리게 만들었다고 한다. Perplexity는 자연스러운 voice interaction을 위해 이 role 설계가 token 수 관리만큼 중요했다고 강조했다.

오디오 파이프라인도 핵심이었다. Swift, TypeScript, Rust, C++ 기반 클라이언트가 각기 다른 native audio buffer를 보내면 성능 편차가 커졌고, 이를 줄이기 위해 product surface 전반에서 audio를 표준화했다고 설명한다. 동시에 현실 환경의 background noise, 사용자 끼어들기, turn-taking 문제에 맞게 모델을 조정해야 했다고 덧붙였다.

왜 중요한가

이 글은 production voice agent가 실제로 어디서 깨지는지를 잘 보여준다. 병목은 모델 품질만이 아니다. context chunking, role labeling, audio normalization, noisy environment 대응 같은 세부 설계가 결국 제품 품질을 결정한다. 좋은 데모와 믿고 쓸 수 있는 voice system 사이의 차이가 여기서 나온다.

개발팀 입장에서는 voice가 이제 인프라 레이어가 되고 있다는 점도 중요하다. Perplexity가 설명한 규모에서는 chunk size, role 구분, tool 선택이 더 이상 사소한 구현 디테일이 아니다. 그것이 곧 제품 아키텍처가 된다. 실시간 multimodal agent를 차세대 인터페이스로 보는 팀이라면, 이 사례는 매우 현실적인 체크리스트가 될 수 있다.