정보관리기술사 학습 노트
← 목록으로
네트워크
#OPC UA#IEC 62541#산업 IoT#OT·IT 통합#정보모델#PubSub#산업 보안
최종 업데이트 · 2026-09-30

OPC UA(IEC 62541) 기반 산업 데이터 상호운용 아키텍처

1. 개요

가. 정의

OPC UA(Open Platform Communications Unified Architecture)는 산업 자동화 시스템의 장치와 응용 간에 데이터를 안전하게 교환하고, 데이터의 구조와 의미까지 표현하기 위한 플랫폼 독립형 통신·정보모델 표준이다.

산업 현장에는 PLC, CNC, 센서, SCADA, MES, ERP 등 서로 다른 세대와 제조사의 시스템이 공존한다. 이들은 통신 방식뿐 아니라 태그 이름, 단위, 상태 코드, 장비 계층을 다르게 정의하기 때문에 연결만으로 데이터 의미가 일치하지 않는다. OPC UA는 통신 규격과 정보 모델을 함께 제공하여 단순 신호 전달에서 의미 기반 상호운용으로 확장한다.

기존 OPC Classic은 Windows COM/DCOM에 강하게 의존하여 방화벽 통과, 이기종 운영체제, 인터넷 규모 확장에 제약이 있었다. OPC UA는 운영체제와 프로그래밍 언어에 중립적인 구조로 이를 개선하고, 임베디드 장치부터 현장 서버와 클라우드까지 동일한 기반을 제공한다. 표준의 핵심은 하나의 전송 프로토콜이 아니라 정보 모델, 서비스, 통신 매핑, 보안, 적합성 규칙을 묶은 아키텍처라는 데 있다.

나. 등장 배경과 필요성

스마트 제조에서는 설비·생산·품질·에너지 데이터를 여러 시스템에서 종합해야 한다. 하지만 장비 교체나 사업장 확장 때마다 전용 드라이버를 새로 만들면 통합비용이 누적되고 특정 벤더에 종속된다. OPC UA의 공통 주소공간과 표준 서비스는 연결 지점을 줄이고 데이터의 재사용성을 높인다.

산업 데이터는 값만이 아니라 엔지니어링 단위, 품질 상태, 시각, 장비의 상하관계가 필요하다. 예를 들어 Temp=72라는 숫자만으로는 섭씨인지 화씨인지, 어느 센서의 측정인지, 값이 정상인지 판단할 수 없다. OPC UA는 변수와 타입, 참조, 메타데이터를 정보 모델로 표현하여 수신 시스템이 의미를 탐색하도록 한다.

또한 OT 환경의 연결 확대는 안전과 가용성 위험을 함께 높인다. 인증서 기반 애플리케이션 신원, 암호화·서명, 사용자 권한, 감사 기능을 네트워크 설계와 운영정책에 결합해야 한다. 따라서 OPC UA는 프로토콜 선정이 아니라 OT·IT 데이터 아키텍처와 보안 거버넌스의 설계 과제이다.

2. 표준 구조와 정보 모델

가. 계층 구조

OPC UA는 애플리케이션이 이용하는 정보 모델, 상호작용을 정의하는 서비스, 메시지 구조, 전송 매핑, 보안 및 적합성 구조로 이해할 수 있다. 이 계층화 덕분에 같은 정보 모델을 유지하면서 환경에 맞는 전송 방식을 선택할 수 있다. 표준 규격은 IEC 62541 시리즈로 구성되며, 개요·보안·주소공간·서비스·정보모델·매핑·프로파일 등 여러 부분이 역할을 나눈다.

flowchart TB
  A[기업 응용: MES·분석·클라우드] --> B[OPC UA Client / Server]
  B --> C[Services: Browse·Read·Write·Subscribe]
  C --> D[AddressSpace: Objects·Variables·Methods·Types]
  D --> E[Information Model·Companion Specification]
  B --> F[SecureChannel·Session·인증서·권한]
  F --> G[전송 매핑: UA TCP·HTTPS·PubSub]
  G --> H[PLC·로봇·센서·현장 게이트웨이]

애플리케이션은 표준 서비스를 호출하여 주소공간을 탐색하고 값을 읽거나 변경하며 이벤트를 구독한다. 주소공간은 장비와 공정의 객체, 속성, 변수, 메서드, 데이터 타입을 노드와 참조로 표현하는 그래프이다. 전송 매핑은 메시지를 네트워크에서 전달하는 방법을 정의하므로, 정보 의미와 전송 기술을 분리할 수 있다.

나. 주소공간과 의미 모델

