개발팀장의 퇴사 그리고 TF팀

IT본부장으로 살아남기 4번째 이야기

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

개발팀장의 퇴사

입사 당시 필자는 개발팀과 시스템팀인 두개의 팀을 맡는 CTO 라는 직책명과 함께 IT본부장으로 입사를 하게되었다. 안타깝게도 필자가  IT본부장으로 입사하고 4개월만에 개발팀장이 퇴사를 하게 된다.

표면상의 이유는 이직으로 인한 퇴사이지만, 팀장보다 나이 어린 본부장과의 커뮤니케이션의 껄끄러움 그리고 웹기획과 PM 경력 기반의 IT 본부장과의 커뮤니케이션이 어려웠기 때문이 이기도 하겠지만, 가장 큰 이유중의 하나는 번아웃으로 인한 점이 아닐까 한다.

필자가 평가하는 당시의 개발팀장은 개발팀장의 역량에 문제가 있기 보다는 많이 지쳐보였다. 그 이유는 전반적인 회사의 IT 프로세스와 현황에 대해 검토를 하면서 알게 된 일이지만, 모든 문제의 최종 종착지가 개발팀인것으로 분위기가 휩쓸려가고 있었다. 

일정이 지연되도 개발팀 탓, 오류가 생겨도 개발팀 탓 모든 유관부서들은 IT 관련 문제의 원흉을 개발팀으로 몰아가고 있었고 이러한 이유로 인해 개발팀장은 어쩔수 없이 방어적으로 커뮤니케이션을 할수 밖에는 없는 상황이였다.

이러한 방어적인 커뮤니케이션이 또다시 개발팀은 업무를 수동적으로, 방어적으로 수행한다는 화살이 되어 돌아오고 이로 인해 잦은 퇴사자가 발생하여 조직이 안정화 되지 못하고, 이로 인해 업무 생산성은 떨어지는 악순환이 계속 반복되고 있는 상황이였다.

당시 개발팀의 분위기만 놓고 보면, "내가 이직할 회사만 정해지만 바로 이직한다" 라는 분위기가 팽배해져 있었다.

이러한 문제점을 어떻게 해결해야할지에 대해 많은 고민을 하게 되었고 본부원들과의 술자리, 식사자리를 통해 많은 이야기를 듣게 된다.

인프라 개선 TF팀

이렇게 어수선한 분위기의 개발팀으로는 새로운 무언가에 대한 도전은 어렵다고 느꼈고, 무언가 반전이 필요하다고 생각했다. 그때 새롭게 만들어진 팀이 바로 개발팀의 인력 중 차출되어 만들어진 인프라 개선 TF 팀이다.

당시에는 IT본부에 대한 신뢰도도 좋지 않았고, 팀의 생산성 역시 좋지 않으니 당연히 사람을 추가로 뽑을 수도없었다. 그러니까 새로운 인력을 1도 뽑지 않고 기존 인력으로 이 난국을 타개 해야 했다.

인프라 개선 TF 팀원을 뽑을때, 한가지 원칙을 세웠다. 

"긍정적인 마인드가 온몸을 휘감고 있을 것, 새로운 것에 대해 거부감이 없을 것"

이렇게 선발된 인원이 총 5명, 기획자 1명, 개발자 3명, 그리고 TF팀장 겸 본부장인 필자였다.

이렇게 조직이 구성된것이 벌써 3년전 이고, 이팀은 현재 인프라 개발팀이라는 명칭으로 약 15명의 조직으로 조직이 커지게 되었다. 현재까지도 조직 구성 당시의 긍정적인 마인드로 무엇이든지 할 수 있다 라는 열정은 식지 않았고 우리 회사의 새롭고 핵심적인 다양한 업무를 수행하고 있다. 

인프라 개선 TF팀이 한일

이렇게 조직된 인프라 개선TF팀으로 한일은 바로 가장 기본적인 운영툴에 대한 자동화였다.

매일 아침 모여서 스크럼을 통해 우리의 운영툴 중에 자동화 해야할것들에 대한 리스트를 정리했고, 이에 대한 우선 순위를 정하고, 2주단위로 나눠서 할수 있도록 업무들을 새롭게 나눴다.

바로 Agile 한 개발 방식을 도입하여 개발을 진행하게 되었고, 첫번째 목표는 무조건 2주안에 하나씩은 자동화를 하자였다.

