웨비나 요약: 텍스트 챗봇에 사람 같은 목소리 입히기

채팅 에이전트는 이제 엔터프라이즈 소프트웨어 스택의 기본 구성 요소가 되었습니다. 대부분의 기업은 이미 하나를 운영하거나 구축 중입니다. 하지만 사용자가 글보다 직접 대화하기를 원할 때 어떻게 해야 하는지 파악한 기업은 많지 않습니다.

음성은 단순한 편의성을 넘어 중요한 방식으로 상호작용을 바꿉니다. 사용자는 텍스트로는 완전히 사라지는 어조를 통해 불만, 긴급함, 혼란을 표현합니다. "내 주문이 아직 도착하지 않았어요"라고 입력하는 고객과 불안한 기색이 묻어나는 목소리로 말하는 고객은 서로 다른 신호를 보내고 있습니다. 대화 기록만 읽을 수 있는 에이전트는 정보의 절반만 활용하는 셈입니다.

이제 대부분의 팀이 던지는 질문은 음성을 추가할지 여부가 아니라, 이미 잘 작동하는 모든 것을 다시 구축하지 않고 어떻게 추가할지입니다.

라이브 워크숍: 텍스트 챗봇에 사람처럼 들리는 음성 추가하기에서 Paul Asjes(개발자 경험), Bhargavi Bhatt(고객 경험), Fergal Burnett(제품 마케팅, ElevenAPI)은 기존 에이전트에 음성을 추가할 때의 기술적 현실과 실제 작동하는 통합 방식에 관해 설명했습니다.

음성 기반 구축이 보기보다 어려운 이유

핵심 과제 중 하나는 턴테이킹입니다. 사람은 억양, 리듬, 맥락을 통해 상대가 말을 마쳤는지 압니다. 하지만 표준 방식인 음성 활동 감지(VAD)는 침묵만 감지합니다.

그 결과, 모든 멈춤을 발화 초대로 여기는 시스템이 흔히 만들어집니다. 사용자의 말을 가로막고, 생각이 끝나기 전에 끊으며, 자연스러운 머뭇거림을 완성된 문장처럼 처리합니다.

기술적으로는 작동하지만, 대화로서는 망가진 상태입니다.

맥락은 문제의 또 다른 절반입니다. 매 턴마다 LLM에 대화 기록을 전달하는 것은 필요하지만 충분하지는 않습니다. 같은 말도 전달 방식에 따라 의미가 달라집니다. 안도하며 말하는 "괜찮아요"와 답답함을 담아 말하는 "괜찮아요"는 대화 기록은 같지만 상호작용은 다릅니다. 이 차원을 무시하는 음성 시스템은 개별 모델의 성능이 아무리 뛰어나도 언제나 어딘가 부자연스럽게 들립니다.

엔지니어링 부담도 있습니다. 자체 음성 오케스트레이션을 운영하는 팀은 턴테이킹 로직, 인터럽션 처리, 지연 시간 프로파일링을 지속적으로 유지 관리하게 됩니다. 한 번 구축하고 끝나는 일이 아닙니다.

기존 에이전트에 음성을 추가하는 방법

가장 깔끔한 접근 방식은 이중 WebSocket 아키텍처입니다. 

1. 하나의 연결은 클라이언트와 ElevenLabs API 사이에, 다른 하나는 서버와 ElevenLabs API 사이에 설정됩니다
2. 사용자가 마이크에 말하면 오디오가 ElevenLabs API로 전송되고, সেখানে 전사된 뒤 서버로 전달됩니다
3. 서버는 ElevenLabs API에서 받은 전체 대화 기록을 LLM에 제공하고, 스트리밍 응답은 오디오 합성을 위해 다시 전송됩니다
4. LLM이 생성을 마치기 전에도 이 과정을 시작할 수 있어 첫 바이트 지연 시간을 낮게 유지합니다 

핵심 통합 지점은 onTranscript 메서드입니다. 이 메서드는 각 턴이 끝날 때 실행되며 전체 대화 기록을 LLM에 전달합니다. 

