하나의 코드베이스로 웹과 iOS, 안드로이드까지: 선택 기준
네이티브, 하이브리드, 웹은 무엇이 다른가
세 방식의 차이는 화면을 결국 누가 그리느냐에 있습니다. 네이티브는 iOS와 안드로이드가 각각 제공하는 도구로 따로 만듭니다. 웹은 브라우저가 그립니다. 하이브리드는 하나의 코드에서 출발해 두 플랫폼을 함께 겨냥합니다. 개발 기간, 유지보수 부담, 성능 특성, 나중에 붙는 운영 비용의 차이는 대부분 이 한 가지 구조에서 파생됩니다.
네이티브 개발은 iOS용 코드와 안드로이드용 코드를 별도로 작성합니다. 같은 로그인 화면을 두 번 만들고, 같은 버그를 두 번 고치고, 같은 사양 변경을 두 번 반영합니다. 대신 각 운영체제가 제공하는 기능을 시차 없이 쓸 수 있고, 화면 동작이 그 플랫폼의 관습과 어긋날 여지가 적습니다.
웹은 설치 과정이 없습니다. 링크를 열면 곧바로 최신 버전이 뜨고, 스토어 심사를 기다리지 않고 배포할 수 있습니다. 화면 크기에 맞춰 배치를 바꾸는 반응형 구현과 홈 화면에 아이콘을 걸어 앱처럼 실행하는 방식까지 포함하면, 생각보다 많은 서비스가 웹만으로 충분합니다. 다만 푸시 알림, 백그라운드 동작, 일부 센서 접근은 브라우저와 운영체제 정책에 묶여 있어 사전에 확인해야 합니다.
하이브리드라는 말은 실무에서 최소 세 가지를 뭉뚱그려 가리킵니다. 첫째는 웹으로 만든 화면을 앱 껍데기 안에서 띄우는 방식입니다. 둘째는 공통 코드가 각 플랫폼의 실제 화면 요소를 불러 쓰는 방식입니다. 셋째는 프레임워크가 자체 그리기 엔진으로 화면을 직접 그리는 방식입니다. 세 갈래는 성능 특성도, 운영체제 신규 기능을 따라가는 속도도, 디자인을 맞추는 방법도 다릅니다.
그래서 견적서에 적힌 프레임워크 이름만 보고 판단하면 어긋나기 쉽습니다. 이름은 몇 년 주기로 흥망이 갈리고 버전마다 성격도 달라집니다. 오래 유효한 질문은 이쪽입니다. 이 방식은 화면을 누가 그리는가, 운영체제가 새 기능을 내놓았을 때 우리 제품이 언제 그것을 쓸 수 있는가, 문제가 생겼을 때 원인을 어느 층에서 찾아야 하는가.
용어가 회사마다 다르게 쓰인다는 점도 미리 알아 두면 좋습니다. 어떤 곳은 웹 화면을 앱으로 감싼 것만 하이브리드라고 부르고, 어떤 곳은 하나의 코드로 여러 플랫폼을 겨냥하는 모든 방식을 묶어 크로스플랫폼이라고 부릅니다. 제안서를 받았다면 단어를 그대로 받아들이지 말고, 앞의 세 갈래 중 어디에 해당하는지 한 번 되물어 보십시오. 이 질문 하나로 견적의 성격이 상당 부분 드러납니다.
하이브리드가 맞는 경우와 맞지 않는 경우
기준은 팀의 취향이 아니라 화면의 성격입니다. 목록과 상세, 입력 폼과 검색, 서버에서 내려온 내용을 보여 주는 화면이 대부분이라면 하나의 코드베이스가 잘 맞습니다. 반대로 매 프레임을 직접 그리거나 센서를 끊임없이 읽거나 운영체제 최신 기능을 출시 당일 써야 하는 제품이라면 플랫폼별로 나눠 만드는 편이 안전합니다.
잘 맞는 쪽을 조금 더 구체적으로 보겠습니다. 예약, 주문, 근태, 구인구직, 회원 관리, 사내 업무 도구처럼 데이터를 읽고 쓰는 일이 중심인 서비스가 여기 들어갑니다. 아직 시장 반응을 확인하는 단계여서 기능이 자주 바뀌는 제품, 두 스토어에 같은 시점에 올려야 하는 제품, 인원이 적어 한 사람이 여러 화면을 맡아야 하는 팀도 마찬가지입니다. 이런 조건에서는 두 벌의 코드를 나란히 끌고 가는 비용이 이득보다 큽니다.
맞지 않는 쪽도 분명합니다. 실시간 카메라 보정, 영상과 음성 편집, 3D와 게임처럼 그리기 성능이 제품의 본질인 경우입니다. 위치를 초 단위로 기록하거나 블루투스 기기와 오래 붙어 있어야 하는 백그라운드 처리도 까다롭습니다. 금융이나 의료처럼 보안 요건이 세밀하게 규정된 영역, 이미 iOS 팀과 안드로이드 팀이 각각 자리 잡은 조직도 굳이 합칠 이유가 적습니다.
애매한 구간이 실제로는 가장 넓습니다. 지도, 결제, 푸시, 생체 인증, 파일 업로드는 대개 연결 수단이 마련돼 있지만 품질과 관리 상태가 제각각입니다. 필수 기능일수록 계약 전에 실물로 확인해야 합니다. 그 기능을 붙인 화면 하나를 실제 기기에서 돌려 보는 데는 며칠이면 충분하고, 그 며칠이 몇 달의 방향을 바꿉니다.
판단이 서지 않을 때 쓰는 방법이 하나 있습니다. 만들려는 화면을 종이에 전부 적어 놓고, 각 화면 옆에 그 화면이 무엇에 의존하는지 한 단어로 적어 보십시오. 서버 데이터, 카메라, 위치, 그리기 성능처럼 짧게 쓰면 됩니다. 그리기 성능과 센서에 적힌 화면이 손에 꼽을 정도라면 공통 코드로 가도 무리가 없고, 목록의 절반을 넘긴다면 방식을 다시 생각할 때입니다. 이 작업은 반나절이면 끝나는데, 회의를 몇 번 하는 것보다 답이 분명합니다.
한쪽을 고르는 문제로만 볼 필요도 없습니다. 화면 대부분을 공통 코드로 만들고 무거운 한두 화면만 플랫폼별 모듈로 빼는 구성은 흔합니다. 웹을 먼저 열어 사용자를 받고 앱은 필요가 확인된 뒤에 만드는 순서도 자주 통합니다. 처음부터 전부를 정하기보다, 되돌리기 어려운 결정을 뒤로 미루는 편이 낫습니다.
하나의 코드베이스가 실제로 아껴 주는 것
절약되는 것은 코드 분량이 아니라 중복된 판단입니다. 같은 사양을 두 번 해석하지 않고, 같은 버그를 두 번 재현하지 않고, 같은 변경을 두 번 검수하지 않는 데서 효과가 나옵니다. 코드가 절반으로 준다는 통념은 화면 성격에 따라 크게 흔들리지만, 이 중복 제거만큼은 프로젝트 성격과 무관하게 대체로 남습니다.
두 벌로 만들면 일이 두 배가 아니라 두 배보다 조금 더 늘어납니다. 사양이 바뀔 때마다 두 구현이 같은 뜻으로 움직이는지 맞춰야 하고, 두 결과물이 다르게 동작하면 어느 쪽이 옳은지 정하는 회의가 한 번 더 생깁니다. 사소해 보이는 차이가 쌓이면 문의 응대와 테스트 케이스가 갈라지고, 나중에는 어느 플랫폼 기준으로 설명해야 하는지부터 헷갈립니다.
효과가 가장 크게 나타나는 구간은 초기 개발이 아니라 그 뒤입니다. 서비스는 만드는 기간보다 고치는 기간이 훨씬 깁니다. 운영체제가 해마다 올라가고, 정책이 바뀌고, 화면이 늘어납니다. 이 긴 구간에서 한 벌만 관리한다는 조건은 매달 조금씩 이자를 돌려받는 쪽에 가깝습니다.
반대로 아껴지지 않는 것도 분명히 알아야 합니다. 스토어 심사는 여전히 각각 받습니다. 실기기 테스트도 여전히 양쪽에서 합니다. 두 플랫폼의 화면 관습이 달라 디자인 대응이 남고, 서버와 데이터베이스는 애초에 공유되던 부분이라 절약분에 포함되지 않습니다. 다국어, 접근성, 알림 발송, 배포 자동화도 마찬가지입니다. 하나의 코드베이스로 줄어드는 몫은 전체 일정의 일부이지 전부가 아닙니다.
그래서 견적을 비교할 때는 개발 기간만 나란히 놓지 말고, 출시 이후 1년치 운영 항목을 같이 적어 보시길 권합니다. 운영체제 대응, 스토어 정책 변경 대응, 문구 수정, 장애 대응, 기능 추가가 여기 들어갑니다. 이 목록 위에 올려놓으면 두 방식의 차이가 초기 견적서에서보다 훨씬 또렷하게 보입니다. 발주 단계에서 가장 자주 빠지는 항목도 바로 이 부분입니다.
여우비 인터랙션도 자체 제품에서 이 판단을 반복해 왔습니다. 출결 관리 서비스 onSpots는 iOS와 안드로이드 양쪽에 올라가 있고 영어, 베트남어, 한국어를 지원합니다. 이 조건에서 반복 비용이 어디서 생기는지는 명확합니다. 문구 하나를 고치면 세 언어와 두 플랫폼에 걸쳐 확인해야 하고, 그 확인 횟수가 곱셈으로 늘어납니다. 구조를 정할 때 우리가 실제로 다룬 문제도 성능보다 이 곱셈 쪽이었습니다.
성능과 기기 기능에서 감수해야 하는 것
대부분의 업무형 앱에서 체감 속도를 좌우하는 것은 렌더링 방식이 아니라 네트워크 응답 속도, 이미지 크기, 목록 처리 방식입니다. 그래도 방식에 따라 차이가 드러나는 자리는 분명히 있습니다. 앱을 눌러서 쓸 수 있게 되기까지 걸리는 시간, 긴 목록을 빠르게 넘길 때의 매끄러움, 화면 전환 애니메이션, 그리고 설치 파일의 크기입니다.
계열마다 치르는 대가가 다릅니다. 웹 기술을 앱 안에서 실행하는 방식은 카메라나 파일 같은 기기 기능을 오갈 때 중간 전달 비용이 생기고, 그 구간에 데이터가 많이 오가면 끊김으로 나타납니다. 프레임워크가 화면을 직접 그리는 방식은 그 부담이 적은 대신 운영체제가 기본으로 제공하는 글꼴, 텍스트 선택, 화면 읽기 도구와의 연동에서 미세한 차이가 남을 수 있습니다. 어느 쪽이 낫다고 잘라 말할 수 없고, 만들려는 화면이 어느 부담에 민감한지로 갈립니다.
기기 기능에서 실제로 부딪히는 문제는 지원 시차입니다. 운영체제가 새 기능을 내놓으면 네이티브는 곧바로 쓸 수 있지만, 공통 코드 위에서는 그 기능을 이어 주는 연결부가 만들어질 때까지 기다립니다. 이 연결부는 상당수가 커뮤니티에서 관리되고, 관리자가 손을 놓으면 어느 시점부터 갱신이 멈춥니다. 그때는 결국 플랫폼별 코드를 직접 작성해야 합니다. 하나의 코드베이스를 택해도 팀 안에 iOS와 안드로이드 지식이 어느 정도는 있어야 하는 이유가 여기 있습니다.
정기적으로 나가는 비용도 계산에 넣어야 합니다. 프레임워크의 큰 버전이 올라가면 연결부와 라이브러리가 함께 움직여야 하고, 그 작업은 새 기능을 만들지 않으면서 일정을 차지합니다. 이 부담을 예산에 미리 잡아 두지 않으면 나중에 버전이 뒤처지고, 뒤처질수록 올리기가 어려워집니다.
접근성도 같은 자리에서 점검하십시오. 글자 크기를 키운 사용자, 화면 읽기 도구를 쓰는 사용자, 색 대비에 민감한 사용자에게 화면이 어떻게 보이는지는 방식마다 기본값이 다릅니다. 나중에 손보면 화면을 다시 그려야 하는 일이 생기므로, 첫 화면을 만들 때 함께 확인하는 편이 비용이 훨씬 적게 듭니다.
숫자로 못 박지 않는 편이 정확합니다. 프레임워크 성능은 버전, 기기, 화면 구성에 따라 달라지고 어제의 비교표가 오늘 유효하다는 보장이 없습니다. 대신 권하는 방법은 단순합니다. 가장 무거울 것으로 예상되는 화면 한두 개를 먼저 만들어, 실제 목표 기기에서 켜 보는 것입니다. 특히 사용자 다수가 보급형 기기를 쓴다면 고사양 기기 한 대만으로 판단하지 않아야 합니다. 이 측정은 어떤 자료보다 여러분의 결정에 직접 답합니다.
결정하기 전에 확인할 질문 목록
아래는 결정을 문서가 아니라 사실 위에 올려놓기 위한 질문들입니다. 제품이 실제로 무엇을 하는가, 누가 얼마나 오래 유지할 것인가, 사용자가 어떤 기기를 쓰는가. 이 세 축에서 답이 한쪽으로 모이면 방식은 대체로 저절로 좁혀집니다. 답이 갈린다면 바로 그 지점이 프로토타입으로 확인해야 할 자리입니다.
제품 쪽에서는 이렇게 묻습니다. 전체 화면 중 실시간 그래픽, 카메라 처리, 지속적인 위치 추적이 차지하는 비중은 얼마인가. 오프라인에서도 동작해야 하는가. 푸시 알림, 결제, 지도, 생체 인증 중 필수는 무엇이며 그것이 이 방식에서 이미 검증돼 있는가. 스토어 등록 없이 링크로 접근하는 웹만으로 첫 버전을 낼 수는 없는가. 규제나 보안 요건이 특정 구현을 강제하지는 않는가.
조직 쪽 질문은 더 현실적입니다. 지금 팀이 이미 다룰 줄 아는 기술은 무엇인가. 이 인력을 우리 지역에서 계속 채용할 수 있는가. 출시 이후 2년 동안 누가 이 코드를 맡는가. 외주로 만든다면 인수인계 범위와 코드 소유권은 계약서에 어떻게 적혀 있는가. 프레임워크 버전을 올리는 작업을 누가 언제 하기로 돼 있는가. 이 다섯 질문에 답하지 못한 채 기술만 고르면, 잘 만든 앱이 관리자 없이 남습니다.
사용자 쪽도 확인이 필요합니다. 실제 사용자의 기기가 무엇인지 추측하지 말고 데이터로 확인하십시오. 이미 웹 서비스가 있다면 접속 기록에 답이 있고, 없다면 초기 사용자 몇 명에게 직접 물으면 됩니다. 여러 언어를 지원해야 하는지, 앞으로 언어가 늘어날 가능성이 있는지도 지금 정해 두는 편이 낫습니다. 언어와 플랫폼은 곱해지는 축이라 나중에 붙이면 비용이 급하게 커집니다.
질문에 답하고 나면 마지막으로 순서를 정하십시오. 가장 위험해 보이는 화면 한두 개를 먼저 만들어 목표 기기에서 돌려 보고, 그 결과를 보고 나머지를 결정하는 순서입니다. 이 단계에 쓰는 시간은 전체 일정에서 크지 않은데, 여기서 걸러지는 것은 나중에 되돌리기 가장 비싼 결정들입니다. 방식을 먼저 정하고 화면을 끼워 맞추는 순서보다 실패 비용이 훨씬 낮습니다.
마지막으로 되돌릴 여지를 남기십시오. 화면을 그리는 부분과 데이터를 다루는 부분을 분리해 두면, 나중에 한 화면을 플랫폼별 코드로 바꿔야 할 때 전체를 다시 만들지 않아도 됩니다. 여우비 인터랙션은 한국과 베트남 양쪽에서 고객사 개발과 자체 제품 운영을 함께 하면서 이 결정을 여러 번 지나왔습니다. 매번 확인한 것은 같습니다. 옳은 방식이 따로 있는 것이 아니라, 이 제품과 이 팀에 맞는 방식이 있을 뿐입니다. 그리고 그 답은 대개 회의실보다 실제 기기에서 먼저 나옵니다.
