Cursor 비용 관리 2026, Usage CSV·Admin API·팀 예산 추적 기준

Cursor 비용 관리를 위한 AI 코딩 도구 사용량 분석과 팀 예산 검토 장면 — Cursor 비용 관리는 Usage 화면, Teams 요금, Admin API, 모델 단가를 같은 billing cycle로 맞춰 봐야 한다.

Cursor 비용 관리를 검색한 팀은 보통 IDE 구독료보다 AI Agent 사용량이 먼저 불안하다.

개발자는 모델을 바꾸고, 팀장은 월 예산을 닫아야 하며, 구매 담당자는 좌석 수와 온디맨드 청구액을 같은 표에서 보고 싶어 한다.

결론부터 말하면 Cursor는 단순 좌석형 개발도구 예산으로 관리하면 안 된다.

Teams 요금, 포함 사용량, Other Models 단가, Cursor Token Rate, 온디맨드 지출, CSV와 Admin API 데이터를 분리해야 실제 비용 통제가 된다.

이 글은 Cursor 사용량 페이지 논란을 옮기는 글이 아니라, 공식 가격 문서와 Admin API 기준으로 팀 예산표를 다시 짜는 실무 가이드다.

핵심 요약

Teams 공식 문서 기준 Standard는 월 $40/user, Premium은 월 $120/user, Free admin seat는 월 $0이다.
Cursor Token Rate는 third-party model request에 적용되는 $0.25 per million tokens이며, Auto Cost와 Cursor Models에는 적용되지 않는다.
Admin API의 /teams/spend는 spendCents와 overallSpendCents를 주고, /teams/filtered-usage-events는 chargedCents 합산으로 event-level 비용 대조가 가능하다.
Usage Analytics의 CSV 다운로드는 행동 분석에는 유용하지만, 청구 대조는 spend endpoint와 invoice snapshot을 함께 남겨야 안전하다.

이 글이 필요한 사람

Cursor Teams를 도입했지만 월말 청구액이 개발팀 예상보다 커지는 조직.
Pro, Teams Standard, Teams Premium, Enterprise 중 어떤 요금 체계를 선택할지 검토하는 엔지니어링 리더.
Usage CSV, Dashboard, Admin API 값을 서로 대조해 팀별 예산표를 만들고 싶은 운영 담당자.
AI 코딩 도구 비용을 GitHub Actions, 클라우드, SaaS 예산과 함께 FinOps 방식으로 관리하려는 팀.
모델별 토큰 단가와 온디맨드 지출을 개발자에게 설명해야 하는 구매·재무 담당자.

먼저 결론: Cursor 비용 관리는 좌석비와 토큰비를 나눠야 한다

Cursor 공식 가격 페이지는 Individual을 월 $20, Teams를 월 $40/user로 표시한다.

Teams 공식 문서는 Standard seat를 월 $40/user, Premium seat를 월 $120/user, Free admin seat를 월 $0/user로 설명한다.

여기까지만 보면 예산은 좌석 수 곱하기 월액으로 끝난다.

문제는 Agent와 모델 선택이 포함 사용량과 온디맨드 지출을 만든다는 점이다.

Teams 문서는 각 paid seat에 포함 사용량이 있고, 초과 사용은 on-demand usage로 계속 쓸 수 있으며 Teams plan에서는 기본 활성이라고 설명한다.

따라서 예산표는 seat budget, included usage, on-demand usage, model mix, API reconciliation 다섯 줄로 나눠야 한다.

예산 줄	공식 기준	관리 질문	실무 판단
좌석비	Individual $20/mo, Teams Standard $40/user/mo, Premium $120/user/mo	사용자별 seat type이 실제 사용량과 맞는가	매월 active paid seat와 admin-only 계정을 분리
포함 사용량	Cursor Models와 Other Models pool이 billing cycle마다 reset	어떤 pool이 먼저 고갈되는가	모델 선택 정책과 팀 교육으로 조정
온디맨드	초과 사용은 arrears billing이며 dashboard와 API에서 추적	월 한도와 owner가 정해졌는가	team-wide limit을 먼저 둠
모델 단가	third-party model은 public list API price와 Cursor Token Rate 영향	고가 모델을 누가 언제 쓰는가	request별 chargedCents와 모델을 추적
대조 데이터	/teams/spend와 /teams/filtered-usage-events를 함께 확인	CSV만 보고 invoice를 설명할 수 있는가	billing cycle snapshot을 저장

이 조건이면 Cursor 비용을 적극적으로 키워도 된다.

