스타트업이 네이티브 앱을 만들면 망하는 이유 (Flutter 도입기)
1. 돈도 없고 사람도 없다
창업 초기, 나와 프리랜서 한 명이 전부였습니다. 통장 잔고는 매달 말라가고 있었고, 투자자들은 "빨리 앱 런칭해서 지표를 가져오라"고 조르고 있었습니다. 그런데 서비스는 iOS와 Android 앱이 모두 필요했죠.
기술 스택을 결정해야 하는 순간, 선택지는 두 가지였습니다.
- Native (Swift + Kotlin): 성능 최고. UX 완벽. 애플과 구글이 밀어주는 정석. 하지만 코드를 두 번 짜야 함. 인력도 2배로 필요함.
- Cross-Platform (Flutter / React Native): 성능 90%. 코드 한 번 짜면 양쪽 출시.
개발자로서의 욕심은 당연히 Native였습니다. "앱은 손맛이지! 애니메이션 60프레임 칼같이 나와야지! 플랫폼 가이드라인 딱 맞춰야지!"
하지만 대표로서의 이성은 Cross-Platform을 가리키고 있었습니다. "우리 지금 망하기 일보 직전인데, 언제 Swift 공부하고 Kotlin 공부할래? 개발자 뽑을 돈은 있고?"
결국 눈물을 머금고 Flutter를 선택했습니다. 개발자로서의 자존심을 버리고, 창업가로서의 생존을 선택한 것입니다. 그리고 1년 뒤, 이 선택은 우리 회사를 살린 신의 한 수가 되었습니다.
2. Flutter: 마약 같은 생산성 (Hot Reload)
Flutter를 쓰면서 가장 충격받은 건 Hot Reload(핫 리로드)였습니다. 과장이 아니라, 이건 앱 개발의 역사를 바꾼 기능입니다.
코드를 수정하고 저장(Cmd+S)하면, 0.5초 만에 앱 화면이 바뀝니다. 앱을 다시 빌드하거나 재시작할 필요가 없습니다. 상태(State)도 유지됩니다.
- Native 개발: 코드 수정 -> 컴파일 -> 빌드 -> 설치 -> 실행 (최소 1분) -> 확인 -> 오타 발견 -> 수정 -> 빌드 (또 1분)... (복장 터짐, 여기서 유트브 봄)
- Flutter 개발: 코드 수정 -> 짠! -> 수정 -> 짠! (쾌감, 몰입도 최강)
이 속도 차이는 단순한 시간 절약이 아닙니다. 개발자의 몰입(Flow)을 끊지 않는다는 게 핵심입니다. 하루에 수정하고 테스트할 수 있는 UI 횟수가 10배는 차이 났습니다. 덕분에 우리는 2명이서 2달은 걸릴법한 작업을 3주 만에 끝내고 MVP를 출시할 수 있었습니다.
3. "근데 네이티브 느낌 안 나지 않나요?" (불쾌한 골짜기)
가장 걱정했던 건 UX의 이질감이었습니다. 옛날 하이브리드 앱(웹뷰 껍데기, Ionic, PhoneGap 등)을 써본 분들은 아실 겁니다. 그 특유의 버벅거림과 "웹사이트 같은 느낌". 버튼을 눌렀는데 반응이 반박자 늦는 그 불쾌한 골짜기 말이죠.
하지만 Flutter는 달랐습니다.
네이티브와 다른 렌더링 방식 (Skia Engine)
기존의 크로스 플랫폼(React Native 등)은 자바스크립트로 로직을 짜면, 그걸 네이티브 컴포넌트(iOS의 UIButton, Android의 Button)로 변환해서 보여주는 방식(Bridge)이었습니다. 그래서 가끔 통신 병목이 생기면 느려졌죠.
반면 Flutter는 운영체제의 UI 컴포넌트를 아예 안 씁니다. 대신 Skia라는 C++ 그래픽 엔진을 내장해서, 화면의 픽셀 하나하나를 직접 그립니다. 마치 유니티(Unity) 게임 엔진으로 게임을 만드는 것과 똑같은 원리입니다.
그래서 다음과 같은 장점이 생깁니다.
- 일관성: 아이폰에서 보든, 갤럭시에서 보든, 구형 폰에서 보든 똑같이 예쁘게 나옵니다. OS 업데이트 탓을 안 해도 됩니다.
- 성능: 중간 다리(Bridge) 없이 바로 GPU를 써서 그리기 때문에, 60fps~120fps 애니메이션이 부드럽습니다.
물론 100% 네이티브 같진 않았습니다. 스크롤 감도나 내비게이션 전환 효과가 미세하게 달랐죠. 하지만 일반 사용자의 99%는 눈치채지 못했습니다. 오직 개발자들만 "어? 이 스크롤 관성이 iOS 순정보다 0.1초 긴데?" 하고 시비 걸 뿐이었죠. 사용자는 그냥 "앱이 예쁘네" 하고 씁니다.
4. 물론 지옥도 있었습니다 (Native Library & 채용)
물론 꽃길만 있진 않았습니다. 크로스 플랫폼의 한계는 명확했습니다.
1) 지도(Map) SDK의 악몽
지도, 카메라, 블루투스 같은 하드웨어 기능을 깊게 써야 할 때 지옥이 시작됩니다. 네이버 지도 SDK가 네이티브(iOS/Android) 버전은 기능이 100개라면, Flutter 플러그인은 기능이 50개밖에 없었습니다. 심지어 버그도 많았죠.
결국 Flutter 코드 안에서 Platform Channel이라는 구멍을 뚫고, Java와 Swift 코드를 직접 짜서 연결해야 했습니다. "아니, Swift 안 하려고 Flutter 썼는데, 결국 Swift를 짜고 있잖아?" 하는 자괴감이 들었죠.
2) 채용의 어려움 (Dart 언어)
Flutter는 Dart라는 언어를 씁니다. 구글이 만들었지만, 솔직히 메이저 언어는 아닙니다. 채용 공고를 올리면 지원자가 많지 않습니다. "저 자바밖에 못 하는데요", "저 자바스크립트밖에 못 하는데요" 하는 분들이 대부분입니다. 반면 React Native는 "저 리액트 할 줄 아니까 RN도 할게요" 하는 웹 개발자들이 넘쳐나죠.
하지만 반전이 있습니다. Dart는 배우기 정말 쉽습니다. 자바나 자바스크립트를 아는 개발자라면, 주말 이틀만 공부하면 월요일부터 코드를 짤 수 있습니다. 우리는 그냥 "언어 상관없음, 러닝 커브 빠른 분"을 뽑아서 가르치는 전략을 썼습니다.
5. React Native vs Flutter?
이 질문도 많이 받습니다. 제 기준은 이렇습니다.
- React Native 추천:
- 이미 웹 개발팀(React)이 있다.
- 앱 내에서 코드 푸시(심사 없이 업데이트)가 필수다.
- UI 커스텀보다 OS 네이티브 느낌이 중요하다.
- Flutter 추천:
- 새로 팀을 꾸린다.
- UI 디자인이 화려하고 커스텀 요소가 많다.
- 성능과 안정성이 더 중요하다 (Type-safe한 Dart 언어 덕분).
저는 개인적으로 Flutter의 개발 경험(DX)이 훨씬 좋았습니다. RN은 의존성 라이브러리 버전 맞추다가 하루가 다 가는데, Flutter는 구글이 "이거 하나면 돼" 하고 다 넣어준(Batteries Included) 느낌이라 안정적이거든요.
6. 마무리 - 에어비앤비가 아니면 깝치지 말자
많은 개발팀이 네이티브를 고집하며 이런 핑계를 댑니다. "에어비앤비도 RN 쓰다가 네이티브로 돌아갔대요!", "페이스북(메타)도 네이티브 비중 늘린대요!"
하지만 뼈아픈 팩폭을 하나 하자면, 우리는 에어비앤비가 아닙니다. 돈과 인력이 넘쳐나고, 앱 성능 0.1초 개선에 수백억 가치가 왔다 갔다 하는 유니콘 기업의 전략을, 이제 막 시작하는 3명짜리 스타트업이 따라 하는 건 자살행위입니다.
스타트업의 목표는 "최고의 코드를 짜는 것"이 아니라, "망하기 전에 제품을 시장에 내놓는 것"입니다.
창업가를 위한 의사결정 매트릭스
- 0 to 1 단계 (검증기): 무조건 Flutter/RN 하세요. 속도가 생명입니다. 아이폰 앱 먼저 만들고 안드로이드는 나중에? 한국에서는 반쪽짜리 서비스가 됩니다.
- Product-Market Fit 찾은 뒤: 사용자가 100만 명 넘고 성능 이슈가 나오면, 그때 네이티브 개발자를 뽑아서 부분적으로 전환하세요. 늦지 않습니다.
- 특수 목적 앱: AR/VR, 고사양 3D 게임, 영상 편집 앱 등 하드웨어를 극한으로 쓴다면 처음부터 Native 가세요. Flutter로 하다가 피 봅니다.
여러분의 앱이 성공할지 망할지도 모르는데, 벌써부터 "네이티브의 완벽한 퍼포먼스"를 걱정하지 마세요. "최고의 성능을 가진, 아무도 안 쓰는 앱"이 되고 싶지 않다면요. 일단 출시하세요. 그게 정답입니다.
Why Startups Should NOT Build Native Apps (My Flutter Journey)
1. No Money, No Talent
Early in my startup, it was just me and a freelancer. Our bank account was drying up, and we were bootstrapping and running low on runway. Yet, we needed both iOS and Android apps to capture the market.
We stood at a crossroads with two choices:
- Native (Swift + Kotlin): Best performance. Perfect UX. The "Standard" way. But write code twice. Need double the headcount.
- Cross-Platform (Flutter / React Native): 90% Performance. Write code once, deploy everywhere.
As a developer, my heart desperately wanted Native. "Apps should feel premium! 60fps animations are mandatory! We must follow Human Interface Guidelines!"
But as a CEO, my rational brain pointed to Cross-Platform. "We are about to go bankrupt. Do you really have time to learn Swift AND Kotlin? Can we afford to hire two more experts?"
I swallowed my pride and chose Flutter. I chose survival over perfectionism. And a year later, that choice became the Best Decision Ever that saved our company.
2. Flutter: Productivity Drug (Hot Reload)
The most shocking thing about Flutter was Hot Reload. This isn't an exaggeration; it changed the history of app development.
Modify code, hit Save (Cmd+S), and the screen updates in 0.5 seconds. No rebuilding. No restarting. The current state is preserved.
- Native Dev: Modify -> Compile -> Build -> Install -> Run (1 min minimum) -> Check -> Typos -> Modify -> Build (1 min)... (Frustrating, watching YouTube in between)
- Flutter Dev: Modify -> Boom! -> Modify -> Boom! (Euphoria, total flow state)
This speed difference isn't just about saving minutes. It's about maintaining Developer Flow. We could iterate on UI designs 10 times more per day. Thanks to this, we finished a 2-month workload in just 3 weeks with 2 people and launched our MVP.
3. "Doesn't It Feel Fake?" (The Uncanny Valley)
My biggest worry was UX Dissonance. You know those old Hybrid Apps (Ionic, PhoneGap) that were just web pages wrapped in an app shell? The button clicks felt laggy, and it looked like a website pretending to be an app.
But Flutter was different.
Different Rendering Engine (Skia)
Previous cross-platform frameworks (like React Native) used a Bridge to convert JavaScript logic into Native components (iOS UIButton, Android Button). This bridge often became a bottleneck causing frame drops.
Flutter doesn't use the OS's UI components. Instead, it uses a built-in C++ graphics engine called Skia to draw every pixel itself. It works exactly like a game engine (Unity).
This brings two massive benefits:
- Consistency: Whether on iPhone, Galaxy, or an old phone, the app looks exactly the same. You don't have to worry about OS version fragmentation.
- Performance: Without a bridge, it communicates directly with the GPU, making 60fps-120fps animations buttery smooth.
Of course, it wasn't 100% Native. Scroll physics and navigation transitions were slightly off. But 99% of users didn't notice. Only developers nitpicked, "Hey, the scroll inertia feels weird." Users just said, "The app looks pretty."
4. There Was Also Hell (Native Libraries & Hiring)
It wasn't all roses. The limitations of Cross-Platform were clear.
1) The Nightmare of Maps SDK
When integrating hardware-heavy features like Maps, Camera, or Bluetooth, hell begins. The Naver Map SDK (widely used in Korea) had 100 features for Native, but the Flutter plugin only had 50. And it was buggy.
I eventually had to dig a Platform Channel inside Flutter code and write Java/Swift code manually to bridge them. I felt defeated. "I chose Flutter to avoid Swift, yet here I am writing Swift..."
2) Hiring Difficulties (Dart Language)
Flutter uses Dart. It's made by Google, but let's be honest, it's not a major language like Java or JS. When we posted job openings, few applied. "I only know Java," "I only know React." React Native has a huge pool of web developers, but Flutter doesn't.
But there's a twist. Dart is incredibly easy to learn. If you know Java or JS, you can learn it over a weekend and start coding on Monday. We adopted a strategy of hiring "Smart people who learn fast" regardless of language stack.
5. React Native vs Flutter?
I get this question a lot. Here is my criteria:
- Choose React Native if:
- You already have a Web Team (React).
- Code Push (Updating app without App Store review) is mandatory.
- OS-native look and feel is priority.
- Choose Flutter if:
- You are building a new mobile team.
- You want highly custom, branded UI designs.
- Performance and stability are key (Thanks to Type-safe Dart).
Personally, Flutter's Developer Experience (DX) was superior. RN often breaks due to dependency hell (npm packages), but Flutter feels like a robust "Batteries Included" kit from Google.
6. Conclusion: You Are Not Airbnb
Many teams insist on Native saying, "Airbnb switched back to Native!", "Facebook is moving back to Native!"
Here's a reality check: You are not Airbnb. Copying the strategy of a Unicorn with unlimited budget and talent is suicide for a 3-person startup. Their goal is micro-optimization; your goal is survival.
Startup's Goal: Not "Writing perfect code," but "Getting the product to market before cash runs out."
Decision Matrix for Founders
- 0 to 1 Stage: Go Flutter/RN. Speed is everything. Launching iOS first and Android later is a bad strategy in many markets.
- After Product-Market Fit: When you have 1M+ users and hit performance ceilings, THEN hire native experts to rewrite critical parts. It's not too late.
- Special Purpose Apps: If you are building AR/VR, heavy 3D games, or video editors that abuse hardware, go Native from day 1. Flutter will struggle there.
Don't worry about "Peak Performance" when you don't even know if your app will succeed. You don't want to build The Highest Performance App That No One Uses. Just launch it. That's the answer.