개발 갈무리

올해도 RPA 전망을 써보려고 한다.

올해의 가장 큰 특징은 '본격적인 AI기술 도입에 대한 수요 급상승 예정'이다.

1. 한국 시장의 현황

- 한국 시장은 내부 관리자가 RPA를 주도하지 않는 이상, 하청업체에서의 SI는 완전히 영업을 잘못하는 경우가 많다. 실제 과제와 요구사항에 대한 분석없이 기간과 맨먼스로 판매하면서 개발자의 몸값은 Discount하며 경쟁하고 있다.

- 따라서 ROI는 여전히 나오지만 RPA SI 하청업체 입장에선 부가가치가 크지 않다. 몸값은 낮춰놨는데 맨먼스 계약을 하기 때문에 개발자는 그 기간동안 배치를 해야되고, 개발자도 빨리 개발을 마치고 나올 유인이 없다. 영업은 최대한 고객이 만족할만한 기간동안 과제 개수를 많이 채워준다고 하고 계약한다.

- 문제는 고객사 입장에서는 퀄리티를 판단하기 어려우므로 싼 업체를 선택하고, 교육받지 않고 체계적이지 않은 업체들이 들어와 기간만 보내다 철수한다. 이 경우 RPA에 대한 긍정적인 경험을 갖지 못해 후속 프로젝트를 진행하지 않는 경우가 많다. (다른 IT 분야에 비해 이런 경우가 더 잦은 이유는 환경변화에 민감하기 때문이다.)

- 결국 RPA는 앞단에서 제대로 컨설팅되고 PI가 제대로 진행되어야 큰 힘을 발휘할 수 있는데 IT영업단에서는 치킨게임을 하기로 결정한 모양새다. 궁극적으론 빠른 컨설팅 이후 예산에 따라 프로젝트 규모를 제안하는 형태로 계약 프로세스가 바뀌어야 한다고 본다. 이를 위해선 공수, 난이도 관련 기준이 명확해져야 한다.

- 드물게도 전문적인 내부 관리자가 RPA를 주도하는 경우, 과제 개발 속도를 맞추기 위해서만 하청업체를 선택하는 편이다. 진행의 실제 성과가 내부 관리자의 성과가 되기 때문에 PDD나 요구사항이 제대로 갖춰지지 않은 경우, RPA에 적합하지 않은 과제인 경우 필터링하여 진행한다. 다른 사이트는 이런 필터링이 전혀 없이 개수와 맨먼스만 언급된 계약이므로 필터링할 이유가 없고 실제 개발 과정에서 지연 사유가 된다.(이는 하청업체 입장에서 더더욱 RPA의 부가가치가 안 된다 판단할만한 사항이다.)

- 작년 중반부터 나름 대기업, 중견기업들의 DU수요가 있었고 프로젝트도 진행되었다. 다만 아직까지도 '그 과제가 전사 입장에서 진짜 DU가 필요한 과제였나'에 대해선 개인적으로 PI가 부족했다고 느끼고 있다. AI 도입이라는 사내 성과를 얻기 위한 도입 수요가 많은 게 아직까지의 현황이다. ['꼭 DU가 필요한 과제'에 관해선 추후 정리 예정]

2. 전망(한국 시장 및 기타 기술 동향)

- 현재 MS, SAP, IBM 등이 공격적으로 RPA 시장에 뛰어들고 있다. 결국 RPA가 IA측면에 녹아들어야 하는데 지금 뛰어든 업체들은 그런 부분에서 강점이 있는 편이다. AA와 Uipath는 2025년까지 꽤 치열하게 주도권 방어를 해야하지 않을까 싶다. (한국에서는 AA가 많이 밀린 상황으로 보인다. 현재 AA는 독자노선으로 툴을 Web Base[Java기반]으로 변경하며 User Friendly로 노선을 잡고 있는데, 국내에서는 아직 느리고 이슈가 많다고 판단하고 있다.)

- Global Main업체인 AA, Uipath, Blue Prism은 각각 AI기능, 클라우딩 기술 관련 기능, 과제 발굴 및 정의 통합 패키지를 주로 신경쓰면서 Product를 내놓고 있는 중이다.

