아티클

정말 모바일 앱이 필요한가요?

30일 리텐션의 현실은 6% 미만이에요. 다운로드하는 앱이 필요한지 잘 만든 모바일 사이트면 되는지 정하는 법과, 어떤 숨은 비용이 붙는지 짚어요.

2026년 9월 6일모바일 앱 · 디지털 제품 · 웹 개발

‘경쟁사처럼 앱 하나 만들고 싶어요.’ 통계적으로, 모바일 제품을 만드는 팀이 가장 자주 받는 요청이면서 데이터에 가장 덜 기대는 요청이에요. 요청하는 팀 가운데 그 경쟁사가 정말로 앱에서 리텐션과 ROI를 내고 있는지, 아니면 브랜드 발표 자료의 한 줄로만 앱을 유지하는지 확인해 본 사람은 대개 없어요. ’네이티브냐 크로스 플랫폼이냐’에 답하기 전에, 그보다 앞선 질문에 먼저 답해 볼 만해요. 정말 다운로드하는 앱이 필요한가요?

네 가지 질문으로 만든 판단 기준

옳은 선택은 취향이 아니라 비즈니스 판단이고, 순서가 있는 네 가지 질문으로 된 간단한 기준이 있어요. 전형적인 사용자가 제품과 얼마나 자주 만나나요. 매일이나 매주면 설치형 앱이 정당화되고, 가끔이면 아니에요. 하드웨어 기능이나 지속적인 오프라인 접근이 실제로 필요한가요. 카메라, GPS, 센서, 블루투스, NFC 결제 같은 것들이요. 푸시 알림이 비즈니스 모델의 중심 채널인가요. 주문 상태, 예약 알림, 제품 추천 같은 것이요. 아니면 있으면 좋은 정도인가요. 플랫폼 수수료를 감당할 만한 인앱 구매 수익 모델이 있나요.

네 가지 중 최소 두 가지에 분명한 ’예’가 나오면, 네이티브든 크로스 플랫폼이든 앱은 경제적으로 말이 돼요. 답이 대부분 ’아니오’나 ’글쎄’라면 프로그레시브 웹 앱(PWA)이나 성능 좋은 모바일 사이트가 정직한 선택이에요. 제품을 가끔 쓰는 사람, 한 번의 예약, 정보 확인, 문의 폼 작성 같은 경우에는 한 번 쓰자고 설치하지 않을 앱보다 빠른 모바일 웹페이지에서 더 잘 전환돼요.

길은 하나가 아니라 셋

네이티브, 그러니까 iOS의 Swift/SwiftUI와 Android의 Kotlin/Jetpack Compose는 최고의 성능과 하드웨어 전면 접근을 줘요. 카메라, 센서, 블루투스, NFC, ARKit/ARCore까지요. 각 플랫폼 가이드라인과의 정합성도 완벽해요. 대신 크로스 플랫폼보다 1.5~2배 비싸요. 사실상 두 팀과 두 코드베이스를 나란히 유지해야 하니까요. 그래픽 부하가 큰 앱, 게임, AR, 고급 하드웨어 연동, 또는 사용자 1,000만 명을 넘겨 확장할 제품이라면 정당화돼요.

크로스 플랫폼, 그러니까 Flutter나 React Native는 하나의 코드베이스로 두 플랫폼을 덮어요. 코드 공유율은 70~~90%이고, 네이티브 이중 개발 예산의 40~~60%로, 커머스, 예약, 로열티, 콘텐츠 같은 대다수 비즈니스 앱에서 네이티브 성능의 90% 이상을 내요. Flutter는 시장 채택에서 React Native를 앞질렀고 개발 주기도 더 빠른 쪽으로 가고 있어요. React Native는 팀에 이미 JavaScript/React 개발자가 있을 때 여전히 유효해요.

프로그레시브 웹 앱은 홈 화면에 설치되고 일부 오프라인에서 동작하며 알림도 보내는 웹 앱이에요. App Store나 Google Play를 거치지 않고 그 수수료도 없어요. 네이티브보다 60~~80% 저렴하고, 콘텐츠형이나 단순 거래형 앱에서 네이티브 성능의 85~~95%에 도달해요. 한계는 분명해요. iOS에서 푸시 알림 지원은 Safari 16.4부터야 생겼고 네이티브보다 제한적이에요. 고급 하드웨어 접근도 좁아요. 그리고 PWA는 App Store와 Google Play의 오가닉 검색 노출을 잃고, 일부 업종에서는 최종 고객이 ’진짜 앱’에 연결 짓는 신뢰 신호도 잃어요.

각 선택지의 실제 비용

루마니아 시장 기준 참고 가격대예요(부가세 제외). 하나의 핵심 흐름에 집중한 MVP, 즉 인증과 핵심 화면 24개, 결제 흐름 하나, 두 스토어 배포까지는 2만 5,000유로에서 시작해 7만 유로까지 갈 수 있어요. 다중 권한, 결제, 백오피스, 기존 시스템 연동이 들어간 완성형 제품은 7만20만 유로예요. 핀테크나 헬스케어처럼 규제를 받거나 대규모인 플랫폼은 20만 유로를 넘어요.

비용의 가장 큰 차이는 기능 복잡도가 아니라 기술 선택에서 나와요. 네이티브 이중 플랫폼은 크로스 플랫폼보다 1.5~~2배 비싸요. 예산이 빠듯하다면 크로스 플랫폼이나 PWA가 완전한 네이티브 비용의 각각 40~~60%와 20~40%로 기능적 결과의 90%를 가져다줘요.

