Cache Miss란? CPU가 필요한 데이터를 캐시에서 찾지 못하면 왜 느려지는지 쉽게 이해하기

CPU는 매우 빠르지만, 필요한 데이터를 매번 느린 Main Memory에서만 가져오면 전체 속도가 떨어집니다. 그래서 CPU 가까이 CPU Cache에 자주 쓰는 데이터를 둡니다. Cache에 있으면 바로 쓰고, 없으면 더 느린 계층으로 내려갑니다. 이처럼 빠른 Cache에서 데이터를 찾지 못해 더 먼 곳에서 다시 가져와야 하는 상황을 Cache Miss(캐시 미스)라고 합니다.

Cache Hit = 캐시에 있어 바로 사용
Cache Miss = 캐시에 없어 더 먼 곳에서 가져옴

책상과 창고

자주 쓰는 서류는 책상(Cache)에, 없는 서류는 창고(Main Memory)까지 갑니다. Cache Hit는 책상에 있는 경우, Miss는 창고로 가는 경우입니다.

L1 · L2 · L3 · Hit Ratio

보통 L1(작고 매우 빠름) → L2 → L3(더 큼·Core 공유 흔함) → Main Memory 순으로 찾습니다. L1 Miss여도 L2 Hit면 Memory까지 안 갑니다. Miss 레벨에 따라 비용이 다릅니다. Hit Ratio는 Hit 비율이지만, Miss Penalty(Miss 한 번의 추가 지연)와 함께 봐야 합니다.

Locality · Cache Line

Temporal Locality는 최근 데이터를 다시 쓸 가능성, Spatial Locality는 주변 데이터도 곧 쓸 가능성입니다. Cache는 Byte 단위가 아니라 Cache Line 묶음으로 가져옵니다. 배열 순회는 유리하고, 주소를 뛰어다니거나 Linked List처럼 흩어진 접근은 Locality가 나쁠 수 있습니다. Big-O가 같아도 Cache 효율 때문에 실제 속도가 갈릴 수 있습니다.

Context Switching과의 연결

Context Switching으로 Thread가 바뀌면 Cache에 쌓여 있던 A의 데이터가 B 데이터에 밀려날 수 있습니다. 다시 A로 오면 Miss가 늘고 Memory 대기가 늘 수 있습니다. Switch 비용은 상태 저장만이 아닙니다.

Working Set · Thrashing · Miss 종류

일정 시간 자주 쓰는 집합이 Working Set입니다. Cache보다 훨씬 크면 Miss가 늘고, 넣고 빼기를 반복하면 Cache Thrashing에 가깝습니다. Miss는 첫 접근(Compulsory), 용량 부족(Capacity), 배치 충돌(Conflict)처럼 원인이 다를 수 있습니다. 공간 부족으로 기존 항목을 빼는 것이 Eviction(앱 LRU/LFU 등)입니다.

CPU Cache ≠ Redis · Stampede

CPU Cache는 하드웨어, Redis 등은 앱·서버 Cache입니다. 원리는 「빠른 곳 Miss → 느린 원본」으로 비슷합니다. 인기 Key가 동시에 만료되면 Miss가 폭발해 DB로 몰리는 Cache Stampede가 됩니다. Single Flight·TTL Jitter(Retry Jitter와 같은 ‘동시 행동 분산’ 정신)·Cache Warming이 도움이 됩니다. Cold Cache(배포 직후 비어 있음)와 Warm Cache를 구분합니다.

브라우저 · CDN · 서버 Cache

브라우저 Cache·CDN·서버 Redis·DB Buffer·CPU Cache 모두 「빠른 곳 확인 → Hit/Miss」 구조입니다. CDN Miss는 Origin까지 가고, Hit Ratio가 높으면 Origin 부하가 줄어듭니다. HTML·개인화 페이지를 잘못 Cache하면 정확성·권한 문제가 납니다. Cache-Control·Key·TTL·Invalidation을 함께 설계합니다.

Contention · Queue · Tail Latency

Miss가 늘면 Backend 요청이 늘고 Resource Contention이 커질 수 있습니다. Miss 요청의 Service Time이 길면 Queue가 길어지고 Retry가 더 악화시킬 수 있습니다. Hit Ratio 99%여도 Miss 1%가 매우 느리면 p99가 나빠집니다. Hit/Miss Latency를 나눠 모니터링하고, Key 설계 오류로 Hit가 안 나는 Fragmentation도 점검합니다. TTFB·응답 지연과도 맞닿습니다.

줄이는 방향 · False Sharing

CPU 쪽은 순차 접근·Working Set 축소·랜덤 접근·과도한 Thread 전환 감소가 도움이 됩니다. 앱 Cache는 TTL·Warming·Single Flight·Key·Jitter입니다. Hit Ratio만 올리는 것이 목표가 아니라 사용자 Latency·메모리·최신성이 우선입니다. 고성능 멀티스레드에서는 같은 Cache Line을 다른 Core가 따로 고쳐 False Sharing·Cache Coherence 비용이 날 수 있습니다. 일반 CRUD에서는 드뭅니다.

자주 묻는 질문

정리

Cache Miss = 빠른 Cache에 데이터가 없어 더 느린 곳에서 가져오는 상황입니다. Hit Ratio·Miss Penalty·Locality·Stampede를 함께 보고, CPU·CDN·서버 Cache 계층을 구분합니다. Miss가 늘면 Contention·Queue·Tail Latency로 이어질 수 있습니다. 그런데 CPU가 느려지는 이유는 Miss만은 아닙니다. 조건문 다음에 어떤 명령을 실행할지 미리 예상해 준비하기도 합니다. 예측이 맞으면 빠르고, 틀리면 준비한 작업을 버리고 올바른 경로를 다시 잡습니다. 이처럼 CPU가 조건문의 실행 방향을 미리 예측하는 기능을 Branch Prediction(브랜치 프리딕션, 분기 예측)이라고 합니다.