완전히 자동화된 엔터프라이즈를 구현하는 애자일 RPA (Part 2: 애자일 RPA방법 도입 배경)

애자일 RPA 전환 배경

RPA CoE팀과 수잔이 애자일 RPA 방법으로 전환한 이유는 프로젝트의 예측 가능성 확보, 투명성 확보부터 적용 능력 강화 그리고 이해 관계자간 협업 강화까지 포괄적입니다. 아래 그림의 각 항목이 CoE팀이 전통적 개발 방법에서 애자일 RPA로 전환한 주요 배경입니다.

애자일 RPA 전환의 주요 배경

1. 예측 가능성

워터폴 등 전통적 개발 방식을 적용하면 사전 분석과 설계로 산출한 문서 내용과 실제 간의 갭이 커지면서 개발 프로세스의 예측 가능성이 크게 떨어집니다. 이 때문에 CoE팀이 RPA 프로젝트를 통해 목표한 결과를 얻지 못하는 상황이 반복되었습니다. 그림의 왼쪽이 CoE팀이 기대한 내용이라면 실제 결과는 오른쪽처럼 나타났습니다.

RPA 개발 프로젝트 기대 사항 vs. 실제 결과

​이유는 기존 프로젝트의 방법론적 특성에서 찾을 수 있습니다. 개발팀은 RPA자동화 아이디어 발굴, 분석, 설계까지는 현업 부서와 긴밀히 협력하지만 개발 작업은 단독으로 진행했습니다. 이 과정에서 개발팀은 현업 부서와의 소통과 피드백보다 문서에 기록된 개념적 내용 구현과 전파에 집중하게 되었죠. 하지만, 문서 내용의 정확성과 일관성이 떨어지고 자동화 대상 업무의 요건이 계속 변하면서 RPA 개발의 예측 가능성 확보라는 목표는 불가능에 가깝다는 공감대가 광범위하게 형성되었습니다.

전통적 개발 방법 진행 단계

​이것이 CoE 팀과 수잔이 애자일 RPA 방식으로 전환한 이유입니다. 애자일 방법론은 사람과 상황 변화를 파악하고 적응하는데 중점을 둡니다. 따라서 개발 및 운영 중에도 끊임 없이 변하는 RPA 업무에 적합하다고 판단한 것이죠. 

2. 투명성 확보많은 사람이 “예측의 첫 번째 법칙은 예측은 항상 틀린다!”라고 합니다. 프로젝트 초기의 시행 착오를 통해 CoE팀은 RPA 개발의 예측이 어렵다는 결론에 도달합니다. 예측이 정확 하려면 처음 정한 개발 사양이 변하지 않아야 하는데 자동화 요건은 계속 변경되었기 때문이죠. 예를 들어 보죠, CoE팀은 문서 내용을 토대로 개발 절차를 지켜가면서 업무를 자동화한 다음 현업 부서에 전달합니다. 그런데 현업 부서는 결과물이 업무와 다르고 오류도 많다고 불평을 합니다. 반면, 개발팀은 자동화 요건이 왜 계속 바뀌는지 모르겠다고 억울함을 쏟아냅니다. 이런 위험 요소를 제거하지 못하면 개발 과정에서 재작업이 계속 발생합니다. 당연히 작업이 지연되고 비용이 늘면서 RPA이니셔티브가 지체되고 RPA 확산 목표도 달성하지 못하는 상황이 벌어졌습니다.​CoE팀은 긴밀한 협업을 통한 투명성 확보없이 문서에만 의존하면 소비자 요구를 정확히 이해할 수 없다는 사실을 깨닫게 됩니다. 얼음이 얼어야만 물 위를 걸을 수 있듯이 문서대로 자동화를 하려면 사양이 변하지 않아야 합니다. 즉, 완벽한 RPA구현은 완벽한 변화 관리를 의미합니다. 개발 과정의 변화를 적극 수용하는 애자일 방식을 택한 또 다른 이유입니다. 그리고 기존 프로세스 중심 접근법을 반복적, 적응형 방식인 애자일 RPA로 전환하면서 예측 가능성이 아닌 적응 능력에 집중하는 전략을 택했습니다.