판매 자료가 아닌 실제 리텐션

여기가 대부분의 에이전시가 빼놓는 부분이에요. 판매에 도움이 안 되니까요. 시장 평균 30일 리텐션은 Android에서 3.8%, iOS에서 5.3%에 불과하고 1일 리텐션은 20~25%예요. 사용자의 약 4분의 1이 한 번 써 보고 앱을 버리고, 일간 활성 사용자의 77%가 사흘째까지 사라져요. 평균적인 사용자는 휴대폰에 80개쯤 앱을 깔아 두지만 한 달에 실제로 쓰는 건 30개 정도, 하루에는 10개 정도예요.

이 수치는 낙담할 이유가 아니라, 만들기 전에 위 판단 기준에 정직하게 답해야 하는 바로 그 근거예요. 주문, 예약, 구독처럼 실제로 자주 쓰이는 상황을 겨냥해 잘 만든 앱은 이 평균을 꾸준히 웃돌 수 있어요. 실제 사용 빈도를 검증하지 않고 ‘그냥’ 만든 앱은 기술적으로 아무리 잘 만들어도 정확히 이 평균 안에 들어가요.

초기 예산에 아무도 넣지 않는 비용

개발은 넣고 유지보수는 통째로 빼놓은 예산은 시장에서 흔한 실수이고, 비싼 실수예요. 유지보수가 없는 앱은 12~18개월 안에 고장 나는 경향이 있어요. iOS와 Android의 연간 업데이트가 권한, API, 심사 요건을 바꾸기 때문이에요. 유지보수는 선택이 아니라 반복되는 예산 항목이에요. 일회성 비용이 아니에요.

여기에 플랫폼 수수료가 붙어요. Apple과 Google은 인앱 매출의 30%를 기본으로 가져가고, 전용 프로그램(Apple Small Business Program, Google Play의 연 100만 달러 미만 기준)을 통해 소규모 기업에는 15%로 낮춰 줘요. 여기에 Apple Developer 계정의 연 99달러와 Google Play의 일회성 25달러가 더해져요. 그리고 배포는 즉시 되지 않아요. 첫 제출에서 Apple은 보통 3~7일이 걸리고 Google도 비슷하거나 조금 더 걸려요. 첫 심사에서 반려되는 건 흔하고 정상이지, 허둥댈 비상 상황이 아니에요.

가장 비싼 기술적 실수 중 하나는 ‘유행 따라’ 기술을 고르는 거예요. 실제 기술적 필요 없이 ’프리미엄해 보인다’는 이유로 네이티브를 고르는 식이죠. 결과는 기한 없이 두 배로 늘어난 유지보수 비용이고, 전면 재작성 없이는 멈출 수 없어요.

누가 앱을 만드는지, 그리고 왜 연속성이 중요한지

모바일 앱 개발의 경쟁은 세 방향에서 오고, 각각 고유한 위험이 있어요. 큰 에이전시는 프로세스가 성숙하지만 납품 주기가 길고 비용이 높아요. 프리랜서나 소규모 팀은 단기적으로는 저렴하지만 연속성 위험이 실재해요. 문서화되지 않은 코드, 그리고 하필 Apple이나 Google이 대형 OS 업데이트를 강제하는 달에 연락이 닿지 않는 개발자 같은 것들이요. 인하우스 팀은 iOS와 Android 두 종류의 개발자를 뽑거나 시니어 크로스 플랫폼 테크 리드를 뽑아야 하고, 램프업 시간과 실제 업무량과 무관한 고정 비용이 따라와요.

프리랜서와 만든 앱에서 가장 흔한 위험은 초기 코드 품질이 아니라 바로 이 연속성이에요. 인수인계 문서와 명시적인 유지보수 SLA가, iOS와 Android의 연간 업데이트를 견디는 앱과 아무도 이유나 고치는 법을 모른 채 조용히 망가지는 앱을 갈라요. 납품에서 지키는 표준들, 즉 iOS의 Human Interface Guidelines, Android의 Material Design 3, 배포 적합성을 위한 App Store Review Guidelines와 Google Play Developer Policy는 겉치레가 아니라, 앱이 재제출을 반복하지 않고 심사를 통과하기 위한 조건이에요.

다른 어떤 결정보다 먼저 할 질문

주문, 예약, 배송, 구독처럼 반복 고객 기반이 있고 잦은 사용이나 알림이 실제로 중요한 제품이라면 앱은 경제적으로 말이 돼요. 고객이 한 번이나 가끔 온다면, 그 돈은 빠르고 잘 만든 모바일 사이트에 쓰는 게 더 효율적이에요. 두 판단의 차이는 내부 발표 자료 속 제품의 모습이 아니라 실제 리텐션에서 드러나요. 예산을 투입하기 전에 비용과 성능을 근거로 한 문서화된 권고안을 원하신다면, 모바일 앱 페이지가 바로 이 첫 단계를 설명해요. 판매 전의 형식적 절차가 아니라 별도의 산출물로 다뤄요.

출처

비슷한 상황이신가요?

지금 어느 지점에 계신지 알려주세요. 여기서 읽으신 것과 다른 답이 맞다면 그렇게 말씀드려요.

견적 요청하기