캐시 적중률이 높아도 총 비용이 줄지 않는다면, 먼저 입력 토큰이 어디서 늘어나는지 기록한 뒤 컴팩션, 도구 결과 축약 또는 새 세션 분할을 선택해야 합니다. 핵심 상태를 검증하지 않은 채 압축만 실행하면 청구액은 낮아져도 코드 작업의 복구 비용이 커질 수 있습니다.
이 글은 긴 세션에서 토큰 사용량이 계속 증가하는 개인 개발자, 지속형 에이전트 비용과 응답 시간을 관리하는 팀, 모델 호출과 실행 환경의 전체 비용을 평가하는 기술 책임자를 위한 운영 절차입니다.
마지막 업데이트: 2026년 8월 18일
데이터 확인: 딥시크 공식 가격표, 토큰 사용량 문서, 문맥 캐시 문서, 공개 하니스 저장소 설명
SECTION 01딥시크 하니스 컴팩션 비용 절감은 어디서 시작합니까?
긴 세션의 토큰 증가는 보통 한 가지 원인이 아닙니다. 한 요청에 포함되는 값은 대체로 다음 네 묶음으로 나뉩니다.
- 이번 차례에 새로 입력한 사용자 요청
- 이전 대화와 도구 호출을 포함한 누적 기록
- 시스템 지침, 작업 규칙, 저장소 설명
- 모델의 답변과 추론 결과
에이전트가 다음 차례를 실행할 때 이전 기록을 다시 전달하면, 새 입력이 많지 않아도 요청 문맥은 커집니다. 따라서 “이번 질문이 짧다”는 사실만으로 토큰 비용을 판단하면 안 됩니다. 공식 토큰 사용량 문서는 실제 응답의 사용량 값을 기준으로 확인하도록 안내합니다. (api-docs.deepseek.com)
먼저 요청마다 다음 값을 저장하십시오.
| 기록 항목 | 확인할 값 | 판단 목적 |
|---|---|---|
| 입력 전체 | 입력 토큰 | 문맥이 실제로 커지는지 확인 |
| 캐시 적중 | 적중 토큰 | 반복 접두부의 비용 경로 확인 |
| 캐시 미적중 | 미적중 토큰 | 새로 계산되는 입력 확인 |
| 출력 | 출력 토큰 | 모델 답변과 추론 길이 확인 |
| 환경 | 응답 시간, 메모리, 저장 공간 | 모델 비용 외 운영 부담 확인 |
여기서 금액은 고정 평균값으로 잡지 마십시오. 공식 가격표는 모델과 입력 경로에 따라 단가가 달라질 수 있으며, 현재 문서에는 입력 캐시 적중, 입력 캐시 미적중, 출력이 별도 항목으로 표시됩니다. 계산은 다음처럼 구성하면 됩니다.
총 비용 = 캐시 적중 입력 토큰 × 적중 단가 + 캐시 미적중 입력 토큰 × 미적중 단가 + 출력 토큰 × 출력 단가
가격은 변경될 수 있으므로 실행일에 딥시크 공식 모델별 가격표를 다시 확인해야 합니다. (api-docs.deepseek.com)
SECTION 02왜 캐시 적중률이 높아도 토큰 비용이 늘어납니까?
딥시크 API의 캐시는 이전 요청과 완전히 일치하는 입력 접두부를 재사용하는 방식입니다. 응답의 사용량에는 prompt_cache_hit_tokens와 prompt_cache_miss_tokens가 따로 표시됩니다. 즉, 캐시 적중은 반복 입력의 과금 경로를 낮출 수 있지만, 요청에 포함되는 전체 문맥이 계속 늘어나는 현상까지 없애지는 않습니다. (api-docs.deepseek.com)
예를 들어 저장소 설명, 시스템 지침, 과거 도구 결과가 매 차례 같은 위치에 남아 있으면 앞부분은 캐시 적중이 될 수 있습니다. 그러나 새 로그와 새 파일 내용이 뒤에 계속 붙으면 미적중 입력과 총 입력량은 증가합니다. 캐시 적중률만 화면에 크게 표시하는 하니스나 제3자 분석기는 이 차이를 숨길 수 있으므로, 원본 응답의 사용량 필드를 우선해야 합니다.
공개 하니스 저장소에는 캐시 적중 추정과 사용량 정규화 기능이 설명되어 있지만, 그 결과를 딥시크 API의 보편적인 동작으로 확대하면 안 됩니다. 모델 버전, 요청 접두부 구성, 저장된 캐시의 상태에 따라 결과가 달라질 수 있습니다. 공개 하니스 저장소의 사용량 관련 설명과 공식 캐시 문서를 서로 분리해서 읽으십시오. (github.com)
SECTION 03도구 결과는 어디까지 줄여야 합니까?
로그, 검색 결과, 빌드 출력, 대용량 파일 읽기는 대화 문맥을 빠르게 키우는 대표적인 원인입니다. 특히 실패한 명령의 전체 표준 출력과 여러 차례 반복된 파일 전문은 다음 요청마다 재전달될 가능성이 큽니다.
도구 결과 축약은 다음 기준으로 나누십시오.
| 결과 유형 | 대화에 남길 내용 | 외부 산출물로 보관할 내용 |
|---|---|---|
| 빌드 로그 | 실패 단계, 오류 앞뒤 문장, 실행 명령 | 전체 로그와 실행 시각 |
| 검색 결과 | 판단에 사용한 문장, 출처 주소, 검색 조건 | 전체 검색 결과와 원문 |
| 파일 읽기 | 변경 대상의 관련 구간, 줄 범위 | 원본 파일과 버전 정보 |
| 테스트 결과 | 실패한 테스트명, 재현 명령, 핵심 오류 | 전체 테스트 보고서 |
| 서버 로그 | 상태 코드, 요청 식별자, 오류 요약 | 원본 로그와 보존 기간 |
여기서 컴팩션과 도구 결과 축약은 같은 기능이 아닙니다. 도구 결과 축약은 입력이 대화에 들어오기 전에 크기를 줄이는 단계입니다. 컴팩션은 이미 쌓인 대화에서 목표와 상태를 요약해 새 문맥으로 재구성하는 단계입니다. 먼저 반복적인 도구 결과를 줄이고, 그래도 문맥이 커질 때 컴팩션을 적용하는 순서가 안전합니다.
주의: 증거를 줄이는 것과 삭제하는 것은 다릅니다. 재현 명령, 오류 위치, 파일 버전, 외부 산출물 경로가 빠진 요약은 나중에 같은 문제를 검증할 수 없습니다.
SECTION 04컴팩션 뒤 상태를 검증하는 절차
컴팩션을 실행했다면 요약문이 그럴듯한지만 보지 말고, 같은 작업을 이어갈 수 있는지 확인해야 합니다. 다음 순서로 점검하십시오.
- 압축 전에 현재 목표와 완료 조건을 한 문장으로 기록합니다.
- 수정된 파일 목록과 각 파일의 핵심 변경 내용을 저장합니다.
- 실패한 테스트, 재현 명령, 아직 처리하지 않은 항목을 별도 기록합니다.
- 컴팩션을 실행한 뒤 에이전트에게 현재 목표와 남은 작업을 다시 말하게 합니다.
- 압축 전과 같은 확인 질문을 던져 파일명, 테스트 상태, 사용자 제약을 비교합니다.
- 작은 재개 작업을 실행해 에이전트가 실제 작업 공간을 올바르게 사용하는지 확인합니다.
- 상태가 다르면 압축본을 폐기하고 원본 세션으로 돌아가거나 통제된 새 세션을 만듭니다.
코드 작업에서는 다음 다섯 항목 중 하나라도 빠지면 압축 성공으로 보지 마십시오.
- 최종 목표와 금지 조건
- 이미 수정한 파일과 수정 이유
- 실패한 테스트와 오류 원인
- 남은 작업과 우선순위
- 사용자가 지정한 출력 형식이나 환경 제약
SECTION 05세션 분할과 일시 정지 판단표
컴팩션이 항상 최선은 아닙니다. 목표가 바뀌거나 작업 공간의 경계가 달라졌다면 이전 기록을 줄이는 것보다 새 세션으로 격리하는 편이 낫습니다.
| 상태 | 권장 조치 | 이유 |
|---|---|---|
| 같은 저장소, 같은 목표, 기록만 증가 | 필요한 상태를 보존한 뒤 컴팩션 | 연속성이 중요함 |
| 새 기능으로 목표 변경 | 새 세션 | 이전 지침의 오염 방지 |
| 다른 저장소나 다른 작업 공간 | 새 세션 | 파일 경계 혼동 방지 |
| 실패 로그와 잘못된 추론이 반복됨 | 새 세션 또는 통제된 재개 | 오류 문맥의 누적 방지 |
| 감사가 필요한 작업 | 원본 로그 보관 후 요약 세션 | 추적성과 비용을 분리 |
| 당장 이어서 작업할 필요가 없음 | 세션 일시 정지 | 불필요한 호출과 환경 점유 방지 |
비용과 환경을 함께 기록하는 점검 목록
- [ ] 요청별 입력 전체 토큰을 저장했습니까?
- [ ] 캐시 적중 토큰과 미적중 토큰을 분리했습니까?
- [ ] 출력 토큰과 응답 시간을 함께 기록했습니까?
- [ ] 긴 도구 결과의 원본 위치와 축약본을 연결했습니까?
- [ ] 컴팩션 전후에 같은 확인 질문을 실행했습니까?
- [ ] 수정 파일, 실패 테스트, 남은 작업이 복원됐습니까?
- [ ] 프로세스 메모리와 저장 공간 증가량을 확인했습니까?
- [ ] 동일한 기준 작업으로 조정 전후를 비교했습니까?
- [ ] 복구에 걸린 사람의 시간을 비용 판단에 포함했습니까?
하니스 저장소나 모델 호출 환경을 장시간 켜 두면 API 비용과 별개로 메모리, 저장 공간, 동시 작업 간섭이 누적될 수 있습니다. 같은 기준 작업을 압축 전후에 반복하고, 비용이 낮아졌더라도 응답 지연이나 복구 작업이 늘었다면 최적화가 성공했다고 보지 마십시오.
SECTION 06자주 묻는 운영 판단
캐시가 높으면 압축하지 않아도 됩니까?
아닙니다. 캐시는 반복되는 접두부를 재사용할 뿐입니다. 새 도구 결과와 대화 기록이 계속 추가되면 전체 문맥은 커집니다. 적중률과 함께 입력 전체 토큰, 미적중 토큰, 출력 토큰을 기록해야 합니다.
컴팩션 요약이 원본 기록을 대신할 수 있습니까?
감사, 장애 분석, 규정 준수가 필요한 작업에서는 대신할 수 없습니다. 원본 대화와 도구 산출물은 별도 보관하고, 컴팩션 결과는 작업 재개용 문맥으로만 사용해야 합니다.
도구 결과를 모두 짧게 만들면 비용이 가장 낮아집니까?
아닙니다. 오류 위치와 재현 정보까지 잘라내면 에이전트가 같은 명령을 반복 실행할 수 있습니다. 비용 절감은 결과의 길이가 아니라 다음 작업에 필요한 정보의 밀도로 판단해야 합니다.
SECTION 07현재 환경과 맥 환경을 함께 비교하는 시점
현재 환경에서 긴 세션을 계속 실행하면 로컬 프로세스가 메모리와 저장 공간을 오래 점유하고, 여러 작업이 같은 작업 공간과 네트워크 자원을 공유하게 됩니다. 여기에 세션 복구를 위해 로그를 직접 정리해야 하고, 개발 장비를 다른 사람이 사용할 수 없다는 운영 비용도 생깁니다.
반면 맥 환경을 임시 실행 공간으로 분리하면 작업별 점유 시간을 나누고, 테스트용 세션과 본 작업을 격리하기 쉬워집니다. 다만 장기간 같은 작업을 계속 실행하거나 물리 장치 접근이 필요하다면 직접 구매한 맥이 더 적합할 수 있습니다. 일시적인 에이전트 실행, 재현 테스트, 여러 환경의 짧은 비교가 목적이라면 맥 대여 요금과 사용 조건을 먼저 확인하고, 필요한 기간만 MACNOX 맥 환경 주문과 비교하는 편이 합리적입니다.
비용 문제와 함께 로컬 장비의 장기 점유, 여러 작업의 충돌까지 확인됐다면 다음 단계는 모델 단가만 낮추는 것이 아닙니다. 동시 작업 수와 점유 시간을 기준으로 클라우드 맥 환경을 나누어 보고, MACNOX의 맥 환경 선택지를 검토한 뒤 컴팩션과 새 세션 분할을 어떤 환경에 적용할지 결정해야 합니다.
SECTION 08자주 묻는 질문 FAQ
캐시 적중률이 높은데도 토큰 사용량이 계속 늘어나는 이유는 무엇입니까?
캐시는 반복되는 입력 접두부의 비용 경로를 낮출 뿐, 매 요청에 전달되는 전체 문맥의 크기 자체를 없애지 않습니다. 새 대화, 도구 결과, 시스템 지침과 모델 출력이 계속 누적되면 입력 토큰 총량은 증가할 수 있습니다. 응답의 사용량 항목에서 적중 토큰과 미적중 토큰을 따로 기록해야 정확한 원인을 확인할 수 있습니다.
컴팩션을 실행하면 코드 작업의 중요한 문맥이 사라질 수 있습니까?
그럴 수 있습니다. 요약문에 목표, 수정한 파일, 실패한 테스트, 남은 작업과 사용자 제약이 빠지면 에이전트가 이전 상태를 잘못 복원할 수 있습니다. 압축 전후에 같은 확인 질문과 작업 재개 동작을 실행하고, 파일 상태와 테스트 결과가 일치하지 않으면 압축본을 폐기하고 원래 세션으로 돌아가야 합니다.
언제 기존 세션을 압축하고 언제 새 세션을 만들어야 합니까?
같은 목표와 같은 작업 공간을 유지하면서 기록만 길어진 경우에는 필요한 상태를 보존한 뒤 컴팩션을 적용하는 편이 적절합니다. 목표가 바뀌었거나 저장소 경계가 달라졌거나 잘못된 추론과 실패 로그가 누적된 경우에는 새 세션이 안전합니다. 감사가 필요한 작업은 원본 기록을 별도 보관한 뒤 요약 세션을 사용해야 합니다.
도구 반환 결과가 너무 길 때 문맥 점유를 줄이는 방법은 무엇입니까?
전체 로그를 매번 대화에 넣지 말고 성공 여부, 오류 핵심, 관련 파일, 재현 명령과 외부 저장 위치를 남기는 방식으로 축약해야 합니다. 빌드 로그는 실패 구간과 앞뒤 문맥을 보존하고, 검색 결과는 인용에 필요한 원문과 주소를 별도 산출물로 저장합니다. 재현에 필요한 증거까지 삭제하면 비용은 줄어도 복구 가능성이 떨어집니다.
긴 세션 비용은 어떤 데이터로 계산해야 합니까?
요청별 입력 토큰, 출력 토큰, 캐시 적중 토큰, 캐시 미적중 토큰을 기본값으로 기록해야 합니다. 여기에 요청 횟수, 응답 시간, 프로세스 메모리, 저장 공간 증가량과 사람이 복구하는 시간을 함께 봐야 합니다. 비용은 각 토큰 유형에 해당 단가를 곱해 합산하고, 한 번의 낮은 청구액이 아니라 동일한 기준 작업의 반복 결과로 판단해야 합니다.