제일 먼저 한 일은 바로 "메인 페이지 배너 운영툴 자동화" 였다.

잉?? 이것도 운영툴 자동화가 안되어있었어?? 라고 할지 모르겠지만, 필자의 회사는 안타깝게도 CMS(Contents Managerment System) 등이 구축되어있지 않았고, 대부분을 그때 그때 필요할때 하드코딩으로 만들어 운영을 하고 있었다.

예를 들어 메인 페이지내 배너를 하나 바꾸기 위해서는 기획 > 디자인 > 퍼블 > 개발 > 운영의 순서로 업무가 이관되어 처리가 되다보니 배너 하나를 교체하는데 심하면 반나절이나 걸리게 된다.

이를 기획 > 디자인 > 운영 으로 프로세스로 단순화를 할수 있게 한것이 바로 배너 운영툴 자동화였다.

말이 쉬워 2주에 하나씩 자동화를 개발하자였지만, 그때의 인력 마인드와 실력이 아니였으면 불가능했을것이라고 확신한다.

화이트 보드에 찍찍 그려져서 만들게된 메인 배너 자동화, 개발자가 스스로 기획하고 개발도한 히트맵 등등 엄청나게 많은 운영툴들이 자동화 되었고 이는 결코 기존의 업무 방식 "기획>디자인>퍼블>개발> QA" 의 프로세스를 거쳐서는 나올수 없는 퍼포먼스였다.

결과물만 만들면 된다. 기획/개발 방식은 아무런 상관이 없다는 Agile 개발 방법론의 적극적인 활용이 이러한 결과를 만들어 낼수 있지 않았나 하는 생각이든다.

이를 시작으로 프로모션 페이지 자동화, 교수소개 자동화 등 회사의 전반적으로 "기획>디자인 > 퍼블 > 개발 > 운영"의 프로세스로 운영되던 업무툴을 "기획 > 디자인 > 운영"으로 단순화해 IT 업무 생산성을 매우 향상시켰다.

약 4개월간 20여개 이상의 기능에 대한 운영툴 고도화 및 자동화를 진행했고, 이는 결국 개발팀에 대한 업무 생산성으로 이어져, 새로운 업무를 시도할 만한 여유를 만들게 된 중요한 계기가 되게 된다.

누구를? 팀장으로

다시 개발팀으로 돌아와 개발팀장의 퇴사시 가장 많이 고민한 점이 이후를 어떻게 조치를 취할 것인가였다.

외부에서 개발팀장을 새롭게 수혈할 것인지? 내부의 선임중에 팀장의 역량이 되는 이를 팀장으로 올릴것인지에 대해 많은 고민이 있었지만 결국은 외부 수혈보다는 내부 선임 인력 중 우수한 인력을 팀장으로 세우기로 결정하게 된다.

안타깝게도 현 개발팀은 앞서 이야기한것 처럼 조직원들에게 긍정의 에너지 보다는 부정의 아우라가 많이 펼쳐져 있는 상태였다. 이를 당장 해결할 방법은 없었지만, 외부 인력을 수혈할 경우, 기존 인력과의 콜라보, 협업을 위한 부분들을 고려할때는 조직의 안정성을 위해서라도 기존 선임 중 역량있는 선임을 고르는게 낫다고 판단하게 되고, 이러한 선택은 당시에는 잘한 선택이라고 생각한다.

선임으로써 대상자가 되는 몇몇에 대해 인터뷰를 했고, 다행히 적임자를 찾아 팀장으로 세우게 되고 이후 조직은 빠르게 안정을 찾기 시작한다.

운영툴 자동화 이후

인프라 개선 TF 팀이 운영툴을 자동화 하는 4개월여 동안 4명이 리소스가 온전히 부족했을텐데도 불구하고 야근을 불사하며, 리소스의 공백을 메꿔준 개발팀장과 팀원들에게 다시한번 감사의 말씀을 드린다.

개발팀의 안정화, 그리고 인프라개선 TF 팀을 통한 운영툴 자동화를 통한 개발 리소스 확보, 이제 부터는 유관부서 업무요청은 100%를 소화하게 되고, 이후에는 요청이 오지 않아도 스스로 알아서 새로운것들을 준비하기 위한 기반이 마련되게 된다.