이 글은 누구를 위한 것인가
- Flutter와 React Native 중 무엇을 선택할지 고민 중인 팀
- Android와 iOS 앱을 동시에 유지하는 데 드는 비용을 줄이고 싶은 개발팀
- KMP라는 말을 들었는데 기존 크로스플랫폼과 뭐가 다른지 궁금한 분
들어가며
"Flutter요, React Native요, 아니면 네이티브로 따로 개발해야 하나요?"
이 질문에 2026년에는 새로운 선택지를 진지하게 고려해야 한다. **Kotlin Multiplatform(KMP)**이다.
2024년 KMP 채택률은 전체 모바일 개발자의 7%였다. 2025년에는 23%로 세 배 이상 폭증했다. 단순한 유행이 아니다. Google이 공식 지원을 선언했고, 주요 기업들이 프로덕션에 도입하기 시작했다.
1. KMP가 기존 크로스플랫폼과 결정적으로 다른 이유
Flutter와 React Native는 UI를 포함한 모든 것을 하나의 코드로 만든다. KMP는 접근 방식이 다르다. 비즈니스 로직만 공유하고, UI는 각 플랫폼 네이티브로 만든다.
[Flutter / React Native 방식]
공유 코드 (UI + 비즈니스 로직)
└─ Android로 컴파일
└─ iOS로 컴파일
└─ Web으로 컴파일
[KMP 방식]
공유 코드 (비즈니스 로직만)
└─ Android에서 사용 (Jetpack Compose UI)
└─ iOS에서 사용 (SwiftUI UI)
└─ Web에서 사용 (React UI)
이 차이가 왜 중요한가?
Flutter와 React Native에서 가장 많은 고통이 생기는 지점이 네이티브 UI 사이의 불일치다. 애니메이션이 iOS에서는 자연스러운데 Android에서는 어색하다거나, 특정 플랫폼 UI 컴포넌트(iOS의 DatePicker, Android의 BottomSheet)를 정확히 구현하기 어렵다거나.
KMP는 UI를 각 플랫폼의 네이티브 방식으로 만든다. Android는 Compose, iOS는 SwiftUI. 각 플랫폼 사용자가 기대하는 느낌 그대로다.
2. KMP + Compose Multiplatform = UI도 공유 가능
"비즈니스 로직만 공유하면 결국 UI 코드를 두 번 짜야 하는 거 아닌가?"라는 의문이 들 수 있다.
여기서 Compose Multiplatform이 등장한다. Android의 Jetpack Compose를 iOS, 데스크탑, 웹까지 확장한 것이다.
[선택 1: 비즈니스 로직만 공유]
공유 모듈 (비즈니스 로직)
└─ Android: Compose UI (네이티브)
└─ iOS: SwiftUI (네이티브)
[선택 2: UI도 공유 (Compose Multiplatform)]
공유 모듈 (비즈니스 로직 + Compose UI)
└─ Android: 그대로 실행
└─ iOS: Compose Multiplatform으로 렌더링
└─ Desktop: 그대로 실행
어느 수준까지 공유할지는 프로젝트 목표와 팀 역량에 따라 결정한다. 복잡한 플랫폼 특화 UI(카메라, 지문인식, 위젯)는 네이티브로, 공통 화면(목록, 폼, 대시보드)은 Compose Multiplatform으로 공유하는 하이브리드 접근이 현실적이다.
3. KMP vs Flutter vs React Native 2026 현실 비교
| 기준 | KMP | Flutter | React Native |
|---|---|---|---|
| UI 공유 | 선택적 (Compose MP) | 완전 공유 | 완전 공유 |
| 네이티브 성능 | 최고 (비즈니스 로직) | 우수 (Skia/Impeller) | 좋음 (New Arch) |
| 학습 곡선 | 높음 (Kotlin 필요) | 중간 (Dart) | 낮음 (JS/TS) |
| 생태계 | 성장 중 | 성숙 | 가장 성숙 |
| 기업 지원 | Google, JetBrains | Meta | |
| 채택 기업 | Netflix, VMware | BMW, Alibaba | Meta, Shopify |
| 적합한 팀 | Android 팀 있음 | 새로 시작 | 웹 개발자 많음 |
4. 기존 Android/iOS 코드베이스에 KMP 점진적 도입
이미 네이티브로 개발된 앱이 있다면, 처음부터 다시 짤 필요 없다. 점진적 도입이 가능하다.
도입 시작하기 좋은 모듈
| 모듈 | 이유 |
|---|---|
| 네트워크 레이어 (API 통신) | UI 의존성 없음, 독립적 |
| 데이터 모델/파싱 | 순수 로직, 테스트 쉬움 |
| 비즈니스 규칙 | 플랫폼 무관한 계산 로직 |
| 로컬 DB (SQLDelight) | KMP 공식 지원 라이브러리 |
// 공유 모듈 (commonMain)
// Android와 iOS 둘 다에서 사용되는 코드
expect class Platform() {
val name: String
}
class Greeting {
private val platform = Platform()
fun greet(): String = "Hello from ${platform.name}!"
}
// Android 구현 (androidMain)
actual class Platform actual constructor() {
actual val name: String = "Android ${android.os.Build.VERSION.SDK_INT}"
}
// iOS 구현 (iosMain)
actual class Platform actual constructor() {
actual val name: String = UIDevice.currentDevice.systemName()
}
expect/actual 메커니즘이 KMP의 핵심이다. 공통 코드에서 expect로 인터페이스를 선언하고, 각 플랫폼에서 actual로 구현한다.
5. KMP 생태계 현황
초기 KMP의 가장 큰 약점은 라이브러리 생태계였다. 2026년 기준으로 상황이 많이 개선됐다.
| 카테고리 | KMP 라이브러리 |
|---|---|
| 네트워크 | Ktor (공식 지원) |
| DB | SQLDelight, Room (KMP 지원 추가) |
| DI | Koin (KMP 지원) |
| 직렬화 | kotlinx.serialization |
| 날짜/시간 | kotlinx-datetime |
| 이미지 로딩 | Coil 3 (KMP 지원) |
| 테스트 | kotlin.test |
주요 라이브러리들이 대부분 KMP를 지원하기 시작했다. 2년 전과 비교해 격차가 크게 줄었다.
6. 국내 기업 KMP 도입 사례
카카오: KakaoTalk의 일부 내부 SDK를 KMP로 전환 실험 중 라인: 메신저 앱의 코어 비즈니스 로직 KMP 공유 진행 배달의민족: 주문 처리 관련 공통 로직에 KMP 도입 검토
아직 Flutter나 React Native처럼 완전 공유 방식의 대규모 전환은 드물다. 비즈니스 로직 공유에서 시작해 점진적으로 확장하는 방식이 국내에서도 선호되는 패턴이다.
맺으며
KMP는 Flutter나 React Native를 대체하는 것이 아니다. 다른 철학을 가진 도구다. "플랫폼 경험은 네이티브답게, 로직은 한 번만 작성"이라는 목표를 가진 팀에게 KMP가 맞다.
이미 네이티브로 운영 중인 팀이라면 전체 재작성 없이 점진적으로 KMP를 도입할 수 있다. 네트워크 레이어 하나부터 시작해보자. 그것이 KMP 여정의 가장 현명한 첫 걸음이다.