Automation Readiness Framework
자동화를 하면 일이 줄어들 것이라고 단정하려는 글은 아닙니다. 특정 솔루션을 도입하면 곧바로 성과가 난다고 말하려는 것도 아닙니다. 자동화는 기술의 문제가 아니라 설계의 문제라는 점을 분명히 하고 싶습니다. 질문은 이것입니다. 우리는 자동화를 “도입”하려는 것입니까, 아니면 “설계”하려는 것입니까?
현장에서 자주 보는 장면이 있습니다. 대표는 말합니다. “사람이 부족합니다.” 팀장은 말합니다. “업무가 너무 많습니다.” 그래서 자동화를 검토합니다. 그런데 자동화 이후에도 야근은 줄지 않습니다. 왜 이런 일이 반복될까요?
자동화는 결과가 아니라 구조의 산물입니다. 구조가 정리되지 않은 상태에서 자동화를 시도하면, 기존의 비효율을 더 빠르게 반복하게 됩니다. 그래서 저는 자동화 이전에 네 단계를 반드시 점검하자고 말합니다. 순서를 지켜야 합니다. 이 네 단계를 건너뛰면 기술은 도입되지만 성과는 남지 않습니다.
1단계: 문제를 수치로 정의한다
자동화를 고민하는 기업에 가장 먼저 묻는 질문은 이것입니다.
“정확히 무엇이 문제입니까?”
대부분은 이렇게 답합니다.
“업무가 많습니다.”
“처리가 느립니다.”
“오류가 자주 납니다.”
이 표현으로는 자동화를 설계할 수 없습니다. 문제는 반드시 수치로 정의되어야 합니다.
예를 들어 직원 11명이 근무하는 B2B 납품 기업을 생각해보겠습니다. 이 회사는 거래처 주문 확인과 발주 과정이 지연된다고 판단해 자동화 시스템 도입을 검토했습니다. 그러나 데이터를 확인해보니 평균 주문 처리 시간은 2시간 40분이었습니다. 문제는 특정 거래처 3곳에서만 평균 6시간 이상 지연이 발생하고 있었습니다.
그렇다면 문제는 “전체 주문이 느리다”가 아닙니다. 정확한 정의는 “특정 거래처 3곳의 주문 처리 시간이 평균 6시간으로, 전체 평균 대비 2.3배 지연된다”입니다.
문제를 이렇게 정의하면 질문이 달라집니다.
모든 주문을 자동화해야 합니까?
아니면 특정 조건에 해당하는 주문만 구조를 바꾸면 됩니까?
수치 정의 없이 자동화를 시작하면, 효과 측정이 불가능합니다. 자동화 이후에도 “좀 빨라진 것 같다”는 감각만 남습니다. 감각은 판단 기준이 될 수 없습니다.
문제를 정의할 때 최소한 다음 세 가지는 명확해야 합니다.
- 발생 빈도 (하루 몇 건, 주 몇 회)
- 평균 소요 시간 (분 단위로)
- 비용 영향 (인건비, 지연 비용 등)
이 세 가지가 숫자로 정리되지 않으면 자동화 설계는 출발할 수 없습니다.
2단계: 현재 업무 흐름을 시각화한다
문제가 수치로 정의되었다면, 그 문제가 발생하는 흐름을 그려야 합니다. 자동화는 단일 작업이 아니라 흐름을 대상으로 합니다.
같은 기업 사례를 이어가 보겠습니다. 주문 처리 과정을 단계별로 나누어보니 다음과 같았습니다.
- 이메일 주문 접수
- 엑셀 주문서 입력
- 재고 확인
- 거래처 조건 검토
- 발주 승인
- 출고 지시
- 송장 입력
총 7단계였습니다.
각 단계의 평균 소요 시간을 측정해보니 재고 확인은 5분, 승인 단계는 3분이었지만, 엑셀 입력과 송장 입력에서 각각 12분 이상이 소요되었습니다. 이유는 데이터 복사와 중복 입력 때문이었습니다.
문제는 승인 속도가 아니었습니다. 데이터 이동이 병목이었습니다.
업무 흐름을 시각화하지 않으면 우리는 가장 눈에 띄는 지점만 보게 됩니다. 그러나 병목은 눈에 잘 보이지 않는 구간에 숨어 있습니다. 승인 지연처럼 보였지만, 실제로는 입력 구조가 비효율이었습니다.
업무 흐름을 시각화할 때 다음 항목은 반드시 포함해야 합니다.
- 단계 수
- 각 단계 평균 시간
- 단계별 책임자
- 입력 데이터 형태 (이메일, 엑셀, ERP 등)
- 출력 데이터 형태
이 과정을 거치면 “어디를 자동화해야 하는지”가 보이기 시작합니다. 흐름을 그리지 않은 자동화는 방향 없는 시도입니다.
3단계: 반복 가능한 구간을 분리한다
모든 업무를 자동화하려는 시도는 위험합니다. 자동화는 반복성과 규칙성을 전제로 합니다.
위 사례에서 7단계 중 4단계는 반복적이고 규칙 기반이었습니다. 주문서 입력, 재고 확인, 송장 생성, 데이터 전송은 조건이 명확했습니다. 반면 거래처 조건 검토는 예외가 많았고 담당자의 판단이 필요했습니다.
전체 업무 중 약 65%는 반복 구간이었고, 35%는 판단 구간이었습니다.
많은 기업이 이 구분을 하지 않은 채 자동화를 시도합니다. 그 결과 예외 상황에서 시스템이 멈추거나, 오히려 수작업이 늘어납니다.
반복 구간을 분리할 때 다음 기준을 사용합니다.
- 조건이 명확한가?
- 예외 발생 비율은 몇 %인가?
- 동일한 방식으로 3개월 이상 반복되었는가?
예외 발생 비율이 20% 이상이면 자동화 대상이 되기 어렵습니다. (※ 업종별 평균 예외 비율은 별도 조사 필요)
자동화는 “가능한 영역”을 정확히 자르는 작업입니다. 범위를 줄일수록 성공 확률은 높아집니다.
4단계: 자동화 우선순위를 결정한다
반복 구간을 분리했다고 해서 모두 동시에 자동화할 필요는 없습니다. 우선순위를 정해야 합니다.
우선순위는 감각이 아니라 계산으로 결정합니다.
위 기업 사례에서 반복 구간 4개를 비교했습니다.
- A 작업: 하루 180건, 건당 3분
- B 작업: 하루 40건, 건당 15분
- C 작업: 하루 15건, 건당 25분
- D 작업: 하루 10건, 건당 40분
계산해보면 A 작업은 하루 540분, B 작업은 600분, C 작업은 375분, D 작업은 400분이 소요됩니다.
가장 큰 절감 효과는 B 작업이었습니다. 빈도와 시간의 곱이 가장 컸기 때문입니다.
우선순위는 다음 세 지표로 점수화합니다.
- 반복 빈도
- 소요 시간
- 오류 발생률
이 세 지표를 5점 척도로 평가해 합산하면 객관적인 순서가 나옵니다.
자동화는 기술 프로젝트가 아니라 자원 배분 전략입니다. 비용 대비 효과를 계산하지 않으면 “편해 보이는 작업”부터 건드리게 됩니다.
사람들이 흔히 하는 착각
자동화를 시작하면 인력이 줄어들 것이라고 기대합니다. 그러나 초기 1~2개월은 오히려 시간이 더 필요합니다. 설계, 테스트, 오류 수정 과정이 필수입니다.
또 다른 착각은 “툴이 해결해 줄 것”이라는 기대입니다. 실제로는 툴보다 프로세스가 먼저입니다. 프로세스가 정리되어 있으면 어떤 툴을 써도 작동합니다. 프로세스가 불명확하면 어떤 툴을 써도 혼란이 반복됩니다.
구조로 다시 정리하면
자동화 이전 점검은 다음 네 단계입니다.
- 문제를 수치로 정의한다.
- 업무 흐름을 시각화한다.
- 반복 구간을 분리한다.
- 비용 대비 효과로 우선순위를 정한다.
이 네 단계를 거치면 자동화 범위가 명확해집니다. 범위가 명확해지면 투자 규모가 줄고, 실패 확률도 낮아집니다.
자동화는 기술 도입이 아니라 설계 과정입니다. 우리는 무엇을 줄이려 합니까? 시간입니까, 오류입니까, 인건비입니까? 그 목표는 숫자로 표현되어 있습니까?
시스템을 찾기 전에 종이에 네 단계를 적어보십시오. 흐름이 그려지지 않는다면 아직 자동화를 시작할 시점이 아닐 수 있습니다.
AI현장감독 이동주는 AI 도입 과정에서 반복되는 구조 문제를 연구한다.
AI adoption failure를 기술 문제가 아닌 설계와 흐름의 문제로 바라본다.
Fieldbly에서 현장 사례를 기반으로 정리하고 있다.
(homepage) http://www.fieldbly.com