Overall Factory Brain: Aumovio 브레이크 공장이 에이전트 3개로 품질 원인 분석을 며칠에서 몇 분으로

공장 AI 에이전트의 쓸모는 모델보다 그 밑에 깔린 공용 기억에서 나옵니다. Aumovio의 프랑크푸르트 브레이크 공장은 생산·품질 데이터와 숙련자의 경험을 한 기반에 모았습니다. 그 위에 원인 분석, 경험 검색, 지표 감시를 맡는 에이전트 3개를 올려 며칠 걸리던 원인 분석을 몇 분으로 줄였습니다. 따라 하려면 과거 품질 사고 기록부터 구조화하고 에이전트마다 볼 수 있는 데이터와 할 수 있는 행동을 먼저 정해야 합니다.

요약

CIO 독일판(CIO DE)의 Bernd Reder 기자는 Aumovio의 프랑크푸르트 뢰델하임(Rödelheim) 공장을 다뤘습니다. Aumovio는 2025년 Continental의 자동차 부문이 분사해 생긴 부품사입니다. 직원은 약 8만 2,000명, 2025년 매출은 186억 유로입니다. 뢰델하임 공장은 자동화 비율이 높은 브레이크 시스템 라인을 운영합니다. 이 공장은 German Edge Cloud(GEC, 독일의 산업용 엣지·클라우드 회사)와 함께 Overall Factory Brain(공장 전체가 함께 쓰는 두뇌)을 만들고 있습니다. 바탕은 GEC의 Oncite Digital Production System(DPS, 설비·공정·품질 데이터를 한데 모으는 플랫폼)입니다. MES(생산 실행 시스템), ERP, 현장 시스템은 바꾸지 않고 연결만 합니다. 에이전트는 Oncite Industrial AI Platform에서 돌아갑니다. Pareto는 공정 단계 사이의 패턴을 찾아 원인 후보를 냅니다. Daedalus는 과거 장애와 분석에서 쌓인 숙련자 지식을 새 질문에 맞춰 꺼내 줍니다. Sentinel은 품질, 에너지, 생산 지표를 지켜봅니다.

예전에는 품질 오류가 나면 팀이 생산·품질 데이터를 모으고 공정 단계 사이의 상관을 따져 본 뒤 전문가를 불러 원인을 좁혔습니다. 며칠이 걸리기도 했습니다. 공장장 Torsten Rauch는 이 분석이 이제 몇 분이면 끝난다고 말합니다. 원문이 밝힌 성과 수치는 이것 하나입니다. 원문 설명을 따르면 속도는 두 가지에서 나옵니다. 세 에이전트가 같은 데이터·지식 기반을 쓰므로 분석할 때마다 데이터를 다시 모을 필요가 없습니다. 그리고 데이터베이스에 없던 숙련자의 경험을 기반 안에 넣었습니다. 산업공학 책임자 Peter Bonerz는 경험의 상당 부분이 시스템이나 직원 머릿속에 흩어져 있다고 봅니다. 그래서 이를 보존해 사람과 에이전트가 함께 쓰게 하는 것이 목표라고 설명합니다. 에이전트가 무엇을 보고 무엇을 할 수 있는지는 역할·권한·거버넌스 규칙이 정하고 결론은 사람이 냅니다. 아래에서는 이 구조를 다섯 가지 작동 원리로 풀고 우리 공장에서 시험할 때 필요한 이음 키, 출력 형식, 권한표, 8주 일정을 덧붙입니다.

핵심 메커니즘

Overall Factory Brain: 데이터와 사람의 경험을 담는 공용 생산 기억

무엇인가. 현장 데이터와 사람이 가진 경험을 한 기반에 모아 사람과 AI 에이전트가 같은 근거로 일하게 하는 공장 단위 지식 기반입니다. 원문은 이를 production memory(생산 기억)라고 부릅니다.

