개발 갈무리

CI/CD : 자동화된 통합(협업하는 프로젝트의 개발 테스트 등)과 자동화된 배포. Devops를 위한 개념. 기존에는 각자 Build하고 Test했다가 한번에 Commit하고 충돌나는 거 빼고 다시 테스트하고.... 하는 과정이 있었다고 한다. (그런 과정에서 보통 밤에 업로드하기 때문에 Nightly-Build라고 부르고, 소프트웨어 버전에서 Nightly라하면 실시간으로 업데이트 되는, 개발팀이 쓰는 최신 버전이라고 한다.) 그러다 Jenkins 같은 테스트 자동화, 배포 자동화를 한번에 관리해주는 툴들이 나오고, 많은 프로젝트와 서버에 관해 환경적인 다양성이 생기자 Docker같은 툴이 생겨났다.

Jenkins : 실시간으로 빠르게 개발, 테스트, 반영을 하려다 보니 각각 build하고 테스트하고 해서는 생산성이 나지 않게 되었다. 즉, 이런 프로세스 자체가 체계화되고 자동화될 필요가 생겼고 이를 위한 시스템이 Jenkins이다. 원래는 허드슨이라는 이름으로 먼저 생겼으나 그놈의 오라클이 인수해 버리면서, Jenkins로 독립해 오픈소스로 유지되고 있다. 테스트가 자동화 됐다고 하지만 테스트를 위해선 먼저 테스트 코드를 작성할 필요가 있다. 다만 그렇게 작성만 해놓으면 새롭게 Git 같은 곳에 commit이 쳐졌을 때 기능테스트를 거쳐 오류가 나면 오류가 났다 오류가 없으면 배포를 자동적으로 해주는 식이다. 개발자에따라 배포를 여러 서버에 해야 돼서 귀찮으니까 배포만 자동화하고 싶어서 쓰는 케이스도 있다.

docker : 테스트를 위해 각 서버의 환경(OS, 환경변수, 패키지, 라이브러리 등)을 각각 세팅하려다 보니 Host OS에서 중복되는 리소스들을 각 Guest OS에 세팅하고 각자 구동해야 하는 경우가 빈번했다. 그러다보니 테스트 자체의 속도도 느리고 테스트 환경을 새로 구축하는 것도 느렸다. 이때 고급 개발자들은 각 테스트를 할 수 있는 Container(일종의 정형화된 테스트베드)를 만들어 썼는데 이런 Container들을 비교적 쉽게 각 Layer로 모아 환경을 구축할 수 있는 것이 Docker이다. 그렇게 리소스를 같이 쓰게 되면서, 각자 Guest OS를 구동하고 돌렸던 hypervisor 방식보다 훨씬 효율적으로 테스트 환경을 구현할 수 있게 되었다.

TSDB : 시계열 데이터베이스. 기존 관계형 DB와의 차이점은 다른 key값을 거의 포기하고 timestamp 위주로 무조건 데이터를 쌓아버린다. 따라서 기존 관계형 DB처럼 예전 자료를 update하고 특정 자료를 찍어 Delete하는 데엔 약하지만 Select하고 새로운 자료를 Insert하는 데는 매우 빠르다. 즉, 실시간 데이터들(센서로부터 들어오거나 시계열 통계값을 바로바로 때리는 경우)을 처리하는 데 있어 강한 모습을 보인다. 또, 계속 병렬적으로 쌓아버리기 때문에 데이터가 방대해질수록 느려지는 관계형 DB와 달리 성능이 일률적이라고 한다. 대표적으로 2013년에 나온 InfluxDB가 있다. 자세한 구조는 따로 글 작성 예정.

