OPC UA Client·Server와 PubSub 차이｜산업 데이터 통신 구조 해석

산업용 PLC, SCADA, MES, 데이터 수집장치의 통신사양을 보면 OPC UA Client/Server, OPC UA PubSub라는 표현을 볼 수 있습니다.

둘 다 OPC UA에서 사용하는 통신모델이지만 데이터를 전달하는 구조가 다릅니다.

가장 간단하게 구분하면

Client/Server = 특정 Client가 Server에 연결해 데이터를 읽고 쓰거나 서비스를 요청

PubSub = Publisher가 데이터를 발행하면 관심 있는 Subscriber가 받아서 사용

하는 방식입니다.

따라서 장비의 Parameter를 조회하거나 설정할 때는 Client/Server가 적합하고, 하나의 생산데이터를 여러 시스템에 동시에 배포하거나 많은 장치를 연결해야 한다면 PubSub 구조가 유리할 수 있습니다.

OPC UA란?

OPC UA는 OPC Unified Architecture의 약자입니다.

산업현장의 서로 다른 장비와 소프트웨어가 제조사에 관계없이 데이터를 교환할 수 있도록 만든 표준화된 통신·정보모델 기술입니다.

단순히 숫자만 전송하는 것이 아니라

온도
압력
Motor Speed
Alarm
Device Status
Engineering Unit
Timestamp

같은 데이터의 의미까지 모델링할 수 있습니다.

또 Authentication, Encryption, Certificate 등의 보안기능도 OPC UA 구조에 포함됩니다.

Client·Server와 PubSub 기본 차이

구분	Client/Server	PubSub
통신관계	Client ↔ Server	Publisher → Subscriber
대표 구조	1:1 또는 여러 Client	1:N 데이터 배포에 유리
연결관계	상대방 Server에 직접 연결	Publisher·Subscriber 분리 가능
주요 목적	조회·설정·Method·Alarm	데이터 배포·확장성
요청/응답	사용	기본적으로 직접 Request/Response 없음
대표 활용	HMI·SCADA가 PLC 데이터 조회	PLC 데이터를 Edge·Cloud·MES 등에 배포
중간 Broker	필수 아님	MQTT Broker 등을 사용할 수 있음

두 방식은 경쟁관계라기보다 서로 다른 목적을 위해 함께 사용할 수 있는 OPC UA 통신모델입니다.

OPC UA Client/Server란?

Client/Server에서는 Client가 먼저 Server에 연결합니다.

예를 들어 PLC가 OPC UA Server이고 SCADA가 OPC UA Client라고 가정해보겠습니다.

구조는

SCADA Client

↓

OPC UA Request

↓

PLC OPC UA Server

↓

Response

형태가 됩니다.

Client는 Server에서

Variable 읽기
Variable 쓰기
Method 호출
Object 탐색
Alarm·Event 확인
Historical Data 조회

등의 기능을 사용할 수 있습니다.

실제 온도값을 읽는다면?

OPC UA Server에 다음 Node가 있다고 가정하겠습니다.

Temperature = 72.5°C

Client가 이 값을 읽으면 개념적으로

Client

Temperature 값을 보내줘

↓

Server

72.5°C

형태가 됩니다.

이처럼 특정 데이터를 필요할 때 요청해 읽는 것이 Client/Server 모델의 기본적인 방식입니다.

하지만 실제 OPC UA에서는 매번 Read 요청만 반복할 필요는 없습니다.

Subscription은 무엇일까?

OPC UA Client/Server에는 Subscription 기능이 있습니다.

예를 들어 SCADA에서 PLC의 온도를 계속 확인해야 한다고 가정해보겠습니다.

Client가

100ms마다 Temperature를 읽어줘

라고 계속 Read Request를 보내는 대신 Server에 Subscription과 MonitoredItem을 설정할 수 있습니다.

그러면 Server가 값의 변화를 감시한 뒤 Client에게 Notification을 전달합니다.

즉

Client → Subscription 생성

↓

Server → 값 Monitoring

↓

값 변화

↓

Server → Notification

구조입니다.

따라서

Client/Server는 항상 Client가 Polling해야 한다

라고 생각하면 정확하지 않습니다.

Client/Server Subscription과 PubSub는 같은 것일까?

아닙니다.

