Android 개발자가 iOS 개발자 없이 앱 출시하기: Compose Multiplatform 아키텍처 설계부터 운영까지 #우아콘2025 #우아한형제들

Common source set이 expect API를 선언하고 platform source set이 actual 구현을 제공하면 logger 같은 동기 platform 기능은 쉽게 감출 수 있다. 하지만 OS에서 먼저 들어오는 push event, callback으로 늦게 끝나는 store version check, 상태 변경을 통지하는 Firebase처럼 KMP를 지원하지 않는 native SDK는 common code가 흐름을 주도하지 못하므로 단순 expect/actual만으로 안정적인 bottom-up data flow를 만들기 어렵다.

Firebase Remote Config에서 권장 version을 읽은 Swift callback이 Compose의 강제 update dialog를 열어야 하므로 iOS source set에 public bridge object와 MutableStateFlow를 만들었다. Swift가 bridge의 update 함수를 호출하면 ComposeUIViewController가 lifecycle-aware하게 flow를 수집해 recomposition하므로, native SDK가 시작한 비동기 event를 common UI로 안전하게 올리는 역방향 통로를 확보했다.

KMP를 공식 지원하지 않는 Crashlytics를 위해 Kotlin iOS source set에 delegate interface를 두고 Swift 구현체가 native Firebase SDK를 호출한 뒤 app 시작 시 singleton logger에 주입하는 IoC 구조를 만들었다. 그러나 shared와 composeApp을 별도 XCFramework로 compile하자 각 framework가 같은 singleton을 다른 memory instance로 보아 injection이 사라졌고, 결국 shared를 composeApp에 합쳐 동작을 복구하는 대신 module isolation의 이점을 포기했다.

Kotlin Native CocoaPods Gradle plugin으로 pod dependency를 iOS source set에 직접 설치하면 Swift delegate 없이 actual 구현에서 Firebase를 부를 수 있다는 더 단순한 대안을 뒤늦게 확인했고, 비공식 Firebase Kotlin SDK나 KMP 지원 Sentry도 선택지로 제시한다. JetBrains 개발자도 interface injection을 현재의 실용적 해법으로 평가했으며, 8개월 운영 결과 UI 100%와 전체 code 약 97%를 Kotlin으로 유지해 Android 개발자의 가장 낮은 learning curve라는 장점을 검증했다.