앱 개발 vs 웹 개발, 무엇을 먼저 만들어야 하나 — 발주 전에 답해야 할 5가지 질문

앱 개발 vs 웹 개발은 대부분의 프로젝트에서 예산 회의 때 결정됩니다. 앱은 비싸다고 하니 웹으로 하자, 또는 요즘은 다 앱이니까 앱으로 하자. 두 결정 모두 근거가 서비스가 아니라 분위기입니다.

그리고 이 결정은 되돌리기가 비쌉니다. 웹으로 만든 뒤 1년쯤 지나 “앱도 필요하다”는 결론이 나면, 대개 서버부터 다시 손대야 합니다. 앱으로 먼저 만든 서비스가 유입이 없어 고전하면, 이번에는 웹 화면을 통째로 새로 만들어야 합니다. 어느 쪽이든 처음 견적의 절반 이상이 다시 듭니다.

디비컨설팅은 삼성물산, GS건설, 하나투어, 직방, LS일렉트릭, 교보생명, 가천대학교 등과 100건 이상의 웹·앱·플랫폼 프로젝트를 수행해 왔습니다. 앱만 만든 프로젝트, 웹만 만든 프로젝트, 그리고 GS건설 엘리시안 리조트처럼 웹과 앱을 함께 구축한 프로젝트가 모두 있습니다. 그 경험에서 확인한 것은 단순합니다. 앱이냐 웹이냐는 기술 선택이 아니라 사용자가 이 서비스에 얼마나 자주 돌아오는지에 대한 판단입니다.

이 글은 발주 전에 답해 두면 그 판단이 훨씬 쉬워지는 다섯 가지 질문을 정리한 것입니다.

예산으로 정하면 왜 어긋나는가

“앱이 비싸다”는 절반만 맞습니다

초기 구축만 놓고 보면 앱이 웹보다 비싼 것은 맞습니다. iOS와 Android 두 벌을 만들어야 하고, 스토어 심사 대응이 붙고, 기기와 OS 버전별 테스트가 늘어납니다.

다만 그 차이는 구축비에서 끝나지 않습니다. 앱은 출시 이후에도 OS 업데이트마다 대응해야 하고, 수정 사항을 반영하려면 다시 심사를 거쳐야 합니다. 웹은 배포하면 그 순간 반영됩니다. 예산을 볼 때 구축비만 비교하면 이 차이가 통째로 빠집니다. 출시 후에 발생하는 비용 구조는 앱 유지보수 비용이 출시 후에 드는 이유에 항목별로 정리해 두었습니다.

설치는 기능이 아니라 장벽입니다

앱을 선택할 때 가장 자주 과소평가되는 것이 설치입니다. 웹은 링크를 누르면 바로 열립니다. 앱은 스토어로 이동해, 내려받고, 열고, 대개 회원가입까지 해야 첫 화면을 봅니다.

이 장벽을 넘을 이유가 사용자에게 있어야 앱이 작동합니다. 그 이유는 대체로 하나입니다. 자주 돌아올 서비스인가. 여기서 첫 번째 질문이 나옵니다.

발주 전에 답해야 할 5가지 질문

1. 사용자가 얼마나 자주 돌아옵니까

하루에 여러 번 열어 보는 서비스인지, 한 달에 한 번인지, 필요할 때만 한 번 쓰고 잊는 서비스인지 먼저 답해 보십시오.

매일 쓰는 서비스라면 설치 장벽은 한 번만 넘으면 되고, 홈 화면에 아이콘이 남아 있다는 것 자체가 자산이 됩니다. 반대로 분기에 한 번 쓰는 서비스라면 사용자는 설치하지 않거나, 설치했더라도 다음에 쓸 때쯤엔 이미 지웠습니다. 이런 서비스에 앱을 만들면 앱을 만든 비용에 더해 앱으로 사람을 데려오는 비용까지 계속 나갑니다.

2. 기기 기능이 실제로 필요합니까

앱이 웹보다 확실히 유리한 영역은 기기에 붙는 기능입니다. 다음 중 서비스의 핵심에 해당하는 것이 있는지 확인해 보십시오.

