RPA 자동화 실패의 진짜 원인

자동화를 했는데, 왜 사람이 더 바빠졌을까

버튼 하나만 누르면 일이 끝나는 미래. 많은 회사가 그런 그림을 그리며 자동화를 들여옵니다. 그런데 막상 뚜껑을 열어 보면 현실은 정반대인 경우가 많습니다.

자동화를 들여도 사람은 여전히 세 가지 일을 합니다. 로봇이 못 한 건을 손으로 메우고, 로봇이 멈추면 원인을 들여다보고, 결과가 맞는지 다시 검수합니다. 일을 덜어 주는 도구를 샀는데 사람 손은 오히려 더 많이 가는 역설이 벌어집니다. — 자동화 뒤에도 남는 사람의 일

로봇이 처리하지 못한 건은 사람이 뒤에서 손으로 메웁니다. 로봇이 멈추면 왜 멈췄는지 들여다봐야 합니다. 결과가 맞는지 다시 검수까지 해야 합니다. 분명 일을 덜어 주는 도구를 샀는데, 사람 손은 더 많이 가는 이상한 상황이 벌어집니다.

"자동화를 했는데 왜 사람이 더 필요해졌을까?" 이 질문은 사실 도입에 실패했다는 신호라기보다는, 자동화가 무엇인지를 처음부터 오해했다는 신호에 가깝습니다.

그리고 이건 어느 한 회사만의 이야기가 아닙니다. RPA 자동화 실패 사례를 들여다보면 놀라울 만큼 비슷한 장면이 반복됩니다. 기술이 모자라서가 아닙니다. 자동화를 얹기 전에 정리했어야 할 것을 정리하지 않아서 생기는 문제입니다.

진짜 원인은 '자동화하기 전의 프로세스'에 있다

컨설팅 회사 투이컨설팅의 황인태 책임은 2019년에 이 점을 이렇게 짚었습니다. 기존 프로세스가 비효율적이면 RPA 프로세스도 똑같이 비효율적이 된다는 것이죠. 그래서 먼저 문제가 되는 지점을 찾아낸 뒤 적절한 자리에 RPA를 입혀야 한다고 그는 말합니다. 실무 매체 엔터프라이저스 프로젝트가 정리한 RPA 실패의 네 갈래도 같은 지점을 짚습니다. 프로세스가 자동화에 맞게 다듬어져 있지 않으면 예외와 변형이 끊임없이 튀어나와서, 결국 실제 업무에 쓰기 어려워진다는 것이죠.

여기서 '예외 처리'라는 말을 곱씹어 볼 필요가 있습니다.

자동화는 규칙이 뚜렷한 반복 작업을 대신해 주는 도구입니다. 그런데 사람이 손으로 하던 일에는, 우리도 모르는 사이에 수많은 즉흥적인 판단이 녹아 있습니다. "이 거래처는 양식이 좀 다르니까 이렇게 처리하고", "이 경우엔 팀장님께 한번 물어보고", "금액이 크면 한 번 더 확인하고" 같은 것들이죠.

이런 판단들을 정리하지 않은 채 자동화만 얹으면 어떻게 될까요? 로봇은 규칙이 뚜렷한 정형 업무 — 산술적으로 말하면 대략 8할 — 만 처리합니다. 그리고 나머지 예외를 전부 사람에게 떠넘깁니다.

자동화는 규칙이 뚜렷한 정형 반복 80%만 처리하고, 나머지 20%의 예외를 전부 사람에게 떠넘깁니다. 문제는 그 20%가 원래부터 가장 어렵고 손이 많이 가던 일이라는 점이어서, 쉬운 일은 로봇이 가져가고 예외와 오류 수습은 사람 몫으로 남습니다. — 로봇이 가진 80%, 사람이 남은 20%

문제는 그 20%가 원래부터 가장 어렵고 손이 많이 가던 일이라는 데 있습니다. 쉬운 일은 로봇이 가져가고, 어려운 일과 '로봇이 뱉어낸 오류를 수습하는 일'이 사람에게 남습니다. 체감상 사람 손이 더 필요해지는 이유가 바로 여기 있습니다.

사람이 배제된 자리에서 실패가 자란다

