개발 갈무리

기본적으로 스튜디오 내부에서는 세팅된 것을 가져다 쓰는 식

아키텍쳐는 

DU Server - Orchestrator - Assistant(혹은 Studio)

형태라고 함

DU Server는 리눅스 OS에서 세팅되며 설치된 곳은 스펙이 좋아야 함. 아니면 부팅 중 멈추거나 제대로 동작하지 않는 현상이 많았다고 함(2021.04 버전 기준) => 2021.10부터는 그나마 안정적으로 작동한다는 말이 있음. [다만 표본이 부족하기 때문에 프로젝트 케이스가 더 생겨야 한다고 봄]

https://docs.uipath.com/document-understanding

관련 영상

1.    https://youtu.be/U11il47YLqk

데이터매니저에서 학습용 영수증을 레이블링한 후 그 결과를 데이터셋으로 내보냄.

2.    https://youtu.be/w6tUly5cxzM

AI Center에서 영수증 데이터셋을 임포트하여 ML 모델을 학습시켜서 로봇이 사용할 수 있는 ML 스킬을 생성함.

3.    https://youtu.be/ommhluQ2FkY

로봇이 ML 스킬을 이용하여 영수증을 인식하고 그 결과를 concur에 입력함.

**** 어떤 과제가 '비싼' DU를 써야 하는가?

1. 기술적 측면

DU를 쓰는 과제는 일반적으로 Input이 불안정한 경우이다.

사내 Guide 정도로 끝낼 수 있는 과제라면 굳이 DU를 쓸 필요가 없으나,

고객으로부터 문서를 제출받아 특정 정책대상으로 분류하는 경우 등에는 쓸 수 있다.

가령 항공사에서 가족관계증명서, 주민등록등본 등을 통해 고객정보를 DB에 집어넣어야 하는 경우

폰 카메라로 마구잡이로 찍어 올리는 케이스가 많기 때문에 DU를 적용시킬 수 있다.

[실제 케이스이긴 하나 PI가 잘못된 경우라 생각된다. PI가 제대로 됐다면 이미 찍는 시점에서 스캔인식이 안 될 경우

업로드가 되지 않도록 input단에서 제한을 두어야 훨씬 깔끔하다.]

다만 이 경우도 학습을 굉장히 많이 시켜야 90% 가까운 확률에 도달할 수 있다.

특히 잘못 OCR 되는 케이스에 대해선 직접적으로 케이스를 잡아 replace를 시켜줘야 했다고 한다. 

이런 보정까지 생각하면 아직은 기술적으로 학습에 대한 공수가 많이 들어간다고 볼 수 있다.

보통 대안으로 Abbyy의 Flexible Capture가 많이 거론되는데

Flexible Capture는 해상도를 맞추고 그에 대해 대략적인 좌표를 템플릿화 시켜놓는 개념이라

Input이 어느 정도는 정형화 되어야 한다. 내부 가이드 정도로 이를 해결할 수 있다면 Flexible Capture가 더 정답이다.

2. 영업적 측면

어떤 판매든 영업적, 정치적 측면이 있지만 DU는 특성이 두드러진다.

어쨌든 Flexible Capture 같은 방식보다 비싸기 때문에 '명분'이 필요하다.

그 명분은 대개 '4차 산업 혁명', 'AI 기술 도입' 같은 키워드이다.

직접적인 이해 관계자를 보면 Uipath 관계자 / 하청업체 수행사 / 고객사 관리자이다.

 - uipath 관계자 : DU 기술이 아직 초기 시점이긴 하지만, 프로덕트로 나온 이상 일단 최대한 많이 팔아야 함.

 - 하청업체 수행사 : 어디든 들어가면 좋음(개발자 입장은 다르겠으나 영업쪽에선 고려되지 않음)

 - 고객사 관리자 혹은 의사결정자 : AI기술 도입 및 ROI 잡아서 실적 쌓기 좋겠다는 생각을 함

다만 고객사 관리자가 드물게 '우리 회사에 실질적인 도움이 돼야 한다'라고 하면서 직접 알아보는 경우

증빙 등을 고객으로부터 받아 보내주는 과제들이 많은지를 체크해볼 필요가 있다.

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를 겹쳐놓은 소스였음