AI Ready Data: 야자키가 모은 트러블 기록 2,432건 중 AI가 쓴 27건, 온톨로지로 다시 짓는다
와이어 하니스 대기업 야자키는 국내 직원 97%가 생성형 AI를 쓰지만 전사 성과는 보이지 않았습니다. 과거 트러블 기록 2,432건을 모았더니 AI가 쓸 수 있는 것은 27건뿐이었고, 원인은 데이터 양이 아니라 표기와 의미가 제각각인 데 있었습니다. 야자키는 DB를 먼저 만들고 그 위에 온톨로지를 세우며, ERP를 Oracle Fusion으로 옮깁니다.
야자키는 직원 대부분이 생성형 AI를 쓰는데도 경영 성과가 보이지 않는 이유를 데이터에서 찾았습니다. 과거 트러블 기록 2,432건 가운데 AI가 쓸 수 있었던 기록은 27건(약 1%)이었습니다. 따라 하려면 AI 도구를 늘리기 전에 기록 한 건 한 건이 AI가 읽을 수 있는 상태인지 먼저 재고, 표기와 의미를 맞추는 온톨로지 작업을 담당자와 일정이 있는 프로젝트로 세워야 합니다.
요약
자동차 와이어 하니스(차량 전선 다발) 대기업 야자키(矢崎総業)의 AI·디지털실장 단게 히로시(丹下博) 집행임원이 2026년 10월 6일 도쿄에서 열린 일본오라클 ‘Oracle AI Forum’ 기조강연에 게스트로 나왔습니다. 미사와 도시미쓰(三澤智光) 일본오라클 사장이 ‘AI로 무엇을 지향하나’라는 주제를 던졌습니다. 그는 Copilot 같은 지원형 AI는 개인 시간을 줄여도 업무 자체는 바꾸지 못해 재무제표에 드러나기 어렵다고 짚었습니다. 반면 AI가 업무를 직접 수행하는 기간계 AI는 100명의 일을 80명이 하게 만들어 KPI에 나타난다는 설명입니다. 단게 집행임원의 현황이 그 대비를 그대로 보여 줍니다. 국내 직원 약 1만 7,000명 가운데 1만 6,572명(약 97%)이 생성형 AI를 쓰고, IT 부서 밖에서 AI로 무언가를 만드는 시민 개발자도 5,307명입니다. 그런데도 전사 수준의 재무 효과는 경영진에게 설명하기 어렵고 본인도 실감하지 못한다고 했습니다.
그는 데이터와 AI 시책이 경영에 기여하는 길을 IT 태스크, 프로세스 변혁, 업무 가치, 재무 가치로 이어지는 틀로 정리했습니다. 어느 시책이든 필요한 데이터가 갖춰지지 않은 데서 멈춘다는 것이 결론이었습니다. 이를 확인한 것이 과거 트러블 기록입니다. 2,432건을 모았지만 AI가 쓸 수 있었던 것은 27건이었고, 그는 이를 전형적인 ‘Garbage in, Garbage out’이라고 불렀습니다. 처방은 두 갈래입니다. 하나는 데이터베이스를 먼저 만들고 그 위에 온톨로지(데이터가 무엇을 뜻하는지 정의한 개념 체계)를 세워 부서마다 다른 표기와 의미를 맞추는 일입니다. 다른 하나는 ERP 아래 데이터를 AI가 폭넓게 쓸 수 있도록 Oracle Fusion Cloud Applications를 들이는 일입니다. 아래에서는 이 흐름을 다섯 메커니즘으로 나누고 실제로 돌릴 때 필요한 디테일을 덧붙입니다.
핵심 메커니즘
AI Ready 진단: 모은 기록 중 AI가 실제로 쓸 수 있는 몫을 잰다
AI Ready는 데이터가 사람 눈이 아니라 AI가 읽고 판단에 쓸 수 있는 상태라는 뜻입니다. 야자키는 기록을 얼마나 모았는지가 아니라, 모은 기록 중 AI가 쓸 수 있는 비율을 쟀습니다. 입력은 모은 과거 트러블 기록 2,432건이고, 출력은 쓸 수 있는 기록 27건이라는 숫자입니다. 이 숫자 하나가 “AI 교육과 계획을 해도 데이터에서 막힌다”는 주장을 경영진이 받아들일 근거가 됐습니다. 품질 이력, 설계 변경, 클레임처럼 사람이 쓴 보고서가 쌓인 영역이라면 AI 과제를 고르기 전에 이 진단부터 하는 편이 맞습니다.
기술 방식의 문제와 형식의 문제: 못 쓰는 이유를 둘로 나눈다
야자키는 AI가 기록을 못 쓴 원인을 두 가지로 갈랐습니다. 기술 방식의 문제(書き方)는 데이터는 있는데 AI가 읽지 못하는 경우입니다. 같은 재료가 최대 12가지 표기로 흩어져 있었습니다. 화살표나 색으로 단 보충 설명은 값으로 남지 않았습니다. 횟수를 적는 칸에는 숫자 대신 ‘산발’, ‘시도 다수’ 같은 말이 들어가 있었습니다. 형식의 문제(形式)는 애초에 데이터가 되어 있지 않은 경우입니다. 둘은 고치는 방법이 다릅니다. 기술 방식의 문제는 정규화와 의미 정렬로, 형식의 문제는 디지털 값으로 옮기는 작업으로 풉니다. 그래서 진단 단계에서 기록마다 어느 쪽인지 표시해 두어야 일을 나눌 수 있습니다.
Ontology over Master Data: 코드 통일을 넘어 뜻을 맞춘다
기존의 데이터 통합은 마스터 데이터(거래처·품목 같은 기준 정보)의 코드를 맞추는 방식이었습니다. 단게 집행임원은 LLM을 쓰는 이상 이 방식은 통하지 않는다고 봤습니다. LLM은 말의 표기와 의미가 맞아야 제대로 반응하기 때문입니다. 온톨로지는 “이 12가지 표기는 같은 재료다”, “이 칸의 ‘산발’은 이런 빈도를 뜻한다” 같은 의미와 관계를 정의해 둡니다. 그는 이 정렬이 부서 하나의 사일로 데이터만 쓸 때는 필요 없고, 여러 부서에 걸쳐 AI를 쓸 때 반드시 필요하다고 구분했습니다. 문제는 데이터의 양이 아니라 의미와 문맥이 어긋나 있다는 데 있다는 진단입니다.
Database First: DB를 먼저, 온톨로지는 그 위에
야자키의 데이터는 전 세계 46개 거점에 흩어져 있어 어디서부터 묶을지가 과제였습니다. 그가 고른 순서는 데이터베이스를 먼저 만들고, 거기서 온톨로지를 만드는 것입니다. 모든 데이터를 한 번에 넣는 것을 전제로 하지 않습니다. 수십 퍼센트만 들어와도 통합이 훨씬 쉬워진다는 판단입니다. 실무로 옮기면 “전사 온톨로지 설계 완료”를 출발 조건으로 두지 않고, 쓸 기록을 한곳에 모은 뒤 그 위에서 개념을 하나씩 늘리는 방식입니다.
Oracle Fusion: ERP 아래 데이터를 AI가 쓰게 하는 SaaS
야자키는 전 세계에 Oracle의 경쟁사 ERP를 쓰고 있었고, 처음에는 Fusion을 검토하지도 않았습니다. 판단이 바뀐 이유는 두 가지입니다. 첫째, AI 시대에는 ERP 아래 데이터를 AI로 폭넓게 쓸 수 있느냐가 중요해졌습니다. 그는 다른 ERP의 AI는 주로 ERP 조작을 돕는 기능이라는 점에서 다르다고 봤습니다. 미사와 사장도 Fusion이 ERP, SCM, HCM, CRM을 단일 데이터 모델로 돌리고 그 안에 문맥과 온톨로지, 권한·감사 같은 규범을 넣었다고 설명했습니다. 둘째, 자동으로 버전이 올라가는 SaaS라는 점입니다. 괴로운 ERP 버전업을 다음 세대에 물려주지 않겠다는 것입니다. 도입은 일본에서 시작해 2027년 가을까지 재무계 시스템 중심으로 마치고, 이후 글로벌로 넓힙니다.
통념과 다른 주장
흔히 이렇게 봅니다사내 기록을 충분히 모으면 AI가 그 경험을 학습해 활용할 수 있다.
야자키는 이렇게 봅니다문제는 데이터의 양이 아니라 의미와 문맥이 맞지 않는 데 있습니다. 모은 기록 대부분은 AI가 쓸 수 없는 상태였습니다.
근거과거 트러블 기록 2,432건을 모았지만 AI가 쓸 수 있었던 것은 27건이었고, 원인은 표기 불일치와 값이 아닌 보충 정보였습니다.
흔히 이렇게 봅니다데이터 통합은 마스터 데이터와 코드 체계를 통일하면 끝난다.
야자키는 이렇게 봅니다LLM을 쓰려면 코드뿐 아니라 말의 표기와 의미까지 맞춰야 합니다. 부서를 넘어 쓰려면 전사 온톨로지가 필요합니다.
근거같은 재료가 최대 12가지 표기로 기록돼 있었고, 이런 데이터는 마스터 통합만으로는 LLM이 같은 것으로 알아보지 못한다고 설명했습니다.
흔히 이렇게 봅니다AI 활용률을 높이면 전사 성과는 따라온다.
야자키는 이렇게 봅니다개인 단위 활용이 거의 전원으로 퍼져도 재무 효과는 보이지 않을 수 있습니다. 시책이 막히는 지점은 데이터입니다.
근거국내 직원 약 97%가 생성형 AI를 쓰고 시민 개발자가 5,307명인데도, 경영진에게 재무 효과를 설명하기 어렵다고 밝혔습니다.
저자가 든 사례
야자키: 과거 트러블 기록의 AI 활용 점검
| 구분 | 내용 |
|---|---|
| 상황 | 국내 직원 약 97%가 생성형 AI를 쓰지만 전사 재무 효과가 보이지 않음 |
| 한 일 | 과거 트러블 기록 2,432건을 모아 AI 활용 가능성을 점검, 원인을 두 갈래로 분류 |
| 결과 | AI가 쓸 수 있는 기록 27건(약 1%). DB 우선·온톨로지 구축으로 방향을 잡고 Oracle Fusion 채택 |
| 연결 | AI Ready 진단, 기술 방식·형식의 문제, Ontology over Master Data |
기술 디테일: 트러블 기록을 AI Ready로 바꾸는 파이프라인을 돌린다면
아래 필드명, 설정값, 수량은 실제로 돌릴 때 필요한 것을 새로 쓴 가상 예시입니다.
AI Ready 진단을 돌리려면 기록 한 건을 구조화 출력 한 묶음으로 바꿉니다. 원본이 스캔 이미지라면 먼저 OCR로 글자를 뽑습니다. 이후 LLM에 아래 JSON만 내도록 스키마를 걸고 temperature 0으로 같은 기록을 3회 돌립니다. 3회 결과가 같은 필드만 채택하고, 다른 필드는 needs_review로 넘깁니다.
{
"record_id": "TR-JP-0412",
"site": "국내 공장 A",
"part_material": {"raw": "표기 원문", "canonical_id": "MAT-0031", "match": "alias"},
"symptom": "단자 압착 불량",
"occurrence": {"raw": "산발", "count": null, "freq_class": "sporadic"},
"root_cause": "…",
"countermeasure": "…",
"visual_notes": ["화살표로 표시된 위치 설명을 문장으로 옮김"],
"problem_type": "writing",
"ready_score": 3,
"evidence": ["page:1", "cell:C7"]
}기술 방식의 문제는 별칭 사전으로 풉니다. 재료·부품 이름은 canonical_id와 별칭 목록을 가진 사전에 대조합니다. 사전에 없는 표기는 LLM이 후보 2~3개를 내고, 임베딩 유사도 0.9 이상이면 ‘같은 개념 후보’, 0.7~0.9면 ‘확인 필요’로 둡니다. 자동 병합은 하지 않고 도메인 오너가 승인한 별칭만 사전에 올립니다. 횟수 칸의 ‘산발’ 같은 말은 count를 비우고 freq_class(sporadic, frequent, once)로 옮깁니다. 숫자를 지어내지 않게 하는 장치입니다.
형식의 문제는 따로 셉니다. 디지털 값이 아예 없는 기록은 problem_type: "format"으로 표시하고 디지털화 대기열로 보냅니다. 두 문제를 한 대기열에 섞으면 정규화 담당이 스캔 작업에 묶입니다.
판정 기준(가상 예시). 기록마다 아래 점수를 매기고 5점만 검색·RAG 대상에 넣습니다. 진단 보고에는 “모은 건수 대비 5점 건수”를 씁니다. 야자키가 쓴 2,432건 대 27건과 같은 형식입니다.
| 점수 | 기준 |
|---|---|
| 5 | 재료·증상·원인·대책이 모두 값으로 있고, 재료가 canonical_id에 연결됨 |
| 3 | 필드는 채워졌지만 별칭 미승인 또는 횟수가 글자로만 있음 |
| 0 | 디지털 값 없음, 또는 핵심 필드 둘 이상이 빔 |
| 막히는 경우 | 증상 | 대응 |
|---|---|---|
| 같은 표기, 다른 재료 | 부서마다 같은 이름을 다른 재료로 씀 | 자동 병합 금지, 거점·부서를 조건으로 붙인 별칭으로 등록 |
| 색·화살표 정보 | 텍스트 추출에서 사라짐 | 이미지 영역을 비전 모델에 넣어 visual_notes로 문장화, 사람 확인 |
| 3회 결과 불일치 | 원인·대책 필드가 매번 다름 | 해당 필드만 needs_review, 원문 위치 evidence 첨부 |
| 다국어 기록 | 거점마다 언어가 다름 | 추출 단계에서 원문 언어 유지, canonical_id로만 연결 |
현업 실행 디테일: 누가, 언제, 무엇을
야자키는 AI·디지털실과 정보시스템 총괄실을 한 사람이 이끌며 AI와 데이터 기반을 함께 다룹니다. 아래 역할, 일정, 기준은 이를 참고해 새로 짠 가상 예시입니다.
| 역할 | 맡는 일 |
|---|---|
| CIO·CDO(스폰서) | 진단 대상 영역 선정, 표준 정의 분쟁의 최종 결정 |
| 품질보증 담당 | 트러블 기록 표본 추출, 필드 정의, 채점 검수 |
| 도메인 오너(재료·설계) | 별칭 승인, 개념 정의 확정 |
| 데이터 엔지니어 | DB 적재, 추출·정규화 파이프라인 운영 |
| AX 추진 | 진단 수치 보고, 확대 여부 판정, ERP 전환 일정과 연계 |
준비물. 거점 2~3곳의 트러블 기록 표본 200건, 재료·부품 마스터, 기록 양식 원본, 부서마다 다르게 쓰는 용어 목록이 필요합니다. 첫 주에 AI가 읽어도 되는 기록 범위를 정보보안과 정합니다.
| 기간 | 할 일 | 산출물 |
|---|---|---|
| 1~2주 | 범위 확정, 표본 200건 추출 | 대상 목록, 필드 정의서 |
| 3~4주 | DB 적재, 구조화 추출 3회 실행 | 기록별 JSON, 기술 방식·형식 분류 |
| 5~6주 | 별칭 사전 정리, 오너 승인 | 승인 별칭, 재료 개념 목록 |
| 7~8주 | 0·3·5점 채점, 경영 보고 | ‘N건 중 M건’ 진단표, 확대 판정 |
도메인 오너에게 물을 것.
- 이 재료를 부르는 이름이 거점·부서마다 몇 가지 있나요? 공식 이름은 무엇인가요?
- 기록에서 색이나 화살표로 표시하는 정보는 무엇인가요?
- ‘산발’, ‘시도 다수’는 실제로 몇 회 정도를 뜻하나요?
- 이 기록을 찾을 때 실제로 어떤 질문으로 찾나요?
- 정의가 바뀌면 누가 승인하나요?
진행 판정 기준(예시). 표본 200건 중 5점 비율이 50% 이상이면 같은 방식으로 기록 전체를 넓힙니다. 20~50%면 양식을 고쳐 새 기록부터 값으로 남기게 하고 4주 더 봅니다. 20% 미만이면 AI 과제보다 기록 양식과 디지털화를 먼저 합니다.
AX 적용 제언. 생성형 AI 이용률은 높은데 성과 보고가 막힌 제조사라면 야자키의 순서를 그대로 옮길 만합니다. 품질·설계처럼 보고서가 오래 쌓인 영역 하나를 골라 ‘N건 중 M건’을 먼저 재면, 경영진에게 데이터 투자를 설명할 숫자가 생깁니다. 그다음 DB에 일부부터 담고 별칭과 개념을 늘려 갑니다. ERP 전환을 앞두고 있다면 새 ERP가 AI에 데이터를 어떻게 내주는지를 선정 기준에 넣고, 온톨로지 작업과 일정을 맞춥니다.
원문 사례
| 항목 | 내용 |
|---|---|
| 원문 | ITmedia 엔터프라이즈, 2026.11.12 게재 |
| 바탕 행사 | 일본오라클 Oracle AI Forum 기조강연(2026.10.6, 도쿄) |
| 발표자 | 미사와 도시미쓰 일본오라클 사장, 단게 히로시 야자키 집행임원(AI·디지털실장 겸 정보시스템 총괄실장) |
| 회사 | 와이어 하니스 대기업, 세계 차량 3대 중 1대에 공급, 46개 국가·지역 약 22만 명, 2026년 6월기 매출 2.9조 엔 |
| AI 이용 | 국내 직원 약 1만 7,000명 중 생성형 AI 이용 1만 6,572명(약 97%), 시민 개발자 5,307명 |
| 과제 | 개인 활용은 넓지만 전사 재무 효과가 보이지 않음 |
| 트러블 기록 | 2,432건 중 AI 활용 가능 27건(약 1%) |
| 원인 | 기술 방식의 문제(표기 최대 12가지, 화살표·색 보충, 횟수 칸의 글자), 형식의 문제 |
| 방침 | 마스터 통합을 넘어 온톨로지로 의미 정렬, DB 먼저, 수십 %부터 |
| ERP | 경쟁사 ERP에서 Oracle Fusion으로. 일본부터, 2027년 가을 재무계 중심 완료, 이후 글로벌 |
핵심 개념
- Garbage in, Garbage out
- 입력 데이터가 나쁘면 아무리 좋은 모델도 나쁜 결과를 낸다는 말입니다.
- 過去トラ(과거 트러블 기록)
- 제조 현장에서 일어난 불량·문제와 그 원인·대책을 적은 보고서입니다. 재발 방지와 설계 검토에 다시 씁니다.
- Master Data
- 거래처, 품목, 재료처럼 여러 업무가 함께 쓰는 기준 정보입니다.
- 시민 개발자
- IT 부서 소속이 아니면서 로코드나 AI 도구로 업무 도구를 직접 만드는 직원입니다.
- 기간계 AI
- 개인 작업을 돕는 데 그치지 않고 ERP 같은 핵심 업무 시스템 안에서 일을 직접 수행하는 AI입니다.
- SaaS ERP
- 공급사가 운영하며 버전을 자동으로 올려 주는 클라우드형 ERP입니다.
내 메모
TODO: 내 생각 추가
원문은 ITmedia 엔터프라이즈의 「トラブル情報2400件超、AIで使えたのは27件 矢崎総業が直面した「AI Ready」の壁」(2026.11.12)입니다. 원문 페이지를 직접 열 수 없어, 같은 강연을 다룬 MONOist의 「矢崎総業が直面したAI活用の壁、オラクルの「Fusion」採用が必然となった理由」(2026.10.27, 朴尚洙, monoist.itmedia.co.jp/mn/articles/2610/27/news046.html)를 근거로 정리했습니다. 요약, 핵심 메커니즘, 통념과 다른 주장, 사례는 이 보도에 나온 내용을 AX Partners가 다시 정리했습니다. 기술·현업 디테일의 필드명, 설정값, 일정, 질문, 판정 기준, 인포그래픽과 표는 실제로 돌릴 때 필요한 것을 새로 작성한 가상 예시입니다. 세부 수치와 발언은 원문에서 확인할 수 있습니다.