기존 개발 방법 vs. 애자일 방법 비교

​3. 적응 능력수잔은 Scrum과 Kanban을 조합한 Scrum with Kanban프로세스 프레임워크로 CoE팀의 반복적 작업을 줄이고 적응력을 높이는 방법을 택했습니다. 이유는 Scrum의 핵심적 특성이 투명성, 반복 점검, 적응에 있기 때문입니다. 참여자의 업무 경험과 린(Lean) 철학에 기반하는 Scrum은 반복적이고 점증적인 접근을 통해 예측 가능성을 최적화하고 위험을 제거하는 방법을 이용합니다. 바로 이 부분이 프로젝트 초기 교훈을 통해 수잔이 필요로 했던 역량이었습니다.​Scrum가이드의 다음 설명이 이를 잘 설명하고 있습니다. “Scrum 프레임워크는 Scrum 이론을 구현하는 데 필요한 부분만 정의하여 의도적으로 불완전하게 만들었다. Scrum은 사용자의 집단 지성을 통해 발전한다. Scrum규칙은 사용자에게 세부 지침을 제공하는 대신 관계와 상호 작용을 안내한다.” 예측 불가능한 개발 프로세스 제어에는 Scrum이 최적이라는 것이 수잔의 믿음입니다.​Scrum이 세부 지침의 제공 대신 구성원간 관계와 상호 작용을 안내하는데 집중한다면, Kanban은 개발 과정의 최적화 전략으로 Scrum팀의 안정적인 개발을 가이드 하는 방법입니다. 즉, Scrum은 RPA 개발의 관리에, Kanban은 RPA개발 과정의 최적화에 중점을 두기 때문에 아주 좋은 결합이 되는 것이죠.

RPA 개발 적응 능력 강화

​CoE팀은 RPA개발 프로세스를 위 그림처럼 2주 단위 반복 과정(스프린트)로 나눴습니다. 각 스프린트 완료 후에 개발된 로봇을 현업에 제공해 피드백을 받고 보완하는 과정을 거치게 됩니다. 이 과정을 반복하면서 RPA로봇 품질과 사용자 만족도가 높아지는 성과를 얻게 되었습니다. 애자일 방법을 이용해 체계적으로 피드백을 받고, 이 피드백을 활용해 개발 프로젝트의 예측 불가능성을 효과적으로 제어할 수 있게 된 것이죠. 이것이 RPA 개발의 적응 능력 강화입니다. 

4. 세분화CoE팀이 도입한 점진적 개발 방법은 로봇 개발은 물론 개발 문서의 작성에도 이용되었습니다. 몇 달씩 걸려 프로젝트의 세부 사항을 모두 정리하기 보다 반복적 보완과 수정을 통해 문서를 개선해 가는 방법을 사용했습니다. 이는 사전 계획이 없다는 뜻이 아니라 초기에는 큰 그림에 초점을 두고 계속 조정해 가면서 세분화하고 발전시켜 간다는 의미입니다. 이를 위해 개발 초기에는 그림처럼 경험과 지식 습득에 중점을 두고 진행하면서 비즈니스 및 기술적 위험을 제거하는데 목표를 두었습니다. 현업 부서와의 긴밀한 협력을 통해 자동화 대상 업무의 흐름과 로직을 파악해 비즈니스 위험을 없애는 것이 좋은 예입니다.

RPA 개발 세분화 과정

