전지전능한 슈퍼 개발자의 역설

필자는 여러 소프트웨어 회사에서 많은 개발자를 만난다. 그러면 보통 회사에 한두명씩 전지전능한 슈퍼 개발자가 있는 것을 보게 된다.

이들은 코딩, 설계, 분석, 테스트, 기획, 고객 전화응대, 고객 지원, 프로젝트 관리, 일반관리, 전략 수립 등 엄청나게 많은 일을 한다. 직책은 대부분 팀장이다.

여러분의 회사에도 이런 개발자가 한두명씩은 있을 것이다. 이들이 여러분의 롤모델인가? “나도 그런 전지전능한 개발자가 되어야지”라는 다짐을 하는가? 아니면 혹시 여러분이 이런 전지전능한 개발자인가?

이렇게 많은 일을 하는 개발자가 One man company에만 있는 것이 아니다. 개발자가 수백명이 넘는 회사에서도 드물지 않게 만날 수 있다.

이런 회사에서는 모든 길이 로마로 통하듯이 모든 기술적인 이슈도 이 전지전능한 개발자를 통해야 해결이 된다. 이 전지전능한 개발자가 모든 기술과 정보를 꽤 뚫고 있어서 문제가 발생하면 즉시 해결해주고 회사는 그럭저럭 굴러간다. 이 개발자가 나가면 회사는 망할 것만 같다.

이런 현상이 좋아보이는 사람도 있을지 몰라도 회사는 인력적으로 큰 리스크를 안고 있는 것이고 뛰어난 개발자를 가장 가치 있는 일에 제대로 사용하지 못하는 손해를 입고 있는 것이다. 전지전능한 개발자는 본인이 선택을 해서 그런 위치가 된 것은 아니다.

회사가 성장과정에서 적당한 때 조직을 전문화하고 변화를 꾀했어야 하는데 그냥 달려만 오다보니 능력이 좋은 개발자가 이거 저거 다 떠 안게 되면서 이런 현상이 벌어지게 되었다. 좀더 잘할 수 있는 분야에 집중했다면 본인 역량 면으로도, 미래 가치면으로도 훨씬 좋은 결과를 가져왔겠지만, 지금은 회사의 맥가이버가 된 상황에 만족할 수 밖에 없다.

다른 회사로 가면 지금의 가치는 대부분 사라지고 만다. 개발자 본인에게도 안타까운 상황이다.

어떤 사람도 서로 완전히 다른 Skill set들을 필요로 하는 일들을 동시에 다 잘 수행해 낸다는 것은 불가능하다. 아주 작은 회사에서나 그렇게 하는 것이다. 이렇게 모든 일을 다하는 전지전능한 개발자는 그 모든 업무를 다 잘 못하고 있다고 봐야 한다. 모든 일을 잘한다는 것은 애초에 불가능하다. 특히 중요한 일은 주 업무인 개발을 할 시간이 확 줄어 든다는 것이다.

대부분의 이들은 예전에는 뛰어난 개발자였다. 하지만, 개발 이외 일들을 하나씩 떠 맡으면서 각 분야의 일들의 전문성이 점점 떨어지게 됐다. 그리고 각 일의 Switching cost가 만만치가 않다. 톰 디마르코는 몰입에는 15분의 시간이 필요하다고 했다. 전화한번만 받아도 15분은 그냥 추가로 까먹는거다.

심지어는 그런 개발자에게 테스트, 고객 응대, 기술 지원까지 하라는 것은 100원주고 20원짜리 일을 시키는 것과 같다. 비효율적일 뿐만 아니라 기획 같은 일은 전문성이 부족하여 제대로 수행하지도 못한다.

이런 슈퍼 개발자는 다른 소프트웨어 회사에 가면 가치가 확 떨어진다. 분야가 달라지면 Domain Knowledge 관련 경쟁력을 잃고, 개발 실력도 경력에 걸맞지 않게 떨어지고 어느 것 하나 특출난게 없게 된다. 관리자가 되어야 하나 고민이 많다. 그래서 회사에 꼭 붙어 있으려고 하고, 정치를 하면서 세력을 키우고, 회사의 개혁이나 변화를 반대하고, 골치덩어리 영웅이 되는 경우도 있다.

회사는 이들에 대한 의존도가 커져서 리스크를 감당할 수 없는 수준에 이르게 된다. 이들이 등돌리면 회사는 휘청거린다.

이것이 개발자 탓일까? 아니면 회사 탓일까? 회사 탓이다. 회사는 개발자가 실력을 발휘할 수 있도록 여건을 조성해주고 훈련도 시켜줘야한다. 그런데 개발자가 맨땅에서 북치고 장구치고 다 하고, 회사에서는 이를 방치하다보니 이렇게 되는 것이다. 하지만 많은 경영자들은 개발자가 잘 하니 그냥 그렇게 개발자가 다 해야 하는 것으로 아는 경우가 매우 많다.

그럼 어떻게 해야 할까?

개발자가 개발에 전념할 수 있도록 항상 여건을 조성해줘야 한다. 회사가 아주 작아서 어쩔 수 없이 개발자가 여러가지 일을 겸해서 하고 있다고 하더라도 회사가 조금만 커져도 개발자의 일에서 개발업무가 아닌 일을 떼어낼 수 있도록 준비를 해야 한다.

조직이 조금 커지면 테스터를 뽑고, 기술지원인력을 보강하는 것이 좋다.

개발자 10명이 이거 저거 모든 일을 다하는 것보다. 개발자 7명에 테스터2명, 기술지원 인력 1명인 조직이 더 낫다. 개발자가 개발에 더 집중할 수 있고 개발자 10명이서 하는 일보다 더 많은 일을 할 수 있다. 물론 조직과 더불어 프로세스, 기반시스템, 개발문화도 뒷받침이 되어야 하지만 이는 기본으로 생각하자.

이렇게 조직이 분리되고 개발자가 개발에 전념을 할 수 있어야 개발이 좀더 체계적으로 진행된다. 다른 조직의 인력과 협업을 하기 위해 필요한 최소한의 문서도 만들어야 하고 프로세스도 자연스럽게 필요하게 된다. 커뮤니케이션을 위한 기반시스템도 잘 활용하게 된다.

조직이 더 커지면 분리해야 하는 역할이 점점 많아진다. 즉 조직이 세분화 된다. 이는 회사 규모에 따라서 다르니 이 일이 개발자가 해야 하는 일인지 잘 생각해보고 결정하면 된다.

여기서 개발자의 업무를 모두 나열할 수는 없지만 회사에서 개발자가 개발에 집중할 수 있도록 노력하는 일은 대단히 중요하다. 개발자가 잘 해낸다고 그냥 방치하면 안된다. 개발자는 개발을 잘할 때 회사의 보물이 되는 것이다. 다른 일들은 여건이 되는 대로 다른 전문가에게 맡기도록 하자.

이 글은 Tech it에 기고한 글입니다.