3개월 전 그린 워크플로우가, 아무도 안 보는 다이어그램이 된 이유
얼마 전 한 제조 기업의 회의실에 앉았을 때, 화이트보드 한쪽에 마커 자국이 흐릿하게 남아 있었습니다. "저건 자동화 파일럿 시작할 때 그린 프로세스 지도예요"라는 설명이 이어졌고, 그 다음 문장이 오래 남았습니다. "그런데 담당자가 바뀌고 나서, 저희 팀에서 아무도 안 봐요."
지난 6회에서는 LLM을 결합한 자동화의 보안·거버넌스를 다뤘습니다. 오늘은 한 걸음 뒤로 물러납니다. 애초에 거버넌스가 얹힐 자리 자체가 사라져 버리는 프로젝트들 — 자동화 도입이 무너지는 다섯 가지 패턴을 정리해 봅니다.
매킨지·언스트앤영·가트너의 여러 조사에서 1세대 RPA 프로젝트의 실패율은 30~50% 사이로 보고됩니다. 가트너는 최근 2027년 말까지 에이전틱 AI 프로젝트의 40% 이상이 취소될 것이라고 예측했습니다. 원인은 대부분 기술이 아닙니다. 아래 다섯 가지 중 하나, 혹은 두세 개가 겹친 경우가 대부분입니다.
패턴 1. 도구를 먼저 사고, 프로세스는 나중에 정리한다
가장 흔한 패턴입니다. 임원 자리에서 "옆 회사가 UiPath를 도입했다더라", "요즘은 n8n이 대세라던데" 같은 이야기가 나오고, 곧바로 라이선스 견적부터 뽑는 흐름입니다. 정작 어떤 업무를 자동화할지는 견적서를 받은 다음에 정해집니다.
현장에서 관측되는 신호는 몇 가지 있습니다. 킥오프 자리에서 "일단 툴부터 깔고 뭘 자동화할지 봅시다"라는 말이 나올 때. 벤더 데모를 본 임원이 그 자리에서 "이거 좋네, 도입합시다"라고 결정할 때. 대상 업무가 문서로 정리된 적 없는데도 도입 일정이 먼저 잡혀 있을 때. 매킨지의 최근 자료에 따르면, 프로세스 자체가 정돈되지 않은 상태에서 자동화를 얹은 사례는 73%가 목표 미달로 끝났습니다.
회피 체크리스트는 단순합니다. 첫째, 자동화 후보 프로세스를 최소 세 개 이상 종이 위에 지도로 그립니다. 둘째, 각 프로세스의 월 반복 횟수와 소요 시간을 실측합니다 — 담당자의 감이 아닌 실제 숫자로. 셋째, 이 두 자료가 준비되기 전까지 도구 견적을 받지 않습니다.
패턴 2. 결정은 위에서, 사용은 아래에서 — 그런데 아래는 회의에 없었다
두 번째 패턴은 조금 더 은밀합니다. 파일럿 결정과 벤더 미팅, 예산 승인까지 전부 부서장·임원 선에서 마무리되고, 실제로 매일 그 자동화를 쓸 팀은 도입 완료 시점에서야 통보를 받는 경우입니다.
제가 몇 년 사이 실제로 들었던 말을 옮겨 봅니다. "저희 팀은 그거 안 씁니다. 저희 방식이 있어요." "쓰라니까 쓰긴 하는데, 옆에 엑셀 하나 더 켜놓고 이중 입력해요." 도구가 나쁜 게 아니라, 그 도구가 자기 손에 맞도록 조정될 기회를 놓친 겁니다. 일본 조사 기관 Gron의 2026년 DX 실패 조사에서도 실패 원인 상위에 "현장 미사용 41%"이 올라 있는데, 한국 중소기업에서도 거의 그대로 재현됩니다.
회피 체크리스트. 첫째, 킥오프 자리에 반드시 그 자동화를 실제로 매일 쓸 담당자를 최소 한 명 앉힙니다 — 부서장이 아니라 실무자. 둘째, 파일럿 기간 중 주 1회, 30분이라도 사용성 리뷰 미팅을 넣습니다. 셋째, 실무자가 "이건 이렇게 바꿔야 쓸 만하다"고 말한 항목을 별도로 기록합니다. 이 기록이 두 번째 이터레이션의 백로그가 됩니다.
패턴 3. "효율화되면 좋겠죠" — 지표 없이 시작한 프로젝트
세 번째 패턴은 도입 4개월쯤 지났을 때 드러납니다. 임원이 "그래서 얼마나 좋아졌어?"라고 물었을 때, 담당자가 답을 못하는 상황입니다.
신호는 도입 초기부터 나옵니다. 성공 기준을 물어보면 "업무가 편해지는 거요" 정도의 추상적 답이 돌아오는 경우. 자동화 전의 baseline 소요 시간·처리 건수를 아무도 측정하지 않은 경우. KPI가 10개, 15개로 늘어져 있어서 결국 아무도 안 보게 된 경우.
회피 체크리스트는 세 가지로 좁힙니다. 도입 전에 대상 업무의 baseline 소요 시간과 건수를 반드시 측정합니다. KPI는 세 개 이하로 좁힙니다 — 예: 처리 시간 단축, 오류 건수 감소, 담당자의 주간 재작업 시간. 매월 첫째 주에 KPI 리뷰를 30분씩 캘린더에 고정합니다. 지표는 만들어 두는 게 아니라 매달 보는 자리가 있어야 살아 있습니다.
패턴 4. 감사·롤백·권한이 없는 자동화
네 번째 패턴은 사고가 나기 전까지 아무도 문제라고 느끼지 않습니다. 그러다 한 번 데이터가 잘못 나가거나, 잘못된 이메일이 발송되거나, 봇 계정이 이상한 파일을 건드리기 시작하면, 그때야 "우리 이거 어떻게 되돌리지?"라는 질문이 나옵니다.
자주 보는 신호. LLM 프롬프트에 고객 이름·전화번호·주민번호 뒷자리가 마스킹 없이 들어가는 경우. 자동화 봇 계정이 관리자 권한을 그대로 갖고 있는 경우. 실행 로그가 남지 않아, 사고 후에 "어제 몇 시에 뭘 처리했는지" 재구성이 안 되는 경우.
지난 회에서 정리한 감사 로그·PII 마스킹·가드레일 체계가 없으면, 이 네 번째 패턴은 도입 3개월 안에 반드시 재현됩니다. 자세한 실행 항목은 LLM 결합 자동화의 보안·거버넌스 편을 다시 참고하시길 권합니다. 여기서는 요점만 정리합니다. 최소 권한 원칙으로 봇 계정 권한을 좁힙니다. 모든 자동화 실행에 감사 로그를 남깁니다 — 최소한 실행 시각·트리거·처리 대상·결과 코드. 그리고 롤백 절차를 문서로 만들어 둡니다. "이 자동화를 오늘 오후 3시에 멈춰야 한다"는 지시가 내려왔을 때, 누가 어떤 스위치를 누를지 사전에 정의되어 있어야 합니다.
패턴 5. 만든 사람이 나가면, 아무도 못 고친다
마지막 패턴은 가장 조용하게 다가옵니다. 도입 첫해에는 잘 돌아갑니다. 만든 담당자가 회사에 있고, 문제가 생기면 그 사람이 바로 손을 봅니다. 문제는 그 담당자가 이직하거나 부서를 옮긴 뒤부터입니다.
어느 유통 기업에서 목격했던 장면입니다. 자동화 도입 담당자가 이직한 뒤, 대상 사이트의 로그인 화면이 개편되면서 스크립트가 멈췄습니다. 남아 있던 팀원 중 누구도 그 스크립트를 수정할 수 없었습니다. 결국 두 달간 담당자가 다시 수기로 처리했고, 그 프로세스는 자동화 이전으로 되돌아갔습니다. IDG의 RPA 실패 조사에서도 "내부 전문 지식 부족"이 최대 실패 원인으로 꼽히는 이유입니다.
회피 체크리스트. 도입 시점부터 운영 담당자를 두 명 이상 지정합니다 — 한 명이 나가도 다른 한 명이 안다는 상태로. 자동화 대상 시스템에 변경이 발생했을 때 알림을 받을 채널을 정합니다(예: 사이트 UI 변경 감지, API 버전 변경 공지 구독). 그리고 도입 산출물에 반드시 최소한의 운영 문서를 포함합니다 — 실행 스케줄, 트리거 조건, 장애 시 연락처. 문서 없이 넘겨받은 자동화는, 넘겨받지 않은 것과 사실상 같습니다.
다섯 개 중 몇 개에 해당하는지, 오늘 30분만 점검해도 됩니다
매킨지가 2026년에 발표한 자료에서, 디지털 전환 예산의 5% 남짓만이 change management — 즉 사람과 프로세스 쪽에 배정된다고 합니다. 권장치는 20~30%입니다. 실패 패턴 다섯 가지가 대부분 기술이 아니라 사람·프로세스·거버넌스 쪽에서 발생하는 이유입니다.
이 다섯 패턴 중 세 개 이상이 겹치는 프로젝트는, 안타깝게도 시작 전에 한 번 멈춰서 재설계하는 편이 결과적으로 더 저렴합니다. 저희 5years+에서 진단을 요청받은 프로젝트 중에도, 도구 도입 직전에 프로세스 지도를 다시 그려 3개월을 아꼈던 경우가 여러 번 있었습니다. 각 항목을 30분씩만 팀 내부에서 점검해 봐도, 3개월 뒤 후회를 상당 부분 줄일 수 있습니다. 자체 점검이 어렵거나 외부 시각이 필요하다면 자동화 도입 진단 상담으로 편하게 문의 주셔도 좋습니다.
다음 8회는 진단에서 PoC, 운영으로 이어지는 실제 실행 플랜을 단계별로 정리합니다. 이 시리즈의 마지막 회차로, 앞선 일곱 편의 논의를 실행 순서 위에 얹어 볼 예정입니다.