앱 리뉴얼, 지금 쓰고 있는 사용자는 그대로 따라오지 않습니다 — 설치된 앱을 갈아끼울 때의 6가지 결정

앱 리뉴얼을 검토하기 시작하는 시점은 대체로 비슷합니다. 앱은 몇 년째 같은 구조로 돌아가고 있고, 스토어 페이지의 스크린샷은 지금 화면과 다르며, 최근 리뷰에는 느리다는 말이 쌓여 있습니다.

그 앱을 만든 개발사는 이미 연락이 닿지 않습니다. 담당자는 퇴사했고 계약은 몇 년 전에 끝났으며, 회사에 남은 것은 운영 중인 앱 하나와 출처가 분명하지 않은 파일 몇 개입니다.

회의에서는 “이참에 새로 만들자”는 말이 나옵니다. 여기까지는 어렵지 않습니다.

문제는 그다음 질문입니다. 지금 그 앱을 쓰고 있는 사용자들은 어떻게 되는가. 이 질문에 답할 수 있는 사람이 회사 안에 없는 상태로 받은 견적서는 거의 틀립니다. 이미 앱 개발 외주를 검토 중이시라면, 발주서를 쓰기 전에 먼저 읽어 보시기 바랍니다.

디비컨설팅은 한국인 PM이 검증된 글로벌 개발팀을 관리하는 구조로 IT 아웃소싱을 수행합니다. 지금까지 100건 이상의 프로젝트를 진행했고, 50개 이상의 글로벌 파트너사와 협업하며, 고객 만족도는 98%입니다. 삼성물산 홈닉, GS건설 엘리시안 리조트, 직방 호갱노노, LS일렉트릭 테크스퀘어 등의 프로젝트를 수행했고, 시원스쿨(Siwon School) 계열사입니다. 회사에 대한 자세한 내용은 디비컨설팅 소개에서 확인하실 수 있습니다. 발주사가 영어로 회의에 들어가는 일은 없습니다. 한국인 PM과 한국어로 이야기합니다.

앱 리뉴얼이 웹사이트 리뉴얼과 결정적으로 다른 지점

웹은 배포하면 끝나지만, 앱은 사용자가 직접 받아야 끝납니다

웹사이트 리뉴얼은 배포 시점에 전환이 끝납니다. 어제 접속한 사람과 오늘 접속한 사람이 같은 화면을 보고, 구버전은 남지 않습니다.

앱은 다릅니다. 새 버전을 스토어에 올렸다는 것은 “받을 수 있게 됐다”는 뜻일 뿐입니다. 실제로 받는 것은 사용자의 선택이고, 자동 업데이트를 꺼 둔 기기와 오래된 OS를 쓰는 기기는 그대로 남습니다. 출시 다음 날에도 구버전은 계속 살아서 돌아갑니다.

그래서 리뉴얼 기간에는 두 벌의 앱이 동시에 운영됩니다. 구버전이 쓰는 서버와 신버전이 쓰는 서버를 함께 유지해야 하고, 데이터는 양쪽에서 동시에 쌓입니다. 이 동시 운영 구간을 설계하지 않고 시작하면 출시 다음 주부터 장애 대응이 시작됩니다. 출시 다음 날 장애가 나면 누가 대응하는가를 인수 전에 정해야 하는 이유도 같은 자리에 있습니다.

견적이 두 배가 되는 자리는 디자인이 아니라 승계 범위입니다

처음 받는 견적서에는 대개 “새 앱을 만드는 값”만 들어 있습니다. 화면 수, 기능 목록, 디자인 범위, 개발 기간. 여기까지는 신규 개발과 같은 방식으로 계산되기 때문에 견적서도 깔끔하게 나옵니다.

빠져 있는 것은 기존 사용자와 데이터, 그리고 스토어 자산을 옮기는 값입니다. 회원 계정을 어떻게 이어받을지, 결제·구독 이력을 어디까지 가져올지, 앱이 등록된 개발자 계정을 누가 갖고 있는지, 구버전 사용자를 언제까지 받아 줄지가 모두 빠져 있습니다.

견적이 두 배가 되는 것은 개발사가 말을 바꿔서가 아니라 처음부터 절반만 계산했기 때문입니다. 앱 리뉴얼에서 비싼 쪽은 새로 만드는 일이 아니라, 쓰고 있던 사람들을 데려오는 일입니다.

발주 전에 정해야 할 6가지

1. 지금 그 앱은 누구의 개발자 계정에 올라가 있습니까

리뉴얼을 검토하다가 앱이 전 개발사의 Apple·Google 개발자 계정에 등록되어 있다는 사실을 발견하는 경우가 드물지 않습니다. 서비스는 우리 회사 이름으로 운영되고 있어도, 스토어에 올린 주체는 개발사였던 것입니다.

