인터넷 속도는 빠른데 게임은 렉? 속도 측정이 재지 않은 구간

속도 측정을 돌렸더니 수백 Mbps가 나왔는데도 게임은 여전히 고무줄처럼 튑니다. 그 결과는 애초에 게임에 대한 증거가 아니었습니다. 다른 값을, 다른 경로로, 다른 서버에 대고 잰 것이니까요. 여기서는 게임이 실제로 반응하는 것이 무엇인지, 그리고 방금 본 그 숫자를 무엇으로 대체해야 하는지 정리합니다.

먼저 내 경우를 찾기

속도 측정은 게임이 묻지 않는 질문에 답한다

Mbps는 내 회선이 1초에 얼마나 많은 데이터를 옮길 수 있는지입니다. 게임이 필요로 하는 건 작은 패킷 하나가 갔다가 돌아오는 데 걸리는 시간이고, 단위는 밀리초입니다. 단위가 다른 건 애초에 서로 다른 문제이기 때문입니다.

다운로드는 관을 채우는 일입니다. 관이 굵을수록 큰 파일이 빨리 끝납니다. 반면 대전은 초당 수십 번 작은 패킷을 가늘게 흘려보내고, 그 하나하나가 전부 급합니다. 관을 굵게 만든다고 패킷이 더 일찍 도착하지는 않습니다. 도로에 차선을 더한다고 길이 짧아지지 않는 것과 같습니다. 그래서 500Mbps로 측정되는 회선이 여전히 내가 쏜 총알을 늦게 전달할 수 있습니다. 문제였던 건 애초에 대역폭이 아니었으니까요.

속도 측정은 가장 가까운 서버를 골랐고, 게임은 그러지 않는다

여기가 가장 많은 사람이 걸려 넘어지는 지점이고, 운이 나빠서가 아니라 구조적인 문제입니다.

속도 측정은 서버를 대신 골라 주는데, 기준은 가까움입니다. 보통 가장 가까운 한 대이고, 내가 쓰는 통신사 망 안에 있는 경우도 흔합니다. 회선의 대역폭을 재는 설계로는 그게 맞지만, 그 말은 측정이 내가 사는 도시와 통신사를 한 번도 벗어나지 않고 끝났다는 뜻이기도 합니다.

게임 서버는 그렇게 고르지 않습니다. 고정된 지역에 있고, 내 패킷은 나와 그 지역 사이에 놓인 모든 중계와 상호접속을 통과해야 합니다. 그래서 플레이가 가능한지를 결정하는 구간, 즉 지역 간 중계, 혼잡한 상호접속 지점, 통신사가 멀리 돌려놓은 경로가 바로 속도 측정이 한 번도 건드리지 않은 구간입니다. 깨끗한 점수는 첫 구간이 건강하다는 뜻일 뿐이고, 렉은 대개 그 뒤에 삽니다.

이걸 보려면 여러 지역을 동시에 측정해서 결과를 나란히 놓아야 합니다. 숫자 하나만 있으면 비교할 대상이 없지만, 여덟 개가 놓이면 내 경로의 모양이 곧바로 드러납니다.

평균이 가리는 건, 정확히 한 판을 날리는 두 가지

속도 측정은 몇 초간의 대량 전송 평균을 보고합니다. 평균은 처리량에는 맞는 도구지만 게임에는 틀린 도구입니다. 교전을 망치는 건 평균이 아니라 그 안의 한순간이기 때문입니다.

• 손실된 패킷 하나. 회선이 여유롭게 30ms를 평균하고 있으면서도, 내가 쏜 총알을 실은 패킷을 잃어버릴 수 있습니다. 게임 안에서는 고무줄, 입력 누락, 한 박자 늦게 들어오는 판정으로 나타납니다.
• 한 번의 튐. 30ms로 있다가 아주 짧은 순간 150ms로 뛰는 쪽이, 내내 60ms인 것보다 더 불쾌합니다. 게임은 일정한 타이밍을 전제로 만들어졌는데, 평균은 그 들쭉날쭉함을 보이지 않는 곳으로 밀어냅니다.

한 번짜리 측정끼리 서로 어긋나는 이유도 여기에 있고, 여기서의 측정이 그런 순간을 뭉개는 대신 잡아내도록 설계된 이유이기도 합니다. 각 지역마다 먼저 버릴 워밍업 패킷 3개를 보낸 뒤, 50ms 고정 간격으로 20개를 한 회차로 보냅니다. 간격을 고정하는 건, 응답을 기다렸다가 다음을 보내는 방식으로는 대기열이 거의 차지 않아 패킷 손실을 체계적으로 과소 보고하기 때문입니다. 패킷이 하나라도 손실되거나 왕복 시간이 크게 출렁이면 그 지역은 자동으로 2회차를 더 측정하고, 총 60개 표본으로 평가합니다. 패킷 20개로는 손실을 5% 단위로만 구분할 수 있지만, 60개면 그 단위가 1.67%까지 내려갑니다. 이것이 판단과 추측의 차이입니다.

빠른 회선도 가득 차면 줄을 선다

