조용한 개발 노트

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