Agent 사용이 실제 배포 리드타임을 줄이고, Premium seat 사용자가 명확하며, chargedCents와 invoice가 매주 대조되는 경우다.

이 경우는 증설을 보류한다.

누가 어떤 모델로 온디맨드 지출을 만들었는지 설명하지 못하고, Usage CSV만 내려받아 월말에 맞추는 구조라면 먼저 계측을 고쳐야 한다.

공식 가격표 핵심 숫자: $20, $40, $120, $0.25를 한 표에 둔다

비용 의도 글에서 가장 위험한 문장은 “요금은 상황에 따라 다릅니다”로 끝내는 것이다.

Cursor는 공식 가격과 Teams 문서에서 최소한 좌석비, Cursor Token Rate, 모델별 token price, API 비용 필드를 공개한다.

이 숫자를 같은 통화와 같은 billing cycle로 놓아야 팀 예산표가 살아난다.

항목	공식 숫자	어디에 쓰나	주의점
Individual Pro	$20/mo	개인 개발자 기준선	팀 billing, SSO, 중앙 관리 요구가 있으면 Teams와 비교
Teams Standard	$40/user/mo	기본 팀 좌석비	seat type은 role과 별개이며 active paid seat 기준
Teams Premium	$120/user/mo	Standard 대비 5x usage seat	고사용자에게만 붙여야 예산이 닫힘
Free admin seat	$0/user/mo	결제 관리 전용 admin	Cursor access가 없는 unpaid admin 용도
Cursor Token Rate	$0.25 per million tokens	third-party model request에 추가되는 Cursor 수수료	Auto Cost와 first-party Cursor Models에는 적용되지 않음
Auto Cost	$1.25 input, $1.25 cache write, $0.25 cache read, $6 output per million tokens	모델 자동 선택 비용 기준	문서상 hidden by default이므로 정책으로 노출 여부 확인
Claude 4 Sonnet 예시	$3 input, $3.75 cache write, $0.3 cache read, $15 output per million tokens	third-party model 비용 예시	출력 토큰이 입력보다 훨씬 비싸므로 긴 응답 습관이 비용을 키움
API rate limit	/teams/spend 20 req/min, usage events 60 req/min	자동 수집 주기 결정	과도한 polling은 피하고 hourly aggregation 기준으로 설계

이 표의 목적은 “어느 플랜이 싸다”를 단정하는 것이 아니다.

좌석비로 닫히는 비용과 토큰으로 커지는 비용을 분리해 승인권자에게 보여주는 것이다.

Usage CSV는 행동 분석, Admin API는 청구 대조로 쓴다

Cursor Usage Analytics 문서는 Web Dashboard에서 팀의 사용 방식을 볼 수 있고 각 chart에서 CSV 다운로드를 제공한다고 설명한다.

같은 문서는 header의 download icon으로 모든 chart 데이터를 내려받을 수 있다고 적는다.

이 CSV는 개발자 adoption, Tab completion, Agent edits, repository insights를 보는 데 좋다.

하지만 청구액을 설명하려면 Admin API의 spending data와 usage events data가 더 직접적이다.

Admin API 문서는 /teams/spend가 current billing cycle의 spendCents, overallSpendCents, monthlyLimitDollars, effectivePerUserLimitDollars를 반환한다고 설명한다.

또 /teams/filtered-usage-events는 chargedCents를 합산해 /teams/spend totals와 대조할 수 있다고 문서화되어 있다.

데이터 경로	강한 지점	약한 지점	추천 용도
Usage Analytics CSV	chart별 행동 지표와 다운로드가 쉽다	invoice 대조 필드가 항상 충분하다고 보면 위험	활동량, adoption, 모델 사용 습관 분석
/teams/daily-usage-data	일별 사용자 활동과 request count 확인	subscriptionIncludedReqs는 raw event count 성격	팀 사용량 추세와 active user 점검
/teams/spend	current cycle 사용자별 spendCents와 limit 확인	request 단위 원인 분석은 부족	월말 예산 대시보드 기준값
/teams/filtered-usage-events	model, kind, chargedCents, token 여부, cloudAgent filter 확인	개인정보와 대량 데이터 보관 통제가 필요	사용자·모델·이벤트 단위 비용 원인 분석
Invoice snapshot	실제 청구 기준	늦게 나온다	재무 보고와 API 대조의 최종 기준

실무 시나리오 1은 팀장이 “지난주에 왜 $300이 늘었나”를 묻는 경우다.

