[음악] [음악] 네, 안녕하세요. [웃음] 오늘 반응을 많이 해 주시네요.

안드로이드 개발자가 iOS 개발자 없이 앱 출시하기: 컴포즈 멀티플랫폼 아키텍처 설계부터 운영까지의 주제로 발표할 김수현입니다.

[박수] 네. 발표 시작에 앞서 어떤 분들이 제 발표를 들으러 와 주셨는지 좀 궁금해서 혹시 여기 계신 분들 중에 안드로이드 개발하시는 분 계실까요?

어, 감사합니다. 그럼 iOS 개발하시는 분도 손 들어 주실 수 있나요?

어, iOS 개발하시는 분들도 좀 계시는군요.

제가 iOS 개발자였다면 제목을 보고 아, 감히 이렇게 생각했을 것 같은데, 과연 iOS 없이 어떻게 앱을 개발하고 운영했을지 어, 예상하셨겠지만 그렇게 행복한 스토리는 아닙니다.

그래서 한번 이야기를 풀어가 보도록 할게요.

저는 우아한 형제들에서 안드로이드 개발자이자 교육자로 일하고 있는데요.

개발자를 위한 교육 프로그램인 오안테크 코스의 안드로이드 교육 분야를 운영하고 있습니다.

회사에서 안드로이드 개발을 시작한 지 7년이 되었고 그중에서도 멀티플랫폼은 2년째 개발을 하고 있습니다.

그리고 GDG 코리아, 안드로이드 나이츠 같은 개발자 커뮤니티에서도 운영진으로 참여하는 등 개발자 커뮤니티를 만들어 나가는데 관심이 많습니다.

어, 제 사진이 저렇게 크게 뜰 줄 몰랐는데.

네. 실무량이 좀 달라도 양해 부탁드리겠습니다.

어, 들어가기 전에 발표에 대해 몇 가지 말씀드리자면, 어, 먼저 이 내용은 iOS 개발이 거의 없는 어, 개발 경험이 거의 없는 안드로이드 개발에 익숙한 사람의 경험을 바탕으로 했습니다.

그래서 iOS 개발자분들이 보시기에 조금 불편한 점이 있으실 수도 있어요.

그리고 KMP나 컴포즈 멀티플랫폼의 기초 개념 설명은 시간 관계상 좀 최소화하였고 짧은 발표 시간 내에 여러분들이 다른 곳에서도 좀 보기 힘든 내용을 전달하는 게 중요하다고 생각해서, 실제 앱 운영기를 좀 많이 담을 수 있도록 노력을 했습니다.

슬라이드가 80장이어서 좀 빠르게 발표해야 됩니다.

그래서 제가 정답을 제시하기보다는 케이스 스터디 위주로 구성을 하는 걸 목표로 해서 설계와 코드 레벨의 고민이 많이 포함되어 있고, 들으시면서 더 좋은 제안이나 의견이 있다면 언제든지 토론을 환영합니다.

그래서 오늘 발표에서는 코틀린 멀티플랫폼, 더 구체적으로는 컴포즈 멀티플랫폼을 사용하여 저희 우아한 테크코스의 인하우스 앱을 개발하고 운영했던 경험을 나누려고 합니다.

희망편부터 시작해서 현실은 그다지 녹록지 않음을 보여주는 절망편으로 이어집니다.

그리고 개발 과정에서 마주한 세 가지 케이스 스터디를 공유하면서 저희 팀이 얻었던 러닝과 코드 레벨의 고민을 나눠 보겠습니다.

순서대로 네이티브 상태의 옵저버를 고민 그리고 KMP 미지원 라이브러리인 파이어베이스를 어떻게 연동하고 아키텍처를 설계했는지, 그리고 iOS 모듈의 코코아팟 의존성을 왜 어떻게 설치했는지입니다.

마지막으로 코틀린 2025에서 제프레임스 개발자들에게 저희 아키텍처를 직접 피드백 받은 이야기도 한번 풀어 보겠습니다.

그러면 첫 번째 챕터, 컴포즈 멀티플랫폼 희망편입니다.

컴포즈 멀티플랫폼에 익숙하지 않으신 분들을 위해 간단하게만 설명드리겠습니다.

제프레임스에서 만든 기술인 컴포즈 멀티플랫폼의 공식 홈페이지에 가 보면 이런 문구가 나옵니다.

하나의 코드 베이스, 두 개의 플랫폼, 안드로이드의 선형 UI 경험을 iOS로 확장.

먼저 코틀린 멀티플랫폼의 경우에는 코틀린 언어를 사용해서 앱의 공통 로직을 한 번만 작성하고 이 코드를 안드로이드, iOS, 데스크톱, 웹 등 여러 플랫폼에서 함께 공유하는 기술입니다.

여기서의 공통 로직이란 사용자에게 보여지지 않는 도메인 로직, 네트워크 통신, 비즈니스 규칙 등을 말하는데요.

컴포즈 멀티플랫폼은 이러한 코틀린 멀티플랫폼의 개념을 UI까지 확장한 겁니다.

원래 안드로이드 앱 개발용으로 만들어진 재Compose라는 선언형 UI 프레임워크를 iOS나 데스크톱에서도 사용할 수 있게 만든 기술입니다.

특히 제가 안드로이드 개발자로서 가장 주목했던 포인트는 두 가지였는데요.

이미 제가 잘 알고 있는 재Compose 기술, 상태 관리, 레이아웃 애니메이션 API를 그대로 활용해서 멀티플랫폼 앱을 개발할 수 있고 상호 운용 가능하다는 점이 상당한 장점으로 느껴졌습니다.

한마디로 완드 개발자에게는 좀 어렵다고 생각했었는데 사실 이건 좀 어마무시한 착각이었지만 자세한 건 이따 절망편에서 말씀드리겠습니다.

