🚧 다시 Android 단독 프로젝트로 전환한 이유

2주간의 KMP 개발기 & 회고

---

🎯 결론

약 2주간 Kotlin Multiplatform(KMP)을 적용하며 개발을 진행해봤지만,

여러 기술적 제약과 시간 압박으로 인해

👉 Android / iOS 분리 개발(2 Track) 전략으로 최종 결정했다.

KMP를 포기한 건 아니지만,

지금 시점에서 KMP를 채택하는 것보다 일정 안정성이 더 중요하다는 판단이었고,

팀장님도 이를 이해해주셔서 과감히 방향을 바꿀 수 있었다.

---

🧩 KMP 진행 중 겪은 주요 이슈 정리

1️⃣

제한된 라이브러리 + 잦은 Breaking Changes

• KMP는 아직도 빠르게 진화 중
• JetBrains의 잦은 업데이트로 인해 → 기존 라이브러리들과 버전 호환성 문제 및 → 예상치 못한 운영 이슈가 발생할 가능성이 높다고 판단
  
• Android 위주로만 한다면 괜찮지만 정말로 cross-platform 개발을 하기엔 아직 리스크가 컸다.
  

---

2️⃣

정형화된 구조(Expect/Actual & SQLDelight)

KMP는 원하는 대로 “설계 자유도”가 높지 않다.

🔹 예시: SQLDelight

• DB 관련된 모든 코드를 sqldelight 패키지 안에 넣어야 함
  
• 구조적 자유도가 낮고 모듈화가 제한됨

🔹 예시: Expect / Actual

• commonMain/androidMain/iosMain 동일 패키지, 동일 네이밍
  
• 정해진 룰을 반드시 지켜야 해서 처음엔 상당히 헷갈리고 생산성이 떨어짐
  

⚠️ 개발할 때마다 “이건 어디에 넣어야 하지?” 라고 찾아야 하는 상황이 반복됨
→ 고민 시간 증가
→ 유지보수 난이도 증가

---

3️⃣

iOS 빌드 문제

KMP를 도입한 가장 큰 목적은 iOS 공용 코드 재사용이었는데…

• iOS에서 공통 모듈 함수가 인식이 안 되거나
• 빌드는 되지만 런타임에서 함수 이름 변경 문제 발생
• KMP + Swift 연결 과정도 쉽지 않음

❗ 이슈 분석 시간이 길어지다 보니, 데드라인 안에 기능 개발을 끝낼 수 없다는 판단이 생겼다.

---

🧠 최종 판단

이런 문제들을 매번 해결하면서 개발을 진행하기에는

• 일정 압박
• 기능 요구 증가
• KMP 경험 부족
• 실서비스 안정성

이 네 가지 조건이 너무 부담이었다.

그래서 팀장님께 현재 상황을 솔직하게 공유했고,

Android 우선 개발 → iOS는 뒤에서 별도로 진행

이렇게 “Two Track 전략”으로 가기로 결정했다.

팀장님이 이해해주신 것도 너무 감사했고,

덕분에 과도한 리스크 없이 빠르게 방향을 잡을 수 있었다.

---

🔙 2주간의 회고

솔직히 말하면…

“2주 동안 난 뭘 한 거지…?” 라는 생각이 잠깐 스쳤다. 하지만 곧 생각이 바뀌었다.

✔ KMP라는 기술을 직접 체감해봤고

✔ 구조적 제약과 문제점을 몸으로 이해했고

✔ 앞으로 KMP를 언제 적용해야 하는지 기준을 세웠고

✔ 팀 방향성에 도움을 줄 판단을 내릴 수 있었다

이건 결코 헛된 시간이 아니었다.

오히려 더 튼튼한 Android 구조를 만들 수 있을 것 같은 자신감이 생겼다.

---

🔥 앞으로의 목표

Android 앱이 현재 회사의 핵심이다.

팀장님의 신뢰에 보답하기 위해

→ 더 완성도 높은 아키텍처

→ 더 안정적인 코드

→ 더 빠른 기능 구현

을 목표로 다시 Android 개발에 집중할 예정이다.

---

✨ 마무리

돌고 돌아 다시 Android 단독 개발로 돌아왔지만,

지식도 늘었고, 실전 감각도 좋아졌고,

앞으로 KMP를 적용할 때 실패 없이 할 수 있는 경험을 쌓은 셈이다.

이제 다시 Android 코드 쓰러 간다.

🔥 “다시 화이팅!”