2026-10-20
MQTT과 OPC UA를 활용한 Microsoft 제조 환경: Azure IoT Operations + Fabric 아키텍처

공장 현장 정리하기: MQTT vs OPC UA, 그리고 단절된 제조 데이터의 진실. 왜 최신 공장들은 ERP, MES, Azure 시스템을 갖추고도 여전히 수작업 내보내기와 추측에 의존하고 있을까요? 이번 에피소드는 기술적 과장을 걷어내고 핵심 문제를 다룹니다. 바로 제조 데이터에 대한 근본적인 신뢰 부족입니다. 많은 사람들이 산업 연결성을 MQTT와 OPC UA 간의 승자독식 싸움으로 규정하지만, 이는 요점을 완전히 놓치고 있습니다. 작업자가 기업 대시보드보다 현장 HMI를 더 신뢰하거나, 모든 OEE 리뷰가 어느 숫자가 맞는지에 대한 논쟁으로 번진다면, 그것은 프로토콜 문제가 아니라 의미(시맨틱) 문제입니다. 기술만으로는 의미가 만들어지지 않습니다. 진정으로 연결된 공장을 구축하려면, 기술을 확장하기 전에 생산 문제를 먼저 정의하고 생산 이벤트에 대한 공통 언어부터 세워야 합니다.
UNTANGLING THE PLANT FLOOR: MQTT vs OPC UA & THE TRUTH ABOUT DISCONNECTED MANUFACTURING DATA왜 현대 공장은 ERP, MES, Azure 시스템을 갖추고 있음에도 여전히 수동 내보내기와 추측에 의존하여 운영되고 있을까? 이번 에피소드는 기술적 과장을 걷어내고 핵심 문제를 다룹니다. 바로 제조 데이터에 대한 근본적인 신뢰 부족입니다. 사람들은 산업용 연결성을 MQTT와 OPC UA 사이의 승자독식 전쟁으로 규정하곤 하지만, 이는 요점을 완전히 놓친 것입니다. 작업자가 기업 대시보드보다 현장 HMI를 더 신뢰하거나, 모든 OEE 리뷰가 어느 숫자가 맞는지에 대한 논쟁으로 흐른다면, 그것은 프로토콜 문제가 아니라 의미(시맨틱) 문제입니다. 기술만으로는 의미가 만들어지지 않습니다. 진정으로 연결된 공장을 구축하려면, 기술 스택을 확장하기 전에 먼저 생산 문제를 정의하고 생산 이벤트에 대한 공유 언어를 확립해야 합니다.
이번 에피소드에서 다루는 내용:
- 플랜트 플로어의 신뢰 격차: ERP와 Azure에 막대한 투자를 했음에도 플래너는 스프레드시트에 의존하고 작업자는 로컬 HMI를 신뢰하는 이유.
- 숫자 전쟁: 주간, 오후, 야간 교대조가 서로 다른 세 가지 생산 수량을 보고하는 이유, 그리고 그중 어느 것도 반드시 틀린 것이 아니라 공정의 서로 다른 지점을 설명하고 있다는 점.
- MQTT vs. OPC UA – 경쟁자가 아닌 서로 다른 역할:
- MQTT (전송): 메시지를 효율적으로 라우팅하고, 게시자와 소비자를 분리하며, 불안정한 네트워크를 처리하는 데 뛰어난 경량 게시/구독 프로토콜. 페이로드 내용은 신경 쓰지 않고 봉투(envelope)를 전달할 뿐입니다.
- OPC UA (의미): 대상이 무엇인지, 그리고 값이 무엇을 나타내는지를 정의합니다. 구조화된 모델, 변수 타입, 공학 단위, 애플리케이션 계층에 내장된 보안을 갖춘 탐색 가능한 주소 공간을 제공합니다.
- 새로운 대시보드가 분절된 데이터를 해결하지 못하는 이유: 깔끔한 차트가 의미를 만들어내지는 않습니다. 대시보드는 기계로부터의 맥락 없이는 상태 코드 "1"이 가동, 대기, 고장 중 무엇을 뜻하는지 알 수 없습니다.
- 엣지의 실질적 역할: 데이터를 다섯 개의 하위 시스템에서 각각 매핑하는 대신, 소스 근처에서 한 번 정규화하는 것이 중요한 이유.
- 명명 계약으로서의 ISA-95: 작업 지시나 제품 같이 변화하는 비즈니스 맥락을 적용하기 전에, 기업에서 셀에 이르는 계층 구조를 자산을 일관되게 찾기 위한 안정적인 지도로 활용하기.
- 통합 네임스페이스(UNS) 과장: UNS를 새로운 마스터 데이터베이스나 노력 없이 공유 운영 모델을 만들어 주는 만능 해결책이 아니라, IT와 OT가 사실(fact)을 게시하는 공통 이벤트 공간으로 이해하기.
- MQTT 토픽 및 페이로드 설계:
- 제품 코드, 오더 번호와 같은 일시적 맥락을 정적 토픽 경로에 밀어넣는 것의 위험성.
- 토픽 이름은 대소문자를 구분하므로 엄격한 소문자 규칙이 필요한 이유.
- "가벼운 JSON의 비용"과 시맨틱 계약(타입, 단위, 계보)이 필수적인 이유.
- Sparkplug B: MQTT에 산업용 규칙(정의된 토픽, 출생/사망 수명주기 상태)을 추가하는 방법, 그러나 여전히 생산 이벤트가 실제로 무엇을 의미하는지 정의할 필요성을 대체하지는 못한다는 점.
- Azure IoT Operations & Microsoft Fabric: Microsoft의 엣지 데이터 플레인 패턴, Arc 지원 Kubernetes에서 모듈형 서비스를 실행하는 방식, 그리고 프로덕션 수준 배포에 IT/OT 하이브리드 역량이 요구되는 이유.
- 제어 플레인과 데이터 플레인의 경계: 로컬 제어 루프가 클라우드와 독립적으로 유지되어야 하는 이유, 그리고 브로커는 결코 안전 컨트롤러가 될 수 없는 이유.
"전송과 의미는 서로 다른 역할입니다. MQTT는 메시지를 필요한 곳으로 라우팅하고, OPC UA는 기계 데이터에 구조와 맥락을 제공합니다."
태그: #ManufacturingData #MQTT #OPCUA #UnifiedNamespace #ISA95 #IndustrialIoT #OEE #AzureIoTOperations #MicrosoftFabric #ITOTconvergence #SmartFactory
이 팟캐스트의 후원자가 되세요: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.
Apple Podcasts · Spotify · YouTube · Deezer
MQTT and OPC UA in Microsoft Manufacturing: Azure IoT Operations + Fabric Architecture (English)