[PoC] 2주 PoC 후기 및 특이사항 정리

 오늘은 RPA 프로젝트 수주 및 도입을 위한 PoC를 지난주, 이번 주 진행하며 느낀 후기와 2주간 PoC와 관련하여 겪은 내용 및 UiPath Studio로 작업을 하던 과정 중 이번에 사용하였던 몇 가지 사항과 이번에 필요성을 느낀 앞으로의 숙제들을 정리 해 둡니다.

 

 

먼저 당연히, 처음 듣고 저도 바로 알지는 못하고 대답해주지 못했던 PoC에 대해서 알아보겠습니다.

 

 

PoC (Proof of Concept)는 단순 개념 증명으로도 해석하기도 하지만 IT 업계에서 PoC는 신기술이 적용된 신제품을 직접 보고 어떻게 작동하는지를 시장에 소개하는 사전 검증의 개념으로 사용되기도 합니다.

 

예를 들어 이미 시장에 나오지 않은 차기 프로세서 로드맵을 구매하기로 한 국내 모 대형 시중은행의 경우 계약 전 업체들을 불러 차기 제품의 성능과 기능을 미리 제시하도록 한 뒤 장비를 정하는 PoC 과정을 거쳤습니다.

보통 시스템 구매 시 기존 제품의 경우 성능 테스트를 뜻하는 BMT를 아직 양산되지 않은 신제품을 채택할 경우 PoC의 단계를 거치는 것이 일반적입니다.

또 일부 업체들은 자사 신제품을 전시하고 시스템을 구현시키는 테스트실을 PoC로도 부르고 있습니다.

 

