사례로 보는 AX

사례를 읽는 법: 다섯 칸짜리 틀

AI 도입 사례를 읽을 때 가장 흔한 실수는 결과 숫자만 보는 것이다. "보고서 작성 시간 70% 단축" 같은 문장은 그 회사가 어떤 구조를 먼저 깔았는지, 무엇을 어떻게 측정했는지를 빼면 우리 팀에 옮길 수 없다. 이 장의 모든 사례는 같은 다섯 칸으로 쪼개서 쓴다.

A사: 고객 품질 클레임, 메일 스레드에서 이슈 카드로

레거시 방식

A사는 해외 완성품 고객사에 커넥터와 수동부품을 납품한다. 클레임은 언제나 메일로 온다. 고객사 품질 담당자가 사진 몇 장과 함께 "LOT 몇 번에서 불량 몇 건"이라고 쓰면, 영업 담당이 품질보증팀에 전달하고, 품질보증팀은 다시 생산·검사·공정기술에 메일을 돌린다. 스레드는 금세 세 갈래로 갈라지고, 숫자는 본문·첨부 엑셀·회신 인용문에 흩어진다.

메일 한 통 안에 LOT 번호, 불량 수, 기한, 과거 유사 사례에 대한 힌트, 검사 데이터 위치가 모두 들어 있다. 문제는 이 정보가 레코드가 아니라 문장이라는 점이다. 3월 건을 찾으려면 그때 담당자의 메일함을 뒤져야 하고, 8D 보고서는 지난번 파일을 복사해 고치기 때문에 고객마다, 담당자마다 양식이 다르다.

무엇이 문제였나

• 정보 단위가 없다. "클레임 1건"을 담는 표준 레코드가 없어서 집계·검색·재사용이 모두 불가능했다(2장의 메일 속 데이터).
• 이슈마다 다른 절차. 같은 접촉 불량인데 누가 맡느냐에 따라 조사 순서와 보고서가 달랐다(3장의 프로세스 부채).
• 과거 사례가 사람에게 묶여 있다. 유사 사례 검색이 "누가 기억하느냐"에 달려 있었고, 담당자 이동과 함께 단서가 사라졌다.

AX 방식

1. 데이터 — 이슈 카드고객, 제품, LOT, 현상(정준 불량 코드), 수량, 기한, 첨부를 필드로 갖는 표준 레코드를 만들었다. 메일이 오면 AI가 필드를 추출해 카드를 미리 채우고 담당자가 확인한다.
2. 프로세스 — 하나의 대응 흐름접수 → 봉쇄 → 원인 → 대책 → 검증 → 종결을 8D 단계에 맞춘 단일 흐름으로 정하고, 각 단계의 산출물을 카드의 필드로 고정했다. "같은 문제는 같은 양식으로."
3. AI — 유사 사례 RAG과거 8D 보고서와 종결된 이슈 카드를 색인해, 새 카드의 현상·제품군으로 유사 사례를 근거(문서 링크)와 함께 찾아 준다(6장).
4. AI — 8D 초안카드에 쌓인 데이터로 고객 양식에 맞춘 8D 초안을 만들고, 엔지니어가 원인·대책 문장을 검토·수정한 뒤 승인한다(10장의 사람 승인 지점).

B사: 설비 알람과 보전, 작업일지 엑셀에서 표준 고장코드로

레거시 방식