- 중국쪽 RPA시장이 커지고 있다고 한다. 특이한 것은 중국의 경우 RPA를 먼저 도입하고 AI를 도입하는 게 아니라, AI를 도입하다가 RPA를 도입하는 경향이 있다.

- 작년의 전망글에 App과의 Integration을 묻는 댓글이 있었는데, 기존 지배적 지위를 누리던 소프트웨어의 개발사들이 RPA시장으로 뛰어들면서 그런 류의 통합이 꾸준히 일어날 수도 있는 환경이 되고 있다.

- Document Understanding(DU)이 2021년 10월 기준으로 stable하지 않나 판단하고 있다. 다만 아직까지 과제 적합성 판단, 가격, 이를 운용하기 위한 서버 스펙 등이 진입장벽으로 작용하고 있다. 웬만하면 2022.4부터는 기술적인 문제는 많이 해결될 예정이므로 2022~23년에는 본격적으로 대기업들이 DU를 도입하지 않을까 생각한다. 꼭 DU가 아니더라도 RPA가 머신러닝 모델링을 위한 데이터 수집 및 전처리를 위해 쓰일 가능성도 있다.

- 공공기관, 공기업에서는 Brity Works 도입에 한창 열을 올리고 있다. RPA를 도입하긴 해야되는데 국산툴을 찾다보니 나오는 결과다.(삼성SDS, KT DS, 그리드원 정도의 삼파전인데 아무래도 삼성이 유리하다.) 삼성그룹 내부 계열사에도 Brity Works 단가를 낮춰 배포에 열을 올리고 있지만, 아직 툴이 상대적으로 불안정하고 커뮤니티가 좁아 불편을 느끼고 있는 것으로 알고 있다. (개발자 입장에선 내부 flowchart내 sequence를 자유자재로 바꿀 수 없고, 복잡한 얼개를 짤 때 구조 파악이 힘들면서, 사용할 수 있는 라이브러리 풀도 좁다는 게 가장 큰 불편함이다.) 이외 금융권이든 제조업이든 무관하게 사기업쪽에선 Uipath의 비율이 지배적이다.

- RPA 국내 수요 증가는 작년에 비해선 완만해진 분위기다. 그래도 여타 4차 산업혁명 라벨을 붙일 수 있는 산업중에선 가격이 싼 편이기 때문에, 중소기업에서도 꾸준히 문의가 들어오는 것으로 보인다.

오류와 해결에 대한 히스토리를 적어놓는 것은 실력향상의 지름길이다.

다만 하기의 문서 작성 이전에 로깅을 꼼꼼히 하도록 하자.

디버깅과 인수인계를 고려하지 않고 개발한다면 그건 Product가 아니라 혼자 개발 연습을 한 것이기 때문이다.

SI에서 과제 개발 중 에러 히스토리를 적는 경우 대부분 시스템 이슈이다.

따라서 개인적으로 과제별로 엑셀파일을 작성하고 버전별 업데이트 정보와 이슈 현상에 대한 스크린샷을

다른 시트에 첨부해두는 걸 좋아한다.

과제별 엑셀 => [과제정보] - [이슈 히스토리] - [이슈 No별 스크린샷 시트]

이슈 히스토리의 컬럼 구조는 이슈No, 발생일, 상태, 현상, 추정되는 원인, 조치, 완료날짜 정도다.

과제 정보에는 과제번호, 사용시스템, 과제명, 프로세스명, 현업 담당자 등을 적어두어 조치, 문의에도 이용하고

추후 산출물 작성에도 용이하도록 구성한다.

SM에서는 이미 어느 정도는 사이클이 진행되는 여러 과제들을 운영하기 때문에

여러 이슈를 한번에 보는 게 편하다.

특히 특정 시스템에서 공통적으로 어떤 이슈가 있는지 비교하면서 케어할 필요가 있다.

통합 엑셀 => [과제 키값 및 과제명이 모인 하이퍼링크 시트] - [과제명(과제정보 및 이슈 히스토리)]

과제정보, 이슈 히스토리를 한 시트에 적는다.

