16강 / 20강

캐시 — 자주 쓰는 것을 손 닿는 곳에

LRU · 히트율 · 그리고 캐시가 만드는 새로운 사고들

상품 상세 페이지 하나를 만드는 데 이런 일이 필요합니다.

상품 정보 조회 (DB · 20ms)
재고 조회 (DB · 15ms)
리뷰 평균 계산 (DB · 80ms)
함께 산 상품 계산 (그래프 탐색 · 120ms)

합계 235ms. 초당 100명이 들어오면 서버가 버티지 못합니다.

그런데 잘 보세요. 같은 상품 페이지를 1,000명이 보는데 매번 똑같은 계산을 1,000번 하고 있습니다.

13강에서 배운 그 아이디어가 그대로 필요합니다. 한 번 계산한 건 저장해 두고 다시 쓰자. 이것이 캐시(cache)예요.

고등학생자주 쓰는 것을 손 닿는 곳에

13강의 발상이 시스템 규모로 커진 것이 캐시입니다.

한 번 가져온 것을 가까이 두고 다시 쓴다

비유 — 책상과 책장

	책상 위	책장
꺼내는 시간	즉시	일어나서 가야 한다
둘 수 있는 양	적다	많다

자주 보는 책을 책상 위에 둡니다. 그게 캐시예요.

빠른 곳은 좁고, 넓은 곳은 느리다

컴퓨터도 똑같이 생겼습니다

층	속도	크기
CPU 캐시	가장 빠름	수 MB
메모리	빠름	수십 GB
디스크	느림	수 TB
네트워크(DB)	가장 느림	무제한

이 계층이 컴퓨터 설계의 뼈대다 — /ca 강의

쇼핑몰에서는

상품 정보를 DB 에서 가져오면 느립니다. 자주 보는 상품은 메모리에 담아 두죠.

인기 상품 100개가 전체 조회의 절반을 차지한다면? 그 100개만 캐시해도 절반이 빨라집니다.

고등학생캐시의 세 가지 숫자

note 가 캐시를 재는 세 숫자를 듭니다.

숫자	무엇	좋은 값
히트율	캐시에서 찾은 비율	높을수록
용량	몇 개나 담나	적당히
수명 (TTL)	얼마나 오래 두나	상황마다

히트율이 90% 면 열에 아홉은 빨리 답한다

히트율이 왜 중요한가

계산해 보면 놀랍습니다. DB 조회가 100ms, 캐시가 1ms 라고 합시다.

히트율	평균 시간
0%	100ms
50%	50.5ms
90%	10.9ms
99%	2ms

90% 만 되어도 10배 빨라진다

그런데 100% 는 안 됩니다

처음 요청은 반드시 미스 니까요. 그리고 새 상품, 드문 상품은 캐시에 없습니다.

완벽을 노리지 말고 대부분을 노린다

80/20 법칙

대개 20% 의 상품이 80% 의 조회를 차지합니다. 그러니 20% 만 캐시해도 히트율 80% 가 나와요.

전부 담을 필요가 없다 — 자주 쓰는 것만

히트율이 높을수록 캐시가 잘 작동하고 있다는 뜻입니다.

Python 브라우저에서 실행

import time

def 무거운계산(상품id):
    time.sleep(0.02)                    # DB 조회 흉내
    return f"상품{상품id} 상세정보"

접속기록 = [1, 2, 1, 3, 1, 2, 1, 4, 1, 2, 3, 1]   # 1번 상품이 인기

# ❌ 캐시 없음
t0 = time.time()
for pid in 접속기록:
    무거운계산(pid)
느림 = time.time() - t0

# ✅ 캐시 있음
캐시 = {}
히트 = 미스 = 0
t0 = time.time()
for pid in 접속기록:
    if pid in 캐시:
        결과 = 캐시[pid]; 히트 += 1
    else:
        결과 = 무거운계산(pid); 캐시[pid] = 결과; 미스 += 1
빠름 = time.time() - t0

