본문 바로가기
서비스 웹 서비스 개발 앱 개발 AI 알고리즘 개발 AI 컨설팅 AI 마케팅 프로젝트 인사이트 회사소개 고객게시판
앱 개발 6 MIN READ

앱을 만들기 전에 정해야 할 것 — 웹앱·크로스플랫폼·네이티브

"앱 만들면 얼마인가요"라는 질문에는 바로 답하기 어렵습니다. 무엇을 만들지에 따라 방식이 갈리고, 방식에 따라 2년 뒤 비용이 두 배 넘게 차이 나기 때문입니다. 선택을 가르는 기준을 정리했습니다.

Category
앱 개발
Published
Read
6분
Author
네이처프랙탈
앱을 만들기 전에 정해야 할 것 — 웹앱·크로스플랫폼·네이티브 대표 이미지

"앱 만들면 얼마인가요." 앱 관련 문의는 대부분 이 질문으로 시작하는데, 바로 답하기 어렵습니다. 같은 기능이라도 어떤 방식으로 만드느냐에 따라 개발 기간과 2년 뒤 유지 비용이 두 배 넘게 벌어지기 때문입니다. 그래서 저희는 견적보다 먼저 이 질문을 드립니다. "그것이 꼭 앱이어야 하나요."

세 가지 선택지

실무에서 고르게 되는 방식은 결국 셋 중 하나입니다.

  • 웹앱. 브라우저에서 돌아갑니다. 설치가 없고 주소만 있으면 열립니다. 홈 화면에 추가해 앱처럼 쓰게 만드는 것(PWA)도 가능합니다.
  • 크로스플랫폼. 하나의 코드로 iOS와 Android 앱을 함께 만듭니다. React Native, Flutter가 여기에 해당합니다.
  • 네이티브. iOS용과 Android용을 각각 그 플랫폼의 언어로 만듭니다. 성능과 기기 기능 활용이 가장 자유롭지만 두 벌을 만들어야 합니다.

예산이 아니라 요구사항이 방식을 정한다

"싼 것부터"로 접근하면 대개 다시 만들게 됩니다. 아래 항목 중 어디에 해당하는지가 선택을 가릅니다.

검색 노출·설치·푸시 알림·기기 센서·오프라인·그래픽 성능·배포 속도 요구사항별로 웹앱, 크로스플랫폼, 네이티브의 적합도를 비교한 표
요구사항별 적합도 · 실무에서 자주 갈리는 항목 기준

표에서 특히 중요한 두 줄이 있습니다.

  1. 검색엔진 노출이 필요한가. 앱스토어 안의 앱은 구글 검색에 걸리지 않습니다. 신규 고객이 검색으로 유입되어야 하는 서비스라면 웹이 먼저이고, 앱은 그다음입니다.
  2. 카메라·블루투스·센서를 쓰는가. 이 조건이 있으면 웹앱은 선택지에서 빠집니다. 브라우저가 허용하는 범위가 제한적이고, 같은 코드가 기기마다 다르게 동작하는 문제를 만나게 됩니다.

가장 흔한 오해는 "앱이 있어야 전문적으로 보인다"는 것입니다. 하지만 설치를 요구하는 순간 이용자 대부분이 이탈합니다. 아직 관계가 없는 사람에게는 웹이, 이미 자주 쓰는 사람에게는 앱이 맞습니다. 두 층을 같은 것으로 보면 안 됩니다.

비용은 첫 개발보다 그 뒤에서 갈린다

견적서에는 최초 개발비만 적히지만, 실제로 쓰게 되는 돈은 그 뒤에도 계속 발생합니다. 2년을 기준으로 놓고 보면 구성이 이렇게 됩니다.

웹앱·크로스플랫폼·네이티브의 2년 총비용을 최초 개발, 유지·개선, OS 대응·심사로 나눈 누적 막대그래프
2년 총비용 구성 · 웹앱 최초 개발비를 100으로 둔 상대값 예시

