"우리 업무를 분석해서 자동화 설계해보자."
이 말로 시작하는 AX 프로젝트들이 있다.
몇 달 뒤 결과는 대개 비슷하다.
시스템은 완성됐는데 현업은 쓰지 않는다.
왜 이 패턴이 반복되는가
AX 대상 업무는 '고약한 문제(Wicked Problem)'다.
해보기 전까지는 진짜 병목이 어디인지 알 수 없다.
사람의 습관, 예외 케이스, 책임 구조가 계속 튀어나오며 계획을 흔든다.
그런데 많은 조직은 폭포수 방식으로 접근한다.
"처음에 모든 걸 정의할 수 있다"는 가정 위에서 출발한다.
6개월 동안 요구사항을 정리하고, 설계하고, 개발하고, 검수한다.
그리고 오픈하면 현업이 "이건 우리가 쓰는 방식이 아닌데요"라고 말한다.
폭포수 방식은 완성도를 올리는 구조다.
AX는 학습 속도를 올리는 게임이다.
이 둘이 충돌하면 언제나 AX가 진다.
유령 시스템이 만들어지는 순서
- 현업 인터뷰를 통해 업무 프로세스를 정의한다.
- 그 프로세스를 자동화하는 시스템을 설계한다.
- 개발을 완료하고 현업에 인계한다.
- 현업은 기존 방식을 유지한다. 시스템은 로그인 기록도 없다.
이 과정에서 무엇이 잘못됐을까.
인터뷰할 때 현업이 말한 프로세스는 '공식 프로세스'다.
실제로 업무가 처리되는 방식은 다르다.
비공식 예외 처리, 팀 간 구두 협의, 시스템 바깥의 판단들.
이것들은 인터뷰로는 잡히지 않는다. 실제로 써봐야 나온다.
올바른 접근: 작은 자동화에서 시작하기
AX는 거대한 설계가 아니라 작은 시도에서 출발해야 한다.
1단계: 작은 자동화를 실제 업무에 붙인다.
2단계: 현업의 반응을 관찰한다.
3단계: 문제를 다시 정의한다.
4단계: 반복한다.
이 과정에서 조직이 얻는 것은 단순히 자동화된 업무가 아니다.
'문제를 정의하는 속도'를 높이는 역량이다.
자동화는 결과물이 아니라 학습을 위한 도구가 된다.
완성도 vs 학습 속도
폭포수 방식이 나쁜 것은 아니다.
소프트웨어 품질을 높이거나 안정적인 인프라를 구축할 때는 효과적이다.
문제는 AX에 그 방식을 그대로 적용한다는 것이다.
AX의 성공 기준은 기술적 완성도가 아니다.
얼마나 빠르게 문제를 재정의하고 개선할 수 있는지다.
완성도 높은 시스템이 아무도 안 쓰는 유령이 되는 것보다, 거칠어도 매주 현업과 함께 개선되는 시스템이 낫다.
결론
AX는 "업무를 자동화하는 프로젝트"가 아니다.
조직이 문제를 정의하고 학습하는 능력을 키우는 과정이다.
작은 자동화부터 시작해, 현업과 함께 배우고, 반복하며 점차 확장하는 접근만이 유령 시스템을 만들지 않는다.
6개월짜리 완벽한 자동화보다, 2주마다 현업과 함께 개선하는 작은 자동화가 더 멀리 간다.