그동안 RPA 개발을 외주에 맡기다 보니, 보안이 필요한 내부 자료를 다루는 과제는 추진 과정에서 제약이 많았다. 내부 검토와 보안 유지 절차를 거치느라 시간이 오래 걸렸고, 반대로 <업무개선학습> 동아리를 통해 자체 개발을 시도하면 전문 개발이 아니다 보니 프로세스의 무결성을 확보하기 어려웠다.
엑셀 VBA를 전문적으로 다루시는 책임님 한 분이 계셨는데, 그 분과 쿵짝이 잘 맞았다. 자연스럽게 '이 분과 함께 구매본부 내 자체 개발 역량을 키워보면 어떨까?' 하는 생각이 들었다.
하지만 현실적인 문제는 있었다. 기업용 UiPath 라이센스는 계정당 비용이 상당했고, 정식 추진을 위해선 개발팀의 교육 지원도 필요했다. 개발자 분들의 시간을 얻기 위해선 그만큼의 결과를 약속해야 했다.
매해 9월이면 내년도 사업계획을 만든다. 이 때 업무개선 과제로 이 아이디어를 냈다.
내가 낸 사업계획서는 이런 내용을 담고있다.
구매 본부에 '업무자동화 자체 개발 역량'을 보유하면
1. 개발 완료까지 6개월 이상 걸리는 시간을 단축할 수 있고,
2. 민감 데이터들도 활용할 수 있으며,
3. 개발팀에 투입됐던 인건비 절감도 할 수 있음
결과적으로 내부 직원들이 간단한 자동화는 스스로 구현할 수 있게 됩니다.
이 때 나는 좀 더 큰 그림을 그렸었는데, 구매팀은 특성상 늘 협력사와 함께 일하는 구조다.
그래서 나중에는 RPA를 협력사 지원 프로그램으로까지 확장해서 <협력사-우리회사-고객사>간 필수 데이터 통합 및 업무프로세스를 일괄 자동화하는 것까지 생각했다.
팀장님도 긍정적으로 보시면서 좀 더 디벨롭 해보라고 하셨다. 당시에는 사업계획서 써 본 경험이 많이 없어서 팀장님과 사수님의 도움을 많이 받아서 완성했다.
아이디어를 낸다고 무조건 채택되는 건 아니다. 예산도 지원받아야 하고 사수, 팀원들의 적극 협력도 필요하다. 교육 예산, 라이센스 예산은 지원팀, IT팀에서 적극적으로 지원해주었기에 가능했다.
구매 본부에서 정식으로 승인되었고, 그 다음해 1월에 예산이 지급 됐다.
공식 UiPath 라이센스를 받아 본격적으로 공부를 시작했다. 이때 처음으로, 그동안 내가 전수조사 해가며 진행했던 자동화 프로젝트들이 코드 형태로 내 눈에 펼쳐졌다.
<발주서 발송 자동화>, <공급 관리 보고서 작성 자동화> 등등...
'내가 한글로 정리해서 적어냈던 요구사항 정의서가 전문가의 손을 거치면서 이렇게 구현됐구나'
그야말로 나에게는 최고의 교보재이자 마스터피스였다. 내가 쓴 요구서에 대한 코드였으니까.
자연스럽게 나는 빠르게 배울 수 있었다. 개발자들이 써놓은 코드를 하나하나 따라해보며 익혔다.
그렇게 1,2월 내내 주말에 추가 근무를 지원했고, 집에서 원격으로 회사pc에 접속해 공부했다.
그 과정에서 개발자들을 자주 찾아갔다.(지금 생각해도 너무 감사했습니다 개발자님들)
질문거리를 항상 한 뭉치 가져갔다. 이틀에 한 번꼴로 화상회의도 했다. 감사한 마음에 커피도 엄청 사서 드리고, 편의점에서 과자를 쓸어담아 갖다드리고 했다. 그분들도 월급 받고 자기일을 하는거였겠지만, 도움받는 내 입장에서는 그저 감사했고 그 마음을 표현하고 싶었던 것 같다.
이 시기에 내가 중점적으로 공부한 내용은 '프레임워크'였다.
기업용 자동화는 사용자 개입 없이 로봇이 혼자 돌기 때문에, 에러 처리와 로그 기록, 안정성이 무엇보다 중요했다. 그만큼 구조도 훨씬 복잡하고 견고했다. 예를 들어, 예상치 못한 메시지 창이 떠서 클릭해야할 화면이 가려졌다고 해보자, 혼자 돌릴 때는 사용자가 개입해서 다시 시작하면 되지만, 기업용은 그런 예외사항까지 전부 자동으로 처리할 수 있어야 한다.
우리 회사 내부엔 통일된 프레임워크 규격이 있었고, 내가 만든 자동화도 그 구조에 맞춰 다시 짜야 했다.
내부에서 통일된 프레임워크에 맞춰 개발을 짜다보니, 전체가 하나의 구조로 돌아가게 되는 장점이 있었다. 한창 내 PC로 개발한 프로젝트를 진행했을 때 이런 질문을 받은 적이 있었다.
"나중에 떼오씨 없으면 이 프로젝트는 어떻게 되는 건가요?"
나는 이렇게 답할 수 밖에 없었다.
"그러면 이거 망하는 거죠"
근데 그러면 안 되는 거다. 구매팀은 특성상 직무 순환이 꾸준히 일어나는 조직이기 때문에. 내가 없어지면 이 모든 프로젝트들도 끊기겠다는 생각이 그때 들었었다.
이제는 그런 걱정도 없어졌다. 언제든지, 어떤 개발자가 와도 수정하거나 손볼 수 있다.
책임님과 함께 내부 교육 커리큘럼도 기획했다. 초급 과정은 우리가 직접 진행했고, 중급 이상은 개발자를 섭외해 진행했다. 처음에는 10~20명이 참여했지만, 마지막에는 5명 정도만이 남았다.
5명만 남은 것도 큰 성과라고 생각한다.
하지만 이 모든 과정을 겪으며 생각이 바뀌기 시작했다.
처음엔 '코딩은 배우면 누구나 할 수 있다'고 생각했었다.
직원 각자가 스스로 간단한 자동화를 할 수 있다면 효율성도 높아지고 좋을 거라고 생각했다.
하지만 내부 분위기는 딱히 바뀌지 않았다.
하나를 자동화하면 또 다른 반복 업무가 생겨났고, 비효율적인 업무가 새로 생기기도 했다.
업무자동화는 관심있는 소수만 할 수 있는 일이었다. 아무리 좋은 것이라고 해도, 스스로가 필요하다고 느끼지 못하면 사람은 움직이지 않는다.
뭐가 좋고 나쁘다는 말이 아니라, 사람마다 Function이 다른 것이다.
'자동화에 관심있는 사람만 해도 충분하다'로 스탠스가 바꼈다.
하나 더 큰 깨달음이 있었는데,
자동화 스킬 자체보다 중요한 건 조직 문화, 즉 사람에 있다는 사실이었다.
'자동화가 필요한 이유는 '비효율' 때문이다. 그런데 그 비효율은 어디서 오는가?'
에 대한 근본적인 질문에 답을 하기 시작하면 결국 사람으로 연결된다.
비효율적인 조직이 비효율적인 업무를 낳는다.
결국 자동화는, 필연적으로 조직 문화 개선으로 이어질 수밖에 없다.
조직 문화...!