무언가를 클릭했을 때, 반응이 오기 전에 잠깐 멈추는 구간이 있어요. 그 멈춤에는 이름이 있고, 그것을 줄이는 일이 어떤 앱은 즉각적으로 느껴지고 어떤 앱은 답답하게 느껴지는 차이를 만들어요. 그 멈춤이 바로 레이턴시예요.
레이턴시는 무언가를 요청한 순간부터 응답이 시작되기까지의 지연 시간이에요. 얼마나 많은 데이터가 오는지, 시작된 후 얼마나 빠르게 흐르는지와는 별개예요. 오로지 기다리는 시간 자체죠. 밀리초 단위로 측정되고, 이름을 몰라도 매일 느끼고 있을 거예요. 전송 버튼을 누른 뒤의 딜레이, 페이지가 뜨기 전의 스피너, AI가 타이핑을 시작하기 전 반 박자의 침묵 — 그게 전부 레이턴시예요.
긴 정원 호스로 생각해보면 명확해져요. 수도꼭지를 틀어도 반대쪽 끝에서 물이 즉시 나오지 않잖아요. 물이 호스 길이만큼 이동하는 시간이 필요하니까요. 레이턴시는 그 이동 시간, 즉 첫 물방울이 나오기까지의 간격이에요. 호스가 얼마나 굵은지(그건 대역폭, 한 번에 얼마나 흐를 수 있는가)와는 다른 문제예요. 아무리 굵은 소방 호스도 긴 거리를 지나야 한다면 첫 물방울까지 기다려야 해요. 대역폭이 충분해도 느리게 느껴질 수 있는 이유가 여기 있어요. 둘은 전혀 다른 문제예요.
지연이 실제로 발생하는 원인을 단순하게 말하면 두 가지예요. 거리와 작업량이에요. 거리 측면에서는, 지구 반대편 서버에 보낸 요청은 가까운 곳보다 시간이 오래 걸려요. 신호는 빠르지만 순간이동은 아니니까요. 작업량 측면에서는, 응답하는 쪽에서 처리할 일이 있을 수 있어요. 예컨대 AI 모델이 답하기 전에 추론을 실행해야 하는 경우예요. 이 둘을 합한 것이 대기 시간이 돼요.
두 가지 개념이 레이턴시와 싸우기 위해 거의 전적으로 설계된 이유가 여기 있어요. CDN은 사이트 사본을 방문자 가까이에 두어 '호스'를 짧게 만들어요. 바다를 건너지 않아도 되는 거예요. 엣지는 같은 이유로 코드를 사용자 근처에서 실행해요. 둘 다 지연을 줄이기 위한 노력이에요. 레이턴시가 바로 사용자가 '이거 느리네'라고 느끼는 감각이기 때문이에요. 기술적으로 모두 정상 작동 중이어도요.
개발자가 아닌 사람이 이 개념을 알아둘 가치가 있는 이유가 있어요. 뭔가 이상할 때 정확한 말을 쓸 수 있게 해주거든요. '느리다'는 막연해요. '응답이 시작되기 전에 레이턴시가 높은 것 같다. 일단 시작되면 괜찮다'는 문제를 정확히 가리켜요. 그리고 현실적인 기대를 세울 수 있게 해줘요. 줄일 수 있는 레이턴시가 있고(더 가까이, 사전 작업을 줄이고), 줄일 수 없는 레이턴시도 있어요. 실제 추론을 수행하는 AI는 잠깐의 시간이 필요해요. 그 시간은 작업 자체이지 버그가 아니에요.
레이턴시는 첫 물방울이 나오기까지의 대기 시간이에요. 호스를 통과하는 이동 시간이지, 얼마나 많은 물이 나오는가의 문제가 아니에요. 앱이 즉각적으로 느껴지는지 아니면 생각하는 것처럼 느껴지는지를 가르는 기준이에요. 레이턴시를 줄이는 일이 '빠르게 만든다'는 말의 절반을 차지해요.