에이전트에게 ADB 대신 전용 CLI를 쥐여주면 생기는 일: Android Dev Summit 2026 개발 도구와 ACP 해부

노트북·폴더블·스마트폰 환경에서 Android 개발 도구와 다수의 코딩 에이전트가 연결되어 동작하는 모습을 표현한 생성형 개념 이미지다. 실제 Android Studio 화면이 아니다.

Google이 공개한 Android Dev Summit 2026 개발 도구 세션 영상과 오프닝 키노트 영상은 코딩 에이전트가 Android 앱을 빌드·디버깅·검증할 때 왜 기존 개발자용 명령줄 도구(adb, gradle)가 병목이 되는지, 그리고 이를 해결하기 위해 어떤 에이전트 전용 인터페이스를 설계했는지를 다룬다. Android 개발자 경험 팀의 Dar Fernando와 Esteban de la Canal은 구조화된 출력을 반환하는 Android CLI, 에뮬레이터 없이 단일 프로세스로 APK를 즉시 띄우는 android prototype, 그리고 40개 이상의 외부 에이전트 하네스를 IDE에 연결하는 Android Studio Rabbit 2의 ACP(Agent Client Protocol)를 핵심 변화로 제시했다.

결론부터 말하면, 프론티어 모델(Claude Opus 5.5, Gemini 4 Argon 등)의 코딩 능력을 Android 프로젝트에서 제대로 끌어내려면 에이전트가 비정형 logcat 텍스트나 화면 픽셀 좌표를 추측하게 두는 대신, 대화형 프롬프트가 없고 의미론적(semantic) 결과를 반환하는 전용 도구 계층(Android CLI 및 Android Skills)을 쥐여주어야 시간과 토큰 비용을 동시에 줄일 수 있다. 다만 이 글은 Google이 공개한 발표 영상과 공식 문서를 바탕으로 도구 구조와 발표 수치를 정리한 것이며, 자체 프로젝트에서 에이전트별 토큰 절감 폭을 직접 벤치마킹한 결과는 아니다.

왜 에이전트에게 날것의 ADB와 Gradle을 주면 토큰을 낭비하는가

기존 CLI 도구들은 사람이 터미널을 보며 대화형 프롬프트에 답하거나 긴 로그를 눈으로 훑는 상황을 가정해 만들어졌다. 코딩 에이전트에게 아무런 래퍼 없이 기존 도구만 주고 메모리 누수를 찾거나 UI를 수정하라고 지시하면 다음과 같은 비효율이 발생한다.

비정형 로그 폴링과 힙 덤프 타이밍 추측: 에이전트가 메모리 누수를 잡으려고 logcat 출력이나 LeakCanary 알림을 반복해서 폴링(polling)하고, 언제 힙 덤프(heap dump)를 떠야 할지 몰라 수십 번의 무의미한 턴을 소모한다.

무거운 컴파일·에뮬레이터 부팅 루프: Jetpack Compose UI 하나를 고칠 때마다 전체 APK를 빌드해 무거운 에뮬레이터에 배포하고 화면을 캡처하느라 피드백 루프가 수 분 단위로 늘어난다.

픽셀 좌표 환각(Hallucination): 화면 요소를 탭할 때 정밀한 픽셀 좌표를 계산하다가 해상도나 폴더블 화면 크기가 달라지면 엉뚱한 곳을 누른다.

이를 해결하기 위해 정식 출시된 Android CLI는 대화형 입력을 완전히 없애고(zero interactive prompts) 에이전트가 한 번의 호출로 필요한 구조화된 결과만 얻도록 재설계되었다(Android CLI 릴리스 노트). 발표(11:36~20:45)에서 공개된 Claude Opus 5.5(중간 노력 수준, 6개 사용자 여정·4개 메모리 누수 수정 과제) 기준 비교 결과는 다음과 같다.

