Talk Lowy(kr)

듣기 버전 :  https://youtu.be/cl20TO-a0IQ 한국에서 RPA가 확산될 수 없는 이유.. RPA란 Robotic Process Automation이라는 용어입니다. 소프트웨어 로봇이 업무를 자동으로 처리해준다는 것이지요. 원래는 Automation anywhere과 WinActor, Control-M 등이 선점한 업무 자동화 시장을 Microsoft가 판도를 바꾸었지요.. WWF, windows workflow foundation이란 무료 엔진을 공개 했습니다. 이 무료 엔진은 visual studio에서도 연결해서 만들 수가 있지요. 이건 무료 엔진이라 UiPath사가 제일 먼저 도입해서 RPA툴을 만들었습니다. UiPath는 초기 5000억원이라는 경이적인 투자액을 받아 한 번에 이름을 날리며 RPA 시장에 뛰어들어 기존의 Automation Anywhere, WinAutomation이나 WinActor, Control-M등의 강자들을 누르고 세계 RPA 1위에 등극하였습니다. 그러자 베트남의 FPT 소프트웨어가 이걸 보고 akabot이란 툴을 만들어 UiPath가 이미 깔린 기업에 리플레이스 영업으로 시장을 키워 갔지요. 어짜피 같은 엔진이라 UiPath에서 만든 xaml파일을 akabot에서 다시 실행이 가능했거든요. 치사하지만, 시장은 가성비의 경쟁이니까요.. MSDN의 WWF의 state machine이란 개념입니다. UiPath의 state machine설명 이미지 입니다. Akabot의 state machine설명 이미지 입니다. 너무 똑같지요? 당연히 엔진이 같은데 제로부터 새로 UI를 만들기엔 너무 방대해서 툴의 레이아웃만 파랗게 빨갛게 만들고 버튼 배치 정도만 바꾸고 상품을 출시한 것이지요. MS가 지속적으로 Update하는 다양한 버그 픽스나 기능 업그레이드를 따라오는 속도를 커버하지 못하면 이 엔진을 사용하기 힘들지요.. 그 만큼의 기술력은 필요합니다. 그런 단점보다 엄청나게 강력한 엔진을 무료로 주니 받아 써야지요

  UiPath 요즘들어 각광 받고 있는 UiPath는 초기 5000억원이라는 경이적인 투자액을 받아 한 번에 이름을 날리며 RPA 시장에 뛰어들어 기존의 Automation Anywhere, WinAutomation이나 WinActor, Control-M등의 강자들을 누르고 세계 RPA 1위에 등극하였습니다. https://www.youtube.com/watch?v=lgiChrgzzoU 이런 UiPath와 아래의 링크들에 있는 이미지들을 봐주시기 바랍니다. 모두 각 회사의 RPA툴입니다. https://docs.microsoft.com/ja-jp/dotnet/framework/windows-workflow-foundation/state-machine-workflows https://docs.uipath.com/studio/lang-ja/v2018.3/docs/state-machines https://akabot.com/wp-content/uploads/guide/jp/jp_akabot_guideline_studio.pdf 너무 같아서 이상하지 않나요? Microsoft는 자체적으로 RPA를 독점 공급하려던 과거의 개념을 버리고 ecosystem(생태계)를 만드는 방향으로 전환 했습니다.  즉, Platform은 누구나 사용가능하도록 오픈을 하고 그 위에 올라간 마켓 플레이스는 반드시 Microsoft의 Marketplace를 사용하게 하여 거기서 이득을 취하는 구조로 간 것이지요. (이렇게 플랫폼 정책을 바꾼 이유는 제 글 중  https://talklowykr.blogspot.com/2015/03/platform.html  에서 알 수 있습니다.) 때문에 WWF의 특징인 State machine이라는 개념이나 Orchestrator를 기반으로 하는 Studio의 개념, 그리고 파일명인 xaml을 그대로 가져가고 있습니다. 현재 UiPath및 Akabot 개발자들을 서포트해 주고 있는 저역시 UiPath등이 이상한 동작을 취하거나 기존엔 잘 되었던 것이 이상