- 출처 : 디지털 타임스 [ http://www.dt.co.kr/contents.html?article_no=2006101702012269704002 ]

 

 즉, UiPath로 작업을 하여 RPA 구동이 가능한지 해당 고객사에서 필요한 작업 과정의 순서(이하 시나리오라고 표기)에 따라서 자동화를 구현 해 시연해 보여주는 과정이라고 할 수 있습니다. 즉, PoC의 성공은 프로젝트 수주에 좋은 영향을 줄 수 있고, PoC의 실패는 당연히 수주에 많은 어려움을 줄 수 있을 거라고 생각합니다. 

 물론 PoC를 아무리 잘해도 여러 내/외부적인 요인으로 인해서 도입을 하지 않을 수 있다고도 느꼈습니다. 그리고 본 프로젝트와 가장 큰 차이점은 시간, 공간, 환경에 제약이 아주 많으며, 특히나 시간은 한정적이라는 부분이었습니다.

 

 PoC는 프로젝트와 몇몇 점들이 달랐습니다.

 프로젝트를 진행한다면(바람직하다고 생각하진 않지만) 연장 또는 초과근무를 하여 일을 마무리할 수 있겠지만 이번 고객사가 특히 까다로운지 몰라도 보안상의 이유로 출입 및 업무 시간이 담당 직원이 옆에 있는 근무시간 중에만 가능하였습니다. 의도치 않게 점심시간도 출퇴근 시간도 여유가 있어 좋은 점도 있었지만, 그만큼 끝내야 하는 한정된 일을 할 수 있는 시간은 최소라고 생각하는 8시간보다도 적은 날들의 연속이었습니다.

 프로젝트도 외부 기기를 사용하지 않고 하는 경우도 있겠지만, PoC의 경우 짧은 기간 진행을 하다 보니 외부 기기를 사용할 수 있을 거라 생각했지만 부서에 따라 고객사 내부망만을 활용하여 작업을 하기도 하였습니다. 망 분리야 필요하다면 할 수 있고 고객사에 맞춰 진행을 해야 하지만 고객사에는 전혀 PoC의 편의를 크게 신경 쓰지 않는다는 것도 큰 차이로 느껴졌습니다. 즉, 고객사 입장에서 발주를 한 프로젝트의 경우는 이미 비용과 시간을 들인 것이기 때문에 당연히 잘 마무리되길 바라고 어느 정도 무리가 되지 않는 선에서의 지원도 있겠지만, PoC의 경우는 잘 안될 수 있는 경우도 확인을 하려고 혹은 별 관심을 두지 않았습니다. 그 이유는 시간과 비용이 거의 들지 않기 때문입니다.

 

 UiPath Studio는 몇 번 사용을 해 보지도 못하고(자랑은 아니지만) 바로 고객사에 일을 하러 나가 걱정을 많이 했지만 스튜디오의 기능이 나름 편하게 잘 되어있어 PoC를 진행하는 정도에는 무리가 없었습니다. 우선 PoC를 잘 끝내기 위한 방법 혹은 이번에 느낀 만약 다음 PoC를 간다면 이렇게 하겠다! 혹은 이후에 누군가 RPA PoC를 하는데 저에게 조언을 구한다면 아래의 3가지를 꼭 말해주고 싶습니다.

 

 

1. 시나리오에서 할 일을 정리하고 순서도(흐름도 - Flowchart)로 그린다.

2. 시나리오를 처음부터 끝까지 빨리 구현한다

3. 머리로 생각할 수 있는 가능한 모든 경우를 테스트하고 예외 처리한다.

 

 

물론 RPA 실무를 접해본 지 1개월도 되지 않았지만, 저와 잘 맞는 몇몇 것들이 보이고 느껴져 위와 같이 3가지 정도의 누군가에게 주고 싶은 팁을 정리해 보았습니다. 각 팁별로 이번 PoC를 진행하며 그렇게 느낀 이유가 있었기 때문입니다.

 

먼저 1번. "시나리오에서 할 일을 정리하고 순서도(흐름도 - Flowchart)로 그린다."

 

그 이유는 효율적인 작업이 가능하기 때문입니다.

물론 "꼭 손으로 그려라."라고 드리는 말씀은 아닙니다. 하지만 저는 경험이 부족하기도 하고 손으로 쓰는 것의 힘(?)을 믿기 때문에 이번엔 가능하면 직접 그려보았습니다. PoC 시나리오를 전달하는 것도 고객별로 큰 차이가 있을 수 있으므로 전달받은 시나리오를 본인이 작업할 수 있는 흐름으로 번역(!!)하는 작업이라고 생각하시면 편할 것 같습니다. 그리고 그 과정에서 고객의 요구사항이 불분명하거나 작업자가 이해가 되지 않는 부분은 빠르게 전체적으로 확인을 하여 효율적으로 작업을 할 수 있었습니다.

 

 

그리고 2번, "시나리오를 처음부터 끝까지 빨리 구현한다."

 

 왜냐면, 그렇지 않다면 예측하지 못한 예외를 빠르게 확인할 수 없기 때문입니다.

 시나리오가 작업이 많을 수도 있고, 적을 수도 있습니다. 작업 단계가 적어도 예외 사항이나 처리 방법을 찾는데 시간이 오래 걸리는 작업이 있을 수 있습니다. 하지만 빨리 한 번 모든 시나리오가 돌아가는 것을 보는 것과 각 단계별로 완벽하게 예외를 잡아가며 마치는 것은 큰 차이가 있었습니다. 굳이 SW 개발 방법론까지 꺼낼 필요는 없겠지만 정말 그 전통적인 방식(Water fall)과 Agile방식으로 가장 잘 설명할 수 있을 것 같아 굳이 용어를 사용합니다.

 전통 방식으로 순차적으로 단계를 끝내도 그 단계에 다시 얼마든지 문제가 발생할 수 있습니다. 그 이유는 하단에 실렉터와 다이내믹 실렉터를 통해서 보다 자세히 설명하겠습니다. 하지만 에자일 방식의 경우에는, 제가 개발하는 방법으로 많이 사용하며 단위 테스트와 빠른 프로토타입 개발(여기서는 시나리오 1회 전 단계 구현) 후 테스트를 거치며 문제를 계속 보완 해 가는 방식입니다. 컴퓨터는 거짓말을 하지 않지만 컴퓨터에게 일을 잘 못 시키면 10번 돌아가던 작업이 갑자기 중요한 때 돌아가지 않는 경우가 있으며, 작업이 모두 끝났고, 순서도 상의 모든 작업이 단위 테스트 상에서 문제가 없었기 때문에 잘 동작할 것이라고 확신하였던 일들이 전체 흐름상에서 문제가 발생한 경우도 있었습니다. 그러한 경우를 빨리 처리할 수 있었던 건 각각의 완벽한 단계로 나아가 모든 단계가 끝나서 끝이라고 생각한 것이 아니라, 빠르게 만들어 보고 돌려보고 문제를 여러 번 만날 수 있어서 각각의 문제에 대해서 처리할 시간과 해결해야 할 명확한 문제를 발견할 수 있었기 때문이죠. 

 한 예를 들면 7 Pages분량의 게시판을 정보수집(이하 간단히 크롤링이라 부르겠습니다)을 하는 과정에서 각 게시물을 확인 게시물에서 원하는 정보를 수집 후 다음 게시물을 가지고 반복하는 과정을 모든 게시물에 대해 처리할 때, 검색어에 따라 한 개의 검색어로는 여러 번 테스트를 해도 발생하지 않던 문제가 검색어 리스트를 파일에서 읽어와 여러 번 수행하자 문제가 발생한 경우가 있습니다. 물론 검색어를 가져오는 부분이 아니라 정확히 크롤링 부분에서 발생한 문제입니다. 물론 하나의 검색어로도 계속 크롤링 테스트를 하였다면 발생할 수 있는 문제였습니다. 그래도 각 단계별로 확인을 하였다면 해당 단계에는 전혀 문제가 없었으니 나중에 전체 테스트 시 문제를 찾을 수 있었고 보다 늦은 시간에 예외 상황을 발견했을 것입니다. 즉, 에자일 방식의 가장 큰 장점은 고객사에서 예측해주지 않은 예외를 최대한 빠른 시간에 다양하게 만날 수 있게 해 줍니다.

 

마지막 3번! 머리로 생각할 수 있는 가능한 모든 경우를 테스트하고 예외 처리한다.

 

 이 팁도 어느 정도 2번과 예외처리라는 공통 키워드가 나오긴 하지만 2번이 방법론, 큰 방향에 대한 내용이라면 3번은 예상과 반복 테스트 - 실행에서 나오는 예외 및 문제를 처리하는 것을 이야기합니다. 물론 여기서 "머리로 생각할 수 있는"이란 말은 진짜로 앉아서 생각을 하는 것뿐 아니라 실제로 실행해 보고 로봇을 돌려보고 나오는 문제뿐 아니라 시스템상에서 시나리오상에서 뭔가 발생할 수 있는 상황들을 분류하고 테스트하여 예외사항에 대한 처리를 해 두는 것을 이야기합니다. 물론 예외사항을 모두 예측할 수는 없겠지만 최대한 많이 준비를 해 두는 것이죠.

 PoC의 경우, 그리고 업무 자동화의 경우 오히려 사용자가 사용을 하며 문제와 예외상황이 나오는 클라이언트 프로그램이나 웹프로그램보다 예외상황이 적을 수 있지만 여기서 "머리로 생각할 수 있는"이라는 말을 쓴 이유는 또 다른 것이 1번과 관련 있는 고객이 예측하지 못한 시나리오 상의 예외 또는 처리해야 할 작업들이 있기 때문입니다.

 

 

PoC에 대한 큰 이야기는 여기까지 정리하고 이제 PoC의 세부적인 내용, 구현 방법과 구현에 대한 Tip을 정리해볼까 합니다. 세부적인 내용이라 해도 고객사의 정보나 시나리오 내용 등은 당연히 없지만 일반적으로 발생할 수 있을 거라고 생각하는 시나리오를 가상으로 하여 설명하겠습니다.

 

이번 PoC를 하면서 UiPath 작업 구현에 대해 느낀 Tip에 대해 먼저 정리하고, 그 뒤에 제가 배워 직접 활용해 본 Activity 및 활용에 대한 Tip은 다른 게시물에 정리를 하도록 하겠습니다.

 

1. 방법이 1가지만 있다고 생각하지 말 것

2. 가능한 변수를 줄이는 방향으로 작업할 것

3. 예외처리와 흐름의 분기를 잘 구분하여 사용할 것

 

4.... 음... 분명 더 있는 것 같은데....

 

각 팁에 대한 내용은 아래에 풀었습니다.

 

 

1. 방법이 1가지만 있다고 생각하지 말 것

 

 출근을 하는 방법에 비유를 하면 최고의 비유는 아닐지라도 적절한 몇 가지 공통점이 보입니다. 방법이 한 가지가 아니지만 대부분의 사람들이 한 가지 방법으로 주로! 출퇴근을 할 거라 확신합니다. 그것이 최적의 방법이기 때문이겠죠. UiPath에서 지원하는 Activity 또한 하나의 작업을 처리할 때 어떤 Activity를 사용할 수 있고 다른 Activity를 사용할 수도 있습니다. 여기서 같이 PoC를 진행해 주신 전무님께 배운 용어를 쓰자면 Work Direct와 Work Around의 차이라고 할 수 있습니다. 물론 저는 영어랑도 어려운 용어랑도 친하진 않아(사실 쉽게 이해할 수 있는 말을 쓰는 걸 선호해서) 돌아가는 방법과 가장 좋은 방법이라고 말을 하겠습니다.

 1번 팁을 가장 먼저 쓴 이유가 개인적으로는 UiPath PoC를 했을 때 유용하고 빨리 끝낼 수 있는데 필요한 팁이라고 생각하기 때문입니다. 프로젝트나 제품, 실 사용할 것들은 성능이 중요합니다. 예를 들어 같은 작업을 하는데 A라는 Flow로는 5분이 걸리는데, B라는 Flow로는 3분이 걸린다면 당연히 B라는 플로우가 더 좋고 실제 프로젝트라면 당 연리 B라는 Flow를 따라야 할 것입니다. 하지만 PoC는 RPA 자동화가 가능하다는 것을 보여주고 고객사에서 도입하게 만드는 것이 중요하지 Flow를 내가 잘 짜서 10초를 아끼고 예외처리를 어떤 로직으로 해서 문제가 덜 생기고 이런 것이 중요하지 않다는 것입니다. 그러니 특히나 PoC에서는 돌아가는 방법도 충분히 활용해도 괜찮다는 것입니다. 또한 작업 상황에 따라서 성능이, 작업의 시간에 크게 구애받지 않는다면 조금 돌아가는 방법도 괜찮다는 이야기입니다. 

 물론 돌아가는 방법을 선호하는 것은 천천히 다양한 방법을 찾는 것을 즐기는 본인의 취향 때문일 수 있습니다. 물론 가능하시다면 항상 구조를 잘 파악하여 최적의 Flow로 효율적인 방식을 찾을 수 있으면 훌륭하겠죠.

 

 

2. 가능한 변수를 줄이는 방향으로 작업할 것

 

 여기서 변수는 물론! 프로그래밍 변수를 이야기한 것은 아니지만 UiPath Studio로 작업을 해 보니 그것도 줄이면 좋을 것 같네요. 프로그래밍을 하는 경우에는 변수를 많이 사용하는 편입니다. 굳이 불필요한 데에서 억지로 만들어 쓰지는 않지만 하드코딩을 피해야 된다는 강박 때문인지 최대한 간단한 것이라도, 2번 이상 사용한다면 변수를 사용합니다. 하지만 변수가 많아지고 Flow의 깊이(Depth)가 깊어지면 변수를 구분하여 사용하는 게 약간은 어려웠습니다. 이 부분은 물론 제가 아직 UiPath Studio에 익숙하지 않아서 그럴 수 있습니다. 

 본격적인 처음에 이야기하고 싶었던 변수는 국어사전을 찾아왔습니다. 명쾌했습니다. 바로. "어떤 상황의 가변적 요인."입니다. 즉, 예외나 문제를 발생시킬 수 있는 것, 처리, 상황들을 줄이는 방향으로 Flow를 작성하는 것입니다.

 

한 예를 들면, E-mail을 자동으로 보내는 시나리오가 있습니다. 스팸메일이지만 각각의 사용자에게 발신자를 1명만 지정하여 보냅니다. 브라우저를 열고, 메일 발송에 활용할 웹 주소로 이동하여 ID, PW를 입력하고 로그인 버튼을 누르고 메일 쓰기 버튼을 누르고 보낼 주소와 내용을 입력하고 메일을 보냅니다. 하지만 여기서 이 작업을 아주 초보자인 제가 작업을 하여 여러 번 테스트를 하고 문제가 없어 시연을 한다고 가정하면 바로 Error가 발생할  것입니다. 왜 나면 브라우저를 닫지 않는다면 로그인 정보가 남아있을 것이고 다시 브라우저를 실행할 때 로그인할 필요가 없어 ID를 입력하는 작업을 할 때 Element를 찾을 수 없기 때문입니다.  여기서 바로 간단한 Flow를 하나 추가해 주면 위의 Flow는 문제가 없을 것입니다. 가장 앞에 작업으로 모든 브라우저(적어도 사용할 브라우저)를 닫아버리는 것입니다. 그러면 반복적으로 위의 플로우를 돌려도 로그인할 때 문제가 발생하지 않을 것입니다. 물론 한번 로그인해서 여러 사용자에게 메일을 보낸다면 로그인하는 작업까지는 1번만 동작시킨 후 보낼 주소와 내용을 입력하고 발송하는 부분만 반복하면 됩니다.

 

 

3. 예외처리와 흐름의 분기를 잘 구분하여 사용할 것

 

 이 팁의 경우 예외처리가 항상 여러 가지 상황에 대해 보완을 해 줄거라 생각하고 하나의 주 상황과 다른 예외상황까지 예측하여 작업을 해 뒀는데 그 부분이 잘 처리되지 않아서 생각을 해 봤는데 오히려 경우가 딱 두 가지면 (물론 그 이상도 가능하지만) 분기 처리하여 훨씬 수월하게 처리할 수 있었습니다.

 본인의 경험을 비슷한 상황의 시나리오로 만들면 다음과 같습니다. 윈도 탐색기에서 파일을 한 경로에서 다른 경로로 매일 복사를 하는 시나리오입니다. 그 경우 새로 만들 경로에 폴더를 만들고 파일을 복하 사면 간단합니다. 폴더를 만드는데 이미 있으면 새로 만든 폴더를 지우고 하는 예외처리들을 하였지만 생각해 보니 해당 날짜에 폴더가 있는지 없는지를 비교해보고 있는 분기와 없는 분기를 나눠 폴더 만드는 작업을 처리하니 순서 흐름 파악도 쉽고 성능도 훨씬 나았습니다. 물론 가상 시나리오와 달리 작업에 예외사항들이 많아 처음 생각했던 것처럼 예외처리로 구상을 하였지만 분기 처리를 고려하고 방법을 찾으니 훨씬 수월하게 작업이 되었습니다. 

 

 

끝으로 정말 이번 PoC의 소감은 2주간 같이 해 주신 전무님께 많은 것을 배울 수 있었고, 2번째 PoC를 같이 진행한 협력사 직원분도 저보다 훨씬 준비가 많이 되어있는 분이어서 도움을 받았습니다. 자동화라고 생각하고 듣고 해 봐도 쉽게 보면 한없이 쉽고 별것 아닌 것 같기도 하고, 조금 더 잘하고 편하게 하고 안전하게 하려고 하면 할 수 있고 해야 할 것들이 하고 싶은 것들이 무궁무진한 분야라는 것을 짧은 기간이지만 부족하지 않게 느낄 수 있었습니다. 글이 길어져 도입부에 적었던 미래를 위한 숙제와 세부적인 구현관련 내용은 아래의 포스팅에 작성하였습니다.

 

2020/02/24 - [UiPath] - [PoC] 2주 PoC에서 경험한 UiPath 구현 팁 외