"Sparkplug는 OT 데이터를 표준 방식으로 묶어내는 산업 IoT의 사실상 공통 언어가 되어가고 있다." — Eclipse Foundation

2023년 11월, Eclipse Foundation의 Sparkplug 3.0 사양이 ISO/IEC 20237로 정식 국제 표준이 되었다. Eclipse 프로젝트가 ISO/IEC 표준으로 승격된 최초의 사례다. 표준화 이전부터 MQTT는 경량 발행-구독(pub/sub) 모델로 산업 현장의 사실상 표준 메시징 프로토콜 자리를 굳혀 왔지만, "토픽을 어떻게 구성하고 페이로드에 무엇을 담을 것인가"는 여전히 벤더와 현장마다 제각각이었다. Sparkplug B는 바로 이 공백, 즉 MQTT 위에 산업 데이터의 의미와 상태를 표준화하는 계층을 채운다.

그렇다면 Sparkplug B는 구체적으로 무엇을 표준화하며, 왜 OPC UA와 경쟁이 아니라 보완 관계로 자리 잡았는가? 그리고 2025년 들어 "Sparkplug를 Unified Namespace(UNS)의 중심에 둘 수 있는가"를 둘러싼 논쟁은 어떤 의미를 갖는가? 이 글은 사양의 핵심 메커니즘부터 최신 아키텍처 합의, 그리고 현장 적용의 함의까지를 정리한다.

엣지에서 클라우드까지, Sparkplug B는 디바이스 상태와 데이터를 하나의 일관된 모델로 연결한다.

---

1. Sparkplug B의 세 가지 기둥

Sparkplug B가 MQTT에 더하는 가치는 세 가지로 압축된다. 첫째, 정의된 토픽 네임스페이스다. spBv1.0/{group_id}/{message_type}/{edge_node_id}/{device_id} 형태로 구조를 고정해, 데이터가 어느 그룹·노드·디바이스에서 왔는지를 토픽만 보고도 알 수 있게 한다. 둘째, Google Protocol Buffer 기반 바이너리 페이로드다. JSON 대비 메시지 크기를 크게 줄이면서 메트릭의 데이터 타입과 타임스탬프, 품질 정보를 구조적으로 담는다. 셋째, 디바이스 생명주기 모델이다. 디바이스의 등장과 소멸, 상태를 네트워크 전체가 일관되게 인지하도록 만든다.

• 토픽 네임스페이스: 데이터 출처와 계위(hierarchy)를 자기 기술적(self-describing)으로 표현
• Protobuf 페이로드: 압축된 바이너리로 대역폭 절감, 타입·타임스탬프·품질 내장
• 생명주기 모델: 일시적 연결 환경에서도 상태 정합성 유지

2. Report-by-Exception과 대역폭 — 90% 절감의 메커니즘

Sparkplug의 설계 철학 중 가장 산업적인 것이 Report-by-Exception(RBE, 예외 보고)다. "데이터와 디바이스 상태는 변경이 있을 때만 전송한다"는 원칙으로, 폴링(polling) 기반 시스템이 초래하는 불필요한 트래픽을 근본적으로 줄인다. 여기에 메트릭 별칭(metric aliasing)이 더해진다. 최초의 NBIRTH·DBIRTH 메시지에서 각 메트릭에 정수 별칭을 부여하고, 이후의 NDATA·DDATA 메시지에서는 긴 문자열 이름 대신 정수 별칭만 전송한다.

• 메트릭 별칭으로 고빈도 텔레메트리의 메트릭당 오버헤드를 90% 이상 절감
• Protobuf 바이너리 인코딩으로 JSON 대비 메시지 크기 대폭 축소
• Store-and-forward로 네트워크 단절 시 데이터를 버퍼링했다가 복구 시 재전송

이 세 가지가 결합되면 셀룰러나 위성처럼 대역폭이 제한되고 비용이 비싼 회선에서도 수천 개 태그를 실시간에 가깝게 운용할 수 있다. 대역폭은 곧 비용이며, 산업 IoT의 확장성은 "얼마나 적게 보내고도 충분한가"에 달려 있다.

3. 상태 인식 — Birth/Death 인증서

전통적인 폴링 시스템에서는 "디바이스가 지금 살아 있는가, 마지막 값은 신뢰할 수 있는가"를 알기 어렵다. Sparkplug B는 출생·사망 인증서(Birth/Death Certificate)로 이 문제를 해결한다. 엣지 노드가 접속하면 NBIRTH로 자신의 메타데이터와 보유 메트릭 전체를 선언하고, 하위 디바이스는 DBIRTH로 구성을 보고한다. 반대로 정상 종료든 예기치 못한 장애든 노드가 사라지면 NDEATH·DDEATH가 네트워크에 알린다.

핵심은 MQTT의 Last Will and Testament(LWT) 기능과 결합된다는 점이다. 브로커는 노드와의 연결이 끊기면 사전에 등록된 NDEATH를 자동 발행한다. 덕분에 모든 구독자(SCADA, 이력 DB, 분석 엔진)는 "이 노드의 데이터는 지금 스테일(stale) 상태"라는 사실을 즉시 공유한다. 상태 정합성이 프로토콜 차원에서 보장되는 것이다.

4. OPC UA vs Sparkplug B — 경쟁이 아니라 분업

OPC UA는 풍부한 객체 모델과 타입 시스템, 정교한 StatusCode를 갖춘 요청-응답(request-response) 기반 표준이다. 의미론(semantics)이 강력하지만 그만큼 무겁고, 애플리케이션이 특정 디바이스에 직접 의존하는 강결합(tightly coupled) 구조를 만든다. 반면 Sparkplug B는 발행-구독 모델로 디바이스와 애플리케이션이 서로를 직접 알 필요 없이 브로커를 매개로 느슨하게 결합(loosely coupled)된다.

