크로스플랫폼 앱 개발, 우리 서비스에 맞을까 — 네이티브와 갈리는 5가지 판단 기준

크로스플랫폼 앱 개발로 갈지 네이티브로 갈지가 정해지지 않은 상태에서 받은 견적서는, 사실 비교할 수 없는 숫자입니다. 같은 기획서를 세 곳에 보냈는데 한 곳은 하나의 코드로 iOS와 안드로이드를 함께 만들겠다고 하고, 다른 곳은 두 개를 따로 만들겠다고 합니다. 금액은 그 자리에서 두 배 가까이 벌어집니다. 그런데 발주사 담당자 입장에서는 어느 쪽이 우리 서비스에 맞는지 판단할 근거가 없습니다. 설명을 들어도 대부분 개발사의 사정처럼 들립니다.

이 글은 그 판단을 발주사 쪽에서 할 수 있게 만드는 것을 목표로 합니다. 기술 용어를 설명하려는 것이 아니라, 무엇을 기준으로 갈라야 견적과 일정이 예측 가능해지는지를 정리합니다.

디비컨설팅은 삼성물산 홈닉(주거 플랫폼 앱), GS건설 엘리시안 리조트(리조트 웹·앱 통합 구축), 하나투어 하나오픈챗, 직방 호갱노노를 포함해 100건 이상의 프로젝트를 수행했고, 50개 이상의 글로벌 파트너사와 함께 일합니다. 아래 내용은 그 과정에서 반복적으로 확인한 패턴입니다.

왜 이 한 줄이 견적 전체를 흔드는가

개발 공수가 한 번이 아니라 두 번 들어갑니다

네이티브로 간다는 것은 iOS와 안드로이드를 각각 별도의 언어와 도구로 만든다는 뜻입니다. 화면 하나를 수정하면 두 번 수정해야 하고, 테스트도 두 번 합니다. 크로스플랫폼은 하나의 코드베이스로 두 플랫폼을 함께 만듭니다. 초기 개발 공수만 놓고 보면 차이가 분명합니다.

다만 여기서 대부분의 견적 비교가 잘못됩니다. 초기 공수만 비교하면 크로스플랫폼이 언제나 이깁니다. 실제 총비용은 그 뒤에서 결정됩니다.

비용은 출시 시점이 아니라 운영 구간에서 갈립니다

앱은 출시하면 끝나는 물건이 아닙니다. iOS와 안드로이드는 매년 새 버전을 내고, 그때마다 대응이 필요합니다. 크로스플랫폼은 이 대응을 한 번에 처리할 수 있는 대신, 프레임워크 자체가 새 OS를 지원할 때까지 기다려야 하는 구간이 생깁니다. 네이티브는 그 기다림이 없지만 매번 두 번 일합니다.

어느 쪽이 싼지는 서비스마다 다릅니다. 판단하려면 출시 이후를 먼저 계산해야 하는데, 이 부분은 앱 유지보수 비용을 따로 정리한 글에서 더 자세히 다뤘습니다.

기능의 개수가 아니라 ‘어떤 기능’인지가 기준입니다

기능이 30개인지 50개인지는 이 결정과 거의 무관합니다. 중요한 것은 그중에 카메라 실시간 처리, 블루투스·웨어러블 연동, 백그라운드 위치 추적, 고사양 그래픽처럼 기기 하드웨어를 깊게 다루는 기능이 몇 개나 있는가입니다. 이런 기능이 하나도 없으면 크로스플랫폼이 유리한 경우가 많고, 서비스의 핵심 가치가 그 기능에 걸려 있으면 네이티브 쪽으로 기웁니다.

크로스플랫폼과 네이티브를 가르는 5가지 판단 기준

발주 전에 내부에서 이 다섯 가지에 답해 두면, 개발사가 어떤 제안을 하든 그 근거를 검증할 수 있습니다.

1. 기기 하드웨어와 OS 기능을 얼마나 깊게 쓰는가

로그인, 목록, 상세, 결제, 푸시 정도라면 크로스플랫폼으로 충분한 경우가 대부분입니다. 반대로 실시간 영상 처리, 정밀한 센서 데이터, 워치·IoT 기기 연동이 서비스의 중심이라면 네이티브를 검토해야 합니다. 웨어러블·IoT 연동 구조를 어떻게 설계하는지는 별도의 주제라 여기서는 판단 기준만 짚습니다.

2. 화면의 반응 속도가 서비스의 경쟁력인가

