앱·모바일 웹, 무엇부터 만들까? 첫 출시 범위를 정하는 기준

1 첫 출시에서 끝내야 할 행동을 하나 정합니다

“예약 서비스를 만들고 싶은데, 아이폰 앱과 안드로이드 앱, 홈페이지를 한꺼번에 만들어야 하나요?” 처음부터 플랫폼을 고르면 아직 필요하지 않은 화면까지 개발 범위에 들어가기 쉽습니다.

먼저 고객이 첫 버전에서 끝내야 할 행동을 적으세요. 행사 소개를 읽고 신청하는 것인지, 매일 운동 기록을 남기는 것인지, 현장에서 기기를 연결해 측정하는 것인지에 따라 출발점이 달라집니다.

이 글에서 모바일 웹은 휴대폰에서도 쓰기 편하게 만든 반응형 웹서비스를 뜻합니다. 앱은 기기에 설치하는 iOS·Android 앱이며, 플랫폼별로 개발하거나 Flutter 같은 크로스플랫폼 방식으로 만들 수 있습니다. PWA는 웹서비스에 설치·오프라인 이용 등 앱과 비슷한 경험을 더하는 방식입니다. 일반 모바일 웹에 그런 기능이 모두 자동으로 생기는 것은 아닙니다. MDN의 PWA 안내를 참고할 수 있습니다.

아래 상황과 그림은 선택을 설명하기 위한 가상 예시입니다. 특정 고객의 프로젝트 결과나 전환율을 나타내지 않습니다.

2 처음 만나는 경로와 다시 찾는 이유를 봅니다

고객이 검색, 블로그, 카카오톡 링크나 QR 코드로 들어와 내용을 확인하고 신청한다면, 설치 없이 열리는 모바일 웹부터 검토할 수 있습니다. 링크를 받은 순간 필요한 행동을 끝낼 수 있는지 살펴보는 것입니다. 웹을 만들었다고 검색 노출이나 문의가 자동으로 생기는 것은 아니며, 소개 내용과 방문 경로도 함께 준비해야 합니다.

매일 기록을 남기거나 자주 재생하고, 이전 작업을 이어서 하는 경험이 중심이라면 앱을 우선 검토할 이유가 있습니다. 다만 앱 아이콘이 생겼다고 재방문이 보장되지는 않습니다. 고객이 다시 열었을 때 얻는 가치가 먼저 있어야 합니다.

• 공유 링크에서 소개를 읽고 문의·신청하기: 모바일 웹을 먼저 검토할 수 있습니다. 휴대폰에서 입력부터 완료까지 편한지 확인하세요.
• 기록·재생 등 같은 기능을 자주 사용하기: 앱 또는 설치형 웹 앱을 검토할 수 있습니다. 다시 여는 동선과 필요한 기능이 맞는지 확인하세요.
• 화면을 끄거나 외부 기기를 연결한 상태에서 사용하기: 핵심 동작을 검증한 뒤 선택하세요. 대상 기기에서 요구한 동작을 유지할 수 있는지 확인해야 합니다.

위 항목은 우선 검토할 방향입니다. 한 서비스 안에서도 처음 방문하는 사람은 웹에서 안내받고, 자주 쓰는 사람은 앱을 사용하는 구성이 가능합니다. web.dev의 PWA 설명도 웹의 링크 접근성과 설치형 경험을 함께 다룹니다.

3 기능 이름보다 사용 조건을 확인합니다

“카메라가 필요하니 앱이어야 한다”거나 “알림이 필요하니 웹은 안 된다”고 바로 결정하지 마세요. 웹에서도 카메라·마이크와 알림을 구현할 수 있지만, 지원 조건을 확인해야 합니다.

예를 들어 웹의 카메라·마이크 접근은 지원 브라우저의 보안 연결(HTTPS)과 사용자 권한 등이 필요합니다. MDN의 getUserMedia 안내에 설명된 것처럼 권한 거부나 사용할 수 있는 장치가 없는 경우도 처리해야 합니다. 사진 한 장을 첨부하는 일과 실시간 영상을 계속 분석하는 일은 같은 요구사항이 아닙니다.

iPhone·iPad의 웹 푸시는 iOS·iPadOS 16.4부터 홈 화면에 추가한 웹 앱에서 지원되며, 사용자 동작에 따른 권한 요청과 허용이 필요합니다. WebKit 공식 안내를 기준으로 대상 환경을 확인하세요. 모든 브라우저 탭에서 같은 방식으로 동작한다고 가정하면 안 됩니다.

특히 다음 조건은 작은 기능 검증을 먼저 진행하는 편이 좋습니다.

• 화면을 끄거나 다른 앱으로 이동했을 때 필요한 작업
• 인터넷이 끊긴 상태에서 읽기·저장하고 다시 연결할 때의 처리
• 블루투스 등 외부 기기와 연결하는 방식 및 대상 기기
• 권한 거부, 절전 설정, 앱·브라우저 종료 후의 동작

