_(1).jpeg&blockId=0e552736-74f0-4f5a-89e1-328d4931ca7c)
배경
Pro 플러스 + 온디맨드 50달러가 1주일만에 소요됨
Cursor를 쓰다 보면 가끔 “나는 코드를 썼는데 왜 통장 잔고가 줄어들지?” 같은 기묘한 경험을 하게 된다. 나도 그랬다. Pro 플러스를 쓰고 있었고, 온디맨드(추가 과금) 한도를 50달러로 잡아둔 상태였다.
그런데 Include와 On-Demand가 일주일 만에 소진됐다.
Cursor 대시보드의 사용량을 보면, ‘내가 많이 물어봐서’가 아니라 ‘Cursor가 많이 읽어서’ 비용이 발생하는 케이스가 꽤 많았다. 그리고 내 케이스가 정확히 그쪽이었다.
토큰 사용량에서 cache read가 압도적으로 많다. 좋은 성능을 내려면 Context를 읽어야하기 때문에. 비싼 걸 많이 쓰긴 했다ㅋㅋ
대시보드를 확인하니 토큰 소비가 input/output이 아니라 cache read 쪽에 쏠려 있었다. 따라서 문제는 “질문을 줄이기”보다 “컨텍스트 유입을 줄이기”에 가깝다고 판단했다.
문제 상황 분석 - 금방 토큰을 쓰는 이유
cache read 폭증
Cursor에서 온디맨드 소비량을 보면, 내가 쓴 모델의 총 토큰이 꽤 크다.
•
Total: 30,152,960
•
Cache Read: 26,167,000
•
Cache Write: 3,761,041
•
Input: 1,710
•
Output: 223,209
숫자만 봐도 방향이 나온다.
•
input이 거의 없다. 즉 “내가 프롬프트를 길게 써서 폭발했다”가 아니다.
•
output도 상대적으로 작다. 즉 “모델이 장문 답변을 쏟아내서 폭발했다”도 아니다.
•
대부분이 cache read다. 즉 “Cursor가 컨텍스트를 읽는 과정에서 토큰이 크게 소모됐다”가 핵심이다.
즉,
토큰 절약은 ‘말 수를 줄이는 것’보다 ‘컨텍스트가 덜 들어오게 만드는 것’이 더 큰 레버리지다.
분석: Cursor는 어떤 컨텍스트를 참고하고 토큰을 소모하는가
Cursor의 컨텍스트는 “지금 내가 보고 있는 파일 한 개” 수준이 아니다. 두 개의 참고 글을 읽어보면, Cursor는 여러 레이어를 조합해 컨텍스트를 만든다고 이해하는 편이 현실과 맞는다.
여기서는 레이어 관점으로 설명한다. 이름은 도구/글마다 표현이 조금 다르지만, 핵심은 비슷하다.
1.
시스템 프롬프트
•
모델의 기본 행동을 규정하는 Cursor 자체의 지시문이 있다.
•
사용자는 잘 보지 못하지만, 매 요청에 영향을 준다.
2.
룰(프로젝트 규칙)
•
.cursor/rules 같은 규칙이 조건에 맞으면 컨텍스트로 붙는다.
•
규칙이 길거나, 매번 불필요하게 많이 매칭되면 그만큼 읽힐 가능성이 커진다.
3.
세션 히스토리(대화 누적)
•
같은 채팅에서 오래 대화하면 이전 발화들이 계속 맥락으로 남는다.
•
오래된 내용은 요약되기도 하지만, 요약도 결국 토큰이다.
•
즉 채팅을 길게 끌수록 AI가 쓰는 토큰이 쌓인다.
4.
동적 컨텍스트(열린 탭/활성 파일/최근 변경)
•
현재 열어둔 파일, 최근 수정한 코드, 편집기 상태 등이 포함될 수 있다.
•
열린 탭이 많으면 “모델이 참고해도 되는 후보군”이 커진다.
5.
코드베이스 검색(RAG/인덱싱 기반)
•
Cursor는 코드베이스를 검색해 관련 조각을 끌어오는 방식으로 맥락을 확장할 수 있다.
•
이 과정은 편리하지만, 잘못 작동하면 “내가 묻지도 않은 파일까지 친절하게” 읽어들일 수 있다.
•
특히 “버그 픽스”처럼 맥락이 필요한 작업에서 검색 범위가 넓어지면 컨텍스트가 눈덩이처럼 불어난다.
여기서 내 상황(캐시 리드 폭증)을 레이어로 매핑하면, 원인은 ‘정확히’ 특정할 수는 없어도 ‘가능성이 높은 범위’로 좁힐 수 있다. Cursor가 레이어별 토큰 기여도를 세밀하게 보여주지 않기 때문이다. 대신 관측 가능한 증상(캐시 리드 압도)과 작업 환경을 통해 가설을 세웠다.
가설 A. 열린 탭이 많아 동적 컨텍스트가 커졌다
•
탭을 많이 열어두면 모델이 참고할 후보가 늘어난다.
•
결과적으로 매 요청마다 읽는 컨텍스트가 커지고, cache read가 증가한다.
가설 B. 참고하는 파일 하나의 크기가 커서 무관 코드까지 함께 읽혔다
•
파일이 크면, 내가 필요한 로직만 있는 게 아니라 주변 맥락까지 같이 붙는다.
•
“이 함수만 고쳐줘”라고 했는데 파일 전체가 컨텍스트로 들어오면 토큰은 당연히 늘어난다.
가설 C. 긴 세션이 누적되어 히스토리 요약/대화 맥락이 계속 붙었다
•
같은 채팅에서 주제가 계속 변하면, 모델 입장에서는 “유지해야 할 컨텍스트”가 늘어난다.
•
나중에는 모델이 잘못 이해하고, 그걸 바로잡기 위해 재시도가 발생해 토큰이 더 늘어난다.
•
인간에게는 “대화 좀 길어졌네”인데, 토큰에게는 “장기 프로젝트 문서”가 된다.
정리하면, 내 케이스의 핵심은 “입력/출력보다 컨텍스트 읽기에서 태웠다”이고, 그 컨텍스트는 레이어 구조상 다음 요인들과 결합되어 커졌을 확률이 높다.
•
열린 탭이 많다.
•
파일이 크다.
•
세션이 길다.
•
인덱싱 기반 검색이 개입했을 가능성이 있다.
해결 방법 - 내가 시도했던 것들
컨텍스트가 커지면 cache read가 커지고, cache read가 커지면 비용이 커진다. 그러니 컨텍스트 유입 경로를 하나씩 막으면 된다. 문제는 막아놓으면 성능이 떨어져서 재시도하게 되고, 그러면 토큰이 다시 늘어난다는 점이다. 이래서 절약은 항상 조건부다.
아래는 내가 실제로 시도한 것들을 정리한 것이다.
1. 모델마다 비용 및 성능 비교 (GLM, Opus, Sonnet 4.5, Codex low/fast)
이전에는 “성능 좋은 모델을 기본값으로 쓰고, 지갑이 얇아지면 그때 바꿔야지”라고 생각했다. 초반에는 Opus가 체감 성능이 좋아서 계속 사용했고, 비용이 커지자 Sonnet으로 내려왔다. 이 방식은 심리적으로 편하지만, 토큰 예산이 있는 환경에서는 곧바로 한계가 온다.
그래서 작업 유형별로 모델을 나눠 썼다. 모델 자체의 단가도 중요하지만, 더 중요한 건 재시도율이다. 싸다고 해서 재시도가 두 배가 되면 결국 비싸진다.
•
GLM 4.7
◦
◦
실제: 성능이 너무 안 좋았고 출력도 느렸다. 그리고 VPN을 사용하는 곳에서는 네트워크 때문에 블라킹되서 http1.1을 쓸 수밖에 없었는데 (이후엔 해결됐다) 통신 속도가 너무 느려 생산성이 저하됐다. AI 엔지니어분들은 GLM만으로도 충분히 좋다고 했는데, 프론트에서는 참고해야할 컨텍스트가 많아서 분야별로 다른 것 같다.
◦
결과: 답이 마음에 안 들어 재시도가 늘어났다. 토큰과 시간 비용이 오히려 더 늘어났다.
•
Opus
◦
배경: 맥락 이해/추론이 강하니 버그 픽스에 좋다.
◦
실제: “한 번에 맞히는 확률”이 높았다.
◦
결과: 같은 문제를 여러 번 물어볼 일이 줄어드는 효과가 있었다. 다만 단가가 높아 무지성 상시 사용은 위험하다.
•
Sonnet 4.5
◦
배경: Opus보다 싸면서도 충분히 좋다.
◦
실제: 대부분의 생산성 작업에서 안정적이었다.
◦
결과: 일상적인 개발 작업(컴포넌트 작성, 간단한 리팩토링, 문서화)은 Sonnet이 가장 무난했다.
•
Codex low/fast
◦
이전 기대: 코드 생성은 빨리 뽑아내고 싶다.
◦
실제: 단순한 코드 스캐폴딩이나 반복 작업에는 좋았다.
◦
결과: 문제는 “코드베이스 이해”가 필요한 작업에서 성능이 떨어질 수 있다는 점이었다. 이 경우 재시도가 늘 수 있다.
결론적으로 모델 선택은 “가격표”가 아니라 “재시도율”로 판단해야 한다. 단가를 낮춰도 실패 확률이 올라가면 총 토큰은 오히려 증가한다.
2. 룰에 넣을 문서 마크다운 파일을 짧게 요약해서 참고시키기
이전 방식은 프로젝트 문서들을 룰에 그냥 넣거나, 긴 문서를 그대로 AI에게 읽히는 방식이었다. 길면 길수록 토큰이 늘어난다. 그리고 룰은 조건에 맞으면 자동으로 컨텍스트에 포함될 수 있다. 즉, 룰에 장문 문서가 붙어 있으면 “매 요청마다 장편소설을 들고 다니는” 셈이다.
개선된 방식은 문서를 짧은 요약본으로 만든 뒤, 그 요약본만 룰에서 참조하게 하는 것이다.
•
긴 문서: 프로젝트 개요, 용어집, 아키텍처 문서, 배포 규칙 등
•
이를 “1페이지 요약”으로 재작성한다.
•
룰에는 요약본만 포함되도록 한다.
다만 이런 점들이 좀 불편하긴 하다.
•
API Key를 사용하는 경우, Cursor 룰이 적용되지 않는 케이스가 있었다.
•
이때는 룰에 넣어도 자동으로 컨텍스트에 안 붙는다.
•
그래서 API Key를 쓰는 경우에는 요약본을 필요할 때마다 수동으로 @file 참조해서 붙이는 방식이 더 안정적이었다.
3. cursorignore 적용
Cursor가 기본적으로 gitignore에 있는 파일들을 무시하긴 한다. 하지만 public의 이미지/폰트/에셋은 gitignore에 들어있지 않다. 이 파일들이 인덱싱되고 검색 대상이 되면, 코드와 무관한 자산이 컨텍스트 후보군에 들어갈 수 있다.
그래서 다음을 제외했다.
•
public/images, public/fonts, public/assets
•
테스트 fixture 중 이미지/바이너리
•
changelog 등
이건 토큰 절약뿐 아니라, 검색 품질을 올리는 데도 도움이 됐다. 검색 대상이 줄면, AI가 가져오는 맥락도 더 정확해진다.
4. 사용하지 않는 탭 닫기
커서의 컨텍스트 사용 방식을 몰랐을 때는 편의를 위해 Tab을 다 켜두었는데, 알고나서는 프롬프트를 하기 전 필요한 탭만 열어두게 됐다.
5. 채팅을 컨텍스트 단위로 분리하기
Cursor는 Context가 90%까지 차지 않는 이상 세션을 요약하지 않고 계속해서 발화를 참고한다. 그렇기 때문에 작업 내용이 조금만 다르다, 혹은 AI가 작업 내용이 너무 길어진다 싶으면 바로 해당 세션을 요약한 후, 다른 탭을 열어 다른 모델로 재시도하는 방법을 썼다.
세션을 분리하면 컨텍스트가 안정되고, 모델이 쓸데없는 과거 맥락을 끌고 오지 않는다. 결과적으로 재시도도 줄었다.
6. 파일 쪼개기
파일이 크면 관련 없는 코드도 함께 읽힐 가능성이 커진다. 특히 “모듈 하나에 모든 유틸을 몰아 넣은 파일” 같은 경우, AI가 파일 하나를 다 읽어들일 수 있다.
따라서, 파일을 쪼개면 AI가 필요한 부분만 읽게 만들 수 있고, 컨텍스트도 줄어든다. 사람도 읽기 쉬워진다. 결국 유지보수 비용도 같이 절약된다.
7. file reference로 필요한 파일만 찍기
명시적으로 @file 참조를 사용하면 된다. 이전에도 이런 방식으로 했지만, indexing을 끄고 file 레퍼런스를 하면 필요한 부분만 명시할 수 있다. 단, 버그 픽스처럼 어느 부분에서 오류가 터지는지 알 수 없는 경우, indexing을 끄고 레퍼런싱을 해도 작업을 완료하기가 어려울 수 있다.
8. 회사 지원 요청 (설문조사 + 설득)
이전에는 내 돈으로 회사 일을 했지만, 회사 업무에만 AI를 쓰고 있는데, LLM 비용으로 월 10~20만 원이 나가기 시작하니 비용 부담이 커져서 결국 회사에게 지원 요청을 하게 됐다. 이미 지원해주고 있는 게 많아 큰 기대는 안했지만, 생산성과 결부해 설득을 하니 지원을 해주시기로 했다.
설득 과정
1.
개발자 대상 설문조사를 돌린다.
•
실제로 AI를 업무에 얼마나 쓰는지, 어떤 효과가 있는지 수치로 정리했다.
•
경영관리팀을 설득한다.
•
결과적으로 1인당 월 10만 원 수준의 지원을 받아냈다.
우리 회사 최고~ >.o
9. Cursor Settings에서 Index New Folders 해제
이전에는 Cursor 성능을 올리기 위해 인덱싱을 켜둔 채로 썼다. 코드베이스 검색이 잘 되니 편하지만 문제는 컨텍스트가 필요 없는 작업에서도 불필요하게 검색이 개입할 수 있다는 점이다.
•
코드베이스 검색(RAG) 개입을 줄인다.
•
불필요한 컨텍스트 확장을 막는다.
•
cache read를 줄인다.
하지만 이런 부분에서 문제가 발생했다.
•
컨텍스트가 필요한 작업에서는 성능이 눈에 띄게 떨어졌다.
•
코드베이스를 잘 모르니 답이 엉키고, 재시도가 늘어났다.
•
결국 토큰이 다시 증가하는 케이스가 생겼다.
그래서 최종적으로는 조건 하에 쓰는 게 낫다는 결론을 내렸다…
•
인덱싱 끄기: 컨텍스트가 필요 없는 작업에서만 사용한다.
◦
독립 컴포넌트 생성
◦
단발성 유틸 작성
◦
문서/정리
◦
작은 스크립트
•
인덱싱 켜기: 코드베이스 이해가 필요한 작업에서 사용한다.
◦
버그 픽스
◦
리팩토링
◦
테스트 보강
◦
기능 추가(기존 구조를 타야 하는 작업)
결론
•
토큰 절약은 “단가 낮추기”가 아니라 “컨텍스트 통제 + 재시도율 낮추기”다.
•
가장 확실한 절약은 개발 습관을 바꾸는 쪽(탭 정리, 채팅 분리, cursorignore, 파일 참조)에서 나온다.
•
인덱싱이나 모델 다운그레이드처럼 성능에 영향을 주는 조치는 작업 유형에 따라 독이 될 수 있다.
결론
토큰을 아끼는 방법은 많지만, 실제로 “돈이 덜 나가고, 개발도 덜 꼬이는” 방법은 생각보다 적다. 그리고 반대로 “싸게 쓰려다 더 많이 쓰는” 함정도 있다. 결국 토큰 절약의 핵심 KPI는 단 하나다.
•
총 토큰 = (요청 1회당 컨텍스트 크기) × (재시도 횟수)
컨텍스트를 줄여도, 재시도가 늘면 말짱 도루묵이다! 재시도를 줄여도, 컨텍스트가 계속 비대해지면 망한다. 둘 다 잡아야 한다.
좋았던 것
사용하지 않는 탭 닫기
이건 가장 즉시 효과가 나온다.
실무에서도 탭이 많으면 사람이 헷갈리는데, 모델도 마찬가지다. 차이는 사람은 헷갈리기만 하고, 모델은 헷갈린 김에 토큰도 태운다는 점이다.
•
효과: 컨텍스트 후보군 축소 → 불필요한 읽기 감소 → cache read 감소
채팅을 컨텍스트 단위로 분리
이건 체감 성능과 비용 둘 다에 영향을 줬다.
하나의 채팅에서 모든 작업을 처리하면 세션 히스토리가 누적되고, 서로 다른 주제가 섞여서 모델이 맥락을 이상하게 이어 붙인다.
•
효과: 히스토리 누적 감소 → 컨텍스트 안정화 → 재시도 감소
cursorignore
cursorignore는 “토큰 절약”이면서 동시에 “검색 품질 개선”이다.
public 폴더의 이미지/폰트/에셋 같은 “AI가 읽을 필요 없는 것들”은 그대로 노출되어 있을 수 있었다. 이런 것들이 인덱싱/검색 대상에 남으면, 컨텍스트 후보군이 커지고 노이즈가 늘어난다.
개선된 방식은 AI가 볼 이유가 없는 덩어리를 명시적으로 제외하는 것이다.
이걸 하면 “AI가 쓸데없는 곳을 뒤지는 비용”이 줄어든다. 특히 코드베이스 검색이 개입하는 상황에서 더 체감된다.
•
효과: 검색 노이즈 감소 → 불필요 컨텍스트 확장 감소
효과가 안 좋았던 것
Cursor Settings에서 Index New Folders 해제
컨텍스트가 거의 필요 없는 작업에서는 괜찮았으나, 버그 픽스나 기존 코드 구조를 타야 하는 기능 추가에서는 성능이 떨어졌다. 성능이 떨어지면 답이 빗나가고, 빗나가면 재시도하기 때문에 결과적으로는 컨텍스트를 다시 읽게 만들고, 토큰이 늘 수 있다.
즉, 인덱싱을 끄는 행위 자체는 cache read를 줄일 수 있는데, 그 대가로 “정답률 하락 → 재시도 증가”가 발생하면 총 토큰은 오히려 늘어난다.
그래서 아래와 같이 조건부로 시도하면 좋을 것 같다.
•
인덱싱 끄기: 컨텍스트 불필요 작업에서만 사용한다.
•
인덱싱 켜기: 코드베이스 이해가 필요한 작업에서는 유지한다.
모델을 무작정 싼 걸로 변경
“싼 모델이면 토큰도 싸겠지”라고 생각했는데 실무에서는 달랐다.
•
한 번에 맞히는가
•
수정 지시를 몇 번이나 주게 만드는가
•
코드베이스 맥락을 이해하는가
싼 모델은 단가가 낮을 수 있지만, 답이 어긋나면 재시도가 발생한다. 재시도는 단순히 output이 늘어나는 문제가 아니다. 컨텍스트를 다시 읽는다. 즉 cache read가 다시 찍힌다. 결국 총 토큰이 늘 수 있다.
GLM 4.7이 대표적이었다.
•
성능이 낮아 재시도가 늘어났다.
•
출력이 느려서 시간 비용도 늘어났다.
•
결과적으로 “토큰 절약”과 “생산성” 둘 다 되지 않았다.
그래서 모델 전략은 이렇게 가져갔다.
•
“싸고 빠른 모델”은 컨텍스트 의존도가 낮은 작업에만 쓴다.
•
“비싸지만 맞히는 모델”은 버그 픽스, 리팩토링 같은 고난이도 작업에 쓴다.
•
모델 선택의 기준을 단가가 아니라 재시도율로 둔다.
