개발 일을 하다 보면 프로그램을 만드는 것보다 더 어려운 일이 있습니다. 바로 유지보수 계약을 설명하는 일입니다. 고객 입장에서는 “문제가 생기면 그때 고치면 되는 것 아닌가?”라고 생각하기 쉽습니다. 하지만 실제 운영은 그렇게 단순하지 않습니다.
서비스는 한 번 만들어서 끝나는 물건이 아닙니다. 서버가 살아 있어야 하고, 데이터가 쌓여야 하고, 오류가 생기면 원인을 찾아야 하고, 업무 방식이 바뀌면 프로그램도 따라 바뀌어야 합니다. 이 과정에는 결국 시간과 사람이 들어갑니다.
유지보수는 단순한 오류 수정이 아니다
유지보수를 단순히 버그 수정으로만 보면 비용을 이해하기 어렵습니다. 실제 유지보수에는 오류 수정뿐 아니라 서버 확인, 로그 확인, 데이터 백업, 계정 관리, 보안 점검, 사용 문의 대응, 소소한 기능 조정까지 포함됩니다.
- 서버가 정상적으로 작동하는지 확인해야 합니다.
- 장애가 발생하면 원인을 찾아야 합니다.
- 데이터가 정상적으로 저장되고 있는지 봐야 합니다.
- 사용자가 문의하면 화면과 데이터를 확인해야 합니다.
- 업무 변경이 생기면 프로그램 수정 범위를 판단해야 합니다.
겉으로는 버튼 하나가 안 눌리는 문제처럼 보여도, 실제로는 서버, DB, 소스, 권한, 네트워크, 사용자 입력값까지 확인해야 하는 경우가 많습니다.
서버 운영은 보이지 않지만 계속 비용이 든다
서버 운영비는 고객에게 설명하기 특히 어렵습니다. 눈에 보이는 프로그램 화면은 있지만, 그 뒤에서 돌아가는 서버, 데이터베이스, 백업, 도메인, SSL 인증서, 보안 설정은 잘 보이지 않기 때문입니다.
하지만 서버는 계속 켜져 있어야 합니다. 사용자가 접속하지 않는 시간에도 서버는 돌아가고 있고, 장애가 나면 누군가는 확인해야 합니다. 특히 업무용 프로그램은 멈추면 바로 업무 차질로 이어질 수 있기 때문에 기본적인 운영 관리가 필요합니다.
즉, 서버 운영은 “가끔 보는 일”이 아니라 “문제가 생기지 않도록 계속 관리하는 일”에 가깝습니다.
인건비 개념을 잡아주기가 가장 어렵다
유지보수에서 가장 설명하기 어려운 부분은 인건비입니다. 개발자는 단순히 코드를 몇 줄 고치는 사람이 아닙니다. 문제를 확인하고, 원인을 추적하고, 기존 기능에 영향이 없는지 판단하고, 수정 후 테스트까지 봐야 합니다.
예를 들어 고객이 “이거 하나만 바꿔주세요”라고 말해도 실제 작업은 하나가 아닐 수 있습니다. 화면 수정, DB 컬럼 확인, 기존 데이터 영향 검토, 권한 체크, 배포, 테스트까지 이어질 수 있습니다.
유지보수 비용은 작업 시간만 사는 것이 아니라, 문제가 생겼을 때 대응해 줄 수 있는 사람의 책임 시간을 확보하는 비용입니다.
건바이건 방식이 어려운 이유
유지보수를 건바이건으로 처리하면 처음에는 공정해 보입니다. 작업이 생길 때마다 견적을 내고, 고객이 승인하면 처리하는 방식입니다. 하지만 실제로는 이 방식이 더 어려울 때가 많습니다.
- 작은 문의마다 견적을 내야 해서 대응 속도가 느려집니다.
- 장애 상황에서 비용 협의부터 해야 하는 문제가 생깁니다.
- 원인 확인 시간이 비용으로 인정받기 어렵습니다.
- 작업 범위가 작게 보이다가 실제로는 커지는 경우가 많습니다.
- 고객도 매번 승인해야 해서 피로도가 높아집니다.
특히 서버 장애나 데이터 오류처럼 빠른 확인이 필요한 상황에서는 건바이건 방식이 오히려 서로에게 부담이 됩니다. 그래서 일정 범위 안에서는 월 유지보수 계약으로 묶고, 큰 기능 개발은 별도 견적으로 분리하는 구조가 더 현실적입니다.
유지보수 계약은 이렇게 나누는 것이 좋다
유지보수 계약을 설명할 때는 “월 얼마입니다”라고만 말하면 설득이 어렵습니다. 무엇이 포함되고, 무엇이 제외되는지 나눠서 보여줘야 합니다.
- 기본 운영 관리: 서버 상태 확인, 기본 장애 확인, 계정 관리, 백업 상태 점검
- 오류 대응: 기존 기능에서 발생한 오류 확인과 수정
- 사용 문의 대응: 관리자 화면, 데이터 확인, 사용 방법 안내
- 경미한 수정: 문구 변경, 간단한 화면 조정, 설정값 변경
- 별도 견적: 신규 기능 개발, 대규모 화면 개편, 외부 시스템 연동, DB 구조 변경
이렇게 구분해야 고객도 유지보수비가 어디에 쓰이는지 이해할 수 있습니다.
고객에게 설명할 때 중요한 포인트
유지보수 계약은 비용을 방어하는 문서가 아니라, 운영 책임 범위를 정하는 문서입니다. 고객에게도 이 관점으로 설명해야 합니다.
예를 들어 “매달 돈이 듭니다”가 아니라 “업무 프로그램이 멈췄을 때 바로 확인할 수 있는 운영 창구를 확보하는 비용입니다”라고 설명하는 편이 더 정확합니다.
또한 “모든 수정이 무료”라고 말하면 안 됩니다. 유지보수는 기존 시스템을 안정적으로 운영하기 위한 계약이고, 새로운 기능 개발은 별도 프로젝트로 봐야 합니다. 이 기준이 없으면 나중에 서로 힘들어집니다.
Codeforest 관점의 유지보수 기준
Codeforest는 유지보수를 단순 오류 수정이 아니라 운영 관리로 봅니다. 프로그램을 만들고 끝내는 것이 아니라, 실제 업무에서 계속 사용할 수 있도록 서버, 데이터, 기능, 문의 대응 범위를 함께 관리해야 합니다.
업무 자동화나 사내 시스템 구축이 필요하다면 Codeforest의 개발 방향을 참고할 수 있습니다. 관련 글은 Codeforest 솔루션과 업무 자동화 카테고리에서 함께 확인할 수 있습니다.
결론: 유지보수는 비용이 아니라 운영 책임의 기준이다
유지보수 계약이 어려운 이유는 고객에게 보이지 않는 비용이 많기 때문입니다. 서버 운영, 장애 대응, 로그 확인, 보안 점검, 기능 수정, 인건비는 화면에 바로 드러나지 않습니다. 하지만 서비스가 계속 돌아가기 위해서는 반드시 필요한 일입니다.
그래서 유지보수는 단순히 “고장 나면 고쳐주는 비용”이 아니라 “운영 책임을 어디까지 맡을 것인지 정하는 기준”으로 봐야 합니다. 건바이건으로 처리할 일과 월 유지보수로 묶을 일을 분리해야 개발자도 고객도 오래 갈 수 있습니다.