NoSQL : 기존 관계형DB의 제약을 풀고 특정 데이터 형태에서 성능에 치중하기 위해 고안된 DB. TSDB도 NoSQL의 일종. NoSQL이라고 해서 SQL 언어를 아예 쓰지 않는 게 아니라서 Not only SQL이라고 하기도 한다. RDB의 수많은 규약들 중에 몇몇을 엄격하게 지키지 않거나 데이터의 분류를 다르게 하고 스키마가 없이 데이터를 Insert하는 등의 방식으로 성능을 극대화시킨다. 예를 들어, InfluxDB 같이 키-값으로 컬럼을 분류하고 데이터를 무조건 시간 순으로 찍어 넣는다든가, MongoDB처럼 정형화되지 않은 데이터(이미지, 테이블 등등)을 Document로 분류해서 넣어버린다든가, 혹은 Node, Label, Edge 등의 데이터 형태로 저장하는 Neo4J(그래프 데이터베이스) 등이 있다.

Internet Explorer가 곧 지원이 완전 종료되면서

기존에 IE로 개발돼있던 프로세스를 chrome이나 Edge로 바꾸는 작업을 하는 경우가 많다.

이때 uipath에서 내놓은 공식 Tool이 있다.

Conversion Tool이다.

(Conversion Tool은 https://cloud.uipath.com/{테넌트그룹PK}/portal_/resourceCenter 에서 다운로드 가능하다.)

+ Conversion Tool은 show all을 눌러야 보인다.

1. 사용법

사용법은 간단하다 Conversion Tool을 켜면 하기와 같은 화면이 뜬다.

프로젝트 폴더를 선택하고 start를 누르면 Destination browser로 변경해 준다.

Replace null browser type은 Browser type없이 기본 브라우저로 열리게 되어 있는 경우도 브라우저를 바꿀 거냐이다.

start를 누르면 .conversion_backup 이라는 백업 폴더가 내부에 생기고 브라우저가 전환된다.

Attach Browser나 Element의 app이 iexplore.exe에서 Chrome.exe로 변경된다.

2. 사용 후기

잡기 쉬운 구조의 웹에서는 상당히 좋은 전환율을 보여줬다.

다만 다음의 한계가 존재한다.

1) IFrame 같은 형태로 된 경우 전환율이 낮은 편

2) 웹 진행 과정에 있는 다른 이름으로 저장창, Alert창 등은 변경되지 않음

3) 브라우저간 내보내주는 셀렉터 정보량이 다른 경우 유효하지 않음

3. 결론

마이그레이션 툴과는 별도로

IE에선 잘 됐던 Click이나 Set Text가

Chrome에서는 simulate click(type), sendwindowsmsg로 input method를 바꿔야 적용되는 케이스가 있다.

그냥 일단 적용시키고 한번 쭉 돌리다가 막힌 곳 있으면 그거부터 바꿔주자.

공수를 조금은 줄일 수 있다.

1편에 이어 2편이 굉장히 늦었다.

이번 글에서는 'RPA회사는 정확히 어떤 서비스를 파는가'와 '그런 서비스를 제대로 팔기 위해 필요한 것'을 쓰고자 한다.

일단 현재 대부분의 국내 SI업체들이 제안하는 계약형태는 이렇다.

과제 개수 N개 => 개발자 투입 M명 * L개월 (보통 1명이 한달에 2~4개 정도 개발한다고 생각하고 러프하게 함)

+ 라이선스 비용(중개비 포함)

개발자는 초급, 중급, 고급 기준으로 하는데 중*고급은 사실상 찾기 어렵고

초급 기준으로 500~600 내외로 계산하는 것으로 알고 있다. (2022년 기준)

운영은 그보다 1.5배는 더 비싸다 생각하면 되겠다.

계약 형태를 봤을 때, SI업체에서 생각하는 서비스의 방식은

러프한 '과제 개수'만큼의 구축, 안정화를 하고 나오는 것이다.

그 과정에서 구체적으로

개발자에게는 과제발굴, 과제컨설팅 및 PI, 과제설계, 과제개발, 과제안정화 및 산출물 작성 등이 요구되며

관리자에게는 개발규칙 및 소스 안정성 관리, 진행사항 리포트 및 요구사항 대응, 산출물 관리, 이슈 관리 등을

기대하게 된다.

이런 프로세스를 빠르고 퀄리티 높게 완성시키기 위해서는 하기와 같은 것들이 필요하다.

1) 공통 로깅이 자연스럽게 남고, 비지니스 로직만 넣으면 소스가 완성되는 프레임워크

