PLM.AI: Mercedes-Benz가 개발·구매·생산 데이터를 한 줄기로 이어 개발 기간을 최대 30% 줄이려는 계획

Mercedes-Benz는 공정마다 따로 쓰던 AI 에이전트를 표준 데이터 모델 위에서 이어, 설계 변경의 영향을 원가·충돌 성능·소프트웨어·생산까지 한꺼번에 보고 일찍 결정하는 방식으로 개발 기간을 최대 30% 줄이려 합니다. 따라 하려면 에이전트를 더 사기 전에 부품·요구사항·시험·공정 데이터를 같은 키로 묶는 데이터 모델부터 정해야 합니다.

요약

Motor1의 Adrian Padeanu가 2026년 11월 4일, Mercedes-Benz의 새 CTO Jörg Burzer가 호주 매체 Drive와 한 인터뷰를 정리했습니다. Burzer는 중국 자동차 업체의 개발 속도와 고객 중심 태도를 높이 평가하면서도 모든 영역에서 뒤처졌다고 보지는 않는다고 말했습니다. 경쟁을 두고는 “Competition is good. It’s good for the customer.”라고 했습니다. 기사는 그 배경으로 판매 수치를 듭니다. 중국 판매는 2025년 19% 줄어 551,932대였고 2026년 1~9월에는 전년 같은 기간보다 29% 줄었습니다. 이 속도 차이를 메우려고 Mercedes-Benz가 내세운 수단이 PLM.AI(AI 기반 제품 수명주기 관리)입니다. 차량 개발, 구매, 생산, 판매, 애프터세일즈를 하나로 잇는 digital backbone(디지털 중추)입니다. 이 노트는 회사가 2026년 10월 16일 낸 공식 보도자료로 작동 방식을 보강했습니다.

보도자료가 밝힌 연결 범위를 허브 구조로 새로 그림

회사가 밝힌 목표는 전체 개발 기간 최대 30% 단축, 개별 엔지니어링 공정의 효율 최대 50% 개선입니다. AI 시뮬레이션이 늘면 물리 시험도 장기적으로 최대 절반까지 줄일 수 있다고 봅니다. 투자 규모는 약 5억 유로입니다. 독일 매체 일부는 30%를 약 17개월로 환산해 전했지만 공식 보도자료에는 이 숫자가 없습니다. 회사는 속도가 품질 타협에서 나오지 않는다고 설명합니다. 팀이 필요한 정보를 제때 받아 더 일찍 더 나은 결정을 내리게 하는 데서 나온다는 것입니다. 재료비 최적화, 인증, 결함 탐지, 소프트웨어 개발에는 AI 에이전트가 이미 쓰이고 있습니다. 다만 지금은 각 공정 안에서만 돌고, PLM.AI는 이들을 표준 데이터 모델로 연결합니다. 최종 결정권은 엔지니어에게 남습니다. 아래에서 다섯 가지 작동 원리와 두 사례를 본 뒤 직접 돌릴 때 필요한 기술·현업 디테일을 붙입니다.

Mercedes-Benz 발표 목표치. 모두 상한값이며 막대는 0 기준 비례

핵심 메커니즘

Digital Thread: 부서마다 흩어진 제품 데이터를 표준 데이터 모델로 잇는다

Digital thread(제품 데이터가 설계부터 애프터세일즈까지 끊기지 않고 이어진 상태)는 PLM.AI의 바탕입니다. 보도자료는 표준화된 데이터 모델과 개발 데이터의 처음부터 끝까지의 통합을 아키텍처의 두 기둥으로 듭니다. 입력은 각 부서 시스템에 있던 설계, 구매, 생산, 판매, 서비스 데이터이고, 이것을 같은 규칙으로 정의한 데이터 모델에 맞춰 연결합니다. 출력은 어느 부서에서 봐도 같은 실시간 정보입니다. 부품 하나의 변경이 여러 부서로 번지는 제품, 즉 부품 수가 많고 부서가 많은 개발에서 효과가 큽니다. 부서 하나 안에서 끝나는 업무라면 이렇게 넓은 통합은 과합니다. 가상 예시로, 시트 프레임 도면이 개정되면 그 부품 번호에 묶인 공급사 견적, 충돌 시험 결과, 조립 공정표가 함께 “검토 필요”로 바뀌는 식입니다.

