[chore] LLM 컨텍스트 캐싱 적용 및 토큰 측정 #58

배경 / 목표

대화당 토큰(현재 ~1.3만)의 대부분이 매 호출 재전송되는 시스템 프롬프트(COMMON 4,460자) 다. 컨텍스트 캐싱으로 반복 입력의 과금을 줄이고, 효과를 측정한다.

핵심 사실(조사 결과)

1. 우리 usedTokens는 totalTokenCount(입력+출력 합계)다. 캐싱은 totalTokenCount를 줄이지 않는다 — 캐시된 반복 입력을 할인 과금할 뿐. 즉 대화당 "총 토큰"은 ~1.3만 그대로, 실효(과금) 토큰이 줄어든다.
2. gemini-3.1-flash-lite는 암시적 캐싱이 기본 활성일 가능성이 크다(시스템 프롬프트가 프리픽스로 동일). SDK(1.51.0)는 명시적 캐싱 API(client.caches)도 지원한다.
3. usageMetadata.cachedContentTokenCount로 캐시 적중을 측정할 수 있다.

제안 (단계)

• 1단계(측정): 생성 응답의 cachedContentTokenCount를 캡처해 generation_log에 기록 → 암시적 캐싱이 이미 먹는지 확인 + 실효 토큰 재계산. (저위험, 재측정 목적에 직접 부합)
• 2단계(필요 시): 명시적 캐싱으로 확정 할인. 단 프롬프트가 백오피스 편집 가능이라 편집 시 캐시 무효화 + TTL 관리 + 최소 토큰 요건 필요(복잡·외부 API).

완료 조건(1단계)

• 생성별 cachedContentTokenCount 기록 → 대화당 실효 토큰 산출 가능

범위 밖(우선)

• 명시적 캐싱은 1단계 측정 결과 보고 결정