제조 디지털화 프로젝트의 범위는 어떻게 정하는가: 6단계 구축 모델과 단계별 산출물

기술 선정보다 범위 정의가 성패를 가르는 이유

검토 기간의 대부분은 기술 비교에 쓰입니다. 어떤 SCADA인지, MES가 필요한지, 데이터베이스는 무엇인지, 기존 설비와 통신이 되는지. 반도체든 디스플레이든 논의 순서는 비슷합니다. 이 비교는 의미가 있지만 프로젝트가 실패하는 이유가 되는 경우는 드뭅니다. 실패하는 프로젝트는 1차 범위가 어디서 끝나는지 적어 둔 문서가 하나도 없는 경우입니다.

범위는 제안서의 한 단락이 아니라 구체적인 답의 집합입니다. 어느 라인인지, 어느 공정인지, 어떤 데이터 항목을 수집하는지, 어떤 리포트를 내는지, 무엇을 충족하면 완료로 보는지. 이 답이 없으면 공수는 개략치에 머물고, 이후 변경도 비교할 기준을 갖지 못합니다.

• 회의마다 공정과 리포트가 늘어나는데, 대신 무엇을 빼기로 했는지 기록한 문서가 없음
• 기준선 측정보다 먼저 개선 목표가 정해져, 사후에 양측 모두 달성 여부를 입증할 수 없음
• 계약서에 '연동'이라는 단어만 있고, 상대 시스템 이름과 데이터 흐름 방향, 기준정보 관리 주체가 적혀 있지 않음
• 화면 세부는 상세히 논의되는데, 각 데이터 항목의 수집 주소는 아직 배정되지 않음
• 검수 조건이 '시스템이 정상 가동될 것'으로 끝나고, 측정 가능한 조건이 붙어 있지 않음

이 다섯 가지는 모두 코드 한 줄을 쓰기 전에 나타납니다. 그래서 그 시점이라면 아직 저렴하게 바로잡을 수 있습니다.

여섯 단계가 각각 무엇을 내고 무엇을 내지 않는가

아래 모델은 디지털화 프로젝트를 여섯 단계로 나눕니다. 단계에 이름을 붙이는 목적은 절차의 형식이 아니라, 각 단계에 종료 조건을 부여해 양측이 '정말 끝났는가'를 판단할 수 있게 하는 것입니다.

• 진단 — 문제점 진단 결과와 데이터 기준선 측정 결과를 냅니다. 약속된 방식은 '먼저 측정하고 그다음 계산한다'입니다. 기준선 데이터를 수집한 뒤에 개선 목표와 범위를 협의합니다. 이 단계는 전사 확산의 확정 견적을 내지 않습니다.
• 파일럿 — 범위를 둘러쌀 수 있으면 작은 범위부터 시작하고 검수 기준을 먼저 정합니다. 확정값이 없는 주기와 지표는 양측 조사를 거쳐 확인합니다. 이 단계는 전사 가동을 내지 않습니다.
• 구축과 시운전 — 표준화된 엔지니어링 템플릿에서 출발합니다. I/O 배분, 태그 리스트, 네트워크 구성도, 화면 규격서가 개발보다 먼저입니다. 개조 프로젝트라면 무정지 시공 관리 계획도 산출물이 됩니다. 이 단계는 신규 요구사항을 내지 않습니다. 요구 추가는 변경 절차를 탑니다.
• 검수 문서 — 문서 자체가 산출물입니다. 계약과 대상 범위에 따라 조작 설명서, 데이터베이스 테이블 설명, 인터페이스 규격서, 태그 리스트 도면집 등 약속된 자료를 인도해, 공장이 이후 스스로 관리하고 조회하고 확장할 수 있게 합니다. 이 단계는 '검수 후에 생각나서 요청하는 문서'를 내지 않습니다. 목록은 기술협의서를 기준으로 합니다.
• 연간 유지보수 — 표준 유지보수 계약, 해마다 갱신되는 유지보수 항목 목록, 연간 유지보수 보고서를 냅니다. 운영을 정량화하고 평가할 수 있게 만듭니다. 이 단계는 상한 없는 신규 개발을 내지 않습니다.
• 확장 — 대상 범위와 현장 평가에 따라 2차를 진행하고, 기존 투자와의 호환을 우선합니다. 이 단계는 1차를 되돌리는 재구축을 내지 않습니다.