둘 다 데이터 변화가 발생하면 정보를 전달할 수 있지만 구조가 다릅니다.

Client/Server Subscription에서는 Client와 Server 사이에 Session과 Subscription 관계가 존재합니다.

Server는 어떤 Client가 연결돼 있고 누구에게 Notification을 전달해야 하는지 알고 있습니다.

반면 PubSub에서는 Publisher가 개별 Subscriber와 직접적인 Client/Server 관계를 만들지 않아도 됩니다.

Publisher는

이 데이터를 발행한다

는 역할에 집중하고,

Subscriber는

나는 이 데이터를 받겠다

는 역할을 담당합니다.

이러한 구조를 Decoupled Communication이라고 합니다.

OPC UA PubSub란?

PubSub는 Publish-Subscribe의 약자입니다.

데이터를 보내는 장치를

Publisher

데이터를 받는 장치를

Subscriber

라고 합니다.

예를 들어 PLC가 생산량 정보를 발행한다고 가정하겠습니다.

PLC Publisher

↓

Production Data

↓

SCADA Subscriber

MES Subscriber

Edge PC Subscriber

Cloud Gateway Subscriber

처럼 하나의 데이터가 여러 시스템으로 전달될 수 있습니다.

Publisher가 각 Subscriber에게 일일이 별도의 Read Response를 만드는 구조와 차이가 있습니다.

Publisher는 Subscriber를 알아야 할까?

PubSub의 중요한 특징 중 하나는 Publisher와 Subscriber를 분리할 수 있다는 것입니다.

Publisher는 자신의 데이터를 발행하지만

Subscriber가 1개인지
10개인지
현재 연결되어 있는지

를 반드시 직접 관리할 필요는 없습니다.

Subscriber 역시 데이터를 생산한 Application과 직접적인 Request/Response Session을 구성하지 않고 필요한 메시지를 받아 처리할 수 있습니다.

이 구조 덕분에 장치와 시스템 수가 많아질수록 확장하기가 편리합니다.

Brokerless 방식은 무엇일까?

OPC UA PubSub는 Broker 없이 데이터를 전달하는 방식도 지원합니다.

대표적으로 UDP 기반 Datagram Communication을 사용할 수 있습니다.

구조를 단순화하면

Publisher

↓

UDP Network

↓

Subscriber A
Subscriber B
Subscriber C

형태입니다.

산업용 네트워크 내부에서 여러 Controller나 장비에 데이터를 빠르게 배포할 때 사용할 수 있습니다.

이런 방식에서는 Network Infrastructure 자체가 데이터 전달을 담당합니다.

Broker 기반 PubSub는 무엇일까?

또 다른 방법은 Message Broker를 사용하는 것입니다.

대표적인 예가 MQTT입니다.

구조는

PLC Publisher

↓

MQTT Broker

↓

SCADA Subscriber
MES Subscriber
Cloud Subscriber

형태입니다.

Publisher는 Broker의 특정 Topic 등에 데이터를 발행하고 Subscriber는 관심 있는 데이터를 구독합니다.

따라서 공장 데이터와 IT·Cloud 시스템을 연결할 때 활용하기 좋습니다.

MQTT와 OPC UA PubSub는 같은 것일까?

같은 개념은 아닙니다.

MQTT

Message를 전달하는 Messaging Transport Protocol

OPC UA PubSub

어떤 산업데이터를 어떤 구조와 의미로 Publish·Subscribe할지 정의하는 OPC UA 통신모델

입니다.

OPC UA PubSub에서 MQTT를 전송수단 중 하나로 사용할 수 있습니다.

즉

OPC UA PubSub over MQTT

구성이 가능합니다.

단순 MQTT 통신과 OPC UA PubSub를 동일한 것으로 생각하면 안 됩니다.

UADP와 JSON은 무엇일까?

OPC UA PubSub에서는 데이터를 메시지로 표현하는 방법도 여러 가지가 있습니다.

대표적으로

UADP

JSON

이 있습니다.

UADP

Binary 형태의 효율적인 메시지 인코딩입니다.

데이터 크기와 처리효율이 중요한 산업 네트워크에서 사용할 수 있습니다.

JSON

사람이 읽기 쉽고 Web·Cloud 시스템에서 다루기 편리한 구조입니다.

따라서

산업용 제어 네트워크 → UADP

