코딩으로 하루종일 써도 0.1달러가 나온다? (DeepSeek-Reasonix)

DeepSeek-Reasonix는 어떻게 딥시크 캐시 히트를 끌어올렸나

 

에이전트 비용 최적화의 핵심은 ‘더 똑똑한 모델’이 아니라 ‘흔들리지 않는 프롬프트 구조’일 수 있다

요즘 코딩 에이전트나 장시간 작업 에이전트를 만들다 보면 가장 먼저 부딪히는 문제가 있다.
바로 토큰 비용이다.

한두 번 질문하는 챗봇이라면 큰 문제가 아니다. 하지만 코드 분석, 파일 수정, 장편 글쓰기, 리서치, 영상 프롬프트 제작처럼 여러 턴에 걸쳐 작업하는 에이전트는 구조가 다르다.

매번 이전 대화, 시스템 프롬프트, 도구 목록, 작업 결과, 파일 내용, 중간 상태를 다시 모델에 넣는다.
그러다 보면 실제로 새로 입력하는 내용은 얼마 안 되는데, 매 요청마다 수만 토큰의 이전 맥락을 반복해서 보내는 상황이 생긴다.

이때 DeepSeek API의 context caching, 즉 캐시 기능을 잘 활용하면 비용 구조가 크게 달라질 수 있다.
GitHub의 DeepSeek-Reasonix 프로젝트는 바로 이 지점을 꽤 영리하게 파고든 에이전트 프레임워크다.

---

DeepSeek 캐시는 무엇을 캐시하는가

DeepSeek API는 context caching을 기본적으로 제공한다. 핵심은 단순하다.

이전 요청과 다음 요청의 앞부분이 같으면, 그 겹치는 prefix 부분을 캐시 히트로 처리할 수 있다.

예를 들어 첫 번째 요청이 다음과 같다고 하자.

A + B

두 번째 요청이 다음처럼 들어오면,

A + B + C

앞의 A + B는 이전 요청과 동일하기 때문에 캐시 히트가 발생할 수 있다.

반대로 두 번째 요청이 이렇게 바뀌면,

A + C + B

겉보기에는 비슷한 정보가 들어 있어도 prefix 구조가 달라진다. 이 경우 캐시 효율은 떨어질 수 있다.

중요한 점은 이것이다.

DeepSeek 캐시는 “의미가 비슷한가”보다 “앞부분이 얼마나 그대로 유지되는가”에 더 민감하다.

그래서 에이전트 설계에서 캐시를 잘 쓰려면 모델을 잘 고르는 것만으로는 부족하다.
프롬프트 구조 자체를 캐시 친화적으로 만들어야 한다.

---

일반 에이전트는 왜 캐시 히트가 낮아지기 쉬운가

많은 에이전트는 매 턴마다 프롬프트를 새로 조립한다.

시스템 프롬프트를 다시 만들고, 도구 목록을 다시 직렬화하고, 최근 작업 상태를 요약해서 앞부분에 붙이고, 파일 내용이나 실행 결과를 재정렬한다.

문제는 이 과정에서 프롬프트의 앞부분이 조금씩 흔들린다는 점이다.

예를 들어 이런 요소들이 캐시 효율을 떨어뜨릴 수 있다.

- system prompt가 매번 조금씩 바뀜
- tool schema 순서가 바뀜
- 도구 실행 결과가 앞부분에 삽입됨
- 타임스탬프나 상태값이 prompt 초반에 들어감
- 중간 reasoning 내용이 다음 요청에 다시 포함됨
- context compaction이 너무 자주 발생함
- planner 모델과 executor 모델이 같은 세션에 섞임

사람이 보기에는 사소한 차이일 수 있다.
하지만 prefix cache 입장에서는 앞부분이 바뀐 것이다.

캐시는 “대충 비슷한 프롬프트”를 좋아하는 것이 아니라, “이전에 본 프롬프트의 앞부분이 그대로 이어지는 구조”를 좋아한다.

---

Reasonix의 핵심 전략: 앞부분은 고정하고 뒤에만 붙인다

DeepSeek-Reasonix의 핵심 설계는 아주 단순하게 요약할 수 있다.

대화의 앞부분을 가능한 한 고정하고, 새로운 내용은 뒤에만 append한다.

즉, 에이전트 세션을 하나의 로그처럼 다룬다.

1턴:
system + user1

2턴:
system + user1 + assistant1 + tool1 + user2

3턴:
system + user1 + assistant1 + tool1 + user2 + assistant2 + tool2 + user3

이 구조에서는 앞부분이 계속 유지된다.
새 요청이 들어와도 기존 대화의 prefix가 그대로 남아 있기 때문에 DeepSeek의 캐시가 작동하기 좋은 형태가 된다.

이것은 특별한 마법이라기보다, DeepSeek의 캐시 과금 구조에 맞춰 에이전트의 대화 관리 방식을 바꾼 것이다.

---

Reasoning content를 다시 보내지 않는 설계

Reasonix에서 특히 눈에 띄는 부분은 assistant의 reasoning content를 다음 API 요청에 다시 넣지 않는다는 점이다.

