[카테고리:] 앱개발

크로스플랫폼 앱 개발로 갈지 네이티브로 갈지가 정해지지 않은 상태에서 받은 견적서는, 사실 비교할 수 없는 숫자입니다. 같은 기획서를 세 곳에 보냈는데 한 곳은 하나의 코드로 iOS와 안드로이드를 함께 만들겠다고 하고, 다른 곳은 두 개를 따로 만들겠다고 합니다. 금액은 그 자리에서 두 배 가까이 벌어집니다. 그런데 발주사 담당자 입장에서는 어느 쪽이 우리 서비스에 맞는지 판단할 근거가 없습니다. 설명을 들어도 대부분 개발사의 사정처럼 들립니다.

이 글은 그 판단을 발주사 쪽에서 할 수 있게 만드는 것을 목표로 합니다. 기술 용어를 설명하려는 것이 아니라, 무엇을 기준으로 갈라야 견적과 일정이 예측 가능해지는지를 정리합니다.

디비컨설팅은 삼성물산 홈닉(주거 플랫폼 앱), GS건설 엘리시안 리조트(리조트 웹·앱 통합 구축), 하나투어 하나오픈챗, 직방 호갱노노를 포함해 100건 이상의 프로젝트를 수행했고, 50개 이상의 글로벌 파트너사와 함께 일합니다. 아래 내용은 그 과정에서 반복적으로 확인한 패턴입니다.

왜 이 한 줄이 견적 전체를 흔드는가

개발 공수가 한 번이 아니라 두 번 들어갑니다

네이티브로 간다는 것은 iOS와 안드로이드를 각각 별도의 언어와 도구로 만든다는 뜻입니다. 화면 하나를 수정하면 두 번 수정해야 하고, 테스트도 두 번 합니다. 크로스플랫폼은 하나의 코드베이스로 두 플랫폼을 함께 만듭니다. 초기 개발 공수만 놓고 보면 차이가 분명합니다.

다만 여기서 대부분의 견적 비교가 잘못됩니다. 초기 공수만 비교하면 크로스플랫폼이 언제나 이깁니다. 실제 총비용은 그 뒤에서 결정됩니다.

비용은 출시 시점이 아니라 운영 구간에서 갈립니다

앱은 출시하면 끝나는 물건이 아닙니다. iOS와 안드로이드는 매년 새 버전을 내고, 그때마다 대응이 필요합니다. 크로스플랫폼은 이 대응을 한 번에 처리할 수 있는 대신, 프레임워크 자체가 새 OS를 지원할 때까지 기다려야 하는 구간이 생깁니다. 네이티브는 그 기다림이 없지만 매번 두 번 일합니다.

어느 쪽이 싼지는 서비스마다 다릅니다. 판단하려면 출시 이후를 먼저 계산해야 하는데, 이 부분은 앱 유지보수 비용을 따로 정리한 글에서 더 자세히 다뤘습니다.

기능의 개수가 아니라 ‘어떤 기능’인지가 기준입니다

기능이 30개인지 50개인지는 이 결정과 거의 무관합니다. 중요한 것은 그중에 카메라 실시간 처리, 블루투스·웨어러블 연동, 백그라운드 위치 추적, 고사양 그래픽처럼 기기 하드웨어를 깊게 다루는 기능이 몇 개나 있는가입니다. 이런 기능이 하나도 없으면 크로스플랫폼이 유리한 경우가 많고, 서비스의 핵심 가치가 그 기능에 걸려 있으면 네이티브 쪽으로 기웁니다.

크로스플랫폼과 네이티브를 가르는 5가지 판단 기준

발주 전에 내부에서 이 다섯 가지에 답해 두면, 개발사가 어떤 제안을 하든 그 근거를 검증할 수 있습니다.

1. 기기 하드웨어와 OS 기능을 얼마나 깊게 쓰는가

로그인, 목록, 상세, 결제, 푸시 정도라면 크로스플랫폼으로 충분한 경우가 대부분입니다. 반대로 실시간 영상 처리, 정밀한 센서 데이터, 워치·IoT 기기 연동이 서비스의 중심이라면 네이티브를 검토해야 합니다. 웨어러블·IoT 연동 구조를 어떻게 설계하는지는 별도의 주제라 여기서는 판단 기준만 짚습니다.

2. 화면의 반응 속도가 서비스의 경쟁력인가

대부분의 업무용 앱, 커머스 앱, 커뮤니티 앱에서 사용자는 크로스플랫폼과 네이티브의 차이를 인지하지 못합니다. 반면 애니메이션과 조작감 자체가 상품인 서비스라면 이야기가 달라집니다. “빠르면 좋다”와 “느리면 서비스가 성립하지 않는다”는 다른 조건입니다. 이 둘을 구분해서 적어 두십시오.

3. 출시 후 업데이트를 얼마나 자주 낼 것인가

2주에 한 번 기능을 내보내는 조직과 분기에 한 번 내보내는 조직은 다른 선택을 해야 합니다. 잦은 업데이트는 두 플랫폼을 따로 관리하는 비용을 매번 두 배로 만듭니다. 업데이트 주기는 기술이 아니라 사업 계획에서 나오는 숫자이므로, 발주사가 먼저 정해 줘야 하는 항목입니다.

