텍스트를 거치지 않는 혁신: End-to-End S2S 작동 원리


End-to-End Speech-to-Speech(이하 S2S)란 음성을 글자로 옮기는 중간 단계 없이, 오디오를 직접 입력으로 받아 오디오로 답하는 구조를 말합니다. 지금까지의 음성 AI 대부분은 이와 정반대였습니다. 음성을 글자로 바꾸고, 글자를 읽어 답을 만들고, 그 답을 다시 목소리로 합성하는 받아쓰기 단계를 거쳤습니다. 그러나 사람은 상대의 말을 글자에 옮긴 다음에야 대답하지 않습니다. 듣는 동시에 이해하고, 말이 끝나기도 전에 답할 준비를 합니다. S2S는 이 "글자로 옮기는 단계" 자체를 없애 그 방식에 다가서려는 시도이며, 이 구조가 무엇을 바꾸는지 원리부터 정리합니다.

[시리즈] S2S·LLM 음성 에이전트 엔지니어링 63편 · 현재 2-1편

← 이전: 1-4 RAG 병목과 오디오 버퍼링 제어 / 다음 → 2-2 OpenAI Realtime API vs 오픈소스 S2S

전체 목차 펼치기 (63편)

Part 1 — 음성 AI가 느린 이유: 레이턴시 진단 (4편)

Part 2 — 텍스트를 넘어: End-to-End S2S의 원리 (4편)

Part 3 — 실시간 대화와 에이전트화: 인터럽트·MCP·도구 (5편)

Part 4 — 인프라·세션·보안: 프로덕션 백엔드 (5편)

Part 5 — 운영·품질·평가: 에이전틱 워크플로우와 신뢰성 (7편)

Part 6 — 음성 경험 고도화·실전 통합: 한국어·UX·전화망·엣지 (5편)

Part 7 — S2S 도입 전략·구매 의사결정 (4편)

Part 8 — LLM 콜봇 PoC 현장 (6편)

Part 9 — 상담어시스트: 상담사 화면을 바꾸는 실시간 AI (7편)

Part 10 — 직접 만든 롤플레이 챗봇: RAG 에이전트 구축기 (8편)

Part 11 — KMS 실무 — 지식관리시스템의 설계와 운영 현실 (8편)

기존 캐스케이드 구조의 한계: 음성을 글자로 납작하게 만든다

지금까지 음성봇의 표준은 세 개의 모듈을 직렬로 잇는 캐스케이드(cascaded) 방식이었습니다. 음성 인식(STT)이 말을 텍스트로 옮기고, 언어 모델(LLM)이 그 텍스트를 읽어 답변 텍스트를 만들고, 음성 합성(TTS)이 그 텍스트를 다시 목소리로 바꿉니다. 모듈을 독립적으로 교체하고 디버깅할 수 있다는 큰 장점 덕분에 오랫동안 사실상의 정답으로 쓰였습니다.

문제는 첫 단계에서 일어납니다. 사람의 발화에는 글자로 옮길 수 없는 정보가 가득합니다. 억양, 말의 속도, 망설임, 한숨, 웃음, 강조, 그리고 화난 목소리인지 다급한 목소리인지 같은 정서적 신호입니다. STT가 음성을 텍스트로 변환하는 순간, 이 모든 것이 평평한 글자열로 납작해집니다. LLM은 "환불해 주세요"라는 글자만 받을 뿐, 그 말이 짜증 섞인 목소리였는지 차분한 목소리였는지 알지 못합니다. 정보가 사라진 자리에서 만들어진 답변은, 다시 TTS를 거치며 기계가 추정한 새로운 억양을 입습니다. 즉 캐스케이드는 한쪽 끝에서 표현을 버리고 반대쪽 끝에서 표현을 지어내는 구조입니다.

End-to-End S2S란 무엇인가: 오디오를 직접 먹고 오디오로 답한다

End-to-End S2S는 이 세 단계를 하나의 모델로 합칩니다. 중간에 사람이 읽을 수 있는 텍스트 산출물을 만들지 않고, 오디오 입력을 받아 곧바로 오디오 출력을 생성합니다. 표현을 빌리자면, 받아쓰기 공책을 거치지 않고 귀에서 입으로 바로 이어지는 셈입니다.

