추가인력의 투입은 언제가 좋을까?

일명 "죽음의 행진(Death March)" 프로젝트에는 여러 공통점들이 있다.
그 중 가장 흔하고, 그러지 말아야지 하면서 잘 안지켜지는 게 밑빠진 독에 물붓는 식으로 추가인력을 투입하는 것이다. 이는 필요에 의해서 일 수도 있고, 갑이나 을의 압박에 의해 울며겨자먹기 식으로 발생하기도 하고, 전략적인 차원(주로 비지니스적인)에서 일어나기도 한다.

스티브 맥코넬의 말을 굳이 빌리지 않더라도, 프로젝트가 어려움에 빠져있을 때 이를 해소하기 위해 추가인력을 투입하면 프로젝트가 오히려 더 깊은 수렁에 빠지는 경우가 실제로 아주 많다.

예전에 갔었던 어느 금융권 프로젝트에서는, 일정 지연을 이유로 고참 PL이라는 사람이 너무나 쉽고 당당하게 추가 인력을 요구하는 모습을 봤었다.

> 본부장 : "일정이 왜 이리 안나가지?"
> PL : "개발자가 부족합니다."
> 본부장 : "얼마나 있어야 되는데?"
> PL : "많으면 많을 수록 좋죠."
> 본부장 : "헐... 두 세명이면 되나?"
> PL : "예. 그 정도면 될 것 같습니다"

자신이 그 업무의 리더라는 사실을 잊고 사는 사람이다. 정확하게 어느 수준(스펙)의 개발자가 어떤 파트에 필요한지 정도는 파악을 하고 있어야 하지 않을까? 이런 부류의 사람들은 프로젝트가 한참 더 힘들어져 있을 때, 그 추가로 투입된 신입개발자 2명의 실력이 떨어져서 진도가 안나간다고 보고할 사람들이다. 그런 상황을 미리 예측하고 필요한 조치를 취하지 못한 자신에게 모든 책임이 있을 뿐이다.



다른 예를 하나 더 들어보자.

또다른 금융권 차세대 프로젝트는 더욱 가관이었다.
너무나 자주 새로운 개발자들이 들어오고 나가서 옆에 있는 동료(같은 회사 직원)가 누군지도 왜 들어왔는지도 모르는 상황이었다. 지난 주 까지 저쪽 파트에서 일하던 사람이 이번 주부터는 이쪽 파트에서 일을 했다. 이쪽이 급하면 이쪽으로, 저쪽이 급하면 저쪽으로 개발자들이 왔다갔다 했다. 당연히 예전에 있던 개발자들은 프로젝트를 옮기거나 회사를 떠났고, 프로젝트의 초창기 멤버라고는 손에 꼽을 정도였다.

이 프로젝트에 들어가서 비어있는 IP Address를 찾는데 반나절이 걸렸고, 자리를 잡고 네트웍 세팅을 하고 전체 시스템(네트웍, 서버 구성)을 파악하기 까지 이틀이 걸렸다. 시스템 구성도는 말할 것도 없고, 누구 하나 제대로 설명을 해주는 사람이 없었다.

너무 극단적인 얘기일까?
아니다. 우리나라에서는 흔히 볼 수 있는 상황일 것이다. (사실 해외에서 프로젝트를 해본 경험이 없다)

---------------------- * ----------------------

그렇다면 프로젝트에 추가 인력은 언제까지 투입하는 게 좋을까? 물론 그때그때 프로젝트 상황에 따라 다르므로 정답은 없다. 다만, 오랜 경험으로 봤을 때 추가인력 투입시기 판단의 가장 중요한 기준은 "그 프로젝트가 추가인력을 감당할 수 있는가"이다.

프로젝트가 추가인력을 감당할 수 있느냐라는 것은 여러가지 의미가 있다.

대형 차세대 프로젝트 같은 곳에는 각종 Framework을 활용하여 업무 프로그램을 개발하는 데 필요한 기초 지식을 가르쳐주는 교육팀이 별도로 존재하기도 한다. 그렇지 못한 곳에서는 인프라팀(공통팀)에서 교육을 시키거나 별도의 팀없이 한두명의 담당자가 있는 경우도 있다. 아예 그런 여건이 안되는 소규모 프로젝트에서는 선임 개발자가 멘트 형태로 교육을 시킬 수도 있다.