저희 팀 상황을 좀 더 구체적으로 말씀드릴게요.

저희는 우아테크 코스라는 교육 플랫폼을 운영하고 있는 만큼 내부 교육생들이 사용하는 인하우스 앱, 일종의 출결 관리 앱을 만들어야 했습니다.

그런데 문제는 저희 팀 모바일 개발자 구성이 저를 포함해서 모두 안드로이드 개발자였는데요.

심지어 요구 사항은 2개월 이내에 출시해야 해서 새로운 기술 스택을 배울 시간은 없었고 팀의 iOS 개발자는 당연히 없었어요.

그리고 한 가지 더 하자면 백엔드 개발자분들도 코틀린 스택을 사용하고 있었습니다.

그래서 저희는 이게 완전 컴포즈 멀티플랫폼을 시도하기 딱 좋은 환경처럼 보였어요.

그래서 결국 안드로이드 개발자들끼리 iOS 개발자 없이 멀티플랫폼 개발을 시도하게 됩니다.

그래서 처음에 계획했던 모듈 구성은 다음과 같은데요. 사실 KMP 프로젝트를 처음 생성하면 보이는 모듈 구성이랑 같습니다.

가장 중심에 있는 컴포즈 앱이라는 모듈에서는 안드로이드 메인, iOS 메인, 그리고 커먼 메인을 위치시키는데요.

이게 바로 핵심입니다. 여기에 안드로이드와 iOS 환경에서 쓰이는 UI와 비즈니스 로직을 둡니다.

안드로이드 메인의 메인 액티비티는 커먼 메인의 앱.

kt를 실행만 시키고, iOS 메인에서는 컴포즈 UIViewController로 앱.

kt를 감싸서 네이티브 iOS 앱의 컨텐츠 뷰.

스위프트가 이걸 그냥 띄워 주기만 하는 거죠.

그리고 서버와 데스크톱 앱에서도 공유하고 있는 쉐어드 모듈에 공통 도메인 로직을 두어서 같은 클래스를 여러 번 작성하지 않아도 되도록 설계를 했습니다.

즉 이론상 컴포즈 UI를 100%로 구성하면 iOS나 스위프트 문법을 몰라도 개발이 가능해 보입니다.

이미 컴포즈 UI가 iOS 플랫폼으로 구동되는 로직은 구성이 되어 있고 코틀린 언어 하나만으로 UI와 비즈니스 로직을 전부 구성할 수 있으니까요.

그리고 놀랍게도 처음에는 이게 잘 작동했습니다.

약 2개월 간의 짧은 개발 기간 끝에 MVP 버전을 안드로이드와 iOS 양대 플랫폼에 성공적으로 출시했고 정말로 컴포즈 UI를 100%로 구성해서 스위프트 문법을 하나도 몰라도 작성을 할 수가 있었습니다.

그리고 파이어베이스 디스트리뷰션이나 테스트 플라이트를 활용해서 150명의 교육생들에게 배포를 하고 실제로 5년까지 할 수 있었습니다.

마침 5월에 컴포즈 멀티플랫폼의 1.8.0 버전이 출시되면서 iOS도 스테이블 단계로 격상이 되었고 저희의 선택은 매우 현명해 보였습니다.

하지만 희망적인 부분을 얘기했으면 당연히 절망 편도 있겠죠.

KMP가 플랫폼별 코드를 다루는 기본적인 방법은 익스펙트 액추얼 API입니다.

어, KMP를 해보신 분들은 좀 익숙하실 API일 텐데요.

간단하게만 설명을 드리자면, 어 커먼 메인 모듈에서 예를 들어서 나는 이런 기능이 필요할 거야라고 익스펙트로 선언만 해둡니다.

그러면 각 플랫폼 모듈 안드로이드 메인과 iOS 메인에서 이 선언에 대한 실제 구현, 즉 액추얼 코드를 각자의 네이티브 라이브러리를 사용해서 제공하는 방식이죠.

예를 들어서 공통 로거 클래스를 만든다고 해볼게요. 일반적으로 iOS에서는 콘솔의 로그를 출력하기 위해 NSLog 함수를 사용하는 반면 안드로이드에서는 플랫폼에서 제공하는 별도의 로그 함수를 또 사용해야 됩니다.

이렇게 각각 다른 플랫폼의 API를 대응하기 위해서 커먼 메인에 익스펙트 오브젝트 로그라고 선언을 하고 로깅 레벨에 따른 함수 시그니처를 정의합니다.

iOS 메인과 안드로이드 메인 각각에서 액추얼 오브젝트 로그를 만들고 각각 네이티브 NS 로그 함수를 호출하는 거죠.

이러면 커먼 메인에서는 각 플랫폼의 의존성을 알지 못하더라도 각 플랫폼 스페시픽한 API를 호출할 수 있게 됩니다.

하지만 문제는 이 익스펙트 액추얼 API만으로는 대응하기 어려운 상황이 너무나도 많았다는 것입니다.

저희가 마주했던 대표적인 세 가지 상황을 설명드리겠습니다.

첫 번째 상황은 네이티브 UI 이벤트 전달입니다. 가장 대표적인 예로 푸시 알람을 꼽을 수 있겠는데요.

푸시 알람은 커먼 메인에서 시작하는 것이 아니라 OS가 기기로 직접 이벤트를 전달해야 합니다.

이 알림을 탭하면 네이티브 코드가 먼저 이벤트를 받게 되죠.

그리고 이 네이티브 코드가 공유 모델에 있는 비즈니스 로직, 예를 들어서 특정 화면으로 이동하라는 로직을 트리거해야 됩니다.

이처럼 푸시 알림은 네이티브의 이존성이 필수적이라서 커먼 메인이 이 흐름을 주도할 수가 없고 네이티브에서 시작된 이벤트를 공통 로직으로 올려보내야 됩니다.

