12월 Cursor 사용 회고: 320달러의 교훈

들어 가며

지난 글에서 말했던 것처럼 나도 Cursor를 적극적으로 사용하기 시작했다.

그런데 12월 한 달간의 사용량 데이터를 보고 솔직히 놀랐다. 320달러. 많은 금액인가, 적은 금액인가? 각자의 상황에 따라 다를 것이다. 이 글의 초점은, 금액의 크기가 아니다.

중요한 것은, 무의식적으로 사용했다는 것이다. 데이터를 분석해보니 최적화 여지가 보였다. 이 글은 그 발견과 개선을 향한 첫걸음이다.

원본 데이터 공개: Google Drive - 2025-12 폴더에서 사용량 데이터 CSV 원본과 NotebookLM 분석 보고서를 확인할 수 있다. 단, NotebookLM의 집계 방식이 실제 CSV 데이터와 다소 차이가 있을 수 있다.

사용량 분석

데이터 수집

Cursor 대시보드에서 12월 사용량 데이터를 CSV로 추출했다. 2025년 12월 5일부터 31일까지, 약 27일간의 데이터다.

주요 지표는 다음과 같다.

항목	값
총 요청 건수	886건
총 사용 토큰	약 2억 8천만 개
총 발생 비용	$320

처음 이 수치를 보고 당황했다. 월 40달러 팀 플랜인데, 320달러라니. 곰곰이 생각해 보니, 이건 내가 AI를 제대로 활용한 결과가 아니라, 마구잡이로 활용한 결과였다.

NotebookLM 분석

데이터 분석을 위해 NotebookLM을 활용했다. 사용 패턴에 대한 분석을 요청했다.

모델별 사용 패턴

CSV 데이터를 집계한 모델별 사용 패턴은 다음과 같다.

모델명	총 요청 건수	총 사용 토큰	총비용 ($)	전체 비용 대비 비중 (%)
claude-4.5-opus-high-thinking	473	약 1.5억	$190	59.45%
claude-4.5-sonnet-thinking	379	약 1억	$124	38.76%
agent_review	9	약 1,900만	$3.79	1.18%
auto	25	약 440만	$1.94	0.61%

claude-4.5-opus-high-thinking 모델이 전체 요청 건수의 약 55%를 차지했고, 총비용에서는 약 60%라는 압도적인 비중을 차지했다. 단일 고비용 모델에 대한 의존도가 너무 높았다.

일별 사용 패턴

비용이 가장 높았던 상위 3개 날짜는 다음과 같다.

1. 12월 9일: $46.48
2. 12월 4일: $41.96
3. 12월 11일: $38.45

이 3일간 발생한 비용은 총 $126.89로, 전체 기간 비용의 약 40%를 차지한다. 단 3일간의 활동이 월 전체 비용의 2/5를 결정한 셈이다.

캐시 활용 패턴

흥미로운 점은 캐시 활용률이 매우 높았다는 것이다. NotebookLM 분석 결과다:

12월 9일 기록을 보면 약 497만 토큰을 사용하는 데 5.03달러가 발생했는데, 이 중 97.5% 이상인 485만 토큰이 ‘Cache Read’였습니다.

처음에는 이게 좋은 건가 싶었다. 캐시를 잘 활용하고 있다는 뜻 아닌가? NotebookLM도 이렇게 평가했다.

이 사용자는 방대한 데이터를 캐싱해 두고 Claude 4.5 시리즈의 추론(Thinking) 능력을 극대화하여 사용하는 ‘전문적인 헤비 유저’의 전형적인 패턴을 보여줍니다.

그런데, 뭔가 이상했다. 회사에서 이미 Cursor를 잘 쓰고 있던 다른 분들로부터 컨텍스트 비우고 새 채팅 창을 열어라라는 말을 많이 들었는데, 나는 그렇게 하지 않았다. 캐시 활용률이 높다는 건, 채팅 창을 많이 안 닫았다는 뜻 아닌가?

Claude 분석

Claude에게도 동일한 데이터를 주고 분석을 요청했다. NotebookLM은 데이터 자체의 패턴을 분석했고, Claude는 일반적인 권장사항과 비교하며 개선점을 찾아줬다. 두 관점 모두 필요했다.

컨텍스트 축적 문제

심각한 컨텍스트 축적 발견:

• 평균 컨텍스트: 310,398 토큰 (일반적인 권장치의 3-5배)
• 95% 요청이 137만 토큰 이상 컨텍스트
• 최대 494만 토큰 - 이건 소설책 여러 권 분량입니다
• 새 대화 시작은 단 1.9% (17개)만!

아, 이거였구나. 캐시 활용률이 높은 게 좋은 게 아니라, 컨텍스트를 너무 많이 쌓아뒀다는 의미였다.

컨텍스트 축적의 문제점