현장에서 자리 잡은 지배적 패턴은 둘 중 하나를 고르는 것이 아니라 역할 분담이다. PLC에서 집계 게이트웨이까지의 사우스바운드(southbound)는 타입 시스템과 StatusCode가 중요한 OPC UA가, 게이트웨이에서 전사 시스템까지의 노스바운드(northbound)는 팬아웃과 브로커 메시가 중요한 MQTT/Sparkplug B가 맡는다. Inductive Automation의 Ignition, PTC Kepware 같은 OT 미들웨어가 OPC UA·독자 프로토콜을 MQTT로 변환하고, HiveMQ 같은 브로커가 이를 전사로 확산하며 Kafka로 연계하는 구성이 대표적이다.

OPC UA 사우스바운드 + Sparkplug B 노스바운드 — 2025년 현장의 지배적 아키텍처 패턴.

5. 2025년의 논쟁 — UNS 프로토콜로서의 한계

Sparkplug를 둘러싼 가장 뜨거운 논의는 "이것이 Unified Namespace의 중심 프로토콜이 될 수 있는가"였다. 2025년 2월, HiveMQ의 Jens Deters는 그간 일부에서 주장하던 입장을 공개적으로 거두며, "Sparkplug는 관심 있는 메트릭만 선택적으로 구독할 메커니즘이 없어 UNS 프로토콜로는 적합하지 않다"고 정리했다. Sparkplug의 토픽 구조는 노드·디바이스 단위로 묶여 있어, 특정 메트릭 하나만 골라 구독하기가 어렵다는 한계 때문이다.

이 논쟁이 시사하는 바는 명확하다. Sparkplug B는 엣지-텔레메트리 전송 표준으로서는 탁월하지만, 전사 데이터의 의미 계층(semantic layer)인 UNS 자체와는 다른 층위라는 것이다. 실제로 UNS를 생산 단계까지 운영 중인 조직은 응답자의 13% 수준으로, 아직 초기 도입자 영역에 머문다. 따라서 Sparkplug B는 "UNS의 전부"가 아니라 "UNS를 채우는 견고한 파이프라인"으로 이해하는 것이 정확하다.

사례 — 표준화가 만든 상호운용성

Eclipse Foundation은 Sparkplug v3.0과 ISO/IEC 20237이 엄밀하게 동등하며, 어느 한쪽을 충실히 구현한 제품은 Eclipse가 발행하는 Technology Compatibility Kit(TCK)를 통과한다고 밝혔다. 이는 곧 벤더 종속 없이 "표준 적합성"을 객관적으로 검증할 수 있다는 의미다. Opto22, Inductive Automation, HiveMQ를 비롯한 다수 공급사가 이 표준을 채택했고, Microsoft Azure Event Grid의 MQTT 브로커 역시 Sparkplug B를 지원한다. 클라우드와 엣지, OT와 IT를 잇는 공통 어휘가 표준 차원에서 마련된 셈이다(출처: Eclipse Foundation, ARC Advisory Group, HiveMQ).

PlantPulse가 답하는 방식

코펜스(Kopens, ㈜한국오픈솔루션)의 PlantPulse는 이 분업 구조를 플랫폼 차원에서 내장한다. 200개 이상의 산업 프로토콜을 지원해 사우스바운드에서는 OPC UA·Modbus·레거시 프로토콜을 수집하고, 노스바운드에서는 MQTT/Sparkplug B로 전사에 데이터를 확산한다. ISA-95 자산 모델링을 통해 수집된 데이터에 의미를 부여하므로, Sparkplug B가 전달한 메트릭이 곧 UNS의 의미 계층으로 자연스럽게 연결된다.

또한 PlantPulse는 엣지-클라우드 하이브리드 구조 위에서 store-and-forward와 상태 인식을 실무적으로 보장하고, 첫날부터 내장된 거버넌스와 AI/ML/MLOps 통합으로 "데이터를 모으는 단계"를 넘어 "운영에서 의사결정으로" 이어지게 한다. Sparkplug B가 표준으로 정의한 전송 계층과, 그 위에서 의미·거버넌스·분석을 책임지는 플랫폼 계층이 만나는 지점이 바로 PlantPulse가 겨냥하는 영역이다.

마치며

Sparkplug B는 MQTT를 산업 등급으로 끌어올린 표준이다. 토픽 네임스페이스, Protobuf 페이로드, 생명주기 모델이라는 세 기둥과 Report-by-Exception·메트릭 별칭·store-and-forward가 결합해, 제한된 대역폭에서도 신뢰할 수 있는 상태 기반 데이터 전송을 가능하게 한다. ISO/IEC 20237 표준화는 이 기술을 벤더 종속에서 해방시켜 글로벌 생태계의 공통 어휘로 만들었다.

동시에 2025년의 논쟁은 균형 잡힌 시각을 요구한다. Sparkplug B는 엣지 전송의 강력한 표준이되, UNS의 의미 계층 그 자체는 아니다. 따라서 성공적인 산업 데이터 아키텍처는 OPC UA의 의미론, Sparkplug B의 전송 효율, 그리고 그 위의 의미·거버넌스 계층을 함께 설계하는 데 달려 있다. (관련 자료: Eclipse Foundation Sparkplug Specification v3.0 / ISO·IEC 20237:2023, ARC Advisory Group, HiveMQ "OPC UA vs MQTT Sparkplug", Kai Waehner "Unified Namespace vs Data Product 2025", Opto22 White Paper)

© KOPENS — Industrial DataOps & PlantPulse Platform

Powered by Froala Editor