2) 모듈화된 시스템 접근, 공통 기능

3) 요구사항이 정확하게 작성된 과제 디자인 문서

4) 합리적인 개발규칙 및 산출물 작성 기준

여기서 실제 프로젝트에서 생산성을 높이기 위해 가장 중요한 것을 하나 뽑으라면 PDD이다.

일반적으로 대기업이 아니고서는 보통 PDD 작성 및 조율까지 RPA 구축 업체에 맡기는 경우가 많다.

대기업에서도 RPA를 전문으로 하는 컨설턴트를 쓰지 않기 때문에 조율이 많이 필요하다.

이 부분이 중요한 이유는 이 단계에서 추후 개발의 크기가 결정되기 때문이다.

원래 제대로된 계약을 한다면 기존에 발굴 과정에서 선정할 때,

요구사항이 명확하고 시스템이 안정적인 걸 선택하거나 어려운 과제에 대해선 더 높은 공수를 부여해야 한다.

지금의 계약형태는 이런 과정을 단순히 비용으로만 치부하고 오버되는 부분을 개발자에게 떠넘기기 좋게 만든다.

게다가 고객사 입장에서도 웬만하면 과제개수를 압축해서 최대한 현업요구를 많이 들어주게 하고 싶다.

[물론 무조건 이런 방향만 있는 건 아니다. RPA 프로젝트를 제대로 관리하는 것도 고객사 담당자의 일이므로]

결과적으론 마치 1000원 받았는데 라면에 음료수, 과자까지 사줘야 되는 상황이 자주 나온다.

SI에 있는 RPA 개발자들이 인간 RPA가 되어있는 웃픈 상황은 근본적으로 여기에서 비롯된다.

---------------------------------------------------

프로젝트 대부분이 계약은 물론 내부에서 필요한 것들을 제대로 갖추지 않고 현장에 뛰어든다.

개발자들은 스튜디오 레벨, 패키지 레벨에서만 허우적대기 쉽고

6개월 이상 있으면 성장은 더뎌지기 쉽다.

그를 상쇄하기 위해선 서로 각자의 시스템, 협의방식에 대한 접근을 정리하고 공유해야 한다.

그래야 너머의 확장성과 아키텍쳐, 거버넌스를 보며 제안을 할 수 있다.

RPA로 엑셀 작업을 할 때,

특정 작업이 구현하기 힘든 경우 매크로를 통해 해결하는 경우가 있다.

다만 매크로를 쓰는 것은 다음과 같은 이유로 웬만해선 지양해야 한다고 생각한다.

1. 유지보수 인원도 매크로를 알아야 해서 인수인계가 제한됨

2. 디버깅이 투 트랙으로 진행되어 원인파악이 느려짐

3. 웬만하면 엑셀 함수나 BalaReva Excel, EasyExcel 기능으로 커버됨

그럼에도 불구하고 매크로를 써야 한다면 다음과 같은 원칙이 좋다.

1. 간단한 상황일 것

=> 투 트랙 디버깅 코스트 절감

2. CoE가 아닌 현업에서 관리하는 매크로이고 RPA는 그저 실행만 시킬 것

=> 투 트랙 디버깅 리스크 절감

3. 자주 쓰여야 하는 것들을 라이브러리화하여 쓰는 법을 정형화 시킬 것 (주석이 꼼꼼하게 돼있어야 함)

=> 인수인계 및 투 트랙 디버깅 코스트 절감

과제를 개발하다 보면 병렬처리 혹은 동시 판단해야 할 케이스들이 생긴다.

그 경우 Parallel이나 Pick 중에 뭐를 쓸지 고민하게 된다.

둘의 차이는 인식 시점에서의 수행이다.

Parallel은 기본적으로 동시에 계속 진행된다.

따라서 어떤 인식 기점이 동시에 True가 될 수도 있고, 하나만 True가 될 수도 있다.

어찌됐든 Parallel 안에서는 Exit 조건이 달성되기 전까지 동시에 진행하게 된다.^[각주:1]

Pick은 Trigger 영역에서 어떤 하나의 Branch를 인식해서 수행할 Branch를 선택하는 순간

