개발 갈무리

Uipath에서는 프로젝트내 사용한 소스의 브라우저 변경을 Convert 해주는 툴이 존재한다.

Xaml 파일의 앱정보에 관한 키워드를 일괄적으로 변경한다.

가령 앱정보에 iexplore.exe 키워드가 있으면 chrome.exe로 변경해주는 형식이다.

변경 시 각 프로젝트, Xaml 파일별로 변경점의 수를 알려준다.

실제 프로젝트에서 적용할 때의 문제는 크게 2가지이다.

1. File Download 등 중간에 브라우저 객체가 아닌 게 끼는 경우

2. 브라우저별로 Element에 대한 정보를 Export하는 게 다른 경우

1,2의 케이스 때문에 결국은 소스를 흘려보면서 테스트를 해야 한다.

선조치를 함으로써 변경하기 쉬운 상태로 바꿔준다 정도로 이해해야 될 듯 하다.

+ 일반적으로 내부 개발 소스를 내부에서 특히 개발자 본인이 convert를 하면 상관없는데

보통 브라우저 전환이나 OS 전환이랍시고 다른 회사의 소스를 가져오면

비지니스 로직 자체에 결함이 있는 케이스가 많아 그게 이슈가 되기 십상이다.

따라서 작업 scope를 명확하게 나누어 진행해야 한다. [사실 너무나 기본적인 건데 참....]

과제를 하다보면 시스템에서 조회를 할 때, 로딩 화면이 휙 나왔다가 슉 사라지는 케이스가 많다.

문제는 간헐적으로 오래걸릴 경우 적절히 대기를 해줘야 하는데, 그를 인식할만한 것이 제대로 보이지 않는다.

이미지로 하려고 해도 보통 로딩화면은 GIF로 구성되어 있기 떄문에 인식이 틀어질 가능성이 높다.

그래서 Element Exist를 잡아보면 로딩이 뜨든 말든 항상 그 로딩 Element가 존재하는 경험을 하게 된다.

보통 로딩 Element를 웹에서 구현할 때는 2가지 방법을 주로 쓴다.

첫째는 Display : none을 On/off 하는 방법,

두 번째는 크기를 0으로 줄여 화면 끝으로 보냈다가 로딩일 때만 화면 중앙으로 불러오는 방법이다.

두 가지 케이스 모두 Element는 항상 존재한다.

첫 번째 방법일 경우 Visibility 같은 속성이 변경되며, 두 번째 방법일 경우 Position이라는 속성이 변경된다.

특히 Position은 Uipath.Core.Rect 라는 Uipath 전용 직사각형 변수에 담기며 메소드를 타고 들어가

rRect.Rectangle.Value.X 혹은 rRect.Rectangle.Value.Width의 값으로 분기할 수 있다.

일반적으로 Try에서 에러가 나면 Catch를 수행한다.

다만 특정 경우 마치 소스 Compile 관련 Validation이 제대로 되지 않은 것처럼 수행되기도 한다.

포럼에서는 pick 같은 액티비티를 썼을 때 일어나는 경향이 있다고 하는데

실제로 여기서 발생한 케이스는 Switch였다. [동시 컨디션 체크라는 공통점]

Try Catch의 Try 안에 Switch가 있고 Switch의 내부에 Try Catch가 또 있는 상태.

디버그로 돌리는 경우 Assign 자체를 들어가지 못 하고 Switch 내부의 Catch에 대한 에러 메세지를 출력했다.

실제 에러가 나는 부분은 Switch 내부의 Try Catch 안에 Try에는 Assign쪽이었다.

Switch 컨디션의 변수 상태에 따라 해당 Assign이 에러가 나는 케이스였다.

해결은 Assign이 에러나지 않도록 null인 경우 기본값을 가진 string을 부여하도록 변경함.

** 개발을 굳이 저렇게 할 필요가 없는데 너무 많이 Try Catch를 겹쳐놓은 소스였음

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% 이상 일치로 설정]

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

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