Cursor Router 가이드 | Teams 모델 라우팅·과금

2026년 7월 22일, Cursor는 Cursor Router를 공개했습니다. Auto 모드가 이제 “모델 하나 고르기”가 아니라, 요청마다 어떤 모델에 보낼지 분류하는 라우터가 됩니다.

핵심 한 줄: Teams/Enterprise에서 Agent를 돌린다면, 문제는 “어떤 frontier가 제일 똑똑한가”가 아니라 요청 단위로 비용을 어디에 둘지입니다. Router는 그 결정을 제품 기능으로 옮깁니다.

왜 중요한가

Cursor 출시 글에 따르면, Cursor를 쓰는 개발자의 약 60%가 하나의 모델을 일상 드라이버로 고정합니다. 그 결과 오타 수정·짧은 리팩터·UI 문구 같은 가벼운 일도 frontier 가격으로 청구되고, 사용량은 품질보다 빨리 늘어납니다.

에이전트 워크플로에서는 그 패턴이 더 가혹합니다. 한 턴이 도구 호출·파일 읽기·테스트 실행을 여러 번 묶기 때문에, “항상 Opus/Fable급” 설정은 한 주의 예산을 순식간에 태웁니다. Router의 존재 이유는 그 고정 모델을 기본값에서 빼는 것에 가깝습니다.

PapaCoder Labs 관점에서도 같은 질문입니다. 콘텐츠 파이프라인·클라우드 에이전트·리뷰 루프를 돌릴 때, 모든 단계를 같은 고가 모델에 맡기면 품질보다 먼저 청구서가 먼저 옵니다.

이전 방식과 어떻게 다른가

접근	무엇을 결정하나	한계
수동 모델 고정	사람이 픽커에서 하나 고름	가벼운 작업도 frontier 단가
레거시 Auto (Cost)	이전 Auto 라우팅 + 번들 Auto 토큰 요금	예측 가능한 대신, Balance/Intelligence가 노리는 “만족도 대비 비용”과는 다른 축
DIY 라우터 (프롬프트/게이트웨이)	팀이 복잡도 휴리스틱을 직접 짬	유지보수·캐시 미스·모델 풀 갱신을 팀이 부담
Cursor Router	요청 분류 → 모델 풀에서 선택	Teams/Enterprise 전용, Grok 4.5 필수, 모드별 과금이 다름

Router는 “실패하면 다음 모델”식 폴백 체인이 아니라, 모델이 돌기 전에 요청을 분류합니다. 문서상 분류 신호는 작업 유형·복잡도 등이고, 관리자는 허용/차단 모델 목록으로 풀을 좁힐 수 있습니다. 다만 차단을 너무 좁히면 라우팅 품질이 떨어지고 라우터 자체가 비활성화될 수 있다고 문서에 명시되어 있습니다.

Cost / Balance / Intelligence — 이름보다 과금이 먼저

모델 픽커에서 Auto를 고른 뒤 Optimize For를 고릅니다.

Cost: 이전 Auto에 가깝습니다. 토큰 지출을 최적화하고, 어떤 모델이 처리했는지와 무관하게 번들 Auto 요금으로 청구됩니다. 예산 예측이 중요한 팀의 바닥 모드입니다.
Balance: 신규 기본값으로 안내됩니다. 지능·속도·비용을 같이 봅니다. Cursor는 Opus 4.8 대비 만족도는 높이고 비용은 약 36% 낮췄다고 자체 A/B를 인용합니다.
Intelligence: 더 어려운 작업에 강한 모델을 태웁니다. Cursor는 Fable급 만족도에 가깝게 맞추면서 팀 비용을 약 60% 낮췄고, Opus 4.8 대비 비슷한 비용에서 만족도를 약 15% 올렸다고 주장합니다.

여기가 함정입니다. Balance와 Intelligence는 라우팅된 모델의 단가로 청구됩니다. 공식 문서 기준으로 Cost보다 평균 약 2배, 모드에 따라 최대 2–4배까지 나갈 수 있습니다. 헤드라인의 “60% 절감”은 단일 frontier에 전부 고정했을 때와의 비교이지, Cost 모드 대비 “무조건 싸다”는 뜻이 아닙니다.

숫자 주의: 절감·만족도 수치는 Cursor 자체 A/B(벤더 주장)입니다. 독립 감사 결과가 아니므로, 도입 결정에는 “우리 워크로드에서 2주 측정”을 붙이세요.

코드 / 설정 예시 (SDK)

TypeScript·Python SDK에서는 Router를 모델 id auto-smart로 노출하고, optimize_for에 cost | balanced | intelligence를 넣습니다. API 키가 속한 팀에 Router가 있는지 Cursor.models.list()로 확인하라고 문서가 권합니다.

import { Cursor } from "@cursor/sdk"; // package name may vary by SDK docs

// Confirm Router is available for this team's API key first.
const models = await Cursor.models.list();
const hasRouter = models.some((m) => m.id === "auto-smart");

if (!hasRouter) {
  throw new Error("Cursor Router (auto-smart) not available for this team key");
}

const run = await Cursor.agent.run({
  model: "auto-smart",
  optimize_for: "balanced", // "cost" | "balanced" | "intelligence"
  prompt: "Review the Internal API draft upsert path and suggest a test plan.",
});

데스크톱에서는 픽커 → Auto → Optimize For면 충분합니다. SDK는 같은 축을 코드로 고정할 때 의미가 있습니다.

실무에서 어떻게 쓸까

팀 체크리스트를 짧게 잡으면 이렇습니다.