이슈에 관한 사항은 No와 과제명을 따서 스크린샷 파일명으로 저장해 두거나 영상을 찍어 보관한다.

RPA 구축사의 Business Model을 논하기 위해선,

근본적으로 RPA 자체의 생산성이 어떻게 생기느냐를 먼저 살펴봐야 한다.

RPA는 업무 자동화 아키텍쳐를 의미한다.

Uipath Studio나 Brity Works Studio 같은 것들, 혹은 시중에서 판매되는 매크로들은

그냥 프로세스 로직 생성 툴, 실행기로 봐야 한다.

RPA가 부각되는 이유는 기존 매크로들에 비해 프로세스 로직 생성 툴이 포함된 아키텍쳐가

코스트 대비 가치를 많이 뽑아내는 '생산성'에 이르렀기 때문이다.

[물론 사일로 시스템에서의 시스템 변화가 잦다든가 하는 부차적인 부분도 있으나 근본적인 건 생산성이다.]

다시 말해, 대단히 새로운 기술이 생겨난 것이 아니라는 것이다.

이미 기존에도 각종 게임, 예매, 크롤링 등에 매크로가 이용되어 왔다.

로직 생성 툴, 실행기를 쓰는 것 자체는 당연히 쉽다.

툴을 포함한 아이텍쳐 자체를 개발한 회사에서는 이를 최대한 쉽다고 말해야 맞다.

그러나 구축사 입장에서는 방어적으로 가야 한다.

실제 가치를 만들어내지 못하는데 괜히 꼬아서 개발하자는 의미가 아니라,

Enterprise급에서 관리, 배포, 수행의 Cost를 최대한 줄일 수 있는 개발 노하우를 갖고 협상을 해야 한다는 말이다.

실제로 기업의 가치를 안정적으로 만들며 관리하기 위해서 구축사를 통해 SM, SI를 진행하는 것이지,

그렇지 않으면 그 '쉬운' 툴로 프로세스를 이미 알고 있는 현업이 개발하는 것이 백배 낫기 때문이다.

요컨대 구축사가 '우리가 왜 필요한가'를 고객사에 보여주기 위해서는

회사 차원에서 체계적으로 RPA 개발 생산성을 높일 수 있는 방법들을 고안하는 데 있다.

[왜냐하면 본질적으로 RPA 자체가 그것때문에 부각이 됐기 때문]

이를 개인의 역량에만 맡기게 되면 '프로젝트' 단위에서 관리되기 어렵다.

슈퍼맨 PM이 개발까지 잘해서 그런 체계를 다 만들고 그를 회사 내부에 전파하지 않는 이상,

비지니스 환경에서 그런 체계까지 고안해서 진행하기란 거의 불가능하다.

다음 글들에서는 '소스 구조 레벨에서의 최적화', 'RPA회사는 정확히 어떤 서비스를 파는가'와

그에 의거한 고객사에 제공할 수 있는, 인력 투입 차원의 '비지니스 모델'에 관해 좀 더 구체적으로 써보고자 한다.

** 텍스트만 올릴 수 있는 환경이라 그림없이 설명하겠음 **

고객사중에 Amazon내에 있는 사이트에서 데이터를 가져와 달라고 하는 경우가 꽤 있다.

아마존은 국제 유통사중에는 가장 규모가 커서

물건을 사는 경우도 있지만 일반적으로는 Vendor, Seller로서 놓칠 수 없는 창구이기 때문이다.

특징적으로 아마존놈들은 별로 친절하지 않아서 기상천외한 방법으로 데이터를 Export해준다. [특히 나름 Cloud에서의 경쟁사인 MS의 제품을 쓰지 않기 위해서 Text나 CSV Export를 자주한다.]

그러나 데이터 Export 이전에 최대의 숙제가 있다. 바로 로그인 시 OTP를 간헐적으로 물어본다는 것이다.

OTP를 자동으로 얻어올 수 없다면, RPA입장에서는 OTP창이 뜨는 순간 실패로 기록했다가

나중에 사람이 한번씩 들어가서 입력해주는 방식을 취해야 한다.

