AI가 실패를 만드는 게 아니라, 실패한 프로세스가 AI를 망친다

ceo-guide-7-esg-key-points

AI를 넣었는데, 왜 기대만큼 좋아지지 않을까

많은 제조 기업이 이미 AI를 도입해봤습니다. 그리고 누구나 한 번쯤 이런 경험을 했을 겁니다. "시장 리포트 하나 요약해줘"라고 물으면 AI는 순식간에 답을 내놓습니다. 그런데 "우리 전체 공정에서 지연의 원인이 뭔지 파악해줘"라고 물으면, 이야기가 달라집니다. 데이터베이스를 연결하고 메타데이터까지 다 붙여놨는데도 답이 시원하게 나오지 않는 경우가 많습니다.

이유는 간단합니다. AI는 프로세스가 좋으면 그 좋은 흐름을 더 빠르고 정확하게 증폭시킵니다. 하지만 프로세스가 꼬여 있으면, AI는 그 꼬인 상태를 더 빠르게, 더 크게 증폭시킬 뿐입니다. AI를 투입하기 전에 진짜로 물어야 할 질문은 "우리가 어떤 AI 모델을 쓸 것인가"가 아니라, **"우리의 프로세스가 AI가 이해할 수 있는 형태로 운영되고 있는가"**입니다.

시스템은 다 깔았는데, 왜 여전히 따로 놀고 있을까

최근 한 조사에 따르면, 제조 현장의 MES 도입률은 이미 상당히 높은 수준에 이르렀습니다. 그런데 문제는 그다음입니다. MES, ERP, CRM 같은 시스템들이 도입은 됐지만 정작 서로 연결되지 않은 경우가 많습니다. 실제로 조사해보면 시스템을 갖춘 기업 네 곳 중 실제로 데이터가 연결된 곳은 한 곳도 채 안 되는 수준이라는 결과가 나옵니다.

왜 이게 문제가 될까요? AI 시대에 중요한 건 결국 '맥락(context)'입니다. 내가 수주한 물량이 언제쯤 작업이 진행되고 언제 납품될 수 있는지에 답하려면, MES와 ERP와 CRM의 데이터가 하나의 흐름으로 이어져야 합니다. 시스템이 따로 놀면, 그 위에 아무리 좋은 AI를 얹어도 "맥락 있는 답"은 나올 수 없습니다. 데이터는 있는데 이야기가 안 되는 상태, 이것이 바로 많은 기업이 AI 도입 후에도 기대만큼의 효과를 보지 못하는 근본 원인입니다.

눈에 보이는 병목이 진짜 병목이 아닐 수 있다

프로세스가 AI-ready한지 점검해야 한다는 말이 추상적으로 들릴 수 있으니, 실제 현장 사례로 풀어보겠습니다.

어떤 공정에서 유독 오래 걸리는 작업이 있었습니다. 케이스 시간과 이벤트 시간을 분석해보니 '사상 디버링'이라는 작업이 눈에 띄게 길게 나타났고, 관련 워크센터인 '가공 사상' 공정에서도 가장 긴 시간이 소요되는 것으로 보였습니다. 여기까지만 보면 누구나 "사상 디버링 공정이 병목이다"라고 결론 내리기 쉽습니다.

하지만 루트코즈 분석을 더 깊이 들어가 보니 결과는 달랐습니다. 70일 이상 걸리는 케이스들을 워크센터와 액티비티 간의 관계로 다시 뜯어보니, 사상 디버링 자체는 지연과 거의 무관한(뉴트럴한) 공정이었습니다. 실제 원인은 따로 있었습니다. 가공 1라인과 가공 5라인에 작업이 적체되는 현상이 지연과 훨씬 강한 연관성을 보였고, 개선이 필요한 지점은 바로 그곳이었습니다.

이 사례가 말해주는 것은 명확합니다. 직관으로 짚은 병목과, 데이터가 실제로 말하는 병목은 다를 수 있습니다. 그리고 만약 AI에게 "이 공정 최적화해줘"라고 시켰는데 그 AI가 참고하는 데이터가 이 관계성을 담고 있지 않다면, AI는 아주 그럴듯하지만 틀린 답을 빠르게 만들어낼 뿐입니다. 나쁜 프로세스 이해가 나쁜 AI 답변으로, 그것도 아주 빠르게 증폭되는 순간입니다.

"AI-ready"란 무엇을 의미하는가

여기서 AI-ready하다는 것은 새로운 시스템을 또 하나 만드는 것을 의미하지 않습니다. 이미 현장에는 공장을 통제하는 ERP와 MES가 있고, KPI를 보여주는 BI가 있고, 설비를 모니터링하는 IoT도 갖춰져 있는 경우가 많습니다. 필요한 건 새 시스템이 아니라, 있는 데이터를 실제 작업 흐름 순서대로 연결하는 것입니다.

이렇게 연결이 되면 공정 시스템 간의 작업 흐름이 복원되고, 그 흐름 위에서 작업 시간과 대기 시간을 정확히 확인할 수 있으며, 비로소 이 데이터를 근거로 한 분석과 AI 활용이 가능해집니다. 다시 말해 AI-ready한 프로세스란, 실제 업무 프로세스가 데이터로 실증 가능한 모델로 복원되어 있는 상태를 뜻합니다. 이 복원된 모델이 있어야, 그 위에 AI를 얹었을 때 "일반 데이터베이스에 연결한 AI"가 아니라 "실제 프로세스 모델에 근거해 답하는 AI"가 될 수 있습니다.

결론: AI를 넣기 전에 먼저 던져야 할 질문

AI 프로젝트를 계획하고 있다면, 모델 선택이나 도구 비교에 앞서 다음 질문부터 던져볼 필요가 있습니다.

  • 우리 시스템들(ERP, MES, CRM, IoT)은 서로 연결되어 하나의 작업 흐름으로 복원 가능한가, 아니면 각자 따로 데이터를 쌓고만 있는가?

  • 우리가 병목이라고 '알고 있는' 지점은 실제 데이터로 검증된 것인가, 아니면 경험과 직관에 의존한 추정인가?

  • 우리가 AI에게 물었을 때, 그 AI는 실제 프로세스 모델에 근거해 답하는가, 아니면 단순히 연결된 데이터베이스를 훑어 그럴듯한 답을 만들어내고 있는가?

이 질문들에 자신 있게 답할 수 없다면, AI 도입 순서가 잘못됐을 가능성이 높습니다. AI는 프로세스를 대신 고쳐주는 도구가 아니라, 이미 있는 프로세스를 증폭시키는 도구입니다. 좋은 프로세스 위에서는 AI가 강력한 지렛대가 되지만, 꼬인 프로세스 위에서는 그 꼬임을 더 빠르고 더 크게 만드는 촉매가 될 뿐입니다. 순서는 언제나 같습니다 — 프로세스를 먼저 눈에 보이게 만들고, 그다음 AI를 태운다.