계정을 넘겨받지 못하면 업데이트 자체가 불가능합니다. 새 버전을 아무리 잘 만들어도 올릴 자리가 없습니다. 스토어마다 앱 소유권을 이전하는 절차와 조건이 따로 있고, 그 절차에는 전 개발사의 협조가 필요합니다.

그래서 이 항목은 개발 일정이 아니라 계약·협상 일정입니다. 연락이 닿는지, 협조 조건이 무엇인지, 이전이 불가능할 때의 대안이 무엇인지를 발주서를 쓰기 전에 확인해야 합니다. 개발사를 교체하기 전에 확인할 항목과 겹치는 부분이 많으므로 함께 점검하시는 편이 좋습니다.

2. 기존 앱을 업데이트할 것인가, 새 앱으로 올릴 것인가

같은 앱을 업데이트하면 그동안 쌓인 리뷰와 평점, 누적 설치, 스토어 검색에서의 위치가 유지됩니다. 대신 기존 구조를 일부 떠안고 갑니다.

새 앱으로 올리면 설계는 자유롭지만 평점과 설치 기반은 처음부터 다시 시작합니다. 그리고 기존 사용자에게 쓰던 앱을 지우고 다른 앱을 받으라고 설득해야 하는데, 이 이동률은 대체로 기대보다 낮습니다. 새로 등록하는 경우에는 앱스토어 심사 거절 사유도 처음부터 다시 통과해야 합니다.

이것은 개발 결정이 아니라 사업 결정입니다. 설치 기반이 자산인지, 평점이 자산인지 부채인지, 사용자를 다시 모을 채널이 있는지를 보고 회사가 직접 정해야 합니다.

3. 구버전 사용자를 언제까지 받아 줄 것인가

출시한다고 전원이 업데이트하지 않습니다. 한 달 뒤에도 구버전에 남아 있는 사용자가 있습니다.

정해야 할 것은 두 가지입니다. 강제 업데이트를 언제 걸 것인가, 그리고 그때까지 구버전용 API와 서버를 얼마나 오래 유지할 것인가. 이 두 가지가 리뉴얼 이후의 유지비를 직접 결정합니다.

발주서에 이 기간을 쓰지 않으면 리뉴얼이 끝난 뒤에도 두 벌의 시스템을 계속 운영하게 됩니다. 리뉴얼을 했는데 운영 부담이 오히려 늘어나는 가장 흔한 경로입니다. 앱 유지보수 비용이 출시 후에 늘어나는 구조와 같은 문제입니다.

4. 계정과 거래 이력을 어디까지 그대로 옮길 것인가

항목은 회원 계정, 로그인 수단, 결제·구독 이력, 포인트·스탬프 잔액으로 나뉩니다. 각각 그대로 옮길지, 일부만 옮길지, 옮기지 않을지를 선택해야 하고 선택마다 개발 범위가 달라집니다.

특히 로그인 수단이나 인증 방식을 바꾼다면, 기존 계정과 새 계정을 어떻게 연결할지가 별도의 설계 과제가 됩니다. 같은 사람이라는 것을 무엇으로 확인할지, 연결에 실패한 사용자는 어떻게 처리할지까지 정해야 합니다.

견적서에서 자주 빠지는 항목입니다. 화면은 모두 적혀 있는데, 그 화면에 로그인할 사람들에 대한 계획이 없습니다. 관리자 페이지가 견적에서 빠지는 것과 같은 이유로 생기는 누락입니다.

5. 앱만 바꿀 것인가, 서버까지 바꿀 것인가

범위가 정확히 두 배로 갈리는 지점입니다. 화면만 새로 만들면 금방 끝날 것 같고, 견적서도 대개 그렇게 쓰입니다.

문제는 새 화면이 요구하는 데이터가 지금 서버 구조에 없는 경우입니다. 새 정렬 기준이나 추천 영역 하나가 지금 없는 값을 요구하면 결국 서버를 열게 되고, 그 시점에 범위는 이미 바뀌었는데 일정은 그대로입니다. 서버까지 바꾸기로 했다면 레거시 시스템 전환의 판단 기준과 데이터 이관 체크포인트를 함께 보시기 바랍니다.

그래서 발주 전에 이 선을 문장으로 그어야 합니다. 서버를 손대지 않는다면 새 화면은 지금 있는 데이터만으로 구성한다는 뜻이고, 서버도 바꾼다면 그 기간이 처음부터 일정에 들어가야 합니다.

6. 기존 소스와 데이터는 누가 읽을 것인가

리뉴얼은 신규 개발과 달리 읽는 일부터 시작합니다. 지금 돌아가는 앱이 무엇을 어떻게 하고 있는지 파악해야 다음 설계를 할 수 있습니다.

