코틀린 멀티플랫폼 (KMP)

안녕하세요. 오늘의 제 요즘 관심 주제인 Kotlin MultiPlatform(KMP)에 대해서 포스팅을 해보겠습니다.

아래 Android Developers Docs에도 소개된 KMP는 구글에서 공식적으로 지원합니다.

키포인트는 비즈니스 로직은 Kotlin으로 플랫폼 공유하고, UI는 각 OS 개발자가 직접 구현하는 것입니다.

제가 Flutter을 아주 간단히 해봤는데요. 상용 UI로 배포되기엔 한계가 있었습니다. 디자이너가 절대 용납못하는 UI로 개발되기 때문이죠.

또한, Dart 언어의 피로도.. 트리구조라 별로 좋지 못한 것 같았습니다.

그래서 요즘 제 관심은 KMP인데요.

Android 개발자로 코틀린에 능숙한 편이고, Android에 익숙한 Compose를 사용할 수도 있죠.

KMP는 프로젝트 전체를 바로 KMP화 하지 않아도 됩니다.

점진적으로 사용이 가능해요. 처음에는 유틸리티성 함수부터 시작하다가 개발자가 익숙해지면 점점 큰 도메인으로 바꾸는거죠.

자세한 주요 장점은 아래에서 소개하겠습니다.

Kotlin Multiplatform (KMP)의 주요 장점

KMP는 "모든 것을 공유한다"는 접근보다는 "필요한 것만 공유하고, 나머지는 네이티브의 장점을 살린다"는 유연함이 가장 큰 특징입니다.

1. 유연한 코드 공유 (Flexible Code Sharing)

프로젝트의 성격에 따라 공유 범위를 자유롭게 조절할 수 있습니다.

• 로직만 공유: 비즈니스 로직(데이터, 도메인)만 공유하고 UI는 네이티브(SwiftUI/Jetpack Compose)로 작성하여 최상의 UX 제공.
• UI까지 공유 (Compose Multiplatform): UI 코드까지 공유하여 개발 속도 극대화.
• 하이브리드: 대부분 공유하되, 카메라/센서 등 플랫폼 특화 기능만 네이티브로 작성.

2. 점진적 도입 가능 (Brownfield Projects)

기존 앱을 갈아엎지 않고 부분적으로 도입할 수 있습니다.

• 기존 앱에 통합: KMP 모듈은 iOS에서 일반적인 Framework로 인식되므로, 기존 네이티브 앱의 작은 기능 하나부터 대체 가능합니다.
• 리스크 분산: 전체 재작성이 필요 없어 도입 리스크가 낮습니다.

3. 네이티브 성능과 API 접근성

• 네이티브 컴파일: 가상 머신이나 브릿지 없이, 각 플랫폼의 네이티브 바이너리(JVM, LLVM)로 직접 컴파일되어 성능 저하가 없습니다.
• 플랫폼 API 직접 호출: 별도 플러그인 없이 Kotlin 코드 내에서 iOS의 UIKit 등을 직접 호출할 수 있습니다 (expect/actual 패턴 활용).

4. 단일 언어(Kotlin)의 생산성

• 언어적 장점: Null Safety, Coroutines, Flow 등 Kotlin의 강력한 기능을 iOS 개발에도 그대로 적용할 수 있습니다.
• Full Stack: 서버(Ktor), 안드로이드, iOS, 웹을 하나의 언어로 개발 가능합니다.

5. 생태계의 안정성

• Google의 공식 지원: Android의 주요 Jetpack 라이브러리(Room, ViewModel 등)가 KMP를 지원합니다.
• JetBrains의 주도: 강력한 IDE 지원과 도구 편의성을 제공합니다.

---

💡 요약: 타 크로스 플랫폼과의 비교

구분	KMP (Kotlin Multiplatform)	Flutter / React Native
철학	로직 공유 중심 + UI 선택적 공유	UI와 로직 모든 것을 한 번에 작성
결과물	네이티브 라이브러리 (Framework)	별도 엔진 위에서 구동되는 앱
기존 앱 도입	매우 쉬움 (모듈 단위 추가)	어려움 (엔진 통합 비용)
성능	네이티브와 동일	브릿지/엔진 오버헤드 존재 가능

Kotlin Multiplatform (KMP)의 주요 단점 및 한계

KMP는 강력하지만, 은탄환(Silver Bullet)은 아닙니다. 도입 전 반드시 고려해야 할 기술적, 조직적 단점들입니다.

