캐시 언제 써야 할까 — 빨라지지만 틀려지는 트레이드오프

"좀 더 빠르게 해주세요"의 함정

기획자가 개발자에게 가장 자주 하는 요구 중 하나가 "이 화면 좀 더 빠르게 안 될까요?"입니다. 그럴 때 개발팀에서 자주 나오는 답이 **캐시(cache)**입니다. "캐싱하면 빨라져요." 여기까지는 좋습니다. 문제는 캐시가 공짜가 아니라는 데 있습니다. 속도를 얻는 대신, 데이터가 옛날 값이 될 위험을 함께 삽니다. 그래서 진짜 물어야 할 질문은 "캐시 쓸까 말까"가 아니라 캐시 언제 써야 하고 언제 피해야 하는가입니다.

이 글은 코드를 몰라도 되는 선에서, 기획자·PM이 이 판단을 내리는 기준을 정리합니다. 캐시는 개발자만의 선택이 아니라, "얼마나 최신이어야 하는가"를 정하는 기획의 결정이기 때문입니다.

캐시란 — 자주 쓰는 걸 가까이 미리 꺼내두기

캐시는 어렵지 않습니다. 자주 꺼내 쓰는 것을 가까운 곳에 미리 복사해 두는 것입니다. 매번 서랍 깊은 곳(원본 데이터베이스)까지 다녀오는 대신, 책상 위(빠른 저장소)에 사본을 놔두고 그걸 씁니다. 그러면 응답이 훨씬 빨라집니다.

일상에도 캐시가 있습니다. 자주 쓰는 비밀번호를 매번 서류함에서 찾지 않고 머릿속에 외워 두는 것, 자주 보는 서류를 서랍이 아니라 책상 앞에 두는 것 — 전부 캐시의 발상입니다. 웹 서비스도 똑같습니다. 매 요청마다 무거운 계산을 다시 하거나 DB를 다시 뒤지는 대신, 한 번 만든 결과를 잠깐 보관해 두고 재사용합니다.

왜 빨라지고, 왜 틀려지나

캐시의 이득과 위험은 동전의 양면입니다.

빨라지는 이유는 분명합니다. 원본까지 가는 먼 길을 건너뛰고 가까운 사본을 쓰니까요. 무거운 계산 한 번을 아껴 수천 명에게 재사용하면 서버 부담도 줄어듭니다.

틀려지는 이유도 같은 데서 옵니다. 사본을 놔둔 사이에 원본이 바뀌면, 캐시는 여전히 옛날 값을 들고 있습니다. 이걸 "stale(오래된) 데이터"라고 부릅니다. 상품 가격을 캐시해 뒀는데 그 사이 가격이 올랐다면, 사용자는 낡은 가격을 봅니다. 캐시의 모든 사고는 결국 이 한 문장으로 요약됩니다 — 원본은 변했는데 사본은 안 변했다.

캐시 언제 쓰면 좋은가

캐시가 잘 맞는 데이터에는 공통점이 있습니다. 자주 읽히고, 자주 바뀌지 않는 것들입니다.

• 자주 조회되는 정보: 인기 상품 목록, 공지사항, 메인 화면 구성처럼 많은 사람이 반복해서 보는 것.
• 잘 바뀌지 않는 데이터: 카테고리 목록, 국가·지역 코드, 약관처럼 하루에 몇 번 바뀔까 말까 한 것.
• 무거운 계산 결과: 통계 집계, 추천 목록처럼 만드는 데 비용이 크지만 결과는 한동안 유효한 것.
• 조금 늦어도 괜찮은 것: 방문자 수, 좋아요 수처럼 몇 초 옛날 값이어도 사용자가 문제 삼지 않는 것.

이런 데이터는 캐시의 이득(속도)은 크고 위험(stale)은 작습니다. 넣는 게 거의 언제나 이득입니다.

캐시 언제 피해야 하나

반대로 캐시가 위험한 데이터도 뚜렷합니다. 항상 정확해야 하거나, 시시각각 바뀌는 것들입니다.

• 실시간 정확성이 중요한 값: 계좌 잔액, 재고 수량, 결제 금액. 옛날 값을 보여주면 곧바로 사고입니다. 재고를 캐시했다가 품절인데 "구매 가능"으로 보이면 주문 사고로 이어집니다.
• 사람마다 다른 개인정보: 남의 캐시가 섞이면 A의 정보가 B에게 보이는 대형 사고가 납니다. 개인화된 데이터는 특히 조심해야 합니다.
• 자주 바뀌는 데이터: 1초에도 여러 번 바뀌는 값은 캐시해 봐야 곧 stale이 되어, 얻는 속도보다 관리 비용이 큽니다.

이런 경우엔 "빠르게"보다 "틀리지 않게"가 우선입니다. 캐시가 필요하면 아주 짧게만 두거나, 원본이 바뀌는 순간 사본을 버리는 장치를 함께 설계해야 합니다.

기획자·PM이 정해야 할 것 — "얼마나 최신이어야 하나"

여기서 핵심은, 캐시의 성패를 가르는 결정이 기술이 아니라 기준이라는 점입니다. 기획자가 정해야 할 것은 딱 하나로 요약됩니다 — 이 데이터는 얼마나 최신이어야 하는가. 이걸 세 가지 질문으로 쪼개면 판단이 쉬워집니다.

허용 지연을 정한다

"이 숫자는 5분 옛날 값이어도 되나, 아니면 반드시 실시간이어야 하나?" 이 한 줄이 캐시 설계의 출발점입니다. 5분 허용이면 캐시를 5분 두고, 실시간이 필수면 캐시를 안 쓰거나 즉시 갱신합니다. 개발자에게 "빠르게"만 요구하지 말고, 허용 지연을 숫자로 함께 건네면 대화가 명확해집니다.

언제 사본을 버릴지 정한다 (무효화)

가격이 바뀌면, 재고가 줄면, 글이 수정되면 — 그 순간 캐시를 버리도록 정해 둬야 합니다. 이 "무효화 시점"을 빠뜨리면 stale 사고가 납니다. 어떤 이벤트가 일어났을 때 사본을 새로 고쳐야 하는지를, 기획 단계에서 목록으로 정리해 두면 좋습니다.

틀렸을 때의 피해를 잰다

좋아요 수가 몇 초 틀린 건 애교지만, 잔액이 틀리면 재앙입니다. 피해가 클수록 캐시를 짧게, 또는 아예 안 씁니다. 속도의 이득과 stale의 피해를 저울에 함께 올려 보는 습관이 판단의 기준이 됩니다.

이 세 가지는 폴백(fallback)이라는 안전망을 정할 때와 똑같은 결의 판단입니다 — "정상이 아닐 때 무엇을 보여줄지"를 기획이 정하듯, "얼마나 최신이어야 하는지"도 기획이 정합니다.

표로 보는 — 캐시가 맞는 데이터 vs 안 맞는 데이터

구분	잘 맞는 데이터	안 맞는 데이터
변경 빈도	드물게 바뀜 (카테고리, 약관)	시시각각 바뀜 (잔액, 재고)
정확성 요구	조금 늦어도 OK (조회수)	항상 정확해야 함 (결제 금액)
대상	모두에게 같은 값	사람마다 다른 개인정보
판단	캐시 이득 큼 → 적극 활용	stale 위험 큼 → 짧게 또는 미사용

캐시는 빠름과 정확함 사이의 다이얼

캐시 언제 써야 할까의 답을 한 줄로 줄이면 이렇습니다. 캐시는 켜고 끄는 스위치가 아니라, 빠름과 정확함 사이를 조절하는 다이얼입니다. 자주 읽고 덜 바뀌고 조금 늦어도 되는 데이터 쪽으로 다이얼을 돌리면 이득이고, 항상 정확해야 하는 데이터 쪽에서는 다이얼을 내려야 합니다.

그리고 그 다이얼을 어디에 둘지는 기술이 아니라 기준의 문제입니다. "이 데이터는 얼마나 최신이어야 하는가"를 기획자가 또렷하게 답할 수 있으면, 개발자는 그에 맞는 캐시를 설계합니다. 이 판단은 결제·주문에서 중복을 막는 멱등성처럼, 눈에 안 보이지만 서비스의 신뢰를 좌우하는 결정입니다. 다음에 "빠르게 해주세요"라고 말하기 전에, "이건 얼마나 최신이어야 하지?"를 먼저 자문해 보세요.