모바일 앱 프레임워크 비교: 네이티브·하이브리드·크로스 플랫폼

모바일 앱을 만드는 방법은 크게 세 가지다. Android와 iOS를 각각 따로 만드는 네이티브, 웹 페이지를 앱 껍데기에 담는 하이브리드, 공통 코드 하나로 두 플랫폼의 네이티브 앱을 만드는 크로스 플랫폼. 두 플랫폼의 UI·기능이 서로 비슷해지면서 한 코드베이스로 둘 다 만드는 방식이 널리 쓰이게 됐다.

네이티브 앱

Android(Kotlin/Java), iOS(Swift/Objective-C)로 플랫폼마다 따로 개발한다.
성능, 최신 기능 지원, 플랫폼 고유의 UI 모두 가장 좋다.
대신 두 벌의 코드와 두 팀이 필요하다.

하이브리드 앱

Native + HTML. 앱 안에서 WebView(주소창이 없는 브라우저)를 띄우고 그 안에 웹 페이지를 보여 준다. 대표 프레임워크는 Ionic의 Capacitor이고, 그 전에는 Cordova(PhoneGap)가 쓰였다.

장점	단점
앱 개발 지식이 없어도 웹 기술로 개발 가능	UI를 전부 직접 만들어야 하고 네이티브 UI를 따라가기 어렵다
웹 페이지 하나로 웹·앱을 모두 서비스	속도가 느리다
화면만 바뀌면 앱 마켓 재심사 없이 업데이트	카메라·센서 등 기기 기능을 쓰기 어렵다
	화면을 매번 불러와 데이터 사용량이 많다

이름의 계보부터 헷갈린다. PhoneGap은 2009년 Nitobi가 만들었고, 2011년 Adobe가 회사를 사면서 오픈 소스 핵심을 Apache에 기증한 것이 Cordova다. Adobe는 2020년 PhoneGap과 클라우드 빌드 서비스 PhoneGap Build를 종료했다. 지금 새 프로젝트는 Capacitor로 시작하고, Cordova 플러그인 상당수를 Capacitor에서도 쓸 수 있다.

실수	왜 문제인가	대신
웹뷰를 브라우저나 웹 서버처럼 생각한다	웹뷰 앱은 서버가 아니다. PHP 같은 서버 코드는 돌지 않고, 브라우저 UI(주소창·뒤로 가기)도 없다	서버 로직은 API로 부르고, 화면 전환·뒤로 가기는 앱에서 처리한다
스크립트·CSS를 CDN에서 불러온다	오프라인에서 앱이 뜨지 않는다	자산은 앱 패키지에 넣는다
네이티브 준비 신호 전에 플러그인 API를 부른다	웹 코드가 네이티브 쪽보다 먼저 실행될 수 있다	Cordova는 `deviceready` 이벤트 뒤에, Capacitor는 플러그인 Promise로 호출한다
플랫폼·플러그인 버전을 고정하지 않는다	빌드할 때마다 최신 버전이 들어와 깨진다	버전을 고정하고 의도적으로 올린다
접근 허용 목록과 CSP를 빠뜨린다	외부 요청이 막히거나, 반대로 무엇이든 실행된다	허용할 도메인을 설정하고 `Content-Security-Policy`를 건다
웹사이트를 그대로 감싸 낸다	앱스토어·Google Play 정책은 웹사이트를 묶기만 한 앱을 거절한다	오프라인 동작·기기 기능처럼 앱으로서의 가치를 더한다. 그럴 게 없으면 PWA가 맞다

크로스 플랫폼 앱

하이브리드의 단점을 보완하려는 방식이다. 하이브리드는 기기 기능을 라이브러리로 감싸 웹에서 호출하느라 느렸다. 크로스 플랫폼은 공통 언어 하나로 작성하면 네이티브 UI·네이티브 앱으로 만들어 주므로 웹뷰를 거치는 하이브리드보다 성능에 유리하다.

