GPT-5.2-Codex, 안드로이드 멀티모듈에서 진짜 어떠냐고요

 

벤치마크 1위 모델이 안드로이드 실무에서 의외의 고전을 면치 못했습니다. 바로 GPT-5.2-Codex 얘기예요. 점수가 높을수록 실무도 강하다는 공식, 안드로이드 멀티모듈 개발에서는 잘 안 통하거든요.

 

얼마 전에 50개 모듈 규모의 코틀린 멀티플랫폼(Kotlin Multiplatform, KMP) 프로젝트에 GPT-5.2-Codex, 클로드 코드(Claude Code) 1M, 커서(Cursor) 3.3을 붙여서 같은 일감을 비교해봤어요. 젯팩 컴포즈(Jetpack Compose) 화면 작성, Gradle 컨벤션 플러그인 리팩터링, ProGuard 분석까지 돌려봤는데 결과가 꽤 흥미로웠습니다.

 

GPT-5.2-Codex 안드로이드 실무, 벤치마크와 달랐던 이유

 

GPT-5.2-Codex는 SWE-Bench Pro에서 56.4%를 기록하며 코딩 벤치마크 상위권을 차지했습니다. (참고로 GPT-5.2 본 모델은 55.6%였죠.)

 

근데 막상 젯팩 컴포즈 화면 작성을 시켜보니, 즉시 실행할 수 없는 코드가 자주 나왔어요. Composable 함수 시그니처가 틀리거나 이미 deprecated된 API를 그대로 써오는 식으로 말이죠. 안드로이드 최신 생태계의 변화 속도를 모델이 완벽히 따라잡지 못한 느낌이었습니다.

 

여기서 주의할 점이 있어요. 커서 안에서 선택하는 'GPT-5.2'와 'GPT-5.2-Codex'는 아예 별개 모델이라는 점이죠. 성능과 비용 체계가 다르니 혼동하면 안 됩니다. 게다가 지금은 후속 버전인 GPT-5.3-Codex(SWE-Bench Pro 56.8%)가 이미 나와 있어서, 5.2 버전은 살짝 한 세대 뒤처진 상태라는 점도 감안해야 해요.

 

커서 3.3 병렬 에이전트가 멀티모듈 반복 작업에 잘 맞는 지점

커서의 핵심 변화는 독립된 작업을 하위 에이전트로 동시에 실행하는 기능입니다. 정확히는 병렬 서브에이전트(/multitask)가 3.0부터 도입되어 3.3의 'Build in Parallel' 기능으로 고도화된 건데요. 이게 Gradle 모듈 단위 병렬 처리와 궁합이 정말 잘 맞아요.

젯팩 컴포즈 화면 신규 작성 작업에서 커서는 압도적이었습니다.

(제 환경 기준) 
- 커서 3.3: 30초 내외 (즉시 실행 가능한 코드)
- 클로드 코드: 1분 30초 내외 (품질은 상급)
- GPT-5.2-Codex: deprecated API 오류 반복

 

50개 모듈에 흩어진 Lint 오류 수정도 커서에 맡기니 모듈별 에이전트가 병렬로 처리해서 속도가 확실히 체감되더라고요. 다만, 하위 에이전트들이 모듈 간 숨겨진 의존성을 모른 채 파일을 동시에 건드리면 빌드가 터질 수 있습니다. 작업 범위를 명확히 나누고 Task Budgets을 걸어두는 게 필수예요.

 

 

클로드 코드 1M 토큰, Gradle 리팩터링에서 결정적인 한 가지

클로드 코드는 1M(100만) 토큰이라는 압도적인 컨텍스트 윈도우를 자랑합니다. A4 용지 수천 장 분량을 한꺼번에 읽는 수준이죠.

이 차이는 Gradle 컨벤션 플러그인 리팩터링에서 극명하게 갈렸습니다. settings.gradle.kts부터 수십 개의 build.gradle.kts, libs.versions.toml을 전부 올려도 넘치지 않거든요. 클로드 코드는 전체 빌드 구조를 한눈에 파악하고 오류 없이 작업을 마쳤습니다.

 

반면 전체 구조를 다 보지 못한 다른 도구들은 변수 중복 선언이나 의존성 누락 실수를 하더라고요. 다만 클로드 코드도 무작정 다 읽게 하면 안 됩니다. .claudeignore로 빌드 산출물을 제외하고, CLAUDE.md에 분석할 모듈 목록을 명시해줘야 토큰 낭비를 막고 정확도를 높일 수 있습니다.

 

 

ProGuard 장기 분석은 왜 GPT-5.2-Codex가 앞섰을까

놀랍게도 3~4일씩 걸리는 ProGuard 규칙 분석 작업은 GPT-5.2-Codex가 가장 나았습니다. 세션이 길어져도 앞서 분석한 내용을 일관성 있게 유지하는 능력이 좋더라고요. 에이전틱 코딩(Agentic Coding)에 특화된 모델답게 장기 리팩터링에서 강점이 나왔습니다.

 

최근 한 벤치마크 분석(Endor Labs)을 보면 재밌는 결과가 있어요. 동일한 모델이라도 커서 SDK 환경(Harness)에서는 87.2%의 성능이 나오는데, 네이티브 Codex CLI에서는 61.5%에 그쳤다고 하거든요. 결국 모델 자체의 지능도 중요하지만, 그 모델을 감싸고 있는 실행 환경(Harness)이 실무 성과를 크게 좌우한다는 증거인 셈이죠.

 

안드로이드 멀티모듈 AI 도구, 일감에 따라 고르는 법

직접 굴려보고 정리한 최적의 조합입니다.

일감 유형	추천 도구
Compose 신규 화면 (단순 반복)	커서 3.3
Gradle 컨벤션 플러그인 리팩터링	클로드 코드 1M
Lint 오류 일괄 수정	커서 3.3
ProGuard 및 장기 분석 작업	GPT-5.2-Codex
라이브러리/AGP 일괄 업그레이드	안드로이드 스튜디오 최신판 (Panda 시리즈)

 

특히 마지막 항목인 라이브러리 일괄 업그레이드는 안드로이드 스튜디오 내장 제미나이와 AGP 업그레이드 어시스턴트 조합이 다크호스입니다. IDE에 완전히 통합된 도구만의 강점이 확실히 있더라고요.

 

 

마치며

벤치마크 1위 모델 하나만 고집한다고 안드로이드 멀티모듈 작업이 저절로 빨라지지는 않습니다. 저는 일감 목록을 먼저 뽑아놓고 그 성격에 맞춰 도구를 갈아 끼우는 방식을 택했어요. 처음엔 번거로워 보이지만, 한 주만 굴려보시면 "이게 진짜 생산성이구나" 하고 체감하게 되실 거예요.