Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

들어가며 — "공식 SDK"와 "공식 지원 플랫폼"은 다른 말이다
타임라인 — 나이틀리에서 정식 릴리스까지
Swift는 Android에서 어떻게 도는가
세 조각을 설치한다 — 툴체인, SDK, NDK
- 크기 이야기 — 정직하게 읽기
비전 문서가 명시한 non-goal — UI는 안 준다
아직 덜 된 것들
그렇다고 실험실 장난감은 아니다
그래서, 당신은 써야 하나
마치며
참고 자료

들어가며 — "공식 SDK"와 "공식 지원 플랫폼"은 다른 말이다

2026년 3월 24일 Swift 6.3이 릴리스됐습니다. 릴리스 노트가 내세운 항목은 네 가지입니다 — 더 유연한 C 상호운용(@c 어트리뷰트), 크로스플랫폼 빌드 도구 개선(SwiftPM에 Swift Build 통합 프리뷰), 임베디드 환경 개선, 그리고 Swift SDK for Android의 첫 공식 릴리스.

마지막 항목이 이 글의 주제입니다. 그런데 이 문장은 오해되기 쉽습니다. 이 블로그의 모던 Swift 2026 정리 편만 해도 "실험적 toolchain이 배포되어 hello world 수준은 잘 도는 상태", "2027년쯤이면 Kotlin Multiplatform과 경쟁할 수 있는 옵션이 될 가능성"이라고 적어 뒀는데, 그 글이 올라온 5월에는 이미 공식 SDK가 나온 뒤였습니다. 반대 방향의 오해도 똑같이 흔합니다 — "이제 Swift로 Android 앱 짜면 되는구나".

정확한 상태는 그 사이 어딘가입니다. 그리고 그 위치를 1차 소스로 짚어 보면, 꽤 명확한 그림이 나옵니다.

타임라인 — 나이틀리에서 정식 릴리스까지

날짜가 붙은 사실만 늘어놓으면 이렇습니다.