다른 Branch들은 무시된다.

각 Trigger별 수행이 바로 밑에 정리되기 때문에 적합한 상황인 경우 가독성도 Parallel에 비해 훨씬 좋다.

따라서 각각의 활용은 대략 이런 형태이다.

i) Parallel이 더 적합한 경우

- 로그인 후 모달형태로 다른 타입들의 공지사항들이 뜨는데 각각 꺼줘야 하는 경우

- 여러 개를 인식하더라도 우선되는 하나만 꺼주면 모두 꺼져서 우선 순위를 지정하면 효율적인 경우

- 여러 개를 인식하면 문제가 있어서 우선 순위를 지정해야 되는 경우

- 보통은 exist 등을 병렬로 늘어놓고 exit조건을 적절히 배합해 진행[각각의 Boolean을 Or 조건으로 연결해도 괜찮]

- 수행 소스는 exit후 If나 switch를 통해 각각 진행. Boolean이 동시에 만족하는 경우도 있을 수 있으므로 주의.

ii) Pick이 더 적합한 경우

 - 여러 케이스 중 하나만 배타적으로 잡아야 하는 경우

 - exist 등을 각각 Trigger에 넣고 진행

 - 각 트리거에 대한 수행 소스는 Pick Branch를 넣어 짤막하게 구성

 - Exit조건이 따로 없기 때문에 Pick Branch의 Trigger에는 클릭같은 걸 넣을 수도 있음

보통 Parallel이나 Pick이 잘못 쓰이는 케이스는 각각이 리딩하는 액티비티들이 너무 많아지는 것이다.

Parallel이나 Pick은 너무 길게 끌고가면 소스의 중복이나 불필요한 리소스 사용 등이 발생할 개연성이 매우 커진다.^[각주:2]

또 좌우로 넓어지는 액티비티의 특성상 길어지면 가독성이 안 좋아지는 단점이 있다.

따라서 동시인식, 동시수행이 필요한 구간만 설정하여 진행해야 한다.

+ pick은 모든 branch의 조건이 충족되지 않으면 가장 왼쪽(첫번째)에 있는 시퀀스를 실행한다.

Uipath Studio는 기본적으로 Telemetry가 True로 되어있다.

[ Telemetry란? usage and performance data를 수집, 모니터링 하는 기능. 익명의 사용데이터를 보내게 됨.]

버전에 따라 Telemetry를 끄도록 되어있는 경우도 있으나, 최신 버전들은 강제로 끄지 못 하도록 막아두었다.

Telemetry는 특히 하드웨어 사양이 좋지 않은 경우, 개발 속도를 상당히 저해할 수 있는 요소다.

사양이 간당간당 하는 경우 Telemetry만 꺼도 스크롤할 때 버벅거리던 것이 버벅거리지 않을 정도가 된다.

스튜디오에서 끌 수 있는 경우는 Settings - General에 가서 꺼주자.

강제로 끄지 못하도록 되어있는 경우,

%ProgramFiles%\UiPath\Studio\uipath.config

이걸 관리자 모드로 켜주고 <analyticsSettings> 태그쪽을 다음과 같이 바꿔주자.

  <analyticsSettings>
   <add key="Telemetry.Enabled" value="false" />
  </analyticsSettings>

[기존엔 <analyticsSettings /> 로 되어있을 거다. ]

- 관리자 모드로 config파일 켜기 : 메모장을 우클릭해서 관리자 권한으로 실행한 후 열기를 통해 파일 찾아 열거나, notepad++을 통해 edit하고 저장하면 관리자모드로 다시 열어주는 걸 이용

1. 기존에 있던 Trigger

오케스트레이터에 Start Job을 시키기 위한 Trigger는 다양하다.

오케스트레이터에서 기본적으로 제공하는 Time Trigger, Queue Trigger

Studio에서 Activity로 존재하는 Start Job

비슷한 원리로 Swagger API로도 실행이 가능하다.

이외 AR인 경우 File Trigger나 Mail Trigger, Element Trigger 등을 쓸 수 있다.

2. 새로운 Trigger

