생산관리시스템을 유지보수 계약 없이 쓰는 상태의 위험은 평소에는 거의 드러나지 않습니다. 시스템이 도는 동안에는 계약이 있는 공장과 없는 공장이 똑같이 보입니다. 차이는 멈춘 뒤에 나타나는데, 계약이 없으면 접수·견적·승인·접속 준비가 모두 생산이 멈춘 시간 안으로 들어옵니다. 아래에 멈춘 뒤 시간대별로 실제로 벌어지는 일과, 지금 확인해 두면 그 시간을 줄일 수 있는 항목을 표로 정리했습니다.
멈춘 뒤에야 계산되는 비용이 있습니다
유지보수 미체결은 비용을 아끼는 선택처럼 보이지만, 정확히 말하면 비용을 지금 내지 않고 장애가 난 날로 미루는 선택입니다. 미뤄진 쪽에는 업체 작업비만 있는 것이 아니라 생산이 서 있는 시간, 그 시간 동안 수기로 받아 둔 기록, 복구 후 그 기록을 다시 입력하는 일이 함께 들어 있습니다.
여기서 많이 놓치는 것이 순서입니다. 계약이 있는 곳은 멈춘 순간 바로 조치 단계로 들어가지만, 계약이 없으면 조치 앞에 협의 단계가 붙습니다. 누구에게 알릴지 정하고, 봐줄 수 있는지 묻고, 범위와 금액을 협의하고, 내부 승인을 받는 네 단계입니다. 이 네 단계는 기술적으로 어려운 일이 아니지만 사람과 결재가 끼기 때문에 가장 느립니다.
판단 기준은 금액이 아니라 멈췄을 때 몇 시간을 버틸 수 있는지입니다. 설비 연동이 없고 조회 중심으로만 쓰며 수기로 대체가 되는 상태라면 건당 요청 방식도 쓰입니다. 반대로 생산 지시와 실적이 시스템을 거쳐야 돌아가는 상태라면, 버틸 수 있는 시간보다 협의 단계가 길어질 가능성을 먼저 보시는 편이 좋습니다.
멈춘 뒤 시간이 어떻게 흐르는가
아래 표는 계약 없이 쓰던 시스템이 멈춘 뒤의 흐름을 시점별로 적은 것입니다. 각 줄의 '막히는 지점'은 기술 문제가 아니라 대부분 절차와 자료 문제입니다.
| 시점 | 미체결 상태에서 하는 일 | 여기서 막히는 지점 | 계약이 있을 때 달라지는 부분 |
|---|---|---|---|
| 멈춘 직후 | 아는 담당자를 찾아 전화·메신저로 연락을 돌린다 | 받는 창구가 정해져 있지 않아 누구에게 알릴지부터 정해야 한다 | 접수 창구가 하나로 정해져 있어 알리는 데 시간이 들지 않는다 |
| 연락이 닿은 뒤 | 증상을 설명하고 봐줄 수 있는지 묻는다 | 계약 건의 접수가 먼저 처리되는 경우가 일반적이라 순서를 기다리게 된다 | 약속된 응답 시간 안에서 순서가 잡힌다 |
| 반나절 안 | 작업 범위와 금액을 협의한다 | 생산이 서 있는 상태에서 범위를 정하게 되어 판단이 급해진다 | 범위가 이미 정해져 있어 협의 단계가 없다 |
| 그날 안 | 내부 승인을 받고 발주한다 | 결재 경로가 생산 중단 시간 안으로 들어온다 | 계약 안의 일로 처리되어 승인 절차가 끼지 않는다 |
| 접속 준비 | 원격 접속 계정과 서버 정보를 찾는다 | 전임자가 만든 계정만 남아 비밀번호를 아는 사람이 없는 경우가 많다 | 평소 점검으로 접속 경로가 살아 있는 상태다 |
| 원인 파악 | 업체가 시스템 구조를 처음부터 읽는다 | 소스와 설정 문서가 없으면 읽는 시간이 그대로 중단 시간이 된다 | 이력을 아는 쪽이 보기 때문에 파악 시간이 짧다 |
| 복구 뒤 | 멈춘 동안의 실적을 수기 기록에서 다시 입력한다 | 받아 둔 종이와 사람 기억으로 기록을 되살려야 한다 | 중단 시간이 짧아 되살릴 기록이 적다 |
표를 보면 실제 수리에 쓰이는 시간보다 그 앞에 붙은 시간이 더 긴 경우가 많습니다. 미체결 위험을 줄이는 일은 결국 이 앞 단계를 미리 치워 두는 일입니다.
복구 속도를 정하는 것은 계약서보다 자료 상태입니다
계약을 바로 맺기 어려운 사정이 있을 수 있습니다. 그렇다면 계약과 별개로 자료 상태만이라도 지금 확인해 두는 것이 다음으로 할 수 있는 일입니다. 아래 일곱 가지는 계약 여부와 무관하게 복구 시간을 직접 좌우하는 항목들입니다.
| 늦추는 조건 | 왜 시간이 더 걸리나 | 지금 확인해 두는 방법 | 확인이 안 될 때 남는 상태 |
|---|---|---|---|
| 서버·DB 관리 계정 소재 | 계정이 없으면 조치 자체를 시작할 수 없다 | 관리 계정을 누가 들고 있는지 이름으로 적어 둔다 | 장애가 나면 계정 찾기부터 시작한다 |
| 프로그램 원본 보관 위치 | 실행 파일만 있으면 손댈 수 없는 범위가 생긴다 | 소스와 설정 자료를 우리가 받아 둔 것이 있는지 본다 | 구축한 곳 외에는 고칠 수 없는 상태가 된다 |
| 백업 복구 시험 이력 | 백업이 도는 것과 되살아나는 것은 다른 확인이다 | 실제로 되살려 본 날짜가 남아 있는지 본다 | 백업을 믿고 있다가 복구 단계에서 막힌다 |
| 구축 담당 엔지니어 연락 가능 여부 | 아는 사람이 없으면 구조를 다시 읽어야 한다 | 당시 담당자와 지금도 연락이 닿는지 확인한다 | 업체는 남아 있어도 파악 시간이 새로 든다 |
| 서버 OS·DB 지원 상태 | 지원이 끝난 환경은 선택할 수 있는 조치가 좁다 | 운영체제와 DB 버전, 지원 종료 시점을 적어 둔다 | 복구가 아니라 이전 논의로 넘어간다 |
| 라이선스·인증 키 보관 | 재설치 단계에서 키가 없으면 그 자리에서 멈춘다 | 라이선스 문서와 키 보관 위치를 한곳에 모아 둔다 | 설치는 되는데 실행이 되지 않는다 |
| 과거 요청 이력 기록 | 같은 증상을 전에 겪었는지 모르면 처음부터 본다 | 메일·통화로 요청했던 일을 목록으로 남긴다 | 이미 한 번 해결한 장애를 다시 처음부터 본다 |
이 표의 항목은 새로 만드는 문서가 아니라 이미 어딘가에 있는 것을 한 장에 모으는 일입니다. 대부분 한두 시간 안에 절반 이상이 채워지고, 채워지지 않는 칸이 지금 가장 큰 위험 지점입니다.
지금 계약 없이 쓰고 있다면
먼저 위 표의 일곱 칸을 채워 보시는 순서를 권합니다. 비어 있는 칸이 두 개 이하라면 건당 요청 방식으로도 버틸 여지가 있고, 절반 이상이 비어 있다면 금액보다 대응 시간을 약속받는 쪽을 먼저 보는 편이 안전합니다.
계약을 검토하실 때도 금액부터 묻는 대신 접수 창구, 대응 시간대, 연동 설비 포함 여부, 종료 시 넘겨받을 산출물을 문장으로 적어 보내시면 비교가 됩니다. 우리 공장이 몇 시간을 버틸 수 있는지는 가동 시간대와 설비 연동 상태에 따라 달라지므로, 현재 구성을 함께 보고 판단해 드리는 편이 정확합니다.
FAQ
자주 묻는 질문
- 생산관리시스템을 몇 년째 문제 없이 쓰고 있습니다. 유지보수 계약이 꼭 필요한가요?
- 문제가 없던 기간은 계약이 필요한지에 대한 답이 되기 어렵습니다. 유지보수가 값을 하는 지점은 평상시가 아니라 멈춘 뒤의 몇 시간에 몰려 있기 때문입니다. 판단은 '지금까지 괜찮았는지'가 아니라 '지금 멈추면 몇 시간을 버틸 수 있는지'로 하시는 편이 정확합니다. 생산 지시와 실적 등록이 시스템을 거쳐야 돌아가고 설비에서 데이터를 받아오는 구간이 있다면, 멈춘 상태에서 업체를 찾고 범위를 협의하는 시간이 버틸 수 있는 시간을 넘길 가능성이 있습니다. 반대로 조회 중심으로만 쓰고 수기 대체가 가능하다면 건당 요청 방식도 쓰이는 방식입니다. 실제 판단은 가동 시간대와 연동 상태를 함께 봐야 확인됩니다.
- 계약이 없으면 장애가 났을 때 업체가 안 봐주는 건가요?
- 봐주지 않는다기보다 순서가 뒤로 가는 경우가 일반적입니다. 업체는 보통 계약된 곳의 접수를 먼저 처리하도록 인력을 배치해 두기 때문에, 계약이 없는 요청은 일정이 비는 시점을 기다리게 됩니다. 여기에 더해 계약 건에는 없는 단계가 앞에 붙습니다. 증상을 설명하고 봐줄 수 있는지 묻고, 작업 범위와 금액을 협의하고, 내부 승인을 받는 과정입니다. 기술적으로 어려운 일은 아니지만 사람과 결재가 끼기 때문에 가장 느린 구간이 됩니다. 생산이 서 있는 상태에서 이 협의를 하게 된다는 점이 미체결 상태의 실제 부담입니다.
- 구축한 업체와 연락이 잘 안 됩니다. 이 상태로 두면 어떤 문제가 생기나요?
- 가장 먼저 확인하실 것은 업체 연락처가 아니라 우리가 들고 있는 자료입니다. 서버와 DB 관리 계정, 프로그램 원본과 설정 자료, 라이선스 키, 시스템 구성 기록 네 가지가 우리 손에 있으면 다른 업체도 검토 대상이 됩니다. 반대로 이 중 상당 부분이 구축한 곳에만 있으면 연락이 닿을 때까지 선택지가 사실상 하나로 좁혀집니다. 그래서 지금 할 수 있는 일은 계약 상대를 찾는 것보다 넘겨받아 둔 산출물이 무엇인지 목록으로 적어 보는 쪽입니다. 비어 있는 항목이 그대로 다음 장애에서 멈추는 지점이 됩니다.
- 시스템이 멈추면 수기로 받아 두면 되지 않나요?
- 짧은 중단이라면 그 방법이 쓰입니다. 다만 수기 대체가 버티는 시간에는 한계가 있고, 그 한계는 중단 시간이 아니라 복구 뒤에 드러납니다. 멈춰 있던 동안의 생산 지시와 실적을 나중에 시스템에 다시 입력해야 하는데, 종이와 사람 기억에 남은 내용으로 되살리는 과정에서 누락과 불일치가 생기기 쉽습니다. 특히 로트 추적이나 투입 자재 기록처럼 순서와 시각이 의미를 갖는 자료는 사후 입력으로 정확히 복원하기 어려운 편입니다. 그래서 수기 대체는 몇 시간 단위의 대책으로 보고, 며칠이 걸릴 수 있는 상황까지 그것으로 막는다고 두지 않는 편이 안전합니다.
- 지금 계약 없이 쓰고 있는데, 당장 계약이 어렵다면 무엇부터 하면 되나요?
- 계약과 별개로 복구 시간을 줄이는 일은 오늘 시작할 수 있습니다. 순서는 네 가지입니다. 첫째, 서버와 DB 관리 계정을 누가 들고 있고 지금 접속이 되는지 확인합니다. 둘째, 프로그램 원본과 설정 자료, 라이선스 키의 보관 위치를 한곳에 모읍니다. 셋째, 백업이 돌고 있는지만 보지 않고 최근에 실제로 되살려 본 기록이 있는지 확인합니다. 넷째, 그동안 업체에 요청했던 일들을 메일과 통화 기록에서 목록으로 뽑습니다. 네 번째는 다음에 계약을 검토할 때 필요한 범위가 그대로 드러나는 자료이기도 합니다. 여기서 채워지지 않는 칸이 지금 가장 먼저 다룰 위험 지점입니다.
근거·참고
제도와 기준의 원본
- 스마트공장 사업관리시스템
정부 스마트공장 보급사업의 공고·신청·공급기업 목록이 있는 곳. 지원금 조건을 여기서 확인합니다.
- 한국생산기술연구원
제조 공정 기술을 연구하는 정부출연 기관. 금형·가공·자동화 분야의 기술 자료가 공개돼 있습니다.
현장에 맞는 답이 필요하시면
이 글은 일반적인 기준을 정리한 것입니다. 공정과 설비를 직접 보고 해당 현장의 조건에 맞춰 범위를 잡아 드립니다.
MORE
함께 보면 좋은 글
- 조선기자재 생산관리시스템 구축 비용, 호선·블록 범위가 기준입니다
조선기자재 생산관리시스템 구축 비용은 사용자 수보다 호선·블록·품목의 연결 깊이와 자재·외주·검사 기록의 연동 범위에서 달라집니다. 거제·통영 생산관리 진단 경험을 바탕으로 견적 전에 정할 관리 단위와 구축 기준을 정리했습니다.
- MES 도입 전에 먼저 정리해야 할 현장 데이터는 설비 목록과 코드 체계입니다
MES 도입 전에 정리할 현장 데이터는 설비 목록, 공정 단위, 코드 체계, 작업지시와 실적 양식입니다. 무엇을 어느 수준까지 정리해야 하는지와 정리 없이 시작했을 때 생기는 일을 함께 정리했습니다.
- MES 유지보수 비용 견적, 받기 전에 범위를 먼저 적어야 비교가 됩니다
MES 유지보수 비용 견적은 금액을 묻기 전에 범위를 문장으로 적어야 비교가 됩니다. 같은 연간 계약이라도 포함 범위가 달라 낮은 금액이 추가 청구로 돌아오는 일이 많습니다. 견적 요청서에 적어 둘 항목을 표로 정리했습니다.