• 푸시 알림을 서비스의 핵심 동선으로 써야 하는가
• 카메라·QR·바코드 인식이 상시로 필요한가
• 위치를 지속적으로 추적해야 하는가
• 블루투스·NFC로 출입, 결제, 기기 제어를 해야 하는가
• 네트워크가 끊긴 상태에서도 동작해야 하는가
• 앱이 화면에 없을 때도 백그라운드에서 무언가 돌아야 하는가

여기서 “있으면 좋은 것”과 “없으면 서비스가 성립하지 않는 것”을 구분하는 것이 중요합니다. 푸시가 마케팅 수단이면 웹에서도 대안이 있습니다. 반면 출입 통제나 설비 점검처럼 기기 기능이 업무 그 자체인 서비스는 웹으로 대체되지 않습니다. 저희가 프라임 오피스 빌딩 관리 시스템을 구축할 때 앱이 필요했던 이유가 여기에 있습니다.

3. 누가 씁니까 — 불특정 고객인가, 정해진 사용자인가

사용자가 누구인지에 따라 설치 장벽의 높이가 완전히 달라집니다.

입주민, 재학생, 사내 임직원, 계약된 협력사처럼 이미 관계가 있는 사용자라면 설치를 요청할 수 있습니다. 안내문 한 장이면 되고, 설치율도 예측 가능합니다. 반대로 검색이나 광고로 처음 들어오는 불특정 고객이라면 설치를 요구하는 순간 대부분이 이탈합니다.

실무에서는 이 질문 하나로 답이 정해지는 경우가 많습니다. 관계가 이미 있으면 앱이 가능하고, 관계를 지금부터 만들어야 하면 웹이 먼저입니다.

4. 첫 진입 경로가 검색입니까

네이버와 구글에서 검색으로 사람을 데려와야 하는 서비스라면 웹이 없다는 것은 유입 경로가 없다는 뜻입니다. 앱 안의 콘텐츠는 검색엔진에 노출되지 않습니다.

콘텐츠로 사람을 모으고, 그중 일부를 고객으로 바꾸는 구조라면 순서는 명확합니다. 웹이 먼저입니다. 앱은 이미 들어온 사용자를 붙잡아 두는 단계에서 의미가 생깁니다.

5. 출시 이후 1년을 감당할 수 있습니까

앱은 출시가 끝이 아닙니다. iOS와 Android가 각각 매년 주요 버전을 내고, 그때마다 동작 확인과 대응이 필요합니다. 스토어 정책이 바뀌면 심사에서 반려되기도 합니다. 수정 사항을 반영할 때마다 심사 기간이 일정에 포함됩니다.

이 부담을 감당할 예산과 담당자가 없다면, 앱은 출시 몇 달 뒤부터 방치됩니다. 방치된 앱은 없는 앱보다 나쁩니다. 스토어 리뷰에 그 상태가 그대로 남기 때문입니다. 심사와 일정의 관계는 앱 개발 기간이 계획보다 길어지는 이유에서 단계별로 다뤘습니다.

대부분의 정답은 “웹 먼저, 앱은 나중에”입니다 — 조건이 하나 있습니다

다섯 질문에 답해 보면 상당수 서비스가 같은 결론에 도달합니다. 웹으로 먼저 시작하고, 사용자가 실제로 자주 돌아온다는 것이 확인되면 그때 앱을 붙이는 것입니다. 검증되지 않은 가정에 두 배의 구축비를 쓰지 않는 방식입니다.

문제는 이 순서가 저절로 되지 않는다는 점입니다. 여기서 프로젝트가 갈립니다.

웹을 만들 때 화면과 서버 로직이 한 덩어리로 붙어 있으면, 나중에 앱을 만들 때 앱이 쓸 서버가 사실상 없습니다. 앱 화면만 새로 만드는 것이 아니라 서버를 다시 설계해야 하고, 그 시점에는 이미 실서비스 데이터가 쌓여 있어 이전 작업까지 따라붙습니다. “앱은 나중에”가 “앱은 새 프로젝트”가 되는 지점입니다.

반대로 처음부터 화면과 데이터를 분리해 API 형태로 만들어 두면, 나중에 붙이는 앱은 그 API를 그대로 씁니다. 서버는 그대로 두고 화면만 추가하는 작업이 됩니다. 초기에 드는 추가 비용은 크지 않고, 나중에 아끼는 비용은 큽니다.