CSV에서 Agent messages가 많은 사용자를 찾고, /teams/spend에서 spendCents 상위 사용자를 확인한 뒤, usage events의 model과 chargedCents를 합산해야 답이 나온다.

CSV만 보면 활동이 많다는 사실은 알지만, 고가 모델의 출력 토큰이 원인인지, 온디맨드 limit이 열린 탓인지는 부족하다.

Dashboard 설정은 한도와 권한부터 본다

Cursor Team Dashboard 문서는 billing 접근, usage-based pricing 설정, team 관리를 dashboard에서 수행한다고 설명한다.

Teams & Enterprise settings에는 Usage-Based Pricing Settings가 있고, usage-based pricing과 monthly team spending limits를 설정할 수 있다고 문서화되어 있다.

Enterprise-only settings에는 Enhanced Spend Limits가 있어 member-level override와 group-based limit을 다룰 수 있다고 설명한다.

이 구조는 작은 팀과 큰 팀의 통제 방식이 달라야 한다는 뜻이다.

통제 항목	Teams 기준	Enterprise 기준	실무 체크
월 한도	team-wide monthly spending limit 관리	member-level override와 group-based limit 가능	초기에는 team limit을 낮게 두고 2주 단위로 조정
권한	admins can modify settings 여부 확인	SCIM, SSO, audit log와 결합	결제 설정 변경자를 2명 이하로 제한
모델 접근	팀 설정의 model access 검토	조직 group별 model policy 가능	고가 모델은 목적과 owner를 남김
API key	Cursor Admin API key 생성과 관리	service accounts와 audit log 검토	비용 수집 key는 읽기 목적과 rotation 기준을 문서화
Cloud Agent	cloud agent 사용량을 dashboard에서 확인	self-hosted hostingType filter로 inference spend 분리	Cursor-hosted와 self-hosted run을 따로 집계

이 조건이면 Dashboard만으로도 첫 달 통제가 된다.

사용자가 10명 안팎이고, paid seat가 적으며, team-wide limit과 weekly review만으로 지출이 설명되는 경우다.

이 경우는 API 수집을 바로 붙여야 한다.

사용자가 30명을 넘고 Premium seat가 섞이며, cloud agent와 automation까지 쓰면 dashboard 캡처만으로는 비용 원인이 흐려진다.

모델별 토큰 단가를 개발 습관으로 연결한다

Cursor의 Models & Pricing 문서는 Cursor Models와 Other Models pool을 나눠 설명한다.

Other Models는 model API rate로 pool이 차감되고, Teams 문서는 third-party model request에 public list API price와 Cursor Token Rate가 붙는다고 설명한다.

Cursor Learn의 Tokens & Pricing 문서는 input tokens와 output tokens가 비용 단위이며, output tokens는 보통 input보다 2~4배 비쌀 수 있다고 설명한다.

개발자에게 이 구조를 말하지 않으면 “Agent가 느렸다”는 감각만 남고 비용 습관은 바뀌지 않는다.

개발 습관	비용 영향	관리 신호	개선 기준
긴 파일 전체를 매번 첨부	input token과 cache write가 증가	usage events의 token 기반 call 증가	작업 단위와 파일 범위를 좁힘
긴 설명을 매번 요청	output token 비용이 커짐	응답 길이와 chargedCents가 같이 상승	짧은 diff, checklist, test command 중심으로 요청
고가 third-party model 고정	public list API price와 Cursor Token Rate 영향	특정 model에 비용 집중	기본은 Auto Cost 또는 적정 모델로 두고 예외만 기록
Cloud Agent 장기 실행	automation과 cloudAgentId로 비용이 누적	hostingType과 cloudAgentId 필터 필요	장기 작업은 owner와 종료 기준을 둠
Premium seat 남발	seat budget이 빠르게 고정비화	사용량 낮은 Premium 사용자 발생	2 billing cycle 연속 저사용자 downgrade 검토

실무 시나리오 2는 신입 개발자가 Agent에게 전체 모노레포를 매번 읽히는 경우다.

이때는 모델을 금지하기보다 작업 템플릿을 바꿔야 한다.

파일 범위, 실패 로그, 원하는 diff 형식, 테스트 명령을 작게 주면 input과 output token을 동시에 줄일 수 있다.

Admin API로 비용 대조 파이프라인을 만든다

Admin API는 Basic Authentication을 쓰며 API key를 username으로 넣는 구조라고 문서화되어 있다.

문서의 rate limit을 보면 audit logs와 spend 계열은 보수적으로 polling해야 한다.

