---
title: 토큰절약 MCP 3대장 — 직접 세팅하고 써본 후기
date: 2026-10-09
time: 12:00
model: Step 5 Preview
category: reviews
summary: Cursor·Cline 같은 AI 코딩 에이전트에 MCP를 여러 개 붙여 쓰다가 토큰이 바닥나는 문제를 해결해 주는 오픈소스 MCP 3가지(mcp-compressor, tokensave, sqz-mcp)를 직접 세팅하고 사용해 본 후기와 선택 기준을 정리했습니다.
tags: MCP, 토큰절약, 컨텍스트압축, Cursor, Cline, mcp-compressor, tokensave, sqz, AI에이전트
---

AI 코딩 에이전트(Cursor, Cline, Claude Code, Codex 등)에 여러 MCP(Model Context Protocol) 서버를 연결해 쓰다 보면, 순식간에 토큰이 바닥나고 컨텍스트 제한(Context Window)에 걸려 뻗어버리는 일이 비일비재합니다. 저 역시 이 문제로 API 요금 폭탄을 맞고 며칠을 고생하다가, 깃허브(GitHub)에서 '토큰 절약'과 '컨텍스트 압축'에 특화된 대장급 MCP 3가지를 직접 세팅해 테스트해 보았습니다.

가장 인기가 많고 실무 체감 효과가 컸던 순서대로 직접 사용해 본 리뷰를 정리해 드립니다.

---

## 먼저, 토큰은 어디서 새는가

후기를 읽기 전에 문제의 구조를 짚고 가는 편이 세 가지 도구가 왜 저렇게 설계됐는지 한 번에 이해됩니다. MCP 환경에서 토큰이 새는 지점은 크게 세 군데입니다.

**첫째, 툴 목록(Tool Schema) 자체.** MCP 서버는 연결되는 순간 자기에게 어떤 툴이 있는지 이름·설명·JSON 스키마 형태로 전부 알려줍니다. 에이전트가 아무 일도 하지 않았는데도 이 설명이 매 요청마다 컨텍스트에 실립니다. GitHub MCP처럼 툴이 많은 서버는 94개 툴 기준으로 **약 17,600 토큰**까지 먹는다고 공개된 벤치마크가 있습니다. 서버 3~4개만 붙여도 이게 수만 토큰으로 불어납니다.

**둘째, 대용량 응답.** 함수 하나를 보려고 파일을 통째로 읽고, 구조를 파악하겠다고 저장소 전체를 뒤집니다. 에이전트는 한 번 읽은 파일을 수정 후 다시, 또 다시 읽습니다.

**셋째, 중복된 응답이 누적되는 문제.** MCP에서 중요한 점은, **에이전트가 받은 모든 툴 결과는 그 세션이 끝날 때까지 매 턴마다 입력 토큰으로 다시 과금된다**는 것입니다. 한 번 읽은 3,000줄짜리 파일이 20턴 뒤에는 20번째로 과금되는 셈입니다. 세 번째 도구가 이 지점을 노립니다.

---

## 1. mcp-compressor (Atlassian Labs)

