조용한 개발 노트

이 글은 Spring Cache 공식 문서를 기반으로 진행한 1~8편 내용을 하나의 판단 프레임으로 정리한 마무리 편입니다.Spring Cache는 “쓰는 법”보다 “쓰면 안 되는 순간을 아는 것”이 더 중요합니다. 이 글의 목적은 그 경계를 명확히 하는 것입니다.들어가며지금까지 이 시리즈에서는 다음 질문들을 반복해서 던졌습니다.이 데이터는 캐시해도 되는가?캐시는 언제 틀려도 괜찮은가?캐시가 사라져도 시스템은 버틸 수 있는가?9편에서는 이 질문들을 한 번에 판단할 수 있는 형태로 정리합니다.1. Spring Cache가 잘 맞는 문제 영역Spring Cache는 다음 조건을 만족할 때 가장 강력합니다.메서드 결과를 단순히 재사용하고 싶다캐시 적용 여부를 선언적으로 표현하고 싶다캐시 구현체를 나중에 바꿀 ..

이 글은 Spring Cache 공식 문서를 기반으로, 지금까지 정리한 Cache Abstraction의 한계를 짚고, “언제 Spring Cache를 쓰지 말고 직접 Redis를 써야 하는가”를 설계 기준으로 정리합니다.Spring Cache는 매우 강력하지만, 모든 캐시 문제의 정답은 아닙니다. 이 편은 그 경계를 명확히 하는 데 목적이 있습니다.들어가며Spring Cache를 쓰다 보면 이런 고민이 생깁니다.TTL을 상황에 따라 다르게 주고 싶다캐시 만료를 이벤트 기반으로 제어하고 싶다여러 키를 한 번에 다루고 싶다이 시점부터 Spring Cache는 점점 답답해집니다. 이건 설계 실수가 아니라, Spring Cache가 의도한 역할을 벗어났다는 신호입니다.1. Spring Cache가 해결하려는 ..

이 글은 Spring Cache 공식 문서와 실무에서 반복적으로 발생하는 장애 사례를 바탕으로, “처음엔 좋아 보였지만 결국 문제를 만든 캐시 설계 패턴”을 정리합니다.캐시는 대부분 의도는 선하고 결과는 나쁜 형태로 실패합니다. 이 안티 패턴들은 캐시를 아예 쓰지 말자는 이야기가 아니라, 언제 멈춰야 하는지를 알려주는 신호들입니다.안티 패턴 1. 캐시를 Source of Truth처럼 사용하는 경우가장 위험한 캐시 사용 방식입니다.DB보다 캐시를 먼저 신뢰캐시 없이는 정상 동작 불가처음엔 이렇게 시작합니다.조회 성능이 너무 중요하다캐시 히트율이 거의 100%다하지만 어느 순간,Redis 장애캐시 flushTTL 설정 실수중 하나가 발생하면, 서비스 전체가 마비됩니다.캐시가 없으면 서비스가 죽는다면, 그건..

이 글은 Spring Cache 공식 문서를 기반으로, 지금까지 살펴본 Cache Abstraction, @Cacheable, Transaction, 동시성, Provider 선택 내용을 설계 체크리스트 형태로 정리합니다.캐시는 기술 문제가 아니라 설계 판단 문제입니다. 이 글의 질문에 명확히 답할 수 있다면, 캐시는 성능 도구가 되고, 그렇지 않다면 장애 포인트가 됩니다.들어가며캐시는 보통 이런 상황에서 등장합니다.DB 부하가 높다응답 시간이 느리다트래픽이 늘어났다하지만 이 시점은 이미 문제가 발생한 이후인 경우가 많습니다. Spring 공식 문서의 관점은 다릅니다.Cache is a performance optimization, not a core design element.즉, 캐시는 문제 해결의 ..

