유지보수 계약, 무엇을 맡기고 무엇을 따로 정해야 하는가

유지보수를 맡기기로 하면 계약서에는 대개 맡기는 일의 목록이 먼저 적힙니다. 오류 수정, 정기 업데이트, 운영 지원, 기능 개선. 이 목록은 어느 업체의 계약서를 펴 보아도 크게 다르지 않습니다.

계약 이후 해석의 차이가 실제로 생기는 것은 목록 밖의 요청입니다. 들어온 요청이 오류인지 새 기능인지, 범위 안인지 밖인지, 범위 밖이라면 누가 승인하는지입니다. 이 경계가 계약서에 비어 있으면 같은 종류의 요청을 두고 매번 다시 협의하게 됩니다. 이 글은 유지보수가 맡는 일을 네 가지로 정리한 뒤, 계약서에 적을 항목을 「정하지 않으면 생기는 일」과 함께 정리합니다.

다루는 범위를 먼저 구분합니다. 지금 시스템을 다른 팀이 이어받을 수 있는 상태인지 — 소스코드, 실행 환경, 데이터, 배포 경로, 계정 명의, 문서를 확보했는지 — 는 기존 시스템, 이어받으려면 무엇이 필요한가에서 다룹니다. 이 글은 그 확인이 끝난 다음, 맡기는 계약에 무엇을 적을 것인가를 다룹니다. 비용을 어떤 구조로 정하는지와 유지할지 다시 만들지의 판단은 유지보수 비용의 구조와 유지보수와 재구축의 판단에서 따로 다룹니다.

계약서 확인 항목은 빌드업웍스를 포함해 어느 업체와 계약하시든 그대로 대조하실 수 있습니다.

유지보수가 맡는 일의 네 가지

유지보수라는 한 단어 안에는 성격이 다른 일이 넷 들어 있습니다. 계약서의 목록이 이 넷을 각각 다루는지부터 보시면 빠진 칸이 드러납니다.

• 오류 수정 — 접수, 원인 분석, 수정입니다. 증상을 없애는 임시 조치와 원인을 고치는 수정은 같은 일이 아닙니다. 계약서의 「오류 대응」에 원인 분석까지 들어 있는지를 확인하실 수 있습니다.
• 정기 업데이트와 점검 — 의존성(라이브러리)과 프레임워크의 업데이트, 보안 패치, 모니터링과 보안 점검입니다. 아무도 요청하지 않아도 해야 하는 일이라, 요청을 받아 처리하는 방식으로만 적힌 계약에서는 빠지기 쉽습니다. 누가 어떤 주기로 점검하고, 반영하기 전에 무엇을 확인하는지가 적혀 있어야 합니다.
• 운영 지원 — 배포, 변경 기록, 운영 문서와 구성 문서의 갱신입니다. 수정한 내용을 서비스에 반영하고, 무엇을 왜 바꿨는지 남기는 일입니다. 이 일이 비어 있으면 수정은 이뤄지는데 그 이력이 남지 않습니다.
• 우선순위에 따른 개선 — 기능 추가, 성능 개선, 테스트 보강입니다. 요청을 한 목록으로 모으고, 합의한 우선순위대로 반영하는 일입니다.

앞의 셋은 시스템을 계속 쓸 수 있게 하는 일이고, 마지막 하나는 시스템을 나아지게 하는 일입니다. 계약에서 가장 자주 흐려지는 것이 이 둘의 경계이고, 그다음이 개선과 별도 프로젝트의 경계입니다. 작은 기능 추가는 개선 목록에 들어가지만, 데이터 구조를 바꾸거나 새 업무 흐름을 세우는 일은 대개 범위와 일정을 따로 정하는 프로젝트의 크기입니다. 이 경계를 무엇으로 구분할지를 계약서에 적어 두면, 개선 요청이 들어올 때마다 다시 협의하지 않아도 됩니다.

계약서에 정할 항목 — 대상 시스템부터 종료 시 인계까지

계약서에 정할 항목과 정하지 않았을 때 생기는 일은 다음과 같습니다. 각 항목이 계약서에 적혀 있는지, 비어 있는지, 적혀 있지만 해석이 갈리는지를 차례로 대조하실 수 있습니다.

표의 항목이 모두 같은 무게는 아닙니다. 장애와 요청의 구분과 범위 밖 작업의 처리는 계약 기간 내내 매달 판단에 쓰이고, 종료 시 인계는 계약 마지막에 한 번 쓰이지만 그 시점에 새로 정하기가 가장 어렵습니다. 여러 칸이 비어 있다면 이 셋부터 채우시는 편이 실효가 큽니다.

