스마트팩토리 개론

"우리 공장 수준"부터 알아야 하는 이유

스마트팩토리는 사면 되는 장비가 아니라 단계를 밟는 일이에요. 우리가 지금 어디에 있는지 모른 채 두 단계 위 물건을 사면, 검수는 통과하고 6개월 뒤에 아무도 안 씁니다.

부울경 현장에서 실제로 자주 보는 장면이 있어요. 지원사업으로 MES를 깔았는데 작업자는 여전히 종이 일보를 쓰고, 사무실에서 그걸 다시 시스템에 입력합니다. 일이 줄지 않고 늘어난 겁니다. 수준 판단을 건너뛰면 이렇게 됩니다.

정부 스마트공장 수준 4단계

정부 수준확인 제도는 진단 점수로 레벨 0~5를 매기고, 이 중 레벨 1~5를 기초·중간1·중간2·고도화 4개 구분으로 묶습니다. ICT를 전혀 안 쓰는 공장은 레벨 0입니다.

> 공식 수준진단은 리더십·공정·품질·설비·정보시스템 등 항목별 점수를 합산해 판정합니다. 아래는 현장에서 스스로 가늠하기 위한 실무 기준이에요.

단계를 가르는 실제 질문 4개

말로만 "우리는 중간1이다"라고 하지 말고, 이 네 가지로 판단하세요.

"데이터로 무엇이 바뀌나"가 가장 정직한 잣대예요. 화면이 아무리 화려해도 그 숫자를 보고 아무것도 안 바뀌면 그 공장의 실질 수준은 기초입니다.

중소 제조업은 낮은 단계에서 효과가 가장 큽니다

투자 대비 효과가 제일 좋은 구간은 기초와 중간1이에요. 이유는 단순합니다. 지금 없는 정보가 그때 처음 생기기 때문입니다.

종이 일보 없애기

• 종이 일보는 기억으로 씁니다. 퇴근 30분 전에 하루치를 몰아 쓰면 시각이 전부 틀려요.
• 사무실에서 엑셀로 재입력하면 같은 데이터를 두 번 만지는 셈이고, 오타가 섞입니다.
• 바코드 스캔으로 바꾸면 시작·종료 시각이 초 단위로 남습니다. 이때부터 사이클타임 분석이 가능해져요.

설비 가동률 자동 수집

가동률을 숫자로 못 대는 공장이 아직 많아요. 타워램프에 센서 하나만 붙여도 시간가동률은 자동으로 나옵니다.

OEE(종합설비효율) = 시간가동률 × 성능가동률 × 양품률

예) 8시간(480분) 근무, 계획정지(조회·청소) 30분
  부하시간   = 480 - 30 = 450분
  실제 가동  = 360분  (정지 90분 = 고장 40 + 준비교체 50)
  시간가동률 = 360 / 450 = 80.0%

  이론 사이클 30초/개, 실제 생산 600개
  성능가동률 = (30초 × 600개) / 360분
             = 18,000초 / 21,600초 = 83.3%

  양품 588개
  양품률     = 588 / 600 = 98.0%

  OEE = 0.800 × 0.833 × 0.980 = 65.3%

> 이 숫자를 종이로 뽑으려면 사람이 하루를 씁니다. 그것도 다음 주에 나와요. 자동 수집이 되면 매일 아침에 나옵니다. 비가동 90분의 내역(고장 40 / 준비교체 50)이 보이는 순간 개선 과제가 저절로 정해집니다.

지원사업 구조와 자부담

정부 스마트공장 사업은 총사업비를 정부와 기업이 나눠 부담하는 구조예요.

총사업비 = 정부지원금 + 자부담금

자부담금 = 현금 부담 + 현물 부담(자사 인력 투입 등)

  예) 총사업비 1억원 / 정부지원 비율 50%
      정부지원금 5,000만원
      자부담금   5,000만원  ← 이 중 현금이 얼마인지가 핵심

