Caching

상품 목록처럼 하루에 수십만 번 읽히지만 실제로 바뀌는 경우는 드문 데이터를 매번 데이터베이스에서 가져온다고 생각해 보십시오. 쿼리 하나당 수십 밀리초가 쌓이면 응답 시간이 늘어나고, 트래픽이 몰리면 데이터베이스가 먼저 한계에 닿습니다. 데이터베이스를 더 크게 늘리면 비용이 올라가고, 읽기 복제본을 추가해도 인기 데이터에 대한 중복 쿼리는 줄지 않습니다. 반복 읽기 부하를 원본 시스템 바깥에서 흡수하지 않으면 규모가 커질수록 읽기 비용이 선형적으로 올라갑니다.

초기 웹 서비스는 모든 요청을 데이터베이스 직접 조회로 처리했고, 그것만으로도 충분했습니다. 서비스 규모가 커지면서 읽기 트래픽이 쓰기보다 훨씬 많아졌고, 같은 데이터를 수백 개 요청이 동시에 조회하는 패턴이 반복됐습니다. 데이터베이스를 수직 확장하는 방식만으로는 비용과 지연을 함께 해결하기 어렵다는 것이 분명해졌습니다. 읽기 경로를 원본 앞에 놓는 캐시 계층이 그 대안으로 자리 잡았고, 지금은 대부분의 대규모 서비스에서 캐시가 없으면 쓰기보다 읽기가 더 큰 병목이 됩니다.

요청이 들어오면 먼저 캐시에 해당 키가 있는지 확인합니다. 있으면 그 값을 바로 반환하고, 없으면 원본 저장소에서 읽어 캐시에 채운 뒤 반환합니다. 캐시된 값에는 수명이 있어서 일정 시간이 지나거나 명시적으로 무효화하면 다음 요청이 원본에서 다시 채웁니다. 데이터가 얼마나 자주 바뀌는지, 오래된 데이터를 어디까지 허용할지에 따라 TTL과 무효화 전략을 다르게 설정합니다.

Caching과 CQRS는 모두 읽기 성능 문제와 관련되지만 접근이 다릅니다. Caching은 기존 데이터 모델을 그대로 유지한 채 읽기 경로를 단축하는 기법입니다. CQRS는 읽기와 쓰기의 데이터 모델 자체를 분리해, 읽기에 최적화된 별도 표현을 유지하는 설계 방식입니다. 조회 빈도가 높고 데이터 구조는 단순한 경우라면 캐시가 충분하지만, 읽기 요구가 쓰기 모델과 완전히 달라지거나 읽기 전용 표현을 항상 최신으로 유지해야 할 때는 캐시만으로 해결하기 어렵습니다.

같은 데이터를 짧은 시간 안에 여러 요청이 반복 조회하고 약간의 지연된 갱신을 감당할 수 있는 상황이라면 캐시 도입을 고려할 시점입니다. 상품 정보, 사용자 프로필, 설정 값, 홈 화면 집계처럼 자주 읽히지만 실시간 정확도가 절대적이지 않은 데이터가 대표적입니다. 반대로 잔액, 재고, 예약 가능 좌석처럼 최신 정확도가 중요한 데이터에 TTL을 길게 두면 오래된 값을 보여주는 문제가 생깁니다. 캐시를 쓰기 시작하면 언제 비울지, 어디에 둘지, 캐시가 빠졌을 때 원본에 요청이 한꺼번에 몰리는 현상을 어떻게 방지할지까지 운영 관점에서 함께 결정해야 합니다.