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

안드로이드 개발자가 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

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

Scripts