IT·Cloud Integration → JSON

과 같은 구성이 가능하지만 실제 선택은 시스템 요구사항과 지원 Profile에 따라 달라집니다.

1:N 구조에서 PubSub가 유리한 이유

PLC 하나의 데이터를 다섯 시스템에서 사용한다고 가정해보겠습니다.

Client/Server에서는 각각

SCADA Client
MES Client
Historian Client
Analytics Client
Maintenance Client

가 OPC UA Server에 연결할 수 있습니다.

Server는 여러 Client의 Session과 Subscription을 관리해야 합니다.

PubSub에서는 PLC가 데이터를 한 번 Publish하면 여러 Subscriber가 같은 데이터를 소비할 수 있도록 구성할 수 있습니다.

즉 데이터 소비자가 늘어나더라도 Publisher와 Subscriber가 직접 강하게 결합되지 않는 것이 장점입니다.

그렇다면 PubSub가 항상 더 좋은 방식일까?

아닙니다.

예를 들어 HMI에서 Motor Parameter 하나를 변경해야 한다고 가정하겠습니다.

Motor Max Speed 값을 읽고 1500rpm으로 변경

하려면 특정 장비에 명확하게 요청하고 결과를 받아야 합니다.

이런 작업에는 Client/Server가 훨씬 자연스럽습니다.

반면 공장의

생산수량
온도
전력사용량
설비상태

를 여러 시스템에 지속적으로 배포하는 경우에는 PubSub가 더 적합할 수 있습니다.

즉 용도에 따라 선택해야 합니다.

실제 공장에서는 두 방식을 함께 사용한다

둘 중 하나만 선택해야 하는 것은 아닙니다.

예를 들어 PLC의 OPC UA Server에 Engineering PC가 연결되어

Parameter 설정
진단
Device Configuration

을 Client/Server로 수행합니다.

동시에 PLC가 생산데이터를

MES
Historian
Edge Computer
Cloud

로 PubSub 방식으로 발행할 수도 있습니다.

구조를 단순화하면

Engineering PC

↕ Client/Server

PLC

↓

PubSub

↓

MES / Historian / Edge / Cloud

형태입니다.

이처럼 Client/Server와 PubSub는 서로 보완적인 관계입니다.

Client/Server에서 Server는 데이터를 가지고 있어야 할까?

OPC UA Server는 데이터를 단순한 Register 번호가 아니라 Address Space와 Information Model 형태로 제공합니다.

예를 들어

ns=2;s=Machine1.Motor.Speed

와 같은 Node에

Value
Data Type
Engineering Unit
Description
Status
Timestamp

등의 정보를 연결할 수 있습니다.

Client는 Server의 Address Space를 Browse하면서 장비가 어떤 데이터를 제공하는지 확인할 수 있습니다.

이런 Discovery와 Information Modeling 능력은 OPC UA Client/Server의 중요한 특징입니다.

PubSub에서도 OPC UA의 데이터 의미를 유지할 수 있을까?

가능합니다.

PubSub가 단순히 숫자만 무작위로 Broadcast하는 것은 아닙니다.

OPC UA의 DataSet과 Metadata 구조를 통해 어떤 데이터가 전달되는지 정의할 수 있습니다.

예를 들어

Temperature
Pressure
Machine State

라는 데이터 세트를 구성해 Publisher가 발행할 수 있습니다.

Subscriber는 정의된 데이터 구조에 따라 메시지를 해석합니다.

따라서 OPC UA의 정보모델을 기반으로 OT와 IT 시스템 사이에서 의미 있는 데이터를 전달하는 데 활용할 수 있습니다.

실제 적용사례로 비교해보자

공장 압축기의 데이터를 다음 시스템에서 사용한다고 가정하겠습니다.

압축기에서 발생하는 데이터는

Pressure = 7.2bar

Temperature = 65°C

Motor Current = 12.5A

입니다.

Client/Server 사용

정비 프로그램에서 현재 값을 조회하고 Motor 설정값을 변경합니다.

Maintenance Client ↔ Compressor OPC UA Server

특정 장비를 탐색하고 설정하기 때문에 Client/Server가 적합합니다.

PubSub 사용

같은 데이터를

MES
Energy Management
Cloud Analytics
Historian

에서 동시에 사용합니다.