4. 출시 이후 몇 명으로 운영할 계획인가

가장 자주 빠지는 항목입니다. 네이티브 두 벌을 유지하려면 두 종류의 개발자가 필요합니다. 출시 후 인력을 최소로 유지할 계획이라면, 초기 견적이 조금 더 나오더라도 유지 인력이 적게 드는 구조를 고르는 편이 총비용에서 유리합니다. 이 계산은 모바일 앱 개발 견적이 회사마다 달라지는 이유와 같은 구조에서 나옵니다.

5. 앞으로 3년 안에 무엇을 붙일 계획인가

지금 기획서에 없는 기능이 결정을 뒤집는 일이 많습니다. 2년 뒤에 오프라인 매장 비콘 연동을 붙일 계획이라면, 그 계획은 지금 문서에 들어가 있어야 합니다. 1차 출시 범위를 어디까지 자를지는 MVP 개발 범위를 다룬 글에서 따로 정리했습니다.

그런데 이 판단을 ‘누가’ 하느냐가 진짜 문제입니다

위의 다섯 가지는 기술 지식이 아니라 사업 판단입니다. 문제는 이 판단을 기술 언어로 번역해 개발팀에 전달하고, 그 결과를 다시 검수하는 사람이 필요하다는 점입니다. 한국 기업이 앱 개발을 발주할 때 실질적으로 고르는 것은 기술 스택이 아니라 이 번역과 검수를 누가 책임지는가입니다.

해외 개발팀에 직접 발주하면 단가는 분명히 내려갑니다. 그런데 위 다섯 가지 판단, 요구사항 정의, 일정 관리, 검수를 모두 발주사 담당자가 영어로 직접 해야 합니다. 사내에 개발 조직이 없는 회사라면 이 구조는 대개 성립하지 않습니다. 아낀 단가만큼, 혹은 그 이상을 담당자의 시간과 재작업으로 돌려주게 됩니다. 이 패턴은 IT 외주개발 비용이 견적보다 더 나오는 구조에서도 반복해서 나타납니다.

디비컨설팅이 이 결정을 다루는 방식

저희는 IT 아웃소싱 구조에서 한국인 PM이 요구사항 정의부터 검수까지 책임지고, 검증된 글로벌 개발팀이 실제 구현을 맡습니다. 앱 개발 외주 프로젝트는 아래 5단계로 진행됩니다.

1. 상담 및 요구 분석 — 사업 목표와 기술 요건을 한국어로 문서화합니다. 크로스플랫폼과 네이티브의 선택도 이 단계에서 근거와 함께 결정됩니다. 이후 재작업의 대부분이 여기서 제거됩니다.
2. 개발팀 구성 — 확정된 기술 방향에 맞는 전담팀을 2~4주 안에 구성합니다.
3. 프로젝트 개발 — 애자일 방식으로 진행하고 진행 상황을 투명하게 공유합니다. 발주사가 하루를 조율에 쓰지 않는 구조입니다.
4. 테스트 및 배포 — QA 프로세스를 거쳐 두 플랫폼을 함께 검증하고 배포합니다.
5. 운영 및 유지보수 — 문서와 함께 인계하고 장기적으로 지원합니다.

1단계에서 무엇을 어디까지 적어야 하는지는 요구사항 정의서 글에, 전체 일정이 어떻게 흘러가는지는 앱 개발 기간 글에 정리해 두었습니다.

실제로 이렇게 만든 서비스들

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

더 많은 사례는 포트폴리오에서 확인하실 수 있습니다.

이런 기업에 적합합니다

• 사내에 개발 조직이 없거나, 있어도 앱 개발을 직접 관리할 여력이 없는 기업
• iOS와 안드로이드를 함께 내야 하는데 어느 쪽 방식이 맞는지 판단이 서지 않는 기업
• 출시 후 최소 인력으로 운영하면서 지속적으로 기능을 추가할 계획인 기업
• 국내 개발사 견적이 예산을 넘었지만 품질과 커뮤니케이션은 포기할 수 없는 기업

반대로 권하지 않습니다

• 사내에 이미 iOS·안드로이드 개발자와 기술 리드가 있는 경우 — 이 판단을 내부에서 하는 편이 빠르고, 저희가 더할 수 있는 가치가 적습니다.
• 가장 낮은 단가만이 유일한 기준인 경우 — 저희는 한국인 PM 비용이 구조에 포함되어 있어 최저가 경쟁에서는 이기지 못합니다.
• 2주 안에 앱이 나와야 하는 경우 — 전담팀 구성에만 2~4주가 필요합니다.
• 요구사항을 논의할 담당자를 지정할 수 없는 경우 — 1단계가 성립하지 않으면 나머지 단계도 성립하지 않습니다.

자주 묻는 질문

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

발주사는 한국인 PM하고만 한국어로 소통합니다. 요구사항 정의, 일정 관리, 검수는 PM의 책임입니다. 크로스플랫폼과 네이티브 중 무엇으로 갈지 같은 기술 논의도 한국어로 근거를 받아 보시게 됩니다.

