개발 갈무리

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 관련 엄한 곳에서 오래 헤매지는 않을 거라고 생각한다.

RPA는 여타 다른 개발 분야와는 프로젝트의 결이 많이 다른 편이다.

개발자에게 요구되는 자질도 다른 여타 IT분야에 비해 좀 다르다.

그런 생각에 RPA 잘하는 기준은 무엇인지 새삼 정리해 보기로 했다.

다른 분야 대비 특이점 [각 케이스는 평균적으로 경향이 그렇다는 거지 무조건은 아님]

i) 개발자가 직접 작성하도록 요구되는 산출물이 많음

ii) 요구사항이 기능에 국한되지 않고 프로세스 전체 로직에 연관됨

iii) IT를 모르는 현업과 긴밀하게 협업해야 하는 경우가 많음

iv) 업무 프로세스에 대한 이해와 설계가 쥬니어에게도 요구됨

먼저 i)는 프로젝트 구성에 따라 조금씩 다르긴 하지만, 대부분 개발과 설계, 과제 정의가 궤를 같이 하기 때문에 일어나는 현상이다. 경우에 따라 컨설턴트나 PM이 붙어서 대신 해주기도 하지만 그렇다 하더라도 개발베이스의 전용 컨설턴트가 아닌 이상 수정사항이 많이 나온다.

ii)는 애초에 프로세스의 실질적인 주인이 현업이기 때문에 나오는 현상이다. 현업이 본인의 프로세스를 잘 이해하고 앞 뒤 영향 파악도 빠르게 할 수 있다면 좋겠지만 대부분 일 못하는 현업은 정리되지 않은 프로세스를 준다. 따라서 요구사항이 생각나면 나오는 경향이 심하며 설계 자체에 영향을 끼치는 케이스가 많다. 경험이 많은 RPA 개발자들은 이를 사전에 체크해서 설계단에서 잡고 나갈 수도 있다.

iii)는 일하면서 많이 답답한 사안 중 하나다. RPA는 커녕 IT도 전혀 모르는 경우가 많아 서로 간략히 소통하기가 쉽지 않다. 어떤 면에선 어느 정도 현업에게 개념을 가르쳐주는 경우도 많기 때문에 교육역량이 있으면 소통하기 훨씬 수월하다.

iv)는 업무 단위에 대한 내용이다. 보통 자바같은 개발의 경우 사이트 중 일부 기능들에 대해서 쥬니어에게 구현하도록 하는데 RPA는 과제단위로 일을 분배하기 때문에 그렇지가 않다. 과제 난이도가 쉬운 게 할당될지는 몰라도 쥬니어도 개발 프레임워크와 프로세스를 잘 이해하여 로직을 설계할 수밖에 없는 구조다. [이런 부분때문에 문과출신에게 접근성이 좋은 편이다.]

이런 특징들을 봤을 때 RPA를 잘하는 사람은

i) 프로세스 이해가 빠르고 프레임워크에 빠르게 녹여 설계함

ii) 각 분야별 프로세스 경험이 많음(=도메인 지식이 많음) [ex. 재무, 제조, 생산, 구매, 인사, IT 등]

iii) RPA의 아키텍쳐 이해도가 높음

iv) RPA툴 및 OS, DB에 대한 전반적인 이해가 있음

결국 현업과 소통하면서 프로세스 정리하는 능력 + RPA 이해도라는 뻔하지만 뻔하지 않은(?) 말이되긴 하는데

영업이나 컨설팅 역량이 있는데 개발도 좀 해보고 싶은 사람에게 RPA는 꽤 훌륭한 첫걸음이지 않을까 싶다.

[RPA가 쉬워서가 아니라 RPA에서 요구되는 자질을 갖추고 있기 때문]

사실 시장에 들어와보면 이런 구조때문에 겪는 애로사항이 많지만 그건 나중에 또 다룰까 한다.

-끝-

브리티웍스 DB ODBC 주의사항 [2021.03.26 현재 최신 버전 기준]

i) Connection시 DSN으로만 가능 [Connection String으로 불가]

ii) MySQL의 경우 8점대는 에러남

iii) 32비트로 인식

UP를 따라한다고 했지만 ii,iii는 AA v11과 비슷한 이슈일 것으로 보임

i번은 사용자가 어려워 할 것 같아서 뺀 거 같은데 그러면서 소스의 Device 종속성을 제거하지 못 함

[=Device 마이그레이션 할 때마다 DSN을 세팅해줘야 함]

최근 강의를 나갔던 김에 RPA의 개념에 대해 개발자 관점에서 정리해본다.

RPA란 근본적으로는 매크로다. RPA 개발자들, 컨설턴트들은 이 말을 좋아하지 않을 수 있겠다.

어차피 매크로인데 왜 전사적인 부가가치가 생기는 것일까

답은 그 생산성에 있다.

IT에서 생산성을 높이는 전형적인 방법 중 하나는 패키징을 하는 것이다.

패키징해 재사용 가능한 부품을 우리는 모듈 혹은 라이브러리라 부른다.

자주 쓰이는 매크로 모듈을 모아 좀 더 일반적으로 만든다고 생각해 보자.

모듈을 만드는 것은 어려울 수 있지만 모듈을 사용하는 것은 쉽다.

따라서 IT를 잘 모르는 개인이라도 모듈별 사용법을 익혀 자신의 프로세스를 자동화 할 수 있다.

적어도 네이버 검색 결과를 크롤링하기 위하여 수 십줄을 코딩할 필요는 없다.

이것이 RDA 개념이다.

RDA가 발전하고 비용을 투자하면서 기업은 고민하게 된다.

전사적인 관리를 통해 가치를 생산할 수는 없을까.

하나의 업무 프로세스는 비단 한 사람에게만 속하는 영역이 아니며

공공재적 성격을 띄는 모듈(앞서 언급했던 모듈들을 모아 만든 공통모듈)도 많이 존재한다.

가령 그룹웨어나 ERP에 로그인하는 모듈은 가져다 쓰기만 하면 시스템 접근까지 자동화 된다.

즉, 모듈의 모듈을 만들면서 규모의 경제가 일어난다.

이를 효과적으로 관리하기 위해 만들어진 컨트롤 타워 및 인센티브 시스템, CoE 및 운영 체계 등을

포괄해 전사적 자동화 시스템 전반을 RPA라 부른다.

++ RPA 관점에서 안정성을 관리하기 위해 구축사에서는 '프레임워크'를 만들어 생산성을 높인다.

++ 이 개념을 보면 결국 기업에서 자동화에 대한 효율을 이끌어내기 위해선 규모를 키워야 하며 이 과정에서 현업들에게도 KPI를 부여하여 스스로 동참하게끔 해야 한다는 결론이 나온다.