공장 공정 진도가 보이지 않는다: 업무는 어떻게 분해하고, 진도는 어떻게 수집하며, 작업지시서와는 어떻게 맞춰야 하는가

许愿牛科技 조회 87

공장의 워크숍 화이트보드가 ERP보다 더 정확한 이유는 현장과 시스템 간의 데이터 수집 경로가 끊어져 있기 때문이다. 본 글에서는 공정 진도를 여섯 가지 수집 가능한 차원으로 세분화하고, 각 역할, 데이터 모델, 인터페이스 범위, 그리고 수집·인터페이스·검수라는 세 가지 실행 단계의 관문을 명확히 설명한다.

서문: 작업장 벽에 걸린 ‘진행 상황 보드’는 왜 항상 시스템보다 이틀이나 빠를까

기계 가공을 하는 한 공장을 들여다보니, 회의실 벽에는 흰색 칠판이 걸려 있고 그 위에는 여러 가지 색깔의 포스트잇이 붙어 있다. 각 포스트잇에는 작업지시서 번호, 당일 공정, 공작기계 번호가 적혀 있다. 매일 밤 당직 관리자는 이 포스트잇들을 다시 한 번 교체한다. 다음 날 아침, 사장이 작업장에 들어와 묻는다. “어제 그 일감 다 처리됐나?” 작업장 주임은 칠판을 꺼내 눈을 가늘게 뜨고 포스트잇을 세어 본다.

같은 공장에서도 종종 두 가지 ‘진행 상황’이 존재한다. 하나는 흰색 칠판과 포스트잇이고, 다른 하나는 ERP나 MES에 표시된 작업지시서 상태다. 전자는 현장의 실제 상황을 반영하고, 후자는 재무나 고객에게 제공되는 수치를 의미한다. 이 둘이 맞지 않는 것은 흔한 일이며, 맞아떨어질 때야말로 뉴스거리다.

이것은 어느 특정 공장만의 특별한 경우가 아니다. 우리가 만난 작업장들은 십여 명 규모의 작은 공방부터 수천 명이 근무하는 완성품 제조업체까지, 모두 비슷한 문제를 겪었다:

  • 생산 계획이 작업대까지 전달되지 않는다: 계획 담당자가 시스템에 30개의 작업지시서를 배정했지만, 작업장에서는 단 8개만 확인할 수 있다. 나머지는 ‘시스템에 걸려 있는 상태’로 남아 있다.
  • 진행 상황은 물어봐야만 알 수 있다: 조정 담당자는 하루에도 수십 통의 전화를 걸어 ‘이 작업 어디쯤 와 있나요?’라고 묻고, 작업반장도 몇 개의 공정이 어디쯤 진행되고 있는지 정확히 기억하지 못한다.
  • 노동 시간과 실제 상황이 맞지 않는다: 작업 보고 담당자는 4시간마다 한 번씩 양식을 작성하다가, 퇴근 두 시간 전에 한꺼번에 보충하기 때문에, 수치와 실제 진행 속도 사이에 20%에서 40%의 차이가 발생한다.
  • 이상 상황을 아무도 챙기지 않는다: 어떤 공정에서 원자재가 사흘째 오지 않아도 아무도 이를 알아채지 못하다가, 고객이 납기를催하면 비로소 부품이 부족하다는 사실을 발견한다.

문제는 어느 소프트웨어를 사용하지 않았느냐가 아니라, ‘현장’과 ‘시스템’ 사이의 정보 수집 과정이 끊어져 있기 때문이다. 벽에 걸린 흰색 칠판이 ERP보다 더 진짜인 이유는, 그것이 공작기계 옆에 서서 현장을 직접 보는 사람이 관리하기 때문이다. 반면 ERP는 대개 세 단계를 거친다: 작업반장 → 팀장 → 조정 담당자, 각 단계마다 다시 입력하므로 매 단계마다 지연되거나 오류가 발생할 가능성이 크다.

이제 이 시스템을 어떻게 설계하고 구현해야 벽에 걸린 칠판이 점점 비워질 수 있을지 살펴보자.

작업대 단말기 대형 버튼 조작

01 업무를 어떻게 분해할 것인가: ‘진행 상황’을 수집 가능한 최소 단위로 쪼개라