B사의 보전 기록은 라인마다 있는 "작업일지" 엑셀이다. 야간 조 정비사가 설비를 고치고 한 줄을 남긴다. 설비 이름은 사람마다 다르게 쓰고(3호기, P3, #3 프레스), 현상·원인·조치가 한 칸에 섞인다. 설비 알람은 SCADA 화면에 뜨지만, 알람 코드와 작업일지 기록은 서로 연결되어 있지 않다.

무엇이 문제였나

• 이름이 맞지 않는다. 설비 ID와 고장 분류가 없으니 MTBF·MTTR을 설비별로 계산할 수 없었다(4장).
• 알람과 조치가 끊겨 있다. 같은 알람 E-214가 반복되어도, 그때 무엇을 했고 효과가 있었는지 찾으려면 엑셀을 줄 단위로 읽어야 했다.
• 예지 보전의 학습 데이터가 없다. 진동 센서는 있었지만 "언제 실제로 고장 났는가"라는 라벨이 자유 텍스트 속에 묻혀 있었다(11장).

AX 방식

1. 데이터 — 설비 마스터와 고장코드ISA-95 계층(사이트–영역–작업센터–작업단위)에 맞춘 설비 ID를 정하고, 현상–원인–조치 3단 고장코드를 보전팀과 함께 50개 남짓(예시)으로 합의했다.
2. 프로세스 — 기록 방식 변경정비사는 태블릿에서 말로 입력하거나 짧게 쓰고, AI가 코드 후보를 제안하면 정비사가 고른다. 자유 텍스트는 버리지 않고 함께 저장한다.
3. AI — 이력 검색과 트리아지알람이 뜨면 같은 설비·같은 코드의 과거 조치와 효과를 요약해 보여 준다. 판단과 작업 지시는 사람이 한다.
4. AI — 예지 보전 파일럿정비 이력 6개월분이 쌓인 뒤, 핵심 설비 몇 대에서 진동 특성과 고장 시점을 연결한 모델을 시험했다.

C사: 설계 변경(ECN) 영향 분석, 메일 결재에서 연결된 지식으로

레거시 방식

C사는 고객 사양에 맞춰 장비를 조금씩 바꿔 만든다. 설계 변경 통지(ECN, Engineering Change Notice)는 PLM에 등록되지만, 실제 영향 검토는 메일 회람으로 이뤄진다. 설계자가 "브래킷 재질 변경"을 올리면 구매·생산기술·품질·서비스 담당이 각자 자기 엑셀과 기억으로 영향을 확인하고 "이상 없음"이라고 회신한다.

문제는 이상 없음의 근거가 없다는 것이다. 이 브래킷이 다른 세 모델의 하위 조립품에도 쓰이는지, 관련 작업 표준서와 검사 기준서가 몇 개인지, 서비스용 예비품 재고는 얼마인지는 각 시스템과 문서에 흩어져 있었다. 변경 후에 "이 부품이 그 모델에도 들어가는 줄 몰랐다"는 일이 반복됐다.

무엇이 문제였나

• 연결이 없다. BOM은 ERP·PLM에, 도면은 PLM에, 작업 표준서와 검사 기준서는 공유 폴더에 있었고, 서로를 가리키는 링크가 없었다.
• 품번 체계가 둘 이상. 설계 품번과 구매 품번이 달라 사람이 매핑표(엑셀)를 들고 다녔다(4장의 점대점 매핑).
• 검토가 기억에 의존. 회람 단계가 많아도, 각 단계가 무엇을 확인했는지는 기록되지 않았다.

AX 방식

1. 데이터 — 품번 정준화설계·구매 품번을 하나의 정준 품번으로 묶는 기준정보(MDM)를 만들고, 매핑 엑셀을 폐기했다.
2. 데이터 — 문서에 품번 메타데이터작업 표준서·검사 기준서·설계 검토록을 인벤토리하고, 문서마다 다루는 품번·공정을 메타데이터로 붙였다. 대부분은 AI가 본문에서 후보를 뽑고 문서 오너가 확인했다.
3. 프로세스 — 영향 검토 체크 항목 고정회람자는 "이상 없음" 대신 그래프가 보여 준 영향 대상 목록에 대해 항목별로 확인·의견을 남긴다.
4. AI — 영향 요약ECN이 등록되면 그래프를 탐색해 영향 대상 목록을 만들고, 관련 문서의 해당 구절을 근거로 붙인 요약을 회람자에게 보낸다.

D사: 공급망 공지 메일, 받은편지함에서 영향 부품 매칭으로

레거시 방식

D사 구매팀은 매주 공급사로부터 부품 단종(EOL, End of Life) 통지, 제품 변경 통지(PCN, Product Change Notification), 납기 지연 안내를 받는다. 형식은 공급사마다 다르다. PDF 첨부, 본문 표, 포털 링크, 심지어 이미지 캡처까지 있다. 담당 바이어가 읽고, 해당 부품이 우리 제품 어디에 쓰이는지 ERP에서 찾고, 영향이 있으면 개발·품질에 메일을 보낸다.

이 메일에는 단종 품번, 최종 주문 기한(LTB, Last Time Buy), 대체품, 호환성 단서라는 네 가지 핵심 정보가 있다. 하지만 받은 사람이 휴가 중이었다면? 첨부의 나머지 14개 품번은 누가 확인했을까? 공급사 품번과 D사 사내 품번은 어떻게 연결할까?

무엇이 문제였나

• 개인 메일함이 접수 창구. 공지가 개인에게 오니 부재·이동 시 누락됐다(2장).
• 공급사 품번 ↔ 사내 품번 매핑 부재. 같은 부품이 여러 사내 품번으로 등록된 경우도 있었다(5장의 유일성 문제).
• 영향 판단 기준이 사람마다 다름. "핀 호환"이면 바로 대체 가능한지, 재승인(PPAP 등 고객 승인 절차)이 필요한지 판단이 들쭉날쭉했다.

AX 방식

1. 데이터 — 공동 접수함과 공지 레코드공급사 공지는 팀 공동 주소로 받도록 공급사에 요청하고, 공지 1건을 공급사·품번 목록·공지 유형·기한·대체품·호환성 필드를 가진 레코드로 정의했다.
2. 데이터 — 공급사 품번 교차표사내 정준 품번과 공급사 품번의 교차 참조를 기준정보로 관리하고, 중복 등록된 사내 품번을 정리했다.
3. AI — 분류와 추출들어온 메일과 첨부(PDF·표)를 유형별로 분류하고 필드를 추출한다. 추출 신뢰도가 낮거나 기한이 가까운 건은 바이어 확인 대기열로 보낸다.
4. AI + 규칙 — 영향 매칭추출된 품번을 교차표와 BOM으로 연결해 영향 받는 모델·재고·진행 중 주문을 표로 만들고, 호환성 수준에 따라 미리 정한 대응 경로(재고 확보, 대체품 평가, 고객 통보)를 제안한다.

E사: 퇴직자 지식, 사람 머릿속에서 검색 가능한 지식으로

레거시 방식

E사의 반응 공정에는 "이 원료 LOT는 점도가 높게 나오니 승온을 천천히"처럼 문서에 없는 판단이 많다. 이런 노하우는 20년 차 공정 엔지니어 몇 명의 머릿속에 있었다. 후배들은 막히면 메신저로 물었고, 답은 메신저에 남았다가 사라졌다. 이 엔지니어들의 정년이 몇 년 안에 몰려 있다는 사실이 확인되자, 회사는 "문서화하라"는 지시를 내렸다. 결과는 수백 쪽짜리 PPT 몇 개였고, 아무도 열어 보지 않았다.

무엇이 문제였나

• 지식의 단위가 너무 크다. "전부 정리하라"는 지시는 읽히지 않는 대형 문서를 낳았다.
• 질문과 답이 만나지 않는다. 후배가 실제로 묻는 질문과 선배가 쓴 문서의 목차가 달랐다.
• 권한과 민감도. 배합·공정 조건은 핵심 기술 정보라서 아무 도구에나 넣을 수 없었다(12장).

AX 방식

1. 사람 — 질문에서 출발한 인터뷰메신저·메일에서 후배들이 실제로 물었던 질문을 모아 유형화하고, 숙련자와 30분짜리 인터뷰를 여러 번 진행했다. 녹취는 AI가 받아 적고 요약한다.
2. 데이터 — 지식 카드인터뷰를 "상황 → 판단 → 이유 → 예외 → 관련 문서" 형식의 짧은 카드로 쪼개고, 숙련자가 직접 검수해 서명했다. 카드마다 공정·설비·원료 코드를 붙였다.
3. 데이터 — 문서 인벤토리와 권한기존 SOP·실험 노트·이상 보고서를 인벤토리하고 보안 등급과 열람 권한을 정리했다.
4. AI — 권한 기반 RAG사내에 배포한 모델로 지식 카드와 문서를 검색해 답하되, 질문자의 권한 범위 문서만 근거로 쓰고 출처를 반드시 표시한다. 답이 없으면 "카드 없음"으로 기록해 다음 인터뷰 주제로 넘긴다.

사례를 가로질러 보기: 전후 지표와 측정 정의

다섯 사례의 결과를 한자리에 놓아 보자. 막대의 길이보다 막대 위의 측정 정의가 더 중요하다. "보고서 작성 시간"을 첫 타이핑부터 쟀는지, 데이터 취합부터 쟀는지에 따라 같은 개선도 두 배 차이가 난다. 8장에서 말한 대로, 지표는 시작 전에 정의하고 기준값(baseline)을 먼저 재야 한다.

다섯 사례의 공통 구조

사례를 나란히 놓으면 업종도 업무도 다른데 뼈대가 같다는 것이 보인다. 모두 정보의 표준 단위를 먼저 정의했고, 그 단위를 정준 ID로 연결했으며, AI는 그 위에서 추출·검색·초안을 맡고 최종 판단은 사람이 했다.

교훈 정리와 업계 흐름

다섯 사례에서 반복된 교훈을 일곱 문장으로 줄이면 다음과 같다.

공개적으로 알려진 업계 흐름

세계경제포럼(WEF)은 첨단 제조 기술을 대규모로 적용한 공장을 선정해 글로벌 등대 네트워크(Global Lighthouse Network)로 소개하고 있으며, 여러 나라·업종의 제조사가 이름을 올렸다. 공개된 소개 자료에서 반복되는 주제는 단일 기술보다 여러 유스케이스를 하나의 데이터 기반 위에서 확산하는 운영 방식, 그리고 현장 인력의 역량 개발이다. 또 산업용 소프트웨어 업계 전반에서는 MES·PLM·ERP와 생성형 AI를 연결하는 "산업용 AI 플랫폼"과 코파일럿 기능을 내놓는 흐름이 뚜렷하다.

이런 흐름은 참고가 되지만, 이 장의 사례가 보여 주듯 플랫폼이 우리 회사의 고장코드나 이슈 카드를 대신 정해 주지는 않는다. 어떤 플랫폼을 고르든 17장의 가시화·표준화 단계는 우리가 해야 한다.

우리 회사 사례로 옮길 때 체크리스트

• 우리 업무의 "1건"은 무엇인가? (클레임 1건, 정비 1건, 공지 1건 …) 그 1건의 필드를 적을 수 있는가?
• 그 1건을 다른 시스템과 연결할 정준 ID(LOT, 설비 ID, 품번)가 있는가?
• 대응 흐름이 하나로 정해져 있는가, 담당자마다 다른가?
• AI가 틀렸을 때 누가, 어느 시점에 알아챌 수 있는가?
• 시작 전 기준값을 쟀는가? 측정 정의를 문서로 남겼는가?
• 현업 주인(팀장·파트장)이 이름으로 정해져 있는가?

이 체크리스트를 우리 팀 계획으로 바꾸는 작업은 다음 장 19장 플레이북에서 한다.