Claude가 지적한 문제점은 다음과 같다.

1. 응답 품질 저하: AI가 너무 많은 정보를 처리하느라 정작 중요한 부분에 집중 못함. 관련 없는 과거 대화가 현재 응답에 영향을 줌.
2. 속도 저하: 캐시에서 읽더라도 494만 토큰을 처리하는 건 느림. 첫 응답까지 기다리는 시간이 길어짐.
3. 비용 비효율: 캐시 덕분에 절감했지만, 이건 “운 좋게 절감”한 것. 적절한 컨텍스트 관리했다면 애초에 이렇게 큰 비용이 안 나왔을 것.

Claude의 추정에 따르면, 컨텍스트 관리만 했어도 320달러가 102달러로 줄어들 수 있었을 것(약 68% 절감)이라고 한다.

분석에 대한 감상

두 AI의 분석 결과와 내 실제 작업 패턴을 비교해 보니, 어느 정도 맞는 말이었다.

배치형 작업 패턴

12월에는 주로 백엔드 리팩토링 작업을 진행했다. 처음 구조 잡고 계획 세울 때 집중적으로 사용했다가, 어느 정도 내가 파악하는 단계에서는 내가 구현하다가, 반복 패턴이 나오면 다시 집중적으로 사용하는 패턴이었다. NotebookLM이 말한 “배치형 작업” 패턴이 맞았다.

모델 선택 전략

NotebookLM이 분석한 것처럼, 모델 선택도 어느 정도 의도적이었다. 리팩토링 구조, 로직 대규모 변경, 새로운 패턴 도입, 스키마 변경 등에는 Opus를 사용하고, 이후에는 주로 Sonnet을 사용했다.

초기나 핵심 분석 단계에서는 가장 강력한 Opus를 사용하고, 반복적이거나 양이 많은 실행 단계에서는 효율적인 Sonnet을 주력으로 활용하는 전략적인 모습을 보이고 있습니다.

Opus를 많이 쓴 이유가 있다. 평소에 못 써보다가, Teams 플랜에 포함되어 있어서 써봤는데 너무 좋았다. 고성능 모델이라고 하던데, 실제로 사용해 보니까 리팩토링 계획 수립, 스키마 변경 계획 수립 등 실제로 내가 설계 단계에서 시간을 많이 쏟는 분야에 만족스러운 답변을 내놓았다.

Sonnet을 쓸 때는 뭔가 틀리게 말하는 경우도 종종 있었다. 예를 들면, 코드 버그 로직을 찾을 때 실제로 파일을 열어서 확인해 보면 Sonnet이 “아, 맞습니다! 죄송합니다.”라고 하는 경우가 있었다.

개인적인 소회지만, 이것도 참 인간이 간사한 것 같다 싶었다. GPT 쓰다가 Claude 쓰면서는 신세계고 너무 좋았다. AI와 대화로 지적 충만감을 느낄 수 있다는 게 놀라웠다. 그런데 그 때의 나는 Sonnet을 사용했었으니.

컨텍스트 관리, 무엇이 문제였나

회사 동료들이 조언했다. 컨텍스트 비우고 새 채팅 창 열어라. 무시한 것은 아니다. 다만, 리팩토링 특성상 비즈니스 로직 맥락이 필요했고, 그 맥락을 매번 설명하기가 부담스러웠을 뿐이다.

하지만 데이터는 거짓말하지 않는다. 평균 31만 토큰, 최대 494만 토큰. 일반 책 한 권이 약 12만 토큰이니, 심할 때 나는 AI에게 50권 분량을 읽힌 셈이다.

문제는 ‘필요성’이 아니라 ‘정도’인 것이었다. 리팩토링에 맥락이 필요한 건 맞지만, 50권은 과하다. 5-10권 정도면 충분했을 작업에 불필요한 컨텍스트가 계속 누적됐다.

두 가지를 배웠다:

1. 간단한 기능 개발의 경우, 웬만하면 새 채팅창을 열자
2. 복잡한 리팩토링과 같은 경우, 컨텍스트 유지하되 20만 토큰을 상한선으로 두자

비용 구조 이해

분석을 하다 보니, Cursor의 비용 구조에 대해 더 알아야 할 필요성을 느꼈다.

Teams 플랜 가격 정책

Cursor Teams Plan 가격 정책은 다음과 같다.

• 전체 40달러/월
• Included 20달러 상당의 사용량 포함
• On-Demand 20달러 상당 추가 사용 가능
• Included 20달러 넘어도 On-Demand로 계속 사용 가능

On-Demand vs. Included

NotebookLM 분석에서 흥미로운 점을 발견했다. 동일하거나 유사한 모델을 사용하더라도 결제 방식에 따라 청구되는 비용의 단위가 다르다.

