MES나 ERP를 도입하는 회사는 구축 계약만큼 유지보수 계약을 꼼꼼히 읽지 않습니다. 그런데 시스템을 쓰는 기간 대부분은 유지보수 계약 아래에서 지나갑니다. 유지보수 업체가 요청을 오류·개선·추가 개발로 나누고 그 분류를 고객이 먼저 골라 올리게 한다면, 발주처는 계약 전에 두 가지부터 확인해야 합니다. 분류를 누가 정하는지, 그리고 분류가 정해지기 전에도 첫 응답이 나가는지입니다.

제조 AI 운영체제 VEXPLOR를 만드는 웨이스는 시스템을 납품한 뒤 고객의 수정 요청을 받는 쪽에 있습니다. 웨이스는 요청이 늦어지는 단계가 고치는 단계보다 그 앞, 「이 요청이 무엇인가」를 두고 고객과 업체가 주고받는 단계인 경우가 많다고 봅니다. 이 글은 그 구분이 고객에게 어떤 부담을 넘기는지, 계약서에서 무엇을 확인하면 되는지를 판정 기준으로 정리한 것입니다.

유지보수 계약서는 요청을 3가지로 나누고 값을 다르게 매깁니다

흔히 보는 구조는 이렇습니다.

· 오류 — 납품한 기능이 약속대로 동작하지 않는 것입니다. 업체가 무상으로 고칩니다.

· 개선 — 지금 있는 기능을 조금 바꾸는 것입니다. 월 유지보수 범위 안에서 처리하되 한도를 두는 경우가 많습니다.

· 추가 개발 — 없던 기능을 새로 만드는 것입니다. 따로 견적을 받고 일정도 새로 잡습니다.

이 구분 자체가 잘못된 것은 아닙니다. 업체 쪽에서 보면 무상으로 고칠 일과 돈을 받고 할 일을 나눠야 계약을 유지할 수 있습니다. 발주처 쪽에서도 무엇에 돈을 내는지 알 수 있어야 예산을 잡습니다.

문제는 그 경계를 누가 판단하느냐입니다. 요청서 양식에 「요청 유형」 선택란이 있고 고객이 그 유형을 골라야 요청이 접수된다면, 그 선택란 하나가 고객에게 생각보다 많은 일을 넘깁니다.

요청 유형을 고객이 고르게 하는 계약은 고객에게 4가지 부담을 넘깁니다

· 판단 부담 — 오류인지 개선인지는 납품 당시 무엇을 약속했는지 알아야 판단할 수 있습니다. 그 약속이 적힌 사양서와 화면 정의서는 업체가 썼고, 현장 담당자는 대개 그 문서를 본 적이 없습니다. 판단에 필요한 정보는 업체에 있는데 판단은 고객이 하는 구조입니다.

· 협상 부담 — 고객이 오류로 올린 요청을 업체가 개선이나 추가 개발로 바꾸면 그때부터 대화가 시작됩니다. 「처음부터 이렇게 동작해야 하는 것 아니었나」와 「그건 사양에 없었다」가 몇 번 오가고, 그동안 요청은 아무도 손대지 않은 채 남습니다.

· 기다림 부담 — 분류가 정해져야 착수하는 계약이라면, 분류를 두고 오간 시간이 그대로 기다리는 시간이 됩니다. 고치는 데 한 시간이면 되는 일도 분류에 며칠이 걸리면 고객이 느끼는 처리 기간은 며칠입니다.

· 말하지 않게 되는 부담 — 가장 눈에 띄지 않는 부담입니다. 분류를 고민하고 협상하는 일이 몇 번 되풀이되면, 현장 담당자는 작은 불편을 올리지 않고 넘어갑니다. 요청 기록에는 남지 않지만 시스템이 현장과 조금씩 어긋나기 시작하는 것은 이때부터입니다.

넷 가운데 앞의 셋은 요청 하나하나의 비용이고, 마지막 하나는 시스템 전체의 비용입니다. 올라오지 않은 불편은 고칠 수 없고, 쌓이면 현장은 시스템 밖에서 엑셀과 메모로 일을 처리하기 시작합니다.

같은 요청이 보는 사람에 따라 오류도 되고 개선도 됩니다

현장에서 흔히 올라오는 요청 세 가지를 보겠습니다.

· 「품목 검색에 단종 품목이 섞여 나온다」 — 단종 품목을 빼는 조건이 처음 사양에 있었다면 오류이고, 없었다면 개선입니다.

· 「출하 지시서에 고객사 품번도 넣어 달라」 — 양식에 항목 하나를 더하는 수준이면 개선이고, 고객사 품번을 관리하는 기준 정보가 새로 필요하면 추가 개발입니다.

· 「월말 마감 화면이 너무 느리다」 — 데이터가 늘어서 느려진 것인지, 처음부터 그 양을 감당하도록 만들지 않은 것인지에 따라 답이 달라집니다.

세 요청 모두 현장 담당자는 「불편하니 고쳐 달라」는 같은 말을 하고 있습니다. 어느 유형에 넣을지는 사양서와 코드를 열어 봐야 알 수 있고, 그 문서와 코드를 가진 쪽은 업체입니다. 고객에게 유형을 고르라고 하는 것은 업체가 할 판단을 고객에게 미리 시키는 것과 같습니다.

발주처가 계약 전에 확인할 것은 6가지입니다

유지보수 계약서나 요청 절차서를 받으면 아래 표의 여섯 줄을 하나씩 대조해 봅니다. 「위험 신호」 쪽에 해당하는 줄이 많을수록 분류 부담이 고객에게 넘어와 있는 계약입니다.

· 분류는 누가 정하나 — 좋은 답: 업체가 정하고 근거를 적음 · 위험 신호: 고객이 요청 유형을 고름

