완전히 자동화된 엔터프라이즈를 구현하는 애자일 RPA (Part 3: RPA이니셔티브의 성공 배경)

지난 포스트에서 수잔과 CoE팀이 전통적 개발 방식을 포기하고 애자일 RPA 방법을 선택한 주요 배경과 과정을 살펴보았습니다. 조금 길지만 끝까지 읽은 분들은 큰 그림이 보이기 시작했을 겁니다. 애자일 RPA 개발의 성공은 기술과 방법론적 변화뿐만 아니라 최고 경영진의 지원, 이해 관계자간 공감대 형성, 프로젝트 참여자간 긴밀한 협업과 소통이 따라야 한다는 사실을 말입니다. 오늘은 마지막으로 RPA 이니셔티브의 성공 배경을 정리했습니다.

애자일 RPA 적용과 평가

수잔과 CoE팀은 두 가지 방향으로 애자일 RPA 자동화 목표를 세웠습니다. 먼저, CoE팀의 내부 목표는 로봇의 지속적 성능 향상으로 정합니다. 로봇의 성능 향상이 보장돼야 사용자의 문제 해결, 시간/비용 절감 등 실질적 효과를 얻을 수 있기 때문이고 현업 부서가 가장 원하는 일이기도 합니다. 대외적 목표로는 현업 부서 만족도를 성공 지표로 설정합니다. 이를 위해 CoE팀을 서비스 공급자로, 현업 부서를 고객으로 정의하고 프로젝트 초기부터 sNPS (stakeholder Net Promoter Score, 이해 관계자 추천 지수) 방법을 이용해 사용자 만족도를 평가했습니다. 동시에 현업 부서 피드백을 적극 수용하고 반영하는 일도 빼놓지 않았습니다.​

sNPS에는 “RPA CoE팀의 서비스를 다른 사람에게 추천할 가능성은 얼마입니까? 0~10 점 중에 선택해 주세요”라는 질문 하나만 담겨 있습니다. 9~10점을 선택한 응답자는 추천자(Promoter)로, 7~8점은 중립자(passive)로, 0~6점은 비추천자(detractor)로 분류했습니다. 결과를 보면, 전통적 방법으로 진행할 때의 sNPS는 +38점이었지만 애자일 RPA개발로 전환하면서 +88 점으로 증가했습니다. 이는 50명의 응답자 중 44명이 추천을 하고 오직 6명만 중립을 선택했다는 의미입니다.

 sNPS 평가 방법​

sNPS결과가 두 배 이상 높아진 이유는 애자일 RPA 개발로의 전환에서 찾을 수 있습니다. 애자일 RPA가 추구하는 사용자 중심 그리고 반복적 개선을 통해 완성도 높은 로봇을 신속하게 개발해 공급하자 현업 부서의 만족도가 급상승한 것이죠. “RPA 자동화의 진정한 평가는 현업 부서와 사용자들이 하는 것!”라는 수잔의 믿음이 빛을 발하는 순간이기도 합니다. 그럼, 이번에는 RPA이니셔티브가 성공적으로 진행된 이유를 살펴보겠습니다. 

RPA 이니셔티브의 성공 요소​

성공의 원인은 다양한 관점에서 찾을 수 있습니다. 예를 들어, 완성도 높은 로봇 개발은 반복 테스트와 검증된 엔지니어링 프렉티스의 결합으로 나타난 결과입니다. 또한 단계별 애자일 RPA개발로 개발 과정의 재작업(낭비)을 줄인 것도 탁월한 선택이었습니다. 만약 CoE팀이 반복적 테스트 없이 개발 속도만 높였다면 더 많은 로봇을 개발했겠지만 현업 부서를 만족시키는 품질은 나오지 못했을 겁니다. 또한 수 많은 재작업을 야기하면서 시간과 비용을 까먹었을 겁니다. 애자일 전문가인 Tim Ottinger(2006)는 ‘관리할 수 없는 빠른 속도로 일을 처리한다면 그것은 애자일이 아니라 그냥 서두르는 것이다’라는 점을 분명히 하고 있습니다. 

이 같은 효과적 로봇 개발을 가능케 한 SW개발, IT운영 및 현업 부서간의 긴밀한 협업 체계, 열린 소통 그리고 솔직한 피드백 제공과 반영도 눈 여겨 봐야 합니다. 이런 업무 분위기는 이해 관계자간의 신뢰를 형성하고 공동체 의식을 쌓는 토대가 되었습니다. 앞선 포스트에서도 언급한 것처럼 구성원간의 신뢰가 없다면 애자일 개발은 성공할 수 없습니다. 수잔과 CoE팀이 자신들의 역할을 프로젝트 통제자가 아닌 지원자로 정의하고 솔선수범하여 참여자간 신뢰와 공동체 의식을 끌어 올린 것은 신의 한수와 같습니다.

RPA 이니셔티브의 성공을 이끈 성장 마인드​

RPA 이니셔티브의 성공을 이끈 또 다른 요소는 애자일 마인드입니다. 수잔은 Carol Dweck(2007) 연구 결과를 토대로 애자일 마인드를 ‘성장 마인드’라고 정의했습니다. 성장 마인드는 도전을 즐기고, 문제에 부딪히면서 계속 시도하고, 자신에 대한 비판을 통해 배우며, 타인의 성공에서 교훈과 영감을 얻는 태도를 의미합니다. 수치화하기도, 설명하기도 어렵지만 가장 중요하다는 것을 누구나 인정할 겁니다.​

애자일을 제대로 이해하고 내재화하려면 머릿속 이론에 머물지 말고 실행이 따라야 합니다. 수잔도 전통적 개발 방법에서 애자일 RPA로 전환하는 여정에서 애자일 마인드를 제대로 배웠다고 이야기합니다. 그녀는 애자일 마인드를 단순히 애자일 방법을 이용하는 것(Doing agile)이 아니라 애자일이 기본이 되는(Being agile) 수준에 도달하려는 의지라고 정의합니다. 눈치 채셨죠, Doing agile은 금세 가능한 일이지만 Being agile은 오랜 시간, 반복된 시도와 노력을 통해 얻을 수 있습니다.​ 

마무리

UiPath가 백서를 만든 이유는 RPA를 마스터하는 도구로 애자일 RPA를 알리기 위함이 아닙니다. 사실 대규모 개발 프로젝트의 성공을 보장하는 분명한 공식 같은 것은 없습니다. 애자일 RPA 개발은 장점도 많지만 위험도 있습니다. Carlijn Hattink(2016)는 기고문을 통해 애자일 방법을 도입한 개발팀이 갖는 위험과 해결 방법 등을 자세히 다루고 있으니 참고하기 바랍니다. 애자일 RPA는 수잔의 회사에는 적합했지만 다른 조직에게도 같은 결과를 가져온다고 확신할 수는 없습니다. Gerald Weinberg(1986)가 ‘처음에는 어떻게 보이든 문제는 항상 사람이다.’라고 말한 것처럼, 핵심은 사람에 달려 있습니다. RPA개발에 참여하는 사람들이 원팀처럼 협력하지 않으면 애자일 개발의 장점은 실현할 수 없습니다. 또한, 애자일을 꺼리는 이들에게 애자일 프랙티스와 원칙을 강요해도 안되고 설득할 수도 없습니다. 그들 스스로 이해하도록 필요한 정보를 제공하고 지원하며, 설득하기보다 애자일 방식으로 얻을 수 있는 이점을 알려주는 것이 현명합니다.