Node는 OPC UA가 관리하는 정보 단위이며, 객체(Object), 변수(Variable), 메서드(Method), 타입 정의 등의 노드 클래스가 있다. 변수 노드는 현재 값뿐 아니라 데이터 타입, 접근 수준, 공학 단위, 설명, 품질, 시간 정보 같은 속성을 가질 수 있다. 객체와 참조를 통해 공장·라인·설비·하위 구성품의 구조를 표현하므로, 소비자는 고정 태그 목록 대신 계층을 탐색할 수 있다.

NodeId는 주소공간 안에서 노드를 식별하며, Namespace URI는 서로 다른 공급자의 모델 식별자가 충돌하는 것을 줄인다. QualifiedName은 이름과 네임스페이스를 결합하고, 참조 유형은 구성·유형·상태 등 노드 간 관계의 의미를 제공한다. 이 식별·관계 모델이 없다면 두 장비의 Pressure 변수가 같은 의미인지 응용이 추측해야 한다.

OPC UA 기본 정보 모델은 일반 구조를 제공하고, Companion Specification은 산업별 의미를 공통화한다. 예컨대 기계, 로봇, 공정 산업에서 사용하는 장비·기능·상태 모델을 정의하면 여러 업체의 장비를 같은 방식으로 발견하고 이용할 수 있다. 다만 companion model을 탑재했다고 모든 현장 의미가 자동으로 맞는 것은 아니다. 버전, 선택 항목, 단위, 선택적 필드의 구현 차이를 시험하고 기업 데이터 사전과 매핑 규칙을 관리해야 한다.

다. 정보모델 기반과 단순 태그 기반의 차이

전통적인 태그 인터페이스는 태그 이름과 주소를 사전에 알아야 하므로, 장비 모델이 바뀌면 응용 코드도 수정되는 경우가 많다. 정보모델 기반 소비자는 객체의 타입과 참조를 탐색하여 장비의 속성·관계를 발견할 수 있다. 이는 통합을 “점대점 태그 변환”에서 “표준 의미를 해석하는 응용”으로 옮긴다.

구분 태그 중심 연계 OPC UA 정보모델 중심 연계
데이터 표현 주소·태그명·값 위주 타입·관계·메타데이터 포함
장비 발견 별도 목록·수작업 매핑 Browse·타입 탐색 가능
변경 영향 태그 주소 변경 때 코드 수정 모델·네임스페이스 변경 영향 관리
의미 일관성 프로젝트별 명명 규칙에 의존 공통 모델·Companion Spec 활용
적용 부담 초기 단순, 통합 누적비용 증가 초기 모델링 필요, 재사용성 향상

표의 차이는 단지 데이터 형식의 풍부함이 아니다. 기업이 공정 지식을 데이터 계약으로 관리하는지, 장비별 구현 세부사항에 의존하는지의 차이다. 소규모 고정 설비에서는 단순 태그가 비용 효율적일 수 있지만, 다사업장·다벤더 분석에서는 모델 기반의 이점이 커진다.

3. 통신 모델과 데이터 전달 절차

가. Client-Server 서비스

Client-Server 모델에서 서버는 주소공간과 서비스를 제공하고 클라이언트는 Browse, Read, Write, Call, Subscribe 등의 서비스를 이용한다. Browse는 노드와 참조를 탐색하고, Read는 값과 메타데이터를 가져오며, Write와 Call은 권한이 허용된 변경·동작을 요청한다. Subscription과 MonitoredItem은 값이나 이벤트의 변경 통지를 지원하여, 클라이언트가 짧은 주기로 전체 데이터를 반복 조회하는 부담을 줄인다.

통신 수립은 대체로 서버 엔드포인트 탐색, 보안 정책 선택, SecureChannel 수립, 사용자 인증, 세션 생성, 서비스 요청 순으로 진행된다. 응용은 서버 인증서를 검증하고, 서버도 클라이언트 애플리케이션의 신뢰 여부를 확인한다. 세션은 사용자와 권한 맥락을 제공하며, 채널은 메시지의 기밀성·무결성과 연결된다.

Client-Server는 설정, 온디맨드 질의, 양방향 제어에 적합하다. 그러나 대규모 일대다 데이터 배포에서 모든 소비자와 장치가 직접 연결되면 세션 수와 연결관리 부담이 커질 수 있다. 따라서 지연·보장·연결 수·운영 통제를 고려해 PubSub와 역할을 나눈다.

나. PubSub 통신

