로컬 캐시와 분산 캐시는 어떤 기준으로 선택해야 할까요?

[haeyoon1]

로컬 캐시는 애플리케이션 메모리에 저장되는 캐시입니다.
분산 캐시는 Redis처럼 별도의 캐시 서버에 데이터를 저장하고 여러 애플리케이션 인스턴스가 같은 캐시를 공유하는 방식입니다.

두 방식의 장단점을 비교하여 각각 어떤 상황에서 적용하면 좋을지 의견을 듣고 싶습니다!

[koreaioi]

저는 얼마나 데이터 일관성을 지켜야하는 가?를 우선으로 생각합니다.
(각 서버마다 같은 데이터를 봐야하는가?)
지금은 데이터 불일치로 인한 동기화 문제가 가장 큰 비용이라고 생각하거든요!

그리고 난 뒤 데이터 변경 여부, 캐시 생존주기, 속도, 인프라 비용를 고민해볼 거 같아요

---

로컬 캐시는 속도가 빠르고, 외부 장애로 부터 독립적입니다. 그러나, 서버가 많아질 경우, 각 서버가 가지는 로컬 캐시 데이터가 달라지는 문제가 발생할 수 있습니다.

데이터 변경이 거의 없고, 각 서버마다 완벽한 데이터 일관성을 지키지 않아도 된다면, 로컬 캐시가 유리하다고 생각합니다!

• ex 전날의 Top 10 주제 목록, 지원서의 질문들 etc...

분산 캐시는 모든 서버가 하나의 캐시 서버를 바라보기 때문에, 데이터 불일치 문제가 일어나지 않습니다. 그러나 외부에 있기 때문에 네트워크 I/O가 필히 발생하고, 인프라 관리 비용이 커집니다.

데이터 변경이 잦거나, 각 서버마다 데이터 일관성이 지켜져야한다면 분산 캐시를 사용하는 게 좋다고 생각합니다.

• ex 선착순 이벤트, RefreshToken

---

보충

• 로컬 캐시는 어플리케이션 내부 메모리에 접근해 네트워크 I/O가 없음.
• 변경이 잦으면 분산캐시가 낫다고 생각하는 이유: 동기화 책임을 한 곳에 둘 수 있음.

[softmoca]

저는 로컬 캐시와 분산 캐시의 선택을 "어느 게 더 빠른가" 또는 "어느 게 더 확장성 있는가"로 보면 본질을 놓친다고 생각합니다.

본질은 이 캐시가 보호하려는 데이터의 일관성을 어디까지 보장해야 하는가, 그리고 어디까지 유효해야 하는가입니다.

이전 격리 수준 토론에서 정리했듯, 캐시도 결국 동시 접근 상황에서 정합성과 성능 사이의 트레이드오프를 다루는 도구이고, 로컬과 분산은 그 트레이드오프를 푸는 방향이 다릅니다.

그래서 둘 중 무엇을 쓸지는 데이터가 인스턴스마다 달라도 괜찮은가, 모두 같아야 하는가라는 질문에서 출발해야 한다고 봅니다.

1. 캐시가 푸는 본질 문제부터

로컬·분산을 비교하기 전에 캐시 자체가 무엇을 푸는지 짚으면 선택 기준이 명확해진다고 생각합니다.

캐시는 자주 읽히지만 자주 안 변하는 데이터를 더 빠른 저장소에 미리 둬서, 원본(DB·외부 API) 접근 비용을 줄이는 도구입니다.

이게 의미하는 바는 캐시를 쓰는 순간 두 군데에 같은 데이터가 살게 된다는 점입니다.

DB의 진실과 캐시의 사본 — 이 둘이 어긋날 가능성이 늘 존재합니다. 캐시 설계의 본질은 이 어긋남을 어떻게 통제할 것인가라고 생각합니다.

그리고 이 어긋남의 위험은 사본이 몇 개인가에 따라 달라집니다. 로컬 캐시는 인스턴스마다 사본이 있으니 N개, 분산 캐시는 중앙 1개. 이 차이가 두 방식의 거의 모든 트레이드오프를 만들어냅니다.

2. 로컬 캐시 — 인스턴스 안의 메모리

각 애플리케이션 인스턴스가 자기 JVM 힙(또는 가까운 메모리)에 데이터를 저장하는 방식입니다. ConcurrentHashMap, Caffeine, Ehcache(로컬 모드) 등이 흔히 쓰입니다.