비용 수집은 실시간 감시보다 billing cycle reconciliation에 맞추는 편이 안전하다.

아래 스켈레톤은 실제 토큰을 넣지 않는 수집 흐름 예시다.

수집 스크립트 스켈레톤

#!/usr/bin/env bash
# cursor-cost-collect.sh
# 목적: Cursor Teams의 현재 billing cycle 비용과 최근 30일 사용 이벤트를 같은 기준으로 수집한다.
# 실제 실행 전 YOUR_API_KEY, 날짜 epoch milliseconds, 접근 권한, 개인정보 마스킹 정책을 내부 기준에 맞춘다.

set -euo pipefail
API_KEY="${CURSOR_ADMIN_API_KEY:?set CURSOR_ADMIN_API_KEY}"
START_MS="${START_MS:?set START_MS}"
END_MS="${END_MS:?set END_MS}"

curl -sS -X POST "https://api.cursor.com/teams/spend"   -u "${API_KEY}:"   -H "Content-Type: application/json"   -d '{"page":1,"pageSize":100,"sortBy":"amount","sortDirection":"desc"}'   > cursor-team-spend.json

curl -sS -X POST "https://api.cursor.com/teams/filtered-usage-events"   -u "${API_KEY}:"   -H "Content-Type: application/json"   -d "{"startDate":${START_MS},"endDate":${END_MS},"page":1,"pageSize":1000}"   > cursor-usage-events.json

spend와 usage events 대조 스켈레톤

#!/usr/bin/env python3
# cursor_cost_reconcile.py
# 목적: /teams/spend의 사용자별 합계와 /teams/filtered-usage-events의 chargedCents 합계를 대조한다.
# 개인정보 보호를 위해 이메일은 실제 보고서에 그대로 쓰지 말고 팀 내부 식별자로 치환한다.

import json
from collections import defaultdict

spend = json.load(open("cursor-team-spend.json", encoding="utf-8"))
events = json.load(open("cursor-usage-events.json", encoding="utf-8"))

by_email = defaultdict(float)
for event in events.get("usageEvents", []):
    email = event.get("userEmail") or "unknown"
    by_email[email] += float(event.get("chargedCents") or 0)

for member in spend.get("teamMemberSpend", []):
    email = member.get("email") or "unknown"
    dashboard_cents = float(member.get("spendCents") or 0)
    event_cents = by_email.get(email, 0.0)
    delta = round(dashboard_cents - event_cents, 4)
    print(email, "dashboard_cents=", dashboard_cents, "event_cents=", round(event_cents, 4), "delta=", delta)

팀 비용 정책 YAML

# cursor-team-cost-policy.yaml
# 목적: Cursor 비용 관리 기준을 좌석, 모델, 온디맨드, CSV/API, 보안 로그로 분리한다.
# 실제 금액은 Cursor 공식 가격 문서, 팀 계약, invoice, Admin API 응답으로 다시 확인한다.

billing_cycle:
  review_day: every_monday
  owner: engineering-operations
  dashboard_pages:
    - https://cursor.com/dashboard/usage
    - https://cursor.com/dashboard/analytics
  api_sources:
    spend: /teams/spend
    usage_events: /teams/filtered-usage-events
    daily_usage: /teams/daily-usage-data

seat_policy:
  standard_team_seat_usd_per_user_month: 40
  premium_team_seat_usd_per_user_month: 120
  unpaid_admin_seat_usd_per_user_month: 0
  review_rules:
    - downgrade_premium_if_other_models_usage_is_low_for_2_cycles
    - remove_paid_seat_after_user_departure_and_credit_review
    - keep_unpaid_admin_for_billing_only_operators

usage_policy:
  cursor_token_rate_usd_per_million_tokens: 0.25
  on_demand_default_for_teams: enabled
  reconciliation:
    - sum_chargedCents_from_filtered_usage_events
    - compare_with_spendCents_from_teams_spend
    - keep_invoice_snapshot_per_billing_cycle
  guardrails:
    - set_team_wide_monthly_limit
    - document_enterprise_member_limit_if_available
    - alert_when_top_user_share_exceeds_35_percent

이 스켈레톤은 바로 운영 배포용이 아니다.

API key 보관, 이메일 마스킹, 로그 보존 기간, 재무 보고 권한을 내부 보안 기준에 맞춘 뒤 적용해야 한다.

보안과 개인정보: 비용 데이터도 개발자 행동 로그다