Publish-Subscribe(PubSub)는 Publisher가 데이터를 발행하고 Subscriber가 관심 데이터셋을 구독하는 통신 패턴이다. 양측은 직접 요청·응답을 하지 않아도 되므로, 중개형 메시지 브로커 또는 브로커리스 전달을 사용해 다수 장치에 데이터를 배포할 수 있다. OPC UA PubSub의 메시지 모델은 데이터셋, 네트워크 메시지, 게시자 식별, 보안 설정 등으로 구성된다.

sequenceDiagram
  participant D as PLC·설비 Publisher
  participant C as OPC UA Client
  participant B as MQTT Broker 또는 UDP망
  participant S as 분석 Subscriber
  C->>D: 보안 채널·세션 수립 및 모델 탐색
  D-->>C: 주소공간·설정 정보 제공
  D->>B: PubSub NetworkMessage 발행
  B->>S: 구독 조건에 따라 전달
  S->>S: 데이터셋 디코딩·검증·저장

Client-Server와 PubSub는 경쟁 관계가 아니라 보완 관계이다. 설정과 모델 탐색은 Client-Server로 수행하고, 고빈도 데이터의 일대다 배포는 PubSub로 분리할 수 있다. 산업 네트워크에서 지연·손실·중복이 발생할 수 있으므로, 시퀀스·타임스탬프·품질 상태·수신 시각을 활용한 소비자 측 검증이 필요하다.

다. 전송과 프로파일 선택

OPC UA는 산업용 바이너리 전송과 웹·메시지 지향 매핑 등 여러 통신 매핑을 지원한다. 실제 선택은 장치 성능, 방화벽, 브로커 보유 여부, 네트워크 지연, 상호운용성 시험, 보안 운영능력으로 결정한다. OPC UA over MQTT 또는 AMQP와 같은 브로커 연계는 기업·클라우드까지 비동기 전달에 유리할 수 있다. 반면 작은 임베디드 장치에서는 CPU·메모리·인증서 관리가 구현 제약이 될 수 있다.

표준이 여러 프로파일과 전송 옵션을 제공한다는 점은 유연성을 높이지만, 지원 조합이 다르면 연결 문제가 생길 수 있다. 따라서 구매 규격에는 “OPC UA 지원”만 적지 말고 서버/클라이언트 역할, companion model, 보안 정책, 전송 프로파일, 진단 기능을 명시한다. 적합성 시험과 실제 장비 간 상호운용 시험을 별도로 실시해야 한다.

4. 보안과 운영 설계

OPC UA 보안은 암호화 하나로 끝나지 않으며 애플리케이션 신원, 사용자 권한, 인증서 수명주기, 네트워크 분리, 감사 추적을 함께 다룬다. Client-Server의 SecureChannel은 메시지 서명·암호화를 제공할 수 있고, 사용자 인증은 계정·인증서·토큰 등 배치 정책에 따라 구성한다. 보안 모드를 끄거나 신뢰 목록을 무분별하게 넓히면 표준의 보안 기능이 있어도 실질 보호는 약해진다.

인증서는 초기 설치, 교체, 만료, 폐기, 백업, 신뢰 저장소 갱신까지 수명주기로 운영해야 한다. 장치 수가 수천 대로 증가하면 수작업 인증서 배포는 만료 장애와 잘못된 신뢰 등록을 유발하므로 자동 프로비저닝과 중앙 가시성이 필요하다. 인증서 교체는 생산 중단과 연결 복구에 영향을 주므로 이중 운영, 롤백, 만료 알림을 계획한다.

권한은 역할과 자산 중요도에 따라 최소화한다. 읽기 전용 수집 계정과 설정·제어 계정을 분리하고, 위험한 Method 실행은 운영자 승인이나 안전 인터록 뒤에 둔다. 쓰기 권한을 사용하지 않는 수집 시스템에 부여하지 말고, 계정 공유와 기본 암호를 제거한다.

PubSub에서는 메시지 서명·암호화, 보안그룹 키, 키 배포와 구독자 검증을 설계한다. 브로커 기반 TLS와 메시지 자체의 보호는 서로 다른 위협 경계를 다룰 수 있으므로 요구사항을 구별한다. 서비스 거부, 잘못된 메시지, 재전송, 대량 구독으로 인한 자원 소진을 고려해 속도 제한과 자원 격리를 둔다.

OT 보안은 패치가 제한된 장비의 현실도 반영한다. 현장 네트워크를 기업망과 분리하고 산업 DMZ 게이트웨이로 데이터 흐름을 통제하며, 허용된 방향과 목적지에 한해 통신을 열어야 한다. 수집 데이터와 제어 명령 경로를 분리하고, 로그·시간 동기화·백업을 포함한 사고 대응 절차를 훈련한다.