비용은 어떻게 산정되나요?

등급별 단가 × 투입 기간으로 산정합니다. 기획, 디자인, 개발, QA, 배포, 유지보수를 항목별로 구분해 제시하므로, 크로스플랫폼과 네이티브 두 안을 나란히 놓고 비교하실 수 있습니다.

기획서가 없는데 견적을 받을 수 있나요?

가능합니다. 해결하려는 문제, 주요 사용자, 필수 기능 3~5개, 일정과 예산 범위만 있으면 개략 견적을 드립니다. 기술 방식이 정해지지 않은 상태여도 괜찮습니다. 그 결정 자체가 상담의 내용입니다.

진행 중에 팀 규모를 조정할 수 있나요?

가능합니다. 전담팀, 장기 협업, 인력 단위, 프로젝트 단위 중에서 선택하실 수 있고 진행 중 조정도 가능합니다. 1차 출시 후 운영 인력만 남기는 방식으로 축소하는 경우가 많습니다.

소스코드 소유권은 누구에게 있나요?

발주사에 귀속됩니다. API 명세, DB 스키마, 배포 절차 문서까지 인계합니다. 나중에 다른 개발사로 옮기거나 내부 팀으로 전환하실 때 필요한 것을 남기지 않고 드립니다.

정리

크로스플랫폼 앱 개발이 네이티브보다 싸다거나 낫다는 일반론은 없습니다. 하드웨어 활용도, 반응 속도의 중요성, 업데이트 주기, 운영 인력 계획, 3년 뒤 로드맵 — 이 다섯 가지 답이 정해지면 선택은 거의 자동으로 나옵니다. 문제는 이 답을 기술 결정으로 번역하고 그 결과를 검수할 사람이 발주사 안에 있느냐입니다. 그 자리가 비어 있다면, 채우는 방법을 정하는 것이 개발사를 고르는 일보다 먼저입니다.

앱 유지보수 비용은 견적서에서 가장 작게 적혀 있다가 출시 이후 가장 크게 불어나는 항목입니다. 스토어 심사를 통과하고 출시 버튼을 누른 다음 주에 벌어지는 일은 대개 비슷합니다. 크래시 리포트가 쌓이기 시작하고, 특정 기종에서만 로그인 화면이 흰 화면으로 멈추고, 결제 마지막 단계에서 이탈하는 사용자가 보입니다. 고객센터에는 기획서에 없던 질문이 들어오고, 마케팅팀은 당장 다음 주 프로모션에 맞춰 배너 하나를 바꿔 달라고 요청합니다. 담당자는 개발사에 연락하지만, 계약서상 프로젝트는 이미 ‘검수 완료’로 종료된 상태입니다.

이 지점에서 많은 기업이 처음 깨닫습니다. 프로젝트가 끝난 것이 아니라, 계약이 끝난 것입니다. 앱은 한 번 만들어 납품받는 물건이 아니라 매달 돌아가는 서비스입니다. 서버는 계속 켜져 있어야 하고, 운영체제는 1년마다 바뀌고, 연동해 둔 외부 서비스는 각자의 사정으로 스펙을 고칩니다. 계약에 무상 하자보수 기간이 명시돼 있더라도 그 범위는 대개 ‘개발 당시 정의된 기능의 결함’까지입니다. 출시 후에 새로 생긴 요구는 대부분 그 범위 밖에 있습니다.

그래서 앱의 실제 총비용은 개발비 한 번으로 끝나지 않습니다. 최종 지출이 초기 견적의 1.5배 수준이 되는 일은 드물지 않고, 그 차액의 상당 부분은 기술적으로 어려운 작업이 아니라 ‘누가 무엇을 어떻게 만들어 놓았는지 다시 파악하는 일’에 들어갑니다. 견적 자체가 왜 어긋나는지는 IT 외주개발 비용이 견적보다 항상 더 나오는 구조에서 따로 정리했습니다. 이 글은 앱 유지보수 비용이 어디서 발생하는지 구조적으로 분해하고, 외주 계약서에 서명하기 전에 무엇을 확인해야 하는지 정리한 글입니다.

디비컨설팅은 시원스쿨(Siwon School)의 자회사로, 한국인 PM이 검증된 글로벌 개발팀을 관리하는 방식의 IT 아웃소싱을 제공합니다. 지금까지 100건 이상의 프로젝트를 수행했고, 50곳 이상의 글로벌 파트너사와 협업 체계를 유지하고 있으며, 고객 만족도는 98%입니다. 삼성물산 주거 플랫폼 앱 ‘홈닉’, GS건설 엘리시안 리조트 웹·앱, 직방 ‘호갱노노’, LS일렉트릭 산업 B2B 거래 플랫폼 ‘테크스퀘어’처럼 출시 이후에도 장기간 운영되는 서비스를 구축했습니다. 국내 채용 대비 평균 40~60%의 비용을 절감하면서, 전담팀 구성은 2~4주 안에 완료합니다.

앱 유지보수 비용은 어디서 발생하는가

출시 후에 발생하는 비용은 예외적인 사고가 아니라 구조적으로 예정된 지출입니다. 발생 지점은 크게 네 가지입니다.

