Caching

같은 데이터를 계속 원본 저장소에서 읽으면 응답 시간이 길어지고 저장소 부하가 빠르게 올라갑니다. 특히 인기 데이터가 반복 조회되는 서비스에서는 읽기 트래픽이 원본 시스템을 압박합니다. 그렇다고 원본을 포기할 수는 없으니, 자주 필요한 값을 더 가까운 곳에 잠시 붙잡아 두고 싶어집니다. Caching은 바로 그 읽기 병목을 완화하기 위한 기법입니다.

웹 서비스가 커지면서 대부분의 요청이 읽기 중심이고, 그중 상당수가 비슷한 데이터를 반복해서 조회한다는 사실이 분명해졌습니다. 저장소를 무조건 더 크게 만드는 방식만으로는 비용과 지연 문제를 모두 해결하기 어려웠습니다. 그래서 원본 정합성은 유지하되, 읽기 경로를 더 가깝게 두는 캐시 계층이 거의 기본 전술처럼 자리 잡았습니다.

애플리케이션은 먼저 캐시에서 값을 찾고, 없으면 원본 저장소에서 읽어 와 캐시에 채웁니다. 이때 TTL이나 무효화 전략으로 오래된 데이터를 얼마나 오래 허용할지 결정합니다. 핵심은 원본을 없애는 것이 아니라, 반복 조회 경로를 더 짧고 싸게 만드는 데 있습니다.

Caching과 CQRS는 둘 다 읽기 성능 문제를 다룰 수 있지만 수준이 다릅니다. Caching은 원본 모델을 유지한 채 자주 보는 데이터를 가까이에 복사하는 기법이고, CQRS는 아예 읽기 모델과 쓰기 모델을 구조적으로 분리하는 방식입니다. 즉 캐시는 빠른 우회로에 가깝고, CQRS는 읽기/쓰기 모양 자체를 다시 설계하는 쪽에 가깝습니다.

상품 조회, 설정 값, 세션 주변 데이터, 홈 화면 요약처럼 반복 읽기가 많고 약간의 지연된 갱신을 감당할 수 있는 장면에서 Caching은 매우 효과적입니다. 다만 캐시를 넣는 순간 언제 비울지, 얼마나 오래 믿을지라는 운영 질문이 생깁니다. 따라서 속도 이점과 데이터 신선도 사이의 균형을 구조적으로 판단해야 합니다.

다음에 볼 개념

함께 보면 좋은 개념