Cursor를 업무에 쓰면서 모델을 선택하고 사용하는데 크게 생각하지 않았었는데 최근 Opus 4.8가 발표된 뒤 사용해보다가, 이번에 비용이 크게 나왔으니 원인 보고를 하도록 지시를 받았습니다.
2026년 5월 초부터 6월 말까지 2개월 치의 토큰 사용량을 확인했는데 이벤트는 900건이 조금 넘었으며 토큰은 대략 6억 3천만 정도였습니다. 이번 사용 내역을 분석해보면서 생각한 것과 그래서 앞으로 저는 어떻게 쓸지를 정리해보았습니다.
처음엔 그냥 골라 썼습니다
처음에는 Auto, Composer, Opus가 각각 뭔지 잘 모른 채로, 필요할 때마다 그냥 골라가며 썼습니다. 새로 나왔다고 하면 써보고, 대규모 작업에 좋다고 하면 좋겠거니 하고 고르는 식이었습니다. 그래서 비용이 나중에야 눈에 들어왔습니다.
숫자가 말해 준 것
사용 내역을 모델별로 나눠 보니, 토큰 대비 비용이 아래처럼 나왔습니다.
| 모델 | 이벤트 | 토큰 비중 | On-Demand | 1M 토큰당 비용 | 이벤트당 평균 토큰 |
| Opus 4.8 | 201 | 47% | $298.60 (79%) | $1.24 | 1.53M |
| auto | 508 | 35% | $36.67 (10%) | $0.36 | 0.67M |
| composer-2.5-fast | 191 | 17% | $44.45 (12%) | $1.05 | 0.78M |
이벤트 수는 Auto가 더 많았는데, 토큰의 절반 가까이와 On-Demand 비용의 약 80%는 Opus에서 나왔습니다.
Auto는 건수도 많고 1M 토큰당 비용도 $0.36으로 가장 낮았습니다. 반면 composer-2.5-fast는 1M 토큰당 $1.05로, Auto보다 토큰 대비 비용이 꽤 높았습니다. Composer 2.5가 저렴하다고 생각해서 사용했는데 왜 이렇게 비용이 크게 나왔는지를 확인해보니 Fast Mode를 쓰면 Standard Mode 보다 6배정보 비싸더라구요..? 😅 (링크)
단순 모델의 문제는 아니었겠으나 기본적으로 모델 비용이 비싼걸 사용하면 비용이 눈에 띄게 차이가 난다는걸 깨달았습니다. 애초에 비용이 10배 차이였으니 말해뭐해...
지금은 이렇게 씁니다.
대부분의 작업은 Auto
일상적인 SQL 작성·검수, ETL 점검, Git·PR, 짧은 수정은 거의 Auto만 둡니다. 생각보다 Agent 구현도 Auto에 맡겨 두면 Composer 쪽으로 라우팅되는 경우가 많았습니다. “구현이니까 무조건 Composer”로 시작하지 않아도 되는 날이 더 많았습니다.
에이전트를 복잡하게 사용할건데 싸게 쓰고 싶으면 Composer 2.5
Agent로 파일을 오래 만지거나, Auto 라우팅에만 맡기기 애매할 때입니다. (Standard 기준입니다.)
기본값이 Fast으로 되어있어서 별도로 변경해줘야 합니다.
Composer 2.5의 성능이 제 기준에서는 매우 만족스러워서 굳이 다른 모델을 고르지는 않고 있습니다.
제가 분석한 결과와 사용하는 방법이 완벽하다고 할 수는 없습니다. 업무 종류와 요금제, Cursor 버전마다 체감이 다를 수 있습니다. 그래도 혹시 모델을 뭘 써야 하는지 고민하는 분들에게 도움이 되면 좋겠습니다.
읽어주셔서 감사합니다.