​다음으로는 비즈니스 프로세스 슬라이싱이라는 개념을 활용해 자동화 대상 업무 프로세스를 작고 관리하기 쉬운 단위로 나누는 작업을 했습니다. 이를 기준으로 로봇 컴포넌트를 너무 크지도, 작지도 않은 규모로 개발했습니다. 또한, 로봇 컴포넌트를 상호 독립적으로 개발했기 때문에 다른 업무에 재활용할 수 있고 관리도 편리했습니다. 슬라이싱 방법을 이용한 이유는 더 중요하고 가치 높은 업무에 집중할 수 있기 때문입니다. 예를 들어, 이 회사 구매팀이 받는 인보이스의 92%는 시스템에서 만들어진 PDF 파일로 파악되었습니다. 따라서 모든 형식의 인보이스가 아닌 PDF 형식만 자동화하는 것이 휠씬 더 높은 가치를 제공합니다.​이 방법은 세 가지 이점을 갖습니다. 첫째, CoE팀이 최소 노력으로 짧은 기간에 최대의 성과를 얻었습니다. 둘째, CoE팀이 로봇을 과다하게 개발하는 것을 막을 수 있었습니다. 셋째, 자동화 투자를 중단해야 하는 시점을 알 수 있었습니다. 즉, CoE팀이 고효율 시점(적은 노력, 높은 가치) 에서 비효율(많은 노력, 낮은 가치)로 넘어가는 시점을 인식하고 불필요한 작업을 막을 수 있었습니다. 피터 드러커의 충고로 마무리를 하겠습니다. “전혀 수행할 필요가 없는 일을 매우 효율적으로 하는 것만큼 쓸모 없는 짓은 없다” 

5. 복잡성RPA개발의 복잡성은 CoE팀이 애자일 개발로 전환하게 된 가장 큰 이유 중 하나입니다. 수잔은 자동화 대상 업무 발굴부터 자동화 구현, 운영에 이르는 총 개발 시간을 분석해서 18개월 후에 아래와 같은 결과를 얻게 되었습니다.

자동화 업무별 재작업 발생 비율

​내용을 분석해보면 자동화 업무의 85%는 5주 이상, 71%는 7주 이상 걸렸습니다. 더 세부적으로 보면 개발 기간이 2주 이내인 단순한 업무의 자동화는 워터폴 같은 기존 개발 방식이 더 효과적이었습니다. 이들 업무는 복잡도가 낮아서 자동화 개발 결과의 예측도 쉽다는 공통점을 갖고 있습니다. 반면에 복잡도 높고 여러 부서가 참여하는 업무 프로세스의 자동화에는 전통적 개발 방식이 비효율적이고 생산성도 떨어지는 것으로 파악되었습니다. 당연히 자동화 개발의 결과를 예측하는 일도 어렵기 때문에 재작업이 발생할 가능성이 높아집니다. 위 그림은 개발 기간이 긴 업무일수록 재작업 비율이 빠르게 증가하는 현상을 잘 보여주고 있습니다. 

6. 제어 가능성“RPA는 단순하지만 쉽지 않은 기술”로 분류됩니다. 로봇 개발과 배포에서 끝나지 않고 이후의 유지보수가 중요하기 때문이죠. 자동화 로봇이 적용된 업무 환경은 계속 변하기 때문에 로봇을 잘 운영하면서 가치를 창출하려면 체계적 유지보수가 필요합니다. 체계적 유지보수가 필요한 첫 번째 이유는 로봇과 애플리케이션SW간의 동기화 오류, 객체 인식 실패 같은 자동화 관련 문제 때문입니다. 다음은 로봇이 사용하는 애플리케이션 변경으로 발생하는 애플리케이션 관련 문제입니다. 마지막으로 자동화 업무에 연계되는 IT시스템 작업(예: 보안 패치, 설정 변경)으로 인한 시스템 환경의 변경 때문입니다.​비즈니스 프로세스의 우선 순위를 정하고 이를 기준으로 가치가 높은 프로세스부터 자동화를 시작하면, 자동화의 절감 효과(예: 정규 직원 수)는 이론적으로 파란색 곡선을 따르지만, 관련 부서간 정보 공유나 협업이 이뤄지지 않아 재개발이나 유지보수 작업이 늘어나면 실제 절감 효과는 빨간 곡선을 따라가게 됩니다. 이 회사의 경우도 IT 운영팀과 CoE팀간 정보 공유가 안되면서 이 같은 문제가 발생했습니다. 예를 들어, IT부서에 ERP시스템 구성을 변경했는데 이 내용이 CoE팀에 전달되지 않아 로봇 작동이 실패하는 경우를 들 수 있습니다.

유지보수 여부에 따른 절감 효과 비교

