실제 콜센터 전화에 AI 붙이기: SIP·PSTN 전화망 연동

음성 AI 데모는 대개 웹 브라우저에서 시작합니다. 마이크 버튼을 누르고 말하면 AI가 바로 대답하니 꽤 그럴듯하게 들립니다. 그런데 실제 콜센터에서 고객은 브라우저가 아니라 '전화'로 겁니다. 데모와 운영 사이의 이 간극이 생각보다 깊습니다. 전화로 들어오는 음성은 웹과는 전혀 다른 망과 다른 신호 규약을 거쳐 도착하기 때문입니다. 이번 글에서는 실시간 음성 AI를 실제 전화망에 연결할 때 마주치는 핵심 개념을 정리합니다. PSTN과 SIP 같은 전화망 기본기부터, 전화 오디오를 AI 파이프라인으로 잇는 미디어 게이트웨이, 8kHz 협대역 음질 문제, DTMF·통화 전환·녹취 같은 운영 요소, 그리고 전화망과 웹을 잇는 브리징까지 한 번에 짚어 보겠습니다.

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

← 이전: 6-3 보이스 페르소나 디자인 / 다음 → 6-5 온디바이스·엣지 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편)

웹이 아니라 '전화'로 들어오는 음성

브라우저 데모에서 음성은 비교적 깨끗한 디지털 오디오로 서버에 도착합니다. 반면 실제 전화는 다릅니다. 고객의 발화는 전화망을 거치며 여러 단계의 신호 변환과 압축을 통과합니다. 이 과정에서 음질이 깎이고, 통화를 걸고 끊고 전환하는 일은 음성 데이터와는 별개의 '제어 신호'로 오갑니다.

즉 전화망 연동에는 두 가지 일이 동시에 필요합니다. 하나는 통화를 설정하고 관리하는 신호 처리이고, 다른 하나는 실제 목소리가 담긴 오디오를 AI가 처리할 수 있는 형태로 받아오는 일입니다. 음성 AI 프로젝트가 데모까지는 빠르게 가다가 실제 운영 직전에서 막히는 이유가 대개 여기에 있습니다. 모델의 성능 문제가 아니라, 모델에 닿기까지의 '마지막 1미터'인 전화망 연결이 별도의 영역이기 때문입니다.

웹 데모와 전화 연동을 나란히 준비해 보면 순서가 뒤바뀌는 경우가 흔합니다. 처음엔 "브라우저에서 이미 잘 돌아가니 전화 붙이는 건 마무리 작업이겠지" 하고 일정 뒤쪽에 배치했다가, 막상 손대 보면 신호 처리·미디어 게이트웨이·코덱 협상까지 별도로 검증해야 할 항목이 한 뭉치 튀어나옵니다. 그래서 전화 연동 검증은 나중이 아니라 초반부터 병행하는 편이 전체 일정을 지키는 데 유리합니다.

PSTN·SIP·SIP 트렁크 기본 개념

먼저 세 가지 용어를 정리하겠습니다. PSTN(Public Switched Telephone Network)은 우리가 흔히 말하는 공중전화망입니다. 일반 전화번호로 전화를 걸 때 통화를 실어 나르는 전통적인 망이라고 보면 됩니다.

SIP(Session Initiation Protocol)는 통화 세션을 설정하고 해제하는 신호 규약입니다. "전화를 건다", "받는다", "끊는다", "보류한다" 같은 통화의 상태 변화를 주고받는 약속입니다. 중요한 점은 SIP 자체가 목소리를 실어 나르지는 않는다는 것입니다. SIP는 통화를 '제어'하고, 실제 오디오는 별도 경로로 흐릅니다.

SIP 트렁크(SIP Trunk)는 인터넷(IP) 기반으로 전화망에 연결하는 가상의 통로입니다. 과거에 물리 회선을 여러 가닥 깔던 것을, IP 위에서 논리적인 회선으로 묶어 제공하는 방식이라고 이해하면 쉽습니다. 보이스봇 서비스를 전화망에 붙일 때는 이 SIP 트렁크가 외부 세계와의 출입구 역할을 합니다.

비유하자면 PSTN은 도로망, SIP는 교통 관제 신호, SIP 트렁크는 우리 시스템이 그 도로로 진입하는 진입로입니다.

그림 1. 전화망에서 AI 파이프라인까지의 연결 경로 — SIP 트렁크가 신호를 진입시키고, 미디어 게이트웨이가 RTP 오디오를 AI가 처리할 수 있는 형태로 중계한다.

