프로젝트를 진행할 때면 언제나 '예산'이 발목을 잡습니다. 고객의 요구 사항은 많은데 그에 비해서 예산이 부족할 때가 많습니다. 주어진 예산을 맞추는 방법 중에 하나가 유료 솔루션을 무료 솔루션(오픈소스)으로 대체하는 것입니다.
그래서 저희는 모바일 시스템(앱)을 만들때 앱 안의 서비스 화면은 HTML로 만들어왔습니다. 즉, 하이브리드 앱 프레임워크 위에 HTML을 얹는 방식입니다. 안드로이드도 되고 i-OS도 됩니다. 코드를 두 번 짤 필요가 없었고, 비용도 줄었습니다.
그런데 5년 전부터 고객의 요구사항 중에 다크모드와 영문서비스에 대한 요구사항들이 늘어나기 시작했습니다. 또한 유지보수 이슈도 발생하기 시작했습니다.
HTML이 한계를 드러내기까지
처음엔 불만이 없었습니다. 앱이 돌아가고 있었으니까요.
문제는 고객 요구가 쌓이면서 나왔습니다.
첫 번째는 다크모드였습니다. 교수용 서비스를 납품한 대학에서 요청이 왔습니다. 아무래도 연령대가 높은 교수분들일수록 눈의 피로 때문에 다크모드를 원하는 경우가 많았습니다. HTML 방식에서 다크모드를 구현하려면 CSS 전체를 뒤집어야 합니다. 버튼 하나, 텍스트 하나, 배경 하나씩 전부 조건을 달아서 다시 짜야 합니다. 공수가 두 배로 들었고, 기종마다 색상이 조금씩 다르게 나왔습니다.
두 번째는 다국어 서비스였습니다. 요즘 대학은 외국인 학생 비중이 빠르게 늘고 있습니다. 중국어, 베트남어, 일본어. 내용까지는 아니더라도 메뉴만이라도 다국어로 바꿔달라는 요구가 들어오기 시작했습니다. HTML 방식은 언어가 바뀌면 텍스트 길이도 바뀌고, 그러면 레이아웃이 틀어집니다. 버튼이 넘치고, 메뉴가 잘립니다. 언어별로 레이아웃을 따로 잡아야 하는 상황이 생겼습니다.
기술적으로도 한계가 명확했습니다. HTML 방식은 결국 앱 안에 미니 브라우저(WebView)를 띄워서 화면을 그리는 구조입니다. 그러다 보니 다크모드나 다국어 메뉴처럼 화면 전체의 스타일을 대대적으로 전환하는 순간, 구형 스마트폰에서는 화면이 미세하게 껌벅이거나 스크롤이 버벅거리는 현상이 고스란히 유저 체감으로 드러납니다.
게다가 삼성, 샤오미, 그리고 구형 아이폰마다 탑재된 WebView 엔진의 버전이 제각각이다 보니, 분명 사무실 PC 환경에서는 멀쩡하게 나오던 CSS 레이아웃이 특정 교수님의 5년 된 갤럭시 폰에서는 사정없이 깨져서 나오는 골치 아픈 문제가 반복됐습니다. OS 파편화의 늪에 빠진 것이죠
결국 리액트로 전환하기로 했습니다. 그리고 그 과정에서 세 가지 선택지를 진지하게 검토했습니다.
왜냐면 일반 앱 서비스에서는 많이 리액트를 많이 사용하고 있었지만, 대학교쪽에서 아직까지 리액트로 서비스를 개발한 곳이 없었기 때문입니다.
세 가지 선택지, 현장에서 뜯어봤습니다
현장에서 실제로 비교하거나 검토해본 세 가지입니다.
첫번째, 리액트 네이티브 (React Native)
메타(페이스북)가 만들었습니다. 자바스크립트 기반이라 웹 개발자가 가장 빠르게 진입할 수 있습니다. 코드를 수정하면 앱을 다시 빌드하지 않아도 화면에 바로 반영되는 'Fast Refresh' 기능 덕분에 개발 속도가 빠릅니다. 국내 SI 시장에서 채택률이 가장 높습니다.
단, 내부적으로 '자바스크립트 브릿지'를 거쳐 네이티브 기능을 호출하는 구조라, 복잡한 애니메이션이나 대용량 데이터 실시간 처리 시 미세한 성능 저하가 생길 수 있습니다.
저희도 HTML에서 전환할 때 리액트를 선택한 이유가 여기 있었습니다. 기존 웹 개발자들이 새로운 언어를 배우지 않아도 됐습니다.
두번째, 플러터 (Flutter)
구글이 만들었습니다. 리액트 네이티브와 결정적으로 다른 점이 있습니다. 브릿지 없이 자체 그래픽 엔진(Skia / Impeller)으로 화면을 픽셀 단위로 직접 그립니다. 그래서 갤럭시든 아이폰이든, 구형 폰이든 관계없이 완벽하게 동일한 UI가 나옵니다. 성능도 네이티브에 준합니다.
최근 채택률이 가장 빠르게 올라가고 있는 프레임워크입니다. 단, Dart라는 언어를 새로 배워야 합니다. 기존 팀에 웹 개발자만 있다면 초기 학습 비용이 생깁니다. 국내 공공기관 특유의 보안 모듈 연동 시 아키텍처가 복잡해질 수 있다는 점도 실무에서 만나는 변수입니다.
세번째, 자마린 / .NET MAUI (Xamarin)
마이크로소프트가 만들었습니다. 최근 .NET MAUI로 고도화됐습니다. C# 기반이라 닷넷(.NET) 환경에 익숙한 기업에서 선호합니다. 컴파일 시 각 OS의 네이티브 API와 1:1로 직접 매핑되는 구조라 성능이 안정적이고, 대기업·공공기관의 C# 레거시 시스템과 코드를 공유하기 유리합니다.
커뮤니티 규모가 작아 컴포넌트를 직접 만들어야 하는 경우가 많고, 초기 앱 설치 용량이 상대적으로 무겁습니다. 유지보수 인력을 구하는 것도 변수가 됩니다.
한눈에 보는 비교표
'백문이불여일견'이란 격언이 있습니다. 각 플랫폼이 가진 핵심 지표를 15년차 IT인의 관점에서 딱 4가지로 요약하면 다음과 같습니다. 기술 검토 보고서 쓰실 때 참고하시면 좋습니다.| 항목 | 리액트 네이티브 | 플러터 | 자마린 / .NET MAUI |
|---|---|---|---|
| 개발 언어 | JavaScript / TypeScript | Dart | C# |
| UI 렌더링 | 네이티브 위젯 (브릿지) | 자체 엔진 (픽셀) | 네이티브 API 직접 컴파일 |
| 그래픽 성능 | 보통 (애니메이션 시 저하) | 매우 높음 (네이티브급) | 높음 |
| 인력 수급 | 매우 용이 | 성장 중 ▲ | 소수 (MS 개발자) |
| 국내 SI 채택률 | 높음 | 상승 중 ▲ | 보통 |
| MS 레거시 연동 | 보통 | 보통 | 매우 우수 |
현장에서 배운 선택 기준 하나
저희가 리액트로 전환하고 나서 깨달은 게 있습니다.
어떤 기술이 더 좋냐가 아니라, 우리 팀이 지금 무엇을 쓸 수 있느냐가 더 중요하다는 것입니다.
플러터가 성능이 좋아도, 팀에 Dart를 쓸 수 있는 사람이 없다면 결국 외주 의존도만 높아집니다. 외주가 늘어나면 유지보수 비용도 늘어나고, 시스템 내재화는 멀어집니다.
리액트 네이티브가 맞는 상황
사내에 웹(React) 개발자가 이미 있고, UI 변경이 잦은 대고객 서비스나 이커머스 앱을 빠르게 출시해야 할 때.
플러터가 맞는 상황
양대 OS에서 디자인 오차 없이 완벽한 UI 일관성이 필요하거나, 차트·애니메이션이 많아 부드러운 퍼포먼스가 최우선일 때.
자마린 / .NET MAUI가 맞는 상황
임직원용 내부 업무 앱이거나, 기존 사내 인프라가 C# / MS SQL로 구성돼 있어 백엔드 보안과 데이터 무결성이 최우선일 때.
1년 후를 생각하면 선택이 달라집니다
지금 진행 중인 모바일 앱 프로젝트가 있으시다면, 딱 한 가지만 먼저 확인해보세요.
1년 후 이 앱을 누가 고칩니까?
시스템 구축 후 1년은 무상 유지 보수입니다. 그 이후는 고객이 유상 유지 보수 계약을 안 할 수도 있습니다. 그 순간 아무도 못 고치는 앱이 되지 않으려면, 처음부터 팀 안에서 소화할 수 있는 기술 스택을 골라야 합니다.
도구 선택이 기술의 문제가 아닌 이유가 여기 있습니다.
결국 사람과 상황의 문제입니다.
그리고 저희는 그걸 HTML에서 리액트로 바꾸면서 배웠습니다.
함께 보면 좋은 글
모바일 시스템 제안서를 쓸 때 기술 스택보다 더 중요한 것이 있습니다. 대학의 보안! 클라우드는 안전한가?