🔥 Android CLI와 Skills — 에이전트가 드디어 안드로이드 개발을 알아듣기 시작했다

#android#agent#android-cli#claude-code#gemini

1066자

13분

강의 목차

Android CLI, 에이전트가 알아볼 수 있는 표면으로 다시 태어났다
왜 이제 와서? 에이전트가 터미널을 두드리는 시대가 도착했다
Skills, Markdown 한 장으로 에이전트의 행동을 교정하기
Android Knowledge Base, 학습 컷오프를 우회하는 정공법
Android Studio는 여전히 집이다
내 생각, 편해졌다기보단 '해석이 필요 없어졌다'
참고 자료

Android CLI — build Android apps 3x faster using any agent
출처: Android Developers Blog

어제 늦은 밤 Android 개발자 블로그에 올라온 글 하나를 읽다가, 커피를 한 잔 더 내렸다. 제목은 "Android CLI and skills: Build Android apps 3x faster using any agent." 내가 Android 개발을 처음 시작했을 때 sdkmanager, avdmanager, adb, 그리고 Gradle 래퍼가 터미널 한가운데에서 서로 싸우고 있었던 풍경이 떠올랐다. 그게 벌써 10년 전이다.

그리고 이번 주, Google이 그걸 전부 android라는 한 글자 남짓한 명령어 아래로 묶어서 다시 가져왔다. 그냥 CLI를 정리한 게 아니라, 에이전트가 쓰기 좋으라고 다시 설계한 CLI다. 그게 이 발표의 핵심이다.

Android CLI, 에이전트가 알아볼 수 있는 표면으로 다시 태어났다

공식 발표는 2026년 4월 16일자. 저자는 Adarsh Fernando(Group Product Manager)와 Esteban de la Canal(Senior Staff Software Engineer)이다.

Android CLI 자체는 새 개념이 아니다. 옛날부터 android 명령어는 있었고, 한참 전에 deprecated된 적도 있다. 이번에 다시 살아 돌아온 이유를 Google은 한마디로 "에이전트가 외부에서 Android를 만질 수 있는 가볍고 프로그래머틱한 인터페이스가 필요했기 때문"이라고 설명한다. 블로그 본문이 꽤 담백하게 수치로 설명한다. 내부 실험에서 프로젝트 셋업 같은 작업에 쓰이는 LLM 토큰이 70% 이상 줄었고, 작업 완료 속도는 3배 빨라졌다고 한다 (verified 2026-04-19).

주요 명령어를 하나씩 보면 왜 그런지 감이 잡힌다.

bash

# SDK 컴포넌트 설치 (필요한 것만 골라서)
android sdk install
 
# 공식 템플릿으로 새 프로젝트 생성
android create
 
# 가상 디바이스 생성과 관리
android emulator
 
# APK를 디바이스/에뮬레이터에 설치하고 실행하기
android run
 
# CLI 자체 업데이트
android update
 
# 최신 공식 문서 조회
android docs
 
# 스킬 탐색 / 설정
android skills

bash

# SDK 컴포넌트 설치 (필요한 것만 골라서)
android sdk install
 
# 공식 템플릿으로 새 프로젝트 생성
android create
 
# 가상 디바이스 생성과 관리
android emulator
 
# APK를 디바이스/에뮬레이터에 설치하고 실행하기
android run
 
# CLI 자체 업데이트
android update
 
# 최신 공식 문서 조회
android docs
 
# 스킬 탐색 / 설정
android skills

여기서 눈여겨볼 건, 각 서브커맨드가 에이전트가 한 번에 이해할 수 있는 단위로 쪼개져 있다는 점이다. 예전 같으면 에이전트가 "프로젝트를 만들어 줘"라는 요청을 받고, sdkmanager "platform-tools" "platforms;android-34"를 설치하고, 디렉토리 구조를 직접 뽑아내고, build.gradle을 손으로 쓰고... 하는 과정을 훑어야 했다. 그 과정에서 토큰이 어마어마하게 날아간다. android create는 이걸 "공식 템플릿을 딸깍" 하는 한 줄로 줄여 버린다.

왜 이제 와서? 에이전트가 터미널을 두드리는 시대가 도착했다

이 발표의 배경을 이해하려면 지난 1년을 잠깐 돌아봐야 한다. Google은 2025년 6월에 Gemini in Android Studio의 Agent Mode를 공개했고, 11월에는 Antigravity라는 에이전트 중심 개발 플랫폼까지 내놨다. Claude Code, Codex, Gemini CLI 같은 써드파티 에이전트들은 이미 개발자들이 일상적으로 쓰고 있다.

문제는, 이 에이전트들이 전부 Android Studio 밖에서 움직이기 시작했다는 것이다. 블로그 서문에 Google이 직접 이렇게 적어 놨다.

"Whether you are using Gemini in Android Studio, Gemini CLI, Antigravity, or third-party agents like Claude Code or Codex, our mission is to ensure that high-quality Android development is possible everywhere."

"possible everywhere"라는 표현이 솔직하다. 예전에는 "Android Studio 안에서 쓰세요"였는데, 이제는 "어디서 뭘 쓰든 일관된 Android 경험을 깔아 주겠다"로 톤이 바뀌었다. Anthropic이나 OpenAI에게 생태계 주도권을 조금이라도 내주지 않겠다는 계산이 보인다. 그리고 그걸 가장 빠르게 실현하는 방법은, 에이전트가 당장 읽고 호출할 수 있는 표준 표면(surface)을 내려놓는 것이다.

Android CLI가 바로 그 표면이다.