대부분의 업무용 앱, 커머스 앱, 커뮤니티 앱에서 사용자는 크로스플랫폼과 네이티브의 차이를 인지하지 못합니다. 반면 애니메이션과 조작감 자체가 상품인 서비스라면 이야기가 달라집니다. “빠르면 좋다”와 “느리면 서비스가 성립하지 않는다”는 다른 조건입니다. 이 둘을 구분해서 적어 두십시오.

3. 출시 후 업데이트를 얼마나 자주 낼 것인가

2주에 한 번 기능을 내보내는 조직과 분기에 한 번 내보내는 조직은 다른 선택을 해야 합니다. 잦은 업데이트는 두 플랫폼을 따로 관리하는 비용을 매번 두 배로 만듭니다. 업데이트 주기는 기술이 아니라 사업 계획에서 나오는 숫자이므로, 발주사가 먼저 정해 줘야 하는 항목입니다.

4. 출시 이후 몇 명으로 운영할 계획인가

가장 자주 빠지는 항목입니다. 네이티브 두 벌을 유지하려면 두 종류의 개발자가 필요합니다. 출시 후 인력을 최소로 유지할 계획이라면, 초기 견적이 조금 더 나오더라도 유지 인력이 적게 드는 구조를 고르는 편이 총비용에서 유리합니다. 이 계산은 모바일 앱 개발 견적이 회사마다 달라지는 이유와 같은 구조에서 나옵니다.

5. 앞으로 3년 안에 무엇을 붙일 계획인가

지금 기획서에 없는 기능이 결정을 뒤집는 일이 많습니다. 2년 뒤에 오프라인 매장 비콘 연동을 붙일 계획이라면, 그 계획은 지금 문서에 들어가 있어야 합니다. 1차 출시 범위를 어디까지 자를지는 MVP 개발 범위를 다룬 글에서 따로 정리했습니다.

그런데 이 판단을 ‘누가’ 하느냐가 진짜 문제입니다

위의 다섯 가지는 기술 지식이 아니라 사업 판단입니다. 문제는 이 판단을 기술 언어로 번역해 개발팀에 전달하고, 그 결과를 다시 검수하는 사람이 필요하다는 점입니다. 한국 기업이 앱 개발을 발주할 때 실질적으로 고르는 것은 기술 스택이 아니라 이 번역과 검수를 누가 책임지는가입니다.

	국내 개발사	해외 직접 발주	한국 PM + 글로벌 개발팀
개발 단가	높음	낮음	낮음
기술 선택의 책임	개발사	발주사 본인	한국 PM
커뮤니케이션 언어	한국어	영어	한국어
발주사 담당자 투입 시간	보통	매우 많음	적음
재작업 리스크	낮음	높음	낮음
총비용 관점	비쌈	기대만큼 안 싸다	실질 절감

해외 개발팀에 직접 발주하면 단가는 분명히 내려갑니다. 그런데 위 다섯 가지 판단, 요구사항 정의, 일정 관리, 검수를 모두 발주사 담당자가 영어로 직접 해야 합니다. 사내에 개발 조직이 없는 회사라면 이 구조는 대개 성립하지 않습니다. 아낀 단가만큼, 혹은 그 이상을 담당자의 시간과 재작업으로 돌려주게 됩니다. 이 패턴은 IT 외주개발 비용이 견적보다 더 나오는 구조에서도 반복해서 나타납니다.

디비컨설팅이 이 결정을 다루는 방식

저희는 IT 아웃소싱 구조에서 한국인 PM이 요구사항 정의부터 검수까지 책임지고, 검증된 글로벌 개발팀이 실제 구현을 맡습니다. 앱 개발 외주 프로젝트는 아래 5단계로 진행됩니다.

1. 상담 및 요구 분석 — 사업 목표와 기술 요건을 한국어로 문서화합니다. 크로스플랫폼과 네이티브의 선택도 이 단계에서 근거와 함께 결정됩니다. 이후 재작업의 대부분이 여기서 제거됩니다.
2. 개발팀 구성 — 확정된 기술 방향에 맞는 전담팀을 2~4주 안에 구성합니다.
3. 프로젝트 개발 — 애자일 방식으로 진행하고 진행 상황을 투명하게 공유합니다. 발주사가 하루를 조율에 쓰지 않는 구조입니다.
4. 테스트 및 배포 — QA 프로세스를 거쳐 두 플랫폼을 함께 검증하고 배포합니다.
5. 운영 및 유지보수 — 문서와 함께 인계하고 장기적으로 지원합니다.

