지원사업이 끝나고 유지보수비가 자부담으로 넘어왔을 때 부담을 줄이는 출발점은 총액을 깎는 협의가 아니라 넘어온 항목을 하나씩 떼어내 계속·축소·내부전환·중단으로 나누는 일입니다. 한 덩어리로 보면 전부 필요해 보이지만, 나눠 보면 지난 1년간 한 번도 쓰지 않은 항목이 섞여 있는 경우가 적지 않습니다. 아래에 자부담으로 넘어오는 항목을 나누는 기준과, 종료 시점에서 역산한 준비 순서를 표로 정리했습니다.
지원 기간에 가려져 있던 항목이 한꺼번에 드러납니다
구축할 때는 소프트웨어 사용권, 서버나 클라우드 사용료, 설비 데이터 수집 구간 유지, 정기 점검, 일정 시간의 변경 작업이 한 묶음으로 계약에 들어가 있는 경우가 많습니다. 사업 기간에는 이것들이 각각 얼마만큼의 일인지 현장에서 체감되지 않습니다. 지원이 끝나는 순간 그 묶음이 그대로 자부담 청구서가 되어 돌아오는데, 받는 쪽에서는 항목별로 무엇을 쓰고 있는지 구분된 자료가 없는 상태로 전체 금액만 보게 됩니다. 그래서 협의가 "조금 깎아 주십시오"에서 더 나아가지 못합니다.
먼저 확인하실 것은 협약서와 사업 공고입니다. 사업과 연도에 따라 성과 확인 기간, 자료 제출 의무, 일정 기간의 시스템 유지 조건이 붙어 있을 수 있습니다. 이 조건은 사업마다 다르므로 일반적인 설명을 그대로 적용해 판단하지 말고 우리 협약 문서에서 직접 확인하셔야 합니다. 유지 의무가 걸린 항목을 모르고 줄이면 비용보다 큰 문제가 됩니다.
넘어온 항목을 네 갈래로 나눕니다
| 넘어온 항목 | 무엇을 보고 판단하나 | 나누는 갈래 |
|---|---|---|
| 소프트웨어 사용권 | 최근 3개월 실제 접속한 사용자와 미접속 계정을 센다 | 실사용 인원 기준으로 축소 |
| 서버·클라우드 사용료 | 보존해야 하는 기간과 실제 조회 빈도를 본다 | 오래된 자료를 분리 보관해 축소 |
| 설비 데이터 수집 구간 유지 | 멈췄을 때 생산·기록에 바로 영향이 있는지 본다 | 영향이 즉시 나타나면 계속 |
| 정기 점검 방문 | 지난 1년 점검에서 실제로 발견된 것이 있었는지 본다 | 원격 확인과 나눠 축소 |
| 화면·집계·출력 양식 변경 | 요청이 설정 화면에서 끝나는 일인지 구분한다 | 설정 범위는 내부전환 |
| 기준정보 등록·사용자 추가 | 절차서와 권한만 있으면 사내에서 되는지 본다 | 내부전환 |
| 거래처 자료 전송 경로 | 지금도 그 경로로 주고받는 거래처가 있는지 확인한다 | 쓰지 않으면 중단 |
| 구축만 되고 쓰지 않는 모듈 | 최근 접속·입력 기록이 남아 있는지 확인한다 | 기록이 없으면 자료만 남기고 중단 |
| 백업 주기와 복구 확인 | 복구를 실제로 해 본 기록이 있는지 본다 | 줄이지 않고 계속 |
네 갈래로 나누는 작업의 효과는 금액이 아니라 협의의 성격이 바뀌는 것에서 먼저 나타납니다. "전체를 낮춰 달라"가 아니라 "사용자 수는 실사용 기준으로, 방문 점검은 분기로, 설정 변경은 우리가 처리하겠다"가 되면 업체도 무엇이 빠지는지 알고 답할 수 있습니다. 양쪽이 같은 표를 보고 이야기하므로 다음 해 갱신에서도 같은 논의를 처음부터 다시 하지 않습니다.
줄이기 전에 남겨야 하는 항목이 있습니다
부담이 급할 때 가장 먼저 빠지는 것은 평소에 체감되지 않는 항목입니다. 백업 복구 확인, 설비 연동 구간 유지, 자료 보관이 그렇습니다. 문제가 없는 달에는 아무것도 달라지지 않기 때문에 지워도 괜찮아 보이지만, 결과는 설비가 멈춘 날이나 자료가 필요한 날에 한꺼번에 나타납니다. 특히 복구는 해 본 적이 있는지가 전부입니다. 백업이 돌고 있다는 사실만 있고 복구를 한 번도 시험하지 않았다면, 그 항목은 줄일 후보가 아니라 지금 확인할 후보입니다.
또 하나는 계약 종료 시 자료 이관 조건입니다. 설정값과 데이터를 어떤 형식으로 받을 수 있는지가 문서에 없으면, 나중에 업체를 바꾸는 선택 자체가 비용 판단에 들어옵니다. 자부담으로 넘어온 시점이 이 조건을 넣기에 오히려 적당한 때입니다.
종료 시점에서 역산해 준비합니다
| 시점 | 할 일 | 이때 하지 않으면 생기는 일 |
|---|---|---|
| 종료 6개월 전 | 협약서에서 유지 의무·성과 확인 기간을 확인한다 | 줄여도 되는 항목과 안 되는 항목을 구분하지 못합니다 |
| 종료 5개월 전 | 모듈별 접속·입력 기록을 뽑아 사용 현황을 센다 | 쓰지 않는 모듈이 그대로 자부담에 포함됩니다 |
| 종료 4개월 전 | 지난 1년 장애·변경 요청 이력을 날짜순으로 모은다 | 협의에 가져갈 근거가 없어 금액 이야기만 남습니다 |
| 종료 3개월 전 | 항목을 네 갈래로 나눈 표를 만들어 업체와 맞춰 본다 | 종료 직전에 급하게 전체 계약을 그대로 이어가게 됩니다 |
| 종료 2개월 전 | 내부전환할 작업의 절차서와 권한을 정한다 | 사내 처리로 돌리기로 한 일이 다시 요청으로 돌아갑니다 |
| 종료 1개월 전 | 복구 시험을 한 번 하고 결과를 기록으로 남긴다 | 축소한 뒤 처음 문제가 생긴 날 확인이 시작됩니다 |
| 종료 직후 | 줄인 항목과 남긴 항목을 한 장으로 정리해 공유한다 | 담당자가 바뀌면 왜 그렇게 정했는지가 사라집니다 |
| 종료 후 3개월 | 접수 건수와 멈춘 횟수를 다시 세어 조정폭을 점검한다 | 과하게 줄인 구간을 늦게 발견합니다 |
다음 단계
먼저 하실 일은 두 가지입니다. 협약서에서 유지 조건을 확인하는 것, 그리고 모듈별 접속 기록과 지난 1년 요청 이력을 뽑아 두는 것입니다. 이 두 자료만 있으면 위 표의 갈래 나누기는 대부분 하루 안에 끝납니다. 자료를 어디서 뽑는지, 어떤 항목이 우리 공정에서 계속 남아야 하는지는 설비 구성에 따라 달라지므로 현장 진단 단계에서 함께 확인해 산출해 드립니다.
FAQ
자주 묻는 질문
- 지원사업이 끝나면 유지보수 계약을 반드시 이어가야 합니까?
- 먼저 협약 문서를 확인하셔야 합니다. 사업과 연도에 따라 성과 확인 기간이나 일정 기간의 시스템 유지 조건이 붙는 경우가 있고, 그 조건은 사업마다 다르므로 일반적인 설명으로 단정하기 어렵습니다. 협약상 의무가 없다면 계약 여부는 선택입니다. 판단 기준은 멈췄을 때 감당할 수 있는 시간입니다. 설비에서 자료를 자동으로 받는 구간이 있고 그 기록이 출하나 품질 확인에 쓰이고 있다면, 멈춘 뒤에 사람을 찾는 방식은 위험이 큽니다. 반대로 사용 범위가 좁고 설비 연동이 없으며 지난 1년간 요청 건수가 거의 없었다면 건별 대응이 맞을 수 있습니다. 결정 전에 모듈별 접속 기록과 지난 1년 요청 이력을 먼저 뽑아 보시기를 권합니다.
- 유지보수를 중단하면 시스템을 계속 쓸 수 없게 됩니까?
- 계약 형태에 따라 다르므로 계약서의 사용권 조항을 보셔야 합니다. 사용권을 구매한 형태라면 유지보수를 중단해도 쓰던 기능은 그대로 쓰고 오류 대응과 업데이트만 멈추는 경우가 있습니다. 반면 기간제로 사용료를 내는 형태나 업체 서버에서 돌아가는 방식이라면 중단이 곧 사용 중지로 이어질 수 있습니다. 확인하실 항목은 세 가지입니다. 사용권이 기간제인지 영구인지, 시스템이 우리 서버에 있는지 업체 서버에 있는지, 종료 시 설정값과 데이터를 어떤 형식으로 받을 수 있는지입니다. 이 셋이 문서에 적혀 있지 않으면 중단을 검토하기 전에 먼저 서면으로 확인해 두는 편이 안전합니다.
- 자부담이 어려워 최소로 줄여야 합니다. 무엇부터 빼고 무엇을 남깁니까?
- 먼저 빼기 좋은 것은 사용 기록으로 근거를 댈 수 있는 항목입니다. 접속 기록이 없는 모듈, 지금은 쓰지 않는 거래처 전송 경로, 쓰지 않는 계정, 실제로 발견 사항이 없었던 방문 점검 횟수가 그렇습니다. 반대로 남겨야 하는 것은 평소에 체감되지 않는 항목입니다. 백업과 복구 확인, 설비 데이터 수집 구간 유지, 자료 보관은 문제가 없는 달에는 지워도 차이가 없어 보이지만 멈춘 날에 결과가 한꺼번에 나타납니다. 응답·복구 기준 시간도 숫자를 아예 없애기보다 생산 중단 상황만 따로 남기는 방식이 현실적입니다. 줄인 뒤에는 무엇이 빠졌는지 한 장으로 적어 두십시오. 담당자가 바뀌면 이유가 가장 먼저 사라집니다.
- 지원 종료 후 업체를 바꾸면 유지보수 부담이 줄어듭니까?
- 줄어드는 경우도 있지만 교체 자체가 비용을 만드는 구간이 있어 함께 계산하셔야 합니다. 새 업체는 우리 설정과 데이터 구조를 처음부터 파악해야 하고, 그 기간에는 요청 처리가 느려집니다. 설비 연동 구간이 있으면 통신 설정과 수집 서버를 다시 확인하는 일이 추가됩니다. 그래서 교체를 검토하실 때는 제안 금액만 비교하지 말고 자료 이관 조건, 인수 기간에 누가 대응하는지, 기존 설정을 어디까지 그대로 쓸 수 있는지를 같은 표에 적어 비교하십시오. 교체가 아니라 범위 조정만으로 목표에 닿는 경우도 적지 않습니다. 네 갈래로 나눈 표를 먼저 만들어 현재 업체와 맞춰 본 다음 판단하시는 순서를 권합니다.
- 사내 인력으로 일부를 가져오려면 어디까지 나눌 수 있습니까?
- 설정 화면에서 끝나는 작업은 대체로 가져올 수 있습니다. 사용자 추가와 권한 변경, 기준정보 등록, 조회 조건과 출력 양식의 간단한 수정이 그렇습니다. 이 구간은 권한과 절차서를 정리하면 요청 건수가 눈에 띄게 줄어듭니다. 반면 데이터 구조, 집계 규칙, 설비 통신 구간은 잘못 손대면 지난 자료까지 영향을 받으므로 나누기 전에 책임 경계를 문서로 정해 두어야 합니다. 함께 보실 것은 내부 시간도 비용이라는 점입니다. 담당자가 요청을 작성하고 확인하는 데 쓴 시간을 한 달만 적어 보시면 내부로 가져오는 편이 실제로 가벼운지 판단이 됩니다. 나눌 구간이 정해지면 계약에서 그만큼을 덜어내는 협의도 가능합니다.
근거·참고
제도와 기준의 원본
- 스마트공장 사업관리시스템
정부 스마트공장 보급사업의 공고·신청·공급기업 목록이 있는 곳. 지원금 조건을 여기서 확인합니다.
- 중소벤처기업부
스마트공장 보급사업의 주관 부처. 연도별 사업 방향과 예산이 공고됩니다.
- 중소기업 기술개발사업 종합관리시스템
기술개발 과제 공고와 신청 창구. 설비·시스템 도입을 과제로 묶을 때 확인합니다.
현장에 맞는 답이 필요하시면
이 글은 일반적인 기준을 정리한 것입니다. 공정과 설비를 직접 보고 해당 현장의 조건에 맞춰 범위를 잡아 드립니다.
MORE
함께 보면 좋은 글
- 조선기자재 생산관리시스템 구축 비용, 호선·블록 범위가 기준입니다
조선기자재 생산관리시스템 구축 비용은 사용자 수보다 호선·블록·품목의 연결 깊이와 자재·외주·검사 기록의 연동 범위에서 달라집니다. 거제·통영 생산관리 진단 경험을 바탕으로 견적 전에 정할 관리 단위와 구축 기준을 정리했습니다.
- MES 도입 전에 먼저 정리해야 할 현장 데이터는 설비 목록과 코드 체계입니다
MES 도입 전에 정리할 현장 데이터는 설비 목록, 공정 단위, 코드 체계, 작업지시와 실적 양식입니다. 무엇을 어느 수준까지 정리해야 하는지와 정리 없이 시작했을 때 생기는 일을 함께 정리했습니다.
- 생산관리시스템 유지보수비 적정 기준은 금액보다 계약에 적힌 범위로 판단합니다
생산관리시스템 유지보수비가 적정한지는 금액 자체보다 계약이 무엇을 범위로 하는지와 지난 1년 요청 이력에서 갈립니다. 계약서에서 확인할 항목과 우리 공장 기준을 직접 만드는 순서를 표로 정리했습니다.