• 지원 비율과 한도는 사업연도·유형(기초형/고도화형/대중소 상생형)마다 다릅니다. 반드시 그해 공고문을 확인하세요. 작년 조건을 그대로 믿으면 안 됩니다.
• 현물로 인정되는 범위를 미리 확인하세요. 현물 비중을 크게 잡았다가 정산에서 인정 못 받으면 그만큼 현금으로 메워야 합니다.
• 사업 종료 후 운영비는 전액 자부담입니다. 라이선스, 서버, 유지보수, 센서 교체가 매년 나가요. 견적 받을 때 구축비만 보지 말고 3년 운영비를 같이 물어보세요.
• 중도 포기하면 지원금 환수 대상이 됩니다. 사업 기간 중 현장 인력이 투입 가능한지부터 따지세요.

자가진단 체크리스트

• 어제 우리 라인의 시간가동률을 숫자로 말할 수 있나
• 어제 비가동 원인 1위를 말할 수 있나
• 생산 실적이 시스템에 들어오는 데 걸리는 시간은 (실시간 / 당일 / 다음 날)
• 특정 로트의 자재가 어디서 왔는지 10분 안에 찾을 수 있나
• 위 네 개 중 못 하는 게 있다면, 우리 다음 과제는 고도화가 아니라 기초·중간1입니다

ERP만으로는 현장이 안 보입니다

ERP는 돈과 계획의 시스템이에요. 수주, 발주, 재고, 원가, 회계를 다룹니다. 그런데 사장님이 "지금 2호기에서 뭐 만들고 있나"를 물으면 ERP는 답을 못 해요. ERP가 아는 건 "이번 달에 A품목 5,000개를 만들기로 했다"까지입니다.

그 사이의 빈칸 — 지금 누가, 어떤 설비에서, 어떤 오더를, 몇 개까지, 어떤 품질로 만들고 있는가 — 를 채우는 게 MES(제조실행시스템)입니다.

ISA-95 — 시스템은 층으로 나뉩니다

공장 시스템의 계층을 정리한 국제 표준이 ISA-95예요. 이 그림 하나만 머리에 있으면 업체가 무슨 말을 해도 위치를 잡을 수 있습니다.

위로 갈수록 시간 단위가 길고 범위가 넓습니다. 아래로 갈수록 짧고 좁아요.

질문으로 구분하기

> 흔한 오해: "SCADA 깔았으니 MES는 필요 없다." 아닙니다. SCADA는 설비를 보는 시스템이고 MES는 오더와 제품을 보는 시스템이에요. SCADA는 온도가 몇 도인지 알지만, 그 온도가 어느 고객의 어느 로트에 걸린 온도인지는 모릅니다.

MES의 11대 기능 (MESA 정의)

중소 현장이 실제로 먼저 켜는 5개

11개를 한꺼번에 켜는 회사는 없습니다. 현실적으로 이 5개부터예요.

작업지시

종이 작업지시서를 현장 단말 화면으로 바꿉니다. 부수 효과가 큽니다 — 구버전 도면으로 가공하는 사고가 사라져요. 화면에는 최신 Rev만 뜨니까요.

실적수집

바코드/QR 스캔으로 시작·종료·수량을 찍습니다. 여기서 사이클타임과 가동률의 원본 데이터가 나옵니다.

품질

초물검사, 인라인 측정값, 불량 코드를 그 자리에서 입력합니다. 검사성적서를 손으로 옮겨 적는 일이 없어져요.

설비

가동·정지·알람 신호를 받습니다. 비가동 원인을 코드로 남기면 개선 과제 우선순위가 자동으로 정해집니다.

자재추적

자재 로트와 완제품 시리얼을 연결합니다. 부울경 자동차부품 협력사에서 MES 도입 명분 1순위가 바로 이겁니다.

> 원청이 클레임을 걸었을 때 "어느 로트의 소재가 문제였고, 그 소재가 들어간 완제품이 몇 개이며, 어디로 출하됐는지" 를 대지 못하면 대상 범위가 전량으로 잡힙니다. 추적성 하나로 회수 비용이 자릿수 단위로 달라져요.

데이터를 어떻게 넣나 — 입력 방식 비교

외국인 근로자가 많은 라인이라면

부울경 조선기자재·주물·도금 현장은 외국인 비중이 높아요. 화면 설계를 이렇게 해야 실제로 씁니다.