​수잔은 문제 해결을 위해 CoE팀과 SW개발팀, IT 운영팀 간의 협업 절차와 방법을 수립했습습니다. 각 팀은 UiPath Test Suite같은 툴을 이용해 개발된 로봇의 정상 작동 여부를 점검하게 됩니다. 이 방법을 통해 시스템 환경이나 애플리케이션 변경 작업이 로봇 작동에 문제를 일으키는지 여부를 자동화된 방법으로 평가하는 절차를 만들고 이를 통해 실질적 협업 체계를 만들어 나갔습니다. 이후로 로봇 다운타임이 88%나 감소하는 결과를 가져왔습니다. 

7. 엔지니어링 프렉티스 적용프로젝트 관리자들이 당연시 하는 엔지니어링 프렉티스가 Scrum에는 의도적으로 빠져 있습니다. 프로젝트팀이 엔지니어링 프렉티스 구현에 몇 개월씩 투입되면서 시간과 비용 면에서 문제가 되기 때문이죠. 반면에 Scrum은 엔지니어링 프렉티스가 필수가 아니기 때문에 도입이 쉽고 2~3일내에 바로 시작할 수 있다는 장점을 갖습니다. 프렉티스가 필요한 상황이라면 XP (eXtreme Programming) 프렉티스를 활용할 수 있습니다. Scrum 개발자인 Jeff Sutherland는 엔지니어링 프렉티스에 몇 달씩 시간을 쓰는 대신 바로 프로젝트를 시작하고 장애물 리스트와 프로세스 개선 계획을 만들 것을 추천합니다.​상황을 고려해 수잔과 CoE팀은 관리 프렉티스(Scrum with Kanban)를 XP(eXtreme Programming) 엔지니어링 프렉티스로 보완하기로 결정했습니다. 목표는 XP 프렉티스를 통한 자동화 품질의 개선에 두었습니다. 적용 범위는 페어 프로그래밍, 테스트 기반 개발, 코딩 표준, 설계 원칙, 코드 검토에서 리팩토링, 공동 코드 소유권, 통합에 이르기까지 다양했습니다.

이 시도가 성공하면서 CoE팀은 Scrum과 Kanban, 그리고 XP를 효과적으로 조합한 애자일 RPA개발 프레임워크를 확보하게 됩니다. 수잔은 이를 XrumBan이라고 부릅니다. 애자일 RPA의 ‘삼위일체’라고 할 수 있죠. 

8. RPA 확장성

지금까지 설명한 사용자 중심의 혁신적 프로젝트 방법의 적용으로 RPA 이니셔티브는 큰 성공을 거두었습니다. 자연스럽게 회사내의 RPA관심과 수요가 급증하기 시작했습니다. 이에 CoE팀은 인력을 충원하고 수요 증가에 대비하기 위해 개발 프로세스를 조정합니다. 또한, 2018년 6명으로 시작한 CoE팀이 2년만에 34명으로 늘면서 아래와 같이 프로젝트 인력의 역할도 재정비하게 됩니다. 수잔은 BizDevOps란 개념을 적용해 업무 역할을 비즈니스, 개발, 운영으로 구분했습니다.

CoE팀 업무 역할 조정 (역할별 상세 내용은 백서 참조) 

RPA 자동화 확산에 대비하기 위해 CoE팀은 다양한 인력으로 구성된 4개의 Scrum팀을 운영했습니다. 복수의 팀 운영으로 업무별 전문화와 업무 유연성이란 장점을 얻게 되죠. RPA솔루션 아키텍트와 테스트는 각 팀마다, RPA 인프라스트럭처 엔지니어와 팀코치는 2개 팀을 지원하게 배정하는 방식이었습니다. 즉, 담당 업무별 특성과 규모를 고려해 인력을 배정했습니다.

CoE Scrum팀 구성 (역할별 상세 내용은 백서 참조) 

​RPA 자동화의 확산을 위한 역할별 재조정과 Scrum팀 운영은 현업 부서 인력들의 자발적 RPA 참여와 확산을 유도하게 되었습니다. 그리고 이는 다시 RPA 프로젝트 확산 과정의 문제점을 최소화하는 효과를 가져왔습니다. 하지만, 가장 중요한 것은 최고 경영진의 투자 결정과 지원을 이끌어 낼 수 있는 수준의 ROI와 가치를 먼저 증명했다는 점입니다. 

