RPA 개발자 입장에서 보는 RPA 잘하는 기준

RPA는 여타 다른 개발 분야와는 프로젝트의 결이 많이 다른 편이다.

개발자에게 요구되는 자질도 다른 여타 IT분야에 비해 좀 다르다.

그런 생각에 RPA 잘하는 기준은 무엇인지 새삼 정리해 보기로 했다.

 

다른 분야 대비 특이점 [각 케이스는 평균적으로 경향이 그렇다는 거지 무조건은 아님]

i) 개발자가 직접 작성하도록 요구되는 산출물이 많음

ii) 요구사항이 기능에 국한되지 않고 프로세스 전체 로직에 연관됨

iii) IT를 모르는 현업과 긴밀하게 협업해야 하는 경우가 많음

iv) 업무 프로세스에 대한 이해와 설계가 쥬니어에게도 요구됨

 

먼저 i)는 프로젝트 구성에 따라 조금씩 다르긴 하지만, 대부분 개발과 설계, 과제 정의가 궤를 같이 하기 때문에 일어나는 현상이다. 경우에 따라 컨설턴트나 PM이 붙어서 대신 해주기도 하지만 그렇다 하더라도 개발베이스의 전용 컨설턴트가 아닌 이상 수정사항이 많이 나온다.

ii)는 애초에 프로세스의 실질적인 주인이 현업이기 때문에 나오는 현상이다. 현업이 본인의 프로세스를 잘 이해하고 앞 뒤 영향 파악도 빠르게 할 수 있다면 좋겠지만 대부분 일 못하는 현업은 정리되지 않은 프로세스를 준다. 따라서 요구사항이 생각나면 나오는 경향이 심하며 설계 자체에 영향을 끼치는 케이스가 많다. 경험이 많은 RPA 개발자들은 이를 사전에 체크해서 설계단에서 잡고 나갈 수도 있다.

iii)는 일하면서 많이 답답한 사안 중 하나다. RPA는 커녕 IT도 전혀 모르는 경우가 많아 서로 간략히 소통하기가 쉽지 않다. 어떤 면에선 어느 정도 현업에게 개념을 가르쳐주는 경우도 많기 때문에 교육역량이 있으면 소통하기 훨씬 수월하다.

iv)는 업무 단위에 대한 내용이다. 보통 자바같은 개발의 경우 사이트 중 일부 기능들에 대해서 쥬니어에게 구현하도록 하는데 RPA는 과제단위로 일을 분배하기 때문에 그렇지가 않다. 과제 난이도가 쉬운 게 할당될지는 몰라도 쥬니어도 개발 프레임워크와 프로세스를 잘 이해하여 로직을 설계할 수밖에 없는 구조다. [이런 부분때문에 문과출신에게 접근성이 좋은 편이다.]

 

이런 특징들을 봤을 때 RPA를 잘하는 사람은

i) 프로세스 이해가 빠르고 프레임워크에 빠르게 녹여 설계함

ii) 각 분야별 프로세스 경험이 많음(=도메인 지식이 많음) [ex. 재무, 제조, 생산, 구매, 인사, IT 등]

iii) RPA의 아키텍쳐 이해도가 높음

iv) RPA툴 및 OS, DB에 대한 전반적인 이해가 있음

 

결국 현업과 소통하면서 프로세스 정리하는 능력 + RPA 이해도라는 뻔하지만 뻔하지 않은(?) 말이되긴 하는데

영업이나 컨설팅 역량이 있는데 개발도 좀 해보고 싶은 사람에게 RPA는 꽤 훌륭한 첫걸음이지 않을까 싶다.

[RPA가 쉬워서가 아니라 RPA에서 요구되는 자질을 갖추고 있기 때문]

 

사실 시장에 들어와보면 이런 구조때문에 겪는 애로사항이 많지만 그건 나중에 또 다룰까 한다.

-끝-