레이턴시

레이턴시(latency)는 요청을 보내고 응답이 돌아오기까지 걸리는 시간이에요. 우리말로 "지연 시간"이라고 해요. 택배로 치면 트럭 크기가 아니라 배송 거리에 따라 늘어나는 도착 시간이에요.

2026년 10월 29일 밤, 서울 KT 회선 PC 에서 직접 잰 값이에요. 재는 방법은 아래에 있어요.

레이턴시는 왜 생기나요?

가장 큰 이유는 거리예요. 데이터는 빛 신호로 광섬유를 타고 가요. 광섬유 안에서 빛은 1ms 에 200km 정도 가요.

서울에서 미국 동부까지는 직선으로 약 1만 1천 km 예요. 왕복이면 2만 2천 km 라서 빛만 따져도 110ms 가 넘어요. 실제 케이블은 바다와 대륙을 돌아가서 더 길어요.

거리 말고도 시간이 붙어요. 중간에 지나는 장비(라우터)마다 조금씩 머물러요. 길이 붐비면 줄을 서요. 서버가 답을 만드는 시간도 더해져요.

핑·대역폭과 뭐가 달라요?

셋은 자주 섞여 쓰여요. 아래 표처럼 나눠 보면 덜 헷갈려요.

차선이 아무리 많아도 부산까지 가는 시간은 줄지 않아요. 그래서 인터넷 요금제를 올려도 해외 서버 반응은 그대로일 수 있어요.

몇 ms 면 빠른 건가요?

정해진 기준은 없어요. 아래는 이번에 서울에서 잰 값으로 만든 어림 기준이에요.

웹페이지 한 장을 열 때 왕복은 한 번이 아니에요. 연결 맺기, 암호화(HTTPS) 약속, 실제 요청에 각각 왕복을 써요. 이미지·스크립트 파일이 많으면 더 늘어요.

서울에서 8곳을 직접 재 봤어요

2026년 10월 29일 22시 50분부터 55분까지 쟀어요. 장소는 서울, 회선은 KT, 컴퓨터는 Windows 11 PC 예요. 도구는 curl 8.17.0 이고 대상마다 7번 재서 가운데 값을 골랐어요.

잰 값은 "TCP 연결 시간"이에요. 서버와 연결을 맺는 데 왕복 한 번이 들어서 레이턴시에 가까워요. 주소를 찾는 DNS 시간은 뺐어요.

DNS 조회 시간은 뺐어요(time_connect − time_namelookup). 같은 날 다른 시각에 재면 몇 ms 씩 달라질 수 있어요.

표로 보기 (7회 값 범위·첫 바이트·ping)

대상	연결 가운데 값(ms)	7회 범위(ms)	첫 바이트 가운데 값(ms)	ping(ms)
futureinfra.ai (국내 IDC)	4.2	3.8~11.7	33.7	2
naver.com	4.7	3.3~30.5	182.8	응답 없음
AWS 서울	6.3	5.8~7.4	39.7	응답 없음
AWS 도쿄	36.4	36~40.4	125.9	응답 없음
AWS 싱가포르	70.6	69.2~74.8	227.2	응답 없음
AWS 미국 서부 (오리건)	147.4	134.4~157	454.3	응답 없음
AWS 미국 동부 (버지니아)	195.1	187.4~203.2	605.8	응답 없음
AWS 유럽 (프랑크푸르트)	273.3	267.8~285.8	829.7	응답 없음

눈에 띄는 점이 두 가지 있어요.

• 국내 대상은 모두 4~7ms 였어요. 도쿄는 그 9배쯤, 미국 동부는 46배쯤이었어요.
• 첫 바이트가 오기까지(TTFB)는 연결 시간의 약 3배였어요. 미국 동부는 연결 195ms, 첫 바이트 606ms 였어요. HTTPS 가 왕복을 여러 번 쓰기 때문이에요.

ping 명령은 futureinfra.ai 만 답했어요(2ms). 네이버와 AWS 주소는 ping 에 답하지 않게 막아 둬서 curl 로 통일했어요.