차이를 만드는 것은 세 번째 항목입니다. iOS와 Android는 매년 새 버전을 내놓고, 그때마다 동작이 바뀌거나 정책이 바뀝니다. 앱을 손대지 않아도 대응 작업은 계속 생깁니다. 네이티브는 이 작업을 두 번 해야 합니다.

반대로 웹앱은 이 항목이 거의 없습니다. 브라우저가 알아서 최신 상태를 유지하기 때문입니다. 기능 요구가 웹으로 충족된다면 이것이 가장 큰 장점입니다.

앱스토어라는 변수

기술 선택만큼 자주 문제가 되는 것이 배포입니다. 웹은 고치는 즉시 반영되지만, 앱은 그렇지 않습니다.

웹앱은 배포 즉시 반영되는 반면 앱스토어 앱은 빌드·제출, 심사 대기, 사용자 업데이트 확산 단계를 거치는 과정 비교
수정 사항이 사용자에게 닿기까지 · 상대 비교

심사에 걸리는 시간도 문제지만, 더 큰 것은 사용자가 업데이트를 받는 속도입니다. 자동 업데이트를 켜두지 않은 이용자가 상당수이기 때문에, 구버전과 신버전이 한동안 함께 돌아갑니다. 서버를 함께 쓰는 서비스라면 구버전과의 호환을 계속 유지해야 한다는 뜻이고, 이것이 앱 운영에서 꾸준히 발목을 잡는 부분입니다.

그래서 자주 바뀌는 화면은 앱 안에서도 웹으로 띄우는 구성을 많이 씁니다. 공지, 이벤트, 약관처럼 수시로 손봐야 하는 영역이 대표적입니다.

실제로는 이렇게 시작하는 경우가 많다

처음부터 완성된 앱을 만들기보다, 단계를 나누는 편이 실패 비용이 작습니다.

1단계 — 웹으로 먼저 검증

기능이 실제로 쓰이는지, 어떤 화면에서 이탈하는지를 웹에서 확인합니다. 검색 유입도 이 단계에서 만들어집니다. 여기서 얻은 데이터가 앱의 설계를 바꿉니다.

2단계 — 재방문이 확인되면 앱

같은 사람이 반복해서 들어오는 것이 확인되면 그때 앱을 검토합니다. 푸시 알림이 의미를 갖는 시점도 이때입니다. 아직 재방문이 없는데 푸시부터 붙이면 알림 차단만 늘어납니다.

3단계 — 병목이 분명해지면 네이티브

크로스플랫폼으로 시작해 특정 화면에서만 성능이나 기기 제어가 부족하다면 그 부분만 네이티브로 바꿀 수 있습니다. 처음부터 전부 네이티브로 갈 이유는 생각보다 많지 않습니다.

결정 전 확인할 것

  1. 설치를 요구할 만한 이유가 있는가. 이용자가 앱을 설치하고 유지할 이유를 한 문장으로 말할 수 없다면 아직 앱을 만들 시점이 아닙니다.
  2. 2년치로 계산했는가. 최초 개발비만 비교하면 네이티브와 크로스플랫폼의 차이가 작아 보입니다. 유지와 OS 대응까지 넣어야 실제 차이가 드러납니다.
  3. 앱을 고칠 사람이 정해져 있는가. 앱은 만들고 끝나지 않습니다. OS가 올라갈 때 대응할 담당이 없다면 1~2년 뒤 실행되지 않는 앱이 남습니다.

정리하면, 앱을 만들지 말지보다 어느 단계에서 무엇을 앱으로 옮길지가 실제 결정입니다. 그 순서만 맞춰도 들어가는 비용이 크게 달라집니다.

/ 다음 단계

이런 문제, 직접 겪고 계신가요?

글로 정리한 방법을 실제 환경에 맞춰 적용하는 일까지 함께 하겠습니다.

영업일 기준 3일 이내 회신 · 상담 및 범위 견적 무료