brunch

You can make anything
by writing

C.S.Lewis

by 루크의 IT이야기 May 20. 2019

IT 운영 툴 자동화와 업무 생산성

IT본부장으로 살아남기 : 3편

본부장(이사)라고 하면 왠지 사원들과는 무언가 달라 보이지만, 실상을 놓고 보면 회사에서 살아남기 위해 몸부림치는 한 명의 회사원이랍니다. 중견 교육업계에서 월급쟁이 중 한 명인 IT본부장으로 재직하면서 배웠던 다양한 조직 운영과 업무에 대한 지식과 경험을 공유하려고 합니다.


회사의 역사와 IT 인프라

필자가 다니고 있는 회사는 30여 년 가까운 업력을 가지고 있는 나름 역사와 전통을 가지고 있는 회사이다. 하지만 회사의 역사와 전통과는 크게 상관없이 사내 IT 인프라 수준은 안타깝게도 그 역사에 걸맞지는 못하였다.


대표적인 예로 홈페이지를 운영하기 위한 운영 툴의 자동화가 미흡한 부분 그리고 인사관리 시스템, 재무 관련 시스템이 여전히 전산화가 되어있지 않는 점 등이다. 

우리 본부의 팀원의 이력정보를 보려면 인사팀에 가서 이력서가 출력된 종이 파일을 가져다가 보고 복사 후 다시 반납을 해야 한다거나, 우리 본부원 휴가가 며칠을 남았는지를 실시간으로 알 수가 없다거나, 홈페이지 내 배너 하나를 교체하기 위해서 기획자 > 디자이너 > 퍼블리셔 > 개발자를 통해 교체를 해야 한다거나 하는 일들이다.


이러한 IT에 기반한 운영 툴이 얼마나 자동화, 전산화가 되어있는지와 그 회사가 IT를 통해 비즈니스를 하고 있는지는 완전히 다른 문제이기 때문이다. 솔루션을 개발하는 회사라고 해서 내부 업무를 위한 툴들이 모두 전산화가 되어있지는 않다는 말이다.


쇼핑몰을 운영하는 회사가 하나 있다고 가정해서 예로 들어보자, 고객이 주문한 물품들이 자동 배송 시스템을 이용해서 배송되는 시스템을 가지고 있는 회사가 있고, 고객의 주문 내역을 일일이 송장을 출력하고 박스를 포장해서 배송을 한다면 고객의 입장에서는 물건을 구매하고 배송을 받는 면에 있어서는 아무런 차이가 없지만 회사의 생산성 입장에서는 하늘과 땅 차이의 업무 생산성을 보여주게 되는 것이다.


회사의 업무 전산화 척도

필자가 20여 년간 다양한 회사의 경험을 비추어 보았을 때, 회사의 전반적인 시스템이 얼마나 전산화가 되어있는지를 보려면 


첫 번째 ERP가 제대로 도입되어있느냐?

그 회사의 내부 시스템이 얼마나 IT 화가 되어있느냐에 대한 기준이 될 수 있지 않을까 생각이 든다.

ERP는 Enterprise Resource Planning의 약자이며, 전사적 자원관리를 하는 시스템으로 회사의 모든 정보가 전산화되어 재무적 관점에서는 전산화가 완료되었다고 볼 수 있다. 좀더 쉽게 풀어쓰면 월 결산을 할때 ERP 가 있는 회사는 3~4일이면 결산이 가능하지만 ERP 시스템이 없는 회사는 최소 10일이상의 시간이 걸리게 된다.


두 번째로는 다양한 운영 툴이 얼마나 자동화되어있느냐?

즉 다시 말하면 홈페이지 또는 어떠한 시스템을 운영할 때 얼마나 개발자의 관여도가 적은 지가 회사의 업무 전산화의 또 다른 척도가 아닌가 싶다. 앞서 이야기한 배너를 변경하는데 운영자 혼자서 변경할수 있는지 아니면 개발자의 도움을 받아야 변경이 가능한지라고 말할수 있을것 같다.


세 번째로는 재직증명서를 바로 출력할 수 있는지와 같이 실제 내부 임직원들이 사용하는 업무 툴이 전산화가 되어있는지이다. 


앞서 이야기한 ERP 가 핵심 업무에 대한 전산화라고 하면 운영 툴 전산화는 실무단에서 업무의 생산성이 얼마나 효율적인지를 보여줄 수 있는 좋은 예가 아닌가 생각된다.


