Talk Lowy(kr)

  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등이 이상한 동작을 취...

코드를 공부하는 글이 아니므로  샘플 코드등은 없으니  코드를 찾으시는 분들은 패스하셔도 됩니다.  개념 적인 접근, 그리고 사용법은 아는데  추가적인 돌파구를 위한  아이디어를 원하시는 분들을 위한 글입니다.  대부분 도큐먼트(글뭉치?)의 의미를  한 눈에 캐치하여  인덱싱하여  도큐먼트를 관리하기 위해  Topic Modeling을 사용하려 하고 있습니다.  하지만 단순히 LDA를 사용해봤자,  사용된 단어의 개수가 많은 글들끼리의 묶음 정도로 밖에 분류가 안됩니다.   https://en.wikipedia.org/wiki/Latent_Dirichlet_allocation LDA : 잠재적 디리클렛 배분법 google스러운  정보의 정리를 위해서는 하나만 사용하는 것이 아니라  다양한 ML모듈을 활용해야 하는데요..  예를 들어 이렇게 합니다.  LDA모듈로 문장을 읽어내면 단어의 기본형과 Document에서 사용된 단어수가 나오고 이를 기반으로 이 document의 topic에 해당할 법한 상위 단어들이 표시됩니다.  여러 document를 던질 수록  각각의 document그룹에서  사용된 빈도가 높은 단어들이 나옵니다.  여기서 topic이 다른 문서가 많이 섞일 수록 topic을 유추하는 확률이 많이 떨어집니다.  그리고 언어가 여러 언어일 수록  서로 모르는 언어가 되버리고 마는 것이지요.  여기서 제가 많이 사용하는 방법은,  모든 언어를 영어로 번역합니다.  google translate API는 무료로 소량의 번역을 해주는데 만약 google sheet의 translate 함수를 사용하면  속도는 조금 느릴 수 있으나 많은 제약이 사라집니다.  뭐, 구글 어카운트를 여러개 만들어서 돌리는 것도 방법...

이번에는 2015년에 썼던 글을 다시 한 번 정리하려고 합니다.  언제나 이야기 하듯이 단어에 대해 누구에게나 쉽게 설명하지 못하면 그건 그 단어를 아는게 아닙니다.  여러분도 이 단어에 대해 비 IT이든 전문가 이든 설명해 줄 수 있는지 한 번 생각해 보시기 바랍니다.  플랫폼에 대해서 이야기를 하다보면 되묻고 싶은 이야기다. 요즘 개발자들 사이에서.. 또는 서비스 기획자들 사이에서 "플랫폼"이란 단어는 필수어가 되었다. 그런데 개발자들 만이 아니라, 기획자, 경영진까지 플랫폼은 필수이다.  웃긴건..  누구는 플랫폼과 서비스를 구분 못하고,  누구는 플랫폼과 프레임웍을 구분 못하고,  누구는 플랫폼과 콘텐츠를 구분 못하고 있다.  이번에는 플랫폼과 서비스를 구분해 보고자 한다.  그런 사람들끼리 이야기하다가 플랫폼이란 단어를 사용하는 사람들에게 물어본다. "플랫폼이 뭔가요?" 누군가 대답한다. "아직도 플랫폼을 몰라요?" 그럼 이렇게 되묻는다. "네.. 제가 잘 몰라서요.. 좀 알려주시겠어요?" 상대방은 IT시스템 어쩌고 하면서 횡설수설한다.. 얼마전 TV에서 플랫폼전문가가 요즘 IT쪽에 도는 플랫폼에 대해서 이야기 한다고 보라고 권장해주었다. TV를 찾아서 보았다. 플랫폼의 정의에 대해서는 나름 이야기를 했다. "수요자와 공급자를 연결해주는 매개체" 그리고 카카오톡을 성공한 플랫폼이라고 했다. 어짜피 성공한 사업에 이름을 붙이는 것은 쉽다. 성공한 주식의 과거를 분석하는게 쉽듯이.. 하지만 성공하지 못한 사업, 그리고 지금 이것이 플랫폼인지 알 수 있는 사람은 몇 안될 것이다. 단어의 의미를 한 번 다시 생각해보자. 그럼 플랫폼은 언제 시작했을까? 18세기후반 부터 19세기에 걸쳐서 약 100년정도를 산업혁명이라고 불렀다. 산업 혁명에 대한 자세한 이야기는 별도 코너로 만들었습니다.  음성 :  https://y...