Skills, Markdown 한 장으로 에이전트의 행동을 교정하기

CLI만 있어서는 반쪽짜리다. 에이전트가 "Navigation 3로 마이그레이션해 줘"라고 들으면 여전히 2년 전 블로그 글을 보고 엉뚱한 라이브러리를 찾을 수 있다. 그래서 같이 나온 게 Android Skills GitHub 저장소다.

Skills는 SKILL.md라는 Markdown 파일 한 장으로 정의된다. 프론트매터에 name, description 같은 메타데이터를 쓰고, 본문에는 에이전트가 따라야 할 절차를 적는 방식이다. 핵심은 이 메타데이터가 자동으로 매칭된다는 점이다. 사용자 프롬프트에 "edge-to-edge"가 나오면 관련 스킬이 조용히 끼어들어 컨텍스트에 로드된다. 수동으로 문서를 첨부하지 않아도 된다.

초기 릴리스에 들어간 스킬은 이런 것들이다.

Navigation 3 셋업과 마이그레이션
Edge-to-edge 지원 구현
AGP 9 및 XML-to-Compose 마이그레이션
R8 config 분석

내 경험상 이 네 가지는 Android 커뮤니티 Q&A의 단골 주제다. StackOverflow에서 검색해도 정답이 엇갈려 있어서 LLM이 구버전 답을 자신 있게 내놓는 일이 잦다. 공식 팀이 직접 "이 경로가 정답"이라고 못 박아 주는 건 생각보다 크다.

android skills 명령어로 공식 저장소를 탐색하고 로컬에 설치할 수 있고, 개인이 만든 스킬이나 커뮤니티 스킬도 같은 자리에 공존할 수 있게 설계됐다. 커뮤니티에서는 벌써 awesome-android-agent-skills 같은 큐레이션 저장소가 움직이고 있다.

Android Knowledge Base, 학습 컷오프를 우회하는 정공법

세 번째 조각은 가장 똑똑한 접근이라고 느꼈다. Android Knowledge Base는 android docs 명령어로 접근하는 검색 기반 지식 소스다. 이미 최신 Android Studio 안에도 들어가 있다.

정체는 에이전트가 질문을 던졌을 때 실시간으로 최신 공식 문서를 가져오는 데이터 소스다. 커버하는 출처는 네 군데다.

developer.android.com (Android 개발자 공식 문서)
Firebase
Google Developers
Kotlin 공식 문서

LLM의 학습 컷오프가 1년 전이어도, Knowledge Base를 통해 어제 업데이트된 AGP 9 릴리스 노트를 그대로 읽을 수 있다. RAG를 따로 구축하지 않아도 에이전트가 내부적으로 이 채널을 쓰게 된다는 뜻이다. 이건 그동안 "에이전트가 구버전 API를 자신 있게 제안하는 문제"를 가장 정공으로 때린 방식이다.

Android Studio는 여전히 집이다

발표문은 CLI와 Skills를 자랑하면서도 마지막에 꼭 한 번 Studio를 강조한다. "프로토타입을 CLI로 빠르게 만들고, 본격 UI 조정은 Studio에서 시각적 도구로." 이 말은 예쁘지만, 솔직히 내가 읽기엔 "Studio를 떠나지 말라"는 부드러운 리마인더에 가깝다.

그래도 이 흐름 자체는 합리적이다. CLI에서 뽑은 프로젝트를 그대로 Studio에서 열면 디버깅, 프로파일링, 레이아웃 인스펙터 같은 묵직한 도구들이 준비돼 있다. 특히 Studio 안의 Agent Mode는 AGENTS.md라는 프로젝트 설정 파일을 읽고, adb shell input까지 써서 실제 앱을 조작하며 테스트한다. CLI는 초입, Studio는 본진. 이 분업 자체는 이치에 맞는다.

내 생각, 편해졌다기보단 '해석이 필요 없어졌다'

이번 발표를 일부 블로그는 "3배 빠른 Android 개발"이라고 요약하는데, 나는 숫자보단 표현 방식의 변화가 훨씬 중요하다고 본다.

지난 10년 동안 Android CLI 생태는 사람 대상이었다. StackOverflow 답변에 sdkmanager "platforms;android-34" "build-tools;34.0.0" 이런 문자열이 박혀 있었고, 사람은 그걸 복붙해서 어찌어찌 동작시켰다. LLM은 이 문자열을 "학습"은 하지만 정작 잘 못 쓴다. 오타도 내고, 버전 번호도 틀리고, 따옴표도 놓친다.

android create는 다르다. 에이전트에게 이건 해석이 거의 필요 없는 인터페이스다. 그만큼 추론 단계가 줄고, 토큰이 줄고, 실수가 줄어든다. Google이 말하는 70% 토큰 절감은 그 결과값이고, 3배 빨라진다는 건 그 부산물이다.

물론 프리뷰다. 실제로 얼마나 잘 도는지는 써 봐야 안다. 그리고 android create가 뽑아 주는 기본 템플릿이 Jetpack Compose 쪽으로만 편향돼 있지 않을지, KMP나 Compose Multiplatform 프로젝트는 어떻게 다룰지, 이런 건 아직 문서에서도 잘 안 보인다. 이번 주말에 d.android.com/tools/agents에서 프리뷰를 받아다가 Claude Code에 붙여서 돌려 볼 생각이다. 결과가 나오면 후속 글로 정리해 보려고 한다.

지금 분명한 건 하나다. "에이전트가 내 Android 프로젝트를 어떻게 시작해 줄 건데?"라는 질문의 답이, 2026년 4월 16일 이전과 이후로 갈린다는 것.