Kotlin Multiplatform은 Android 앱에서 공통 코드를 줄일 수 있는 매력적인 선택지입니다.
하지만 KMP를 “한 번 쓰면 Android와 iOS 코드가 거의 하나가 된다”로 이해하면 도입 후 실망하기 쉽습니다.
실제로 중요한 질문은 “무엇을 공유할 수 있나?”보다 “무엇을 공유해도 제품과 팀이 버틸 수 있나?”입니다.
Kotlin Multiplatform 도입 기준을 먼저 보기
KMP는 공통 코드를 늘리는 도구이기 전에 책임 경계를 정하는 설계 선택입니다.
가장 안전한 출발점은 UI가 아니라 domain/data layer 공유입니다.
KMP를 도입하면 좋은 경우
KMP가 잘 맞는 팀은 보통 플랫폼별 화면은 다르지만 비즈니스 규칙과 데이터 처리 흐름은 비슷한 경우입니다. 예를 들어 인증, 가격 계산, 캐시 정책, API DTO 변환, 오프라인 동기화 규칙은 플랫폼보다 제품 규칙에 가깝습니다.
- Android와 iOS가 같은 API와 같은 도메인 규칙을 쓴다
- 중복 구현 때문에 버그가 양쪽에서 다르게 난다
- 공통 로직을 테스트 코드로 강하게 묶고 싶다
- 팀 안에 Kotlin과 Gradle을 다룰 사람이 있다
이 조건이 맞으면 KMP는 단순히 파일 수를 줄이는 것보다 규칙의 일관성을 지키는 데 도움이 됩니다.
처음부터 UI까지 공유하려고 하면 어려워진다
Compose Multiplatform까지 고려하면 UI 공유도 가능해 보입니다. 다만 Android 앱 관점에서는 UI 공유가 항상 첫 단계는 아닙니다.
화면은 플랫폼별 내비게이션, 권한, 접근성, 입력 방식, 디자인 시스템과 강하게 연결됩니다. 이 영역까지 한 번에 공유하려 하면 작은 화면 수정도 공통 모듈 설계 문제로 커질 수 있습니다.
처음 KMP를 도입한다면 UI는 플랫폼별로 두고, 공통 모듈은 아래처럼 작게 시작하는 편이 현실적입니다.
// shared module
class PricePolicy {
fun finalPrice(base: Long, discountRate: Double): Long {
require(base >= 0)
return (base * (1.0 - discountRate)).toLong()
}
}이런 코드는 화면과 덜 얽혀 있고 테스트하기 쉽습니다. 반대로 Activity, Fragment, Compose navigation과 바로 연결된 코드를 공유하려 하면 비용이 커집니다.
KMP 도입 비용도 코드로 드러난다
KMP는 공통 코드를 만들지만 동시에 새로운 경계도 만듭니다. 공통 모듈의 의존성, 플랫폼별 구현, 빌드 설정, 테스트 환경을 이해해야 합니다.
- 공통 모듈에서 쓸 수 있는 라이브러리 제한
- expect/actual 구조를 이해해야 하는 비용
- Gradle 설정과 CI 시간이 늘어나는 문제
- 플랫폼별 디버깅 경로가 달라지는 문제
- 공통 코드 수정이 여러 앱 배포 일정에 영향을 주는 문제
그래서 KMP는 “코드를 줄여서 편해지는 기술”이라고만 보면 안 됩니다. 중복 비용을 줄이는 대신 경계 관리 비용을 새로 받는 선택입니다.
Android 앱에서 추천하는 도입 순서
보수적으로 시작하려면 다음 순서가 좋습니다.
- 순수 Kotlin 유틸리티와 값 객체
- 도메인 규칙과 validation
- API DTO와 mapper
- repository interface와 공통 use case
- 플랫폼별 storage, network, permission 구현
- 마지막으로 UI 공유 가능성 검토
이 순서의 장점은 실패해도 되돌리기 쉽다는 점입니다. 공통 모듈이 너무 넓어지기 전에 팀이 빌드, 테스트, 릴리스 흐름을 익힐 수 있습니다.
KMP를 미루는 게 나은 경우
아래 조건이라면 지금은 KMP보다 Android 앱 구조 자체를 정리하는 편이 낫습니다.
- Android 한 플랫폼만 운영한다
- 앱 내부 계층도 아직 정리되지 않았다
- 테스트가 거의 없어 공통화 후 회귀를 잡기 어렵다
- iOS 팀과 릴리스 리듬이 크게 다르다
- 공유할 로직보다 플랫폼별 UI 차이가 더 크다
공통화는 중복을 줄이지만 설계를 대신해주지는 않습니다. 기존 코드가 얽혀 있다면 KMP가 그 복잡도를 다른 모듈로 옮길 뿐일 수 있습니다.
정리
Kotlin Multiplatform은 Android 앱에서 충분히 검토할 가치가 있지만, 도입 기준은 “얼마나 많이 공유할 수 있나”가 아닙니다. “공유해도 안정적인 책임이 무엇인가”를 먼저 봐야 합니다.
Android 앱 구조를 먼저 정리하고 싶다면 Offline-first Android 앱 구조와 stateIn과 shareIn 글을 함께 보면 흐름이 이어집니다.
KMP의 공식 개념과 시작 방법은 Kotlin Multiplatform 공식 문서에서 확인할 수 있습니다.