2025-06-02 — Swift Package Index가 Android·Wasm 호환성 테스트를 추가합니다. 당시 측정으로 약 9,000개 인덱스 패키지 중 27.9%가 Android로 빌드됐고, Wasm은 18.9%였습니다 (SPI 블로그). 공식 SDK보다 열 달 앞선 숫자이고, 당시 커뮤니티 툴체인 기준이라는 점을 감안해서 읽어야 합니다. 이후 갱신된 수치는 공개된 게 없습니다.
2025-08-27 — Android 비전 문서 PR(swift-evolution #2946)이 열립니다.
2025-10-24 — swift.org가 Swift SDK for Android의 나이틀리 프리뷰를 발표합니다.
2025-12-18 — 워크그룹이 SDK를 설명하는 후속 글을 올리고, Swift 6.3 SDK 나이틀리 CI가 가동됩니다.
2026-01-06 — Android 에뮬레이터에서 테스트를 돌리는 CI 워크플로가 병합됩니다(swiftlang/github-workflows #215).
2026-03-24 — Swift 6.3 릴리스. Swift SDK for Android 첫 공식 릴리스 포함. (GitHub의 swift-6.3-RELEASE 태그는 3월 27일 게시.)

릴리스 노트의 감사 문단이 이 흐름을 요약합니다 — Android 워크그룹의 수개월에 걸친 노력이 "나이틀리 프리뷰에서 Swift 6.3의 공식 릴리스로" SDK를 옮겨 왔다는 것. 그 앞에는 2015년 소스 공개 직후부터 시작된 10년치 커뮤니티 작업이 깔려 있습니다.

Swift는 Android에서 어떻게 도는가

여기가 제일 자주 오해되는 지점이라 워크그룹의 설명을 그대로 옮깁니다.

Swift는 Android에서도 다른 대부분의 플랫폼과 똑같이 네이티브 기계어로 직접 컴파일됩니다. NDK로 빌드한 C/C++ 코드와 비슷한 성능을 내되, 성능·안전성·사용성 사이에서 더 나은 균형을 잡는다는 게 워크그룹의 설명입니다. 이걸 가능하게 하려고 Android의 Swift 앱은 네이티브 런타임을 함께 번들합니다 — 표준 라이브러리와 Dispatch, Foundation 같은 코어 라이브러리가 여기 들어갑니다.

그런데 대부분의 Android API는 Java와 Kotlin으로만 노출돼 있습니다. 그래서 Swift는 Android 런타임(ART)을 호출해야 하고, 그 통로가 JNI입니다. 이걸 사람이 직접 쓰지 않게 해 주는 게 swift-java 프로젝트의 jextract와 wrap-java 도구입니다. 양방향 바인딩을 자동 생성해 주고, 더 낮은 수준이 필요하면 Swift Java JNI Core를 직접 씁니다.

정리하면 이 그림입니다.

Swift 소스
  --(swiftc + Swift SDK for Android + NDK)--> 아키텍처별 네이티브 .so
                                              (Swift 런타임/stdlib/Foundation 번들)
  APK의 lib/<arch>/ 에 실림
       ^
       | JNI (swift-java: jextract / wrap-java 가 바인딩 생성)
       v
Kotlin/Java 앱 코드  --(Android SDK)--> Activity, View, Compose ...

즉 Swift는 Android에서 Kotlin의 대체재가 아니라 NDK 자리의 대체재에 가깝습니다. C++로 짜던 로직 레이어를 Swift로 짜고, 나머지는 여전히 Kotlin/Java가 붙듭니다.

세 조각을 설치한다 — 툴체인, SDK, NDK

공식 시작 가이드가 요구하는 건 크로스컴파일 구성 세 조각입니다. 호스트(macOS·Linux)에서 빌드해 타깃(Android)에서 돌리는 구조라서요.

Swift 툴체인 — 호스트용 컴파일러. Xcode에 딸린 swift로는 안 되고, 오픈소스 툴체인이어야 하며 SDK 버전과 정확히 일치해야 합니다. swiftly로 관리하는 걸 권장합니다.
Swift SDK for Android — swift sdk install <URL> --checksum <체크섬> 으로 설치하는 artifact bundle.
Android NDK — LTS r27d 이상. SDK 번들 디렉터리에서 ./scripts/setup-android-sdk.sh 를 돌려 엮습니다.

빌드는 SDK 트리플을 지정해서 합니다.

$ swift build --swift-sdk aarch64-unknown-linux-android28 --static-swift-stdlib
$ swift build --swift-sdk x86_64-unknown-linux-android28 --static-swift-stdlib

트리플 끝의 28이 중요합니다. 플랫폼 지원 페이지의 최소 배포 버전 표에도 Android가 9 (API 28) 로 올라 있습니다. 즉 Android 9 미만은 대상이 아닙니다. API 레벨 분기는 Apple 플랫폼과 같은 문법으로 합니다.

@available(Android 33, *)
func backtrace() { /* ... */ }

if #available(Android 33, *) {
    // Android 33+ 에서만 실행
    backtrace()
}

실행 파일을 만든 다음에는 adb push 로 밀어 넣고 돌립니다. 다만 Android 앱은 보통 실행 파일로 배포되지 않으니, 실전에서는 Swift 모듈을 아키텍처별 공유 라이브러리로 빌드해 APK의 lib/<arch> 에 넣고 JNI로 부릅니다.

크기 이야기 — 정직하게 읽기

가이드의 hello world 예제 출력에 숫자가 하나 찍혀 있습니다. adb push 가 보고한 바이너리 크기는 69,559,568 바이트(약 66.3 MiB) 입니다. 여기에 NDK의 libc++_shared.so(1,794,776 바이트, 약 1.71 MiB)도 함께 밀어야 합니다.

이 숫자를 오해하지 마세요. 조건이 전부 붙어 있습니다 — 디버그 빌드, --static-swift-stdlib, 그리고 가이드 자신이 file 출력에 적어 둔 대로 with debug_info, not stripped 상태입니다. 릴리스 빌드에 스트립까지 하면 자릿수가 달라집니다. swift.org는 스트립된 릴리스 기준 수치나 실제 APK 증가분을 공개하지 않으므로, 여기서 그 숫자를 지어내지는 않겠습니다.

그래도 이 출력이 말해 주는 사실은 하나 분명합니다 — Swift 런타임은 빌려 쓰는 게 아니라 앱이 싸서 들고 간다는 것. Kotlin이 이미 ART 위에 있는 것과 근본적으로 다른 지점이고, APK 크기 예산이 빠듯한 팀이라면 직접 재 봐야 할 항목입니다.

비전 문서가 명시한 non-goal — UI는 안 준다

Android 워크그룹의 비전 문서 초안에는 "Non-goals" 절이 따로 있습니다. 이런 문서에서 제일 정직한 부분이 대개 여기입니다.

전체 SwiftUI/UIKit 이식 — 목표가 아닙니다. 문서 표현으로는, 공식 Swift on Android 노력은 "언어와 코어 라이브러리 지원에 집중하고, 우리만의 크로스플랫폼 UI 프레임워크를 만들지는 않는다".
JVM 바이트코드 컴파일 — 당면 목표가 아닙니다. Swift의 컴파일 모델은 네이티브 기계어를 대상으로 하고, NDK를 통해 Android의 네이티브 레이어와 직접 붙는 쪽을 택했다는 설명입니다.

UI 절의 문장도 분명합니다 — 공식 이니셔티브는 단일 UI 프레임워크를 제공하지 않고, 여러 접근을 인정·지원할 뿐입니다. 실제 선택지로 문서가 나열하는 건 Jetpack Compose(브리징 레이어 경유), 기존 XML 기반 Android View, Flutter 같은 서드파티, 그리고 SwiftUI 비슷한 코드를 Compose로 변환하는 Skip.tools 같은 브리징 솔루션입니다. 각 플랫폼에서 네이티브 UI 컴포넌트를 쓰는 SwiftCrossUI 같은 커뮤니티 프로젝트도 있습니다. 워크그룹은 개별 프로젝트의 주장을 검증하지는 않았다고 못 박아 뒀습니다.

그래서 워크그룹이 밀고 있는 대표 유스케이스는 명확합니다 — 핵심 비즈니스 로직, 알고리즘, 데이터 모델을 앱들 사이에서 공유하는 것. 비전 문서가 "전체 네이티브 앱"을 아예 배제하진 않지만, 거기에도 "UI에 상당한 노력이 필요하지만"이라는 단서가 붙어 있습니다.

비전 문서에 관해 하나 더 짚을 게 있습니다. 이 PR은 2025년 8월 27일에 열렸고, 지금(2026년 7월 16일)까지도 draft 상태로 병합되지 않았습니다. 마지막 업데이트는 2026년 2월 24일입니다. SDK가 정식 릴리스에 실린 뒤에도 방향을 정의하는 문서는 아직 초안이라는 뜻입니다.

아직 덜 된 것들

여기가 하이프와 현실이 갈리는 곳입니다. 전부 확인 가능한 사실만 적습니다.

디버깅. 2025년 12월 글에서 워크그룹은 쉬운 디버깅이 "이제 우리에게 높은 우선순위"라고 적으면서, "작은 예제에서는 동작할 수 있지만" 더 확장하고 테스트하고 설정하기 쉽게 만들어야 한다고 했습니다. 그 근거로 링크된 이슈가 swiftlang/llvm-project #10831 "Get this lldb working for Android debugging"인데, 2025년 6월 12일에 열려 오늘까지 열려 있습니다. 플랫폼 지원 페이지의 디버거·REPL 지원 표에도 Android 행은 없습니다.

swift-java가 아직 0.x다. Android에서 Android API를 부르려면 반드시 거쳐야 하는 상호운용 레이어인데, 최신 릴리스가 0.4.2(2026-06-26)입니다. 1.0 이전이라는 건 API 안정성 약속이 아직 없다는 뜻입니다.

IDE. 2026년 4월 IDE 지원 확대 발표는 VS Code 익스텐션의 Open VSX 등록을 알리면서 "macOS, Linux, Windows에서의 매끄러운 크로스플랫폼 개발"을 말합니다. Android Studio 통합은 비전 문서의 목표 목록에 있을 뿐, 아직 발표된 게 없습니다.

"공식 지원 플랫폼"의 층위. 이게 제일 미묘합니다. Android 워크그룹 헌장의 주 목표는 여전히 "Android를 Swift 언어의 공식 지원 플랫폼으로 추가하고 유지하는 것"이고, 세부 항목에는 "Platform Steering Group과 함께 플랫폼 지원 레벨을 일반적으로 정의하고, 그다음 Android에 대해 특정 레벨의 공식 지원을 달성하도록 노력한다"가 들어 있습니다. 즉 그건 아직 달성 상태가 아니라 목표입니다. 지원 API 레벨과 아키텍처 범위를 "정한다"도 여전히 헌장의 할 일 목록에 있습니다. 플랫폼 지원 페이지의 Platform Owner 표에는 Apple 플랫폼·Linux·Windows만 있고 Android는 없습니다.

한 가지 단서를 달아야 공정합니다 — 워크그룹 헌장 페이지는 2025년 9월 24일, 플랫폼 지원 페이지는 2025년 10월 31일이 마지막 수정입니다. 둘 다 6.3 릴리스보다 앞섭니다. 그러니 표에서 Android가 빠진 걸 "정책적 배제"로 과하게 읽으면 안 되고, 문서가 아직 안 따라온 것일 수도 있습니다. 다만 방향은 분명합니다 — 공식적으로 빌드·배포되는 SDK가 생긴 것과 Linux·Windows와 같은 티어의 지원 플랫폼이 된 것은 아직 다른 말입니다.

그렇다고 실험실 장난감은 아니다

균형을 맞춰야 할 반대편도 있습니다. Swift on Android는 공식 SDK 이전에도 이미 프로덕션에서 돌고 있었습니다. 워크그룹이 직접 나열한 사례는 이렇습니다 — Readdle의 이메일 클라이언트 Spark(iOS/Android 모바일과 macOS/Windows 데스크톱 사이 코드 공유), 피아노 학습 앱 flowkey(거의 10년째 Swift for Android 사용), 헬스케어 앱 MediQuo, 유기농 마켓 Naturitas. 이들은 전부 자체 제작 Java interop으로 그 일을 해냈고, swift.org의 표현으로는 합쳐서 "수백만 회 다운로드"됐습니다. (이건 swift.org 자체 서술이고 앱별 수치는 제시되지 않습니다.)

공식 SDK의 의미는 바로 여기 있습니다. 되느냐 마느냐를 증명하는 단계는 이미 지났고, 그 일을 하려고 각자 포크와 커스텀 툴체인을 유지하지 않아도 되는 단계로 넘어온 겁니다. 비전 문서의 표현대로, 역사적으로 Swift for Android는 비공식 포크·커스텀 툴체인·서드파티 솔루션에 의존해야 했습니다.

그래서, 당신은 써야 하나

값을 하는 경우

iOS 앱이 이미 Swift로 있고, 모델·네트워크·도메인 로직을 Android와 공유하고 싶다. 이게 워크그룹이 정조준한 유스케이스입니다.
이미지·오디오 처리처럼 성능이 중요한 모듈을 NDK C++ 대신 Swift로 짜고 싶다. 비전 문서가 두 번째로 꼽는 용도이고, Swift가 대체하는 자리가 정확히 여기입니다.
여러 플랫폼에 같은 API 표면으로 나가는 라이브러리·SDK를 만든다.

과잉이거나 아직인 경우

Android 앱을 새로 짠다. 비전 문서 자신이 "Kotlin은 여전히 Android 개발에 권장되는 언어"라고 적어 뒀습니다. UI를 Swift로 짜는 공식 경로는 존재하지 않습니다.
팀에 Swift 자산이 없다. 공유할 Swift 코드가 없는데 Swift on Android를 도입하는 건 이득 없이 런타임 번들과 JNI 경계만 떠안는 일입니다.
디버깅 편의가 협상 불가다. lldb 이슈가 열려 있는 상태에서 Android 쪽 Swift 코드를 디버깅하는 경험은 아직 iOS와 같지 않습니다.
APK 크기 예산이 빠듯하다. 런타임을 들고 가는 구조라는 걸 먼저 재 보세요.

Kotlin Multiplatform과의 비교를 원하실 텐데, 여기서 정직하려면 이렇게 말해야 합니다. KMP는 같은 문제(로직 공유)를 몇 년 더 오래 풀어 왔고 JetBrains의 지원을 받습니다. 두 진영을 나란히 놓고 잰 신뢰할 만한 공개 벤치마크나 마이그레이션 사례 비교는 제가 확인한 범위에 없었고, 그래서 여기서 승패를 매기지 않겠습니다. 실질적인 판단 기준은 대개 벤치마크가 아니라 당신의 기존 자산이 어느 쪽 언어로 쓰여 있는가입니다. iOS 로직이 이미 Swift라면 Swift SDK는 그 코드를 그대로 쓰는 길이고, 그게 아니라면 KMP가 더 짧은 길입니다.

마치며

정리하면 이렇습니다. Swift 6.3(2026-03-24)은 Swift SDK for Android의 첫 공식 릴리스를 담았고, 이건 10년짜리 커뮤니티 노력이 공식 배포 경로에 올라탄 진짜 이정표입니다. 모델은 명확합니다 — 네이티브 기계어로 컴파일하고, 런타임을 번들하고, Android API는 JNI로 부른다. Kotlin의 자리가 아니라 NDK의 자리입니다.

동시에 빠진 것도 명확합니다. UI는 non-goal이고, JVM 바이트코드도 non-goal이고, 비전 문서는 아직 초안이고, lldb 이슈는 열려 있고, swift-java는 0.4.x이고, 워크그룹 헌장이 말하는 "공식 지원 플랫폼"은 여전히 목표 시제로 쓰여 있습니다.

그래서 이 릴리스를 읽는 정확한 방법은 "Swift로 Android 앱을 짤 수 있게 됐다"가 아니라 "Swift 로직을 Android에 태우는 일이 이제 공식 지원 도구로 가능해졌다"입니다. 그 둘의 차이가 당신 프로젝트에서 중요한지 아닌지가, 지금 이걸 꺼낼지 말지를 결정합니다.