학습 목표
- 캐싱 전략을 제대로 설계하기의 역할과 적용 조건을 설명할 수 있다.
- 공개 AI 모델 목록의 허용 지연을 6시간으로 정하고 개인 데이터와 분리하세요.
- 적중률·외부 요청 수·DB 읽기 수를 비교하고 정기 기록이 필요하면 별도 스케줄을 설계하세요.
사전 지식
앞선 서버 사용량과 비용 줄이기를 먼저 읽으면 용어를 이해하기 쉽습니다. 이미 아는 내용이면 이 장부터 시작해도 됩니다.
개념 이해
캐시는 자주 찾는 결과를 가까운 곳에 잠시 보관하는 복사본입니다. 복사본을 믿어도 되는 시간과 잘못된 복사본을 지우는 방법까지 정해야 안전한 캐시입니다.
브라우저·메모리·서버·CDN
브라우저는 한 사용자의 응답을, 메모리는 한 실행 프로세스 안의 결과를, 서버 저장소는 여러 실행이 공유할 결과를, CDN은 지역별 공개 응답을 보관합니다. 프로세스 메모리는 재시작하면 사라집니다.
Redis·Local Storage·IndexedDB
Redis는 서버 공유 임시 저장·잠금의 선택지입니다. Local Storage는 작은 문자열 설정에, IndexedDB는 더 큰 구조화 오프라인 데이터에 쓰입니다. 브라우저 저장은 로그인 비밀의 안전한 금고가 아닙니다.
HTTP Cache-Control과 TTL
TTL은 재사용 가능한 수명입니다. public 응답과 개인 응답을 분리하고 사용자 데이터에는 private 또는 no-store 등 목적에 맞는 정책을 선택합니다. no-cache는 저장 금지가 아니라 재사용 전 검증 요구입니다.
Cache First·Network First
Cache First는 복사본을 먼저 읽어 빠르지만 오래된 값을 주의해야 합니다. Network First는 최신값을 먼저 요청해 연결 실패 시 대체를 검토합니다.
Stale While Revalidate
오래된 값을 먼저 주고 뒤에서 갱신하는 방식입니다. 조회성 정보에는 유용하지만 권한·잔액·주문 확정처럼 오래된 값이 위험한 판단에 그대로 적용하면 안 됩니다.
Cache Invalidation
수정·삭제·권한 변경·스키마 변경 때 해당 키를 제거하거나 버전을 올립니다. TTL만 기다려도 되는지 서비스 요구로 판단합니다.
동시 요청과 Cache Stampede
만료 직후 여러 서버가 한꺼번에 외부 요청을 보내는 현상입니다. 프로세스 내 진행 Promise 공유와 서버 간 임대 잠금, 제한된 재시도·만료 분산으로 줄일 수 있습니다.
영구 캐시와 정기 수집
Firestore 같은 저장소는 재시작 후에도 남지만 정기 실행은 별도입니다. 방문할 때 갱신하는 캐시는 방문 없는 날의 히스토리를 수집하지 않습니다.
오래된 캐시·개인정보·적중률
마지막 성공 시각과 재시도 시각을 구분하고 대체 가능한 데이터만 오래된 값을 사용합니다. 사용자 키·권한별 캐시를 분리하며 적중률은 재사용/전체 조회로 관찰합니다.
방문자 A → 서버 캐시 확인 → 유효함 → 저장된 결과 반환
↘ 없음/만료 → 갱신 잠금 확인
↘ 갱신자 1개 → 외부 API
↓
응답 검증·영구 저장
↓
방문자 B·C → 서버 캐시 확인 ────────────────→ 6시간 재사용
외부 API 장애 → 마지막 정상 캐시 + 수집 시각 + 오류 안내실제 사용 사례
비효율적인 AI 순위는 A·B·C가 접속할 때마다 외부 API를 부릅니다. 개선한 흐름은 A가 영구 캐시를 확인하고 만료 시 한 번 수집한 뒤 6시간 저장합니다. B·C는 저장 결과를 읽고 외부 장애 때 마지막 정상값과 시각을 표시합니다.
단계별 실습
실습은 운영 서비스가 아닌 별도 연습 프로젝트에서 진행하세요. 기존 파일이 있다면 변경 전 기록을 남깁니다.
- 공개 AI 모델 목록의 허용 지연을 6시간으로 정하고 개인 데이터와 분리하세요.
- 요청→메모리 확인→영구 캐시 확인→만료 잠금→외부 수집→검증→저장 흐름을 그리세요.
- 잠금 소유자·만료·타임아웃을 정하고 늦은 실행자가 최신 결과를 덮지 못하게 하세요.
- Cache-Control과 데이터 버전, 수정 시 무효화 규칙을 적으세요.
- 동시 방문·서버 재시작·외부 장애·키 변경·캐시 만료를 각각 확인하세요.
- 적중률·외부 요청 수·DB 읽기 수를 비교하고 정기 기록이 필요하면 별도 스케줄을 설계하세요.
코드와 프롬프트
아래 코드는 공개 통계 응답에서 재사용 수명을 안내하는 예시이며 개인 정보에는 적용하지 않는 환경의 예시입니다. 실제 프로젝트의 버전과 기존 구성을 확인한 뒤 필요한 부분만 적용하세요.
Cache-Control: public, max-age=60, s-maxage=300
Content-Type: application/json아래 요청에서 대괄호 부분을 내 프로젝트에 맞게 바꾼 뒤 AI 도구에 전달하세요.
[공개 API] 결과를 서버에서 6시간 캐싱해줘. 메모리와 영구 저장을 구분하고 동시 요청 잠금·만료·늦은 실행 차단·오류 시 정상 캐시·수집 시각·다음 갱신을 설계해줘. 개인 데이터는 공유 캐시에서 제외하고 방문 기반 캐시와 예약 수집의 차이, 무효화·적중률 확인 방법을 설명해줘.자주 발생하는 문제와 해결
| 문제와 원인 | 해결 방법과 확인 기준 |
|---|---|
| 만료될 때 외부 요청이 폭증함 | 인스턴스 간 잠금과 캐시 재확인으로 갱신자를 제한합니다. |
| 다른 회원의 결과가 보임 | 개인 응답을 공유 캐시에 넣지 말고 인증·권한 경계별 키와 저장 정책을 검토합니다. |
| 오래된 데이터로 영원히 정상처럼 표시함 | 원본 수집 시각과 오류·재시도 상태를 명확히 표시합니다. |
핵심 요약
- 복사본의 수명·무효화·보안 범위를 함께 정합니다.
- 프로세스 내 중복 제거만으로 여러 서버의 동시 요청을 막을 수 없습니다.
- 캐시와 시계열 기록 저장은 목적이 다릅니다.
완료 확인
참고자료
확인 기준일: 2026-10-20. 요금·사용 한도·제품 기능·설정 경로는 변경될 수 있으므로 작업 직전 공식 문서와 설치 버전을 확인하세요.