개발자가 알아야 할 레이턴시 숫자와 시스템 설계 감각

출처: https://m.youtube.com/watch?v=WbzMtyyOQpM · 코딩하는기술사 · 19:16 · 2026-04-23

요지

• 시스템 설계에서는 “빠르다”와 “느리다”를 직관이 아닌 대략적인 수치와 차수로 설명해야 한다.
• CPU 캐시, 메모리, SSD, 디스크, 네트워크는 각각 나노초·마이크로초·밀리초 단위의 서로 다른 비용 계층을 이룬다.
• 정확한 숫자를 암기하기보다 연산 사이에 수십·수천·수십만 배의 차이가 날 수 있다는 상대적 감각을 익혀야 한다.
• 이 감각을 이용하면 캐시 도입, 데이터 압축, 마이크로서비스 분리, 샤딩 같은 선택의 비용을 구현 전에 추정할 수 있다.
• 고전적인 레이턴시 표는 출발점일 뿐이며, 실제 결정에서는 최신 벤치마크와 처리량·동시성·운영 복잡성도 함께 검토해야 한다.

개요

AI가 코드를 생성해 주더라도 어떤 구조가 적절한지 판단하고 그 근거를 설명하는 일은 개발자의 몫이다. 예컨대 데이터베이스가 느리다는 이유만으로 캐시를 추가하거나, 기능을 독립적으로 배포하고 싶다는 이유만으로 원격 서비스로 분리해서는 충분하지 않다. 예상 호출 횟수와 각 연산의 비용을 숫자로 비교해야 선택의 효과와 대가를 가늠할 수 있다.

영상은 Peter Norvig, Jeff Dean, Colin Scott을 거쳐 발전한 이른바 ‘모든 프로그래머가 알아야 할 레이턴시 숫자’를 소개한다. 이 표의 핵심은 특정 연도의 측정값을 외우는 데 있지 않다. CPU와 메모리, 저장장치와 네트워크 사이의 규모 차이를 익혀 아직 만들지 않은 시스템의 성능을 대략 계산하는 데 있다.

배경 / 사전 지식

레이턴시(latency)는 작업 하나가 시작되어 끝날 때까지 걸리는 지연 시간이다. 처리량(throughput)은 일정 시간 동안 완료할 수 있는 작업의 수다. 한 요청의 레이턴시가 짧아도 동시 요청을 충분히 처리하지 못할 수 있고, 개별 작업이 느려도 배치·병렬화로 높은 처리량을 낼 수 있으므로 둘은 구분해야 한다.

시간 단위 사이에는 각각 1,000배의 차이가 있다.

• 1마이크로초(μs) = 1,000나노초(ns)
• 1밀리초(ms) = 1,000마이크로초(μs)
• 1초(s) = 1,000밀리초(ms)

왕복 시간(RTT)은 요청이 목적지까지 갔다가 응답이 돌아오는 데 걸리는 시간이다. 데이터센터 내부 통신과 대륙 간 통신은 같은 네트워크 호출이라도 물리적 거리와 장비 경로 때문에 비용이 크게 다르다. 캐시는 자주 사용하는 데이터를 더 빠른 계층에 복제해 원본 저장소 접근을 줄이는 장치이며, 샤딩은 데이터를 여러 노드에 나누어 부하와 저장 공간을 분산하는 방식이다.

영상에서 제시하는 숫자들은 특정 하드웨어의 보장값이 아니라 차수 수준의 고전적 근사치다. 현대 장비, 클라우드 환경, 데이터 크기, 캐시 적중 여부와 부하에 따라 실제 값은 달라진다.

핵심 개념

비용 계층과 차수

대표 연산은 대략 다음과 같은 비용 계층으로 이해할 수 있다.

개별 숫자는 시대와 환경에 따라 바뀌지만, CPU 캐시 → 메모리 → SSD → 디스크·원거리 네트워크로 갈수록 비용이 커지는 서열은 설계의 유용한 출발점이 된다.

레이턴시 표의 발전

Peter Norvig은 프로그래밍 숙련에는 장기간의 경험과 컴퓨터 시간 비용에 대한 이해가 필요하다는 맥락에서 초기 수치를 제시했다. 이 관점은 한 대의 컴퓨터 안에서 CPU, 캐시, 메모리, 디스크의 차이를 파악하는 데 초점이 있었다.

Jeff Dean은 대규모 분산 시스템의 경험을 반영해 데이터센터 왕복 통신, 압축, SSD 같은 항목을 보강했다. 이에 따라 표는 로컬 하드웨어뿐 아니라 여러 컴퓨터가 협력하는 시스템의 비용을 추정하는 도구로 확장됐다.