많은 프로젝트에서 처음부터 ‘공정 진행 상황’이라는 네 글자를 하나의 필드로 취급한다. 그러나 실제로 ‘공정 진행 상황’은 복합적인 상태다: 작업지시서가 어느 작업대에 위치해 있는지 누가 작업 중인지 이미 얼마나 진행되었는지 얼마나 많은 노동 시간이 소요되었는지 품질이 합격인지 여부 자재가 충분히 갖춰졌는지. 이 여섯 가지 차원은 각각 독립적으로 수집되어야 하며, 하나로 통합해서는 안 된다.

구체적으로 이렇게 분해된다:

  1. 작업대: 각 공작기계나 작업대에는 고유한 번호가 부여되어 있으며, 스캔이나 카드 인식으로 ‘현재 이 기계는 누구의 일을 처리하고 있는지’를 파악할 수 있다.
  2. 작업자: 각 작업지시서의 시작 공정, 이동 공정, 보고 공정은 모두 하나의 직원 번호와 연결된다. 사제 간 협업이라도, 주 작업자는 유일한 기록 담당자다.
  3. 이미 처리된 수량: 공정에는 초기 검사, 중간 검사, 완료 계수 등이 있다. 수량은 상태가 아니므로, 버튼을 누르거나 코드를 스캔해 반드시 업데이트해야 한다.
  4. 실제 노동 시간: 시작 공정과 완료 공정 사이의 시간 차이(자동 수집)에, 중간에 발생한 정지(비정상적 체류 사유를 수동으로 추가)를 더한다.
  5. 품질 상태: 초기 검사, 중간 검사, 최종 검사의 세 기록이 있으며, 합격·재작업·폐기의 흐름은 서로 독립적으로 진행되므로, 합격률만 기입하는 것은 허용되지 않는다.
  6. 자재 완전성: BOM에 기재된 각 자재는 ‘완전함’, ‘미완성’, ‘부족한 자재 보충 대기’의 세 가지 상태로 구분되며, 작업지시서 상태와 연동된다.

이 여섯 가지 차원을 모두 독립적인 ‘이벤트 흐름’으로 분리한다. 상태 필드가 아니라, 이벤트를 기록하는 방식이다. 이벤트는 일련의 기록으로, 누가, 언제, 어느 기계에서, 어느 부분까지 진행했는지, 어떤 이상이 있었는지를 모두 기록한다. 상태는 이벤트 흐름에서 도출된 시각적 표현일 뿐이며, 상태 필드는 사람의 손으로 직접 기입해서는 안 된다..

02 설계 방법: 역할, 프로세스, 데이터, 인터페이스의 경계를 명확히 그려라

설계 단계에서 가장 흔히 빠지는 함정은 ‘앱을 만들어 사람들이 입력하게 하는 것’이다. 하지만 운영 2년이 지나도 앱에는 로그인 화면과 비밀번호 입력란만 남아 있다. 문제는 역할과 인터페이스의 불일치에 있다.

역할 설계

작업장에는 네 가지 유형의 사람이 있으며, 각 유형은 서로 다른 인터페이스를 사용한다:

  • 작업자: 큰 버튼이 달린 작업대 단말기나 태블릿을 사용하며, ‘내 손에 있는 작업지시서’만 볼 수 있다. 버튼은 세 개뿐이다: 시작, 일시정지, 완료. 화면에는 표가 나타나서는 안 된다.
  • 작업반장: 휴대폰이나 작업장 보드를 이용해 해당 교대의 모든 작업대 상태를 확인하며, 2분이면 ‘어디서 막혔는지’를 찾아낼 수 있다.
  • 조정 담당자 또는 계획 담당자: PC를 사용해 전체 공장의 모든 작업대의 간트차트와 이상 목록을 확인하며, 특히 일정 조정과 이상 대응에 집중한다.
  • 품질 또는 공정 담당자: 독립적인 접근권을 가지고, 초기 검사 합격률, 재작업 비율, SPC 추세 그래프 등을 확인하며, 작업지시서 상태를 직접 수정하지 않고, ‘라인 정지’나 ‘통과’만 결정할 수 있다.

데이터 모델

