Digital Twin은 단일 소프트웨어나 3D 엔진으로 완성되지 않는다. 현실 대상을 의미 있게 정의하는 모델, 상태를 가져오는 연결 계층, 시간에 따라 데이터를 보존하는 플랫폼, 정보를 해석하는 분석, 사람이 사용하는 애플리케이션이 함께 작동해야 한다. 프로젝트마다 제품 구성은 달라도 다음 다섯 기술 층으로 나누면 누락과 책임 범위를 파악하기 쉽다.
1. 자산·관계 모델링
첫 번째는 현실 대상을 디지털 개체로 정의하는 기술이다. 자산 ID, 유형, 속성, 단위와 상태뿐 아니라 공간의 포함 관계, 설비의 공급 관계, 공정의 선후 관계를 모델링한다. Azure Digital Twins에서는 사용자 정의 모델의 인스턴스가 개별 Twin이 되고 관계를 통해 Twin Graph를 구성한다. AWS IoT TwinMaker는 개체, 컴포넌트와 관계를 이용해 물리 시스템을 표현한다.
좋은 모델은 3D 오브젝트 계층을 그대로 복사하지 않는다. 운영자가 찾는 설비 코드와 정비 시스템의 ID가 그래픽 오브젝트에 연결되어야 한다. 이름 변경과 교체에도 추적할 수 있는 안정적인 식별자를 먼저 정하는 것이 중요하다.
2. 데이터 수집과 연결
센서, PLC, IoT 게이트웨이, 데이터베이스와 업무 API에서 값을 가져오는 계층이다. MQTT 같은 발행·구독 메시징, OPC UA, HTTP API, 파일 배치 등 환경에 맞는 방법을 조합한다. 여기서 프로토콜 연결만 성공했다고 끝나는 것이 아니다. 단위 변환, 시간 스탬프, 품질 코드, 장비 ID 매핑과 재전송 정책을 함께 설계해야 한다.
3. 시계열·이벤트 데이터 플랫폼
Twin의 현재 상태와 긴 이력을 같은 방식으로 취급하면 확장성이 떨어진다. 최신 상태는 빠르게 조회할 저장소에, 고빈도 원시 데이터는 시계열 저장소나 기존 Historian에, 문서와 미디어는 별도 저장소에 둘 수 있다. AWS IoT TwinMaker의 컴포넌트 정의도 정적 속성과 외부에 저장된 시계열 속성을 구분하고, 데이터 리더를 통해 외부 소스를 조회할 수 있게 한다.
이 계층은 순서가 뒤바뀐 이벤트, 중복 메시지, 네트워크 단절 후 재전송을 처리해야 한다. 원본 데이터와 가공 결과의 계보, 보존 기간, 접근 권한도 기술 설계의 일부다.
4. 규칙·분석·Simulation
원시값을 운영 정보로 바꾸는 계층이다. 임계값 규칙, 상태 머신, 집계 지표, 이상 탐지, 예측 모델과 물리 Simulation이 포함될 수 있다. 분석 결과에는 사용한 입력 기간, 모델 버전과 신뢰 수준을 남겨야 한다. 특히 측정값과 추정값을 같은 필드에 덮어쓰지 말고 출처를 구분해야 한다.
5. 시각화와 업무 애플리케이션
사용자는 2D 대시보드, 3D 공간, 알림 목록, 모바일 점검 화면이나 외부 업무 시스템을 통해 Twin을 사용한다. 중요한 것은 그래픽의 화려함보다 업무 흐름이다. 경보를 클릭했을 때 관련 설비, 최근 추세, 매뉴얼과 작업 이력으로 이동하고 필요한 권한의 사용자만 조치를 실행할 수 있어야 한다.
| 기술 층 | 대표 산출물 | 초기 검증 질문 |
|---|---|---|
| 모델 | 자산 스키마, ID·관계 규칙 | 현실 개체를 중복 없이 찾을 수 있는가? |
| 연결 | 인터페이스 명세, 데이터 매핑 | 단위·시간·품질을 함께 전달하는가? |
| 플랫폼 | 현재 상태, 이력과 이벤트 저장 | 중복·지연·단절을 견디는가? |
| 분석 | 규칙, 지표, 모델 결과 | 결과를 재현하고 검증할 수 있는가? |
| 애플리케이션 | 대시보드, 3D, 알림·작업 UI | 실제 판단과 조치로 이어지는가? |
다섯 기술을 가로지르는 기반
보안, 관측성, 데이터 거버넌스와 배포 운영은 별도의 장식이 아니라 모든 층을 관통한다. 장치 인증, 최소 권한, 암호화, 비밀정보 관리, 변경 감사와 백업 정책을 초기 구조에 포함해야 한다. 또한 수집 지연, 연결 실패, 분석 오류와 화면 갱신 상태를 측정할 로그·메트릭이 없으면 Twin 자체의 상태를 신뢰할 수 없다.
단계적으로 구축하는 방법
- 한 가지 운영 질문과 제한된 자산 범위를 선택한다.
- 자산 ID와 최소 속성·관계를 정의한다.
- 한 개 데이터 소스를 연결하고 품질·시간 정책을 검증한다.
- 현재 상태와 이력 조회를 만든 뒤 간단한 규칙을 추가한다.
- 사용자 검증 후 3D, 예측 또는 제어 범위를 확장한다.
이 순서는 특정 제품 구매보다 앞선다. 각 층의 책임과 교체 가능한 인터페이스를 먼저 정의하면 클라우드, 온프레미스 또는 혼합 구조를 선택하기도 쉬워진다.
FAQ
다섯 기술을 한 제품에서 모두 제공받아야 하나?
그럴 필요는 없다. 기존 Historian, IoT 플랫폼, 3D 엔진과 업무 시스템을 인터페이스로 연결할 수 있다. 다만 장애와 데이터 책임의 경계를 명확히 해야 한다.
3D 시각화는 어느 단계에 필요한가?
공간 위치와 형상이 판단에 중요한 경우 유용하다. 표와 추세만으로 목적을 달성할 수 있다면 3D는 이후 단계로 미뤄도 된다.
보안은 여섯 번째 기술인가?
분리된 한 층이라기보다 장치부터 사용자 화면까지 모든 계층에 적용되는 횡단 요구사항으로 보는 편이 안전하다.
관련 글과 도구
- 센서 데이터가 Digital Twin에 연결되는 과정
- Unreal Engine으로 Digital Twin을 구현하는 기본 구조 (공개 예정)
- XR Project Budget Estimator — 콘텐츠·센서·통합·설치 요소별 초기 범위 확인