1. OS 버전 업데이트와 기기 파편화

iOS와 Android는 매년 한 번 메이저 업데이트를 발표합니다. 그때마다 권한 정책, 화면 규격, 백그라운드 동작 제한, 알림 처리 방식이 조금씩 바뀌고, 스토어가 요구하는 최소 SDK 기준도 함께 올라갑니다. 즉 앱을 그대로 두어도 앱이 놓인 바닥이 매년 한 번씩 움직입니다.

Android는 여기에 기기 파편화가 더해집니다. 제조사별 커스텀 OS, 해상도, 카메라·알림 구현 차이가 겹치면서 사내 테스트 기기 몇 대로는 재현되지 않는 버그가 생깁니다. 이 작업의 특징은 새 기능이 하나도 늘지 않는다는 점입니다. 사용자 화면에서 달라지는 것이 없으니 예산을 정당화하기는 가장 어렵고, 미루면 스토어 등록 자체가 막힐 수 있는 항목입니다.

2. 서드파티 의존성은 우리 일정으로 움직이지 않습니다

지금 앱 개발 외주로 만든 앱에는 결제(PG), 소셜 로그인, 지도, 푸시 알림, 분석 도구가 붙어 있습니다. 이들은 모두 외부 회사의 서비스이고, 각자의 로드맵에 따라 API 버전을 올리고 구버전 지원을 종료하며 인증 정책을 변경합니다. 우리 프로젝트 일정을 참고해 주지 않습니다.

문제는 이 중 하나가 막히면 멈추는 것이 부가 기능이 아니라 결제와 로그인이라는 점입니다. 즉 예고 없이 발생하고, 발생하면 당일 대응해야 하며, 계획에 없던 일정에 사람을 밀어 넣어야 합니다. 유지보수에서 가장 비싼 형태의 작업이 바로 이 긴급 대응입니다.

3. 운영 중에만 드러나는 요구

실사용자가 붙기 전에는 보이지 않는 것들이 있습니다. 데이터가 쌓이면서 목록 화면이 느려지고, 특정 조회 기능이 병목이 되고, 기획 단계에서 예상하지 못한 사용 패턴이 나타납니다. 여기에 운영 조직의 요구가 붙습니다. 고객센터는 사용자 계정을 직접 확인하고 싶어 하고, 마케팅팀은 배너와 푸시를 직접 발송하고 싶어 합니다.

기획 단계에서 관리자 화면을 얕게 잡아 둔 프로젝트는 이 요구를 전부 개발자에게 보냅니다. 그 결과 개발자의 시간이 운영 업무 대행에 소모되고, 정작 필요한 개선은 계속 뒤로 밀립니다. 이것도 유지보수 비용입니다. 다만 견적서에 그런 이름으로 적혀 있지 않습니다. 서비스 개발에서 가장 비싼 비용은 사람을 관리하는 시간이라는 점은 운영 단계에서 특히 분명해집니다.

4. 인수인계가 안 된 코드

앞의 세 가지는 어떤 앱이든 겪습니다. 비용 차이를 결정적으로 벌리는 것은 네 번째입니다.

문서 없이 코드만 넘겨받은 프로젝트는 모든 수정이 재조사부터 시작합니다. API 명세가 없으면 서버가 무엇을 주고받는지 코드를 열어 역추적해야 하고, DB 스키마 설명이 없으면 이 컬럼을 지워도 되는지 아무도 확답하지 못합니다. 배포 절차와 환경변수가 정리돼 있지 않으면 빌드 한 번을 올리는 일이 하루짜리 작업이 됩니다. 담당 개발자가 퇴사하거나 개발사를 교체한 뒤라면 조건은 더 나빠집니다.

이 상태에서는 버튼 문구 하나를 바꾸는 요청에도 며칠이 붙습니다. 발주사 입장에서는 “이 간단한 걸 왜 이렇게 오래 하느냐”가 되고, 작업자 입장에서는 “이 코드는 건드리면 무엇이 깨질지 모른다”가 됩니다. 이것이 IT 외주 프로젝트가 납기 후 분쟁으로 끝나는 구조와 같은 뿌리입니다. 그래서 앱 유지보수 비용을 실제로 결정하는 변수는 개발 단가가 아닙니다. 구조가 문서로 남아 있는지, 그리고 그 문서를 한국어로 설명하고 다음 작업을 정의해 줄 사람이 계속 있는지입니다.

세 가지 선택지 비교

표에서 유지보수와 직접 연결되는 행은 개발 단가가 아니라 아래쪽 세 개입니다. 해외에 직접 발주하면 단가는 분명히 내려가지만, 요구사항을 영어로 정의하고 산출물을 검수하고 일정을 관리하는 일이 전부 발주사 담당자에게 넘어옵니다. 그 담당자가 개발 전문가가 아니라면 스펙이 불완전한 상태로 개발이 시작되고, 그 결과는 재작업으로 돌아옵니다. 단가에서 절감한 몫을 재작업과 담당자의 시간으로 다시 지불하는 구조입니다.

