음성 AI가 API가 된 시대, 연구자는 무엇을 만들어야 하나

음성 AI 시제품은 이제 며칠 안에도 만들 수 있다. 그렇다면 녹음과 모델 학습이 사라진 자리에서 연구자는 무엇을 파고들어야 할까. 답은 목소리 생성보다 대화가 실패하는 순간에 가까워지고 있다.

API는 음성 합성보다 앞뒤의 작업을 줄였다

과거 TTS 개발에서는 음성 데이터부터 직접 마련하는 일이 흔했다. NVIDIA의 Tacotron 2 연구는 약 24시간 분량의 단일 화자 데이터를 학습에 사용했다. Microsoft의 VALL-E는 3초 음성으로 처음 듣는 화자를 모사하는 방향까지 나아갔다. citeturn5search0turn5search1

2026년 9월의 개발 환경은 다르다. OpenAI Realtime API와 Google Gemini Live API는 입력 음성을 받아 음성으로 응답하는 경로를 제공한다. 별도의 STT와 TTS를 연결하지 않고도 실시간 대화 시제품을 만들 수 있다. citeturn1search1turn2search0turn2search1

개발자 커뮤니티에서도 변화는 선명했다. 예전에는 녹음, 정제, 학습이 프로젝트의 큰 부분이었다는 경험담이 나왔다. 지금은 API 연결과 프롬프트 설계만으로 작동하는 데모를 만들 수 있다는 의견이 많았다.

다만 API가 없앤 것은 진입 비용이지 음성 대화의 난제가 아니다.

가장 어려운 문제는 사람이 언제 말을 끝냈는지 판단하는 일이다

텍스트 챗봇은 전송 버튼이 발화의 끝을 알려준다. 음성 대화에는 그런 경계가 없다. 짧은 침묵이 생각하는 시간인지 답변을 마친 것인지 시스템이 추정해야 한다.

판단이 빠르면 사용자의 문장을 잘라 먹고, 늦으면 응답이 굼떠진다. 모델이 말하는 도중 사용자가 끼어들면 재생을 멈추고 새 문맥을 반영해야 한다. OpenAI 공식 가이드도 VAD, 끼어들기 처리, 지연시간을 음성 에이전트 설계의 핵심 요소로 다룬다. citeturn0search0turn1search1

Kyutai의 Moshi는 두 개의 오디오 스트림을 함께 처리해 전이중 대화를 구현했다. τ-Voice와 Full-Duplex-Bench 같은 연구도 지연시간, 중첩 발화, 백채널 반응을 따로 측정한다. 기존 텍스트 평가만으로는 자연스러운 대화를 설명하기 어렵기 때문이다. citeturn1search3turn3search0turn3search2

써본 사람들 사이에서는 첫 응답은 인상적이지만 긴 대화에서는 끼어들기와 문맥 유지가 흔들린다는 반응도 있다. 너무 민감한 VAD가 주변 소음에 반응하거나 문장 중간의 숨을 종료 신호로 처리한다는 불만도 나온다. 이런 문제는 음성 모델 하나를 교체한다고 모두 사라지지 않는다.

Claude Code로 최소 실험 환경부터 만든다

가장 빠른 출발점은 기반 모델을 학습하는 일이 아니다. Claude Code에는 브라우저 클라이언트, 세션 서버, 도구 호출, 평가 스크립트를 각각 만들도록 맡길 수 있다. 실행 모델은 OpenAI Realtime이나 Gemini Live처럼 직접 음성을 처리하는 API로 정한다.

브라우저의 client.ts는 마이크 입력과 출력 재생을 담당하고 server.ts는 인증정보를 숨긴 채 세션을 만든다. OpenAI는 브라우저 연결에 WebRTC를, 서버 중심 구성에는 WebSocket을 안내한다. Google Live API도 클라이언트와 직접 통신하거나 백엔드 프록시를 두는 구성을 지원한다. citeturn0search0turn2search0turn2search1

agent.ts에는 역할, 말투, 응답 길이와 호출 가능한 도구를 넣는다. 예약 확인이나 검색 같은 함수는 음성 모델이 호출하되 실제 처리는 서버가 맡는다. 입력은 마이크 음성과 도구 결과이고, 산출물은 재생할 오디오와 이벤트 로그다.

평가용 파일도 처음부터 필요하다. eval/fixtures에 침묵, 잡음, 말 고치기, 중간 끼어들기 음성을 넣는다. metrics.jsonl에는 발화 종료부터 첫 오디오까지 걸린 시간, 잘못 끊긴 횟수, 도구 호출 성공 여부를 기록한다. 이때 API 데모가 연구 가능한 하네스로 바뀐다.

좋은 연구 주제는 평균 품질이 아니라 실패 조건에서 나온다

VoiceBench는 음성 언어 모델을 지식, 명령 이행, 안전성 등 여러 축으로 평가한다. 최근 전이중 벤치마크는 여기에 응답 시점과 동시 발화까지 더한다. 단순히 자연스러운 음성을 골라내는 평가보다 실제 대화 구조에 가까워졌다. citeturn3search2turn3search3

연구자는 같은 대본을 조용한 방과 카페 소음에서 실행할 수 있다. 말이 빠른 사용자와 긴 침묵을 두는 사용자, 한국어와 영어를 섞는 사용자도 비교한다. 평균 점수보다 어떤 조건에서 시스템이 상대의 말을 빼앗는지 기록해야 한다.

감정과 영상도 독립된 축이다. Video-FDBench와 Moshi-Face 같은 연구는 얼굴 움직임과 음성을 함께 다루면서 말의 내용만으로 잡기 어려운 타이밍과 표현을 평가한다. 화면 속 인물이 입을 열려는 순간을 감지한다면 음성 에이전트가 먼저 말하는 실수를 줄일 수 있다. citeturn5search2turn5search3

소규모 팀에는 이 접근이 특히 현실적이다. 범용 TTS를 새로 학습하기보다 특정 업무의 실패 데이터를 모을 수 있다. 상담 중 정정 발화, 교육 상황의 망설임, 고령 사용자의 긴 간격처럼 상용 데모가 놓치는 조건이 연구 자산이 된다.

감정 표현이 좋아질수록 개인정보 설계가 먼저 필요하다

음성은 문장보다 많은 정보를 품는다. 말투와 주변 소리에는 감정, 건강 상태, 생활환경을 추정할 단서가 섞일 수 있다. 사용자가 기계와 정서적인 대화를 시작하면 수집 범위도 기능 명령을 넘어서기 쉽다.

NIST는 합성 콘텐츠 탐지 성능이 생성 방식과 데이터 조건에 따라 크게 달라진다고 설명한다. 음성 복제 기능을 붙였다는 이유만으로 탐지기를 안전장치처럼 믿기 어렵다. citeturn3search3

그래서 하네스에는 삭제 경로도 들어가야 한다. 원본 음성을 저장할지, 전사문만 남길지, 로그를 언제 지울지 분리한다. 화자 모사에는 명시적 동의를 받고 생성 음성임을 알리는 절차도 제품 흐름에 넣어야 한다.

API 시대의 연구 질문은 더 사람 같은 목소리를 만드는 데서 끝나지 않는다. 누가 말할 차례인지, 어떤 환경에서 판단이 무너지는지, 대화가 얼마나 노출돼도 되는지를 재현 가능하게 측정하는 일이 남았다. 상용 서비스가 아직 안정적으로 다루지 못하는 그 실패 지점이 지금 음성 AI 연구의 가장 구체적인 출발점이다.