# Kotlin Multiplatform 실제 도입기: 기대 vs 현실

# Kotlin Multiplatform 실제 도입기: 기대 vs 현실  Kotlin Multiplatform은 하나의 코드로 여러 플랫폼을 지원한다는 매력적인 제안을 내세운다. 하지만 실제 도입 과정에서는 이론과 현실 사이의 간극이 분명히 드러난다. 무엇을 공유할 수 있고, 무엇을 공유해야 하는지에 대한 판단이 필요한 지점에서 기술 선택의 본질적인 문제가 시작된다.  --- ## 코드 공유라는 약속 Kotlin Multiplatform(이하 KMP)의 핵심 제안은 명확하다. iOS, Android, 서버, 웹까지 하나의 코드베이스로 여러 플랫폼을 지원한다는 것이다. 이는 단순히 개발 시간을 줄이는 것을 넘어, 플랫폼 간 경계를 허무는 구조적 변화를 의미한다.  하지만 이 약속에는 두 가지 전제가 있다. 공유할 수 있는 로직이 명확히 존재해야 하고, 공유로 얻는 이득이 늘어나는 복잡성보다 커야 한다. 실제로 부딪히는 대부분의 문제는 이 전제가 충족되지 않는 지점에서 발생한다. KMP의 설계는 "expect/actual" 메커니즘으로 요약된다. 공통 코드에서 플랫폼별 구현을 선언(expect)하고, 각 플랫폼에서 실제 구현(actual)을 제공하는 방식이다. 이는 전형적인 추상화 패턴이지만, 동시에 개발자가 플랫폼 간 차이를 명시적으로 관리해야 한다는 의미이기도 하다. 코드 공유는 저절로 주어지지 않는다. 설계를 통해 만들어가야 한다. ## 기대: 이론 속 효율성 KMP 도입을 고려할 때 가장 먼저 떠오르는 기대는 중복 제거다. 비즈니스 로직, 데이터 모델, 네트워킹 레이어를 한 번만 작성하고 모든 플랫폼에서 재사용한다는 구상은 본질적으로 매력적이다. 특히 스타트업이나 소규모 팀에서 iOS와 Android 개발자를 모두 확보하기 어려운 상황이라면 현실적인 해법처럼 보인다.  두 번째 기대는 일관성이다. 동일한 코드가 모든 플랫폼에서 실행된다면, 플랫폼 간 동작 차이로 인한 버그를 구조적으로 방지할 수 있다. API 응답 파싱, 비즈니스 규칙 적용, 데이터 검증 로직이 완전히 동일하다면, 한 플랫폼에서만 테스트해도 다른 플랫폼의 품질을 어느 정도 보장할 수 있다. 세 번째는 유지보수의 단순화다. 비즈니스 요구사항이 변경되었을 때 하나의 코드만 수정하면 모든 플랫폼에 즉시 반영된다. 개발 속도가 빨라질 뿐 아니라 두 개의 코드베이스를 동기화하는 데 드는 커뮤니케이션 비용도 사라진다. 이론적으로 이 기대들은 타당하다. 문제는 현실이 이론의 전제를 충족하지 않는다는 데 있다.  ## 현실: 경계에서 드러나는 복잡성 실제 도입 과정에서 가장 먼저 마주하는 것은 공유 가능한 영역의 제한이다. UI 레이어는 본질적으로 플랫폼 종속적이다. iOS의 SwiftUI와 Android의 Jetpack Compose는 각자의 철학과 패턴을 가지고 있으며, 이를 통합하려는 시도는 양쪽 모두를 희석시킨다. Compose Multiplatform이 있긴 하지만, 이는 또 다른 학습 곡선과 생태계 의존성을 의미한다. 결국 공유할 수 있는 영역은 비즈니스 로직과 데이터 레이어로 좁혀진다. 하지만 여기서도 미묘한 차이가 발생한다. 플랫폼별 저장소(iOS의 Keychain, Android의 EncryptedSharedPreferences), 네트워킹 라이브러리의 세부 동작, 동시성 모델의 차이 등이 expect/actual 인터페이스를 늘어나게 만든다. 공유 코드의 비중이 예상보다 낮아지는 순간, 도입의 정당성이 흔들린다. 두 번째 현실은 생태계의 성숙도 문제다. 네이티브 개발에서 당연히 사용하던 라이브러리가 KMP를 지원하지 않는 경우가 많다. 대체 라이브러리를 찾거나 직접 래핑해야 하는데, 이는 개발 시간을 늘릴 뿐 아니라 유지보수 부담도 가중시킨다. Ktor, SQLDelight, Koin 등 핵심 라이브러리들은 안정적이지만, 특정 도메인(결제, 분석, 푸시 알림)의 라이브러리는 여전히 부족한 경우가 많다. 세 번째는 빌드 시스템과 도구의 복잡성이다. Gradle 멀티플랫폼 설정은 직관적이지 않다. iOS 빌드를 위한 Xcode 프로젝트 연동, CocoaPods 의존성 관리, 플랫폼별 빌드 타겟 설정은 초기 진입 장벽을 높인다. Android Studio와 Xcode를 오가며 디버깅해야 하는 상황은 개발 흐름을 단절시킨다. 특히 iOS 개발 경험이 없는 Android 개발자에게는 가파른 학습 곡선이다. 네 번째는 팀의 역량 분포다. KMP를 제대로 활용하려면 Kotlin, iOS 네이티브 API, Android 네이티브 API를 모두 이해해야 한다. 그러나 대부분의 팀은 Android 중심이거나 iOS 중심이다. 한쪽 플랫폼에만 익숙한 개발자가 다른 플랫폼의 특성을 이해하지 못한 채 공유 코드를 작성하면 오히려 품질이 저하된다. 플랫폼별 최적화가 무시되고, 각 플랫폼의 관례를 위반하는 코드가 양산된다. ## 언제 도입해야 하는가 그렇다면 KMP는 언제 의미 있는 선택이 되는가? 경험상 다음 조건들이 충족될 때 도입 효과가 극대화된다. 첫째, 비즈니스 로직이 복잡하고 플랫폼 독립적인 경우다. 금융 계산, 복잡한 상태 머신, 데이터 변환 로직 등이 여기에 해당한다. 반대로 UI 중심의 앱이나 플랫폼 고유 기능(카메라, 센서, AR)에 크게 의존하는 앱은 공유 가능한 영역이 제한적이다. 둘째, 팀이 Kotlin에 능숙하고 양쪽 플랫폼을 이해하는 경우다. KMP는 마법이 아니다. 플랫폼별 차이를 이해하고 적절히 추상화할 수 있는 역량이 필요하다. 팀이 Android만 다루어왔다면, iOS 네이티브 개발 경험을 먼저 쌓는 편이 낫다. 셋째, 점진적 도입이 가능한 구조인 경우다. 기존 네이티브 앱에 KMP 모듈을 부분적으로 추가하는 방식은 리스크를 최소화한다. 처음부터 전체 앱을 KMP로 구성하려는 시도는 대부분 실패한다. 작은 모듈(네트워킹 레이어 등)부터 시작해 점차 확장하는 전략이 현실적이다. 넷째, 장기적 관점의 투자 여력이 있는 경우다. 초기 설정과 학습에 드는 비용은 적지 않다. 단기 프로젝트나 빠른 검증이 필요한 MVP 단계에서는 네이티브 개발이나 Flutter 같은 성숙한 크로스플랫폼 프레임워크가 더 효율적일 수 있다. KMP의 진가는 중장기적으로 드러난다. ## 기술 선택의 본질 KMP를 둘러싼 기대와 현실의 간극은 기술 선택의 본질을 보여준다. 모든 기술은 트레이드오프다. 코드 공유는 추상화 비용과 교환되고, 일관성은 플랫폼 최적화 기회의 포기와 맞바꾼다. 중요한 것은 이 교환이 특정 상황에서 가치 있는지 판단하는 것이다. KMP가 실패하는 경우는 대개 기술 자체의 문제가 아니다. 도입 맥락과의 불일치에서 비롯된다. 팀의 역량, 프로젝트의 성격, 조직의 우선순위가 KMP의 전제와 맞지 않는데도 유행이라는 이유로 도입하면 복잡성만 증가한다. 반대로 KMP가 빛을 발하는 경우는 명확하다. 복잡한 도메인 로직을 다루고, Kotlin 생태계에 익숙하며, 장기적 관점에서 플랫폼 간 일관성에 가치를 두는 팀이라면 KMP는 강력한 도구가 된다. 이때 코드 공유는 단순한 중복 제거를 넘어 지식의 공유이자 조직 역량의 집중을 의미한다. ## 결론 Kotlin Multiplatform은 완성된 해법이 아니라 진행 중인 실험이다. 생태계는 여전히 성장하고 있으며, 도구는 계속 개선되고 있다. 하지만 기술의 성숙도와 별개로, 도입 결정은 현재의 맥락 안에서 이루어져야 한다. 기대는 가능성을 보여주지만, 현실은 제약을 드러낸다. 그 사이에서 의미 있는 선택은 자신의 상황을 정직하게 평가하고, 트레이드오프를 명확히 인식하는 데서 출발한다. KMP는 만능 해결책이 아니지만, 적절한 조건 아래에서는 탁월한 도구가 될 수 있다. 중요한 것은 기술 자체가 아니라, 그 기술을 사용하는 이유와 방식이다.