캐싱이란? AI 앱 빌더를 위한 쉬운 설명

캐싱은 가져오는 데 느리거나 비용이 많이 드는 것의 준비된 사본을 보관해 두는 것입니다. 그러면 같은 것에 대한 다음 요청을 그 사본에서 빠르게 응답할 수 있습니다. 저장된 사본을 캐시라고 합니다. 브라우저는 이미지를 캐시해서 두 번째 방문부터 사이트가 더 빨리 열리게 하고, 서버는 느린 데이터베이스 쿼리의 결과를 캐시해서 방문자마다 같은 쿼리를 다시 실행하지 않도록 합니다.

캐싱은 앱을 더 빠르고 저렴하게 운영하게 해 줍니다. 가장 큰 단점은 사본이 오래될 수 있다는 것입니다.

AI로 만들 때 캐싱이 중요한 이유

AI로 만든 앱에서 캐싱을 마주치는 경우는 세 가지입니다.

• "앱을 업데이트했는데 아직 예전 버전이 보여요." 가장 흔한 캐싱 상황이며, 보통 해롭지 않습니다. 브라우저나 CDN이 저장된 사본을 보여 주고 있는 것입니다.
• 속도. 페이지가 방문자마다 같은 숫자를 다시 계산하느라 느리다면, 결과를 캐시하는 것만으로 즉시 열리는 것처럼 느껴질 수 있습니다.
• 비용. 많은 AI 빌더와 호스팅 서비스는 컴퓨팅, 데이터베이스 시간, 외부 API 호출에 요금을 부과합니다. 방문자 1,000명이 같은 비용이 큰 요청을 보낸다면, 캐싱으로 한 번만 비용을 내면 됩니다.

기본 원리를 알면 도움이 되는 곳에서 캐싱을 요청할 수 있고, 캐싱 때문에 무언가가 이상해 보일 때 이를 알아챌 수 있습니다.

일상의 비유

바쁜 카페의 주방을 생각해 보세요.

매일 아침 바리스타는 주문이 들어올 때마다 원두를 갈아 커피를 내릴 수도 있습니다. 하지만 그러면 느립니다. 대신 핫플레이트 위에 드립 커피를 미리 준비해 둡니다. 대부분의 손님은 몇 초 만에 커피를 받습니다. 이것이 **캐시 적중(cache hit)**입니다. 커피가 다 떨어지면 누군가 새로 내립니다. 이것이 **캐시 미스(cache miss)**입니다.

그런데 커피는 오래 두면 맛이 떨어지므로, 카페에는 30분이 지난 커피 포트는 버린다는 규칙이 있습니다. 이 규칙이 캐시의 만료 시간입니다. 하루 종일 같은 포트를 두는 사람은 없을 것이고, 오트 우유에 설탕 세 개를 넣는 맞춤 주문을 미리 만들어 두는 사람도 없을 것입니다. 어떤 것은 아예 캐시하면 안 됩니다.

캐시가 있는 곳

한 번의 페이지 로드는 사용자와 가까운 곳부터 먼 곳까지 여러 캐시를 거칠 수 있습니다.

CDN(콘텐츠 전송 네트워크)은 사이트 파일을 위한 전 세계적인 캐시 네트워크라고 생각하면 됩니다.

캐시가 무엇을 보관할지 정하는 방식

모든 캐시는 같은 질문에 답해야 합니다.

• 무엇을 캐시할 수 있나요? 공개적이고 공유되는 데이터(상품 이미지, 블로그 글)는 캐시해도 됩니다. 개인 데이터(사용자의 계정 페이지, 메시지)는 공유 캐시에 절대 넣으면 안 됩니다.
• 얼마나 오래 보관하나요? 이를 TTL(Time to Live, 유효 기간)이라고 합니다. 로고는 1년 동안 캐시할 수 있고, 재고 수량은 30초 동안만 캐시할 수 있습니다.
• 어떻게 갱신되나요? 사본이 만료되어 다시 가져오거나, 데이터가 바뀔 때 앱이 의도적으로 사본을 제거합니다. 이를 **무효화(invalidation)**라고 합니다.

웹사이트에서는 서버가 Cache-Control 헤더를 사용해 파일마다 브라우저와 CDN에 캐시 방법을 알려 줍니다. 예를 들어 Cache-Control: max-age=3600은 "이 사본을 한 시간 동안 재사용해도 됩니다"라는 뜻입니다.

최신 빌드 도구는 정적 파일에 대해 가장 어려운 부분을 캐시 버스팅으로 해결합니다. 파일이 바뀔 때마다 app.3f9a2c.js처럼 지문이 붙은 새 이름을 얻습니다. 새 버전은 이름이 다르므로, 브라우저는 예전 이름을 오랫동안 캐시해도 괜찮습니다.

