MCP가 AI 에이전트에게 도구를 연결하고 Skill이 작업 기준을 알려준다면, Android Agent는 특정 역할을 맡아 실제 작업을 수행하는 전문가에 가깝습니다. Android 앱 개발에서는 모든 일을 하나의 AI에게 맡기기보다, 설계·Compose·장애 분석·테스트처럼 판단 기준이 다른 작업을 전문 Agent에게 나누어 맡기는 편이 더 잘 맞을 때가 많습니다.
앞선 글에서 MCP와 Skill을 살펴봤습니다. 이번에는 그 위에서 실제로 추가해 사용할 수 있는 Agent를 이야기해 보겠습니다. 사용자가 직접 Agent를 작성해도 되지만, 이미 누군가가 많은 시행착오를 거쳐 역할과 출력 형식을 정리해 공개한 Agent를 가져와 사용하는 방법도 있습니다. 좋은 Agent를 고르는 일은 반복해서 입력할 프롬프트를 줄이고, 결과를 검토하는 기준을 일정하게 만드는 데 도움이 됩니다.
먼저 Android 앱 개발 MCP 글에서 도구 연결 방식을 확인하고, Android Agent Skills 글에서 작업 지침과 추천 조합을 살펴보면 이번 글의 차이를 더 쉽게 이해할 수 있습니다.
Android Agent와 MCP·Skill은 무엇이 다른가
세 가지는 함께 사용되는 경우가 많아서 처음 보면 비슷해 보입니다. 하지만 책임 범위는 다릅니다. 저는 다음처럼 구분하면 이해하기 쉽다고 봅니다.
| 구분 | 하는 일 | Android 예시 | 비유 |
|---|---|---|---|
| MCP | AI가 외부 도구와 데이터에 접근하도록 연결합니다. | 에뮬레이터 조작, 공식 문서 검색, 빌드·스토어 작업, 파일 시스템 접근 | 도구가 놓인 작업대 |
| Skill | 특정 작업의 규칙, 절차, 품질 기준을 제공합니다. | Material 3 적용, Compose 상태 관리, Edge-to-Edge, 테스트 작성 규칙 | 작업 매뉴얼 |
| Agent | 특정 역할을 맡아 문제를 분석하고 계획하거나 코드를 작성·검토합니다. | Android 아키텍트, Compose UI 리뷰어, ANR 조사관, Navigation 설계자 | 전문 담당자 |
예를 들어 “Compose 화면을 만들고 에뮬레이터에서 확인해줘”라는 요청을 생각해 보겠습니다. Compose Skill은 상태 호이스팅과 Material 3 규칙을 참고하게 하고, Compose Screen Builder Agent는 화면 구조와 코드를 만들며, Mobile MCP는 실제 에뮬레이터를 조작합니다. 한 문장으로 이어져 보여도 안에서는 세 가지가 서로 다른 역할을 담당합니다.
또한 Agent는 반드시 별도의 AI 모델이어야 하는 것은 아닙니다. 보통은 역할, 입력 형식, 판단 기준, 출력 형식을 담은 Markdown 정의 파일입니다. Claude Code의 Agent, Codex의 Agent, Cursor의 서브에이전트처럼 도구마다 설치 위치와 호출 방식은 다를 수 있지만, 특정 역할을 독립된 문맥으로 실행한다는 방향은 비슷합니다.
Android Agent 추천 10가지
아래 목록은 공개 저장소인 Mobile AI Agents에서 Android 작업에 직접 연결되는 Agent를 중심으로 골랐습니다. 이 저장소는 Android 전용 Agent뿐 아니라 Claude Code, Cursor, Codex 등 여러 도구를 대상으로 설치할 수 있는 CLI와 워크플로도 함께 제공합니다. 저장소의 Agent 파일을 그대로 복사해 사용하는 방법도 있고, 제공되는 설치 명령을 사용하는 방법도 있습니다.
| 순위 | Agent | 주요 용도 | 추천 이유 |
|---|---|---|---|
| 1 | MOBILE-HARNESS | 기획부터 구현, 테스트, 출시까지 | PRD, 설계, 작업 분해, 구현, 코드 리뷰, UI 검증, 디바이스 QA, 릴리즈 준비를 하나의 흐름으로 연결합니다. Android 프로젝트의 기본 Agent로 고려할 만합니다. |
| 2 | AXIOM | Android 아키텍처와 Kotlin/Compose 리뷰 | Clean Architecture 위반, God ViewModel, Coroutine Scope 누수, Compose 안티패턴, 테스트 누락을 심각도와 수정안으로 정리합니다. |
| 3 | Compose Screen Builder | Compose 화면 생성 | 화면 설명을 입력하면 Composable, UiState, Hilt ViewModel, Navigation 연결, Preview까지 포함한 화면 초안을 만들도록 설계되어 있습니다. |
| 4 | NAVIGATOR | Compose Navigation 설계 | 타입 안전 라우트, 중첩 그래프, Bottom Navigation, 딥링크, 인증 게이트, 백스택 동작을 함께 검토합니다. |
| 5 | Compose UI Reviewer | Compose UI 품질과 재구성 리뷰 | 상태 호이스팅, LazyColumn 성능, Side Effect 위치, remember, derivedStateOf, 컴포넌트 API 설계를 Compose 관점에서 집중 점검합니다. |
| 6 | Android Code Reviewer | 일반 Kotlin/Android 코드 리뷰 | 파일 단위로 계층 구조, Kotlin 안티패턴, Coroutine, Compose, 테스트 신호를 확인합니다. AXIOM과 겹치는 부분이 있으므로 둘을 항상 함께 켤 필요는 없습니다. |
| 7 | CRASHER | Crashlytics와 스택 트레이스 분석 | NullPointerException, Lifecycle 오류, Coroutine 예외, RecyclerView 오류, 메모리 문제의 원인을 설명하고 수정안과 테스트 목록을 제시합니다. |
| 8 | Android Crash Analyzer | Crash, ANR, LeakCanary 종합 분석 | Crashlytics export, ANR trace, LeakCanary report처럼 운영 중 수집된 자료를 입력으로 받아 원인, 수정 전후 코드, 재발 방지 점검까지 정리합니다. CRASHER와 용도가 가까우므로 둘 중 하나만 선택하는 편이 좋습니다. |
| 9 | FREEZE | ANR와 메인 스레드 정지 조사 | Play Console 또는 Crashlytics의 ANR, thread dump, ApplicationExitInfo를 분석해 어떤 스레드가 무엇을 막고 있는지 추적합니다. |
| 10 | RETAINER | 메모리 누수와 Lifecycle 분석 | LeakCanary trace와 heap retention 자료를 기준으로 객체를 붙잡고 있는 참조, 잘못된 생명주기, 검증 방법을 분석합니다. |
장애 분석 Agent가 여러 개 있는 이유는 이름만 다르게 붙인 것이 아닙니다. 일반적인 스택 트레이스 설명이 필요하면 CRASHER가 빠르고, 운영 자료를 종합해 보고 싶으면 Android Crash Analyzer가 더 적합합니다. ANR만 따로 조사할 때는 FREEZE를, 메모리 누수만 확인할 때는 RETAINER를 호출하는 식으로 문제의 형태에 맞춰 고르면 됩니다.
Android Agent 설치와 관리 방법
Skill을 설치할 때와 마찬가지로 사용자가 저장소의 모든 경로를 기억할 필요는 없습니다. 현재 사용 중인 도구와 Android 프로젝트의 목적을 함께 설명하면 AI가 적합한 Agent를 찾고 설치 방법을 제안하게 할 수 있습니다.
내 Android 프로젝트에 필요한 Agent를 추천하고,
현재 사용 중인 에이전트 도구에 설치해줘.공개 저장소의 설치 도구를 직접 사용하는 경우에는 다음처럼 플랫폼과 도구를 지정할 수 있습니다.
npx mobile-ai-agents install --platform android --tool codexClaude Code라면 --tool claude, Cursor라면 --tool cursor처럼 대상 도구를 바꾸고, 여러 지원 도구에 한 번에 설치하려면 저장소의 --tool all 옵션을 확인하면 됩니다. 다만 설치 명령이 모든 환경에서 같은 방식으로 동작하는 것은 아닙니다. AI에게 먼저 현재 도구의 Agent 디렉터리, 설치 스크립트, 필요한 권한, 기존 Agent와의 중복 여부를 확인하게 하는 것이 좋습니다.
직접 Agent를 추가하는 방법도 간단합니다. 공개 저장소의 agent.md를 검토한 뒤 현재 도구가 읽는 Agent 디렉터리에 복사하고, 호출 이름과 사용 조건을 CLAUDE.md 또는 AGENT.md에 적어 두면 됩니다. 단, 외부 저장소의 Markdown이나 설치 스크립트가 무조건 안전하다고 가정하면 안 됩니다. 파일 내용을 먼저 읽고, 쉘 명령·권한 요청·네트워크 호출·비밀값 처리 방식을 확인해야 합니다.
Android Agent를 너무 많이 설치하면 생기는 일
Agent도 MCP와 Skill처럼 많이 설치한다고 결과가 좋아지는 것은 아닙니다. 서로 비슷한 역할의 Agent가 동시에 활성화되면 어떤 기준을 우선해야 하는지 모호해지고, 같은 파일을 여러 관점에서 반복해서 분석할 수 있습니다. Agent가 MCP와 Skill까지 호출하는 구조라면 의도하지 않은 추론과 입출력이 이어질 가능성도 커집니다.
그때는 토큰이 조금씩 녹는 것을 눈앞에서 보게 됩니다. 비용만의 문제가 아닙니다. 응답이 길어지고, 서로 다른 수정안이 섞이고, 실제로 필요한 변경보다 검토 보고서가 커질 수 있습니다. 그래서 저는 기본 Agent 하나와 현재 작업에 필요한 전문 Agent 하나 정도에서 시작하는 편을 권합니다.
작업별로 선택하는 예시
| 현재 작업 | 먼저 사용할 Agent | 추가 조건 |
|---|---|---|
| 새 Android 프로젝트 설계 | MOBILE-HARNESS 또는 AXIOM | 화면 흐름까지 필요하면 NAVIGATOR 추가 |
| Compose 화면 구현 | Compose Screen Builder | 완성 후 Compose UI Reviewer로 점검 |
| Navigation 구조 변경 | NAVIGATOR | 딥링크와 인증 게이트를 함께 검토 |
| 코드 품질 점검 | AXIOM 또는 Android Code Reviewer | 두 Agent를 동시에 켜기보다 하나를 선택 |
| 출시 후 크래시 분석 | CRASHER 또는 Android Crash Analyzer | ANR이면 FREEZE, 누수면 RETAINER 추가 |
Android Agent 선택 기준 정리
MCP는 AI가 사용할 도구를 연결하고, Skill은 작업 기준과 절차를 제공하며, Agent는 특정 역할을 맡아 분석·설계·구현·검토를 수행합니다. 세 가지를 함께 사용하면 강력하지만, 각각의 역할을 구분하지 않으면 비슷한 지침과 호출이 겹칠 수 있습니다.
Android 앱 개발에서는 처음부터 10개 Agent를 모두 설치할 필요가 없습니다. 전체 흐름을 관리할 기본 Agent를 하나 선택하고, 현재 작업에 맞춰 AXIOM, Compose Screen Builder, NAVIGATOR, CRASHER, FREEZE 같은 전문 Agent를 추가하면 됩니다. UI 작업이 끝나면 UI Reviewer를 호출하고, 장애가 생겼을 때만 Crash나 Memory Agent를 켜는 식으로 관리하면 됩니다.
좋은 Agent는 누군가가 이미 정리해 둔 고민과 경험을 가져다 쓸 수 있게 해 줍니다. 그렇다고 설치한 순간 모든 판단을 맡겨도 된다는 뜻은 아닙니다. Agent 정의 파일과 설치 명령을 먼저 감사하고, 현재 프로젝트의 Kotlin·Compose·Gradle 버전과 맞는지 확인한 뒤, 작은 작업에서 결과를 검증하면서 범위를 넓히는 것이 가장 현실적인 사용 방법입니다.
답글 남기기