빠르다는 건 무엇이 빠른 것인가
흔히 네트워크 속도를 대역폭으로만 이야기하지만, 사용자가 체감하는 빠르기를 가르는 것은 지연(Latency)인 경우가 많습니다. 대역폭이 한 번에 얼마나 많은 데이터를 보낼 수 있느냐의 문제라면, 지연은 데이터가 출발해서 도착하기까지 걸리는 시간의 문제입니다.
넓은 도로가 있어도 신호등에 자꾸 걸리면 목적지에 늦게 닿는 것과 같습니다. 대역폭이 아무리 커도 한 번 오가는 데 시간이 오래 걸리면 반응이 굼떠 보입니다. 특히 실시간 통신, 게임, 금융 거래처럼 즉각적인 반응이 중요한 영역에서는 대역폭보다 지연이 결정적입니다. 큰 파일을 내려받을 때는 대역폭이 중요하지만, 클릭에 대한 반응을 기다릴 때는 지연이 모든 것을 좌우합니다.
지연은 무엇으로 이뤄지나
하나의 지연 수치 안에는 성격이 다른 여러 요소가 섞여 있습니다. 어느 요소가 큰지 알아야 올바른 곳을 손볼 수 있습니다.
전파 지연
신호가 물리적 거리를 이동하는 데 걸리는 시간입니다. 신호는 빛의 속도라는 물리적 한계를 넘을 수 없으므로, 거리가 멀수록 아무리 좋은 장비를 써도 줄일 수 없는 최소 지연이 생깁니다. 서울에서 지구 반대편 서버까지의 왕복은 그 거리만으로 수백 밀리초가 걸릴 수 있습니다. 이 부분은 거리를 줄이는 것 외에는 방법이 없습니다.
전송 지연
데이터를 회선에 실어 보내는 데 걸리는 시간으로, 보내는 데이터의 크기와 회선의 대역폭에 따라 달라집니다. 같은 회선이라면 데이터가 클수록 오래 걸리고, 같은 데이터라면 대역폭이 넓을수록 빨리 실립니다. 데이터를 압축하거나 줄이는 것이 여기에 도움이 됩니다.
처리와 큐잉 지연
라우터나 스위치가 패킷을 살펴 다음 경로로 넘기는 데 드는 처리 시간, 그리고 장비가 바쁠 때 대기열에서 차례를 기다리는 큐잉 시간입니다. 트래픽이 몰릴수록 대기열이 길어져 이 부분이 커집니다. 평소에는 작지만 혼잡한 순간에 급격히 늘어나는, 변동이 큰 요소입니다.
어떻게 측정하나
최적화에 앞서 지연을 정확히 재는 것이 먼저입니다. 어디서 얼마나 지연이 생기는지 모르면 엉뚱한 곳을 손보게 됩니다.
핑과 RTT
가장 기본적인 도구는 핑으로, 목적지까지 갔다가 돌아오는 왕복 시간(RTT)을 측정합니다. 결과가 밀리초 단위로 나와 기본적인 응답성을 한눈에 가늠하게 해줍니다. 핑 값이 안정적인지 들쭉날쭉한지를 보면 연결의 품질도 짐작할 수 있습니다.
경로 추적
트레이스라우트 같은 도구는 패킷이 목적지까지 거쳐가는 각 구간의 지연을 단계별로 보여줍니다. 전체 지연이 큰 것을 확인하는 데서 그치지 않고, 그 지연이 어느 구간에서 갑자기 튀는지를 짚어낼 수 있습니다. 덕분에 문제가 내 쪽인지, 중간 경로인지, 상대 쪽인지를 좁혀갈 수 있습니다.
대역폭과 지연은 다른 문제다
두 개념을 혼동하면 엉뚱한 처방을 내리게 됩니다. 회선을 더 굵은 것으로 바꿨는데도 반응이 빨라지지 않는다면, 문제가 대역폭이 아니라 지연에 있었던 것입니다. 대역폭을 늘리는 것은 한 번에 더 많은 데이터를 보내게 해줄 뿐, 한 번 오가는 데 걸리는 시간을 줄여주지는 않습니다.
반대로 작은 데이터를 자주 주고받는 상황에서는 대역폭이 남아돌아도 지연 때문에 느리게 느껴집니다. 그래서 무엇을 개선해야 할지 판단하려면 먼저 내 서비스가 대역폭에 묶여 있는지 지연에 묶여 있는지를 구분해야 합니다. 큰 파일 전송이 잦다면 대역폭을, 잦은 상호작용이 핵심이라면 지연을 우선해서 손봐야 합니다.
평균보다 흔들림이 문제일 때
지연을 이야기할 때 평균값만 보면 놓치는 것이 있습니다. 바로 지터, 즉 지연이 일정하지 않고 들쭉날쭉 흔들리는 정도입니다. 평균 지연이 낮아도 어떤 패킷은 빠르고 어떤 패킷은 느리게 도착하면, 실시간 통신에서는 오히려 더 큰 문제가 됩니다.
영상 통화나 음성 통화를 떠올리면 이해하기 쉽습니다. 모든 패킷이 일정한 간격으로 도착하면 매끄럽게 재생되지만, 도착 간격이 제멋대로 흔들리면 소리가 끊기거나 영상이 멈칫거립니다. 그래서 이런 서비스는 도착한 데이터를 잠시 모아두었다가 일정한 속도로 내보내는 완충 장치를 둬서 흔들림을 흡수합니다. 다만 이 완충도 지나치면 그 자체가 지연이 되므로, 흔들림을 줄이는 것과 대기를 줄이는 것 사이에서 균형을 잡아야 합니다.
줄이기 위한 전략
지연을 낮추는 방법은 결국 세 방향으로 모입니다. 거리를 줄이거나, 왕복 횟수를 줄이거나, 혼잡을 줄이는 것입니다.
사용자와 가까이 두기
콘텐츠를 사용자 근처의 거점에 배치하는 CDN은 전파 지연을 직접 줄이는 가장 효과적인 수단입니다. 물리적 거리가 짧아지면 줄일 수 없다던 최소 지연 자체가 낮아지기 때문입니다. 멀리 있는 원본 대신 가까운 사본에서 받는 것만으로 응답이 눈에 띄게 빨라집니다.
왕복 횟수 줄이기
연결을 맺는 데 드는 왕복을 줄이는 것도 큰 효과를 냅니다. 한 번 맺은 TLS 세션을 재사용해 협상을 건너뛰거나, 연결 수립과 암호화 협상을 하나로 합쳐 처음 응답까지의 왕복을 줄이는 방식입니다. 왕복 한 번이 줄면 그 거리만큼의 시간이 통째로 절약됩니다.
경로와 혼잡 관리
트래픽을 덜 혼잡한 경로로 보내고, 한곳에 쏠리지 않도록 분산하면 큐잉 지연을 낮출 수 있습니다. 대기열이 짧아지면 기다리는 시간이 줄기 때문입니다. 또한 실시간성이 정확성보다 중요한 트래픽이라면, 확인 절차로 지연을 만드는 대신 곧장 보내는 UDP 기반 프로토콜을 택하는 것도 방법입니다. 지연과 연결 재개의 관계는 MDN Web Docs의 지연 이해 문서에서 측정과 단축 방법을 함께 다룹니다.