Semantic cache는 잘 맞으면 강력하지만, 무효화가 없으면 위험합니다. 오래된 답변이 계속 재사용되면 사용자는 “빨라졌지만 틀린 시스템"을 만나게 됩니다.
이 글은 Semantic Cache, AI Cache Strategy, Context Compression, RAG Monitoring을 함께 보면서, 캐시 무효화를 어떤 기준으로 설계해야 하는지 설명합니다.
개요 #
Semantic cache 무효화는 “언제 캐시를 버릴 것인가"를 결정하는 규칙입니다. 단순 TTL만으로 해결하려고 하면 운영 중에 예외가 많아집니다.
실무에서는 아래 세 가지 축으로 나누면 정리하기 쉽습니다.
- 시간 기반 무효화
- 버전 기반 무효화
- 이벤트 기반 무효화
이 셋을 섞어야 오래된 응답 재사용을 막을 수 있습니다.
왜 중요한가 #
Semantic cache는 의미가 비슷하면 재사용한다는 점에서 편리하지만, 바로 그 특성 때문에 위험합니다.
- 문서가 바뀌었는데 옛 답이 남을 수 있습니다
- 정책이 바뀌었는데 이전 요약을 돌려줄 수 있습니다
- 사용자 권한이 바뀌었는데 이전 세션 결과가 재사용될 수 있습니다
RAG Monitoring에서 응답 품질 저하가 보이면, 원인은 cache hit가 아니라 cache invalidation일 수 있습니다. 그래서 무효화 정책이 캐시 정책보다 먼저 정의돼야 합니다.
무효화 설계 #
무효화는 보통 아래 규칙을 조합합니다.
- TTL: 일정 시간이 지나면 자동 삭제
- Version: 문서 버전이나 프롬프트 버전이 바뀌면 삭제
- Event: 원본 데이터가 바뀌면 즉시 삭제
Context Compression을 쓰는 경우에도 압축 결과는 원본 세션 버전과 묶어서 관리해야 합니다. AI Cache Strategy에서 말하는 세션 캐시도 같은 원칙이 적용됩니다.
설계 선택 #
무효화 방식을 고를 때는 다음을 봅니다.
- 답변이 얼마나 자주 바뀌는가
- 원본 데이터 변경을 감지할 수 있는가
- 사용자 권한 변화가 잦은가
- 캐시 저장 비용이 무효화 비용보다 큰가
- stale answer 허용 범위가 어느 정도인가
정책이 자주 바뀌는 영역은 TTL만으로 버티기 어렵습니다. 반대로 자주 안 바뀌는 FAQ는 버전 기반 무효화만으로도 충분할 수 있습니다.
아키텍처 도식 #
권장 아키텍처는 다음과 같습니다.
- 요청이 들어오면 cache key와 version을 함께 확인합니다.
- TTL이 만료되었는지 검사합니다.
- 원본 데이터 이벤트를 반영한 invalidation flag를 확인합니다.
- 미스면 semantic lookup 또는 RAG 실행으로 넘어갑니다.
- 새 응답을 버전과 함께 다시 저장합니다.
이 구조는 RAG Cost Optimization과 함께 보면 더 유용합니다. stale answer를 막는 비용과 캐시 적중으로 줄이는 비용을 같이 봐야 합니다.
체크리스트 #
- TTL만 믿고 있지 않은가
- 문서 버전과 캐시 버전이 분리돼 있는가
- 권한 변경 시 캐시가 무효화되는가
- 원본 데이터 이벤트를 받아 무효화할 수 있는가
- 무효화 후 hit rate가 얼마나 떨어지는지 추적하는가
결론 #
Semantic cache는 빠르지만, 무효화가 없으면 운영이 무너집니다. TTL, 버전, 이벤트를 함께 쓰면 오래된 답변을 줄이면서도 캐시의 장점을 살릴 수 있습니다.