private final Cache<Long, Theme> themeCache = Caffeine.newBuilder()
        .maximumSize(1000)
        .expireAfterWrite(Duration.ofMinutes(10))
        .build();

public Theme getTheme(Long id) {
    return themeCache.get(id, k -> themeRepository.findById(k));
}

강점

• 가장 빠르다: 같은 JVM 안의 메모리 접근. 네트워크 비용 0
• 인프라가 단순하다: 별도 서버·운영 부담 없음
• 외부 의존성이 없다: 캐시 서버 장애에 영향받지 않음
• 직렬화 비용이 없다: 객체를 그대로 둠

약점

• 인스턴스마다 사본이 다를 수 있다: 서버 A는 가격이 5,000원으로 캐싱, 서버 B는 6,000원으로 캐싱 → 같은 사용자가 새로고침할 때마다 다른 가격을 본다
• 메모리 한계: JVM 힙을 공유하므로 캐시가 커지면 GC 영향
• 재시작 시 캐시 증발: 워밍업 필요
• 무효화가 어렵다: "이 데이터 바뀌었어"를 모든 인스턴스에 알리려면 별도 메커니즘(메시지 큐, 이벤트 브로드캐스트)이 필요

이 약점 중에서 저는 인스턴스마다 사본이 다를 수 있다가 가장 본질적이라고 봅니다. 나머지는 운영으로 대응 가능하지만, 이건 로컬 캐시의 본성이라 해결이 어렵습니다.

3. 분산 캐시 — 중앙의 캐시 서버

Redis, Memcached 같은 별도 서버에 데이터를 두고, 모든 애플리케이션 인스턴스가 그 서버를 공유합니다.

public Theme getTheme(Long id) {
    String key = "theme:" + id;
    Theme cached = redisTemplate.opsForValue().get(key);
    if (cached != null) return cached;
    
    Theme theme = themeRepository.findById(id);
    redisTemplate.opsForValue().set(key, theme, Duration.ofMinutes(10));
    return theme;
}

강점

• 모든 인스턴스가 같은 데이터를 본다: 일관성 보장
• 무효화가 쉽다: 캐시 키 하나만 지우면 모든 인스턴스가 다음 접근에서 새 값을 받음
• 메모리 풀이 분리됨: JVM 힙과 무관, GC 영향 없음
• 재시작 후에도 유지: 인스턴스 재배포해도 캐시 살아있음
• 풍부한 자료구조: Redis는 Set/SortedSet/Hash 등 다양한 구조 제공

약점

• 네트워크 비용: 캐시 접근에 RTT가 더해진다 (보통 1~5ms 추가, 그래도 DB보다는 훨씬 빠름)
• 직렬화 비용: 객체를 바이트로 변환해야 함. JSON, Protobuf 등 직렬화 방식 결정 필요
• 추가 인프라: Redis 서버 운영·모니터링·HA 구성 필요
• 장애 영향: 캐시 서버가 죽으면 모든 인스턴스가 영향받음 (그래서 회로 차단기 패턴이 필요)
• 비용 증가: 별도 인스턴스 비용

저는 분산 캐시의 핵심 가치를 일관성 보장으로 봅니다. 빠른 메모리 저장소라는 측면만 보면 로컬도 가능하지만, 여러 인스턴스가 같은 진실을 본다는 보장은 분산만 줄 수 있습니다.

4. 비교표

항목	로컬 캐시	분산 캐시
접근 속도	가장 빠름 (ns~μs)	네트워크 RTT (ms 단위)
인스턴스 간 일관성	보장 안 됨	보장
메모리 위치	JVM 힙	별도 서버
재시작 시	증발	유지
무효화	어렵다 (브로드캐스트 필요)	쉽다 (키 하나 삭제)
외부 의존성	없음	Redis 등 필요
운영 부담	낮다	높다 (HA, 모니터링)
직렬화	불필요	필요
GC 영향	있음	없음

이 표가 보여주는 건 둘이 강함·약함으로 줄 세워지지 않는다는 점입니다. 로컬은 빠르지만 일관성이 약하고, 분산은 일관성이 강하지만 인프라 부담이 크고 네트워크 비용이 있습니다.

둘은 다른 트레이드오프를 푸는 도구입니다.

5. 선택 기준 — 데이터의 성격으로 갈라본다

저는 데이터 성격을 다음 축으로 봅니다.

(a) 인스턴스 간 일관성이 필수인가?

