프롬프트 캐시 영향: 캐시 히트율과 토큰 절감 간의 균형
배울 수 있는 내용
- LLM 제공자의 프롬프트 캐싱 메커니즘이 어떻게 작동하는지 이해
- DCP修剪가 왜 캐시 히트율에 영향을 미치는지 파악
- 캐시 손실과 토큰 절감 사이의 균형을 잡는 방법 학습
- 사용하는 제공자와 요금 모델에 따라 최적의 전략 수립
현재 직면한 딜레마
DCP를 활성화한 후 캐시 히트율이 85%에서 65%로 떨어진 것을 보고, 오히려 비용이 증가하는 것이 아닐지 걱정되시나요? 아니면 서로 다른 LLM 제공자(Anthropic, OpenAI, GitHub Copilot)에서 DCP를 사용할 때 다른 영향이 있는지 알고 싶으신가요?
DCP의修剪操作은 메시지 내용을 변경하여 프롬프트 캐싱에 영향을 미칩니다. 하지만 이 균형이 정말 가치 있는 것인지 살펴보겠습니다.
언제 이 전략을 사용해야 하는가
- 긴 세션에서 컨텍스트 팽창이 두드러질 때
- 요청별 요금제를 사용하는 제공자(GitHub Copilot, Google Antigravity)
- 컨텍스트 오염을 줄이고 모델 응답 품질을 향상시키고 싶을 때
- 토큰 절감의 가치가 캐시 히트율 손실보다 클 때
핵심 아이디어
프롬프트 캐싱이란 무엇인가
프롬프트 캐싱은 Anthropic, OpenAI 같은 LLM 제공자가 성능과 비용을 최적화하기 위해 제공하는 기술입니다. 이는정확한 접두사 일치를 기반으로 처리된 프롬프트를 캐시하며, 동일한 프롬프트 접두사는 토큰을 다시 계산하지 않습니다.
캐시 메커니즘 예시
다음과 같은 대화 기록이 있다고 가정해 봅시다:
[시스템 프롬프트]
[사용자 메시지 1]
[AI 응답 1 + 도구 호출 A]
[사용자 메시지 2]
[AI 응답 2 + 도구 호출 A] ← 동일한 도구 호출
[사용자 메시지 3]캐시가 없으면 LLM에 보낼 때마다 모든 토큰을 다시 계산해야 합니다. 캐시가 있으면 두 번째 전송 시 제공자가 이전 계산 결과를 재사용할 수 있어 새로운 「사용자 메시지 3」 부분만 계산하면 됩니다.
DCP가 캐시에 미치는 영향
DCP가 도구 출력을修剪할 때, 도구의 원본 출력 내용을 플레이스홀더 텍스트로 대체합니다:"[Output removed to save context - information superseded or no longer needed]"
이 작업은 메시지의 정확한 내용을 변경하여(완전한 도구 출력이 플레이스홀더로 변경됨) 캐시 무효화를 발생시킵니다—해당 지점부터의 캐시 접두사는 더 이상 재사용할 수 없습니다.
균형 분석
| 지표 | DCP 없음 | DCP 활성화 | 영향 |
|---|---|---|---|
| 캐시 히트율 | ~85% | ~65% | ⬇️ 20% 감소 |
| 컨텍스트 크기 | 지속 증가 | 제어된修剪 | ⬇️ 현저히 감소 |
| 토큰 절감 | 0 | 10-40% | ⬆️ 현저히 증가 |
| 응답 품질 | 하락 가능 | 더 안정적 | ⬆️ 향상(컨텍스트 오염 감소) |
캐시 히트율은 떨어졌는데 왜 비용은 더 낮을 수 있나요?
캐시 히트율의 하락이 비용 증가를 의미하지는 않습니다. 이유:
- 토큰 절감이 보통 캐시 손실을 초과함: 긴 세션에서 DCP修剪가 절감하는 토큰 수(10-40%)는 캐시 무효화로 인한 추가 토큰 계산을 대체하는 경우가 많습니다
- 컨텍스트 오염 감소:冗余内容이 제거되면 모델이 현재 작업에 더 집중할 수 있어 응답 품질이 높아집니다
- 캐시 히트율의 절대값은 여전히 높음: 65%로 떨어져도 여전히 2/3 정도의 내용이 캐시될 수 있습니다
테스트 데이터에 따르면 대부분의 경우 DCP의 토큰 절감 효과가 더 두드러집니다.
서로 다른 요금 모델의 영향
요청별 요금제(GitHub Copilot, Google Antigravity)
최적의 사용 사례로, 부정적인 영향이 없습니다.
이 제공자들은 토큰 수가 아닌 요청 횟수를 기준으로 요금을 청구합니다. 따라서:
- ✅ DCP修剪가 절감하는 토큰이 비용에 직접 영향을 미치지 않음
- ✅ 컨텍스트 크기 감소가 응답 속도 향상으로 이어짐
- ✅ 캐시 무효화가 추가 비용을 발생시키지 않음
GitHub Copilot과 Google Antigravity
이 두 플랫폼은 요청별 요금제를 적용하므로, DCP는 제로 비용 최적화입니다—캐시 히트율이 떨어져도 비용이 증가하지 않으며, 오히려 성능이 향상됩니다.
토큰별 요금제(Anthropic, OpenAI)
캐시 손실과 토큰 절감 사이의 균형을 고려해야 합니다.
계산 예시:
100개의 메시지를 포함하고 총 토큰 수가 100K인 긴 세션을 가정합니다:
| 시나리오 | 캐시 히트율 | 캐시 절감 토큰 | DCP修剪 절감 토큰 | 총 절감 |
|---|---|---|---|---|
| DCP 없음 | 85% | 85K × (1-0.85) = 12.75K | 0 | 12.75K |
| DCP 활성화 | 65% | 100K × (1-0.65) = 35K | 20K(추정) | 35K + 20K - 12.75K = 42.25K |
DCP修剪 후에는 캐시 히트율은 떨어졌지만 컨텍스트가 20K 토큰만큼 줄어들어서 실제 총 절감이 더 많습니다.
긴 세션에서 더 명확한 장점
긴 세션에서 DCP의 장점이 더 두드러집니다:
- 짧은 세션(< 10 메시지): 캐시 무효화가 지배적일 수 있어收益가 제한적
- 긴 세션(> 30 메시지): 컨텍스트 팽창이 심각하여 DCP修剪의 토큰 절감이 캐시 손실을 훨씬 초과
권장 사항: 긴 세션에서는 DCP를 우선 활성화하고, 짧은 세션에서는 비활성화할 수 있습니다.
관찰 및 검증
1단계: 캐시 토큰 사용량 관찰
이유 캐시 토큰이 총 토큰에서 차지하는 비율을 파악하여 캐시의 중요성 평가
# OpenCode에서 실행
/dcp context확인해야 할 내용: 다음과 같은 토큰 분석
╭───────────────────────────────────────────────────────────╮
│ DCP Context Analysis │
╰───────────────────────────────────────────────────────────╯
Session Context Breakdown:
───────────────────────────────────────────────────────────
System 15.2% │████████████████▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒│ 25.1K tokens
User 5.1% │████▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒│ 8.4K tokens
Assistant 35.8% │██████████████████████████████████████▒▒▒▒▒▒▒│ 59.2K tokens
Tools (45) 43.9% │████████████████████████████████████████████████│ 72.6K tokens
───────────────────────────────────────────────────────────
Summary:
Pruned: 12 tools (~15.2K tokens)
Current context: ~165.3K tokens
Without DCP: ~180.5K tokens주요 지표解读:
| 지표 | 의미 | 평가 방법 |
|---|---|---|
| Pruned | 이미修剪된 도구 수와 토큰 수 | 높을수록 DCP 절감이 많음 |
| Current context | 현재 세션 컨텍스트의 토큰 총수 | Without DCP보다 현저히 작아야 함 |
| Without DCP | DCP를 활성화하지 않을 경우 컨텍스트 크기 | 절감 효과 비교용 |
2단계: DCP 활성화/비활성화 비교
이유 비교를 통해 캐시와 토큰 절감의 차이를 직관적으로 파악
# 1. DCP 비활성화(설정에서 enabled: false로 설정)
# 또는 일시적으로关闭:
/dcp sweep 999 # 모든 도구를修剪하여 캐시 효과 관찰
# 2. 몇 차례 대화 진행
# 3. 통계 확인
/dcp stats
# 4. DCP 다시 활성화
# (설정 수정하거나 기본값 복원)
# 5. 대화 계속하고 통계 비교
/dcp stats확인해야 할 내용:
/dcp context를 사용하여 주요 지표 변화 관찰:
| 지표 | DCP 비활성화 | DCP 활성화 | 설명 |
|---|---|---|---|
| Pruned | 0 tools | 5-20 tools | DCP가修剪한 도구 수 |
| Current context | 큼 | 작음 | DCP 후 컨텍스트가 현저히 감소 |
| Without DCP | Current와 동일 | Current보다 큼 | DCP의 절감 잠재력 표시 |
실제 테스트 권장 사항
서로 다른 세션 유형에서 테스트:
- 짧은 세션(5-10 메시지): 캐시가 더 중요한지 관찰
- 긴 세션(30+ 메시지): DCP의 절감이 더 두드러지는지 관찰
- 반복 읽기: 동일한 파일을 자주 읽는 시나리오
이를 통해 실제 사용 습관에 따라 최선의 선택을 내릴 수 있습니다.
3단계: 컨텍스트 오염의 영향 이해
이유 DCP修剪가 토큰 절감뿐 아니라 컨텍스트 오염을 줄여 응답 품질을 향상시킴
컨텍스트 오염이란 무엇인가?
컨텍스트 오염은 대화 기록에 너무 많은冗余, 무관하거나 오래된 정보가 쌓여 있어 발생하는 현상으로, 다음과 같은 결과를 초래합니다:
- 모델의 주의력이 분산되어 현재 작업에 집중하기 어려움
- 오래된 데이터(예: 이미 수정된 파일 내용)를 참조할 수 있음
- 응답 품질이 하락하여 더 많은 토큰으로 "컨텍스트를 이해"해야 함
DCP는 완료된 도구 출력, 반복되는 읽기 작업 등을 제거하여 이러한 오염을 줄입니다.
실제 효과 비교:
| 시나리오 | DCP 없음 | DCP 활성화 |
|---|---|---|
| 동일한 파일 3번 읽기 | 3번의 완전한 출력 유지(冗余) | 최신 한 번만 유지 |
| 파일 쓰기 후 다시 읽기 | 이전 쓰기 작업 + 새로운 읽기 | 새로운 읽기만 유지 |
| 오류 도구 출력 | 완전한 오류 입력 유지 | 오류 메시지만 유지 |
컨텍스트 오염이 줄어들면 모델이 현재 상태를 더 정확하게 이해하여 "허튼소리"를 하거나 오래된 데이터를 참조하는 경우가 줄어듭니다.
모범 사례 권장 사항
제공자에 따른 전략 선택
| 제공자 | 요금 모델 | 권장 사항 | 이유 |
|---|---|---|---|
| GitHub Copilot | 요청별 | ✅ 항상 활성화 | 제로 비용 최적화로 성능만 향상 |
| Google Antigravity | 요청별 | ✅ 항상 활성화 | 同上 |
| Anthropic | 토큰별 | ✅ 긴 세션 활성화 ⚠️ 짧은 세션 선택적 | 캐시와 절감의 균형 |
| OpenAI | 토큰별 | ✅ 긴 세션 활성화 ⚠️ 짧은 세션 선택적 | 同上 |
세션 유형에 따른 설정 조정
// ~/.config/opencode/dcp.jsonc 또는 프로젝트 설정
{
// 긴 세션(> 30 메시지): 모든 전략 활성화
"strategies": {
"deduplication": { "enabled": true },
"supersedeWrites": { "enabled": true }, // 활성화 권장
"purgeErrors": { "enabled": true }
},
// 짧은 세션(< 10 메시지): 중복 제거만 활성화
"strategies": {
"deduplication": { "enabled": true },
"supersedeWrites": { "enabled": false },
"purgeErrors": { "enabled": false }
}
}전략 설명:
- deduplication(중복 제거): 영향이 작아 항상 활성화 권장
- supersedeWrites(덮어쓰기): 영향이 중간으로 긴 세션에 권장
- purgeErrors(오류 제거): 영향이 작아 활성화 권장
전략 동적 조정
/dcp context를 사용하여 토큰 구성과修剪 효과 관찰:
# Pruned 값이 높으면 DCP가 적극적으로 토큰을 절감하고 있다는 의미
# Current context와 Without DCP를 비교하여 절감 효과 평가 가능
/dcp context체크포인트 ✅
다음 내용을 이해했는지 확인:
- [ ] 프롬프트 캐싱은 정확한 접두사 일치를 기반으로 하며, 메시지 내용 변경 시 캐시가 무효화됨
- [ ] DCP修剪가 메시지 내용을 변경하여 캐시 히트율이 하락함(약 20%)
- [ ] 긴 세션에서 토큰 절감이 보통 캐시 손실을 초과함
- [ ] GitHub Copilot과 Google Antigravity는 요청별 요금제로 DCP가 제로 비용 최적화임
- [ ] Anthropic과 OpenAI는 토큰별 요금제로 캐시와 절감의 균형을 고려해야 함
- [ ]
/dcp context를 사용하여 토큰 구성과修剪 효과 관찰 - [ ] 세션 길이에 따라 전략 설정을 동적으로 조정
함정 경고
❌ 캐시 히트율 하락이 비용 증가라고 오해
문제: 캐시 히트율이 85%에서 65%로 떨어진 것을 보고 비용이 증가할 것이라 생각
이유: 캐시 히트율만 주목하고 토큰 절감과 컨텍스트 감소 효과를 무시함
해결: /dcp context를 사용하여 실제 데이터 확인,重点关注:
- DCP修剪가 절감하는 토큰(
Pruned) - 현재 컨텍스트 크기(
Current context) 3.修剪하지 않을 경우의 이론적 크기(Without DCP)
Without DCP와 Current context를 비교하면 DCP가 실제로 절감하는 토큰 수를 확인할 수 있습니다.
❌ 짧은 세션에서 너무 적극적으로修剪
문제: 5-10개 메시지의 짧은 세션에서 모든 전략을 활성화하여 캐시 무효화가 두드러짐
이유: 짧은 세션에서는 컨텍스트 팽창이 심각하지 않아 적극적인修剪의收益가 작음
해결:
- 짧은 세션에서는
deduplication과purgeErrors만 활성화 supersedeWrites전략 비활성화- 또는 DCP 완전 비활성화(
enabled: false)
❌ 서로 다른 제공자의 요금 차이 무시
문제: GitHub Copilot에서 캐시 무효화로 비용이 증가할까 걱정
이유: Copilot이 요청별 요금제라는 것을 인지하지 못하여 캐시 무효화가 비용을 증가시키지 않음
해결:
- Copilot과 Antigravity: 항상 DCP 활성화
- Anthropic과 OpenAI: 세션 길이에 따라 전략 조정
❌ 실제 데이터를 관찰하지 않고 의사결정
문제: 느낌으로 DCP를 활성화해야 하는지 판단
이유: /dcp context와 /dcp stats를 사용하여 실제 효과를 관찰하지 않음
해결:
- 서로 다른 세션에서 데이터 수집
- DCP 활성화/비활성화의 차이 비교
- 자신의 사용 습관에 따라 선택
본 수업 요약
프롬프트 캐싱의 핵심 메커니즘:
- LLM 제공자가정확한 접두사 일치를 기반으로 프롬프트를 캐시
- DCP修剪가 메시지 내용을 변경하여 캐시 무효화 발생
- 캐시 히트율은 하락(약 20%)하지만 토큰 절감이 더 두드러짐
균형 의사결정 매트릭스:
| 시나리오 | 권장 설정 | 이유 |
|---|---|---|
| GitHub Copilot/Google Antigravity | ✅ 항상 활성화 | 요청별 요금제로 제로 비용 최적화 |
| Anthropic/OpenAI 긴 세션 | ✅ 모든 전략 활성화 | 토큰 절감 > 캐시 손실 |
| Anthropic/OpenAI 짧은 세션 | ⚠️ 중복 제거+오류 제거만 활성화 | 캐시가 더 중요 |
주요 포인트:
- 캐시 히트율 하락이 비용 증가를 의미하지 않음: 총 토큰 절감을 확인해야 함
- 서로 다른 제공자의 요금 모델이 전략에 영향: 요청별 vs 토큰별
- 세션 길이에 따라 동적으로 조정: 긴 세션에서 더 많은 혜택
- 도구로 데이터 관찰:
/dcp context와/dcp stats
모범 사례 요약:
1. 사용하는 제공자와 요금 모델 확인
2. 세션 길이에 따라 전략 설정 조정
3. 정기적으로 /dcp context로 효과 관찰
4. 긴 세션에서는 토큰 절감을 우선시
5. 짧은 세션에서는 캐시 히트율을 우선시다음 수업 예고
다음 수업에서는 **하위 에이전트 처리**를 학습합니다.
배울 내용:
- DCP가 하위 에이전트 세션을 어떻게 감지하는지
- 하위 에이전트가修剪에 참여하지 않는 이유
- 하위 에이전트에서의修剪결과가 어떻게 주 에이전트에 전달되는지
부록: 소스 코드 참고
클릭하여 소스 코드 위치 보기
업데이트 시간: 2026-01-23
| 기능 | 파일 경로 | 줄 번호 |
|---|---|---|
| 프롬프트 캐싱 설명 | README.md | 46-52 |
| 토큰 계산(含 캐시) | lib/messages/utils.ts | 66-78 |
| 컨텍스트 분석 명령 | lib/commands/context.ts | 68-174 |
| 캐시 토큰 계산 | lib/commands/context.ts | 106-107 |
| 로그 기록 캐시 토큰 | lib/logger.ts | 141 |
| 修剪플레이스홀더 정의 | lib/messages/prune.ts | 6-7 |
| 도구 출력修剪 | lib/messages/prune.ts | 22-46 |
주요 상수:
- 없음
주요 함수:
calculateTokens(messages, tokenizer): 메시지 토큰 수 계산, cache.read 및 cache.write 포함buildSessionContext(messages): 세션 컨텍스트 분석 구축, System/User/Assistant/Tools 구분formatContextAnalysis(analysis): 컨텍스트 분석 출력 포맷팅
주요 타입:
TokenCounts: 토큰 카운트 구조, input/output/reasoning/cache 포함
캐시 메커니즘 설명(README에서):
- Anthropic과 OpenAI는 정확한 접두사 일치를 기반으로 프롬프트를 캐시
- DCP修剪가 메시지 내용을 변경하여 캐시 무효화 발생
- DCP 활성화 시 캐시 히트율 약 65%, 비활성화 시 약 85%
- 최적 사용 사례: 요청별 요금제 제공자(GitHub Copilot, Google Antigravity)에서 부정적 영향 없음