미디어 게이트웨이: 전화 오디오를 AI 파이프라인으로 잇기

앞서 SIP는 신호이고 오디오는 별도로 흐른다고 했습니다. 이 오디오는 보통 RTP(Real-time Transport Protocol)라는 규약으로 전송됩니다. 그리고 통화를 시작할 때 양쪽이 "어떤 코덱으로, 어디로 오디오를 보낼지"를 SDP(Session Description Protocol)로 협상합니다. 정리하면 SIP로 통화를 열고, SDP로 오디오 조건을 합의하고, RTP로 실제 목소리가 흐르는 구조입니다.

여기서 미디어 게이트웨이의 역할이 등장합니다. 게이트웨이는 전화망에서 들어온 RTP 오디오를 받아, AI 파이프라인이 입력으로 받을 수 있는 오디오 스트림으로 변환·중계합니다. 반대로 AI가 만들어 낸 응답 음성을 다시 전화망 쪽 RTP로 흘려보냅니다. 인바운드 콜 한 통이 처리되는 흐름을 의사코드로 그려 보면 다음과 같습니다.

수신: SIP INVITE (새 전화 도착)
  → 응답 가능 여부 확인
  → SDP 협상: 코덱·오디오 목적지 합의
  → 200 OK 응답으로 통화 수락

미디어 연결:
  → RTP 오디오 스트림 수신 시작(고객 목소리)
  → 게이트웨이가 AI 입력 형식으로 변환
  → AI 파이프라인에 오디오 스트림 전달

대화 루프:
  while 통화 유지:
      고객 발화 → AI 처리 → 응답 음성 생성
      응답 음성 → RTP로 변환 → 전화망으로 송출

종료:
  → SIP BYE 수신/송신 → 미디어 스트림 정리

게이트웨이는 단순 변환기가 아니라, 신호와 미디어를 양방향으로 일관되게 이어 주는 연결의 중심입니다. 이 계층이 안정적이지 않으면 모델이 아무리 좋아도 통화가 끊기거나 음성이 어긋납니다.

코덱과 8kHz 협대역(narrowband) 음질 문제

전화망 연동에서 음질은 피해 갈 수 없는 주제입니다. 전통적인 전화 통화는 통상 8kHz 표본화의 협대역(narrowband) 오디오로 다뤄집니다. 사람 목소리의 핵심 대역만 남기고 나머지를 잘라 낸 상태라, 우리가 흔히 느끼는 "전화 목소리"의 답답함이 여기서 나옵니다.

문제는 이 협대역 음질이 음성 인식과 합성 품질에 영향을 준다는 점입니다. 광대역(wideband)에서 또렷하던 발음도 협대역에서는 비슷한 소리들이 뭉개져 인식이 더 어려워질 수 있습니다. 그래서 전화망 연동에서는 어떤 코덱으로 오디오를 주고받을지가 실무적으로 중요합니다.

코덱	대역	특징
G.711	협대역(8kHz)	전화에서 가장 널리 쓰이는 기본 코덱, 호환성 높음
G.722	광대역(16kHz)	더 넓은 대역, 음질 개선 여지
Opus	가변(광대역 가능)	유연한 비트레이트, 웹·IP 환경에서 널리 사용

핵심은 양쪽이 광대역을 지원한다면 SDP 협상 단계에서 광대역 코덱을 선택해 음질을 끌어올릴 여지가 있다는 점입니다. 다만 전화망 구간이 협대역으로 고정돼 있으면, 중간에 광대역으로 바꾼다고 잘려 나간 정보가 되살아나지는 않습니다. 그래서 실무에서는 "가능한 구간에서 최대한 넓은 대역을 확보하고, 협대역 구간을 전제로 인식·합성 품질을 검증한다"는 두 갈래 대응이 함께 갑니다.

DTMF(번호 입력)·통화 전환·녹취 처리

전화 응대에는 음성 말고도 다뤄야 할 제어 신호가 있습니다. 대표적인 것이 DTMF(Dual-Tone Multi-Frequency), 즉 고객이 번호 키를 누를 때 발생하는 신호입니다. "상담원 연결은 0번"처럼 키 입력을 받아야 하는 흐름에서는 이 DTMF를 정확히 인식해야 합니다. IP 환경에서는 키 입력을 오디오에 섞지 않고 별도의 이벤트 신호로 전달하는 방식이 일반적이며, 이렇게 하면 압축 과정에서 신호가 망가질 위험을 줄일 수 있습니다.