9. 거버넌스각 Scrum팀은 마케팅, 영업, 재무 등 부서에 배정되어 해당 부서의 업무 자동화를 담당했습니다. 하지만 상황에 따라 다른 부서의 업무를 맡기도 하고 다른 Scrum팀과 함께 협력하는 경우도 자주 발생했습니다. 참여자가 많아지고 업무가 늘면 자연스레 관리 문제가 대두되죠. CoE팀은 중앙 집중식 및 연합 모델을 적절히 연계한 거버넌스 모델을 채택했습니다. 각 팀들은 거버넌스 모델을 기반으로 한 협업을 통해 여러 부서가 연계된 복잡한 업무의 자동화도 매끄럽게 진행할 수 있게 되었습니다. 또한, 모든 Scrum팀은 한 제품의 백로그를 사용해 업무를 진행했고, 구성원 누구나 해당 백로그 정보를 확인할 수 있게 했습니다. 이는 투명한 업무 정보 공유가 중요하다는 수잔의 생각에 따른 결정이었습니다.

길드 커뮤니티 구성

​시간이 흐르면서 Scrum팀들을 중심으로 비슷한 기술과 관심사를 가진 이들이 모여서 지식을 공유하고 의사 결정을 내리며, 함께 문제를 해결하여 프렉티스를 개선하는 ‘길드’라는 프렉티스 커뮤니티가 형성됩니다. 길드는 보통 2시간 일정으로 특정 주제의 논의와 해결 방안을 찾는 방식으로 운영되었고, 시간이 지나면서 자동화 프로젝트 관련 경험, 정보를 공유하고 RPA 프로젝트 고도화를 주도하는 원동력으로 작동하게 됩니다. 여기에 IT운영팀과 SW 개발팀원들이 참가해 코치 역할을 함으로써 정확한 방향성을 제시하고 상호간 신뢰를 높였습니다. 대부분의 길드는 워킹 그룹으로 이론적 논의보다 실행에 중점을 두고 운영되었기 짧은 기간에 실질적 다양한 성과들을 만들어 냈습니다. 그리고 이것이 구성원들의 지속적 참여를 유도하는 동력으로 작용했습니다.​길드 문화가 퍼지면서 RPA업무 자동화의 경험, 지식, 수행 절차와 협력 방안이 조직 내부에 스스로 자리잡게 됩니다. 유연성이 뛰어난 하이브리드 방식의 거버넌스 모델 이용, 투명한 정보 공유, 현업 사용자 커뮤니티 활성화 그리고 IT운영팀과 SW개발팀 같은 전문가들의 지원이 지속 가능한 프로젝트를 실현한 핵심 요소입니다. 

10. 오케스트레이션 (조율)CoE에 속한 Scrum팀과 구성원이 늘면서 팀 종속성 관점에서 복잡도가 증가하고, 의사 결정 경로가 늘어나면서 세밀한 협업의 필요성이 커졌습니다. 결과적으로 팀 간 종속성, 중복된 업무, 소통 부담 증가 등으로 각 Scrum팀의 RPA 처리량, 품질 및 속도가 떨어지는 현상이 나타나기 시작했습니다. 이에 Scrum팀의 생태계를 효율적으로 조율하기 위한 프레임워크가 필요했습니다. 그래서 도입된 것이 Nexus 입니다. Nexus도입 목표는 Scrum팀 증가와 비례해 RPA 처리량도 같이 늘어나도록 보장하는 것이었습니다.

​Nexus, LeSS, SAFe, Spotify Model, Scrum@Scale 등 여러 프레임워크가 있지만 CoE팀은 Nexus를 선택합니다. ‘연결된 그룹’이란 단어의 의미처럼 Nexus가 Scrum팀간 종속성을 줄이고, 각 팀의 자체 관리와 투명성 유지 및 명확한 책임 소재 등 RPA확산 과정에서 생기는 이슈를 해결하는데 적합했기 때문입니다.

Nexus 방법론 수행 단계

