음성 토큰(Audio Token)이란? LLM이 소리를 이해하는 원리
대형 언어 모델에 사람의 목소리를 그대로 넣을 수는 없습니다. LLM은 문장을 놀랍도록 잘 다루지만, 본질적으로 "다음에 올 토큰"을 맞히도록 훈련된 기계이고, 소리는 초당 수천~수만 개의 표본으로 디지털화해야 할 만큼 촘촘한 연속 신호이기 때문입니다. 둘 사이에는 반드시 번역기가 필요하며, 그 번역기의 출력물이 바로 음성 토큰(Audio Token)입니다. 이 글에서는 파형 한 조각이 어떤 과정을 거쳐 LLM이 읽을 수 있는 토큰으로 바뀌는지, 그리고 그 과정에서 어떻게 말의 내용뿐 아니라 감정과 뉘앙스까지 함께 실려 나가는지를 정리합니다.
[시리즈] S2S·LLM 음성 에이전트 엔지니어링 63편 · 현재 2-3편
← 이전: 2-2 OpenAI Realtime API vs 오픈소스 S2S / 다음 → 2-4 감정·톤 조절이 CS를 바꾸는 이유
- 2-1 End-to-End S2S 작동 원리
- 2-2 OpenAI Realtime API vs 오픈소스 S2S
- 2-3 음성 토큰(Audio Token)이란 (현재 글)
- 2-4 감정·톤 조절이 CS를 바꾸는 이유
- 3-1 실시간 인터럽트(끼어들기) 감지
전체 목차 펼치기 (63편)
Part 1 — 음성 AI가 느린 이유: 레이턴시 진단 (4편)
- 1-1 AI 보이스봇이 답답한 이유 — Cascaded 레이턴시
- 1-2 1초의 벽 — 지연이 UX를 결정하는 이유
- 1-3 지연 줄이기 — 스트리밍·청크로 TTFT 단축
- 1-4 RAG 병목과 오디오 버퍼링 제어
Part 2 — 텍스트를 넘어: End-to-End S2S의 원리 (4편)
- 2-1 End-to-End S2S 작동 원리
- 2-2 OpenAI Realtime API vs 오픈소스 S2S
- 2-3 음성 토큰(Audio Token)이란 (현재 글)
- 2-4 감정·톤 조절이 CS를 바꾸는 이유
Part 3 — 실시간 대화와 에이전트화: 인터럽트·MCP·도구 (5편)
- 3-1 실시간 인터럽트(끼어들기) 감지
- 3-2 실시간 음성에 MCP가 필요한 이유
- 3-3 스트리밍 중 MCP 초고속 데이터 룩업
- 3-4 통화 중 외부 API 도구 호출
- 3-5 실시간 세션 관리 — 통화 맥락·고객 데이터
Part 4 — 인프라·세션·보안: 프로덕션 백엔드 (5편)
- 4-1 동적 컨텍스트 윈도우 관리
- 4-2 WebRTC·WebSocket 초저지연 음성
- 4-3 비동기 이벤트 루프와 동시 콜 처리
- 4-4 트래픽 스파이크를 견디는 확장성 설계
- 4-5 실시간 음성 보안 — 암호화·PII 마스킹
Part 5 — 운영·품질·평가: 에이전틱 워크플로우와 신뢰성 (7편)
- 5-1 에이전틱 워크플로우 — 응대를 넘어 완결로
- 5-2 상용화의 한계와 트러블슈팅
- 5-3 보이스 에이전트 평가(Eval) 설계
- 5-4 관측성(Observability) — 어디서 끊기나
- 5-5 가드레일과 환각 제어
- 5-6 상담사 전환(Handoff) 설계
- 5-7 프롬프트 A/B 테스트와 튜닝
Part 6 — 음성 경험 고도화·실전 통합: 한국어·UX·전화망·엣지 (5편)
- 6-1 한국어 음성 AI의 난관 — 존댓말·코드스위칭
- 6-2 턴테이킹과 시맨틱 VAD
- 6-3 보이스 페르소나 디자인
- 6-4 SIP·PSTN 전화망 연동
- 6-5 온디바이스·엣지 S2S와 프라이버시
Part 7 — S2S 도입 전략·구매 의사결정 (4편)
Part 8 — LLM 콜봇 PoC 현장 (6편)
- 8-1 LLM 콜봇 PoC — 검증의 갭
- 8-2 STT 정확도 93% 목표가 부족한 이유
- 8-3 금융 콜봇에서 소수점이 중요한 이유
- 8-4 TTFT 1.5초, 콜봇 스트리밍 파이프라인 설계
- 8-5 콜봇 SLM: 30B vs 70B 트레이드오프
- 8-6 PoC와 본사업 사이의 성능 괴리
Part 9 — 상담어시스트: 상담사 화면을 바꾸는 실시간 AI (7편)
- 9-1 상담어시스트란 무엇인가 — 실시간 STT가 상담사 화면을 바꾸는 구조
- 9-2 상담어시스트의 뼈대 — STT·인텐트·KMS 파이프라인
- 9-3 추천의 근거 — KMS·RAG 지식 그라운딩
- 9-4 통화 중 놓친 고지를 잡는 실시간 필수 안내 체크
- 9-5 AI가 상담 품질을 자동 채점하는 법 — AutoQA
- 9-6 신입 상담사에게 어시스트가 더 필요한 이유
- 9-7 온프레미스 상담어시스트 — GPU 제약과 모델 선택
Part 10 — 직접 만든 롤플레이 챗봇: RAG 에이전트 구축기 (8편)
- 10-1 왜 롤플레이 챗봇을 직접 만들었나
- 10-2 전체 아키텍처 한 장
- 10-3 RAG 파이프라인과 로컬 임베딩
- 10-4 멀티 LLM 백엔드 스위칭
- 10-5 AI 고객 페르소나 프롬프트 엔지니어링
- 10-6 퀴즈 풀 사전생성
- 10-7 대화가 끝나면 채점한다
- 10-8 혼자 쓰는 챗봇의 현실
Part 11 — KMS 실무 — 지식관리시스템의 설계와 운영 현실 (8편)
토큰이라는 공통 언어: 텍스트에서 소리로
LLM이 텍스트를 처리할 때 가장 먼저 하는 일은 글자를 토큰으로 쪼개는 것입니다. "안녕하세요"라는 문장은 모델 내부에서 몇 개의 정수 ID 시퀀스로 변환되고, 모델은 그 정수들 사이의 통계적 관계를 학습합니다. 핵심은 모델이 "연속적인 무언가"가 아니라 "유한한 종류의 이산(discrete) 단위"만 다룬다는 점입니다. 어휘집(vocabulary)에 등록된 토큰만이 모델의 세계에 존재합니다.
소리를 LLM에 넣으려면 똑같은 규칙을 따라야 합니다. 연속적인 음파를 유한한 종류의 이산 단위로 바꿔야 한다는 뜻입니다. 이렇게 만든 단위가 음성 토큰이며, 텍스트 토큰처럼 정수 ID로 표현됩니다. 차이는 텍스트 토큰이 "글자 조각"을, 음성 토큰은 "짧은 소리 조각"을 가리킨다는 점뿐입니다. 일단 소리가 토큰의 형태를 갖추면 LLM은 텍스트를 다루던 방식 그대로 소리를 다룰 수 있습니다. 음성을 받아 곧바로 음성으로 답하는 Speech-to-Speech(S2S) 방식에서 음성 토큰이 그 심장으로 불리는 이유입니다.
파형에서 특징으로: 음향 특징 추출
음파를 곧바로 토큰으로 양자화하지는 않습니다. 원시 파형은 표본 수가 많아 그대로는 무겁고 의미 단위로 정제돼 있지 않으며 노이즈에 민감하기 때문에, 먼저 의미 있는 표현으로 압축하는 전처리 단계를 거칩니다. 이 단계의 산출물을 음향 특징(acoustic feature)이라고 부릅니다.
전형적인 흐름은 다음과 같습니다.
원시 파형(16kHz PCM) -> 짧은 프레임으로 분할 (보통 10~25ms 단위) -> 멜 스펙트로그램 등 시간-주파수 표현으로 변환 -> 신경망 인코더 통과 -> 프레임마다 고차원 특징 벡터
쉽게 말해 1초짜리 음성을 수십 개의 짧은 조각으로 자르고, 각 조각을 "이 순간 소리의 특성"을 요약한 벡터 하나로 바꾸는 것입니다. 이 벡터에는 어떤 발음이 들렸는지(내용), 목소리의 높낮이와 떨림(운율), 화자의 음색이 뒤섞여 담깁니다. 이 단계는 보통 자기지도 학습 기반 음성 인코더가 맡는데, 공개된 인코더 몇 종을 나란히 붙여 놓고 같은 음성을 넣어 비교해 보면 모델마다 잡아내는 "결"이 꽤 다르다는 게 눈에 띕니다. 텍스트 라벨 없이 대량의 음성만으로 학습해 둔 모델일수록 그 차이가 도드라집니다.
연속 벡터를 이산 토큰으로: 양자화의 핵심
특징 벡터는 여전히 연속적인 실수값입니다. LLM이 요구하는 것은 유한한 ID이므로, 연속 벡터를 가장 가까운 "대표값"으로 반올림하는 과정이 필요합니다. 이 과정을 벡터 양자화(Vector Quantization, VQ)라고 합니다.
핵심 도구는 코드북(codebook)입니다. 코드북은 미리 학습해 둔 대표 벡터들의 목록이며, 각 대표 벡터에는 번호가 붙어 있습니다. 입력 특징 벡터가 들어오면, 코드북에서 가장 비슷한 대표 벡터를 찾아 그 번호를 출력합니다. 결국 연속 벡터의 시퀀스가 정수 ID의 시퀀스, 즉 음성 토큰으로 변환됩니다.
문제는 코드북 하나로는 소리의 풍부함을 다 담기 어렵다는 점입니다. 코드북을 너무 키우면 학습이 불안정해지고, 너무 작으면 음질이 거칠어집니다. 그래서 실무에서 널리 쓰이는 방식이 잔차 벡터 양자화(Residual Vector Quantization, RVQ)입니다. 작동 원리는 단순합니다.
첫 번째 코드북으로 큰 윤곽을 잡은 뒤, "맞히지 못하고 남은 오차(잔차)"를 두 번째 코드북으로 다시 양자화하고, 거기서 또 남은 오차를 세 번째 코드북으로 양자화합니다. 이렇게 여러 층을 겹쳐서 점점 정밀하게 소리를 복원합니다.
이런 구조를 신경 오디오 코덱(neural audio codec)이라고 부릅니다. 덕분에 한 시점의 소리가 여러 개의 토큰(코드북 층마다 하나씩)으로 표현되며, 층을 얼마나 쓰느냐로 음질과 데이터양을 조절할 수 있습니다.
그림 1. 음성 토큰화 흐름 — 연속적인 파형이 특징 추출과 벡터 양자화를 거쳐 이산적인 오디오 토큰이 되면, LLM은 텍스트 토큰과 같은 방식으로 다음 토큰을 예측할 수 있다.
의미 토큰 vs 음향 토큰: 무엇을 보존하는가
음성 토큰이라고 다 같은 토큰이 아닙니다. 실무에서는 보통 두 종류로 나눠 생각합니다.
| 구분 | 의미 토큰(Semantic) | 음향 토큰(Acoustic) |
|---|---|---|
| 담는 정보 | 무슨 말을 했는가(발음·내용) | 어떻게 말했는가(음색·운율·감정) |
| 주 출처 | 자기지도 음성 인코더 | 신경 오디오 코덱(RVQ) |
| 토큰 수 | 상대적으로 적음 | 상대적으로 많음 |
| 역할 | 언어적 맥락 이해 | 자연스러운 음성 복원 |
이 분리가 중요한 이유는 감정과 뉘앙스의 보존 때문입니다. 텍스트로 받아쓰기를 해 버리면 "정말요?"라는 한 단어가 의심인지 감탄인지 짜증인지 구분할 수 없습니다. 글자만 남고 억양이 사라지기 때문입니다. 반면 음향 토큰은 그 순간의 높낮이·속도·떨림을 함께 인코딩하므로, 같은 단어라도 다른 토큰 조합이 됩니다. 의미 토큰이 "무엇을"을, 음향 토큰이 "어떻게"를 책임지며 두 정보가 손실 없이 모델 안으로 들어갑니다. 텍스트를 경유하던 옛 파이프라인이 끝내 살리지 못한 부분을 음성 토큰이 살려 내는 핵심 메커니즘입니다.
이 지점에서 자주 놓치는 게 하나 있습니다. 텍스트를 한 번 경유하는 손실이 억양·감정에만 그치는 게 아니라는 점입니다. 내용 자체가 어긋나는 경우도 있습니다. 잡음이 끼거나 발음이 뭉개져 못 알아들은 구간을 침묵처럼 통째로 지워 버리는 인식 모델도 있고, 반대로 빈자리를 그럴듯한 말로 억지로 채워 넣는(할루시네이션) 모델도 있는데, 앞은 정보가 사라지고 뒤는 없던 정보가 끼어드는 식이라 둘 다 위험합니다. 한 번 글자로 굳어 버린 오류는 뒷단에서 되돌리기도 어렵습니다. 소리를 글자로 바꾸지 않고 그대로 토큰화하는 방식이 주목받는 이유 중 하나가 바로 이 "텍스트 변환 손실"을 줄이려는 데 있습니다. 못 알아들은 구간조차 애매한 채로의 소리로 모델에 전달되어, 글자로 단정 짓기 전에 맥락으로 판단할 여지를 남기는 것입니다.
LLM이 토큰으로 맥락을 이해하는 방식
토큰화가 끝나면 그다음은 의외로 익숙합니다. LLM은 텍스트 토큰을 예측하던 것과 똑같이 음성 토큰을 예측합니다. 모델의 어휘집을 텍스트 토큰과 음성 토큰을 모두 포함하도록 확장해 두면, 모델은 둘을 한 시퀀스 안에서 자연스럽게 섞어 다룰 수 있습니다.
작동을 의사코드로 그리면 다음과 같습니다.
입력 음성 -> 음성 토큰 시퀀스 [a12, a87, a3, ...] 모델 -> 다음 토큰을 자기회귀(autoregressive)로 예측 출력 -> 응답용 음성 토큰 시퀀스 [a55, a9, ...] 디코더 -> 음성 토큰을 다시 파형으로 복원 -> 스피커 출력
여기서 모델은 "소리"를 직접 듣는 게 아니라, 소리를 번역한 토큰들의 통계적 패턴을 읽습니다. 그래서 충분히 학습된 음성 LLM은 "질문 끝에서 음이 올라가면 의문문"이라는 운율적 단서까지 토큰 패턴으로 포착해 응답의 어조를 맞춥니다.
다만 공짜는 아닙니다. 음성 토큰은 텍스트보다 밀도가 훨씬 높습니다. 같은 1초라도 음향 토큰은 여러 층에 걸쳐 수십 개씩 생성되므로 컨텍스트가 빠르게 차고 연산 비용도 커집니다. 그래서 토큰레이트(초당 토큰 수)를 낮추면서도 음질을 지키는 코덱 설계가 실시간 음성 AI 성능의 승부처입니다.
정리: 음성 토큰화의 3핵심
음성 토큰화에는 압축률·품질·지연 사이의 균형이라는 줄타기가 따르지만, 그 구체적인 트레이드오프는 별도 편에서 자세히 다룹니다. 이 글의 메커니즘 관점에서 음성 토큰은 세 가지를 동시에 해냅니다.
첫째, 연속적인 소리를 LLM이 다룰 수 있는 이산 단위로 바꾸는 이산화입니다. 둘째, 의미 토큰과 음향 토큰을 분리·결합해 내용과 감정을 함께 보존합니다. 셋째, 텍스트와 같은 공통 어휘공간에 올라가 자기회귀 예측의 대상이 됩니다. 이 세 가지가 맞물릴 때, 비로소 LLM은 받아쓰기를 넘어 진짜로 "소리를 이해하고 소리로 답하는" 에이전트가 됩니다.
오디오 토큰을 볼 때 확인할 3가지
다른 자료에서 음성 토큰을 접할 때, 아래 세 가지만 짚어 보면 그 방식의 성격을 빠르게 가늠할 수 있습니다.
- 파형을 바로 쓰는지, 음향 특징으로 먼저 압축하는지 확인합니다.
- 의미 토큰과 음향 토큰 중 무엇을 보존하는 구조인지 봅니다.
- 초당 토큰 수가 지연·비용에 어떻게 걸리는지 따집니다.
이 세 축을 기준으로 읽으면 어떤 음성 토큰화 방식이든 그 트레이드오프를 스스로 판단할 수 있습니다.
댓글
댓글 쓰기