다만 IP Resolution 방식인 경우에는 Azure나 SignalR같은 서비스에 대해 IP가 변동될 수 있음을 안내해야 한다.
+ 사내 방화벽 관리자와 서비스를 이용하면서 트래픽을 모니터링할 필요가 있다. [막히는 걸로 의심되면 그걸 풀어줌]
보통 Start Job이나 package 다운로드, UR연결 등을 해보면 대부분 체크가 된다.
1. 라이선스 등록 및 유저 생성
- 라이선스는 기본적으로 12자리 시리얼 Key 형태로 주어진다.
- User는 기본적으로 Email을 필수로 하기 때문에 Verify 과정을 Email 링크로 진행한다.
- 최초 SSO 계정은 주어지지 않으며, 그냥 처음에 Group을 만든 User가 전체 관리자가 된다.
- 관리 계정을 따로 만들고 싶다면 메일 계정을 연결하여 권한을 주면 된다.
- 관리 계정으로 administration을 들어가 '계정 및 그룹'에서 사용자를 초대할 수 있다.
- administration에서 라이선스를 들어가면 Enterprise 활성화가 있고, 이를 활성화하면 라이선스 기간이 시작된다.
2. 머신 및 로봇 연결
- Machine은 템플릿 형태로 생성해야 한다. [Modern 기준]
- Machine의 Production이 1이라는 것은 한번 연결될 때 라이선스를 1씩 부여한다는 뜻이다.
- 즉, 유효한 Machine Template이라면 Production이 1로 올려져 있다.
- Developer와 Attended Robot(User)는 오케스트레이터에서 권한을 주고 Assistant를 통해서 로그인만 하면 된다.
- 머신키로도 인증하고 싶으면 테넌트 선택 - 설정으로 들어가서 로봇 보안에서 수동로봇 관련 '하이브리드'라는 항목을 체크[굳이 이렇게 해서 Device에 종속될 이유는 없다. 그게 필요한 경우는 설정.]
- UR은 계정에서 로봇 유저를 일단 만들어야 한다. 로봇유저는 기본적으로 UR만을 위한 계정이다.
- UR로 연결할 Device는 UR버전으로 설치해야 한다. 설치에 시스템 서비스를 포함하고 있기 때문. 실제로 UR로 설치하지 않으면 연결이 되더라도 AutoLogin이 되지 않는다. 이 부분은 장치를 관리하는 사람 입장에서는 이전에 비해 불편해졌다고 할 수 있다. (AR을 Windows Scheduler로 쓰는 입장에선 UR로 깔고 AR로 연결하는 편이 낫다. 아니면 Windows Lock을 그냥 없애든가)
- 테넌트 레벨에서 엑세스 관리 - 로봇 유저 편집을 하면 로봇 설정이라는 카테고리가 있다. 거기서 머신 로그인 자격증명을 체크하고 연결할 로봇의 구체적인 Windows Credential을 입력해주자.
- 사용할 폴더 레벨에서 머신템플릿을 할당하고 그 폴더에 할당될 수 있는 로봇을 주면 연결 준비 완료(커뮤니티 클라우드쪽에서는 머신에 로봇을 할당하는 메뉴가 뜨지 않는 듯)
- UR의 경우 Machine Key와 연결해야 하며, Cloud 주소는 폴더를 선택했을 때 나오는 주소 기준으로 입력해야 제대로 들어간다. (클라우드의 경우 https://cloud.uipath.com/{그룹PK}/DefaultTenant/orchestrator_ 형태다.)
- 온 프레미스의 경우 UR에서 OAuth Application Connection을 요구하기도 하나, 무인로봇 하이브리드 체크하고 머신키 인증을 하는 게 수월하다.
- 한국 시장은 내부 관리자가 RPA를 주도하지 않는 이상, 하청업체에서의 SI는 완전히 영업을 잘못하는 경우가 많다. 실제 과제와 요구사항에 대한 분석없이 기간과 맨먼스로 판매하면서 개발자의 몸값은 Discount하며 경쟁하고 있다.
- 따라서 ROI는 여전히 나오지만 RPA SI 하청업체 입장에선 부가가치가 크지 않다. 몸값은 낮춰놨는데 맨먼스 계약을 하기 때문에 개발자는 그 기간동안 배치를 해야되고, 개발자도 빨리 개발을 마치고 나올 유인이 없다. 영업은 최대한 고객이 만족할만한 기간동안 과제 개수를 많이 채워준다고 하고 계약한다.
- 문제는 고객사 입장에서는 퀄리티를 판단하기 어려우므로 싼 업체를 선택하고, 교육받지 않고 체계적이지 않은 업체들이 들어와 기간만 보내다 철수한다. 이 경우 RPA에 대한 긍정적인 경험을 갖지 못해 후속 프로젝트를 진행하지 않는 경우가 많다. (다른 IT 분야에 비해 이런 경우가 더 잦은 이유는 환경변화에 민감하기 때문이다.)
- 결국 RPA는 앞단에서 제대로 컨설팅되고 PI가 제대로 진행되어야 큰 힘을 발휘할 수 있는데 IT영업단에서는 치킨게임을 하기로 결정한 모양새다. 궁극적으론 빠른 컨설팅 이후 예산에 따라 프로젝트 규모를 제안하는 형태로 계약 프로세스가 바뀌어야 한다고 본다. 이를 위해선 공수, 난이도 관련 기준이 명확해져야 한다.
- 드물게도 전문적인 내부 관리자가 RPA를 주도하는 경우, 과제 개발 속도를 맞추기 위해서만 하청업체를 선택하는 편이다. 진행의 실제 성과가 내부 관리자의 성과가 되기 때문에 PDD나 요구사항이 제대로 갖춰지지 않은 경우, RPA에 적합하지 않은 과제인 경우 필터링하여 진행한다. 다른 사이트는 이런 필터링이 전혀 없이 개수와 맨먼스만 언급된 계약이므로 필터링할 이유가 없고 실제 개발 과정에서 지연 사유가 된다.(이는 하청업체 입장에서 더더욱 RPA의 부가가치가 안 된다 판단할만한 사항이다.)
- 작년 중반부터 나름 대기업, 중견기업들의 DU수요가 있었고 프로젝트도 진행되었다. 다만 아직까지도 '그 과제가 전사 입장에서 진짜 DU가 필요한 과제였나'에 대해선 개인적으로 PI가 부족했다고 느끼고 있다. AI 도입이라는 사내 성과를 얻기 위한 도입 수요가 많은 게 아직까지의 현황이다. ['꼭 DU가 필요한 과제'에 관해선 추후 정리 예정]
2. 전망(한국 시장 및 기타 기술 동향)
- 현재 MS, SAP, IBM 등이 공격적으로 RPA 시장에 뛰어들고 있다. 결국 RPA가 IA측면에 녹아들어야 하는데 지금 뛰어든 업체들은 그런 부분에서 강점이 있는 편이다. AA와 Uipath는 2025년까지 꽤 치열하게 주도권 방어를 해야하지 않을까 싶다. (한국에서는 AA가 많이 밀린 상황으로 보인다. 현재 AA는 독자노선으로 툴을 Web Base[Java기반]으로 변경하며 User Friendly로 노선을 잡고 있는데, 국내에서는 아직 느리고 이슈가 많다고 판단하고 있다.)
- Global Main업체인 AA, Uipath, Blue Prism은 각각 AI기능, 클라우딩 기술 관련 기능, 과제 발굴 및 정의 통합 패키지를 주로 신경쓰면서 Product를 내놓고 있는 중이다.
- 중국쪽 RPA시장이 커지고 있다고 한다. 특이한 것은 중국의 경우 RPA를 먼저 도입하고 AI를 도입하는 게 아니라, AI를 도입하다가 RPA를 도입하는 경향이 있다.
- 작년의 전망글에 App과의 Integration을 묻는 댓글이 있었는데, 기존 지배적 지위를 누리던 소프트웨어의 개발사들이 RPA시장으로 뛰어들면서 그런 류의 통합이 꾸준히 일어날 수도 있는 환경이 되고 있다.
- Document Understanding(DU)이 2021년 10월 기준으로 stable하지 않나 판단하고 있다. 다만 아직까지 과제 적합성 판단, 가격, 이를 운용하기 위한 서버 스펙 등이 진입장벽으로 작용하고 있다. 웬만하면 2022.4부터는 기술적인 문제는 많이 해결될 예정이므로 2022~23년에는 본격적으로 대기업들이 DU를 도입하지 않을까 생각한다. 꼭 DU가 아니더라도 RPA가 머신러닝 모델링을 위한 데이터 수집 및 전처리를 위해 쓰일 가능성도 있다.
- 공공기관, 공기업에서는 Brity Works 도입에 한창 열을 올리고 있다. RPA를 도입하긴 해야되는데 국산툴을 찾다보니 나오는 결과다.(삼성SDS, KT DS, 그리드원 정도의 삼파전인데 아무래도 삼성이 유리하다.) 삼성그룹 내부 계열사에도 Brity Works 단가를 낮춰 배포에 열을 올리고 있지만, 아직 툴이 상대적으로 불안정하고 커뮤니티가 좁아 불편을 느끼고 있는 것으로 알고 있다. (개발자 입장에선 내부 flowchart내 sequence를 자유자재로 바꿀 수 없고, 복잡한 얼개를 짤 때 구조 파악이 힘들면서, 사용할 수 있는 라이브러리 풀도 좁다는 게 가장 큰 불편함이다.) 이외 금융권이든 제조업이든 무관하게 사기업쪽에선 Uipath의 비율이 지배적이다.
- RPA 국내 수요 증가는 작년에 비해선 완만해진 분위기다. 그래도 여타 4차 산업혁명 라벨을 붙일 수 있는 산업중에선 가격이 싼 편이기 때문에, 중소기업에서도 꾸준히 문의가 들어오는 것으로 보인다.
사용 설정만 하면 구글 시트뿐 아니라 Gmail이나 Google Vision, Google Drive 등도 손쉽게 쓸 수 있다.
인증은 api키, oath, Account key(JSON) 방식이 있는데 Account Key가 가장 발급, 관리가 쉬운 편이다.
api키, oath는 크롬에서 재인증 요청을 하는 케이스가 많다. [일단 권한을 부여 해두면 그 로컬에서 돌아가긴 하지만 Device가 바뀌거나 세션이 지워지면 또 물어본다. deploy하는 입장에선 중대한 관리포인트다.]
** 2022-02-28 내용 추가
1. 몇몇 Cloud Service는 결제 계정(Billing Account)을 필수로 함
2. Cloud Vision 쓸 일이 있어 Service Account로 API 형태로 소환하는 건 잘 됐으나 Cloud Vision Activities의 Scope에서 활용할 때는 권한 문제가 생겼음. => API키로 설정하면 권한 문제 없이 넘어감. 서비스 계정이 앱에서 사용될 때의 제약인 것으로 보임.
3. 구글시트나 구글 드라이브 같은 Billing Account가 필수가 아닌 앱들의 경우엔 Service Account가 더 주효했음. Api Key의 경우 간혹 로그인 확인절차를 거치는 케이스가 있었던 것으로 기억.
