2026년의 KMP: Kotlin 멀티플랫폼의 아키텍처, 구축 및 생태계
수년 동안 Kotlin Multiplatform(KMP)은 "흥미롭지만 아직 준비가 되지 않았습니다"라는 라벨이 붙었습니다. 생산." 2026년에는 이러한 이야기가 완전히 바뀌었습니다. KMP가 성숙해졌습니다. 안정적인 iOS API를 갖춘 기업, 모든 주요 플랫폼에서 안정적인 Compose Multiplatform, 전자 신속한 내보내기 마침내 Objective-C 브리징이 필요 없게 되었습니다. 기본 Swift 코드와의 상호 운용성.
이 가이드는 2026년 KMP 생태계에 대한 포괄적인 개요를 제공합니다. 이후 변경된 사항은 무엇입니까? 이전 몇 년 동안 Flutter 및 React Native와 비교하면 올바른 아키텍처는 무엇입니까? 크로스 플랫폼 프로젝트의 경우 KMP가 사용 사례에 적합한 선택인지 평가하는 방법을 알아보세요.
무엇을 배울 것인가
- KMP 아키텍처: 공유 모듈, 소스 세트 및 플랫폼별 코드
- KMP vs Flutter vs React Native: 2026년으로 업데이트된 기술 비교
- Swift 내보내기 및 iOS와의 기본 상호 운용성
- Compose Multiplatform: 현재 상태 및 제한사항
- KMP 2026 라이브러리 생태계: Ktor, SQLDelight, Koin
- KMP를 선택해야 할 때와 선택하지 않을 때
2025~2026년 품질 도약
KMP 1.0은 이미 비즈니스 로직을 공유하는 데 안정적이었지만 중요한 제한 사항이 있었습니다. iOS 통합에는 자동으로 생성된 Objective-C 헤더가 필요합니다. Swift 개발자) 및 Compose Multiplatform에는 여전히 iOS 및 데스크톱에서 알파 버전의 많은 API가 있었습니다.
2024년부터 2026년 사이에 발생한 주요 변경 사항은 다음과 같습니다.
- Swift 내보내기(KMP 1.9 이상에서는 안정적): 이름 지정을 사용하여 기본 Swift API 생성 관용적, 프로토콜, 기본 인수 및 중간 Objective-C가 없습니다. 개발자 iOS는 이제 마치 순수한 Swift인 것처럼 Kotlin 코드를 사용합니다.
- Compose 다중 플랫폼 1.7 이상(iOS에서는 안정적): 완전히 공유된 UI Android, iOS, 데스크톱(JVM) 및 웹(Wasm)의 Kotlin/Compose. 플랫폼별 렌더링 엔진 이제 성숙해졌으며 복잡한 앱에서도 성능이 허용됩니다.
- Amper 빌드 시스템(베타): KMP 프로젝트를 위한 Gradle의 단순화된 대안 복잡한 Kotlin DSL 대신 YAML 설정을 사용합니다.
- 향상된 도구: Android Studio Ladybug 이상에서는 KMP를 지원합니다. 크로스 플랫폼 리팩토링, 내장 iOS 시뮬레이터 디버깅, 프로파일링을 갖춘 세계적 수준의 제품입니다.
KMP 프로젝트 아키텍처
KMP의 기본 아키텍처는 공유 코드(commonMain) 분리를 기반으로 합니다. 그리고 플랫폼별 코드. React Native가 약속한 것처럼 "모든 것을 한 번에 작성"하는 것이 아닙니다. 하지만 플랫폼에 공유하고 위임하는 것이 합리적인 논리를 공유하려면 본질적으로 네이티브.
// Struttura tipica di un progetto KMP nel 2026
shared/
├── src/
│ ├── commonMain/kotlin/
│ │ ├── data/
│ │ │ ├── repository/ # Repository patterns condivisi
│ │ │ ├── network/ # Ktor client (HTTP multiplatform)
│ │ │ └── local/ # SQLDelight (DB multiplatform)
│ │ ├── domain/
│ │ │ ├── model/ # Data classes pure Kotlin
│ │ │ ├── usecase/ # Logica business
│ │ │ └── repository/ # Interfacce repository
│ │ └── presentation/ # ViewModels (Compose o altri)
│ │
│ ├── androidMain/kotlin/
│ │ └── actual/ # Implementazioni Android-specific
│ │ ├── DatabaseDriver.kt
│ │ └── HttpEngine.kt
│ │
│ ├── iosMain/kotlin/
│ │ └── actual/ # Implementazioni iOS-specific
│ │ ├── DatabaseDriver.kt
│ │ └── HttpEngine.kt
│ │
│ └── desktopMain/kotlin/ # (opzionale, per desktop JVM)
│
androidApp/ # App Android con UI nativa
iosApp/ # App iOS con UI nativa (Swift/SwiftUI)
desktopApp/ # App desktop (opzionale)
composeApp/ # (alternativa: UI condivisa con Compose MP)
기본 원칙: 가능한 한 많이 공유하고, 필요한 경우 기본 API를 사용하세요.. 일반적으로 성숙한 KMP 애플리케이션은 다음을 공유합니다.
- 비즈니스 로직의 90-95%(도메인 레이어)
- 데이터 계층(네트워크, 지속성, 캐싱)의 80-85%
- 프레젠테이션 계층의 40~80%(Compose Multiplatform 사용 여부에 따라 다름)
- UI 레이어의 0-20%(플랫폼별 기본 UI를 사용하는 경우)
KMP vs Flutter vs React Native: 2026년 비교
"어떤 크로스 플랫폼 프레임워크를 사용할 것인가?"라는 질문이 있습니다. 2026년과 2022년의 답은 다릅니다. 솔직한 비교는 다음과 같습니다.
// Matrice decisionale semplificata
| KMP | Flutter | React Native
--------------------|--------------|-------------|-------------
Linguaggio | Kotlin | Dart | TypeScript/JS
UI Engine | Nativa o CMP | Custom (Skia)| Nativa (bridge)
Performance | Ottima | Buona | Buona
Look nativo | Perfetto | Non nativo | Parziale
Team Android-first | Eccellente | Buono | Buono
Condivisione codice | ~70-80% | ~95% | ~80-90%
Ecosistema librerie | Crescente | Maturo | Maturo
Enterprise adoption | Alta (2026) | Alta | Diminuzione
주요 차이점: Flutter는 사용자 정의 렌더링 엔진(Impeller)을 사용하여 그림을 그립니다. 전체 UI를 통합하여 플랫폼 간 시각적 일관성을 보장하지만 "기본" 모양을 희생합니다. 플랫폼. 기본 UI가 포함된 KMP는 기본 앱과 똑같아 보입니다. 미국 구성 요소 플랫폼 고유.
KMP를 선택해야 하는 경우
KMP는 다음과 같은 경우에 최적의 선택입니다.
- 팀은 강력한 Android/Kotlin 전문 지식을 보유하고 있으며 해당 논리를 iOS로 가져오고 싶어합니다.
- UI의 "기본" 측면은 협상할 수 없는 요구 사항입니다(뱅킹 앱, 기업).
- 플랫폼별 UI에 대한 전체 제어를 유지하면서 비즈니스 로직을 공유하고 싶습니다.
- 애플리케이션에 복잡한 비즈니스 로직이 있음(UI 문제로부터 격리하는 것이 좋음)
- 모든 것을 다시 작성하지 않고 기존 Android 앱에 iOS를 추가하고 있습니다.
Flutter 또는 React Native는 다음과 같은 경우에 선호될 수 있습니다.
- 팀이 웹/React 기술을 보유하고 있으며 이를 재사용하고 싶어합니다.
- (로직뿐만 아니라) UI 공유를 극대화하고 싶습니다.
- 출시 시기는 매우 중요하며 팀은 Kotlin을 모릅니다.
Swift 내보내기: 2026년 iOS 상호 운용성
Swift 내보내기 이전에는 공유 Kotlin 코드가 헤더를 통해 iOS에 노출되었습니다. 자동으로 생성된 Objective-C. 결과는 다음과 같은 API였습니다.
// PRIMA (Objective-C headers generati da KMP):
// Swift deve usare classi con nomi generati automaticamente
let viewModel = SharedUserViewModel()
let users = viewModel.users as! [SharedUser]
viewModel.loadUsers(completionHandler: { users, error in
// Gestione callback non-idiomatica
})
// DOPO (Swift Export in KMP 1.9+):
// Swift idiomatico, direttamente da codice Kotlin
let viewModel = UserViewModel()
let users: [User] = viewModel.users
await viewModel.loadUsers() // async/await nativo Swift
Swift 내보내기는 Kotlin 코루틴을 자동으로 변환합니다. async/await 스위프트,
Swift 구조체의 데이터 클래스(자동 동일화 가능), Swift 열거형의 봉인된 클래스,
AsyncSequence의 흐름. 그 결과 iOS 개발자는 Kotlin API를 사용하게 됩니다.
마치 Swift로 작성된 것처럼 말이죠.
Compose 멀티플랫폼: 현재 상태
CMP(Compose Multiplatform)를 사용하면 Compose Kotlin으로 작성된 전체 UI를 공유할 수 있습니다. Android, iOS, 데스크톱 JVM 및 웹(Kotlin/Wasm을 통해). 2026년에는 iOS와 초기 베타에 비해 크게 개선되었습니다.
// commonMain: UI condivisa con Compose Multiplatform
@Composable
fun UserListScreen(
users: List<User>,
onUserClick: (User) -> Unit
) {
LazyColumn {
items(users) { user ->
UserCard(user = user, onClick = { onUserClick(user) })
}
}
}
@Composable
fun UserCard(user: User, onClick: () -> Unit) {
Card(
modifier = Modifier
.fillMaxWidth()
.padding(horizontal = 16.dp, vertical = 8.dp)
.clickable(onClick = onClick)
) {
Column(modifier = Modifier.padding(16.dp)) {
Text(user.name, style = MaterialTheme.typography.titleMedium)
Text(user.email, style = MaterialTheme.typography.bodySmall)
}
}
}
Compose UI는 Android와 iOS에서 동일합니다. 렌더링에서는 Skiko(Skia의 Kotlin 바인딩)를 사용합니다. 기본 UIKit 구성 요소 대신 iOS에서 이는 앱이 일관된 모양을 가짐을 의미합니다. 크로스 플랫폼이지만 기본 SwiftUI 앱과 동일하지는 않습니다.
2026년 KMP 도서관 생태계
성숙한 도서관의 생태계는 생산성을 위해 필수적입니다. 2026년에는 다음과 같습니다. KMP 프로젝트의 기본 라이브러리:
// build.gradle.kts (shared module)
kotlin {
sourceSets {
commonMain.dependencies {
// Network: client HTTP multiplatform
implementation("io.ktor:ktor-client-core:2.3.10")
implementation("io.ktor:ktor-client-content-negotiation:2.3.10")
implementation("io.ktor:ktor-serialization-kotlinx-json:2.3.10")
// Database: SQL multiplatform
implementation("app.cash.sqldelight:runtime:2.0.2")
// Serialization
implementation("org.jetbrains.kotlinx:kotlinx-serialization-json:1.7.0")
// Coroutines multiplatform
implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:1.8.1")
// Dependency Injection
implementation("io.insert-koin:koin-core:3.5.6")
// DateTime multiplatform
implementation("org.jetbrains.kotlinx:kotlinx-datetime:0.6.0")
// Logging multiplatform
implementation("co.touchlab:kermit:2.0.3")
}
androidMain.dependencies {
implementation("io.ktor:ktor-client-okhttp:2.3.10")
implementation("app.cash.sqldelight:android-driver:2.0.2")
}
iosMain.dependencies {
implementation("io.ktor:ktor-client-darwin:2.3.10")
implementation("app.cash.sqldelight:native-driver:2.0.2")
}
}
}
완전한 예: KMP의 패턴 저장소
KMP에서 사용자 관리를 위한 간단한 저장소를 구현하는 방법을 살펴보겠습니다. 공통 코드와 플랫폼별 코드 간의 구분을 보여줍니다.
// commonMain: Interfaccia repository e modello
data class User(
val id: Long,
val name: String,
val email: String,
val createdAt: Instant
)
interface UserRepository {
suspend fun getUsers(): List<User>
suspend fun getUserById(id: Long): User?
suspend fun saveUser(user: User): User
}
// commonMain: Implementazione con Ktor + SQLDelight
class UserRepositoryImpl(
private val httpClient: HttpClient,
private val database: AppDatabase
) : UserRepository {
override suspend fun getUsers(): List<User> {
return try {
// Prima controlla il database locale
val cached = database.userQueries.selectAll().executeAsList()
if (cached.isNotEmpty()) {
cached.map { it.toDomain() }
} else {
// Poi scarica dalla rete e salva
val remote = httpClient.get("$BASE_URL/users").body<List<UserDto>>()
remote.forEach { database.userQueries.insert(it.toEntity()) }
remote.map { it.toDomain() }
}
} catch (e: Exception) {
// Fallback al cache anche se la rete fallisce
database.userQueries.selectAll().executeAsList().map { it.toDomain() }
}
}
}
기업도입통계(2026)
2026년 1분기에 업데이트된 Kotlin 생태계 데이터에 따르면:
- Fortune 500대 기업의 KMP 채택: 18%(2023년에는 7%), 핀테크, 전자상거래, B2B 기업용 앱이 대다수입니다.
- 주요 사용 사례: Android와 iOS 간 비즈니스 로직 공유(82%) JVM/Android 백엔드 동기화(45%), 데스크톱 앱(12%).
- 주목할만한 회사: Cash App (Block), VMware, Philips, Touchlab 및 다수의 SME 유럽의 기술 회사들은 생산에 KMP를 사용합니다.
- 가치 실현 시간: 팀에서는 시간이 30~40% 단축되었다고 보고합니다. 채택 후 처음 3개월 후에 기능을 구현합니다.
팀 채택 시 고려 사항
KMP를 채택하기 전에 다음과 같은 실질적인 요소를 고려하십시오.
- 팀 기술: KMP에는 Kotlin을 아는 개발자가 필요합니다. 이상적으로는 Android 팀이 KMP를 iOS로 가져오는 것이지 그 반대가 아닙니다.
- Gradle 학습 곡선: Kotlin Multiplatform을 사용한 KMP 빌드 시스템 Gradle 플러그인은 학습 곡선이 가파르다. 이해하는 데 시간을 투자하세요. 시작하기 전에 소스 세트를 확인하세요.
- 라이브러리 호환성: 모든 Java/Android 라이브러리가 호환되는 것은 아닙니다. Kotlin/Native(iOS)를 사용합니다. 종속성을 추가하기 전에 항상 KMP 호환성을 확인하세요.
- 빌드 시간: KMP 프로젝트는 앱보다 빌드 시간이 더 깁니다. 단일 플랫폼, 특히 iOS(Kotlin/Native 컴파일)용. 잘 구성된 CI/CD 캐싱 및 필수.
결론 및 다음 단계
2026년 Kotlin Multiplatform은 라이브러리 생태계를 갖춘 성숙하고 안정적인 플랫폼입니다. 기업 품질. 모든 사람에게 적합한 솔루션은 아닙니다. 팀이 React 우선이라면, React Native 또는 Expo가 더 적합합니다. 하지만 코드를 이식하려는 Android 우선 팀의 경우 iOS에서는 관용적으로 KMP가 전문적인 선택이 되었습니다.
다음 기사에서는 방법을 보여줍니다. 처음부터 첫 번째 KMP 프로젝트 설정: 소스 세트 구조, Gradle 버전 카탈로그, 최초 예상/실제 기능 및 통합 생산적인 개발 워크플로를 위해 Android Studio를 사용하세요.
시리즈: Kotlin Multiplatform — 하나의 코드베이스, 모든 플랫폼
- 제1조(본): 2026년 KMP — 아키텍처, 구축 및 생태계
- 기사 2: 첫 번째 KMP 프로젝트 구성 — Android, iOS 및 데스크톱
- 기사 3: 공유 모듈 아키텍처 - 예상/실제, 인터페이스 및 DI
- 기사 4: Ktor 클라이언트와의 멀티플랫폼 네트워킹
- 기사 5: SQLDelight를 사용한 다중 플랫폼 지속성
- 기사 6: Compose 다중 플랫폼 — Android 및 iOS의 공유 UI
- 기사 7: 상태 관리 KMP — ViewModel 및 Kotlin 흐름
- 기사 8: KMP 테스트 - 단위 테스트, 통합 테스트 및 UI 테스트
- 기사 9: Swift 내보내기 — iOS와의 관용적 상호 운용성
- 기사 10: KMP 프로젝트를 위한 CI/CD — GitHub Actions 및 Fastlane
- 기사 11: 사례 연구 — KMP를 활용한 핀테크 앱 제작