가장 핵심 질문입니다. "같은 사용자가 새로고침할 때마다 다른 값을 봐도 괜찮은가?"

• 불일치가 사용자 경험을 깬다 → 분산 캐시. 예: 장바구니, 회원 권한, 잔액
• 불일치를 잠시 허용해도 된다 → 로컬 캐시 가능. 예: 메뉴 목록, 상품 카테고리, 환율(분 단위 갱신)

(b) 데이터가 얼마나 자주 변경되는가?

• 거의 안 변경됨 → 로컬 캐시가 유리. TTL 길게 두고 인스턴스 간 불일치 위험 최소화
• 자주 변경됨 → 분산 캐시. 무효화 비용이 핵심이 된다
• 실시간성 필수 → 캐시 자체를 재검토 (캐시가 적합한가?)

(c) 데이터가 사용자별인가, 공용인가?

• 사용자별 세션·임시 데이터: 분산 캐시가 자연스럽다. 로드 밸런서가 어느 서버로 보내든 같은 데이터를 봐야 함
• 모든 사용자가 같이 보는 공용 데이터: 둘 다 가능. 일관성 vs 속도로 결정

(d) 캐시 미스 비용이 얼마나 큰가?

• DB 한 번 조회면 충분 → 로컬 캐시 정도로도 충분
• 외부 API 호출 등 비싼 작업 → 분산 캐시로 인스턴스 간 중복 호출 방지

6. 흔히 만나는 시나리오별 선택

시나리오 1. 사용자 세션·로그인 상태

• → 분산 캐시. 로드 밸런서가 어느 서버로 보내도 로그인 상태 유지되어야 함
• 이건 sticky session으로 우회할 수도 있지만, 분산 캐시 쪽이 일반적

시나리오 2. 자주 안 변하는 마스터 데이터 (카테고리, 코드성 데이터)

• → 로컬 캐시. 변경이 거의 없으니 인스턴스 간 미세한 시점 차이 무시 가능
• TTL을 길게 두고, 갱신 시 모든 인스턴스 캐시 만료 처리

시나리오 3. 자주 조회되는 도메인 데이터 (상품 정보, 테마 정보)

• → 상황에 따라. 가격처럼 정확해야 하는 데이터는 분산, 설명·이미지처럼 미세한 시점 차이가 무관한 데이터는 로컬
• 또는 2단 캐시: L1=로컬, L2=분산

시나리오 4. 인기 게시글 조회수, 좋아요 수

• → 분산 캐시 (보통 Redis). 모든 인스턴스가 같은 카운터를 갱신해야 함
• Redis의 INCR 같은 원자 연산 활용

시나리오 5. 회원 권한, 잔액, 재고

• → 분산 캐시 또는 캐시 안 씀. 정합성이 핵심인 데이터는 캐시 자체를 신중히 고려

시나리오 6. 인증 토큰 블랙리스트

• → 분산 캐시 필수. 어느 서버에서 로그아웃해도 모든 서버가 알아야 함

7. 2단 캐시 — 둘을 결합하기

저는 실무에서 흔히 보는 패턴이 둘을 결합하는 것이라고 생각합니다. 일관성이 어느 정도 필요하면서도 속도가 중요할 때, 로컬을 L1, 분산을 L2로 두는 방식입니다.

요청 → L1 (로컬) → 있으면 반환
                 → 없으면 L2 (Redis) → 있으면 L1에 저장 후 반환
                                     → 없으면 DB → L2 → L1

장점

자주 쓰는 데이터는 로컬에서 빠르게, 그 외엔 분산을 통해 일관성 확보

단점

복잡도가 증가, L1 무효화 메커니즘 필요 (Redis Pub/Sub 등)

이 패턴은 강력하지만 그만큼 복잡도가 큽니다. 정말 필요한 경우에만 도입하는 게 좋다고 봅니다.

8. 캐시 자체에 대한 경계 — "캐시는 공짜가 아니다"

저는 캐시를 도입하기 전에 한 번 더 묻는 편이 좋다고 생각합니다.

(a) 진짜 캐시가 필요한가?

• 인덱스 추가로 해결될 일은 아닌가?
• 쿼리 튜닝으로 충분하지 않은가?
• 캐시 도입 시 발생할 복잡도(무효화, 일관성 관리)가 그 이득을 넘는가?

(b) 캐시 일관성 문제를 감당할 수 있는가?