국내 개발사는 한국어로 소통하고 요구사항 정의도 맡아 주지만, 계약이 끝나면 그 팀이 그대로 남아 있을 이유가 없습니다. 6개월 뒤 수정 요청을 보냈을 때 그 프로젝트를 담당했던 인원이 이미 다른 프로젝트에 배치돼 있거나 회사를 떠난 경우가 흔합니다. 같은 기능을 두고 모바일 앱 개발 견적이 회사마다 크게 달라지는 이유도 결국 이 구조 차이에서 나옵니다.

결국 유지보수는 단가의 문제가 아니라 두 가지 문제입니다. 첫째, 같은 맥락을 아는 팀이 계속 유지되는가. 둘째, 필요한 변경을 한국어로 정의해서 개발팀에 넘겨 줄 사람이 계속 있는가. 이 두 가지가 확보되지 않으면 아무리 낮은 단가로 시작해도 총비용은 올라갑니다.

디비컨설팅이 앱 유지보수 비용을 통제하는 방법

디비컨설팅은 다섯 단계로 프로젝트를 진행합니다. 각 단계는 개발을 빠르게 하기 위한 절차이기도 하지만, 그보다 출시 이후의 지출을 줄이기 위한 장치입니다.

1단계 · 상담 및 요구 분석

비즈니스 목표와 기술 요구사항을 한국어로 문서화합니다. 이 단계의 목적은 견적을 뽑는 것이 아니라, 나중에 “그건 원래 범위에 있었다 / 없었다”로 다투는 일을 없애는 것입니다. 범위가 문서로 고정되면 추가 요청이 들어올 때 그것이 하자 보수인지 신규 개발인지 판단할 기준이 생깁니다. 출시 후 분쟁 비용의 대부분이 이 문서 하나로 사라집니다.

2단계 · 개발팀 구성

프로젝트 성격에 맞춰 2~4주 안에 전담팀을 구성합니다. 전담 구조가 중요한 이유는 유지보수 단계에서 드러납니다. 프로젝트마다 인력을 새로 모으는 방식은 6개월 뒤 수정 요청이 왔을 때 그 코드를 아는 사람이 남아 있지 않습니다. 처음 만든 팀이 운영까지 이어지면 맥락 재학습 비용이 발생하지 않습니다.

3단계 · 프로젝트 개발

애자일 방식으로 개발하고 진행 상황을 투명하게 공유합니다. 발주사는 완성된 결과물을 마지막에 한 번 받는 것이 아니라, 진행 중인 산출물을 주기적으로 확인합니다. 방향이 어긋났을 때 그것을 개발 도중에 발견하면 수정이고, 검수 단계에서 발견하면 재개발입니다. 이 차이가 곧 비용입니다.

4단계 · 테스트 및 배포

QA를 거쳐 릴리즈합니다. 여기서 잡지 못한 결함은 출시 후 긴급 대응으로 전환되고, 긴급 대응은 계획된 작업보다 항상 비쌉니다. 실사용 환경에서 발생하는 장애는 개발 시간뿐 아니라 고객센터 대응과 이탈까지 함께 발생시킵니다.

5단계 · 운영 및 유지보수

가장 중요한 단계입니다. 디비컨설팅은 결과물을 코드만 넘기지 않고, API 명세와 DB 스키마, 배포 절차 문서까지 함께 인계합니다.

이 문서가 있으면 담당자가 바뀌어도 재조사 비용이 발생하지 않습니다. 발주사 쪽 담당자가 교체되든, 나중에 사내 개발 조직이 생겨 직접 운영하기로 결정하든, 다른 업체에 이관하든 마찬가지입니다. 새로 들어온 사람이 코드를 역추적하며 보내는 몇 주가 필요하지 않기 때문입니다. 앞에서 설명한 네 번째 비용 구조, 즉 앱 유지보수 비용을 가장 크게 부풀리는 항목을 처음부터 제거하는 방식입니다. 소스코드 소유권은 발주사에 귀속되므로 이 문서 역시 발주사의 자산으로 남습니다.

실제 구축 사례

출시 이후 장기간 운영되는 성격의 프로젝트를 중심으로 정리했습니다. 전체 목록은 포트폴리오에서 확인하실 수 있습니다.

• 삼성물산 홈닉 — 입주민을 대상으로 하는 주거 플랫폼 앱
• GS건설 엘리시안 리조트 — 리조트 웹·앱 통합 구축
• 직방 호갱노노 — 부동산 데이터 서비스
• LS일렉트릭 테크스퀘어 — 산업 B2B 거래 플랫폼
• 센터필드·센트로폴리스·그랑서울 — 프라임 오피스 빌딩 관리 시스템
• 가천대학교 학사관리 시스템 — 학사 업무를 처리하는 관리 시스템

어떤 기업에 맞고, 어떤 기업에 맞지 않는가

이런 기업에 적합합니다

• 사내에 개발 조직이 없거나, 있어도 기존 업무로 이미 가득 차 있는 경우
• 앱이나 웹 서비스를 만든 뒤 최소 1년 이상 계속 운영할 계획인 경우
• 개발 예산은 제한적이지만 품질과 일정 관리는 국내 개발사 수준으로 요구되는 경우
• 요구사항을 영어로 정의하고 해외 팀을 직접 관리할 인력이 없는 경우
• 이미 만들어 둔 앱을 인계받아 운영해 줄 팀이 필요한 경우