핵심 네 개의 테이블과 몇몇 보조 테이블만으로 충분하다:

  • work_order: 작업지시서 메인 테이블로, 판매 주문, 계획 주문, 제품과 연동된다.
  • work_order_route: 공정 경로를 설정하며, 각 공정 단계마다 필요한 자재량을 기록한다.
  • route_event: 공정 이벤트 흐름(핵심 기록)으로, 누가, 언제, 어느 기계에서, 어느 단계까지 진행했는지를 기록한다.
  • exception_log: 이상 상황 일지(자재 부족, 설비 고장, 품질 재작업 등).

상태 필드(statuscurrent_stepprogress_pct)는 모두 route_event에서 실시간으로 계산되며, 저장되지 않는다; 저장되는 것은 이벤트뿐이다. 따라서 누가 작업지시서를 수정하더라도, 상태는 항상 이벤트 흐름에 따라 결정된다.

인터페이스 경계

세 가지 단말기의 경계를 명확히 그려야 한다:

  • 작업대 단말기: 스캔 → 작업지시서 호출 → 공정 표시 → 큰 버튼으로 시작/일시정지/완료; 어떠한 숫자 필드도 입력할 수 없으며, 모든 숫자는 PLC나 스캐너가 자동으로 기록한다.
  • 작업반장 보드: 해당 교대의 작업대를 그리드 형태로 표시하며, 초록은 정상, 노란색은 초과, 빨간색은 이상을 나타낸다. 빨간색을 클릭하면 바로 이상 일지 상세로 이동한다.
  • 조정원 PC: 간트차트에 자원 부하와 이상 대기를 추가하고, 이상은 반드시 대기로 구분해야 하며, 간트차트 안에 섞여 있어 사람으로 하여금 ‘이상을 찾게’ 해서는 안 됩니다.

공장 배차 간트 차트와 이상 대기열

03 어떻게 개발할 것인가: 수집, 인터페이스, 검수의 세 가지 관문

개발 단계의 핵심 과제는 ‘현장에서 사용하고자 하는 마음을 갖게 하는 것’입니다. 현장에서 사용하고자 하는 마음을 갖게 하려면 ‘한 번만 누르면 된다’는 전제가 필요하며, ‘일련의 정보를 입력해야 한다’는 방식이어서는 안 됩니다. 이는 결국 세 가지 관문에 달려 있습니다.

수집 관문

수집은 세 단계로 나뉩니다:

  • 장비 직접 수집: CNC, 사출성형기, SMT 등은 OPC UA 또는 Modbus를 통해 가동·정지 신호, 현재 프로그램 번호, 카운트 값을 실시간으로 이벤트 스트림에 기록합니다. 이 부분은 가장 어렵지만 가치가 가장 높으며, 한 번 구축하면 이후에는 더 이상 인력에 의존하지 않아도 됩니다.
  • 바코드 스캔과 버튼 추가: 수작업 작업대에서는 바코드 스캐너(재료)와 큰 버튼(시작/일시정지/완료)을 사용합니다. 바코드 스캐너는 USB HID를 통해 문자열을 출력하며, OCR이나 이미지 인식을 하지 않습니다.현장 네트워크에 문제가 생기면 이미지 처리가 무효가 되기 때문입니다.
  • 계량/계수/광전 센서: 재료 무게 측정, 부품 개수 세기, 안전 광전 센서 모두 PLC 신호를 OPC로 변환하여 처리합니다.

3층은 하나의 수집 게이트웨이 서비스를 공유하며, 게이트웨이는 서로 다른 프로토콜을 통일된 이벤트 형식(JSON)으로 정규화한 뒤, 메시지 큐(Kafka 또는 RabbitMQ)에 기록하고, 구독 서비스가 이를 소비한 후 데이터베이스에 저장합니다. 이렇게 하면 설비나 작업 위치를 변경하더라도 게이트웨이만 수정하면 되고, 주요 업무 시스템을 다시 작성할 필요가 없습니다.

인터페이스 관문

외부 인터페이스는 두 가지 유형으로 나뉩니다:

  • 상류: ERP 또는 MES에서 작업 지시서, 판매 주문, BOM을 전달합니다. 이는 주 데이터 소스이며, 본 시스템은 읽기 전용으로 작동하여 두 시스템 간에 작업 지시서 상태가 서로 변경되는 것을 방지합니다.
  • 하류: 재무 시스템에서는 근무 시간과 원가를 필요로 하고, 고객 시스템에서는 납품 진척도를 요구하며, 공급업체 시스템에서는 부품 조립 상태를 확인합니다. 하류 시스템은 ‘이벤트 트리거’ 또는 ‘정기적 페칭’ 방식으로 동작하며, 본 시스템의 작업 지시서 상태를 반대로 수정하는 것은 허용되지 않습니다.