MS의 저주일지도 모르지만,  역시 윈도우에서 발생하는 버그는 상상을 초월한다.  많은 부분을 Exception을 처리해도 알 수 없는 오류가.. 이번에는 Excel을 두 개 열어서 A파일의 S시트를 B파일로 복사해서  데이터를 그 포맷에 Write Range 로 쓰도록 하였다.  A파일의 S시트는 템플릿이 아니고 현재 사용하는 시트이다 보니 데이터가 있다.  그래서 Delete Range를 이용해서 삭제를 하니.. 에러가.. Excel Application Scope를 여러개 열면 뭔가 충돌이 난다.  그래서 이번에는 close workbook을 이용해서 매번 닫도록 해봤다.  그런데도 역시 Delete Range에서 알수없는 오류로 종료... B파일의 Excel Application Scope를 열어서 그 안에서 A파일의 Excel Application Scope를 열고, Copy -> Delete -> Write를 해보았다.  역시 에러.. 이번엔 분기를 해봤다.  Copy하는 경우는 Delete를 하지 않고,  Copy하지 않는 경우는 Delete를 하고..  기존 시트명이 있는 경우만 데이터를 삭제를 하는 방식이다.  이렇게 하니까 Delete Range는 성공 했으나 몇 개 실행하다보니 Excel workbook이 닫히지 않기 시작하면 다음 처리에서 에러가 발생..  두 개이상 workbook이 열리면 Write Range나 Delete Range에서 해당 파일을 찾지 못하는 것 같다.  결국 마지막 부분에 close workbook을 하여 강제로 죽여주니까 성공.. 그냥 놔둬도 닫히지만 안닫힐 때도 있는 경우에 따른 변수가 생겨서 close workbook의 타이밍에 따라서 에러가 나오기도 안나오기도 하네.. 윈도우즈의 버그는 ...  익셉션 처리하는게 코드 짜는 거보다 많은 거 같다.. -------- 추기1.  나중에 해보니 똑같은 에러가 빈도는 줄었지만 또 났다.  그래서 시도한 것이, Excel이 열리지 않은 경우는 workboo

정리는 시간나면 하고.. 일단 생각나는대로 적어둠. VBS에서는 for each를 이용해서 필드명을 가져오는 방법등이 있었지만 이는 원래 Recordset등의 필드명이 지정되었을 경우에만 해당한다.  datatable을 vbs에서 어떻게 for each로 만들지는 아직 연구하지 않았기 때문에 일단 패스, 아마 csv에서 첫 행을 헤더로 읽거나 xlsx에서 첫 행을 header로 읽으면 가능할 듯 하지만,  쉬운 방법으로 일단 기술해 본다.  ## csv의 경우 파일을 header있음으로 우선 datatable에 저장. 그리고 다시 파일을 text읽기로 하여 첫 로우만 변수로 저장. 저장된 변수를 sFields라고하면 aryFields = split(sFields, ",")  로 assign activity에 집어 넣음 물론 aryFields의 속성은 text속성의 array 타입 그리고 각 필드의 전후에 스페이스를 없애기 위해  Trim을 사용해서 스페이스를 없애줌. replace로 먼저 없애고 split을 하는 것도 가능. 그리고 datatable의 for each row 를 이용하여  매 row마다 for each로 aryFields를 호출(for each에서 row를 가져오면 안됨!) jLine = jLine + """" + item.toString + """:""" + row(item).toString + """" 이렇게 하면 필드 개수를 모르더라도 한 라인을 Json타입으로 가져올 수 있음.  물론 좌우는 {}를 적절히 넣어주고, 콤마도 적절히 if를 이용해서 넣을 것.  row(item).toString이 숫자인 경우의 처리는  Microsoft.VisualBasic.Information.IsNumeric 을 이용하여 판단 가능.  VBScript를 선택하였다 하더라도 MS Visual Basic과는 코드가

