분명히 잘 만들었는데, 반년쯤 지나면 아무도 안 쓰는 자동화가 있어요. 버튼을 눌러도 되는데 다들 다시 엑셀을 켜고, 손으로 취합하고, 메일로 돌려요. 시스템은 멀쩡히 돌아가는데 현장에는 안착하지 못한 거예요.
기술이 문제인 경우는 의외로 드물어요. 코드는 잘 짜여 있고 테스트도 통과해요. 그런데도 쓰이지 않아요. 왜 그럴까요? 자동화가 현장에서 외면받는 데는 거의 항상 같은 패턴이 있거든요. 크게 세 가지로 정리해 볼게요.
1. 문제보다 도구를 먼저 고른다
"우리도 RPA 하나 도입해야 하지 않아?"로 시작하는 프로젝트가 있어요. 도구를 먼저 정해놓고, 그 도구로 자동화할 업무를 나중에 찾는 거예요. 순서가 거꾸로예요.
자동화는 모든 업무에 잘 맞지 않아요. 효과를 내는 일에는 공통점이 있거든요.
- 반복 횟수가 많고 주기가 일정해요
- 입력 데이터가 구조화되어 있거나, 구조화할 수 있어요
- 판단 기준이 명확해서 규칙으로 표현할 수 있어요
- 오류가 나도 파급 범위가 제한적이에요
이 조건을 먼저 따져보지 않으면, 자동화 범위가 엉뚱하게 넓어지거나 반대로 너무 좁아져요. 그러면 시스템은 만들어졌는데 실제 업무 흐름과 어긋나요. 며칠에 한 번 쓸까 말까 한 기능에 몇 달치 개발비가 들어가기도 하고요.
도구가 먼저 정해지면 사고가 그 도구 안에 갇혀요. RPA로 해결할 일을 찾다 보면, 정작 데이터 표준화 한 번이면 끝날 문제를 굳이 화면 클릭 자동화로 풀게 돼요. 도구는 수단인데, 어느새 목적이 되어버리는 거죠.
그래서 이렇게 해보세요
프로젝트를 시작하기 전에 딱 한 문장을 적어보세요. "이 업무를 자동화하지 않으면 어떤 문제가 생기는가?" 답이 또렷하게 나오면 자동화할 가치가 있는 일이에요. 답이 흐릿하다면, 자동화보다 표준화가 먼저예요. 들쭉날쭉한 일을 자동화하면 들쭉날쭉함까지 그대로 굳어버리거든요.
2. 정작 그 일을 하는 사람을 설계에서 뺀다
자동화 시스템을 IT 부서나 외주팀이 단독으로 설계하고, 현업 담당자는 다 만들어진 뒤 테스트 때 처음 보는 구조가 있어요. 이 방식은 거의 실패해요.
이유는 단순해요. 실제로 그 일을 하는 사람만 아는 게 있거든요. 공식 프로세스 문서에는 절대 안 적혀 있는 것들이에요.
문서에 없는 예외 처리가, 사실은 그 업무의 절반이에요.
예를 들어 볼게요. 월말 결산 때 특정 거래처 데이터는 매번 손으로 보정해요. 분기 초에만 입력 양식이 살짝 달라져요. 시스템에는 안 남지만 팀장 구두 승인이 있어야 넘어가는 단계가 있어요. 이런 건 담당자 머릿속에만 있어요. 누구도 적어두지 않았고, 적어둘 생각도 못 했어요. 그냥 매번 그렇게 처리했으니까요.
이 현장 지식이 빠진 자동화는 예외가 나올 때마다 멈추거나 틀려요. 담당자 입장에선 자동화가 오히려 손이 더 가요. 결과 확인하랴, 틀린 거 고치랴, 예외는 또 수동으로 처리하랴. 그러다 어느 순간 "그냥 내가 하는 게 빠르다"며 시스템을 우회하기 시작해요. 한 번 우회가 시작되면 자동화는 죽은 거나 마찬가지예요.
그래서 이렇게 해보세요
업무 흐름을 정의하는 첫 단계부터 담당자를 넣으세요. 회의실에서 프로세스를 그릴 게 아니라, 담당자 옆에 앉아 실제로 어떻게 처리하는지 한 번 지켜보는 게 훨씬 정확해요.
그리고 단계마다 물어보세요. "여기서 예외가 얼마나 자주 생기나요?" 가정해서 보면, 어떤 단계에서 예외가 전체의 10%를 넘는다면 자동화를 서두를 때가 아니에요. 예외 유형을 먼저 줄이는 게 순서예요. 예외 비율이 낮아져야 자동화가 비로소 안정적으로 돌아가거든요.
3. 유지보수 계획 없이 출시한다
자동화는 한 번 만들면 영원히 도는 기계가 아니에요. 주변 환경이 바뀌면 조용히 망가져요.
연동하던 외부 시스템의 API 버전이 바뀌면 데이터가 안 들어와요. 스크래핑하던 웹사이트의 HTML 구조가 개편되면 엉뚱한 값을 긁어와요. 내부 업무 프로세스가 바뀌면 자동화 로직의 전제가 무너져요. 이런 변화는 예고 없이 와요. 그리고 자동화는 망가져도 비명을 안 질러요. 그냥 틀린 값을 조용히 만들어낼 뿐이에요.
많은 팀이 초기 구축에는 힘을 쏟지만, 그다음을 비워둬요. "문제 생기면 그때 보자"는 마음이죠. 그런데 이 태도가 자동화를 자산이 아니라 리스크로 만들어요. 틀린 줄도 모르고 쓴 데이터로 한 달치 정산이 어긋난 다음에야 알아차리는 식이거든요.
그래서 이렇게 해보세요
출시 전에 세 가지를 미리 정해두세요. 거창할 필요 없어요. 한 줄씩이면 충분해요.
- 오류 감지 — 자동화가 잘못 돌면 누가, 어떻게 알아차리나요? 실패하면 알림이 오게 해두는 게 가장 확실해요.
- 담당자 지정 — 망가졌을 때 고칠 권한과 책임이 누구한테 있나요? "다 같이"는 곧 "아무도"예요.
- 검토 주기 — 분기나 반기마다 로직이 아직 유효한지 한 번 점검하나요? 환경은 계속 바뀌니까요.
이 세 줄을 정해두는 데는 한 시간이면 돼요. 그런데 이게 없으면 잘 만든 자동화도 몇 달 안에 신뢰를 잃어요.
자동화는 도입 자체가 목적이 아니에요. 반복 부담을 줄이고, 오류를 줄이고, 더 중요한 일에 쓸 시간을 버는 수단이에요. 문제를 먼저 정의하고, 현장 담당자와 함께 설계하고, 출시 뒤에도 돌볼 체계를 갖출 때 자동화는 제 몫을 해요.
도입을 검토 중이라면, 효과를 어떻게 가늠할지도 같이 보면 좋아요. 자동화 ROI 계산법에서 비용과 효과를 따져보는 방법을 정리해 뒀어요.