기능이 지원된다는 설명과, 우리 서비스가 요구한 조건에서 동작한다는 확인은 각각 필요합니다. 앱도 운영체제의 권한·백그라운드·전력 관리 제약을 받습니다. 대상 OS, 브라우저, 설치 상태와 실제 기기를 정해 검증해야 합니다.

4 비용은 같은 운영 범위로 비교합니다

모바일 웹으로 시작하면 스토어용 패키지와 제출 작업을 첫 범위에서 줄일 수 있습니다. 그렇다고 로그인, 예약 처리, 결제, 관리자 화면과 서버가 필요 없어지는 것은 아닙니다. 반대로 기기 안에서만 동작하는 작은 도구는 서버가 필요하지 않을 수도 있습니다. 필요한 데이터와 운영 방식에 따라 정할 일입니다.

견적을 비교할 때는 화면 이름보다 포함되는 작업을 맞추세요.

• 고객의 행동을 처리하는 화면과 서버 기능
• 운영자가 직접 수정할 콘텐츠와 처리할 문의·신청
• 지원할 기기·브라우저, 접근성, 오류 상황의 확인 범위
• 배포·업데이트 담당자와 출시 후 운영 범위

웹은 브라우저별 동작과 배포·캐시 갱신을, 앱은 플랫폼별 빌드·권한·스토어 제출과 업데이트 과정을 고려해야 합니다. 오프라인 기능 역시 저장할 데이터와 재연결 처리를 설계해야 하므로, PWA라는 이름만 붙인다고 완성되지 않습니다.

처음부터 어느 쪽이 더 저렴하다고 정하기보다 같은 고객 행동을 어디까지 구현하고 운영할지 맞춰 비교하세요.

5 작은 범위로 시작하고 확장 조건을 정합니다

가상의 체험 행사 서비스를 생각해보겠습니다. 첫 목표가 “참가자가 링크로 일정을 보고 신청할 수 있는가”라면 소개·신청 모바일 웹과 운영자가 확인할 도구부터 시작할 수 있습니다. 이후 참가자가 여러 행사에 반복 참여하며 일정과 기록을 계속 확인한다면, 그 사용 경험을 개선할 앱을 검토할 수 있습니다.

반대로 첫 목표가 기기를 연결해 측정하고 화면을 끈 동안에도 정해진 동작을 이어가는 것이라면, 단순 신청 웹으로는 핵심 가정을 확인하기 어렵습니다. 필요한 동작을 실제 기기에서 검증한 뒤 플랫폼과 첫 개발 범위를 정하는 편이 적절합니다.

확장 여부는 실제 관찰로 판단하세요. 고객이 어디에서 그만두는지, 같은 기능을 얼마나 자주 사용하는지, 설치가 도움이 되는 상황은 무엇인지 확인합니다. 모든 서비스에 같은 방문자 수나 전환율 기준을 적용할 필요는 없습니다.

웹 다음에 앱을 만든다면 기존 계정·데이터·서버 기능을 함께 사용할 수 있도록 설계할 수 있습니다. 다만 기존 웹 화면이 앱으로 자동 변환되거나 개발비가 그대로 절약되는 것은 아닙니다. 재사용 가능한 부분과 새로 설계·구현할 부분은 현재 구조를 확인해야 알 수 있습니다.

6 개발 상담 전에 이 네 가지를 적어보세요

처음부터 완성된 기획서를 준비할 필요는 없습니다. 다음 네 가지가 있으면 첫 버전의 방향을 구체적으로 논의할 수 있습니다.

1. 첫 방문 경로: 검색, 광고, 공유 링크, 매장 QR, 스토어 등 어디에서 고객을 만날지
2. 반복 이용 이유: 한 번 신청하고 끝나는지, 기록·재생·관리 때문에 다시 방문하는지
3. 필수 기기 기능: 카메라, 알림, 오프라인, 백그라운드, 외부 기기 연결이 어떤 조건에서 필요한지
4. 첫 버전 범위: 고객이 반드시 끝내야 할 행동과 운영자가 처리할 일, 예산·일정의 우선순위

기존 홈페이지나 앱, 이미 쓰는 운영 도구가 있다면 함께 알려주세요. 활용 가능한 부분을 확인한 뒤 첫 출시와 이후 확장 범위를 나누면 됩니다.

키플은 자체 앱·게임을 개발·운영하며, 의뢰 프로젝트의 앱과 웹, 관리자 화면도 함께 만듭니다. 앱 개발 상담 안내와 포트폴리오에서 작업 범위를 확인할 수 있습니다. 어떤 형태를 만들지 아직 정하지 못했다면, 고객이 해야 할 행동부터 설명해 주세요.