AI-Ready Data Backbone: 공장 AI를 20곳으로 넓힐 때 깨지는 것과 Volkswagen의 설계

공장 하나에서 잘 맞던 AI 모델이 공장 20곳에서 흔들린다면 먼저 데이터 바탕을 의심해야 합니다. 공장마다 태그 이름, 시각, 맥락이 어긋나기 때문입니다. Volkswagen은 데이터를 공장마다 그대로 두고 시맨틱 레이어로 뜻만 하나로 맞췄습니다. 그 덕에 43개 공장이 한 공장의 품질 개선을 함께 씁니다. 따라 하려면 같은 설비가 있는 공장 두 곳에서 태그 사전과 시각 기준부터 맞춰 봐야 합니다.

요약

IIoT World의 Paul Viorel이 Industrial AI Summit 2026의 패널 토론을 정리했습니다. 패널은 Galyos의 Gaspard Duthilleul, AWS의 Sanjay Mahato, InfluxData의 Ian Clark, Grayhawk Consulting Group의 Tauseef Ahmed입니다. 기사는 발언을 사람별로 나누지 않고 패널 전체의 의견으로 묶었습니다. 출발점은 한 장면입니다. 공장 한 곳에서 잘 맞던 AI 모델을 공장 20곳에 깔면 결과가 흔들립니다. 패널은 그 원인을 모델이 아니라 데이터에서 찾았습니다. 같은 태그 이름이 공장마다 다른 값을 가리키고(tag naming drift), 여러 원천의 시각이 서로 어긋나며(clock skew), 측정값에는 설비, 제품, 정비 이력 같은 맥락이 빠져 있습니다. 태그 단위로 값을 매기는 historian(설비 시계열 저장소) 라이선스는 AI용 센서를 늘릴수록 비용을 키웁니다. 공장이 하나 늘 때마다 수작업 보정과 맞춤 커넥터도 함께 늘어납니다.

처방은 AI-ready data backbone(AI가 바로 쓸 수 있는 데이터 바탕)의 다섯 가지 조건입니다. 끊겨도 잃지 않는 내구성, 나노초 단위의 시각, 개방형 표준, 학습과 추론을 함께 받치는 구조, 공장 사이의 뜻을 맞추는 semantic layer(시맨틱 레이어)입니다. 대표 사례는 Volkswagen Group의 Digital Production Platform입니다. 이 플랫폼은 엣지에서 데이터를 미리 고르지 않고 모두 모읍니다. 수집하는 순간 제품, 정비 상태, 운전 조건을 메타데이터로 붙입니다. 데이터는 중앙으로 옮기지 않고 공장에 두되 시맨틱 레이어로 뜻을 맞춥니다. 그래서 43개 공장 중 한 곳에서 만든 품질 개선이 나머지 42곳에 그대로 쓰이고 지금은 공장 70곳을 더 붙이는 확대를 진행 중입니다. 패널은 투자 근거를 기술 사양이 아니라 정지 시간, 첫 합격률 같은 사업 문제로 세우고 데이터를 담당자와 예산이 있는 제품으로 다루라고 권합니다. 아래에서는 이 조건을 여섯 가지 작동 원리로 풀고 공장 두 곳에서 시험할 때 필요한 필드와 일정, 판정 기준을 붙입니다.

핵심 메커니즘

Scale failure points: 공장이 늘 때 먼저 깨지는 곳

무엇인가. 공장 한 곳에서는 드러나지 않다가 공장 수가 늘면 한꺼번에 터지는 데이터 문제의 묶음입니다. 패널은 태그 이름, 시각, 맥락, historian 라이선스, 공장마다 늘어나는 수작업 커넥터를 꼽았습니다.

어떻게 작동하나. 공장 한 곳에서는 엔지니어가 태그의 뜻을 알고, 시각 차이를 눈으로 보정하고 빠진 맥락을 기억으로 메웁니다. 공장이 20곳이 되면 이 암묵지가 통하지 않습니다. 같은 이름의 태그가 다른 측정값을 가리키면 모델은 서로 다른 신호를 같은 것으로 배웁니다. 시각이 어긋나면 원인과 결과의 순서가 뒤바뀐 학습 데이터가 생깁니다. 맥락이 없으면 정비 직후의 정상 변화와 진짜 이상을 가릴 수 없습니다. 비용 쪽에서는 태그당 과금과 공장별 커넥터가 공장 수만큼 불어납니다.

