큰 규모의 IT 회사에서 다른 개발팀 인력을 한시적으로 동원하는 것은 어떤 결과를 초래하는가?
오늘은 한 가지 개인적인 경험에 기반한 모의 상황을 가정해보고 결과와 문제점, 그리고 해결책에 대해 사유해보도록 하자.
Simulation
어떤 대규모 IT회사에, 비교적 새롭게 만들어진 A 팀이 있고 오래된 B 팀이 있다. 어느 날 회사에서 중대한 의사결정으로 A팀의 서비스가 현재 시장에서 빠르게 자리를 차지하는게 굉장히 중요하므로, B팀에게 진행중인 프로젝트를 일부 홀딩하고 A팀을 지원하라고 한다. 당연히 B팀의 리더는 반발하지만, 기나긴 설득과 회유와 협박의 과정 후에 결국 A팀에 B팀의 인력을 한시적으로 3개월정도 파견하기로 한다. A팀도 역시 난감하고 바라던 상황은 아니지만, 일단 주어진 일정이 현실적으로 불가능하기에 파견을 받아들인다.
A팀 리더는 B팀 파견 인력들 대다수를 차지하는 서버 개발자들에게 기획자가 필요한 서비스의 전면 기능들을 따로 맡기거나 그렇다고 아예 흡수해서 같은 팀원처럼 부려먹을 순 없다고 판단해, 외부에서는 보이지 않지만 내부적으로 많이 쓰게될 유틸성 서버들의 개발을 맡긴다. 파견 인력들이 A팀 리더의 지시를 받는건 불편한 상황이 될 수 있으므로 파견 인력들의 리더가 A팀 리더의 대략적인 요구사항만 받아들고, 아키텍처 등의 기술적인 세부사항은 모두 본인들의 해석에 따라 해당 시스템을 구현하게 된다.
B팀의 기술적인 의사결정은 완전히 별개로 이루어졌기 때문에, 그 결과 B팀에서 시스템 구현시 사용한 기술 스택은 프로그래밍 언어부터 시작해서 A팀의 기술적 기반과 완전히 다르게 가게되었다. 결국 A팀의 인력들은 B팀의 시스템을 전혀 내부적으로 이해하지 못한 채 그저 주어진 사용법대로만 호출해서 사용하게 되었다.
파견 기간은 어느새 끝나버렸고, 인수인계를 해야할 시기가 다가왔다. 그런데 여기서 문제가 발생한다. 파견을 받긴 했지만 그 인력들이 온전히 같은 팀원처럼 일한것도 아니고, 당연히 리소스는 여전히 부족한데, 엎친데 덮친 격으로 회사에서는 급변하는 시장 상황에 대응하기 위해, 그리고 경영진의 큰 그림과 조바심의 작품으로 A팀에게 혁신적이면서도 충격적인 기능들을 요구한다. A팀 리더들은 3개월 전까지만 해도 상상도 못했던 요구사항들에 직면하게 되었고, 이젠 더이상 인수인계가 문제가 아니게 되었다.
새로운 요구사항에 허둥지둥 대처하는사이 파견은 끝났고 B팀의 인력들은 자기팀으로 돌아가버렸다. 인수인계가 적절히 이뤄지기 못했기 때문에 B팀의 일부는 본인들이 만든 서비스 일부를 한동안 계속 유지보수 해야하는 상황이 되었다. 상황이 이렇게 되자 파견되었던 B팀 인력들은 무언가 잘못됨을 느끼고 회사를 하나둘 떠나기 시작한다. 결국 그렇게 담당자가 떠나버린 서비스들은 전혀 유지보수가 이뤄지지 못한 채 A팀에서 계속 쓰이게 되었다.
심지어 A팀의 리더들도 대부분 앞에서의 경영진의 의사결정에 반발해 퇴사하고 리더진이 교체된 상황이다. A팀의 실무자들은 더이상 막아주는 사람 없이 물밀듯이 밀려들어오는 요구사항을 처리하기 위해 파견 인력들이 만든 내부서비스들을 의존하며 개발을 한다. 파견인력들이 만들어놓은 서비스는 더이상 유지보수 할 수는 없지만, 어떤 문제가 생기면 전체 서비스에 커다란 악영향을 끼치는 매우 두렵고 알 수 없는 무언가가 되어버렸다.
What if it’s me?
큰 규모의 IT 회사에서, 회사의 현재 중요하게 여겨지는 서비스를 위해 다른팀에서 한시적인 파견 인력을 보냈을 경우 벌어질 수 있는 최악의 상황을 한 번 적어보았다. 물론 여기서 문제는 단지 파견만이 아니지만, 파견에 대해 한정해서 생각해보자. 만약 이런 상황에서 파견을 유의미하게 하기 위해선 어떤 일을 했어야 할까?
내가 파견이 결정된 후 상황에서 A팀의 리더나 혹은 회사의 기술 책임자라면, 파견 인력들이 만드는 서비스가 A팀의 현재 기술 스택과 크게 차이나지 않도록 하는것을 첫번째로 우선시 했을 것이다. 또한 파견인력들이 처음부터 인수인계를 위한 준비과정을 서비스를 만드는 것과 동등하게 중요한 과제로 생각하도록 하고, A팀의 인력들은 B팀과 주기적인 커뮤니케이션 시간을 갖고 서로간에 이해도를 높이는 시간을 강제로라도 갖도록 했을 것이다.
내가 만약 파견에 대해 처음부터 의사결정을 내릴 수 있는 위치였다면, 우선 대규모 파견은 고려 대상이 아니었을 것이다. 소프트웨어 프로젝트 개발에서 의외의 사실은, 때로는 다수의 개발자보다 소수의 개발자가 생산성이 훨씬 높아질 수 있다는 사실이다. 특히 이건 장기적으로 봤을 때 그렇다. 단순히 리소스를 맨먼스(man-month)로 계산해서 단기간에 다수 인력을 투입하는것보다, 장기적으로 해당 팀에 헌신할 수 있는 소수의 인력을 설득해서 팀 이동을 시켰을 것이다.
이것은 맨먼스 미신(The Mythical Man-Month)에서도 나오는 대목이다. 일부 인용을 해보자면, 다음과 같은 흥미로운 대목들이 있다.
…(중략) 색먼, 에릭슨, 그랜트는 어떤 연구에서 경력직 프로그래머들을 대상으로 생산성을 측정했는데, 이 그룹 안에서만도 가장 뛰어난 사람과 가장 못한 사람의 생산성 비율이 평균 10:1인데다, 실행 속도와 사용 공간 면에서는 무려 다섯 배의 차이가 난 것이다. 간단히 말하면 연봉 2만 달러 받는 프로그래머가 1만 달러 받는 이에 비해 열 배의 생산성을 발휘할 수도 있다는 얘기다.. (후략)
…(중략) 아키텍처 관리자에게는 열 명의 뛰어난 사람들이 있었다. 그는 그 사람들이 제대로 된 명세를 만들어 낼 수 있다고 단언했다. 추정 기간은 허용된 일정보다 세 달이 더 필요한 열 달이었다.
제어 프로그램 관리자에게는 150명이 있었다. 그는 그 사람들이 아키텍처 팀과 협조해서 명세를 훌륭하고 실용적으로 작성할 수 있으며, 일정도 지킬수 있다고 주장했다. 게다가 만일 아키텍처 팀이 명세를 맡을 경우 그 150명은 열 달 동안 빈둥거리며 앉아 있게 될 처지였다.
그 주장에 대해 아키텍처 관리자는, 만약 제어 프로그램 팀이 그 일을 맡을 경우 명세 작성은 일정을 넘겨서 역시나 세 달 늦어질 것이며, 품질도 더 낮을 것이라고 했다. 하지만 나는 그렇게 결정했고, 결과는 그의 말대로였다. 그는 두 가지 면에서 모두 옳았다. 더구나 만들어진 명세는 개념적 일관성이 결여되어 있어서 시스템 구축과 변경에 많은 비용이 들었고..(중략)..
물론 이런 잘못된 결정에는 여러 가지 요인이 영향을 끼쳤겠지만, 그중에서도 가장 컸던 것은 일정 압박, 그리고 150명의 구현 담당에게 일거리를 주어야 한다는 점이었다. 바로 이것이 이제 그 치명적인 위험을 드러내고자 하는 유혹의 속삭임이다…
하지만 물론 소수의 인력을 영구적으로 이동시키는 것도 쉽지 않을 것이다. 결국 파견이라는 극단적인 선택지는 프로젝트가 이미 잘못된 길로 가는것을 나타내는 한 가지 현상일 뿐이다.
Conclusion
내가 항상 머릿속에 새기고 있는 생각 중 하나는 소프트웨어 개발자들의 생산성과 능력은 연차와 연봉에 비례하지 않는다는 것이다. 다른 직업보다 그 특성은 매우 두드러지며 때로는 반비례하는 등 훨씬 극단적이다. 하지만 전통적인 직업들에서 경력과 경험은 객관적인 능력 평가에 있어서 필수적인 요소다. 이 간극으로 인해 프로젝트의 비효율성과 몰락이 종종 발생한다. 때로는 그것은 다소 정치적 혹은 이해집단적 이기도 하다.
이 시뮬레이션에서의 가장 큰 문제점은 회사의 덩치에 비해 너무 작은 팀에 과도하게 큰 기대치를 가졌다는 것이 아닐까? 노하우조차 없는 분야에서 머릿수로만 밀어붙이는 것이 IT에서는 필패라는 것을 보여주는 것이 아닐까 싶다. 사유하기엔 재밌는 상황이지만, 여러분은 혹시라도 겪지 않기를 바란다.
언젠가 개발 리딩을 맡게 되면 이러한 상황에서도 모든것을 극복하고 최선의 선택을 할 수 있을까? 이러한 사고실험은 그것을 위한 노력이다.