Gemini API로 문서 분석, 코드 리뷰, 고객지원 챗봇을 만들다 보면 같은 컨텍스트를 반복해서 보내는 상황이 자주 생깁니다. 제품 매뉴얼, 약관, 코드베이스 설명, 긴 회의록 같은 자료를 매 요청마다 프롬프트에 붙이면 비용과 지연 시간이 같이 늘어납니다. 이 문제를 줄이기 위한 대표적인 방법이 context caching입니다.
Context caching의 핵심은 “반복되는 긴 입력”을 매번 새로 처리하지 않도록 만드는 것입니다. 사용자가 질문할 때마다 100페이지 문서를 통째로 보내는 대신, 공통 컨텍스트를 캐시해두고 이후 요청에서 재사용합니다. 잘 맞는 워크로드에서는 비용 절감과 응답 속도 개선을 동시에 얻을 수 있습니다. 반대로 짧고 매번 다른 입력에는 큰 효과가 없습니다.
캐싱이 필요한지 판단하는 가장 쉬운 기준은 동일한 긴 컨텍스트가 반복되는가입니다. 예를 들어 고객지원 챗봇이 제품 문서 30개를 바탕으로 질문에 답한다면, 문서 컨텍스트는 여러 사용자 요청에서 반복됩니다. 법무 검토 도구가 같은 계약서에 대해 여러 질문을 받는 경우도 마찬가지입니다. 코드 리뷰 도구가 특정 모듈의 설계 문서와 함께 여러 diff를 분석한다면 공통 컨텍스트를 캐시할 수 있습니다.
반대로 사용자가 매번 완전히 다른 짧은 질문을 던지는 일반 챗봇은 캐싱 이점이 작습니다. 캐시를 만들고 관리하는 비용이 절감 효과보다 클 수 있습니다. 또 컨텍스트가 자주 바뀌는 데이터라면 캐시 무효화가 더 큰 문제가 됩니다. 캐싱은 성능 마법이 아니라 반복 입력이 명확할 때 쓰는 운영 기법입니다.
실무에서는 “5회 이상 재사용될 가능성이 있는 10,000 토큰 이상의 컨텍스트”를 1차 후보로 잡아볼 만합니다. 정확한 기준은 모델, 가격, 요청 패턴에 따라 달라지지만, 이 정도면 캐시 설계를 검토할 가치가 있습니다.
많은 팀이 캐시 단위를 원본 문서 파일로만 생각합니다. 하지만 실제로는 작업 컨텍스트 단위가 더 유용합니다. 예를 들어 고객지원 봇에서는 “환불 정책 + 요금제 문서 + 계정 관리 FAQ”를 하나의 지원 컨텍스트로 묶을 수 있습니다. 개발 도구에서는 “결제 모듈 아키텍처 + API 스펙 + 에러 코드 표”를 하나의 분석 컨텍스트로 묶을 수 있습니다.
캐시 단위를 너무 작게 잡으면 요청마다 여러 캐시를 조합해야 하고 관리가 복잡해집니다. 너무 크게 잡으면 불필요한 정보가 섞여 모델 답변 품질이 떨어질 수 있습니다. 좋은 기준은 사용자의 질문 의도입니다. 같은 질문 흐름에서 함께 필요한 자료는 묶고, 다른 업무 흐름의 자료는 분리합니다.
또한 캐시 이름과 메타데이터를 잘 남겨야 합니다. 어떤 문서 버전으로 만들었는지, 언제 생성했는지, 어떤 모델에 맞춰 만든 캐시인지 기록해야 합니다. 나중에 답변이 이상해졌을 때 캐시가 오래됐는지, 원본 문서가 바뀌었는지 확인할 수 있어야 합니다.
캐싱에서 가장 어려운 문제는 만드는 것이 아니라 언제 버릴지입니다. 제품 문서가 업데이트됐는데 오래된 캐시를 계속 쓰면 사용자는 틀린 답변을 받습니다. 따라서 원본 데이터 변경과 캐시 무효화를 연결해야 합니다. 문서 CMS, Git 저장소, 데이터베이스 업데이트 이벤트가 발생하면 관련 캐시를 폐기하거나 새로 만들어야 합니다.
버전 기반 전략이 가장 안전합니다. 원본 문서의 hash나 버전 번호를 캐시 key에 포함합니다. 문서가 바뀌면 key가 달라지고 이전 캐시는 더 이상 선택되지 않습니다. TTL만으로 관리하는 방식은 간단하지만 정확하지 않습니다. 자주 바뀌는 문서는 TTL이 길면 위험하고, 거의 안 바뀌는 문서는 TTL이 짧으면 비용을 낭비합니다.
운영 환경에서는 캐시 재생성도 고려해야 합니다. 사용자가 요청한 순간 캐시가 없으면 즉시 생성할지, 백그라운드에서 미리 생성해둘지 결정해야 합니다. 자주 쓰는 컨텍스트는 배포나 문서 업데이트 직후 미리 warming하는 편이 좋습니다. 드물게 쓰는 컨텍스트는 최초 요청 시 생성해도 됩니다.
Context caching을 도입하면 RAG가 필요 없다고 생각하기 쉽지만 둘은 역할이 다릅니다. RAG는 많은 문서 중 필요한 조각을 검색해 프롬프트에 넣는 방식입니다. Context caching은 반복되는 입력을 효율적으로 재사용하는 방식입니다. 실제 서비스에서는 둘을 같이 쓰는 경우가 많습니다.
예를 들어 전체 지식베이스가 수천 문서라면 매번 모두 캐시하는 것은 비효율적입니다. 먼저 검색으로 관련 문서를 좁히고, 특정 고객이나 프로젝트에서 반복되는 자료 묶음만 캐시할 수 있습니다. 반대로 법률 계약서처럼 하나의 긴 문서 전체를 기준으로 여러 질문을 받는 경우에는 캐싱의 가치가 큽니다.
좋은 설계는 질문 유형에 따라 선택합니다. 단발성 질문은 RAG만 사용합니다. 같은 문서에 대한 연속 질의는 context caching을 사용합니다. 같은 도메인 문서와 사용자별 데이터가 섞이는 경우에는 공통 문서는 캐시하고 사용자별 작은 데이터만 매 요청에 붙입니다.
캐싱 도입 전에는 반드시 비용 계산을 해야 합니다. 필요한 값은 네 가지입니다. 공통 컨텍스트 토큰 수, 하루 재사용 횟수, 캐시 생성 비용, 캐시된 컨텍스트 사용 비용입니다. 여기에 캐시가 틀렸을 때 발생하는 품질 리스크도 포함해야 합니다.
예를 들어 50,000 토큰짜리 매뉴얼을 하루 200번 반복해서 보낸다면 캐싱 후보입니다. 반대로 8,000 토큰짜리 문서를 하루 2번만 쓴다면 구현 복잡도 대비 이득이 작을 수 있습니다. 비용 절감률만 보지 말고 latency 개선도 함께 봐야 합니다. 긴 컨텍스트를 매번 처리하지 않으면 사용자 응답 시간이 안정될 가능성이 큽니다.
모니터링 지표는 캐시 적중률, 캐시 생성 횟수, 캐시 사용 요청 수, 평균 응답 시간, 답변 오류 신고율입니다. 캐시 적중률이 낮다면 단위가 잘못됐거나 재사용 패턴이 없다는 뜻입니다. 답변 오류가 늘면 캐시 무효화가 늦거나 원본 문서 버전 관리가 부실한 것입니다.
Gemini context caching은 긴 프롬프트를 많이 쓰는 팀에게 강력한 비용 절감 수단입니다. 다만 캐시 무효화와 버전 관리 없이 붙이면 오래된 답변을 빠르게 내는 도구가 될 수 있습니다. 반복 컨텍스트, 명확한 버전, 측정 가능한 적중률이 있을 때 도입하는 것이 안전합니다.