보도자료의 digital thread 설명을 비교 구도로 새로 그림. 왼쪽은 흔한 모습을 든 가상 예시

공정 안의 에이전트를 공정 사이로 잇는다

Mercedes-Benz는 이미 네 갈래 업무에 AI 에이전트를 쓰고 있습니다. 재료비 최적화, 인증과 형식승인(homologation, 판매 국가 규제를 충족했음을 인정받는 절차), 결함 탐지와 해결, 소프트웨어 개발 지원입니다. 보도자료는 이 에이전트들이 지금은 주로 개별 공정 안에서 쓰인다고 설명합니다. PLM.AI는 이 응용들을 표준 데이터 모델로 이어 개발 공정 전체를 가로지르게 합니다. 재료비 에이전트가 고른 대체 소재가 인증 에이전트의 규제 확인으로 바로 넘어가는 구조가 가능해집니다. 에이전트가 같은 부품 번호와 같은 개정 번호를 보고 있어야 결과를 서로 넘겨받을 수 있다는 점이 전제입니다. 연결이 안 된 상태에서 에이전트 수만 늘리면 부서마다 다른 답이 나와 회의가 다시 늘어납니다.

보도자료가 든 기존 에이전트 네 종류와 PLM.AI의 역할

Cross-Functional Trade-off: 변경 하나의 영향을 동시에 계산한다

보도자료가 든 예는 경량화입니다. 부품 하나를 바꾸면 원가, 충돌 거동, 하드웨어·소프트웨어 기능, 생산 공정이 함께 움직입니다. PLM.AI에서는 전문 에이전트들이 이 의존 관계를 동시에 분석해 팀이 전체 그림을 더 빨리 보고 안전, 품질, 사업성을 저울질하게 합니다. 입력은 설계 변경 하나, 처리는 기능별 에이전트의 병렬 분석, 출력은 trade-off(하나를 얻으려 다른 것을 포기하는 선택)를 한눈에 보여 주는 판단 자료입니다. 개발 후반에 드러나던 충돌을 초기에 찾는 데 쓰고, 결정 자체는 팀이 내립니다. 가상 예시로, 브래킷을 알루미늄으로 바꾸면 무게는 줄지만 단가가 오르고 용접 공정이 체결 공정으로 바뀐다는 결과가 한 화면에 나란히 나옵니다.

보도자료의 경량화 예시를 새로 그림. 브래킷은 가상 예시

Digital Twin 시뮬레이션: 물리 시험을 표적화한다

Siemens는 AI 기반 자동차 설계, 시뮬레이션, 디지털 검증 기술을 digital twin(실물 차량과 같은 조건으로 계산하는 가상 모델)에 공급합니다. 시뮬레이션으로 먼저 걸러 확인이 꼭 필요한 항목만 물리 시험으로 보내므로 시험이 더 표적화되고 검증 결정이 앞당겨집니다. 회사는 이렇게 해서 물리 시험이 시간이 지나며 최대 절반까지 줄 수 있다고 봅니다. 시뮬레이션 모델이 실물 시험과 충분히 맞는다는 근거가 쌓인 영역부터 적용해야 하고, 신소재나 처음 쓰는 구조처럼 비교 데이터가 없는 곳에서는 물리 시험이 계속 기준입니다.

보도자료 설명을 네 칸으로 새로 그림

플랫폼은 빌리고 데이터 모델과 AI 모델은 소유한다

역할 분담도 설계의 일부입니다. CONTACT Software는 CONTACT Elements로 개방형 PLM 코어를 제공해 제품 데이터, 프로세스, 애플리케이션을 모듈 방식으로 통합하고 향후 AI 기술을 붙일 기반을 만듭니다. Siemens는 시뮬레이션과 디지털 트윈을 맡습니다. Mercedes-Benz는 목표 아키텍처, 데이터 모델, 거버넌스를 직접 정하고 글로벌 도입을 애자일 방식의 전환 프로그램으로 이끕니다. 데이터와 그 위에서 개발한 AI 모델의 소유권과 통제권도 회사에 남습니다. 벤더가 바뀌어도 데이터 모델과 학습 결과가 회사에 남게 하는 구조입니다.