이 글은 Spring Framework Cache Abstraction 공식 문서와 Spring Boot Cache 자동 설정 문서를 기반으로, 실무에서 가장 자주 마주치는 질문인 “Caffeine과 Redis 중 무엇을 선택해야 하는가”를 설계 관점에서 다시 정리합니다.들어가며Spring Cache를 도입할 때 가장 흔한 출발점은 다음과 같습니다.이미 Redis가 있으니까 캐시도 Redis로 쓰자분산 캐시가 로컬 캐시보다 항상 더 좋아 보인다하지만 Spring 공식 문서의 관점은 다릅니다. Spring Cache는 특정 기술을 권장하지 않으며, 캐시의 성격에 따라 구현체를 선택하라고 말합니다.이 글의 목적은 단순 비교가 아니라, “이 캐시는 어디까지 믿어도 되는가”를 기준으로 선택 기준을 명확히 하는 ..

이 글은 Spring Framework 공식 문서(Cache Abstraction)를 기반으로 캐시 환경에서 가장 자주 발생하는 동시성 문제와 @Cacheable(sync = true) 옵션의 실제 의미를 정리합니다.들어가며캐시를 도입하면 성능이 좋아질 것이라 기대합니다. 하지만 트래픽이 몰리는 순간, 캐시는 오히려 장애의 시작점이 되기도 합니다.캐시가 비어 있는 상태에서 동시에 수십 개의 요청이 몰림모든 요청이 DB를 동시에 때림캐시는 있는데 DB 부하가 더 커짐이 현상을 일반적으로 Cache Stampede라고 부릅니다.1. Cache Stampede란 무엇인가Cache Stampede는 다음 조건이 동시에 만족될 때 발생합니다.캐시 미스 상태동시에 여러 스레드가 동일한 키를 조회캐시를 채우는 비용이..

이 글은 Spring Framework 공식 문서(Cache Abstraction)를 기반으로 캐시와 트랜잭션이 함께 있을 때 실제로 어떤 순서로 동작하는지를 정리합니다. 특히 @Transactional과 @Cacheable, @CacheEvict가 겹칠 때 발생하는 오해를 호출 흐름 중심으로 설명합니다.들어가며캐시와 트랜잭션이 함께 등장하는 순간, 개발자는 본능적으로 이렇게 기대합니다.트랜잭션이 커밋되면 캐시도 반영될 것이다롤백되면 캐시는 자동으로 되돌려질 것이다하지만 Spring Cache 공식 문서는 이 기대를 명확히 보장하지 않습니다. 캐시와 트랜잭션은 서로 다른 책임을 가진 독립적인 메커니즘이기 때문입니다.1. Spring Cache는 트랜잭션을 “알지 못한다”공식 문서 관점에서 가장 중요한 전..

이 글은 Spring Framework 공식 문서(Cache Abstraction)를 기반으로 @Cacheable이 실제로 언제 동작하고, 어떤 경우에 동작하지 않는지를 호출 흐름 중심으로 정리합니다.들어가며Spring Cache를 쓰다 보면 이런 경험을 하게 됩니다.분명 @Cacheable을 붙였는데 캐시가 안 된다한 번은 캐시가 되고, 한 번은 안 된다로컬에서는 되는데 운영에서는 다르게 동작한다이런 문제의 대부분은 캐시 설정이 아니라, @Cacheable의 실제 실행 시점과 조건을 정확히 이해하지 못해서 발생합니다.1. @Cacheable은 “메서드 실행 전”에 동작한다Spring 공식 문서는 @Cacheable의 동작을 명확하게 설명합니다.The caching abstraction applies c..

이 글은 Spring Framework 공식 문서(Cache Abstraction)를 기반으로 “왜 Spring은 Cache를 추상화했는가”를 설계 관점에서 정리합니다.들어가며캐시는 대부분의 서버 애플리케이션에서 성능 최적화의 마지막 카드처럼 사용됩니다. 하지만 Spring 공식 문서를 읽다 보면, 캐시는 단순한 성능 옵션이 아니라 애플리케이션 설계의 일부로 다뤄집니다.Spring은 왜 Redis, EhCache, Caffeine 같은 구체적인 기술 대신 Cache Abstraction이라는 계층을 만들었을까요?이 질문에 대한 답을 이해하지 못하면, Spring Cache는 곧 이렇게 사용됩니다.“조회 느리니까 @Cacheable 붙이자”“Redis 있으니까 그냥 캐시 쓰는 거지”이 글에서는 공식 문서가..