소프트웨어 회사에서 경영자가 하면 안되는 것들

필자는 23년 경력의 개발자이며 소프트웨어 회사의 CEO다. 과거 8년 동안 소프트웨어 공학 컨설턴트로서 소프트웨어 개발에 관한 글을 써왔다. 우리나라의 열악한 소프트웨어 개발 환경의 핵심이 개발문화 때문이라고 생각해서 글로벌 개발 문화를 소개해 왔고 이제는 실제 한국의 소프트웨어 회사에 적용된 사례 소개하고 있다.

오늘은 소프트웨어 회사에서 경영자가 하면 안 되는 것들을 소개하려고 한다. 물론, 회사마다 기업문화가 달라서 사람에 따라서는 괴리감을 있을 수 있다. 문화란 원래 경험하지 않은 사람은 괴상하다고 생각할 수도 있고 현실성이 없다고 느낄 수도 있다. 하지만 우리 회사에서는 당연하게 생각되는 것들이고 이런 문화가 글로벌 소프트웨어 기업들과 경쟁하기 위해서 필요하고 생각하기 때문에 소개를 한다.

첫째, 개발자들의 개발 기간 예측(Estimation)을 무시하기

많은 회사에서 벌어지고 있는 일이고 일방적으로 경영자의 잘못으로 치부하기도 힘들다.

사례는 워낙 많지만 개발자들이 1년 이하로는 도저히 개발할 수 없다고 주장하는 프로젝트를 경영자가 6개월안에 무조건 끝내라고 하는 경우는 매우 흔하다. 이유도 여러 가지다. 개발자의 주장을 믿지 않기도 하고, 프로젝트가 늦어질 것을 감안하여 필요 일정보다 무조건 당겨서 끝내라고 하기도 한다. 또한, 이렇게 개발자를 강하게 압박하지 않으면 개발자들이 야근도 안하고 열심히 일을 안 한다고 생각하는 경영자도 많다.

당장은 이렇게 해서 몇몇 프로젝트가 성공할 수도 있고 개발 일정도 당겨지고 이익을 보기한다. 하지만, 이런 행위가 관행처럼 굳어지면 결국에는 개발자, 경영자 모두가 손해를 본다. 또한 회사의 개발 문화도 한참 후퇴한다. 경영자가 일정을 무조건 줄이면 개발자는 다음부터 어쩔 수 없이 예상보다 조금씩 늘려서 얘기를 하곤 한다.

개발자도 경영자가 납득할만한 근거를 가지고 적절한 개발 기간을 제시하지 못하는 문제도 벌어진다. 그래서 경영자는 개발자가 제시한 일정을 납득하지 못하고 무조건 일정을 줄이고 본다. 이 싸움은 누구도 승자가 될 수 없는 싸움이다. 개발자는 아키텍처가 망가지는 고통 속에서 야근을 거듭하고 경영자는 프로젝트의 예측 가능성이 낮아져서 비즈니스를 수시로 그르치게 된다.

먼저, 개발자는 잘 분석된 스펙을 바탕으로 납득할 수 있는 일정을 제시해야 한다. 그리고 경영자는 개발자가 예측한 일정을 믿어주는 신뢰관계가 필요하다. 그래야 개발자는 항상 최선을 다해서 정확한 일정을 산정하려고 노력한다. 개발자가 제시한 일정을 단축해야 하는 경우에는 합리적인 수단을 사용해야 한다. 야근도 하나의 방법이기는 하지만 습관적인 야근은 이익보다 손실이 큰 방법이다. 합리적인 수단이란 기능 축소, 핵심 기능에 집중, 단계별 개발, 전문 컨설턴트 투입, 일부 상용 모듈 구매 등 여러 가지가 있다.

이런 개발자와 경영자 간의 신뢰 관계는 개발 방법론과 상관없이 필요하며 정착하는데 상당한 기간이 필요하다. 그리고 이렇게 개발하는 방법이 소프트웨어를 가장 빨리 개발하는 방법이라는 것을 깨달아야 한다.

둘째, 합의된 요구사항을 경영자의 취향대로 바꾸기

우리나라 회사들은 경영자가 무엇이든지 뒤집을 수 있는 막강한 권력을 가진 경우가 많다. 출시 임박한 제품의 모양을 경영자가 갑자기 바꾸거나, 취향대로 색깔을 바꾸기도 한다. 소프트웨어 분야에서도 흔히 벌어진다.

프로젝트에서 경영자의 역할은 프로젝트마다 다르다. 하지만 경영자가 프로젝트에서 절대 권력자는 아니다. 한 명의 Stakeholder일 뿐이다. 대부분의 프로젝트에서 경영자의 역할은 비전과 전략을 담당한다. 빌게이츠는 초창기 프로젝트의 기술적인 내용까지 깊숙이 간섭을 했는데 이는 경영자로서가 아니고 Chief Architect로서의 역할을 한 것이다.