Colin Scott은 하드웨어 변화 추세를 반영한 연도별 시각화를 만들었다. 특정 숫자의 영속성을 주장하기보다 시간이 흘러도 남는 상대적 서열과 격차를 눈으로 비교할 수 있게 했다는 데 의미가 있다.

구현 전 추정

레이턴시 감각의 목적은 코드를 작성하기 전에 대략적인 상한과 병목 후보를 찾는 것이다. 작업 하나의 예상 비용을 L, 순차 호출 횟수를 N이라 하면 단순한 직렬 경로의 지연은 우선 N × L로 근사할 수 있다. 여기에 직렬화, 큐 대기, 재시도, 잠금 경쟁, 저장장치 접근 같은 비용을 더한다.

이 계산은 정밀한 성능 예측이 아니라 틀린 설계를 일찍 걸러 내는 봉투 뒷면 계산이다. 후보를 좁힌 뒤에는 실제 워크로드로 측정해야 한다.

트레이드오프의 정량화

압축에는 CPU 시간이 들지만 전송할 바이트 수를 줄인다. 압축 시간이 3μs이고 데이터 크기를 절반으로 줄여 전송 시간이 10μs에서 5μs가 된다면 총비용은 약 8μs다. 압축하지 않은 10μs보다 작으므로 이 조건에서는 이득이다. 반대로 데이터가 작거나 네트워크가 충분히 빠르거나 압축률이 낮다면 손해가 될 수 있다.

마이크로서비스 호출도 같은 방식으로 볼 수 있다. 프로세스 내부 함수 호출은 매우 짧지만 원격 호출에는 네트워크 RTT뿐 아니라 직렬화·역직렬화, 암호화, 프록시, 큐 대기와 장애 처리 비용이 붙는다. 따라서 호출 빈도가 높은 경로를 분리할 때는 독립 배포와 확장성이라는 이점이 추가 지연보다 큰지 따져야 한다.

작동 원리

레이턴시 숫자를 설계에 적용하는 절차는 다음과 같다.

1. 사용자 요청이 거치는 경로를 함수 호출, 캐시, 데이터베이스, 저장장치, 서비스 간 통신으로 분해한다.
2. 각 단계에 정확한 값 대신 ns·μs·ms 중 어느 차수인지 우선 배정한다.
3. 직렬 단계는 합산하고 반복 횟수를 곱한다. 병렬 단계는 가장 느린 분기와 조정 비용을 중심으로 계산한다.
4. 캐시 적중률, 압축률, 요청 크기처럼 결과에 큰 영향을 주는 가정을 명시한다.
5. 가장 큰 항을 병목 후보로 삼고 캐시, 배치, 호출 제거, 데이터 배치 변경 등의 대안을 비교한다.
6. 선택한 구조를 프로토타입이나 부하 테스트로 측정하고 추정값을 실제 환경의 분포로 교체한다.

예를 들어 캐시가 적중하면 0.5ms, 실패하여 데이터베이스까지 가면 10ms가 걸리고 적중률이 90%라면 평균은 단순화하여 0.9 × 0.5 + 0.1 × 10 = 1.45ms로 추정할 수 있다. 그러나 평균만으로는 부족하다. 캐시 실패가 몰리거나 데이터베이스 지연이 길어지면 p95·p99 레이턴시는 평균보다 훨씬 커질 수 있다.

초당 100만 요청을 처리하는 URL 단축 서비스를 생각하면, 모든 요청이 디스크나 여러 원격 서비스를 순차적으로 거치는 구조는 곧 병목이 된다. 읽기 비중이 높다면 메모리 캐시, 데이터 분할, 호출 단계 축소를 후보로 세울 수 있다. 다만 1 ÷ 단일 연산 시간은 이론적 상한일 뿐 CPU 코어 수, 네트워크 대역폭, 락, 런타임, 응답 크기와 장애 여유를 포함하지 않으므로 서버 용량으로 그대로 사용해서는 안 된다.

코드 예시

다음 Python 코드는 캐시 도입 전후의 평균 레이턴시를 단순 모델로 비교한다. 그대로 저장해 실행할 수 있다.

from dataclasses import dataclass


@dataclass(frozen=True)
class CacheModel:
    hit_rate: float
    cache_ms: float
    database_ms: float
    network_ms: float = 0.0

    def expected_ms(self) -> float:
        if not 0.0 <= self.hit_rate <= 1.0:
            raise ValueError("hit_rate must be between 0 and 1")

        hit = self.cache_ms + self.network_ms
        miss = self.cache_ms + self.network_ms + self.database_ms
        return self.hit_rate * hit + (1.0 - self.hit_rate) * miss