giip에서는 내가 만든 RPA스크립트로 인해서 얼마나 업무 시간을 줄여 주고 있는지 한 눈에 알 수 있습니다.  한 달 평균 업무 시간은 160시간 전후이지만,  로봇은 여러 대로 무한하게 일을 시킬 수 있기 때문에  내가 로봇들에게 시킨 업무로 인해 800시간을 줄일 수 있었네요!  점점 늘어나는 것을 기대하면서 계속 업무를 자동화 해가고 있습니다. ^^ UiPath를 사용해도 되고 Auto Hot Key를 사용해도 됩니다.  아니면 자신이 직접 만든 스크립트를 사용해도 됩니다.  이 모든 것을 giip에서 통합 관리를 하고, 자신이 만든 자동화가 얼마만큼의 인건비를 줄일 수 있었는지 알 수 있는 지표를 대시보드로 나타냈습니다.  여러분은 얼마나 많은 일을 아직까지 수동으로 하고 계신가요? giip :: Free mixed RPA orchestration tool!  https://giipasp.azurewebsites.net/

UiPath에서 Read CSV를 이용하면 Datatable에 저장이 된다.  이를 tab으로 분리된 text파일로 저장을 하는데는 몇 가지 방법이 있다.  1. write text 액티비티를 사용하는 경우 write text를 하게 되면, 그냥 텍스트로 저장이 되면서 tsv포맷에 맞지 않게 되고,  내용이 없는 경우 필드명도 표시 되지 않는다.  2. write excel을 이용 write excel 액티비티를 이용하여 저장후 이를 excel application scope를 이용해서 연 다음 다른이름으로 저장을 하여 txt파일로 저장. 번거롭지만 가장 편하게 tsv형태로 저장 가능 3. 하드코딩 첫 행에 필드명을 탭으로 나열 for each datarow를 이용하여 행을 읽은 뒤에 for each item으로 각 필드를 변수에 넣으면서 사이에 tab을 추가,  데이터가 없는 경우 필드명을 for each에 넣으면 데이터가 없기 때문에 패스한다.  때문에 첫 행은 하드코딩을 해야 하는 불편함이 있어 확정된 케이스가 아니라면 사용하기 귀찮다. 이걸 할 바엔 차라리 1번의 write text를 사용하는 것을 추천. Automation human works! giip :: Free mix RPA orchestration service! https://giipasp.azurewebsites.net/

유난히도 요청이 많았던 날이다. 그래서 한 번 요청 오늘 처리한 데이터 추출작업 파일 수를 세어 보았다. 94건... 일반적인 데이터 추출은 추출 조건 및 내용을 보고 요청자와의 커뮤니케이션, 추출 작업, 추출된 결과의 엑셀 정리 작업까지 하면 평균 25분 걸린다. 하루에 8시간 일한다면 쉬지않고 한시간에 3건 정도, 8시간에 24건 추출 가능하다. 정말로 쉬지 않고 말이다. 실제로 이 업무는 세 명이서 했던 것이고, 우연히 이렇게 몰려오면 날짜를 미루거나 해서 처리하는 것 같았는데, 그냥 하다보니 다 처리를 해버렸다. 상담도 들어주고, 휴식도 하곤 했지만, 요청 내용의 변경만 RPA에 적용 시키는데에도 하루 종일 걸렸다. 하다보니 조금 더 개선해야지 하는 내용도 머릿속에 떠올랐으나, 오늘은 정기 점검도 미룰 수 없고, 다른 요청 작업들도 담당자가 미룰 수 없다고 사정하는 바람에 전부 처리를 해주게 되었다. RPA의 파워가 느껴지는 하루였긴 했지만, 회사에서는 이 속도가 기준이 되어 버리지 않을까 하는 불안함이 생긴다. 나를 나가게 했던 모 회사가 나의 자리를 메우기 위해 5년을 사람을 찾다가 결국 타협하고 5명으로 늘린 실제 상황이 있었기 때문에.. 경영자들이 이런 과오를 또 일으키지 않았으면 한다.  Do not login your machine any more! giip :: Free RPA orchestration tool! https://giipasp.azurewebsites.net/

