캐시
Cache
캐시란?
- 자주 쓰는 데이터를 가까이 미리 저장
- 다음에 더 빠르게 꺼냄
- 속도의 핵심 기법
캐시가 바꾸는 것은 데이터를 어디서 가져오느냐가 아니라, 누가 언제까지 그 사본을 진짜라고 믿느냐입니다. 캐시를 쓰는 순간 시스템 안에는 원본과 사본이라는 두 개의 진실이 생기고, 운영자는 응답 속도와 정보의 최신성 중 무엇을 먼저 볼지를 골라야 합니다. 그래서 캐시 설정은 개발자만의 기술 결정이 아니라 몇 분까지 옛 정보를 보여줘도 되는가라는 업무 기준의 문제이고, 가격·재고처럼 틀리면 돈이 나가는 화면일수록 현업이 그 기준에 개입해야 합니다.
캐시는 한 곳이 아니라 층으로 쌓입니다. 사용자 브라우저, 그 앞단의 CDN, 서버의 메모리 저장소(Redis 등), DB 조회 결과가 각각 따로 사본을 들고 있습니다. 보관 기간은 Cache-Control의 max-age나 TTL 값으로 초 단위로 지정하는데, 잘 안 바뀌는 이미지·폰트는 며칠에서 1년, 가격·재고처럼 수시로 바뀌는 값은 30~60초로 잡는 식입니다. 한 층만 지워서는 화면이 바뀌지 않는다는 점이 실무에서 가장 자주 걸리는 대목입니다. 로그인 상태를 담는 세션이나 쿠키와는 성격이 달라서, 캐시는 지워져도 업무가 멈추지 않아야 한다는 것이 설계의 전제입니다.
현장에서 어긋나는 지점은 대개 '제 화면에서는 정상인데요'라는 한마디입니다. 담당자가 강력 새로고침으로 자기 브라우저 사본만 지우고 배포 완료로 보고하면, CDN에 남은 옛 사본 때문에 고객 수만 명은 며칠 지난 공지나 잘못된 가격을 계속 보게 됩니다. 반대로 불안하다고 캐시를 전부 꺼 버리는 선택도 위험합니다. 트래픽이 몰리는 시간에 모든 요청이 DB로 직행하면서 응답이 늘어지고, 속도 문제가 장애로 번집니다. 안전한 쪽은 캐시를 끄는 것이 아니라 바뀐 파일만 새 주소로 만들어 내보내는 방식입니다.
컴퓨터가 느린 저장장치의 병목을 줄이기 위해 빠른 임시 저장소를 두던 하드웨어 기법에서 출발해, 웹·소프트웨어 전반의 성능 최적화 원리로 확장됐습니다.
가상의 사례로 살펴보겠습니다. 임직원 240명, 연매출 약 800억 원 규모의 생활용품 유통사 A사는 자사몰에서 월 12만 건의 주문을 처리합니다. 3월 봄 프로모션 첫날 할인가를 적용해 배포했는데, 고객센터에 '화면 가격과 결제 금액이 다르다'는 문의가 두 시간 만에 180건 들어왔습니다.
- 이커머스팀 김 과장이 자기 PC에서 상품 페이지를 열어 보고 '할인가 12,900원 정상인데요'라고 했지만, 고객이 보낸 캡처 화면에는 정가 18,000원이 그대로 찍혀 있었습니다.
- 개발팀 이 팀장이 접속 로그를 확인하니 전체 요청의 87%가 서버까지 오지 않고 CDN에서 처리되고 있었고, 상품 상세 페이지 TTL이 24시간으로 걸려 있었습니다.
- 이 팀장이 CDN 콘솔에서 상품 상세 경로만 골라 캐시를 강제 삭제하자, 15분 뒤 관련 문의가 시간당 90건에서 6건으로 줄었습니다.
- 재발을 막기 위해 가격·재고가 들어가는 페이지는 TTL을 60초로 낮추고, 이미지와 폰트는 30일을 유지하되 파일명에 배포 버전값을 붙이는 규칙을 넣었습니다.
- 다음 달 여름 프로모션 배포에서는 가격 오표시 문의가 0건이었고, 캐시 적중률 91%를 유지한 덕에 첫 화면 로딩은 1.8초에서 1.9초로 사실상 그대로였습니다.