제조업용 디지털 트윈 소프트웨어: 구매자를 위한 체크리스트

Disclosure: M365.FM host Mirko Peters works at iFAKT GmbH. This page describes the company factually; paid partnerships and links are labelled as advertising.

By Mirko Peters · 2026-11-12

제조업용 디지털 트윈 소프트웨어는 모델을 실시간 데이터와 계속 동기화합니다. 플랫폼, 패키지형 도구, 보안, 비용 및 유지 관리를 비교할 때 사용할 수 있는 체크리스트입니다.

Automatically translated with AI from the original post. Read the English original

제조업용 디지털 트윈 소프트웨어는 기계, 라인 또는 공장의 모델을 만들고 그 모델을 실제 데이터와 연결해 두어, 가동 중인 상태를 모니터링하고 문제를 예측하거나 변경 사항을 실제로 적용하기 전에 테스트할 수 있게 해 줍니다. 이 글은 같은 용어를 사용하는 여러 제안서를 비교해야 하는 공장 관리자를 위한 것입니다. 트윈의 기본 개념은 다시 설명하지 않으며, 소프트웨어를 선택할 때 반드시 갖춰야 할 기능부터 운영을 지속하는 데 드는 비용까지 확인할 수 있는 체크리스트를 제공합니다.

핵심 포인트

• NIST는 트윈의 핵심 요소 세 가지로 고빈도 센싱, 안정적인 산업용 IoT 연결, 예측을 위한 시뮬레이션 모델을 꼽습니다. 소프트웨어가 이 요소들을 직접 다루거나 파트너를 통해 제공해야 합니다.
• Azure Digital Twins는 트윈 그래프를 위한 플랫폼 서비스이며, 바로 사용할 수 있는 공장 애플리케이션이 아닙니다. Microsoft는 이것이 Fabric 디지털 트윈 빌더 미리 보기와 다르다고 밝히고 있습니다.
• 먼저 구축의 기반이 될 플랫폼이 필요한지, 아니면 특정 질문에 답하는 패키지형 도구가 필요한지 결정하십시오. 답에 따라 작업 주체와 비용이 달라지기 때문입니다.
• ISO 23247-1은 제조를 위한 디지털 트윈 프레임워크의 개요와 일반 원칙을 제시하며, 공급업체와 용어를 맞추는 데 도움이 됩니다.
• 라이선스뿐 아니라 데이터 통합, 모델 검증, 유지 관리에 대한 예산도 잡아 두고, 첫 파일럿은 라인 하나와 의사결정 하나로 한정하십시오.

제조업용 디지털 트윈 소프트웨어에는 무엇이 포함되어야 합니까?

공급업체가 임의로 넓게 해석할 수 없는 정의에서 출발하십시오. NIST는 디지털 트윈을 물리적 대응물을 정확히 복제하고, 연결하며, 동기화하는 동적이고 데이터 기반의 가상 표현이라고 설명합니다. 또한 트윈은 정적 모델이 아니며, 충실도, 유용성, 장기적 실행 가능성을 결정하는 핵심 요소로 고빈도 센싱, 연결을 위한 안정적인 산업용 IoT 인프라, 예측 분석을 위한 고급 시뮬레이션 모델을 제시합니다.

이 세 가지 요소를 어떤 제품에든 적용할 수 있는 질문으로 바꿔 보십시오.

1. 데이터 입력. 머신 컨트롤러, 센서, MES, ERP, 스프레드시트 등 어떤 소스를 읽습니까? 데이터는 얼마나 자주 갱신됩니까? 각 연결은 누가 구축하고 유지 관리합니까?
2. 의미 있는 모델. 공장은 자산, 라인, 공정, 관계 측면에서 어떻게 표현됩니까? 공정이 바뀌었을 때 내부 담당자가 이 정의를 직접 수정할 수 있습니까?
3. 그 위의 분석. 현재 값만 보여 주는지, 아니면 예측, 시뮬레이션, 시나리오 비교까지 가능한지 확인하십시오. 이런 기능이 기본으로 내장되어 있습니까, 아니면 별도의 프로젝트가 필요합니까?