1999년도 부터 서버쪽 일을 계속 하면서 느꼈는데, github등의 공동 작업 서비스들이 발전하면서 엄청난 진화를 했는데, 현재까지도 기존의 방식을 사용하고 있는 기업이 너무 많습니다. 게다가 클라우드면 다되는줄 알고 전부 클라우드에 올렸다가 막대한 비용을 내고 있는 기업들도 있지요.. 규모에 따라 여러가지 어렌지는 필요하지만, 제가 사용하는 방법을 공개합니다. 1. Github계정을 생성, 소스 마스터는 유료 계정으로 설정(월 $7). * 소스 마스터가 유료이면 Contributor를 무제한으로 늘릴 수 있으나 무료 계정이면 2 명까지 밖에 못늘림(언젠가 부터 바뀐 정책). 게다가 워크 그룹이나 오거나이저를 생성하면 계정당 비용을 내야 함. 2. Azure에서 F1(Free) 티어로 App Service등록 * giipasp : 서비스용 App service * giipaspstg01 : 스테이징 1 * giipaspdev01 : 개발 1 3. DB서버 역시 클라우드로 만들어도 되고, 자체 서버에 DB를 설치해도 됨. 이번엔 Azure의 sql cloud 를 사용함. * giipdb DB생성. (10DAU로 설정하면 고정 SQL라이선스를 내지 않아도 됨) * 참고로 S1등의 스탠다드 DB로 만들면 사용을 안해도 1서버당 25만원 정도의 라이선스 비용이 별도로 과금 됨. (처음에 몰랐다가 지불을.....) 4. Github에서 Repository를 Dev, Real 두 개를 생성 * Real은 위의 유료 계정이 아닌 다른 관리 계정으로 만듬.   유료 계정은 개발 및 기타 여러가지 Repository를 잔뜩 만들기 때문에 나중에 deploy관리시 아주 많이 어려움. Deploy는 Contributor가 필요 없으니 차라리 새로 생성해서 Deploy전용 repository만 관리. * Dev : https://github.com/LowyShin/giipasp.git * Stg : https://github.com/

UiPath를 이용한 giipAgentUIP 를 받아서 실행. wsf를 호출하는건 문제가 없는데.. 디렉토리명이 일본어로 되어 있는 wsf를 호출하니 문제가!! wsf를 실행하는 것도 UiPath는 모르는 확장자라고 내뱉어서 우선 wsf파일로 저장후 wsf파일을 실행하는 batch파일을 저장, Start Process Activity를 이용하여 CMD.exe 를 실행하여 batch파일을 실행하도록 함. 이렇게 했으나, 결국 자동으로 UTF-8로 저장된 wsf파일은 열어보면 잘 보이지만 더블클릭하면 일본어가 깨짐. 이걸 ANSI로 저장하여 더블클릭해서 실행하면 정상 실행이 되었다. 그래서 Write Text File Activity에서 Endoding을 "shift_jis"로 저장하였더니 열어보면 ANSI로 되어 있다. 더블클릭하면 정상 실행, 하지만 UiPath상에서는 에러가.. 아직 해볼 법한 내용들은 몇 개 더 있지만, 소스에서 shift_jis를 박을 수 없고, 그렇다고 giipAgent에서 각각 스크립트마다 언어코드를 가져오도록 사양 변경은 쉽지 않은 상태. 기본은 UTF-8통신을 시키고 있다. UTF-8로만 할 수 있도록 모든 것을 맞추는 것이 나중에도 큰 불편함이 없으리라 생각해서 일단 언어 변환은 포기하고 우선 UiPath에서 일본어 디렉토리를 인식하여 처리하는 xaml파일을 만들어 invoke로 호출하는 것으로 대처함. UiPath : https://uipath.com giip로 Orchestrator없는 UiPath 자동화를! RPA를 생각한다면 다양한 툴은 많지만, 툴들의 장단점을 살려 의존을 줄인 giip에서 컨트롤을! Do not login your server any more! giip :: Free server management tool! https://giipasp.azurewebsites.net/