보도자료가 밝힌 역할을 표로 정리

통념과 다른 주장

흔히 이렇게 봅니다개발을 빨리 하면 시험이나 검토 어딘가를 줄이게 되고 품질과 안전이 흔들린다.

저자는 이렇게 봅니다Mercedes-Benz는 단축이 타협에서 나오지 않는다고 설명합니다. 팀이 맞는 정보를 제때 받아 더 일찍 결정하면 기간이 줄고, 품질과 안전 기준은 그대로라는 것입니다.

근거경량화 예처럼 변경의 영향을 동시에 계산하면 후반에 드러나던 충돌을 초기에 잡습니다. 최종 결정권은 엔지니어에게 남는다고 회사가 밝혔습니다.

보도자료와 Motor1 기사 내용을 비교 구도로 새로 그림

흔히 이렇게 봅니다AI 효과를 키우려면 쓸모 있는 에이전트를 업무마다 하나씩 더 붙이면 된다.

저자는 이렇게 봅니다에이전트는 이미 여러 공정에서 쓰이고 있으니, 다음 단계는 에이전트를 늘리는 일이 아니라 표준 데이터 모델로 서로 잇는 일입니다.

근거재료비, 인증, 결함, 소프트웨어 에이전트가 공정 안에서 따로 돌던 상태를 PLM.AI가 공정 사이로 연결하고, 이 연결에 약 5억 유로를 씁니다.

왼쪽은 흔한 방식을 든 개념도

저자가 든 사례

Mercedes-Benz PLM.AI: 중국 업체의 개발 속도에 맞서는 개발 체계 전환

상황: CTO가 중국 업체의 개발 속도와 고객 중심을 높이 평가했습니다. 중국 판매는 2025년 19%, 2026년 1~9월 29% 줄었습니다. 기사는 감소를 중국 경쟁 탓만으로 볼 수 없다고 덧붙였습니다.
한 일: 개발, 구매, 생산, 판매, 애프터세일즈를 잇는 PLM.AI를 발표하고 약 5억 유로를 투자합니다. CONTACT Software와 Siemens가 함께합니다.
결과(목표): 개발 기간 최대 30% 단축, 개별 공정 효율 최대 50% 개선, 물리 시험 장기적으로 최대 50% 감소. 모든 차량 프로그램의 기반으로 삼겠다고 밝혔고 단계별 일정과 적용 차종은 밝히지 않았습니다.
연결: Digital Thread, 공정 사이 에이전트 연결, 플랫폼과 소유권 분담.

수치는 Motor1 기사와 Mercedes-Benz 보도자료 기준

판매 흐름: 왜 지금 속도를 말하나

상황: 글로벌 판매도 2025년 9% 줄어 1,801,291대였고 2026년 1~9월에는 7.2% 줄어 1,341,427대였습니다.
한 일: 새 엔트리 모델, 차세대 CLA, 전기 E-Class, 소형 G-Class, G-Class 컨버터블 복귀 같은 신차를 준비하고 있습니다.
결과: 기사는 신차가 판매 흐름을 되돌릴지는 아직 알 수 없다고 봅니다.
연결: 신차를 빨리 내는 능력이 곧 개발 기간이라는 점에서 PLM.AI 목표와 이어집니다.

Motor1 기사 수치. 판매 감소율, 막대는 0 기준 비례

기술 디테일: 변경 영향 분석을 직접 만든다면

아래 필드명, 설정값, 구성은 실행 제안이자 가상 예시입니다. 원문과 보도자료에서 온 내용은 따로 표시했습니다.