1. iOS 개발 경험과 상호운용성 (iOS Interop)

안드로이드 개발자에게는 친숙하지만, iOS 진영과의 통합 과정에서 마찰이 발생할 수 있습니다.

• 디버깅의 어려움: Xcode에서 Kotlin 코드를 디버깅하는 것이 순수 Swift를 디버깅하는 것만큼 매끄럽지 않습니다. (JetBrains Fleet 등으로 개선되고 있으나 여전히 Xcode 네이티브 환경보다는 불편함)
• 언어 간 변환 (Objective-C Bridge): Kotlin 코드는 Swift로 직접 변환되는 것이 아니라 Objective-C 헤더를 거쳐 연결됩니다. 이로 인해 Kotlin의 Sealed Class, Generics, Suspend Function이 Swift에서 다소 부자연스럽게 표현될 수 있습니다.
• SwiftUI 연동: Compose를 쓰지 않고 로직만 공유할 경우, Kotlin의 데이터 흐름(StateFlow 등)을 SwiftUI 관점에서 소비하려면 별도의 어댑터/래퍼 코드가 필요합니다.

2. 복잡한 빌드 시스템 (Gradle)

• 높은 러닝 커브: KMP의 모든 설정은 Gradle 기반입니다. iOS 개발자에게 Gradle은 매우 낯설고 복잡한 도구이며, 오류 발생 시 해결이 어렵습니다.
• 설정의 까다로움: CocoaPods/Swift Package Manager 통합, cinterop 설정 등 초기 환경 세팅 과정이 복잡하며 깨지기 쉽습니다.
• 빌드 시간: 다중 플랫폼 컴파일로 인해 초기 빌드 및 클린 빌드 시간이 네이티브 프로젝트보다 오래 걸릴 수 있습니다.

3. 라이브러리 생태계의 제약

• Java/Android 라이브러리 사용 불가: 공통 코드(Common Main)에서는 순수 Kotlin 코드만 동작합니다. java.* 패키지나 android.* 패키지에 의존하는 라이브러리는 사용할 수 없습니다.
• 대체제 학습 필요:
  • Retrofit → Ktor (또는 Ktorfit)
  • Hilt/Dagger → Koin (또는 Kodein)
  • Room → SQLDelight (최근 Room KMP가 나왔으나 아직 초기 단계)
    위와 같이 KMP를 지원하는 라이브러리로 기술 스택을 변경하고 학습해야 합니다.

4. Compose Multiplatform (iOS)의 한계

UI까지 공유하는 경우 발생하는 단점입니다.

• Uncanny Valley (불쾌한 골짜기): 스크롤 물리 엔진, 텍스트 선택 커서, 햅틱 반응 등 미묘한 부분에서 iOS 네이티브와 다른 '이질감'이 느껴질 수 있습니다.
• 시스템 기능 접근: 최신 iOS 기능이나 복잡한 시스템 UI(예: 복잡한 권한 팝업 처리, 위젯 등)를 구현할 때 네이티브보다 구현이 번거롭습니다.

5. 인력 구성과 채용 (Human Resource)

• 구인 난이도: "KMP 실무 경험이 있는 개발자"는 시장에 매우 드뭅니다.
• 팀 내 갈등: iOS 개발자가 Kotlin과 Android Studio/Gradle 환경을 강제로 학습해야 하는 상황이 오면 방어적인 태도를 보일 수 있습니다.

---

💡 요약: 도입이 위험한 경우

1. 극강의 iOS 네이티브 UX가 필수인 경우: Apple의 최신 UI 트렌드와 미세한 애니메이션을 즉시 반영해야 한다면 Compose Multiplatform은 적합하지 않을 수 있습니다.
2. 하드웨어 의존도가 높은 앱: 블루투스, AR, 복잡한 카메라 처리 등이 앱의 90%라면 공유할 로직이 적어 KMP의 효용이 떨어집니다.
3. iOS 개발자의 동의가 없는 경우: 팀의 합의 없이 도입하면 프로젝트 유지보수에 큰 어려움을 겪을 수 있습니다.

이러한 부분이 있는데요.
저는 이제 스터디를 시작해보려고합니다!
나중에 후기로 들고 오겠습니다~

https://developer.android.com/kotlin/multiplatform?hl=ko

[Kotlin 멀티플랫폼 | Android Developers

컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요. 이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자

developer.android.com](https://developer.android.com/kotlin/multiplatform?hl=ko)