Claude Code·Cursor·Codex에서 코드베이스를 그대로 넣지 않기: 압축 프록시 먼저 두기

2026년 4월 12일 | 개발 깨알 상식_Tips

---

Hacker News에 Cut Token Costs on Claude Code, Cursor, and Codex라는 제목이 올라와서 바로 저장소를 같이 열어봤다. 소개된 도구는 Entroly였고, 성격은 MCP(Model Context Protocol) 서버이자 컨텍스트 압축 엔진에 가깝다. 이름보다 더 눈에 들어온 건 접근 방식이었다. 요즘 코딩 에이전트가 자꾸 답을 헛치거나 같은 파일을 다시 붙여 넣게 만드는 이유 중 하나가, 모델이 멍청해서라기보다 코드베이스를 보는 방식이 너무 거칠기 때문인 경우가 많다. 중요한 파일은 전문을 보고, 주변 파일은 시그니처와 참조만 보고, 나머지는 링크처럼 다루는 식으로 해상도를 나눠 주겠다는 발상이 꽤 실전적이었다.

README에는 토큰 사용량을 70~95% 줄인다고 적혀 있다. 이런 숫자는 당연히 공급자 주장으로 읽는 편이 맞다. 그래도 내가 오늘 팁으로 남겨두고 싶은 건 숫자보다 구조다. 에이전트에게 코드를 더 많이 붙여 넣는 대신, 먼저 압축 프록시를 세우는 쪽이 낫다는 운영 감각 말이다. 긴 세션에서 파일 몇 개만 번갈아 복붙하다 보면 토큰도 새고, 중요한 의존성도 빠지고, 결국 같은 설명을 다시 하게 된다.

Figure 1. Entroly는 코드베이스를 한 덩어리로 밀어 넣는 대신, 해상도를 나눠 컨텍스트 창에 다시 배치하는 흐름을 전면에 내세운다.

이 그림에서 내가 좋게 본 건 "파일을 더 적게 보내자"가 아니라 같은 예산 안에서 더 넓게 보이게 하자는 쪽이다. 에이전트 작업은 결국 한 파일 수정이 아니라 주변 의존성과 이름 규칙, 설정 파일, 테스트 경로까지 같이 읽어야 안정적이다. 그런데 지금 많이들 하는 방식은 관련 파일 몇 개를 전문으로 던지고 나머지는 프롬프트로 설명하는 식이다. 이때 가장 먼저 무너지는 게 import 경로와 설정 연결이다.

1. raw dump가 생각보다 비싼 이유

나는 에이전트가 틀린 답을 냈을 때 종종 모델 탓부터 하기 쉬웠다. 그런데 실제로는 컨텍스트 예산을 쓰는 방식이 더 큰 문제일 때가 많다. 파일 몇 개를 통째로 복붙하면 당장은 안심되는데, 그 안에는 중복 import, 주석, boilerplate, 이미 아는 코드가 다 같이 들어간다. 반대로 정말 필요한 주변 파일은 창 밖에 남는다. 그러면 모델은 일부만 본 상태에서 전체 구조를 추정해야 하고, 그 추정이 바로 환각처럼 보이는 경우가 많다.

• 같은 헬퍼를 여러 번 설명하게 된다.
• 실제 수정 대상보다 붙여 넣은 파일 분량에 토큰을 더 많이 쓴다.
• 설정 파일, 테스트 경로, 의존 모듈이 빠진 상태에서 함수 시그니처를 추정하게 된다.
• 결국 다음 턴에서 "아 그 파일도 봐야 해"를 반복하게 된다.

이럴 때 압축 프록시나 컨텍스트 엔진이 의미를 갖는다. 핵심은 RAG처럼 비슷한 조각 몇 개만 뽑는 게 아니라, 코드베이스 전체를 해상도 다르게 넣어 보는 전략이다. 중요한 파일은 전문, 덜 중요한 파일은 요약, 나머지는 참조로 남겨서 전체 지도를 먼저 보여 주는 식이다. 에이전트가 당장 모든 줄을 읽지 않아도, 적어도 무엇이 어디 있는지는 잃지 않게 만드는 셈이다.

2. 오늘 바로 따라 해볼 최소 루프

좋았던 건 설치 진입이 생각보다 무겁지 않다는 점이었다. 실제 CLI 도움말 기준으로 demo, go, proxy, optimize 같은 명령이 이미 붙어 있다. 나는 이런 도구를 볼 때 무조건 상시 도입부터 하지 않고, 데모로 먼저 숫자와 체감만 확인하는 편이 덜 위험하다고 본다.

pip install entroly
entroly demo
entroly go

여기서 내가 먼저 볼 건 두 가지다. 첫째, 내 저장소에서 토큰 절감이 실제로 체감되는지. 둘째, 답변 품질이 진짜로 나아지는지다. 비용만 줄고 정답률이 같이 떨어지면 아무 의미가 없다. README 기준으로는 entroly go가 IDE 감지와 설정을 한 번에 잡아 주고, Claude Code 쪽은 아래처럼 MCP 등록도 가능하다고 적혀 있다.

claude mcp add entroly -- entroly
entroly proxy --quality balanced
# 기본 엔드포인트 예시: http://localhost:9377/v1

