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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

그럼 어떻게 해야 할까?

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

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

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

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

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

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

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

지금은 바빠서 못한다.

지금은 바빠서 못하고 나중에 여유가 생기면 할 것이다.

비단 소프트웨어 개발이 아니더라도 우리는 이런 말을 달고 사는 사람들을 자주 본다. 이런 사람들이 특징은 시간적인 여유가 생겨도 거의 대부분 안하기는 마찬가지라는 것이다.

운동, 공부, 다이어트, 취미생활 등 이런 핑계를 대는 대상은 다양하다.

영어 속담에 이런 말이 있다.

"A stitch in time saves nine"

직역하면 "필요할 때 한땀이 아홉을 구한다." 

소프트웨어 회사도 마찬가지이다. 한땀이 필요한 결정적인 시기들이 수없이 닥친다. 하지만 그 결정적인 시기를 놓치면 10배, 100배의 비용을 지불한다.

코딩만 보더라도 처음에 제대로 해놓지 않으면 나중에 고치기에는 훨씬 많은 노력이 드는 경우가 많다. 소스코드를 너저분하게 어질러 놓거나 여기 저기 마구 복사를 해넣고 암호 같은 코드를 써 놓으면 나중에 고생을 한다. 

여기까지는 나중에 문제가 되어도 그렇게 심각하지는 않지만 회사는 결정적인 시기를 놓치면 영원히 복구를 못할 수 있다.

어떤 시기에 무엇을 해야 하는지는 워낙 광범위한 이슈라서 한마디로 얘기할 수는 없다. 하지만 많은 회사들이 변화를 두려워하거나 귀찮아해서, 또는 변화에 지불해야 하는 비용이 아까워서 그냥 버텨나가곤 한다. 그리고는 더이상 버티기 힘들다고 판단될 때는 너무 늦은 경우가 많다.

회사의 프로세스, 조직, 시스템, 문화 등 적절한 시긴에 준비하고 변화해야 할 부분은 많다.

비경영자 출신의 경영자는 몰라서 실기를 하기도 하고 개발자 출신의 경영자들도 자신의 경험의 테두리에 갇혀서 사태의 심각성을 깨닫지 못하는 경우가 많다. 가장 좋은 방법은 상황이 좋을 때 변화하는 것이다. 상황이 점점 안좋아지면 변화는 엄두도 못낸다. 일단 상황에 밀리기 시작하면 끝까지 밀려서 꼼짝달싹 못하기 쉽상이다. 

좋은 경영자라면 좋은 세월에 뭘 해야 할지 알아야 한다.

내가 책임지고 해보겠습니다.

우리나라 경영자들은 "내가 책임지고 해보겠습니다."라는 말을 좋아한다. 물론 책임감을 가지고 일을 추진하는 것은 좋은 일이다. 하지만 많은 경우 엄밀히 말하면 제대로 책임을 지는 것이 아니다. 결과적으로 책임을 지겠다고 말만하는 꼴이 되는 경우가 많다. 그럼에도 무모하더라도 추진력있게 밀고 나갈 사람이 인기가 많다.

경영자들이 이런 돌격형 인재를 좋아하는 이유는 여러가지가 있다. 실제 좋은 성과를 내는 경우도 많지만 소프트웨어에서는 상황이 좀 다르다. 

경영자들이 소프트웨어 개발에 대해서 잘 모르기 때문에 그냥 알아서 개발을 해주기를 원하는 경우가 많다. 또한 이런 경우 무모한 시도가 되는 경우가 많다. 

열심히 하는 것은 좋지만 무모한 것과는 다르다. 대부분의 무모한 프로젝트는 일정이 제대로 예측이 안되는 상태로 밀어 붙인다. 일정이 촉박하다는 이유로 분석, 설계 생략하고 코딩부터 진행하고, 개발 막바지까지 현재 진행률을 파악하기가 어렵다.

