2010년, 구글의 전설적인 엔지니어 제프 딘(Jeff Dean)이 스탠퍼드 대학에서 강연을 통해 컴퓨팅 시스템의 성능을 좌우하는 몇 가지 핵심 숫자를 소개하며 큰 반향을 일으켰습니다. 이후 피터 노빅(Peter Norvig)이 이 숫자들을 인터넷에 공개하면서 '프로그래머라면 반드시 알아야 할 지연 시간 수치'로 널리 알려지게 되었습니다.
시간이 흐르면서 하드웨어와 네트워크 환경이 발전함에 따라 이 숫자들도 조금씩 변해왔습니다. Colin Scott이 만든 인터랙티브 웹 페이지를 보면 연도별로 이 수치들이 어떻게 변화했는지 한눈에 파악할 수 있습니다.
이 글은 단순히 제프 딘의 추정치만을 나열한 것이 아니라, 여러 출처에서 수집한 수치를 종합해 정리한 것입니다. 시스템을 설계하는 개발자나 아키텍트라면 이 숫자들을 활용해 시스템에 필요한 리소스 규모를 사전에 가늠할 수 있습니다.
2019년 기준 주요 작업별 지연 시간
빠른 작업부터 느린 작업 순으로 정렬했습니다. 참고로 1밀리초(ms) = 1,000마이크로초(μs) = 1,000,000나노초(ns)입니다.
| 작업 | 지연 시간 |
|---|---|
| L1 캐시 참조 | 1 나노초(ns) |
| CPU 분기 예측 실패(branch mispredict) | 3 나노초 |
| L2 캐시 참조 | 4 나노초 |
| 뮤텍스(Mutex) 잠금/해제 | 17 나노초 |
| 메인 메모리(RAM) 참조 | 100 나노초 |
| 일반 네트워크로 2,000바이트 전송 | 62 나노초 |
| 메인 메모리에서 1MB 순차 읽기 | 4 마이크로초(μs) |
| Snappy(구 Zippy)로 1KB 압축 | 2 마이크로초 |
| SSD 랜덤 읽기 | 16 마이크로초 |
| SSD에서 1MB 순차 읽기 | 62 마이크로초 |
| 같은 데이터센터 내 네트워크 왕복 | 500 마이크로초 |
| HDD에서 1MB 순차 읽기 | 947 마이크로초 |
| HDD(자기 디스크) 탐색(seek) | 3 밀리초(ms) |
이 수치를 체감하기 쉽게 비유하면, L1 캐시 참조를 '1초'라고 가정했을 때 메인 메모리 참조는 약 1분 40초, SSD 랜덤 읽기는 약 4시간 반, HDD 탐색은 무려 한 달 이상에 해당합니다. 계층 간 격차가 얼마나 큰지 실감할 수 있습니다.
TCP로 데이터를 전송하는 데 걸리는 시간
RTT(Round Trip Time, 왕복 시간)란 하나의 데이터 패킷이 송신자에서 수신자로 갔다가 다시 되돌아오는 데 걸리는 총 시간을 의미하며, 흔히 '핑(Ping) 시간'이라고 부릅니다.
다음은 데이터 손실이 없다고 가정했을 때, 전 세계 일반적인 셀룰러(이동통신) 네트워크에서 각 크기의 페이로드를 전송하는 데 필요한 시간입니다.
| 페이로드 크기 | 필요 RTT | 미국 | 인도 | 브라질 |
|---|---|---|---|---|
| 1바이트 ~ 13KB | 1 RTT | 150ms | 1,200ms | 600ms |
| 13KB ~ 39KB | 2 RTT | 300ms | 2,400ms | 1,200ms |
| 39KB ~ 91KB | 3 RTT | 450ms | 3,600ms | 1,800ms |
| 91KB ~ 195KB | 4 RTT | 600ms | 4,800ms | 2,400ms |
결국 API 응답 크기가 커질수록 전송해야 할 바이트가 늘어나고, 왕복 횟수가 많아지며, 지연 시간이 길어져 사용자 경험이 나빠집니다. 특히 네트워크 RTT가 큰 지역의 모바일 사용자를 고려한다면 응답 페이로드를 최소화하는 것이 매우 중요합니다.
마무리
이러한 수치들은 시스템 설계 시 병목 지점을 예측하고, 캐싱 전략 수립, 저장소 선택, 네트워크 최적화 등을 결정하는 실질적인 기준이 됩니다. 새로운 수치가 확인되는 대로 이 글을 업데이트할 예정이니, 더 좋은 자료가 있다면 언제든 공유해 주시기 바랍니다.