언제 보나. 두 번째 공장에 모델을 옮길 때가 첫 신호입니다. 정확도가 떨어지면 재학습부터 하지 말고 태그 사전과 시각 기준을 먼저 대조합니다.

작은 예시(가상). A 공장의 SPDL_VIB_01은 스핀들 진동 실효값인데, B 공장의 같은 이름 태그는 피크값입니다. A에서 학습한 이상 탐지 모델을 B에 깔면 정상 설비에도 경고가 쏟아집니다.

Store-and-forward: 끊겨도 버리지 않고 나중에 채우기

무엇인가. 네트워크나 상위 시스템이 멈춰도 엣지가 데이터를 쌓아 두었다가 연결이 돌아오면 순서대로 보내는 방식입니다. 패널이 꼽은 첫째 조건인 내구성의 핵심입니다.

어떻게 작동하나. 입력은 원래 시각이 찍힌 설비 신호입니다. 엣지 버퍼가 상위 연결이 끊긴 동안 이 신호를 로컬에 쌓습니다. 연결이 돌아오면 버퍼가 빈 구간을 원래 시각 그대로 채웁니다. 이것이 backfill(사후 채움)입니다. 빈 구간이 남으면 학습 데이터에 구멍이 생기고 그 구간의 이상은 아무도 모르게 지나갑니다.

언제 쓰나. 공장과 클라우드 사이 연결이 불안정하거나 중앙 시스템 점검이 잦을 때 필수입니다. 설비 옆 단말에서 모든 판단을 끝내는 구조라면 필요성이 줄어듭니다.

작은 예시(가상). 야간 방화벽 점검으로 프레스 라인의 상위 연결이 40분 끊겼습니다. 버퍼가 있으면 점검 뒤 40분치 진동 데이터가 원래 시각으로 채워지고 없으면 그 구간은 영영 비어 있습니다.

Time as the core: 시각을 데이터 모델의 중심에

무엇인가. 모든 레코드의 기준을 시각으로 삼고 정밀도를 나노초까지 두는 원칙입니다. 패널의 둘째 조건입니다.

어떻게 작동하나. PLC, 비전 검사, MES(제조 실행 시스템)처럼 원천이 여럿이면 값을 잇는 기준은 시각뿐입니다. 시계가 서로 어긋나면 다른 순간의 값이 한 행으로 묶이고 그 오류가 그대로 학습 데이터에 들어갑니다. 시각을 모델의 중심에 두면 원천을 합치는 기준이 하나로 정해집니다. 정밀도가 높을수록 빠른 공정에서도 사건의 순서를 잃지 않습니다.

언제 쓰나. 고속 공정이나 여러 원천을 합쳐 학습할 때 필요합니다. 시간 단위 집계 보고만 한다면 이득이 작습니다.

작은 예시(가상). 체결 토크 이상과 비전 불량 판정을 잇는데 두 시스템의 시계가 0.8초 어긋나 있습니다. 앞 부품의 토크 값이 뒤 부품의 불량 판정과 묶여, 모델은 엉뚱한 상관을 배웁니다.

Semantic layer: 데이터는 공장에, 뜻은 하나로

무엇인가. 공장마다 다른 태그 이름과 구조를 공통 의미로 바꾸는 층입니다. 패널의 다섯째 조건이고 Volkswagen 플랫폼의 축입니다.

어떻게 작동하나. 입력은 공장별 원시 태그입니다. 처리 단계에서 공통 이름과 단위, 설비 계층으로 매핑하고 맥락을 잇습니다. 출력은 어느 공장에서 읽어도 같은 뜻을 내는 데이터입니다. 데이터를 한곳으로 옮기지 않아도 질의와 모델이 같은 이름으로 모든 공장을 봅니다. Volkswagen은 이 방식으로 IT, OT(설비 운영 기술), 엔지니어링 데이터를 묶었습니다. 주문 접수부터 생산까지가 하나의 digital thread(제품 하나의 이력을 처음부터 끝까지 잇는 데이터 줄기)로 이어집니다.