이 경우 Publisher가 DataSet을 발행하고 여러 Subscriber가 받아 사용하는 구조가 편리할 수 있습니다.

보안구조도 같은가?

두 통신모델 모두 OPC UA의 보안개념을 사용할 수 있지만 구조는 다릅니다.

Client/Server에서는 대표적으로

Secure Channel
Application Certificate
User Authentication
Message Signing
Encryption

등을 사용합니다.

PubSub에서는 Publisher와 Subscriber가 직접 Session을 만들지 않을 수 있기 때문에 PubSub Security와 Key 관리방식을 사용합니다.

특히 Broker를 사용하는 경우에는 MQTT·Broker 자체의 보안설정도 함께 고려해야 할 수 있습니다.

따라서

OPC UA니까 자동으로 암호화된다

고 생각하면 안 됩니다.

실제 Security Policy와 구성상태를 확인해야 합니다.

흔히 잘못 해석하는 부분

첫 번째는

“Client/Server는 Polling만 한다.”

라는 생각입니다.

Subscription과 MonitoredItem을 이용해 Server가 변경 데이터를 Notification 형태로 전달할 수 있습니다.

두 번째는

“Subscription이 있으니 PubSub와 동일하다.”

라는 생각입니다.

Client/Server Subscription에는 Client와 Server의 Session 관계가 존재하지만 PubSub는 Publisher와 Subscriber를 분리하는 구조입니다.

세 번째는

“OPC UA PubSub는 MQTT다.”

라는 생각입니다.

MQTT는 PubSub에서 사용할 수 있는 전송방식 중 하나입니다.

네 번째는

“PubSub가 최신 방식이므로 Client/Server를 대체한다.”

라는 생각입니다.

Parameter 설정·Browse·Method 호출 같은 작업에서는 Client/Server가 여전히 매우 중요한 역할을 합니다.

정리

OPC UA Client/Server와 PubSub의 차이를 이해할 때 가장 중요한 것은 누가 누구에게 데이터를 요청하는지입니다.

Client/Server

Client가 특정 Server와 연결
Read·Write·Browse·Method 사용
Subscription 가능
장비설정·HMI·SCADA에 적합

PubSub

Publisher가 데이터 발행
Subscriber가 필요한 데이터 구독
Publisher와 Subscriber 분리
UDP 또는 MQTT 같은 전송방식 활용 가능
다수 시스템으로 데이터 배포할 때 유리

로 정리할 수 있습니다.

실제 산업시스템에서는

장비 탐색·설정·제어 → Client/Server

생산데이터 대량 배포 → PubSub

처럼 두 방식을 함께 활용하는 것이 가능합니다.

따라서 OPC UA 장비의 사양을 확인할 때는 단순히 OPC UA 지원만 보는 것이 아니라 Client/Server, Subscription, PubSub, UADP·JSON, UDP·MQTT 및 Security 지원범위까지 확인하는 것이 중요합니다.

참고자료

• OPC Foundation – OPC UA Part 1: Overview and Concepts: OPC UA Client/Server는 Client가 Server의 데이터와 Service에 접근하고 Event 등을 받을 수 있는 구조이며, 하나의 Application이 Client와 Server 역할을 동시에 가질 수도 있습니다. OPC UA 온라인 참조
• OPC Foundation – OPC UA Part 14: PubSub: PubSub는 Client/Server 모델을 보완하는 Publish-Subscribe 통신모델로, Publisher와 Subscriber가 직접 Request/Response를 교환하지 않고 Message Oriented Middleware를 통해 데이터를 배포하도록 정의합니다. 현재 OPC Foundation Reference 기준 Part 14의 Current Release는 **v1.05.06(2025-10-22)**입니다. OPC UA 온라인 참조
• OPC Foundation – PubSub Decoupling by Middleware: PubSub는 Brokerless Datagram 방식에서 UDP 등을 사용할 수 있고, Broker 기반에서는 MQTT와 같은 Messaging Protocol을 사용할 수 있습니다. OPC UA 온라인 참조
• OPC Foundation – PubSub Fields of Application: Controller 간 데이터교환, HMI, 비동기 Workflow, Logging과 다수 시스템으로의 데이터배포 등 Publisher와 Subscriber의 결합을 낮춰야 하는 환경에서 PubSub를 활용할 수 있습니다. OPC UA 온라인 참조