비즈니스를 하기에는 이렇게 열심히 일하지만 예측 불가능한 프로젝트보다는 합리적인 일정제시와 제시된 일정에 결과가 제대로 나오는 프로젝트가 더 좋다. 그래야 비즈니스도 계획한 대로 움직일 수 있다.

이렇게 무모한 프로젝트를 진행하는 개발자들은 불투명한 프로젝트 진행을 선호한다. 투명하게 프로젝트를 진행하는 것이 더 효율적이라는 것을 몰라서 그렇게 하기도 하지만, 정보와 지식을 숨길 수록 자신들의 가치가 더 올라간다고 착각을 하기도 한다.

이런 환경에서는 경영자는 Detail은 잘 모르고 개발자들을 쪼기만(일정 압박) 하고, 개발자들은 매일 야근에 내몰리다가 프로젝트 막바지에는 이런 저런 핑계를 만들어 내기 급급해진다. 물론 가끔은 일정내에 프로젝트가 끝나기도 하지만 그 과정에서 마케팅, 영업, QA와 유기적으로 협력이 잘 안되고 혼자 달려가는 프로젝트가 되곤한다. 개발자가 개발을 끝내주면 그때부터 다른 부서는 일이 시작된다. 무엇을 개발하고 있는지 제대로 파악이 안되므로 미리미리 준비를 하기도 어렵다.

물론 개발자는 열싱히 일을 했다. 비난을 들으면 억울할만하다. 물론 나는 개발자를 비난하는 것은 아니다. 이런 일이 벌어지는 근본적인 이유는 경영자들의 무모한 개발자를 선호하고 너무 압박을 하기 때문이다. 이런 일이 반복되면 개발자는 지치고 프로젝트는 지연된다. 잘못된 방향으로 달려가던 프로젝트는 커다란 매몰비용(Sunken cost)를 치뤄야 하기도 한다. 이런 상황에서는 경영자도 개발자도 선택의 여지가 별로 없다. 아무리 손해를 보더라도 경영자는 이런 무모한 프로젝트에 계속 후원을 할 수 밖에 없다. 

이 모든 부작용은 개발 문화의 부재에서 오는 것이다. 제대로 된 스펙에 의해서 합리적인 일정을 제시하고 경영자는 이를 믿어줘야 한다. 처음에는 개발자들이 역량이 부족하여 나름대로 개발자들이 제시한 일정이 좀 틀릴 수도 있지만 개발자들은 최대한 합리적인 가능한 일정을 제시해야 한다. 그런 관계가 거듭되야 개발자도 역량이 향상되고 비즈니스 일정에 맞춰서 제품을 만들어 줄 수 있다.

혹자는 현실적으로 불가능한 일이라고 한다. 항상 일정이 너무 촉박하여 경영자는 절대로 개발자들이 제시한 일정을 따를 수 없다고 한다. 그래서 무모하게 짧은 일정을 제시한다고 한다. 경영자가 그렇게 하는 이유는 무지 때문이기도 하고 개발자들이 합리적으로 일정으 제시하지 못하기 때문이기도 하다. 가끔은 경영자와 개발자의 신뢰가 무너진 경우도 있다. 그렇게 해서는 평생을 가도 무모한 프로젝트만 진행하게 된다.

그 부작용은 개발자 사기저하, 비즈니스 일정이 꼬이고, 제품의 품질이 떨어진다.개발자들은 매일 야근에 고생을 하지만 일정 지연에 자주 내몰린다.

여기서 핵심은 경영자들의 이해이다. 그리고 개발자들도 제대로 된 분석, 설계 능력을 갖춰서 합리적인 개발 계획을 제시할 수 있어야 한다. 한번에 그렇게 될 수는 없지만, 경영자와의 신뢰 하에서 개발자에게 꾸준히 투자를 해줘야 개발자들도 그렇게 할 수 있는 역량이 올라가게 된다.