캐시 쓰기 전략이 필요한 이유
캐시는 자주 조회되는 데이터를 빠르게 읽기 위해 사용하지만, 데이터를 ‘쓸 때’는 캐시와 실제 저장소(DB)의 데이터를 어떻게 동기화할지 고민이 필요하다. 이때 등장하는 대표적인 전략이 Write-Through와 Write-Behind(Write-Back)다. 두 방식 모두 캐시에 데이터를 저장한다는 점은 같지만, DB에 언제 반영하느냐에서 큰 차이가 있다.
Write-Through: 캐시와 DB를 동시에 갱신
Write-Through는 데이터를 쓸 때 캐시와 DB에 즉시(순차적으로) 기록하는 방식이다. 예를 들어 은행 창구에서 입금을 하면 창구 직원(캐시)이 전산 시스템(DB)에 바로 반영하고 나서야 처리 완료 도장을 찍어주는 것과 같다. 두 곳 모두 최신 상태가 보장되므로 데이터 정합성이 매우 높다.
다만 매 요청마다 DB 쓰기 작업을 기다려야 하므로 쓰기 지연(latency)이 늘어난다는 단점이 있다. 트래픽이 많은 서비스에서는 이 지연이 병목이 될 수 있다.
- 장점: 캐시와 DB의 데이터 불일치 위험이 낮음
- 단점: 쓰기 성능이 DB 속도에 종속됨
Write-Behind: 캐시만 빠르게, DB는 나중에
Write-Behind(Write-Back이라고도 부름)는 데이터를 일단 캐시에만 기록하고, 이후 별도의 백그라운드 프로세스가 일정 주기나 조건에 따라 DB에 반영하는 방식이다. 창구 직원이 입금을 즉시 처리해주고, 전산 반영은 영업 마감 후 일괄 처리하는 것에 비유할 수 있다. 사용자 입장에서는 응답 속도가 매우 빠르게 느껴진다.
하지만 캐시에만 존재하고 아직 DB에 반영되지 않은 데이터가 서버 장애나 캐시 노드 다운으로 유실될 위험이 있다. 따라서 이 전략을 쓸 때는 로그 기반 복구, 큐(Queue)를 통한 재시도 로직 등 보완 장치가 필요하다.
- 장점: 쓰기 성능이 뛰어나고 DB 부하 감소
- 단점: 데이터 유실 가능성, 구현 복잡도 증가
실무에서는 어떻게 선택할까
정합성이 중요한 결제, 주문 데이터는 Write-Through를 사용해 데이터 손실 위험을 최소화하는 것이 일반적이다. 반면 좋아요 수, 조회수처럼 약간의 유실이 허용되고 쓰기가 잦은 데이터는 Write-Behind로 처리해 성능을 확보하는 경우가 많다. 실제로는 두 전략을 데이터 특성에 따라 혼합해서 사용하는 것이 현실적인 접근이다.