두 번째는 비동기 플랫폼 로직입니다. 저희가 실제로 구현했던 강제 업데이트 확인 기능을 예로 들어 볼게요.

예를 들어서 앱이 처음 구동될 때 앱스토어나 플레이 스토어에 새로운 필수 업데이트 버전이 있는지 확인해야 한다고 가정을 해 볼게요.

이는 플랫폼마다 각각 다른 방식의 비동기 호출을 필요로 할 텐데요.

플랫폼 코드가 백그라운드에서 이 작업을 수행하고 한참 뒤에 완료가 되면 콜백이나 리스너를 통해 커먼 메인의 결과를 전달해 줘야 됩니다.

하지만 커먼 메인의 단순한 익스펙트 함수는 즉시 반환되는 값을 기대하기 때문에 이런 비동기적인 지연 응답을 처리할 수가 없습니다.

사실 세 번째가 가장 큰 문제였는데 바로 KMP를 지원하지 않는 서드파티 네이티브 SDK 연동입니다.

저희의 경우에는 파이어베이스 SDK를 연동해야 했습니다.

네이티브 파이어베이스 SDK를 사용해서 리모트 컨피그 값을 가져온다고 가정을 해 보면은 어 파이어베이스 콘솔에서 이 값이 변경되었을 때 우리 앱에 공유된 컴포즈 UI도 이 변경 사항을 즉시 반영해서 리컴포지션이 돼야 됩니다.

여기서 핵심은 우리 코드가 파이어베이스의 상태를 직접 요청하는 것이 아니라 파이어베이스 SDK가 상태 변경을 알려주는 콜백을 구현해야 합니다.

그리고 익스펙트 액추얼 구조로는 이러한 구조를 구현하기가 굉장히 까다롭습니다.

지금 당장 줄글 설명만으로 이해되지 않으셔도 이따가 각각의 케이스를 어떻게 해결했는지 코드로 같이 살펴보도록 할게요.

그러면 첫 번째 케이스인 네이티브 상태 옵저버 구현 사례를 보여드리도록 하겠습니다.

앞서 말씀드렸던 강제 업데이트 기능입니다. 요구 사항은 파이어베이스 리모트 컨피그 같은 외부 SDK를 통해 권장 앱 버전을 가져와서 만약 현재 버전이 권장 버전보다 낮으면 화면에 보이는 스크린샷처럼 업데이트 해 주세요라는 다이얼로그를 띄우고 앱의 초기 진입을 막는 것이었습니다.

아까 보여 드렸던 초기 모듈 구성 계획을 다시 보면 저희의 원래 계획은 커먼 메인에서 모든 UI를 100% 그리는 게 목표였죠.

하지만 이 구조만으로 핸들링할 수 없는 이유는 강제 업데이트 버전 정보는 파이어베이스 SDK, 즉 네이티브 iOS 앱 모듈에서 가져와야 하기 때문입니다.

그렇다면 iOS 모듈, 즉 스위프트 코드에서 발생하는 이 이벤트를 어떻게 코틀린 모듈에 있는 우리 컴포즈 UI가 수신해서 모달을 띄워 줄 수 있을까요?

공유 모듈에서 네이티브 의존성을 갖지 않도록 의존 방향을 설계했는데, 역으로 네이티브 이벤트를 수신해야 한다는 상황으로 보시면 될 것 같습니다.

긴말하기보다 우리는 개발자니까 코드로 바로 볼게요. 기존 코드는 이렇게 구성되어 있습니다.

이건 KMP 프로젝트를 처음 만들면 보여지는 코드 구성 모듈인데, 이제 iOS 메인에서는 메인뷰 컨트롤러 함수가 그저 앱을 f.KT KT 컴포저브를 컴포즈 UI 뷰 컨트롤러로 감싸서 반환하는 것이 전부였습니다.

iOS 앱의 스위프트 코드 즉 컴포즈 뷰는 이러한 메인 뷰 컨트롤러를 호출해서 화면을 노출시키는 역할만 하고 있었죠.

그래서 저희는 iOS 메인의 브릿지를 만들기로 했습니다. 먼저 iOS 메인의 쉐어드뷰 컨트롤러라는 오브젝트를 만듭니다.

이게 오브젝트로 구현된 것은 사실 크게 중요하지 않습니다. 내부에 있는 코드를 잠깐 보면, 내부에 뮤터블 스테이트 플로우를 두어서 저희가 관찰할 리퀴어드 앱 버전 코드 강제 업데이트를 트리거하는 코드죠.

이걸 포함하는 뷰 스테이트를 이 스테이트 플로우가 들고 있게 합니다. 그리고 메인 뷰는 이제 이 메인 뷰를 통해서 화면을 업데이트할 수 있습니다.

컨트롤러, 즉 컴포즈 UI를 생성하는 부분에서는 상태 점검과 상태 라이프사이클을 사용해서 이 상태 플로우를 라이프사이클 어웨어하게 구독합니다.

이제 뷰 상태가 변경이 되면 if 구문 내에서 리컴포지션이 발생하고 UI가 자동으로 업데이트 되며 UI는 항상 최신 값을 볼 수 있도록 만들 수 있습니다.

그리고 업데이트 요구된 앱 버전이라는 함수를 외부의 퍼블릭으로 노출시킵니다. 이 함수는 스위프트 코드에서 호출될 것이며 호출되면 상태 플로우의 값을 업데이트합니다.

이렇게 네이티브에서 발생한 이벤트를 컴포즈 UI로 안전하게 전달하는 브릿지를 완성해서 코틀린 모듈에서도 스위프트 코드의 변경 사항을 수신하여 리컴포지션으로 트리거할 수 있습니다.

그러면 스위프트 코드가 어떻게 호출되고 있는지도 한번 볼게요. iOS 앱의 ContentView.swift에 스위프트의 make UI 뷰 컨트롤러 함수를 보면 이전처럼 메인 뷰가 있습니다.

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