5. 비교와 적용 사례

가. OPC UA와 MQTT·Modbus 비교

Modbus는 단순한 레지스터 읽기·쓰기와 폭넓은 레거시 지원이 장점이지만 복잡한 장비 의미와 인증·암호화 기능은 별도 보완이 필요하다. MQTT는 경량 발행-구독 전달과 브로커 생태계가 강점이나, 토픽과 페이로드 의미는 응용 계약으로 별도 관리해야 한다. OPC UA는 정보모델과 보안 구조를 함께 정의하지만, 모델링과 구현·인증서 운영 비용이 더 크다.

비교축 OPC UA MQTT Modbus
기본 강점 의미 모델·서비스·보안 통합 경량 비동기 메시징 단순한 레거시 레지스터 연계
데이터 의미 타입·참조·정보모델 토픽·페이로드 계약에 의존 주소·레지스터 의미를 별도 정의
통신 패턴 Client-Server, PubSub PubSub 주로 요청·응답
고려사항 모델·인증서·프로파일 상호운용 브로커·토픽·스키마 거버넌스 보안 보완·주소 문서화

현장에서는 하나의 기술로 통일하기보다 레거시 연결에는 Modbus 게이트웨이를 두고, 기업 이벤트 전달에는 MQTT를 이용하며, 설비 의미 모델과 장비 서비스를 OPC UA로 제공하는 조합이 현실적이다. 다만 게이트웨이는 데이터 변환과 보안의 집중 지점이므로, 장애 격리·원본 보존·품질 메타데이터 전달을 설계해야 한다.

나. 가상 스마트 제조 사례

가상의 공장에 120대의 CNC와 조립설비가 있고, 설비별로 초당 10개의 상태값을 수집한다고 가정한다. 장비가 개별 태그를 제공하면 이름·단위·상태코드를 공장별로 매핑해야 하므로, 신규 설비 추가 때마다 분석 시스템 변경이 필요하다. OPC UA 서버에 설비 타입과 변수, 공학 단위, 품질 상태를 모델링하고 공통 장비 모델을 적용하면 MES와 분석 구독자가 재사용할 수 있다.

이 공장에서 수집용 소비자는 읽기 권한만 갖고, 제어용 응용은 별도 인증서와 운영자 승인 후 제한된 Method만 호출한다. 초당 전체 데이터를 모두 클라우드로 보내기보다 현장 게이트웨이에서 이상 요약을 만들고 원시 신호는 품질 분석에 필요한 구간만 보관한다. 예시는 설계 접근을 설명하기 위한 가정이며, 실제 처리량·지연 목표는 장비의 사양과 공정 위험 분석으로 산정해야 한다.

다. 에너지·시설 운영 사례

빌딩 관리 시스템에서는 보일러, 공조기, 전력 계량기, 환경 센서가 서로 다른 프로토콜과 모델을 사용한다. 시설 운영자는 OPC UA 주소공간에 층·구역·장비 관계와 측정 단위를 표현하고, 에너지 분석 시스템은 이 모델을 탐색하여 부하를 집계할 수 있다. 여러 건물에서 동일한 모델과 네이밍 원칙을 사용하면 에너지 원단위 비교와 설비 이상 탐지를 일관되게 수행할 수 있다.

6. 심화: OT·IT 데이터 패브릭에서의 역할

OPC UA는 PLC와 MES 사이의 프로토콜 변환을 넘어, 장비 모델을 기업 데이터 플랫폼까지 전달하는 엣지 데이터 계약으로 사용할 수 있다. 현장 게이트웨이는 주소공간 탐색, 품질 정규화, 시간 동기화, 메시지 버퍼링, 접근정책 적용을 수행한다. 상위 분석 시스템은 모델 기반으로 설비를 발견하고, 표준 속성으로 지표를 계산할 수 있다.

그러나 산업 간 모델을 그대로 합치기만 하면 의미 충돌이 남는다. 예를 들어 동일한 State가 생산 중·정지·고장·대기 중 무엇을 뜻하는지 사업장마다 다를 수 있다. 기업은 OPC UA companion model과 내부 데이터 카탈로그, 단위 표준, 자산 계층을 연결하여 업무 의미를 관리해야 한다.

대규모 도입에서는 모델 버전과 서버 기능 프로파일을 자산 목록에 등록한다. 스키마 변경은 생산 설비에 즉시 반영하지 않고 호환성 시험과 단계적 배포를 거친다. 게이트웨이에서 구버전과 신버전을 일정 기간 병행하면 소비자 전환을 통제할 수 있지만, 중복 운영의 보안·성능 비용도 검토해야 한다.