그다음 두 가지 실무적 요구 사항도 더하십시오. 사람들이 결과를 읽을 수 있어야 하고(대시보드, 보고서, 알림), 역할에 따라 접근이 통제되어야 합니다. 제품이 이 다섯 가지 중 하나라도 빠뜨린다면, 누가 그 기능을 제공하는지 물어보십시오.

어떤 종류의 소프트웨어가 디지털 트윈으로 판매되고 있습니까?

디지털 트윈이라는 표현은 서로 매우 다른 제품들을 포괄합니다. 가격을 비교하기 전에 제안을 네 가지 그룹으로 분류하십시오.

• 구축 기반 플랫폼. 모델을 저장하고, 데이터를 연결하고, 질의하는 데 필요한 구성 요소를 제공합니다. 솔루션은 여러분이나 파트너가 그 위에 직접 구축합니다.
• 패키지형 생산 트윈. 생산 계획, 시뮬레이션, 설비 최적화처럼 생산에 맞춘 데이터 모델이 기본으로 포함되어 있어 개발이 적게 듭니다.
• 자산 및 상태 트윈. 센서 데이터를 활용해 기계의 마모와 이상 징후를 찾아내고, 설비 상태 관리에 초점을 맞춥니다.
• 설계 및 시운전 트윈. 설비를 설치하기 전에 배치와 제어 로직을 테스트합니다.

그룹마다 답하는 질문이 다르므로 도구도 다른 질문에 답합니다. 상태 트윈으로는 새로운 교대 근무 모델이 작업 적체를 해소할 수 있는지 알 수 없고, 생산 시뮬레이션으로는 베어링이 언제 고장 날지 알 수 없습니다. 먼저 결정하려는 사항을 적어 두고, 그다음에 그룹을 선택하십시오.

Azure Digital Twins 같은 플랫폼은 무엇을 제공합니까?

Azure Digital Twins가 Microsoft의 대표적인 예입니다. Microsoft Learn에 따르면, 이는 건물, 공장, 에너지 네트워크 같은 환경의 디지털 모델을 기반으로 트윈 그래프를 만드는 서비스형 플랫폼(PaaS)입니다. JSON과 유사한 언어인 DTDL(Digital Twins Definition Language)로 도메인 용어를 정의하고, 트윈은 이 모델의 인스턴스입니다. 트윈 간의 관계가 그래프를 구성하며, 이를 최신 상태를 반영하는 실시간 표현으로 조회할 수 있습니다. IoT Hub는 장치 데이터를 제공하고, REST API와 커넥터는 업무 시스템 데이터를 가져올 수 있으며, 이벤트 라우트를 통해 트윈 데이터를 분석용으로 다른 Azure 서비스에 전달할 수 있습니다.

구매자가 알아야 할 점은 두 가지입니다. 첫째, 이것은 빌딩 블록입니다. 모델을 저장하고 연결하는 역할을 하며, 대기열, 셋업, 교대 일정을 포함한 생산 시뮬레이션의 What-if 로직은 별도의 소프트웨어가 담당합니다. 따라서 그 결과물은 여러분이나 파트너가 직접 개발해야 합니다. 둘째, 해당 문서에서는 Azure Digital Twins가 Fabric 디지털 트윈 빌더(미리 보기)및 IoT Hub 장치 트윈과 다르다고 설명합니다. 계획을 세우기 전에 동료나 공급업체가 말하는 것이 어느 쪽인지 반드시 확인하십시오.

데이터 이력은 별도의 단계입니다. 그래프는 실시간 보기이며, 데이터 이력에 대한 Microsoft 문서에서는 그래프 업데이트를 시간에 따라 기록하려면 인스턴스를 Azure Data Explorer 클러스터에 연결해야 하며, 그 사이에 Event Hubs 네임스페이스가 필요하다고 설명합니다. 또한 데이터 이력에서 발생하는 메시지는 메시지 가격 책정 항목에 따라 과금된다고 명시되어 있습니다. 즉, "지난달 추세를 보고 싶다"는 요구에는 구성 요소와 비용 항목이 추가됩니다. 공급업체에는 같은 질문을 던지십시오. 이력 데이터는 어디에 저장되며, 비용은 얼마입니까?