• 텍스트 입력을 요구하지 마세요. 스캔과 버튼만으로 끝나야 합니다.
• 불량 코드는 글자가 아니라 사진·아이콘으로 고릅니다.
• 화면 언어는 최소 한국어 + 주 사용 언어 1~2개.
• 장갑을 낀 손으로 눌러지는 큰 버튼. 정전식 터치는 장갑에서 안 먹는 경우가 많습니다.
• 단말 위치는 작업 동선에서 2보 이내. 5m 떨어지면 아무도 안 갑니다.

MES가 실패하는 3가지 이유

1. 목적 없는 도입

"공고가 떴으니 일단 신청"으로 시작한 프로젝트는 요구사항이 안 나옵니다. 판별법은 간단해요. "이 시스템으로 어떤 숫자가 몇 % 좋아집니까?" 에 3초 안에 답이 안 나오면 목적이 없는 겁니다. 결과는 검수 통과 후 방치입니다.

2. 마스터 데이터 미정비

품번 체계가 사람마다 다르고, BOM이 실제와 다르고, 공정 라우팅이 문서로 없는 상태에서 MES를 얹으면 시스템이 매일 틀린 답을 냅니다. 현장은 곧 시스템을 안 믿게 되고, 종이로 돌아가요. MES 프로젝트의 절반은 사실 마스터 데이터 정리 작업입니다.

3. 현장 미참여

사무실과 전산 담당이 요구사항을 다 정하고, 현장은 오픈 전에 교육 30분 받는 방식. 그러면 위에 적은 장갑·언어·동선 문제가 그대로 남습니다. 요구사항 정의 단계부터 조·반장과 실제 입력할 작업자를 넣으세요.

도입 전 체크리스트

• 품번 체계가 전사 통일되어 있나
• BOM과 공정 라우팅이 실제와 일치하나
• 개선하려는 지표를 3개 이내로 적었나
• 현장 단말 위치와 입력 동선을 도면에 그려봤나
• 작업자 언어 구성을 반영했나
• 커스터마이징 항목이 몇 개인가 (많을수록 나중에 손댈 수 없게 됩니다)
• 3년치 운영비(라이선스·유지보수)를 견적에 받았나

데이터는 저절로 모이지 않습니다

"IoT 센서를 붙이면 데이터가 모인다"는 말은 절반만 맞아요. 센서에서 나온 신호가 화면의 숫자가 되기까지는 네 번의 관문을 지납니다. 어느 한 곳이 끊기면 전체가 죽어요. 설비 업체와 SI 업체가 서로 책임을 미루는 지점이 대부분 이 경계선입니다.

경계마다 누가 책임지는지를 계약서에 적어두지 않으면, 나중에 "우리는 PLC까지만 합니다"라는 말을 듣게 됩니다.

수집 경로: 센서 → PLC → 게이트웨이 → 플랫폼

[센서 / 액추에이터]          Level 0~1
      │   4~20mA, 0~10V, 접점(ON/OFF), 펄스
      ▼
[PLC / 인버터 / 계측기]      Level 1~2
      │   설비 내부 메모리(레지스터)에 값이 들어 있음
      │   Modbus TCP, EtherNet/IP, PROFINET
      ▼
[게이트웨이 / 엣지 장치]     ← 프로토콜 변환 + 버퍼링 + 필터링 + 시각 동기
      │   OPC UA, MQTT(TLS)
      ▼
[MES / IoT 플랫폼]           저장 + 화면 + 알람 + 분석

게이트웨이가 하는 일을 과소평가하면 안 됩니다.

• 프로토콜 변환: 설비마다 말이 다릅니다. 여기서 하나로 맞춥니다.
• 버퍼링: 회선이 끊겨도 로컬에 쌓아뒀다가 복구되면 올려보냅니다. 이게 없으면 정전 한 번에 그날 데이터가 통째로 날아가요.
• 시각 동기: 설비마다 시계가 다르면 데이터를 겹쳐볼 수 없습니다. NTP로 맞춰야 해요.
• 필터링·집약: 원신호를 다 올리면 회선과 저장소가 못 버팁니다(아래 계산 참고).

현장에서 쓰는 센서 4종