반대로 권하지 않습니다

솔직하게 적겠습니다. 다음의 경우라면 디비컨설팅을 쓰지 않는 것이 합리적입니다.

• 사내에 개발 조직과 PM이 이미 있는 경우. 요구사항을 직접 정의하고 개발자를 직접 관리할 수 있다면, 그 역할을 대신하는 구조에 비용을 지불할 이유가 없습니다.
• 한 번 만들고 더 이상 손대지 않을 일회성 결과물인 경우. 캠페인용 페이지나 단기 이벤트 앱처럼 수명이 정해져 있다면 유지보수 연속성이 의미가 없고, 그 가치가 총비용의 핵심인 우리 구조와 맞지 않습니다.
• 월 단위 운영 예산을 아예 편성할 수 없는 경우. 앱은 출시 후에도 매달 비용이 드는 자산입니다. 개발비만 확보된 상태로 시작하면 6개월 뒤 방치되고, 그때는 재개발이 유지보수보다 비싸집니다. 그 상황이라면 착수 시점을 미루고 예산 구조를 먼저 정리하시는 편이 낫습니다.
• 당장 며칠 안에 착수해야 하는 경우. 전담팀 구성에는 2~4주가 필요합니다. 그보다 급한 일정은 맞춰 드릴 수 없습니다.
• 요구사항을 문서로 정의하는 과정 자체를 생략하고 싶은 경우. 1단계에서 발주사의 시간이 반드시 필요합니다. 그 과정을 건너뛰면 어떤 개발사와 일해도 결과는 재작업입니다.

자주 묻는 질문

해외 개발팀이라고 하셨는데, 의사소통은 어떻게 하나요?

발주사는 한국인 PM하고만 한국어로 소통합니다. 해외 개발팀과 직접 대화하실 필요가 없습니다. 요구사항 정의, 일정 관리, 산출물 검수는 PM의 책임이며, 개발팀에 전달되는 스펙 문서 작성도 PM이 담당합니다. 발주사가 확인하시는 것은 한국어로 정리된 진행 상황과 결과물입니다.

앱 유지보수 비용은 어떻게 산정되나요?

등급별 단가에 투입 기간을 곱하는 방식으로 산정합니다. 견적에는 기획, 디자인, 개발, QA, 배포, 유지보수를 항목별로 구분해 제시하므로 어떤 작업에 얼마가 들어가는지 확인하실 수 있습니다. 총액 한 줄로 제시하지 않는 이유는, 항목이 구분돼 있지 않으면 나중에 범위를 조정할 때 근거가 없어지기 때문입니다.

기획서가 없는데 견적을 받을 수 있나요?

가능합니다. 완성된 기획서는 필요하지 않습니다. 해결하려는 문제, 주요 사용자, 반드시 있어야 하는 기능 3~5개, 그리고 일정과 예산의 범위만 알려 주시면 개략 견적을 드립니다. 상세 요구사항은 1단계 상담 과정에서 함께 문서로 정리합니다.

유지보수 단계에서 팀 규모를 줄일 수 있나요?

가능합니다. 전담팀, 장기 협업, 인력 단위, 프로젝트 단위 중에서 선택하실 수 있고, 진행 중에도 조정할 수 있습니다. 개발 기간에는 인원을 늘려 속도를 내고, 출시 이후 운영 단계에서는 규모를 줄여 유지하는 방식이 일반적입니다. 개발할 때의 인원을 운영 단계까지 그대로 유지하실 필요가 없습니다.

소스코드 소유권은 누구에게 있나요?

발주사에 귀속됩니다. 그리고 코드만 드리지 않습니다. API 명세, DB 스키마, 배포 절차 문서까지 함께 인계합니다.

이 답변을 계약 전에 반드시 확인하시기를 권합니다. 소유권 조항만 있고 인계 문서 범위가 명시되지 않은 계약은, 실질적으로 그 코드를 그 개발사 외에는 아무도 다룰 수 없다는 뜻입니다. 코드는 발주사 것이지만 코드를 읽을 수 있는 사람은 개발사에만 있는 상태이기 때문입니다. 문서까지 인계받으면 이후의 선택권이 발주사에 남습니다. 같은 팀과 계속 운영하실 수도 있고, 사내 개발 조직으로 이관하실 수도 있고, 다른 업체를 쓰실 수도 있습니다. 그 선택권이 곧 유지보수 협상력입니다.

정리

앱 유지보수 비용은 없앨 수 없습니다. OS는 매년 바뀌고 외부 서비스는 자기 일정으로 스펙을 고치며, 실사용자가 붙은 뒤에야 보이는 요구는 반드시 생깁니다. 다만 이 비용을 예측 가능하게 만들 수는 있습니다. 그리고 그 차이를 만드는 것은 개발 단가가 아니라 구조입니다. 요구사항을 한국어로 정의해 문서로 남기고, 그 맥락을 아는 팀을 운영 단계까지 유지하고, API 명세와 DB 스키마와 배포 절차까지 인계하는 구조입니다. 외주 계약서에 서명하기 전에 단가표보다 먼저 확인하실 것은 그 세 가지가 계약 범위에 들어 있는지입니다.