print(f"❌ 캐시 없음 : {느림*1000:>7.1f} ms")
print(f"✅ 캐시 사용 : {빠름*1000:>7.1f} ms")
print(f"   히트 {히트}회 · 미스 {미스}회 · 히트율 {히트/(히트+미스)*100:.0f}%")

문제 — 캐시는 무한하지 않다

위 코드의 캐시는 계속 커집니다. 상품이 3만 개면 3만 개가 다 들어가요. 메모리가 터집니다.

그래서 크기를 정해 두고, 가득 차면 무언가를 버려야 합니다. 무엇을 버릴 것인가 — 이것이 캐시 교체 정책입니다.

정책	버리는 기준	특징
LRU	가장 오래 안 쓴 것	가장 널리 쓰임. 최근 쓴 건 또 쓸 거라는 가정.
LFU	가장 적게 쓴 것	인기 상품에 유리. 옛날 인기가 오래 남는 단점.
FIFO	가장 먼저 들어온 것	단순하지만 성능이 나쁨.
TTL	정해진 시간이 지난 것	신선도 보장. 다른 정책과 함께 씀.

OrderedDict 하나로 LRU가 완성됩니다. 실행해서 무엇이 버려지는지 보세요.

Python 브라우저에서 실행

from collections import OrderedDict

class LRU캐시:
    def __init__(self, 최대):
        self.최대 = 최대
        self.d = OrderedDict()
        self.히트 = self.미스 = 0

    def get(self, key):
        if key in self.d:
            self.d.move_to_end(key)      # 방금 썼으니 '최근'으로 옮김
            self.히트 += 1
            return self.d[key]
        self.미스 += 1
        return None

    def put(self, key, val):
        self.d[key] = val
        self.d.move_to_end(key)
        if len(self.d) > self.최대:
            버림, _ = self.d.popitem(last=False)   # 가장 오래된 것 버리기
            print(f"      🗑️ 캐시 가득 참 → {버림} 버림")

캐시 = LRU캐시(최대=3)
접속 = [1, 2, 3, 1, 4, 2, 5, 1, 3]

for pid in 접속:
    if 캐시.get(pid) is None:
        캐시.put(pid, f"데이터{pid}")
        print(f"  상품{pid} 요청 → 미스 (DB 조회)  캐시: {list(캐시.d)}")
    else:
        print(f"  상품{pid} 요청 → ✅ 히트          캐시: {list(캐시.d)}")

print()
print(f"히트율 {캐시.히트/(캐시.히트+캐시.미스)*100:.0f}%")

🎮 LRU 캐시 시뮬레이터

캐시 크기를 바꿔 가며 히트율이 어떻게 변하는지 보세요. 접속 패턴도 고를 수 있습니다 — 인기 상품 집중형과 고르게 분산형에서 같은 캐시 크기라도 히트율이 완전히 달라집니다.

캐시가 만드는 새로운 사고 세 가지

캐시는 만능이 아닙니다. 새로운 종류의 장애를 만들어요.

오래된 데이터(stale) — 가격을 바꿨는데 캐시에 옛 가격이 남아 있으면? 손님이 옛 가격으로 주문합니다. 가격·재고는 캐시 TTL을 짧게 하거나, 변경 시 즉시 무효화해야 합니다.
캐시 스탬피드 — 인기 상품의 캐시가 만료되는 순간 수천 개의 요청이 동시에 DB로 몰립니다. 서버가 죽어요. 처방: 만료 시각을 조금씩 흩뜨리거나(jitter), 첫 요청만 계산하고 나머지는 기다리게(lock).
재고 캐시의 위험 — 재고를 캐시하면 없는 물건을 팝니다. 재고는 원칙적으로 캐시하지 않거나, 아주 짧은 TTL만 씁니다.

고등학생캐시가 만드는 새로운 사고 세 가지

note 가 캐시의 대가를 정리합니다. 빠르게 만들었더니 새로운 문제가 생겨요.

① 낡은 값 (stale)

가격을 바꿨는데 캐시에 옛날 가격이 남아 있으면?

손님이 다른 가격을 본다 — 심각한 사고