공통 데이터 모델은 부품 번호와 개정 번호를 키로 짭니다(Digital Thread). 처음부터 전 영역을 모델링하지 말고 변경 영향 분석에 필요한 객체만 정의합니다. 부품(part_id, revision, 재질, 질량), BOM 관계, 요구사항, 시험 케이스와 결과, 공급사 견적, 공정 단계, 규제 항목, 소프트웨어 기능이 최소 단위입니다. 관계는 “부품은 시험 케이스로 검증된다”, “부품은 공정 단계에서 조립된다”, “기능은 ECU에 배포된다”처럼 정의해 그래프로 탐색할 수 있게 둡니다. 개정 번호가 빠진 레코드는 에이전트 입력에서 제외합니다. 같은 부품의 옛 개정 결과를 섞으면 trade-off 표가 틀립니다.

변경 요청 하나를 이 구조로 받습니다(Cross-Functional Trade-off).

{
  "change_id": "ECR-2026-0412",
  "part_id": "BRK-SEAT-07",
  "from_rev": "C",
  "to_rev": "D",
  "change_type": "material",
  "detail": {"from": "steel", "to": "aluminium", "delta_mass_g": -420},
  "requested_by": "경량화 설계",
  "decision_due": "2026-11-20"
}

에이전트는 각자 같은 형식으로 답합니다. 원가 에이전트는 cost_delta_eur, 충돌 에이전트는 crash_margin_pct(기준 대비 여유), 기능 에이전트는 affected_functions, 공정 에이전트는 process_changes를 채우고, 모두 evidence에 근거가 된 레코드 ID와 개정 번호, 조회 시각을 남깁니다. 근거 없는 수치는 취합 단계에서 버립니다. 원가 에이전트의 답은 아래와 같은 모양입니다.

{
  "change_id": "ECR-2026-0412",
  "agent": "cost",
  "cost_delta_eur": 3.8,
  "status": "ok",
  "evidence": [
    {"record": "COST-TBL/BRK-SEAT-07", "revision": "D", "read_at": "2026-11-08T09:14:00"},
    {"record": "QUOTE/SUP-118", "revision": "2", "read_at": "2026-11-08T09:14:02"}
  ],
  "note": "알루미늄 단가 상승, 가공비는 동일"
}

status는 ok, unverified(시간 초과나 근거 부족), conflict(근거 개정 번호가 요청과 다름) 셋 중 하나로 두고, 취합 화면은 ok가 아닌 칸을 따로 표시합니다.

실행 제안(가상 예시). 필드명은 아래 JSON과 같음

숫자는 계산 도구가, 문장은 LLM이 맡습니다(공정 사이 에이전트 연결). 원가는 원가 테이블, 충돌 여유는 CAE 해석 결과처럼 숫자는 결정적인 도구에서 가져옵니다. LLM은 어떤 도구를 부를지 고르고 결과를 trade-off 문장으로 바꾸는 데 씁니다. temperature는 0으로 두고 같은 요청을 3회 돌려 affected_functions 목록이 다르게 나오면 사람 검토로 넘깁니다. 에이전트 하나가 30초 안에 답하지 않으면 그 칸을 “미확인”으로 표시하고 나머지로 표를 만듭니다. 빈칸을 다른 에이전트가 추정해 채우지 않게 합니다.

시뮬레이션이 시험을 대신할 조건을 기록으로 정합니다(Digital Twin 시뮬레이션). 부품군마다 시뮬레이션과 물리 시험 결과의 차이를 누적합니다. 최근 10건의 오차가 정한 범위(예: 5% 이내) 안에 있고 신소재가 아닌 경우에만 물리 시험을 생략 후보로 올립니다. 생략 여부는 시험 책임자가 승인합니다. 오차가 범위를 벗어나는 건이 한 번이라도 나오면 그 부품군은 다시 물리 시험 필수로 돌립니다.