프로젝트에서 경영자는 경영자 관점에서 비전과 전략 요구사항을 전달해야 한다. 그것도 초기에 제시해야 한다. 전략이 바뀌면 프로젝트는 엄청나게 바뀌는 것이므로 가능하면 초기의 전략이 유지되는 것이 좋다. 전략이 바뀌더라도 합리적인 변경을 해야 한다.

경영자가 프로젝트 막바지에 뒤늦게 관여를 해서 감 놔라 대추 놔라 하는 것은 금기사항이다. 이런 일이 벌어지면 아키텍처는 완전히 엉망이 되고 개발자들의 사기는 땅에 떨어지면 신뢰관계는 금이 간다. 우리 회사에서는 스펙이 Close 된 후에는 경영자가 요구사항을 바꾸려고 해도 Change Control Process를 통과해야 한다. Change Control Board에서 변경이 거부되면 아무리 경영자가 요구한 내용이라고 변경이 불가능하다.

이래야 경영자도 프로젝트에서 자신의 역할을 제대로 수행하기 위해서 최선을 다한다. 뒤늦게 아무 때나 간섭할 수 있다는 생각은 하지 않게 된다.

셋째, 개발자에게 아무 때나 가서 말을 시키거나 지시하기

우리 회사에서는 경영자뿐만 아니라 누구도 개발자에게 아무 때나 말을 걸고 개발을 방해하지 않는다. 개발자가 개발에 집중을 하고 있는 경우에 중간에 방해를 하면 엄청난 손해가 발생한다. 피플웨어에서는 30분 정도의 손실이 발생한다고 한다. 이런 방해가 하루에 3,4번 벌어지면 하루를 망친다.

개발자와 면담을 할 것이 있으면 몇 시간 전이나 하루 전에 미리 시간을 Arrange해야 한다. 급하게 할 얘기가 있으면 개발자가 집중을 하고 있는지 조심스럽게 살핀다.

그래서 우리 회사에는 메신저도 금지되어 있고 근무 중에는 카카오톡도 무음 설정을 해야 한다. 개발자가 집중해서 일을 하고 있는데 메신저가 부르거나 “까똑” 거리면 집중해서 일할 수가 없다. 개발자에게 전화를 거는 일도 거의 없다. 대신에 근무 시간에 최대한 집중을 하고 야근은 되도록 하지 않는다.

넷째, 수시로 보고서를 요구하기

공유 문화가 잘 정착되어 있는 회사에서는 진행되는 거의 모든 일이 온라인 시스템에 잘 기록되어 있다. 그래서 별도의 보고서가 없어도 경영자는 거의 모든 내용을 실시간으로 모니터링이 가능하다. 그래서 특수한 경우가 아니면 시스템에 있는 정보를 다시 정리해서 보고하라고 하지 않아야 한다. 보고서는 경영자의 시간을 약간 절약해 주지만 직원들은 수십, 수백 배의 시간을 소모해야 한다. 일보다 보고서 작성에 더 많은 시간을 쏟기도 한다. 또한 보고서만으로 업무를 파악하면 가공과정을 거치면서 내용이 왜곡되곤 한다. 시간이 허용하는 한 최대한 많은 정보를 직접 보는 것이 좋다. 보고서는 꼭 필요한 경우에만 작성해야 한다. 이것이 가능 하려면 공유 문화가 완전히 정착되어 있어야 한다.

지금까지 네 가지 경영자가 하면 안 되는 일을 소개했다. 그럼 경영자는 별로 할 일이 없는가? 경영자는 회사의 비전, 전략을 정하고 목표를 설정해야 한다. 인재를 채용하고 직원을 코칭, 육성해야 하며 회사의 규칙을 만들고 문화를 만들어가야 한다. 이외에도 경영자가 해야 할 일은 수없이 많다.

필자는 CEO일 뿐만 아니라 아키텍트의 역할도 일부 수행하며 또한 소프트웨어 국제화 전문가이다. 그래서 소프트웨어 공학, 아키텍처, 국제화 관련 이슈에도 전문가로서 직접 관여를 한다. 하지만 그 외의 것은 위에서 얘기한 것처럼 Stakeholder로서 의논에 참여를 하고 의견을 제시하지만 결정에 과도한 압력을 가하거나 합의된 결정을 뒤집지는 않는다. 합의를 바꾸려면 정해진 절차를 따른다.

글로벌 수준의 개발 문화 속에서 경영자와 개발자가 각자의 전문 역할을 충실히 수행할 때 글로벌 소프트웨어 회사들과 비로소 경쟁을 시작할 수 있을 것이다.