그래서 발주서에 넣어야 할 문장은 “앱도 나중에 만들 수 있게 해 주세요”가 아니라 “API 기반으로 설계하고, API 명세서를 산출물에 포함해 주세요”입니다. 앞 문장은 지킬 의무가 없고, 뒤 문장은 검수할 수 있습니다.

앱으로 가기로 정했다면 그다음 갈림길은 네이티브냐 크로스플랫폼이냐입니다. 그 판단 기준은 크로스플랫폼 앱 개발과 네이티브가 갈리는 5가지 기준에 따로 정리해 두었습니다. 웹으로 간다면 만들 것이 홈페이지인지 웹 플랫폼인지부터 구분하셔야 하는데, 그 기준은 웹 플랫폼 개발과 홈페이지 제작의 차이에 있습니다.

그런데 이 판단은 누가 합니까

다섯 질문을 다시 보면 공통점이 있습니다. 전부 기술 질문처럼 보이지만 실제로는 발주사의 사업 질문입니다. 우리 고객이 얼마나 자주 돌아오는가, 첫 진입이 검색인가 배포인가, 1년 뒤 운영 예산이 있는가. 개발사가 대신 답할 수 없습니다.

동시에 그 답을 구조 결정으로 번역할 수 있어야 합니다. “나중에 앱도 할 수 있게”라는 말이 API 분리 설계를 뜻한다는 것을 아는 사람이 초기 설계 회의에 있어야 합니다. 없으면 그 요청은 견적에도, 산출물에도 남지 않습니다. 이 번역이 문서로 남는 자리가 요구사항 정의서입니다.

그래서 한국 기업이 실제로 마주하는 선택지는 이렇게 정리됩니다.

	국내 개발사	해외 직접 발주	한국 PM + 글로벌 개발팀
개발 단가	높음	낮음	낮음
앱·웹 판단 책임	개발사	발주사 본인	한국 PM
확장 구조 설계 요구	가능	발주사가 영어로 명시	한국어로 PM이 반영
커뮤니케이션 언어	한국어	영어	한국어
발주사 담당자 투입 시간	보통	매우 많음	적음
재작업 리스크	낮음	높음	낮음
총비용 관점	비쌈	기대만큼 안 싸다	실질 절감

해외 개발사에 직접 발주하면 단가는 확실히 내려갑니다. 다만 위의 다섯 가지를 발주사 담당자가 직접, 영어로, 개발 공수와 확장 구조까지 판단해 가며 정리해야 합니다. 사내에 개발 조직이 없는 회사에서 이 방식이 기대만큼 저렴해지지 않는 이유가 여기에 있습니다. 절감한 단가가 담당자의 시간과 재작업으로 되돌아옵니다.

디비컨설팅이 발주 전 단계에서 하는 일

앱 개발 외주와 웹 개발 외주는 다음 5단계로 진행됩니다. 앱이냐 웹이냐가 결정되는 곳은 첫 번째 단계입니다.

1. 상담 및 요구 분석 — 비즈니스 목표와 기술 요구사항을 한국어 문서로 정리합니다. 위의 다섯 가지 질문을 이 단계에서 끝내고, 확장 구조가 필요하면 API 분리를 요구사항에 명시합니다.
2. 개발팀 구성 — 프로젝트에 맞춘 전담팀을 2~4주 안에 구성합니다.
3. 프로젝트 개발 — 애자일 방식으로 진행하며 진행 상황을 투명하게 공유합니다. 발주사 담당자가 하루를 조율에 쓰지 않는 것이 목표입니다.
4. 테스트 및 배포 — QA 프로세스를 거쳐 릴리스합니다. 앱은 스토어 심사 일정까지 포함해 계획합니다.
5. 운영 및 유지보수 — 문서와 함께 인계하고 장기 운영을 지원합니다.

발주사는 한국인 PM하고만 한국어로 소통합니다. 요구사항 정의, 일정 관리, 검수가 PM의 책임 범위입니다. “나중에 앱도 붙일 수 있게”라는 요청이 설계에 반영되었는지 확인하는 것도 PM의 일입니다.

이 구조로 만든 것들

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