어떻게 작동하나. 입력은 두 갈래입니다. 하나는 Oncite DPS가 모은 설비·공정·품질 데이터입니다. 다른 하나는 과거 장애와 분석에서 얻은 사람의 지식입니다. 기반은 이 둘을 지금 현장에서 들어오는 정보와 이어 둡니다. 에이전트는 각자 필요한 부분을 이 기반에서 꺼내 씁니다. 출력은 에이전트마다 다르지만 근거가 한곳에서 나오므로 결과끼리 맞춰 볼 수 있습니다. 기존 MES·ERP를 걷어 내지 않고 연결만 하므로 생산 구조를 바꾸는 공사가 없습니다.

언제 쓰고 언제 안 쓰나. 같은 데이터를 두고 품질, 생산, 엔지니어링이 서로 다른 질문을 던질 때 맞습니다. 질문이 하나이고 데이터도 한 시스템 안에 있다면 단일 분석 도구로 충분합니다.

원문의 예. Rauch는 이 기반이 데이터와 경험에서 배우는 공장의 전제 조건이 된다고 봅니다. Bonerz는 사람과 에이전트가 같은 지식 기반에서 일하는 것을 목표로 꼽습니다.

작은 예시(가상). 최종 시험에서 불량이 늘었다고 합시다. 같은 lot의 가공 데이터, 그 설비의 지난 정비 기록, 숙련자가 2년 전 남긴 “같은 증상, 원인은 지그 마모” 기록이 한 화면에서 이어져야 이 기반이 제 역할을 한 것입니다.

Pareto: 공정 단계를 가로질러 원인 후보를 좁히는 에이전트

무엇인가. 품질 이상의 원인을 찾는 에이전트입니다. 원인을 정하지 않고 후보를 냅니다.

어떻게 작동하나. 입력은 여러 공정 단계에 걸친 생산·품질 데이터입니다. Pareto는 공정 단계를 서로 이어 보고 패턴과 상관을 찾아 가능한 원인을 추립니다. 출력은 원인 후보와 그 근거이며 품질·생산 담당자가 이를 평가합니다. 원문은 결과가 사람의 추가 평가를 위해 제공된다고 분명히 적습니다.

언제 쓰고 언제 안 쓰나. 불량이 여러 공정을 거친 뒤에야 드러나 어느 단계가 원인인지 모를 때 효과가 큽니다. 설비 알람 하나로 원인이 바로 보이는 고장에는 필요 없습니다.

원문의 예. 뢰델하임 공장에서 며칠 걸리던 원인 분석이 몇 분으로 줄어든 장면의 주역이 Pareto입니다.

작은 예시(가상). 최종 시험 불량을 두고 Pareto가 세 후보를 냅니다. 가공 2단계에서 공구를 바꾼 직후 생산분, 세척 공정 온도의 하향 추세, 특정 소재 lot입니다. 담당자는 첫 후보를 현장에서 확인하고 나머지 둘은 기각 사유와 함께 닫습니다.

Daedalus: 숙련자의 지난 경험을 새 질문에 붙여 주는 에이전트

무엇인가. 공장에 이미 있는 노하우를 꺼내 쓸 수 있게 하는 에이전트입니다. 원문은 Daedalus를 사람의 지식을 Factory Brain에 들여오는 구성 요소로 설명합니다.

어떻게 작동하나. 입력은 직원의 전문성과 과거 장애·분석에서 얻은 통찰입니다. Daedalus는 이를 검색할 수 있게 정리하고 새 질문에 적용합니다. 출력은 상황에 맞춘 의사결정 지원이고 사용자는 생산과 엔지니어링 전문가입니다. 결정을 대신하지 않고 결정할 사람에게 맥락을 줍니다.

언제 쓰고 언제 안 쓰나. 숙련자가 은퇴하거나 자리를 옮길 때, 같은 증상이 몇 년 간격으로 되풀이될 때 값이 큽니다. 새로 깐 공정처럼 지난 사례가 없으면 돌려줄 것이 적습니다.

원문의 예. Pareto가 낸 결과는 사람이 평가하고 Daedalus는 그 전문가에게 이전 사례의 맥락을 줍니다. 두 에이전트가 같은 원인 분석 장면에서 짝을 이룹니다.

Sentinel과 공용 기반: 도구 묶음이 아니라 전문 에이전트 체계