성능 검증은 평균 지연만 측정해서는 안 된다. 수집 주기, 동시 구독 수, 알림 폭주, 네트워크 단절 후 재연결, 인증서 검증, 서버 재시작 상황에서 p95/p99 지연과 데이터 누락을 시험한다. 제어 경로에는 최악 지연과 안전 인터록을 검증하고, 일반 분석 경로와 동일한 서비스 수준을 가정하지 않는다.

표준 버전은 조달과 개발 시점에 공식 목록으로 확인해야 한다. IEC 카탈로그에는 OPC UA의 개요와 개념을 다루는 IEC 62541-1:2025가 2025년 12월 19일 발행본으로 등재되어 있다. 다른 파트의 판과 개정 시점은 서로 다를 수 있으므로, 준수 기준을 정할 때 적용 파트별 현행판과 프로파일을 확인한다.

7. 고려사항 및 시사점

가. 의미 모델의 거버넌스

모델이 풍부해도 각 설비가 속성·단위·품질코드를 제각각 쓰면 상호운용성이 낮다. 참조 모델, 네임스페이스, 버전 정책, 필수 속성, 데이터 품질 규칙을 기업 표준으로 정하고 공급자 계약에 반영한다.

나. 보안 우선 구성

운영 현장에서 보안 정책을 기본값으로 남겨 두지 말고, 인증서 신뢰·사용자 권한·암호 정책·감사 로깅을 배포 전 점검한다. 읽기 수집과 제어를 분리하고, 네트워크 경계와 자산 중요도에 따라 허용 경로를 최소화한다.

다. 안전·가용성 분리

일반 OPC UA 통신이 기능 안전 시스템이나 결정론적 제어를 자동 대체한다고 가정하지 않는다. 안전 기능은 해당 안전 표준과 인증 체계에 따라 분리 검증하고, 통신 장애 시 안전 상태와 수동 운전 절차를 정의한다.

라. 상호운용성 시험

제품이 표준을 지원한다는 선언만으로 실제 장비 간 호환을 보장할 수 없다. 서버·클라이언트 역할, 보안 정책, 모델 버전, 통신 매핑, 오류 처리, 재연결을 포함한 다자 시험을 조달·검수 단계에 포함한다.

마. 인증서·키 운영

장치 식별과 키 수명주기를 운영팀의 책임으로 명확히 하고 만료·폐기·유출 대응을 자동화한다. 개인 인증서와 공장 전체 공유 키를 구별하며, 키 탈취가 의심될 때 영향을 받는 Publisher·Subscriber 범위를 추적할 수 있어야 한다.

바. 브라운필드 전환

기존 PLC와 SCADA를 일괄 교체하기보다 게이트웨이로 읽기 중심 연결을 먼저 만들고, 품질·보안·가용성 지표를 확인하며 범위를 넓힌다. 변환 규칙, 원천 태그, 데이터 손실 가능성을 기록하여 새 모델이 기존 운영 절차를 깨뜨리지 않게 한다.

사. 기술사 관점의 도입 로드맵

1단계에서는 자산·프로토콜·데이터 흐름·제어 중요도를 조사해 위험 기반 적용 범위를 정한다. 2단계에서는 우선 설비군의 정보모델, 보안 프로파일, 인증서 체계, 상호운용 시험 기준을 정의한다. 3단계에서는 현장 게이트웨이와 기업 데이터 플랫폼을 연결하고 데이터 품질·운영 관측·복구를 검증한다. 4단계에서는 모델 카탈로그와 변경승인, 취약점·인증서 수명주기 관리로 다사업장 확산을 표준화한다.

기술사는 도입 효과를 장비 연결 수가 아니라 재사용 가능한 의미 모델, 통합 유지보수 비용, 데이터 신뢰도, 안전·보안 위험 감소로 평가해야 한다. 표준 준수와 현장 적합성의 간극을 줄이려면 발주요건, 아키텍처, 보안운영, 시험성적을 하나의 추적 가능한 거버넌스로 묶어야 한다.

참고자료

한 줄 요약: OPC UA는 보안 통신과 탐색 가능한 산업 정보모델을 결합해 이기종 OT 장비의 데이터 의미를 표준화하고, Client-Server·PubSub를 현장 요구에 맞게 조합하여 안전한 OT·IT 상호운용을 구현하는 IEC 62541 아키텍처이다.