1단계에서 무엇을 어디까지 적어야 하는지는 요구사항 정의서 글에, 전체 일정이 어떻게 흘러가는지는 앱 개발 기간 글에 정리해 두었습니다.

실제로 이렇게 만든 서비스들

• 삼성물산 — 홈닉 · 주거 플랫폼 앱
• GS건설 — 엘리시안 리조트 · 리조트 웹·앱 통합 구축
• 하나투어 — 하나오픈챗 · 여행 상담 채팅 서비스
• 직방 — 호갱노노 · 부동산 데이터 서비스
• LS일렉트릭 — 테크스퀘어 · 산업 B2B 거래 플랫폼
• 교보생명 — 사내벤처(글펍) · 커뮤니티 서비스
• 센터필드 · 센트로폴리스 · 그랑서울 · 프라임 오피스 빌딩 관리 시스템

더 많은 사례는 포트폴리오에서 확인하실 수 있습니다.

이런 기업에 적합합니다

• 사내에 개발 조직이 없거나, 있어도 앱 개발을 직접 관리할 여력이 없는 기업
• iOS와 안드로이드를 함께 내야 하는데 어느 쪽 방식이 맞는지 판단이 서지 않는 기업
• 출시 후 최소 인력으로 운영하면서 지속적으로 기능을 추가할 계획인 기업
• 국내 개발사 견적이 예산을 넘었지만 품질과 커뮤니케이션은 포기할 수 없는 기업

반대로 권하지 않습니다

• 사내에 이미 iOS·안드로이드 개발자와 기술 리드가 있는 경우 — 이 판단을 내부에서 하는 편이 빠르고, 저희가 더할 수 있는 가치가 적습니다.
• 가장 낮은 단가만이 유일한 기준인 경우 — 저희는 한국인 PM 비용이 구조에 포함되어 있어 최저가 경쟁에서는 이기지 못합니다.
• 2주 안에 앱이 나와야 하는 경우 — 전담팀 구성에만 2~4주가 필요합니다.
• 요구사항을 논의할 담당자를 지정할 수 없는 경우 — 1단계가 성립하지 않으면 나머지 단계도 성립하지 않습니다.

자주 묻는 질문

해외 개발팀인데 의사소통은 어떻게 하나요?

발주사는 한국인 PM하고만 한국어로 소통합니다. 요구사항 정의, 일정 관리, 검수는 PM의 책임입니다. 크로스플랫폼과 네이티브 중 무엇으로 갈지 같은 기술 논의도 한국어로 근거를 받아 보시게 됩니다.

비용은 어떻게 산정되나요?

등급별 단가 × 투입 기간으로 산정합니다. 기획, 디자인, 개발, QA, 배포, 유지보수를 항목별로 구분해 제시하므로, 크로스플랫폼과 네이티브 두 안을 나란히 놓고 비교하실 수 있습니다.

기획서가 없는데 견적을 받을 수 있나요?

가능합니다. 해결하려는 문제, 주요 사용자, 필수 기능 3~5개, 일정과 예산 범위만 있으면 개략 견적을 드립니다. 기술 방식이 정해지지 않은 상태여도 괜찮습니다. 그 결정 자체가 상담의 내용입니다.

진행 중에 팀 규모를 조정할 수 있나요?

가능합니다. 전담팀, 장기 협업, 인력 단위, 프로젝트 단위 중에서 선택하실 수 있고 진행 중 조정도 가능합니다. 1차 출시 후 운영 인력만 남기는 방식으로 축소하는 경우가 많습니다.

소스코드 소유권은 누구에게 있나요?

발주사에 귀속됩니다. API 명세, DB 스키마, 배포 절차 문서까지 인계합니다. 나중에 다른 개발사로 옮기거나 내부 팀으로 전환하실 때 필요한 것을 남기지 않고 드립니다.

정리

크로스플랫폼 앱 개발이 네이티브보다 싸다거나 낫다는 일반론은 없습니다. 하드웨어 활용도, 반응 속도의 중요성, 업데이트 주기, 운영 인력 계획, 3년 뒤 로드맵 — 이 다섯 가지 답이 정해지면 선택은 거의 자동으로 나옵니다. 문제는 이 답을 기술 결정으로 번역하고 그 결과를 검수할 사람이 발주사 안에 있느냐입니다. 그 자리가 비어 있다면, 채우는 방법을 정하는 것이 개발사를 고르는 일보다 먼저입니다.