기본 콘텐츠로 건너뛰기

일본에선 채소가게에서도 하는 RPA를 한국에선 안되는 이유.

듣기 버전 : https://youtu.be/cl20TO-a0IQ



한국에서 RPA가 확산될 수 없는 이유..

RPA란 Robotic Process Automation이라는 용어입니다.
소프트웨어 로봇이 업무를 자동으로 처리해준다는 것이지요.

원래는 Automation anywhere과 WinActor, Control-M 등이 선점한 업무 자동화 시장을
Microsoft가 판도를 바꾸었지요..

WWF, windows workflow foundation이란 무료 엔진을 공개 했습니다.
이 무료 엔진은 visual studio에서도 연결해서 만들 수가 있지요.

이건 무료 엔진이라 UiPath사가 제일 먼저 도입해서 RPA툴을 만들었습니다.
UiPath는 초기 5000억원이라는 경이적인 투자액을 받아 한 번에 이름을 날리며
RPA 시장에 뛰어들어 기존의 Automation Anywhere, WinAutomation이나 WinActor, Control-M등의
강자들을 누르고 세계 RPA 1위에 등극하였습니다.

그러자 베트남의 FPT 소프트웨어가 이걸 보고
akabot이란 툴을 만들어 UiPath가 이미 깔린 기업에
리플레이스 영업으로 시장을 키워 갔지요.

어짜피 같은 엔진이라 UiPath에서 만든 xaml파일을 akabot에서 다시 실행이 가능했거든요.
치사하지만, 시장은 가성비의 경쟁이니까요..




MSDN의 WWF의 state machine이란 개념입니다.



UiPath의 state machine설명 이미지 입니다.



Akabot의 state machine설명 이미지 입니다.
너무 똑같지요?
당연히 엔진이 같은데 제로부터 새로 UI를 만들기엔 너무 방대해서 툴의 레이아웃만 파랗게 빨갛게 만들고 버튼 배치 정도만 바꾸고 상품을 출시한 것이지요.

MS가 지속적으로 Update하는 다양한 버그 픽스나 기능 업그레이드를 따라오는 속도를 커버하지 못하면 이 엔진을 사용하기 힘들지요.. 그 만큼의 기술력은 필요합니다.
그런 단점보다 엄청나게 강력한 엔진을 무료로 주니 받아 써야지요..

Microsoft는 왜 이런 강력한 엔진을 공개 했을까요?
전에 제가 MS가 Apple을 보고 플랫폼에 대해서 다시 생각했다고 했지요?

이미 플랫폼이 무엇인지 아는 MS는 플랫폼은 무료로 뿌리려고 합니다.
때문에 WWF를 무료로 뿌리면 그 엔진을 기반으로 유로로 팔든 무료로 뿌리든
시장은 넓어집니다.

그 속에서 Marketplace를 열고 커스터마이징된 xaml을 모듈화 시켜서 판매하는 시장을 열었지요.
때문에 UiPath나 Akabot을 설치하면 무조건 Microsoft Marketplace가 표시되구요,
Marketplace에 컴퍼넌트로 팔 사람들은 반드시 visual studio에서 만들어서 올려야 합니다.

그럼에도 불구하고 WWF를 탑재한 소프트웨어는 MS에서도 지원을 해주어 커져갔습니다.
그래서 시장은 매년 엄청나게 커지고 있지요.

그런데 한국은 어떨까요?

한국에서 RPA관련 영업차 많은 대기업에서 미팅을 했었는데요..

RPA를 무슨 완벽한 대체인간 마냥 알고 있더라구요..

어떤거냐면..

RPA자체는 사람이 하는 데스크워크를 대신 작업을 해주는 소프트웨어 로봇입니다.
사람이 하던 마우스, 키보드 조작을 이젠 Robot이 화면을 인지해서 조작하는 것이거든요..
사람이 로봇은 사람이 시키는 것 만을 하고,
사람이 지정하지 않은 예외가 발생하면 멈출 수 밖에 없습니다.
하지만, 한국의 모 ailabs에서 설명을 해주다보니 이런 이야기를 하더라구요..

문제가 생기면 어떻게 책임질거냐..
중간에 멈추면 다시 사람이 해야 하니까 있으나 없으나 같은거 아니냐..

그래서 제가,
사람이 하는 영역을 사람없이 도와주는거 뿐이지,
나온 문제에 책임을 지는게 RPA가 아니라고 하자,
책임도 안질거면 도입하는 의미갸 없지 않느냐며
거절 당한 적이 있습니다.

RPA를 도대체 뭐라 생각하는지 모르겠네요.

닛츠 라는 일본 최대의 물류회사에서 하는 RPA를 이야기 해봅니다.

닛츠는 UiPath라는 툴을 이용해 연간 160만 시간의 인간의 작업을 로봇이 해주고 있습니다.
즉, 833명을 1년 동안 안써도 되는 분량이구요,
사람은 틈틈이 휴식도 하고, 하루에 8시간을 풀로 일하지 않는 경우가 더 많잖아요?
로봇은 24시간 일을 불평없이 일을 해줍니다.
데모도 하지 않구요,
딴짓도 하지 않습니다.
인사관리나 복리후생 같은 고민을 할 필요가 없습니다.
그걸 떠나서..

