디지털트윈이 '실시간'이 되는 조건 — 샘플링·지연시간·동기화 설계하기

'실시간'이라는 말의 함정

 

디지털트윈 프로젝트 발표 자리에서 "실시간으로 반영됩니다"라는 말을 수없이 들었습니다. 그런데 현장에 가보면 그 '실시간'이 기계의 현재 상태가 아니라 몇 초 전, 어떤 날은 몇 분 전의 상태인 경우가 많습니다.

 

디지털트윈의 3D 화면이 화려하면 화려할수록 이 간극은 잘 안 보입니다. 하지만 그 데이터로 "지금 이 기계가 안전한가?"를 판단해야 하는 순간, 지연된 데이터는 거짓말을 합니다. 정지한 기계를 돌아가고 있다고, 정상 온도를 과열이라고 보

여주죠.

 

시간축을 설계하는 3가지 요소

 

디지털트윈이 진짜 '실시간'이 되려면 화면을 그리기 전에 시간축을 설계해야 합니다. 현장 7년차인 제가 실제 구축 때 체크하는 요소는 세 가지입니다.

 

첫째, 샘플링 주기. 진동 데이터는 1초에 수백 번씩 샘플링해야 의미가 있지만, 탱크의 수위는 10초에 한 번이면 충분합니다. 신호마다 '이 데이터가 판단에 필요한 시간 해상도'가 다릅니다. 전부 1ms로 맞추면 네트워크가 죽고, 전부 1초로 맞추면 알람이 늦습니다.

 

둘째, 지연시간(latency) 예산. 센서에서 게이트웨이, 브로커, 처리 파이프라인, 화면까지 데이터가 지나가는 각 구간이 지연을 더합니다. 목적지별 예산을 정해야 합니다. "경광등 트리거는 100ms 이내, 대시보드는 1초 이내, 일간 리포트는 다음 날" 같은 식입니다. 전체를 '실시간'으로 묶는 순간 설계는 망가집니다.

 

셋째, 타임스탬프 동기화. 서로 다른 장비의 데이터를 "같은 시각"의 것으로 붙이려면 시계가 맞아야 합니다. NTP로 수백 ms 어긋난 시계끼리 데이터를 합치면, 인과관계가 뒤집힌 그래프가 그려집니다. "A가 B보다 먼저 이상했다"는 판단이 시계 오차 때문이었다면 현장에서 신뢰를 잃습니다.

 

그래서 뭘 하면 되나

 

신규 구축이라면 센서를 달기 전에 먼저 물어보세요. "이 데이터는 어디에, 언제까지 닿아야 하는가?" 이 질문에 답이 나오면 샘플링 주기와 지연 예산이 정해지고, 그제야 어떤 프로토콜(OPC UA·MQTT·Modbus)이 어울리는지가 정해집니다.

 

디지털트윈의 진짜 엔진은 3D 모델이 아닙니다. 데이터가 "지금"을 말하게 만드는 시간축 설계입니다. 화면이 예쁘다고 실시간이 되는 건 아닙니다.

 

관련 글: #124 "디지털트윈의 진짜 엔진은 3D가 아니라 '데이터 수집'이다" — 수집 단계(프로토콜 선택)에서 시간축 설계로 이어지는 심화편입니다.