핵심은 모델이 음성을 "글자로 번역해야 할 외국어"가 아니라 "처음부터 다룰 줄 아는 입력 양식"으로 본다는 점입니다. 이것을 네이티브 멀티모달(native multimodal)이라고 부릅니다. 텍스트만 학습한 모델에 음성 모듈을 외부로 덧붙인 것이 아니라, 모델 자체가 오디오와 텍스트를 같은 표현 공간 안에서 함께 학습했다는 의미입니다. 그래서 발화의 톤이나 속도 같은 비언어적 단서가 변환 단계에서 폐기되지 않고, 모델 내부의 맥락으로 살아남습니다.

Cascaded와 End-to-End S2S 경로 비교도 위쪽은 캐스케이드 구조로 음성 입력 → STT → LLM → TTS → 음성 출력의 5단계를 거치며 경계마다 대기 시간이 붙는다. 아래쪽은 End-to-End S2S 구조로 STT·LLM·TTS 세 단계가 오디오 토큰을 입출력하는 단일 모델 하나로 합쳐져, 모듈 경계가 1곳으로 줄어든다. Cascaded (기존) 음성 입력 STT LLM TTS 음성 출력 ← 5단계, 매 경계마다 대기 End-to-End S2S (신규) 음성 입력 단일 모델 — 오디오 토큰 in / out (STT·LLM·TTS 세 단계가 한 모델 안으로) 음성 출력 ← 경계 1곳

그림 1. 캐스케이드(위) vs End-to-End S2S(아래) 경로 비교 — STT·LLM·TTS 세 단계가 단일 모델로 합쳐지면서 모듈 경계가 4곳에서 1곳으로 줄어든다.

핵심 메커니즘: 오디오 토큰과 네이티브 멀티모달

연속적인 소리 파형을 LLM이 어떻게 직접 다룰까요. 열쇠는 오디오 토큰(audio token)입니다. LLM이 텍스트를 단어 조각 토큰으로 쪼개 다루듯, S2S 모델은 오디오를 잘게 잘라 이산적인(discrete) 코드, 즉 오디오 토큰의 나열로 바꿉니다. 일단 토큰이 되면, 모델 입장에서 음성과 글자의 경계는 흐려집니다. 둘 다 "다음에 올 토큰을 예측하는" 같은 문제로 환원되기 때문입니다.

대략의 흐름은 다음과 같이 정리할 수 있습니다.

입력 오디오(파형)
  → 오디오 인코더: 파형을 이산 오디오 토큰 열로 변환
  → 단일 모델(LLM 코어): 오디오 토큰 + (필요시) 텍스트 토큰을 한 시퀀스로 처리
  → 출력 오디오 토큰을 자기회귀적으로 생성
  → 오디오 디코더(보코더): 오디오 토큰을 다시 파형으로 복원
출력 오디오(목소리)

여기서 중요한 점은, 가운데 단계가 "음성 → 텍스트 → 음성"이 아니라 "오디오 토큰 → 오디오 토큰"이라는 것입니다. 사람이 읽을 텍스트로 일단 환원했다가 되돌리는 왕복이 없습니다. 토큰을 만들고 푸는 인코더·디코더의 구체적 설계, 음성 코덱과 양자화의 세부는 07편에서 자세히 다룹니다. 이 글에서는 "음성도 토큰이 되면 LLM이 텍스트처럼 예측할 수 있다"는 핵심만 잡으면 충분합니다.

왜 빨라지는가: 직렬 단계 제거가 만드는 지연 단축

캐스케이드의 응답 지연은 본질적으로 덧셈입니다. STT가 끝나야 LLM이 시작하고, LLM이 끝나야 TTS가 시작합니다. 각 모듈의 처리 시간과 그 사이 데이터를 넘기는 시간이 직렬로 누적됩니다. 스트리밍 기법으로 단계를 겹쳐 상당 부분 줄일 수 있지만, 모듈 경계가 존재하는 한 경계마다 약간의 대기와 오버헤드는 남습니다.