오케스트레이터의 Integration Service라는 메뉴에서 제공하는 연결 앱들이다.

구글 및 MS 앱들을 비롯해 개발자들이 자주 쓰는 Slack이나 제조쪽 CS에서 많이 쓰이는 Zendesk

프로젝트 및 일감 관리를 위한 Jira, CRM 관리 툴로 유명한 SalesForce

미국에 영업본부를 크게 둔 회사에서 자주 보이는, 사내 커뮤니케이션 툴 Twilio

이외 dropbox나 Twitter같은 보편적인 서비스와도 연결하여 Trigger를 생성할 수 있다.

가령 구글시트를 연결한다고 해보자.

구글 시트 선택 후 Add Connection을 누르고 Google로 로그인하면, 바로 연결이 완료된다.

트리거를 거는 방식은 생각보다 러프하다.

파일은 선택할 수 없고 Spreadsheet만 선택 가능하다. 

(2022-08-23) 확인 결과 condition filter가 생겼다.

https://docs.uipath.com/integrations/docs/uipath-google-sheets-events

이벤트는 New Record Created, Existing Record Deleted, Existing Record Updated 3가지다.

위의 docs에서도 설명돼 있듯이 확인은 5분 간격으로 하고 설정을 변경할 수는 없다. [2022. 04. 11. 기준]

Google Sheet, Google Drive, Gmail, Microsoft Office 365 정도는 당장 쓸만해 보인다.

3. 리소스 활용

Document ID를 통해 파일을 지정해서 Trigger를 하나의 드라이브로 관리할 수 있으면 좋겠지만

그 정도까지는 아직 힘들어 보인다. [사실 된다고 해도 클라우드의 리소스를 굉장히 많이 잡아먹을 것이다.]

앞선 새로운 이벤트 트리거가 활성화 가능하다면, 각 과제별 Connection을 만들어 Trigger 할 수 있게 된다.

Data filter가 생겨서 이제 쉽게 외부 리소스에서 봇 트리거링이 가능하게 되었다.

특히 파일로 Trigger하는 것들에 대해서 기존 메일체킹하는 봇이 항상 필요했다면

이젠 구글 드라이브나 구글 시트에서 작업함으로써 리소스를 아낄 수 있게 됐다.

사이트 보안이 세서 클라우드 형태에서 Connection이 어렵다 하더라도 앞으로 확장성에 따라

내부에서 레거시 시스템을 바라볼 수 있게끔 구성할 수 있을 것으로 보인다.

4. Connection Test

- Google Sheet 및 Google Drive : 연결 가능.

** Available Events : New Record(file) Created, Existing Record(file) Deleted, Existing Record(file) Updated

- Slack : 연결 가능(BOT TOKEN - No. Redirect URL을 https://cloud.uipath.com/provisioning_/callback 으로 설정)

** Available Event : None(Preview 상태)

 => 2022-08-23 아쉽게도 슬랙은 아직 설정 가능한 event가 없고 user token으로만 connection이 설정됨

- JIRA : 연결 가능

** Available Event : New Record Created, Existing Record Updated

1. 패키지 버전에 맞는 Uipath Remote Runtime을 클라이언트(붙을 VM)에 깔아줌

 - 버전에 맞는지는 리소스 센터(https://cloud.uipath.com/portal_/resourceCenter)에서 받을 때 확인 가능

다운로드드 링크(리소스센터 못 들어가는 경우)

https://drive.google.com/file/d/1BXe5eZi94mQLn-jmft8LLUkCtVfYizrv/view?usp=sharing

2. 스튜디오가 깔린 PC에서 원격 프로그램에 따라 플러그인 설치(Microsoft Remote Desktop이나 Citrix 등)

3. Selector 체크

이래도 안 된다면 mstsc(RDP)를 관리자권한 빼고 실행해 보길 바람

C:\Windows\System32\cmd.exe /min /c "set __COMPAT_LAYER=RUNASINVOKER && start "" "mstsc"

++ Input할 때, 개발 PC와 VM PC를 혼동하는 케이스들만 잘 잡아주면 특별히 안 되는 기능은 없음