언제 쓰나. 같은 공정이 여러 공장에 반복될 때 효과가 큽니다. 공장마다 제품과 공정이 전혀 다르면 공통 의미로 묶을 수 있는 범위가 좁아집니다.

Context over volume: 양보다 맥락, 평균보다 원래 해상도

무엇인가. AI가 막히는 이유는 데이터가 적어서가 아니라 맥락이 없어서라는 관점입니다. 여기에 기계가 쓸 데이터는 사람이 보는 대시보드보다 촘촘해야 한다는 원칙이 붙습니다.

어떻게 작동하나. 측정값에 설비 식별자, 생산 중인 제품, 정비 이력, 품질 결과가 붙어야 모델이 의미 있는 패턴을 배웁니다. 해상도도 다릅니다. 대시보드는 대략 1~5초마다 값을 찍으면 충분하지만, 이상 탐지 모델에는 킬로헤르츠 수준 신호가 필요할 수 있습니다. 평균을 내 저장하면 짧은 충격이나 진동 패턴이 사라집니다.

언제 쓰나. 베어링, 스핀들, 모터처럼 빠른 신호에서 이상을 찾을 때 적용합니다. 생산량 집계 같은 느린 지표는 낮은 해상도로 충분합니다.

Open standards and dual workloads: 갇히지 않고 학습과 추론을 함께

무엇인가. 패널의 셋째, 넷째 조건입니다. 데이터를 특정 벤더 형식에 가두지 않고 같은 바탕이 과거 이력으로 모델을 학습하는 일과 현장에서 실시간으로 판정하는 일을 함께 받쳐야 합니다.

어떻게 작동하나. 학습은 긴 기간의 대량 이력을 읽고 추론은 방금 들어온 값을 짧은 지연으로 읽습니다. 두 경로가 같은 이름과 시각 기준을 쓰지 않으면, 학습 때 본 데이터와 현장에서 받는 데이터가 달라집니다. 개방형 표준을 쓰면 공장을 늘리거나 도구를 바꿀 때 데이터를 옮겨 다시 짜는 비용이 줄어듭니다. historian의 태그당 과금처럼 센서 추가를 망설이게 하는 구조도 이 판단에 걸립니다.

언제 쓰나. 공장이 여러 곳이고 공장마다 도구가 다를 때 먼저 따집니다.

Data as a product: 담당자와 예산이 있는 데이터

무엇인가. 데이터를 일회성 프로젝트의 부산물로 두지 않고 전담 담당자와 지속 예산, 계속되는 유지보수가 있는 제품으로 다루는 운영 방식입니다.

어떻게 작동하나. 프로젝트 방식에서는 사용 사례마다 데이터를 새로 정리하고 프로젝트가 끝나면 아무도 손대지 않습니다. 제품 방식에서는 여러 공장의 여러 사용 사례가 하나의 엔터프라이즈 데이터 플랫폼을 씁니다. 투자 근거는 사업 문제로 세웁니다. 패널이 든 예는 정지 시간, first-pass yield(첫 합격률), 정비·보증 비용, 노동 생산성입니다.

언제 쓰나. 사용 사례가 둘을 넘고 공장이 둘 이상일 때 전환할 시점입니다.

통념과 다른 주장

저자가 든 사례

Volkswagen Group Digital Production Platform: 43개 공장이 한 공장의 개선을 함께 쓰는 구조

구분	내용
상황	전 세계 43개 공장에서 같은 데이터의 뜻을 일관되게 유지해야 함
한 일	엣지에서 데이터를 미리 고르지 않고 모두 수집. 수집 시점에 제품, 정비 상태, 운전 조건을 메타데이터로 부착. 데이터는 공장마다 보관하고 시맨틱 레이어로 뜻을 맞춤. IT, OT, 엔지니어링 데이터를 주문 접수부터 생산까지 하나의 digital thread로 연결
결과	43개 공장 중 한 곳에서 만든 품질 개선이 나머지 42곳에 쓰임. 공장 70곳 추가 확대 중. 데이터 양과 일정은 원문에서 밝히지 않음
연결	Semantic layer, Context over volume, Data as a product

