많은 공장에서 맞춤형 소프트웨어 프로젝트는 코딩 단계에서 막히는 것이 아니라, ‘요구사항이 명확히 전달되지 않고 범위가 계속 변경되며, 시스템이 도입되어도 아무도 인정하지 않는’ 문제로 인해 실패합니다. 영업팀은 공정 진행 상황을 원하고, 작업장에서는 배치 변경 기능을 요구하며, 재무팀은 작업지시서와 원가를 일치시키길 바라지만, IT 부서는 인터페이스 목록조차 아직 확정되지 않았다고 합니다. 석 달 뒤 시스템이 도입되었지만, 현장에서는 여전히 위챗으로 사진을 보내고 엑셀로 작업 보고를 이어갑니다. 실제로 부족한 것은 기능 목록이 아니라, 범위 확정부터 설계, 개발, 검수까지의 실행 가능한 전환 경로입니다.
비즈니스 문제: 왜 ‘완료’됐는데도 사용되지 못하는 걸까요?
분산형 제조의 흔한 애로사항은 다음과 같습니다. 작업지시서는 발급되지만 공정 진행 상황은 확인할 수 없고, 반장이 구두로 배치를 변경해도 시스템은 여전히 이전 단계에 머물러 있습니다. 품질검사 불합격 시 종이로만 폐쇄된 후 처리되고, 원가 계산과도 맞지 않습니다. 사장님은 실제 WIP(진행 중인 작업)를 볼 수 있는 시스템을 원하지만, 납품업체가 ‘모듈 목록’에 따라 견적을 내면, 보드, 작업 보고, 재고, 원가 등 모든 것을 한 번에 포함시켜 범위가 커져 결국 검수가 불가능해집니다.
또 다른 실패 유형은 인터뷰 요약을 요구사항 명세로 착각하는 경우입니다. 요약에는 “진행 상황을 확인할 수 있어야 한다”는 내용만 적혀 있을 뿐, 어떤 작업 보고를 기준으로 할 것인지, 재작업은 어떻게 반영할 것인지, 반장 간 배치 변경 시 누가 권한을 갖는지 등의 구체적인 규정은 명시되어 있지 않습니다. 개발팀은 그 문구를 문자 그대로 해석해 리스트 페이지를 만들었고, 현장에서 바로 사용하자마자 문제가 발생했습니다. 소프트웨어가 해결할 수 있는 부분은 이러한 규칙들을 실행 가능한 상태 전환 및 권한 체계로 만드는 것이고, 해결하지 못하는 부분은 조직 내에서 누구도 규칙을 확정하려 하지 않는다는 점입니다.
또한 숨은 비용으로는 오랜 기간 동안 병행 운영되는 두 가지 시스템이 있습니다. 기존 엑셀은 계속 사용되고 새로운 시스템은 아직 완전하지 않아 현장에서는 편리한 쪽을 선택하게 되고, 시스템 데이터는 점점 더 지저분해져 결국 “시스템이 잘 안 된다”는 평가를 받게 됩니다. 병행 운영은 가능하지만, 기존 표를 폐기하는 날짜와 정산 규정을 명확히 정해야 하며, 그렇지 않으면 시스템 도입은 단지 화면만 추가하는 것에 불과합니다.
- 범위가 명확하지 않아 1단계 목표가 ‘전체 디지털화’로 혼재됩니다.
- 데이터 수집의 단절: 진행 상황은 여전히 구두로만 전달되고, 시스템은 단지 표시 기능만 제공합니다.
- 검수의 미스매칭: 메뉴 기반 점검만 실시하고, 실제 비즈니스 결과를 기준으로 하지 않습니다.
- 병행 운영의 통제력 상실: 기존 표는 계속 사용되고, 새로운 데이터에는 주인이 없습니다.
비즈니스를 어떻게 나눌 것인가: 먼저 1단계에서 검증 가능한 결과를 고정합니다.
1단계는 ‘주요 공정의 작업 보고 지연이 30분을 넘지 않으며, 계획자가 작업지시서를 통해 세트와 병목 원인을 파악할 수 있다’는 식의 측정 가능한 결과에 맞춰 고정하는 것이 좋습니다. 나머지 재고 최적화, 원가 배분, BI 대시보드는 2단계로 미루는 것이 바람직합니다. 비즈니스 분할은 네 가지 링크를 기준으로 할 수 있습니다:
- 작업지시서 링크: ERP/MES에서 작업지시서와 공정 정의를 가져오고, 주요 데이터 책임자를 명확히 지정합니다.
- 작업 보고 링크: 누가 언제 스캔하거나 클릭하여 완공, 재작업, 일시중지 등을 보고하는지 규정합니다.
- 이상 상황 링크: 자재 부족, 설비 정지, 품질 동결 등이 하류 공정에 어떤 방식으로 영향을 미치는지 규정합니다.
- 정산 링크: 매일 정산 시, 시스템 진척과 현장 재고 차이를 어떻게 설명할 것인지 규정합니다.
각 링크마다 트리거 사건, 책임 역할, 시간 초과 시 승급 절차를 명확히 기술합니다. 만약 기술할 수 없다면, 해당 비즈니스는 아직 시스템 도입 준비가 되지 않았음을 의미하므로, 무리하게 개발에 돌입하기보다는 먼저 제도적 예열을 거쳐야 합니다. 범위 확정 회의에서는 서명 문서를 작성해야 합니다: 포함된 기능은 1단계로, 제외된 기능은 요구사항 풀로 이동시키고, 변경 사항은 변경 신청서를 통해 처리하며 기간을 평가합니다.
설계 방법: 역할, 프로세스, 데이터 경계
설계 단계에서는 여러 개의 와이어프레임보다 세 가지 핵심 결과물을 도출해야 합니다: 역할 매트릭스, 상태 전환 기계, 인터페이스 계약. 와이어프레임은 추후 보완 가능하지만, 앞의 세 가지가 부족하면 어떤 화면도 다시 수정해야 합니다.
역할과 권한
최소한 계획자, 반장, 조작원, 품질검사원, 창고 관리자, 읽기 전용 관리자 등을 구분해야 합니다. 배치 변경과 취소는 반드시 두 사람의 기록을 남겨야 하며, 조작원은 자신의 작업대만 보고하고, 계획자는 병목 풀을 확인합니다. 권한은 ‘직무+생산라인’ 기반으로 부여하여, 한 사람이 모든 권한을 갖는 상황을 방지합니다. 계정과 퇴사 정보는 유지보수 목록에 반드시 반영해야 하며, 그렇지 않으면 권한 부채가 데이터 신뢰성에 악영향을 미칠 수 있습니다.
프로세스와 상태
공정별 상태는 간략화하는 것이 좋습니다: 개시 대기, 가공 중, 검사 대기, 완공, 재작업, 동결. 상태 전환은 법적으로 허용된 경계만 가능하며, 불법 전환에는 반드시 이유 코드를 기재해야 합니다. 보드는 상태 전환 결과만 읽을 수 있고, 작업 보고를 건너뛰어 직접 상태를 변경하는 행위는 금지됩니다. 재작업 시에는 어느 공정으로 돌아가는지, 하위 작업지시서가 생성되는지 명확히 밝혀야 하며, 진행 상황이 ‘완료된 듯 보이지만 실제로는 되돌아가는’ 상황을 방지해야 합니다.
데이터와 인터페이스 경계
주요 데이터(자재, 공정 경로, 반)는 원천 시스템에서 관리되고, 실행 데이터(작업 보고, 이상 상황)는 현장 시스템에서 생성됩니다. 인터페이스는 직무별로 최적화되어야 합니다: 조작원은 세 개의 버튼으로 작업 보고를 완료하고, 계획자는 병목과 세트를 확인하며, 관리자는 지연 분포를 살펴봅니다. ERP의 모든 필드를 작업장 태블릿에 옮겨서는 안 됩니다. 필드 수가 적을수록 데이터 수집은 더욱 정확해집니다.
개발과 도입 방법: 인터페이스, 데이터 수집, 검수
개발 순서는 다음과 같은 권장 사항을 따릅니다: 주요 데이터 동기화 → 작업 보고 수집 → 이상 상황 병목 처리 → 작업지시서와의 일치 조회 → 일일 정산 보고서 작성. 인터페이스는 우선적으로 멱등성을 확보해야 합니다: 작업지시서 변경 시에는 버전 번호를 사용하고, 작업 보고에는 사업상 유일한 키를 적용해 중복을 방지합니다. 데이터 수집 측에서는 약한 네트워크 환경에 대응해야 합니다: 로컬 큐, 재전송 및 보충 전송, 충돌 알림 등을 마련해야 합니다. 장비 스캔과 인력 클릭은 병행 가능하지만, 동일한 공정 인스턴스에는 하나의 ‘권위 있는 완공 사건’만 존재할 수 있습니다.
연동 테스트에서는 ‘더러운 데이터 시나리오’를 준비해야 합니다: 반복 스캔, 네트워크 중단, 작업지시서 중간에 공정 변경, 반장 간 배치 변경 등. 이러한 상황들은 성공적인 경로보다 설계 결함을 더 잘 드러냅니다. 성능 면에서는 보드 조회를 생산라인별로 분할하여, 전체 공장에서 실시간으로 전체 표를 스캔하는 일을 피해야 합니다.
검수는 ‘기능 점검’ 방식이 아니라, 시나리오 기반으로 진행해야 합니다: 실제 작업지시서를 열고, 공정 전반에 걸쳐 작업 보고를 수행하며, 인위적으로 자재 부족을 만들어 하류 동결을 검증하고, 반장 간 배치 변경 후 보드와 작업지시서가 일치하는지 확인합니다. 그리고 3일간의 작업 보고와 현장 재고를 비교해, 차이율이 합의된 임계값 이하인지 확인합니다. 기준에 미달하면 최종 검수에 서명하지 않고, 조건부 오픈만 승인합니다.
문서 전달 시에는 범위 확정 요약, 상태 전환 기계 설명, 인터페이스 목록, 권한 매트릭스, 시나리오 검수 기록, 유지보수 당직 및 변경 절차 등이 포함되어야 합니다. 이들 문서가 부족하면, 이후 유지보수는 구두 고고학으로 전락할 수 있습니다.
마무리: 납품을 ‘실행 가능한 규칙’으로 간주합니다.
요구사항부터 시스템 도입까지, 핵심은 기능을 늘리는 것이 아니라, 작업장의 기본 규칙을 실행 가능한 논리로 정리하고, 데이터 수집과 검수를 통해 그것이 실제로 작동함을 입증하는 것입니다. 1단계에서는 단 하나의 링크만 완성해도, 열 개의 반제품 메뉴보다 훨씬 가치가 있습니다. 만약 귀하의 공장이 공정 진행 상황과 작업지시서의 일치 문제로 어려움을 겪고 있다면, 위에서 제시한 방식을 따라 1단계 범위를 축소한 뒤 다시 시작해 보시기 바랍니다.
Shandong XYN Information Technology Co., Ltd. (XYN Tech)는 다양한 산업 분야의 소프트웨어 맞춤 개발을 오랫동안 수행해 왔으며, 범위, 설계, 개발, 검수를 모두 분리하여 각각의 독립된 과제로 전환합니다. 더 자세한 정보는 우리 소개 를 참조하시기 바랍니다.