앱 유지보수 비용은 앱을 만든 뒤 그것을 계속 운영하는 데 들어가는 돈을 말한다. 앱은 한 번 만들고 끝나는 물건이 아니다. 운영체제가 바뀌고, 스토어 정책이 바뀌고, 사용자가 오류를 겪으면서 계속 손을 봐야 하는 서비스에 가깝다. 이 글은 유지보수 비용이 무엇으로 구성되는지, 왜 앱마다 금액 차이가 크게 나는지, 계약서를 볼 때 어디를 살펴야 하는지를 차례로 정리한다.
유지보수라는 말 안에는 서로 다른 성격의 작업이 여럿 섞여 있다. 서버를 켜 두고 접속이 끊기지 않게 관리하는 일, 운영체제나 기기 업데이트로 앱이 갑자기 멈추지 않도록 손보는 일, 사용자가 신고한 오류를 고치는 일, 그리고 화면이나 기능을 새로 추가하는 일이 모두 유지보수라는 이름 아래 묶여서 이야기된다. 문제는 이 네 가지가 같은 일이 아닌데도 계약서에는 뭉뚱그려 적히는 경우가 많다는 점이다.
유지보수 비용에 실제로 포함되는 항목
일반적으로 앱 유지보수 비용에는 서버와 데이터베이스를 안정적으로 운영하는 호스팅 관련 비용, 오류가 발생했을 때 원인을 찾고 고치는 대응 비용, 운영체제나 스토어 정책이 바뀔 때 앱이 계속 작동하도록 맞추는 대응 비용, 지도나 결제처럼 외부 서비스를 불러다 쓸 때 드는 사용료, 그리고 화면이나 기능을 조금씩 개선하는 작업이 들어간다. 이 다섯 가지 중 어디까지를 정액 계약에 포함하고 어디부터를 별도 견적으로 처리할지가 계약서마다 다르다. 그래서 같은 금액이라도 실제로 받는 서비스 범위는 계약마다 크게 달라질 수 있다.
앱 유지보수 비용이 사례마다 다르게 매겨지는 가장 큰 이유는 앱의 규모와 구조 때문이다. 화면 몇 개짜리 단순한 앱과 회원 관리, 결제, 실시간 알림까지 갖춘 앱은 유지보수에 들어가는 손이 근본적으로 다르다. 외부 서비스와 연동이 많을수록, 그리고 이용자 수가 많아 서버 부담이 클수록 관리해야 할 지점이 늘어난다. 그래서 유지보수 비용을 물을 때는 앱 규모에 대한 설명 없이 금액만 비교하는 것은 큰 의미가 없다.
계약 방식도 비용 구조를 가르는 요소다. 매달 일정 금액을 내고 정해진 범위의 대응을 받는 정액제 방식이 있고, 문제가 생길 때마다 작업 시간이나 건수를 기준으로 비용을 매기는 방식도 있다. 정액제는 예산을 예측하기 쉽지만 계약 범위 밖의 일은 별도 비용이 붙는다. 건별 방식은 평소에는 비용이 적게 들지만 문제가 한꺼번에 몰리면 예상보다 부담이 커질 수 있다. 둘 중 무엇이 낫다고 단정하기보다는 앱을 얼마나 자주, 얼마나 크게 바꿀 계획인지에 맞춰 고르는 편이 맞다.
계약서에서 자주 어긋나는 지점
실제로 분쟁이 생기는 지점은 대개 금액이 아니라 범위에 대한 해석 차이에서 나온다. 오류를 고치는 일과 기능을 새로 추가하는 일의 경계가 애매하게 적혀 있으면, 같은 요청을 두고 한쪽은 유지보수라 하고 다른 쪽은 추가 개발이라 주장하는 일이 생긴다. 또한 문제가 생겼을 때 며칠 안에 대응해야 하는지, 즉 응대 기간에 대한 기준이 계약서에 없으면 급한 오류도 순서 없이 밀릴 수 있다. 앱의 소스코드와 관리자 계정을 누가 보관하는지도 반드시 짚어야 할 부분이다. 계약이 끝났을 때 소스코드를 넘겨받지 못하면 다른 곳에 유지보수를 맡기고 싶어도 옮길 수 없는 처지에 놓인다.
상황에 따라 달라지는 비용 구조
같은 앱이라도 운영 단계에 따라 유지보수의 무게 중심이 달라진다. 앱을 막 출시한 직후에는 예상치 못한 오류가 몰리기 때문에 대응 비중이 크다. 어느 정도 안정된 뒤에는 오류 대응보다는 운영체제나 정책 변화에 맞추는 작업과 기능 개선이 중심이 된다. 이용자가 늘어나 서버 부담이 커지는 단계에서는 서버 관련 비용이 새롭게 커질 수 있다. 이 때문에 유지보수 계약은 한 번 정해 놓고 끝내기보다, 운영 단계가 바뀔 때마다 범위와 금액을 다시 점검하는 편이 현실적이다.
유지보수를 둘러싼 흔한 오해 중 하나는 앱을 만들 때 이미 낸 개발비 안에 이후 관리까지 포함되어 있으리라는 생각이다. 개발비는 앱을 처음 만드는 작업에 대한 대가이고, 유지보수비는 그 이후 계속 운영하는 데 대한 대가로 별도로 다뤄지는 경우가 대부분이다. 또 하나는 유지보수를 아예 하지 않아도 앱이 그대로 유지될 것이라는 생각인데, 운영체제나 스토어 쪽 정책이 바뀌면 아무 기능도 건드리지 않았는데도 앱이 갑자기 작동하지 않는 일이 생길 수 있다. 이런 변화에 대응하지 않고 방치된 앱은 시간이 지날수록 손보기가 더 어려워진다.
계약을 맺기 전에는 몇 가지를 순서대로 확인하는 편이 좋다. 먼저 유지보수 범위에 오류 대응, 정책 대응, 기능 개선이 각각 포함되는지를 항목별로 짚어 본다. 다음으로 정액제인지 건별인지, 정액제라면 범위를 벗어난 작업은 어떻게 처리되는지를 확인한다. 그다음 응대까지 걸리는 기간에 대한 기준이 명시되어 있는지, 마지막으로 소스코드와 관리자 권한을 누가 갖는지를 문서로 남겨 둔다. 이 네 가지만 분명히 해 두어도 뒤늦게 생기는 다툼의 상당수를 미리 막을 수 있다.
아래는 유지보수 계약을 검토할 때 참고할 수 있도록 항목별 성격을 정리한 표다. 금액이 아니라 무엇을 살펴야 하는지에 초점을 맞췄다.
| 구분 | 확인할 내용 |
|---|---|
| 서버·호스팅 | 접속 안정성과 데이터 보관을 누가 책임지는지 |
| 오류 대응 | 신고 후 대응까지 걸리는 기간 기준이 있는지 |
| 정책 대응 | 운영체제·스토어 정책 변화 대응이 범위에 포함되는지 |
| 기능 개선 | 별도 견적 대상인지, 정액 범위에 포함되는지 |
| 소스코드·권한 | 계약 종료 시 이관 방식이 명시되어 있는지 |
앱 유지보수 비용은 정해진 시세가 있는 항목이 아니라 앱의 규모와 계약 범위에 따라 달라지는 값이다. 그래서 금액 자체보다 계약서에 어떤 항목이 포함되고 빠져 있는지를 먼저 확인하는 것이 순서에 맞다. 견적을 받을 때는 항목별로 나누어 설명해 달라고 요청하고, 계약서에 응대 기간과 소스코드 이관 조건이 명시되어 있는지를 직접 확인하면 된다.
· · · · · · · · · ·
스페셜타임스는 AI 기술의 도움을 받아 더 빠르고 다양한 뉴스를 독자에게 전달하기 위해 노력하고 있습니다.