작년에 RPA의 흐름에 대한 글을 갈무리하고 1년이 넘어서야 새롭게 글을 쓰게 됐다.

그 사이에 상당히 많은 흐름의 변화가 생겼다.

 

i) AI 도입 OCR이 서서히 도입되는 중

작년만 해도 아직 정식 도입되기에는 시기상조일 수 있다고 썼으나, 지금은 서서히 도입 가능할 정도로 올라왔다. 역시나 UP가 가장 빠르게 진행하고 있는 것으로 보이고 늦어도 올해 말엽부터 시작되는 프로젝트들은 Document Understanding 기술이 들어가는 과제를 최소 하나 이상 끼고 있지 않을까 예상해본다.

 

ii) Portal을 따로 도입하기에는 솔루션의 중앙통제 아키텍쳐들이 사용하기 쉽도록 잘 개선되고 있음

작년엔 포탈에 대해 갈팡질팡하는 곳이 많았다면 지금은 아주 가격이 싸지 않는 이상 안 하겠다는 분위기가 있지 않나 싶다. UP, AA, BW 등등 각 툴들도 관련한 권한 분할을 더 세련되게 개선하고, 일반 User가 접근해 디자인하거나 참여하는 형태의 기능을 도입하고 있다. 포탈 제공 업체 입장들은 관련 Swagger API가 아닌 이상 따로 Custom하는 공수가 꽤나 필요하므로 Swagger API만 적용한 기본 포탈을 일종의 미끼상품(?)처럼 Standard 형태로 무상제공 하는 전략을 보이고 있다.

 

iii) 재택근무 시스템 정비로 인한 본격적인 수요 증가세

재택근무를 경험한 대기업들의 만족도가 생각보다 높아지면서 시스템 연결 관련 단순 작업에 대해 RPA 수요가 커졌다. RPA 개발자 입장에서는 굉장히 반가운 소식이다. 단순히 수요가 늘었다는 측면뿐만 아니라 정말 'RPA가 수행해야 되는 과제'일 확률이 높아졌기 떄문이다. 정합성과 권한 관련한 의심, 절차 정비가 많이 누그러졌고 재택 관련한 시스템 정비가 많이 이뤄졌기 때문에 RPA 수요 증가세가 가파르다. 

iv) 개발 공수 관련 혼잡성은 여전

RPA 비지니스 측면에서 어려운 것이 과제개수 X 난이도 => 공수 산정 얼마나 해야 적당한가이다. 영업 입장에서는 최대한 줄이고 싶겠으나 결국 적당한 선에서 주어져야 하는데, 각 프로젝트 사이트마다, 사용하는 시스템의 안정성마다, 과제의 복잡성에 대한 판단 기준에 따라 실제 공수는 달라진다. (역으로 프로젝트 경험이 없거나 실제 업무를 잘 모를수록 과제 개수만 따지는 경향이 있다.) 그나마 서로 변수를 줄이기 위해선 프로젝트 계약 이전에 구축사에서 공수산정을 위한 인터뷰, 테스트를 진행해보는 것이 베스트이다. 어중간하게 내부 담당자가 대충 산정했다가 1차 구축에서 곤혹을 치르는 경우가 많다.

 

v) 시장 점유율 변화

작년에도 이미 많은 변화가 있었으나 지금은 거의 결정됐다고 봐도 되지않을까 싶다. 결정적인 레퍼런스가 됐던 곳들에서 연이어 전환하고 공공쪽에서 수요가 시작되면서 조정이 되고 있다. 구체적인 부분은 민감한 사안이므로 따로 언급은 안 하겠지만 실제 시장 상황을 알아본 담당자라면 알고 있으리라 생각한다. 개발자 입장에서는 느끼는 것은, 결국 전체 아키텍쳐 수준에서 좋은 것은 각 회사의 개발자들도 알게 된다는 점이다. 영업전략이나 가격 모두 중요하지만 장기적으로는 그런 근본적인 변수들이 영향을 미친다.

+ Recent posts