우아한형제들의 기술조직 이야기를 전하는 우아한테크입니다.

우아한형제들 https://www.woowahan.com/
우아한테크 Facebook https://www.facebook.com/woowahanTech
우아한형제들 기술블로그 https://techblog.woowahan.com

우아한테크

컴포즈 멀티플랫폼은 안드로이드 개발자가 가장 낮은 러닝 커브로 멀티플랫폼 앱을 개발할 수 있도록 지원하며, 우아한테크코스 앱 개발 사례에서 UI 로직의 100%를 공통 코드로 작성하고 약 97%의 코드를 코틀린으로 작성하는 데 성공하여 기술적 안정성을 입증했습니다.

KMP 미지원 라이브러리(예: 파이어베이스) 연동 시 익스펙트/액추얼만으로는 한계가 있어, 네이티브 UI 이벤트를 컴포즈 UI로 전달하기 위한 브릿지와 상태 흐름을 활용하거나 IOC(제어의 역전) 패턴을 통해 의존성을 주입하는 방식이 효과적인 해결책이 될 수 있습니다.

KMP 커뮤니티는 아직 발전 중이며, 최적의 아키텍처나 모범 사례가 정립되는 과정에 있으므로, 개발자들이 겪는 문제와 해결책을 적극적으로 공유하고 논의하는 것이 중요합니다.

우아한형제들 안드로이드 개발자 김수현입니다. 저는 안드로이드 개발자가 iOS 개발자 없이 앱을 출시하는 주제로 발표를 진행합니다. **iOS 개발 경험이 거의 없는 안드로이드 개발자의 경험을 바탕으로** KMP 및 컴포즈 멀티플랫폼의 기초 개념 설명은 최소화하고, 실제 앱 운영기를 중심으로 케이스 스터디를 공유합니다. 저희 팀은 우아한 테크코스의 인하우스 앱을 컴포즈 멀티플랫폼으로 개발하고 운영했습니다.

컴포즈 멀티플랫폼(KMP)은 JetBrains에서 만든 기술로, **하나의 코드 베이스로 안드로이드와 iOS 두 플랫폼에 앱을 출시**할 수 있게 합니다. 코틀린 언어를 사용하여 앱의 공통 로직(도메인, 네트워크 통신, 비즈니스 규칙 등)을 한 번만 작성하고 여러 플랫폼에서 공유합니다. 특히 컴포즈 멀티플랫폼은 코틀린 멀티플랫폼의 개념을 UI까지 확장하여, 안드로이드용 Jetpack Compose UI 프레임워크를 iOS나 데스크톱에서도 사용할 수 있게 합니다. 안드로이드 개발자에게는 이미 익숙한 Compose 기술을 활용해 멀티플랫폼 앱을 개발할 수 있다는 점이 큰 장점으로 다가왔습니다.

저희 팀은 안드로이드 개발자로만 구성되어 있었고, 2개월 이내에 우아한 테크코스 인하우스 앱(출결 관리 앱)을 출시해야 했습니다. iOS 개발자는 없었고, 백엔드 개발자도 코틀린 스택을 사용하고 있었기에, **컴포즈 멀티플랫폼을 시도하기에 완벽한 환경**이라고 판단했습니다. 초기 계획은 KMP 프로젝트의 기본 모듈 구성과 같이 '컴포즈 앱' 모듈에 안드로이드와 iOS의 UI 및 비즈니스 로직을 두고, '쉐어드' 모듈에 공통 도메인 로직을 두는 것이었습니다. 이론상 컴포즈 UI를 100% 구성하면 iOS나 Swift 문법을 몰라도 개발이 가능해 보였습니다.

놀랍게도 초기에는 이 방식이 잘 작동했습니다. 약 2개월의 짧은 개발 기간 끝에 안드로이드와 iOS 양대 플랫폼에 MVP 버전을 성공적으로 출시했습니다. **정말로 컴포즈 UI를 100%로 구성하여 Swift 문법을 전혀 모른 채 개발이 가능**했습니다. Firebase Distribution과 TestFlight를 활용해 150명의 교육생들에게 배포하고 운영까지 할 수 있었으며, 마침 Compose Multiplatform 1.8.0 버전이 출시되어 iOS도 스테이블 단계로 격상되면서 저희의 선택은 매우 현명해 보였습니다.

컴포즈 멀티플랫폼: 절망편과 문제 해결

KMP의 기본적인 플랫폼별 코드 처리 방식은 `expect/actual` API를 사용합니다. `commonMain` 모듈에서 필요한 기능을 `expect`로 선언하고, 각 플랫폼 모듈(AndroidMain, iOSMain)에서 해당 선언에 대한 실제 구현(`actual` 코드)을 네이티브 라이브러리를 사용하여 제공하는 방식입니다. 하지만 이 방식만으로는 **대응하기 어려운 상황이 너무나 많았습니다.**

저희가 마주했던 대표적인 세 가지 상황은 다음과 같습니다. 첫째, **네이티브 UI 이벤트 전달** (예: 푸시 알림). OS가 기기로 직접 이벤트를 전달하고 네이티브 코드가 먼저 받은 후, 공유 모델의 비즈니스 로직을 트리거해야 합니다. 둘째, **비동기 플랫폼 로직** (예: 강제 업데이트 확인). 앱스토어/플레이 스토어의 업데이트 여부를 확인하는 것처럼 플랫폼마다 다른 비동기 호출이 필요하며, `expect` 함수는 즉시 반환되는 값을 기대하기 때문에 지연 응답 처리가 어렵습니다. 셋째, **KMP를 지원하지 않는 서드파티 네이티브 SDK 연동** (예: Firebase SDK). Firebase의 상태 변경을 알려주는 콜백을 구현해야 하는데, `expect/actual` 구조로는 구현이 매우 까다로웠습니다.