RPA는 예외상황을 모두 기록하지 않으면 데이터베이스에 없는 예외상황은 멈춥니다.
그게 또 안전하구요..
머신러닝으로 예외 상황을 학습해서 어떻게 해라 라고 할 수도 있겠지만,
이런 경우는 이런 상황 아니면 일단 멈춰 하는게 낫습니다.
그리고 일본의 매뉴얼 중심의 업무 시스템에는 RPA의 도입이 아주 쉽지요..
매뉴얼에는 하면 안되는 상황을 기록하는 것보다
매뉴얼에 없는 상황이 발생하면 상사에게 보고하라는 내용이 대부분이거든요.

예외상황에 RPA가 멈추면 그 동안 해왔던 작업자가 일을 더 하면 되는겁니다.
즉, 작업자 10명 쓸 작업을 한 명이 쉬엄쉬엄 자기일을 하면서 지켜보다가
로봇이 멈추면 재개할 때까진
그 일을 할 수 있는 사람 한 두명 더 추가하여
수동으로 메꾸다가 로봇이 재개하면
다시 사람은 쉬는 그런 방식입니다.

전국 4000여개의 지점의 모든
피씨와 장치, 프린터, 팩스 등등의 전자 장치를 전부
UiPath가 중앙에서 각자 역할을 정의해서 보내면
각 지점에선 피씨가 혼자 마우스, 키보드를 움직여서 작업하고,
작업결가 전표로 출력되면 그걸 각
상자에 붙이고 드라이버에게 전달히는 정도의 일을 합니다.

닛츠의 RPA팀은 총 12명입니다.
12명이 833명분의 일을 해주고 있는 것이지요.
기업으로 보면 엄청난 효자 팀인 것입니다.
게다가 앞으로 업무량은 늘지만 12명의 인원이 더 늘지는 않습니다.

이렇게 하는데도 미즈호 은행에 뒤쳐진다며
200만시간을 줄이는게 이번 목표라고 하네요..
일본은 경쟁적으로 인간의 업무시간을
RPA에 넣으려고 총력을 기울이고 있습니다.

이렇게 다른 전제 속에 RPA시장은 달라지고 있지요.

아마 한국에서 RPA사업을 제안하셨거나 참여하신 분들은
갑들의 꽉막힌 생각에 답답하신 분들이 계실겁니다.

일본에선 지난 번에도 말씀 드렸듯이
채소가게 아주머니도 UiPath로 DX를 합니다.
자동차 정비소에서도 RPA로 업무를 지원합니다.
KDDI에서는 1인 1로봇을 만들라는 회장님의 지시로 대대적인 전사원 교육을 하고 있습니다.


KDDI 이야기가 나와서 또 제자랑 해봐야죠.. ^^;;

KDDI 본사의 RPA교육을 하러 제가 들어갔을 떄의 이야기 입니다.
RPA의 위대함을 우선 전 사원에게 각인 시키기 위해 샘플을 만들어 줘야 했는데요..

이 떄 KDDI직원들이 이건 못하겠지 하고 준 것이
직원의 휴가계를 받는 시스템에서 csv로 떨군 데이터와 종이로 낸 휴가계를 OCR로 읽어
모든 휴가 처리를 전혀 다른 Java로 만든 시스템의 ERP에 입력해 주고
그 중에서 일반 사원은 연 5일, 과장 이하는 0.5일씩 쉰 거는 제하고 0.5일, 그리고 부장 이상은 제외로
연간 5일 이상 안쓴 사람에게 남은 필수 휴가와 휴가를 쓰라는 안내를 매달 자동으로 보내는것을
RPA로 해달라고 했습니다.

2일동안 요건을 분석하고
3일동안 UiPath로 혼자 만들어서 시연을 했는데,
업무 처리를 하다보니, 지난 달에 보냈던 사원 목록이랑
RPA가 처리했던 지난달의 사원 목록을 대조하다가,
각 부서의 인사 담당자들이 오타나 계산 미스로 잘못 기입된
사람들까지 찾아내져서 이슈가 된 적이 있지요..

원만하게 사람들이 실수해도
로봇이 찾아주니까 더 안심하고 일을 할 수 있게 해주는게 RPA라고 했지만,
아마 사원들은 이제 RPA가 자신들의 실수를 감시하지 않을까 불안해 했다는
웃지못할 실제 이야기가 있긴 합니다.





RPA는 현재 초기 시장으로 가파르게 성장하고 있습니다.
이들은 인간보다 빠른 속도로
그 동안 인간 밖에 못한다던 업무들을
하나하나 잠식하고 있습니다.

한국에 도입된 RPA는 지금 무얼 하고 있을까요?




giip :: Control all Robots and Devices! Free inter-RPA orchestration tool! https://giipasp.azurewebsites.net/

댓글

이 블로그의 인기 게시물

Alter table 에서 modify 와 change 의 차이 :: SQL Server