장애와 변경 요청을 구분하는 기준

기준은 정해 둔 동작입니다. 정해 둔 대로 동작하지 않으면 오류이고, 그 오류로 업무가 멈추면 장애로 먼저 처리합니다. 정해 둔 동작 자체를 바꾸는 것은 변경 요청입니다.

판정이 자주 갈리는 것은 「원래 그렇게 동작해야 했다」는 요청입니다. 요청한 쪽에서는 오류이고, 받는 쪽에서는 새 요구사항으로 보일 수 있습니다. 어느 쪽 판단이 맞는지는 기준 문서가 있어야 판단할 수 있습니다. 요구사항 정의나 화면 정의 같은 문서가 있다면 그것이 기준이 되고, 그런 문서가 남아 있지 않은 시스템이라면 계약 시점의 현재 동작을 기준으로 삼는다고 적어 두는 방법이 있습니다.

그래도 판정이 갈리는 요청은 생깁니다. 그때 누가 정하는지를 함께 적어 두시면 됩니다. 업무 우선순위는 고객사가 결정할 사항이므로, 판정이 갈린 요청을 어느 목록에 넣을지도 고객사의 담당자가 정하는 구조가 자연스럽습니다.

장애의 등급과 등급별 대응 방식은 그 시스템이 업무에서 차지하는 비중에 따라 달라집니다. 일률적인 기준을 가져오기보다, 어떤 상황을 장애로 볼지를 그 시스템의 업무 기준으로 정의해 계약에서 확정하시는 편이 정확합니다.

범위 밖 작업 — 착수 전 안내와 승인

범위 밖 작업이 생기는 것 자체는 문제가 아닙니다. 운영 중인 시스템에는 계약할 때 예상하지 못한 요청이 생기기 마련입니다. 문제가 되는 것은 그 순간의 절차가 비어 있을 때입니다.

계약서에 적을 절차는 네 단계면 충분합니다.

1. 범위 밖이라는 판단을 유지보수 쪽이 먼저 알립니다.
2. 작업 범위와 비용, 일정을 안내합니다.
3. 고객사의 지정된 담당자가 승인합니다.
4. 승인 뒤에 진행하고, 변경 기록에 남깁니다.

이 중 비워 두기 쉬운 것이 세 번째의 승인하는 사람입니다. 요청하는 실무자와 비용을 승인할 수 있는 사람이 다른 경우, 그 구분이 계약서에 없으면 실무 요청이 곧 승인으로 처리됩니다. 그리고 「승인 전에는 착수하지 않는다」는 문장이 있어야, 작업이 끝난 뒤에 비용을 처음 알게 되는 일이 생기지 않습니다.

반대 방향도 있습니다. 범위 밖이라는 이유로 필요한 작업이 멈추는 경우입니다. 보안 패치처럼 미룰수록 위험이 커지는 일은 범위 안에 명시해 두는 편이 안전합니다.

하자보수와 유지보수 — 기간이 겹칠 때

하자보수는 구축 계약으로 납품한 결과물이 합의한 대로 동작하지 않을 때, 만든 쪽이 그 결함을 고치는 책임입니다. 민법 제667조도 도급 계약에서 완성된 목적물에 하자가 있으면 도급인이 수급인에게 상당한 기간을 정해 하자의 보수를 청구할 수 있다고 정합니다. 유지보수는 그와 별개로, 운영 중에 생기는 오류 대응과 업데이트와 변경을 맡는 계약입니다. 구축 계약이 도급에 해당하는지, 하자 대응의 기간과 범위가 어떻게 되는지는 먼저 그 구축 계약서에서 확인합니다. 하자보수와 유지보수가 무엇이 다른지는 전문가 Q&A — 하자보수와 유지보수 차이와 경계에 따로 정리해 두었습니다.

두 계약이 한 업체에 있으면 경계가 비교적 단순합니다. 경계가 실제로 어려워지는 것은 구축한 곳과 유지보수를 맡는 곳이 다를 때입니다. 하자 대응 기간이 남아 있는 동안 결함이 발견되면, 어디에 먼저 접수하고 누가 고칠지가 정해져 있어야 합니다. 유지보수 쪽이 먼저 수정하면 그 코드에 다른 변경이 더해져, 이후에 발견되는 문제가 원래의 결함인지 이후 변경의 결과인지 구분하기 어려워질 수 있습니다.

그래서 유지보수 계약서에는 다음을 적어 두시는 편이 좋습니다.

• 구축 계약의 하자 대응 기간이 언제까지인지
• 그 기간 중 결함으로 보이는 문제의 접수처와 수정 주체
• 유지보수가 책임을 지기 시작하는 날