무엇인가. Sentinel은 품질, 에너지, 생산 지표를 감시하는 에이전트입니다. 원문은 입력, 처리 방식, 출력을 더 밝히지 않았습니다. 이 절의 핵심은 Sentinel 하나보다 세 에이전트가 같은 데이터·지식 기반 위에 놓인 방식입니다.

어떻게 작동하나. 모든 에이전트가 같은 기반을 읽습니다. 감시, 원인 분석, 경험 검색이 각자 데이터를 따로 모으지 않습니다. 원문은 이를 따로 노는 AI 도구들의 조각보 대신 전문 에이전트의 체계로 바꾸는 일로 설명합니다. 새 업무가 생기면 새 도구를 들이는 대신 같은 기반 위에 전문 에이전트를 하나 더 얹습니다.

언제 쓰고 언제 안 쓰나. AI를 쓸 업무가 셋 이상이고 같은 데이터를 공유할 때 맞습니다. 업무 하나만 자동화할 계획이라면 공용 기반을 먼저 만드는 비용이 더 클 수 있습니다.

원문의 예. Aumovio는 에이전트 체계를 단계적으로 넓히고 전문 에이전트를 더 붙일 계획입니다.

역할·권한·거버넌스 규칙: 에이전트마다 볼 것과 할 것을 정한다

무엇인가. 에이전트가 어떤 정보에 접근하고 어떤 행동을 실행해도 되는지 정하는 규칙입니다. 원문은 규칙이 있다는 것과 그 두 가지 대상(접근할 정보, 실행할 행동)을 밝혔고 규칙의 세부는 밝히지 않았습니다.

어떻게 작동하나. 같은 기반을 쓰더라도 에이전트마다 읽는 범위가 다릅니다. 행동도 제안, 알림, 실행처럼 층이 나뉩니다. 공용 기반은 “모두가 모든 것을 본다”는 뜻이 아닙니다. 기반은 하나로 두되 보는 창은 역할별로 따로 냅니다.

언제 쓰나. 에이전트가 하나를 넘는 순간부터 필요합니다. 특히 에이전트가 현장 시스템에 쓰기나 지시를 할 수 있게 넓힐 때는 그 전에 정해 둬야 합니다.

통념과 다른 주장

저자가 든 사례

뢰델하임 공장의 품질 원인 분석: 며칠에서 몇 분으로

구분	내용
상황	품질 오류가 나면 생산·품질 데이터를 모으고 공정 단계 사이 상관을 확인하고 전문가를 불러 원인을 좁혔습니다. 며칠이 걸리기도 했고 경험은 데이터베이스 밖에 있었습니다.
한 일	GEC와 함께 Oncite DPS로 설비·공정·품질 데이터를 모았습니다. 그 위에 Pareto(원인 후보)와 Daedalus(과거 경험)를 올리고 역할·권한 규칙으로 접근 범위를 정했습니다.
결과	공장장 Rauch의 설명으로 며칠 걸리던 분석이 몇 분으로 줄었습니다. 비용, 불량률 같은 다른 수치는 원문에서 밝히지 않았습니다.
연결	Overall Factory Brain, Pareto, Daedalus, 역할·권한 규칙

확장 경로: 전문 에이전트를 하나씩 더하는 방식

구분	내용
상황	높은 비용과 중국 경쟁이 독일 자동차 업계와 Aumovio 같은 공급사를 누릅니다.
한 일	개별 AI 도구 대신 같은 기반 위에 에이전트 3종(Pareto, Daedalus, Sentinel)을 올렸습니다. 기존 생산 구조는 바꾸지 않았습니다.
결과	다음 단계는 에이전트 체계를 단계적으로 넓히고 전문 에이전트를 더하는 것입니다. 공장 지식은 오래 남고 검색되는 생산 기억으로 만듭니다. 일정은 원문에서 밝히지 않았습니다.
연결	Sentinel과 공용 기반, 통념과 다른 주장 1·2

기술 디테일: 공용 기반 위 에이전트 3종을 우리 공장에서 돌리려면

원문은 내부 구현을 밝히지 않았습니다. 아래는 같은 구조를 시험할 때 필요한 것을 새로 정리한 실행 제안이며 필드명과 숫자는 가상 예시입니다.

