커서(Cursor) 3.3 토큰 사용량 분석 — 멀티모듈 안드로이드 토큰 낭비 줄이기

 

얼마 전에 커서(Cursor) 3.3으로 업데이트하고 Context Usage Breakdown을 처음 켜봤는데, 숫자가 예상보다 훨씬 크게 나와서 멘붕이 왔어요. 사이드로 만들던 5모듈 안드로이드 앱에서 제 화면 기준으로 codebase로 잡힌 항목 하나가 토큰 예산의 68%를 먹고 있었거든요(어디까지나 제 환경 기준 수치예요). 처음엔 뭔가 잘못 설정한 줄 알았는데, 파고들다 보니 멀티모듈 구조 특유의 패턴이더라고요.

 

한 가지 먼저 짚어두고 싶은 부분이 있습니다. 커서 3.3 업데이트에서 본격적으로 강조된 병렬 빌드(Build in Parallel) 기능으로 돌아가는 서브에이전트는 독립된 토큰 공간에서 작업하고, 결과 요약만 부모 에이전트에게 돌려줍니다. 그래서 수치가 크게 보여도 실제 메인 토큰 소모는 생각보다 적어요. 링에서 빨간색이 뜬다면 subagents보다 codebase와 rules를 먼저 확인하는 게 낫습니다.

 

멀티모듈 안드로이드에서 토큰이 빨리 닳는 구조적 이유

단일 모듈에서는 별 문제 없다가 멀티모듈로 넘어오면 갑자기 체감이 달라지는 경우가 많아요. 구조적인 이유가 있거든요.

 

@Codebase를 쓰면 커서는 :app, :feature:auth, :core:data 같은 모든 모듈을 통째로 인덱싱합니다. 그 안에 Hilt와 KSP가 빌드 때 자동으로 만들어내는 파일들, Gradle 스크립트, build/ 디렉터리까지 다 딸려오거든요. 코드는 영어 텍스트보다 토큰 밀도가 높아서 ViewModel 파일 하나만 해도 수백~수천 토큰이 쌓이는 경우가 많아요. 제가 손에 잡힌 200줄짜리 ViewModel을 GPT 토크나이저에 넣어보니 대략 1,500토큰 정도가 나왔거든요. 그런 파일이 수십 개 딸려오면 @Codebase 한 번에 사용량이 순식간에 올라가는 거예요.

 

대화 히스토리도 무시할 수가 없습니다. 세션 초반에 첨부한 로그 파일이 한참 뒤에도 매 요청마다 재전송됩니다. 따로 정리하지 않으면 이미 해결된 오류 로그가 계속 자리를 차지하는 구조라고 볼 수 있죠. 에이전트 모드의 스펜딩 리밋(Spending Limit) 같은 토큰 사용량 관리 설정을 명시적으로 잡아두지 않으면 이게 누적되는 속도가 더 빨라집니다.

 

 

커서 멀티모듈 안드로이드 토큰 누수 3가지

Context Usage Breakdown 세부 내역을 보면 세 곳이 특히 눈에 들어왔어요. (아래 퍼센티지는 모두 제 화면 기록 기준이에요.) 이 세 가지가 합쳐서 사실상 codebase로 잡힌 덩어리의 대부분을 차지하고 있었습니다.

 

1. build/generated 디렉터리 생성 코드 (26%) Hilt와 KSP가 빌드 시 자동으로 만들어내는 파일들이 원본 소스와 이중으로 인덱싱되고 있었습니다. Hilt 쪽이면 Hilt_<원본>.kt, <원본>_HiltModules.kt, <원본>_GeneratedInjector.kt 같은 패턴이고, Room을 쓰는 모듈이면 DAO 구현체인 <원본>_Impl.kt가 따로 또 쌓여요. 무시 설정이 없으면 커서는 이 파일들이 자동 생성 코드인지 구분 없이 집어들어요. AI 입장에서는 거의 쓸모없는 정보인데 토큰은 꼬박꼬박 차지하는 구조거든요.

 

2. 과도하게 상세한 규칙 파일군 (18%) .cursor/rules/ 아래에 젯팩 컴포즈(Jetpack Compose) 컨벤션, 코루틴 패턴, Hilt 주입 규칙을 각각 파일로 나눠뒀었는데, 이게 매 요청마다 전부 딸려오더라고요. AI가 이미 잘 따르는 규칙이라면 매번 상기시켜줄 필요가 없는데, 규칙이 정교해질수록 토큰 비용도 커지는 역설이에요. 내재화된 규칙은 별도 디렉터리로 보관하거나 비활성화하는 게 낫습니다.

 

3. Gradle 스크립트 중복 인덱싱 (12%) 멀티모듈에서는 최상위 build.gradle.kts, 각 모듈 스크립트, Convention Plugin 코드가 전부 따로 인덱싱됩니다. 내용이 겹치는 부분이 많아도 파일 단위로 각각 처리하다 보니, 같은 설정이 반복해서 계산되는 구조입니다.

 

 

.cursorignore 5개 규칙으로 안드로이드 codebase 점유율 낮추기

프로젝트 루트에 설정 파일을 만들어 인덱싱 제외 범위를 지정합니다. 아래 다섯 가지를 적용하고 나서 codebase 점유율이 68%에서 38% 수준으로 내려갔어요.

 

