2026년 8월 3일, Cursor는 X에서 이렇게 알렸습니다. 클라우드 에이전트가 토큰 효율이 20–30% 좋아졌고, computer use를 쓰는 런에서는 80% 더 효율적이라는 주장입니다. MCP·skills·computer use 처리가 개선됐다는 설명과 함께요.
핵심 한 줄: 퍼센트는 벤치마크가 아니라 제품 신호입니다. 진짜로 줄여야 할 것은 “매 턴에 MCP 스키마를 전부 넣는 습관”과 “데모 없이 긴 클라우드 런을 돌리는 습관”입니다.
왜 중요한가
클라우드 에이전트는 랩톱을 닫아도 돌아가고, 병렬로 여러 대를 띄울 수 있습니다. 그만큼 토큰 × 병렬도가 바로 비용이 됩니다. 팀에서 MCP를 잔뜩 붙이고, 스킬 문서를 길게 넣고, UI 검증까지 맡기기 시작하면 “한 번의 이슈 해결”이 예상보다 비싸집니다.
Cursor가 효율을 말했다는 건, 제품이 긴 위임(long delegation) 쪽으로 더 밀어붙이겠다는 신호이기도 합니다. 반대로 말하면, 효율이 좋아져도 잘못된 워크플로면 절감분이 바로 사라집니다.
이전 방식과 비교
| 축 | 예전(정적 컨텍스트에 가깝게) | 지금 논의되는 방향 |
|---|---|---|
| MCP | 연결된 도구의 전체 JSON 스키마를 매 요청에 실을 수 있음 | 이름 카탈로그만 두고, 필요할 때 스키마를 끌어오는 dynamic context discovery |
| 검증 | diff/로그 위주, 사람은 로컬에서 다시 실행 | 격리 VM + computer use로 UI를 직접 클릭하고 recordScreen 데모를 PR에 첨부 |
| 환경 장애 | 에이전트가 “설치 실패”에서 맴돌거나 사람 개입 | Cursor Cloud MCP로 egress·시크릿·셋업 실패를 스스로 점검, Cloud Doctor가 반복 실패를 추적 |
Cursor가 공개한 dynamic context discovery 글에서는, MCP 도구를 실제로 호출한 런에 대해 총 에이전트 토큰이 약 46.9% 감소했다는 A/B 결과가 나옵니다(설치 MCP 수에 따라 분산이 큼). 8월 3일 발표의 20–30%/80%와 같은 실험은 아닙니다. 다만 “컨텍스트를 덜 넣는 쪽이 이긴다”는 같은 엔지니어링 방향을 보여 줍니다.
computer use 쪽 80%는 특히 주의해서 읽어야 합니다. UI를 검증하는 런에서 낭비가 줄었다는 제품 주장이지, “computer use를 켜면 무조건 80% 싸다”는 뜻이 아닙니다. 데모 경로가 정리되면 재시도·장황한 로그 덤프·사람 핸드오프가 줄어든다는 쪽이 더 설득력 있습니다.
코드 / 설정 예시
클라우드 런의 토큰을 아끼려면, 프롬프트만 다듬기보다 환경과 MCP 표면적을 먼저 줄입니다.
// .cursor/environment.json (개념 스케치 — 팀 스키마에 맞게 조정)
{
"install": "pnpm install --frozen-lockfile",
"start": "pnpm dev",
// 에이전트가 매번 추측하지 않도록 “어떻게 띄우는지”를 고정
}
실무 체크리스트:
[ ] MCP는 이번 작업에 필요한 서버만 attach (장식용 서버 제거)
[ ] 가능하면 HTTP MCP — 자격증명이 에이전트 VM에 안 들어가게
[ ] stdio MCP는 env/시크릿이 VM에 노출된다는 전제로 최소 권한
[ ] Skills는 “전 레포 소설”이 아니라 작업별 짧은 지시
[ ] UI 검증이 목표면 computer use + recordScreen을 명시, 아니면 끄고 로그/테스트로
Cursor 문서도 클라우드 에이전트에서 HTTP MCP를 권장합니다. stdio는 VM 안에서 돌고 설정·환경변수를 에이전트가 볼 수 있기 때문입니다. 효율 이야기 옆에 신뢰 경계가 항상 붙습니다.
실무에서 쓰는 법
- 작업을 쪼개기 전에 비용 단위를 정한다. “이슈 하나 = 클라우드 에이전트 하나”가 기본이면, MCP 10개를 전부 붙인 채 돌리지 않습니다.
- computer use는 데모가 필요할 때. PR에 클릭 영상이 가치 있을 때만 켭니다. CLI/유닛 테스트로 끝나는 작업에 데스크톱을 쥐어 주면, 효율이 좋아져도 절대 토큰은 늘 수 있습니다.
- 실패 모드를 환경에 맡긴다. 설치·egress·시크릿 변경을 채팅에서 추측하게 두지 말고, Cloud MCP / 환경 스냅샷 /
anydev같은 “서비스 기동 경로”를 고정합니다. - 자기 레포의 토큰 구성을 본다. 입력(히스토리·도구 결과)·출력·캐시 미스가 어디서 크는지 모른 채 벤더 %만 인용하면, 다음 분기 예산에서 집니다.
처음 클라우드로 긴 리팩터를 맡겼을 때, 저는 MCP를 “있을 수도 있으니” 다섯 개나 붙여 둔 채로 돌렸습니다. 에이전트는 도구 이름 읽느라 턴을 허비했고, 정작 필요한 건 테스트 실행과 PR 본문뿐이었습니다. 서버를 두 개로 줄이고 작업을 “테스트 그린 + 데모 30초”로 바꾸니, 같은 모델인데도 런이 눈에 띄게 짧아졌습니다. 퍼센트를 믿기 전에 표면적을 줄이는 실험이 먼저였습니다.
시니어 엔지니어 관점
마케팅 숫자는 방향을 알려 주지만, SLO가 되지 않습니다. 레포 크기, 모델 믹스, MCP 개수, 캐시 적중, computer use 유무에 따라 체감은 갈립니다. Cursor도 방법론을 공개하지 않았으니, 내부 발표 자료에 “우리는 30% 절감”이라고 적지 마세요. “Cursor가 효율 개선을 주장했고, 우리 워크로드에서 측정한다”가 정직한 문장입니다.
또 하나: 토큰을 줄이는 최적화와 권한을 줄이는 최적화는 같이 가야 합니다. 효율이 좋아져 더 긴 작업을 맡길수록, stdio MCP·광역 시크릿·자동 git push의 사고 반경도 커집니다. Black Hat 시즌에 코딩 에이전트 인젝션 연구가 반복되는 이유와 같은 축입니다. 싸게 돌리는 것과 안전하게 돌리는 것은 충돌하지 않아야 합니다.
Cursor에서 쓰기
- Agents Window / 클라우드 환경 셋업으로 재사용 스냅샷을 만듭니다. 매 런마다
pnpm install을 추측하게 두지 마세요. - 로컬에서 시작한 작업을
/in-cloud로 넘길 때는, MCP·스킬 목록을 클라우드용으로 다시 고릅니다. 로컬에 붙여 둔 서버가 그대로 따라오면 토큰과 권한이 같이 갑니다. - UI 변경이면 “브라우저로 확인 후
recordScreen첨부”를 프롬프트에 명시합니다. computer use 효율 주장이 의미 있는 구간입니다. - 환경이 이상하면 장황한 재시도보다 Cloud MCP 진단(egress, 시크릿, 셋업 로그)을 먼저 보게 합니다.
FAQ
Q. 20–30% / 80%를 그대로 예산에 넣어도 되나요?
A. 아니요. Cursor 제품 주장이며 공개 방법론이 없습니다. 파일럿 워크로드로 측정하세요.
Q. dynamic context discovery의 46.9%와 같은 숫자인가요?
A. 아닙니다. 46.9%는 MCP를 호출한 런에 대한 A/B 결과로 공개된 별도 수치입니다. 방향은 같고 실험은 다릅니다.
Q. MCP를 많이 붙이면 무조건 손해인가요?
A. “전부 정적 주입”이던 시절보다 나아졌더라도, 카탈로그·히스토리·도구 결과는 여전히 비용입니다. 필요한 서버만 붙이세요.
Q. computer use를 끄면 손해인가요?
A. 데모가 필요 없는 작업에서는 끄는 편이 나을 수 있습니다. 80%는 computer use 사용 런에 대한 주장입니다.
소스
- Cursor on X (2026-08-03) — https://x.com/cursor_ai/status/2084317547608911986
- Dynamic context discovery — https://cursor.com/blog/dynamic-context-discovery
- How we set up our cloud agent environment — https://cursor.com/blog/cloud-agent-environment
- Agent computer use — https://cursor.com/blog/agent-computer-use
- Cloud agent capabilities — https://cursor.com/docs/cloud-agent/capabilities.md
- Cloud agent setup — https://cursor.com/docs/cloud-agent/setup
- Secondary summary — https://aicatchup.com/news/cursor-cloud-agents-token-efficiency-computer-use
마치며
클라우드 에이전트는 “더 싸게 더 길게” 가는 쪽으로 움직이고 있습니다. 그 위에서 이길 팀은 벤더 퍼센트를 외우는 팀이 아니라, MCP 표면적·검증 경로·권한을 레포에 고정해 두는 팀입니다.
앞으로 몇 분기 동안은 모델 단가 경쟁보다 에이전트 하네스의 토큰 회계가 더 자주 회의 안건이 될 가능성이 큽니다. 퍼센트를 인용하기 전에, 우리 런의 입력 토큰이 어디서 새는지부터 재는 습관을 들이는 편이 낫습니다.