> 신규 센서를 붙일 때 설비 제조사 보증 조건을 먼저 확인하세요. 제어반을 열거나 배선을 분기하면 보증이 무효가 되는 계약이 흔합니다. CT 클램프와 광센서가 선호되는 실질적 이유예요.

통신 프로토콜 — 세 가지만 알면 됩니다

OPC UA와 MQTT는 경쟁 관계가 아닙니다

• OPC UA는 "무슨 값인가" 의 문제를 풉니다. 레지스터 40001이 아니라 "3호기 배럴 2존 온도, 섭씨"라고 의미가 붙어요.
• MQTT는 "어떻게 나르는가" 의 문제를 풉니다.

그래서 실제 구축에서는 겹쳐 쓰는 경우가 많습니다. 업체가 "우리는 MQTT라 OPC UA는 필요 없다"고 하면, 그럼 태그 의미는 어디에 정의되어 있는지 물어보세요. 엑셀 파일 하나로 관리하고 있다면 담당자 퇴사와 함께 사라집니다.

> Modbus를 사내망 밖으로 그대로 내보내면 안 됩니다. 인증도 암호화도 없어서 값을 읽는 것뿐 아니라 쓰는 것도 막을 수 없어요. 외부로 나갈 때는 게이트웨이에서 OPC UA나 TLS를 적용한 MQTT로 바꿔 보냅니다. 제어망과 사무망은 반드시 분리하세요.

구형 설비를 어떻게 붙이나 — 부울경 현실

중소 제조 현장 설비의 상당수는 통신 포트가 없거나 있어도 개방이 안 됩니다. 포기할 필요 없어요.

> 감전 주의. 분전반·제어반을 열거나 타워램프 배선에서 전압을 따는 일은 전기작업입니다. > 산업안전보건기준에 관한 규칙 제319조에 따라 원칙적으로 정전 후 시공하고, 부득이 충전전로에서 > 해야 하면 제321조에 따라 절연용 보호구·방호구를 갖춰야 해요. > 시공은 전기 유자격자가 합니다. 현장 담당자가 임의로 붙이지 마세요.

| PLC는 있으나 설비사 봉인 | 별도 IO 유닛으로 접점만 병렬 취득 | 사이클 카운트, 도어 개폐 |

| 수동 공정(용접·도장·조립) | 작업자 스캔 + 위치 태그 | 시작·종료 시각, 작업자 |

타워램프 3상태만 모아도 시간가동률이 나옵니다. 여기서 시작하는 게 정석이에요. 몇만 원짜리 센서가 몇천만 원짜리 컨설팅보다 먼저 값을 합니다.

조선기자재·야외 작업 현장의 추가 변수

• 블록·의장품 작업은 위치가 계속 바뀝니다. 유선 배선이 불가능해 LTE 게이트웨이나 배터리형 무선 센서가 현실적이에요.
• 도장·용접 구간은 분진과 스패터로 광센서가 자주 죽습니다. 보호 커버와 교체 주기를 처음부터 계획에 넣으세요.
• 사외 협력사 작업분은 우리 망에 못 들어옵니다. 이 구간은 스캔 기반 실적 입력으로 끊어서 설계합니다.

왜 엣지에서 걸러야 하는가 — 용량 계산

진동 센서 1대를 1kHz로 샘플링, 값 하나에 4바이트

  1초  = 1,000 × 4 = 4,000 B  ≈ 4 KB/s
  하루 = 4 KB × 86,400초       ≈ 340 MB/일 (센서 1대)
  설비 20대                    ≈ 6.8 GB/일 → 월 200 GB 이상

→ 원파형을 전부 서버로 보내면 회선도 저장소도 못 버팁니다.

엣지에서 특징값만 뽑으면 (RMS, 피크, 첨도, 주요 주파수 등 1초 간격 20바이트)

  하루 = 20 B × 86,400        ≈ 1.7 MB/일 (센서 1대)
  설비 20대                    ≈ 34 MB/일

  → 약 200분의 1

원파형은 이상이 감지된 구간만 남기고 나머지는 특징값으로 축약하는 게 표준 설계입니다. "일단 다 쌓고 나중에 보자"는 비용도 크고, 실제로는 나중에도 안 봅니다.

