1. 개요[편집]
Robotic Process Automation의 약자. 현재는 데이터 입력 등의 단순 반복 업무 프로세스의 자동화에 주로 적용할 수 있다. AI, 머신러닝 등의 기술이 발전하면 IPA 또는 CA[1] 라는 기술로 발전할 수 있다. 사무직들 일자리 날라가는 소리 들린다
기존의 Robot이 공장 생산 라인의 실체적 기계였다면 RPA는 Software로 사람이 하는 일을 단순반복적인 일을 하는 Robot으로 이해하면 쉽다.
2. 상세[편집]
2019년, 지금도 점차 적용하기 시작하는 프로그램이다. 노령화가 심한 일본에서는 우리나라보다 더 활발하게 적용하고 있다. 우리나라의 경우, 이미 여러 대기업에서 RPA를 적용하였으며 자동화 대상 업무를 늘려가고 있다.
현재 일상적인 회사 업무에서 가장 손쉽게 적용 가능한 부분을 간단히 설명하자면,
1. ERP시스템에 있는 데이터를 다운로드 하여 엑셀로 정리
2. 엑셀 혹은 텍스트 기반의 데이터를 ERP에 입력….이라고 할 수 있다.
즉, 특히 회계 경리 혹은 생산관리분야에서, 대량으로 단순, 반복적으로 하는 업무에 적용하는 것이 가장 쉬우며, 여기에 OCR등의 프로그램을 이용하면 PDF 자료등의 문자를 인식 입력하는 것도 가능하다. (단, 한글 기반의 경우 OCR의 인식률이 떨어진다는 것은 참고요망)
가장 큰 특징으로는 Diagram이나 Tree구조등의 GUI로 되어 있어, 기존 컴퓨팅 언어로 업무자동화를 진행하는 경우, IT비전공자가 코딩을 배워 실제 본인 업무에 적용하는 것이 쉽지 않지만, RPA 툴의 경우 비교적 간단한 관계로, Operator가 1주~1달가량의 교육을 받은 후 (IT팀의 서포트가 어느정도 있다면) 직접 개발 및 기존 프로세스의 수정 개선이 가능하여 비전공자의 접근성이 좋다.
(케바케지만, 가령 이미 ERP가 노코딩 또는 로코딩으로 화면을 만들 수 있고 API로 자료를 수집, 데이터베이스 또는 Storage같은 곳에 자료 저장, 실시간 또는 배치를 활용한 주기적으로 자료 처리, 이메일, API를 활용하여 자료 전송, API로 OCR, 번역 등 AI시스템과 연동한다면 ERP가 곧 IPA 또는 CA라고 부를 수 있기 때문에 위와 같이 엑셀 또는 ERP같이 다른 응용프로그램의 화면에 의존하는 RPA는 굳이 필요하지 않다.)
RPA가 가장 활발하게 적용되고 있는 분야가 바로 BPO(Business Process Outsourcing) 시장이므로, 특히 영어권 국가의 IT Outsourcing 중심지인 인도가 많이 사용하고 있어 Youtube에서 Tutorial을 검색하면 인도 발음의 영어로 된 자료들을 볼 수 있을 것이다.
(여담으로 장기적 관점에서, 기존의 단순반복적인 대량의 오피스 업무를 인건비가 싼 인도에 Outsourcing을 하였으나, Robot이 자동으로 처리해 준다면 해당 업무가 다시 이전의 Country 본사로 돌아가게 되어 전체 BPO시장에는 악영향을 미칠 수 있다는 연구도 있다.)
단, 국내 도입시에 걸림돌이 될 수 있는 부분은 위에 언급했듯, 영어권 Global회사의 시스템을 기반으로 만들어진 관계로
1. 기술적 관점에서, SAP, Oracle등이 아닌 국내 ERP 시스템 혹은 회사 자체 개발 ERP의 경우 RPA 프로그램과의 연계가 문제될 수 있다
(심지어 SAP경우도, 실제로는 별도의 SAP Mode가 있어 SAP상의 각 메뉴 단추를 자동으로 인지하여 Tool개발을 간단하게 할 수 있도록 서비스를 제공중이나, 그 역시, SAP 메뉴의 세부내역에 들어가면 전체 Range를 인지하지 각각 세부내역을 인지 못하여 결국 몇 Process Step은 수동으로 처리해야 되는 경우도 생길 수 있다. (단, RPA tool들이 개발된 기간을 생각한다면 이러한 문제들은 Version 업에 따라 머지 않은 시기에 해결될 수 있을 것이다.))
2. 문화적 관점에서, Global 기업의 경우 거의 모든 Report가 Mail기반인 관계로, 예를들어, 전체 업무 Flow상,
- 타 부서로 부터 메일을 통해 txt 혹은 엑셀 파일로 시스템 입력 자료 접수 → b. RPA 통해 시스템에 입력 → c. Daily Report의 경우 RPA로 시간 지정을 한하면 어제 입력된 일일 전체 내역을 지정된 시간에 자동 다운로드 및 엑셀표로 레포트 작성 → d. RPA로 지정된 Manager에게 자동으로 메일 발송 및 보고 완료 → e.Manager로 부터 결재 메일 회신…, => 이 전체 프로세스중 (b)~(d) Part에 RPA 적용이 가능하지만….,
아직 대면 보고가 일반적인 한국 기업인 경우 위의 Process 중에서 오직(b)파트만이 RPA 적용이 가능한 관계로, Global기업에 비해 활용도가 제한적일 수밖에 없다. (간단히 말하자면, 시스템 입력은 자동으로 어제 이미 완료 했는데, 정리된 Report는 직접 출력하여, 부장님이 자리에 있는 시간 혹은 부장님 기분에(?) 맞추어 24시간 후에나 결재도장을 받을 수 있는 현실이 발생한다.)
실제로 개발 진행을 하다 보면, Operator는 전체 프로세스의 개선을 생각하지 않고 부분적인 (예를 들어 위의(b)part에서도 일부분만) 자동화만을 IT팀에 요구하고, 그러다 보면 결국, 개발후에도 기존 전체 프로세스상의 비효율적의 부분이 표출될 수밖에 없으므로, 개발 진행 전 전체 업무 프로세스에 대한 재평가가 꼭 필요하다. (그 점이 RPA와 단순 매크로 사이의 중요한 차이라고도 할 수 있으며, 고객사 혹은 Operator의 이부분에 대한 이해도가 개발후 결과물에 큰 영향을 끼치게 된다. Ui Path Korea 장은구 대표의 프레젠테이션을 참조하면, (RPA 특성상 본인 업무에 바로 적용하기 쉬우므로) 얼마전만 하더라도 작은 것부터 시작하여 크게 적용하자는 Idea였으나 (Bottom-up), 내부저항 및 전체 Process상의 부서간 업무조율등의 문제로 Top-Down방식으로 접근해야 한다는 목소리가 우리보다 1~2년 일찍 RPA를 도입한 일본에서 나오고 있다고 한다.)
반대로, 전체 프로세스를 가장 잘 이해하는 것도, 실제 운용하는 것도 Operator팀이므로, 위에 상술했듯 전체 Work flow를 이해하고 있는 경험이 풍부한 Operator팀원이 직접 프로젝트를 리드하거나, 회사 전체 Process 부분이 완료된 후, 부서별 세부 Process는 Operator가 사용하면서 장기적으로 직접 개선해 나가며(내재화) 가장 본인이 입맛에 맞는 프로세스를 개발할 수 있는 것도 사실이다. [이 점은 결국, 회사 규모 혹은 업무성격/RPA 프로세스 개발의 복잡성에 따라 케바케일 수밖에 없다]
아래의 외국계 3대 RPA 업체의 경우 RPA Market이나 자사 홈페이지에 다른 개발자가 개발한 프로세스를 올려놓아 무료 혹은 유료로 다운받아 사용이 가능하다. (만약, 사용하는 시스템이 같다면 개발시간을 많이 단축할 수도 있다)
유튜브 Upload 시기를 보면, 대부분 17~18년부터 급성장하고 있는 시장이므로, 단순 회계 입력 분야를 떠나 Cognitive, AI등과 접목하여 이미지 분석등 다양한 분야에 개발이 현재 진행중인 관계이다.(물론 이런 건 개발 비용이 관건이므로 대기업 위주일 수밖에 없으며, 또한 AI, 머신러닝등은 아직 관련 기술이 미성숙 단계로 제한적 사용일 것으로 예상하는 것이 낫다.)