앱은 만든 뒤가 시작입니다: 운영과 유지보수에 실제로 드는 것
출시는 비용의 끝이 아니라 시작입니다
앱 개발 견적서는 대개 출시일에서 끝납니다. 그런데 앱에 돈이 실제로 들어가기 시작하는 시점은 그 다음 날입니다. 출시된 앱은 계속 바뀌는 환경 위에 놓여 있고, 그 환경에 맞춰 손을 대지 않으면 어느 시점부터 작동을 멈춥니다. 운영과 유지보수는 선택 항목이 아니라 앱을 살려 두는 조건입니다.
발주하는 쪽에서 예산을 짤 때 개발비는 비교적 또렷하게 잡힙니다. 화면 수와 기능 목록과 기간이 있으니 숫자로 정리됩니다. 반면 운영비는 항목 자체가 잘 보이지 않습니다. 무엇이 발생하는지 모르면 예산표에 0으로 들어가고, 0으로 잡힌 항목은 출시 몇 달 뒤에 예정에 없던 지출로 다시 나타납니다.
출시 이후의 비용은 성격이 다른 네 갈래로 나눠 보면 정리가 쉽습니다. 첫째는 하지 않으면 앱이 멈추는 강제 유지 작업입니다. 둘째는 사용자와 데이터가 늘면 따라 늘어나는 인프라 비용입니다. 셋째는 문의 응대와 버그 수정에 들어가는 사람의 시간입니다. 넷째는 새 기능과 개선입니다. 앞의 세 갈래는 기능을 하나도 추가하지 않아도 발생한다는 점이 중요합니다.
실무에서는 넷째만 유지보수라고 생각하고 계약하는 경우가 많습니다. 그래서 당분간 새 기능 계획이 없으니 유지보수도 필요 없다는 판단이 나옵니다. 앞의 세 갈래를 빼고 보면 맞는 말처럼 들리지만, 앱은 새 기능이 없어도 낡습니다. 가만히 두면 그대로 있는 게 아니라 주변이 움직여서 뒤처집니다.
여우비 인터랙션은 고객사 개발을 하면서 동시에 자체 제품을 직접 운영합니다. 출결 관리 서비스 onSpots는 App Store와 Google Play 양쪽에 올라가 있고 한국어와 베트남어와 영어 세 언어로 돌아갑니다. 베트남 구인구직 서비스 Job Connect VN, 한국어 학습에서 배우는 사람과 가르치는 사람을 잇는 랭토리도 같은 방식으로 운영 중입니다. 아래에 적는 항목은 발주자를 설득하려고 만든 목록이 아니라 저희가 매달 직접 처리하는 목록입니다.
이 글은 금액을 다루지 않습니다. 앱의 성격과 사용자 규모와 요구되는 대응 속도에 따라 편차가 커서, 일반화한 숫자는 오히려 판단을 흐립니다. 대신 어떤 항목이 왜 생기는지, 계약 전에 무엇을 물어야 하는지를 정리합니다.
하지 않으면 앱이 멈추는 일들: OS 업데이트, 스토어 정책, 인증서 갱신
새 기능을 전혀 만들지 않아도 반드시 해야 하는 일이 있습니다. 운영체제가 올라가고, 스토어 심사 기준이 바뀌고, 서명에 쓰는 인증서가 만료됩니다. 이 셋을 방치하면 새 빌드를 올릴 수 없게 되거나, 신규 설치가 막히거나, 이미 설치한 사용자의 앱이 실행 중에 죽습니다.
iOS와 Android는 해마다 주요 버전이 나옵니다. 버전이 올라가면 권한 처리, 백그라운드 실행, 알림 동작, 파일 접근 같은 기본 규칙이 바뀝니다. 앱 코드가 그대로여도 실행 환경이 달라지므로 어제까지 되던 기능이 멈출 수 있습니다. 카메라, 위치, 블루투스, 백그라운드 동기화를 쓰는 앱일수록 영향을 크게 받습니다. 여기에 쓰던 오픈소스 라이브러리가 새 버전에 대응하지 않으면 라이브러리를 갈아 끼우는 작업까지 따라붙습니다.
두 스토어 모두 앱이 지켜야 할 기준을 계속 갱신합니다. 빌드가 겨냥해야 하는 SDK 수준, 개인정보 처리방침 고지 방식, 수집하는 데이터 항목의 공개, 계정 삭제 경로 제공, 결제 처리 방식 같은 것이 대표적입니다. 요건의 구체적인 내용과 적용 시점은 자주 바뀌므로 이 글의 서술을 기준으로 삼지 마시고, 빌드를 올리기 전에 각 스토어의 공식 개발자 문서에서 그 시점의 요건을 확인하시기 바랍니다. 기준을 맞추지 못하면 심사가 거절되고, 경우에 따라 기존 앱의 노출이 제한됩니다.
앱을 스토어에 올리려면 서명이 필요하고, 서명에 쓰는 인증서와 키에는 유효기간이 있습니다. 개발자 계정 자체도 갱신 대상입니다. 푸시 알림에 쓰는 키, 지도와 결제 연동에 쓰는 키도 마찬가지입니다. 갱신 주기와 절차는 플랫폼 정책에 따라 다르고 중간에 방식이 바뀌기도 하므로, 만료일을 달력에 등록해 두고 그때그때 공식 안내를 확인하는 편이 안전합니다. 만료를 놓치면 배포가 막히는데, 급하게 처리하려 해도 계정 권한을 가진 사람을 찾는 데 며칠이 갑니다.
이 범주에서 되돌리기가 가장 어려운 사고는 서명 키를 잃어버리는 것입니다. 안드로이드의 앱 서명 키는 앱의 신원에 가까워서, 보관 방식과 복구 경로를 미리 정해 두지 않으면 업데이트를 올리지 못하는 상황이 생길 수 있습니다. 계정과 키가 개발사 담당자 개인 명의로 남은 채 계약이 끝나는 경우가 실무에서 반복되는 사고 유형입니다. 5절에서 다시 다루겠지만, 이건 기술 문제가 아니라 계약 문제입니다.
앱이 붙어 있는 외부 서비스도 같은 이유로 유지 대상입니다. 지도, 소셜 로그인, 결제, 푸시, 문자 발송, 분석 도구는 각자 API 버전을 올리고 옛 버전을 종료합니다. 종료 공지는 대개 여러 달 전에 나오지만, 그 공지를 읽는 사람이 없으면 종료일에 기능이 조용히 죽습니다. 운영에는 코드를 고치는 일뿐 아니라 이런 공지를 읽고 일정에 반영하는 일도 들어갑니다.
서버와 인프라: 사용자가 늘면 함께 늘어나는 항목
서버 비용은 앱을 만들 때 정해지는 고정값이 아니라 사용량에 따라 움직이는 변수입니다. 사용자가 늘면 연산, 데이터베이스, 저장 공간, 전송량, 로그, 알림 발송량이 함께 늘어납니다. 무엇이 어떤 속도로 늘어나는지는 앱의 구조에 달렸고, 그 구조는 개발 단계에서 결정됩니다.
청구서에 실제로 찍히는 항목을 보면 대체로 이렇습니다. 서버 연산 시간, 데이터베이스 용량과 처리량, 이미지와 파일 저장 공간, 밖으로 나가는 전송량, 로그와 모니터링 보관, 백업 보관, 푸시와 문자와 이메일 발송 건수, 그리고 지도나 인증처럼 호출 수로 과금되는 외부 API입니다. 여기에 도메인, 스토어 개발자 계정처럼 규모와 무관하게 매년 나가는 고정 항목이 붙습니다.
예산이 어긋나는 지점은 대체로 정해져 있습니다. 사용자가 올리는 사진과 동영상이 첫 번째입니다. 원본을 그대로 저장하고 그대로 내려보내면 저장 비용과 전송 비용이 함께 뜁니다. 두 번째는 로그입니다. 디버깅을 위해 켜 둔 상세 로그를 그대로 두면 보관량이 조용히 쌓입니다. 세 번째는 문자 인증입니다. 건당 과금이라 가입자가 늘면 정직하게 비례하고, 자동화된 가입 시도가 들어오면 예상 밖으로 튑니다.
클라우드와 외부 서비스의 무료 구간도 주의할 부분입니다. 초기에는 대부분 무료 한도 안에서 돌아가기 때문에 인프라 비용이 거의 없는 것처럼 보입니다. 한도를 넘는 순간 과금이 시작되는데, 그 시점은 대개 사용자가 늘어 기뻐하고 있을 때입니다. 예산 알림과 사용량 상한을 미리 걸어 두지 않으면 청구서를 받고 나서야 알게 됩니다.
운영비를 줄이는 방법은 대부분 출시 후가 아니라 설계 단계에 있습니다. 이미지를 올릴 때 크기를 줄여 저장할지, 자주 읽는 데이터를 캐시할지, 목록 조회를 어떻게 짤지, 오래된 데이터를 언제 정리할지 같은 결정이 매달 나가는 금액의 자릿수를 바꿉니다. 발주 단계에서 월 운영비를 어느 수준으로 잡고 설계하는지 물어보면 개발사가 이 부분을 고려하고 있는지 드러납니다.
반대로 줄이면 안 되는 항목도 있습니다. 백업과 복구 절차, 오류 추적, 기본적인 상태 감시는 분명히 비용이지만, 없애는 순간 사고 한 번에 그보다 훨씬 큰 비용으로 돌아옵니다. 백업은 받아 두는 것으로 끝나지 않고 실제로 복구되는지 확인하는 시간까지가 항목입니다. 한 번도 복구해 보지 않은 백업은 있다고 말하기 어렵습니다.
문의 대응과 버그 수정에 들어가는 사람의 시간
출시 후 비용에서 가장 큰 항목은 서버가 아니라 사람의 시간인 경우가 많습니다. 문의를 읽고, 재현하고, 원인을 찾고, 고치고, 다른 기능이 깨지지 않았는지 확인하고, 배포하고, 스토어 심사를 기다립니다. 한 줄짜리 수정에도 이 과정이 통째로 붙습니다.
웹은 고치면 그날 반영됩니다. 모바일 앱은 다릅니다. 빌드를 만들고 스토어에 올리고 심사를 통과해야 하며, 통과한 뒤에도 사용자가 업데이트를 받아야 합니다. 업데이트를 받지 않는 사용자는 계속 옛 버전에 남습니다. 그래서 모바일 운영에서는 지금 당장 고쳐야 하는 것을 앱 배포 없이 처리할 경로를 미리 만들어 둡니다. 서버에서 값을 내려 주는 설정, 특정 기능만 끌 수 있는 스위치, 문구를 서버에서 관리하는 구조가 그런 장치입니다. 처음부터 넣어 두면 급한 상황에서 며칠을 법니다.
사람 시간이 가장 많이 새는 곳은 재현되지 않는 버그입니다. 가끔 로그인이 안 된다는 문의 한 줄로 원인을 찾으려면 기기, OS 버전, 네트워크, 계정 상태를 하나씩 좁혀야 합니다. 크래시 리포팅과 오류 추적을 붙여 두면 이 과정이 몇 시간에서 몇 분으로 줄어듭니다. 도구 비용이 사람 시간보다 싼 대표적인 경우입니다.
문의는 한 곳으로만 오지 않습니다. 스토어 리뷰, 앱 안의 문의 폼, 이메일, 회사 대표 전화, 영업 담당자의 메신저로 흩어져 들어옵니다. 계약할 때 정해야 할 것은 1차로 받는 주체가 누구인가입니다. 발주사의 응대 인력이 먼저 받고 기술 사안만 개발사로 넘길지, 개발사가 처음부터 받을지에 따라 양쪽의 업무량이 크게 달라집니다. 정해 두지 않으면 스토어 리뷰에 달린 불만이 아무도 읽지 않은 채 쌓입니다.
대응 속도를 어디까지 약속하느냐가 곧 비용입니다. 영업일 기준으로 다음 날 답변하는 것과, 주말과 야간을 포함해 정해진 시간 안에 대응하는 것은 필요한 인력 구성이 다릅니다. 모든 문의를 같은 속도로 처리할 이유는 없으므로, 결제가 막히는 수준의 장애와 화면 문구 오타를 같은 등급에 두지 않는 편이 서로에게 낫습니다. 긴급도 구분과 등급별 목표 응답 시간을 계약서에 적어 두면 나중에 다툴 일이 줄어듭니다.
여러 언어로 서비스하는 앱은 응대도 그 언어로 해야 합니다. onSpots를 한국어와 베트남어와 영어로 운영하면서 확인한 것은 번역이 화면에서 끝나지 않는다는 점입니다. 문의 답변, 스토어 설명, 공지, 오류 메시지까지 같은 품질로 유지해야 하고 여기에도 사람 시간이 듭니다. 베트남과 한국 양쪽을 대상으로 하는 앱이라면 이 항목을 처음부터 예산에 넣는 편이 정확합니다.
계약 전에 합의해 두어야 할 유지보수 범위
유지보수는 가격을 묻기 전에 범위를 정하는 편이 낫습니다. 범위가 다르면 견적을 나란히 놓고 비교하는 일 자체가 성립하지 않기 때문입니다. 아래는 발주하는 쪽에서 계약서와 제안서를 읽을 때 확인할 항목입니다. 어느 업체와 일하든 같은 질문을 하시면 됩니다.
먼저 무상 하자보수 기간과 하자의 정의입니다. 합의된 검수 기준대로 동작하지 않는 것은 하자이고, 검수를 통과한 뒤에 새로 요구하는 동작은 개선입니다. 이 경계가 문서에 없으면 출시 직후 몇 달 동안 양쪽이 소모적인 논쟁을 합니다. 요구사항 문서와 검수 기준이 남아 있어야 구분이 가능하다는 점도 같이 기억해 두시는 게 좋습니다.
유지보수 계약의 형태도 확인 대상입니다. 매달 정해진 범위를 처리하는 방식, 실제 투입 시간을 정산하는 방식, 건별로 견적을 내는 방식이 있고 각각 맞는 상황이 다릅니다. 변경이 적고 안정적으로 돌아가는 앱은 건별이 편하고, 계속 손볼 계획이 있으면 정액이나 시간 정산이 관리하기 쉽습니다. 어느 쪽이든 포함되는 작업과 포함되지 않는 작업을 목록으로 적어 두는 것이 핵심입니다.
특히 2절에서 다룬 강제 유지 작업이 유지보수에 포함되는지 명시해야 합니다. 운영체제 주요 버전 대응, 스토어 정책 변경 대응, 인증서와 키 갱신, 외부 API 버전 종료 대응이 기본 계약 안인지 별도 건인지에 따라 실제 부담이 크게 달라집니다. 이 항목들이 계약서에 아예 등장하지 않는다면 그 자체가 물어볼 지점입니다.
인프라 비용을 누가 부담하고 어떻게 청구하는지도 적어 두시기 바랍니다. 클라우드 요금을 개발사가 대납하고 청구하는지, 발주사 계정에서 직접 나가는지, 사용량이 예상을 넘으면 누가 먼저 알리는지가 정해져 있어야 합니다. 사용량 기반 항목은 매달 달라지므로 고정 금액으로 묶어 두면 어느 쪽이든 손해를 보는 달이 생깁니다.
계정과 자산의 소유권은 가장 나중에 확인되지만 가장 중요한 항목입니다. 클라우드 계정, 스토어 개발자 계정, 도메인, 서명 키, 소스 저장소, 외부 서비스 계정이 각각 누구 명의인지 문서로 남겨야 합니다. 발주사 명의로 두고 개발사에 운영 권한을 위임하는 형태가 나중에 문제가 적습니다.
마지막은 끝내는 방법입니다. 계약을 종료할 때 소스코드와 문서를 어떤 형태로 넘기는지, 다른 업체가 그 소스로 같은 빌드를 만들 수 있는지, 이관 지원을 몇 주 동안 하는지, 종료 통지는 며칠 전에 하는지를 적어 둡니다. 이 조항이 잘 정리된 계약은 헤어지기 위한 문서가 아니라 계속 일하기 좋은 문서입니다. 나갈 수 있게 열어 둔 쪽이 대체로 더 성실하게 일합니다.
권하는 순서는 단순합니다. 개발 견적을 받을 때 운영 항목을 같은 문서에서 함께 묻고, 1년 치 부담을 대략이라도 그려 본 다음에 개발 범위를 정하는 것입니다. 만들 수 있는 앱과 유지할 수 있는 앱은 다릅니다. 저희도 자체 제품을 운영하며 매달 같은 항목을 처리하고 있으니, 어떤 항목부터 정리해야 할지 궁금하시면 편하게 물어보셔도 됩니다.