• "캐시와 DB가 어긋난 짧은 순간"이 발생해도 비즈니스가 안전한가?
• 그 어긋남이 사용자 신뢰를 깨지 않는가?

(c) 캐시 무효화 전략이 있는가?

• "두 가지 어려운 문제: 캐시 무효화와 이름 짓기"라는 유명한 농담이 있을 만큼, 무효화는 어렵습니다
• TTL, 명시적 삭제, 이벤트 기반 무효화 — 무엇을 쓸지 결정해야 한다

캐시는 강력하지만 부수 복잡도가 큰 도구입니다. "성능이 필요하니까"가 아니라 "이 데이터의 특성상 캐시가 자연스럽다"라는 근거가 있을 때 도입하는 게 좋다고 봅니다.

9. 미션 관점에서 보면

이번 예약 대기 미션 범위에서는 캐시가 꼭 필요한 자리가 많지 않다고 생각합니다. 그래도 만약 도입한다면 이런 식이 될 것 같습니다.

도입 후보 1. 테마 정보 조회

• 자주 조회되고 거의 안 변경되는 데이터
• 단일 서버라면 로컬 캐시(Caffeine 등)로 충분
• 다중 서버라면 로컬도 가능하지만, 가격 변경 같은 정합성이 중요하면 분산 캐시

도입 후보 2. 인기 테마 조회

• 집계 비용이 크지만 자주 조회됨
• 분산 캐시가 자연스러움. 모든 인스턴스가 같은 순위를 보여야 함
• TTL 짧게(1분 정도) 두고 주기적으로 재계산

도입 안 함 — 예약/대기 데이터

• 정합성이 매우 중요한 데이터. 캐시 도입 시 위험이 큼
• DB 인덱스로 조회 성능을 확보하는 게 우선

이번 미션 단계에서는 캐시 도입보다 트랜잭션·동시성·인덱스를 명확히 다루는 게 먼저라고 생각합니다. 캐시는 그 위에 얹는 도구입니다.

10. 정리

로컬 캐시와 분산 캐시는 속도 vs 확장성의 트레이드오프가 아니라, 인스턴스마다 다른 진실을 허용할 것인가, 모든 인스턴스가 같은 진실을 보아야 하는가의 트레이드오프다.

핵심 정리:

• 캐시 자체의 본질은 "DB와 캐시 사이의 어긋남을 어떻게 통제할 것인가"
• 사본이 N개냐(로컬) 1개냐(분산)가 거의 모든 차이를 만든다
• 로컬은 빠르지만 인스턴스 간 일관성을 못 준다. 자주 안 변하고 미세한 차이가 무관한 공용 데이터에 적합
• 분산은 일관성 보장과 무효화 용이성을 주지만 네트워크·인프라 비용이 든다. 세션, 정확성이 중요한 데이터에 적합
• 둘을 결합한 2단 캐시도 흔한 패턴이지만 복잡도가 큼
• 캐시는 강력하지만 부수 복잡도가 큰 도구. 성능이 필요해서가 아니라 이 데이터의 특성상 자연스러워서 도입하는 게 좋다

선택 기준 한 줄:

• 인스턴스 간 일관성이 필수인가 → 분산
• 거의 안 변하고 인스턴스 간 미세한 차이가 무관한가 → 로컬
• 둘 다 필요하면 → 2단 캐시 (단, 복잡도 감수)

결국 캐시 선택은 데이터의 성격을 먼저 진단하고 도구를 역산하는 일이라고 생각합니다. 이전 토론들에서 반복적으로 정리한 "도구가 아닌 본질에서 출발하라"의 원칙이 캐시에서도 그대로 적용된다고 봅니다.

[Uechann]

로컬 캐시와 분산 캐시 개념

로컬 캐시

애플리케이션 프로세스 (JVM 힙) 안에 데이터를 두는 캐시이다.
Caffeine, Ehcache, Guava Cache, 단순하게는 ConcurrentHashMap이 여기에 해당된다.
캐시가 애플리케이션과 같은 메모리 공간을 쓰기 때문에 네트워크를 타지 않는다.

분산 캐시

Redis, Memcached처럼 애플리케이션 바깥에 독립된 캐시 서버를 두는 방식이다.
여러 인스턴스가 네트워크를 통해 같은 캐시 저장소를 바라보므로, 캐시가 인스턴스가 아니라,
서버 클러스터에 속하게 된다.

핵심적인 두 차이는 캐시가 어디에 존재하는가 이다.
로컬은 인스턴스 안에, 분산은 인스턴스 밖에 존재한다.