S2S는 이 경계 자체를 없앱니다. 하나의 모델이 오디오를 받아 오디오를 내보내므로, 모듈 간 인계와 대기에서 생기던 오버헤드가 사라져 누적 지연이 크게 줄어듭니다. 물론 S2S 안에도 앞서 본 흐름도처럼 인코드·생성·디코드 단계는 그대로 있지만, 이들이 한 모델 안에서 끊김 없이 이어지기 때문에 모듈 사이를 넘나들 때 붙던 경계 오버헤드가 없습니다. 결과적으로 사용자가 말을 마친 뒤 첫 음성이 나오기까지의 체감 지연이 짧아지고, 사람의 자연스러운 대화 리듬에 가까워집니다. 나아가 듣기와 말하기를 동시에 처리하는 전이중(full-duplex) 상호작용, 즉 사용자가 끼어들면 즉시 멈추고 반응하는 흐름도 같은 모델 안에서 자연스럽게 설계할 여지가 커집니다. 다만 끼어들기 처리를 실제로 구현하는 방법은 09편에서 자세히 다룹니다.

역설적이게도 S2S를 검토 테이블에 처음 올리게 만드는 계기는 새로운 기술에 대한 관심이 아니라, 익숙하게 써 온 방식에서 느끼는 불편함인 경우가 많습니다. 표 위의 밀리초 수치가 아니라, "한마디 묻고 답이 수 초 뒤에 온다"는 체감 지연이 먼저 걸립니다. 정적인 시나리오 분기형 음성봇은 정해진 길만 빠르게 타지만, 사용자가 조금만 벗어나면 STT→LLM→TTS의 왕복이 매 턴 쌓여 대화가 뚝뚝 끊깁니다. 그 답답함을 한 번 겪고 나면, 누적 왕복 지연을 줄여 줄 실시간 S2S로 넘어갈지를 본격적으로 따져 보게 됩니다. 즉 S2S 전환의 첫 트리거는 새 기술에 대한 호기심이 아니라, 캐스케이드가 쌓아 올린 지연이 대화의 자연스러움을 깨뜨린다는 현장의 체감입니다.

구분캐스케이드 (STT-LLM-TTS)End-to-End S2S
처리 경로음성 → 텍스트 → 텍스트 → 음성오디오 → (오디오 토큰) → 오디오
비언어 정보텍스트 변환 시 대부분 손실모델 내부에 보존
지연 구조모듈별 처리·인계 시간 누적경계 제거로 누적 지연 감소
모듈 교체쉬움 (각 단계 독립)어려움 (단일 모델)
동작 관측·로그중간 텍스트로 추적 쉬움중간 텍스트가 기본 없음

S2S가 얻는 것과 잃는 것: 만능은 아니다

S2S가 모든 면에서 우월한 것은 아닙니다. 캐스케이드가 가졌던 가장 큰 미덕, 즉 제어성과 관측성을 상당 부분 내려놓아야 합니다.

캐스케이드에서는 중간에 텍스트가 존재합니다. 그래서 무엇을 알아들었고 무엇을 답하려는지 글자로 확인할 수 있고, 금칙어 필터링이나 답변 규칙을 텍스트 단계에서 끼워 넣기도 쉽습니다. 문제가 생기면 어느 모듈이 틀렸는지 좁혀 들어갈 수 있습니다. 반면 S2S는 입력과 출력이 모두 오디오라, 모델이 무엇을 근거로 그렇게 답했는지 들여다보기가 더 까다롭습니다. 규제가 엄격하거나 응답을 한 글자도 틀리면 안 되는 영역에서는 이 불투명함이 부담이 됩니다.

  • 얻는 것: 비언어 정보 보존으로 풍부한 표현, 짧은 체감 지연, 자연스러운 끼어들기와 대화 리듬.
  • 잃는 것: 텍스트 기반의 세밀한 제어, 동작 추적·감사(audit)의 용이성, 모듈 단위 교체·튜닝의 유연성.