새로운 개발자가 들어왔을 때 프로젝트에서 그 개발자를 교육시킬 준비가 되어 있는가? 일정과 각종 이벤트들을 고려했을 때 프로젝트 상황이 그럴 여유가 있는가? 즉, 위에서 얘기한 대로 신규 인력이 들어왔을 때 교육을 전담할 팀(그룹)이나 선임 개발자가 있는지 반드시 고려해 봐야 한다.

다행스럽게도 신규 투입된 개발자가 굉장히 스마트하고 프로젝트에서 사용중인 여러 기술셋(Framework 등)에 익숙하다면 1~2주 만에 아웃풋을 낼 수 있겠지만, 그렇지 못한 경우에는 선임 개발자가 전담해서 교육을 시킨다 하더라도 최소 3주 정도는 돼야 기대하는 수준의 결과를 만들어 낼 수 있을 것이다. 빨라야 3주라는 말이다. 한달이 지나도 별 성과를 못내는 사람들도 수두룩하다.

너무나 상식적인 얘기가 아닌가? 익숙하지 않은 환경에서 익숙하지 않은 툴과 Framework으로 업무 프로그램을 2주 안에 뽑아내라는 게 오히려 더 이상한 요구가 아닌가 말이다. 그것도 업무를 어느정도 알고 있을 때나 가능하지 개발해야 할 업무 조차도 잘 모르는 상황이라면 업무 파악에 대한 부담도 생기게 된다.

욕심을 버리자. 신규 투입된 개발자가 원하는 성과를 내려면, 게시판 같은 것을 뚝딱 만드는 게 아닌 한 보통 한달은 걸린다. 정말로 운이 좋지 않다면 말이다.

한달 동안 이 개발자는 혼자서 묵묵히 개발표준과 각종 매뉴얼을 보며 기술셋을 익힐까? 아니, 그런 매뉴얼과 표준은 잘 만들어두고 있는가? 참고할 문서라도 제대로 갖고 있는가? 요구사항 정의서는 얼마나 잘 업데이트 되어 있을까? 신규 개발자가 혼자서 이런 (잘 되어 있으리라 기대해 마지 않는) 산출물들을 갖고 열심히 노력하면 한달 정도 지나서 아웃풋이 나올 수 있을까?

아무리 그렇다 하더라도 누군가에게 물어봐야 한다. 옆에 있는 사람이나 아까 얘기한 멘토(기존 인력)를 괴롭혀야 한다. 차라리 이렇게 물어라도 보는 개발자들은 나중에 있을 삽질을 막을 수 있어서 그나마 낫다. 혼자서 끙끙거리며 뚝딱뚝딱 뭔가를 만드는 개발자는 100% 삽질을 하게 된다. 아예 업무를 잘못 이해하고 있을 수도 있고, 기존 인력들이 수 개월간 고민해서 해결한 문제를 다시 똑같이 고민하며 혼자 해결하려 시간 낭비를 할 수도 있다. (이런 내용은 산출물에 잘 안들어 있다)

신규 개발자의 성격에 따라 다를 수 있지만, 혼자서 문제를 해결하려는 사람이 있는가 하면, 뭐든 시시콜콜 물어보며 옆사람을 괴롭히는 사람들도 있다. 이들은 산출물이나 매뉴얼을 잘 보지 않는다. 파일서버 어딘가에 분명히 있다고 했는데도 바빠 죽겠는데 옆에 와서 자꾸 물어본다. 원래 성격이 그럴 수도 있고 신규 투입된 인력의 권리로 여기는 것일 수도 있다.

괴롭힘을 당하는 사람들이 이런 식의 질문에 대응하며 집중력을 잃고 다시 원래의 자리로 돌아가는 이른바 'Context Switching 비용'은 스티브 맥코넬의 연구에 의하면 약 30분 정도라고 한다. 물론 사람에 따라 다를 것이다. 나는 보통 누군가에게 약간 긴(10분? 20분?) 시간 동안 무엇을 알려주고 나면 항상 담배를 하나 핀다. 메일을 확인하는 사람도 있을 거고 네이버나 블로그, 페이스북을 열어보는 사람들도 있을 것이다. 곧바로 일에 몰두하는 사람들도 있겠고..