이 정도만 봐도 오늘의 팁은 꽤 선명해진다. 에이전트 앞단에 얇은 컨텍스트 계층을 하나 더 둬라. 긴 프롬프트를 더 쓰는 것보다, 컨텍스트를 어떻게 보낼지 먼저 만지는 편이 체감 차이가 크다. 특히 여러 디렉터리를 오가는 저장소, 공통 설정 파일이 많은 백엔드, 테스트와 구현 파일이 멀리 떨어진 코드베이스에서는 이런 방식이 더 잘 맞는다.

여기서 내가 구분하고 싶은 건 검색과 포장이다. 벡터 검색이나 grep은 필요한 파일을 찾는 데 강하지만, 찾은 뒤에 그 파일들을 어떤 해상도로 창 안에 넣을지는 또 다른 문제다. 오늘 Entroly를 보면서 흥미로웠던 지점도 바로 그 층위였다. "무엇을 찾을까"보다 "찾은 걸 어떤 비율로 보여 줄까"에 더 가까운 도구라는 점이다. 에이전트가 이미 관련 파일을 어느 정도 알고 있는데도 답이 자꾸 흐리다면, 검색 로직보다 포장 로직을 먼저 손보는 쪽이 더 잘 맞을 수 있다.

3. 붙이기 전에 baseline부터 남기기

이런 도구를 볼 때 내가 꼭 먼저 하는 건 비교 기준을 한 번 남겨두는 일이다. 그냥 붙여 놓고 "왠지 좋아진 것 같다"로 끝내면 금방 흐려진다. 같은 저장소, 같은 작업 요청으로 한 번은 기존 방식대로 보내고, 한 번은 압축 프록시를 낀 뒤에 아래 항목만 짧게 적어 두면 체감이 훨씬 명확해진다.

• 토큰 수: 첫 응답까지 얼마나 먹는지
• 지연: 첫 응답이 나오기까지 얼마나 걸리는지
• 의존성 정확도: import, 설정 경로, 테스트 파일 연결이 맞는지
• 재설명 횟수: 내가 추가로 파일을 몇 번 더 붙여 넣었는지

이 네 개를 같이 보면 비용 절감이 진짜 생산성 개선으로 이어지는지 바로 드러난다. 토큰만 줄고 재설명 횟수가 그대로면 생각보다 얻는 게 적고, 반대로 응답이 조금 느려져도 import 실수가 확 줄었다면 충분히 붙일 가치가 있다. 나는 앞으로 이런 프록시를 볼 때 광고 문구보다 재설명 횟수가 실제로 줄었는지를 더 먼저 볼 것 같다.

4. 아무 데나 붙이지 말고, 이럴 때만 먼저 본다

물론 모든 작업에 이런 계층이 필요한 건 아니다. 작은 스크립트 하나 고치거나 파일 두세 개만 보는 버그 수정이라면, 그냥 직접 파일 읽기와 검색으로도 충분하다. 내가 이런 도구를 먼저 떠올리는 건 보통 아래 같은 순간이다.

• 매 턴 비슷한 파일을 계속 붙여 넣고 있을 때
• 답변이 자꾸 맞는 척하지만 import나 의존성이 어긋날 때
• Claude Code, Cursor, Codex에서 컨텍스트 비용과 지연이 눈에 띄기 시작했을 때
• 저장소가 커서 "관련 파일이 더 있을 텐데" 감각이 강할 때

반대로 기준이 하나 더 있다. 프록시를 붙였는데도 내가 검증 습관을 안 바꾸면 효과가 금방 반감된다. 압축해서 보여 준다고 해서 모델이 자동으로 더 신중해지는 건 아니다. 그래서 나는 이런 도구를 붙일수록 오히려 출력 검증을 더 짧게, 더 자주 하는 편이 낫다고 본다. 예를 들면 수정 뒤에 테스트 경로와 import 경로를 먼저 확인하고, 변경 설명에도 "어떤 주변 파일을 같이 참고했는지"를 짧게 남기게 하는 식이다.

5. 오늘 내 운영 규칙으로 남긴 한 줄

앞으로 코딩 에이전트가 자꾸 파일을 더 달라고 하거나, 내가 같은 저장소 설명을 세 번째 반복하고 있으면 먼저 이 질문을 던질 것 같다. 지금 필요한 건 더 긴 프롬프트인가, 아니면 더 나은 컨텍스트 포장인가. 오늘 Entroly를 보면서 무릎 친 건 바로 그 지점이었다. 바이브코딩이 무너질 때 원인이 모델보다 컨텍스트 포장 방식에 있는 경우가 꽤 많다.

그래서 오늘 팁은 도구 추천이라기보다 순서 추천에 가깝다. 코드베이스를 통째로 붙이기 전에, 압축 프록시를 먼저 의심해 보기. 그 한 단계만 추가해도 비용, 속도, 의존성 누락 문제를 훨씬 덜 거칠게 다룰 수 있다. 오늘 기준으로는 이 도구 자체보다도, 에이전트 앞단에서 컨텍스트를 압축하는 발상이 더 오래 남을 것 같다.