리눅스에서 로그성 데이터들이 쌓이는 곳들이 몇 곳이 있다. 그 중에서 일정 기간 지나면 자동으로 지워지지 않는 파일들이 있는데, 이를 매일 들어가서 지우는 것도 일이다. 삭제도 좋고, 데이터를 이동하는 것도 좋은데, 파일을 이동하는 스크립트로 만들어 봤다. mkdir -p /data1/expdata/partitions for   i   in   `find /oracle/expdata/partitions -mtime +4 -type f` ;  do  mv  $i  /data1/expdata/partitions;  done 이렇게 하면 4일이 지난 해당 디렉토리의 파일을 /data1/expdata/partitions 로 이동한다. 이걸 크론에 등록 하면 (crontab -l ; echo "1 0 * * * sh /data1/DBA/LowyWorks/arrange_oldfiles.sh")| crontab - 쉘에서 이걸 실행하면 자동으로 crontab에 등록 된다. 물론 등록 할 때의 로그인 계정으로 등록되니 crontab에 등록할 때 여기저기 계정으로 등록되지 않게 주의해서 등록하기 바란다. 위의 find 는 일반적인 find문을 그대로 쓸 수 있기 때문에 | grep -v .sh 처럼 이동하고 싶지 않은 파일들을 제외할 수도 있지만, 관리를 위해서는 로그성 데이터는 모두 한 곳으로 이동해 놓는 것을 추천한다. 더 많은 정보를 보고 싶다면, https://github.com/LowyShin/KB-KnowledgeBaseHome/wiki/Shell

일반인들에게  RPA를 가르치면서  배우기 위해 온 사람들을 봤습니다. 2~30대도 있지만,  50대가 넘는 사람들도 왔습니다.  배우지 않으면 정년 전에 밀려날 것 같다는 불안감을 떨구기 위해 최소한의 지식이라도 습득하려 오셨더라구요. 그 동안에는  오피스 정도만 만지는게 고작이었는데.. 지금 50대는  PC가 없이 대학을 졸업한 분들도 있습니다. 너무 빠른 변화에 이해가 안되도  어떻게든 따라가려 하는 모습이 안타깝기도 합니다. 이젠 엑셀도 로봇이 대신하고, 휴가도 로봇이 대신 내주고 있습니다. 사람의 실수를 로봇이 체크해주고 있고, 적정성 평가를 로봇이 대신 내주고 있습니다. 로봇에게  빼앗기기 시작하고 있는 일자리 젊은 층은 어떤 일자리를 찾아야 할까요? 단순하게 얘기하면 창의력 이 필요한 일자리는  이미 물건너 갔습니다. 그림을 사람보다 잘 그리는 로봇이나 새로운 향수를 만들어내는 로봇 새로운 음악을 만들어내는 로봇 거의 모든 일자리는  천재 0.01% 로봇 70% 그외 29.99% 이런 구조로 될 것입니다. 천재가 아닌 대부분의 사람들은 로봇에게 일자리를 뺴앗기고 그 외의 29.99% (갈 수록 줄어들겠지만)에서  더욱 치열한 싸움을 하겠죠.. 아직 로봇이 점령하기 전인  지금도 취준생의 문제가 심각한데 말이죠.. 그리고 저 29.99%는 아마도 로봇에게 지시를 받아서 로봇조차 가성비가 안나오는 일을  하는 것일 겁니다. 제가 가르치는 사람들에게  많이 하는 말이 있습니다.  로봇을 제어하거나 로봇을 수리하는 일은 당분간 로봇이 대체하기 힘든 영역일 것입니다. 차라리 이 쪽으로 눈을 돌리라고 종국에는  수리 로봇이나  로봇을 제어하는 로봇들도 나오겠지만. 사람들은 로봇의 지배를 두려워 하여 이 영역만큼은 로봇의 힘을 빌