애플 맥에서 안드로이드 앱을 에뮬레이터 없이 돌리는 오픈소스 Mac.apk, 받아서 직접 살펴봤다

무엇인가

Mac.apk는 Apple Silicon 맥(인텔 맥은 안 됨)에서 안드로이드 앱을 가상머신 없이 실행하는 프로그램입니다. 에뮬레이터는 CPU를 가상화하지만, 이 프로그램은 앱 코드를 호스트 CPU가 이해하는 코드로 바꿔 그대로 실행합니다(README 표현: "no virtualization").

APK 안에는 크게 두 가지가 들어 있습니다.

• Java 코드 → 내장 OpenJDK(JRE)로 실행
• 네이티브 코드(.so) → arm64는 로더로 그대로 실행, ARM32는 실행 시점에 ARM64로 변환

ARM32 변환이 이 프로젝트의 기술 핵심입니다. 변환된 코드가 다시 원래 코드로 되돌아가지 않도록(리컴파일 방지) 변환된 이미지를 마운트된 디스크에 저장해 두고, 그 이미지에서 직접 실행합니다. 렌더링은 ANGLE/MoltenVK(게임 GPU 가속용)를, 화면 출력은 CoreVideo를 씁니다.

기본 정보는 다음과 같습니다. v1.0.2303 · Alpha · Apple Silicon 전용 · macOS 26.4 이상 · AGPL-3.0(상용 라이선스 병행) · 설치 약 280MB · 설치된 앱당 1.5~3배 디스크.

직접 해 본 것

먼저 밝혀 둡니다. 저는 이 저장소를 설치하지도, 빌드하지도, 인터넷에서 뭔가를 받아오지도 않았습니다. GitHub에서 받은 소스를 읽고, 이 프로젝트가 ARM32 코드를 ARM64로 바꾸는 방식이 실제로 되는지 인터넷 없이 재현 실험만 했습니다. 실제 apk 실행까지 못 한 이유는 이렇습니다.

이 프로젝트는 macOS 26.4 이상만 지원합니다. 제 맥은 macOS 27.0.1이라 조건은 맞습니다. 다만 이번 시험은 설치하지 않고 코드를 받아 살펴보는 방식이라 실제 앱은 실행하지 않았고, "변환이 실제로 되는가"라는 핵심 아이디어만 로컬에서 재현했습니다.

재현은 이렇게 했습니다. 먼저 실제 앱에 들어가는 것과 같은 ARM32(32비트 ARM, 리틀엔디안) .so 형태의 테스트 코드를 만들었습니다. "ELF"는 리눅스·안드로이드에서 쓰는 실행 파일 포맷이고, .so는 그중 공유 라이브러리(앱의 네이티브 코드)를 뜻합니다.

# ARM32(32비트 ARM, 리틀엔디안) 테스트 코드 컴파일
clang -target armv7-linux-gnueabihf -O1 -fPIC -marm -nostdlib -c hello.c -o hello.o
llvm-objcopy -O elf32-littlearm --strip-all hello.o hello.so
file hello.so
# => ELF 32-bit LSB relocatable, ARM, version 1

이 hello.so는 실제 앱에서 lib/arm32/...로 들어가는 파일과 같은 모양입니다. 다음으로 이 프로젝트의 C++ 변환기 소스를 읽으면서 ARM 명령어를 ARM64 명령어에 어떤 규칙으로 대응시키는지 확인했습니다.

grep -rn 'armv7' repo/runtime/translator/src/arm32rc/xlat_core.cpp

핵심은 조건 분기는 동등한 조건 분기(Bcond → CBZ/CBNZ)로 변환하고, 즉시수는 리터럴 풀 + adr/add로, 레지스터는 W↔X 레지스터 에일리어스로 처리한다는 점입니다. 이 규칙을 그대로 따라 ARM32를 ARM64로 변환하는 스크립트를 직접 써서 실행했습니다.

python3 xlat_repro.py out/hello.so out/main64.s

변환된 ARM64 어셈블리는 실제 ARM64 하네스와 링크해 실행까지 해 봤습니다.

$ (arm64로 컴파일·링크·실행)
add(2,3)=5
max2(7,3)=7   max2(-5,-1)=-1
sum_to(10)=55   sum_to(0)=0
abs_diff(3,7)=4   abs_diff(-2,5)=7
nested(-1)=-1  (0)=0  (5)=1  (50)=2  (500)=3
→ 전부 PASS

