― 수집이 아니라 ‘흐름’을 설계하는 구조 재정의(Process Data Architecture)
공정 데이터를 많이 모으면 문제가 해결될까?
센서를 늘리고 MES를 도입하면 품질이 안정될까?
이 글은 장비 스펙 비교나 최신 솔루션을 소개하는 글이 아니다.
정부 지원사업 안내도 아니다. (※ 관련 제도는 별도 조사 필요)
현장에서 반복적으로 나오는 질문 하나에 답하기 위한 정리다.
“데이터는 쌓이는데, 왜 의사결정은 빨라지지 않습니까?”
현장에서 실제로 나오는 상황
직원 42명 규모의 자동차 부품 가공 업체.
월 매출 약 18억 원.
CNC 장비 18대, 2교대 운영.
설비별 생산량, 불량 수량, 작업자 정보는 엑셀로 관리한다.
온도·진동 센서는 일부 장비에 부착되어 있고, 로그 파일은 서버에 저장된다.
문제는 명확하다.
- 특정 시간대에 불량률이 2.8% → 5.1%까지 상승
- 납기 지연이 월 3회 이상 발생
- 설비 고장은 예측되지 않고 갑자기 발생
대표의 질문은 단순하다.
“데이터는 있는데, 왜 미리 알 수 없습니까?”
구조가 정리되지 않은 상태의 특징
겉으로 보면 데이터는 많다.
하지만 흐름은 없다.
현재 구조
- 설비 → 로컬 PC 저장
- 작업자 → 엑셀 입력
- 품질팀 → 별도 엑셀 재정리
- 월말 회의에서 통합 보고
여기에는 세 가지 단절이 있다.
- 시간 단절 (실시간이 아님)
- 주체 단절 (입력자 ≠ 분석자)
- 목적 단절 (수집 목적이 불명확)
문제는 “데이터가 부족하다”가 아니다.
“데이터가 흐르지 않는다”는 점이다.
흔히 하는 착각
1. 데이터가 많으면 통제가 가능하다
실제로는 그렇지 않다.
데이터가 많을수록 정리 비용이 증가한다.
2. 시각화하면 해결된다
대시보드는 결과 표현 도구다.
흐름이 설계되지 않으면 그래프만 화려해진다.
3. 분석 인력이 부족해서 문제다
구조가 없으면 분석가는 매번 처음부터 정리해야 한다.
문제는 인력이 아니라 설계다.
Fieldbly 공정 데이터 3단계 흐름 모델
공정 데이터는 “수집 → 저장 → 분석” 구조가 아니다.
이 구조는 IT 관점이다.
현장 관점에서는 아래 3단계로 다시 설계해야 한다.
1단계: 의사결정 기준 정의
가장 먼저 해야 할 일은 질문을 정하는 것이다.
예:
- 불량률이 몇 %를 넘으면 조치할 것인가?
- 설비 진동 값이 어느 수준에서 경고인가?
- 납기 지연 기준은 몇 시간인가?
숫자 기준이 정의되지 않으면 데이터는 의미가 없다.
체크
- KPI가 숫자로 명확한가
- 기준 초과 시 누가 판단하는가
- 대응 시간은 정해져 있는가
2단계: 원천 → 판단지점까지의 경로 설계
데이터는 저장 위치가 아니라 “판단 지점”으로 흘러야 한다.
예시 재설계:
설비 센서
→ 실시간 수집 서버
→ 임계값 비교 로직
→ 현장 관리자 모바일 알림
→ 조치 로그 자동 기록
이때 중요한 것은 저장이 아니라 “조건 분기”다.
모든 데이터를 다 분석할 필요는 없다.
임계 조건을 통과한 것만 판단 단계로 이동하면 된다.
3단계: 피드백 루프 설계
조치 후 데이터는 다시 기준을 수정하는 데 사용되어야 한다.
예:

- 불량률 4% 기준이 너무 낮은가?
- 특정 작업자 교대 시간에 집중되는가?
- 특정 원자재 LOT에서 반복되는가?
이 단계가 없으면 데이터는 기록으로 끝난다.
구조 재설계 전후 비교
| 구분 | 기존 구조 | 재설계 구조 |
|---|---|---|
| 수집 목적 | 일단 저장 | 의사결정 기준 연동 |
| 분석 시점 | 월말 | 실시간 조건 초과 시 |
| 책임 주체 | 품질팀 | 현장 관리자 1차 대응 |
| 보고 방식 | 엑셀 취합 | 자동 알림 + 조치 로그 |
실행 절차
1. 공정별 핵심 지표 3개만 선정
- 불량률
- 가동률
- 설비 이상 신호
3개 이상은 초기에는 과하다.
2. 임계값 수치 명확화
- 예: 불량률 3.5% 초과 시 알림
3. 데이터 이동 경로 도식화
화이트보드에 아래만 그려도 된다.
설비 → 서버 → 조건 비교 → 관리자 → 조치 → 기록
4. 자동화 범위 최소화
처음부터 전체 공정 자동화는 실패 확률이 높다.
1개 공정, 1개 설비부터 시작한다.
5. 주간 피드백 회의 구조 변경
보고 회의가 아니라 “기준 수정 회의”로 전환한다.
도식 구조
[기준 정의]
↓
[데이터 발생]
↓
[임계값 비교]
↓
[알림/조치]
↓
[조치 기록]
↓
[기준 재설정]
이 루프가 작동해야 흐름이 완성된다.
현장에서 자주 놓치는 부분
- 센서 데이터와 작업자 수기 데이터의 통합 지점이 없다
- 불량 원인이 설비인지 사람인지 구분 기준이 없다
- 기준 변경 이력이 남지 않는다
이 세 가지가 정리되지 않으면 시스템은 유지되지 않는다.
실제 적용 후 변화 (가상 사례)
동일 기업에서 1개 라인만 재설계 적용.
- 불량률 평균 4.2% → 3.1%
- 고장 대응 시간 평균 3시간 → 40분
- 월 납기 지연 3회 → 1회
매출이 급증하지는 않는다.
하지만 손실이 줄어든다.
제조업에서 이 차이는 크다.
(※ 업계 평균 불량률 비교 데이터는 추가 조사 필요)
점검 질문
- 지금 우리 공정 데이터는 어디에서 멈추고 있는가?
- 기준 없이 쌓이고 있는 숫자는 없는가?
- 판단 지점까지 자동으로 도달하는 흐름이 있는가?
- 조치 후 기준을 수정하는 구조가 있는가?
데이터를 더 모을 것인지,
흐름을 다시 설계할 것인지.
먼저 확인할 것은 양이 아니라 구조다.
AI현장감독 이동주는 AI 도입 과정에서 반복되는 구조 문제를 연구한다.
AI adoption failure를 기술 문제가 아닌 설계와 흐름의 문제로 바라본다.
Fieldbly에서 현장 사례를 기반으로 정리하고 있다.
(homepage) http://www.fieldbly.com