Cursor Usage Analytics는 사용자, repository, messages, active users, agent edits 같은 행동 데이터를 다룬다.

Admin API의 usage events는 userEmail, serviceAccountId, cloudAgentId, automationId, model, chargedCents 같은 필드를 포함한다.

비용 최적화라는 이름으로 이 데이터를 아무나 보는 dashboard에 모으면 개인정보와 인사평가 리스크가 생긴다.

리스크	발생 지점	통제 방법	책임자
개인 성과 오해	사용자별 spend와 AI 코드 비율을 단순 순위화	팀 단위 추세와 예외 조사 기준만 공개	엔지니어링 리더
이메일 노출	API raw JSON과 CSV 공유	보고서에는 내부 ID로 pseudonymize	데이터 운영자
API key 유출	비용 수집 스크립트와 CI secret 관리	읽기 권한 key, rotation, audit log 점검	보안팀
장기 보관	usage events와 repository insights 저장	billing cycle별 snapshot만 보관하고 원본 폐기	재무·보안 공동
모델 정책 우회	개별 사용자가 고가 모델을 임의 선택	model access와 exception approval 기록	플랫폼팀

이 조건이면 사용자별 상세 비용을 볼 수 있다.

예산 초과 원인 분석, 보안 감사, 본인 확인 요청처럼 목적이 명확하고 접근 로그가 남는 경우다.

이 경우는 팀 전체 공개를 피한다.

사용자별 AI 코드 비율과 비용을 순위표처럼 공유하면 생산성 논쟁이 비용 통제를 덮을 수 있다.

운영 절차: 첫 30일 Cursor 비용 관리 루틴

도입 첫 달에는 자동 절감보다 관측 신뢰도를 먼저 만든다.

값이 맞는지 모르는데 한도를 낮추면 개발자가 우회하고, 값을 믿지 못하면 재무팀이 도구 효과를 인정하지 않는다.

1주차에는 paid seat, admin-only seat, Teams Standard, Premium 사용자를 확정한다.
1주차에는 dashboard에서 usage-based pricing과 monthly team spending limit 설정 권한을 확인한다.
2주차에는 Usage Analytics CSV를 내려받아 adoption 지표와 repository별 사용 흐름을 본다.
2주차에는 /teams/spend를 호출해 spendCents, overallSpendCents, monthlyLimitDollars를 저장한다.
3주차에는 /teams/filtered-usage-events에서 chargedCents를 합산해 spendCents와 차이를 기록한다.
3주차에는 모델별 비용 집중 사용자에게 작업 템플릿과 model choice 기준을 공유한다.
4주차에는 invoice snapshot, dashboard export, API 결과를 하나의 billing report로 묶는다.
4주차에는 Premium 유지, downgrade, Enterprise pooled usage 검토 대상을 분리한다.

이 루틴은 개발자를 감시하려는 절차가 아니다.

AI 코딩 도구가 실제로 돈을 쓰는 지점을 설명해 다음 달 예산을 덜 감정적으로 정하려는 절차다.

실패 패턴: Cursor 비용 최적화가 더 비싸지는 경우

첫 번째 실패는 좌석비만 보고 팀 전체를 Standard로 올린 뒤 온디맨드 지출을 늦게 발견하는 것이다.

두 번째 실패는 Usage CSV만 보고 invoice와 맞지 않는 숫자로 회의하는 것이다.

세 번째 실패는 고가 모델 사용을 전면 금지해 개발자가 외부 도구나 개인 계정으로 우회하게 만드는 것이다.

네 번째 실패는 user-level 비용 데이터를 맥락 없이 공개해 팀 신뢰를 깨는 것이다.

실패 패턴	초기 증상	비용 영향	막는 방법
좌석비만 관리	월 고정비는 맞는데 사용량 청구가 튐	예산 초과 원인을 뒤늦게 찾음	seat와 chargedCents를 같은 report에 둠
CSV 과신	활동량은 보이나 실제 spend 설명이 약함	재무 보고와 dashboard 논쟁 발생	/teams/spend와 usage events를 대조
모델 전면 금지	작업 품질 저하와 우회 사용 증가	비공식 계정 비용과 보안 리스크 발생	고가 모델 exception과 template을 둠
한도만 낮춤	개발 중단과 불만 증가	중요 작업이 월말에 막힘	team-wide limit과 owner 승인 절차를 둠
개인 순위표 공개	사용량 논쟁이 성과 평가처럼 변함	협업 신뢰와 도구 adoption 저하	목적 제한, 마스킹, 집계 보고로 전환