화상회의가 끊기는 건 속도 탓이 아닙니다

속도 측정 사이트에서는 다운로드 100Mbps가 넉넉하게 찍히는데, 회의만 시작하면 상대방 목소리가 로봇처럼 갈라지고 화면이 몇 초씩 멈춥니다. 이럴 때 가장 먼저 떠오르는 해결책은 요금제를 올리는 것입니다. 500Mbps, 1Gbps로 바꾸면 나아질 것 같습니다.

공식 문서를 열어 보면 이 해결책이 대부분 헛돈이라는 것을 알 수 있습니다. 화상회의 서비스가 요구하는 대역폭은 생각보다 훨씬 작고, 정작 문제를 일으키는 지표는 속도 측정 결과 화면에서 눈에 잘 띄지 않는 자리에 있습니다.

화상회의가 실제로 요구하는 속도

세 서비스가 공개한 요구치를 나란히 놓으면 이렇습니다. 단위는 Mbps(초당 메가비트)이고, 업로드/다운로드 순서입니다.

서비스	1080p 영상	그룹 회의	출처
Microsoft Teams	권장 1.5 / 1.5 (1:1)	권장 2.5 / 4.0	Microsoft Learn 「Prepare your organization's network for Teams」
Zoom	3.8 / 3.0	갤러리 49명 수신 4.0	Zoom 지원 문서 시스템 요구사항
Google Meet	최대 3.6 / 3.6	송신 0.25 이상, 수신 최대 4.0	Google Workspace 관리자 도움말

가장 넉넉하게 잡아도 한 사람당 4Mbps 안팎입니다. 마이크로소프트는 아예 "HD 영상 품질을 1.5Mbps 미만으로 전달할 수 있다(can deliver HD video quality in under 1.5 Mbps)"고 적어 두었습니다. 대역폭이 모자랄 때는 영상보다 음성을 먼저 지킨다는 설계 원칙도 같은 문서에 있습니다.

계산해 보면 결론이 분명해집니다. 100Mbps 회선은 팀즈 그룹 회의 권장 수신량 4Mbps의 25배입니다. 가족 네 명이 동시에 각자 회의에 들어가도 수신 16Mbps, 송신 10Mbps면 충분합니다. 속도가 모자라서 끊긴다면 회선 자체가 이보다 훨씬 느린 경우에 한정됩니다.

속도 말고 봐야 할 지표 세 가지

마이크로소프트의 교육 문서는 이렇게 정리합니다. 대역폭이 높아도 지연과 패킷 손실이 나쁘면 통화와 회의 같은 실시간 통신의 품질은 떨어진다는 것입니다(Even if you have a high bandwidth, bad latency and packet loss result in a degraded experience). 그 지표들을 한 줄씩 풀면 이렇습니다.

지연(latency) 은 데이터 조각(패킷)이 출발지에서 도착지까지 가는 데 걸리는 시간입니다. 왕복 기준으로 잴 때는 RTT라고 부릅니다. 흔히 '핑'이라고 부르는 값이 이것입니다.
패킷 손실(packet loss) 은 보낸 패킷 가운데 도착하지 못한 비율입니다.
지터(jitter) 는 지연 시간이 패킷마다 들쭉날쭉한 정도입니다. 지연이 늘 50ms면 지터는 0에 가깝고, 10ms와 90ms를 오가면 평균이 같아도 지터가 큽니다.

지터의 정확한 정의는 실시간 음성·영상 전송 규격인 RFC 3550(2003년)에 있습니다. 송신 측에서 패킷을 보낸 간격과 수신 측에 도착한 간격의 차이 D를 구하고, 이를 다음 식으로 계속 평균 냅니다.

J(i) = J(i-1) + (|D(i-1,i)| - J(i-1)) / 16

규격은 이 값을 "패킷 간격 차이 D의 평균 편차(the mean deviation (smoothed absolute value) of the difference D in packet spacing)"라고 정의하고, 서로 다른 장비의 보고를 비교할 수 있도록 반드시 이 식을 따르라고(MUST conform) 적어 둡니다. 16으로 나누는 것은 순간적인 튐 하나에 값이 크게 흔들리지 않게 하려는 장치입니다.

참고로 마이크로소프트 교육 문서는 지터를 "패킷이 잘못된 순서로 도착하는 것"이라고 풀어 쓰는데, 같은 표에 '패킷 순서 뒤바뀜(packet reorder)'이 별도 항목으로 있습니다. 둘은 다른 지표이고, 정의는 RFC 3550 쪽을 따르는 것이 정확합니다.