“3개월이면 나온다”는 말을 듣고 시작한 앱이, 7개월째 스토어에 올라가지 못하는 경우가 있습니다. 개발사가 일을 안 한 것도 아니고, 요청을 무리하게 늘린 것도 아닙니다. 앱 개발 기간이 계획을 넘어서는 일은 특정 업체의 문제가 아니라, 일정을 산정하는 방식 자체에서 반복적으로 발생합니다.

디비컨설팅은 삼성물산 홈닉, GS건설 엘리시안 리조트, 하나투어 하나오픈챗, 직방 호갱노노, LS일렉트릭 테크스퀘어 등 100건이 넘는 프로젝트를 수행했습니다. 그 과정에서 확인한 것은 분명합니다. 일정이 밀리는 원인은 개발 속도가 아니라 개발이 시작되기 전과 끝난 뒤에 있습니다. 이 글에서는 앱 개발 기간이 단계별로 실제 얼마나 걸리는지, 그리고 어디서 일정이 새는지를 정리했습니다.

앱 개발 기간, 단계별로 실제 얼마나 걸리는가

아래는 일반적인 중소 규모 앱(iOS·Android 양대 플랫폼, 로그인·결제·푸시 포함) 기준의 통상적인 소요 기간입니다. 기능 범위와 연동 시스템에 따라 달라지므로, 절대적인 숫자가 아니라 어느 단계에 시간이 쌓이는지를 보는 용도로 참고하시기 바랍니다.

합계로 보면 대략 4~8개월입니다. 그런데 대부분의 견적서는 여기서 개발 단계만 떼어 “3개월”이라고 안내합니다. 발주사는 3개월을 기억하고, 실제로는 6개월이 걸립니다. 일정에 대한 인식 차이는 여기서 시작됩니다.

일정이 실제로 새는 4가지 지점

1. 기획이 끝나지 않은 채 개발이 시작된다

가장 흔하고 가장 비쌉니다. “일단 시작하고 세부는 진행하면서 정하자”로 출발한 프로젝트는 개발 중반에 화면 구조를 다시 그리게 됩니다. 이미 만들어진 화면과 API를 되돌리는 비용은 처음부터 만드는 것보다 큽니다. 기획 단계에서 아낀 2주가 개발 단계에서 6주로 돌아옵니다.

2. 의사결정 대기 시간이 일정에 포함되지 않는다

개발사가 화면 시안을 보냈는데 발주사 내부 검토에 2주가 걸립니다. 이런 대기가 프로젝트 전체에서 다섯 번 발생하면 10주입니다. 개발사 일정표에는 이 시간이 없습니다. 발주사 입장에서는 “개발사가 늦었다”고 느끼지만, 실제로는 승인 프로세스가 일정을 소비한 것입니다.

3. 외부 연동은 상대방의 일정에 묶인다

PG 결제, 본인인증, 지도 API, 사내 ERP 연동은 우리 개발팀이 빨라도 단축되지 않습니다. 심사와 계약, 테스트 계정 발급에 각각 수 주가 필요합니다. 이 항목들을 프로젝트 시작 시점에 병렬로 착수하지 않으면 개발이 끝난 뒤에 대기하게 됩니다.

4. 해외 개발팀이면 시차만큼 사이클이 늘어난다

질문을 보내고 답을 받는 데 하루가 걸리면, 하루 걸릴 결정이 사흘이 됩니다. 언어가 겹치면 재확인이 한 번 더 붙습니다. 단가를 낮추려고 해외에 직접 발주했다가 일정이 오히려 늘어나는 전형적인 경로입니다. 한국 기업이 해외 IT 외주에서 실패하는 5가지 패턴에서 같은 구조를 다뤘습니다.

기업이 실제로 선택하는 3가지 방식

일정을 줄이려는 기업 앞에 놓인 선택지는 세 가지입니다. 결과를 가르는 것은 개발자의 손 속도가 아니라 요구사항과 의사결정을 누가 정리하는가입니다.

해외에 직접 발주하면 단가는 확실히 내려갑니다. 다만 기획, 일정 관리, 품질 검수라는 세 가지 업무가 그대로 발주사에게 넘어옵니다. 이 세 가지를 감당할 내부 인력이 없다면 일정은 늘어나고, 단가에서 아낀 금액은 지연 비용으로 돌아옵니다.

디비컨설팅이 일정을 관리하는 방식

디비컨설팅의 IT 아웃소싱은 한국인 PM이 요구사항 정의부터 검수까지 책임지고, 실제 구현은 검증된 글로벌 개발팀이 수행하는 구조입니다. 국내 채용 대비 평균 40~60% 비용 절감이 가능하며, 프로젝트 요구사항에 따라 2~4주 내 전담팀을 구성합니다.