IT 운영 툴 자동화와 업무 생산성

IT 본부장인 필자의 입장에서는 업무의 전산화가 되어있지 않는다는 건 그 만큼 내가 해야 할 일들이 많이 있다는 것이고, 또한 내가 회사에 기여할 점이 많다는 점에 있어서는 단점이 아닌 장점이 될 수도 있다.


그럼 운영 툴이 자동화되어있을 때와 자동화가 되어 있지 않았을 때 얼마나 업무 생산성에 영향을 끼치는지를 예를 들어 설명해 보도록 하겠다.


첫 번째 사례로 홈페이지에 배너를 하나 바꾼다고 가정을 해보자!

웹사이트에 하나의 배너를 바꾸는 일은 개발적으로 어려운 일도 아닐뿐더러 별로 대단한 일이 아니다. 보통의 개발자가 10분 내외면 배너를 교체하게 될 것이다.

하나의 웹페이지 내의 배너에 대한 운영 툴이 자동화되어있지 않아도 기획자가 개발자에게 업무 요청을 통해 배너를 변경하는 것이 업무 생산성에 별 문제가 없겠지만 만일 이렇게 변경해야 하는 사이트가 50개라면?? 산술적으로 하나의 웹사이트 내의 배너를 변경하는 데 있어 10분이 걸린다고 가정하면 50개의 웹사이트의 배너를 변경해야 한다면 500분이 걸리게 될 것이다.

하지만 50여 개의 사이트에 배너를 동시에 등록할 수 있도록 운영 툴을 자동화한다면, 1개의 웹사이트에 배너를 교체하는 일이나 50여 개의 웹사이트에 배너를 교체하는 일이나 업무 시간의 측면에 있어 크게 차이가 없을 것이다.


사실 위와 같은 일들이 말도 안 될 것 같지만, 아직까지도 많은 회사에서 운영 툴을 자동화할만한 개발 리소스가 없다는 이유만으로 운영 툴 자동화를 해야 하는 업무들을 하지 못하고 있다. 필자의 회사에서는 초창기에 단순 배너 교체 이외에도 정말 많은 업무들이 자동화가 되어있지 않았고, 대부분 하드 코딩(수동 개발)이나 반복 수작업을 통해 운영 업무를 진행했던 것이 현실이었다.


업무 생산성을 높이기위해 야근을 할것이 아니라

본인이 하고 있는 모든 업무들이 자동화가 되어있고, 전산화가 되어있는지 다시 한번 잘 점검해주기를 바란다.


다시 말하면 규모가 작은 서비스를 운영할 때는 운영 툴 자동화가 되어있으나 자동화가 되어있지 않으나 업무 생산성에는 큰 차이가 없어 보이지만, 서비스의 규모가 커질수록 운영 툴 자동화가 업무 생산성과 비용에 미치는 영향은 매우 크다고 할 수 있다.


두 번째로 인사 관리 시스템을 예를 들어 보자

많은 회사들이 채용을 위해 지원자들에게 이력서를 받고 관리하게 될 것이다. 만일 자체 인사 관리 시스템이 없는 경우 이 모든 인사 자료를 종이로 출력하고 관리하고 운영해야 할 것이다. 임직원이 한두 명이라면 큰 문제가 되지 않겠지만 100명이 넘어간다면 어떻게 될까?

그래서 운영 툴에 대한 전산화와 채용 사이트와 같은 내부 운영관리 시스템의 전산화는 회사의 전반적인 업무 생산성을 끌어올리는 데 있어서 무엇보다도 중요하다.


세 번째 솔루션을 이용한 약속 잡기를 예를 들어보자!

필자가 있었던 회사는 보통 회의를 잡을 때 별도의 툴을 사용하지 않았다. 메신저로 회의 시간을 통보하고 해당 시간을 조율해서 회의를 진행했었다. 그런데 회의 인원이 서너 명이면 큰 문제없이 회의시간을 잡을 수 있으나 5명이 넘어가게 되거나 우리 팀이 아닌 타 본부와 회의시간을 잡으려면 "난 이 시간이 되고 이 시간이 안된다 등등" 적어도 네다섯 번 정도는 메시지가 왔다 갔다 해야 회의 일정을 잡을 수가 있었다.