지터가 음성을 깨는 방식

화상회의 앱은 지터에 대비해 지터 버퍼를 둡니다. 도착한 패킷을 잠깐 모아 두었다가 일정한 간격으로 재생하는 대기열입니다. 마이크로소프트의 옛 스카이프 포 비즈니스 문서(2017년 작성, 현재는 보관 문서)가 이 원리를 잘 설명합니다. 대부분의 VoIP 소프트웨어는 버퍼링으로 어느 정도의 지터를 흡수할 수 있고, 지터가 버퍼를 넘어설 때만 참가자가 그 영향을 느낀다는 것입니다. 그리고 한 줄을 덧붙입니다. "지터를 위한 버퍼링은 종단 간 지연을 늘린다(Buffering for jitter will increase end-to-end latency)."

여기서 문제가 두 방향으로 갈립니다. 버퍼를 넘는 지터가 오면 늦게 온 패킷은 버려져 손실과 같은 결과가 되고, 목소리가 뚝뚝 끊깁니다. 버퍼를 키우면 끊김은 줄지만 대화가 반 박자씩 늦어져 서로 말이 겹칩니다. 패킷 손실도 같은 문서의 표현대로 개별 손실은 거의 티가 나지 않지만, 연달아 몰려서 생기는 손실(burst loss)은 음성을 완전히 끊어 버립니다.

팀즈 문서가 "소리가 지지직거리고 끊기거나 로봇처럼 들리면 지터나 패킷 손실일 수 있다(could be jitter or packet loss)"고 따로 적어 둔 이유가 이것입니다. 대역폭 부족은 같은 문서에서 '팀즈가 느리게 동작하는' 증상으로 따로 분류됩니다.

공식 기준표가 알려 주는 문제의 위치

마이크로소프트는 팀즈 품질 기준을 두 구간으로 나눠 제시합니다. 하나는 회사(또는 집) 네트워크의 출구에서 마이크로소프트 네트워크까지, 곧 통신사 회선만 잰 값이고, 다른 하나는 사용자 기기에서 출발해 와이파이와 공유기를 거쳐 마이크로소프트까지 가는 전체 경로입니다.

지표	통신사 회선 구간	기기부터 전체 경로
왕복 지연(RTT)	60ms 미만	100ms 미만
패킷 손실	15초 구간 0.1% 미만	15초 구간 1% 미만
지터	15초 구간 15ms 미만	15초 구간 30ms 미만
몰린 손실(burst)	200ms 구간 1% 미만	200ms 구간 10% 미만

(출처: Microsoft Learn 교육 과정 「Understand Teams network requirements」, 2026년 9월 갱신)

두 열의 차이를 보면 마이크로소프트가 문제를 어디서 예상하는지가 드러납니다. 기기에서 집 출구까지, 즉 와이파이와 공유기 몇 미터 구간에 지터 허용치의 절반(15ms)을 따로 배정했고, 패킷 손실은 통신사 구간보다 10배를 더 허용했습니다. 수십 킬로미터 떨어진 데이터센터까지 가는 길보다 방 안의 무선 구간이 더 험하다고 보는 셈입니다.

그래서 요금제를 올리는 것이 대개 효과가 없습니다. 바뀌는 것은 표의 왼쪽 열인데, 문제는 오른쪽 열에서 생기고 있기 때문입니다.

집 안에서 지터를 만드는 두 가지 원인

첫째는 와이파이입니다. 팀즈 문서는 와이파이가 VPN과 마찬가지로 "실시간 미디어를 위해 설계되거나 구성된 것이 아니다"라고 적고, 구체적인 지점을 짚습니다. 2.4GHz 대역은 다른 가전 기기들의 간섭을 자주 받으며, 5GHz가 실시간 미디어에 더 적합하고, 인접한 공유기(액세스 포인트)끼리 같은 채널을 쓰면 신호가 겹쳐 서로 경쟁한다는 것입니다. 아파트처럼 이웃 공유기가 수십 개 잡히는 환경에서 2.4GHz로 회의를 하고 있다면 가장 먼저 의심할 곳입니다. 채널과 대역을 바꾸는 방법은 와이파이 속도 개선 방법에 정리해 두었습니다.

둘째는 버퍼블로트(bufferbloat)입니다. Bufferbloat 프로젝트는 이를 "공유기나 다른 네트워크 장비가 너무 많은 데이터를 버퍼에 쌓아서 생기는 원치 않는 지연"으로 정의합니다. 장비 설계자들이 패킷 손실을 무슨 수를 써서라도 피하려고 버퍼를 키운 결과, 회선이 꽉 차는 순간 패킷들이 긴 줄을 서게 되고 그 줄의 길이만큼 지연이 늘어납니다.