한 가지 미리 짚고 갈게요. 공식 문서 기준으로 .cursorignore는 "AI 접근 자체를 베스트-에포트로 차단"하는 용도라서, 순수하게 인덱싱만 빼고 싶다면 .cursorindexingignore가 더 정확한 선택이에요. 그래서 보안 목적(예: local.properties, gradle.properties)은 .cursorignore에, 빌드 산출물·생성 코드·테스트 리포트처럼 단순히 인덱싱에서만 빼면 되는 항목은 .cursorindexingignore에 두는 식으로 나눠 두면 시니어 디테일이 훨씬 살아납니다. 팀 단위로 운영할 때는 분리해두는 게 확실히 안전해요.

 

1. 빌드 디렉터리 제외 효과가 제일 큽니다. 모든 모듈의 빌드 산출물을 한 번에 인덱싱 대상에서 날릴 수 있거든요. (인덱싱 차단만 필요한 경우라면 .cursorindexingignore 쪽이 더 적합해요.)

build/
**/build/
.gradle/

 

2. KSP/Hilt/Room 생성 파일 패턴 제외 1번 규칙과 겹쳐 보여도 둘 다 있어야 확실히 잡힙니다. 경로 기준과 파일명 패턴 기준이 각각 다르게 동작하기 때문입니다. Hilt와 Room 산출물을 같이 묶어둡니다. KAPT를 아직 쓰는 모듈이 있다면 .java 패턴도 함께 넣어주는 게 안전해요. 이 항목도 인덱싱 차단 목적이라면 .cursorindexingignore 추천 후보예요.

**/build/generated/**
**/Hilt_*.kt
**/*_HiltModules*.kt
**/*_GeneratedInjector*.kt
**/*_Factory.java
**/*_Impl.kt

 

3. Convention Plugin 구현부 제외 Gradle 설정 공통화 코드인데, 기능 개발할 때는 볼 일이 거의 없어요. Gradle 설정을 물어볼 때만 해당 build.gradle.kts를 직접 참조하는 방식이 훨씬 낫습니다.

buildSrc/src/main/kotlin/**/*.kt
convention/src/main/kotlin/**/*.kt

 

4. IDE 캐시 및 로컬 설정 제외 local.properties에는 SDK 경로가 들어가고, gradle.properties에는 팀별 API 키나 빌드 환경 변수를 넣어두는 경우가 있어서 보안상으로도 빼두는 게 맞아요. 이 항목은 성격상 완벽한 접근 차단을 위해 .cursorignore에 두는 게 맞습니다.

.idea/
local.properties
gradle.properties

 

5. 테스트 빌드 산출물 제외 테스트 커버리지 리포트가 XML 형식으로 수백 줄씩 쌓이는 경우가 있어요. 생각보다 토큰을 많이 잡아먹더라구요. 이 항목도 단순 인덱싱 제외라면 .cursorindexingignore 쪽으로 옮겨도 됩니다.

**/test-results/
**/reports/
**/coverage/

 

참고로 저는 파일 정리와 함께 @Codebase 사용 습관도 바꿨어요. 이제는 @LoginViewModel.kt, @UserRepository.kt처럼 필요한 파일만 명시적으로 참조하고 있어요. @Codebase 전체를 넘기는 건 구조를 정말 통째로 봐야 하는 순간에만 쓰는 편입니다.

 

커서 vs 클로드 코드 안드로이드 역할 분담

멀티모듈 안드로이드에서 커서가 버거운 작업이 있는데, 전체 아키텍처를 보면서 방향을 잡는 일입니다. 새로운 레이어를 어디서 나눌지, 마이그레이션 순서를 어떻게 잡을지 같은 설계 작업은 코드베이스 전체를 한꺼번에 봐야 하거든요.

 

이럴 때는 클로드 코드(Claude Code)를 씁니다. 한 번에 받아들일 수 있는 토큰 한도가 훨씬 크거든요. 쉽게 말하면 5개 모듈 소스 전체를 한 번에 넣어도 버티는 수준이에요. 클로드 코드로 설계 방향을 먼저 잡고, 중간중간 HITL(Human-in-the-Loop, 사람의 개입)로 분기점을 직접 확정한 다음, 파일 단위 구현은 커서로 넘기는 식으로 쓰고 있습니다.

 

커서는 반대로 단일 파일 리팩토링이나 모듈 내 버그 수정 같은 좁고 집중적인 작업에서 진가가 나옵니다. 토큰 예산을 최소로 유지할수록 응답 정확도가 올라가는 게 체감되더라고요.

 

안드로이드 스튜디오(Android Studio)도 이 역할 분담 흐름 안에 넣으면 좋아요. Gradle 동기화, 빌드, 에뮬레이터 실행은 안드로이드 스튜디오에 맡겨두는 겁니다. 이걸 커서의 MCP로 처리하면 빌드 로그 전체가 토큰으로 쌓여버리거든요. 빌드는 IDE, 코드 구현은 커서, 설계 정리는 클로드 코드 — 이 세 가지 구분만 잡아두면 토큰 소진 속도가 눈에 띄게 달라집니다.

 

 

마치며

codebase가 빨간색으로 뜨는 건 코드가 복잡해서가 아니라, 커서가 봐선 안 될 파일까지 보고 있다는 신호입니다. 10분짜리 설정 작업 하나로 토큰이 어디서 새고 있었는지가 선명하게 드러납니다. 멀티모듈 프로젝트라면 오늘 안에 한 번은 확실히 정리해 두는 게 맞습니다.