기술 디테일: 공장 두 곳에서 같은 모델을 돌리려면

태그 이름 드리프트(Scale failure points)를 잡으려면 공장별 태그를 공통 이름으로 잇는 매핑표를 먼저 만듭니다. 시맨틱 레이어의 가장 아래 단위가 이 표입니다. 필드는 공장, 원래 태그, 공통 이름, 단위, 신호 종류(실효값, 피크, 평균), 샘플링 주기, 설비 식별자, 유효 시작일, 담당자입니다. 태그 수가 수천 개면 LLM으로 매핑 후보를 뽑을 수 있습니다. 태그 이름, PLC 주석, 설비 문서를 넣고 구조화 출력(JSON)으로 공통 이름 후보와 신뢰도를 받습니다. temperature는 0으로 두고 같은 태그를 3회 돌려 답이 갈리면 사람 검토 대기열로 보냅니다. 신뢰도가 높아도 신호 종류와 단위는 OT 엔지니어가 승인합니다. 아래는 가상 예시입니다.

{
  "site": "plant_b",
  "source_tag": "SPDL_VIB_01",
  "canonical_name": "spindle.vibration.peak",
  "unit": "mm/s",
  "signal_kind": "peak",
  "sample_rate_hz": 10000,
  "asset_id": "B-CNC-14",
  "valid_from": "2026-11-02",
  "mapping_source": "llm_suggested",
  "llm_confidence": 0.82,
  "approved_by": "ot_engineer_b",
  "owner": "data_product_machining"
}

시각을 맞추려면(Time as the core) 레코드마다 원천 시각(source_ts)과 수신 시각(ingest_ts)을 함께 저장합니다. 공장 안 시계는 하나의 기준 시계로 동기화하고 원천별로 두 시각의 차이 분포를 매일 봅니다. 차이가 평소보다 커진 원천은 경고를 띄우고 그 구간 데이터에는 학습 제외 표시를 붙입니다. 경고 기준은 공정 속도에 맞춰 정하고 처음에는 사이클 타임의 1% 정도에서 시작해 조정합니다(실행 제안). 원천끼리 합칠 때는 늘 source_ts를 씁니다.

Store-and-forward를 설정하려면 버퍼 크기를 “견뎌야 할 최대 단절 시간 × 초당 데이터량”으로 잡습니다. 지난 1년의 네트워크 장애와 점검 기록에서 가장 길었던 단절의 두 배를 목표로 둡니다(실행 제안). 가상 예시로 태그 2,000개를 평균 10 Hz로 받고 레코드당 50바이트라면 초당 약 1 MB이고, 8시간 단절을 견디려면 약 29 GB가 필요합니다. backfill 때는 설비 식별자, 공통 이름, source_ts를 묶어 중복 제거 키로 써야 같은 값이 두 번 들어가지 않습니다. backfill이 끝난 구간은 완료 표시를 남겨 학습 파이프라인이 미완성 구간을 읽지 않게 합니다.

해상도를 나누려면(Context over volume) 저장을 두 층으로 둡니다. 엣지에는 원래 해상도 신호를 일정 기간(예: 14일) 두고 중앙에는 집계값과 이벤트 구간의 원본만 보냅니다. 이상 탐지 모델이 경고를 띄우면 그 앞뒤 구간 원본은 기간과 상관없이 보존합니다. 수집 순간에는 설비 식별자, 생산 중인 제품 번호, 마지막 정비 일자, 운전 모드를 메타데이터로 붙입니다. Volkswagen이 수집 시점에 맥락을 붙인 것과 같은 원리입니다.