두 개의 차이를 모르는 경우가 많아서 정리합니다.  modify는 필드의 속성값을 바꿀때 사용하구요.. change는 필드명을 바꿀떄 사용합니다.  alter table tbbs modify bNote varchar(2000) NULL; alter table tbbs change bNoteOrg bNoteNew varchar(2000) NULL; change에는 원래 필드와 바꾸고 싶은 필드명을 넣어서 필드명을 바꾸는 것이죠~ 더 많은 SQL Server 팁을 보려면  https://github.com/LowyShin/KnowledgeBase/tree/master/wiki/SQL-Server giip :: Control all Robots and Devices! Free inter-RPA orchestration tool! https://giipasp.azurewebsites.net/

책에서는 안 알려주는 대규모 트래픽을 위한 설계

음성 버전 :  https://www.youtube.com/watch?v=ZZlW6diG_XM 대규모 트래픽을 커버하는 첫 페이지 만드는 법..  보통 DB를 연결할 때 대규모 설계는 어떻게 하시나요?  잘 만들었다는 전제 하에 동접 3000명 이하는  어떤 DBMS를 사용해도 문제 없이 돌아갑니다.  여기서 이미 터졌다면 이 콘텐츠를 보기 전에 DB의 기초부터 보셔야 합니다.  아.. 개발 코드가 터졌다구요? 그럼 개발자를 때리셔야지요..  만약 3000명을 넘겼다면? 이제 Write/Read를 분리해서  1 CRUD + n개의 READ Replica를 만들겠죠?  보통 Read Replica는 5개가 최대라고 보시면 됩니다.  누가 연구한 자료가 있었는데...  6번째 레플리카를 만든느 순간 마스터가 되는 서버의 효율 저하 때문에  5번째에서 6번쨰로 올릴때의 성능이 급격히 줄어든다는 연구 결과가 있습니다.  때문에 Azure에서도 replica설정할 때 5대까지 밖에 설정 못하게 되어 있지요.  유저의 행동 패턴에 따라 다르긴 하지만,  1 CRUD + 5 Read Replica의 경우 동접 15000명 정도는 커버 합니다.  즉, 동접 15000명 에서 다시 터져서 저를 부르는 경우가 많지요..  이 때부터는  회원 DB, 게시판DB, 서비스DB, 과금 DB 등등 으로 성격, 서로의 연관도에 따라 나누기 시작합니다.  물리적으로 DB가 나눠지면 Join을 못하거나 Linked Table또는 LinkDB등의 연결자를 이용해서 JOIN이 되기도 합니다.  그에 따라 성능 차이가 생기지만 가장 중요한 포인트는  서로 다른 물리적 테이블의 JOIN은 인덱스를 타지 않는다!  라는 것입니다. 즉, JOIN할 테이블들을 최소한으로 만든 뒤에 JOIN을 걸지 않으면 NoSQ...

BI의 궁극판! Apache Drill을 써보자!

사실 Apache Drill 은 BI(Business Intelligence)라고 부르는 것 보다는 단순 데이터 연결 엔진이다. https://drill.apache.org/ 하지만 내가 왜 극찬을 하느냐면.. DBA로서 항상 문제가 되어왔던게, 이기종 데이터의 변환이나 처리였다. 포맷을 맞추는데 엄청난 시간이 걸리고, 데이터 임포트 실패가 무수하게 나고.. 한 번 잘못 데이터를 추출하면 다시 조정, 변환, 추출하는데 시간이 많이 걸린다. 그런데! Apache Drill은 그냥 RDB를 CSV랑 연결해서 조인해서 통계를 낼 수 있다. 그것도 표준 SQL을 사용하여! 예를 들어, CSV의 세 번째 컬럼이 price 이고, 물건의 판매이력을 PG사에서 CSV로 출력 받았다. 우리 DB와의 검증을 위해서는 수동으로 Import를 한 뒤에 포맷이 안맞아 잘리는 데이터가 있다면 다시 맞춰주고, 재 임포트를 수십 번, 그리고 나서 겨우 들어간 데이터를 조인하여 빠진 데이터를 분간한다. 숫자가 적다면 개발자가 개발로 처리할 수도 있지만, 건수가 하루에 300만건 짜리라면.. 한 달 온 파일은 9천만 건이다. 프로그램으로 고작 처리하는 것이 초당 500건. 거의 20만초, 에러 없이 약 56시간.. 에러가 생기면 다시 56시간.. ㅠㅡㅠ 이런게 현실이기 때문에 쿼리 말고는 방법이 없다. apache drill 의 진면목을 보자! 이번에는 좀 범용 적인 MySQL DB와 붙여 보자. . 난 이번에는 Mac에서 작업을 했기 때문에 그냥 다운 받아서 풀었음.. https://drill.apache.org/download/ 여기서 자기 OS에 맞는 버전을 받아서 설치하시길.. 압축을 풀고 나면 MySQL 커넥터를 붙여야 한다. https://dev.mysql.com/downloads/connector/j/5.1.html 여기서 다운로드 이런 커넥터 들을 붙일 때마다 콘피그를 수정해 줘야 하지만, 몇 번만...