docker-android: KVM 가속 Android 에뮬레이터를 컨테이너로 패키징하고 MCP와 로컬 LLM 에이전트를 지원

개요

budtmo/docker-android는 Android와 관련된 모든 작업을 위한 Docker 이미지 모음입니다. 프로젝트는 스스로를 네이티브, 웹, 하이브리드 앱의 개발과 테스트에 쓰는 컨테이너라고 소개합니다. 컨테이너 하나에 기기 프로필을 고를 수 있는 Android 에뮬레이터, 브라우저로 화면을 볼 수 있는 VNC 서비스, 로그용 웹 화면, adb 접속 지점이 들어 있습니다. 실행에는 docker run 명령 한 줄이면 됩니다.

이미지 목록은 Android 9부터 14까지, 즉 API 수준 28에서 34를 다룹니다. 각 버전마다 최신 릴리스 태그와 특정 릴리스 태그가 있습니다. 별도 이미지도 둘 있습니다. genymotion 이미지는 Genymotion Cloud와 연결되고, mcp 이미지는 이번에 주목할 새 방향입니다. 기기로는 Samsung Galaxy S6부터 S10 계열, Nexus 4, Nexus 5, Nexus One, Nexus S, 태블릿 Nexus 7과 Pixel C 등을 고를 수 있습니다.

핵심 구조

구조는 세 층으로 볼 수 있습니다. 맨 아래는 호스트의 KVM입니다. 가운데는 컨테이너 안의 Android SDK와 에뮬레이터 프로세스로, 지정한 API 수준의 시스템 이미지와 기기 설정을 불러옵니다. 맨 위는 사용자용 접점입니다. noVNC 웹 데스크톱은 기본적으로 6080 포트에 연결되고, 로그 공유 웹 페이지와 호스트가 adb connect로 붙을 수 있는 디버그 포트가 있습니다.

접점이 하나로 모여 있다는 점이 장점입니다. 개발자는 브라우저에서 에뮬레이터를 직접 볼 수 있습니다. Appium이나 Espresso 같은 테스트 프레임워크는 adb나 서비스 포트로 기기를 조작합니다. 빌드, 단위 테스트, UI 테스트가 같은 이미지를 쓰므로 컴퓨터마다 SDK와 시스템 이미지, 의존성을 다시 설치할 필요가 없습니다.

동작 원리

Android 에뮬레이터는 QEMU를 기반으로 한 전체 기기 가상화입니다. 컨테이너 안에서 쓸 만한 속도를 얻으려면 x86 시스템 이미지가 KVM을 통해 CPU의 하드웨어 가상화 명령을 직접 써야 합니다. 컨테이너 자체는 가상화를 제공하지 않고 호스트 커널을 공유할 뿐입니다. 그래서 실행할 때 --device /dev/kvm으로 장치를 컨테이너에 넘기도록 요구합니다. 빠른 시작도 먼저 kvm-ok로 호스트가 가상화를 지원하는지 확인하게 합니다.

이것이 Ubuntu에서만 실행되는 이유이기도 합니다. README는 macOS와 Windows 사용자가 가상화를 지원하는 Ubuntu 가상 머신을 먼저 써야 한다고 밝힙니다. Windows 11의 WSL2에는 전용 절차가 있습니다. 사용자를 kvm 그룹에 추가하고, /etc/wsl.conf의 부팅 명령에서 /dev/kvm의 소유자와 권한을 바꾸고, .wslconfig에서 nestedVirtualization을 켭니다.

환경 변수가 실행 동작을 정합니다. EMULATOR_DEVICE는 기기 프로필을 고르고 WEB_VNC=true는 웹 데스크톱을 켭니다. 기본값에서는 컨테이너를 재시작하면 에뮬레이션된 기기가 파기됩니다. /home/androidusr에 볼륨을 마운트하면 앱과 설정이 남습니다. 기본은 일회용이고 필요할 때만 영구 보존한다는 설계는 지속적 통합이 요구하는 깨끗한 환경과 맞아떨어집니다.

MCP와 AI 에이전트

