앱 유지보수 계약 전에 확인할 여섯 가지

유지보수 계약에서 문제가 생기는 지점은 대개 기술이 아니라 기준입니다. 무엇을 넘겨받았는지, 무엇이 1건인지, 누가 승인하는지가 흐리면 몇 달 뒤에 다툼이 됩니다. 계약 전에 아래 여섯 가지를 문서로 확인해 두면 대부분 예방됩니다.

1. 인수 자료

소스 코드, 설계 문서, 배포 계정, 서버와 도메인 접근 권한, 외부 서비스 키. 이 중 하나라도 없으면 유지보수 범위가 줄거나 복구 작업이 먼저 필요합니다. 다른 업체가 만든 앱이라면 넘겨받을 수 있는 자료 목록을 먼저 확인하고 그 뒤에 범위를 정합니다.

어디까지가 1건이고 어디부터 별도인지 예시와 함께 적혀 있어야 합니다. '기존 기능에 조건 하나를 추가하는 것'과 '한 가지 용도의 기능을 새로 만드는 것'처럼 구분이 있는지 보세요.

요청이 곧바로 작업으로 이어지면 안 됩니다. 범위와 건수를 먼저 안내받고, 승인한 뒤에 개발이 시작되고, 결과를 확인한 뒤에 배포되는 구조인지 확인합니다. 이 순서가 있으면 청구서에 모르는 항목이 생기지 않습니다.

요청, 승인, 배포, 산출물이 어디에 남는지 봅니다. 메신저 대화만 남는다면 나중에 찾을 수 없습니다. 정기 보고서의 주기와 내용(처리 작업, 점검 결과, 이상 알림)도 계약서에 있어야 합니다.

정기 점검 주기, 서비스 상태 확인과 오류 수집이 자동으로 도는지, 장애가 났을 때 누가 언제 알게 되는지를 확인합니다. 요청이 없어도 돌아가는 부분이 유지보수의 절반입니다.

남은 작업 건수가 다음 달로 넘어가는지, 해지하면 자료와 계정이 어떻게 돌아오는지를 계약 전에 문서로 받습니다. 이 두 가지는 나중에 물어보면 답이 달라지는 항목입니다.