#접두사 캐시와 시맨틱 캐시의 차이

← 전체 목차 · 이전: 다중 턴 대화에서 왜 이력을 그냥 밀어 넣으면 안 되나 · 다음: 프롬프트는 도대체 어떻게 쓰나 — Zero-shot / Few-shot / CoT

"둘 다 token을 아끼기 위한 것"이라고만 답하면 너무 거칠다. 올바른 진입점은 세 차원이며, 두 캐시는 이 셋이 완전히 다르다: 적중 조건, 리스크, 적용 시나리오.

#접두사 캐시: "글자 단위 일치"여야 하고 "의미가 비슷한 것"으로는 안 된다

• 전형적으로 재사용 가능한 접두사 내용: 시스템 프롬프트, 도구 설명, 고정 지식 조각.
• 이 내용이 같으면 모델이 이미 계산한 KV 결과를 재사용해 프리필 오버헤드를 대폭 줄일 수 있다.
• 핵심 제약: 텍스트 접두사가 안정적이어야 하며, 의미가 비슷한 정도로는 안 된다 — 시맨틱 캐시와의 가장 큰 분수령이다.

#시맨틱 캐시: 의미 유사도를 본다

• 예: 사용자가 "경비 정산은 어떻게 신청하나요"와 "정산 절차는 어디 있나요"를 물으면 — 글자는 다르지만 의미가 가깝기 때문에 시스템이 과거 답변을 그대로 재사용할 수 있다.
• 수익은 명확하다: 한 번의 완전한 모델 호출을 절약한다.
• 리스크도 명확하다: 오적중. 그래서 시맨틱 캐시는 네 가지를 반드시 함께 처리해야 한다.

#엔지니어링 함정: 동적 내용을 앞에 두면 접두사 캐시가 깨진다

• 잘못된 시범(동적 전치): 타임스탬프 / 랜덤 ID → 동적 변수 → 공용 시스템 프롬프트 순서로 배치해 동적 내용을 프롬프트 가장 앞에 둔다.
• 결과: 접두사가 매번 달라진다 → 접두사가 깨진다 → 캐시 적중률이 매우 나빠진다.
• 올바른 방식: 고정 부분은 앞에, 동적 부분은 되도록 뒤로.
• 인식의 전환: 이것은 프롬프트의 구조 설계에 속하지 서버 측 최적화만이 아니다 — 프롬프트를 쓰는 사람도 캐시 적중률에 책임이 있다.

#판단 흐름

「돈을 아끼고 싶다 / 속도를 올리고 싶다」는 요구를 받았을 때
        │
        ├── 질문①: 입력의 앞부분이 본래 안정적인가?
        │      (시스템 프롬프트, 도구 설명, 고정 지식 조각의 비중이 높은가?)
        │      예 → 【접두사 캐시】 도입
        │            └── 점검: 프롬프트 구조가
        │                  [공용 시스템 프롬프트] → [도구 설명] → [고정 지식]
        │                  → [동적 변수] → [타임스탬프/랜덤ID] → [사용자 질문]
        │                  인가? 동적 내용이 앞에 있으면 재배치부터 하고 적중률을 논할 것
        │
        └── 질문②: 프로덕션에 「표현만 바꿔 같은 것을 묻는」 요청이 대량으로 있는가?
               예 → 【시맨틱 캐시】 도입
                     └── 네 개의 관문을 함께 설정할 것:
                           권한 통제 / 시간 유효성 / 지식 버전 / 유사도 임계값
                     └── 핵심 취사선택: 임계값을 높이면 적중률↓ 오적중↓
                                        임계값을 낮추면 적중률↑ 오적중↑

#핵심 통찰