실제 예시: 상품 카탈로그

작은 온라인 상점이 있다고 해 봅시다. 홈페이지에는 데이터베이스에서 가져온 상품 50개와 가격, 재고가 보입니다. 또한 모든 주문을 대상으로 한 느린 계산이 필요한 "인기" 목록이 있습니다.

1. 이미지와 스크립트는 브라우저와 CDN이 오랫동안 캐시합니다. 새 빌드마다 바뀐 파일에 새 이름이 붙으므로 업데이트는 여전히 반영됩니다.
2. 인기 목록은 10분마다 한 번 계산되어 애플리케이션 캐시에 저장됩니다. 그 10분 동안 모든 방문자는 저장된 결과를 즉시 받습니다.
3. 가격은 짧은 시간 동안 캐시되며, 상품을 수정할 때마다 캐시가 지워집니다. 그래서 고객이 오래된 가격을 오래 보는 일이 없습니다.
4. 결제 단계의 재고는 절대 캐시하지 않습니다. 누군가 "구매"를 누르면 앱은 실제 데이터베이스를 확인하므로, 방금 품절된 상품을 판매할 수 없습니다.
5. 장바구니와 계정 페이지는 개인적인 정보이므로 공유 캐시에 저장하지 않습니다.

결과적으로 홈페이지는 빠르고, 데이터베이스는 훨씬 적은 작업을 하며, 돈이나 개인정보와 관련된 것은 절대 오래된 상태로 남지 않습니다.

핵심 용어

흔한 오해

• "캐싱은 항상 좋다." 잘못된 것을 캐시하면 실제 버그가 생깁니다. 예전 가격이 보이거나, 새 글이 나타나지 않거나, 최악의 경우 한 사용자의 개인 페이지가 다른 사용자에게 보일 수 있습니다. 신중하게 캐시하세요.
• "예전 버전이 보이면 업데이트가 실패한 것이다." 대개 실패한 것이 아닙니다. 무언가 고장 났다고 판단하기 전에 강력 새로고침(Windows는 Ctrl+Shift+R, Mac은 Cmd+Shift+R)이나 시크릿 창을 먼저 시도해 보세요.
• "캐싱으로 느린 앱이 고쳐진다." 캐싱은 반복되는 요청의 느림을 가려 줄 뿐입니다. 첫 번째 요청은 여전히 느리며, 근본 원인이 데이터베이스 인덱스 누락이라면 그것도 고쳐야 합니다.
• "가능한 한 오래 모든 것을 캐시해야 한다." 긴 캐시 시간은 바뀔 때 새 이름을 받는 파일에 적합합니다. HTML 페이지와 데이터는 더 짧은 시간이 안전합니다.
• "내 브라우저 캐시를 지우면 모든 사람에게 해결된다." 그것은 내 브라우저만 지웁니다. 방문자와 CDN 캐시에는 여전히 각자의 사본이 있습니다.

AI 빌더에게 요청할 내용

• "이 앱에서 느린 부분은 어디이고, 어떤 부분을 안전하게 캐시할 수 있나요?"
• "[인기 목록 / API 결과]를 [N]분 동안 캐시하고, 기반 데이터가 바뀌면 캐시를 지워 줘."
• "개인 정보나 계정 데이터가 있는 페이지는 CDN이나 공유 캐시가 저장하지 못하도록 해 줘."
• "지문이 붙은 정적 파일에는 긴 캐시 시간을, HTML에는 짧은 캐시 시간을 설정해 줘."
• "[외부 API]의 응답을 캐시해서 페이지를 열 때마다 호출하지 않도록 해 줘. 그리고 그 데이터가 얼마나 오래될 수 있는지 알려 줘."
• "게시한 뒤에 예전 버전이 보여요. 브라우저 캐시 문제인가요, 아니면 배포가 안 된 건가요?"

Mythex에서의 캐싱

Mythex 앱을 업데이트해서 게시한 뒤에는 CDN 캐시가 잠시 늦게 반영될 수 있으며, 공개 URL을 강력 새로고침하면 새 버전이 보인다고 문서에 나와 있습니다. 자세한 내용은 게시 방법을 참고하세요. 호스팅 한도 페이지도 정적 자산 캐싱을 권장합니다. 호스팅, 데이터베이스 시간, 대역폭은 크레딧 잔액에서 차감되기 때문입니다. 그 밖에 쿼리 결과나 API 응답을 캐시하는 것은 에이전트에게 앱에 구축하도록 요청하면 됩니다.

관련 글: CDN이란 무엇인가, 웹사이트 속도를 높이는 방법, 속도 제한이란 무엇인가.

자주 묻는 질문