Physical AI at the Edge: Siemens Energy가 공장마다 현장에서 판단하고 고장 데이터는 모아 학습하는 구조
Siemens Energy는 AWS IoT SiteWise Edge로 공장마다 상태 감시와 에너지 최적화를 현장에서 돌리고, 여러 공장의 고장 데이터는 클라우드에 모아 예지정비 모델을 학습합니다. Industrial AI Summit 2026 패널은 200ms 안에 끝나야 하는 판단은 엣지에 두고, 자율 실행 권한은 네 단계로 나눠 성적에 따라 넓히라고 정리했습니다.
공장 AI는 판단은 현장에서, 학습은 전사에서 하도록 나누면 밀리초 단위로 대응하면서도 여러 공장의 경험을 한 모델에 모을 수 있습니다. 실제로 돌리려면 프로토콜을 한곳에 모으는 엣지 계층, 자율 실행 전 확인 네 가지, 단계별 권한 확대 규칙이 함께 있어야 합니다.
요약
IIoT World는 Industrial AI Summit 2026 패널(Galyos의 Gaspard Duthilleul, AWS의 Sanjay Mahato, InfluxData의 Ian Clark, Grayhawk Consulting Group의 Tauseef Ahmed)을 정리하며 피지컬 AI(Physical AI, 설비·로봇처럼 물리 세계에서 움직이는 AI)를 어디에 두고 어떻게 통제할지를 다뤘습니다. 대표 사례는 Siemens Energy입니다. 이 회사는 공장마다 AWS IoT SiteWise Edge를 두고 상태 감시와 에너지 최적화를 현장에서 실행합니다. Modbus, OPC UA, 구형 Siemens S7을 포함한 프로토콜 10종을 이 엣지 계층에 연결합니다. 여러 공장에서 나온 고장 데이터는 클라우드에 모아 예지정비 모델을 학습하고, 공장 간 에너지 사용도 비교합니다.
이렇게 나누는 이유는 지연입니다. 기사는 200ms 차이가 안전한 정지와 안전사고, 품질 불량, 라인 정지를 가를 수 있다고 설명합니다. 그래서 베어링 이상 신호처럼 즉시 대응해야 하는 판단은 클라우드를 거치지 않고 엣지 모델이 처리합니다. 패널은 위치 결정에 더해 두 가지를 강조했습니다. 하나는 거버넌스입니다. 자율 실행 전에 네 가지를 확인하고, 자율 권한은 관찰에서 완전 자율까지 네 단계로 나눠 성적에 따라 넓힙니다. 다른 하나는 보안입니다. 피지컬 AI가 원래 나뉘어 있던 공장 시스템 층을 이어 붙이므로 IT와 OT 보안을 합쳐야 합니다. 아래에서 이 구조를 개념별로 풀고, 실제로 돌릴 때 필요한 설계와 일정을 덧붙입니다.
핵심 메커니즘
Act Locally, Learn Globally: 판단은 현장, 학습은 전사
판단마다 허용 지연을 먼저 정하고, 그 값에 따라 엣지와 클라우드에 나눠 두는 원칙입니다. 입력은 판단의 종류이고, 처리 기준은 허용 지연과 네트워크 의존도입니다. 200ms 안에 끝나야 하고 네트워크가 끊겨도 돌아가야 하는 판단(안전 정지, 이상 감지, 품질 검사)은 엣지에 둡니다. 초나 분 단위로 충분하고 여러 공장 데이터가 필요한 판단(모델 학습, 공장 간 벤치마크, 에너지 패턴 분석)은 클라우드에 둡니다. 비용 구조도 다릅니다. 엣지는 연산 자원이 빠듯한 대신 왕복 비용이 없고, 클라우드는 저장량에 비례해 비용이 늘지만 질의당 단가가 쌉니다. 기사는 이 원칙을 “acts locally and learns globally”라는 말로 요약합니다.
가상 예시로, 압축기 진동이 기준을 넘으면 엣지가 그 자리에서 감속 명령을 냅니다. 같은 진동 패턴이 다른 공장 세 곳에서 고장으로 이어졌다는 사실은 클라우드가 모은 데이터로 학습해 다음 모델에 반영합니다.
Edge Layer: 프로토콜 10종을 한곳에서 번역하는 현장 계층
공장 설비는 제조사와 연식에 따라 다른 통신 규약을 씁니다. Siemens Energy는 Modbus, OPC UA, 구형 Siemens S7을 포함한 10종을 엣지 계층 하나에 연결합니다. 입력은 설비별 원시 신호이고, 엣지 계층(SiteWise Edge)이 이를 같은 형식의 시계열로 바꾼 뒤 로컬 모델이 상태 감시와 에너지 최적화를 수행합니다. 출력은 현장 조치와 클라우드로 보낼 데이터 일부입니다. 이 계층이 없으면 모델마다 설비별 연결 코드를 따로 짜야 하고, 공장 간 데이터를 합칠 때 같은 센서가 서로 다른 이름으로 들어옵니다.
Agentic Hybrid Workflow: 엣지가 감지하고 클라우드가 서류를 꾸린다
세 번째 층은 엣지와 클라우드를 잇는 에이전트 워크플로입니다. 엣지가 이상을 감지하면, 클라우드 쪽 워크플로가 정비 이력, 설비 매뉴얼, 부품 재고를 조회해 작업지시서와 부품 요청을 만듭니다. 만든 조치는 다시 엣지로 내려가 현장에서 실행됩니다. 즉시 대응은 엣지가 맡고, 여러 시스템을 뒤져야 하는 행정 업무는 클라우드가 맡는 분업입니다. 엣지의 빠른 판단과 클라우드의 넓은 조회를 한 흐름으로 묶는 것이 이 층의 역할입니다.
Confidence Checks: 자율 실행 전 네 가지 확인
모델이 사람 승인 없이 움직이기 전에 네 가지를 확인합니다. 데이터가 지금 값이고 믿을 만한가, 현재 운전 조건이 학습한 범위 안에 있는가, 해도 되는 행동의 범위가 명확히 정해져 있는가, 예외가 생기면 넘길 경로가 있는가입니다. 기사는 거버넌스의 강도를 결과의 무게에 맞추라고 말합니다. 점검을 권하는 일과 핵심 공정 파라미터를 바꾸는 일은 같은 규칙으로 다룰 수 없습니다. 위험이 기준을 넘으면 사람에게 올리는 경로, 결과를 설명하는 기능, 한 공장에서 학습한 모델을 다른 공장에 함부로 쓰지 않는 도메인 경계도 모든 단계에 필요합니다.
Autonomy Ladder: 자율 권한은 네 단계로 얻는다
자율 수준은 관찰, 사람 승인을 거치는 권고, 검증되고 되돌릴 수 있는 일에 한한 패턴 기반 판단, 완전 자율의 네 단계로 올라갑니다. 다음 단계로 가는 조건은 앞 단계에서 꾸준히 낸 성적입니다. 완전 자율은 처음부터 켜는 기능이 아니라 쌓은 기록으로 얻는 권한이라는 뜻입니다. 같은 공장 안에서도 설비마다 단계가 다를 수 있습니다.
Data Trust: Unified Namespace와 태그 온톨로지
모델이 믿는 데이터가 조용히 바뀌는 것을 막는 장치입니다. 공장 데이터는 태그 이름이 바뀌거나, 장비 시계가 어긋나거나, 스키마가 바뀌면서 오염됩니다. 이런 변화는 경보 없이 모델 성능을 떨어뜨립니다. 1차 방어는 Unified Namespace(공장 데이터를 한 이름 체계로 모은 공간)와 태그 온톨로지(태그가 어떤 설비의 무엇인지 정의한 사전)입니다. 2차 방어는 새 센서를 붙일 때 그 값을 과거 패턴과 대조하는 백테스트입니다. 데이터는 저장된 상태, 엣지와 클라우드 사이를 오가는 상태, 쓰이는 순간 세 지점에서 보호합니다.
IT/OT Convergence: 층을 잇는 만큼 보안도 합친다
ISA-95(공장 시스템을 설비 제어부터 경영 시스템까지 층으로 나눈 표준 모델)는 층 사이를 떼어 놓도록 설계됐습니다. 피지컬 AI는 이 경계를 넘습니다. 로봇 하나가 창고 시스템과 MES(제조실행시스템)에 동시에 붙는 식입니다. 그래서 엣지 모델이 오염되거나 프롬프트 공격을 받으면 그 영향이 클라우드 워크플로로 올라가 여러 공장의 작업지시와 정비 일정까지 번질 수 있습니다. 기사는 IT 보안과 OT 보안을 합치라고 권하고, 보안관제센터가 위협 탐지와 대응에 AI를 쓰기 시작했다고 전합니다. 하드웨어 제약도 보안과 함께 봐야 합니다. 엣지 장비는 메모리와 열에 약해서, 여름철 열 스로틀링으로 추론 시간이 30ms 늘어난 사례가 소개됐습니다.
통념과 다른 주장
흔히 이렇게 봅니다공장 AI도 데이터를 클라우드에 모두 모아 중앙에서 돌리는 편이 관리하기 쉽고 성능도 좋다.
패널은 이렇게 봅니다즉시 대응이 필요한 판단은 현장에 두고, 클라우드는 여러 공장의 경험을 모아 학습하는 곳으로 씁니다.
근거200ms 지연이 안전 정지와 사고를 가를 수 있고, 엣지는 네트워크가 끊겨도 돌아가야 합니다. 원시 데이터를 현장에 두고 일부만 올리면 저장 비용도 전량 전송의 약 10분의 1로 줄어듭니다.
흔히 이렇게 봅니다모델 성능이 검증되면 자율 운전을 켜면 된다.
패널은 이렇게 봅니다자율은 관찰, 권고, 패턴 판단, 완전 자율의 네 단계를 거치며 단계마다 성적으로 얻는 권한입니다.
근거점검 권고와 공정 파라미터 변경은 결과의 무게가 다르고, 데이터 신선도·운전 범위·행동 범위·예외 경로가 확인되지 않으면 정확한 모델도 틀린 조치를 낼 수 있습니다.
저자가 든 사례
Siemens Energy: 공장마다 현장에서 판단하고 고장 데이터는 모아 학습
| 항목 | 내용 |
|---|---|
| 상황 | 공장마다 설비와 통신 규약이 다르고, 지연이 곧 안전 문제로 이어짐 |
| 한 일 | 공장마다 AWS IoT SiteWise Edge로 상태 감시와 에너지 최적화를 현장 실행, 프로토콜 10종(Modbus, OPC UA, 구형 Siemens S7 등)을 엣지에 연결, 여러 공장의 고장 데이터를 모아 예지정비 모델 학습, 공장 간 에너지 비교 |
| 결과 | 엣지 모델이 클라우드 왕복 없이 밀리초 단위로 대응. 가동률·비용 절감 수치는 원문에서 밝히지 않음 |
| 연결 | Act Locally, Learn Globally와 Edge Layer의 실제 사례 |
원시 데이터는 현장에, 필요한 부분만 클라우드로
| 항목 | 내용 |
|---|---|
| 상황 | 고주파 원시 데이터를 모두 클라우드로 보내면 저장 비용이 커짐 |
| 한 일 | 원시 텔레메트리를 현장에 5일~1달 보관하고 관련 있는 부분만 클라우드로 전송 |
| 결과 | 저장 비용이 전량 전송의 약 10분의 1 |
| 연결 | Act Locally, Learn Globally의 비용 측면 |
여름철 열 스로틀링: 추론 시간 30ms 증가
| 항목 | 내용 |
|---|---|
| 상황 | 엣지 장비는 메모리가 빠듯하고 열에 약함 |
| 한 일 | 원문은 현상만 소개 |
| 결과 | 여름에 엣지 프로세서가 열 스로틀링에 걸려 추론 시간이 30ms 늘어남 |
| 연결 | 200ms 지연 예산을 잡을 때 계절 변동까지 넣어야 하는 이유 |
기술 디테일: 엣지 판단과 클라우드 학습을 실제로 잇는 법
아래는 원문 구조를 실제로 돌릴 때 필요한 설계를 새로 정리한 가상 예시입니다.
판단마다 지연 예산표를 먼저 만듭니다(Act Locally, Learn Globally). 판단 하나마다 허용 지연, 네트워크 단절 시 동작, 위치(edge/cloud)를 적습니다. 200ms 예산이면 센서 수집, 전처리, 추론, 명령 전달을 각각 재고, 추론은 여름철 최악값(평상시 측정값에 30ms 이상 여유)으로 잡습니다. 측정은 평균이 아니라 p99로 봅니다. 엣지 모델은 작은 분류·이상 탐지 모델(시계열 오토인코더, 트리 계열 등)을 쓰고, 대형 언어 모델은 클라우드 쪽 작업지시 생성에만 씁니다.
엣지가 올리는 이상 이벤트는 구조화된 형식으로 고정합니다(Agentic Hybrid Workflow). 클라우드 워크플로가 이 이벤트를 받아 정비 이력과 재고를 조회하므로 필드가 흔들리면 뒤 단계가 모두 틀립니다. 예시 필드는 다음과 같습니다.
{
"event_id": "plantA-cmp07-20261114-0412",
"asset_id": "plantA/compressor-07",
"tag_path": "plantA/line2/compressor-07/bearing/vibration_rms",
"detected_at": "2026-11-14T04:12:33.120Z",
"edge_action": "derate_20pct",
"anomaly_score": 0.91,
"model_version": "bearing-ae-v14",
"in_training_range": true,
"data_age_ms": 180,
"autonomy_stage": 2
}클라우드 쪽 LLM은 이 이벤트와 정비 이력, 매뉴얼 해당 절, 재고 조회 결과를 받아 작업지시서를 JSON(work_order: 설비, 증상, 원인 후보, 필요 부품, 권장 작업, 근거 문서 ID)으로 냅니다. temperature는 0~0.2로 두고, 같은 이벤트를 3회 생성해 필요 부품이 엇갈리면 사람 검토로 넘깁니다. 근거 문서 ID가 비어 있는 작업지시는 내보내지 않습니다.
네 가지 확인은 코드의 게이트로 만듭니다(Confidence Checks). data_age_ms가 기준(예: 500ms)을 넘거나, 현재 운전 조건이 학습 데이터 범위를 벗어나거나(in_training_range=false), 조치가 허용 목록에 없거나, 예외 담당자가 지정되지 않았으면 자동 실행을 막고 권고로 낮춥니다. 막힌 건수와 이유를 매일 집계하면 다음 단계로 갈 근거가 됩니다.
드리프트 감시는 태그 단위로 돌립니다(Data Trust). 태그 온톨로지에 설비, 측정량, 단위, 정상 범위, 샘플링 주기를 적고, 들어오는 데이터가 이 정의와 어긋나면(새 태그 이름, 단위 변경, 타임스탬프 역전, 주기 변화) 모델 입력에서 빼고 알립니다. 새 센서는 최소 2주 관찰 데이터를 과거 같은 설비 패턴과 비교한 뒤 모델 입력에 넣습니다.
모델은 공장 경계를 지켜 배포합니다(도메인 경계, IT/OT 보안). 클라우드에서 학습한 모델에는 학습에 쓴 공장 목록과 운전 범위를 메타데이터로 붙이고, 그 목록 밖 공장에는 관찰 단계로만 배포합니다. 엣지에 내려가는 모델 파일은 서명하고 엣지에서 서명을 검증한 뒤 올립니다. 원시 데이터 보관 기간(예: 14일)과 업로드 대상(이상 구간 앞뒤, 시간 단위 집계)은 공장별 설정으로 둡니다.
현업 실행 디테일: 누가, 언제, 무엇을
| 역할 | 담당 | 하는 일 |
|---|---|---|
| 설비 정비 리더 | 공장 정비팀장 | 대상 설비 선정, 이상 판정 기준과 허용 조치 목록 확정 |
| OT 엔지니어 | 제어·자동화 담당 | 프로토콜 연결, 태그 정리, 엣지 장비 설치와 열 관리 |
| 데이터·ML 담당 | 데이터팀 | 모델 학습, 지연 측정, 드리프트 감시 |
| 보안 담당 | IT·OT 보안 | 엣지 장비 접근 통제, 모델 서명, 이벤트 감시 |
| 승인권자 | 공장장 | 자율 단계 승격 승인 |
시작 전 준비물. 대상 설비의 최근 1~2년 고장·정비 기록, 설비별 통신 규약과 태그 목록, 정비 매뉴얼, 부품 재고 조회 경로, 판단마다 허용 지연과 허용 조치를 적은 표입니다.
현장에 묻는 질문. 지금 이 설비가 이상하다는 것을 누가 무엇을 보고 아는가? 이상을 발견하고 작업지시가 나가기까지 몇 시간이 걸리는가? 네트워크가 끊기면 지금은 어떻게 대응하는가? 자동으로 해도 되는 조치와 반드시 사람이 해야 하는 조치는 무엇인가? 같은 설비가 다른 공장에도 있는가?
진행 판정 기준(가상 예시). 관찰 단계 4주 동안 엣지 판단 지연 p99가 예산 안에 들고, 정비팀이 확인한 이상 가운데 모델이 잡은 비율과 오경보 건수가 사전에 합의한 기준을 넘지 않으면 권고 단계로 올립니다. 권고 단계에서는 사람이 승인한 비율과 수정한 작업지시 비율을 보고, 승인 없이 실행할 조치 목록을 공장장이 서명해야 패턴 판단 단계로 갑니다.
어디에 먼저 쓰나. 여러 공장에 같은 종류의 회전 설비(압축기, 펌프, 팬)가 있는 제조사라면 이 구조가 가장 빨리 값을 냅니다. 한 공장, 한 설비 종류로 관찰과 권고 단계까지 12주 안에 돌리고, 효과가 확인되면 같은 엣지 구성, 확인 규칙, 보안 통제를 그대로 다른 공장에 복제합니다. 기사도 범위와 성공 기준, 허용 조치를 정한 작은 프로젝트로 시작해 한 곳에서 검증된 패턴을 다른 시설로 반복하라고 권합니다. 이때 클라우드 학습은 공장이 두세 곳 이상 붙은 뒤에야 의미가 커지므로, 첫 공장 단계에서는 태그 온톨로지를 전사 공통으로 정해 두는 일이 가장 중요한 투자입니다.
원문 사례
| 항목 | 내용 |
|---|---|
| 원문 | IIoT World, Paul Viorel, 2026.11.12 (InfluxData 후원) |
| 출처 행사 | Industrial AI Summit 2026 패널 |
| 패널 | Gaspard Duthilleul(Galyos), Sanjay Mahato(AWS), Ian Clark(InfluxData), Tauseef Ahmed(Grayhawk Consulting Group) |
| 사례 기업 | Siemens Energy: 공장마다 AWS IoT SiteWise Edge로 상태 감시·에너지 최적화, 프로토콜 10종 연결, 고장 데이터 모아 예지정비 학습, 공장 간 에너지 비교 |
| 지연 | 200ms가 안전 정지와 사고·품질 불량·라인 정지를 가를 수 있음 |
| 저장 비용 | 원시 데이터 5일~1달 현장 보관 후 일부 전송 시 전량 전송의 약 10분의 1 |
| 하드웨어 | 여름철 열 스로틀링으로 추론 시간 30ms 증가 |
| 거버넌스 | 자율 실행 전 확인 4가지, 자율 4단계, 데이터 보호 3지점 |
| 보안 | ISA-95 층 경계를 넘는 연결, 엣지 모델 오염과 프롬프트 공격의 전파, IT·OT 보안 통합 |
| 성과 수치 | 가동률·비용 절감은 원문에서 밝히지 않음 |
핵심 개념
- AWS IoT SiteWise Edge
- 공장 현장 장비에서 설비 데이터를 수집·처리하고 로컬로 모델을 돌리게 하는 AWS의 엣지 소프트웨어입니다.
- Modbus · OPC UA · S7
- 설비와 제어기가 데이터를 주고받는 통신 규약입니다. S7은 Siemens PLC 계열이 쓰는 규약입니다.
- Condition monitoring
- 진동, 온도, 전류 같은 신호로 설비 상태를 계속 지켜보는 일입니다.
- Thermal throttling
- 프로세서가 과열되면 스스로 속도를 낮추는 동작입니다. 엣지 추론 지연을 늘립니다.
- Schema drift
- 데이터 구조나 태그 정의가 예고 없이 바뀌어 모델 입력이 달라지는 현상입니다.
- ISA-95
- 설비 제어, 생산 관리(MES), 경영 시스템(ERP)을 층으로 나눈 제조 시스템 통합 표준입니다.
- p99 지연
- 요청 100건 가운데 가장 느린 1건 수준의 지연입니다. 안전 판단은 평균이 아니라 이 값으로 봅니다.
내 메모
TODO: 내 생각 추가
원문은 IIoT World 「How to Deploy, Govern, and Secure Physical AI」(Paul Viorel, 2026.11.12, InfluxData 후원)로, Industrial AI Summit 2026 패널 내용을 정리한 기사입니다. 기사는 발언자별로 주장을 나누지 않아 노트에서도 패널 전체의 의견으로 적었습니다. 요약, 핵심 메커니즘의 원문 설명, 통념과 다른 주장, 사례, 원문 사례 표는 기사 내용을 AX Review가 다시 정리했습니다. 기술 디테일, 현업 실행 디테일, 인포그래픽, 표의 필드명·일정·기준값은 실제로 돌릴 때 필요한 내용을 새로 작성한 가상 예시입니다. 전체 내용은 원문에서 볼 수 있습니다.