케이스 스터디 1: 네이티브 상태 옵저버 구현

첫 번째 케이스는 강제 업데이트 기능 구현이었습니다. Firebase Remote Config 같은 외부 SDK를 통해 권장 앱 버전을 가져와 현재 버전이 낮으면 업데이트 다이얼로그를 띄우고 앱 진입을 막는 것이 요구사항이었습니다. 문제는 **강제 업데이트 버전 정보가 네이티브 iOS 앱 모듈에서 가져와야 한다는 것**이었습니다. iOS 모듈에서 발생하는 이벤트를 코틀린 모듈의 Compose UI가 수신하여 모달을 띄우는 방법을 고민했습니다.

해결책으로 iOS Main 모듈에 **브릿지(Bridge) 역할을 하는 `SharedViewController` 오브젝트를 생성**했습니다. 이 오브젝트는 `MutableStateFlow`를 통해 `requiredAppVersionCode` (강제 업데이트 트리거 코드)를 포함하는 `ViewState`를 들고 있습니다. Compose UI를 생성하는 부분에서는 `remember`와 `LaunchedEffect`를 사용하여 이 `StateFlow`를 라이프사이클에 맞춰 구독했습니다. `updateRequiredAppVersion` 함수를 외부에 공개하여 Swift 코드에서 호출될 때 `StateFlow`의 값을 업데이트하도록 했습니다. 이로써 네이티브에서 발생한 이벤트를 Compose UI로 안전하게 전달하는 브릿지를 완성하여, 코틀린 모듈에서도 Swift 코드의 변경 사항을 수신하고 UI를 리컴포지션할 수 있었습니다.

Swift 코드에서는 `ContentView.swift`의 `makeUIViewController` 함수에서 `SharedViewController`의 `mainView` 컨트롤러를 호출하도록 변경했습니다. 또한 `fetchRemoteConfig` 함수를 만들어 Swift에서 직접 iOS용 Firebase SDK를 호출하고, 성공 콜백에서 받은 값을 `updateRequiredAppVersionCode` 함수로 호출하여 **코틀린의 `StateFlow`로 전달**했습니다. 이로써 네이티브에서 시작해서 공통 UI로 올라오는 '바텀업' 데이터 흐름을 완성하여 강제 업데이트 기능을 구현할 수 있었습니다.

케이스 스터디 2: KMP 미지원 라이브러리 연동 (Firebase)

두 번째 케이스는 KMP를 지원하지 않는 Firebase SDK 연동 문제였습니다. 저희의 목표는 모든 로직을 `commonMain`에 넣고 UI를 100% Compose로 그리는 것이었으나, **Firebase Crashlytics 연동 시 KMP SDK가 공식 지원되지 않아** 안드로이드와 iOS 네이티브 모듈에 각각 SDK를 설치해야 했습니다. 기존 `expect/actual` 기반의 로그 코드에 Crashlytics 리포트 기능을 추가해야 했습니다.

안드로이드의 경우 `commonMain`의 `expect` 함수에 대한 `actual` 구현체인 `shared/androidMain` 모듈에서 Firebase Android KTX 라이브러리를 직접 사용하여 Crashlytics 코드를 한 줄 추가하는 것으로 간단히 해결되었습니다. 하지만 iOS는 코틀린 네이티브 환경이어서 Swift로 작성된 네이티브 Firebase SDK를 직접 참조할 수 없었습니다. 이를 해결하기 위해 **IOC(Inversion of Control) 패턴을 활용한 아키텍처를 설계**했습니다.

해결 계획은 다음과 같습니다. 먼저 `shared/iOSMain` 모듈에 `FirebaseCrashlyticsDelegate` 인터페이스를 정의합니다. iOS 앱 모듈에서는 이 인터페이스의 실제 구현체를 Swift로 만들고, 앱 시작 시 이 Swift 구현체를 `shared/iOSMain`의 `Log` 객체에 주입시켜 줍니다. 이로써 `Log.iOS`는 실제 구현이 Swift에 있는지조차 모르고 델리게이트의 함수를 호출하여 의존성을 참조할 수 있게 됩니다. Swift 코드에서 네이티브 Firebase SDK를 초기화하고, `initCrashlyticsDelegate` 함수를 통해 `Log` 객체에 Swift 구현체 인스턴스를 주입했습니다. **코틀린 멀티플랫폼은 Swift와 코틀린을 연결하는 상호 운용 API를 많이 제공**합니다.

이 구조를 통해 Firebase Crashlytics SDK를 각 플랫폼에 연동하여 공통 로직에서 발생할 수 있는 에러들을 각 플랫폼에서 트래킹할 수 있는 기반을 만들었습니다. 이는 IOC, 즉 제어의 역전 구조로, 저수준 모듈(iOS 앱)이 고수준 모듈(shared)을 의존하는 과정에서 의존성의 흐름을 역전하여, iOS 앱이 실제 구현체를 만들고 이를 상위 모듈인 `shared`에 주입하여 제어권을 가져오는 방식입니다. 이렇게 애널리틱스나 리모트 컨피그 등도 연동할 수 있었습니다.

모듈 분리의 함정과 아키텍처 재고

완벽해 보였던 계획과 달리 모듈 분리 과정에서 문제가 발생했습니다. `shared` 모듈과 `composeApp` 모듈을 별도의 XC 프레임워크로 컴파일되도록 분리했는데, iOS 환경에서 이 두 프레임워크가 **서로 다른 메모리 영역에서 작동하는 것**으로 보였습니다. 테스트 결과, `shared` 모듈에 주입한 인스턴스와 `composeApp`이 바라보는 인스턴스가 서로 달랐습니다. 이 문제를 해결하기 위해 **`shared` 모듈을 제거하고 iOS 앱이 `composeApp`에 직접 델리게이트를 주입**하도록 아키텍처를 수정했습니다. 모든 로직이 `composeApp`이라는 올인원 모듈 안에 움직이게 되면서 메모리 문제는 사라졌으나, 모듈 분리를 통해 얻을 수 있는 이점을 잃게 되었습니다.

