그 많던 코드는 누가 다 먹었을까: Kotlin multiplatform을 활용한 서비스 런칭기 | 인프콘2023

11개월 개발 일정에서 세 달만 남은 시점에 Flutter 담당자가 이탈했고, 백엔드는 거의 끝났지만 클라이언트 기능은 사실상 시작되지 않은 위기를 맞는다. Android 네이티브 개발을 즉시 시작하고 iOS 개발자를 채용하되, 현재 Android 작업을 방해하지 않으면서 새 동료가 합류했을 때 실제 생산성을 높일 방법이 필요했다. 당시 알파였던 Kotlin Multiplatform이 두 조건을 만족할 가능성을 보여 작은 화면부터 직접 검증하기로 한다.

첫 시도는 데이터와 도메인 레이어만 공유했지만 iOS가 각 유스케이스의 입출력을 알아야 해 결합도가 높고 중첩 제네릭·sealed class 호환에도 문제가 생겼다. 뷰 모델까지 공유하자 결합이 줄었고, 여기에 단방향 데이터 흐름을 적용해 State와 Action만 노출하는 Store로 로직을 캡슐화했다. 네이티브 UI는 상태를 관찰하고 액션을 전달하는 데 집중할 수 있어 타입 문제와 학습 부담을 줄이면서 목표한 생산성을 확보했다.

공유 Store를 이용한 iOS 개발로 목표 일정에 서비스를 출시하고 중간의 주요 기능 피벗에도 대응했지만, Xcode 빌드에 공유 모듈이 포함돼 약 10분의 오버헤드가 생겼다. Android·iOS·공유 모듈을 한 저장소에 둔 탓에 코드베이스도 커지고 iOS 디버깅과 CI/CD가 어려워졌다. iOS 저장소를 분리하고 Android 쪽 공유 모듈을 CocoaPods로 배포했으며, 테스트와 로그를 보강해 남은 디버깅 위험을 완화했다.

API 문서 대신 화면 기준의 Store 문서를 전달하면 클라이언트 개발자가 비즈니스 해석보다 UI 구현에 집중할 수 있고 중복 코드도 줄어든다. iOS·Android 개발자 모두 큰 생산성 향상을 체감했지만 낯선 Kotlin 타입, 어려운 디버깅, 공유 로직 작성자에게 의존하는 구조와 메모리 모델의 러닝 커브를 단점으로 꼽았다. Kotlin Multiplatform은 강력한 대안이지만 모든 팀의 정답은 아니므로 자원·팀 구성·Kotlin 친숙도와 특성을 이해한 뒤 선택해야 한다.