Context Caching 실험 보고서
이즈리얼
제작일지
카테고리
Empty
왜 실험했나
Rovel의 캐릭터 채팅은 매번 단순한 한 줄 답변만 만드는 기능이 아니다.
AI가 캐릭터의 성격, 말투, 장면 상태, 이전 대화 흐름, 안전 규칙, 출력 형식 등을 함께 참고해야 한다. 그래서 한 번의 답변을 만들 때 꽤 긴 "맥락"이 같이 들어간다.
문제는 간단하다.
•
같은 규칙을 매번 다시 보내면 느려지지 않을까?
•
반복되는 맥락을 캐시하면 더 빨라질까?
•
실제 사용자 체감 속도에도 도움이 될까?
Cloudturing의 글은 비슷한 질문을 Vertex AI와 Gemini 환경에서 실험한 사례였다. 특히 "Context Caching이 생각보다 레이턴시를 크게 줄이지 못했다"는 결론이 흥미로웠다. 우리도 현재 구조에서 같은 방향의 효과가 있는지 작은 실험을 진행했다.
Context Caching이란?
간단히 말하면, AI에게 매번 반복해서 보내는 긴 내용 일부를 미리 저장해 두고 다음 요청에서 재사용하는 방식이다.
예를 들어 매번 이런 내용을 보낸다고 생각해보자.
•
캐릭터의 성격
•
말투 규칙
•
장면 진행 규칙
•
안전 규칙
•
JSON 출력 형식
이 내용이 거의 바뀌지 않는다면, AI 시스템이 이를 매번 처음부터 처리하지 않고 "전에 본 내용"으로 재사용할 수 있다. 이론적으로는 비용과 처리 시간이 줄어들 수 있다.
다만 캐싱은 모든 시간을 줄여주지는 않는다. AI 답변 과정은 크게 보면 다음처럼 나뉜다.
1.
입력 맥락을 읽고 준비하는 시간
2.
실제 답변을 생각하고 생성하는 시간
Context Caching은 주로 1번에 영향을 준다. 답변을 길게 생성하거나 내부 추론이 길어지는 경우에는 2번이 더 큰 병목이 될 수 있다.
참고한 외부 실험에서 배운 점
•
약 7,500토큰 규모의 시스템 프롬프트를 기준으로 테스트했다.
•
명시적 캐싱을 적용해도 평균 응답 시간이 크게 줄지 않았다.
•
Priority PayGo도 비혼잡 시간대에는 기대만큼 빠르지 않았다.
•
실제 병목은 캐싱 가능한 입력 처리보다, 모델의 thinking/생성 단계에 가까웠다.
즉, "긴 프롬프트를 캐시하면 무조건 빨라진다"는 단순한 결론은 위험하다.
우리가 확인한 것
이번 실험에서는 두 가지를 나눠서 봤다.
1. 개발자가 직접 캐시를 만들고 재사용할 수 있는가
현재 사용 중인 AI 호출 방식에서는, 우리가 원하는 형태로 "명시적인 캐시 객체를 만들고, 그 캐시를 다음 요청에서 직접 참조하는 방식"을 안정적으로 사용할 수 있다고 판단하기 어려웠다.
공식 Gemini API에는 이런 기능이 있지만, 우리가 사용하는 호출 경로에서는 동일한 방식이 그대로 열려 있다고 보기 어려웠다.
그래서 지금 당장 제품 코드에 "명시적 Context Caching"을 넣는 것은 보류하는 게 맞다고 봤다.
2. 반복되는 맥락이 자동으로 재사용되는 신호가 있는가
반면, 같은 앞부분 맥락을 여러 번 반복해서 보냈을 때 일부 요청에서 캐시된 토큰이 잡히는 신호는 확인됐다.
쉽게 말해, 우리가 직접 캐시를 만들지는 않았지만, AI 제공 환경이 비슷한 앞부분을 자동으로 재사용하는 듯한 흔적이 있었다.
다만 여기서도 주의할 점이 있다.
•
캐시 신호가 잡힌다고 항상 더 빨라지는 것은 아니다.
•
답변 생성량이나 내부 추론량에 따라 지연 시간이 크게 흔들린다.
•
작은 표본만으로 "캐싱 덕분에 몇 % 빨라졌다"고 단정할 수 없다.
이번 실험에서는 반복 맥락을 사용한 요청들이 평균적으로 더 빨랐지만, 캐시 신호가 있었던 요청 중에서도 느린 경우가 있었다. Cloudturing 글에서 말한 것처럼, 실제 병목은 입력 처리보다 답변 생성 쪽일 수 있다.
사용자 경험 관점의 결론
이번 실험에서 얻은 결론은 현실적이다.
Context Caching은 분명 유용한 기술이지만, 지금 Rovel에서 바로 "체감 속도를 크게 줄이는 마법 버튼"은 아니다.
현재 더 중요해 보이는 개선 방향은 다음이다.
1.
반복되는 규칙은 프롬프트 앞쪽에 안정적으로 배치하기
•
AI 시스템이 같은 앞부분을 더 잘 재사용할 가능성이 있다.
2.
매번 바뀌는 정보는 뒤쪽에 분리하기
•
최근 대화, 현재 입력, 장면 상태처럼 변하는 내용은 고정 규칙과 섞지 않는 편이 좋다.
3.
답변 생성량을 관리하기
•
너무 긴 답변이나 과한 내부 추론은 캐싱보다 더 큰 지연 원인이 될 수 있다.
4.
실제 사용자 체감 기준으로 보기
•
평균 응답 시간보다 중요한 것은 p95 지연, 실패율, 첫 응답까지의 체감 대기다.
당장 적용할 방향
이번 결과를 바탕으로 바로 큰 구조 변경을 하기보다는, 안전한 최적화부터 진행하는 것이 맞다.
•
공통 규칙과 캐릭터 기준을 더 안정적인 앞부분 구조로 정리한다.
•
매 턴 바뀌는 정보는 뒤쪽으로 분리한다.
•
응답 지연과 토큰 사용량을 더 잘 관측한다.
•
캐시된 토큰이 실제 비용과 속도에 어떤 영향을 주는지 더 긴 기간으로 본다.
이 방식은 사용자에게 기능 변화가 갑자기 보이지 않으면서도, 내부적으로 응답 안정성과 비용 효율을 개선할 수 있다.
하지 않기로 한 것
이번 단계에서는 다음은 하지 않는다.
•
명시적 Context Caching을 바로 제품 기능으로 넣지 않는다.
•
캐싱으로 비용이 크게 줄어든다고 가정하고 가격 정책을 바꾸지 않는다.
•
소규모 실험 결과만으로 응답 속도 개선을 확정하지 않는다.
기술적으로 가능해 보이는 것과, 안정적으로 운영할 수 있는 것은 다르다. 이번에는 후자를 기준으로 판단했다.
다음 실험
다음에는 조금 더 사용자 경험에 가까운 방식으로 확인할 계획이다.
•
같은 캐릭터와 같은 장면에서 여러 턴을 연속 테스트한다.
•
공통 규칙을 앞에 둔 버전과 뒤섞인 버전을 비교한다.
•
답변 길이와 내부 추론량이 지연에 미치는 영향을 나눠 본다.
•
캐시 신호가 실제 운영 비용에도 반영되는지 장기적으로 관찰한다.
최종 메모
이번 실험의 가장 큰 수확은 "무엇을 당장 도입하지 않을지"를 분명히 한 것이다.
Context Caching은 앞으로도 계속 볼 만한 기술이다. 하지만 지금 Rovel에 필요한 것은 단순히 캐시 기능을 켜는 것이 아니라, AI가 매번 읽는 맥락을 더 안정적이고 재사용하기 쉬운 형태로 정리하는 일이다.
속도 개선은 그 다음에 따라오는 결과여야 한다.
Ro
Subscribe to 'rovel.ai'
Subscribe to my site to be the first to receive notifications and emails about the latest updates, including new posts.
Join Slashpage and subscribe to 'rovel.ai'!
Join Slashpage and subscribe to 'rovel.ai'!
Subscribe