1. "token을 아낀다"는 현상이지 답이 아니다 — 묻는 것은 계층을 나눌 수 있는가이다. 접두사 캐시가 아끼는 것은 계산(prefill 단계의 KV 재계산)이고, 시맨틱 캐시가 아끼는 것은 호출(LLM 요청 1회 전체)이다. 아끼는 대상이 같은 층에 있지 않으므로 구현 방식도 자연히 다르다.
2. 적중 조건의 엄격성이 그것이 어느 층에 속하는지를 결정한다 — "글자 단위 일치"를 요구하는 메커니즘은 추론 엔진 안에서만 만들 수 있고(Prefix Cache), "의미가 비슷한 것"을 용인할 수 있는 메커니즘은 필연적으로 벡터 검색과 임계값을 끌어들이므로 애플리케이션 층에서만 만들 수 있다(Semantic Caching). 이 판정 기준은 어떤 캐시 설계에도 이식된다.
3. 접두사 캐시에는 정확성 리스크가 없고 시맨틱 캐시에는 있다 — 접두사 캐시가 실효하면 기껏해야 조금 느리고 조금 비싸질 뿐이지만, 시맨틱 캐시의 오적중은 곧바로 틀린 답을 준다. 따라서 둘의 출시 문턱, 카나리 전략, 회귀 테스트 요구 수준은 전혀 다른 등급이다.
4. 프롬프트의 필드 순서는 가독성 문제가 아니라 성능 파라미터다 — 타임스탬프, 랜덤 ID, user_id 같은 고엔트로피 내용을 머리에 두는 것은 매 요청마다 캐시를 능동적으로 포기하는 것과 같다. "고정은 앞, 동적은 뒤"는 팀의 프롬프트 규범에 명문화되어야 한다.
5. 시맨틱 캐시의 네 관문은 하나도 빠질 수 없다 — 권한, 시효, 지식 버전, 유사도 임계값. 어느 하나가 빠져도 **"답이 매우 자신 있어 보이지만 이미 틀렸다"**는 형태로 드러난다: 월권 유출, 만료된 정책, 구 버전 지식, 엉뚱한 대상.
6. 두 캐시는 양자택일이 아니라 서로 다른 층에 겹쳐진다 — 접두사 캐시는 모든 요청에 기본 유효하고(접두사만 안정적이면), 시맨틱 캐시는 고빈도 반복 문답에만 유효하다. 실제 시스템에서는 동시에 켤 수 있다.
7. 수익의 예측 가능성이 다르다 — 접두사 캐시의 수익은 "고정 접두사 길이 / 총 입력 길이" 비율에 따라 선형으로 변해 추산이 가능하다. 시맨틱 캐시의 수익은 프로덕션 질문의 반복률 분포에 좌우되므로 먼저 트래픽 분석을 해야 할 가치가 있는지 알 수 있다.

#엔지니어링 실전 Tips

• 프롬프트 편집이 곧 캐시 전략이다: System Prompt / 도구 스키마 / 고정 지식 조각을 가장 앞에 고정하고, {{timestamp}}, {{request_id}}, {{user_name}}은 일률적으로 뒤로 보낼 것.
• "보이지 않는 동적 내용"을 경계할 것: 도구 목록의 순서가 불안정하거나, JSON 필드의 직렬화 순서가 무작위이거나, 프롬프트 템플릿에 현재 날짜가 들어 있는 것 — 전부 조용히 접두사를 깨뜨리며 모니터링에서 직접 보이지도 않는다.
• 시맨틱 캐시는 권한별로 버킷을 나눌 것: 역할/테넌트별 캐시 키에 반드시 권한 차원을 포함시켜야 "A의 답변이 B에게 적중되는" 월권 사고를 막는다.
• 지식베이스가 갱신되면 시맨틱 캐시를 일괄 실효시킬 수 있어야 한다: 지식 버전 번호를 캐시 키의 일부로 삼는 것이 가장 손쉬운 방법이다.
• 시맨틱 캐시에 수동 다운그레이드 스위치를 남길 것: 금융, 경비 정산, 주문처럼 정확성이 강하게 요구되는 시나리오에서는 적중하지 않을지언정 오적중은 안 된다.
• 적중률은 관측해야 할 지표다: 접두사 캐시 적중률, 시맨틱 캐시 적중률, 시맨틱 캐시 오적중률(샘플링 사람 심사나 사용자 부정 피드백으로 추정)을 모니터링에 올릴 것.
• 더 파고들 방향: 각 추론 프레임워크(vLLM, SGLang 등)와 각 API의 접두사 캐시 발효 조건·과금 할인 규칙 차이, 시맨틱 캐시 임계값의 오프라인 데이터셋 기반 튜닝과 오적중률 측정, 그리고 접두사 캐시 + 시맨틱 캐시 + 결과 캐시(정확 query 적중) 3단 캐시의 조합 설계.