구축 계약서와 유지보수 계약서를 나란히 놓고, 두 기간 사이에 빈 기간이나 겹치는 기간이 없는지를 보시면 됩니다.

데이터 정정 승인과 개인정보

데이터 정정은 프로그램 수정과 성격이 다릅니다. 잘못 입력된 주문, 중복으로 등록된 고객, 계산이 잘못된 정산 기록을 고치는 일은 기술 작업처럼 보이지만, 무엇이 맞는 값인지는 업무 담당자만 판단할 수 있습니다. 그래서 정정을 승인하는 주체는 고객사이고, 유지보수 쪽은 승인된 내용을 반영하고 기록을 남기는 역할을 맡습니다.

계약서에는 정정을 요청할 수 있는 사람과 승인하는 사람, 그리고 정정 전 백업과 전후 기록을 남긴다는 절차를 적습니다. 이 기록이 있어야 같은 데이터에 다시 문제가 생겼을 때 언제 누가 왜 바꿨는지를 확인할 수 있습니다.

유지보수 과정에서 개인정보가 담긴 데이터에 접근하게 된다면, 그 일이 개인정보 처리 업무의 위탁에 해당하는지를 함께 확인하셔야 합니다. 개인정보 보호법 제26조는 개인정보의 처리 업무를 위탁할 때 위탁업무 수행 목적 외 처리 금지와 기술적·관리적 보호조치에 관한 사항이 포함된 문서로 하도록 정하고, 같은 법 시행령 제28조는 여기에 위탁업무의 목적과 범위, 재위탁 제한, 접근 제한 등 안전성 확보 조치, 관리 현황 점검 등 감독, 의무 위반 시 손해배상 등 책임에 관한 사항을 더합니다. 수탁자가 위탁받은 업무를 다른 곳에 다시 맡기려면 위탁자의 동의를 받아야 한다는 규정도 같은 법 제26조에 있습니다.

위탁에 해당한다면 유지보수 계약서에 이 사항들이 들어 있는지, 들어 있지 않다면 별도의 문서가 있는지를 확인하실 수 있습니다. 위탁업무의 목적과 범위는 대상 시스템 목록과 같은 조항에서 정해지므로, 두 항목을 함께 적어 두시면 서로 어긋나지 않습니다.

서버와 프로그램의 담당이 다를 때 — 책임 경계

서버와 프로그램을 서로 다른 업체가 맡는 구성에서는, 각자의 영역에서는 문제가 보이지 않는데 서비스는 느린 경우처럼 원인이 경계에 있는 장애가 정리되기 어렵습니다. 화면이 느린 원인이 쿼리에 있는지 데이터베이스 서버의 자원에 있는지는 양쪽의 기록을 함께 봐야 확인되는데, 경계가 계약서에 없으면 각자 자기 영역을 확인한 데서 멈추게 됩니다.

빌드업웍스가 AWS 환경에서 서버(클라우드 관리)와 프로그램(소프트웨어 관리·개선)을 함께 맡을 때 적용하는 기본 역할 구분은 다음과 같습니다. 담당이 서로 다른 업체로 나뉘어 있어도 각 계약의 출발점으로 쓰실 수 있습니다.

이 표는 기본 구분이고, 실제 경계는 시스템마다 계약에서 문서로 정합니다. 담당이 둘로 나뉘어 있다면 이 영역 구분에 더해 다음 세 가지를 두 계약에 같은 말로 적어 두시는 편이 정확합니다.

• 원인이 분명하지 않은 장애를 어느 쪽이 먼저 접수하는지
• 원인을 규명하기 위해 서로 전달할 기록(로그 · 지표 · 최근 변경)
• 원인이 확인되면 누가 수정하는지

플랫폼 제공사의 장애는 제공사가 복구합니다. 다만 그동안 유지보수 쪽이 할 일 — 영향 범위 확인, 제공사 문의, 복구 뒤의 동작 점검 — 은 계약에 적어 두지 않으면 아무도 맡지 않은 일로 남을 수 있습니다.

종료 시 인계와 권한 회수

종료 조항은 계약을 맺는 시점에 적는 편이 좋습니다. 종료 시점에 처음 정하면 양쪽 모두 정리할 시간이 부족하고, 무엇을 넘기기로 했는지의 기준도 없습니다.