인터페이스 설계 원칙: 이벤트 흐름은 출구만 있고 입구는 없다. 본 시스템은 이벤트의 진실 원천(source of truth)이며, 외부 시스템은 구독자입니다. 이 규칙을 준수하면 언제나 진실은 하나뿐입니다.

검수 관문

검수란 ‘기능이 작동한다’는 것만을 의미하는 것이 아니라, 다음 세 가지를 포함합니다:

  1. 데이터 진실성: 무작위로 5건의 작업 지시서를 선별하여 화이트보드나 현장 카메라와 대조해, 시스템 기록과 실제 시작·완료 시간 간 오차가 5분을 넘지 않는지 확인합니다.
  2. 이상 사항 폐쇄 순환: 자재 부족 이상을 발생시켜, 반장의 생성부터 배차 담당자의 처리, 구매를 통한 재공급, 그리고 작업대 복구까지 전 과정의 흐름을 추적하고, 5분 이내에 이상 대기열에서 해당 이슈가 확인되도록 검증합니다.
  3. 사이클 타이밍 비교: 일주일간 각 작업대의 실제 사이클 타이밍을 연속적으로 집계하여 공정 표준과 비교하고, 차이가 30%를 초과하면 자동으로 경고 알림을 발송합니다.

위 세 가지 항목을 모두 통과해야 비로소 ‘공정 진척이 실제로 확인되었다’고 할 수 있습니다.

마무리: 도입 순서, 리스크 및 지표들

이러한 프로젝트는 한 번에 모든 것을 도입하지 않고, 세 단계로 나누어 진행합니다:

  1. 1단계(1~2개월): 우선 작업대 단말기에 야근반장 보드를 도입하고, 한 개의 생산 라인만 커버합니다. 목표는 ‘화이트보드에 있는 80%의 포스트잇이 자동으로 시스템에 동기화된다’는 것입니다.
  2. 2단계(2~3개월): 배차 담당자의 PC와 이상 대기열, 설비 직접 구매 기능을 추가하여 전체 공장의 주요 생산 라인을 포괄합니다. 목표는 ‘현장에서 더 이상 진척 상황을 전화로 문의하지 않아도 된다’는 것입니다.
  3. 3단계(필요 시): ERP, 재무 및 고객 시스템과 연동하여 사이클 최적화와 SPC 분석을 수행합니다. 이 단계는 반드시 수행해야 하는 것은 아니며, 앞선 두 단계를 완료한 뒤 현장 피드백을 바탕으로 결정합니다.

일반적인 리스크:

  • 현장의 저항: 감시와 비교를 두려워하는 마음입니다. 해결 방법은 인터페이스에 사람 정보는 노출하지 않고 작업대만 표시하며, 지표 역시 팀 단위로만 산정하고 개인 순위는 제공하지 않는 것입니다.
  • 수집 누락: 노후 설비에는 통신 포트가 없어 스캐너를 대체해야 합니다. 검수 시 누락률이 5%를 넘지 않도록 확인해야 합니다.
  • 근무 시간 왜곡: 작업자가 ‘숫자 맞추기’를 위해 여러 번 일을 시작했다가 중단하는 경우가 발생합니다. 시스템은 동일 작업대에서 5분 내에 여러 번 작업이 이루어진 경우 이를 이상으로 간주하여 바로 처리합니다.

검사 항목의 성패를 가르는 지표는 단 세 가지뿐입니다:

  • 배차 담당자의 전화 건수: 시스템 도입 후 50% 이상 감소합니다.
  • 이상 평균 대응 시간: 시간 단위에서 분 단위로 단축됩니다.
  • 고객이 확인 가능한 진척도: 납품 지연 관련 불만족율이 30% 이상 감소합니다.

이 세 가지 지표를 현장에 적용하면 벽에 걸린 화이트보드가 비워지고, 이제야 비로소 진척 관리가 제대로 이루어졌다고 할 수 있습니다.

온라인 상담