전형적인 장면은 이렇습니다. 같은 집에서 누군가 클라우드에 사진을 백업하거나 큰 파일을 올리는 순간, 업로드 회선이 꽉 차고 공유기 대기열이 길어집니다. 화상회의 패킷도 그 줄 뒤에 서야 하므로 지연이 수십에서 수백 ms씩 출렁입니다. 평소 속도 측정에서는 아무 문제가 없다가 '누가 뭘 하고 있을 때만' 회의가 끊기는 이유가 여기에 있습니다.

진단은 이 순서로 합니다

회의 앱의 통계 화면부터 봅니다. 팀즈는 통화 중 '통화 상태(Call health)' 패널에서 수신 지터, 수신 패킷 손실, 왕복 시간을 보여 주고, 마이크로소프트 지원 문서는 음성 기준으로 지터 30ms 미만, 패킷 손실 2% 미만, 왕복 시간 200ms 미만을 기준값으로 제시합니다. 줌도 설정의 통계 메뉴에서 지연·지터·패킷 손실을 보여 줍니다. 끊기는 순간에 이 숫자가 튀는지가 첫 단서입니다.
유선으로 바꿔 같은 회의를 해 봅니다. 랜선 하나로 증상이 사라지면 원인은 와이파이 구간입니다. 위 기준표의 오른쪽 열이 왼쪽 열에 가까워지는 것입니다.
부하가 걸린 상태의 지연을 잽니다. 클라우드플레어 속도 측정(speed.cloudflare.com)은 다운로드·업로드 중의 지연(loaded latency)과 지터를 따로 보여 줍니다. 클라우드플레어는 이 항목을 두고 "연결을 실제로 사용하고 있을 때 어떻게 동작하는지 보여 주려고" 잰다고 설명합니다. 평소 지연과 업로드 중 지연의 차이가 크게 벌어진다면 버퍼블로트입니다.
VPN을 끄고 비교합니다. 마이크로소프트와 구글은 모두 VPN이 지연을 더하고 회의 품질을 떨어뜨린다고 적고, 마이크로소프트는 회의 트래픽만 VPN을 우회시키는 분할 터널(split tunnel)을 권장합니다. 회사 VPN을 켠 채 집에서 회의한다면 이 단계에서 원인이 드러나는 경우가 많습니다.
공유기의 대기열 관리 기능을 찾아봅니다. Bufferbloat 프로젝트는 단순한 선착순 대기열 대신 fq_codel 같은 똑똑한 대기열 관리로 바꾸면 비교적 쉽게 고칠 수 있다고 설명합니다. 공유기 설정에서 SQM(Smart Queue Management)이나 대기열 관리 항목이 있는지 확인하고, 없다면 대용량 업로드를 회의 시간과 겹치지 않게 하는 것이 현실적인 대안입니다.

한 가지 주의할 점이 있습니다. 마이크로소프트는 핑(ICMP) 명령으로 잰 값만으로 네트워크 품질을 판단하는 것은 효과적이지 않다고 밝혀 왔습니다. 핑이 낮게 나와도 실제 회의 패킷은 다른 경로와 우선순위로 처리될 수 있으므로, 회의 앱 자체의 통계가 가장 믿을 만한 근거입니다.

속도 측정 결과를 다시 읽는 법

속도 측정 화면에서 큰 글씨로 나오는 다운로드 숫자는 회선이 한 번에 실어 나를 수 있는 양입니다. 화상회의는 그 양의 몇 퍼센트만 쓰고, 대신 패킷이 일정한 간격으로 빠짐없이 도착하기를 요구합니다. 고속도로가 넓은 것과 버스가 정시에 도착하는 것은 다른 문제인 것과 같습니다.

그래서 진단의 출발점은 '몇 Mbps냐'가 아니라 '언제, 어느 구간에서 흔들리느냐'입니다. 유선에서도 끊기고 부하 여부와 상관없이 수치가 나쁘다면 그때 비로소 통신사에 회선 점검을 요청할 근거가 생깁니다. 공유기에 모르는 기기가 붙어 대역을 쓰고 있는지 의심된다면 공유기 연결 기기 확인 방법을 함께 보시면 됩니다.

회의가 끊길 때, 같은 집에서 다른 누군가가 무엇을 올리고 있었는지 확인해 보신 적이 있으신가요?