지터는 음성 패킷이 도착하는 시각의 들쭉날쭉함입니다. VoIP 통화는 목소리를 작은 패킷으로 쪼개 20밀리초마다 하나씩 보내고, 그 패킷들이 똑같이 일정한 박자로 도착하기를 기대합니다. 늦거나 빠르거나 순서가 뒤바뀌어 도착하면, 그 불규칙함이 지터이며 상대방에게는 끊기는 단어, 로봇 같은 소리, 공백으로 들립니다.
음성 에이전트를 운영한다면 지터는 두 번 중요합니다. 들어오는 길에서는 발신자의 오디오를 망가뜨려 음성 인식 모델이 더 나쁜 신호를 듣게 되고, 나가는 길에서는 에이전트의 오디오를 망가뜨려 발신자가 제품이 고장 났다고 결론 내리게 됩니다. 브라우저에서는 멀쩡한데 전화에서 로봇처럼 들린다면, 모델을 건드리기 전에 네트워크를 확인하세요.
이 가이드는 지터가 무엇인지, 원인은 무엇인지, 실제 통화에서 어떻게 재는지, 어떻게 고치는지를 다룹니다. 음성 에이전트 개발자가 실제로 제어할 수 있는 구간도 포함합니다.
지터 한눈에 보기
| 지표 | 쾌적 | 체감됨 | 사용 불가 |
|---|---|---|---|
| 지터 | 30ms 미만 | 30~50ms | 50ms 초과 |
| 패킷 손실 | 1% 미만 | 1~3% | 3% 초과 |
| 편도 지연 | 150ms 미만 | 150~400ms | 400ms 초과 |
이는 보장이 아니라 경험칙입니다. 150ms와 400ms 지연 수치는 허용 가능한 편도 지연에 관한 ITU 권고 G.114에서 나왔고, 30ms 지터 수치는 Cisco의 지터 문서 같은 벤더 문서에서 볼 수 있는 지침입니다. 좋은 적응형 지터 버퍼는 30ms가 넘는 지터도 숨길 수 있지만, 지연 추가라는 대가가 따릅니다. 이 지표들을 아우르는 전체 청취 경험을 하나의 숫자로 압축하려는 시도가 MOS(평균 의견 점수)입니다.
지터의 실체
VoIP 음성은 RTP(Real-time Transport Protocol) 위를 달립니다. 송신 측은 모든 패킷에 시퀀스 번호와 타임스탬프를 찍고(RFC 3550), 수신 측은 패킷이 보내진 순서와 20ms 분량의 오디오 조각이 재생되어야 할 정확한 시각을 둘 다 알고 있습니다.
지터는 그 일정과 현실 사이의 차이입니다. 41번 패킷이 40번보다 20ms 뒤에 도착했는데 42번이 41번보다 60ms 뒤에 도착했다면, 그 스트림에는 지터가 있는 것입니다. 같은 RFC는 보고 방식도 정의합니다. 모든 RTP 스트림에는 RTCP 제어 메시지가 짝으로 따라붙고, 수신 측은 측정한 도착 간 지터가 포함된 리시버 리포트를 주기적으로 돌려보냅니다. 제대로 된 전화 시스템이 별도 계측 없이 지터를 알려줄 수 있는 이유입니다. 프로토콜이 처음부터 계속 점수를 매기고 있었기 때문입니다.
비슷해 보이지만 고치는 법이 다른 이웃 둘을 구분해 두면 좋습니다.
- 레이턴시. 패킷이 전반적으로 얼마나 늦게 도착하는가입니다. 사람들이 어쩔 수 없이 말을 겹치게 하지만, 오디오 자체를 왜곡하지는 않습니다.
- 패킷 손실. 아예 도착하지 않는 패킷(또는 너무 늦어 쓸 수 없어 수신 측이 손실로 세는 패킷)입니다. 손실은 오디오 조각을 없애고, 지터는 그 조각들을 엉망으로 배달할 뿐입니다. 순서가 뒤바뀐 패킷 뭉치는 수신 측에는 손실처럼 보입니다. 디코더가 늦은 패킷을 하염없이 기다릴 수는 없기 때문입니다.
지터는 어떻게 들리나
지터가 커지는 통화에서 사람들은 똑같은 경과를 묘사합니다. 단어 가장자리가 잘리기 시작합니다. 디코더가 빠진 프레임을 보간하기 시작하면 목소리가 금속적이거나 로봇처럼 변합니다. 이어서 공백이 옵니다. 수신 측이 패킷을 기다리는 0.5초의 침묵이고, 기다리던 패킷은 잠시 뒤 한꺼번에 몰려옵니다. 극단에 가면 통화가 끊깁니다.
이 모든 것이 지터 버퍼가 자기 일을 하다가 여유분을 다 쓴 모습입니다. 그러면 자연스럽게 이런 질문이 나옵니다.
지터 버퍼와 그 대가
지터 버퍼는 수신 측의 작은 큐입니다. 패킷이 도착하는 즉시 재생하는 대신, 수신 측은 패킷을 잠시 보관했다가 일정한 박자로 보냅니다. 그래서 30ms 늦게 도착한 패킷도 제자리에 맞출 수 있습니다. 일반적인 버퍼는 3050ms 분량의 오디오를 담습니다. 적응형은 상황에 따라 늘었다 줄었다 하며, 때로는 100200ms까지 커집니다.
이 거래는 지연을 내고 매끄러움을 사는 것입니다. 버퍼의 1밀리초는 왕복에 더해지는 1밀리초이고, 추가 지연이 대략 150ms를 넘어가면 대화가 무전기 교신처럼 느껴지기 시작합니다. 각자 기다렸다가, 말하고, 다시 기다립니다. 너무 작은 버퍼는 늦은 패킷을 버려 끊김이 들립니다. 너무 큰 버퍼는 지터를 숨기는 대신 레이턴시를 건넵니다. 둘 다 주는 설정은 없습니다. 그래서 버퍼 튜닝보다 네트워크 수리가 낫습니다.
버퍼가 어디 있는지는 통화에 따라 다릅니다.
- 브라우저와 앱 통화(WebRTC) 에는 적응형 지터 버퍼와 패킷 손실 은폐가 기본 탑재되어 있습니다. WebRTC vs WebSocket 가이드에서 다룹니다. 직접 조정할 일은 거의 없습니다.
- SIP 전화기, PBX, SBC(세션 보더 컨트롤러) 는 설정 가능한 버퍼가 있으며, 기본값이 우리 네트워크에 맞지 않을 수 있습니다.
- 날것의 RTP 연동 에서는 버퍼 작성자가 바로 당신입니다. SIP 트렁크에서 자체 스택으로 오디오를 끌어온다면, 그 버퍼 크기 조정은 당신의 일입니다.
지터는 어디서 오나
지터는 거의 항상 큐잉 문제입니다. 경로 어딘가에서 패킷이 각기 다른 시간만큼 기다리고 있습니다.
- 혼잡. 찼다가 비워지는 라우터나 스위치 포트는 패킷을 예측 불가능한 시간만큼 붙듭니다. 고전적인 원인이며, 붐비는 시간대에 나타납니다.
- Wi-Fi와 셀룰러. 무선 링크는 송신 시간을 배정하고 조용히 재전송하므로, 도착 시간 변동이 유선 이더넷보다 훨씬 큽니다. 호텔 Wi-Fi로 거는 발신자는 괜한 상상을 하는 게 아닙니다.
- QoS 부재. 서비스 품질 마킹이 없으면 음성 패킷이 대용량 다운로드 뒤에 줄을 섭니다. 음성 트래픽을 마킹하면(보통 DSCP EF) 우리 라우터와 많은 통신사 백본이 우선 처리해 줍니다. 다만 마킹은 공중 인터넷을 넘지 못하는 경우가 많습니다.
- 경로 변경. 통화 중간에 트래픽이 다른 경로로 옮겨가면 새 경로는 타이밍이 다르고, 버퍼가 적응할 때까지 스트림이 말을 더듬습니다.
- 너무 큰 버퍼. 버퍼블로트는 지터의 조용한 사촌입니다. 어딘가의 거대한 큐가 부하에 따라 변하는 상주 지연을 추가하고, 어디에도 패킷 손실로는 나타나지 않습니다.
지터 측정 방법
특별한 장비는 필요 없습니다. 통화가 이미 스스로를 측정하고 있습니다.
- RTCP 리시버 리포트를 읽는다. 지터 필드는 상대방이 실제로 겪은 값에 대한 공인 숫자로, 스트림의 타임스탬프 단위로 표시됩니다. G.711 통화에서는 8로 나누면 밀리초가 됩니다(대부분의 대시보드는 환산되어 표시됩니다). PBX, SBC, CPaaS 대시보드가 통화별로 보여 줍니다.
- Wireshark로 스트림을 캡처한다. Telephony → RTP → Stream Analysis 가 방향별 지터와 손실을 보고하고, 수신 측이 실제로 가지고 작업한 오디오를 그대로 들려줍니다.
- WebRTC라면 통화 중 chrome://webrtc-internals 를 열고
jitter,packetsLost,jitterBufferDelay를 실시간으로 봅니다. - 간이 탐침으로 상대방에게 ping을 날린다. 왕복 시간의 평균과 최댓값 사이의 큰 차이는 경로상의 지터를 시사합니다. RTP 지터는 오디오 스트림 자체의 타임스탬프 단위로 재기 때문에, 이는 추정치이지 지표 그 자체는 아닙니다.
가장 바쁜 시간대에 실제 통화 중에 측정하세요. 혼잡한 화요일의 문제를 한적한 일요일에 측정하면 모든 게 괜찮다는 답이 나올 뿐입니다.
지터 해결 방법
제어할 수 있는 구간부터 바깥으로 나아가세요.
- 우리 네트워크에서 음성을 우선 처리한다. RTP에 DSCP EF를 마킹하고 라우터가 그것을 존중하는지 확인합니다. 다른 무엇보다 먼저 통화 트래픽을 유선 연결로 옮기세요.
- 지터 버퍼 크기를 의도적으로 잡는다. 설정할 수 있는 장비에서는 30~50ms 부근에서 시작하고, 적응형 버퍼가 있으면 그것을 선택합니다.
- 손실을 견디는 코덱을 고른다. 코덱을 선택할 수 있는 구간에서는 Opus가 대역 내 전진 오류 정정을 내장합니다(RFC 6716). 공중 전화망에서는 G.711을 쓰게 되는데, 여기에는 그런 보호가 없어 전적으로 버퍼에 의지합니다.
- 경로를 짧게 한다. 발신자 가까이에 거점을 둔 제공자를 고르세요. 추가되는 네트워크 구간마다 찰 수 있는 큐가 하나씩 늘어납니다.
- 라스트 마일은 받아들인다. 발신자가 있는 카페의 Wi-Fi는 고칠 수 없습니다. 할 수 있는 일은 그것을 측정하는 것입니다. 남의 라우터 때문에 우리 스택을 디버깅하는 일을 그만두기 위해서요.
지터와 음성 에이전트
에이전트 통화는 사람 간 통화보다 연결 고리가 많습니다. 발신자의 전화, 발신자의 통신사, 우리의 전화 제공자나 SIP 트렁크, 그리고 에이전트 스택, 그리고 돌아오는 길. 지터는 어느 구간에서든 들어올 수 있고, 발신자의 경험에서는 모델 레이턴시와 더해집니다. 발신자에게는 “네트워크가 120ms의 버퍼를 추가했고 그다음 모델이 90ms 걸렸다”로 들리지 않습니다. 느리고 끊기는 하나의 에이전트로 들릴 뿐입니다.
네트워크를 정직하게 유지하는 습관은 두 가지입니다.
- 구간별로 측정한다. 전화 제공자의 RTCP 통계를 읽고, 음성 인식과 음성 합성 홉을 따로 잽니다. Cartesia는 Sonic의 모델 레이턴시 90ms 미만을 공개합니다. 그것은 모델 이야기이고, 네트워크 구간은 그 위에 자체 지연을 얹습니다. 바로 그 지연을 잡아내려고 P95·P99 측정이 있는 것입니다. 모델은 빠른데 통화가 여전히 느리거나 깨진다면, 그것은 지터를 보고 있는 것입니다.
- 실제 전화 경로로 테스트한다. 전화 오디오는 8kHz의 G.711 mu-law 또는 A-law로 흐르고, 다른 누군가의 지터 버퍼를 지납니다. 노트북에서 깨끗하게 들리는 에이전트가 혼잡한 통신사 경로에서는 고장 난 것처럼 들릴 수 있습니다. 음성 모델을 탓하기 전에, 실제 전화번호로, 붐비는 시간대에, 테스트 전화를 걸어 보세요.
Cartesia 측에서는 Sonic이 8kHz의 mu-law나 A-law 원시 데이터를 직접 반환하므로("encoding": "pcm_mulaw", "sample_rate": 8000) 전화망 오디오에 추가 변환 홉이 필요 없고, Ink는 스트리밍 음성 인식에서 같은 포맷을 받습니다. Managed Agents는 Cartesia 번호, Twilio 또는 자체 SIP 트렁크로 통화에 응답하고 전화 구간을 대신 운영해 줍니다. 에이전트 통화는 분당 $0.03이며, 분당 $0.014의 전화 추가 요금은 Cartesia 제공 번호에만 적용됩니다. 배포 리전은 미국, EU, 영국, 인도, 호주에 있어 네트워크 경로를 짧게 유지합니다. SIP 트렁크는 SRTP 미디어와 함께 TLS로 연결되며, 설정은 SIP 트렁킹 가이드에서 다룹니다.
그래도 지터가 멀쩡한데 에이전트가 계속 로봇처럼 들린다면, 그때는 모델 탓을 해도 된다고 저희가 허락해 드립니다.