DB 쿼리는 충분히 빠른데 사용자는 여전히 느리다고 느끼는 경우가 있습니다. 같은 상품 정보, 같은 게시글 목록, 같은 설정값을 요청할 때마다 네트워크를 지나 애플리케이션과 데이터베이스를 반복해서 거치기 때문입니다. 이때 필요한 것이 단순한 저장소 추가가 아니라, 요청 흐름 중 어디에서 어떤 데이터를 얼마나 오래 재사용할지 정하는 캐싱 구조입니다.
좋은 캐싱 구조는 지연 시간을 줄이고 원본 서버와 DB의 부하를 낮추지만, 잘못 설계하면 오래된 데이터 노출, 권한 오류, 캐시 스탬피드 같은 문제를 만들 수 있습니다. 따라서 캐시는 ‘빠르게 저장한다’가 아니라 ‘성능과 일관성의 균형을 설계한다’에 가깝습니다.
캐싱 구조란 무엇인가
캐시는 원본 저장소보다 빠르게 접근 가능한 계층에 자주 쓰는 데이터나 계산 결과를 임시 저장하는 방식입니다. AWS 캐싱 개요에서도 캐시를 고속 데이터 저장 계층으로 설명하며, 일반적으로 RAM이나 인메모리 엔진처럼 원본보다 빠른 저장 매체와 함께 사용한다고 설명합니다.
캐시가 성능을 높이는 기본 원리
요청이 들어올 때 매번 DB, 외부 API, 복잡한 계산을 수행하지 않고 이미 만들어진 결과를 재사용하면 응답 경로가 짧아집니다. 예를 들어 메인 화면의 인기 게시글 목록은 수천 명이 비슷한 시간에 조회할 수 있으므로, 짧은 시간 동안 같은 결과를 캐시에 두는 것만으로도 원본 조회 횟수를 줄일 수 있습니다.
Cache Hit와 Cache Miss의 의미
Cache Hit는 요청한 데이터가 캐시에 있어 즉시 응답할 수 있는 상태입니다. Cache Miss는 캐시에 없거나 만료되어 원본 저장소를 다시 조회해야 하는 상태입니다. 캐싱 구조의 효과는 hit 비율, miss 시 지연, 원본 부하 감소량을 함께 봐야 판단할 수 있습니다.
캐시는 왜 원본 저장소보다 빠른가
캐시는 보통 사용자와 가까운 위치, 더 빠른 메모리, 더 단순한 조회 구조를 사용합니다. 브라우저 캐시는 네트워크 요청 자체를 줄이고, CDN은 지리적으로 가까운 엣지에서 파일을 제공합니다. 애플리케이션 로컬 캐시는 프로세스 내부에서 읽을 수 있고, Redis 같은 분산 캐시는 DB보다 단순한 키 기반 접근에 강합니다.
캐싱 구조를 이루는 주요 계층
실무의 캐싱 구조는 하나의 캐시 서버가 아니라 여러 계층의 조합입니다. 요청은 보통 브라우저, CDN, 애플리케이션, 분산 캐시, DB 순서로 이동하며 각 계층은 서로 다른 문제를 해결합니다.
| 계층 | 주요 역할 | 주의점 |
|---|---|---|
| 브라우저 캐시 | 정적 리소스와 개인 응답 재사용 | 사용자별 데이터와 만료 정책 관리 |
| CDN과 엣지 캐시 | 전 세계 사용자에게 가까운 위치에서 응답 | 동적 API와 권한 응답 캐싱 주의 |
| 애플리케이션 로컬 캐시 | 프로세스 내부에서 설정값, 코드성 데이터 조회 | 인스턴스 간 불일치 가능 |
| 분산 캐시 | 여러 서버가 공유하는 인메모리 캐시 | 네트워크 지연, 장애, 핫 키 관리 |
| DB 캐시와 쿼리 결과 캐시 | 반복 쿼리 비용 완화 | 복잡한 무효화와 최신성 문제 |
캐싱 구조의 핵심 구성 요소
Cache Key
Cache Key는 캐시 항목을 찾는 주소입니다. 상품 상세라면 product:123처럼 만들 수 있지만, 언어, 통화, 로그인 상태, 권한에 따라 응답이 달라진다면 키에 해당 조건을 반영해야 합니다. HTTP 표준인 RFC 9111은 캐시 키가 최소한 요청 메서드와 대상 URI를 기반으로 구성된다고 설명하며, 일반적으로 GET 응답이 캐시 대상이 됩니다.
TTL과 만료 시간
TTL은 캐시 항목을 fresh 상태로 볼 기간입니다. 너무 짧으면 miss가 늘어 원본 부하가 커지고, 너무 길면 오래된 정보가 사용자에게 보일 수 있습니다. 자주 바뀌지 않는 카테고리 목록은 길게, 재고나 가격처럼 변동이 잦은 데이터는 짧게 잡거나 이벤트 기반 무효화를 함께 사용합니다.
캐시 무효화와 Eviction 정책
캐시 무효화는 더 이상 유효하지 않은 데이터를 제거하거나 갱신하는 과정입니다. 무효화는 시간 기반 TTL, 데이터 변경 이벤트, 관리자 수동 purge, 배포 시 버전 변경 등으로 설계할 수 있습니다. Eviction은 캐시 공간이 부족할 때 어떤 항목을 내보낼지 정하는 정책이며 LRU, LFU 같은 방식이 자주 사용됩니다.
Fresh 데이터와 Stale 데이터
Fresh 데이터는 TTL 안에 있어 재사용 가능한 응답이고, Stale 데이터는 만료되었지만 상황에 따라 임시로 쓸 수 있는 응답입니다. stale-while-revalidate는 오래된 응답을 먼저 주고 백그라운드에서 갱신하는 전략이며, stale-if-error는 원본 장애 때 일정 시간 오래된 응답을 제공해 가용성을 높이는 방식입니다.
대표적인 캐싱 패턴
Cache-Aside 패턴
Cache-Aside는 애플리케이션이 먼저 캐시를 확인하고, miss가 나면 원본 DB에서 읽은 뒤 캐시에 채우는 방식입니다. 실제 요청된 데이터만 캐시에 들어가 비용 효율적이고 구현이 비교적 단순합니다. 다만 첫 요청은 느릴 수 있고, 외부 프로세스가 원본 데이터를 바꾸면 캐시가 갱신되기 전까지 오래된 데이터가 남을 수 있습니다.
Write-Through와 Write-Behind 패턴
Write-Through는 DB 업데이트 직후 캐시도 함께 업데이트합니다. 캐시가 최신 상태일 가능성이 높지만, 자주 읽히지 않는 데이터까지 캐시에 기록되어 비용이 커질 수 있습니다. Write-Behind 또는 Write-Back은 캐시에 먼저 쓰고 나중에 원본에 반영하는 방식입니다. 쓰기 지연을 줄일 수 있으나 장애 시 데이터 유실과 순서 보장을 신중히 다뤄야 합니다.
Read-Through 패턴
Read-Through는 애플리케이션이 캐시만 호출하고, 캐시 계층이 miss 시 원본 조회와 채우기를 담당합니다. 애플리케이션 코드는 단순해지지만 캐시 솔루션과 원본 저장소 통합 방식에 의존성이 생깁니다.
| 패턴 | 장점 | 주의점 |
|---|---|---|
| Cache-Aside | 단순하고 필요한 데이터만 저장 | 첫 요청 지연, stale 가능성 |
| Write-Through | 읽기 시 최신 캐시 가능성 증가 | 쓰기 지연과 불필요한 캐시 기록 |
| Write-Behind | 쓰기 응답 지연 감소 | 장애 시 유실과 정합성 위험 |
HTTP 캐싱 구조에서 꼭 알아야 할 헤더
브라우저와 CDN 캐시는 HTTP 요청과 응답을 저장해 동일하거나 동등한 요청에 재사용합니다. MDN의 HTTP caching 문서는 private cache와 shared cache, fresh와 stale, 검증 방식의 차이를 이해하는 데 유용합니다.
Cache-Control, max-age, s-maxage
Cache-Control은 HTTP 캐싱 구조의 핵심 헤더입니다. max-age는 응답 생성 후 몇 초 동안 fresh로 볼지 지정합니다. s-maxage는 CDN 같은 shared cache의 신선도 기간을 지정하며 브라우저 같은 private cache에서는 무시됩니다.
no-cache와 no-store, private
no-cache는 저장하지 말라는 뜻이 아니라, 저장은 가능하지만 재사용 전에 원본 검증을 하라는 의미입니다. 저장 자체를 막으려면 no-store를 사용해야 합니다. private은 브라우저 같은 개인 캐시에만 저장되도록 하여 사용자별 응답이 공유 캐시에 남는 위험을 줄입니다.
ETag, Last-Modified, Vary
ETag와 Last-Modified는 캐시된 응답이 여전히 유효한지 재검증하는 데 쓰입니다. Vary는 Accept-Language, Accept-Encoding 같은 요청 헤더에 따라 같은 URL이라도 다른 캐시 항목으로 구분하게 합니다. 다국어 사이트나 압축 응답에서는 Vary 설계가 캐시 키 설계와 직접 연결됩니다.
| 지시어 | 의미 |
|---|---|
| no-cache | 저장은 가능하지만 재사용 전 검증 필요 |
| no-store | 요청과 응답을 저장하지 않도록 지시 |
| private | 개인 캐시에만 저장, 공유 캐시 저장 제한 |
캐싱 구조 설계 시 고려해야 할 문제
데이터 일관성과 최신성
캐시는 원본의 복사본이므로 항상 최신이라고 가정하면 안 됩니다. 가격, 재고, 권한처럼 변경 즉시 반영되어야 하는 데이터는 TTL만으로 부족할 수 있습니다. 변경 이벤트가 발생하면 관련 cache key를 삭제하거나 버전 키를 바꾸는 방식으로 무효화를 설계해야 합니다.
개인정보와 인증 응답 캐싱
사용자별 개인정보, 인증 토큰, 권한에 따라 달라지는 응답은 shared cache에 저장되면 심각한 노출 사고로 이어질 수 있습니다. 이런 응답은 Cache-Control: private, no-store, 사용자별 키 분리, 권한 검증 우회 방지 등을 함께 검토해야 합니다.
캐시 스탬피드와 핫 키 문제
인기 키가 동시에 만료되면 많은 요청이 한꺼번에 원본 DB로 몰립니다. 이를 캐시 스탬피드라고 부릅니다. 만료 시간에 무작위 지터를 넣거나, 한 요청만 갱신하도록 락을 사용하거나, stale-while-revalidate 전략을 적용해 완화할 수 있습니다. 특정 상품이나 이벤트 페이지처럼 한 키에 트래픽이 집중되는 핫 키는 샤딩, 복제, 로컬 캐시 조합이 필요할 수 있습니다.
장애 상황에서 Stale 데이터 활용
원본 API가 일시적으로 실패할 때 모든 요청을 오류로 돌려보내는 대신, 오래된 캐시를 제한된 시간 제공하면 사용자 경험을 보호할 수 있습니다. 단, 결제 승인, 계좌 잔액, 의료 기록처럼 강한 일관성이 필요한 영역에서는 stale 응답을 제공하면 안 되는 경우가 많습니다.
어떤 데이터에 캐싱을 적용해야 할까
캐싱에 적합한 데이터는 읽기 빈도가 높고 변경 빈도가 낮으며, 계산 비용이 크거나 반복 조회되는 데이터입니다. 정적 리소스, 공지 목록, 인기 게시글, 상품 카탈로그, 프로필의 공개 영역, 외부 API 응답 일부가 대표적입니다.
반대로 인증 응답, 사용자별 개인정보, 권한에 따라 내용이 바뀌는 API, 금융·결제·보안성 데이터는 신중해야 합니다. 캐싱하지 않는 것이 나은 경우도 있습니다. 요청이 거의 반복되지 않거나 데이터가 매번 바뀌며 원본 조회 비용도 낮다면 캐시 관리 비용이 이익보다 클 수 있습니다.
실무적인 캐싱 구조 설계 체크리스트
- 읽기 빈도와 변경 빈도를 먼저 측정한다.
- 응답이 사용자별인지 전체 공통인지 구분한다.
- TTL은 데이터의 허용 가능한 오래됨을 기준으로 정한다.
- 데이터 변경 이벤트와 cache key 무효화 범위를 설계한다.
- 캐시 장애 시 원본으로 우회할지, 제한적으로 stale 데이터를 줄지 정한다.
- hit ratio, miss ratio, 원본 DB 부하, 캐시 지연, eviction 수, 오류율을 모니터링한다.
- 배포, 권한 변경, 상품 가격 변경처럼 대량 무효화가 필요한 이벤트를 사전에 정의한다.
캐싱 구조를 이해할 때 흔히 하는 오해
첫째, 캐시는 무조건 빠르지 않습니다. 네트워크를 거치는 분산 캐시가 로컬 계산보다 느릴 수도 있고, 낮은 hit ratio에서는 오히려 복잡도만 늘어납니다. 둘째, no-cache는 저장 금지가 아닙니다. 재사용 전 검증을 요구하는 지시어입니다. 셋째, TTL만 정하면 일관성이 해결되지 않습니다. 중요한 데이터는 이벤트 기반 무효화, 검증, 권한 분리, 모니터링이 함께 필요합니다.
좋은 캐싱 구조는 속도와 신뢰성의 균형이다
캐싱 구조는 단순히 Redis나 CDN을 추가하는 일이 아닙니다. 브라우저, CDN, 애플리케이션, DB 앞단 중 어디에 캐시를 둘지 정하고, cache key와 TTL, 무효화, eviction, 보안 정책을 함께 설계하는 작업입니다. 읽기는 빠르게 만들되 사용자가 잘못된 데이터나 타인의 정보를 보지 않도록 통제해야 합니다. 결국 좋은 캐싱 구조는 데이터 신선도와 성능 사이의 균형을 서비스 특성에 맞게 선택하는 설계입니다.