추론 과정은 길고, 매번 달라지고, 다음 요청에 꼭 필요한 정보가 아닐 때가 많다.
이런 내용을 계속 prompt에 포함하면 입력 토큰도 커지고, prefix 안정성도 떨어질 수 있다.

Reasonix는 reasoning content를 세션 기록이나 화면 표시용으로는 다룰 수 있지만, 다음 모델 호출의 prompt input에는 다시 넣지 않는 방향을 취한다.

구조적으로 보면 이런 차이다.

비효율적인 구조:
system + history + assistant reasoning + tool result + user

Reasonix에 가까운 구조:
system + history + assistant visible content + tool result + user

이 차이는 작아 보이지만 장시간 실행되는 에이전트에서는 꽤 중요하다.

특히 DeepSeek처럼 reasoning 모델을 사용할 경우, reasoning output을 다시 input으로 넣는 순간 비용이 커질 수 있다.
또한 reasoning은 변동성이 큰 내용이라 캐시 prefix를 오염시키기 쉽다.

결국 Reasonix는 “보관할 것”과 “다음 프롬프트에 다시 넣을 것”을 분리한다.

---

Tool schema와 system prompt를 안정적으로 유지한다

에이전트에서 tool schema는 생각보다 큰 토큰 덩어리다.
파일 읽기, 셸 실행, 검색, 수정, 패치, 플러그인, MCP 도구 등이 많아질수록 tool definition은 길어진다.

그런데 이 tool schema가 매번 순서가 바뀌거나 JSON 구조가 조금씩 달라지면 어떻게 될까?

캐시 입장에서는 앞부분이 흔들린다.

Reasonix의 설계 방향은 system prompt와 tool specs를 세션 앞부분에 안정적으로 두고, 가능하면 이를 바꾸지 않는 것이다.

[Stable Prefix]
- system prompt
- tool definitions
- project rules
- output format rules

[Append-only Log]
- user request
- assistant response
- tool result
- next user request

이런 구조를 유지하면, 매 턴 새로 추가되는 부분은 뒤쪽에 쌓이고, 앞부분은 계속 캐시 대상으로 남는다.

---

Planner와 Executor를 같은 세션에 섞지 않는다

Reasonix의 또 다른 흥미로운 설계는 planner model과 executor model을 분리해서 운영하는 방식이다.

복잡한 에이전트에서는 보통 두 가지 역할이 필요하다.

Planner:
무엇을 할지 계획하는 역할

Executor:
실제로 도구를 호출하고 작업을 수행하는 역할

문제는 이 둘을 같은 대화 세션에 섞으면 prompt prefix가 복잡해진다는 점이다.
특히 서로 다른 모델을 번갈아 호출하면 캐시 효율이 떨어질 수 있다.

Reasonix는 이 문제를 피하기 위해 planner session과 executor session을 분리하는 구조를 취한다.

planner session:
planner system + planner history

executor session:
executor system + tool schema + executor history

이렇게 하면 각 세션의 prefix가 독립적으로 안정화된다.

즉, “멀티 모델 협업”을 하더라도 하나의 세션에 마구 섞는 것이 아니라, 캐시가 유지되기 좋은 단위로 나누는 것이다.

---

Compaction은 필요하지만 자주 하면 안 된다

장시간 실행되는 에이전트는 언젠가 context window 한계에 도달한다.
이때 필요한 것이 compaction이다.

compaction은 오래된 대화나 작업 기록을 요약해서 context를 줄이는 과정이다.

하지만 캐시 관점에서 compaction은 조심해야 한다.
왜냐하면 오래된 대화 앞부분을 요약문으로 바꾸는 순간, 이전에 유지되던 prefix 구조가 깨질 수 있기 때문이다.

즉, compaction은 비용을 줄이는 기능이면서 동시에 캐시를 리셋할 수 있는 이벤트다.

Reasonix는 compaction을 너무 자주 하지 않고, context window가 일정 비율 이상 찼을 때만 수행하는 방식으로 설계되어 있다.

흐름은 대략 이렇다.

평소:
system + old history + recent history + new turn
=> cache hit가 유지되기 쉬움

compaction 시점:
system + summary + recent history
=> 기존 prefix 일부가 깨질 수 있음

compaction 이후:
system + summary + recent history + new turns
=> 다시 append-only 구조로 캐시 효율 회복

핵심은 compaction 자체를 없애는 것이 아니다.
compaction을 “매번 하는 정리 작업”이 아니라 “가끔 발생하는 캐시 리셋 포인트”로 다루는 것이다.

---

Reasonix가 주장하는 캐시 히트 수치

Reasonix 저장소에는 실제 사용 사례로 매우 높은 cache hit ratio가 제시되어 있다.
문서 기준으로는 99% 이상의 input cache hit ratio를 기록한 사례도 소개되어 있다.

다만 이 수치는 프로젝트 측이 공개한 사례이며, 독립적으로 재현된 벤치마크라고 보기는 어렵다.
따라서 이 숫자 자체를 그대로 일반화하기보다는, “이런 구조를 만들면 DeepSeek 캐시가 잘 작동할 가능성이 높다”는 방향으로 보는 것이 안전하다.

