필드 노트 · RESPONSIVENESS
속도 측정은 거짓말을 한다.
대신 responsiveness를 측정하라.
500 Mbps를 결제하셨는데도 통화는 여전히 끊깁니다. 모든 속도 측정 사이트가 보여주는 숫자가 왜 잘못된 숫자인지, 그리고 진짜 숫자를 측정하기 위해 Apple이 macOS 안에 무엇을 넣었는지 이야기합니다.
Insights 안의 Network Quality 패널.
큰 숫자라는 거짓말
모든 속도 측정 사이트는 게이지로 시작합니다. 바늘이 돌고, 인상적인 숫자(다운로드 480, 510, 광이라면 940)에 멈추고, 그 숫자가 이야기가 됩니다. 그 이야기는 거의 항상 틀렸습니다. 부정직해서가 아니라, 잘못된 질문에 정확하게 답한 것뿐입니다.
처리량은 용량의 측정입니다. 다른 일이 아무것도 일어나지 않을 때, 파이프가 옮길 수 있는 물의 양. 문제는 실제 네트워크가 거의 절대로 "다른 일이 아무것도 일어나지 않는" 모양이 아니라는 점입니다. 실제 네트워크는 가족 화상 통화, 클라우드 백업, Slack 동기화, 소프트웨어 업데이트, 그리고 만화를 보는 아이가 동시에 펼쳐지는 풍경입니다. 그 장면에서 중요한 것은 분당 총 갈론이 아닙니다. 당신의 음성 패킷이 줄을 끊고 들어가 제때 도착할 수 있느냐는 것입니다.
이 두 번째 질문이 responsiveness입니다. 20년 동안 우리는 브라우저에서 이것을 측정할 방법이 거의 없었습니다. 이제 있습니다. macOS 안에 내장되어 있습니다. 단지 아무도 말해주지 않았을 뿐입니다.
bufferbloat을 한 단락으로
당신의 노트북과 인터넷 사이의 모든 라우터와 모뎀에는 버퍼가 있습니다. 패킷이 차례를 기다리는 작은 메모리 공간입니다. 버퍼 앞쪽 링크가 뒤쪽 링크보다 느리면(가령, 기가비트 LAN 뒤에 있는 40 Mbps 업링크), 버퍼가 차오르기 시작합니다. 제조사들은 이 버퍼를 터무니없이 크게 만들었습니다. 패킷 손실은 버그처럼 보이기 때문입니다. 그러나 너무 큰 버퍼는 1밀리초 먼저 도착한 모든 다른 패킷 뒤에 당신의 Zoom 음성 패킷을 잡아둡니다. 파이프는 충분히 많은 바이트를 옮기고 있습니다. 단지 중요한 바이트가 줄을 서고 있을 뿐입니다. 부하 시 수백 밀리초로 측정되는 그 지연이 bufferbloat입니다. 속도 테스트는 통과하고 통화는 무너지는 이유입니다.
RPM 등장: Round-trips Per Minute
2021년, Apple의 네트워킹 팀은 평이한 지표를 제안했습니다. RPM, 분당 왕복 횟수입니다. 발상은 거의 부끄러울 정도로 단순합니다. 파이프가 포화 상태일 때(당신이 다운로드와 업로드를 동시에 풀 스피드로 돌리는 동안), 1분 동안 완료할 수 있는 완전한 요청/응답 왕복의 수를 셉니다. 응답성이 좋은 네트워크는 수천 회를 해냅니다. bloated된 네트워크는 수백 회로 떨어집니다. 같은 500-Mbps 파이프인데도 그렇습니다.
Apple은 macOS Monterey에서 그 도구를 출시했습니다. 이름은 networkQuality이고 위치는 /usr/bin/networkQuality입니다. 터미널을 열고 실행하면 다음과 같은 출력을 보게 됩니다:
$ networkQuality
==== SUMMARY ====
Uplink capacity: 38.412 Mbps
Downlink capacity: 476.185 Mbps
Responsiveness: Medium (540 RPM)
Idle Latency: 18 ms이 출력을 주의 깊게 읽어보세요. 파이프는 굵습니다. 다운로드 거의 절반 기가비트. 응답성은 medium. 분당 540 왕복은 초당 약 9회: 부하가 걸린 네트워크에서 당신의 음성 패킷은 약 111ms를 기다리고, 유휴 시에는 18ms입니다. 이 차이가, 집에 아무도 없을 때는 통화가 깔끔하게 들리고, 온 가족이 스트리밍 중일 때는 망가지는 정확한 이유입니다.
High, Medium, Low, 무슨 뜻일까
Apple은 RPM을 사람이 읽기 쉬운 세 카테고리로 묶습니다:
- High, 2,000 RPM 이상. 네트워크가 응답성이 좋습니다. 통화, 게임, 협업 편집 같은 실시간 작업이 다른 무엇이 돌고 있더라도 또렷하게 느껴집니다.
- Medium, 약 600–2,000 RPM. 네트워크는 쓸 만하지만, 부하 아래에서 인터랙티브 앱은 굼뜨게 느껴집니다. 대다수 가정 네트워크가 프라임 타임에 머무는 곳이며, 불만의 진원지입니다.
- Low, 600 RPM 미만. 버퍼가 가득 찼습니다. 음성 통화는 끊기고, 영상은 멈추며, SSH 세션의 키 입력은 묶여서 도착합니다. 버퍼가 비워지기 전까지는 아무리 많은 추가 대역폭도 이를 고치지 못합니다.
왜 속도 테스트는 이걸 보지 못하나
속도 테스트는 문제의 쉬운 절반만 측정합니다. idle throughput(유휴 처리량), 보통 짧은 버스트로, 보통 ISP가 우선 처리하도록 학습한 연결 위에서. 가벼운 부하일 때 파이프가 무엇을 할 수 있는지 알려주지만, 부하 시의 지연이라는 후속 질문은 결코 던지지 않습니다. Bufferbloat은 정의상 이 테스트에는 보이지 않습니다. 테스트 자체가 부하이며, 뒤에 줄을 설 다른 트래픽이 없기 때문입니다.
소비자 쪽 증상은 익숙합니다. ISP 기사가 와서 속도 테스트를 돌립니다. 통과합니다. 그리고 연결에는 문제가 없다고 말합니다. 다음 화상 통화는 여전히 끊깁니다. 기사는 거짓말한 것이 아닙니다. 단지 잘못된 것을 측정했을 뿐입니다.
실제로 RPM 테스트를 돌리면
Apple의 networkQuality는 우아하면서도 가차 없습니다. CDN 엔드포인트에 여러 병렬 연결을 열고, 양방향으로 포화시키고, 그 포화가 일어나는 동안 작은 HTTP/2 요청과 응답 한 쌍이 얼마나 빨리 완료되는지 시간을 잽니다. 그것이 RPM 값입니다. 용량 측정값은 덤으로 따라오기 때문에, 도구는 한 번 실행으로 세 숫자를 모두 보고합니다.
테스트는 약 15초 정도 걸립니다. 회선을 두드리기 때문에 통화 중에는 실행하지 마세요. 또한 ISP가 보여주고 싶지 않은 것들을 드러냅니다. 이웃과 간섭하는 Wi-Fi 채널, 큐 깊이를 두 배로 만드는 펌웨어 버그가 있는 라우터, 모든 왕복에 200ms 지연을 더하는 VPN. 매우 자주, 약한 고리는 ISP가 아니라 당신의 집 안에 있다는 사실을 발견하게 됩니다.
RPM이 Low일 때 무엇을 해야 하나
만능 해결책은 없지만, 체크리스트는 유한합니다:
- 먼저 유선으로 시험하라. Mac에 이더넷 케이블을 연결하고
networkQuality를 다시 실행하세요. RPM이 High로 점프하면, 문제는 Wi-Fi(혼잡, 채널 겹침, 또는 거리)이지 ISP가 아닙니다. - Smart Queue Management를 켜라. SQM, CAKE, fq_codel을 지원하는 라우터는 bufferbloat을 극적으로 평탄화합니다. fq_codel이 켜진 100달러 라우터가 그것이 꺼진 600달러 라우터를 이깁니다.
- 업로드를 제한하라. SQM을 쓸 수 없다면, Mac의 업로드를 측정한 업링크 용량의 약 90%로 조절하세요. 이 한 가지 변경만으로도 자신의 업로드가 버퍼를 채우고 다운로드의 응답 ACK를 굶기는 일을 막을 수 있습니다.
- ISP의 모뎀-라우터 결합기를 교체하라. 많은 ISP 지급 장비는 처리량 벤치마크용이지, 응답성용이 아닙니다. ISP 장비를 브리지 모드로 두고 자신의 라우터를 그 앞에 두는 것은, 대부분의 사람들이 보게 될 가장 큰 단일 RPM 향상입니다.
꺾이지 않는 세 가지 신화
"대역폭을 늘리면 해결된다." 가끔은 그렇지만, 대체로 아닙니다. 업링크가 단일 백업으로 이미 포화 상태라면, 40에서 100 Mbps 업로 업그레이드하는 것이 도움이 됩니다. 그러나 진짜 범인이 버퍼라면, 같은 천장에 두 배 빨리 부딪히게 되고 증상은 돌아옵니다. 해결책은 줄을 비우는 것이지, 그 앞의 파이프를 더 굵게 만드는 것이 아닙니다.
"내 ping이 12ms이니까 괜찮다." Ping은 유휴 지연을 측정합니다. 길에 아무것도 없을 때 패킷 하나가 얼마나 걸리는가. Bufferbloat은 부하 아래에서만 모습을 드러냅니다. bloated된 링크에서의 12ms 유휴 ping은 부하 시 350ms로 변하기 일쑤입니다. 한 터미널에서 ping을 돌리고 다른 터미널에서 큰 업로드를 돌리면 실시간으로 일어나는 것을 볼 수 있습니다.
"ISP가 이미 이걸 위해 최적화했다." 그런 곳도 있습니다. 그렇지 않은 곳도 많습니다. 엔지니어링은 어렵지 않지만, 상업적 인센티브는 반대 방향을 가리킵니다. 속도 테스트용으로 튜닝된 네트워크가 처리량 게이지로 쇼핑하는 시장에서 이깁니다. 응답성은 마케팅 페이지에 거의 등장하지 않습니다.
WiFi & IP Info가 들어맞는 자리
우리는 networkQuality 엔진을 메뉴 바에서 한 번의 클릭 거리로 두었습니다. Pro 등급의 Network Quality 패널은 동일한 Apple 테스트를 실행하고, 업링크/다운링크 용량을 표면에 드러내며, RPM 버킷과 베이스 RTT 기준선을 보고하고, 그리고 결정적으로 로그를 남깁니다. 일주일 동안 매시간 "다시 실행"을 눌러 패턴을 볼 수 있습니다. 토요일 아침은 High, 저녁식사 시간에는 Medium, 아이들이 학교에서 돌아오면 Low. 이 그래프가 ISP가 실제로 무엇을 하게 만드는 그래프입니다. 재현성이 불만을 티켓으로 바꿔주기 때문입니다.
앱의 Latency History 그래프 및 Connection Log와 결합하면, 30초면 쓸 수 있는 다음과 같은 티켓을 통신사에 보낼 수 있습니다. "현지 시간 18:00에서 21:00 사이 RPM이 2,400에서 410으로 떨어지며, 귀하의 게이트웨이까지 중앙값 RTT가 3배 높아진 것과 상관관계. CSV 첨부." 이는 "인터넷이 느려요"와는 완전히 다른 대화입니다.
짧은 버전
당신의 속도 테스트는 용량을 측정합니다. 용량은 실재하며, 가끔은 그것이 문제입니다. 그러나 대부분의 경우 문제는 responsiveness입니다. 파이프가 바쁜 동안 당신의 트래픽이 신속하게 들어왔다 나갈 수 있는가. RPM이 그것을 측정하는 지표입니다. Apple은 그것을 측정하기 위해 일급 도구를 만들었습니다. 우리는 그 도구를 당신의 메뉴 바에 두었고, 히스토리를 유지합니다.
이 페이지에서 단 한 문장만 기억해야 한다면, 이 문장으로 하세요. 대역폭은 길이 얼마나 넓은가이고, responsiveness는 신호등에서 얼마나 기다리는가다. 둘 다 중요합니다. 그러나 그중 하나만이 당신의 속도 테스트 페이지에 있습니다.