앱 유지보수 비용, 출시 후에 진짜 돈이 드는 이유 — 외주 계약 전에 확인해야 할 것

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

이 지점에서 많은 기업이 처음 깨닫습니다. 프로젝트가 끝난 것이 아니라, 계약이 끝난 것입니다. 앱은 한 번 만들어 납품받는 물건이 아니라 매달 돌아가는 서비스입니다. 서버는 계속 켜져 있어야 하고, 운영체제는 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 외주 프로젝트가 납기 후 분쟁으로 끝나는 구조와 같은 뿌리입니다. 그래서 앱 유지보수 비용을 실제로 결정하는 변수는 개발 단가가 아닙니다. 구조가 문서로 남아 있는지, 그리고 그 문서를 한국어로 설명하고 다음 작업을 정의해 줄 사람이 계속 있는지입니다.

세 가지 선택지 비교

구분	국내 개발사	해외 직접 발주	한국 PM + 글로벌 개발팀
개발 단가	높음	낮음	낮음
요구사항 정의 책임	개발사	발주사 본인	한국 PM
커뮤니케이션 언어	한국어	영어	한국어
발주사 담당자 투입 시간	보통	매우 많음	적음
유지보수 연속성	계약 종료 시 단절 위험	발주사가 직접 관리	팀 유지·규모 조정 가능
재작업 리스크	낮음	높음	낮음
총비용 관점	비쌈	기대만큼 안 싸다	실질 절감

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

국내 개발사는 한국어로 소통하고 요구사항 정의도 맡아 주지만, 계약이 끝나면 그 팀이 그대로 남아 있을 이유가 없습니다. 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 스키마와 배포 절차까지 인계하는 구조입니다. 외주 계약서에 서명하기 전에 단가표보다 먼저 확인하실 것은 그 세 가지가 계약 범위에 들어 있는지입니다.