하지만 지금은 과거에 30분정도 걸리던 회의시간 잡기를 Google G-suite 의 캘린더를 활용하게 되면 5분이면 회의일정을 잡을 수 있게 되었다.

회의시간을 잡기 위한 커뮤니케이션에 있어 한 사람 한 사람에게는 몇 분의 시간일지 모르겠지만 500여 명이 되는 회사에서 전사적으로 들어가는 커뮤니케이션 시간을 따지게 된다면, 상상하는 것 이상의 시간이 소요될 것이고, 이는 결국 업무 생산성과도 연관이 되게 되는 것이다.


즉, 회의시간을 잡기 위해 툴 하나만 제대로 바꿔도 업무 생산성이 올라가게 되는 것이다.


구글 G-Suite의 캘린더 화면



무엇부터 시작해야 하는가?

그럼 필자가 이 회사에 입사를 해서 앞서 이야기했던 업무 전산화에 대한 리스트를 어떻게 뽑아냈고, 어떻게 운영 툴을 자동화하고 고도화했는지에 대해 이야기해보도록 하겠습니다.


순서는 아래와 같은 4단계를 거쳐 진행을 하게 되었다.


Step 1. 인터뷰

Step2. 내부 컨설팅 보고서 작성

Step 3. 조직 개편 (인프라 개선 TF 팀) 

Step 4. Agile 그리고 운영 툴 자동화



Step 1. 인터뷰

인터뷰는 1차는 IT인력들인 기획자, 개발자, 퍼블리셔, 디자이너들을 1 on 1 로 인터뷰를 했으며 2차로는 고객센터, 마케팅본부 등 업무를 요청하는 부서에 팀장과 팀원을 동석하여 인터뷰를 행했다.


IT 담당자들에 대한 인터뷰 주제로는

기획자라면 디자인과 개발에 아쉬운 점, 개발자, 디자이너로써 아쉬운 점 등

본인의 현재 업무 프로세스에 대한 현황

본인이 생각하는 현재 업무의 문제점 및 개선방안

업무 생산성 개선을 위한 아이디어


업무 요청부서에 대한 인터뷰 주제로는

현재 업무에 있어서 가장 불편한 점

기획/디자인/개발에 있어서 가장 아쉬운 점

자동화를 했으면 하는 업무

본인이 생각하는 현재 업무의 문제점 및 개선방안

업무 생산성 개선을 위한 아이디어

등을 질문을 하였고 다양한 의견들을 들을 수가 있었다.


필자가 앞서 이야기했던 IT 담당자들과의 인터뷰를 통해 알아낸 것은 운영 시스템들의 노후화가 심각하다 것에 있어 다들 공감을 하고 있었고, 운영툴의 자동화가 매우미흡하다는 사실을 많은 사람들이 인지하고 있었다.

조금 생소했던것들중에 하나는 현업 담당자의 경우는 본인이 하고 있는 일들이 전산화나 자동화가 가능하다는 것 자체를 생각하지를 못하고 있다는 점들이다.


당시 개발팀장이었던 분은 이러한 현실을 알고 있으면서도 애써 외면하고 있는 상황이었다. 리소스가 부족하다는 이유로 할 일이 쌓여있다는 이유로 말이다.


사실 필자가 봤을 때 이러한 이야기는 비겁한 변명이다. 필자의 과거 경험에 비추어보면 서너 명의 개발자가 몇 개월 정도만 고생하면 어느 정도는 운영 툴이 자동화가 가능하고 이를 통해 확보한 개발 리소스를 또 다른 운영 툴 자동화와 자동화 시스템 구축에 투입된다면 충분히 개발 리소스에 대해 선순환의 구조로 들어갈 수 있는 상황이었으나 아무도 나서지 않았던 상황이라고 판단했다.


Step2. 내부 컨설팅 보고서 작성

내부/외부 고객에 대한 인터뷰(면담)를 진행하면서 아래와 같은 방향으로 문제점을 진단하고 개선 방안을 도출하였다.


개발팀에 대한 문제점 진단 및 개선방안 도출

업무 프로세스에 대한 진단 및 개선 방안

시스템에 대한 진단 및 개선 방안

커뮤니케이션에 대한 진단 및 개선 방안

리소스에 대한 진단 및 개선방안

역량에 대한 진단 및 개선 방안