성공했습니다. 제가 재현한 파이프라인은 ARM32 코드를 ARM64로 변환했고, 변환된 코드를 ARM64 CPU에서 실행하자 맞는 답이 나왔습니다. 이 프로젝트의 핵심 아이디어인 "ARM32를 ARM64로 변환"이 실제로 작동한다는 것을 확인한 셈입니다. 다만 이 결과는 제 재현 스크립트가 낸 것이고, Mac.apk 바이너리 자체를 실행한 것은 아니라는 점을 분명히 해 둡니다.

하지 못한 것도 적어 둡니다.

• 실제 .apk 파일을 Mac.apk로 실행: 아직 안 함(이번 시험은 설치하지 않는 방식이라 실행하지 않음 — macOS 버전 조건은 충족)
• 저장소 빌드: 못 함(빌드 도구와 의존성이 제 맥에 없고, 설치 금지)
• 이 프로젝트 바이너리 자체 실행: 못 함(설치·의존성 제한)
• C++ 변환기 소스 전체 정적 분석: 일부만(핵심 변환 규칙만 확인)

이 맥에서 쓸 수 있나

제 환경은 Apple M5 Max(Mac Studio) · 48GB RAM · 외장 4TB 디스크이고, 로컬 AI 모델 서버가 RAM을 약 34GB 상시 사용합니다. 이를 기준으로 정리했습니다.

결론부터 말하면 사양으로는 제 맥에서 쓸 수 있습니다. macOS 27.0.1이라 26.4 이상 조건을 넘고, CPU·RAM·저장공간도 여유가 있습니다. 다만 이번에는 설치하지 않고 살펴본 것이라, 실제로 안드로이드 앱이 잘 도는지는 아직 확인하지 못했습니다.

한 가지 더 있습니다. 이 프로젝트는 Apple Silicon 전용이라, 인텔(Intel) 맥은 macOS 버전이 아무리 높아도 대상이 아닙니다.

이런 분께

맞아요

• 애플 실리콘 Mac + macOS 26.4 이상을 쓰면서 안드로이드 앱·게임을 가상머신 없이 돌려 보고 싶은 분
• ARM32 → ARM64 동적 변환이 코드 수준에서 어떻게 돌아가는지 궁금한 분(이 글의 재현 실험이 참고가 됩니다)
• 안드로이드 앱 자동화를 맥에서 하려는 분(이 프로젝트는 앱 자동화용 adb를 내장하고 있습니다)

안 맞아요

• 인텔(Intel) 맥 사용자(Apple Silicon 전용이라 인텔은 아예 안 됩니다)
• macOS 26.4 미만 사용자와 OS를 올리기 어려운 분(현재 상태로는 쓸 수 없습니다)
• 안정성이 먼저인 분(Alpha이고, 프로젝트 스스로 "매우 빠른 개발 속도"를 밝히고 있습니다)
• 앱을 상업 제품 안에 넣으려는 분(AGPL-3.0이라 수정·배포 시 조건이 따릅니다. 상용 라이선스는 별도로 있습니다)

주의할 점

1. Alpha입니다. 프로젝트 스스로 "매우 빠른 개발 속도"를 알리고 있고, 공식적으로 macOS 26.4 이상 + Apple Silicon 전용입니다. 완성도와 안정성은 아직 검증 단계입니다.
2. 디스크를 꽤 씁니다. 설치에 약 280MB가 들고, 앱마다 1.5~3배 공간이 더 필요합니다.
3. 라이선스가 AGPL-3.0입니다. 개인 사용과 연구에는 문제가 없지만, 수정한 뒤 네트워크로 배포하면 AGPL 공개 의무가 생깁니다. 클로즈드소스 제품에 넣으려면 별도의 상용 라이선스(유료)가 필요합니다. 이름·로고 상표권도 따로 있습니다.
4. 변환이 실패하는 앱도 있습니다. 프로젝트도 "ARM32 변환이 실패하면 앱을 못 열 수 있다"고 인정합니다. 앱마다 열리는지가 갈립니다.
5. "실제 실행"과 "재현 실험"을 구분하세요. 이 글에서 ARM32→ARM64 변환이 성공한 것은 제 재현 스크립트의 결과입니다. Mac.apk 바이너리 자체는 이번에 실행하지 않았습니다(설치하지 않는 시험 방식). 그래서 앱이 실제로 도는지에 대한 결론은 아직 없습니다.

출처

• 저장소: https://github.com/kksimp/Mac.apk (v1.0.2303, AGPL-3.0 · 별 1,961 · 2026-05-19 생성)
• README·라이선스·요구사항: 위 저장소 README / LICENSE
• 확인 시각: 2026-10-22 04:20 (KST) — GitHub 웹페이지·라이브 API 확인
• 위 실험(ARM32→ARM64 재현)은 이 GitHub 저장소 소스를 참고해 작성·실행했고, 설치·빌드·외부 다운로드는 하지 않았습니다.