구분	On-Demand	Included
비용 효율	상대적으로 낮음 (200만 토큰 ≒ $2.57)	매우 높음 (346만 토큰 ≒ $2.57)
캐시 처리	캐시 비중이 높으나 비용 발생	캐시 비용이 극도로 저렴

Included 방식이 On-Demand에 비해 압도적인 비용 효율성을 보였다. 특히 대규모 캐시 처리에서 큰 차이가 난다.

이걸 보니, 비용이 많이 나올 것이라 예상되는 작업은 최대한 Included 사용량이 적용될 때 진행하는 게 좋겠다는 생각이 들었다. 예컨대, 리팩토링 계획 수립, 대규모 코드 구조 변경, 새로운 패턴 도입, 스키마 설계처럼 복잡한 추론이 필요하고 컨텍스트를 많이 쌓아야 하는 작업들.

다만, 이게 마음처럼 조절이 될까 싶은 건 사실이다. 무거운 작업은 월초에 하고, 반복 패턴 작업은 월말에 하고, 이런 식으로 내가 원하는 대로 업무를 컨트롤할 수 있는 게 아니니까. 일정은 일정대로 돌아가고, 작업은 작업대로 치고 들어온다. 나에게 맞는 적정 패턴을 찾아가는 게 숙제다.

액션 아이템

생산성에 대한 회고인 만큼, 다음 달의 액션 아이템을 정해 보자.

1월 실험 계획

Week 1-2: 측정

• 매일 사용 후 컨텍스트 토큰 수 기록
• 어떤 작업에서 토큰이 급증하는지 파악

Week 3-4: 최적화

• 10만 토큰 초과 시 새 대화 시작
• 단순 작업은 Sonnet 우선
• 목표: 비용 20% 절감 ($160 이하)

실패 대비책

• 컨텍스트 재주입이 비효율적이라면? → 20만 토큰까지 허용
• Sonnet 품질이 떨어진다면? → 품질 vs 비용 재평가

정립해 나갈 원칙들

스스로에게 맞는 사용 원칙을 정립해 나가자. 다만, 이 원칙들은 앞으로의 실험 결과에 따라 수정될 예정이다.

모델 선택 가이드라인

어떤 경우에 어떤 모델을 써야 할지에 대한 명확한 가이드라인을 세워야 한다.

작업 유형	권장 모델	이유
리팩토링 계획 수립, 스키마 변경	Opus	복잡한 추론 필요
아키텍처 설계, 구조 논의	Opus	깊은 사고 필요
코드 포맷팅, 간단한 함수 작성	Sonnet	비용 효율적
코드 설명, 에러 해석	Sonnet	비용 효율적
반복적인 CRUD 구현	Sonnet	패턴이 정해져 있음

이를 위해, Claude 계열 모델 외에, 다른 모델도 써봐야 한다. Cursor 커뮤니티를 보니, 캐시 read에 대한 고민도 있고, 다른 모델이 낫다는 의견도 있다. 다양한 사용 사례를 참고해 보자.

컨텍스트 관리 원칙

아래와 같은 경우, 새 대화를 시작하는 것을 고려해 보자:

• 작업 주제가 바뀔 때
• 한 작업이 끝나고 다음 작업 시작할 때
• 컨텍스트가 10만 토큰 상한선을 넘어갈 때
• 느낌상 “이전 대화가 이제 관련 없다” 싶을 때
• 리팩토링, 설계 등 무거운 작업의 경우 예외 허용

Included 사용량 최적화

비용이 많이 나올 것이라 예상되는 작업은 Included 사용량이 적용될 때 진행하자.

• 리팩토링 진행, 대규모 코드 구조 변경 등
• 새로운 패턴 도입
• 스키마 설계

결론

320달러라는 숫자는 충격적이었지만, 이번 분석을 통해 많은 걸 배웠다.

얻은 것

1. 비용 구조 이해: On-Demand vs. Included의 차이, 모델별 비용 차이를 알게 되었다.
2. 컨텍스트 관리의 중요성: 캐시 활용률이 높은 게 무조건 좋은 게 아니라는 걸 깨달았다.
3. 의도적인 선택의 필요성: 마구잡이로 쓰지 말고, 작업의 성격에 따라 모델과 컨텍스트 관리 전략을 달리해야 한다.

앞으로

이번 회고를 시작으로, 주기적으로 사용량 데이터를 확인하고 회고를 진행할 예정이다. 스스로 만족할 만한 사용법을 정립해 낼 때까지.

320달러는 적지 않은 금액이다. 하지만 이 비용으로 대규모 리팩토링을 완료했고, 데이터 분석을 통해 최적화 여지를 발견했다. 진짜 회고는 나중에 나온다. 실험을 통해 실제로 비용이 줄어드는지, 품질은 유지되는지 검증할 것이다.