'무엇을 내지 않는가'는 앞 절반과 똑같이 중요합니다. 검수 시점의 분쟁은 대부분 어느 한쪽이 '그 작업은 그 단계에 포함된다'고 생각했지만 실제로는 한 번도 합의되지 않았던 일로 거슬러 올라갑니다.

단계별 대조: 산출물과 발주사가 확정할 사항

아래 표는 공급사와 협의할 때 체크리스트로 쓰도록 썼습니다. 어떤 단계의 세 번째 열을 채울 수 없다면 그 단계는 아직 정의되지 않은 것입니다. 제안서가 아무리 두꺼워도 마찬가지입니다.

번호는 순서를 뜻하고 기간을 뜻하지 않습니다. 진단은 며칠, 단일 라인 파일럿은 4~8주, 전사 구축은 그보다 훨씬 깁니다. 각 단계의 종료 조건을 정하는 일이 기간을 정하는 일보다 중요합니다.

문서는 산출물이며 부수적인 서류 작업이 아니다

익숙한 상황입니다. 시스템은 돌아가고, 공급사의 그 엔지니어는 왜 돌아가는지 알고, 그 외에는 아무도 모릅니다. 2년 뒤 라인을 개조할 때 그 엔지니어는 이미 다른 업무로 옮겼고, 공장은 리포트 하나를 고치지도 못합니다. 그것이 어떤 테이블을 읽는지 아무도 적어 두지 않았기 때문입니다.

산업 프로젝트의 완전한 자료 일체는 14종입니다. 생성 시점으로 묶어 두면 계약서와 대조해 공급사가 제시한 목록을 확인하기 쉬워집니다.

권장되는 방식은 이 목록을 기술협의서에 첨부하는 것입니다. 양측의 선의에 맡기지 않는다는 뜻입니다. 계약 시점에 문서 목록을 명기해도 추가 비용은 들지 않지만, 프로젝트 팀이 해산한 뒤 되돌아가 다시 만들면 대가가 큽니다.

기술협의서에 넣을 만한 검수 지표

'시스템이 정상 가동될 것'은 측정할 수 없습니다. 검수 조항이 작동하는 전제는, 프로젝트 경위를 모르는 제3자가 그것을 읽고 시험을 한 번 수행해 합격 또는 불합격을 판정할 수 있다는 것입니다.

아래 지표는 현장에서 측정 가능하며, 계약 전에 항목별로 협의할 가치가 있습니다. 수치는 실제 공정에 맞춰 양측이 함께 채워야 하고, 템플릿에서 옮겨 쓰는 것이 아닙니다.

• 통신 복구 후 보완 수집: 통신이 회복된 뒤 중단 구간의 공정 곡선을 자동으로 채우는지, 완전성을 어떤 방법으로 검증하는지
• 알람 정확도: 오보와 미보를 어떻게 집계하는지, 어느 관측 구간에서 집계하는지, 허용 기준은 어디인지
• 데이터 지연: 설비 측 변화가 화면과 데이터베이스에 나타나기까지의 시간 차를 '실시간'이 아니라 수치로 적기
• 리포트 집계 정의: 리포트별 집계 규칙, 교대 경계, 시간대, 반올림 방식 — 생산과 품질이 같은 숫자를 보게 하기
• 복구와 응답: 서버 장애 후 재기동 시간, 이력 데이터베이스로 옮기기 전 보관 기간, 유지보수에서 약속하는 응답 시간

통신 복구 후 보완 수집이나 알람 정확도 같은 지표는 기술협의서에 검수 조건으로 명기할 수 있습니다. 발주사가 이를 요구하는 것은 통상적인 요청이며 과도한 요구가 아닙니다.