RPA 구축사의 Business Model에 대한 고찰 2편

1편에 이어 2편이 굉장히 늦었다.

이번 글에서는 'RPA회사는 정확히 어떤 서비스를 파는가'와 '그런 서비스를 제대로 팔기 위해 필요한 것'을 쓰고자 한다.

 

일단 현재 대부분의 국내 SI업체들이 제안하는 계약형태는 이렇다.

과제 개수 N개 => 개발자 투입 M명 * L개월 (보통 1명이 한달에 2~4개 정도 개발한다고 생각하고 러프하게 함)

+ 라이선스 비용(중개비 포함)

 

개발자는 초급, 중급, 고급 기준으로 하는데 중*고급은 사실상 찾기 어렵고

초급 기준으로 500~600 내외로 계산하는 것으로 알고 있다. (2022년 기준)

운영은 그보다 1.5배는 더 비싸다 생각하면 되겠다.

 

계약 형태를 봤을 때, SI업체에서 생각하는 서비스의 방식은

러프한 '과제 개수'만큼의 구축, 안정화를 하고 나오는 것이다.

 

그 과정에서 구체적으로

개발자에게는 과제발굴, 과제컨설팅 및 PI, 과제설계, 과제개발, 과제안정화 및 산출물 작성 등이 요구되며

관리자에게는 개발규칙 및 소스 안정성 관리, 진행사항 리포트 및 요구사항 대응, 산출물 관리, 이슈 관리 등을

기대하게 된다.

 

이런 프로세스를 빠르고 퀄리티 높게 완성시키기 위해서는 하기와 같은 것들이 필요하다.

1) 공통 로깅이 자연스럽게 남고, 비지니스 로직만 넣으면 소스가 완성되는 프레임워크

2) 모듈화된 시스템 접근, 공통 기능

3) 요구사항이 정확하게 작성된 과제 디자인 문서

4) 합리적인 개발규칙 및 산출물 작성 기준

 

여기서 실제 프로젝트에서 생산성을 높이기 위해 가장 중요한 것을 하나 뽑으라면 PDD이다.

일반적으로 대기업이 아니고서는 보통 PDD 작성 및 조율까지 RPA 구축 업체에 맡기는 경우가 많다.

대기업에서도 RPA를 전문으로 하는 컨설턴트를 쓰지 않기 때문에 조율이 많이 필요하다.

이 부분이 중요한 이유는 이 단계에서 추후 개발의 크기가 결정되기 때문이다.

 

원래 제대로된 계약을 한다면 기존에 발굴 과정에서 선정할 때,

요구사항이 명확하고 시스템이 안정적인 걸 선택하거나 어려운 과제에 대해선 더 높은 공수를 부여해야 한다.

지금의 계약형태는 이런 과정을 단순히 비용으로만 치부하고 오버되는 부분을 개발자에게 떠넘기기 좋게 만든다.

게다가 고객사 입장에서도 웬만하면 과제개수를 압축해서 최대한 현업요구를 많이 들어주게 하고 싶다.

[물론 무조건 이런 방향만 있는 건 아니다. RPA 프로젝트를 제대로 관리하는 것도 고객사 담당자의 일이므로]

결과적으론 마치 1000원 받았는데 라면에 음료수, 과자까지 사줘야 되는 상황이 자주 나온다.

SI에 있는 RPA 개발자들이 인간 RPA가 되어있는 웃픈 상황은 근본적으로 여기에서 비롯된다.

 

 

 

---------------------------------------------------

프로젝트 대부분이 계약은 물론 내부에서 필요한 것들을 제대로 갖추지 않고 현장에 뛰어든다.

개발자들은 스튜디오 레벨, 패키지 레벨에서만 허우적대기 쉽고

6개월 이상 있으면 성장은 더뎌지기 쉽다.

그를 상쇄하기 위해선 서로 각자의 시스템, 협의방식에 대한 접근을 정리하고 공유해야 한다.

그래야 너머의 확장성과 아키텍쳐, 거버넌스를 보며 제안을 할 수 있다.