1. 상담 및 요구 분석 — 비즈니스 목표와 기술 요구사항을 한국어로 문서화합니다. 앞서 말한 1번 지연 원인을 없애는 단계입니다.
2. 개발팀 구성 — 프로젝트에 맞는 전담팀을 2~4주 내에 구성합니다.
3. 프로젝트 개발 — 애자일 방식으로 진행 상황을 투명하게 공유합니다. 발주사가 매일 조율에 매달리지 않아도 됩니다.
4. 테스트 및 배포 — QA 프로세스를 거쳐 품질을 확인한 뒤 스토어에 제출합니다.
5. 운영 및 유지보수 — 문서와 함께 인계하고 장기 운영을 지원합니다.

현재 50개 이상의 글로벌 파트너사와 협업하고 있으며, 고객 만족도는 98%입니다. 앱 개발 외주와 웹 개발 외주 모두 동일한 구조로 진행됩니다.

실제로 이런 앱을 만들었습니다

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

교육, 금융·핀테크, 헬스케어, 제조·물류, 이커머스, 스마트빌딩·IoT 영역의 구축 경험을 보유하고 있습니다. 전체 사례는 포트폴리오에서 확인하실 수 있습니다. 비용 관점의 정리는 모바일 앱 개발 견적이 회사마다 다른 이유를 함께 참고하시기 바랍니다.

일정을 앞당기고 싶다면, 발주사가 할 수 있는 4가지

1. 의사결정권자를 한 명으로 지정합니다. 검토 인원이 늘어날수록 대기 시간이 곱해집니다.
2. 외부 연동은 착수와 동시에 신청합니다. PG·본인인증 심사는 개발과 병렬로 진행할 수 있습니다.
3. 1차 출시 범위를 줄입니다. 모든 기능을 담은 출시보다, 핵심 기능으로 먼저 내고 개선하는 편이 총 기간이 짧습니다.
4. 기획 확정 전에는 개발을 시작하지 않습니다. 역설적이지만 가장 확실한 단축 방법입니다.

이런 기업에 적합합니다

• 개발 인력을 채용하기에는 부담이 크지만 앱은 계속 개선해야 하는 기업
• 국내 개발사 견적이 예산을 넘어 출시를 미루고 있는 기업
• 해외 외주를 검토했지만 일정과 소통 리스크 때문에 결정하지 못한 기업
• 이전 앱 프로젝트가 지연이나 분쟁으로 끝나 다시 시작해야 하는 기업

반대로, 이런 경우에는 권하지 않습니다

• 망분리 등 물리적 보안 요건상 국내 상주 개발이 의무인 공공·금융 프로젝트
• 2주 안에 결과물이 필요한 초단기 건 — 전담팀 구성에만 2~4주가 필요합니다
• 요구사항이 확정되지 않은 상태에서 착수부터 원하는 경우 — 이 상태로 시작하면 어떤 개발사와 해도 일정이 초과됩니다

자주 묻는 질문

앱 개발 기간을 3개월로 줄일 수 있나요?

기능 범위를 좁히면 가능합니다. 다만 그 3개월은 기획이 이미 확정된 상태에서 개발만 진행하는 경우입니다. 기획부터 시작한다면 3개월 안에 스토어 출시까지 마치는 것은 현실적이지 않습니다. 범위를 줄여 1차 출시하고 이후 개선하는 방식을 권합니다.

iOS와 Android를 동시에 만들면 기간이 두 배인가요?

두 배는 아닙니다. 기획, 디자인, 백엔드는 공용이므로 늘어나는 것은 클라이언트 개발 부분입니다. 크로스플랫폼으로 구현하면 더 줄일 수 있으나, 기기 기능을 깊게 쓰는 앱은 네이티브가 유리합니다. 어느 쪽이 맞는지는 기능 목록을 보고 판단해야 합니다.

해외 개발팀인데 일정 관리는 어떻게 하나요?

발주사는 한국인 PM하고만 한국어로 소통합니다. 요구사항 정의, 일정 조율, 품질 검수는 PM이 책임지므로 영어로 개발자와 직접 대화하거나 시차를 감안해 회의를 잡을 일은 없습니다.

기획서가 없어도 일정 산정이 가능한가요?

가능합니다. 해결하려는 문제, 주요 사용자, 필수 기능 3~5개, 희망 출시 시점만 정리되어 있으면 개략 일정과 견적을 산출할 수 있습니다.

소스코드와 산출물의 소유권은 누구에게 있나요?

발주사에 귀속됩니다. API 명세, DB 스키마, 배포 절차 문서를 함께 인계하므로 이후 다른 팀이 이어받더라도 재분석 기간이 발생하지 않습니다.

정리

앱 개발 기간을 줄이는 방법은 더 빠른 개발자를 찾는 것이 아닙니다. 기획을 확정하고, 의사결정을 한 곳으로 모으고, 외부 연동을 먼저 걸어두는 것입니다. 개발 속도는 전체 일정의 일부일 뿐이고, 지연은 대부분 그 바깥에서 발생하기 때문입니다.

검토 중인 앱 프로젝트가 있다면, 필수 기능과 희망 출시 시점만 알려주셔도 예상 일정과 가견적을 회신드리겠습니다. 상담 비용은 없습니다.