플랫폼을 직접 구축해야 할까요, 아니면 패키지 도구를 구매해야 할까요?

다음 질문을 참고해 결정하십시오.

• 질문이 얼마나 구체적입니까? 용량, 인력 배치, 제품 믹스처럼 명확하게 정의된 생산 질문이라면 패키지 도구가 보통 더 빨리 답을 줍니다. 여러 자산 유형을 아우르는 장기적이고 광범위한 디지털 기반이 필요하다면 플랫폼이 더 높은 유연성을 제공합니다.
• 작업은 누가 합니까? 플랫폼에는 개발자나 파트너가 필요합니다. 그들의 시간을 계산에 포함하십시오. 패키지 도구는 작업의 상당 부분을 구성과 데이터 준비로 옮겨 줍니다.
• 공정이 얼마나 고유합니까? 공정이 특수할수록 유연한 모델의 중요성이 커집니다. 표준화된 흐름에는 패키지 도구가 더 잘 맞습니다.
• 얼마나 오래 사용할 계획입니까? 수년간 사용할 모델에는 담당자와 변경을 위한 예산이 필요합니다. 제품군을 추가하거나 라인을 이전할 때 누가 모델을 업데이트할지 확인하십시오.
• 이미 보유한 것은 무엇입니까? IT 팀이 이미 클라우드 플랫폼과 데이터 팀을 운영하고 있다면 플랫폼 구축이 적합할 수 있습니다. 둘 다 없다면 패키지 도구가 더 현실적인 선택일 수 있습니다.

모든 상황에 맞는 정답은 없습니다. 많은 공장이 결국 두 가지를 함께 사용합니다. 공용 데이터 기반에는 플랫폼을, 특정 결정에는 패키지 도구를 사용하는 방식입니다. 처음부터 둘 사이의 인터페이스를 계획하십시오.

연결성과 표준은 어떻게 확인합니까?

트윈은 데이터가 들어오고 결과가 나갈 때에만 쓸모가 있습니다. 연식과 제조사가 다른 설비와 소프트웨어가 어떻게 연결되는지 반드시 물어보십시오.

일반적인 경로 중 하나가 OPC UA입니다. OPC Foundation은 OPC UA를 공장 및 공정 제어 장비의 데이터를 기업 시스템으로 전달하는 기술로 설명하며, 보안, 신뢰성, 플랫폼 간 운영을 강조한다고 밝히고 있습니다. 또한 2011년에 IEC 62541 표준이 되었다고 설명합니다. OPC UA를 지원하는 공급업체는 대개 별도의 커스텀 드라이버 없이도 많은 장비의 데이터를 읽을 수 있습니다. 다만 구형 장비는 게이트웨이나 센서를 추가로 설치해야 할 수 있습니다.

프레임워크 자체에 대해서는 ISO 23247-1이 "Digital twin framework for manufacturing(제조를 위한 디지털 트윈 프레임워크)"의 첫 번째 파트입니다. ISO에 따르면 2021년 10월에 발행되었으며, 용어, 정의, 프레임워크 요구사항을 포함한 개요와 일반 원칙을 담고 있습니다. 이 표준을 읽는다고 트윈이 만들어지지는 않지만, 팀과 공급업체가 같은 용어로 소통할 수 있게 해 줍니다. 공급업체에 아키텍처가 이 표준을 참조하는지, 그리고 실제로 그것이 무엇을 의미하는지를 물어보십시오. 발표 자료의 설명만으로 판단하지 마십시오.

시스템의 경계에 대해서도 다음을 확인하십시오.