중요한 것은 숫자보다 구조다.

Reasonix가 보여주는 핵심은 다음과 같다.

1. system prompt를 고정한다.
2. tool schema를 고정한다.
3. 대화 로그를 append-only로 유지한다.
4. reasoning content를 다음 input에 다시 넣지 않는다.
5. compaction을 자주 하지 않는다.
6. planner와 executor 세션을 분리한다.
7. 모델별 세션을 섞지 않는다.
8. cache hit / cache miss usage를 계속 관측한다.

이 원칙들은 Reasonix뿐 아니라 다른 에이전트 시스템에도 적용할 수 있다.

---

이 구조가 중요한 이유

많은 사람들이 AI 에이전트 비용 최적화를 이야기할 때 가장 먼저 모델 가격을 본다.

물론 모델 가격도 중요하다.
하지만 장시간 실행되는 에이전트에서는 프롬프트 구조가 더 큰 차이를 만들 수 있다.

같은 모델을 쓰더라도 한쪽은 매번 전체 프롬프트를 새로 조립하고, 다른 한쪽은 안정적인 prefix를 유지한다면 비용 구조가 완전히 달라질 수 있다.

특히 코딩 에이전트, 리서치 에이전트, 글쓰기 에이전트, 영상 제작 에이전트처럼 작업 맥락이 길게 이어지는 시스템에서는 캐시 친화적인 세션 설계가 필수에 가까워진다.

단순히 말하면 이렇다.

비싼 에이전트:
매번 전체 문맥을 새로 만든다.

캐시 친화적인 에이전트:
한번 만든 앞부분을 최대한 유지하고, 뒤에만 쌓는다.

---

내가 에이전트를 만든다면 어떻게 적용할까

DeepSeek 기반으로 에이전트를 만든다면 다음과 같은 구조가 좋다.

[고정 Prefix]
- 시스템 프롬프트
- 역할 정의
- 출력 규칙
- 도구 목록
- 프로젝트 규칙
- 세계관/캐릭터/코드베이스 핵심 요약

[Append-only 작업 로그]
- 사용자 요청
- 에이전트 응답
- 도구 실행 결과
- 사용자 수정사항
- 다음 작업 지시

[Volatile Scratch]
- 내부 계획
- 임시 추론
- 실패한 후보
- 중간 생각
=> 다음 API 요청에는 넣지 않음

[Compaction]
- context가 커졌을 때만 수행
- 오래된 기록은 요약
- 최근 작업 tail은 유지
- compaction 이후 다시 append-only로 진행

이렇게 하면 DeepSeek의 prefix cache를 활용하기 좋은 구조가 된다.

특히 영상 제작 에이전트나 웹소설 제작 에이전트에도 이 방식은 잘 맞는다.

예를 들어 웹소설 기반 영상 제작 파이프라인을 만든다고 하자.

고정 Prefix:
세계관 규칙, 캐릭터 설정, 영상 스타일 규칙, 금지사항

Append-only Log:
회차별 줄거리, 장면별 프롬프트, 수정 피드백, 생성 결과

Volatile Scratch:
장면 후보, 임시 아이디어, 실패한 프롬프트, 내부 판단

Compaction:
완료된 회차는 요약하고, 현재 제작 중인 회차와 최근 피드백은 유지

이 구조는 단순히 비용 절감만을 위한 것이 아니다.
작업의 일관성도 좋아진다.

캐릭터 설정, 세계관 규칙, 스타일 가이드가 안정적인 prefix에 남아 있기 때문에 에이전트가 매번 다른 방향으로 튀는 문제도 줄일 수 있다.

---

결론: Reasonix의 진짜 포인트

DeepSeek-Reasonix의 핵심은 “새로운 캐시 기술을 직접 구현했다”가 아니다.

더 정확히 말하면,

DeepSeek API가 제공하는 prefix caching이 잘 작동하도록 에이전트 세션 구조를 설계했다.

에 가깝다.

이 차이가 중요하다.

캐시는 모델 제공사가 제공한다.
하지만 그 캐시를 얼마나 잘 먹게 만들지는 에이전트 설계자의 몫이다.

Reasonix는 그 지점을 잘 보여준다.

앞부분을 고정하고, 뒤에만 쌓고, reasoning은 다시 보내지 않고, compaction은 드물게 하고, 모델별 세션을 분리한다.

화려한 기능보다 이런 구조적 설계가 장시간 에이전트의 비용과 안정성을 좌우할 수 있다.

앞으로 DeepSeek 기반 에이전트를 만들거나, 코딩 에이전트·글쓰기 에이전트·영상 제작 에이전트를 설계한다면 Reasonix의 접근 방식은 참고할 만하다.

핵심은 결국 하나다.

에이전트 비용 최적화는 “토큰을 덜 쓰는 것”만이 아니라,
“반복되는 토큰이 캐시되도록 구조를 유지하는 것”이다.

 

GitHub - esengine/DeepSeek-Reasonix: DeepSeek-native AI coding agent for your terminal. Engineered around prefix-cache stability