그나마 이 방식도 북미쪽 계정은 너무 자주 OTP 세션을 잃어버리기 때문에 그렇게 개발했다간 인간 RPA를 하기 십상이다.

OTP를 자동으로 얻어오기 위해선 Customer용 amazon을 들어가 로그인을 해야 한다.

[Seller랑 계정이 나뉘지는 않는다.]

로그인 후 우측 상단의 Account & Lists => Account를 누르면 Login&Security 라는 DIV가 있다. [자물쇠 모양]

거기서 Two-Step Verification (2SV) Settings의 Edit 버튼을 클릭하자.

핸드폰과 Authenticator App이 있는데 add new app을 눌러 APP을 추가한다.

이 단계까지 왔다면 QR코드를 볼 수 있다.

이 QR코드는 구글 스토어에서 '인증도구'를 검색해 나오는 APP을 깔아서 인식할 수 있다.

구글 스토어에서 인증도구 혹은 Authenticator App으로 검색해 추가하고 브라우저 우측 상단에 앵커로 고정해주자.

인증도구를 누르면 우측 상단에 [-] 형태로 QR을 읽을 수 있는 버튼이 있다.

그걸 누르고 아마존에서 나온 QR을 스캔하면 OTP가 설정된다.

그 OTP를 입력하고 아래 Verify and Continue를 누르면 그 계정의 OTP로 등록이 된다.

등록된 OTP는 백업 다운로드를 통해 내보내기를 할 수 있고,

다른 기기에도 인증 도구를 설치하면 똑같은 OTP를 받아볼 수 있다.

팝업으로 띄우는 방법, 우측 상단에 확장도구 앵커를 쓰는 방법 두 가지가 있는데 둘 다 Element가 잡히진 않았던 것으로 기억한다.

계정별로 이미지를 따서 클릭하는 것을 추천 드린다. [95% 이상 일치로 설정]

+ 이걸 모르고 있던 현업이 이게 된다는 걸 알면 권한에 민감해지는 케이스가 있으므로, 미리 알려주고 이거 써도 될지 물어보자.

개발을 아무리 잘해도 이런 부분에서 걸리면 개발 하나마나가 된다.

※ 트러블슈팅은 꼭 남기는 것을 추천한다. 사이트내 체계나 정책으로 돼있지 않더라도 개인적으로 갈무리를 하는 것이 좋다. 조금 귀찮지만 인수인계나 디버깅에서 매우 편해진다.

트러블슈팅이란?

어떤 이슈가 있었고 그걸 어떻게 해결했다에 대한 체계적인 기록, 분석

일반적으로 엑셀로 관리하며 발생일시, 원인, 조치 등을 적어둔다.

스샷을 찍어둘 수 있다면 더 좋다. [엑셀로 스크린샷 관리]

에러가 났을 땐 현상을 정확히 파악하는 것이 먼저다.

경험이 많지 않을 때 흔히 저지르는 실수는 원인을 너무 빠르게 확신하는 것이므로 현상은 일어난 그대로 파악해보자.

1. 현상파악

2. 추정원인

3. 추정원인에 의거한 조치

4. 최종 조치 결과

디버그 알고리즘 예시1

현재 발생한 현상 : Process영역 내부에 있는 로그상 End 자체를 가지않고 중간에 Kill된 것 같다.

Loop
추정하는 원인들 : 1. 누가 Stop을 했는데 로그상 End로 남겨졌다. 2. Executor 자체가 스스로 에러나서 꺼졌다.
조치 : 1. => Audit Log를 확인 X[누군가 건드린 히스토리 없음] 2. Executor 자체 오류
end Loop

해결하지 못한 경우라도 '추후 모니터링' 등으로 기록하고 hanging하도록 하자.

디버그 알고리즘 예시2

현재 발생한 상황 : Write Cell에서 HRESULT가 발생했다. 

Write Cell [엑셀 파일 / 시트 / 셀]

i) 셀에 다음과 같은 String이 추가되어 있나 => String '='(잘못된 함수 에러) '@'(잘못된 이메일 주소 에러) 등

 - [Success/Fail 같은 개발자가 정해놓은 코멘트밖에 없음] 

