DX와 AX는 무엇이 다른가 — 제조업 기준으로
요즘 AX라는 말이 부쩍 늘었습니다. DX는 이제 낡은 말처럼 취급되기도 합니다.
그런데 제조 현장의 사정은 좀 다릅니다. DX가 끝난 곳이 많지 않습니다. 시스템은 도입했지만 BOM은 여전히 엑셀로 만들어지고, 실적은 수기로 적었다가 나중에 입력됩니다. 그 상태에서 AX 이야기가 밀려옵니다.
그래서 두 단어를 구분하는 일이 용어 정리가 아니라 실무 판단의 문제가 됩니다. 무엇을 먼저 해야 하는지가 여기서 갈립니다.
용어부터 짧게
DX(Digital Transformation)는 종이와 사람의 기억으로 돌아가던 일을 데이터로 옮기는 것입니다. ERP, MES, PLM 도입이 여기에 해당합니다.
AX(AI Transformation)는 그 데이터를 가지고 AI가 일의 일부를 맡는 것입니다.
여기까지는 어느 자료에나 있는 설명입니다. 문제는 이 정의가 현장에서 판단할 때 별로 도움이 안 된다는 것입니다.
실질적인 경계는 '판단을 누가 하는가'입니다
DX는 사람이 판단하도록 데이터를 보여줍니다. 대시보드를 만들고, 리포트를 뽑고, 현황을 화면에 띄웁니다. 판단은 그것을 보는 사람이 합니다.
AX는 판단까지 합니다. 그리고 경우에 따라 실행도 합니다.
설비 데이터로 예를 들면 이렇게 갈립니다.
- DX — 진동값 추이 그래프를 보여줍니다. 담당자가 보고 "슬슬 봐야 하나" 판단합니다.
- AX — "3번 설비 베어링, 3주 내 점검 필요"라고 말합니다. 판단이 결과물로 나옵니다.
같은 데이터, 다른 산출물입니다. DX는 데이터를 보는 훈련을 요구했고, AX는 기계의 판단을 어디까지 믿을지 정하는 일을 요구합니다. 후자가 훨씬 어렵습니다.
AX는 DX가 남긴 데이터를 먹고 자랍니다
AI는 없는 데이터로 판단하지 못합니다. 설비 이력이 없으면 예측정비를 못 하고, 불량 데이터가 정리되어 있지 않으면 품질 예측을 못 합니다. 재고 정확도가 70%인 상태에서 AI에게 발주를 맡기면, 틀린 판단이 더 빠르게 나올 뿐입니다.
이것이 "DX 건너뛰고 AX로 가자"가 위험한 이유입니다. AX는 DX의 다음 단계라기보다, DX가 만들어놓은 데이터를 재료로 쓰는 다른 층입니다. 재료가 없으면 층을 올릴 수 없습니다.
그런데 전부 기다려야 하는 것은 아닙니다
지금의 생성형 AI는 정형 데이터가 아니어도 다룹니다. 표와 코드값만 읽던 이전 세대와 다릅니다. 문서, 도면, 메일, 회의록, 사양서처럼 사람이 읽던 것을 읽습니다.
BOM이 엑셀로 만들어지고 메일로 넘어오는 회사를 생각해봅시다. DX 관점에서 이것은 미완성입니다. 데이터가 시스템 밖에 있으니까요.
그런데 AX 관점에서 보면, 그 엑셀과 메일과 도면은 이미 존재하는 재료입니다. 20년치 사양서와 견적서와 설계 변경 메일이 사내에 쌓여 있습니다. 아무도 못 찾아서 안 쓰이고 있을 뿐입니다.
시스템을 다 정비한 다음에야 AI를 시작할 수 있는 것이 아닙니다. 정리되지 않은 자료를 찾을 수 있게 만드는 일부터 시작할 수 있고, 이 일은 DX 진척도와 거의 무관하게 착수됩니다. 오히려 정리가 안 된 회사일수록 효과가 큽니다.
AX는 투자가 아니라 비용으로 들어왔습니다
DX는 처음부터 투자였습니다. 라이선스 몇 명분, 서버 몇 대, 구축 용역 몇 개월. 견적서가 나오고 품의를 올리고 승인을 받습니다. 투자 대상이 명확하고 심의를 거칩니다.
AX는 그렇게 들어오지 않았습니다. 문서 초안 작성, 회의록 정리 같은 일로 시작했습니다. 특정한 투자 대상이라기보다 비용 측면에서 쓰이기 시작했습니다. 투자 심의를 타지 않았고 ROI를 계산하지도 않았습니다.
그래서 확산이 빨랐습니다. 부서마다 반복적이고 단순한 업무를 대상으로 Agent를 만들어 쓰기 시작합니다. 이것도 부서가 자체적으로 결정할 수 있는 범위입니다.
문제는 그다음입니다.
세 번째 단계에서 성격이 바뀝니다
- 1단계 · 문서 작성과 회의록 정리 — 비용으로 처리되고, 개인이 그냥 씁니다.
- 2단계 · 부서별 반복·단순 업무 Agent — 부서가 자체적으로 만들어 씁니다.
- 3단계 · ERP 등 기간계 시스템 연계 — 여기서 막힙니다.
1단계와 2단계가 쉬웠던 이유는 틀려도 되기 때문입니다. 문서 초안이 엉성하면 고쳐 쓰고, 회의록이 부정확하면 사람이 손봅니다. 결과가 시스템에 남지 않습니다. 그래서 권한도 책임도 따지지 않았습니다.
기간계 연계는 다릅니다. ERP와 연결되는 순간 데이터를 읽는 것으로 끝나지 않고 쓰게 됩니다. 틀리면 실물이 움직입니다. 발주가 나가고 재고가 변하고 작업지시가 떨어집니다.
그러면 그때까지 묻지 않았던 것들이 한꺼번에 요구됩니다. 어느 데이터에 접근을 허용할지, 어느 판단까지 맡길지, 틀렸을 때 누가 책임질지. 그리고 기간계가 애초에 제대로 작동하고 있는지.
여기서 앞의 이야기로 돌아옵니다. 1단계와 2단계는 DX와 거의 무관하게 굴러갔지만, 3단계는 DX가 되어 있어야 성립합니다. 부서 Agent는 잘 쓰이는데 기간계 연계에서 막히는 이유가 여기에 있습니다.
정리
- 하는 일 — DX는 데이터를 모아 보여주고, AX는 판단하고 실행합니다.
- 판단 주체 — DX는 사람, AX는 AI가 판단하고 사람이 확인합니다.
- 필요한 것 — DX는 시스템과 입력 규칙, AX는 데이터와 업무 정의입니다.
- 돈이 드는 방식 — DX는 처음부터 투자 심의를 거치고, AX는 비용으로 시작해 나중에 투자가 됩니다.
- 성과 확인 — DX는 화면이 뜨면 끝이고, AX는 판단이 맞아야 끝입니다.
DX와 AX는 순서라기보다 층입니다. 아래층이 부실하면 위층을 올리기 어렵고, 다만 아래층 없이도 세울 수 있는 부분이 일부 있습니다. 어디가 그 부분인지 아는 것이 지금 제조업에서 필요한 판단입니다.
다음 글에서는 세 번째 단계의 벽을 구체적으로 다뤄보겠습니다. 부서 Agent는 잘 쓰이는데 기간계 연계에서는 무엇이 걸리는지, 기준정보와 코드 체계 문제부터 짚어보려 합니다.
댓글
댓글 쓰기