이 경험을 통해 `shared` 모듈이 과연 꼭 필요했을까 하는 근본적인 질문이 생겼습니다. JetBrains의 Matvei Bragin이 LinkedIn에 올린 글에 따르면, KMP를 위한 새로운 기본 프로젝트 구조가 작업 중이며, 기존 올인원 `composeApp` 모듈을 **플랫폼별 앱 모듈과 별도의 공유 모듈인 `shared-logic`, `shared-ui`로 분리**할 것이라고 합니다. 이는 저희가 처음에 시도했던 구조와 유사하며, JetBrains가 이 구조를 공식화하면서 저희가 겪었던 싱글톤 인스턴스 문제를 해결해 나갈 것으로 보입니다.

문제 해결을 위한 대안으로는 **Firebase 팀에 KMP 공식 SDK 지원을 요청**하는 것(현재 1200명 이상이 공감), 비공식 Firebase Kotlin SDK인 **KMMBridge (GitLiveApp)** 사용 (아직 필요한 기능이 개발되지 않아 사용 못 함), 또는 Firebase를 대체할 수 있는 Sentry처럼 **KMP를 공식 지원하는 다른 로깅 SDK를 선택**하는 방법 등이 있습니다.

케이스 스터디 3: iOS 모듈에 SPM 또는 CocoaPods 설치

외부 라이브러리 연동을 위한 더 좋은 방법에 대한 고민에서 시작된 세 번째 케이스는 iOS 모듈에 SPM (Swift Package Manager) 또는 CocoaPods를 설치하는 방법이었습니다. 한 개발자는 **네이티브 CocoaPods 플러그인을 사용하여 `expect/actual` 방식으로 Firebase를 연동**했다고 조언했습니다. 실제로 GitLiveApp의 Firebase Kotlin SDK 저장소를 살펴보니, `appleMain` 소스셋에서도 CocoaPods를 통해 Firebase 의존성을 가져오고 있는 것을 확인할 수 있었습니다.

이 구현 방식은 코틀린 멀티플랫폼 공식 문서에서도 찾아볼 수 있습니다. 코틀린 네이티브는 CocoaPods 의존성 관리자와의 통합을 제공하며, Xcode를 켤 필요 없이 **안드로이드 스튜디오나 IntelliJ에서 Gradle 플러그인을 통해 Pod 의존성을 관리**할 수 있습니다. `composeApp` 모듈의 `build.gradle.kts` 파일에 네이티브 CocoaPods 플러그인을 추가하고, `kotlin` 블록 내부에 `cocoapods` 블록을 만들어 Firebase Crashlytics 같은 네이티브 의존성을 직접 설치할 수 있습니다. 이 방법을 사용했다면, 저희가 겪었던 복잡한 델리게이트 주입 및 IOC 과정 없이 iOS Main에서도 `expect/actual`을 활용할 수 있었을 것입니다.

KotlinConf 2025에서 JetBrains 개발자들에게 저희 아키텍처에 대한 직접적인 피드백을 받을 기회가 있었습니다. KMP를 지원하지 않는 Firebase와 같은 서드파티 라이브러리 연동에 대해 질문했을 때, 처음에는 표준 C 인터페이스 접근 방식이 언급되었지만, Firebase SDK는 C-interop 방식만으로는 해결하기 어렵다는 답변을 들었습니다. 이후 **저희 팀의 아키텍처(commonMain에 인터페이스 정의, 플랫폼별 네이티브 구현체 만들어 주입)를 설명하자, 두 개발자 모두 현재 가능한 최선의 실용적인 해결책이라고 평가**했습니다. 이는 저희의 노력이 헛되지 않았음을 확인시켜 주었고, KMP 생태계가 아직 베스트 프랙티스를 만들어 가는 과정에 있다는 것을 다시 한번 느낄 수 있었습니다.

8개월간 앱을 운영하며 얻은 핵심 러닝은 다음과 같습니다. 자잘한 버그는 있었지만, 기술적인 문제는 없었으며, **UI 로직만큼은 100% 컴포즈(공통 코드)로 만들 수 있었다**는 것입니다. 약 97%의 코드를 코틀린으로 작성했고, Swift 코드는 브릿지나 델리게이트처럼 꼭 필요한 부분에만 사용했습니다. 이는 안드로이드 개발자에게 러닝 커브를 낮추는 매력적인 기술 스택입니다. 나아가 저희 팀은 서버 코드도 코틀린 기반으로 만들어서 향후 서버 코드까지 같은 코틀린 프로젝트로 합칠 계획입니다. 즉, **서버와 클라이언트 플랫폼 모두를 코틀린으로 운영할 수 있다는 점이 큰 장점**이었습니다. iOS에서의 디자인 정합성 문제도 스테이블 출시 이후 사소한 UI 어긋남 외에는 매우 안정적이었습니다.

결론적으로, 컴포즈 멀티플랫폼은 **안드로이드 개발자가 가장 낮은 러닝 커브로 멀티플랫폼을 개발할 수 있는 스택**입니다. KMP 커뮤니티는 아직 발전 중이며, 저희와 같은 개발자들이 계속해서 더 좋은 방법을 연구하고 공유해야 합니다. 저희의 경험과 해결책, 그리고 대안적인 방법들이 다른 개발자들에게 도움이 되기를 바랍니다.

발표자가 안드로이드 개발자임에도 불구하고 iOS 개발자 없이 앱을 출시할 수 있었던 주요 요인은 무엇인가요?

