대부분의 RPA 프로젝트가 실패하는 이유는 동일합니다. 기술 때문이 아닙니다.

RPA는 복잡한 평판을 가지고 있으며, 여기에는 타당한 이유가 있습니다. 영업 주기(sales cycle)에서 약속된 내용과 구현 후 실제로 일어나는 일 사이의 간극이 너무 커서 많은 조직이 회의적으로 변했습니다. 이는 기술이 작동하지 않기 때문이 아니라, 기술이 작동하기 위한 조건이 제대로 설정되지 않았기 때문입니다.

실질적인 결과를 내는 구현 사례와 유지보수의 악몽이 되는 사례는 종종 동일한 플랫폼을 사용하며, 때로는 동일한 벤더(vendor)를 사용하기도 합니다. 이 둘을 가르는 차이점은 프로세스 선정(process selection)입니다. 즉, 무엇을 자동화했는지, 그리고 구축하기 전에 그에 대해 어려운 질문들을 던졌는지 여부입니다.

무엇이 프로세스를 자동화할 가치가 있게 만드는가

모든 반복적인 작업이 좋은 자동화 후보인 것은 아닙니다. 성공적인 사례들은 몇 가지 공통점을 공유하는 경향이 있습니다.

가장 명백한 것은 규모(Volume)입니다. 트랜잭션당 8분을 절약하는 봇은 월 80건의 트랜잭션일 때와 월 2,000건일 때의 모습이 다릅니다. 규모가 작으면 유지보수 오버헤드(maintenance overhead)가 절약된 시간을 쉽게 초과할 수 있으며, 이 경우 유일한 승자는 구현을 판매한 사람뿐입니다.

하지만 규모보다 중요한 것은 규칙(Rules)입니다. RPA 봇은 지침을 정확하게 따르며, 명시적으로 정의되지 않은 것은 아무것도 처리하지 않습니다. 사람이 정기적으로 맥락을 읽고, 요소를 저울질하거나, 어디에도 기록되지 않은 경험을 바탕으로 판단을 내리는 프로세스는 봇이 처리할 수 없는 수많은 예외(exceptions)를 발생시킬 것입니다. 사람이 본질적으로 매번 같은 일을 같은 방식으로, 단지 느리고 수동으로만 수행하는 프로세스가 바로 자동화를 위해 만들어진 대상입니다.

안정성(Stability)은 과소평가되기 쉬운 요소입니다. 봇은 인터페이스를 통해 시스템과 상호작용합니다. 화면이 바뀌거나, 필드가 이동하거나, 벤더가 포털을 업데이트하면 봇은 작동을 멈춥니다. 빈번하게 변경되는 시스템을 대상으로 실행되는 프로세스는 지속적인 유지보수를 요구할 것입니다. 반면, 레거시 ERP(legacy ERP)나 거의 손대지 않는 내부 도구와 같이 안정적인 대상을 대상으로 실행되는 프로세스는 계속 운영하기에 훨씬 위험 부담이 적습니다.

어떤 산업 분야의 어떤 구체적인 프로세스들이 이러한 기준을 충족하는지는 RPA 사용자 및 자동화 대상에 관한 가이드에서 자세히 다루고 있습니다.

대부분의 팀이 범하는 프로세스 선정 실수

RPA에서 가장 비용이 많이 드는 실수는 잘못된 플랫폼을 선택하는 것이 아닙니다. 그것은 왜 프로세스가 그런 방식으로 작동하는지 묻지 않은 채, 현재 존재하는 그대로의 프로세스를 자동화하는 것입니다.

대부분의 조직 내 수동 프로세스(Manual processes)에는 더 이상 아무도 의문을 제기하지 않는 단계들이 수년에 걸쳐 축적되어 있습니다. 2년 전에 해결되었으나 정리되지 않은 시스템 제한 사항에 대한 임시방편(Workarounds), 다른 시대에는 타당했던 중복 점검, 사고 발생 후 누군가 추가하여 그대로 남아 있는 비공식적인 단계들이 그러합니다. 이 모든 것을 충실하게 자동화하는 것은 비효율성을 봇(Bot)에 그대로 인코딩(Encoding)하는 것과 같습니다. 그 결과는 더 빠르게 실행되기는 하지만, 근본적으로는 여전히 망가진 상태인 무언가가 됩니다.

무엇인가를 자동화하기 전에, 어떤 단계가 진정으로 필요한 단계이고 어떤 단계가 과거의 잔재(Artifacts)인지 이해할 가치가 있습니다. 때때로 이러한 검토를 통해 자동화하기 전에 프로세스 자체를 변경해야 한다는 사실이 드러나기도 합니다. 때로는 아무도 신경 쓰지 않았던 작은 시스템 설정 변경만으로 전체 프로세스를 제거할 수 있다는 사실이 밝혀지기도 합니다. 자동화 프로젝트는, 최소한 프로세스에 대해 오래전에 이루어졌어야 할 대화를 강제하는 역할을 합니다.

예외 처리(Exception handling)는 파일럿 프로젝트가 운영 환경보다 더 좋아 보이는 이유입니다