대표: React Native(JavaScript/React), Flutter(Dart), Kotlin Multiplatform(Kotlin, Compose Multiplatform로 UI까지 공유), .NET MAUI(C#)
(레거시) Xamarin(C#)은 2024년 5월 1일 지원이 종료되었고, Microsoft는 후속인 .NET MAUI로 옮길 것을 권한다.

100% 네이티브처럼 만들 수 있을까?

아니다.

네이티브의 모든 기능을 제공하지는 못한다.
플랫폼에 새 기능이 나와도 프레임워크가 지원하기까지 시간이 걸린다.
프레임워크를 만든 회사의 사정에 따라 지원이 중단될 위험이 있다.
JS와 네이티브 사이의 브리지 병목은 크로스 플랫폼을 포기하는 흔한 이유였다. React Native는 0.76(2024)에서 New Architecture를 기본으로 바꾸고 0.82(2025)부터 이전 아키텍처를 없애 이를 구조적으로 풀었다. 자세한 내용은 React Native 기초 참고.

어떻게 고를까

상황	추천
모바일 개발을 처음 공부한다	네이티브. 원리를 알면 하이브리드·크로스 플랫폼은 쉽게 익힌다
빠르게 출시해 시장 반응을 보고 싶다	하이브리드 또는 크로스 플랫폼
이미 웹(React) 팀이 있다	React Native
최고의 성능·최신 기능이 필요하다	네이티브

스타트업처럼 두 플랫폼을 네이티브로 따로 만들 여력이 없다면, 크로스 플랫폼으로 먼저 출시해 반응을 본 뒤 필요하면 네이티브로 전환하는 전략도 가능하다.

왜 크로스 플랫폼을 찾게 되나

두 플랫폼을 네이티브로 따로 만들면 기획은 같이 해도 디자인 이후부터 일정이 갈라진다. 한쪽 개발자가 모자라면 그 플랫폼만 기능이 늦거나 빠진다. 기술 공유 모임, 네이밍 컨벤션 통일, 공통 라이브러리 같은 시도는 플랫폼이 다르면 오래 유지되기 어렵다. 크로스 플랫폼은 이 인력 불균형과 이중 작업을 구조적으로 줄인다. 반대로 걱정되는 것은 성능, 학습 비용, 그리고 기존 앱을 옮기거나 나중에 네이티브로 되돌아갈 때의 전환 비용이다.

평가 기준과 방법

후보를 고를 때는 같은 과제 앱을 후보마다 짧게 만들어 보고 기준별로 비교한다. 기본 UI와 네트워크 정도의 1차 과제로 추린 뒤, 지도·WebView·커스텀 UI·서드파티 라이브러리가 들어간 실제 서비스 수준의 2차 과제로 한계를 확인한다.

기준	확인할 것
학습 비용·가독성	언어와 UI 작성 방식이 익히기 쉬운가, 중첩이 깊어져도 읽히는가
서드파티·커뮤니티	필요한 라이브러리가 있는가, 막혔을 때 답을 찾을 수 있는가
개발 도구	IDE 지원, 디버거, 컴파일 속도, 핫 리로드
런타임 성능·안정성	애니메이션이 60fps 근처로 부드러운가, 크래시가 나는가
네이티브 호환성	기존 Kotlin·Swift 코드와 함께 쓸 수 있는가, 버전마다 API가 크게 바뀌는가
현지화·테스트	다국어 처리, 단위·위젯(컴포넌트)·통합 테스트를 나눠 할 수 있는가

Flutter는 브리지 없이 자체 엔진으로 화면을 직접 그려 네이티브와 구분하기 어려운 성능을 내고, 선언형 UI로 복잡한 화면을 빨리 만든다. 선언형 UI는 SwiftUI·Jetpack Compose도 택한 방향이라 네이티브 쪽도 같은 방식으로 수렴하고 있다. 구조는 Flutter의 구조와 위젯 트리에 있다.

코딩 에이전트가 바꾼 비용 계산

크로스 플랫폼을 고르는 가장 큰 이유는 같은 기능을 두 번 만드는 비용이었다. 코딩 에이전트가 이 비용을 크게 낮추면서, 대규모 앱이 크로스 플랫폼에서 네이티브(Swift·Kotlin)로 돌아가는 사례가 나왔다. Shopify는 2020년부터 React Native로 앱을 만들다가 2026년 네이티브로 다시 짓는 쪽으로 방향을 바꿨다.

관점	크로스 플랫폼을 고른 이유	에이전트가 있을 때
이중 구현	같은 기능을 두 번 만들지 않는다	한 플랫폼 구현을 참고 삼아 에이전트가 다른 플랫폼을 구현한다
기능 동등성	한 코드라 자동으로 맞는다	공통 명세·테스트·리뷰 체크포인트로 맞춘다
인력	웹 개발자가 앱까지 맡는다	에이전트가 주력 스택 밖 기여를 돕는다
남는 비용	성능 튜닝, 프레임워크 업그레이드, 의존성 관리	코드베이스 두 개의 유지 비용(여전히 있다)

네이티브는 플랫폼 기능과 1차 도구에 가깝고, 프레임워크·의존성 계층이 줄어든다. 두 코드베이스를 유지하는 비용은 사라지지 않았지만, 구현·테스트·리뷰의 상당 부분을 에이전트가 맡으면서 그 비용이 더는 결정적이지 않게 됐다.

에이전트로 대규모 이전을 할 때 드러난 원칙은 다음과 같다.

통째로 옮기게 하지 않는다. 에이전트에게 기존 코드베이스를 그대로 넘기면 크고 유지하기 어려운 코드가 나온다. 화면 하나를 작고 순서 있는 체크포인트로 쪼개고, 체크포인트마다 자체 테스트, 실행 중인 앱과의 시각 비교, 적대적 코드 리뷰, 사람의 승인을 거쳐야 커밋한다. 리뷰 피드백은 다음 체크포인트에 반영해 점점 자율성을 높인다.
피드백 루프를 짧게 만든다. 에이전트가 시뮬레이터를 접근성 트리나 스크린샷으로 조작하면 몇 초면 쓸 코드를 몇 분씩 확인한다. 비즈니스 로직을 UI에서 떼어 헤드리스(데스크톱 포함)로 돌리고, 상태 확인·화면 이동·동작을 CLI로 열어 주면 반복 주기가 크게 줄어든다.
점진 이전보다 새로 짓기를 고려한다. 에이전트가 재작성 속도를 높이면, 옛 제약을 안고 가는 점진적 이전(brownfield)보다 새로 짓기(greenfield)가 나을 수 있다. 다만 성능·안정성·접근성·제품 품질이 기존 이상이어야 한다는 기준은 그대로다.
전제가 바뀌면 결정을 다시 본다. 기술 선택은 당시의 비용 구조에 대한 답이다. 비용 구조가 바뀌면 같은 질문에 다른 답이 나온다.

핵심 정리

하이브리드 = WebView에 웹 페이지를 담은 앱(빠른 개발, 느린 성능).
크로스 플랫폼 = 하나의 코드로 네이티브 앱 생성(React Native, Flutter).
크로스 플랫폼도 네이티브를 100% 대체하지는 못한다. 기본기는 네이티브다.
코딩 에이전트가 이중 구현 비용을 낮추면 크로스 플랫폼의 핵심 이점이 줄어든다. 프레임워크 선택은 비용 구조가 바뀔 때마다 다시 따져 본다.

버그 제보