KMP(Kotlin Multiplatform)를 사용하여 앱을 개발하고 운영하면서 발표자가 겪었던 가장 큰 어려움 세 가지는 무엇이며, 각 문제를 어떻게 해결했나요?

Firebase SDK와 같이 KMP를 공식 지원하지 않는 서드파티 라이브러리를 연동할 때 발표팀이 사용한 IOC(제어의 역전) 패턴은 구체적으로 어떤 방식으로 작동했나요?

발표자가 JetBrains 개발자들로부터 아키텍처 피드백을 받은 경험은 KMP 생태계의 현재 상황과 어떤 관련이 있나요?

Compose Multiplatform을 사용하여 앱을 개발하고 8개월간 운영한 경험을 바탕으로, 이 기술 스택이 안드로이드 개발자에게 제공하는 가장 큰 장점은 무엇이며, 아직 개선이 필요한 부분은 무엇이라고 생각하시나요?

발표자는 김수현이며, 우아한 형제들에서 안드로이드 개발자 겸 교육자로 7년간 안드로이드 개발, 2년간 멀티플랫폼 개발을 했다.

발표 내용은 iOS 개발 경험이 거의 없는 안드로이드 개발자의 경험을 바탕으로 하며, KMP 및 컴포즈 멀티플랫폼 기초 개념 설명은 최소화하고 실제 앱 운영 경험에 집중한다.

발표는 정답 제시보다 케이스 스터디 위주로 구성되어 설계 및 코드 레벨의 고민을 공유하며, 토론을 환영한다.

우아한 테크코스의 인하우스 앱 개발 및 운영 경험을 다루며, 희망편, 절망편, 세 가지 케이스 스터디(네이티브 상태 옵저버, KMP 미지원 라이브러리 연동, iOS 모듈 코코아팟 의존성), 그리고 제트브레인스 개발자 피드백 순으로 진행된다.

컴포즈 멀티플랫폼 희망편 및 초기 성공 사례

컴포즈 멀티플랫폼은 하나의 코드 베이스로 안드로이드와 iOS 두 플랫폼에 선언형 UI 경험을 확장하는 기술이다.

코틀린 멀티플랫폼은 공통 로직(도메인, 네트워크, 비즈니스 규칙)을 코틀린으로 한 번 작성하여 여러 플랫폼에서 공유하며, 컴포즈 멀티플랫폼은 이 개념을 UI까지 확장한다.

안드로이드 개발자로서 기존 Jetpack Compose 기술, 상태 관리, 레이아웃 애니메이션 API를 그대로 활용하여 멀티플랫폼 앱을 개발할 수 있다는 점이 큰 장점으로 다가왔다.

팀 상황은 모두 안드로이드 개발자였고, 2개월 이내 앱 출시, iOS 개발자 부재, 백엔드도 코틀린 스택을 사용하고 있어 컴포즈 멀티플랫폼 시도에 적합해 보였다.

초기 모듈 구성은 `composeApp` 모듈에 안드로이드, iOS, 커먼 메인을 두고 UI 및 비즈니스 로직을 공유하며, `shared` 모듈에는 공통 도메인 로직을 두어 100% 컴포즈 UI로 개발 가능해 보였다.

2개월의 짧은 개발 기간 끝에 MVP 버전을 안드로이드와 iOS 양대 플랫폼에 성공적으로 출시했으며, 컴포즈 UI를 100% 구성하여 Swift 문법을 모르고도 개발 가능했다.

파이어베이스 디스트리뷰션 및 테스트 플라이트를 활용하여 150명 교육생에게 배포 및 5년간 운영할 수 있었고, 컴포즈 멀티플랫폼 1.8.0 버전 출시와 함께 iOS도 스테이블 단계로 격상되어 선택이 현명해 보였다.

컴포즈 멀티플랫폼 절망편: 익스펙트 액추얼 API의 한계

KMP의 기본적인 플랫폼별 코드 처리 방식인 익스펙트 액추얼 API는 `commonMain`에서 기능을 선언하고 각 플랫폼 모듈에서 네이티브 라이브러리를 사용하여 실제 구현을 제공한다.

하지만 익스펙트 액추얼 API만으로는 대응하기 어려운 상황이 많았으며, 세 가지 대표적인 상황은 네이티브 UI 이벤트 전달, 비동기 플랫폼 로직, KMP 미지원 서드파티 네이티브 SDK 연동이었다.

케이스 스터디 1: 네이티브 상태 옵저버 구현 (강제 업데이트 기능)

요구 사항은 파이어베이스 리모트 컨피그를 통해 권장 앱 버전을 가져와 현재 버전보다 낮으면 업데이트 다이얼로그를 띄우고 앱 초기 진입을 막는 것이었다.

초기 계획은 커먼 메인에서 모든 UI를 그리는 것이었으나, 강제 업데이트 정보는 네이티브 iOS 앱 모듈에서 가져와야 하므로 네이티브 이벤트를 코틀린 모듈의 컴포즈 UI가 수신해야 했다.

해결책으로 iOS 메인에 `SharedViewController` 오브젝트를 만들고, 내부에 `MutableStateFlow`를 두어 강제 업데이트 트리거 코드를 관찰했다.

컴포즈 UI 생성 부분에서 이 상태 플로우를 라이프사이클 어웨어하게 구독하여 뷰 상태 변경 시 UI가 자동으로 업데이트되도록 했다.

`updateRequiredAppVersion` 함수를 외부 퍼블릭으로 노출시켜 Swift 코드에서 호출하면 상태 플로우 값을 업데이트하도록 구현했다.

Swift 코드의 `ContentView.swift`에서 `SharedViewController`의 `mainViewController`를 호출하도록 변경하고, `updateRequiredAppVersion` 함수를 통해 파이어베이스 SDK에서 가져온 값을 코틀린의 스테이트 플로우로 전달하여 바텀업 데이터 흐름을 완성했다.

