[Optimization-2] 캐싱 개념 (2)

1. 들어가며

 앞서 캐싱의 기본적인 정의와 데이터 지역성에 대해 알아보았다. 이번 글에서는 백엔드 서버에서 캐싱을 도입하는 구체적인 이유와 어떤 데이터를 캐싱해야 하는지, 그리고 데이터의 일관성을 유지하기 위한 만료 정책에 대해 심층적으로 다루고자 한다.

---

2. 백엔드 서버에서 캐싱을 도입하는 이유

 백엔드 서버가 유저의 요청을 처리하는 과정에서 대부분의 데이터는 데이터베이스(DB)를 통해 조회된다. DB는 대량의 데이터를 안전하게 보관하고 관리하는 핵심 저장소이지만, 디스크 기반 저장소라는 물리적 한계로 인해 접근 속도가 상대적으로 느리다. 특히 복잡한 쿼리나 조인(Join) 연산이 포함된 경우 처리 시간은 더욱 길어진다.

 

 실제 서비스 환경에서는 수많은 사용자가 동시에 요청을 보내며, 이는 DB 접근 집중으로 이어진다. 트래픽이 증가할수록 DB 부하는 심화되고, 이는 전체 시스템의 병목 현상을 유발하여 성능 저하 및 서비스 장애의 원인이 된다. 이를 해결하기 위해 백엔드 서버는 메모리 기반의 캐시 시스템을 도입하여 다음과 같은 이점을 얻는다.

• 비용 절감: 복잡한 쿼리나 대량 데이터 처리는 많은 리소스를 소모한다. 캐싱을 통해 이러한 작업의 실행 횟수를 줄이면 DB 리소스를 절감할 수 있으며, 이는 특히 클라우드 환경에서 직접적인 비용 절감 효과로 이어진다.
• 성능 향상: 메모리 기반 캐시는 디스크 기반 DB보다 훨씬 빠른 조회가 가능하다. API 응답 속도가 개선되어 동일한 서버 자원으로도 더 많은 요청을 처리할 수 있다.
• 안정성 확보: 트래픽 급증 상황에서 캐싱은 DB 부하를 분산한다. 이를 통해 핵심 서비스의 지연이나 장애를 방지하고 일관된 성능을 유지할 수 있다.

궁극적으로 캐싱은 유저에게 더 빠른 응답과 안정적인 환경을 제공하여 사용자 경험(UX)을 극대화하는 역할을 한다.

---

3. 어떤 데이터를 캐싱해야 할까?

모든 데이터를 캐싱할 수는 없으므로 전략적인 선택이 필요하다. 데이터를 선정할 때 가장 먼저 고려해야 할 기준은 앞서 학습한 데이터 지역성(Data Locality)이다.

• 시간적 지역성: 최근 접근한 데이터는 다시 접근될 가능성이 높다.
• 공간적 지역성: 현재 접근한 데이터 주변의 데이터도 곧 접근될 가능성이 높다.

3.1. 캐싱 데이터 기준

실제 서비스 운영에서는 지역성 외에도 다음과 같은 추가 기준을 종합적으로 고려해야 한다.

판단 기준	설명
데이터 변경 빈도	얼마나 자주 데이터가 수정되는가?
데이터 생성 비용	데이터를 생성하거나 조회하는 데 복잡한 계산이 필요한가?
데이터 공유 가능성	다양한 유저나 시스템이 이 데이터를 공통으로 사용하는가?

 

3.2. 실제 캐싱 적합 데이터 사례

• 시간적 지역성이 높고 변경이 적은 데이터 (예: 뉴스 메인 페이지): 많은 사용자가 반복적으로 접근하며 갱신 주기가 일정(예: 10~30분)하므로 매우 이상적인 캐싱 대상이다. 단, 주식 시세처럼 변경이 너무 잦다면 캐시 효율이 떨어질 수 있다.
• 지역성은 낮지만 생성 비용이 높은 데이터 (예: 통계 대시보드): 접근 빈도는 낮을 수 있으나 매번 복잡한 집계 쿼리를 실행해야 하므로 캐싱의 이득이 크다. 최신 데이터가 아니어도 되는 경우 특히 효과적이다.
• 공간적 지역성이 나타나는 연관 데이터 (예: 상품 상세 정보와 옵션/태그): 상품 정보를 조회할 때 관련 태그나 옵션을 함께 묶어 캐싱하면 DB 추가 조회를 방지하고 로딩 속도를 높일 수 있다.
• 공유 가능성이 높은 데이터 (예: 공휴일 정보): 모든 유저와 시스템이 공통으로 활용하므로 한 번만 캐싱해두면 재사용 효율이 극대화된다.

---

4. 언제 캐시를 만료 시켜야할까?

 원본 DB의 데이터는 지속적으로 수정되지만 캐시 데이터가 그대로 남아 있다면 데이터 불일치 문제가 발생한다. 이는 유저에게 잘못된 정보를 제공하는 심각한 장애로 이어질 수 있으므로, 데이터 일관성을 위해서는 적절한 캐시 만료 정책(Cache Expiration)을 수립해야 한다.

4.1. TTL (Time To Live)

 캐시 생성 시점부터 일정 시간이 지나면 자동으로 삭제하는 방식이다. 설정이 간단하지만 원본 데이터의 변경을 실시간으로 반영하지 못한다는 단점이 있다.

4.2. 명시적 무효화 (Explicit Invalidation)

 원본 데이터가 변경되는 시점에 서버 로직에서 명시적으로 캐시를 삭제하는 방식이다. 데이터 정합성을 즉시 확보할 수 있으나, 서버가 데이터의 변경 시점을 정확히 감지할 수 있어야 한다.

• 감지 가능한 경우: API 호출을 통한 수정, 내부 어드민 페이지를 통한 수정.
• 감지 불가능한 경우: 외부 시스템이 DB를 직접 수정하는 경우.

4.3. 전략의 조합과 트레이드오프

 실무에서는 두 방식을 보완하여 사용한다. 실시간 감지가 가능한 변경은 명시적으로 무효화하고, 혹시 모를 감지 불가능한 변경이나 누락을 대비해 TTL을 설정하여 주기적으로 갱신되도록 한다.

주의: TTL이 너무 짧으면 정합성은 높아지나 캐시 미스(Cache Miss)가 빈번해져 성능이 저하된다. 반대로 길면 캐시 효율은 좋아지나 데이터 반영이 느려진다.

---

5. 캐싱 적용 여부 결정 가이드

 만약 데이터가 변경 즉시 반영되어야 하는데 일부 변경 경로를 감지할 수 없다면, 해당 데이터는 캐싱을 적용해서는 안 된다. 이 경우 성능보다 데이터 정합성이 우선이므로 항상 DB를 직접 조회해야 한다.