RPA의 기본 동작에 관해[초보 개발자용]

RPA툴은 대부분 기본적으로 UI를 자동 분석해 property를 설정한다.

수행 시 해당 Step에서 분석된 Property를 활용해 Element를 찾고, 그 Element에 정한 트리거를 동작시킨다.

어떤 RPA든 이런 형태로 수행한다.

즉, 기본적인 Keyboard, Mouse로 하는 동작들은 컴퓨터에게 정확한 UI 정보를 알려주는 행위라 할 수 있다.

그러므로 개발이 고도화 될수록 기본 동작과 UI에 대한 이해가 필요하다.

 

 

이해를 위해선 다음과 같은 원칙들이 필요하다.

i) Element나 Object가 로드된 후 첫 행위와 두 번째 행위는 같은 행위라도 그 특성은 다를 수도 있다고 생각해야 한다.

ii) 보이지 않는 것이 존재하지 않는 것은 아니다.

iii) Element를 잘 인식하지 못 할 때는 어떤 Window 혹은 Field에 있는가를 파악해야 한다.

 

 

i)는 웹개발에 대한 감각이 있는 사람이라면 자연스럽게 공감할 거라고 생각한다.

같은 Element라도 Checked, Select, Value에 따라 다를 수 있다.

특히 로드된 후 첫 행위 자체가 하위 데이터를 로드하는 트리거인 경우 그 기능이 제대로 수행되기 위해선

트리거 역할의 무언가가 추가 되어야 한다. [가령 드롭다운 형태는 그걸 클릭하는 순간 데이터를 로드하므로 클릭하기 전에는 그 하위에 데이터가 없다. 따라서 클릭을 먼저 해주고 Select Item을 쓴다든가 클릭-클릭으로 선택한다든가 하는 방식으로 개발한다.]

따라서 테스트도 시스템을 새로 RPA로 켜면서 테스트 / 켜진 상태에서 테스트 둘 모두 필요하다.

 

 

ii) 이것도 CSS를 생각하면 간단한 원리다.

보통 로딩바는 항상 존재하지만 로딩인 경우에만 트리거되어 크기가 생긴다.

혹은 데이터가 없을 때 보이는 창을 항상 존재하게 두고 조건에 해당할 때만 Visible로 바꾸는 사이트도 많다.

RPA에서 이런 보이는 것들이 존재하는지 아닌지로 데이터 없음을 구분할 수 없다는 의미이다.

따라서 반대의 조건에서도 혹시나 있다고 판단하는지 체크가 필수적이다.

 

 

iii)는 2번과도 맥락이 다르지 않은데 분명 같은 창으로 보이는데도 사실은 다른 창인 경우가 이에 해당한다.

어떤 앱에서 우클릭을 했다고 하자. 보통 그 우클릭으로 형성되는 선택 리스트는 ListView라는 새로운 타입의 Tag이고

 Title도 'Windows4:""' 같은 식으로 임시형성되는 경우가 많다.

RPA툴이 좋다면 이걸 잘 잡아주지만 이런 경우를 모두 자동으로 잡아주기란 불가능에 가깝다.

정 안 잡히는 경우 RPA 내부에 있는 Record툴로 잡아보길 권한다.

Record를 하면 RPA 툴에 관련없이 항상 Element의 Parent app title을 가져오려고 할 것이기 때문에

필드가 꼬이지 않고 잡히는 경우가 많기 떄문이다.

 

 

 

이외 더 경험적으로 얻을 수 있는 팁들, 툴마다 특성화된 것들이 존재하지만

이 3가지 원칙만 갖고 있어도 Element 관련 엄한 곳에서 오래 헤매지는 않을 거라고 생각한다.