개발을 하다 보면 “캐시를 붙여야겠다”라는 말을 자주 듣습니다.
저도 최근에 프로젝트를 하면서 Redis 캐싱을 고민하다 보니, 문득 “그런데 캐시라는 게 본질적으로 뭘까?”라는 질문이 생겼습니다.
캐시, 왜 필요한 걸까?
캐시(Cache)는 한마디로 “자주 쓰이는 데이터를 더 빨리 꺼내오기 위해 임시로 저장해두는 공간”입니다.
보통 우리가 원하는 데이터는 DB나 외부 API 같은 비교적 느린 저장소에 있습니다.
매번 거기서 꺼내다 보면 속도도 느려지고, 트래픽이 몰리면 시스템이 버티지 못합니다.
그래서 “자주 쓰이는 것만 따로, 가까운 곳에, 빠르게 꺼낼 수 있게 두자” → 그게 바로 캐시의 탄생 이유입니다.
캐시의 위치
- CPU 캐시
→ L1/L2/L3 캐시 같은 하드웨어 차원. 메모리에서 가져오는 것보다 더 빠르게 CPU가 접근할 수 있음. - 웹 브라우저 캐시
→ 우리가 웹사이트를 들어갈 때, 이미지나 CSS 파일을 매번 새로 다운로드하지 않고 브라우저가 저장해뒀다가 보여줌. - 애플리케이션 캐시
→ 서버단에서 자주 조회되는 데이터를 Redis, Memcached 같은 인메모리 저장소에 저장. - CDN 캐시
→ 전 세계 사용자에게 콘텐츠를 빠르게 전달하기 위해, 가까운 CDN 서버에 이미지·동영상 파일을 복사해 둠.
즉, 캐시는 어디에 두느냐에 따라 다르게 불리고, 역할도 달라집니다.
캐싱 전략
캐시는 무조건 저장한다고 좋은 게 아닙니다.
오히려 잘못 쓰면 오래된 데이터를 보여주거나, 메모리를 과도하게 점유할 수도 있죠.
그래서 보통 아래 같은 전략을 씁니다.
- Cache Aside (Lazy Loading)
요청이 들어올 때 캐시 확인 → 없으면 DB 조회 후 캐시에 저장.
가장 흔한 방식. - Write Through
DB에 쓰는 순간 캐시에도 동시에 반영.
데이터 일관성은 좋아지지만, 쓰기 성능이 조금 느려질 수 있음. - Write Back
캐시에 먼저 쓰고 나중에 DB에 반영.
빠르지만, 캐시 장애 시 데이터 유실 위험이 있음.
캐시와 TTL
캐시에서 중요한 개념이 TTL(Time To Live)입니다.
데이터를 언제까지 유효하다고 볼 건지 정하는 거죠.
- TTL이 너무 짧으면 → 금방 만료돼서 캐싱 효과가 떨어짐.
- TTL이 너무 길면 → 오래된 데이터를 계속 보여줄 위험이 있음.
그래서 보통은 데이터 성격에 따라 다르게 줍니다.
예시: 뉴스 기사 캐시는 몇 분, 인기 게임 정보는 1시간, 사용자 프로필은 하루 등등.
결론
- 캐시는 본질적으로 “자주 쓰는 데이터를 더 가까이 두는 것”이다.
- 위치에 따라 CPU 캐시, 브라우저 캐시, CDN 캐시, 애플리케이션 캐시 등 다양한 형태가 있다.
- 전략과 TTL을 잘못 설계하면 오히려 문제가 될 수 있다.
- 캐싱은 성능을 넘어, 서비스 안정성까지 챙겨주는 중요한 기술이다.