• 모델과 데이터를 개방형 형식으로 내보낼 수 있습니까?
• ERP, MES, 그리고 Power BI 같은 보고 도구와 연결할 때 보고서마다 별도의 커스텀 작업이 필요하지 않습니까?
• 데이터 피드가 중단되면 어떻게 됩니까? 오래된 값을 확신에 찬 듯 계속 보여주는 트윈은, 공백을 그대로 보여주는 트윈보다 더 나쁩니다.

보안과 접근 권한은 어떻게 평가합니까?

트윈은 원래 분리되어 있던 시스템들을 한데 묶습니다. 설비, 생산 오더, 경우에 따라서는 공급업체 데이터까지 포함됩니다. 이는 공격자가 악용할 수 있는 경로를 넓히고, 공정을 볼 수 있는 사람의 범위도 넓힙니다.

다음 질문은 서면으로 확인하십시오.

• 누가 모델의 어떤 부분을 보고 수정할 수 있습니까? 접근 권한은 역할 기반입니까, 그리고 공장이나 라인 단위로 제한할 수 있습니까?
• 데이터는 어디에 저장되며, 누가 운영하고, 계약을 종료하면 데이터는 어떻게 됩니까?
• 모델 변경 사항은 어떻게 기록되며, 이전 상태로 되돌릴 수 있습니까?
• 공급업체가 보유한 보안 인증은 무엇이며, 그 적용 범위는 어디까지입니까? 회사에 대한 인증이 구매하려는 제품까지 자동으로 포함하는 것은 아닙니다.
• 업데이트와 패치는 시스템에 어떻게 반영되며, 그 책임은 누구에게 있습니까?

고객이나 공급업체와 데이터를 공유한다면, 무언가를 연결하기 전에 고객이 특정 보안 평가를 요구하는지 확인하십시오.

실제 비용은 얼마이며, 가치는 어떻게 측정합니까?

라이선스 비용은 눈에 보이는 부분에 불과합니다. 나머지 비용은 대개 나중에 드러납니다.

• 디지털 출력이 없는 설비를 위한 센서, 게이트웨이, 네트워크 작업.
• 데이터 준비: 정제, 매핑, 그리고 시스템 간 정의에 대한 합의.
• 모델 구축과 실제 결과를 기준으로 한 검증.
• 메시지 볼륨과 이력 저장 공간 같은 클라우드 사용량.
• 공정이 바뀔 때마다 모델을 유지보수할 인력.
• 결과를 활용하는 사용자에 대한 교육.

각 공급업체에 위의 모든 항목을 포함하여 한 개 파일럿 라인에 대한 3년 비용을 산정하도록 요청하십시오. 구독료가 아니라 총비용을 비교하십시오.

가치를 판단하려면 시작하기 전에 측정 지표를 정하십시오. 트윈이 지원하는 의사결정과 연결하십시오. 예를 들어 파일럿 라인의 계획되지 않은 가동 중단, 리드타임, 일정 준수율, 셋업 시간, 스크랩 또는 보전 작업량이 있습니다. 최소 몇 주 동안 기준선을 기록하고, 파일럿을 실행한 뒤 비교하십시오. 변화해야 할 수치를 제시할 수 없다면, 아직 구매할 준비가 되지 않은 것입니다.

가상의 예를 들어 보겠습니다. 공장장은 조립 셀의 2교대 운영이 반복되는 적체를 해소할 수 있는지 알고 싶어 합니다. 이 질문에는 실시간 설비 데이터가 필요하지 않습니다. 작업 순서, 사이클 타임, 작업 달력으로 만든 시뮬레이션만으로 바로 답할 수 있습니다. 센서 프로그램을 포함한 상태 모니터링 트윈은 훨씬 큰 프로젝트가 될 것이며, 그 질문에는 답하지도 못할 것입니다. 의사결정에 답할 수 있는 가장 저렴한 도구가 이깁니다.

시간이 지나도 트윈의 정확도를 어떻게 유지합니까?

공장은 변하며, 업데이트되지 않는 트윈은 현실과 점점 멀어집니다. 초기에 규칙을 정하십시오.