넘겨받을 것은 대개 운영하면서 만들거나 갱신한 문서, 변경 기록, 배포 절차, 그리고 유지보수 쪽에 부여했던 계정과 접근 권한의 목록입니다. 소스코드를 포함해 무엇을 넘겨받을 수 있는지는 계약이 정한 권리 범위를 따르므로, 넘겨받을 산출물의 목록과 형식, 인계 기간을 계약서에 미리 적어 두셔야 종료 시점에 해석이 갈리지 않습니다.

권한 회수는 인계와 같은 조항에 적습니다. 종료일에 유지보수 쪽의 계정, 접근 키, 원격 접속 경로를 회수하고, 회수했다는 사실을 양쪽이 확인하는 절차입니다. 이 절차가 없으면 계약이 끝난 뒤에도 외부에서 접근할 수 있는 경로가 남습니다.

넘겨받은 것으로 다음 팀이 실제로 이어받을 수 있는지는 이어받기에 필요한 여섯 가지 확인 항목으로 대조하실 수 있습니다.

빌드업웍스가 유지보수 범위를 정하는 방식

빌드업웍스는 운영 중인 소프트웨어를 이어받아 유지보수와 개선을 맡는 소프트웨어 관리·개선을 제공하며, 그 계약의 범위는 다음 방식으로 정합니다.

• 범위는 시스템을 확인한 뒤에 정합니다. 30분 무료 상담에서 들은 내용을 기준으로 이어받을 수 있는 상태인지와 먼저 확보할 것을 서면으로 정리해 드립니다. 코드와 환경을 직접 확인하는 일은 인수인계 · 안정화 단계(프로젝트 견적)에서 진행하며, 코드 · 빌드 · 배포 · 계정 · 백업과 복구 절차를 점검해 운영 문서와 위험 목록을 만듭니다. 월 운영 · 유지보수의 대상 시스템과 지원 범위는 그 결과를 놓고 계약에서 정합니다.
• 맡는 일과 별도로 정하는 일을 나란히 적습니다. 오류 접수 · 원인 분석 · 수정, 정기 업데이트와 의존성 점검, 배포 절차 정리와 변경 기록, 운영 문서 갱신, 우선순위에 따른 기능 추가 · 성능 개선을 맡습니다. 큰 기능 개발 · 구조 변경 · 단계적 전환은 별도 견적으로, 상용 패키지 내부 수정은 제조사 정책을 확인한 뒤 판단하며, 현장 출동 · 장비 교체 · 회선도 별도로 범위를 정하는 일입니다.
• 범위 밖 작업은 착수 전에 범위와 비용을 안내하고 승인을 받은 뒤 진행합니다.
• AWS 환경에서 클라우드 관리와 함께 맡기시면 단일 창구에서 접수하고, 경계에서 생긴 장애는 원인을 함께 확인한 뒤 작업 주체를 정합니다. 책임은 역할 구분 표와 같이 나눠 계약 문서에 적습니다.
• AWS가 아닌 환경도 대상입니다. Azure · GCP · 자체 서버 · 호스팅에서 운영 중인 소프트웨어도 환경과 접근 방법을 확인한 뒤 진행하며, AWS로 옮기는 것을 조건으로 하지 않습니다.

금액은 대상 시스템과 범위를 확인한 뒤 안내합니다. 확인 결과 지금 시스템을 유지하는 것이 적합하면 유지하고 필요한 부분만 개선하며, 다른 판단이 더 합리적이면 그 근거부터 설명드립니다. 판단은 근거와 함께 말씀드리고, 결정은 고객사가 내리십니다.

다음 단계

지금 계약서나 계약서 초안이 있다면, 계약서에 정할 항목마다 「적혀 있음 · 비어 있음 · 해석이 갈림」을 표시해 보시는 것이 첫 단계입니다. 비어 있거나 해석이 갈리는 칸이 곧 협의할 목록입니다.

계약 전에 지금 시스템이 이어받을 수 있는 상태인지부터 확인하고 싶으시면 이어받기 진단으로 연락처 없이 점검하실 수 있습니다. 빌드업웍스가 맡는 일과 별도로 정하는 일, 진행 순서는 소프트웨어 관리·개선에 정리돼 있습니다.

표시한 항목을 놓고 계약서를 함께 점검하고 싶으시면 상담 신청으로 연락 주십시오. 확인 결과 빌드업웍스가 맡는 것이 적절하지 않다면, 그 판단도 근거와 함께 말씀드립니다.

참고 자료

• 개인정보 보호법 (국가법령정보센터) — 제26조 업무위탁에 따른 개인정보의 처리 제한
• 개인정보 보호법 시행령 (국가법령정보센터) — 제28조 개인정보의 처리 업무 위탁 시 조치
• 민법 (국가법령정보센터) — 제667조 수급인의 담보책임