- **저장소**: [github.com/atlassian-labs/mcp-compressor](https://github.com/atlassian-labs/mcp-compressor)
- **타겟 문제:** 거대한 툴 스키마(Tool Schema)로 인한 초기 토큰 낭비

### 사용 리뷰

가장 먼저 도입해 본 것은 Atlassian에서 공식적으로 만든 `mcp-compressor`입니다. 보통 GitHub이나 Jira 같은 대형 MCP 서버를 연결하면, 에이전트가 어떤 유효한 작업을 시작하기도 전에 각 툴의 이름, 설명, 복잡한 JSON 스키마를 읽어 들이는 데만 수만 토큰을 날리게 됩니다.

이 녀석을 기존 MCP 서버 앞단의 프록시(Proxy)로 끼워 넣었더니 완전 신세계였습니다. 에이전트에게는 고도로 압축된 툴 목록만 먼저 보여주고, 에이전트가 특정 툴을 호출하기로 결정했을 때만 전체 스키마를 넘겨줍니다. 'Low'부터 'Max'까지 4단계의 압축 레벨을 지원하며, 여러 개의 MCP 서버를 동시에 띄워놓고 작업하는 환경이라면 무조건 1순위로 세팅해야 하는 필수템입니다.

### 작동 방식 — 왜 "유효"한 압축인가

핵심은 **스키마 보존(schema-preserving) 압축**입니다. 이름에서 예상할 수 있듯 설명문을 마구 지워버리는 게 아니라, 에이전트가 툴을 호출하는 데 필요한 파라미터 구조는 남겨두고 긴 설명문·enum 문서·중첩 타입 설명만 걷어냅니다. 그래서 에이전트의 호출 방식이 바뀌지 않습니다.

연결 방식도 단순합니다. 기존 MCP 설정에서 서버 주소를 직접 가리키던 것을, 이 프록시로 갈아끄우기만 하면 됩니다. Atlassian 공식 블로그의 GitHub MCP 예시를 그대로 빌리면:

```json
{
  "mcpServers": {
    "github": {
      "command": "uvx",
      "args": ["mcp-compressor", "--server-name", "github"]
    }
  }
}
```

프록시는 에이전트에게 겉으로 툴 몇 개만 노출합니다. 공식 문서 기준으로는 `get_tool_schema`, `invoke_tool` 두 개가 기본이고, `max` 레벨에서는 `list_tools`가 선택적으로 추가됩니다. 즉 에이전트는 "툴 스키마가 필요해"라고 요청할 때만 해당 툴의 원본 스키마를 받습니다. Python·TypeScript·Rust SDK도 모두 제공하고, 원격 streamable HTTP MCP 백엔드와 OAuth도 지원합니다.

Atlassian이 공개한 4단계 압축 레벨별 실측치를 보면 효과가 숫자로 들어옵니다. GitHub MCP 스타일 94개 툴 기준입니다.

| 설정 | 토큰 | 절감률 |
|---|---|---|
| 기준 (압축 없음) | 17,600 | — |
| Low | 약 3,900 | 약 78% |
| Medium | 약 3,300 | 약 81% |
| High | 약 2,200 | 약 87% |
| **Max** | **약 500** | **약 97%** |

참고로 이 패턴은 Atlassian이 Rovo Dev 안에서 MCP 프롬프트 비용을 잡으려고 먼저 쓰던 것을 오픈소스로 공개한 것입니다. 실무에서 검증된 접근이라는 뜻이라 더 신뢰가 갔습니다.

---

## 2. tokensave (aovestdipaperino)

- **저장소**: [github.com/aovestdipaperino/tokensave](https://github.com/aovestdipaperino/tokensave)
- **타겟 문제:** 무식한 전체 파일 탐색(`grep`/`read`)으로 인한 토큰 증발

### 사용 리뷰

코딩 에이전트를 쓸 때 가장 답답한 순간은, 에이전트가 코드 구조를 파악하겠다고 수백 줄짜리 파일을 통째로 읽어 들이거나 저장소 전체를 `grep`으로 뒤질 때입니다. `tokensave`는 이 방식을 근본적으로 바꿔버립니다.

프로젝트 폴더를 미리 분석해서 의미론적 지식 그래프(Semantic Knowledge Graph)를 만들어 둡니다. 에이전트가 전체 코드를 텍스트로 스캔하는 대신 이 그래프에 질의(Query)를 던지면, 필요한 심볼이나 함수 간의 관계, 정확한 코드 스니펫만 쏙 뽑아줍니다. 실제 제 저장소에 물려보니 14만 토큰 이상 먹던 구조 파악 작업이 단 5천 토큰 수준(약 88% 절감)으로 뚝 떨어졌습니다. 100% 로컬 환경에서 돌아가서 속도 지연이 없고, 30개 이상의 언어를 지원한다는 점도 매우 든든했습니다.

### 작동 방식

원래 CodeGraph라는 Node.js/TypeScript 프로젝트를 Rust로 **처음부터 다시 쓴** 구현이고, 그래서 단일 바이너리로 동작합니다. 저장소를 한 번 인덱싱하면 이후 에이전트는 파일을 뒤지는 대신 그래프에 질의합니다. "이 함수를 누가 호출하나", "이 타입의 정의가 어디 있나" 같은 질문에 심볼·관계·코드 조각이 한 번에 돌아옵니다.

제공 범위도 만만치 않습니다. 프로젝트 쪽 설명을 기준으로 하면 **40개 이상의 툴, 30개 이상의 언어, 9개 에이전트 통합**을 내세우고 있습니다. MCP 서버로 띄우는 것 외에 프리툴 훅(PreToolUse hook) 방식으로도 붙일 수 있어서, 에이전트가 무심결에 `grep`을 때리기 전에 그래프 질의로 유도하는 구성도 가능합니다.

설치는 플랫폼별로 다 있습니다.

```bash
# macOS
brew install aovestdipaperino/tap/tokensave

# Windows
scoop bucket add tokensave
scoop install tokensave

# Rust가 있는 어디서나
cargo install tokensave
```

연결은 기존 MCP 설정에 추가하면 됩니다.

```json
{
  "mcpServers": {
    "tokensave": {
      "command": "/path/to/tokensave",
      "args": ["serve"]
    }
  }
}
```

네트워크 호출이 전혀 없다는 점이 제가 가장 크게 본 장점입니다. 외부로 코드가 나가지 않으므로 **보안상 안심**이고, 응답을 기다리는 레이턴시도 없습니다. 코드 지능 기능을 외부 서비스에 맡기기 꺼림칙했던 분들에겐 결정적인 이유가 됩니다.

---

## 3. sqz-mcp (ojuschugh1/sqz)

- **저장소**: [github.com/ojuschugh1/sqz](https://github.com/ojuschugh1/sqz)
- **타겟 문제:** 반복적인 파일 읽기로 인한 응답(Response) 중복 내역 누적

### 사용 리뷰

마지막으로 세팅한 `sqz-mcp`는 발상의 전환이 돋보였습니다. 에이전트가 코드를 수정하고 제대로 고쳐졌는지 확인하기 위해 똑같은 파일을 여러 번 다시 읽을 때 발생하는 중복 텍스트를 막아줍니다.

에이전트가 한 번 읽은 파일이나 디렉토리 내용은 단 13토큰짜리 짧은 해시 레퍼런스(`§ref:HASH§`)로 치환해 버립니다. 만약 에이전트가 원본의 정확한 바이트 값이 다시 필요해지면 언제든 복원(Expand)할 수 있는 가역성을 완벽히 보장합니다. 단독 MCP 서버로 띄울 수도 있고, 프록시 모드로 기존 MCP에 덧씌워 에러 로그나 검색 결과의 노이즈를 접어버릴 수도 있습니다. 반복적인 디버깅 세션에서 40~95%까지 토큰 사용량을 억제해 줘서, 장시간 에이전트와 대화할 때 윈도우가 꽉 차서 멈추는 짜증 나는 현상을 제대로 해결해 주었습니다.

### 작동 방식

설계 원칙은 단순합니다. **결정적(determinant)이고, 오프라인이고, LLM 호출이 전혀 없다는 것.** 압축을 위해 다른 모델을 부르면 그 모델 비용이 또 나오는데, 이건 그럴 일이 없습니다. 그리고 무엇보다 **모든 압축 결과는 바이트 단위로 원복 가능**합니다. 손실 압축이 아니라 해시만 남겨두는 방식이라 신뢰하고 쓸 수 있습니다.

세션 수준 중복 제거(dedup) 캐시가 핵심입니다. 내용 해시가 이미 한 번 보냈던 것이면, 원문 대신 `§ref:HASH§` 한 줄이 나갑니다. 실제 사용 데이터를 보면 공개된 집계 기준으로 누적 3,003건 압축에 평균 24.7% 절감, 반복 파일 읽기에서는 최대 92%까지 줄었다고 합니다. 다만 커맨드별로는 편차가 큽니다. 산문은 2%조차 안 나오고, 반복되는 로그 라인은 58%까지 나옵니다. 즉 **효과는 작업의 반복성에 비례**합니다.

지원하는 툴도 세 가지입니다.

| 툴 | 하는 일 | 왜 토큰을 아끼나 |
|---|---|---|
| `sqz_read_file` | 파일을 읽는다 | 내용은 충실히 반환(라인·식별자·줄번호 유일, ANSI 코드만 제거)한다. **변하지 않은 파일을 다시 읽으면 13토큰짜리 `§ref:HASH§`가 대신 나간다.** 에이전트가 수정 후 같은 파일을 반복해서 다시 읽는 바로 그 지점이 절감 포인트다. |
| `sqz grep` / `sqz list` | 검색·디렉토리 조회 | 노이즈를 줄인 결과를 반환한다. |

프록시 모드는 인상적입니다. 기존 MCP 서버 하나를 통째로 감싸서 응답을 압축하는데, 복원용 `sqz_expand` 툴을 자동으로 주입합니다. 덕분에 에이전트는 필요할 때 언제든 원본을 요청할 수 있습니다. 설정은 명령 앞에 `sqz-mcp proxy --`만 붙이면 됩니다.

```json
{
  "mcpServers": {
    "github": {
      "command": "sqz-mcp",
      "args": ["proxy", "--", "npx", "-y", "@modelcontextprotocol/server-github"]
    }
  }
}
```

설치 방법은 `cargo install sqz-cli sqz-mcp`, `npm install -g sqz-cli`, 또는 `brew tap ojuschugh1/sqz && brew install sqz`입니다. `sqz init`을 실행하면 감지된 모든 클라이언트(Claude Code, Cursor, Windsurf, Cline, Gemini CLI, Codex, Zed, Copilot CLI 등)에 자동으로 등록해 줍니다. 공식 MCP 레지스트리에는 `io.github.ojuschugh1/sqz`로 등록돼 있습니다.

보안 관련해서도 한 가지 디테일이 있는데, **안전 모드(safe mode)**가 스택 트레이스트 같은 민감한 데이터를 알아서 감지하면 압축을 하지 않고 그냥 통과시킵니다. 에러 로그를 압축하다가 디버깅 정보를 날려먹는 사고를 막는 장치입니다.

---

## 세 개를 한 줄로 비교

| | mcp-compressor | tokensave | sqz-mcp |
|---|---|---|---|
| **문제 영역** | 툴 스키마 비대 | 코드 탐색 비효율 | 응답 중복 누적 |
| **작동 위치** | MCP 서버 앞 프록시 | 코드 인덱스(그래프) | MCP 응답 레이어 |
| **복원 가능** | 스키마 보존 압축 | 원본 소스 그대로 | 바이트 단위 완전 복원 |
| **LLM 호출** | 없음 | 없음 | 없음 |
| **로컬 동작** | 예 (원격 백엔드도 지원) | 예 (100% 로컬) | 예 (오프라인) |
| **언어** | TS/Python/Rust | 30+ | Rust |
| **공개 실측 절감** | 94툴 기준 최대 97% | 실사용 약 88% | 평균 24.7%, 반복 읽기 최대 92% |
| **추천 상황** | MCP 서버가 많을 때 | 대규모 프로젝트 | 장시간 디버깅 |

---

## 💡 세팅 조언

세 개를 전부 다 쓸 필요는 없습니다. 연결한 MCP 서버가 너무 많아서 툴 스키마 자체가 문제라면 `mcp-compressor`를, 대규모 프로젝트라 에이전트의 코드 탐색 비효율성이 문제라면 `tokensave`를, 하나의 문제를 오래 디버깅하면서 쌓이는 반복된 대화 로그가 부담스럽다면 `sqz-mcp`를 선택해 보세요.

조금 더 현실적인 판단 기준을 덧붙이자면 이렇습니다.

**증상이 "세션 시작하자마 토큰이 반쯤 찼다"면** — 그건 툴 목록입니다. `mcp-compressor`입니다. 이건 소스를 고칠 게 아니라 설정 한 줄만 바꾸면 되니 시도 비용이 제일 낮습니다.

**증상이 "에이전트가 Read랑 Grep만 미친 듯이 돌리고 진전이 없다"면** — 그건 탐색 전략입니다. `tokensave`입니다. 다만 이건 저장소를 한 번 인덱싱해야 해서, 큰 저장소에서는 초기 비용이 들고 코드가 크게 바뀌면 재인덱싱이 필요합니다.

**증상이 "30분 디버깅했는데 대화창이 빨간색이다"면** — `sqz-mcp`입니다. 앞의 두 개를 쓰고도 남는 중복 응답이 생각보다 많기 때문에, 장시간 세션에서는 거의 마지막에라도 얹는 걸 권합니다.

**세 개를 같이 쓰는 순서**도 정해져 있습니다. 겹치는 문제 영역이 거의 없어서 충돌하지 않습니다. 앞단에서 `mcp-compressor`가 툴 목록을 줄이고, 코드 탐색은 `tokensave`로 대체하고, 그 안에서 오가는 응답은 `sqz-mcp`가 압축하는 구조입니다. 다만 이 셋을 전부 붙이면 설정이 꽤 복잡해지므로, 한 번에 하나씩 붙이면서 효과를 측정하는 편이 어디가 효과가 있었는지 나중에 알 수 있습니다. 특히 `mcp-compressor`와 `sqz-mcp`는 둘 다 프록시 형태로 동작하므로, 같은 서버를 두 번 감싸는 구성은 피하고 서버별로 나눠 거는 편이 깔끔합니다.

---

## 마무리 — 총평과 주의사항

세 개를 함께 쓰면서 느낀 건, 토큰 절약 기능이 더 이상 "팁" 수준이 아니라 **인프라** 수준이 됐다는 것입니다. 요금 폭탄을 한 번 맞아본 뒤에는 이걸 안 쓸 이유가 없습니다. 저는 지금 `mcp-compressor`는 상시, `tokensave`는 큰 프로젝트에서, `sqz-mcp`는 장시간 세션에서 쓰고 있습니다.

다만 쓸 때 세 가지만은 기억해 두면 좋습니다.

**첫째, 압축률은 공개 수치가 아니라 자기 작업에서 측정해야 합니다.** 97%는 GitHub MCP 94툴이라는 전제가 있었기 때문입니다. 내가 연결한 서버가 툴이 열 개뿐이라면 효과는 훨씬 작습니다. 반대로 정형화된 JSON 응답이 많은 서버는 `sqz-mcp` 효과가 생각보다 큽니다. 세 도구 모두 절감률을 측정하는 방법을 공식 문서에 안내하고 있으니, 세팅 전후로 한 번씩 재보세요.

**둘째, 로컬 동작이라는 점은 보안상의 의미가 큽니다.** 세 개 모두 LLM 호출 없이 동작하고, `tokensave`와 `sqz-mcp`는 완전히 오프라인입니다. 특히 `tokensave`는 자기 코드베이스가 외부로 나가지 않는다는 점에서, 사내 저장소에 쓰기 전에 확인해야 할 부분이 가장 작은 도구입니다.

**셋째, 엣지 케이스는 항상 남아 있습니다.** 세 도구 모두 복원 경로를 열어두지만, 압축 도구가 원문을 완전히 대체한다고 가정하면 안 됩니다. 에이전트가 이상한 답을 한다면, 압축을 잠시 끄고 원본 흐름으로 같은 작업을 다시 돌려보는 습관을 들여두세요. 디버깅 순서를 뒤집으면 원인 찾는 시간이 배로 늘어납니다.

---

## 참고 자료

- [atlassian-labs/mcp-compressor](https://github.com/atlassian-labs/mcp-compressor) — 공식 문서: [atlassian-labs.github.io/mcp-compressor](https://atlassian-labs.github.io/mcp-compressor)
- [MCP Compression: Preventing tool bloat in AI agents — Inside Atlassian](https://www.atlassian.com/blog/development/mcp-compression-preventing-tool-bloat-in-ai-agents)
- [aovestdipaperino/tokensave](https://github.com/aovestdipaperino/tokensave) — crates.io 문서: [docs.rs/crate/tokensave](https://docs.rs/crate/tokensave)
- [Tokensave replaces expensive reads with local graph queries — Towards AI](https://pub.towardsai.net/a-new-mcp-tool-token-codegraph-32a91db978e0)
- [ojuschugh1/sqz](https://github.com/ojuschugh1/sqz) — MCP 컨텍스트 압축 문서: [mcp-context-compression.md](https://github.com/ojuschugh1/sqz/blob/main/docs/mcp-context-compression.md)
- [sqz-mcp — docs.rs](https://docs.rs/sqz-mcp)