​그럼, CoE팀의 Nexus적용 방법을 간략히 알아보죠. 1단계는 모든 scrum팀 대표들이 참여하는 미팅입니다. 여기서 대상 업무의 전체적 현황 이해, 팀간 작업 할당 및 팀간 종속성을 명확하게 정의하는 작업이 진행됩니다. 2단계는 2주간의 Nexus 스프린트 진행입니다. 이 기간 동안 목표 업무의 로봇을 개발하면서 기술적 종속성이 많은 로봇의 통합을 위해 정기적으로 팀 단위 작업을 조율하고 통합하게 됩니다. 정기적 조율과 통합 작업은 Nexus 일일 스크럼을 통해 진행되는데, 이 작업을 3단계로 분류할 수 있습니다. 스프린트 마지막 날에 4단계 검토 작업을 진행합니다. 작업은 CoE팀 관계자들이 참석하는 현황 점검 회의와 현업 부서까지 참석해 개발 결과물을 점검하고 피드백을 주는 2가지 형식으로 진행됩니다. 마지막 Nexus 스프린트 리뷰 단계에서는 scrum팀 대표들이 모여서 전체적 진행 결과 리뷰, 주요 이슈, 해결 방안과 개선안을 논의하게 됩니다.​이것이 CoE팀이 Nexus를 활용해 RPA개발을 확산한 방법입니다. Scrum전문가 Ken Schwaber (2015)에 따르면 Nexus는 3~9개 규모의 Scrum팀 업무 진행에 적합합니다. 팀이 9개 이상이면 늘어나는 종속성과 통합 이슈로 인해 Nexus 효과가 떨어질 수 있습니다. 

11. 협업모든 조직은 사람으로 구성됩니다. 이 회사의 RPA 이니셔티브도 예외는 아닙니다. 조직은 직능별 부서(예: 영업, 재무, SW개발, IT운영 등)로 분리되어 있었습니다. 각 부서 내부에 권위적이고, 파편화된 프로세스와 문화가 뿌리를 내리면서 부서 이기주의가 만연한 상태였죠. 이는 애자일 방식의 RPA 개발에 필수적인 업무 조율과 협업을 가로막는 장애물이었습니다. 다행히 경영진이 주도하는 디지털 트랜스포메이션 목표도 조직 변화를 통한 이런 조직 장벽의 제거였기에 기존의 계층적 구조와 분산형 관리(holacracy) 구조를 융합해 조직 모델로 전환해 안정적으로 변화할 수 있었습니다.​CoE팀과 리더인 수잔은 디지털 트랜스포메이션의 핵심은 기업 문화의 변화라는 점을 깨닫고, 개별 부서 대신 단일 공동체라는 개념을 확산시키고 이를 기반으로 한 협업 문화를 정착시키는데 중점을 두었습니다. RPA이니셔티브도 부서간 효율적 협업 없이는 달성이 불가능하기 때문이었죠.

협업의 성공 요인

​이런 협업 문화를 정착시킨 방법을 살펴보겠습니다. 우선, 초기부터 시작한 RPA관련 홍보 활동을 멈추지 않았습니다. 지속적으로 RPA인지도를 높이고 실질적 이점을 전달하면서 RPA에 대한 초기 우려와 부정적 인식이 기대와 자동화 수요로 바뀌었습니다. 동시에 현업부서, SW개발, IT운영 등 관련 부서간의 협업 정책과 프로세스를 계속 강화해 RPA 자동화 품질을 높일 수 있었습니다. 또 앞서 언급한 것처럼 RPA이니셔티브 초기부터 꾸준히 경영진의 관심과 지원을 끌어내는데 많은 공을 들였습니다. 경영진의 지속적 지원을 끌어낸 비밀은 우수한 품질의 RPA를 현업에 제공해 만족도를 높이고 투자 가치를 입증한데 있습니다. 여기까지 읽고 나니 어떤 생각이 드시나요? 이슈도 많고 해야 할 일도 많아 보이지만 RPA 프로젝트를 성공적으로 이끌 수 있는 공식들이 좀 더 분명해졌을 겁니다. 다음에는 애자일 RPA방법론의 적용으로 CoE팀과 회사가 얻은 이점을 정리해보겠습니다.