기술보다 먼저 점검해야 할 것은 ‘업무 흐름’이다(Workflow Before AI)
AI 도입 방법이나 도구 비교를 다루려는 글은 아니다. 어떤 모델이 더 뛰어난지, 어떤 솔루션이 저렴한지 이야기하려는 것도 아니다. 이 글은 그 이전 단계에 대한 이야기다. 많은 조직이 묻는다. “어떤 AI를 써야 합니까?” 그런데 더 먼저 물어야 할 질문이 있다. 지금 우리 업무는 어떤 흐름으로 돌아가고 있는가?
나는 AI 도입을 기술 프로젝트로 보지 않는다. 구조 점검 작업으로 본다. 기술은 교체할 수 있지만, 업무 흐름은 조직의 사고방식을 반영한다. 흐름이 정리되지 않은 상태에서 자동화를 시도하면, 문제는 사라지지 않고 더 빠르게 반복될 뿐이다. AI는 혼란을 해결하지 않는다. 혼란을 확대할 수도 있다.
한 중견 제조기업을 예로 들어보자. 직원 120명 규모의 부품 가공 업체였다. 대표는 생산성 개선을 위해 AI 기반 보고서 자동화와 데이터 분석 시스템을 도입하고 싶어 했다. 영업팀은 매주 엑셀로 실적을 정리했고, 생산팀은 수기 기록 후 ERP에 다시 입력했다. 경영진은 “데이터가 늦게 올라온다”고 불만이 있었다. 그래서 AI 대시보드를 만들자는 제안이 나왔다.

도입 전, 우리는 먼저 업무 흐름을 그렸다. 그 결과 세 가지가 드러났다.
- 동일 데이터를 3번 입력하고 있었다.
- 보고서 형식은 부서마다 달랐다.
- KPI 정의가 팀마다 달랐다.
AI가 해결해야 할 문제는 ‘분석 속도’가 아니었다. 데이터 생성 구조가 일관되지 않은 것이 핵심 문제였다.

이 지점에서 흔히 발생하는 착각이 있다.
첫째, 도구를 바꾸면 문제가 해결된다고 생각한다. 그러나 입력 구조가 정리되지 않으면 어떤 도구를 써도 결과는 달라지지 않는다.
둘째, 데이터가 많으면 자동으로 통찰이 생긴다고 믿는다. 하지만 기준이 다르면 비교가 불가능하다.
셋째, 자동화는 속도 문제라고 본다. 실제로는 정의의 문제다. 무엇을 측정하고, 왜 측정하는가가 먼저다.
AI 도입 전에 반드시 해야 할 한 가지는 명확하다. 업무 흐름을 구조화하는 것이다. 이것은 추상적인 말이 아니다. 다음 네 단계로 정리할 수 있다.
1. 업무 단계 시각화
업무를 시작부터 종료까지 한 장에 그린다. 누가, 언제, 무엇을 입력하는지 표시한다.
2. 데이터 정의 통일
같은 단어가 같은 의미로 사용되는지 점검한다. 매출, 수주, 출고의 정의가 다르면 자동화는 불가능하다.

3. 중복 제거
동일 정보가 몇 번 입력되는지 확인한다. 2회 이상 반복된다면 구조 문제다.

4. 의사결정 연결
그 데이터가 실제로 어떤 의사결정에 사용되는지 확인한다. 사용되지 않는 수치는 자동화 대상이 아니다.
앞선 제조기업은 이 네 단계를 거친 후에야 자동화를 시작했다. 결과적으로 AI 대시보드는 6개월 뒤에 도입되었다. 그 사이에 먼저 한 일은 보고서 양식 통합과 KPI 재정의였다. 대시보드는 그 이후에 자연스럽게 작동했다. AI가 성과를 만든 것이 아니라, 정리된 구조가 AI를 제대로 작동하게 한 것이다.

이 과정을 통해 확인한 점은 단순하다. AI 도입의 실패는 기술 역량 부족 때문이 아니라, 업무 구조가 합의되지 않은 상태에서 시작하기 때문이라는 것이다. 기술은 가속 장치다. 방향이 틀리면 더 빠르게 벗어난다.
그렇다면 지금 점검해야 할 것은 무엇일까?
- 우리 조직의 업무 흐름은 한 장으로 설명 가능한가?
- 같은 데이터를 몇 번 입력하고 있는가?
- KPI 정의가 팀 간에 일치하는가?
- 자동화 후 줄어들 시간이 명확히 계산되는가?
- 자동화가 아니라 ‘업무 재정의’가 필요한 부분은 없는가?
AI 도입은 도구 선택이 아니라 구조 선택이다. 어떤 시스템을 쓰느냐보다, 어떤 흐름 위에 올릴 것인가가 먼저다. 기술을 도입하기 전에 이 질문을 충분히 점검했다면, 이미 절반은 정리된 상태다.
지금 검토하고 있는 AI 프로젝트는, 현재의 업무 흐름을 그대로 빠르게 만드는 일인가. 아니면 먼저 흐름을 다시 정의하는 일인가. 그 차이를 구분하고 있는지 스스로에게 한 번 물어볼 필요가 있다.

AI현장감독 이동주는 AI 도입 과정에서 반복되는 구조 문제를 연구한다.
AI adoption failure를 기술 문제가 아닌 설계와 흐름의 문제로 바라본다.
Fieldbly에서 현장 사례를 기반으로 정리하고 있다.
(homepage) http://www.fieldbly.com