1. 모델마다 담당자를 지정하고, 대리인도 함께 정하십시오.
2. 모델에 버전을 부여하십시오. 누가 무엇을 왜 변경했는지 기록하고, 이전 상태로 되돌릴 수 있는 기능을 유지하십시오.
3. 모델 변경을 공장 변경과 연결하십시오. 새로운 제품군, 이동된 설비, 변경된 교대 패턴은 모델 검토를 촉발해야 합니다.
4. 정기적으로 검증하십시오. 최근 기간의 실제 결과와 트윈의 출력을 비교하고, 차이를 문서로 남기십시오.
5. 단계적으로 확장하십시오. 첫 번째 라인에 담당자, 검증된 모델, 측정 가능한 결과가 모두 갖춰진 후에만 다음 라인을 추가하십시오. 여러 공장으로 확장할 때는 핵심 데이터 정의를 표준화하고, 통제된 범위 내에서 현장별 차이를 허용하십시오.

흔한 실수

• 어떤 의사결정을 지원해야 할지 정하기 전에 소프트웨어부터 구매하는 것.
• 통합, 검증, 유지 관리를 빼고 라이선스 가격만 비교하는 것.
• 패키지형 도구로 충분한 질문인데 플랫폼을 고르거나, 그 반대로 하는 것.
• 실시간 데이터가 구동하지 않는 3D 모델을 트윈의 증거로 받아들이는 것.
• 데이터 피드가 실패할 때 어떤 일이 일어나는지 확인하지 않는 것.
• 프로젝트 팀이 떠난 뒤 모델에 담당자를 두지 않는 것.
• 라인 하나부터 시작하지 않고 공장 전체부터 시작하는 것.

Polaris가 맞는 경우

첫 번째 질문이 계획 수립과 가정 분석(what-if) 의사결정에 관한 것이라면, iFAKT Polaris를 검토해 볼 만한 선택지 중 하나입니다. iFAKT는 Polaris를 생산용 AI와 디지털 트윈을 결합한 제품으로 소개하며, ERP 데이터와 제조 디지털 트윈을 함께 활용합니다. Polaris Designer 모듈은 ERP 데이터, 공정 시간, 자원 구조, 제약 조건 같은 입력 데이터를 단일 진실 공급원 역할을 하는 제품-공정-자원 지식 그래프로 바꿔 줍니다. Polaris Simulator 모듈은 이를 기반으로 생산 시스템을 가상으로 테스트하며, 용량, 인력 배치, 버퍼 시나리오를 포함합니다. 이 제품은 개별 기계의 상태 모니터링이 아니라 생산 계획 의사결정을 목표로 하므로, 먼저 해결하려는 질문과 맞는지 확인하십시오.

함께 살펴볼 관련 주제

• 표준과 상호 운용성: 여러 종류의 기계가 섞여 있는 환경에서 OPC UA, 기타 프로토콜, ISO 23247이 어떻게 맞물리는지 살펴봅니다.
• 미들웨어와 통합: 보고서마다 별도 연결을 만들지 않고 디지털 트윈을 ERP, MES, SCADA와 연결하는 방법입니다.
• 모델 거버넌스: 자주 변경되는 모델의 버전 관리, 접근 역할, 검토 주기를 다룹니다.
• 여러 공장으로의 확장: 중앙 모델과 현장 모델의 차이, 그리고 데이터 정의를 일관되게 유지하는 방법입니다.
• 총 비용과 투자 효과: 3년 비용 구조를 세우고, 파일럿의 전후 비교 지표를 정하는 방법입니다.

다음 단계

디지털 트윈이 지원해야 할 의사결정 하나와, 성공했을 때 변해야 할 수치 하나를 적어 두십시오. 그 페이지를 다음 벤더 미팅에 가져가서, 각 벤더에게 제조용 디지털 트윈 소프트웨어가 파일럿 라인 한 곳에서 어떤 데이터로, 3년 총 비용은 얼마인지 기준으로 이 질문에 어떻게 답할지 물어보십시오.