본문으로 바로가기

캐싱 전략 — Cache-Aside · Read/Write-Through · Write-Around · Write-Back

같은 읽기(v1)와 쓰기(v2)를 다섯 전략으로 실행해, 캐시를 채우는 책임과 쓰기 경로가 어떻게 다른지 — 그리고 Write-Back의 유실 위험까지 보여준다.

1 / 9상품 가격 v1을 읽고, v2로 고치는 두 동작을 다섯 전략으로 실행합니다. 갈리는 질문은 둘 — 캐시를 채우는 책임이 누구에게 있는가, 쓰기가 어디를 먼저 거치는가.
Cache-AsideRead-ThroughWrite-ThroughWrite-AroundWrite-Back
앱—
캐시 비어 있음
DBv1

단계 목록 · 키보드 ←/→ 이동, Space 재생

다섯 전략은 두 질문의 조합이다 — 캐시를 채우는 책임이 누구인가(앱=Aside, 캐시=Through), 쓰기가 어디를 거치는가(캐시+DB 동기=Write-Through, DB만=Write-Around, 캐시만=Write-Back).

왜 헷갈리는가

이름이 비슷해 표로 외우다 끝난다. Read-Through와 Cache-Aside의 차이(부적중 시 DB를 읽는 주체), Write-Back과 Write-Through의 차이(DB 반영이 비동기냐 동기냐)를 흐름으로 보면 헷갈릴 수가 없다. 그리고 'Cache-Aside 쓰기는 캐시 갱신'이라는 흔한 오답 — 정석은 무효화다.

애니메이션이 보여주는 것

읽기 축: Cache-Aside는 앱이 '캐시 확인→DB 읽기→캐시 채움'을 전부 코드로 한다(가장 흔함, Redis 표준 사용법). Read-Through는 그 채움 로직이 캐시 계층으로 들어간다 — 앱은 캐시에게만 묻는다.

쓰기 축: Write-Through는 캐시를 지나 DB까지 동기라 항상 일치(느린 쓰기). Write-Around는 캐시를 건너뛰어 한 번 쓰고 안 읽는 데이터로 캐시를 오염시키지 않는다. Write-Back은 캐시에만 쓰고 나중에 몰아서 반영 — 압도적으로 빠르지만 '더티' 상태에서 캐시가 죽으면 그 쓰기는 세상에서 사라진다. 화면의 경고 줄이 그 대가다.

선택 가이드

워크로드가 전략을 고른다.

  • 기본값: Cache-Aside + 쓰기 시 무효화(갱신 아님 — 동시 쓰기의 순서 경쟁으로 낡은 값이 박제되는 사고를 피한다) + TTL을 안전망으로.
  • 읽기 폭주 + 채움 로직 통일: Read-Through(+ 미리 데우기). 캐시 스탬피드(만료 순간 동시 부적중)는 잠금이나 소프트 TTL로.
  • 쓰기 후 즉시 읽기가 잦고 일관성 민감: Write-Through — 쓰기 지연을 감수한다.
  • 로그·배치 적재처럼 쓰고 안 읽음: Write-Around — 캐시는 읽기 인기 데이터에 양보.
  • 쓰기 폭주 흡수(좋아요·조회수·IoT): Write-Back — 유실 허용 범위를 정하고, 복제·영속 큐로 보강한다. CPU 캐시와 OS 페이지 캐시가 실제로 이 방식이다.

기억할 것

  • 두 질문으로 분류: 채움 책임(앱/캐시) × 쓰기 경로(동기 양쪽/DB만/캐시만).
  • Cache-Aside 쓰기의 정석은 갱신이 아니라 무효화 + TTL 안전망.
  • Write-Back의 속도는 유실 위험과의 거래 — 더티가 그 증거다.
  • Write-Around는 '캐시를 아끼는' 전략 — 쓰고 안 읽는 데이터용.
캐싱 전략 — Cache-Aside · Read/Write-Through · Write-Around · Write-Back | KIE