ii) 잘못된 시트 문제인가 => 시트는 고정돼 있었고 이미 에러없이 처리된 전력이 많다. 갑자기 에러남.

iii) 엑셀 세션의 간헐적 문제인가 => * 엑셀 파일을 끄고 켜는 과정에서 세션이 물렸나?

* 조치1 => save changes deselect + save workbook => 효과없음

* 조치2 => 기존 Activity에서 에러가 나는 경우 File-workbook에 있는 Activity로 대체

보통 이 경우는 jsp 등으로 로컬의 서비스 프로그램을 실행시키고자 했을 때 발생한다.

이때 IE로 하면 실행이 되는데 크롬에서 하면 실행이 안 되면서 CORS Policy가 뜬다면 다음과 같은 옵션을 Disable로 변경해주면 된다.

chrome://flags/#block-insecure-private-network-requests

크롬에서는 기본적으로 CORS 정책을 지키지 않았을 때, 보안이 되지 않은 Context로 인식하고 막게끔 설정되어 있다.

IE는 그것이 약하기 때문에(그래서 일반 유저 입장에선 크롬이 훨씬 보안이 좋다) 그런 검사없이 실행시키므로 사내 레거시 프로그램을 실행하는 데 더 유리하다.

내 경우는 고객사에서 가급적 크롬으로 진행하기를 원해서 크롬 기준으로 개발을 했으나

그룹웨어에서 이 프로그램을 트리거링 하면서 CORS 정책을 풀어주는 코드를 삭제했기 때문에

RPA 소스 수정없이 크롬에서 문제를 해결하는 것을 찾아보다 발견했다.

보안이 약해지는 것이기 때문에 확인하고 풀길 바란다.

과제번호: 
과제명: 
프로세스명: 

사용 시스템: 
접속 URL: 
사용 ASSET: 
사용 CREDENTIAL:
마스터 파일: 
수신인: TBD

결과 파일: 

메일 제목: 

메일 본문: 


Transaction 기준: 

------------------------------------------------------------------------------------------------


1. Data Loading(데이터 추출하는 부분)



2. BusinessLogic(추출된 데이터를 처리하는 부분)


  

3. 결과 메일링(End Process) (결과 체크하는 부분)

과제정의서 체크리스트

- [Required] 과제명, 프로세스명, DL, (현업에 Confirm 받은) 결과메일 양식, 선호 스케쥴
- [Required] 과제 진행을 위한 권한 확보[ex. 외부 파일 반출, 시스템 접근 등]
- [Required] 요청 파일 양식[마스터, 템플릿 파일 등] 확인 및 가이드
 * 미팅 후 +n일까지 준비되지 않을 시 홀드 후 다른 과제 진행하는 것으로 사전 협의 필요
- [Required] 실패 시 처리[Step별로 다르다면 그 부분도 작성. 특히 소급가능하지 않은 Step이 있다면 꼭 명시돼야 함.]

* 특히 시스템에 입력하는 과제중 중복이 일어나면 안 되는 과제들에는 중요

- [Required] 현업이 실패 리스크에 대한 인지를 하고 있는지, 로직상 이중 대책이 필요한지 체크

- [Required] 메일 요청 키워드, 작업 파일 키워드

- [Required] (기존 과제 수정이나 이관인 경우) 기존 성공 수행 이력

- [Required] 필요앱 설치 가이드 및 설치 파일

- [Optional] 요청 파일별 메일 키워드[제목 혹은 첨부파일명]
- [Optional] 해당 프로세스에 대한 예외 사항 명시
 * 미리 수동으로 진행해 봤을 때 3 Cases 이상 발견되는 경우엔 공수를 추가하는 형태로 협의

- 외부메일이 필요한지. 필요하다면 허가 진행 가능한지? [사이트 특이사항]

- 파일 개수 10개 limit이 있는데 zip으로 진행해도 되는지? [사이트 특이사항]

- 외부 메일링 시(Big File이 아님) 용량제한(현재 30MB)에 문제없는지? [사이트 특이사항]

-