케이스 스터디 2: KMP 미지원 외부 라이브러리(파이어베이스) 연동 및 아키텍처 고민

초기 목표는 모든 로직을 `commonMain`에 넣고 UI를 100% 컴포즈로 그리는 것이었으며, `composeApp` 모듈과 `shared` 모듈을 분리하여 `shared`에는 범용적 익스펙트 액추얼 구현체를, `composeApp`에는 UI와 뷰모델을 담는 구조를 구상했다.

파이어베이스 크래시리틱스 연동 요구사항이 발생했으나, 파이어베이스는 KMP SDK를 공식 지원하지 않아 안드로이드와 iOS 네이티브 모듈에 각각 SDK를 설치해야 했다.

안드로이드에서는 `shared` 안드로이드 메인 모듈의 로그 파일에 파이어베이스 의존성을 임포트하고 액추얼 함수 내부에 크래시리틱스 코드를 한 줄 추가하는 것으로 간단히 해결했다.

iOS에서는 코틀린 네이티브 환경이므로 Swift로 작성된 네이티브 파이어베이스 SDK를 직접 참조할 수 없어, `shared` iOS 메인에 `CrashlyticsDelegate` 인터페이스를 정의하고, iOS 앱에서 실제 구현체를 Swift로 만들어 앱 시작 시 `shared` 모듈의 로그 객체에 주입하는 IOC(제어의 역전) 구조를 사용했다.

문제는 모듈 분리 과정에서 `shared` 모듈과 `composeApp` 모듈이 별도의 XC 프레임워크로 컴파일되면서 iOS 환경에서 서로 다른 메모리 영역에서 작동하여 싱글톤 인스턴스 문제가 발생했다.

해결책으로 `shared` 모듈을 제거하고 iOS 앱이 `composeApp`에 직접 델리게이트를 주입하도록 아키텍처를 수정했으나, 모듈 분리의 이점은 잃게 되었다.

이 경험을 통해 `shared` 모듈이 꼭 필요했는지에 대한 의문이 들었으나, 제트브레인스에서 KMP를 위한 새로운 기본 프로젝트 구조(플랫폼별 앱 모듈 + `sharedLogic`, `sharedUI` 모듈 분리)를 작업 중이며, 이는 초기 시도했던 구조와 유사하여 향후 싱글톤 인스턴스 문제를 해결할 것으로 기대된다.

다른 대안으로는 파이어베이스 팀에 KMP 공식 SDK 지원을 요청하거나, 비공식 파이어베이스 코틀린 SDK (GitLive 앱)를 사용하거나, KMP를 공식 지원하는 다른 로깅 SDK (예: Sentry)를 선택하는 방법이 있다.

케이스 스터디 3: iOS 모듈에 SPM 또는 코코아팟 설치하기

외부 라이브러리 연동을 위한 더 좋은 방법에 대한 고민에서 `native.cocoapods` 플러그인을 사용하여 익스펙트 액추얼로 파이어베이스를 연동했다는 의견이 나왔다.

GitLive 앱의 파이어베이스 코틀린 SDK 저장소에서 애플 메인 소스셋에서 코코아팟을 통해 파이어베이스 의존성을 가져오는 것을 확인했다.

코틀린 멀티플랫폼 공식 문서에서도 코코아팟 통합이 명시되어 있으며, Xcode를 켤 필요 없이 안드로이드 스튜디오나 인텔리제이에서 그레이들 플러그인을 통해 팟 의존성을 관리할 수 있다고 설명되어 있다.

`composeApp` 모듈의 `build.gradle.kts` 파일에 `native.cocoapods` 플러그인을 추가하고 코틀린 블록 내부에 코코아팟 블록을 만들어 파이어베이스 크래시리포트 의존성을 직접 추가할 수 있다.

이 방법을 사용했다면 복잡한 델리게이트 주입 과정 없이 iOS 메인에서도 익스펙트 액추얼을 사용할 수 있었을 것으로 추측된다.

제트브레인스 개발자 피드백 및 결론

코틀린 컴프 2025에 방문하여 제트브레인스 개발자들에게 KMP를 지원하지 않는 서드파티 라이브러리 연동 베스트 프랙티스에 대해 질문했다.

처음에는 표준 C 인터페이스 접근 방식을 제안받았으나, 파이어베이스 SDK는 해당 방식만으로는 해결하기 어렵다는 추가 피드백을 받았다.

팀의 아키텍처(커먼 메인에 인터페이스 정의, 플랫폼별 네이티브 구현체 만들어 주입)를 설명하자, 제트브레인스 개발자들은 현재 가능한 최선의 실용적인 해결책이라고 평가했다.

결론적으로 KMP 커뮤니티는 아직 발전 중이며, 개발자들이 계속해서 더 좋은 방법을 연구하고 공유해야 한다.

8개월간 앱을 운영하면서 자잘한 버그는 있었으나 기술적인 문제는 없었으며, UI 로직은 100% 컴포즈(공통 코드)로 만들 수 있었다.

약 97%의 코드를 코틀린으로 작성하고, Swift 코드는 브릿지나 델리게이트처럼 꼭 필요한 부분에만 사용하여 안드로이드 개발자에게 낮은 러닝 커브를 제공했다.

서버 코드도 코틀린 기반이어서 향후 서버 코드까지 같은 코틀린 프로젝트로 합칠 계획이며, 서버와 클라이언트 플랫폼 모두를 코틀린으로 운영할 수 있는 것이 큰 장점이다.

iOS에서의 디자인 정합성 문제도 안정적이었으며, 컴포즈 멀티플랫폼은 안드로이드 개발자가 가장 낮은 러닝 커브로 멀티플랫폼을 개발할 수 있는 스택이라고 평가할 수 있다.

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

스크립트