앞선 개발사가 API 명세와 DB 스키마, 배포 절차를 문서로 남겼다면 이 단계는 짧습니다. 남기지 않았다면 분석 기간이 별도의 과업이 되고, 그 기간은 정확히 예측되지 않습니다. 열어 보기 전에는 무엇이 들어 있는지 알 수 없기 때문입니다.

분석을 과업으로 명시하지 않은 견적은 반드시 움직입니다. 움직이지 않게 하는 방법은 하나뿐입니다. 분석을 먼저 과업으로 두고, 그 결과로 본 개발 견적을 다시 쓰는 것입니다. 요구사항 정의서를 어디까지 써야 하는지가 리뉴얼에서 특히 중요한 이유입니다.

선택지는 셋입니다 — 그리고 쟁점은 개발 단가가 아닙니다

앱 리뉴얼을 맡길 곳은 크게 셋으로 나뉩니다. 국내 개발사에 맡기는 방식, 해외 개발팀에 직접 발주하는 방식, 그리고 한국인 PM이 글로벌 개발팀을 관리하는 방식입니다.

	국내 개발사	해외 직접 발주	한국 PM + 글로벌 개발팀
개발 단가	높음	낮음	낮음
요구사항 정의 책임	개발사	발주사 본인	한국 PM
기존 시스템 분석 책임	개발사	발주사 본인	한국 PM
커뮤니케이션 언어	한국어	영어	한국어
발주사 담당자 투입 시간	보통	매우 많음	적음
재작업 리스크	낮음	높음	낮음
총비용 관점	비쌈	기대만큼 안 싸다	실질 절감

세 방식의 비교는 대개 단가로 그려집니다. 그러나 리뉴얼에서 비용을 실제로 결정하는 것은 단가가 아니라 “무엇을 만들지 정의하는 일”을 누가 하느냐입니다. 해외 직접 발주가 기대만큼 싸지지 않는 이유가 여기에 있습니다. 단가는 분명히 낮지만, 요구사항을 정의하고 범위를 문서로 쓰고 일정과 검수를 관리하는 일이 통째로 발주사에게 넘어옵니다.

리뉴얼에서는 거기에 “기존 시스템을 읽는 일”까지 얹힙니다. 남이 짠 구조를 읽고 무엇을 가져오고 무엇을 버릴지 판단하는 작업이 발주사 몫이 됩니다. 사내에 개발팀과 PM이 있는 회사라면 가능합니다. 없는 회사에는 사실상 불가능합니다.

디비컨설팅의 구조는 세 번째입니다. 국내 채용 대비 평균 40~60%의 비용을 절감하면서, 정의하고 책임지는 일은 한국인 PM이 맡습니다.

디비컨설팅이 앱 리뉴얼을 통제하는 5단계

1. 상담 및 요구 분석

현재 앱에서 고칠 영역과 다시 만들 영역을 나누고, 승계 범위를 한국어 문서로 확정합니다. 개발자 계정 상태, 소스 인계 여부, 계정과 결제 이력의 이전 범위, 구버전 유지 기간이 이 문서에 들어갑니다. 견적은 이 문서를 근거로 산출됩니다.

2. 개발팀 구성

확정된 범위에 맞춰 전담팀을 2~4주 내에 구성합니다. 리뉴얼은 기존 기술 스택을 읽을 수 있는 인력이 필요하기 때문에, 신규 개발과는 다른 기준으로 팀을 짭니다. 앱 개발 기간이 계획보다 길어지는 지점도 대부분 이 단계의 준비에서 갈립니다.

3. 프로젝트 개발

애자일 방식으로 진행하고 진행 상황을 투명하게 공유합니다. 발주사는 해외 개발자와 직접 대화하지 않습니다. 한국인 PM하고만 한국어로 소통하며, 요구사항 정의와 일정, 검수는 PM이 책임집니다.

4. 테스트 및 배포

리뉴얼의 검증 대상은 기능만이 아니라 전환 그 자체입니다. 기존 계정으로 로그인이 되는지, 결제와 구독 이력이 그대로 보이는지, 구버전과 신버전이 동시에 떠 있는 기간에 양쪽이 모두 정상 동작하는지까지 포함해 검증합니다.

5. 운영 및 유지보수

출시 이후 운영을 지원하고, API 명세와 DB 스키마, 배포 절차 문서까지 인계합니다. 다음 리뉴얼에서 같은 분석 비용이 다시 들지 않게 하는 것이 인계의 목적입니다.

실제 수행 프로젝트