공용 기반(Factory Brain)을 잇으려면 먼저 이음 키 네 가지를 정합니다. 부품 단위 추적 번호(part_serial)와 소재 lot(material_lot), 공정 단계(step_id)와 설비(station_id), 시작·종료 시각(start_ts, end_ts), 그리고 사람의 경험을 담는 사건 카드 번호(incident_id)입니다. 브레이크 같은 안전 부품은 대개 lot 추적 체계가 이미 있으니 그 번호를 그대로 키로 씁니다. 데이터는 MES·ERP에서 읽기 전용으로 가져오고 키가 빈 레코드 비율을 매일 셉니다(목표 1% 미만).

Daedalus식 경험 검색을 붙이려면 사람의 지식을 사건 카드로 구조화합니다. 원천은 8D 보고서(문제 해결 8단계 보고서), 정비 이력, 교대 일지, 숙련자 인터뷰입니다. 카드 하나에 증상, 공정 단계, 확정 원인, 조치, 재발 여부, 작성자, 검증자, 날짜를 둡니다. 검색은 키워드와 임베딩을 함께 쓰는 하이브리드로 하고 제품군·공정 단계·불량 모드로 먼저 걸러 범위를 줄입니다. 답에는 근거가 된 incident_id를 반드시 달게 하고 맞는 카드가 없으면 “유사 사례 없음”이라고 답하게 합니다. 카드는 3년이 지나거나 공정이 바뀌면 재검토 대상으로 표시합니다.

{
  "incident_id": "INC-2024-0417",
  "product_family": "브레이크 부품 A",
  "step_id": "machining_02",
  "symptom": "최종 시험 누설 불량 증가",
  "confirmed_cause": "지그 마모로 클램핑 위치 편차",
  "action": "지그 교체, 점검 주기 단축",
  "recurred": false,
  "author": "생산기술 담당",
  "verified_by": "품질 담당",
  "date": "2024-04-17"
}

Pareto식 원인 후보를 만들려면 순위는 통계가 정하고 LLM은 설명만 쓰게 합니다. 첫째, 불량군과 양품군, 비교 기간을 정합니다. 둘째, 공정 단계마다 특징값을 만듭니다. 설비, 공구 교체 후 생산 개수, 주요 파라미터의 평균과 산포, 소재 lot이 들어갑니다. 셋째, 두 군의 차이 크기와 지지 건수(n)로 순위를 매기고 상위 5개만 남깁니다. 넷째, LLM이 후보마다 설명과 현장 확인 방법을 정해진 JSON으로 씁니다. 모델은 JSON 스키마를 강제하는 구조화 출력을 지원하면 충분합니다. 다만 공정 데이터가 회사 밖으로 나가지 않는 배포 방식을 고릅니다. temperature는 0~0.2로 낮추고 같은 입력을 3회 돌려 상위 3개 순서가 바뀌면 “불안정” 표시를 붙입니다. 다섯째, 담당자가 후보를 채택하거나 기각하고 기각 사유를 남깁니다.

{
  "alert_id": "SEN-2026-1030-07",
  "defect_mode": "누설 불량",
  "window": {"from": "2026-10-28T06:00Z", "to": "2026-10-30T06:00Z"},
  "candidates": [
    {
      "rank": 1,
      "step_id": "machining_02",
      "feature": "공구 교체 후 200개 이내 생산분",
      "effect": "불량률 차이 2.1%p",
      "support_n": 340,
      "similar_incidents": ["INC-2024-0417"],
      "check_on_site": "해당 공구 교체 기록과 첫 200개 치수 대조",
      "stability": "stable",
      "status": "pending_review"
    }
  ],
  "warnings": ["동시 변경: 같은 시간대 소재 lot 교체"]
}

자주 틀리는 곳은 세 군데입니다. 상관을 원인으로 읽는 일, 표본이 작은 후보(n 30 미만)를 상위에 올리는 일, 같은 시간대에 두 가지가 함께 바뀐 경우입니다. 마지막 경우는 warnings에 “동시 변경”으로 묶어 내고 사람이 가르게 합니다. Pareto가 similar_incidents에 사건 카드를 달아 주면 Daedalus가 붙이는 맥락과 자연스럽게 이어집니다.