작업 영역	기존 방식 (Raw ADB / Gradle / 에뮬레이터)	Android CLI 전용 명령	발표된 에이전트 효율 개선 폭
메모리 누수 탐지 및 수정	`logcat` 반복 폴링 및 수동 힙 덤프 시점 추측	`android profiler` (LeakCanary 네이티브 연동 및 참조 체인 분석)	동일 과제 완수 속도 약 2배 향상, 토큰 사용량 25% 절감
UI 레이아웃 반복 검증	전체 빌드 후 에뮬레이터/IDE에서 화면 캡처	`android preview` (IDE·에뮬레이터 없이 터미널에서 Compose 프리뷰 즉시 렌더링)	UI 수정 및 시각 검증 반복 시간 최대 77% 단축
APK 크기 및 R8 최적화	수십 번의 빌드·역컴파일 왕복으로 DEX 구조 탐색	`android analyze` (단일 명령으로 이전·이후 APK의 DEX 델타 비교)	출력 토큰(Output Tokens) 사용량 5.5배 감소 (Pocket Casts 데모에서 24초 만에 DEX 0.5MB 감량)
기기 화면 조작 및 재현	화면 캡처 후 픽셀 좌표 계산 및 원시 `adb shell input` 호출	`android input` • `android layout` (`text=Submit` 등 의미론적 셀렉터 조작)	좌표 계산 오류 제거로 전체 작업 실행 속도 25% 향상
대용량 APK 배포 및 현장 진단	500MB 전체 APK 반복 재설치 및 수동 크래시 확인	`android install` (변경된 바이트만 델타 푸시) + `android signals` (Crashlytics 연동)	변경 파일만 즉시 반영하여 재현·검증 루프 단축 (데모에서 1분 42초 만에 크래시 재현·수정 완료)

에뮬레이터 없는 단일 프로세스 실행기(android prototype)와 30개 이상의 Android Skills

에이전트가 수십 개의 화면 변형을 동시에 검증할 때 가장 큰 물리적 한계는 개발자 노트북의 RAM을 차지하는 무거운 가상머신(AVD 에뮬레이터)이다. 세션(11:10~13:20)과 키노트(13:25~14:58)에서 초기 프리뷰로 공개된 android prototype은 이 제약을 우회한다.

중첩 가상화 없는 단일 호스트 프로세스 실행: android prototype app.apk 명령을 실행하면 전체 Android OS 에뮬레이터를 부팅하지 않고 호스트(현재 Linux 기반) 위에서 가벼운 단일 프로세스로 기성 Android x86 APK를 바로 띄운다.

네이티브(.so) 및 OpenGL ES 변환 계층 내장: 단순 UI 껍데기만 그리는 것이 아니라 내부 Room 데이터베이스 변경이 그대로 동작하며, 40개 모듈 규모의 실제 오픈소스 앱(Pocket Casts)에 포함된 네이티브 공유 라이브러리(.so)와 OpenGL ES 그래픽 호출도 변환 계층(translation layer)을 통해 데스크톱에서 바로 실행한다.

다중 폼팩터 동시 실행: 메모리 부담이 작기 때문에 스마트폰(Phone), 폴더블(Foldable), 데스크톱(Google Book 등) 프로필을 한 번에 여러 개 띄워 놓고 에이전트가 동시에 레이아웃과 상태 유지를 검증할 수 있다.

또한 모델의 사전 학습 데이터가 놓치기 쉬운 최신 플랫폼 규약을 보완하기 위해 20개 이상 영역에 걸친 30개 이상의 공식 Android Skills가 함께 제공된다(Android CLI 에이전트 플러그인 문서). Google은 자체 평가 프레임워크(Eval)를 돌려 모델이 이미 알고 있는 상식은 빼고, Compose 리컴포지션 성능 최적화, 최신 카메라 API, 보안, 대형 화면 적응형(Adaptive) 레이아웃, 온디바이스 함수 호출(AppFunctions 스킬 문서)처럼 모델이 자주 실수하는 영역만 스킬로 패키징했다.

Android Studio Rabbit 2의 ACP(Agent Client Protocol)와 AI 변경 사항 리뷰

