2026년 4월 17일 | 개발 깨알 상식_Tips
Android Developers Blog에 Android CLI가 올라온 걸 보고, 내가 제일 먼저 메모한 건 android docs였다. 새 CLI가 나왔다는 사실 자체도 반가웠지만, 진짜 실전 포인트는 따로 있었다. 코딩 에이전트에게 Android 작업을 맡길 때 제일 자주 새는 지점이 보일러플레이트 생성이 아니라 낡은 문서 기억이기 때문이다. Compose, Navigation, edge-to-edge, 성능 최적화처럼 이름은 익숙한데 권장 패턴이 계속 바뀌는 영역에서는, 에이전트가 대충 아는 척하면서 예전 방식으로 밀어붙일 때가 제일 허무하다.
오늘 팁은 한 줄이다. Android 작업을 에이전트에게 넘길 때는 문서 링크만 채팅창에 던지기보다, android docs search와 android docs fetch로 최신 공식 가이드를 먼저 뽑아 컨텍스트로 붙이는 편이 낫다. 이 흐름이 좋은 이유는 단순하다. 브라우저 탭 여러 개를 더 열지 않아도 되고, 모델의 학습 시점이 조금 오래됐더라도 지금 Android 팀이 밀고 있는 권장 문장을 바로 근거로 붙일 수 있다. 나는 요즘 바이브 코딩 쪽에서 이런 차이가 꽤 크게 느껴진다.
Figure 1. 이번 발표의 핵심은 CLI 하나가 늘었다는 것보다, 에이전트가 공식 Android 기술 자료에 바로 닿는 표면이 생겼다는 점이었다.
1. 내가 먼저 본 건 create보다 docs였다
공식 글은 Android CLI를 agent-first workflow용 진입점으로 설명한다. android create, android run, android emulator, android update 같은 명령도 물론 유용하다. 그런데 나는 그중에서도 android docs가 제일 실무적이라고 봤다. 새 프로젝트를 한 번 만드는 일보다, 이미 있는 프로젝트에서 "이제 edge-to-edge를 어떻게 잡지?", "Navigation 3로 옮길 때 현재 권장 패턴이 뭐지?", "R8 점검 포인트가 어디지?" 같은 질문이 훨씬 자주 나오기 때문이다.
- 브라우저 링크만 붙이는 방식: 문서를 직접 읽기 전까지는 에이전트가 링크 제목만 보고 대충 진행해 버릴 수 있다.
- 학습 기억만 믿는 방식: 예전 Compose / XML, 예전 Navigation 관성을 그대로 끌고 오기 쉽다.
android docs를 쓰는 방식: 검색 결과를kb://...주소로 받고, 그 문서를 터미널 출력으로 바로 붙일 수 있다.
이 차이가 은근히 크다. 에이전트는 링크 자체보다 이미 펼쳐진 텍스트를 훨씬 잘 쓴다. 그러니까 최신 Android 가이드를 줄 거면, "이 링크 읽고 해줘"보다 지금 필요한 문단을 직접 fetch해서 프롬프트에 같이 넘기는 쪽이 안정적이다. 오늘 Android CLI 발표를 보며 내가 제일 먼저 건진 포인트가 바로 이거였다.
2. 최소 준비는 세 줄이면 된다
공식 문서를 보면 시작도 복잡하지 않다. 이미 설치돼 있는지 확인하고, 최신 버전으로 올리고, 에이전트용 skill까지 한 번 붙이면 된다. 여기서 중요한 건 CLI를 설치하는 것과 에이전트가 그 CLI를 이해하게 만드는 것을 나눠 보는 감각이다. 후자 쪽에 해당하는 명령이 android init다.
command -v android
android update
android init공식 문서에도 command -v android로 설치 여부를 확인하라고 적혀 있고, android update는 새 기능 반영용으로 자주 돌리라고 돼 있다. android init는 android-cli skill을 설치해서 에이전트가 이 도구를 더 자연스럽게 쓰게 만드는 단계다. 나는 이런 도구를 볼 때 설치 자체보다 도구 사용법을 모델 쪽에 어떻게 붙여 두는가를 먼저 보는 편인데, 이번 공개는 그 부분이 꽤 선명했다.
Figure 2. 내가 오늘 바로 메모해 둔 루프는 질문 → android docs search → kb:// 선택 → android docs fetch → 에이전트 프롬프트였다.
3. 실전에서는 kb:// 주소를 먼저 뽑아 두면 편하다
공식 Android CLI 문서를 보면 android docs는 두 단계다. 먼저 android docs search <query>로 관련 문서를 찾고, 거기서 나온 kb://... 주소를 android docs fetch <kb-url>에 넣어 실제 문서를 꺼낸다. 이 설계가 좋은 이유는 검색과 본문 출력을 분리해 둬서, 에이전트에게 지금 필요한 문서만 좁혀 주기 쉽다는 점이다.
android docs search 'How do I improve my app performance?'
android docs fetch kb://android/topic/performance/overview내가 실제로는 이런 식으로 쓸 것 같다. 예를 들어 edge-to-edge나 R8, Navigation 3 같은 작업이 나오면, 먼저 search로 후보를 보고 가장 맞는 kb:// 하나를 고른다. 그다음 fetch 결과를 파일로 떨군 뒤, 에이전트에게 "이 문서 기준으로 수정해 달라"고 넘긴다. 이렇게 하면 에이전트가 예전 블로그 글이나 오래된 Stack Overflow 습관으로 새는 일을 꽤 줄일 수 있다.
android docs search 'Make app edge to edge'
android docs fetch kb://android/topic/ui/edge-to-edge > docs/android-kb-edge-to-edge.md
# 그다음 에이전트 프롬프트 예시
# "docs/android-kb-edge-to-edge.md 기준으로 현재 Activity와 Theme 설정을 정리해 줘"핵심은 링크를 주는 게 아니라 근거 텍스트를 바로 붙이는 것이다. 나는 이 차이가 생각보다 크다고 본다. 링크는 에이전트가 나중에 읽을 수도 있는 참고 자료고, fetch 결과는 지금 판단에 바로 들어가는 재료다.
4. skills는 반복 작업용, docs는 최신 근거용으로 나누면 깔끔하다
이번 공개에서 같이 나온 Android skills도 재미있었다. 공식 Android skills 페이지를 보면 XML에서 Compose로 옮기기, AGP 9 업그레이드, Navigation 3 설정, edge-to-edge 적용, R8 점검 같은 주제가 이미 skill 형태로 정리돼 있다. CLI에서도 android skills list와 android skills add --skill ...로 다룰 수 있다.
android skills list
android skills add --skill skill-name나는 여기서 역할을 이렇게 나누는 편이 제일 덜 헷갈린다. 반복 워크플로와 체크리스트는 skill에 맡기고, 지금 시점의 공식 문장과 최신 권장안은 docs fetch로 붙인다. skill만 쓰면 최신 근거가 약해질 수 있고, docs만 쓰면 매번 같은 작업 절차를 다시 설명하게 된다. 둘을 같이 놓으면 에이전트가 훨씬 덜 흔들린다.
5. 오늘 바로 써먹을 때 주의한 점
공식 CLI 문서를 읽다 보니 주의점도 몇 개 보였다. 이런 건 짧아 보여도 실제로는 꽤 중요하다.
- 문서를 너무 크게 붙이지 않기: fetch 결과를 통째로 던지기보다, 지금 바꾸려는 주제와 직접 맞닿은 KB만 고르는 편이 좋다.
- skills와 docs를 섞어 보기: 절차는 skill, 최신성은 docs라는 분리를 잡아 두면 프롬프트가 훨씬 얇아진다.
- Windows 제한 확인: 공식 문서에는 현재
android emulator명령이 Windows에서 비활성화돼 있다고 적혀 있다. 환경 차이를 미리 알아두는 편이 낫다. - SDK 경로가 여러 개면
--sdk로 명시: 문서에도 기본 SDK를 잠깐 덮어쓰는 패턴이 따로 설명돼 있다.
나는 이런 도구가 나왔을 때 무조건 "에이전트가 더 똑똑해졌다"로 읽기보다, 낡은 관성을 줄일 수 있는 새 입구가 생겼다고 보는 편이다. Android CLI의 재미도 거기에 있다. create나 run도 좋지만, 오늘 내 눈에는 docs가 제일 손에 잡혔다.
6. 오늘의 한 줄
오늘 내가 건진 건 Android CLI 전체가 아니라 android docs search/fetch를 먼저 태우는 습관이었다. Android 작업을 에이전트에게 맡길 때는 링크만 던지지 말고, kb:// 결과를 fetch해서 최신 공식 문장을 바로 붙이는 쪽이 훨씬 덜 흔들린다. 원문은 Android Developers Blog 발표 글, Android CLI 문서, Android skills 개요, Android skills 목록을 같이 보면 더 잘 잡힌다.