baseline_ms = 10.0
model = CacheModel(
    hit_rate=0.90,
    cache_ms=0.10,
    database_ms=10.0,
    network_ms=0.50,
)

cached_ms = model.expected_ms()
print(f"DB only: {baseline_ms:.2f} ms")
print(f"With cache: {cached_ms:.2f} ms")
print(f"Estimated speedup: {baseline_ms / cached_ms:.1f}x")

이 모델에서는 캐시 적중도 데이터센터 네트워크 비용을 지불하며, 실패하면 캐시 확인 후 데이터베이스 비용까지 추가된다. 계산 결과는 의사 결정의 첫 근거일 뿐이다. 실제 적용 전에는 연결 풀 대기, 데이터 크기, 캐시 갱신, 장애 시 우회, p95·p99 지연과 운영 비용을 측정해야 한다.

함정·실수

• 고전적 수치를 상수로 취급한다. 하드웨어와 클라우드 토폴로지가 달라지므로 최신 환경에서 벤치마크해야 한다.
• 평균값만 본다. 사용자가 체감하는 지연과 용량 위험은 p95·p99 같은 꼬리 지연에서 드러나는 경우가 많다.
• 레이턴시와 처리량을 혼동한다. 연산 하나의 역수를 곧바로 서버 QPS로 간주하면 동시성, 대역폭, CPU 포화와 큐 대기를 놓친다.
• 캐시가 언제나 빠르다고 가정한다. 낮은 적중률, 원격 캐시 RTT, 무효화 비용과 장애 시 캐시 스탬피드는 이득을 없앨 수 있다.
• 서비스 분리 비용을 RTT 하나로 계산한다. 직렬화, TLS, 서비스 메시, 재시도, 로깅과 부분 장애까지 포함해야 한다.
• 레이턴시만으로 아키텍처를 결정한다. 독립 배포, 팀 경계, 확장성, 일관성, 복구성과 비용도 함께 비교해야 한다.
• 단위를 섞는다. ns, μs, ms 사이에는 각각 1,000배 차이가 있으므로 계산 전에 한 단위로 통일한다.

베스트 프랙티스

• L1 캐시, 메모리, SSD, 데이터센터 내부 RTT, 디스크, 대륙 간 RTT처럼 대표 기준점 몇 개의 차수만 익힌다.
• 모든 추정에 하드웨어, 데이터 크기, 호출 횟수, 캐시 적중률 등 가정을 함께 기록한다.
• 평균과 함께 p50·p95·p99를 측정하고, 정상 상태뿐 아니라 캐시 실패와 재시도 폭증 같은 장애 상태도 시험한다.
• 요청 경로에서 가장 큰 직렬 비용부터 줄인다. 작은 CPU 연산보다 반복되는 네트워크 왕복이나 디스크 접근을 먼저 살피는 편이 효과적이다.
• 원격 호출은 가능한 한 배치하고, 불필요한 왕복을 제거하며, 서로 강하게 결합된 고빈도 연산은 데이터와 계산을 가까이 둔다.
• 캐시 도입 시 TTL, 무효화, 일관성 수준, 용량, 스탬피드 방지와 원본 저장소 보호 전략까지 설계한다.
• 봉투 뒷면 계산으로 후보를 좁힌 뒤 실제와 유사한 데이터·부하로 벤치마크하고 관측 결과로 모델을 갱신한다.
• 레이턴시 최적화가 처리량, 비용, 신뢰성에 미치는 영향을 함께 기록하여 선택의 근거를 재검증할 수 있게 한다.

참고

영상에서 다음 자료와 인물을 언급한다.

• Peter Norvig, 「Teach Yourself Programming in Ten Years」와 초기 시간 비용 표
• Jeff Dean의 대규모 분산 시스템 관련 강연과 레이턴시 수치
• Colin Scott의 연도별 레이턴시 시각화
• Jonas Bonér가 정리한 ‘Latency Numbers Every Programmer Should Know’ 자료
• Martin Kleppmann, 《Designing Data-Intensive Applications》
• Alex Xu의 시스템 디자인 면접 관련 서적
• ACM Queue, Google Research 및 Cornell University의 관련 자료

영상 설명란에 관련 링크를 정리했다고 안내하지만, 자막에는 개별 URL이 명시되어 있지 않다.