들어가며
일요일(12/21), Kotlin User Group Seoul에서 주최한 KMP 밋업에 다녀왔다. 아들이 생긴 이후 정말 오랜만에 개발자 모임에 나갔다. 그나마 최근 참석했던 모임은 모두 GDG Android 주관 행사였는데, 아는 분이 없는 커뮤니티 행사에 가려니 약간의 설렘과 뻘쭘함이 공존했다.
육아휴직 기간 동안 최근 KMP + CMP로 간단한 앱을 만들어볼까 싶어 이것저것 실험 중이다. 직접 코드를 짜는 게 귀찮아 대부분 Claude Code에 시키면서, Firebase를 이용한 인증이나 Metro를 이용한 DI 등을 테스트하고 있다. 마침 밋업 주제들이 내가 고민하던 지점들과 딱 맞아서 고민 없이 참석했다.
전체 발표 자료도 공유되었으니, KMP / CMP에 관심 있는 분들은 읽어보시면 큰 도움이 될 듯하다. 세션을 들으며 느꼈던 감상을 간단히 정리해본다.
세션별 정리
Compose Multiplatform 외부 의존성 아키텍처 설계부터 운영까지
CMP로 내부 사용자용 앱을 iOS / Android로 배포하며 겪은 경험을 공유해 주셨다. expect / actual은 KMP의 언어적 특성인데, 뒤에 나올 Metro 같은 DI를 사용할 경우 인터페이스만 선언하고 각 플랫폼별 구현체를 주입할 수 있다. 생성자도 동일해야 하는 등의 제약이 있어, DI를 쓰지 않을 때나 유용한 기능이 아닐까 하는 생각이 들었다.
모든 멀티플랫폼 기술은 플랫폼 특화 구현이 등장할 때 이를 얼마나 덜 고통스럽게 처리해 주느냐가 관건이라 생각한다. 이 발표에서는 Swift에서 Kotlin 코드의 함수를 자연스럽게 호출하여 네이티브 쪽 변경사항을 Kotlin에 반영하는 예시를 보여주었다. 또한 Kotlin에서 선언한 인터페이스의 구현체를 Swift로 작성해 제공하는 방법도 인상적이었다.
Kotlin/Native는 JNI처럼 Java와 Native 세상이 따로 존재하며 중재하는 역할이 아니라, 아예 Kotlin 코드가 Native 코드로 컴파일되어 나온다. 그 덕분에 Swift와 Kotlin 간의 상호 호출이 매우 자연스러운데, 이 점은 볼 때마다 놀랍고 아직 적응이 잘 안 된다.
다만, 멀티 모듈 상황에서 싱글톤 객체가 Swift와 Kotlin 영역에서 서로 다른 인스턴스로 존재할 수 있는 문제는 주의해야겠다. 관련 문서를 확인해 보니 여러 모듈을 묶은 Umbrella Module 이라는 통합 Kotlin 모듈을 만들어 처리하라고 권장한다. Android로 치면 app 모듈 아래에 모든 모듈이 모이는 umbrella 모듈을 하나 더 두는 구조가 될 것 같다.
Firebase 관련 내용도 언급되었다. 아직 Firebase는 공식 KMP SDK가 없어서 Android/iOS 버전을 따로 써야 한다. GitLive의 Firebase SDK가 대안이지만 모든 기능을 커버하진 못한다. 뒤에 나올 Supabase는 KMP를 잘 지원하는 것과 대조적이다. 개인적인 경험으로도 GitLive 연동은 그리 깔끔하지 않아 고통스러웠다.
만약 프로젝트를 다시 설계한다면 이렇게 구성해보고 싶다.
- 가입 및 사용자 인증 등 세션 기반 기능: Supabase
- FCM, Analytics, Crashlytics 등 세션과 무관한 기능: 각 플랫폼의 Native Firebase SDK
발표에서는 CocoaPods 설치도 다뤘는데, 나는 어떻게든 SPM(Swift Package Manager)으로 해결하는 편이 낫다고 본다. CocoaPods는 Android 개발자 입장에서 이해하기 어려운 괴랄한 문제들이 자주 발생하기 때문이다. 또한 회사에서 KMP 도입 시 "CocoaPods를 써야 한다"고 하면 iOS 개발자분들에게 어떤 반응을 얻을지 눈에 선하다. (안드로이드 프로젝트에 갑자기 Java로만 코딩하라는 느낌 아닐까.)
KMP와 UIKit으로 iOS 네이티브 앱 만들기
CMP로 앱을 출시해 본 분의 발표였는데 매우 흥미로웠다. KMP로 빌드할 때 Native Code가 만들어지는 컴파일 과정을 상세히 짚어주었고, Xcode 없이 손으로 하나하나 'Hello World' iOS 앱을 만드는 과정을 소개했다.
발표 내용 중 UIView와 MetalView의 오버레이 옵션이나 Alert 구현 방법 등은 나중에 iOS용 CMP 앱을 만들 때 실무적인 팁이 될 것 같다. 특히 ARC(Automatic Reference Counting)가 CMP 앱 개발에 영향을 끼칠 수 있다는 점은 귀동냥으로만 듣던 지식이 실제 개발에 어떻게 연결되는지 깨닫게 해준 지점이었다. 역시 멀티플랫폼을 잘하려면 양쪽 플랫폼을 깊이 있게 알아야 한다.
KMP + Supabase: 1인 개발의 새로운 패러다임
Firebase로 Google 로그인을 구현(Desktop/Android)하며 꽤 고통받았던 기억이 있는데, Supabase의 KMP SDK 발표를 보고 나니 다음엔 무조건 이걸 써야겠다는 생각이 들었다. Claude Code에게 잔소리하며 고생했던 것보다 라이브러리 차원의 지원이 훨씬 간편해 보였다. DB 쪽도 PostgreSQL 기반이라 SQL 사용이 자유롭고 API 생성도 직관적이었다.
Metro로 KMP에서 의존성 주입 사용하기
마지막은 새로운 DI 솔루션인 Metro 소개였다. 현재 토이 프로젝트에 Metro를 쓰고 있어 더 반가웠다. 과거 Dagger의 복잡함에 질려 Koin으로 갈아탔던 터라 '컴파일 기반 DI'에 선입견이 있었는데, Metro는 기억 속의 Dagger보다 훨씬 사용하기 편해 보였다. Anvil 같은 솔루션들의 장점을 잘 흡수한 듯하다.
발표에서는 뒷단에서 벌어지는 동작 원리도 설명해 주었다. Dagger가 Java 코드를 생성하는 방식이라면, Metro는 Kotlin Compiler Plugin으로 동작하여 IR(Intermediate Representation) 단에서 정보를 활용하므로 생성된 코드가 지저분하지 않고 깔끔하다. 특히 에러 메시지가 친절해졌다는 점이 가장 마음에 든다. Dagger 시절, 빌드 실패를 보면 초콜릿만 주워 먹으며 스트레스를 풀다 배만 나왔던 기억이 난다. 아직 1.0 버전은 아니지만, 토이 프로젝트에는 충분히 도입할 만한 수준이다.
마무리
집에서 Claude Code와 씨름하며 CMP를 가지고 놀다가, 같은 고민을 하는 분들의 깊이 있는 이야기를 들으니 즐겁고 자극이 되었다.
KMP가 앞으로 얼마나 더 잘 안착할지는 지켜봐야겠지만, 현재로선 Android와 Desktop 조합은 매우 깔끔해 보이고 iOS 쪽은 여전히 학습 곡선이 있어 보인다. UI를 제외한 로직 공유(KMP)라면 도입 가능성이 훨씬 높지 않을까 싶다. 이번 기회에 Kotlin User Group Seoul에도 가입했으니 앞으로 활발히 활동해봐야겠다. 멋진 행사를 준비해 주신 운영진과 발표자분들께 감사드린다.
Top comments (0)