---

왜 사용 할까?

캐시의 목적은 비싼 연산(DB 연산, 외부 API 호출, 복잡한 계산)의 결과들을 저장해서 반복되는 비용을 줄이는 것이다.

애플리케이션을 여러 인스턴스로 스케일아웃하면서 로컬 캐시만으로 풀 수 없는 문제가 발생한다.

• 인스턴스 A가 캐시한 값을 인스턴스 B는 모른다.
  즉, 같은 요청이 인스턴스마다 다른 응답을 줄 수 있다. → 캐시 불일치
• 인스턴스가 10개라면 같은 데이터가 10개로 중복 저장된다. → 메모리 낭비
• 애플리케이션을 재배포하면 캐시가 통째로 날아감 → cold start

분산 캐시는 이렇듯 여러 인스턴스가 캐시를 공유해야 하는 문제를 풀기 위해서 등장하였다.
반대로 로컬 캐시는 네트워크 한 번도 타지 않는 극한의 속도가 필요할 때 사용한다.

---

언제 무엇을 사용해야 할까?

로컬 캐시 사용해야 할 때

• 거의 변하지 않는 참조 데이터
  • 테마 목록, 운영 시간대
• 인스턴스 간 약간의 불일치를 허용할 수 있을 때
  • 인기 테마 랭킹, 조회수 통계
• 데이터의 크기가 작고, 저지연이 필요할 때
  • JWT 서명 검증용 공개키
• 인프라를 단순하게 단일 인스턴스를 사용해야할 때

분산 캐시를 사용해야 할 때

• 인스턴스 간 일관성이 중요할 때 (세션, 로그인 상태, 재고 수량)
  • 로그인 세션으로 로드밸런서가 요청들에 따라서 인스턴스를 다르게 보낼텐데,
    세션이 로컬에 있다면 다른 인스턴스에서는 로그인이 안됨
  • 인기 시간대 테마의 재고/잔여 좌석
• 데이터가 자주 바뀌고 변경이 즉시 모든 인스턴스에 반영돼야 할 때
  • 실시간 예약 가능 여부
• 캐시 데이터가 커서 힙에 두기 부담스러울 때
  • 사용자가 많아서 수십만 명의 사용자 세션 저체
• 재배포, 재시작과 무관하게 캐시가 살아있어야 할 때
  • 세션을 로컬에 두면 배포할 때마다 전체 사용자가 로그아웃이 된다.

보통은 둘중 하나가 아니라, 다 계층적으로 함께 사용하는 경우가 많다고 한다.
로컬에서도 Caffeine 캐시를 사용하고, 분산에서도 Redis를 사용하여서,
로컬에서도 찾고 없다면 Redis, 그래도 없다면 DB로 가는 구조로 한다고 한다.

[sangjun121]

저도 마찬가지로 데이터 일관성이 얼마나 중요한지를 기준으로 결정할 것 같습니다.

로컬 캐시는 인스턴스마다 캐시를 하나씩 들고 있기 때문에, 속도는 빠르지만 여러 서버가 같은 데이터를 봐야 하는 상황에서는 동기화 비용이 부담됩니다. 반대로 분산 캐시는 네트워크와 운영 비용이 들지만 모든 인스턴스가 같은 데이터를 바라볼 수 있습니다.

1. 서비스 정책이나 로직이 인스턴스 간 데이터가 달라도 괜찮은 경우: 로컬 캐시 사용
   (예를 들어, 카테고리, 테마 목록, 공지사항처럼 자주 바뀌지 않는 조회 데이터)

2. 모든 인스턴스가 같은 데이터를 봐야 하는 경우: 분산 캐시 사용
   (예를 들어, 로그인 시, Refresh Token, 로그인 세션, 재고, 선착순 이벤트 즉, 정합성이 중요한 경우)

결과적으로 캐시는 복사본을 떠, 조회 성능을 높이는 도구이기 때문에 어디에 캐시를 둘지보다는 비즈니스 정책이 데이터가 오래된 값을 반환해도 괜찮은가를 기준으로 결정해야 할 것 같습니다.

실무에서는 둘 중 하나만 사용하는 것보다 L1(Caffeine) + L2(Redis)처럼 2단 캐시도 많이 사용한다고 합니다. 개인적으로는 복잡도가 꽤 올라가기 때문에 실제 병목이 확인된 이후에 도입하는 것이 좋다고 생각합니다.