막히는 경우	증상	대응
부품 번호 체계가 부서마다 다름	원가와 시험 결과가 같은 부품에 안 붙음	매핑 테이블을 먼저 만들고 매핑률 95% 미만 부품군은 시범에서 제외
옛 개정 데이터 혼입	trade-off 표 수치가 현재 설계와 안 맞음	`evidence`의 개정 번호를 요청의 `to_rev`와 대조, 다르면 경고
에이전트 결과가 매번 다름	영향 기능 목록이 실행마다 바뀜	3회 실행 비교, 불일치 시 사람 검토
시뮬레이션 과신	생략한 시험 항목에서 후반 결함	부품군별 오차 이력 관리, 범위 이탈 시 즉시 물리 시험 복귀
벤더 종속	플랫폼 교체 시 데이터 모델과 이력 유실	데이터 모델 정의와 학습 데이터를 회사 저장소에 보관(보도자료의 소유권 원칙과 같은 방향)

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

보도자료는 엔지니어가 최종 결정권을 갖고, 회사가 아키텍처·데이터 모델·거버넌스를 정한다고 밝혔습니다. 아래 역할, 일정, 기준은 이를 바탕으로 새로 짠 가상 예시입니다.

역할	맡는 일
차량 프로그램 PM	시범 부품군 선정, 판정 회의 주재, 현장 스폰서
설계 엔지니어 2~3명	지난 변경 이력 제공, 에이전트 결과와 기존 검토 결과 대조, 최종 결정
원가·CAE·생산기술 담당 각 1명	기능별 기준값과 판정 규칙 정의, 에이전트 결과 검증
인증 담당	규제 항목과 부품의 연결 확인
PLM·데이터 아키텍트	데이터 모델 범위, 부품 번호 매핑, 에이전트 연결과 로그

준비물. 시범 부품군의 최근 1년 설계 변경 요청(ECR) 이력과 각 건의 처리 기간, 부품별 원가 테이블, CAE 해석과 물리 시험 결과, 공정표, 규제 요구사항 목록이 필요합니다. 처리 기간은 효과 측정의 기준선이므로 변경 요청 접수부터 승인까지 날짜를 건별로 뽑아 둡니다.

기간	할 일	산출물
1~3주	부품군 선정, 지난 변경 30건 수집, 데이터 모델 범위 정의	객체·관계 정의서, 변경 처리 기간 기준선
4~6주	데이터 연결, 기능별 에이전트 연결, 기준값 정의	변경 요청 1건당 trade-off 표 시제품
7~11주	새 변경 요청에 기존 방식과 병행 적용	처리 기간, 결과 일치율, 후반 발견 결함 수
12주	판정 회의, 확대 범위 결정	진행·보완·중단 결정서

가상 예시 일정. 1~3주 준비, 4~6주 구축, 7~11주 병행, 12주 판정

현장에 물을 것.

설계 변경 하나가 승인되기까지 평균 며칠 걸리고, 가장 오래 기다리는 부서는 어디인가요?
지난 1년 동안 양산 직전에 드러난 문제 가운데, 변경 당시 이미 있던 데이터로 찾을 수 있었던 건은 몇 건인가요?
같은 부품을 부서마다 다른 번호나 이름으로 부르는 경우가 있나요?
시뮬레이션 결과만으로 물리 시험을 줄여 본 적이 있다면 어떤 부품이었고 결과는 어땠나요?
에이전트가 낸 trade-off 표를 누가 보고 누가 서명해야 하나요?

진행 판정 기준(예시). 병행 기간에 변경 요청 처리 기간이 기준선보다 30% 이상 줄고, 에이전트가 낸 영향 범위가 기존 검토 결과와 90% 이상 일치하며, 후반 발견 결함이 늘지 않으면 다음 부품군으로 넓힙니다. 일치율이 80% 아래면 데이터 모델과 매핑부터 고쳐 4주 더 봅니다. 처리 기간이 10% 미만으로 줄면 병목이 데이터가 아니라 승인 절차에 있는지 다시 봅니다.

AX 적용 제언. 이 구조는 자동차에만 해당하지 않습니다. 가전, 산업 장비, 조선처럼 부품이 많고 설계 변경이 여러 부서로 번지는 제조업이면 그대로 옮길 수 있습니다. 순서는 데이터 모델, 에이전트 연결, 시뮬레이션 확대입니다. 이미 부서마다 AI 도구를 쓰고 있다면 도구를 더 들이기 전에 부품 번호와 개정 번호로 데이터를 잇는 작업을 먼저 예산에 올립니다. 첫 대상은 변경이 잦고 처리 기간이 길며 원가와 안전이 함께 걸린 부품군이 좋습니다. 스폰서는 개발 총괄 임원이 맡아야 구매와 생산이 같은 데이터 모델에 동의합니다. 플랫폼 벤더와 계약할 때는 데이터 모델과 그 위에서 만든 AI 모델의 소유권을 회사가 갖는다는 조항을 먼저 확인합니다.