· 분류 기준 문서 — 좋은 답: 납품 사양서를 고객도 보관 · 위험 신호: 기준 문서를 받은 적 없음

· 첫 응답 시점 — 좋은 답: 접수 시각부터 계산 · 위험 신호: 분류 확정 뒤부터 계산

· 분류 변경 기록 — 좋은 답: 바꾼 사유가 요청에 남음 · 위험 신호: 전화로 바꾸고 기록 없음

· 추가 개발 견적 — 좋은 답: 공수 산정 기준이 계약에 있음 · 위험 신호: 건마다 따로 협의

· 요청 기록 소유 — 좋은 답: 고객이 언제든 내려받음 · 위험 신호: 업체 시스템에만 있음

표의 각 줄을 계약서에서 확인하는 방법은 이렇습니다.

· 분류는 누가 정하나 — 요청 절차에 「업체는 요청 내용을 검토해 유형을 정하고 그 근거를 요청 기록에 남긴다」 같은 문장이 있는지 봅니다. 고객은 겪은 일을 문장으로 적기만 하면 되는 절차가 맞습니다.

· 분류 기준 문서 — 오류의 기준은 납품 당시 사양입니다. 사양서와 화면 정의서를 검수 때 넘겨받아 발주처도 보관하고 있어야, 분류가 갈릴 때 같은 문서를 펴 놓고 이야기할 수 있습니다.

· 첫 응답 시점 — 응답 기준 시간이 「접수 후 몇 시간」인지 「유형 확정 후 몇 시간」인지 확인합니다. 뒤의 경우라면 분류 협의가 아무리 길어져도 계약상으로는 늦은 것이 아닙니다.

· 분류 변경 기록 — 업체가 유형을 바꿀 수는 있습니다. 다만 바꾼 이유가 요청 기록에 글로 남아야 다음 갱신 때 「어떤 요청이 왜 추가 개발이 됐는지」를 되짚어 볼 수 있습니다.

· 추가 개발 견적 — 추가 개발로 분류되는 순간 견적 협의가 새로 시작된다면, 분류 다툼의 크기는 곧 금액 다툼의 크기입니다. 공수를 어떤 기준으로 산정하는지가 계약에 미리 있어야 합니다.

· 요청 기록 소유 — 요청과 응답 기록은 업체를 평가하는 유일한 근거입니다. 계약이 끝나도 발주처가 그 기록을 내려받을 수 있는지 확인합니다.

지금 쓰는 시스템은 요청 기록 3가지로 먼저 점검해 볼 수 있습니다

계약 갱신을 앞두고 있다면, 지금의 요청 기록으로 분류 부담이 얼마나 넘어와 있는지 먼저 확인해 볼 수 있습니다.

1. 유형이 바뀐 요청 — 최근 석 달 요청 가운데 고객이 고른 유형을 업체가 바꾼 건이 있는지, 있다면 바꾼 이유가 기록에 남아 있는지 봅니다.

2. 분류를 두고 오간 메시지 — 요청을 올린 때부터 업체가 「이렇게 처리하겠다」고 처음 답한 때까지, 유형을 두고 메시지가 몇 번 오갔는지 확인합니다.

3. 올리지 않은 불편 — 현장 담당자에게 「시스템이 불편한데 요청하지 않고 넘어간 일이 있는가」를 직접 물어봅니다.

1번과 2번에서 분류 협의가 보이고 3번에서 넘어간 불편이 나온다면, 지금 계약은 분류 부담을 고객에게 넘기고 있는 것입니다. 이 세 가지 기록은 갱신 협상 때 위 6가지를 계약 문구로 넣어 달라고 요구할 근거가 됩니다.

요청 분류는 업체가 맡고, 고객은 불편한 점만 적으면 되는 계약이 맞습니다

업체가 분류를 맡으면 업체의 일이 늘어납니다. 요청을 하나하나 읽고 사양서와 대조해야 하기 때문입니다. 업체가 그 일을 요청서 양식의 선택란 하나로 고객에게 넘겨 온 이유도 여기에 있습니다.

그런데 요청 문장을 읽고 유형과 처리 기준 시간을 정하는 일은 이제 사람이 하나하나 하지 않아도 됩니다. AI가 요청을 읽고 먼저 분류하고, 사람은 그 분류가 틀린 건만 고치면 됩니다. 분류 비용이 줄어들면 업체가 분류를 고객에게 넘길 이유도 줄어듭니다.

웨이스는 VEXPLOR 고객의 요청을 이렇게 받습니다. 고객은 요청 유형을 고르지 않고 겪은 일을 문장으로 적고, 분류와 처리 기준 시간은 AI가 정합니다. 그렇게 운영한 90일 기록은 다음 글에 따로 정리했습니다.

발주처가 유지보수 계약서에서 지킬 원칙은 하나입니다. 무엇이 불편한지 말하는 것은 고객의 일이고, 그것이 오류인지 개선인지 정하는 것은 업체의 일입니다.

함께 읽어보세요

· 웨이스가 고객의 시스템 수정 요청을 AI에게 맡긴 90일 기록: https://blog.vexplor.com/post/ai-handles-maintenance-requests-90-days?utm_source=eo&utm_medium=social&utm_campaign=2026-11-11

· "AI가 유지보수까지 해 드립니다"라는 업체, 계약 전에 무엇을 확인해야 할까요: https://blog.vexplor.com/post/ai-maintenance-vendor-checklist?utm_source=eo&utm_medium=social&utm_campaign=2026-11-11

(이 글은 웨이스 기술블로그에 먼저 실린 글입니다. 원문: https://blog.vexplor.com/post/maintenance-request-classification-burden?utm_source=eo&utm_medium=social&utm_campaign=2026-11-11)