Cursor Composer 2.5 vs Claude Code, 안드 프로젝트 닷새 같이 굴린 1차 후기

 

지난주 새벽 2시, 안드로이드 스튜디오(Android Studio) 터미널 한쪽엔 클로드 코드(Claude Code), 다른 창엔 커서 컴포저 2.5(Cursor Composer 2.5). Room 마이그레이션을 누가 더 깔끔하게 뽑는지 정면으로 붙여봤거든요.

 

조건은 단순했어요. 단일 모듈 Compose 앱, Kotlin 2.3.x, AGP 9.2.0. 평가 축은 ① Room 스키마 마이그레이션 ② Compose 화면 추가 ③ Gradle 빌드 실패 디버깅 세 가지로 잡았습니다. 결과부터 미리 흘리자면, 한쪽이 완승하는 그림은 아니었어요.

 

Composer 2.5와 Claude Code, 어디에 강점이 있나

커서 컴포저 2.5는 Kimi K2.5 베이스에 Cursor가 후처리를 얹은 에이전트예요. SWE-Bench Multilingual에서 79.8%, CursorBench v3.1에서는 Opus 4.7을 살짝 앞서는 63.2%를 기록했다는 발표가 있습니다. 강점은 인라인 Tab 자동완성과 IDE 안에서 도는 매끄러운 손맛, 그리고 비용입니다.

 

클로드 코드 Opus 4.7은 터미널 기반 에이전트예요. SWE-bench Verified 87.6%로 현행 최상위권인데, 진짜 무기는 1M 토큰 한도와 CLAUDE.md 파일로 프로젝트 규칙을 박아두는 구조더군요. 1M 토큰이 어느 정도냐면, 단일 모듈 안드 프로젝트의 코틀린 파일을 거의 통째로 한 번에 읽힐 수 있는 분량입니다.

 

두 도구의 자리잡기는 분명히 다릅니다. 컴포저는 IDE 안에서의 손맛과 비용 효율, 클로드 코드는 CLI에서 빌드 시스템과 직접 대화하는 능력. 같은 "AI 코딩 도구" 라벨이 붙어 있지만 풀려고 만들어진 문제가 좀 달라 보여요.

 

Room 마이그레이션 다중 파일 일관성은 클로드 코드 우위

첫 테스트는 Room 스키마에 컬럼 두 개 추가, 인덱스 하나 변경. Dao 호출부 14곳에 영향이 갔습니다.

 

클로드 코드는 @Entity 수정 → Migration 객체 작성 → 마이그레이션 테스트 추가 → Dao 호출부 14곳 동시 패치를 한 번의 지시로 통과시켰습니다. 14곳 중 13곳은 그대로 쓸 만했고, 한 곳만 nullable 처리가 어긋나 손볼 정도였어요.

 

컴포저 2.5는 체감 속도가 더 빨랐는데, FTS 가상 테이블 재생성 로직을 빠뜨려서 한 번 더 지시를 넣어야 했습니다. IDE 안에서 Tab으로 받아치는 흐름은 즐거운데, 여러 파일에 걸친 구조 변경에서는 일관성이 살짝 흔들리는 인상입니다. 토큰 한도 차이가 크게 작용한 듯합니다.

 

 

Jetpack Compose 화면 추가, 컴포저 2.5 자동완성의 손맛

UI 작업으로 들어오면 분위기가 완전히 뒤집힙니다. 검색 화면 하나를 새로 만드는 작업이었는데, LazyColumn + OutlinedTextField + LaunchedEffect 조합을 컴포저 2.5가 Tab 몇 번으로 다 깔아줬어요.

LaunchedEffect(query) {
    snapshotFlow { query }
        .debounce(300)
        .collectLatest { viewModel.search(it) }
}

 

이런 보일러플레이트가 거의 손 안 대고 흘러나옵니다. Preview 수정-재실행 사이클도 평균 11초 정도로 짧았어요.

 

반면 클로드 코드는 Compose Preview를 볼 방법이 없으니, 미세 조정할 때마다 안드로이드 스튜디오 창으로 다시 돌아가야 했습니다. 화면 하나 만드는 동안 IDE-CLI 전환이 다섯 번 넘게 일어나더라고요. 작업 자체는 가능한데, 손이 더 갑니다.

 

개인적으로는 Compose UI 작업만큼은 컴포저 2.5가 훨씬 손에 붙는다고 봅니다. Tab 자동완성에 한번 익숙해지면 CLI로 돌아가기가 쉽지 않아요.

 

 

Gradle 빌드 에러 디버깅, 터미널 에이전트가 강한 이유

세 번째 테스트가 가장 갈렸습니다. 일부러 빌드 깨짐 세 가지를 만들어봤어요.

1. KSP와 Kotlin 버전 불일치
2. Compose Compiler와 Kotlin 2.3 호환성 충돌
3. Java 21 desugaring 미설정

클로드 코드는 ./gradlew assembleDebug 로그를 터미널에서 그대로 읽고, 세 케이스 모두 1차 시도에서 정확한 수정안을 내놓았습니다. libs.versions.toml 갱신과 AGP 플러그인 ID 정정까지 한 흐름으로 처리됐어요.

 

컴포저 2.5는 IDE 안에서 도니까 터미널 로그를 복사해 채팅창에 넣는 단계가 들어갑니다. 그 단계에서 로그 끝부분이 잘렸고, 첫 시도에서 엉뚱한 의존성을 건드리는 일이 한 번 있었습니다. 빌드 에러처럼 콘솔 중심으로 풀어야 하는 일은 클로드 코드가 명확히 우위라고 봐요.

 

 

두 도구 같이 쓸까, 한쪽만 골라야 할까

지금 제가 굴리는 조합은 두 도구 병행입니다. 안드로이드 스튜디오 안에서는 컴포저 2.5로 UI와 빠른 수정, 별도 터미널 탭에서는 클로드 코드로 빌드 진단과 구조 리팩토링. 월 비용은 Cursor Pro 20달러 + Claude Code Max 100달러 안팎으로 묶이는데, AI 응답 속도보다 ./gradlew 대기 시간이 더 큰 병목이라 두 에이전트가 그 빈 시간을 갉아먹어 주는 효과가 큽니다.

 

물론 변수는 남아 있어요. 구글 AI 스튜디오가 프롬프트만으로 안드로이드 앱을 뽑아내기 시작했고, 두 모델 다 Compose의 stable/experimental 경계나 코틀린 버전 호환성에서는 여전히 부정확한 코드를 종종 내놓는 일이 있더라고요. 1차로 뽑힌 의존성과 API 시그니처는 사람이 한 번 더 확인해야 한다는 게 닷새 굴려본 1차 감상입니다.

 

한쪽만 골라야 한다면 저는 클로드 코드 쪽에 손을 들겠습니다. UI 자동완성의 손맛은 분명히 컴포저 2.5가 한 수 위인데, 빌드 에러로 새벽에 멍해지는 그 시간을 깎아주는 효과가 결국 더 컸어요. 단일 모듈 UI 중심 앱이라면 거꾸로 컴포저 하나로 가는 쪽이 맞고요. 본인 프로젝트가 UI 폴리싱에 시간이 더 들어가는지, 멀티 모듈·빌드 시스템 씨름이 더 잦은지부터 답해보시면 도구는 자연히 한쪽으로 기울 거예요.