개발 갈무리

Uipath가  타사 툴에 비해 불편한 사항 중 하나가 String 포맷의 편집이 다소 귀찮게 돼있다는 점이다.

그중 하나가 Before-After 기능인데, String의 Before와 After Word를 정해서 그 Between을 가져오는 Activity이다.

가령 "기간 : 20211217~20211231 {개행} 주최자 : James" 형태의 문자열이 있을 때 "기간 : "과 "~" 사이를 sBefore라는 변수에 넣는다고 하면 Index를 이리저리 찾아줘야 하는 귀찮음이 생긴다.

거기에 이 단어가 없는 경우까지 고려해서 분기처리를 또 해야한다.

간단하게 할 수 있는 방법은 다음과 같다.

split(split(sOrgStr,sBeforeStr)(1),sAfterStr)(0).Trim

split(split(sOrgStr,"기간 : ")(1),"~")(0).Trim

split(split(sOrgStr,"~")(1), environment.newline)(0).Trim

물론 이 경우 주의해야 될 케이스는 있다. 사용하고자 하는 분기 String이 앞에 또 있는 경우다.

그렇게 Occurence가 2이상인 경우는 split index의 (1)을 (2) 등으로 변경해야 하는 번거로움이 생긴다.

[라이브러리 만드는 법도 간단하므로 아예 라이브러리 만드는 것을 추천한다.]

split(split(sOrgStr,sBeforeStr)(iOccurence),sAfterStr)(0).Trim

Trim 여부도 조절하게 만드는 걸 추천한다. [어떤 값은 앞에 띄어쓰기가 있어야 시스템에서 조회되기도 함]

+ 웬만하면 이렇게 쓰더라도 값이 잘못 가져와 지거나 키워드가 변경될 소지를 고려해 split 에러 시 대처를 추가하자

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

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

디버깅과 인수인계를 고려하지 않고 개발한다면 그건 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% 이상 일치로 설정]

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

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

보통 리소스가 충분하다면 시의성이 중요한 과제들의 경우 스케줄 텀을 짧게 두어 체크하도록 개발한다.

그러나 리소스가 충분하지 않으면,

가령 시스템에 데이터를 요청 후 오래 대기하였다가, 추후에 받아야 되는 과제 등은

메일이나 큐로 트리거 되었다 하더라도, 후속처리를 위해 특정시간 이후 Start Job 되어야 할 수 있다.

[일반적으로 시스템 요청 후 지연처리 되는 과제는 이런 복합적인 스케줄을 요구할 수 있다.]

[현업도 오케스트레이터를 접근하여 큐를 이해하고 활용하는 경우면 다른 방법도 있을 수 있다. 다만 그런 사이트는 거의 없을뿐]

이럴 때는 큐로 요청체크를 하더라도 후속작업을 위해 스케줄을 걸기 때문에 소스 내에서 지금의 작업 트리거가 스케쥴인지 큐인지를 구분해야 한다.

그 중 가장 편한 방법은 스케쥴 트리거를 걸 때만, Main이 되는 Xaml의 구분용 Argument를 따로 생성해 두고

그 파라미터 값을 부여해 주는 것이다.

[기본적으로 파라미터 값의 설정은 프로세스를 생성할 때부터도 가능하다.]

[물론 패키지 자체를 여러 개 생성하는 것도 가능한 선택지이다. 다만 관리 시에 소스 관련 패키지를 모두 취합해야 하는 불편함이 있으므로 Argument로 구분하고 분기를 통해 작업이 달라지는 게 합리적이다.]

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

트러블슈팅이란?

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

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

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

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

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

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로 대체

주의 : 요청당 5천자까지 번역이 권장되므로 대량의 텍스트엔 부적합하다.

준비해야 하는 패키지 : UipathTeam.String.Activities

App key는 프로젝트 사이트에 요청하는 게 일반적이나 개발자가 직접 받아야 되는 케이스가 있다.

그럼 프로젝트용으로 받은 구글 아이디에서 Console을 접속해 API를 받으면 된다.

[API 및 서비스 - 사용자 인증 정보 - API Key]

https://console.cloud.google.com/navigation-error;errorUrl=%2Fhome%2Fdashboard

Key를 입력 후 Source Language Code와 Target Language Code를 입력하면 Input Text를 번역해 Output으로 돌려준다. [code는 하단 참조]

이때 언어 자동감지를 하게 하려면 Source Language Code를 빈 String("")으로 주면 된다.

[Language Codes]

https://developers.google.com/admin-sdk/directory/v1/languages