터미널 밖에서 IDE를 쓰는 개발팀을 위해 Android Studio Rabbit 2(Stable)는 특정 AI 벤더에 종속되지 않는 Bring Your Own Agent(BYOA) 구조를 채택했다.

핵심은 개방형 프로토콜인 ACP(Agent Client Protocol)다. 개발자는 사내에서 이미 구독 중인 Claude Code(Opus 5.5), OpenAI Codex, Google Antigravity(Gemini 4 Argon), Qwen, Kimi 등 40개 이상의 외부 에이전트 하네스를 Android Studio 내부에 그대로 연결할 수 있다. 단순 챗봇 창만 빌려 쓰는 것이 아니라, ACP를 통해 연결된 외부 에이전트가 Android Studio 고유의 정적 분석기, 빌드·싱크 도구, Compose 프리뷰 렌더러, 디바이스 배포 도구를 직접 호출하고 컨텍스트를 공유한다.

또한 에이전트가 작성한 대규모 PR을 사람이 검토할 때의 피로를 줄이기 위해 AI Change Review 및 Walkthrough 기능이 안정 버전에 포함되었다. 데모(24:15~26:30)에서는 15개 파일·800줄이 변경된 북마크 스와이프 PR을 분석해, “행(row)이 리컴포지션(recomposition)될 때마다 전체 스와이프 액션이 중복 실행되어 삭제 확인 대화상자가 무한 반복될 수 있다”는 Compose 특유의 상태 버그를 찾아내고 수정안까지 제시하는 과정을 보여주었다.

현업 Android 프로젝트에 에이전트 도구를 도입할 때 확인할 점

사내 Android 개발 환경이나 CI 파이프라인에 이번 도구들을 적용할 때는 다음 네 가지를 먼저 점검하는 편이 좋다.

범용 셸 접근보다 공식 Android CLI 플러그인 우선 연결: Claude Code, Codex, Antigravity를 쓰고 있다면 에이전트가 adb나 ./gradlew를 주먹구구식으로 호출하게 두지 말고 공식 플러그인(Agent plugins 가이드)을 설치해 android preview, android analyze, android input을 기본 도구로 쓰게 유도해야 토큰 비용과 실행 시간을 아낄 수 있다.

AGENTS.md에 사전 빌드 및 사용 명령 명시: 발표 데모에서도 강조되었듯, 에이전트가 매번 전체 클린 빌드를 돌리지 않도록 증분 설치(--use-delta-install)와 android signals·android profiler 사용 규칙을 프로젝트 루트의 AGENTS.md에 명시해 두는 것이 효과적이다.

온디바이스 에이전트 연동(AppFunctions) 시 Kotlin 기본값 함정 주의: 함께 발표된 Android MCP 및 Jetpack AppFunctions(Beta)로 앱 기능을 Gemini 등 외부 에이전트에 노출할 때는 Kotlin 함수의 파라미터 기본값(default value)이 무시되고 생략된 인자가 null·false·0으로 전달된다(AppFunctions 품질 가이드라인). 또한 기본적으로 메인(UI) 스레드에서 호출이 시작되므로 무거운 I/O는 반드시 백그라운드 코루틴 디스패처로 넘기고 AppFunctionException으로 명확한 에러 원인을 반환해야 한다.

에이전트가 생성한 Compose 코드는 리컴포지션 부작용(Side-effect) 중심으로 리뷰: 코딩 에이전트가 XML View를 Compose로 빠르게 변환해 주더라도, 데모 사례처럼 리컴포지션 시점에 이벤트나 상태 갱신이 중복 실행되는 미묘한 버그가 섞이기 쉽다. PR 병합 전 AI Change Review나 프리뷰 검증을 통해 상태(State) 바인딩과 코루틴 스코프 수명주기를 중점적으로 확인해야 한다.

결국 에이전트 시대의 개발 생산성은 더 비싼 모델을 고르는 것보다, 에이전트가 시행착오 없이 한 번에 정확한 상태를 읽고 조작할 수 있는 구조화된 도구(CLI·ACP·Skills)를 제공하는가에서 결정된다.