위의 진단 컨설팅 보고서 안에는 다양한 문제점에 대해 진단을 하고 이 진단 내용을 바탕으로 하여 개발팀에 대한 조직 개편안, 운영 툴 자동화를 전담하게 될 인프라 개선 TF팀을 신설을 통한 상세 운영 툴 자동화 실행방안, 그리고 솔루션을 활용한 업무 생산성 개선방안에 대한 내용이 담겨 있다.


그 내용을 간단히 요약하면 아래와 같다.

개발팀에 대한 파트 단위의 조직개편

인프라 개선 TF팀 신설을 통한 운영 툴 자동화의 선도적 역할 수행

JIRA와 Confluence 도입 및 활용을 통한 IT 업무 프로세스 고도화 및 지식 기반 경영 환경 마련

G-Suite 도입을 통한 커뮤니케이션 효율 개선


Step 3. 조직개편과 인프라 개선 TF팀의 신설

결국 모든 일은 사람이 하게 되고 결국 모든 컨설팅의 끝은 조직개편이 되게 된다. 개발팀이 20명이라면 1개의 팀으로 유지를 하고 파트를 나눌 것인지, 팀을 2개로 나눌 것인지, 기존 팀장을 대신하여 새로운 리더십을 세울 것인지 등 조직개편의 방법에 대해서는 너무나 많은 방법이 있고, 어떠한 조직개편이 정답이다 라고 이야기는 어렵다. 


다만 현재의 상황에 따라 조직의 현황이나 해야 하는 일의 상황에 따라 조직개편을 달라질 것이다.


필자가 택한 방법은 기존의 개발팀을 파트장 단위로 작게 쪼개 파트장에게 책임과 권한을 부여했고, 본부장 직속 TF팀인 인프라 개선 TF팀을 신설하여 이를 통해 앞서 이야기했던 운영 툴을 자동화하고 시스템을 통합하여 개발의 전반적인 업무 생산성을 끌어올리자는 목표를 가지고 조직 개편을 실시하게 된다.


사실 인프라 개선 TF팀을 신설하면서 가장 많이 고민했던 부분이 팀원을 누구로 할 것인지였다.

필자가 정말 탄탄한 인맥을 지니고 있다면 적합한 인력을 데리고 오면 되지만, 그만한 인맥이 없던 필자는 현재 조직원들 중에 가장 열정이 넘치며 긍정적인 마인드를 가지고 있는 팀원을 선발하게 된다.


인프라 개선 TF팀이 만들어진지 벌써 2년이 넘었지만 이때의 인력들은 지금도 IT본부 내에서 핵심적인 역할을 하며 필자와 함께 많은 업무 성과를 만들어 내고 있다.


Step 4. Agile 그리고 운영 툴 자동화

 Agile 개발 방법론에 대해 이런저런 이야기들이 있지만, 필자가 생각하는 Agile의 핵심은 업무를 잘게 쪼개고 이를 짧은 시간 내에 성과로 만들어 내는 것이라고 생각을 한다. 


그래서 인프라 개선 TF팀으로 조직개편을 하고 나서 제일 먼저 한일이 

자동화가 필요한 모든 업무에 대해 정리와 함께 우선순위를 정하고 또한 2주단위로 성과를 낼수 있도록  업무 단위를 잘개 쪼개는 것이였다.

그래서 찾아낸 업무들은 아래와 같다.


배너 운영 툴 자동화, 프로모션 관리 페이지 자동화, 상품 리스트 자동화 등이었다. 이러한 자동화가 별것 아닌 자동화라고 생각할 수 있지만 우리 회사에는 약 50개의 아이템에 50여 개의 홈페이지가 있으며, 프로모션과 이벤트 그리고 상품들이 1년에 약 300여 개 이상 만들어지고 운영이 되게 된다. 따라서 마케팅과 프로모션을 위한 운영 툴의 자동화는 무엇보다는 개발 생산성 개선에 아주 큰 기여를 하게 된다.


업무 성과를 만들어내기 위해서는 가장 먼저 해야 하는 일이 무엇인지를 찾아내는 것이 무엇보다도 중요하다. 이렇게 업무 우선순위를 정하는 것은 직관이나 경험에 의지 할 수도 있지만 앞서 인터뷰했던 문제점들을 잘 파악한다면 King Pin 이 되는 업무 우선순위를 찾아낼 수 있을 것이다.


