“웹은 있는데 앱도 필요해요.” 이 요청을 받으면 대부분 앱을 새로 만드는 견적이 나갑니다. 그런데 서비스 성격에 따라, 있는 웹을 그대로 앱으로 감싸는 게 훨씬 나은 경우가 있습니다.
밥알을 그렇게 냈습니다
밥알은 식품 성분을 확인하고 정보를 나누는 서비스입니다. 웹으로 먼저 만들었고, 앱 요청이 생겼을 때 Capacitor로 감싸서 앱스토어와 플레이스토어에 냈습니다.
Capacitor는 웹을 앱 껍데기 안에 넣어주는 도구입니다. 화면은 웹 그대로 쓰고, 카메라나 알림 같은 기기 기능은 앱 쪽에서 연결합니다.
이 방식이 맞는 경우
- 화면이 대부분 목록과 글, 폼으로 되어 있다
- 웹에서 이미 잘 돌아가고 있다
- 빠르게 스토어에 올려야 한다
- 콘텐츠가 자주 바뀐다
특히 마지막이 큽니다. 웹을 고치면 앱도 같이 바뀝니다. 스토어 심사를 다시 안 받아도 됩니다. 콘텐츠가 자주 바뀌는 서비스라면 이게 엄청난 장점입니다.
웹을 고치면 앱이 같이 바뀐다는 점, 이것 하나로 결정되는 경우가 많습니다.
이 방식이 안 맞는 경우
- 화면 전환이 아주 부드러워야 하는 서비스
- 카메라나 센서를 깊게 쓰는 서비스
- 오프라인에서도 대부분 기능이 돌아야 하는 서비스
이런 건 처음부터 앱으로 만드는 게 맞습니다. 감싸는 방식은 아무래도 앱 특유의 매끄러움에서 조금 밀립니다.
감싸기만 하면 심사에서 막힙니다
중요한 부분입니다. 웹을 그냥 껍데기에 넣기만 하면 애플 심사에서 거절될 수 있습니다. “웹사이트를 그대로 옮긴 앱”은 반려 사유가 됩니다.
그래서 앱다운 요소를 반드시 붙여야 합니다. 밥알에서는 이렇게 했습니다.
- 카카오 로그인을 앱 방식으로 연결
- 푸시 알림
- 앱 버전 관리와 업데이트 안내
- 앱 안에서만 자연스러운 화면 이동 처리
이 정도가 들어가면 “앱으로서의 가치”가 인정됩니다.
실제로 손이 가는 부분들
감싸기만 하면 끝이라고 생각하면 곤란합니다. 실제로는 이런 게 필요합니다.
- 뒤로가기 버튼 처리 (안드로이드는 물리 버튼이 있습니다)
- 화면 아래 여백, 상단 노치 대응
- 앱 안에서 외부 링크를 열 때의 동작
- 로그인 상태 유지
이걸 안 다듬으면 “웹을 그냥 띄운 것 같다”는 느낌이 그대로 남습니다.
정리
- 웹이 이미 있고 화면이 문서 위주라면 감싸는 방식이 빠르고 쌉니다.
- 웹을 고치면 앱도 바뀝니다. 심사 없이 반영됩니다.
- 다만 앱다운 기능을 붙여야 심사를 통과합니다.
- 부드러운 움직임이 핵심인 서비스라면 처음부터 앱으로 만드는 게 낫습니다.
무엇이 맞는지는 서비스 성격에 달렸습니다. 상담에서 이 판단부터 같이 하시면 예산을 크게 아낄 수 있습니다.