RPA 개발을 6개월 이상하고 다음 스텝을 생각하다 보면 불안해 하는 경우가 많다. RPA 개발자는 다른 개발자들에 비해 진입장벽이 낮고, 기간이 지남에 따라 성장성이 뚜렷하게 보이지 않기 때문이다. 실제로 전반적으로 개발 역량이 떨어지는 분들이나 개발에 적성이 맞지 않는 분들이 IT로는 가고 싶은데 마땅한 분야가 없어 RPA로 시작하는 케이스도 많이 존재한다. 개발자 입장에서 노동시장에서 수요는 엄청 늘진 않아 보이는데 공급이 대단히 많이 늘 것으로 보인다.특히 개발자들 스스로가 '개발자'라는 포지션은 '대체가 어려운 기술자'여야 된다는 생각이 강하다.
본질적으로 이런 사고의 흐름이 아주 잘못되었다고는 보지 않는다. RPA의 벤더사들에서도 최대한 개발자가 쉽게 프로세스를 구성하고 빠르게 수행될 수 있다는 점을 강조하고 있고, Attended User에 대한 수요를 실제 Business Demand로 만들기 위해 현업용 Tool을 따로 개발하는 추세다. 이런 과정에서 'IT 개발자' 포지션에 있던 사람들은 기술에서 멀어지고 궁극적으로 Tutor나 Server Manager 혹은 Module supplier가 되는 것으로 보인다.
이 이야기를 먼저 해보자. IT가 보수를 많이 받는 이유는 무엇일까? 숙련 노동자의 수요 대비 공급이 적기 때문이기도 하지만 한계 생산성[각주:1]이 높기 때문이다. 다른 분야에서는 1명이 3~4명분을 하려면 슈퍼맨이어야 하지만, IT에서는 실력이 뛰어나다면 10명분 이상도 가능한 경우가 심심찮게 보인다. 또 일반적으로 IT분야에서 제공하는 서비스와 Product의 경우 한계비용이 매우 낮기 때문에, 마케팅과 서비스의 수준에 따라 기하급수적으로 생산성이 높아질 수 있다.
그렇다면 RPA는 어디서 생산성이 날까? RPA의 장점은 '프로세스 단위당 생산이 빠르고 유지, 관리비용이 적다'이다. 프로세스 단위 개발이 빠르고 유지, 관리 비용을 적게 하기 위한 기술적, 구조적 구성을 해야 한다. RPA 개발자들은 그런 구성에 필요한 것들을 스스로 찾아보고 숙련될 필요가 있다. 그러나 RPA 개발자들 대부분은 Studio 안에 갇혀, 현업이 얘기하는 요구사항을 drag&drop으로 당장 구성하기에 바쁘다. Project Manager라고 들어온 사람들은 대부분 Project Management에 관심이 없다. 고객사의 심기를 거스르지 않기 위해 고군분투한다. 그런 과정에서 R&R도 명확하지 않고, 분명하지도 않은 요구사항을 받아가며 개발을 하다보니 기술적인 문제가 아닌 업무 프로세스 문제에서 고통받는다.
결국 '생산성이 나지 않는' 프로젝트 진행으로 인해 몸값은 낮아지고, 고객사 입장에서도 RPA의 가성비가 떨어진다. 이에 따라 RPA 개발자 노동 시장이 소위 '레몬 시장'이 된다. 상대적으로 대우가 떨어지기 때문에 기술적인 역량이 좋은 사람일수록 RPA에서 멀어지려고 하고, 이는 RPA 개발자의 노동시장을 더더욱 '레몬 시장'으로 만든다. 이런 시장 상황에서 보통 SI에서 요구하는 역량을 채우는 개발자들은 미래가 불안해 진다.
특히 한국에 있는 대부분의 공급사들, 그 의사결정자들 또한 RPA 비지니스를 어떻게 이끌어 갈 것인가에 대해 제대로된 아이디어가 없다. 관리 명목으로 라이선스를 팔 때 발생하는 마진에 만족한다. 그나마 계속 사업을 유지할 생각이 있는 측에서는 개발자를 투입하지 않아도 판매가 가능한 AR이 더 폭넓게 배포될 날을 기다리거나, 공통 domain이 될 수 있는 소스를 만들어 한계 개발 비용이 0에 가까운 그런 영업을 하려고 한다. 물론 그게 아주 틀린 생각은 아니다. 문제는 본질적으로 제공하는 RPA 거버넌스의 퀄리티에 대한 생각이 결여돼 있다는 것이다. 어차피 개발자들 몸값도 높고 구하기도 힘든 상황에서 퀄리티를 높여봤자 교육, 관리에 리소스만 투입되지 회수를 못 한다는 근시안적인 사고도 깔려 있다.
따라서 생산성을 위한 구성이 아예 없거나 규모 대비 퀄리티가 너무 낮아, RPA 개발자들이 낮은 수준의 데이터 체킹이나 프로세스 정의 체크, 사막에서 바늘 찾는 느낌의 디버그 등을 하며 인간 RPA가 된다. 아직 한국에서는 이 업계의 효율성에 대해 많은 관심이 없고, 정보 비대칭 때문에 상당 수의 RPA PM들은 프리시장의 레몬들이며 그마저도 PM 경험 자체가 거의 없다. 고도화 되지 않은 업계 아키텍쳐, 스킬 Set에 좋지 않은 PM들의 조합 아래 RPA 개발자들은 자신의 IT 적성을 의심한다.
게다가 RPA는 다른 IT분야와는 달리 현업과 관리자, 개발자 모두 역할을 명확하게 인지하고 적극적으로 참여해야 생산성이 높다. 이걸 고객사 혹은 내부 관리자, 결정권자들이 이해를 해야 개발, 구축 과정에 대한 인센티브도 조직할 수 있는데 이걸 이야기하는 영업도 거의 없고 관리자도 없다. 결국 순전히 개발자 입장에서는 현업을 최대한 귀찮지 않게 하면서 최대한 Studio 내부에서 문제를 해결할 수밖에 없는 상황이 자주 온다. '기술자'로서는 해결하기 어려운 상황들에 지치다보면, (적어도 주니어 입장에서는) 상대적으로 기술로 대부분이 해결되는 다른 IT분야로 눈이 돌아갈 수밖에 없다.
2. RPA의 생산성 극대화
RPA는 시스템의 빠른 변화 혹은 시스템의 부재에 손쉽고 빠르게 대응하기 위한 자동화 시스템이다. RPA 관점에서 진행되는 업무는 '프로세스 도출, 적용 검토, 프로세스 표준화, 설계 및 개발, 운영 안정화, 리소스 관리'[각주:2] 등이 있다. 각각의 단계에서 최적화 할 수 있는 예시, 기술적인 발전 방향 등을 간략히 보자.
1) 프로세스 도출
- 이 단계에서는 먼저 현업이 'RPA'의 개념을 알고 있는지, 모른다면 어떻게 전달해야 할지 체크해야 한다.
- 기대효과, 사례 등등을 모은 문서, 영상자료가 있으면 좋다.
- AS-IS를 어떻게 바라보고 정리할지 가이드 해줄 수 있는 PDD나 시나리오 기술 문서 등도 같이 제공하면 좋다.
2) 적용 검토
- 적합도 필터링 기준 양식을 통해 우선순위 선정을 하는 단계이다.
- 기준에는 ROI나 시스템 접근 가능성, 셀렉터 명확성, 시스템 안정성 등을 정량데이터로 지수화하여 포함시킨다.
- 가능하다면 이때 프로세스를 최종 선택하면서 프로세스를 프리징하면 좋다.
- JIRA나 Confluence 같은 업무 관리 툴이 있다면 최종 선정된 과제에 대해 티켓을 발행하여 관리하면 좋다.
- 회의를 한다면 요구사항의 디테일을 살려 회의록을 꼭 작성해야 한다.
- 이 단계와 관련해 현재 Uipath에서는 Automation Hub라는 공간이 있으나 국내에선 자주 활용되진 않는다. [각주:3]
- 기술적으로는 클라우드로 옮겨가면서 다른 앱과의 연동 및 연결 시스템 확장이 계속 쉬워지고 있는 추세이다. [각주:4]
3) 프로세스 표준화
- 선정된 프로세스를 시스템간의 데이터 교환으로 치환해 다른 부서에도 비슷한 업무가 있는지 체크하는 단계이다.
- 프로세스 자체에 살을 붙이거나 혹은 특정 부분이 제거될 수도 있다.
- 이를 위해선 체크해야 하는 정보를 각 담당자로부터 얻을 수 있는 관리자와 Contact이 필요하다.
- 이 과정에서 사용할 수 있는 모듈도 함께 체크하면 좋다.
- 과제 리소스 관리 리스트나 모듈 관리 리스트, Repository 혹은 설명서 등을 만들어 관리해야 규모가 커지는 것에 대비할 수 있다.
- 이 단계는 각 RPA 벤더들의 Marketplace에서 기본적인 것들을 제공하려고 하고 있고, 규모의 경제가 있는 부분이다. 한국의 RPA SI업체들은 이런 부분에서 빠른 기업 솔루션을 제공하는 형태를 고려하고는 있지만, 구체적으로 진행되는 곳은 아직 못 봤다. 기업 전반의 업무에 대한 도메인 지식이 많이 필요하리라 본다.
4) 설계 및 개발(테스트 포함)
- 이 단계에서는 설계 및 개발을 한다.
- 설계 전에 이 프로세스의 시스템을 확인하고 관련 모듈이 있는지 체크한다.
- 설계문서는 초보일수록 웬만하면 전수 작성하는 것이 좋다. 조각설계도 안 되는데 프로세스 전체를 설계없이 진행할 수는 없기 때문이다. 특히 설계 과정에서 프리징이 필요한 사안들이 꽤 나오기 때문에 앞선 단계에서 프로세스 프리징을 못 했다면 여기서 진행해야 한다.
- 커스텀 프레임워크가 있으면 좋다. 같은 프로젝트에 투입될 인원 또는 같은 회사 개발자들끼리 논의를 거쳐 필요한 사안들을 정하고 구현되게 하는 걸 추천한다. RE프레임워크는 비지니스 관점에서는 모자란 측면이 꽤 있다.
- 모듈은 각 개발자별로 시스템 접근 소스나 보편적으로 쓸만한 것들을 등록, 관리할 수 있게 Repository를 만들자.
- 1년 미만 개발자들이 많으면 1주일에 한번, 2주일에 한번 세션을 열어 서로 자주 쓰는 패키지, 팁 등을 공유하면 좋다.
- 현업 검증 후 개선이 필요할 수 있으므로 진행상황에 따라 빠르게 현업과 소통해야 한다.
5) 운영 안정화
- RPA 프로세스를 운영에 등록하고 수행을 관리하는 단계이다.
- 보통 각 과제 운영에 대한 히스토리 문서를 두면 좋다. 각각 둘 필요는 없고 하나의 엑셀로 과제별 시트를 만들어 관리하는 게 합리적이다. 과제의 난이도나 복잡성에 따라 차이는 있지만 대략 1인당 30~60개 정도를 관리하는 편이다.
- 각 Bot Device의 세팅 및 특이성에 대해 기록해야 하고 관리해야 한다.
- 주기적으로 변경되는 Credential에 관해 최근 변경 기록을 관리하면 사전에 어느 정도는 대응을 할 수 있다.
- Bot에 대한 트러블 슈팅, 프로세스에 대한 트러블 슈팅을 각각 해줘야 한다.
- 과제별 '우선순위' 관리를 해주는 것이 효율적이다.
- OCR의 경우 오케스트레이터 같은 곳에서 기준 스코어에 따라 사용자가 데이터를 확정해주는 케이스도 있을 수 있다.
6) 리소스 관리
- 라이선스가 얼마나 필요한가, Device는 얼마나 필요한가, Credential의 추가 발급 혹은 삭제가 필요한가 등 연결된 리소스 관리를 하는 단계이다.
- 특별히 운영 이후의 단계라기 보다는 전반적으로 시스템을 유지하기 위한 단계이다.
- 운영에 적절한 리소스를 공급해줘야 추가 개발이 운영으로 마이그레이션 되는 과정을 스무스하게 연결할 수 있다.
- 특히 우선순위가 높은 과제들을 스케줄 표에서 신경써서 배치해야 한다.
- R&D를 통해 운영에 적용하고 개발 Cost를 줄일 수 있는 부분이 있는지 체크도 필요하다. [주기적인 Docs, 릴리즈 노트 체크, 신기능 구현 등]
3. RPA 개발자로서 필요한 자질
RPA 개발자는 위와 같은 과정 전체를 주관할 수 있게끔 성장해야 한다. 다른 IT분야와 마찬가지로 기본적인 스킬 set을 갖춰야 하지만 그 최소 기간이 다른 분야에 비해 짧은 편이므로, 전체 아키텍쳐와 개발 환경, 개발 과정에서의 커뮤니케이션에 신경을 쓸 필요가 있다. RPA 전체의 프로세스를 인식하고 빠르게 성장하면, 퀄리티는 크게 높지 않더라도, 2년 정도 충실히 갈고 닦으면 위의 과정들을 어느 정도 구성할 수 있지 않을까 싶다.
RPA가 구축된 대부분의 사이트는 위의 관리포인트, 개발포인트들을 제대로 체크하지 않고 관리한다. 제대로 일을 관리하는 환경이 아니다. [각주:5] 제대로된 개발을 하기 힘든 상태라면 RPA 프로세스에서 어떤 부분이 문제인지, 해결할 수 있는 부분이 있는지를 체크하고 최대한 정상화를 시키자고 제안할 용기도 필요하다. 그 과정에서 위의 프로세스를 인지하고 하나씩 채워나가면서 자신이 해보지 않은 빈 부분을 서서히 메꿔가는 게 좋다. RPA는 어디까지나 다른 시스템을 활용하는 조직에 가깝다.
RPA 개발은 생각보다 아무나 할 수 있지 않다. 생각보다 다른 분야와도 호환성이 높아서, 개발 잘하는 사람이면 RPA에 들어와서도 금방 적응하고, RPA 개발을 잘하는 사람은 다른 언어에도 꽤 빠르게 적응한다. 어디까지나 문제를 잘 해결하려면 현황을 인식하고 원인을 추정, 해결을 기획해야 한다. 이걸 당장 코드로 구현할 수 있느냐보다 문제 해결과 재발 방지에 얼마나 빠르게 도달하느냐를 염두에 두고 성장하면 좋다. 결국 비지니스적으로 어떤 성과를 낼 수 있을지를 고민하면서 요구사항을 받아들여야 코드 몽키가 아닌, 유망한 개발자가 될 수 있고 이건 어느 분야든 마찬가지인 거 같다.
여기서 한계 생산성이란 고용 1단위에 대해 추가로 발생하는 최종생산물의 부가가치이다. [본문으로]
전사 관점에서는 KPI나 연결 조직 관리도 포함되나 이건 결정권을 가진 C레벨에서나 따로 이야기할 수 있는 사안이다. 어디까지나 RPA 개발자 측면에서는 이런 흐름으로 진행된다. [본문으로]
개인적으로 2021년 초반에 체크해봤을 땐 기준들을 뭉뚱그려 놓은 느낌이라 커스텀 기준을 활용하고 소통하는 데 큰 장점이 있어 보이진 않았다. [본문으로]
대표적으로는 Uipath의 Integration Service가 있다. 아웃룩을 사용한다면 메일 체크 프로세스는 따로 만들지 않아도 되는 상태. 각 시스템에서 과제를 트리거링하기 더 쉬워졌다. [본문으로]
물론 이건 RPA만 그렇다고 보긴 어렵다. 다만 RPA가 유독 심한 것은 사실이다. 실질적으로 몸값이 3년 전 대비 반값 수준이기 때문이다. [본문으로]