학습과 추론을 한 바탕에서 돌리려면(Open standards and dual workloads) 두 경로가 같은 공통 이름과 source_ts를 읽게 합니다. 학습용 이력은 개방형 열 기반 파일 형식으로 내보내고 추론은 같은 시맨틱 레이어에서 실시간으로 구독합니다. 모델을 B 공장에 옮길 때는 B 공장 원시 태그가 아니라 공통 이름으로만 입력을 받게 짜 두면 코드 수정 없이 이식됩니다. LLM 에이전트가 설비 데이터를 조회하게 할 때도 도구 설명에는 공통 이름과 단위만 넣습니다.

라이선스 비용을 미리 재려면 AI용으로 더할 태그 수에 태그당 단가와 공장 수를 곱해 3년치를 계산하고 개방형 저장소를 쓸 때의 비용과 나란히 놓습니다. 이 표가 있어야 센서를 더할지 말지를 기술팀이 아니라 사업 판단으로 결정할 수 있습니다.

현업 실행 디테일: 누가, 언제, 무엇을

역할	담당	하는 일
스폰서	제조 본부장	시범 공장 두 곳과 사업 지표 하나 선정, 12주차 확대 결정
데이터 제품 오너	AX·DX 조직	매핑표와 시맨틱 모델의 주인. 예산과 유지보수 계획 관리
OT 엔지니어	공장별 1명	태그 사전 정리, 신호 종류·단위 승인, 엣지 버퍼 설치
데이터 엔지니어	IT 또는 벤더	시각 기준, backfill, 저장 두 층, LLM 매핑 후보 생성
공정·품질 담당	공장별 1~2명	맥락 메타데이터 정의, 모델 결과 현장 검증
재무	FP&A	정지 시간·첫 합격률 기준선과 라이선스 비용 계산

시작 전 준비물. 같은 설비가 있는 공장 두 곳, 그 설비의 태그 목록과 PLC 주석, 공장별 시계 동기화 방식, 지난 1년 네트워크 단절 기록, 현재 historian 라이선스 조건, 사업 지표 하나의 기준선(예: 해당 설비의 월 정지 시간)입니다.

기간	할 일	산출물
1~3주	두 공장 태그 사전 대조, 시각 차이 측정, 맥락 정보 위치 확인	불일치 태그 목록, 원천별 시각 차이 리포트
4~6주	매핑표 작성(LLM 후보 + 엔지니어 승인), 엣지 버퍼 설치, 수집 시 메타데이터 부착	승인된 매핑표, backfill 시험 결과
7~9주	A 공장 데이터로 모델 하나 학습(예: 이상 탐지), 공통 이름으로만 입력	모델, 성능 기준선
10~12주	B 공장에 코드 수정 없이 이식, 성능 비교, 3년 비용표 작성	이식 결과, 확대 투자안

현업에 물을 것.

1. 같은 이름인데 공장마다 다른 값을 내는 태그를 알고 있나요?
2. 이 설비의 시계는 무엇에 맞춰져 있고 마지막으로 언제 확인했나요?
3. 경고가 떴을 때 정비 직후인지 아닌지를 지금은 어떻게 아나요?
4. 지난 1년 동안 공장과 중앙 사이 연결이 가장 길게 끊긴 때는 언제였나요?
5. 센서를 더 달지 못한 이유가 라이선스 비용이었던 적이 있나요?

진행 판정 기준(예시). 세 조건을 채우면 공장 수를 늘립니다. 첫째, 시범 설비 태그의 95% 이상이 승인된 공통 이름을 가집니다. 둘째, A 공장에서 학습한 모델을 B 공장에 코드 수정 없이 올렸을 때 성능 저하가 합의한 범위(예: 재현율 5%p) 안입니다. 셋째, 시범 기간 중 단절 구간이 backfill로 모두 채워졌습니다. 정지 시간 같은 사업 지표 변화는 함께 기록하되, 12주 안에 확정하지 않아도 됩니다.

