디지털트윈의 진짜 엔진은 3D가 아니라 '데이터 수집'이다 — 모드버스·OPC UA·MQTT 프로토콜 선택 가이드

"3D 모델은 다 만들었는데, 왜 트윈이 '살아' 있지 않을까요"

 

스마트팩토리 현장에서 디지털트윈 프로젝트를 맡으면, 대부분의 회의는 3D 모델링부터 시작됩니다. 어떤 엔진으로 렌더링할지, 모델 정밀도는 어느 정도로 할지. 그런데 제가 7년 동안 현장에서 본 프로젝트들의 성패는 정 반대편에서 갈렸습니다. 모델이 아무리 정교해도, 현장 설비의 상태가 실시간으로 들어오지 않으면 그건 그냥 예쁜 스크린샷에 불과합니다.

 

디지털트윈이 '트윈'인 이유는 데이터가 살아 있기 때문입니다. 그리고 그 데이터를 현장에서 끄집어내는 통로가 바로 통신 프로토콜입니다. 모드버스, OPC UA, MQTT — 이름은 익숙하지만 각자 성격이 완전히 다릅니다. 무엇을 기준으로 골라야 하는지, 현장에서 부딪히며 정리한 기준을 공유합니다.

 

모드버스 — 가장 단순하고, 가장 널리 쓰이는 '현장어'

 

모드버스는 산업 통신의 국어책 같은 존재입니다. 단순한 레지스터 구조(주소만 알면 값 하나를 읽는 방식)로 40년 넘게 살아남았고, 지금도 PLC·인버터·센서 대부분이 기본으로 지원합니다. 장점은 명확합니다. 배우기 쉽고, 장비 호환성이 넓고, 비용이 거의 안 듭니다.

 

단점도 분명합니다. 보안 기능이 사실상 없고(평문 통신), 데이터에 '의미'가 붙지 않습니다. 레지스터 주소 40001번의 값이 36.5라고 해서, 그게 온도인지 압력인지 알려면 별도의 해석 문서가 필요합니다. 소규모 설비의 현재 값을 빠르게 긁어오는 용도에는 여전히 최고지만, "공장 전체를 하나의 데이터 모델로 묶고 싶다"는 순간 한계가 드러납니다.

 

OPC UA — 데이터에 '의미'를 입히는 산업 표준

 

OPC UA는 모드버스의 뒤를 잇는 산업 표준 프로토콜입니다. 가장 큰 차이는 정보 모델(Information Model) 개념입니다. 값 하나하나에 이름, 단위, 상한·하한, 심지어 설비 계층 구조까지 붙어 전송됩니다. 즉, 데이터를 받는 쪽이 별도 문서 없이도 "이건 2호기 용접 로봇의 모터 온도"라는 걸 알 수 있습니다.

 

보안도 프로토콜 레벨에서 지원하고(인증서 기반 암호화), 서로 다른 벤더의 장비도 같은 언어로 묶을 수 있습니다. 제가 협동로봇의 부하 데이터를 디지털트윈으로 끌어올 때 가장 먼저 검토했던 것도 OPC UA였습니다. 다만 진입 비용이 있습니다. 장비가 OPC UA를 지원해야 하고, 모드버스보다 설정·튜닝이 복잡합니다. "표준화된 큰 그림을 그리고 싶다"면 정답에 가깝습니다.

 

MQTT — 가볍고 빠른 '메시지 우체통'

 

MQTT는 공장 설비 전용은 아니지만, IoT 센서 데이터를 모으는 데 특화된 경량 프로토콜입니다. 브로커라는 중앙 우체통을 두고, 센서가 값을 발행(Publish)하면 필요한 곳이 구독(Subscribe)하는 구조라 네트워크 부하가 작습니다. 수백·수천 개의 센서가 1초 단위로 데이터를 쏘는 환경에서 진가를 발휘합니다.

 

단, 메시지에 표준 의미 구조가 없어서 "값이 왔다"는 사실만 보장될 뿐, 그 값이 무엇인지는 약속(토픽 설계·페이로드 규격)으로 정해야 합니다. 잘 설계하면 가장 유연하고 확장성 좋은 수집망이 되지만, 설계 없이 붙이면 '값은 쏟아지는데 아무도 해석 못 하는' 데이터 쓰레기장이 됩니다.

 

그래서 뭘 골라야 할까 — 현장의 선택 기준

 

제 기준은 세 가지입니다. (1) 데이터에 의미가 필요한가 → 필요하면 OPC UA, 단순 값 수집이면 모드버스. (2) 센서 수가 수백 개인가 → MQTT를 앞단에 두고 수집. (3) 지금 당장 돈과 시간이 얼마나 있는가 → 소규모 파일럿은 모드버스로 시작해도 됩니다.

 

실제로는 섞어 씁니다. 설비 단은 모드버스로 긁어와서, 게이트웨이에서 OPC UA나 MQTT로 변환해 상위 시스템에 올리는 구성이 현장에서 가장 흔한 타협점입니다. 중요한 건 프로토콜 이름이 아니라, "이 데이터가 어디서 와서 어디에 쓰이는지"를 먼저 그리는 일입니다. 수집 경로 설계가 끝나면 디지털트윈은 절반 완성된 셈입니다.

마무리 — 3D보다 먼저, '살아 있는 데이터'부터

 

디지털트윈 프로젝트가 멈추는 가장 흔한 이유는 기술이 아니라 순서입니다. 3D 모델부터 만들고 데이터는 나중에 붙이려 하면, 모델은 완성됐는데 아무것도 움직이지 않는 텅 빈 트윈이 됩니다. 반대로 수집 경로를 먼저 잡아두면, 3D는 나중에 얼마든지 갈아끼울 수 있습니다.

 

여러분의 공장에는 어떤 프로토콜이 깔려 있나요? 아직 모드버스만 있다면, 다음 증설 때는 OPC UA 한 대라도 붙여보세요. 트윈이 '살아나는' 순간을 직접 보게 될 겁니다.