내 사이트는 어떻게 재요?

Windows 명령 프롬프트, Mac·리눅스 터미널에서 똑같이 돼요. 이번에 쓴 명령 그대로예요.

curl -o /dev/null -s -w "%{time_namelookup} %{time_connect} %{time_starttransfer}\n" https://내사이트주소/
ping 내사이트주소

Windows 명령 프롬프트에서는 /dev/null 대신 NUL 을 써요. 결과는 초 단위예요. 두 번째 값에서 첫 번째 값을 빼면 연결 왕복 시간이에요. 세 번째 값이 첫 바이트까지 걸린 시간이에요.

브라우저로도 볼 수 있어요. 크롬에서 F12 를 누르고 네트워크 탭에서 문서를 고르면 "서버 응답 대기" 시간이 나와요.

자주 하는 오해

• "인터넷 속도가 빠르면 레이턴시도 낮다" — 아니에요. 속도는 대역폭 이야기예요. 거리는 요금제로 줄지 않아요.
• "ping 이 안 오면 서버가 죽었다" — 꼭 그렇지 않아요. 이번에도 네이버·AWS 는 ping 에 답하지 않았지만 웹은 잘 열렸어요.
• "한 번 재면 끝" — 값은 시각마다 흔들려요. 이번에도 네이버 연결이 한 번은 30ms 로 튀었어요. 여러 번 재서 가운데 값을 보세요.

레이턴시는 어떻게 줄여요?

• 방문자와 가까운 곳에 서버를 둬요. 손님이 대부분 국내라면 국내 서버가 가장 쉬운 방법이에요.
• 파일 수를 줄여요. 왕복 횟수가 줄어요. 이미지를 합치거나 꼭 필요한 스크립트만 남겨요.
• CDN 을 써요. 자주 쓰는 파일을 여러 곳에 미리 두고 가까운 곳에서 내주는 방식이에요.

퓨쳐인프라에서는

퓨쳐인프라 가상서버는 국내 자체 IDC 에서 돌아가요. 이번 측정에서 서울 PC 와 futureinfra.ai 사이 연결은 4.2ms 였어요. 국내 손님이 많은 쇼핑몰·예약 사이트라면 이 거리가 그대로 반응 속도가 돼요.

서버를 만들면 약 40초 만에 주소와 HTTPS 가 같이 준비돼요. 이미지 같은 정적 파일은 CDN 으로 내보낼 수 있어요. CDN 은 내보낸 양 GB당 95원이에요. 요금은 요금표에 다 나와 있어요.

자주 묻는 질문

레이턴시와 핑은 같은 말인가요?

거의 같은 뜻으로 써요. 엄밀히는 핑은 재는 명령이고, 레이턴시는 잰 시간이에요. 게임 화면의 '핑 30' 은 왕복 30ms 라는 뜻이에요.

웹사이트는 몇 ms 면 괜찮아요?

정답은 없어요. 이번 실측에서 국내는 4~7ms, 도쿄는 36ms 였어요. 100ms 를 넘으면 페이지마다 왕복이 쌓여 기다림이 느껴지기 시작해요.

TTFB 는 뭐예요?

첫 바이트가 도착하기까지 걸린 시간이에요. 연결·암호화·서버 처리 시간이 다 들어 있어요. 이번 측정에서는 연결 시간의 약 3배였어요.

해외 서버를 써도 되나요?

손님이 해외에 있으면 그쪽이 나아요. 손님이 국내라면 해외 서버는 왕복마다 수십~수백 ms 가 붙어요.

관련 용어

• 대역폭 — 한 번에 보낼 수 있는 양이에요. 레이턴시와 자주 헷갈려요.
• 트래픽 — 주고받은 데이터의 총량이에요.
• CDN — 파일을 가까운 곳에서 내주는 방식이에요.
• IDC · 데이터센터 — 서버가 실제로 놓인 곳이에요.