데이터만 쌓고 안 보는 함정

수집을 시작한 회사에서 6개월쯤 뒤 자주 보이는 상태를 예로 들면 이렇습니다. (아래 숫자는 특정 조사값이 아니라 규모감을 보여주기 위한 예시입니다.)

• 태그 3,000개를 수집 중인데, 정작 매일 보는 화면은 없음
• 대시보드가 40개인데 접속 로그는 주 1회 미만
• 알람이 하루 200건 울려서 아무도 안 봄 (경보 피로)

판별법은 하나예요. 주간 생산회의 안건에 시스템 숫자가 올라오지 않으면 그 시스템은 죽은 겁니다.

• 지표를 3개로 줄이고, 그 3개를 회의 첫 화면으로 고정하세요.
• 알람은 조치 담당자와 조치 방법이 붙은 것만 남깁니다. 조치할 수 없는 알람은 소음입니다.
• 태그는 처음부터 다 붙이지 말고, 개선 과제 하나당 필요한 태그만 붙이세요.

구축 전 체크리스트

• 이 데이터로 어떤 판단을 할 것인지 한 문장으로 적었나
• 설비 보증 조건상 배선·제어반 접근이 가능한가
• 게이트웨이에 버퍼링과 시각 동기(NTP) 가 있나
• 제어망과 사무망이 분리되어 있나
• 태그 이름 규칙과 의미 정의를 문서로 남기나
• 하루 발생 데이터 용량과 3년치 저장 비용을 계산했나
• 센서 고장 시 누가 언제까지 교체하나 (센서도 소모품입니다)

"3D로 돌아가는 화면"은 디지털 트윈이 아닙니다

전시회나 제안서에서 공장이 3D로 돌아가는 화면을 보면 대단해 보이죠. 하지만 그 화면 대부분은 디지털 트윈이 아니라 시각화입니다. 구분을 못 하면 몇억 원짜리 판단을 잘못합니다.

관리자가 반드시 던져야 할 질문은 하나예요. "이 모델이 낸 결과가 실제 현장의 무엇을 바꿉니까?" 답이 "보기 좋습니다"면 그건 트윈이 아닙니다.

3단계로 구분하면 명확해집니다

국내 중소 제조 현장의 도입 사례 대부분은 디지털 섀도까지예요. 그것도 충분히 값을 합니다. 다만 그걸 "트윈 구축 완료"라고 부르면 다음 투자 판단이 왜곡돼요. 이미 다 한 줄 알고 예산이 안 나옵니다.

트윈이 성립하려면 4가지가 필요합니다

1. 신뢰할 수 있는 실시간 데이터 — 입력이 틀리면 모델은 정교할수록 더 크게 틀립니다.
2. 검증된 모델 — 물리 기반이든 데이터 기반이든, 실측과 비교한 오차가 숫자로 나와 있어야 합니다. "대략 맞습니다"는 검증이 아니에요.
3. 되먹임 경로 — 모델 결과가 스케줄러나 설비 조건으로 실제 연결돼야 합니다.
4. 유지 주체 — 금형·설비·품번이 바뀌면 모델도 고쳐야 합니다. 담당자가 없으면 6개월 뒤 죽은 모델이 됩니다.

> 4번이 가장 자주 무너집니다. 구축 업체가 철수하고 사내에 모델을 손댈 사람이 없으면, 라인 한 번 개조하는 순간 트윈은 그날부터 거짓말을 하기 시작합니다.

실제로 값을 하는 범위 (그리고 안 하는 것)

첫 과제는 레이아웃이나 스케줄 시뮬레이션이 정답에 가깝습니다. 설비를 옮기기 전에 시뮬레이션으로 병목을 찾는 일은 데이터가 적어도 되고, 결과가 눈에 보이고, 틀려도 되돌릴 수 있어요.

과장된 기대 vs 현실

트윈이 실패하는 3가지 이유

1. 검증 없는 모델

• 전형적 경로: 업체가 만든 모델을 실측과 대조하지 않고 그대로 수용 → 결과가 현장과 어긋나면 아무도 안 믿음
• 판별법: '실측 대비 오차 몇 %'를 문서로 못 받으면 검증한 게 아닙니다
• 대책: 준공 조건에 검증 시나리오와 허용 오차를 숫자로 넣으세요

