2025년 5월 04일·8분
지멘스와 클라우드: 자동화, 소프트웨어 및 디지털 트윈
지멘스가 자동화, 산업용 소프트웨어, 디지털 트윈을 결합해 기계와 공장을 클라우드 분석 및 운영과 연결하는 방식을 확인하세요.
지멘스가 자동화, 산업용 소프트웨어, 디지털 트윈을 결합해 기계와 공장을 클라우드 분석 및 운영과 연결하는 방식을 확인하세요.
“물리적 경제를 클라우드에 연결한다”는 것은 생산 라인에서 돌아가는 기계, 펌프, 로봇, 물류 차량 같은 현실 세계의 산업 활동을 분석하고 조정하며 개선할 수 있는 소프트웨어와 연결하는 것을 말합니다.
여기서 ‘물리적 경제’는 제조, 에너지 생산·배분, 건물 시스템, 물류처럼 유형의 것을 생산하고 이동시키는 경제 부문을 뜻합니다. 이러한 환경은 속도, 온도, 진동, 품질 검사, 에너지 사용 같은 끊임없는 신호를 생성합니다. 하지만 그 신호들을 의사결정으로 바꿀 때 비로소 가치가 생깁니다.
클라우드는 확장 가능한 컴퓨팅과 공유 데이터 접근을 제공합니다. 공장 및 플랜트 데이터가 클라우드 애플리케이션에 도달하면, 팀은 여러 라인이나 사이트 전반의 패턴을 포착하고 성능을 비교하며 유지보수를 계획하고 일정 관리를 개선하며 품질 문제를 더 빨리 추적할 수 있습니다.
목표는 “모든 것을 클라우드로 보내는 것”이 아니라, 올바른 데이터를 올바른 장소로 보내 현실 세계의 조치가 개선되도록 하는 것입니다.
이 연결은 흔히 세 가지 구성 요소로 설명됩니다:
다음으로는 개념을 실용적인 예와 함께 살펴봅니다—데이터가 엣지에서 클라우드로 어떻게 이동하는지, 인사이트가 어떻게 현장 조치로 바뀌는지, 파일럿에서 확장으로 가는 채택 경로 등입니다. 구현 단계 미리보기를 원하면 /blog/a-practical-adoption-roadmap-pilot-to-scale 로 건너뛰세요.
지멘스의 “물리적을 클라우드에 연결” 스토리는 세 계층이 함께 작동하는 것으로 이해하는 것이 가장 쉽습니다: 현실 데이터를 생성하고 제어하는 자동화, 수명주기 전반의 데이터를 구조화하는 산업용 소프트웨어, 그리고 분석과 애플리케이션이 사용할 수 있도록 안전하게 데이터를 옮기는 플랫폼입니다.
현장에서는 지멘스의 산업용 자동화 영역이 컨트롤러(PLC), 드라이브, HMI/운전자 패널, 산업용 네트워크를 포함합니다—센서를 읽고 제어 로직을 실행하며 기계를 규격 내에서 유지하는 시스템입니다.
이 계층은 결과에 결정적입니다. 클라우드의 통찰은 궁극적으로 설정값(setpoint), 작업 지시, 알람, 유지보수 조치로 다시 번역되어야 하기 때문입니다.
지멘스의 산업용 소프트웨어는 생산 전과 도중에 사용되는 도구 전반을 아우릅니다—엔지니어링, 시뮬레이션, PLM, MES가 하나의 흐름처럼 작동한다고 생각하세요. 실무적으로는 설계를 재사용하고 프로세스를 표준화하며 변경을 관리하고 설계·계획·실제 구축 관점이 정렬되도록 돕는 "접착제" 역할을 합니다.
성과는 보통 명확하고 측정 가능합니다: 엔지니어링 변경 속도 향상, 재작업 감소, 가동시간 증가, 품질 일관성 향상, 스크랩/폐기 감소 등입니다. 이는 의사결정이 동일한 구조화된 문맥에 기반할 때 나타납니다.
기계와 클라우드 애플리케이션 사이에는 연결성과 데이터 계층(일반적으로 산업용 IoT 및 엣지-투-클라우드 통합으로 묶이는)이 있습니다. 목표는 적절한 데이터만—안전하게 그리고 맥락과 함께—클라우드나 하이브리드 환경으로 이동시켜 대시보드, 분석, 사이트 간 비교를 수행할 수 있게 하는 것입니다.
이 조각들은 종종 Siemens Xcelerator라는 우산 아래에 프레임됩니다—지멘스 포트폴리오와 파트너·통합 생태계를 묶는 방식으로 생각하는 것이 가장 좋습니다. 단일 제품이라기보다는 기능을 패키지하고 연결하는 방법입니다.
현장(센서/기계) → 자동화/제어(PLC/HMI/드라이브) → 엣지(수집/정규화) → 클라우드(저장/분석) → 애플리케이션(유지보수, 품질, 에너지) → 현장으로의 액션(조정, 일정, 알림).
현장 장비에서 클라우드 통찰로, 그리고 다시 현장 조치로 이어지는 그 루프가 스마트 제조 이니셔티브의 핵심입니다.
공장은 서로 다르게 성장한 두 종류의 기술로 운영됩니다.
**운영 기술(OT)**은 물리적 프로세스를 움직이게 하는 기술입니다: 센서, 드라이브, PLC, CNC, SCADA/HMI 화면, 안전 시스템 등. OT는 밀리초 단위, 가동시간, 예측 가능한 동작을 중시합니다.
**정보 기술(IT)**은 정보를 관리합니다: 네트워크, 서버, 데이터베이스, 아이덴티티 관리, ERP, 분석, 클라우드 애플리케이션 등. IT는 표준화, 확장성, 다수 사용자·위치에 대한 데이터 보호를 중시합니다.
역사적으로 공장들은 OT와 IT를 분리해 왔습니다. 분리가 신뢰성과 안전을 높였기 때문입니다. 많은 생산 네트워크는 수년간 "그냥 돌아가도록" 설계되었고, 변경이나 인터넷 접근이 제한되었으며 누가 무엇을 건드리는지 엄격히 관리되었습니다.
현장과 엔터프라이즈·클라우드 시스템을 연결하는 것은 단순히 들리지만, 다음과 같은 마찰점에서 문제가 발생합니다:
T_001 같은 태그는 자산·위치·유닛·제품에 일관되게 매핑되지 않으면 외부에서 아무 의미가 없습니다.모든 장치가 연결되어도 표준 데이터 모델 없이는 가치가 제한적입니다—자산, 이벤트, KPI를 설명하는 공유 방식이 필요합니다. 표준화된 모델은 커스텀 매핑을 줄이고 분석을 재사용 가능하게 하며 여러 공장이 성능을 비교하는 데 도움을 줍니다.
목표는 실용적인 사이클입니다: 데이터 → 통찰 → 변경. 기계 데이터가 수집되어(대개 생산 맥락과 함께) 분석되고, 그 다음 일정 업데이트, 설정값 조정, 품질 검사 개선, 유지보수 계획 변경 등으로 바뀌어 클라우드 통찰이 실제로 현장 운영을 개선하도록 하는 것입니다.
공장 데이터는 클라우드에서 시작하지 않습니다—기계에서 시작합니다. 지멘스 스타일의 구성에서는 "자동화 계층"이 물리적 신호를 다른 시스템이 안전하게 사용할 수 있는 신뢰 가능한 타임스탬프 정보로 바꾸는 곳입니다.
실무적으로 자동화는 함께 작동하는 구성 요소의 스택입니다:
어떤 신호든 신뢰하려면 누군가가 그 신호가 무엇을 의미하는지 정의해야 합니다. 엔지니어링 환경은 다음 작업에 사용됩니다:
이는 소스에서 데이터를 표준화합니다—태그 이름, 단위, 스케일링, 상태—그래서 상위 소프트웨어가 추측하지 않아도 됩니다.
구체적 흐름의 예는 다음과 같습니다:
베어링 온도 센서가 경고 임계값을 넘음 → PLC가 이를 감지해 상태 비트 설정 → HMI/SCADA가 알람을 발생시키고 이벤트를 타임스탬프와 함께 기록 → 조건이 보전 규칙으로 전달되어 → 보전 작업 지시가 생성됩니다("모터 M-14 점검, 베어링 과열"). 이 작업 지시에는 최근 값과 운전 맥락이 포함됩니다.
이 체인이 바로 자동화가 데이터 엔진인 이유입니다: 원시 측정값을 신뢰 가능한 의사결정 준비 신호로 바꿉니다.
자동화는 신뢰할 수 있는 현장 데이터를 생성하지만, 산업용 소프트웨어는 그 데이터를 엔지니어링, 생산, 운영 전반의 조정된 결정으로 바꿉니다.
산업용 소프트웨어는 단일 도구가 아니라 워크플로의 일부를 "소유"하는 여러 시스템의 집합입니다:
디지털 스레드는 하나의 일관된 제품·공정 데이터 세트가 작업 전반을 따라 흐르는 것을 의미합니다—엔지니어링에서 제조 계획, 현장까지 그리고 다시 엔지니어링으로 피드백됩니다.
부서마다 정보를 재생성하고 누가 가진 파일이 최신인지 다투는 대신, 연결된 시스템을 통해 설계의 변경이 제조 계획으로 흐르고 제조 피드백이 엔지니어링으로 돌아갑니다.
이 도구들이 연결되면 회사는 보통 실질적 결과를 봅니다:
결과적으로 "최신 파일"을 찾는 데 드는 시간이 줄고 처리량, 품질, 변경 관리 개선에 더 많은 시간을 쓸 수 있습니다.
디지털 트윈은 제품, 생산 라인, 자산처럼 실제 존재하는 것의 살아있는 모델로—시간이 지나도 실제 데이터와 연결되어 있습니다. "트윈"이라는 개념은 설계에서 멈추지 않는다는 점을 강조합니다. 물리적 대상이 만들어지고 운영·유지보수되는 동안 트윈은 계획된 대로가 아닌 실제로 일어난 일을 반영합니다.
지멘스의 프로그램에서 디지털 트윈은 일반적으로 산업용 소프트웨어와 자동화 전반에 걸쳐 존재합니다: 엔지니어링 데이터(CAD, 요구사항), 운영 데이터(센서·드라이브·기계의 텔레메트리), 성능 데이터(품질, 다운타임, 에너지)가 연결되어 팀이 단일 일관된 기준으로 의사결정할 수 있게 합니다.
트윈은 시각화나 보고 도구와 혼동되기 쉽습니다. 구분하자면:
관심사가 다른 다양한 "트윈"이 존재합니다:
실용적 트윈은 보통 다음을 포함한 여러 소스에서 당겨옵니다:
이 입력들이 연결되면 팀은 더 빨리 문제를 해결하고 변경을 적용하기 전에 검증하며 엔지니어링과 운영의 정렬을 유지할 수 있습니다.
시뮬레이션은 제품, 기계, 생산 라인이 다양한 조건에서 어떻게 동작할지를 예측하는 디지털 모델을 사용하는 실무입니다. 가상 시운전은 한 단계 더 나아가 제어 로직을 실제 장비에 적용하기 전에 시뮬레이션된 공정에 대해 "커미셔닝"(테스트·튜닝)합니다.
보통 기계적 설계와 공정 거동은 시뮬레이션 모델로 표현되고(종종 디지털 트윈과 연결), 제어 시스템은 현장에서 사용할 동일한 PLC/컨트롤러 프로그램을 실행합니다.
피지컬 라인이 조립되기를 기다리는 대신, 컨트롤러가 가상 버전의 기계를 구동합니다. 이를 통해 제어 로직을 시뮬레이션된 프로세스에 검증할 수 있습니다:
가상 시운전은 후기 재작업을 줄이고 팀이 더 일찍 문제를 발견하게 하여 레이스 컨디션, 역station 간의 신호 누락, 안전하지 않은 동작 시퀀스 같은 문제를 찾아냅니다. 또한 속도나 체류시간, 불량 처리 변경이 처리량과 결함에 어떻게 영향을 미치는지 테스트해 품질을 지원합니다.
현장 시운전이 완전히 수월해진다는 보장은 없지만, 반복이 더 빠르고 방해가 적은 환경으로 위험을 이동시킵니다.
제조사가 계절 수요를 맞추기 위해 포장 라인 속도를 15% 높이고자 한다고 가정해 보세요. 변경된 PLC 로직을 물리적으로 적용하기 전에 가상 라인에서 테스트합니다:
가상 테스트 후 팀은 개선된 로직을 계획된 창에 배포합니다—이미 주의 깊게 봐야 할 엣지 케이스를 알고 있는 상태입니다. 모델이 이를 어떻게 지원하는지에 대한 추가 내용은 /blog/digital-twin-basics 를 참조하세요.
엣지-투-클라우드는 실제 기계 거동을 클라우드 데이터로 바꾸는 경로입니다—공장의 가동시간을 해치지 않으면서요.
엣지 컴퓨팅은 기계 가까이(종종 산업용 PC나 게이트웨이)에서 수행되는 로컬 처리입니다. 모든 원시 신호를 클라우드로 전송하는 대신 엣지에서 필터링, 버퍼링, 맥락화(Enrichment)를 수행할 수 있습니다.
이것이 중요한 이유는 공장이 제어에 저지연을 필요로 하고 인터넷 연결이 약하거나 끊길 때에도 높은 신뢰성이 필요하기 때문입니다.
일반적인 아키텍처는 다음과 같습니다:
디바이스/센서 또는 PLC → 엣지 게이트웨이 → 클라우드 플랫폼 → 애플리케이션
산업용 IoT(IIoT) 플랫폼은 일반적으로 안전한 데이터 수집, 디바이스·소프트웨어 플릿 관리(버전, 상태, 원격 업데이트), 사용자 접근 제어, 분석 서비스를 제공합니다. 많은 공장 사이트를 일관된 방식으로 관리 가능하게 하는 운영 계층이라고 생각하세요.
대부분의 기계 데이터는 시계열(time-series) 입니다: 시간에 따라 기록된 값들.
원시 시계열 데이터는 자산 ID, 제품, 배치, 교대조, 작업 지시 같은 맥락이 추가될 때 훨씬 더 유용해져 클라우드 앱이 단순히 추세를 그리는 것을 넘어 운영 질문에 답할 수 있습니다.
닫힌 루프 운영은 생산 데이터가 수집·보고만 되는 것이 아니라 다음 시간·교대·배치를 개선하는 데 사용된다는 개념입니다.
지멘스 스타일 스택에서는 자동화와 엣지 시스템이 기계 신호를 포착하고, MES/운영 계층이 이를 작업 맥락으로 조직하며, 클라우드 분석은 패턴을 찾아 권고를 생성하고 그 권고가 현장으로 다시 전달됩니다.
MES/운영 소프트웨어(예: Siemens Opcenter)는 실장비 및 공정 데이터를 사용해 작업을 실제 발생 상황에 맞춥니다:
닫힌 루프 제어는 무엇을, 어떻게, 어떤 투입물로 만들었는지를 정확히 아는 것에 기반합니다.
MES 추적성은 보통 로트/일련번호, 공정 파라미터, 사용 장비, 운영자 행동을 캡처해 계보(genealogy)(부품→완제품 관계)와 감사 추적을 구축합니다. 이 이력이 있어야 클라우드 분석이 범용 권고가 아니라 특정 원인(예: 특정 캐비티, 특정 공급업체 로트, 특정 레시피 단계)을 짚어낼 수 있습니다.
클라우드 인사이트는 명확한 로컬 조치로 반환될 때만 운영적 가치가 있습니다: 감독자 알림, 제어 엔지니어에 대한 설정값 권고, 작업표준서(SOP) 업데이트 등. 이상적으로는 MES가 “전달 채널”이 되어 올바른 지침이 올바른 스테이션에 적시에 도달하게 합니다.
공장은 전력계와 기계 사이클 데이터를 클라우드로 집계해 워밍업 후 마이크로 스토퍼(micro-stoppages) 동안 반복되는 에너지 스파이크를 발견합니다. 분석은 스파이크를 특정 재시작 시퀀스에 연결합니다.
팀은 엣지로 변경을 푸시합니다: 재시작 램프 속도를 조정하고 PLC 로직에 짧은 인터록 검사를 추가합니다. MES는 업데이트된 파라미터를 모니터링하고 스파이크 패턴이 사라졌음을 확인합니다—인사이트에서 제어, 검증된 개선으로 닫힌 루프를 완성한 것입니다.
공장 시스템을 클라우드 애플리케이션과 연결하면 일반 사무용 IT와는 다른 위험들이 발생합니다: 안전, 가용성, 제품 품질, 규제 준수 등입니다.
다행히도 대부분의 "산업용 클라우드 보안"은 신원·네트워크 설계와 데이터 사용 규칙에 대한 규율로 귀결됩니다.
사람, 기계, 애플리케이션을 각각 명확한 권한이 필요한 신원으로 다루세요.
역할 기반 접근 제어(RBAC)를 사용해 운영자·보전·엔지니어·외부 벤더가 꼭 필요한 것만 보거나 실행하도록 합니다. 예를 들어, 벤더 계정은 특정 라인의 진단은 볼 수 있지만 PLC 로직을 변경하거나 생산 레시피를 다운로드할 수는 없게 합니다.
원격 접속에는 가능한 경우 강력한 인증(MFA)을 사용하고 공유 계정은 피하세요. 공유 자격증명은 누가 무엇을 언제 변경했는지 감사를 불가능하게 만듭니다.
여전히 많은 플랜트가 "에어갭"을 이야기하지만, 실제 운영은 원격 지원, 공급업체 포털, 품질 보고, 본사 분석 등 원격 연결을 요구합니다.
분리가 시간이 지남에 따라 약해지는 것에 의존하기보다는 의도적으로 분절(segmentation)을 설계하세요. 일반적 접근은 엔터프라이즈 네트워크와 OT 네트워크를 분리하고, 그 사이를 엄격히 관리되는 경로로 구역(셀/영역)별로 나누는 것입니다.
목표는 간단합니다: 폭발 반경을 제한하라. 한 워크스테이션이 침해되더라도 그것이 곧바로 사이트 전체의 컨트롤러로 가는 경로를 제공하지 않아야 합니다.
데이터를 공장에서 스트리밍하기 전에 다음을 정의하세요:
초기에 소유권과 보존 기간을 명확히 하세요. 거버넌스는 단순한 규정 준수가 아니라 “데이터 스프로일”과 중복 대시보드, 수치의 공식성에 대한 논쟁을 방지합니다.
플랜트는 노트북처럼 패치할 수 없습니다. 일부 자산은 긴 검증 주기를 가지며 예기치 않은 다운타임은 비용이 큽니다.
단계적 롤아웃을 사용하세요: 실험실이나 파일럿 라인에서 업데이트를 테스트하고 유지보수 시간에 배포하며 롤백 계획을 준비하세요. 엣지 디바이스와 게이트웨이에 대해서는 표준 이미지와 구성을 유지해 사이트 간 일관된 업데이트가 가능하도록 합니다.
좋은 산업용 클라우드 프로그램은 "빅뱅"형 플랫폼 롤아웃이 아니라 반복 가능한 패턴을 만드는 것입니다. 첫 프로젝트를 기술적·운영적 템플릿으로 삼으세요.
비즈니스 영향이 명확한 단일 생산 라인, 기계, 또는 유틸리티 시스템을 선택하세요.
우선순위 문제가 하나 있어야 합니다(예: 포장 라인의 예기치 못한 다운타임, 성형 스테이션의 스크랩, 압축공기 과다 사용).
빠른 가치를 증명할 수 있는 하나의 지표를 선택하세요: OEE 손실 시간, 스크랩률, 단위당 kWh, 평균 고장 간격(MTBF), 전환 시간 등. 이 지표가 파일럿의 북극성(north star)이며 확장 시 기준선이 됩니다.
대부분의 파일럿은 클라우드가 아니라 기본 데이터 문제로 멈춥니다.
이 요소들이 갖춰지지 않았다면 초기에 고치세요—자동화와 산업용 소프트웨어는 입력 데이터의 품질에 의해 제한됩니다.
내부에서 가벼운 생산 대시보드, 예외 큐, 보전 선별 앱, 데이터 품질 검사기 같은 커스텀 도구를 만들 계획이라면 아이디어에서 작동하는 소프트웨어로 빠르게 가는 경로가 있으면 도움이 됩니다. 일부 팀은 채팅 기반 플랫폼(예: Koder.ai)로 이러한 "글루 앱"을 프로토타이핑한 뒤 데이터 모델과 사용자의 워크플로가 검증되면 반복합니다.
"완료"의 의미를 문서화하세요: 목표 개선 수준, 투자 회수 기간, 지속적 튜닝의 책임자.
확장하려면 세 가지를 표준화하세요: 자산/태그 템플릿, 배포 플레이북(사이버보안 및 변경 관리 포함), 그리고 사이트 전반의 공유 KPI 모델. 그런 다음 한 라인에서 한 영역으로, 같은 패턴의 여러 공장으로 확장합니다.
현장 자산을 클라우드 분석에 연결하는 작업은 단일 프로젝트가 아니라 시스템으로 접근할 때 가장 잘 작동합니다. 유용한 사고 모델은 다음과 같습니다:
이미 가지고 있는 데이터로 달성할 수 있는 성과부터 시작하세요:
지멘스 솔루션으로 표준화하든 다수 공급업체를 통합하든, 다음을 평가하세요:
또한 인사이트를 현장에서 사용 가능하게 만드는 라스트 마일 애플리케이션을 얼마나 빨리 제공할 수 있는지 고려하세요. 일부 팀은 핵심 산업 플랫폼과 빠른 앱 개발을 결합합니다(예: React 기반 웹 인터페이스와 Go/PostgreSQL 백엔드를 빠르게 배포). Koder.ai 같은 도구는 채팅 인터페이스를 통해 이를 빠르게 수행하는 한 방법이며, 소스 코드 내보내기와 배포 제어 옵션도 유지합니다.
흥미로운 파일럿에서 측정 가능한 확장으로 이동하려면 다음을 고려하세요:
진행 상황은 작은 스코어카드로 측정하세요: OEE 변화, 예기치 못한 다운타임 시간, 스크랩/재작업률, 단위당 에너지, 엔지니어링 변경 사이클 시간.
현실 세계의 운영(기계, 유틸리티, 물류)이 신뢰할 수 있는 신호를 소프트웨어로 보내 이를 분석·조정하고, 그 통찰을 다시 작업 지시, 설정값, 보전 작업 등으로 현장에 반영하는 작동 루프를 만드는 것을 의미합니다. 목표는 "모든 것을 업로드"하는 것이 아니라 가동시간, 품질, 생산성, 에너지 같은 실질적 성과입니다.
한 번에 모든 기계 데이터를 클라우드로 보낼 필요는 없습니다. 우선 하나의 사용 사례와 필요한 데이터만으로 시작하세요.
실용적인 규칙: 고주파 데이터는 로컬에서 수집·보관하고, 이벤트·변화·계산된 KPI를 클라우드로 전달하세요.
세 계층이 함께 작동하는 구조로 생각하세요:
진짜 가치는 이들 세 가지가 닫힌 루프로 연결될 때 나타납니다. 단일 계층만으로는 부족합니다.
문자 그대로의 다이어그램(문장형)은 다음과 같습니다:
다음과 같은 마찰 요소들이 흔히 발생합니다:
T_001 같은 태그가 자산/제품/배치와 매핑되어 있지 않음).대부분의 통합 작업은 단순한 네트워킹이 아니라 “번역 + 맥락화 + 거버넌스” 작업입니다.
연결만으로는 추세만 보입니다; 데이터 모델이 있어야 의미가 생깁니다. 최소한으로 정의해야 할 항목들:
안정된 모델이 있으면 대시보드와 분석을 라인·공장 간 재사용할 수 있어 일회성 프로젝트를 줄일 수 있습니다.
디지털 트윈은 시간에 따라 실제 운영 데이터와 연결된 살아있는 모델입니다. 흔한 유형들:
디지털 트윈은 **단순 3D 모델(기하학)**이나 **단순 대시보드(보고서)**가 아닙니다. 운영 데이터와 결합된 행동·제약·예측적 기능이 핵심입니다.
가상 시운전(Virtual commissioning)은 실제 장비를 만지기 전에 **실제 제어 로직(PLC 프로그램)**을 시뮬레이션된 공정/라인에 대고 테스트하는 방법입니다. 이를 통해 다음을 할 수 있습니다:
모든 현장 작업을 완전히 대체하지는 못하지만, 위험을 더 빨리 발견하고 반복을 빠르게 수행할 수 있는 환경으로 위험을 왼쪽으로 이동시킵니다.
핵심은 실질적이고 반복 가능한 패턴을 만드는 것입니다. 첫 프로젝트를 템플릿으로 삼아 기술적으로나 운영적으로 복제할 수 있어야 합니다.
다음과 같은 기본 원칙에 집중하세요:
보안은 단지 IT 편의가 아니라 가용성·안전·감사 가능성을 전제로 설계되어야 성공합니다.
설계 시 신뢰성을 고려하세요: 클라우드 연결이 끊겨도 공장은 계속 가동되어야 합니다.