세션 시작 시 contextualUpdate 를 사용하면 사용자가 음성으로 전환하기 전 텍스트 대화에서 발생한 내용을 그대로 이어받을 수 있습니다. 덕분에 하나의 에이전트가 맥락을 잃지 않고 두 가지 모달리티에서 모두 작동할 수 있습니다.

구축할 때 염두에 둘 몇 가지 사항:

1. 음성에서는 채팅보다 LLM 선택이 더 중요합니다. 응답 품질이 더 높더라도, 심층 추론 모델은 오디오에서 부자연스러운 망설임으로 느껴지는 공백을 만듭니다. 실시간 음성에서는 더 빠른 모델이 체감 품질 면에서 거의 항상 우세합니다.
2. 오디오에는 WebSocket보다 WebRTC를 사용하세요. WebRTC에는 에코 및 노이즈 제거 기능이 기본 내장되어 있어 모바일이나 소음이 많은 환경에서 특히 중요합니다. 오디오 전송에 WebSocket을 사용하면 이를 직접 처리해야 합니다.
3. 사용자에게 언어를 선택하게 하지 마세요. 대화 흐름이 끊깁니다. 발화의 처음 몇 초에서 언어를 감지해 고정하는 편이 더 나은 패턴이며, 사용자가 아무것도 하지 않아도 자연스럽게 전환할 수 있습니다.
4. 턴테이킹 모델과 LLM을 분리하세요. 사용자가 말을 마쳤는지 판단하는 데 LLM을 사용하면 매 턴마다 지연 시간과 비용이 추가됩니다. 전용 턴테이킹 모델은 이를 더 빠르고 정확하게 처리하므로, 아키텍처에서 별도의 구성 요소로 다룰 가치가 있습니다.

어느 정도의 인프라를 직접 운영할지

정답은 이미 갖추고 있는 것에 따라 다릅니다. 작동하는 채팅 에이전트가 있다면 LLM, 오케스트레이션, 비즈니스 로직은 그대로 유지한 채 그 위에 음성 레이어를 추가하는 것이 일반적으로 가장 빠르고 위험이 적은 방법입니다. 

무언가를 다시 구축하는 것이 아닙니다. 이미 작동하는 시스템에 오디오 인터페이스를 추가하는 것입니다.

요구 사항이 전화 통신, 배포 채널 관리, 내장 테스트, 분석까지 확장된다면 스택의 더 많은 부분을 음성 에이전트 플랫폼에 맡기는 것이 합리적입니다. 두 접근 방식은 상호 배타적이지 않습니다. 팀은 가벼운 음성 레이어로 시작한 뒤 사용 사례가 성숙해짐에 따라 플랫폼 기능을 추가할 수 있습니다.

데모: 기존 챗봇에 음성 추가하기

이 데모에서는 텍스트 기반 여행 계획 챗봇과 대화 중인 사용자가 일본 여행을 위한 동네와 음식 추천을 요청하는 과정을 살펴봅니다.

다룬 내용:

• 기반 에이전트는 전혀 변경하지 않고 챗봇에 음성 레이어를 확장했습니다.
• 사용자는 대화 도중 입력에서 음성으로 전환했고, 에이전트는 두 모달리티 전반에서 전체 맥락을 유지했습니다.
• 사용자는 네덜란드어로 말했고, 에이전트는 언어 전환을 자동으로 감지했습니다
• 에이전트가 말을 끊긴 뒤 문장 중간에 영어로 다시 전환해 달라는 요청을 받자 전환했고, 별도의 지시 없이 약간의 네덜란드식 억양으로 응답을 마무리했습니다.
• 대화 전반에서 인터럽션 감지 기능 덕분에 사용자는 에이전트가 자신의 턴을 끝낼 때까지 기다리지 않고 자연스럽게 말을 겹쳐 할 수 있었습니다.

중요한 이유: 

이 데모는 처음부터 설계된 음성 에이전트를 보여준 것이 아닙니다. 이미 작동하던 텍스트 에이전트 위에 음성 레이어를 추가한 모습을 보여주었습니다. 맥락 처리, 언어 감지, 인터럽션 동작은 모두 음성 레이어에서 제공되며, 기반 텍스트 에이전트는 변경되지 않았습니다. 

전체 세션 시청

전체 웨비나는 여기에서 시청하세요.