2. 되먹임 경로 없음

• 전형적 경로: 시뮬레이션 결과가 보고서로만 나오고 스케줄러·설비 조건에 연결되지 않음
• 결과: 디지털 섀도인데 트윈 예산을 쓴 상태가 됩니다
• 대책: '이 결과가 어느 시스템의 어느 값을 바꾸나'를 착수 전에 지정하세요

3. 유지 주체 부재

• 전형적 경로: 구축 업체 철수 → 라인 개조·금형 변경 → 모델은 그대로 → 그날부터 거짓말 시작
• 판별법: 사내에 모델을 수정할 수 있는 사람이 있는지, 없다면 연간 유지 계약이 있는지
• 대책: 변경 발생 시 모델 갱신 책임과 비용을 계약서에 못 박으세요

(앞 단원에서 다룬 '목적 없는 도입'·'현장 미참여'·'데이터만 쌓고 안 봄'은 트윈에도 그대로 적용됩니다. 해당 단원을 참고하세요.)

1. 목적 없는 도입

• 전형적 경로: 공고 → 신청 → 업체 제안 그대로 수용 → 검수 통과 → 방치
• 판별법: "이 시스템으로 어떤 숫자가 몇 % 좋아집니까?"에 3초 안에 답이 안 나오면 목적이 없는 겁니다
• 대책: 착수 전에 개선 지표 1개와 목표치를 종이에 적고 사장·현장 반장이 같이 서명하세요. 이게 없으면 준공 검사 기준도 없습니다

2. 현장 미참여

• 전형적 경로: 사무실·전산이 요구사항 전부 결정 → 오픈 직전 현장 교육 30분
• 실제로 벌어지는 일: 장갑 낀 손에 터치가 안 먹고, 화면이 한국어 전용인데 작업자 절반이 외국인이고, 단말이 동선에서 5m 떨어져 있습니다
• 결과: 입력을 퇴근 전에 몰아서 함 → 데이터는 있는데 시각이 전부 틀림 → 사이클타임·가동률 분석이 통째로 불가능해집니다
• 대책: 요구사항 정의 단계부터 조·반장과 실제 입력할 작업자를 넣습니다. 화면은 스캔과 아이콘 중심, 언어는 다국어

3. 데이터만 쌓고 안 봄

• 전형적 경로: 태그 3,000개 수집 → 대시보드 40개 → 6개월 뒤 접속자 0명
• 판별법: 주간 생산회의 안건에 시스템 숫자가 안 올라오면 그 시스템은 죽었습니다
• 대책: 지표를 3개로 줄이고 회의 첫 화면으로 고정. 이상값은 사람이 찾는 게 아니라 시스템이 먼저 알리게 합니다. 단, 조치 담당자와 조치 방법이 붙은 알람만 남기세요

중소기업이 밟아야 할 순서

1단계  종이 일보 없애기        → 실적을 스캔으로 수집
2단계  설비 가동·정지 자동수집  → 비가동 원인 Top 3 도출
3단계  Top 3을 3개월 개선      → 개선 효과를 금액으로 산출
4단계  그 다음에 예지보전·시뮬레이션 검토

> 1~2단계 없이 3~4단계로 뛴 회사는 예외 없이 되돌아옵니다. 데이터의 품질이 모델 성능의 상한선이기 때문이에요. 입력이 하루 늦고 시각이 틀린 데이터로는 어떤 AI도 답을 못 냅니다.

제안서를 받았을 때 물어볼 것

• 이건 디지털 모델·섀도·트윈 중 어디까지인가
• 모델 검증은 어떻게 하나. 실측 대비 오차를 숫자로 제시할 수 있나
• 시뮬레이션 결과가 어느 시스템의 어느 값을 바꾸나
• 라인이나 금형이 바뀌면 모델은 누가, 얼마에 고치나
• 예지보전을 한다면 학습에 쓸 고장 데이터가 몇 건 있나
• 구축 후 3년간 라이선스·유지보수·클라우드 비용은 총 얼마인가