캐싱

캐싱은 만들기 비싼 데이터를 빠른 저장소에 복사해 두고 다음 요청에 재사용하는 기법이다. 캐시는 사용하는 쪽과 데이터베이스, 외부 API, 모델 같은 느린 원본 사이에 놓인다. 모든 캐시에는 만료 규칙과 축출 정책이 필요하다. 속도의 대가가 낡은 데이터이기 때문이다. TTL 설정, 쓰기 시점의 명시적 무효화, 키 네임스페이스 분리가 기본 장치다. Redis와 Memcached는 애플리케이션 데이터를 담는 공유 인메모리 캐시로 쓰이고, Cloudflare 같은 CDN은 정적 파일을 사용자 가까이에 둔다. LLM 서비스도 같은 발상을 쓴다. 프롬프트 캐싱은 긴 시스템 프롬프트의 앞부분을 저장해 반복 호출에서 연산을 건너뛰고, 시맨틱 캐싱은 임베딩 거리가 가까운 질문에 저장된 답을 돌려준다. 어려운 쪽은 언제나 무효화다. 지우지 않는 캐시는 틀린 값을 내보내고, 너무 자주 지우는 캐시는 효과가 없다. 짧은 TTL과 중요한 쓰기에만 거는 선별적 무효화를 함께 쓰는 편이 안전하다.

Caching is the practice of keeping a copy of expensive-to-produce data in fast storage so later requests can be served without redoing the work. A cache sits between a consumer and a slower source such as a database, a remote API, or a model. Every cache needs an eviction policy and an expiry rule, because stale data is the price of speed. Time-to-live settings, explicit invalidation on write, and key namespacing are the usual controls. Redis and Memcached serve as shared in-memory caches for application data, CDNs such as Cloudflare cache static assets close to users, and browsers cache responses locally. Language model providers apply the same idea. Prompt caching stores the processed prefix of a long system prompt so repeated calls skip recomputation, and semantic caching returns a stored answer when a new question is close enough in embedding space. The hard part is invalidation. A cache that is never cleared serves wrong data, and one cleared too eagerly gives no benefit, so teams pair a short TTL with targeted invalidation on the writes that actually matter.