먼저 분명히 말씀드리겠습니다. 아래 가운데 이미 운영 중인 서비스를 손본 작업은 이투스 동영상 강의 앱, 직방 호갱노노, 웅진컴퍼스 LMS 세 건입니다. 삼성물산 홈닉, GS건설 엘리시안 리조트, LS일렉트릭 테크스퀘어, 가천대학교 학사관리 시스템은 구축 프로젝트입니다. 전부 같은 종류의 일이라고 말씀드리지 않겠습니다. 다만 공통점은 사용자와 데이터가 이미 있는 상태에서 구조를 바꾸거나 얹어야 했다는 점이고, 그 조건에서 일정과 품질을 지키는 방법을 쌓아 왔습니다.

• 이투스 동영상 강의 스트리밍 앱 — 운영 중인 앱의 기능 개선과 오류 대응
• 직방 호갱노노 — 실서비스 운영 중 실거래가 API 구조 현대화
• 웅진컴퍼스 LMS 플랫폼 — 기존 학습 플랫폼 커스터마이징과 재구성
• 삼성물산 홈닉 — 주거 플랫폼 앱
• GS건설 엘리시안 리조트 — 리조트 웹·앱 통합 구축
• LS일렉트릭 테크스퀘어 — 산업 B2B 거래 플랫폼
• 가천대학교 — 학사관리 시스템

교육, 금융·핀테크, 헬스케어, 제조·물류, 이커머스, 스마트빌딩·IoT 영역에서 실서비스를 운영 중인 기업들과 함께 진행한 프로젝트입니다. 전체 목록은 포트폴리오에서 보실 수 있습니다.

이런 기업에 적합합니다

• 몇 년째 운영 중인 앱이 있고, 사용자와 결제 이력을 그대로 옮겨야 하는 기업
• 기존 개발사와 연락이 끊겼거나 소스와 문서를 온전히 넘겨받지 못한 기업
• 사내에 요구사항을 문서로 정의하고 개발 일정을 관리할 PM이 없는 기업
• 해외 발주를 검토했지만 영어 소통과 범위 관리가 부담스러운 기업
• 앱만 바꿀지 서버까지 바꿀지 정하지 못해 견적 자체를 받기 어려운 기업

반대로, 권하지 않습니다

• 설치 기반과 결제 이력이 거의 없는 앱이라면 승계 설계에 비용을 쓰지 않으시는 편이 낫습니다. 새 앱으로 깨끗하게 시작하는 편이 쌉니다.
• 디자인만 다듬고 싶은 경우라면 리뉴얼이 아니라 기존 유지보수 업체의 UI 업데이트가 빠르고 저렴합니다.
• 사내에 개발팀과 PM이 있어 요구사항을 직접 정의할 수 있다면 저희 구조는 필요 없습니다.
• 출시일이 몇 주 뒤로 이미 고정되어 있고 그 안에 승계까지 끝내야 한다면, 저희는 그 일정에 동의하지 않습니다.

자주 묻는 질문

해외 개발자와 직접 소통해야 합니까

아닙니다. 발주사는 한국인 PM하고만 한국어로 소통합니다. 요구사항 정의와 일정 관리, 검수는 PM이 책임지며, 개발팀과의 커뮤니케이션도 PM이 전담합니다.

기존 개발사가 소스를 주지 않으면 리뉴얼이 불가능합니까

소스를 받지 못해도 진행은 가능합니다. 다만 현재 앱과 데이터를 분석하는 기간이 별도 과업으로 들어가고, 앱 소유권과 개발자 계정 이전이 선행 조건입니다. 그 협의 범위를 상담 단계에서 먼저 정리합니다.

기획서가 없는데 견적을 받을 수 있습니까

가능합니다. 해결하려는 문제, 주요 사용자, 반드시 필요한 기능 3~5개, 그리고 일정과 예산 범위만 있으면 개략적인 견적을 드립니다. 기획서는 상담 과정에서 함께 정리합니다.

프로젝트 중간에 팀 규모를 조정할 수 있습니까

가능합니다. 전담팀, 장기 협업, 인력 단위, 프로젝트 단위 중에서 계약 형태를 선택할 수 있고 진행 중에도 조정할 수 있습니다. 리뉴얼은 분석 단계와 개발 단계에 필요한 인력이 다르기 때문에 조정 여지를 두는 편이 유리합니다.

소스코드 소유권은 누구에게 있습니까

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

정리

앱 리뉴얼에서 어려운 부분은 새 앱을 만드는 일이 아닙니다. 이미 설치되어 있는 앱과 그 안에 쌓인 사용자, 계정, 거래 이력, 스토어 자산을 끊기지 않게 옮기는 일입니다. 이 승계 범위를 한국어 문서로 정의하지 않은 채 받은 견적은 착수 후에 반드시 움직입니다. 지금 운영 중인 앱의 상태와 바꾸고 싶은 부분만 알려 주시면, 개발자 계정과 소스 인계 여부부터 확인해 승계 범위가 포함된 견적을 드리겠습니다.