SW개발, 착한 리더보다 독한 리더가 낫다

몇년전 A사에서 이슈관리 시스템 도입에 대해서 경영자와 의논한 적이 있다. A사는 이슈관리시스템을 사용하고 있지 않았고 버그만 엑셀 파일로 관리하고 있었다. 

이슈관리시스템이 꼭 필요한 상황이었고 당장이라도 도입해야 했었다. 하지만 경영자는 결단력있게 결정을하지 못하고 일단 모든 직원들이 공감을 할 수 있도록 설득을 해야한다는 것이었다. 그렇게 직원들을 설득하는데 시간이 소요되고 결정을 해야할 시점에는 다수결로 결정해야한다고 했다.

얼핏들으면 경영자가 독선적이지 않고 직원들의 마음을 헤아린다고 생각할 수 있다. 이런 경영자는 직원들이 싫어하는 일은 안하려고 한다. 직원들이 싫어하는 것을 하게될 경우 직원들의 호응도 떨어질 것이고 결국 실패할것이라는 것이다. 그렇게 다수결에 의한 결정으로 이슈관리시스템 도입에 실패한다면 과연 회사에 잘된 결정일까? 잘못된 결정일까? 

사회가 민주화 되다 보니 민주화를 해야할 것과 그렇지 않은 것이 헷갈리는 경우가 발생한다. 개혁에 대한 중요한 결정을 다수결로 결정하는것은 어리석은 짓이다. 그 이유는 대부분의 직원은 변화를 싫어하기 때문에 회사에 필요한 결정이 다수결로 통과되기는 어렵다. 통찰력을 가지고 있는 경험이 많은 리더가 과감하게결정해야 한다. 직원들 90%가 반대한다고 해도 회사에 꼭 필요하다고 생각하면 결단을해야 한다. 

소프트웨어 회사에서 민주적인 경영자는 두 부류가 있을 수 있다. 

첫째, 소프트웨어 개발에 대해서 잘모르는 경영자다. 

소프트웨어 개발에 대해서 잘 모르기 때문에 팀장들이 하는 얘기를 그대로 들어줄 수 밖에 없는 경우가 많다. 결국 개발자들이 편한대로 회사를 이끌다가 주먹구구식 개발에서 못벗어나게 된다. 변화는 꼭 필요하나적응하기 전까지는 불편하고 거북한 것이기 때문에 누가 강요를 하지 않으면 변화하기 어렵다. 

반대로 개발도 잘 모르면서 독재적인 경영자도 있다. 이런 경영자는 개발팀에 대한 신뢰도 부족하고 본인이개발팀을 뜯어고쳐보려고 다양한 시도를 한다. 

그러면서 개발팀에 진짜로 필요한 변화가 무엇인지 잘모르고 엉뚱한것을 강요하기 시작한다. 엉뚱한 기법을 도입하기도 하고 황당하게도 비싼시스템을 구축하기도 한다. 회사역량으로는도저히 쫓아가기 어려운 복잡하고 무거운 프로세스를 도입하기도 한다. 대기업에서 흔히 이런 일들이 벌어진다. 알지도 못하면서 독선적인 개발자는 모르면서 민주적인 경영자와 똑같이나쁘다. 

둘째, 과거에 주먹구구식으로 개발 꽤나 해본 경영자다. 

이 경영자는 코딩은 좀 해봐서 개발에 관련된 얘기를 하면 대충 알아 듣기는 하나 정작 회사의 미래를 위해서 무엇이 필요한지는 잘모른다. 과거 독재형 경영자에 대한 나쁜 기억도 있고 개발자들의 얘기를 잘 들어주는 마음씨 좋은형과 같은 경영자가 된 경우다. 

개발자들이 이런저런 고충이 있다고할 때 내용을 꽤나 잘 이해한다. 그래서 개발자들의 불만은 무시하지 않고 들어주려고 한다. 그러다보니 정작 필요한 개혁은 못하고 사사건건 개발자들을 설득하려고하고 다수결로 결정을 하려고 한다. 개혁을 통해서 앞으로 나아가지 못하고 주먹구구식 개발에 머물러 있거나 기형적인개발 형태로 발전하기 쉽다. 

경영자는 독해야 한다. 독재를 말하는것은 아니고 통찰력이 있어야 하고 과감히 추진을 해야 한다. 마음씨좋은 동네형 같은 경영자가 되어서는 안 된다. 보통의 경영자는소프트웨어 개발을 잘 알기 어렵다. 그래서 CTO가 필요한 것이다. 소프트웨어 개발과 기술에 관련된 결정은 CTO가 하는 것이다. 

필자가 만나본 소프트웨어 회사는100여개가 넘는데 그중에서 진짜 CTO가 있었던 소프트웨어 회사는 한손가락을 꼽고도 손가락 몇개가 남는 정도였다. 그만큼 CTO에 대한 인식도 부족하고 CTO급 역량을 가진 개발자가 부족한 것이 우리나라의 현실이다. 

이슈관리시스템 도입에 주저하고 다수결 결정을 시도했던 A사는 수년이 지났지만 여전히 과거의 개발방식에 머물러 있고 어려움을 겪고 있다. 이제는 회사 내부구조가 과거보다 몇 배 복잡해져서 변화를 하기는 점점더 어려워지고 있다. 

회사는 성장하는 과정에서 변화를 해야하는 결정적인 순간이 온다. 그 시기를 놓치면 기회는 또 다시 오지않는다. 개발자가 30명일때 개발 방식과 프로세스를 바꾸지 못하면 개발자가 100명이 되고 고객이 몇배로많아진 시점에서는 바꾸기 더 어렵다. 

결정적인 시기를 놓치면 영원히 좋은 시기는 오지 않거나 몇배의 고통을 감내해야 한다. 

이런 다수결 결정은 개발할 때도 종종 벌어진다. 소프트웨어 개발은 수많은 결정의연속이다. 아키텍처를 결정할때도 많은 결정을 해야 한다. 예를들어서 자바로개발할까 C++로 개발을 할까 팽팽히 맞서있는 경우 개발자들이 자신들이 좋아하는 개발언어를 주장하면서 한치도 물러서지 않는다고 하자. 이때 다수결로 결정하는 경우가 있다. 

다수결은 점심메뉴 결정할 때나 쓰면 된다. ,자바로 개발해야 하는 이유와 C++로 개발해야 하는이유를 제대로 설명하고 끝장을 보더라도 토론을 해서 결정해야 한다. 이때 회사의 경영전략과 비전 등을 모두 고려해야한다. 끝까지 결론이 안나면 CTO가 결정하면 된다. 

경영자에게 민주적 행동을 기대해서는 안 된다. 그만큼 경영자는 자신의 결정에 책임이 따른다. 이런 책임을 피하려고 민주적으로 행동한다면 죽도 밥도 안 된다. 자신의 결정을 책임지지 못하고 직원들의 결정을 따라야할 만큼 무능하다면 경영자 자리에서 물러나는게 낫다. 

이글은 ZDNet Korea에 기고한 칼럼입니다.