주말 사이에 OpenAI Realtime API 데모를 붙여 음성 에이전트를 만들어 본 개발자라면 그 완성도에 한 번쯤 놀랍니다. 마이크를 열고 말을 걸면 끊김 없이 대화가 이어지고, 중간에 끼어들어도 자연스럽게 받아칩니다. 영어로는 거의 '완성된 제품'처럼 보입니다.
문제는 그다음입니다. 같은 파이프라인에 한국어를 흘려보내면 "1,245,600원"을 "일 이 사 오 육 공 공 원"으로 읽거나, "010-1234-5678"을 숫자 나열로 뭉개고, 상담이 길어지면 반말과 존댓말이 뒤섞입니다. PoC 데모에서는 그럴듯했던 것이 실제 콜센터 시나리오에 들어가는 순간 벽에 부딪힙니다.
이 글은 특정 벤더를 비방하려는 것이 아닙니다. 글로벌 실시간 음성 스택은 영어권·멀티모달·개발 편의에서 분명한 강점을 갖습니다. 다만 '한국어 콜봇'이라는 구체적 과제에서 어떤 기술적 트레이드오프가 발생하는지, 그리고 그 구간을 한국어 특화 스택이 어떻게 메우는지를 계층별로 짚습니다. 결론을 미리 말하면, 승부는 데모 화면이 아니라 화면에 보이지 않는 구간에서 갈립니다.
실시간 음성 에이전트는 4개 계층으로 나뉜다
실시간 음성봇을 하나의 블랙박스로 보면 문제를 진단하기 어렵습니다. 실제로는 네 개의 계층이 직렬로 연결된 파이프라인입니다.
| 계층 | 역할 | 한국어에서 민감한 지점 |
|---|---|---|
| STT(음성인식) | 발화 → 텍스트 | 조사·띄어쓰기, 은행/의료 전문용어, 사투리 |
| LLM(대화·추론) | 의도 파악·응답 생성 | 존댓말/호칭, 문서 근거 답변(그라운딩) |
| TTS(음성합성) | 텍스트 → 음성 | 숫자·금액·주소·전화번호 정규화, 발음, 지연 |
| 텔레포니 | PSTN/SIP 연동 | 국내 회선 연동, 망분리, 통화 지연 |
OpenAI Realtime API는 STT·LLM·TTS를 하나로 묶은 통합(speech-to-speech) 모델이라는 점이 매력입니다. 하지만 통합형은 계층별로 다른 엔진을 갈아 끼우기 어렵고, 한국어 TTS 정규화만 따로 손보는 식의 튜닝이 사실상 불가능합니다. 문제가 어느 계층에서 터졌는지 분리 진단하기도 힘듭니다.
글로벌 스택으로 한국어를 PoC할 때 부딪히는 5가지
- 숫자·금액·기호 정규화 — 한국어 TTS 품질의 절반은 텍스트 정규화(TN)가 좌우합니다. "1,245,600원"은 "백이십사만 오천육백 원"으로 읽어야 하고, "3.5%"·"오전 9시 30분"·"2026년 3분기"처럼 도메인마다 규칙이 다릅니다. 영어 중심으로 학습·튜닝된 스택은 이 규칙 밀도가 낮습니다.
- 주소·전화번호 — "서울 강남구 테헤란로 152"의 도로명·번지, "02-1234-5678"의 자릿수 끊어 읽기는 한국어 특유의 규칙입니다. 콜센터에서 이 두 가지를 자주 다루는데, 오독은 곧 재확인 통화로 이어집니다.
- 존댓말·호칭 일관성 — "고객님, ~하시겠어요?"의 어투를 대화 내내 유지하는 것은 LLM 프롬프트만으로는 흔들립니다. 발화가 길어지면 반말이 섞이는 현상이 대표적입니다.
- 레이턴시 — 뒤에서 자세히 다루지만, 물리적 왕복 거리와 계층 수가 지연을 만듭니다.
- 데이터 주권·망분리 — 금융·의료·공공은 통화 원문이 해외 리전으로 나가는 것 자체가 규제·심사 이슈입니다.
발음과 정규화 — 데모와 실전을 가르는 구간
정규화는 화면에 안 보이지만 통화 품질을 가장 크게 흔듭니다. 상담봇이 "납부하실 금액은 1,245,600원입니다"를 잘못 읽으면, 고객은 금액을 다시 물어보고 상담은 길어집니다. 오독 한 건이 통화 시간에 얼마나 영향을 주는지는 간단한 계산으로 가늠할 수 있습니다.
- 가정: 콜센터 발화의 약 15%가 숫자·금액·주소·전화번호 → 이 구간의 오독률 10% → 오독 1건당 재확인·정정에 평균 30초 추가
- 통화당 관련 발화가 4회라면: 4 × 0.10 × 30초 = 약 12초/콜의 순증
- 하루 5,000콜 규모라면: 12초 × 5,000 = 60,000초 ≈ 약 16.7시간/일의 상담 시간이 오독 정정에 소모
정확한 수치는 도메인마다 다르지만, 정규화 오독률이 곧 평균 통화시간(AHT)과 재문의율로 환산된다는 구조는 동일합니다. 한국어 특화 엔진은 이 정규화 규칙을 언어 자원으로 내장합니다. 휴멜로의 DIVE는 한국어 숫자·금액·단위·주소 정규화를 파운데이션 모델 단계에서 다루도록 설계됐고, 48kHz 음질과 20초 샘플 보이스클로닝을 함께 제공합니다. 정규화·발음이라는 '보이지 않는 절반'을 한국어 기준으로 처리한다는 점이 범용 스택과의 실질적 차이입니다.
레이턴시와 텔레포니 — 물리 법칙과 규제의 현실
체감 응답성은 '모델이 얼마나 빠른가'만으로 결정되지 않습니다. 사용자 발화 종료 → STT → LLM → TTS 첫 소리까지의 왕복이 관건인데, 여기에 서버 리전까지의 물리적 네트워크 지연이 더해집니다. 해외 리전을 경유하면 왕복만으로 수백 ms가 쌓이고, PSTN/SIP 통화에는 회선 자체의 지연이 또 얹힙니다.
| 요소 | 글로벌 통합 스택(해외 리전) | 한국어 특화·국내 배포 |
|---|---|---|
| 첫 소리까지 체감 지연 | 통합 모델은 빠르나 해외 왕복이 가산 | 국내 리전/온프레미스로 왕복 최소화 |
| TTS 스트리밍 첫 청크 | 통상 수백 ms 수준 | 국내 배포 기준 수백 ms 이내 |
| 텔레포니 연동 | 국내 회선·번호 연동 별도 과제 | 국내 SIP/PSTN·다채널 배포 전제 설계 |
| 데이터 경로 | 원문이 해외로 이동 | 온프레미스로 내부 처리 가능 |
특히 데이터 주권은 성능이 아니라 '도입 가능 여부'를 가릅니다. 금융·공공에서는 통화 원문이 외부로 나가면 안 되는 경우가 많고, 이 조건이 안 맞으면 아무리 성능이 좋아도 후보에서 탈락합니다. DIVE가 GPU 없이 CPU만으로 도는 온프레미스 버전과 약 0.35초(350ms) 스트리밍 합성을 제공하는 것도 이 지연·주권 제약을 국내 기준으로 풀기 위한 설계입니다.