통화 전환(transfer)도 핵심입니다. AI가 처리하기 어려운 상황에서는 사람 상담원에게 매끄럽게 넘겨야 합니다. 이때 단순히 연결만 하는 것이 아니라, 지금까지의 대화 맥락을 함께 넘겨야 고객이 같은 설명을 반복하지 않습니다. 맥락 없는 전환은 오히려 만족도를 떨어뜨립니다.

녹취는 운영과 규정의 영역입니다. 통화 녹음에는 사전 고지와 동의, 보관 기간, 접근 통제 같은 절차가 따라붙습니다. 기술적으로 녹음이 가능하다는 것과 그것을 어떻게 합법적·안전하게 운용하느냐는 별개의 문제이며, 이 부분은 도입 단계에서 반드시 정책으로 정리하고 가야 합니다.

SIP ↔ WebRTC 브리징

마지막으로 전화망과 웹이 만나는 지점을 짚겠습니다. 많은 음성 AI 스택은 웹 실시간 통신 기술인 WebRTC를 기반으로 구성됩니다. 그런데 고객은 전화(SIP/RTP)로 들어옵니다. 서로 다른 두 세계를 잇기 위해 필요한 것이 SIP와 WebRTC를 연결하는 브리지입니다.

브리지의 역할은 한마디로 "전화망 쪽 신호·오디오와 웹 쪽 신호·오디오를 서로 통하게 번역하는 것"입니다. 전화로 들어온 통화를 웹 기반 AI 파이프라인이 다룰 수 있게 넘기고, AI의 응답을 다시 전화망으로 돌려보냅니다. 이렇게 하면 레거시 전화망을 그대로 둔 채로, 최신 웹 기반 음성 AI 스택을 뒤에 붙일 수 있습니다.

다만 WebRTC 자체의 내부 동작, 즉 연결 수립 절차나 미디어 보안, 협상 과정의 세부는 이 글의 범위를 벗어납니다. 그 부분은 웹 기반 실시간 프로토콜을 다루는 15편에서 따로 정리합니다. 이 글에서는 "전화망과 웹 스택을 잇는 다리가 필요하고, 그 다리가 양쪽을 번역한다"는 경계까지만 이해하면 충분합니다.

구분	전화망(SIP/PSTN)	웹(WebRTC)
진입 경로	일반 전화번호, SIP 트렁크	브라우저·앱
신호 제어	SIP	웹 기반 시그널링(15편)
음질 기본값	협대역으로 고정되기 쉬움	광대역 확보 용이
연동 포인트	게이트웨이·브리지로 웹 스택과 연결	브리지로 전화망과 연결

자주 묻는 질문(FAQ)

Q1. 음성 AI를 붙이려면 기존 콜센터 장비를 다 교체해야 하나요?
반드시 그렇지는 않습니다. 핵심은 전화망과 AI 스택을 잇는 연결 계층, 즉 SIP 트렁크와 게이트웨이·브리지를 어떻게 구성하느냐입니다. 기존 전화 인프라를 유지한 채 그 뒤에 콜봇을 붙이는 방식도 가능하며, 어떤 구조가 적절한지는 현행 환경에 따라 달라집니다.

Q2. 8kHz 협대역이면 음성 인식이 많이 떨어지지 않나요?
협대역이 광대역보다 불리한 것은 사실입니다. 다만 전화 음성은 오랫동안 협대역으로 다뤄져 온 영역이라, 이를 전제로 한 처리·검증이 가능합니다. 가능한 구간에서 광대역을 확보하되, 협대역을 기준으로 인식·합성 품질을 미리 점검하는 편이 안전합니다.

Q3. 전화망을 거치면 응답이 더 느려지나요?
신호 변환과 망 구간을 거치는 만큼 웹 직결보다 지연 요소가 늘어날 수 있습니다. 다만 체감 지연을 줄이는 설계는 별도 주제이며, 실시간 음성의 레이턴시 최적화는 이 시리즈의 다른 편에서 더 깊이 다룹니다. 이 글에서는 전화망 연동 자체에 집중합니다. 덧붙이면 여기 정리한 내용은 2026년 6월 기준이고 세부 구성은 환경마다 다를 수 있으니, 실제 설계의 출발점으로 참고해 주시면 좋겠습니다.

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

6월 13, 2026

자세한 내용 보기

이 블로그 검색

AI에이전트엔지니어링