Sentinel식 감시를 돌리려면 지표를 세 묶음으로 둡니다. 품질은 불량률과 1차 합격률, 에너지는 생산 1개당 전력, 생산은 OEE(설비 종합 효율)를 이루는 가용률·성능·품질입니다. 관리 한계를 벗어난 값과 같은 방향으로 7점 이상 이어지는 추세를 경보로 잡습니다. 경보가 나면 alert_id를 붙여 Pareto를 자동으로 부르는 연결이 이 체계의 이음매입니다. 경보가 하루 10건을 넘으면 담당자가 보지 않으니 상한을 두고 우선순위를 매깁니다.

권한표를 만들려면 에이전트마다 읽기 범위, 허용 행동, 사람 승인이 필요한 행동을 한 줄씩 적습니다. 시범 동안은 모든 에이전트를 읽기와 제안까지만 둡니다. 설비 파라미터 변경이나 작업 지시처럼 현장을 바꾸는 행동은 열지 않습니다. 모든 호출은 누가, 어느 에이전트로, 어떤 데이터를 읽고 무엇을 냈는지 감사 로그로 남깁니다. 남길 필드는 user_id, agent, data_scope, output_id, decision, decided_by입니다.

평가하려면 지난 1~2년의 품질 사건 20~30건을 골라 그때의 데이터로 다시 돌립니다. 사람이 확정한 원인이 상위 3개 후보 안에 드는 비율, 인용한 근거의 정확도, 경보부터 검토 완료까지의 시간을 잽니다.

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

역할	담당	하는 일
스폰서	공장장	시범 라인·불량 모드 선정, 8주차 확대 결정
AX 추진	AX·DX 조직 PM	범위·일정, 권한표와 판정 기준 확정
품질 담당	품질 엔지니어 2명	사건 카드 검증, Pareto 후보 채택·기각
생산기술	공정 엔지니어 1~2명	공정 단계·특징값 정의, 숙련자 인터뷰 진행
숙련자	현장 경력 15년 이상 2~3명	지난 사건의 원인·조치 구술, 카드 검토
데이터 엔지니어	IT 또는 벤더	MES·ERP 읽기 연결, 이음 키, 감사 로그

시작 전 준비물. 시범 라인 하나와 자주 나는 불량 모드 하나, 지난 1~2년의 품질 사건 기록(8D 보고서, 클레임, 정비 이력), 해당 라인의 MES 공정 데이터와 lot 추적 데이터 접근 권한, 그리고 지금 원인 분석 한 건에 걸리는 시간의 기준선입니다. 원문에서도 출발점은 원인 분석이 며칠 걸리던 업무였으므로 기준선이 있어야 효과를 말할 수 있습니다.

기간	할 일	산출물
1~2주	지난 사건 정리, 숙련자 인터뷰, 이음 키 점검	사건 카드 30건 이상, 키 누락 목록
3~4주	MES·lot 데이터 연결, 공정 단계별 특징값 생성	특징값 표, 데이터 품질 리포트
5~6주	원인 후보 파이프라인과 경험 검색 연결, 권한표 적용	후보 JSON, 권한표, 감사 로그
7~8주	과거 사건 재생 평가, 실제 경보 2~3건 병행 운영	평가표, 확대 여부 판정

현업에 물을 것.

1. 지난 1년 동안 원인을 찾는 데 가장 오래 걸린 품질 사건은 무엇이었고 며칠이 걸렸나요?
2. 그때 결정적인 단서를 준 사람은 누구였고 그 사람의 판단은 어디에 기록됐나요?
3. 부품 하나가 어느 설비, 어느 lot을 거쳤는지 지금 몇 분 안에 추적할 수 있나요?
4. 에이전트가 절대 하면 안 되는 행동은 무엇인가요?