CIO가 정리한 RPA 자동화 실패의 다섯 가지 이유는 기술 스택이 아니라 사람과 조직을 가리킵니다. 경영진의 망설임, 부족한 훈련·교육, 잘못된 사례 선택, IT·보안 부서 배제, 앱 개발자 배제 — 다섯 가지가 하나같이 사람과 조직에 관한 이야기입니다. — RPA 실패 5가지, 모두 사람 문제

기술보다 조직의 문제인 경우도 많습니다. IT 매체 CIO가 정리한 'RPA에 실패하는 5가지 이유'는 기술 스택을 가리키지 않습니다. 대신 사람과 조직을 가리킵니다. 경영진의 망설임, 부족한 훈련·교육, 잘못된 사례 선택, IT·보안 부서 배제, 그리고 앱 개발자 배제 — 다섯 가지가 하나같이 사람과 조직에 관한 이야기입니다.

이 가운데 특히 뼈아픈 세 갈래를 하나씩 뜯어보면 이렇습니다.

경영진의 망설임. 자동화를 그저 '비용 절감 프로젝트'로만 보면, 프로세스를 근본적으로 다시 설계할 예산과 시간을 주지 않습니다. 그러면 팀은 낡은 프로세스 위에 로봇만 얹게 됩니다. 앞에서 말한 예외 처리 지옥으로 곧장 직행하는 셈이죠.
개발자 배제. RPA를 '코딩 없이 현업이 직접 만드는 도구'라고 포장하다 보면, 시스템 연동·에러 처리·유지보수를 아는 개발자가 초기 설계에서 빠집니다. 화면을 클릭하는 방식으로 짠 자동화는 대상 시스템의 화면이 조금만 바뀌어도 멈춥니다. 그때마다 사람이 다시 달라붙어야 합니다.
현업과의 소통 부족. CIO가 '잘못된 사례 선택'을 실패 이유로 꼽은 것도 결국 이 문제와 맞닿아 있습니다. 그 '숨은 예외'를 아는 사람은 실제로 그 업무를 하는 사람뿐입니다. 이들이 설계에서 빠지면, 자동화는 실제 업무가 아니라 '문서상의 이상적인 업무'를 자동화하게 됩니다. 그런데 현실은 문서와 다릅니다.

결국 RPA 자동화 실패의 공통분모는 한 문장으로 모입니다. 사람을 나중에 부른다는 것. 도입할 때 배제했던 바로 그 사람들을, 운영 단계에 가서 수습 인력으로 다시 불러들이는 셈입니다.

그래서, 사람 손을 줄이려면

자동화가 사람을 더 필요하게 만드는 악순환을 끊으려면 일하는 순서를 바꿔야 합니다. 먼저 프로세스를 단순화하고, 예외 비율과 유형을 측정해 가시화하고, 현업·개발자·관리자를 처음부터 같은 테이블에 앉히고, 사람이 판단할 예외를 설계의 일부로 인정합니다. 자동화는 정리된 프로세스 위에 마지막으로 얹는 것입니다. — 사람 손을 줄이는 일의 순서

자동화가 오히려 사람을 더 필요하게 만드는 이 악순환을 끊으려면, 일하는 순서를 바꿔야 합니다.

자동화하기 전에 프로세스부터 단순하게 만듭니다. 없애도 되는 단계, 합칠 수 있는 단계를 먼저 정리합니다. 자동화는 '정리된 프로세스'에 마지막으로 얹는 것이지, 정리를 대신해 주는 도구가 아닙니다.
예외를 미리 눈에 보이게 만듭니다. 전체 건 중에서 예외가 몇 %인지, 어떤 유형인지 측정합니다. 예외가 유독 잦은 업무라면 — 가령 처리 건 상당수가 예외로 빠진다면 — 그건 자동화보다 표준화가 먼저인 업무입니다.
현업·개발자·관리자를 처음부터 같은 테이블에 앉힙니다. 숨은 규칙을 아는 사람, 시스템을 아는 사람, 우선순위를 정하는 사람이 초기에 함께 있어야 나중에 수습 인력을 부르지 않습니다.
'사람이 처리할 예외'를 설계의 일부로 인정합니다. 100% 자동화를 목표로 삼지 마세요. 로봇이 처리할 영역과 사람이 판단할 영역을 또렷하게 나눕니다. 잘 나눈 예외 처리 흐름은 사람의 손을 '수습'이 아니라 '판단'에만 쓰게 해 줍니다.