AX 적용 제언. 공장이 여럿인 국내 제조사라면 “공장 AI 몇 개 도입”을 목표로 걸기보다 “공장 사이에 그대로 옮겨지는 모델 몇 개”를 목표로 거는 편이 낫습니다. 데이터 레이크 통합부터 시작하는 큰 사업은 길어지기 쉽습니다. 같은 설비가 있는 공장 두 곳에서 태그 사전과 시각 기준을 맞추는 일은 12주 안에 결과가 나옵니다. 매핑표의 주인은 AX 조직에, 신호 승인은 OT에, 투자 판단의 언어는 재무에 맡기면 데이터 제품의 담당자와 예산이 처음부터 정해집니다. Volkswagen 사례처럼 한 공장의 개선이 다른 공장으로 번지는 것을 보여 주면, 다음 공장을 붙일 예산을 설득하기도 쉬워집니다.

원문 사례

항목	내용
출처	IIoT World, 2026.10.29, Paul Viorel. InfluxData 후원(편집 독립 표기)
바탕	Industrial AI Summit 2026 패널 토론. 발언을 개인별로 나누지 않고 패널 의견으로 정리
패널	Gaspard Duthilleul(Galyos), Sanjay Mahato(AWS), Ian Clark(InfluxData), Tauseef Ahmed(Grayhawk Consulting Group)
확장 시 문제	태그 이름 드리프트, clock skew, 맥락 누락, historian 태그당 과금, 공장별 수작업과 맞춤 커넥터
다섯 가지 조건	store-and-forward 내구성, 나노초 시각 정밀도, 개방형 표준, 학습·추론 동시 지원, 시맨틱 레이어
해상도	대시보드 대략 1~5초 간격, 이상 탐지 모델은 킬로헤르츠 수준 신호가 필요할 수 있음
투자 근거	정지 시간, 첫 합격률, 정비·보증 비용, 노동 생산성
운영 방식	재사용하는 엔터프라이즈 데이터 플랫폼, data as a product(전담 담당자, 지속 예산, 유지보수)
사례	Volkswagen Group Digital Production Platform: 43개 공장, 한 공장의 품질 개선을 나머지 42곳이 씀, 공장 70곳 추가 확대 중
현장 투표	참석자 33%가 데이터 인프라 확장을 진행 중, 41%는 지금 우선순위가 아니라고 답함
인용 수치	패널이 인용한 MIT 조사: 해마다 AI에 투자되는 350억~400억 달러 중 약 95%가 확장 단계로 가지 못함

핵심 개념

historian

설비 신호를 시간 순서로 오래 저장하는 산업용 시계열 데이터베이스입니다. 태그 단위로 라이선스를 매기는 제품이 많습니다.

tag naming drift

같은 태그 이름이 공장이나 시점에 따라 다른 신호를 가리키게 되는 현상입니다.

clock skew

여러 원천의 시계가 서로 어긋나, 같은 순간의 값이 다른 시각으로 기록되는 현상입니다.

backfill

끊긴 동안 쌓아 둔 데이터를 연결이 돌아온 뒤 원래 시각으로 빈 구간에 채우는 일입니다.

digital thread

주문부터 설계, 생산까지 제품 하나의 데이터를 끊김 없이 잇는 흐름입니다.

first-pass yield

재작업 없이 첫 공정에서 바로 합격한 제품의 비율입니다.

inference

학습이 끝난 모델이 새로 들어온 데이터로 판정이나 예측을 내는 일입니다.

내 메모

TODO: 내 생각 추가

원문은 IIoT World의 「Why AI Data Architecture Breaks at Scale」(Paul Viorel, 2026.10.29)이며 Industrial AI Summit 2026 패널 토론을 정리한 InfluxData 후원 콘텐츠입니다(편집 독립 표기). 원문은 내용 요약에 AI 도구를 썼다고 밝히고 있습니다. 요약, 핵심 메커니즘의 원문 내용, 통념과 다른 주장, Volkswagen 사례, 원문 사례 표는 기사 내용을 AX Review가 다시 정리했습니다. 수치와 효과는 패널과 기사의 설명입니다. 메커니즘의 작은 예시, 기술·현업 실행 디테일, JSON 예시, 문제·대응 표, 일정·판정 기준, 인포그래픽은 원문에 없는 내용으로 새로 작성했으며, 그 안의 필드명과 숫자는 가상 예시입니다. 원문 전체는 IIoT World에서 볼 수 있습니다.