앱 개발의 복음서는 다시 쓰여지고 있다. 과거에는 네이티브(Native)라는 성전(聖典) 외에는 다른 길이 없다고 여겨졌다. 아이폰용 앱은 스위프트(Swift)로, 안드로이드용은 코틀린(Kotlin)으로, 각자의 언어로 기도해야만 했다. 그러나 토스(Toss)와 당근마켓(Karrot)은 다르다. 이들은 각 플랫폼의 신도가 아니라, 비즈니스라는 교황을 섬기는 실용주의자들이다. 그들이 선택한 전략은 단순하다. 더 빠르게, 더 유연하게, 그리고 더 많은 사용자 앞에 도달하기 위해 웹 기술로 앱을 만드는 것. 바로 ‘하이브리드(Hybrid)’ 그 이상의 지혜다.
더 이상 ‘네이티브 vs 하이브리드’는 무의미하다
혹시 아직도 ‘네이티브만이 진정한 앱이다’라는 10년 전 미신에 사로잡혀 있는가? 그 시각은 마치 “오토바이만 운전할 줄 알면 된다”고 우기는 것과 같다. 중요한 것은 당신의 비즈니스가 포르쉐의 서스펜션이 필요한지, 아니면 실용적인 SUV의 효율성이 필요한지다 .
2025년 현재, 업계의 정답은 이미 정해져 있다. 정답은 ‘하이브리드’나 ‘네이티브’가 아니라, ‘전략적 하이브리드’다. 단일 코드베이스로 두 개의 플랫폼을 정복하는 크로스 플랫폼의 매력은 스타트업의 심장을 뛰게 만들기에 충분하다. 초기 개발 비용을 30% 이상 절감할 수 있다는 사실은 단순한 숫자 이상의 의미를 갖는다. 생존의 문제이기 때문이다 . 하지만 진짜 교훈은 토스와 당근마켓이 그 다음에 무엇을 했는가에 있다.
토스의 미니 앱: 생태계를 품은 슈퍼 앱의 조건
토스 앱을 열어보라. 단순한 송금 앱이 아니다. 그 안에는 증권, 보험, 심지어 운동까지, 수많은 서비스가 들어찬 하나의 광장이다. 이 광장을 ‘슈퍼 앱’이라 부른다. 그런데 이 거대한 광장을 어떻게 매번 업데이트할 때마다 앱 스토어의 심사를 기다리며 운영할 수 있을까? 답은 미니 앱(Mini App)이라는 전략에 있다 .
토스는 자체 앱 안에 또 다른 앱을 실행할 수 있는 앱 속의 앱(App-in-App) 환경을 구축했다. 이것이 가능한 이유는 웹 기술을 적극적으로 수용했기 때문이다. 복잡한 금융 기능의 핵심은 네이티브의 강력한 성능을 빌리면서도, 실제 콘텐츠와 서비스는 웹뷰(Webview)를 통해 유연하게 제공하는 하이브리드 구조를 택한 것이다.
여기서 리액트 네이티브(React Native)가 등장한다. 토스의 개발자들이 자바스크립트와 리액트에 능숙했다는 점은 중요한 퍼즐 조각이었다. 웹 개발자라는 풍부한 인력 풀을 그대로 앱 개발로 전환할 수 있었고, 이는 단순한 기술 선택을 넘어 비즈니스 확장성을 위한 선견지명이었다 .
| 전략 | 핵심 기술 | 토스의 적용 방식 |
|---|---|---|
| 미니 앱 | Webview, JavaScript Bridge | 앱 내에서 별도 심사 없이 제3자 서비스(슈퍼워크 등)를 즉시 론칭 |
| 핵심 기능 | Swift, Kotlin (Native) | 금융 거래, 보안, 생체 인증 등 성능과 안전이 절대적인 영역 |
| 비즈니스 로직 | React Native | 메인 화면, 이벤트 페이지, 마케팅 툴 등 빠른 업데이트가 필요한 영역 |
토스는 2025년, 광고 수익을 무려 891%나 끌어올리면서도 사용자 경험을 해치지 않았다 . 단순한 네이티브 앱으로는 불가능한 일이다. 광고라는 ‘변화무쌍한 콘텐츠’를 네이티브의 딱딱한 틀이 아니라 웹의 유연한 프레임 안에서 관리했기 때문에 가능했다.
당근마켓의 추천 시스템: 데이터를 품은 확장성의 미학
당근마켓 이야기는 조금 다르다. 이웃 간 거래라는 단순한 아이디어로 시작했지만, 이제는 동네 생활 전반을 아우르는 플랫폼으로 성장했다. 문제는 이 성장 속에서 발생했다. 추천 시스템이었다.
당근마켓이 사용자에게 ‘딱 맞는’ 동네 글을 보여주기 위해서는 사용자의 모든 행동(클릭, 체류, 좋아요)과 게시글의 정보를 머신러닝 모델에 먹여야 한다. 초기에는 이 시스템이 중고거래 서버에 단단히 달라붙어 있어서 새로운 기능(예: 동네 구인구직, 광고)을 추가할 때마다 시스템 전체를 흔들어야 했다. ‘단단한 결합(Tightly coupled)’은 혁신의 적이었다 .
당근마켓 팀은 과감하게 시스템을 분리했다. 그 중심에는 피처 플랫폼(Feature Platform)이라는 새로운 개념이 자리 잡았다. 2021년, 약 2년간의 고민 끝에 시작한 이 프로젝트는 기존의 문제를 완전히 해체했다 .
이 플랫폼의 핵심은 데이터를 계층화(Caching Strategy)하는 지혜였다. 모든 데이터를 같은 방식으로 대하지 않았다. 자주 쓰는 데이터는 서버 안의 로컬 캐시(Local Cache)에, 덜 쓰는 데이터는 원격 캐시(Remote Cache)에, 그리고 잘 쓰지 않는 방대한 데이터는 데이터베이스(DB)에 저장하는 3단계 전략을 펼쳤다. 마치 옷을 자주 입는 계절별로 꺼내놓고, 안 입는 옷은 창고 깊숙이 넣어두는 것과 같다 .
“모든 데이터가 네이티브여야 할 필요는 없다.” 당근마켓의 기술 블로그에 따르면, 이러한 아키텍처 개선 덕분에 추천 시스템의 클릭률(CTR)은 30% 이상 증가했고, 전환율(Conversion Rate)은 무려 70% 향상됐다 . 이는 단순히 개발 언어의 선택이 아니라, 시스템 설계 자체를 ‘웹 기술의 유연함’으로 무장한 결과다.
프로들이 말하는 진짜 승부처: 플레이버, 그리고 언어의 경계
그렇다면 이쯤에서 반문할 수 있다. “그래도 플러터(Flutter)나 리액트 네이티브는 네이티브만큼 빠르지 않잖아?#8221; 물론이다. 정교한 60FPS의 애니메이션이 필요하다면, 그리고 AR처럼 기기의 숨통을 조여야 하는 기능이 필요하다면 네이티브가 여전히 황제다 . 그러나 중요한 건, 우리 앱의 80%는 그런 극한의 성능을 요구하지 않는다는 사실이다 .
오히려 전문가들이 주목하는 것은 ‘커뮤니케이션 비용’이다. 리액트 네이티브처럼 자바스크립트와 네이티브 영역이 분리된 구조에서는 이 둘이 대화하는 ‘브릿지(Bridge)’ 과정에서 지연이 발생한다. 플러터는 다트(Dart)라는 언어로 통일해 이 문제를 해결했지만, 대신 기기의 기본 기능(카메라, 블루투스)을 사용하려면 다시 ‘통역사(Plugin)’가 필요해진다 .
여기서 최신 트렌드는 이 모든 ‘통역’ 과정 자체를 없애는 방향으로 흐른다. 예를 들어, 유니앱(uni-app) X의 경우, 코틀린 코드를 직접 사용해 네이티브 API를 호출하기 때문에 어떤 브릿지도 거치지 않는다. 이것은 ‘웹 기술로 앱 만들기’라는 명제의 새로운 진화형이다 .
“네이티브는 신성한 언어가 아니다. 그저 도구일 뿐이다.” 당신의 개발팀이 자바스크립트에 강하다면, 리액트 네이티브는 현명한 선택이다. 성능이 검증된 모듈은 네이티브로 만들고, 나머지는 웹 기술로 빠르게 조립하는 ‘이중 전략’이 바로 토스와 당근마켓이 묵묵히 걸어온 길이다.
결론: 당신의 앱은 어떤 옷을 입어야 하는가
결국 ‘앱 만들기’라는 기술적 고민은 ‘비즈니스 모델’이라는 철학적 질문으로 귀결된다.
당신이 지금 막 시작하는 스타트업이라면, 그리고 시장의 반응을 확인하기 위해 단 3개월 안에 MVP를 세상에 내놓아야 한다면, 하이브리드는 선택이 아니라 필수다. 더 빠르게, 더 저렴하게, 그리고 더 많은 사람에게 도달하라 .
당신이 이미 수천만 사용자를 거느린 토스와 같은 ‘슈퍼 앱’을 꿈꾼다면, 그리고 그 안에서 다양한 서비스가 숨 쉬는 생태계를 만들고 싶다면, 네이티브와 웹 기술의 경계를 허문 ‘미니 앱’ 아키텍처를 주목하라.
당신의 비즈니스가 복잡한 추천 알고리즘과 방대한 데이터를 다루는 당근마켓과 같다면, 단단한 ‘데이터 계층화 전략’으로 무장하라. 그리고 그 모든 전략의 중심에는 ‘이 기술이 우리의 성장 속도를 따라잡을 수 있을까?#8217;라는 질문이 있어야 한다.
앱 개발의 세계는 더 이상 ‘어느 언어가 더 빠른가’의 싸움이 아니다. ‘어떻게 하면 더 지혜롭게 비즈니스를 확장할 것인가’에 대한 고민이다. 토스와 당근마켓은 그 질문에 가장 세련된 방식으로 답한 모범답안들이다.
자, 이제 당신의 차례다. 지금 당신의 앱 아키텍처는 비즈니스의 성장 속도를 따라잡고 있는가?