자, 프로젝트가 추가 인력을 감당할 수 있는가?

한달 앞으로 다가온 2차 중간보고나 혹은 오픈 일정에 쫓겨 모든 개발자들이 고도의 집중력을 발휘하며 철야를 하고 있다. 애초부터 일정은 많이 지연되고 있어서 지금 있는 인력으로는 기간 안에 도저히 마무리 할 수 없을 것 같다. 추가 개발자가 필요하다고 판단이 되는가? 틀렸다. 일정을 연기하거나 범위를 협상해야 한다. 물론 절대로 선택할 수 없는 옵션일 것이다. 고객을 설득할 자신이 없을 뿐더러 "추가인력 투입"이 더 쉬워 보이기 때문이다. 개발자 2명만 더 투입되면 될 것 같은 느낌이 들기 때문이다. (보통 이런 상황에서는 객관적인 근거는 없고 느낌만으로 판단한다)

2달 동안의 통합테스트 기간이다. 담당 고객들과의 지속적인 회의를 통해 테스트 결과로 나온 수많은 버그들을 수정하며 고된 시간을 보내고 있다. 어제까지 잘 되던 기능이 자고나면 안된다는 불만으로 고객이 화가 머리끝까지 나있다. 수정해야 할 것도 많고 새로 개발해야 할 기능들도 아직 많이 남아있다. 추가 개발자가 필요하다고 판단이 되는가? 틀렸다. 기존의 팀을 개발모드가 아닌 테스트 모드로 재편해야 한다. 한두명의 테스트 전담인원을 요청하는 게 더 낫다. 필요한 사람은 개발자가 아니다.

이런 상황에서 추가인력을 투입하는 건 공멸의 길로 가는 것이다. 프로젝트가 그 인력들을 감당할 수 없기 때문이다. 프로젝트 후반에 갈 수록 필요한 것은 추가 개발자가 아니라 기존 개발자의 집중력이나 생산성을 떨어뜨리는 요인들을 찾아서 제거해주는 것이다.

> 왜 진도가 안나갈까?

> 고객의 요구사항이 자주 바뀌는 것은 아닐까?

> 화면 혹은 DB 설계가 잘못 되었나?

> 개발자가 업무를 제대로 이해하지 못하는 것은 아닐까?

> 집에 무슨 일이 있나?

> 여자친구와 헤어졌나?

> 밥은 먹고 다니나?

개발자의 주위 환경을 개선해주려고 한다면, 정말 잠시도 쉬지 않고 생각해도 끝이 없을 무수히 많은 고민들이 생긴다. 개발자들은 레고 블럭이 아니기 때문이다.

* 물론 예외는 있다. 독립적으로 개발이 가능한 업무, 이를테면 배치 프로그램이나 집계(통계) 프로그램은 기존의 표준과는 약간 다른 관점으로 개발이 되어도 무관할 수 있다. 이런 업무라면 경험있는 개발자를 스팟성으로 지원받아 일정을 맞추는 것이 가능하다. 또한 방법론에 대한 가이드(산출물 작성 등)나 업무 교육, 성능 튜닝 등 비개발적인 필요성도 배제하자. 이런 것은 그때그때 도움을 받아야 한다.

---------------------- * ----------------------

프로젝트가 그 인력들을 감당할 수 있는지 아닌지 판단하기는 매우 어렵다.
프로젝트 외부의 압박도 심할 것이기 때문이다. 어떤 경우에는 "영업적으로의 원만한 해결"을 원하는 윗선들로 인해 원치 않는 추가 개발자가 투입될 수 밖에 없는 경우도 있다. 어떤 경우든 해당 프로젝트의 리더라면 "이 인력이 우리에게 도움이 될 수 있을지"를 반드시 심각하게 고민해야 할 것이다. 경험이 부족하고 우유부단 하거나 책임을 지지 않으려는 성향의 리더들은 이런 것 조차도 다른 사람 탓을 한다. "XX가 개발자 2명이 필요하대요"

돈과 관련된 이런 중요한 의사결정 마저 스스로 판단하지 않는다면 도대체 왜 그 자리에 앉아 있는 것일까. 프로젝트에서 뒤늦게 추가인력이 필요하게 만든 책임은 생각지도 않고 말이다.

부끄러운 줄 알아야지..