아이러니하게도 원리상으로는 뚜렷한 장점인데, 막상 도입을 검토하는 단계에 들어서면 현실적 제약부터 먼저 눈에 밟힙니다. 우선 온프레미스 환경에서 곧바로 올려 쓸 만한 S2S 모델이 아직 마땅치 않습니다. 쓸 만한 품질은 대형 모델과 클라우드 API에 몰려 있어, 폐쇄망을 전제로 하거나 비용에 민감한 환경에서는 클라우드 의존·고비용·대형 모델 운영 부담이 그대로 따라옵니다. 캐스케이드 쪽이 각 모듈을 가볍게 갈아 끼우며 온프레미스로 맞추기 쉬웠던 것과 대비되는 지점입니다.

또 하나 자주 부딪히는 혼란은, 캐스케이드(전사 후 텍스트를 다루는 길)와 S2S(오디오 대 오디오로 가는 길)가 아키텍처상 근본적으로 다른 경로라는 점에서 옵니다. 한쪽 방식을 머릿속에 두고 설계하던 사람이 다른 경로의 구성도를 보면, 같은 음성 AI인데도 데이터가 흐르는 모양이 달라 곧바로 와닿지 않습니다. 그래서 검토 초기에 기술을 고르기보다, "이 서비스에서 음성과 데이터가 어느 경로로 흐를 것인가"라는 흐름 정의를 먼저 합의해 두는 편이 시행착오를 줄입니다. 캐스케이드를 전제로 짠 모듈 경계·로그·제어 지점이 S2S에서는 통째로 다시 그려져야 하기 때문입니다.

실무에서 어디에 쓰나: 하이브리드 관점

그런데 정작 실제 선택은 의외의 방향으로 흘러갑니다. 둘 중 하나를 고르기보다 성격에 맞게 나눠 쓰는 경우가 더 많습니다. 자연스러운 응대와 빠른 반응이 경험을 좌우하는 대화형 구간에는 S2S의 강점이 크고, 정확한 사실 전달과 규정 준수, 거래 처리처럼 한 치의 오차도 허용되지 않는 구간에는 텍스트로 검증 가능한 캐스케이드가 여전히 안전합니다. 그래서 실제 설계에서는 S2S로 대화의 자연스러움을 살리되, 의료 예약의 일정 확정, 금융 서비스의 본인 인증, 결제 금액 안내처럼 핵심 행동은 텍스트로 명시적으로 확정하고 로그를 남기는 절충안이 흔합니다. 검증 가능성을 따로 챙기는 이유는 분명합니다. 나중에 분쟁이 생기거나 법규 대응이 필요할 때, "무엇을 안내하고 무엇을 확정했는가"를 글자로 입증할 수 있어야 하기 때문입니다. 중요한 것은 "S2S냐 캐스케이드냐"라는 양자택일이 아니라, 어느 구간에 표현력이 필요하고 어느 구간에 검증 가능성이 필요한지를 먼저 가르는 일입니다. 기술 선택은 그다음입니다.

엔드투엔드 구조를 처음 접했을 때 가장 놀란 것은 속도가 아니라 톤의 자연스러움이었습니다. 캐스케이드에서는 아무리 지연을 줄여도 되돌아오는 목소리가 어딘가 평평했는데, 오디오를 텍스트로 납작하게 만들지 않고 그대로 통과시키니 망설임과 강조까지 살아 있었습니다.

그때 깨달은 것은, S2S의 진짜 가치가 밀리초 단축보다 "말이 지어낸 억양이 아니라 원래의 억양으로 이어진다"는 감각에 있다는 점이었습니다. 어느 구간에 표현력이 필요하고 어느 구간에 검증 가능성이 필요한지를 먼저 가르는 일이, 기술 선택보다 앞서야 한다고 느낀 것도 이 지점에서였습니다. 이 판단은 2026년 6월 기준 공개 가능한 일반론과 현장 경험을 바탕으로 정리한 것입니다.

댓글

이 블로그의 인기 게시물

STT 인식률 93%의 함정 — 왜 그 숫자는 콜봇 목표가 될 수 없는가

AI 보이스봇이 답답한 이유: Cascaded 구조 레이턴시 완전 분석

음성 토큰(Audio Token)이란? LLM이 소리를 이해하는 원리