여기서는 큰 대역폭이 오히려 불리하게 작용하기도 합니다. 업로드나 클라우드 백업, 같이 사는 사람의 스트리밍이 업링크를 채우면 내 게임 패킷은 그 트래픽 뒤의 대기열에서 기다립니다. 장비의 버퍼가 클수록 기다리는 시간도 길어집니다. 핑은 올라가고, 때로는 많이 올라가는데, 나중에 한가한 회선에서 돌린 속도 측정은 완벽해 보이는 결과를 돌려줍니다. 집에서 렉이 난다고 했는데 한 시간 뒤에는 아무도 재현하지 못하는 흔한 이유입니다.

2분이면 결론이 납니다. 회선이 한가할 때 한 지역을 측정하고, 그다음 큰 파일 업로드를 시작한 뒤 같은 지역을 다시 측정하세요. 부하 상태에서 지연 시간과 패킷 손실이 뛴다면 고쳐야 할 건 공유기의 대기열 관리나 무거운 트래픽의 시간대 조정이지, 더 비싼 요금제가 아닙니다.

대신 무엇을 측정해야 할까

네 가지를, 이 순서대로 봅니다.

1. 하나만 재지 말고 지역을 비교하세요. 모든 지역을 한 번에 돌립니다. 전부 나쁘면 내 네트워크를 가리키고, 일부만 나쁘면 경로를 가리키며, 후자는 지역을 바꾸면 오늘 바로 해결됩니다.
2. 숫자 하나가 아니라 범위를 읽으세요. 28에서 34ms 사이에 머무는 지역과 25에서 140ms 사이를 오가는 지역은, 평균이 같더라도 전혀 다른 이야기입니다.
3. 그 옆에서 패킷 손실을 함께 읽으세요. 지연 시간이 낮아도 손실이 있으면 여전히 플레이가 나쁩니다. 아주 작은 손실도 한 번 더 볼 가치가 있고, 그래서 여기서는 패킷 하나만 손실돼도 보완 측정이 실행됩니다.
4. 실제로 게임하는 시간대에 측정하세요. 피크 시간의 혼잡이야말로 이 질문의 핵심이고, 일요일 아침에 측정한 결과로는 보이지 않습니다.

실제로 일하는 숫자는 세 개이고, 하나의 점수로 뭉치지 않고 따로 보여줍니다. 일반적인 실시간 대전이라면 중앙값 25ms 미만이 우수, 50ms 미만이 쾌적이고, 대략 90ms를 넘어가면서 경험이 나빠집니다. 경쟁 슈터는 느긋한 장르보다 더 빡빡하게 평가되며, 이 구간들은 제작사가 발표한 공식 기준이 아니라 저희의 엔지니어링 해석입니다. P10–P90 범위는 표본이 얼마나 퍼져 있는지를 보여주며, 핑이 괜찮아 보이는데도 끊기는 느낌이 드는 이유를 가장 잘 설명하는 숫자입니다. 패킷 손실은 0%여야 하고, 5% 이상이면 평가가 크게 떨어집니다.

다섯 번째 점검도 남겨둘 만합니다. 네트워크 수치가 전부 깨끗하게 나온다면 네트워크에 시간을 더 쓰지 마세요. 프레임 시간 튐, 셰이더 컴파일, 열로 성능이 떨어진 GPU, 버거워하는 게임 서비스는 모두 렉과 똑같이 느껴지는 끊김을 만듭니다. 깨끗한 여러 지역 결과는 여기서 정말 유용합니다. 어디를 더 이상 보지 않아도 되는지 알려주니까요.

그리고 나 혼자가 아니라 팀 전체가 영향을 받는다면 질문의 모양이 달라집니다. 필요한 건 가장 느린 팀원에게도 받아들일 만한 지역이지, 가장 빠른 사람에게 최적인 지역이 아닙니다. 그 논리는 5분 만에 모두에게 공평한 서버 지역 고르는 법에 정리돼 있습니다.

이 테스트가 측정하는 것

이 테스트는 여러분의 브라우저에서 8개 지역에 있는 저희 측정 노드까지의 왕복 시간을 UDP로, 브라우저 안에서, 설치할 것 없이 측정합니다. 이 숫자들은 방향을 비교하는 데 쓰세요. 내 통신사가 어느 지역으로 경로를 잘 잡아주는지, 오늘 밤 피하는 게 좋은 지역은 어디인지, 문제가 어디를 가도 따라오는지 아니면 한 방향만 가리키는지를요. 특정 한 판에 대한 최종 근거는 게임 클라이언트가 표시하는 숫자입니다. 클라이언트는 퍼블리셔 서버까지 자기만의 경로로 가기 때문입니다. 여기서 얻는 건 어느 경로에 올라탈 가치가 있는지 알려주는 비교입니다. 측정 자체에 대해서는 핑 테스트 결과는 정확할까? 도구마다 다른 이유에서 자세히 다룹니다.

게임에 대한 질문을 속도 측정에 던지는 건 그만두세요. 모든 지역을 한 번 돌리면 1분도 안 돼서 답이 눈앞에 놓입니다.

핑 테스트 시작

함께 읽기

• 게임 렉 원인 찾기: 3단계로 진짜 원인 확인하기
• 핑, 패킷 손실, 지터란? 패킷 손실 몇 %부터 문제일까
• 핑 테스트 결과는 정확할까? 도구마다 다른 이유