원문 사례

항목	내용
원문	Motor1, 2026.11.4, Adrian Padeanu. 호주 Drive 인터뷰를 인용
화자	Jörg Burzer, Mercedes-Benz 이사회 멤버, CTO(개발·구매)
중국 평가	중국 업체의 개발 속도와 고객 중심을 높이 평가, 모든 영역에서 뒤처진 것은 아니라고 언급
중국 판매	2025년 19% 감소 551,932대, 2026년 1~9월 29% 감소 418,305대
글로벌 판매	2025년 9% 감소 1,801,291대, 2026년 1~9월 7.2% 감소 1,341,427대
PLM.AI	개발·구매·생산·판매·애프터세일즈를 잇는 AI 기반 디지털 중추, 표준 데이터 모델
기존 에이전트	재료비 최적화, 인증·형식승인, 결함 탐지·해결, 소프트웨어 개발 지원
목표	개발 기간 최대 30% 단축, 개별 공정 효율 최대 50% 개선, 물리 시험 장기 최대 50% 감소
투자·파트너	약 5억 유로, CONTACT Software(CONTACT Elements), Siemens(시뮬레이션·디지털 트윈)
소유·결정	데이터와 AI 모델은 Mercedes-Benz 소유, 결정 책임은 팀에
공식 발표	2026.10.16 Mercedes-Benz Group 보도자료
신차 계획	새 엔트리 모델, 차세대 CLA, 전기 E-Class, 소형 G-Class, G-Class 컨버터블 등

핵심 개념

PLM: Product Lifecycle Management. 제품의 기획, 설계, 생산, 서비스까지 제품 데이터와 변경 이력을 관리하는 체계와 시스템입니다.
BOM: Bill of Materials. 제품을 이루는 부품과 수량, 상하 관계를 적은 목록입니다.
ECR: Engineering Change Request. 설계를 바꾸자는 공식 요청으로, 관련 부서의 영향 검토를 거쳐 승인됩니다.
Homologation: 판매하려는 국가의 안전·환경 규제를 충족했음을 당국에서 인정받는 절차입니다.
CAE: Computer-Aided Engineering. 충돌, 강도, 열 같은 성능을 컴퓨터 해석으로 미리 계산하는 일입니다.
CONTACT Elements: CONTACT Software의 개방형 플랫폼으로, PLM.AI에서 제품 데이터와 프로세스를 통합하는 코어 계층을 맡습니다.

내 메모

TODO: 내 생각 추가

원문은 Motor1의 「Mercedes Praises China For Developing Cars So Quickly, Turns To AI To Catch Up」(Adrian Padeanu, 2026.11.4)이며 호주 Drive 인터뷰를 인용한 기사입니다. PLM.AI의 작동 방식, 경량화 예시, 파트너 역할, 투자 규모, 소유권 원칙은 Mercedes-Benz Group의 공식 보도자료(2026.10.16)로 보강했고, 약 17개월 환산치는 독일 매체(mbpassion 등)의 보도입니다. 30%, 50% 같은 목표치는 회사 발표이며 달성 결과가 아닙니다. 요약, 핵심 메커니즘의 원문 설명, 통념과 다른 주장, 사례, 원문 사례 표는 원문과 보도자료 내용을 AX Review가 다시 정리했습니다. 데이터 모델 객체, JSON 예시, 에이전트 실행 설정, 막히는 경우 표, 역할·일정·판정 기준, 인포그래픽은 원문에 없는 내용으로 새로 작성했고 그 안의 필드명과 숫자는 가상 예시입니다. 전체 내용은 원문 페이지에서 볼 수 있습니다.