대부분의 파일럿(Pilot) 프로젝트는 해피 패스(Happy path)를 테스트합니다. 트랜잭션(Transaction)이 깔끔하게 처리되고, 데이터가 올바르게 형식화되며, 모든 예상 필드가 채워지고, 다운스트림 시스템(Downstream system)이 이를 수용합니다. 봇은 이를 완벽하게 처리하며 데모는 훌륭해 보입니다.

하지만 운영(Production) 데이터는 그렇지 않습니다.

실제 데이터는 형식의 불일치, 누락된 필드, 그리고 너무 드물게 발생하여 요구사항(requirements)에 포함하는 것을 아무도 기억하지 못했던 예외 케이스(edge cases)를 가지고 있습니다. 실제 프로세스에는 인간이 비공식적으로 처리하는 예외 사항들이 존재합니다. 정보가 누락되면 두 번째 출처를 확인하고, 무언가 잘못되어 보이면 처리하는 대신 플래그(flag)를 표시하며, 특이한 케이스가 나타나면 이를 어떻게 라우팅할지에 대해 판단을 내립니다.

이러한 상황이 이를 처리하도록 설계되지 않은 봇(bot)에 닥치면, 두 가지 중 하나가 발생합니다. 봇이 명시적으로 오류를 일으켜 누군가가 조사해야 하거나, 더 나쁜 것은 봇이 조용히 실패(fails silently)하는 것입니다. 즉, 트랜잭션(transaction)을 잘못 처리하고 다음 단계로 넘어가 버리며, 하류(downstream) 단계에서 문제가 발생할 때까지 아무도 이를 알지 못하게 됩니다.

빌드하기 전에 예외 경로(exception paths)를 신중하게 매핑하고 각 경로에 대한 명시적인 처리 방식을 설계하는 팀은 운영(production) 환경에서도 잘 버티는 봇을 출시합니다. 반면, 해피 패스(happy path)만을 매핑하고 예외 처리는 나중에 할 계획을 세우는 팀은 운영 개시(go-live) 후에 자동화의 상당 부분을 다시 구축하게 됩니다.

유지보수의 현실

봇은 지속적인 주의가 필요합니다. 이 부분은 ROI(투자 대비 수익) 예측에서는 과소평가되는 경향이 있지만, 자동화를 1~2년 동안 운영해 온 조직의 경험에서는 과하게 나타나는 RPA의 특징입니다.

시스템은 변합니다. 벤더(vendors)는 포털을 업데이트합니다. 내부 애플리케이션은 새로운 릴리스(releases)를 받습니다. 프로세스는 수정됩니다. 이 중 어떤 것이든 봇을 고장 낼 수 있으며, 이를 구축한 팀이 이를 수정해야 합니다. 소규모 규모에서는 관리가 가능합니다. 하지만 봇의 수가 늘어남에 따라 고장 날 수 있는 접점(surface area)도 함께 늘어나며, 의도적인 운영 구조(operational structure)가 없다면 유지보수 작업이 새로운 개발 작업을 밀어내기 시작합니다.

이를 잘 처리하는 조직은 처음부터 프로그램에 소유권(ownership)을 구축하는 경향이 있습니다. 즉, 각 봇에는 정의된 소유자가 있고, 장애가 쌓이기 전에 이를 포착할 수 있는 모니터링 체계가 갖춰져 있으며, 시스템 변경 사항이 발생할 때 봇이 이미 고장 난 후에 발견하는 것이 아니라 사전에 통지받을 수 있는 프로세스가 존재합니다. 이 중 어느 것도 복잡한 것이 아닙니다. 단지 세 번째 운영 장애(production incident)가 발생한 후에 사후 대응적으로(reactively) 해결하는 것이 아니라, 의도적으로 설정되어야 할 뿐입니다.

어떤 부서가 가장 내구성 있는 프로그램을 구축했는지와 그 이유에 대한 비교는 자동화 실무(automation practice)를 구축하기 전에 읽어볼 가치가 있습니다 — 산업 및 부서별 RPA 도입에 관한 이 상세한 분석은 성공적인 프로그램들이 무엇을 공통적으로 가지고 있는지 다룹니다.

가장 먼저 던져야 할 질문

어떤 봇이 구축되기 전에, 대부분의 팀보다 더 오래 고민해 볼 가치가 있는 질문이 하나 있습니다. 바로 '이 프로세스를 자동화하는 것이 올바른 문제를 해결하는 것인가?'입니다.

때로는 '예'입니다. 해당 프로세스가 필수적이고, 처리량이 많으며, 규칙 기반(rule-based)이고, 주요 문제가 인간의 시간을 너무 많이 소모한다는 것이라면 봇을 구축하십시오.

때로는 직접적으로 해결할 수 있는 시스템의 한계 때문에 해당 프로세스가 존재하는 경우도 있습니다. 혹은 중복된 작업일 수도 있고, 작은 워크플로(workflow) 변경만으로도 프로세스 자체를 완전히 없앨 수 있는 경우도 있습니다. 이러한 경우에 자동화는 문제를 해결하는 것이 아니라 문제를 영구적인 것으로 만듭니다.

가치 있는 프로그램을 구축하는 팀은 봇 로직을 단 한 줄이라도 작성하기 전에, 모든 후보 프로세스에 대해 이 질문을 일관되게 던집니다. 이는 시작을 늦추게 만듭니다. 하지만 이것이 바로 그들의 자동화가 2년이 지난 후에도 여전히 작동하고 있는 이유입니다.