외주 개발을 처음 경험하는 창업자들이 가장 당황하는 순간 중 하나예요. 론칭하고 나서 서버 비용, 버그 수정, 기능 추가, OS 업데이트 대응… 개발이 끝난 줄 알았는데 비용이 계속 나가는 거예요.
이게 비정상적인 일이 아니에요. 소프트웨어는 본질적으로 살아있는 시스템이기 때문에 유지보수가 필수예요. 문제는 계약 단계에서 이 부분을 제대로 정의하지 않으면, 나중에 비용과 책임 문제로 개발사와 갈등이 생기는 거예요.
2026년 현재, 포텐랩이 컨설팅하는 스타트업들 중 상당수가 유지보수 계약 문제로 어려움을 겪고 있어요. 계약서에 없는 내용을 요청해서 갈등이 생기거나, 반대로 당연히 해줄 거라 생각했던 것들이 유료로 청구되는 경우들이요.
이 글에서는 유지보수 계약 전 반드시 확인해야 할 5가지 실수와 그 예방법을 정리했어요.
유지보수 계약에서 가장 흔한 실수는 "유지보수 월 N만 원"이라고만 쓰고, 그 안에 무엇이 포함되는지 명시하지 않는 거예요.
개발사 입장의 유지보수와 클라이언트 입장의 유지보수가 완전히 다를 수 있어요:
계약서에 반드시 명시해야 할 항목:
유지보수 계약을 "무기한"으로 체결하거나, 해지 조건을 불명확하게 두면 두 가지 문제가 생겨요.
첫째, 개발사 입장에서 핵심 개발자가 이직하거나 팀이 해체되어도 계약이 유지되는 경우가 있어요. 이때 서비스 품질이 급격히 낮아져도 해지하기 어려운 상황이 됩니다.
둘째, 클라이언트가 내부 개발팀을 채용했거나 다른 개발사로 전환하려 해도, 계약 해지 조건이 까다로우면 이중 비용이 발생해요.
권장 계약 구조:
외주 개발이 완료된 후에도 GitHub 레포지토리 소유권이 개발사에 있거나, 서버 관리자 계정을 개발사만 갖고 있는 경우가 생각보다 많아요.
이렇게 되면 유지보수 계약이 끝났을 때 매우 곤란한 상황이 됩니다. 새 개발사에 인수인계가 어렵고, 긴급 상황에서 직접 대응이 불가능해요.
개발 완료 시점에 반드시 확보해야 할 것들:
이게 "내 것"이 되어야 진짜로 개발이 완료된 거예요. 포텐랩은 프로젝트 종료 시 소스코드 및 인프라 접근 권한을 100% 클라이언트에게 이전하는 것을 원칙으로 하고 있어요.
개발사가 바뀔 때 가장 많이 발생하는 문제예요. 서버 아키텍처, 환경변수 목록, 배포 프로세스, API 구조, 데이터베이스 스키마 — 이런 것들이 문서화되어 있지 않으면, 새 개발사가 처음부터 파악하는 데만 한두 달이 걸려요.
이 비용은 클라이언트가 고스란히 부담하게 됩니다.
유지보수 계약에 포함해야 할 문서 요구사항:
분기마다 한 번씩 이 문서를 업데이트하는 것을 계약 조건으로 넣으면, 언제 개발사를 교체해도 인수인계가 원활해요.
유지보수 계약에서 SLA가 없으면 서비스가 중단되었을 때 개발사에 "빨리 고쳐달라"고 요청하는 것 외에 법적으로 할 수 있는 게 없어요. 개발사 입장에서도 어느 정도의 우선순위로 처리해야 하는지 기준이 없어서 혼란스럽고요.
권장 SLA 항목:
SLA 위반 시 패널티 조항도 넣을 수 있어요. "P0 미달 시 해당 월 유지보수 비용 50% 환불" 같은 방식으로요. 이게 있으면 개발사도 더 긴장하고 빠르게 대응해요.
유지보수 비용은 서비스 규모와 기술 스택에 따라 다르지만, 일반적인 스타트업 서비스 기준으로:
이 비용에는 서버 비용(별도)이 포함되지 않아요. 서버 비용은 실사용량 기준으로 클라이언트가 직접 클라우드 제공사에 납부하는 구조가 가장 투명해요.
외주 개발은 개발 완료가 끝이 아니에요. 어떻게 운영하느냐가 진짜 시작이에요. 포텐랩은 개발 착수 전 계약 구조 설계부터, 인프라 소유권 이전, 운영 문서화까지 97%의 수행완수율로 함께합니다. 유지보수 계약으로 고민 중이라면 무료 상담 먼저 받아보세요.