개발 갈무리

보통 Main RPA들이 MS SQL DB를 쓰기 때문에 한글 관련한 이슈가 있다.

쿼리 날릴 때 Where 절이든 Value든 한글이 들어가면 인코딩 에러가 날 수 있는데 앞에 대문자 N을 붙이면 해결된다.

EX) ~~~ Where [Description] Like N'%검색%'

- 소문자로 하면 에러가 난다.

- 유니코드 인코딩을 해서 쿼리를 날린다.

작년에 RPA의 흐름에 대한 글을 갈무리하고 1년이 넘어서야 새롭게 글을 쓰게 됐다.

그 사이에 상당히 많은 흐름의 변화가 생겼다.

i) AI 도입 OCR이 서서히 도입되는 중

작년만 해도 아직 정식 도입되기에는 시기상조일 수 있다고 썼으나, 지금은 서서히 도입 가능할 정도로 올라왔다. 역시나 UP가 가장 빠르게 진행하고 있는 것으로 보이고 늦어도 올해 말엽부터 시작되는 프로젝트들은 Document Understanding 기술이 들어가는 과제를 최소 하나 이상 끼고 있지 않을까 예상해본다.

ii) Portal을 따로 도입하기에는 솔루션의 중앙통제 아키텍쳐들이 사용하기 쉽도록 잘 개선되고 있음

작년엔 포탈에 대해 갈팡질팡하는 곳이 많았다면 지금은 아주 가격이 싸지 않는 이상 안 하겠다는 분위기가 있지 않나 싶다. UP, AA, BW 등등 각 툴들도 관련한 권한 분할을 더 세련되게 개선하고, 일반 User가 접근해 디자인하거나 참여하는 형태의 기능을 도입하고 있다. 포탈 제공 업체 입장들은 관련 Swagger API가 아닌 이상 따로 Custom하는 공수가 꽤나 필요하므로 Swagger API만 적용한 기본 포탈을 일종의 미끼상품(?)처럼 Standard 형태로 무상제공 하는 전략을 보이고 있다.

iii) 재택근무 시스템 정비로 인한 본격적인 수요 증가세

재택근무를 경험한 대기업들의 만족도가 생각보다 높아지면서 시스템 연결 관련 단순 작업에 대해 RPA 수요가 커졌다. RPA 개발자 입장에서는 굉장히 반가운 소식이다. 단순히 수요가 늘었다는 측면뿐만 아니라 정말 'RPA가 수행해야 되는 과제'일 확률이 높아졌기 떄문이다. 정합성과 권한 관련한 의심, 절차 정비가 많이 누그러졌고 재택 관련한 시스템 정비가 많이 이뤄졌기 때문에 RPA 수요 증가세가 가파르다. 

iv) 개발 공수 관련 혼잡성은 여전

RPA 비지니스 측면에서 어려운 것이 과제개수 X 난이도 => 공수 산정 얼마나 해야 적당한가이다. 영업 입장에서는 최대한 줄이고 싶겠으나 결국 적당한 선에서 주어져야 하는데, 각 프로젝트 사이트마다, 사용하는 시스템의 안정성마다, 과제의 복잡성에 대한 판단 기준에 따라 실제 공수는 달라진다. (역으로 프로젝트 경험이 없거나 실제 업무를 잘 모를수록 과제 개수만 따지는 경향이 있다.) 그나마 서로 변수를 줄이기 위해선 프로젝트 계약 이전에 구축사에서 공수산정을 위한 인터뷰, 테스트를 진행해보는 것이 베스트이다. 어중간하게 내부 담당자가 대충 산정했다가 1차 구축에서 곤혹을 치르는 경우가 많다.

v) 시장 점유율 변화

작년에도 이미 많은 변화가 있었으나 지금은 거의 결정됐다고 봐도 되지않을까 싶다. 결정적인 레퍼런스가 됐던 곳들에서 연이어 전환하고 공공쪽에서 수요가 시작되면서 조정이 되고 있다. 구체적인 부분은 민감한 사안이므로 따로 언급은 안 하겠지만 실제 시장 상황을 알아본 담당자라면 알고 있으리라 생각한다. 개발자 입장에서는 느끼는 것은, 결국 전체 아키텍쳐 수준에서 좋은 것은 각 회사의 개발자들도 알게 된다는 점이다. 영업전략이나 가격 모두 중요하지만 장기적으로는 그런 근본적인 변수들이 영향을 미친다.

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에서 요구되는 자질을 갖추고 있기 때문]

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

-끝-

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

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

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

답은 그 생산성에 있다.

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

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

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

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

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

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

이것이 RDA 개념이다.

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

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

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

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

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

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

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

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

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

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