진행 판정 기준(예시). 세 조건을 채우면 둘째 불량 모드나 둘째 라인으로 넓힙니다. 첫째, 과거 사건 재생에서 확정 원인이 상위 3개 후보 안에 든 비율이 60% 이상입니다. 둘째, 후보가 인용한 데이터와 사건 카드가 실제 근거와 맞는 비율이 95% 이상입니다. 셋째, 실제 경보에서 원인 후보 검토까지 걸린 시간이 기준선보다 확실히 짧습니다. 숙련자가 카드 내용을 맞다고 확인한 비율도 함께 기록합니다.

AX 적용 제언. 국내 부품사라면 “AI 품질 분석 도구 도입”을 과제로 걸기보다 “품질 사건 기억 만들기”를 첫 과제로 거는 편이 낫습니다. 뢰델하임 사례에서 몇 분이라는 결과는 에이전트보다 같은 기반에 데이터와 경험이 함께 들어간 데서 나왔습니다. 첫 대상은 반복해서 나는 불량 모드 하나로 좁힙니다. 사건 카드의 검증 권한은 품질에, 특징값 정의는 생산기술에, 연결과 권한표는 IT에 나눠 줍니다. 이 순서를 지키면 감시, 정비, 에너지 같은 다음 에이전트가 같은 기반 위에 붙습니다. 효과를 보고할 때는 인력 절감보다 원인 확정까지 걸린 시간과 재발률을 앞에 둡니다.

원문 사례

항목	내용
출처	CIO DE, Bernd Reder, 2026.10.28
회사	Aumovio, 프랑크푸르트 본사, 2025년 Continental 자동차 부문에서 분사, 직원 약 8만 2,000명, 2025년 매출 186억 유로
공장	프랑크푸르트 뢰델하임, 자동화 비율이 높은 브레이크 시스템 라인
파트너	German Edge Cloud(GEC)
데이터 기반	Oncite Digital Production System(DPS), 기존 MES·ERP·현장 시스템 연결
에이전트 실행	Oncite Industrial AI Platform
에이전트	Pareto(원인 후보), Daedalus(경험 검색·의사결정 지원), Sentinel(품질·에너지·생산 지표 감시)
통제	역할·권한·거버넌스 규칙이 접근 정보와 실행 행동을 정함
수치	원인 분석이 며칠에서 몇 분으로 (공장장 설명), 다른 수치 없음
등장인물	Torsten Rauch(공장장), Peter Bonerz(산업공학 책임), Dieter Meuser(GEC 대표)
다음 단계	에이전트 체계의 단계적 확장, 전문 에이전트 추가, 검색되는 생산 기억

핵심 개념

MES

Manufacturing Execution System. 작업 지시, 공정 실적, 추적 데이터를 관리하는 생산 현장의 실행 시스템입니다.

German Edge Cloud (GEC)

공장 데이터 플랫폼과 산업용 AI 플랫폼을 공급하는 독일 회사입니다. 이 사례의 구축 파트너입니다.

Oncite Industrial AI Platform

GEC의 에이전트 실행 환경입니다. 뢰델하임 공장의 세 에이전트가 여기서 돌아갑니다.

근본 원인 분석

불량의 직접 증상이 아니라 그 증상을 만든 공정 조건을 찾는 일입니다. 영어로는 root cause analysis라고 합니다.

8D 보고서

문제 정의부터 재발 방지까지 여덟 단계로 품질 문제를 정리하는 자동차 업계의 보고 형식입니다. 사건 카드의 좋은 원천입니다.

OEE

Overall Equipment Effectiveness. 가용률, 성능, 품질을 곱해 설비가 제대로 일한 정도를 보는 지표입니다.

내 메모

TODO: 내 생각 추가

원문은 CIO DE의 「Aumovio fertigt mit Industrial AI produktiver」(Bernd Reder, 2026.10.28)입니다. 요약, 핵심 메커니즘의 원문 예, 통념과 다른 주장, 사례, 원문 사례 표는 원문이 언급한 내용을 AX Review가 다시 정리했습니다. 성과 수치는 공장장의 설명입니다. 기술·현업 실행 디테일, JSON 예시, 권한표, 지표와 판정 기준, 일정, 인포그래픽은 원문에 없는 내용으로 새로 작성했으며 그 안의 필드명과 숫자는 가상 예시입니다. 원문 전체는 CIO DE에서 볼 수 있습니다.