가장 최근의 변화는 MCP 서버와 AI 에이전트입니다. README는 둘 다 베타로 표시하고 도식도 싣고 있습니다. MCP는 AI 클라이언트가 외부 도구를 표준 방식으로 호출하게 하는 프로토콜입니다. Android 에뮬레이터를 MCP 서버로 감싸면 코딩 어시스턴트가 기기 시작, 화면 확인, 탭, 입력, 결과 읽기를 요청할 수 있습니다. 어시스턴트마다 따로 연결 코드를 짤 필요가 없습니다.

AI 에이전트 기능은 한 걸음 더 나아갑니다. README에 따르면 Ollama와 vLLM 두 가지 로컬 모델 서버를 지원합니다. 로컬 모델에는 분명한 의미가 있습니다. 스크린샷과 테스트 대상 앱의 데이터가 내부망 밖으로 나가지 않고, 호출 횟수에 따른 클라우드 API 요금도 없습니다. 대신 GPU 메모리와 추론 처리량이 필요하고, 작은 모델은 복잡한 화면을 판단하는 능력이 떨어집니다.

비용과 절충

README에는 시작 시간, 메모리 사용량, 테스트 처리량 같은 벤치마크 수치가 없으므로 성능 숫자를 인용하면 안 됩니다. 구조상 절충은 분명합니다. 첫째, 하드웨어 가속 덕분에 에뮬레이터를 쓸 수 있지만 컨테이너마다 메모리와 CPU를 상당히 차지하므로 병렬 규모는 호스트 자원에 묶입니다. 둘째, 이미지가 Android 버전별로 나뉘어 각각이 크기 때문에 내려받기와 캐시를 미리 계획해야 합니다. 셋째, 에뮬레이터는 실제 폰이 아닙니다. 센서, 제조사 맞춤 시스템, 하드웨어 의존 동작은 실기기나 클라우드 기기로 보완해야 합니다. 프로젝트가 Genymotion Cloud 연동을 제공하는 이유입니다.

개발자와 기업에 주는 영향

개인 개발자에게 가치는 일회용 환경입니다. 내 컴퓨터가 깨끗하게 유지되고 SDK 버전 충돌 걱정이 없습니다. 팀에서는 이미지 태그로 버전을 고정해 로컬, 지속적 통합, 클라우드가 같은 환경을 쓰게 할 수 있습니다. 내 컴퓨터에서는 되는데 하는 논쟁이 줄어듭니다. 프로젝트는 Jenkins, Azure와 AWS와 GCP 클라우드 배포, SMS 시뮬레이션, Appium 사용 문서도 제공합니다.

더 큰 의미는 AI 도구 체인에 있습니다. 지금까지는 AI 코딩 어시스턴트가 모바일 변경을 검증하려면 사람이 기기를 준비해야 했습니다. 에뮬레이터가 MCP 서비스로 나타나면 어시스턴트는 호출할 수 있는 실제 실행 환경을 얻어 코드 수정, 빌드, 실행, 관찰, 재수정의 순환을 닫을 수 있습니다.

한계와 전망

주요 한계는 네 가지입니다. 첫째, KVM이 필수라서 중첩 가상화가 없는 일반 클라우드 호스트나 Apple 실리콘의 컨테이너 환경에서는 바로 실행되지 않습니다. 둘째, MCP와 에이전트는 아직 베타라 인터페이스와 동작이 바뀔 수 있고, 모델의 비결정성 때문에 당분간 유일한 회귀 판정 기준으로는 맞지 않습니다. 셋째, 기기 목록이 오래된 프로필 중심이라 최신 화면 규격은 직접 설정해야 합니다. 넷째, 에뮬레이터는 실제 폰을 완전히 대신하지 못합니다.

앞으로는 지원하는 Android 버전과 기기의 확대, 더 안정적인 MCP 도구 정의, 멀티모달 로컬 모델 지원 강화, 클라우드 기기 팜과의 연계가 기대됩니다. 모바일 자동화를 검토하는 팀은 먼저 빌드와 일반 UI 테스트에 쓰고, AI 에이전트는 분리된 환경에서 시험하며, 결정적인 검증은 기존 스크립트에 남겨 두는 것이 현실적입니다.