본문 바로가기
모바일2026년 8월 21일6분 읽기

크로스플랫폼 3파전 — Flutter·React Native·Kotlin Multiplatform, 무엇을 고를까

YS
김영삼
조회 3
크로스플랫폼 3파전 — Flutter·React Native·Kotlin Multiplatform, 무엇을 고를까

모바일 앱 하나를 만들려면 iOS와 안드로이드를 따로 개발해야 한다는 오랜 상식은 이제 예외에 가깝다. 지금 크로스플랫폼 시장은 Flutter, React Native, Kotlin Multiplatform의 삼파전으로 재편됐고, 셋은 같은 목표를 완전히 다른 철학으로 푼다. "무엇이 제일 나은가"보다 "우리 팀·우리 앱에 무엇이 맞는가"가 진짜 질문이 됐다.

재미있는 건 이 셋이 서로를 밀어내며 수렴하는 게 아니라, 각자의 영역을 확실히 나눠 가지는 방향으로 굳어지고 있다는 점이다. 승자독식이 아니라 삼각 균형이다.

Flutter는 화면을 직접 그리고, React Native는 네이티브를 빌리며,
Kotlin Multiplatform은 로직만 공유한다.

이 한 문장에 세 진영의 세계관 차이가 다 담겨 있다. UI를 얼마나 공유하고 얼마나 네이티브에 맡길 것인가가 선택의 갈림길이다.

3진영
Flutter·RN
·KMP
DartJS·KT
각기 다른
주력 언어
UI공유율
100%~0%
선택 스펙트럼
데스크톱
모바일 넘어
확장 경쟁

세 진영의 세계관

Flutter — 픽셀을 직접 그린다

Flutter는 플랫폼의 네이티브 위젯을 거의 쓰지 않는다. 대신 자체 렌더링 엔진으로 모든 픽셀을 직접 그린다. 덕분에 iOS와 안드로이드에서 화면이 100% 똑같이 나오고, 애니메이션이 매끄럽다. 브랜드 아이덴티티가 강하고 화면 전체를 장악하고 싶은 앱, 예컨대 커스텀 디자인이 촘촘한 서비스에 잘 맞는다. 대신 각 OS의 최신 네이티브 룩앤필을 그대로 따라가려면 손이 더 간다.

React Native — 네이티브를 빌린다

React Native는 반대다. 화면을 직접 그리지 않고 실제 플랫폼의 네이티브 컴포넌트를 자바스크립트로 조종한다. 그래서 각 OS의 기본 느낌을 자연스럽게 살리고, 무엇보다 방대한 웹 개발자 인력과 리액트 생태계를 그대로 끌어올 수 있다. 자바스크립트 브리지가 병목이던 시절도 있었지만, 새로운 아키텍처로 네이티브와의 통신 방식을 대폭 개선하면서 그 약점을 상당히 덜어냈다.

Kotlin Multiplatform — 로직만 나눈다

가장 다른 접근이 KMP다. UI는 각 플랫폼의 네이티브(SwiftUI, 안드로이드)로 따로 만들고, 네트워크·비즈니스 로직·데이터 계층만 코틀린으로 공유한다. "UI는 네이티브가 제일 낫다, 하지만 규칙과 계산은 두 번 짤 이유가 없다"는 실용주의다. 기존 네이티브 앱에 점진적으로 도입할 수 있다는 점이 큰 무기다. 여기에 Compose Multiplatform을 얹으면 UI까지 공유하는 길도 열린다.

무엇으로 고를까

선택은 취향이 아니라 조건의 문제다. 아래가 현실적인 판단 기준이다.

  • 팀 구성 — 웹·리액트 개발자가 많다면 React Native의 학습 곡선이 가장 완만하다. 안드로이드 네이티브 팀이 이미 있다면 KMP가 자연스럽다.
  • UI 통일성 vs 네이티브다움 — 두 OS에서 똑같은 화면을 원하면 Flutter, 각 OS의 표준 느낌을 지키고 싶으면 RN이나 KMP+네이티브 UI.
  • 기존 앱 유무 — 이미 큰 네이티브 앱이 있고 조금씩 공유 코드를 늘리고 싶다면 KMP의 점진적 도입이 위험이 가장 적다.
  • 확장 범위 — 하나의 코드로 웹·데스크톱까지 노린다면 Flutter의 커버리지가 넓다.
항목FlutterRN / KMP
렌더링자체 엔진으로 직접네이티브 위젯 사용
언어DartJS·TS / Kotlin
UI 공유전면 공유공유 or 네이티브 선택
점진적 도입까다로움KMP가 특히 유리

수렴이 아니라 분업이다

몇 년 전만 해도 "결국 하나가 이길 것"이라는 예측이 많았다. 지금 흐름은 반대다. 세 진영은 각자 잘하는 영역에서 자리를 굳혔고, 큰 조직일수록 상황에 따라 둘을 병행하기도 한다. 신규 앱은 Flutter로 빠르게, 기존 네이티브 앱은 KMP로 로직을 공유하는 식이다. 크로스플랫폼의 승부는 "누가 표준이 되느냐"에서 "언제 무엇을 쓰느냐"로 이동했다.

자주 묻는 질문

세 가지 중 성능이 가장 좋은 건 무엇인가요?

단순 서열은 의미가 없다. UI를 각 네이티브로 만드는 KMP가 이론상 네이티브에 가장 가깝고, Flutter는 자체 엔진 덕에 애니메이션이 매끄럽다. 대부분의 앱에서는 세 방식 모두 체감 성능이 충분하며, 병목은 프레임워크보다 앱 설계에서 생긴다.

지금 새로 배운다면 무엇이 유리한가요?

배경에 따라 다르다. 웹 개발 경험이 있으면 React Native, 안드로이드 경험이 있으면 Kotlin Multiplatform이 익숙하다. 아무 배경이 없고 앱 개발 자체가 목표라면 문서와 학습 자료가 풍부한 Flutter가 진입이 수월한 편이다.

KMP는 UI를 공유하지 못하나요?

기본 개념은 로직만 공유하고 UI는 네이티브로 만드는 것이지만, Compose Multiplatform을 함께 쓰면 UI까지 공유할 수 있다. 즉 로직만 나눌지, UI까지 나눌지를 프로젝트가 선택할 수 있다는 점이 KMP의 유연함이다.

크로스플랫폼이면 네이티브 개발자가 필요 없나요?

그렇지 않다. 카메라, 결제, 백그라운드 처리 같은 플랫폼 고유 기능을 다루거나 스토어 심사 이슈를 풀 때 네이티브 지식은 여전히 필요하다. 크로스플랫폼은 네이티브를 없애는 게 아니라 중복 작업을 줄이는 도구에 가깝다.

댓글 0

아직 댓글이 없습니다.
Ctrl+Enter로 등록