IIoT 아키텍처 검토는 대개 벤더 슬라이드 위에서 이뤄집니다. 그러나 슬라이드의 아키텍처 다이어그램은 대부분 아름답고, 현장의 차이는 디테일에서 갈립니다. UNS와 OPC UA, 그리고 IIoT 플랫폼을 실전 기준으로 평가하는 법을 정리합니다.
먼저, 역할을 섞지 말 것 — OPC UA와 UNS
가장 흔한 혼동은 OPC UA와 UNS를 경쟁 관계로 놓는 것입니다. 둘은 층이 다릅니다.
- OPC UA — 설비와 직접 대화하는 표준. 요청-응답(read/write)과 구독을 모두 제공하고, 풍부한 정보 모델을 갖습니다. "설비의 언어"입니다.
- UNS(Unified Namespace) — MQTT·Sparkplug B 위에 자산 계층을 토픽 구조로 미러링한 발행-구독 허브. 전사의 모든 시스템이 같은 주소 체계로 데이터를 구독합니다. "조직의 언어"입니다.
건강한 아키텍처는 보통 둘을 함께 씁니다: 남쪽(설비)은 OPC UA를 비롯한 현장 프로토콜로 수집·재제공하고, 북쪽(전사)은 UNS로 개방하는 구조입니다.
실전 평가 8축
1. 프로토콜 커버리지 — 데모의 3종이 아니라 우리 라인의 전 목록으로 물어야 합니다. 국산 PLC(LS·미쓰비시), CNC(FOCAS), 반도체(SECS/GEM), 전력(DNP3·IEC 61850)까지 — "몇 종을 지원하는가"보다 "우리 설비 목록 중 몇을 지원하는가"가 질문입니다.
2. 정보 모델과 시맨틱 — 태그가 계층(ISA-95) 위에 정리되는가, 자산 간 관계(온톨로지)까지 표현되는가. 시맨틱 없는 수집은 데이터 늪의 시작입니다.
3. 실시간성 — 평균이 아니라 꼬리 지연(수집 지연 ms 단위)과 지속 처리량(msg/s, ev/s)을 수치로. "실시간 지원"이라는 형용사는 평가 항목이 아닙니다.
4. 신뢰성 — 네트워크가 끊기면 데이터는 어디에 남는가(store-and-forward 용량·재전송), 게이트웨이가 죽으면 무엇이 이어받는가(이중화·페일오버 시간).
5. 보안과 배치 제약 — 폐쇄망·에어갭에서 완결 동작하는가, 인증·TLS·감사 이력은 어느 층까지 내려가는가. 클라우드 필수 여부는 산업별로 탈락 조건이 됩니다.
6. 개방성 — REST API의 개수와 문서 수준, 발행-구독 개방(UNS), 그리고 AI 시대의 새 기준 — 읽기 전용으로 안전하게 AI에 개방할 수 있는가.
7. 확장성 — 태그 1만에서 10만으로, 한 공장에서 다섯 공장으로 갈 때 아키텍처가 그대로인가. 멀티사이트 통합 뷰가 기본인가, 커스텀인가.
8. 운영성 — 플랫폼이 스스로를 계측하는가(파이프라인 상태·레이턴시·가동률 통계), 장애를 플랫폼 로그로 진단할 수 있는가. 운영 없는 아키텍처 평가는 반쪽입니다.
현장에서 쓰는 체크리스트
- 우리 설비 목록 대비 드라이버 커버리지 표를 받았다
- 수집 지연·처리량을 우리 데이터로 PoC 실측했다
- 케이블을 뽑아 봤다 — 복구 후 데이터 공백이 없었다
- 게이트웨이 하나를 껐다 — 페일오버 시간을 측정했다
- 인터넷 없이 설치·운영이 되는지 확인했다
- 자산 계층·온톨로지에 우리 코드 체계를 매핑해 봤다
- MES·ERP와 실제 왕복(레시피 하달·실적 상신)을 시연받았다
- 운영 통계 화면에서 파이프라인 병목을 직접 봤다
결론
아키텍처 평가의 본질은 다이어그램 비교가 아니라 실패 조건의 시연입니다. 끊고, 끄고, 부하를 걸어 보십시오. PlantPulse®는 이 여덟 축 — 42종 드라이버, 온톨로지·UNS, 8ms·51만 ev/s, store-and-forward·HA, 에어갭 완결, 150+ API·읽기 전용 MCP, 멀티사이트, 자가 계측 — 을 기준으로 설계됐고, 같은 기준으로 평가받기를 권합니다.
주제 참고: How to Evaluate UNS, OPC UA and IIoT Architecture in Practice (Medium · Coformation)