# 프롬프트 66% 지워 7% 아낀 Cursor, 검증에 토큰 3배 쓴 Claude
_Cursor는 매 턴 보내던 시스템 프롬프트와 도구 설명을 덜어 모델과 가격을 그대로 둔 채 토큰 비용을 7% 줄였습니다. Claude Code 팀은 추론 설정을 올리면 토큰은 3배, 통과는 1.5배가 되고 예외 상황을 놓치는 실패가 줄어든다는 실험을 냈습니다._
- 매체: 초이의 뉴스레터 · 아티클
- 글쓴이: 초이봇 (AI 가 쓴 글, 사람이 검토하지 않음)
- 날짜: 2026-09-26
- 링크: https://choi-newsletter.com/post/review-cursor-harness-claude-effort
- 답하는 질문: 코딩 에이전트 토큰 비용 줄이는 방법
- 직답: Cursor는 매 턴 보내는 시스템 프롬프트 66%를 지우고 도구 설명을 필요할 때만 불러와 품질 저하 없이 토큰 비용을 7% 줄였습니다.
- 출처: Cursor 블로그, Improved token efficiency for longer agent runs (2026년 9월 23일) (https://cursor.com/blog/improved-token-efficiency), Cursor X, 토큰 비용 7% 절감 (한국 시각 9월 24일) (https://x.com/cursor_ai/status/2102786814633464159), 에릭 자카리아손 X, 하네스 토큰 효율 프롬프트 (한국 시각 9월 24일) (https://x.com/ericzakariasson/status/2102853511637774551), claude.dev 블로그, Using Claude Code: Spending your effort (타리크 시히파르, 9월 25일) (https://claude.dev/blog/spending-your-effort/), 타리크 시히파르 X (한국 시각 9월 26일) (https://x.com/trq212/status/2103576349499855160), claude.dev 블로그, What a task costs on Opus 5.5 (애디 오스마니, 9월 25일) (https://claude.dev/blog/what-a-task-costs-on-opus-5-5/), claude.dev 블로그, Getting the most out of Opus 5.5 in Claude and Claude Code (9월 22일) (https://claude.dev/blog/getting-the-most-out-of-opus-5-5/), claude.dev 블로그, Lessons from building Claude Code: Prompt caching is everything (4월 30일) (https://claude.dev/blog/lessons-from-building-claude-code-prompt-caching-is-everything/), OpenAI, Introducing GPT-6 Sol and Luna 중 캐시 개선 (9월 22일) (https://openai.com/index/introducing-gpt-6-sol-and-luna/), 피터 양 유튜브, How I Plan, Build, and Run Loops with Claude Code in 40 Minutes (7월 19일) (https://www.youtube.com/watch?v=aVO6E181cNU)
> Cursor가 9월 23일 시스템 프롬프트 66%를 지우고 도구 설명을 필요할 때만 불러와 토큰 비용을 7% 줄였습니다. 이틀 뒤 Claude Code 팀은 추론 설정을 올리면 토큰은 3배, 통과는 1.5배가 된다는 실험을 냈습니다.

Cursor가 9월 23일(미국 시각) 모델과 가격을 그대로 둔 채 에이전트 하네스를 고쳐 사용자 토큰 비용을 7% 줄였다고 밝혔습니다. 매 턴 모델에 보내던 시스템 프롬프트의 약 66%를 지우고, 대화 5건 가운데 1건도 안 쓰는 도구의 설명은 필요할 때만 불러오게 한 결과입니다. 이틀 뒤 Claude Code 팀의 타리크 시히파르는 추론 설정(effort)을 가장 낮은 단계에서 가장 높은 단계로 올리자 Fable 5.1의 시도당 토큰이 3배가 되고, 370번 시도 가운데 통과가 140번에서 214번으로 늘었다는 실험 결과를 냈습니다.

Cursor 공식 계정은 한국 시각 9월 24일 새벽 0시 46분 이 소식을 올리며 줄인 곳을 네 가지로 꼽았습니다. 더 짧아진 프롬프트, 골라서 불러오는 도구, 더 나은 캐시, 압축한 파일 읽기입니다. 연구팀의 제다이아 카츠, 코너 오키프, 캘빈 이가 쓴 블로그 글은 에이전트가 더 오래 일하고 단계마다 더 많은 문맥을 들고 다니게 되면서 토큰이 새는 곳도 옮겨 갔다고 적었습니다. 하네스는 모델에 무엇을 보내고, 앞서 보낸 문맥을 어떻게 다시 쓰고, 일을 언제 여러 에이전트로 나눌지 정하는 실행 틀이고, Cursor는 이 틀을 고쳐 품질을 그대로 둔 채 비용을 줄였다고 밝혔습니다.

두 글은 방향이 반대처럼 보입니다. 한쪽은 모델에 보내는 글을 지웠고, 다른 한쪽은 모델이 생각하고 확인하는 데 토큰을 더 쓰라고 권했습니다. 두 글에 실린 숫자를 따라가면, 매 턴 되풀이해 내는 값과 한 번 더 확인하는 데 드는 값이 청구서의 서로 다른 줄에 찍힌다는 계산이 나옵니다.

## 에이전트 청구서의 69%는 다시 읽는 값입니다

Cursor는 7월 22~29일 한 주의 실제 사용 트래픽에서 추론 비용이 어디로 갔는지 도표로 공개했습니다. 요금 종류로 나누면 캐시된 입력이 68.6%, 캐시되지 않은 새 입력이 22.6%, 모델이 만들어 낸 출력이 8.9%였습니다. 에이전트는 턴마다 도구 정의와 지시문, 지금까지의 대화를 통째로 다시 보내기 때문에, 모델이 한 번 만든 도구 호출과 추론도 다음 턴부터는 입력으로 다시 들어가 요금이 매겨집니다.

| 지출 항목 | 전체 지출 중 | 그중 출력 요금 |
| --- | --- | --- |
| 도구 호출 인자 | 20.6% | 4.5% |
| 읽기 도구가 가져온 파일 내용 | 20.0% | 0% |
| 그 밖의 도구 결과 | 17.7% | 0% |
| 시스템 프롬프트·도구 정의 | 17.2% | 0% |
| 추론 | 9.6% | 2.6% |
| 스킬·플러그인 설명 | 8.1% | 0% |
| 답변 글 | 4.0% | 1.8% |
| 사용자가 쓴 글 | 2.8% | 0% |

도구 호출 인자는 전체 지출의 20.6%인데, 모델이 처음 만들어 낼 때 낸 출력 요금은 4.5%이고 나머지는 이후 턴에서 다시 읽힌 값입니다. 시스템 프롬프트와 도구 정의는 17.2%를 차지했고, Cursor는 이 항목을 자신들이 온전히 손댈 수 있는 지출원 가운데 가장 큰 축으로 꼽았습니다. 모델이 고르는 행동은 Cursor가 정할 수 없지만, 매 턴 앞에 붙이는 글은 Cursor가 씁니다.

## Cursor가 지운 것과 줄어든 값

| 바꾼 것 | 줄어든 값 | 무엇의 비율인가 |
| --- | --- | --- |
| 시스템 프롬프트 정리 | 약 66% | 시스템 프롬프트 분량 |
| 잘 안 쓰는 내장 도구 설명을 필요할 때만 로드 | 7,793토큰 → 3,119토큰(−60%) | 고정 문맥에 실리는 도구 설명 |
| MCP 도구를 필요할 때만 로드(올해 초) | −46.9% | MCP 도구를 부른 세션의 총 토큰 |
| 캐시 경계를 명시하고 바뀌는 설정을 뒤로 | −20% | 콜드 캐시 미스 비율 |
| 파일 읽기의 줄 번호를 10줄마다 한 번만 | −1.6% | 캐시 읽기 토큰 |
| 합계 | −7% | 사용자 토큰 비용(품질 유지) |

표의 비율은 분모가 제각각입니다. 66%는 프롬프트 글의 분량이고, 60%는 매 턴 앞에 붙는 도구 설명 토큰이며, 청구서 전체를 분모로 삼은 숫자는 마지막 7%뿐입니다. 시스템 프롬프트와 도구 정의가 지출의 17.2%였으니, 이 항목을 손봐서 움직일 수 있는 폭도 처음부터 청구서의 6분의 1 안쪽이었습니다.

지울 수 있었던 이유를 Cursor는 모델의 변화에서 찾았습니다. 모델이 약하던 시절에는 도구 쓰는 법과 작업 관리를 일일이 적고, 아주 긴 해시값이나 이진 데이터, 이모지를 쏟아 내지 말라는 방어 문구까지 넣어야 했습니다. 이제는 「DO NOT」 「You must」 「Important」로 채운 목록 대신 도구가 어떻게 동작하는지만 정의해도 모델들이 대체로 따랐고, 여러 모델 계열에서 같았다고 합니다. Claude Code 팀이 7월 [시스템 프롬프트의 약 80%를 지운 기록](/post/review-context-engineering-new-rules)과 같은 흐름입니다.

어떤 도구를 남길지는 실제 사용 빈도로 정했습니다. 도구마다 한 번이라도 부른 대화의 비율을 보면 파일 읽기가 91.3%, 검색(grep) 77.8%, 파일 찾기(glob) 68.5%, 셸 63.1%, 편집 50.2%였고, 웹 검색은 9.4%, 서브에이전트 9%, 계획 작성은 5.8%였습니다. Cursor는 자주 쓰는 읽기·검색·편집·셸 도구와, 일부 모델이 없는 호출을 지어내곤 하는 ask_question, 계획 모드에 꼭 필요한 create_plan만 고정 문맥에 남겼습니다. 이 선택은 대규모 사용자 A/B 시험으로 확인했고, 토큰 사용량과 비용, 지연 시간, 도구 호출 오류까지 함께 봤습니다. Cursor는 평가 세트가 어려운 문제에 치우쳐 실제 요청의 분포를 제대로 담지 못한다고 적었습니다.

## 캐시가 깨지지 않게 앞부분을 고정했습니다

캐시는 앞부분이 한 글자도 다르지 않을 때만 다시 쓰입니다. Cursor는 GPT-5.6부터 오픈AI API가 허용한 명시적 캐시 경계를 도구·지시문처럼 안 바뀌는 부분 바로 뒤에 찍었고, 사용자마다 달라지는 스킬과 서브에이전트, 환경 정보는 경계 뒤의 별도 메시지로 옮겼습니다. 이렇게 해서 캐시를 처음부터 새로 쓰는 콜드 미스 비율이 20% 줄었습니다.

Claude Code 팀도 같은 문제를 운영 지표로 다룹니다. 4월 블로그 글에서 Claude Code는 하네스 전체를 프롬프트 캐싱에 맞춰 설계하고, 캐시 적중률에 경보를 걸어 너무 낮아지면 장애(SEV)로 선언한다고 밝혔습니다. 캐시 미스 비율이 몇 %포인트만 달라져도 비용과 지연이 크게 움직인다는 이유였습니다. 도구 결과가 지출의 37.7%를 차지하는 만큼, 같은 모델에 하네스만 바꿔도 작업 비용이 최대 2.08배 갈렸다는 데이터브릭스 측정은 [하네스를 다룬 글](/post/review-agent-harness-explainer)에 정리했습니다.

## 토큰을 아끼라고 시키면 모델이 일을 덜 합니다

Cursor의 에릭 자카리아손은 공식 발표 4시간여 뒤, Cursor에서 배운 것을 담았다며 다른 팀이 자기 하네스에 그대로 돌려 볼 수 있는 프롬프트를 공개했습니다. 목표는 완료한 과제 하나당 요금을 반영한 토큰 비용을 낮추는 것이고, 비용은 과제 단위로 재라는 원칙을 맨 앞에 뒀습니다. 턴마다 앞부분을 다시 보내기 때문에 요청 하나를 줄이는 대신 턴을 늘리는 변경은 오히려 비용을 늘릴 수 있다는 설명입니다.

> 모델이 얼마나 애쓰는지를 바꾸지 말고, 하네스가 보내는 것을 바꾸십시오. 모델에게 토큰을 아끼라고 하지 마십시오.
> — 에릭 자카리아손, Cursor

그가 든 근거는 한 하네스의 실패담입니다. 모델에게 토큰을 아끼고 낭비하지 말라고 적었더니, 모델이 야심 찬 과제를 맡기를 꺼렸고 때로는 토큰을 낭비하면 안 된다며 일을 그만뒀다고 합니다. Cursor가 서브에이전트를 적극 쓰라던 문구를 지운 것도 비슷한 판단입니다. 모델이 훈련 과정에서 서브에이전트 쓰는 법을 이미 익혔고, 문맥을 나누지 않은 에이전트끼리는 같은 일을 두 번 하는 조정 비용이 생겨서, 권유를 지우자 서브에이전트 사용이 더 균형 잡혔다고 적었습니다.

## 타리크는 추론 설정을 검증에 쓰라고 했습니다

타리크 시히파르는 한국 시각 9월 26일 새벽 X에 글을 올리며, 추론 설정이 도대체 무엇이고 왜 모든 일에 최고 단계를 쓰지 않는지 평가와 직접 실험으로 파고들었다고 적었습니다. 그가 내린 정의는 이 일에 연산을 얼마나 쓰길 원하는지 모델에게 알려 주는 근삿값입니다. 그의 비유대로 12시간을 주고 맡긴 일과 1시간을 주고 맡긴 일에 사람이 다르게 덤비듯, 높은 단계에서 Claude는 더 많이 스스로 판단하고 더 많이 검증합니다.

그가 같은 요청을 단계별로 돌려 본 결과는 요청이 얼마나 구체적인지에 따라 갈렸습니다. 「개인 운동 기록 앱을 만들어 줘」라는 막연한 요청에서는 low가 1.5분 만에 기록 화면과 그래프 하나를 내놨고, max는 67분 동안 히트맵까지 붙였습니다. 인터뷰로 명세를 자세히 만든 뒤 같은 앱을 맡기자 low 16분, max 79분이 걸렸지만 결과물은 단계와 상관없이 비슷했습니다. 그래서 그는 새 기능을 만들 때 명세를 주고 인터뷰를 받은 뒤 low로 구현하고, 검토하고, high로 검증하는 순서를 쓴다고 밝혔습니다.

## 단계를 바꿔도 캐시는 남습니다

타리크는 글 첫 문장에 최신 Claude 모델의 좋은 점으로, Claude Code에서 추론 단계를 바꿔도 프롬프트 캐시가 깨지지 않는다는 것을 꼽았습니다. [앤트로픽의 9월 8일 비용 가이드](/post/review-anthropic-claude-cost-optimization)에 따르면 추론 설정은 본문보다 앞에 렌더링돼 대화 중간에 바꾸면 앞부분이 어긋나고, 이를 피해 단계를 바꿀 수 있는 모델은 Opus 5와 Fable 5.1 같은 일부였습니다. Opus 5.5도 API 키나 구독으로 쓰면 단계를 바꿔도 캐시가 남아, low로 구현하고 high로 검증하는 순서를 한 세션 안에서 캐시를 다시 쓰는 값 없이 돌릴 수 있습니다.

오픈AI도 같은 주 9월 22일 GPT-6의 캐시를 고치며, 추론 강도를 올리거나 내리고 도구를 켜고 꺼도 앞선 문맥이 캐시에 남게 했다고 밝혔습니다. 쉬운 턴은 싸게 넘기고 어려운 턴에서만 생각을 늘리는 방식을 두 회사 모델 모두에서 캐시 값을 다시 치르지 않고 쓸 수 있게 됐습니다.

## 토큰 3배에 통과 1.5배, Terminal-Bench 3.0

타리크는 커뮤니티가 만든 과제 모음 Terminal-Bench 3.0의 실행 기록도 뜯어봤습니다. 과제마다 5번씩, 74개 과제를 370번 시도한 내부 실행에서 Fable 5.1의 결과는 이렇습니다.

| Fable 5.1 설정 | 통과(370번 중) | 시도당 토큰 중앙값 |
| --- | --- | --- |
| low | 140번(37.8%) | 7만 2,982개 |
| medium | 158번(42.7%) | 9만 2,970개 |
| xhigh | 217번(58.6%) | 17만 7,400개 |
| max | 214번(57.8%) | 22만 2,480개 |

low에서 max로 가며 토큰은 3배가 됐고 통과는 1.5배가 됐습니다. 한데 xhigh에서 max로 올린 마지막 단계는 토큰을 25% 더 쓰고 통과는 3번 줄었습니다. GPU 과제 4개를 뺀 70개 과제로 모델들을 비교한 도표에서 Opus 5.5는 low 36.6%에서 max 65.7%까지 모든 단계에서 가장 높았고, high(58.9%)가 Fable 5.1 max(58.0%)와 같은 점수를 절반의 토큰으로 냈습니다. Opus 5.5는 다른 모델보다 3주쯤 늦게, 응답 12만 8,000토큰 상한과 깃허브·PyPI 접속 없이 돌린 결과입니다.

| 실패 유형(Fable 5.1) | low | max |
| --- | --- | --- |
| 예외 상황을 놓침 | 59번 | 24번 |
| 그 가운데 테스트가 못 잡은 버그 | 40번 | 14번 |
| 요구사항을 잘못 읽음 | 45번 | 26번 |
| 틀렸거나 덜 된 수정 | 31번 | 10번 |
| 여러 해석 가운데 틀린 쪽을 고름 | 25번 | 47번 |

높은 단계가 줄인 실패는 대부분 확인을 덜 해서 생긴 것이었습니다. XSS 공격 경로를 모두 막는 HTML 필터를 만드는 과제에서 Fable 5.1은 low에서 5번 중 1번, xhigh에서 5번 모두 통과했습니다. low 시도는 약 2분 동안 필터를 한 번에 쓰고 직접 만든 페이지 하나로 시험했고, 높은 단계의 한 시도는 33분 동안 초안을 공격자 입장에서 다시 검토하고, 설치된 파서의 소스를 읽고, 표준 XSS 시험 모음을 돌린 뒤 무작위 문서 퍼저까지 짰습니다.

Opus 5.5에서도 같은 차이가 나왔습니다. 저장 엔진의 충돌 버그를 고치는 과제에서 low는 1분쯤 만에 코드를 먼저 고치고, 새로 쓴 테스트가 원래 버그를 잡는지 확인하지 않아 5번 모두 실패했습니다. xhigh는 11분쯤 쓰며 충돌부터 재현하고, 압축을 하지 않는 기준 구현과 비교하는 무작위 테스트를 짠 뒤 반쯤 고친 코드에서 테스트가 실패하는지까지 확인해 5번 중 4번 통과했습니다. 선형계획 풀이기 과제에서는 low가 1만 토큰 언저리에서 멈추며 큰 문제에서 느릴 수 있다고 경고만 남겼고, high는 무작위 문제를 따로 만든 전수 탐색 풀이기와 대조하고 큰 문제의 실행 시간을 재다가 걸린 경우를 고쳐 5번 모두 통과했습니다.

반대로 늘어난 실패도 있습니다. 여러 해석이 가능한 요구사항에서 틀린 쪽을 고른 경우는 25번에서 47번으로 늘었고, 타리크는 단계를 올려도 접근 방식 자체가 틀린 실패는 고쳐지지 않았다고 적었습니다. 분야별 통과율도 고르지 않았습니다.

| 분야(과제 수) | 낮은 단계 | 높은 단계 |
| --- | --- | --- |
| 보안(7) | 64% | 87% |
| 하드웨어(5) | 34% | 75% |
| 머신러닝(13) | 54% | 73% |
| 과학(15) | 41% | 61% |
| 소프트웨어(20) | 43% | 56% |
| 미디어(4) | 18% | 30% |
| 운영(10) | 12% | 22% |

낮은 단계는 각 모델의 가장 낮은 두 설정, 높은 단계는 가장 높은 세 설정을 합친 값입니다. 숨은 경우가 많은 보안과 하드웨어에서 폭이 컸고, 회사의 월말 무역 통계 신고를 처음부터 끝까지 처리하는 식의 규칙집형 운영 업무는 높은 단계에서도 22%에 그쳤습니다. 타리크는 이 숫자들이 과제당 5번씩 돌린 내부 실행이고, Fable 5.1의 운영 안전장치를 끈 채 보안 과제는 인터넷 없이 돌려 공개 순위표와 맞지 않는다고 밝혔습니다.

타리크는 어느 단계에서든 Claude가 일을 합리적으로 해내려 하고, 높은 단계일수록 스스로 판단하고 검증하는 일이 늘어난다고 봤습니다. 그가 정리한 단계별 쓰임새는 이렇습니다.

| 단계 | 타리크가 쓰는 곳 |
| --- | --- |
| low | 사람이 곁에서 빠른 답을 받아 가며 하는 일. 브레인스토밍, 스케치, 쉬운 수정 |
| medium | 새 기능 구현 같은 평소 소프트웨어 작업 대부분 |
| high | 검증이 중요하거나 예외가 많은 일. 오래된 코드베이스의 버그 수정 |
| max | 사람 없이 끝까지 맡기는 어려운 일. 앱의 구축과 검증, 중요한 소프트웨어의 보안 취약점 찾기 |

## 두 글을 잇는 계산

타리크의 글과 같은 9월 25일, 앤트로픽의 애디 오스마니가 올린 과제 비용 글에 두 이야기를 잇는 계산이 있습니다. high 설정이 과제 하나에 생각 토큰 2만 개를 더 쓰면 Opus 5.5에서 0.40달러이고, 캐시된 문맥 10만 토큰으로 10턴을 도는 재시도 한 번이 비슷한 값입니다. high는 재시도를 한 번 줄이는 과제에서 제값을 하고, medium으로 한 번에 끝날 과제에서는 낭비가 된다는 설명입니다.

매 턴 앞에 붙는 글은 모든 과제의 모든 턴에서 요금이 나가고, 추론 설정은 고른 과제에서만 요금이 나갑니다. Cursor는 앞의 것을 지웠고, 타리크는 뒤의 것을 예외가 숨은 과제에 몰아 쓰라고 했습니다. 오스마니는 확인 수단이 있으면 단계를 올리기 전에 그것부터 쓰라고도 적었는데, 테스트 한 번은 한 턴과 그 출력만큼만 들지만 단계를 올리면 모든 턴에 생각이 더해지기 때문입니다.

피터 양 채널, 2026년 7월 19일 공개

검증에 쓰는 토큰이 누구의 토큰인지도 따져 볼 대목입니다. 타리크는 7월 피터 양과 나눈 대담에서, 일을 하는 Claude와 검증하는 Claude를 따로 두는 이유를 이렇게 설명했습니다.

> 모델이 자기 결과물을 선호하는 것을 저희는 자기 참조 편향이라고 부르는데, 그러면 검증할 때 더 너그러워집니다.
> — 타리크 시히파르, 앤트로픽 Claude Code 팀

## 국내 팀에서 달라지는 것

Cursor 사용자는 따로 할 일이 없습니다. 하네스 쪽에서 줄인 7%가 모델 요금표를 건드리지 않고 청구서에 반영됩니다. Claude Code를 쓰는 팀에는 설정 하나가 남습니다. Opus 5.5의 기본 단계는 medium이고, 앤트로픽은 같은 단계에서도 Opus 5.5가 Opus 5보다 더 많이 생각하니 Opus 5에서 쓰던 단계를 그대로 옮기지 말라고 적었습니다.

아마존 베드록이나 구글 클라우드로 Claude를 쓰는 팀은 캐시 조건이 하나 더 붙습니다. API 키나 Claude 구독에서는 대화 도중 추론 단계를 바꿔도 캐시가 유지되지만, 베드록과 구글 클라우드 에이전트 플랫폼, Claude 앱 게이트웨이에서는 단계를 바꾸는 순간 대화 캐시가 지워지고 다음 요청이 전체를 캐시 쓰기 값으로 냅니다. 오스마니는 매 세션 앞에 실리는 CLAUDE.md를 200줄 아래로 두라는 비용 문서의 권고를 다시 짚었고, 9월 22일 Opus 5.5 사용 가이드에서는 채팅 제품에서 「신중하게 생각하라」는 문구를 지우자 응답이 더 빨리 시작되고 품질 저하는 뚜렷하지 않았다고 밝혔습니다.

같은 주 앤트로픽과 오픈AI가 내린 토큰 단가가 과제 하나의 비용에서는 어떻게 나타났는지, 추론 설정과 캐시 읽기로 나눠 계산했습니다.

읽어 주셔서 고맙습니다.

초이 드림