웹만, 앱만, 그리고 둘을 함께 만든 사례가 모두 들어 있습니다. 100건 이상의 프로젝트, 50개 이상의 글로벌 파트너사, 고객 만족도 98%. 다른 사례는 포트폴리오에서 확인하실 수 있습니다.

이런 기업에 적합합니다

• 앱과 웹 중 무엇을 먼저 만들지 내부에서 결론이 나지 않아 발주가 멈춰 있는 기업
• 웹으로 시작하되 앱으로 확장할 가능성을 열어 두고 싶은 기업
• 앱을 만들었는데 설치가 늘지 않아 웹 유입 구조를 다시 짜야 하는 기업
• 국내 견적이 예산을 넘는데, 해외 직접 발주는 관리할 사람이 없는 기업

반대로 권하지 않습니다

• 사내에 기획자와 개발 리드가 이미 있는 기업. 위의 다섯 가지를 직접 판단하고 설계 요구까지 명시하실 수 있다면 해외 인력을 직접 계약하는 편이 더 쌉니다. 저희 구조의 가치가 정확히 그 부분에 있기 때문입니다.
• 페이지 몇 개짜리 브로슈어형 사이트. 앱이냐 웹이냐를 고민할 단계가 아니고, 저희 구조는 과합니다.
• 2~3주 안에 결과물이 필요한 프로젝트. 전담팀 구성에만 2~4주가 걸리고, 앱은 여기에 스토어 심사 기간이 더해집니다.
• 이미 앱으로 결정이 끝났고 이유를 묻지 않기를 원하는 발주. 저희는 첫 단계에서 다섯 질문을 다시 확인합니다. 그 과정이 불필요하다면 맞지 않습니다.

자주 묻는 질문

기획서가 없는데 앱·웹 판단까지 상담이 되나요?

가능합니다. 해결하려는 문제, 주요 사용자, 필수 기능 3~5개, 일정과 예산 범위만 알려주시면 개략 견적을 드립니다. 앱이냐 웹이냐는 상담 단계에서 이 글의 다섯 질문을 함께 짚으며 정리하고, 그 결론을 요구사항 정의서에 반영합니다.

비용은 어떤 기준으로 산정되나요?

등급별 단가에 투입 기간을 곱하는 방식입니다. 기획, 디자인, 개발, QA, 배포, 유지보수를 항목별로 구분해 제시합니다. 앱과 웹을 함께 검토하실 경우 두 방향의 견적을 나란히 드려 총비용을 비교하실 수 있게 합니다.

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

발주사는 한국인 PM하고만 한국어로 소통합니다. 요구사항 정의, 일정 관리, 검수가 모두 PM의 책임 범위입니다. 개발팀과의 영어 소통은 PM이 담당하며, 발주사가 부담하지 않습니다.

웹으로 먼저 시작했다가 나중에 팀을 늘려 앱을 붙일 수 있나요?

가능합니다. 전담팀, 장기 협업, 인력 단위, 프로젝트 단위 중에서 선택하실 수 있고 진행 중 조정도 가능합니다. 다만 앱 확장을 염두에 두신다면 웹 착수 시점에 API 분리 설계를 요구사항에 넣어 두시는 편이 훨씬 저렴합니다.

소스코드 소유권은 어떻게 되나요?

발주사 귀속입니다. API 명세서, DB 스키마, 배포 절차 문서까지 함께 인계합니다. 나중에 앱을 다른 회사가 붙이더라도 그 문서만으로 이어받을 수 있는 상태로 넘기는 것을 기준으로 삼습니다.

정리

앱 개발 vs 웹 개발은 예산표로 결정할 문제가 아닙니다. 사용자가 얼마나 자주 돌아오는지, 기기 기능이 서비스의 핵심인지, 사용자가 이미 관계가 있는 사람들인지, 첫 진입이 검색인지, 출시 이후 1년을 감당할 수 있는지 — 이 다섯 가지가 답을 정합니다. 상당수 서비스에서 답은 “웹 먼저, 앱은 검증 후”이고, 그 순서가 실제로 가능하려면 처음부터 API 기반으로 설계해 두어야 합니다. 이 판단과 설계 요구를 발주사가 직접, 영어로 정리할 수 없다면, 그 일을 한국어로 대신 해 주는 사람이 프로젝트 초반에 있어야 합니다.