위와 같은 업무의 자동화 이후에는 별도의 인력충원 없이, 채용 사이트, 평가 사이트 구축 등 사내 핵심 업무 툴인 인사 관련 운영 툴 자동화 등을 통해 내부 업무 생산성을 다시한번 끌어올리게 된다.


위 업무 외에도 Google G-suite의 도입, JIRA와 컨플루언스 툴의 도입 및 활용, CRM 시스템 도입 등등 참 많은 프로젝트 등을 진행했었고 실질적으로 이렇게 진행된 프로젝트로 인해 전반적인 IT 생산성이 증대되어 유관 부서로부터 아주 좋은 평가를 듣게 되었다.




사실 위에서 필자가 언급한 일은 쉬워 보지만 이를 실제 업무 성과로 이끌어 내는 일은 정말 쉽지 않은 일이며, 필자 역시 쉽지 않았다.


첫 조직 개편 당시 인프라 개선 TF팀의 신설 시 기존 개발팀의 반발이 굉장히 심했다. 그 이유를 들자면 현재 리소스로는 운영하기에도 어려움이 있는데 3명이나 개발인력을 빼낸다면 결국 운영 업무에 공백이 발생하게 될 것이고 이는 결국 장애와 오류로 인해 고객 서비스에 문제가 생긴다는 반발이었다. 


사실 그 이유가 전혀 말도 안 되는 이야기는 아니었고, 필자 역시 조직개편 당시 많은 걱정을 하였지만

그냥 밀어 붙였다!


다행스러운 것은 두 달 남짓하는 기간 동안 인프라 개선 TF팀원들이 밤낮없이 운영 툴 자동화 업무를 해준 덕분에 운영 툴 자동화가 어느 정도 이루어지게 되었고, 이러한 작은 성과를 통해 좀 더 큰 규모의 운영 툴 자동화를 시도할 수 있게 되었다.


물론 이 시기에 기존 개발팀의 개발자들은 인프라 개선 TF팀으로 인해 부족한 개발팀의 리소스를 메우기 위해 야근도 마다하지 않았다. 


사실 필자가 앞서 이야기한 방법은 어찌 보면 IT 본부장이라면 다 아는 이야기 일수도 있다. 하지만 이를 실천하지 못하는 이유는 현실의 벽을 깨는 것이 쉽지 않고 현재를 유지하고자하는 조직의 타성을 이겨내기 위해서는 끊임없는 노력과 인내 그리고 설득이 필요하기 때문이 아닐까 한다.


이러한 운영 툴 자동화 이외에도

필자가 개발자들에게 제안한 일은 바로 코드 리뷰이다.

코드 리뷰는 개발자들의 코드를 보고 해당 코드에 대한 장점과 단점에 대해 토론하고 이야기를 하는 일이지만, 사실 많은 코드 리뷰들이 "나 같으면 저렇게 개발을 하지 않을 것이다"라는 비난이 난무하는 리뷰가 되기도 하는 것이 현실이다. 그래서 이러한 코드 리뷰는 개발자들에게는 자기의 속살을 보여주는 일이고 실력이 다소 부족한 개발자들에게는 무엇보다도 하기 싫은 일중에 하나일 것이다.


하지만 디자이너는 디자인된 산출물을 통해 평가를 받게 되고, 기획자는 기획한 서비스의 참여자 수 등으로 평가를 받지만 개발자들은 코드 리뷰가 아니면 본인이 만든 코드에 대해 누구에게도 평가를 받지 않게 된다.


평가라는 것이 너무나 부담스러운 일이기는 하지만, 평가를 통해 나의 단점과 장점을 알게 되고 단점은 극복하고 장점을 개발하여 좀 더 성장하는 개발자가 되기 위해서는 개발자의 평가 수단인 코드 리뷰가 반드시 필요하다는 생각은 지금도 변함이 없다.


평가가 쉬운 일은 아니다, 하지만 올바른 평가는 일을 잘하는 조직원과 일을 게을리하는 조직원들에 대한 보상을 나누는 기준이 되고, 얼마나 공정한 평가를 내리느냐가 조직을 올바르게 이끄는 데 있어 가장 중요한 점이 아닌가 하는 생각이 든다.

매거진의 이전글 본부장님 사케 한잔 사주세요!
작품 선택
키워드 선택 0 / 3 0
댓글여부
afliean
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari