한 번 만든 것을 다시 쓰기(캐시)
고쳤는데 화면이 안 바뀌는 미스터리의 팔 할이 이거예요. 컴퓨터가 한 번 만든 결과를 저장해 뒀다가 다시 내놓는 장치인데, 그 저장본이 어디에 사는지만 알면 대부분 풀려요.
쉽게 말하면
김밥집에서 주문이 들어올 때마다 밥을 새로 짓지는 않죠. 아침에 한 솥 지어서 보온밥솥에 담아 두고, 주문이 오면 바로 퍼 담아요. 그래서 빨라요. 캐시가 딱 이 보온밥솥이에요. 한 번 만든 결과를 저장해 뒀다가 다음 손님에게 바로 내놓는 거예요. 그런데 이 밥솥 때문에 사고도 나요. 레시피를 바꿔서 새 밥을 지어도, 밥솥에 어제 밥이 남아 있으면 손님은 어제 밥을 받아요. "분명히 고쳤는데 화면이 그대로"라는 미스터리가 바로 이 장면이에요.
캐시는 고장도 아니고 버그도 아니에요. 인터넷 전체가 빠르게 도는 이유가 캐시예요. 매번 처음부터 새로 만들면 손님은 느려서 떠나고, 서버는 일이 많아져서 비용이 늘어요. 그래서 컴퓨터들은 어디서든 "아까 만든 거 그대로 줘도 되지 않을까?" 를 먼저 생각해요.
그래서 캐시는 한 곳의 기능이 아니라 컴퓨터 세계의 습관이에요. 손님 폰도, 사이트를 실어 나르는 중간 거점도, 서버도, 심지어 AI도 같은 습관을 써요. 이 문서에서 "어디에 저장본이 사는지"를 지도처럼 그려 두는 이유가 그거예요. 습관은 같고, 사는 곳만 다르거든요.
새 밥을 지었는데 밥솥에 어제 밥이 남은 상황이에요. 저장본이 아직 안 죽은 거예요.
한 번 만든 걸 다시 내놓으니 빠르고, 서버가 일을 덜 해서 비용도 줄어요.
저장본은 네 군데에 살아요
"캐시를 지우세요"라는 말이 헷갈리는 이유는, 캐시가 한 군데가 아니라서예요. 내 사이트의 저장본은 보통 네 군데에 흩어져 살아요. 어디 것이 묵었는지에 따라 증상이 달라져요.
| 어디 | 무엇을 저장하나 | 묵으면 생기는 증상 |
|---|---|---|
| 손님 폰의 브라우저 | 한 번 본 화면의 그림·글꼴·꾸밈 파일 | 나는 새 화면을 보는데 그 손님만 옛 화면을 봐요 |
| 중간 배달 거점(CDN) | 전 세계에 복사해 둔 사이트 파일 | 게시 직후 몇 분간 지역·사람마다 새 것과 옛 것이 섞여 보여요 |
| 서버 | 미리 만들어 둔 페이지나 자주 꺼내는 데이터 | 가격·재고를 바꿨는데 사이트가 옛 숫자를 계속 보여줘요 |
| 내 폰의 앱·홈 화면 추가본 | 앱처럼 설치된 사이트가 통째로 담아 둔 판 | 인터넷을 껐다 켜도, 새로고침을 해도 유난히 오래 버텨요 |
핵심은 이거예요. 내 화면과 손님 화면이 다르면, 둘 중 하나가 고장 난 게 아니라 각자 다른 저장본을 보고 있는 거예요. 사장님은 아까 강력 새로고침을 해서 새 판을 받았고, 손님은 지난주에 받아 둔 판을 아직 들고 있는 것뿐이에요. 그래서 "저는 잘 보이는데요?"라는 말은 캐시 앞에서는 증거가 못 돼요. 중간 배달 거점이 궁금하면 CDN 문서에 따로 정리해 뒀어요.
네 군데 중 어디가 범인인지 사장님이 짚어낼 필요는 없어요. 다만 "저장본이 여러 군데에 있다"는 그림만 있으면, 뒤에 나오는 진단 순서가 왜 그 순서인지 이해돼요. 가장 가까운 저장본부터 하나씩 버려 보며 좁히는 것이거든요.
증상을 보면 주문이 나와요
사장님이 원인을 파고들 필요는 없어요. 증상을 알아보고, AI에게 맞는 문장을 건네는 것까지가 사장님 몫이에요. 아래 표를 그대로 복사해서 써도 돼요.
| 증상 | 먼저 해볼 것 | AI에게 말할 문장 |
|---|---|---|
| 고쳤는데 내 화면만 그대로예요 | 강력 새로고침(Ctrl+Shift+R), 또는 시크릿 창에서 열어 보기 | "방금 고친 게 화면에 반영이 안 돼요. 캐시 문제인지 확인해 주세요." |
| 내 화면은 새 건데 손님 화면이 옛것이에요 | 몇 분 기다렸다가 다시 확인 | "게시하면 손님 브라우저가 새 파일을 바로 알아보게 해 주세요." |
| 바꾼 가격·재고가 옛 숫자로 계속 보여요 | 다른 기기에서도 같은지 확인 | "가격과 재고는 캐시하지 말고 항상 최신 값을 보여 주세요." |
| 로그아웃했는데 아까 그 사람 정보가 보여요 | 즉시 고칠 문제로 취급하기 | "로그인한 사람의 개인 정보는 캐시에 저장되지 않게 해 주세요." |
| 글은 바뀌었는데 사진만 옛것이에요 | 그 사진만 강력 새로고침으로 확인 | "사진을 교체하면 옛 사진 저장본이 안 보이게, 새 파일로 올려 주세요." |
이 한 문장이 진단의 절반이에요
"시크릿 창에서는 잘 보이는데, 일반 창에서는 옛 화면이 보여요." 이렇게 말하면 듣는 쪽(AI든 개발자든)은 바로 알아들어요. 시크릿 창은 저장본 없이 새로 받아 오니까, 거기서 잘 보인다는 건 사이트는 멀쩡하고 저장본만 묵었다는 증거거든요.
손님이 "옛 화면이 보인다"고 연락해 오면 이렇게 안내하면 돼요. "확인해 보니 사이트는 정상이고, 폰에 이전 화면이 잠시 남아 있는 거예요. 잠시 후 다시 열어 보시면 최신으로 보여요." 사실이면서, 손님 탓도 내 탓도 아닌 말이에요. 그리고 같은 연락이 반복되면 그때는 손님 안내가 아니라 내 쪽에서 고칠 신호로 받아들여요.
실제로 겪는 장면
장면 1 · 가격을 올렸는데 손님이 옛 가격으로 주문했다
“어제 분명히 8,000원으로 바꿨는데, 손님 폰에는 아직 7,000원이래요. 그 가격으로 주문이 들어왔어요.”
손님 폰 브라우저가 며칠 전 저장본을 내놓은 거예요. 여기서 배울 건 하나예요. 가격·재고처럼 틀리면 돈이 걸리는 숫자는 캐시하면 안 되고, 로고·글꼴처럼 안 바뀌는 것만 캐시해야 해요. AI에게 "가격은 항상 최신으로, 꾸밈 파일만 캐시해 주세요"라고 말하면 그 분리를 해 줘요.
장면 2 · 외주 개발자가 말했다
“배포는 정상이에요. 캐시 때문에 그런 거니까 강력 새로고침 한번 해 보세요.”
이제 해석돼요. 사이트에 새 판을 올리는 건 성공했고, 사장님 브라우저가 옛 저장본을 붙들고 있을 뿐이라는 뜻이에요. 고장 신고를 이어갈 상황이 아니라, 내 쪽 저장본을 버리고 새로 받으면 끝나는 상황이에요.
장면 3 · 이벤트를 끝냈는데 배너가 계속 걸려 있다
“마감 지난 할인 배너를 어제 내렸는데, 오늘도 그 배너를 보고 전화한 손님이 있어요. 할인해 달라고요.”
손님 잘못도, 사이트 고장도 아니에요. 그 손님의 브라우저가 이벤트 기간에 받아 둔 저장본을 아직 쓰고 있는 거예요. 여기서 배울 건 기한이 있는 내용은 캐시가 오래 살지 않게 해 달라고 미리 주문하는 것이에요. "이벤트 배너처럼 기한 있는 내용은 캐시를 짧게 잡아 주세요"라고 말하면 돼요. 그리고 이미 벌어진 상황이라면, 배너에 적힌 기한을 근거로 안내하는 게 다툼을 줄여요.
3분 진단 순서
"고쳤는데 안 바뀌어요"가 오면 이 순서로 좁혀요. 가장 가까운 저장본(내 폰)부터 버리고, 점점 바깥쪽으로 나가는 순서예요.
- 1강력 새로고침을 해요. 컴퓨터는 Ctrl+Shift+R(맥은 Cmd+Shift+R)이에요. 일반 새로고침과 달리 저장본을 무시하고 전부 새로 받아 와요. 여기서 바뀌면 내 브라우저 저장본이 범인이었던 거예요.
- 2시크릿 창에서 열어 봐요. 저장본이 아예 없는 깨끗한 방이에요. 여기서 새 화면이 보이면 사이트는 정상이고, 손님들도 각자의 저장본이 만료되는 대로 새 화면을 받게 돼요.
- 3다른 기기(폰)로 열어 봐요. 다른 기기에서도 옛 화면이면 내 브라우저 문제가 아니라 중간 거점이나 서버 쪽 저장본이에요. 몇 분 기다렸다가 다시 봐요.
- 4그래도 그대로면 캐시가 아니에요. 수정한 판이 아예 안 올라간 것일 수 있어요. 배포가 실제로 성공했는지부터 확인해요.
4번이 중요해요. 캐시 탓을 하며 새로고침만 백 번 누르는 것보다, "이건 캐시가 아니구나"를 판정하고 다음으로 넘어가는 것이 진짜 실력이에요. 화면 안쪽을 직접 들여다보고 싶어지면 개발자 도구에 방법이 있어요.
지금은 신경 쓰지 않아도 되는 때
캐시는 알아두는 지식이지, 미리 손봐야 하는 숙제가 아니에요. 다음 경우라면 아무것도 안 해도 돼요. 강력 새로고침 한 번으로 해결됐고 다시 안 생기면 그걸로 끝이에요. 원인 규명 회의를 열 일이 아니에요.
혼자 만드는 중이라면 캐시 설정을 고민할 때가 아니에요. 만들고 고치는 동안 겪는 "안 바뀌어요"는 새로고침으로 넘기면 되고, 캐시를 어떻게 저장할지 정하는 일은 손님이 몰려서 느려질 때의 이야기예요. 그때 가서 캐시 전략을 읽으면 돼요. 게시 직후 몇 분간 새 것과 옛 것이 섞여 보이는 것도 정상이에요. 전 세계 배달 거점에 새 판이 퍼지는 데 시간이 조금 걸리는 거라, 기다리면 저절로 풀려요.
| 상황 | 지금 할 일 |
|---|---|
| 강력 새로고침 한 번으로 해결됐다 | 없어요. 끝난 일이에요 |
| 게시 직후 몇 분간만 옛것과 섞여 보인다 | 없어요. 기다리면 저절로 풀려요 |
| 아직 손님 없이 혼자 테스트 중이다 | 없어요. 캐시 설정은 손님이 생긴 뒤 일이에요 |
| 가격·재고가 옛 숫자로 계속 보인다 | 있어요. 위 표의 문장으로 AI에게 주문해요 |
| 같은 증상이 손님에게서 반복된다 | 있어요. 이건 넘기지 말고 고쳐야 해요 |
겁먹고 캐시를 다 꺼 달라고 하지 마세요
옛 화면이 보이는 게 무서워서 "캐시 전부 꺼 주세요"라고 주문하면 더 나쁜 결과가 나와요. 사이트가 눈에 띄게 느려지고 서버 비용이 늘어요. 보온밥솥이 미덥지 않다고 주문마다 밥을 새로 짓는 가게가 되는 거예요. 끄는 게 아니라 가려서 담는 것(바뀌는 건 캐시 금지, 안 바뀌는 건 캐시)이 정답이에요.
헷갈리기 쉬운 것
캐시 = 쿠키? 아니에요. 캐시는 화면 재료의 저장본이고, 쿠키는 "이 손님이 누구인지"를 적어 둔 쪽지예요. 캐시가 묵으면 옛 화면이 보이고, 쿠키가 지워지면 로그인이 풀려요. 증상이 다르니 이름을 구분해서 말하면 도움받기가 훨씬 빨라져요.
캐시 = 백업? 이것도 달라요. 둘 다 "복사본을 둔다"는 점은 같지만 목적이 반대예요. 백업은 잃어버리면 안 돼서 오래 보관하는 복사본이고, 캐시는 언제 지워져도 아무 문제 없는 복사본이에요. 캐시가 지워지면 조금 느려질 뿐, 원본은 서버에 멀쩡히 있어요. 그래서 "캐시를 지우면 데이터가 날아가나요?"의 답은 "아니요"예요.
캐시 = 임시저장? 문서 앱의 임시저장은 내가 쓰던 초안을 지켜 주는 기능이고, 캐시는 컴퓨터가 속도를 위해 알아서 하는 살림이에요. 임시저장은 사라지면 내 글이 날아가지만, 캐시는 사라져도 잃는 게 없어요. 캐시는 지워도 되는 것, 이 감각 하나만 가져가도 반은 안 거예요.
자주 묻는 것
- Q. 손님들에게 "캐시를 지워 주세요"라고 안내해도 되나요?
- 안 하는 게 좋아요. 손님 백 명에게 부탁하는 것보다 한 번 고치는 게 빨라요. AI에게 "파일이 바뀌면 손님 브라우저가 새 파일로 알아보게 해 주세요"라고 말하면, 손님이 아무것도 안 해도 새 화면을 받게 만들 수 있어요.
- Q. 캐시를 지우면 로그인도 풀리나요?
- 보통은 안 풀려요. 캐시는 화면 재료(그림·꾸밈 파일)의 저장본이고, 로그인 상태는 쿠키라는 다른 서랍에 살아요. 다만 브라우저 설정에서 지울 때 "쿠키도 함께"에 체크하면 같이 지워져서 로그인이 풀려요. 둘은 다른 물건이에요.
- Q. 새로고침과 강력 새로고침은 뭐가 다른가요?
- 새로고침은 "다시 보여줘"라서 저장본이 있으면 저장본을 또 내놔요. 강력 새로고침은 "저장본 버리고 전부 새로 받아 와"예요. 그래서 캐시 의심 상황에서는 강력 새로고침이 기본기예요.
- Q. 얼마나 기다리면 손님들도 새 화면을 보게 되나요?
- 저장본에는 유통기한이 있어서, 기한이 지나면 브라우저가 알아서 새로 받아 와요. 기한은 파일마다 다르게 정해져 있어요. 다행히 요즘 만드는 방식은 내용이 바뀌면 파일 이름 자체를 바꿔 버려서, 게시만 되면 손님이 기다릴 것 없이 새 파일을 받는 경우가 대부분이에요.
- Q. 바이브캠퍼스에서 만들면 캐시 설정을 제가 직접 해야 하나요?
- 미리 만질 건 없어요. 기본 상태로 시작하고, 이 문서의 증상이 실제로 나타났을 때 표의 문장으로 주문하면 돼요. 캐시는 설정 화면을 외우는 지식이 아니라, 증상이 왔을 때 알아보는 지식이에요.
- Q. AI 비용을 아끼는 캐시도 있다던데요?
- 있어요. AI에게 매번 똑같이 들려주는 앞부분을 저장해 뒀다 다시 쓰면 요금이 크게 줄어요. 원리는 이 문서와 같지만 사는 곳이 달라서 프롬프트 캐싱에 따로 정리해 뒀어요.
- Q. 제 폰에서는 홈 화면에 추가한 사이트가 유난히 안 바뀌어요.
- 홈 화면에 추가한 사이트는 앱처럼 통째로 저장본을 들고 있는 경우가 있어서 제일 오래 버텨요. 앱을 완전히 닫았다 다시 열거나, 그래도 안 되면 한 번 지우고 다시 추가하면 새 판을 받아 와요.
- Q. 폰에서는 강력 새로고침 단축키가 없는데 어떻게 하나요?
- 폰 브라우저에는 그 단축키가 없어서 시크릿 창(사파리는 개인 정보 보호 모드)으로 열어 보는 게 제일 간단해요. 그래도 확인이 안 되면 브라우저 설정에서 이 사이트의 데이터만 지우는 방법도 있어요. 전부 지울 필요 없이 사이트 하나만 골라서 지울 수 있어요.
확인해 보세요
화면을 고쳤는데 일반 창에서는 옛 화면이 보이고, 시크릿 창에서는 새 화면이 잘 보여요. 무슨 뜻일까요?
하나 더
다음 중 캐시에 저장하면 안 되는 것은 뭘까요?
직접 해보기
직접 겪어 보는 게 제일 빨라요
스튜디오에서 만들던 것의 문구를 하나 바꾸고 미리보기를 확인해 보세요. 바로 안 바뀌는 것 같으면 오늘 배운 순서(새로고침, 그다음 판정)를 그대로 써 보는 거예요. 한 번 겪어 두면 실전에서 안 당황해요.
스튜디오 열기더 깊이 (안 읽어도 괜찮아요)
저장본에도 유통기한이 있어요 · 모든 저장본에는 "몇 초 동안 유효"라는 기한이 붙어요. 기한 안이면 브라우저는 서버에 물어보지도 않고 저장본을 내놓고, 기한이 지나면 "이거 아직 쓸 만해요?" 하고 서버에 확인해요. 그래서 아무것도 안 해도 시간이 지나면 저절로 풀리는 캐시 문제가 많은 거예요. 기한을 얼마로 두는지가 캐시 전략의 핵심 결정이에요.
파일 이름을 바꿔 버리는 꾀 · 제일 우아한 해법은 저장본을 지우는 게 아니라 무의미하게 만드는 거예요. 내용이 바뀔 때마다 파일 이름 자체를 새 이름으로 바꿔서 올리면, 옛 저장본은 이름이 다른 남남이 되니까 손님 브라우저가 자연히 새 파일을 받아 와요. 신메뉴를 옛 메뉴판에 덧칠하는 대신 메뉴판을 통째로 새로 거는 방식이에요. 요즘 만들기 도구들은 대부분 이걸 자동으로 해 줘요.
"캐시 히트"라는 말 · 저장본이 있어서 바로 내놓는 데 성공하면 히트, 없어서 새로 만들면 미스라고 불러요. 개발자가 "히트율이 높다"고 하면 손님 대부분이 저장본을 받아 서버가 한가하다는 뜻이라 칭찬에 가까운 말이에요. 반대로 히트율이 낮다는 말은 캐시가 일을 못 하고 있다는 신호예요.
이것만 기억하세요
- ·캐시는 한 번 만든 결과를 다시 내놓는 보온밥솥이에요. 빠름의 비결이자 "안 바뀌어요"의 팔 할이에요
- ·저장본은 손님 브라우저, 중간 거점, 서버, 내 폰 네 군데에 살아요
- ·진단은 강력 새로고침, 시크릿 창, 다른 기기 순서로 좁혀요. 다 아니면 캐시가 아니라 배포 문제예요
- ·가격·재고처럼 바뀌는 숫자는 캐시 금지, 로고·글꼴처럼 안 바뀌는 것만 캐시해요
- ·새로고침 한 번으로 해결됐다면 그걸로 끝이에요. 캐시를 다 끄는 건 오답이에요