0. 디버깅에 관해

1. console 또는 log 찾기

2. 윈도우 환경

3. 브라우저

4. 네트워크

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

0. 디버깅에 관해

개발자 업무의 절반 이상은 디버깅이다.

그럴 수밖에 없는 것이 어떤 service를 만드는 기간이든

그걸 운영하는 기간이든 간에 에러와 시행착오는 항상 존재하기 때문이다.

따라서 얼마나 적확하게 디버깅을 하느냐가 개발과 운영을 잘하느냐를 결정한다.[각주:1]

 

우리는 모든 에러를 겪어볼 수 없다.

새로운 에러는 언제든 등장하고 원인을 분석하고 해결하는 일은 개발자의 몫이다.

이 시리즈에서는 RPA, Uipath를 개발하는 입장에서 디버깅을 어떻게 할 수 있을까에 대해 정리를 해보려고 한다.

먼저 이번 글에서는 디버깅을 하기 위한 근거를 어떻게 찾아야 되는지를 다루려고 한다.

 

1. console 또는 log 찾기

  제대로 된 프로그램이라면 에러가 나든 안 나든 진행상황에 관해 어디든 찍어놨을 가능성이 높다.

보통 그것들은 console이라 불리는 곳에 찍히거나 log가 쌓이는 곳에 적재된다.

에러가 발생했다면 기본적으로는 다루는 툴의 console이나 log 위치를 찾아보고 파악해야 한다.

그 위치는 로컬일 수도 있고, 오케스트레이터 서버일 수도 있고 또는 타겟 프로그램일 수도 있다.

Uipath 기준에서는 가장 기본이 되는 로컬 로그나 오케 로그를 우선적으로 체크해야 한다.

 

2. 윈도우 환경

  RPA 환경은 윈도우 환경이다. 이렇게 단정적으로 말하는 이유는 linux나 mac은 일반적으로 전문가 영역이기 때문이다.

유저도 적을 뿐더러 그런 영역에서는 굳이 RPA를 써가며 자동화할 일이 거의 없다.

다행히도 윈도우에서는 이벤트 뷰어라는 강력한(?) 로깅툴이 존재한다.

이벤트 뷰어

윈도우에서 일어나는 대부분의 행위는 여기에 로그가 찍힌다.

어떤 계정으로 몇시 몇분에 로그인이 됐고 무슨 프로그램을 설치 또는 설치 실패했으며,

어떤 서비스가 돌다가 인증을 실패했고 뭐 그런 로그들이다.

보통 응용 프로그램에 우리가 찾는 로그들이 많이 찍혀있다.

여기까지 찾아온다는 것은 'uipath 로그에서는 원인이 애매하게 찍혀있는데 화면으로 봐도 특별한 뭐가 없고 에러는 왜인지 모르겠는데 자꾸 발생한다'는 경우다.

 

3. 브라우저

  RPA 과제들은 브라우저로 접속해서 데이터를 추출하는 경우가 많다.

브라우저는 html을 해석하고 api를 호출해주는 툴이기 때문에 자체적인 console이 아주 잘 발달돼 있다.

F12를 누르면 개발자 도구가 뜬다.

글을 작성하는 와중에 자동저장이 호출되는 것을 볼 수 있다.

여기서 콘솔탭을 누르면 웹페이지가 로드되면서 나오는 로깅을 볼 수 있다

굉장히 깔끔한 콘솔

웹에서 특정 버튼을 눌렀는데 평소엔 잘 되다가 반응이 갑자기 안 된다? 그럼 여기서 이유가 다 찍힌다.

나오는 문구로 구글링을 해보자.

Elements 탭에서는 다음과 같이 Css selector를 copy할 수 있는데

구조 변경 등으로 인해 셀렉터가 안 잡히거나, 데이터 스크래핑이 안 되는 경우

이 기능으로 비교해보면서 빠르게 디버깅이 가능하다.

이 정도면 크롬이 무거워도 용서해주자....

ctrl + f로 검색하거나 모바일 크기로 줄이기 같은 기능들도 아주 유용하다.

 

4. 네트워크

네트워크 영역은 대부분 최초 환경 세팅에서 디버깅하게 된다.

결국은 방화벽 문제일 가능성이 높고, 회사 내부 정책에 따라 조치해야 한다.

RPA 개발자 입장에서 문제는 보안 담당자가 '뚫어는 줄텐데 뭐 뚫어줘야 되는지는 너가 알아서 가져와'라고 했을 때이다.

그럼 Trigger후 Traffic 변화를 로깅해주는 것이 필요하다.

다양한 툴이 있겠으나 wireshark로 소개한다.

찾을 때 눈이 좀 아프긴 하다

일반적으로는 이런 디버깅을 경험하진 않는다.

보통 벤더사나 솔루션사에서 클라우드 서비스를 해주는 과정에서

뚫어줘야 하는 url을 정확히 알고 있어야 되는데 대충 알고 있거나 빠뜨렸을 때,

또는 그 회사에서 일반적이지 않은 방화벽 정책을 쓰느라 이상한 곳에서 막혔을 때,

혹은 방화벽 관리자가 안 풀어놓고 풀었다고 거짓말하는 거 같을 때,

그럴 때 울며 겨자먹기로 깔아서 눈을 살짝 혹사시키지만 근거를 찾을 수 있는 패킷 분석 툴이다.

회사가 엄청 크고 엄격한 곳이 아니라면 방화벽 담당자를 찾아가서,

'저 혹시 제가 이러이러한 기능이 막혀서 그러는데 제가 트리거하면 그거 리스트 같이 보고 해제할 목록 좀.....'이라고 하는 게 속편하다.

다행히도 Uipath는 나름 docs에 이 정보가 적혀있다.

https://jnaul.tistory.com/260

 

IP Resolution 관련 Cloud Orchestrator 세팅

일반적으로 Hostname을 *를 붙여 요청하면 방화벽을 해제해 주지만 간혹 IP Resolution 형태라 IP질의가 무조건 확인돼야만 방화벽을 해제해주는 사이트들이 있다. Cloud로 오케스트레이터를 설치하는

jnaul.tistory.com

https://docs.uipath.com/automation-cloud/automation-cloud/latest/admin-guide/configuring-your-firewall-for-automation-cloud

 

https://docs.uipath.com/automation-cloud/automation-cloud/latest/admin-guide/configuring-your-firewall-for-automation-cloud

 

docs.uipath.com

 

  1. 엄밀히 말하면 요구사항과 scope의 정의나 PI 등도 그 영역에 포함되지만 여기선 소스 관점에서 다뤄보려고 한다. [본문으로]

+ Recent posts