대책	설명
TTL	일정 시간 뒤 자동 만료
무효화	바꿀 때 캐시를 지운다

② 캐시 스탬피드

인기 상품의 캐시가 만료되는 순간, 동시에 들어온 요청이 전부 DB 로 몰립니다.

캐시가 있어서 버티던 DB가 한꺼번에 맞는다

비유하자면 — 댐이 갑자기 열리는 것입니다. 평소엔 막고 있다가 한 번에 쏟아지죠.

③ 캐시 미스가 더 느리다

캐시를 확인하고, 없으면 DB 에 가고, 다시 캐시에 넣습니다. 단계가 늘어난 거예요.

	시간
캐시 히트	1ms
캐시 미스	1 + 100 + 1 = 102ms
캐시 없이	100ms

히트율이 낮으면 오히려 느려진다

이 강의에서 계속 나온 그 구조입니다 — 공짜 최적화는 없다.

무엇을 캐시하고 무엇을 하지 말아야 할까

데이터	캐시?	이유
상품 이름 · 설명 · 이미지	✅ 길게 (시간 단위)	거의 안 바뀜
리뷰 평균 · 추천 목록	✅ 중간 (분 단위)	계산이 비싸고, 조금 늦어도 괜찮음
가격	⚠️ 짧게 + 변경 시 무효화	틀리면 금전 사고
재고 수량	🚫 거의 안 함	틀리면 없는 물건을 판매
장바구니 · 결제 진행	🚫 절대 안 됨	사람마다 다르고 실시간이어야 함

원칙은 하나예요. "조금 낡아도 괜찮은 것"만 캐시한다.

lru_cache 의 cache_info() 로 히트율을 바로 볼 수 있습니다.

Python 브라우저에서 실행

from functools import lru_cache
import time

@lru_cache(maxsize=128)          # ← 13강의 메모이제이션과 정확히 같은 도구
def 리뷰평균(상품id):
    time.sleep(0.05)             # 무거운 집계 흉내
    return round(3.5 + (상품id % 15) / 10, 1)

접속 = [101, 102, 101, 103, 101, 102, 101]
t0 = time.time()
for pid in 접속:
    print(f"  상품{pid} 평점 {리뷰평균(pid)}")
print(f"
총 {(time.time()-t0)*1000:.0f} ms")
print("캐시 통계:", 리뷰평균.cache_info())
print()
print("💡 hits=4, misses=3 → 히트율 57%. 이 숫자를 모니터링하는 것이 운영입니다.")

고등학생LRU — 무엇을 버릴 것인가

캐시는 가득 찹니다. 그러면 뭘 버릴까요?

LRU = 가장 오래 안 쓴 것을 버린다

왜 그게 합리적인가

최근에 쓴 것은 또 쓸 가능성이 높기 때문입니다. 이걸 지역성(locality) 이라고 해요.

상황	다음에도 볼까
방금 본 상품	볼 가능성 높다
한 달 전에 본 상품	낮다

과거가 미래를 예측한다는 가정

비유 — 책상 정리

책상이 꽉 찼습니다. 뭘 책장으로 보낼까요?

가장 오래 안 펴 본 책이겠죠. 자연스러운 판단입니다.

다른 방법도 있습니다

정책	버리는 것	언제 좋나
LRU	오래 안 쓴 것	대부분
LFU	적게 쓴 것	인기가 안정적일 때
FIFO	먼저 들어온 것	단순함이 필요할 때
무작위	아무거나	놀랍게도 꽤 괜찮다

완벽한 정책은 없다 — 미래를 모르니까

이론적으로 최선은 "앞으로 가장 안 쓸 것" 을 버리는 건데, 미래를 모르므로 불가능합니다.

LRU 는 과거로 미래를 짐작하는 최선의 어림이다

🤔 확인 문제

캐시 히트율이 95%라는 것은 무슨 뜻일까요?

🤔 확인 문제

LRU 캐시가 가득 찼을 때 버리는 항목은?

🤔 확인 문제

인기 상품의 캐시가 만료되는 순간 수천 개의 요청이 동시에 DB로 몰리는 현상은?