플랜 확인: Router는 문서상 Teams / Enterprise 전용입니다. 개인 Pro만 쓰고 있다면 모드 셀렉터가 안 보이는 게 정상입니다.
Grok 4.5 허용: 가격 효율 바닥 모델로 Grok 4.5가 필요하다고 문서·changelog가 명시합니다. 차단 목록에서 빼면 라우터가 제대로 동작하지 않을 수 있습니다.
기본 모드 합의: 예산 팀이면 Cost부터, 일상 Agent면 Balance, 장기 리팩터/설계면 Intelligence를 세션 단위로 올리는 식이 현실적입니다.
라우팅 모델 표시: 기본은 숨김입니다. 도입 첫 2주는 표시를 켜서 어떤 작업이 어떤 모델로 갔는지 감을 잡으세요. 그다음 브랜드 편향을 줄이려면 다시 숨겨도 됩니다.
Admin 가드레일: 모드 제한, 그룹별 enable, soft/hard Auto 강제 옵션이 changelog에 있습니다. “전원 Intelligence”를 금지하는 것만으로도 청구서 분산이 됩니다.

처음 Router를 켠 팀은 Balance 기본값만 믿고 한 주를 보냈다가, Cost 때보다 사용량 한도가 빨리 닳아 “절감이 어디?”를 물은 경우가 있습니다. 절감은 항상 Opus를 고르던 습관 대비이지, 가장 싼 Auto 모드 대비가 아닐 수 있습니다.

시니어 엔지니어 관점

Router를 “품질 마법”으로 보지 말고 비용·거버넌스 컨트롤 플레인으로 보세요.

관측 없이 라우팅하면 나중에 “누가 이 버그를 넣었나”보다 “어떤 모델 계층이 이 패턴을 만들었나”를 못 묻습니다. 초기에 모델 표시를 켜는 이유가 여기 있습니다.
모델 allow/block은 보안 정책이기도 합니다. 특정 벤더를 막으면 라우팅 여지가 줄고, 심하면 라우터 비활성으로 이어질 수 있습니다. 정책은 “전부 차단”보다 “바닥 모델(Grok 4.5) + 허용 frontier 소수”가 낫습니다.
캐시 미스: 대화 중간에 모델이 바뀌면 프롬프트 캐시가 깨질 수 있습니다. Cursor는 학습·평가에 캐시 미스를 반영했다고 설명합니다. 그래도 팀이 DIY 라우터를 만들 때는 이 비용을 빼먹기 쉽습니다.
Individual 플랜 공백: 개인 Pro에서 수동으로 모델을 나누는 습관은 여전히 유효합니다. Router가 없다고 “품질이 낮다”기보다, 거버넌스 자동화가 아직 팀 SKU라는 뜻입니다.

Cursor에서 쓰는 법

Teams/Enterprise 워크스페이스에서 모델 픽커를 엽니다.
Auto를 선택합니다.
Optimize For에서 Cost / Balance / Intelligence를 고릅니다.
(선택) Admin 대시보드에서 라우터 enable, 기본 모드, 모델 표시, 그룹 정책을 맞춥니다.
Agent·CLI·웹·iOS·SDK 모두 같은 Router 축을 공유한다고 changelog가 말합니다. 로컬에서 Balance로 검증한 프롬프트를 클라우드 에이전트에도 그대로 가져가되, 시크릿·이그레스 정책은 환경 설정의 별 문제입니다.

FAQ

Q. Pro(개인)에서도 Router를 쓰나요?
A. 현재 문서 범위는 Teams와 Enterprise입니다. 개인 플랜은 수동 모델 선택이 기본입니다.

Q. Balance가 기본이라는데, 그냥 두면 되나요?
A. 일상에는 합리적 출발점입니다. 다만 Balance/Intelligence는 라우팅 모델 단가라서 Cost보다 비쌀 수 있습니다. 예산을 먼저 보면 Cost로 바닥을 재세요.

Q. “60% 절감”을 우리 숫자로 믿어도 되나요?
A. Cursor 온라인 A/B·자체 만족도 지표입니다. 도입 후 1–2주, 커밋/PR당 비용·재작업률을 팀 기준으로 재측정하세요.

Q. Grok 4.5를 꼭 켜야 하나요?
A. 문서상 Router가 가격 효율 옵션으로 Grok 4.5를 요구합니다. 막아 두면 라우팅이 깨지거나 비활성화될 수 있습니다.

Q. SDK에서 모드를 코드로 고정할 수 있나요?
A. auto-smart + optimize_for로 가능합니다. 배포 전에 models.list()로 팀 키에 Router가 있는지 확인하세요.

출처

마무리

Cursor Router는 새 모델이 아니라, Agent 시대의 모델 선택을 인프라 문제로 격상시킨 기능입니다. 팀에 의미 있는 절감은 헤드라인 퍼센트가 아니라, Cost/Balance/Intelligence를 워크로드에 맞게 나누고 Grok 4.5 바닥을 열어 둔 뒤, 첫 두 주는 라우팅 결과를 눈으로 확인하는 운영에서 나옵니다.

앞으로는 IDE 안의 요청 라우팅, 에이전트 플래너/워커 분리, 벤더 요금 티어가 같은 문장으로 수렴할 가능성이 큽니다 — 품질 막대를 넘는 가장 싼 단위에 일을 붙인다. Router는 그 문장을 Cursor Teams에 먼저 심은 제품입니다.

Cursor Router: Teams에서 모델 고르는 일을 인프라로 넘긴다