작은 팀이 강하다 |
 |
깔때기 이론
대학생 시절 내가 처음 떠났던 유럽 배낭 여행. 런던의 모 민박집에서 우연히 만난 한국의 사나이 네댓 명이 밤 늦은 줄도 모르고 도란도란 이야기 꽃을 피우고 있었다. 그러던 중 카리스마 넘치는 큰형님이 흥미로운 이야기를 해줬다. 이름하여 ‘깔때기 이론’. 대한민국 남성들의 대화는 종국에는 군대나 축구(지금 기억해보면 이게 여자였는지도 모르겠다)로 모인다는 대통합 이론이었다. 마침 우리는 군대에서 공 차던 이야기(얼핏 군대에서 공 차면서 여자 생각하던 이야기 같기도 하다)를 하고 있었다.
IT 업계에도 이런 깔때기 이론이 있다. 고객사에 컨설팅을 가서 사람들을 만나 인터뷰도 하고 워크샵도 한다. 무엇이 가장 큰 문제입니까? 십중팔구 이야기는 하나로 모인다. "우리는 인원이 부족해요!" (그리고 또 다른 레퍼토리는 "우리는 커뮤니케이션이 잘 안 돼요!"다.)
침묵 효과와 탈색 효과
사실 처음에는 다양한 이야기가 나온다. 그러다가 누군가가 인력 이야기를 꺼내면 모든 이야기가 이쪽으로 모이기 시작한다. “그래, 그래. 맞다, 맞아.” 문제의 원인, 그 원인의 원인을 따지고 들어가면 결국 남는 것은 '인원 부족'이다. 대화는 대부분 이런식으로 진행된다 "우리는 뭐뭐뭐가 안돼요", "사람이 없는데 어쩌라구", "아, 맞다! 근데 사람 언제 뽑아주나?".
그 때부터 사람들은 소극적 방관자로 바뀌기 시작한다. 위에서 해결해 줘야 한다. 두어달 후에 충원될테니 그 때까지 기다려야 한다. 계속 사람을 모집 중인데 뽑기 참 어렵다. 그 동안 우리가 할 수 있는 일은 없다... 등.
이상하게도 이렇게 인력 문제가 거론되고 나면 더 이상 토론이 진행되질 않는다. 사람들이 더 이상의 탐구를 포기하는 것이다. 그래서 나는 그 말에 침묵 효과(일명 ‘그 입 다물라’ 효과)가 있다고 말한다. 이와 동시에 문제들이 다 비슷해져 보이는 탈색 효과도 있다.
왜 그럴까? 사람들이 더 이상 생각, 고민을 안 해도 되게 만든다. 사람이 더 증원되면 해결되겠지. 증원은 위에서 해주는 일이다. 우리가 당장 할 수 있는 조치는 없다. 이런 식으로 사람들은 무기력해지고 현실에 매몰된다. 또한, 사람이 많아지면 근본 문제가 감춰지기 쉽다. 더 많은 문제가 생기기 때문이다.
필자는 종종 IT 인력(특히 개발자) 구인 컨설팅을 하기도 하는 사람으로, 인력을 잘 뽑아야 한다는 데에는 적극 찬동하지만, 인력을 더 뽑아야 한다는 데에는 우선 의심부터 하고 본다. 구인 컨설팅의 영번째 단계는 클라이언트와 함께 우리가 구인을 통해 해결하려고 하는 진정한 문제가 무엇인지, 그리고 그걸 구인을 통해 해결하는 것이 최선인지 파악하는 것이다. "우리가 왜 이 사람을 뽑는가?". 정말 구인이 필요한 경우도 있지만, 다른 근본 문제가 우선인 경우도 많으며, 근본 문제를 덮어두기 위해 사람을 뽑기도 한다.
인원 부족이라는 문제에 생각이 다다르면 모든 문제가 근원적으로 동일해져 버린다. 소, 개, 고래의 공통점을 묻는 IQ 질문에 "존재하는 것들이다"라고 자랑스럽게 답해버리는 사람 앞에서 오는 허탈감이 느껴진다. 사실 문제의 근본 원인은 다른 곳에 있는데도 이런 식으로 사람 숫자 부족으로 몰기 시작하면 문제를 덮어버린다.
사람을 줄이면 문제가 쉽게 노출될 수 있다. 하지만 대부분의 사람들은 이 사고를 쉽게 실천하지 못한다. 일하는 능력도 줄어들 것이라 생각하기 때문이다.
다다익선의 미신
그런 의심을 갖는 독자들에게 두 가지 연구를 언급한다. 하나는 월간 마이크로소프트웨어 8월호에 소개한 카오스 보고서다.
|
|
대략 5만여개 IT 프로젝트에 대한 누적 통계 자료를 갖고 매년 추가 보고서를 내고 있는 스탠디쉬 그룹(Standish Group)의 카오스 보고서에서는 IT 프로젝트의 평균 성공률을 34% 정도라고 말한다. 해가 가면서 이 수치는 높아지기는 했다 -- 1995년도에는 16% 근방이었다. 하지만 "저는 10명 중 3명만 성공시켜요"라고 말하는 외과의사에게 누가 몸을 맡기겠는가 하는 생각에 다다르면 우리가 전문직(profession)을 가진 사람인가 반문하게 된다.
흥미롭게도 이 통계자료를 프로젝트 크기별로 그룹을 지어서 다시 계산하면 어떤 패턴이 보인다. 일반적으로 작은 프로젝트 성공률은 큰 것의 3배가 넘는다. 예를 들어 6명이 6개월 일하는 프로젝트의 성공률은 50%가 넘는 반면, 500명 이상이 36개월 이상 일하는 "비싼" 프로젝트는 성공률이 0%이고, 250명 이상, 24개월 이상의 프로젝트는 8%의 성공률을 갖는다.
또 다른 케이스 스터디에서는 프로젝트 크기가 증가함에 따라 결함 수는 비선형적으로 증가함을 발견했다. 소프트웨어 공학에 널리 알려진 진실 중 하나는, 결함을 줄이는 최고의 방법은 전체 라인수를 줄이는 것이라는 사실이다.
--김창준, 월간 마이크로소프트웨어 8월호 특집 기사
| |
두 번째는 QSM의 연구다. QSM은 2005년 7월 기준으로 7000개가 넘는 프로젝트에 대한 데이터를 갖고 있다. 여기에서 프로젝트를 소규모 팀(5명 이하)과 대규모 팀(20명 이상)으로 구분해 보았다. 해당 프로젝트들의 소스 코드 크기는 1만 라인(SLOC)과 20만 라인 사이에 분포한다. 4만 라인을 기준점으로 잡을 때, 프로젝트당 평균 인원 수는 작은 팀의 경우 2.5명, 큰 팀의 경우 29명이었다. 쉽게 말해, 똑같은 규모의 프로젝트에도 2.5명이 작업한 팀이 있고, 29명이 작업한 팀이 있다는 이야기다.
각 팀별 개발 기간을 보면 놀라운 사실을 발견할 수 있다. 두 개 팀 사이에 평균 개발 기간의 차이가 있긴 한데, 딱 12일 차이다. 전체 기간은 최소 6개월에서 1년을 넘는다. 놀랍지 않은가? 같은 크기의 프로그램을 개발하는데, 예컨대 2.5명은 1년 12일 걸리고, 29명은 1년 걸린다는 이야기. 29명 중 26.5명이 일정을 단지 12일 앞당길 뿐이라니! 인월(man-month)로 따지면 작은 팀이 40 인월이면 되는 일을 큰 팀에선 191 인월을 소모한다. 연구 보고서에 따르면 29인팀은 약 18억 원을 추가로 쓴 셈이다. 1년 가까이 되는 프로젝트에 12일 앞당기는 것이 18억 원의 가치가 있는가? 그렇다면 큰 팀을 택하라는 이야기.
왜 이런 일이 생길까? 4만 라인의 코드를 만들면서 큰 팀(평균 29명)은 작은 팀(평균 2.5명)에 비해 통상 여섯 배나 많은 결함을 생산해 냈다. 큰 팀은 많은 양의 결함과 씨름하느라 추가 인력의 덕을 거의 보지 못했다.
적어도 지식 노동이라면 인력은 단순 비례식이 먹히질 않는다. 1이라는 작업을 두 사람이 1년 걸려 완료한다고 가정하자. 임원진의 특별 명령 하사. 10의 작업을 1년만에 하려면 스무 명이면 되겠네? 우리의 불쌍한 팀장님 그 앞에서 “예스, 아이 캔!”을 외친다. 결함 개수의 변화만 살펴보자. 우선 팀 크기가 두 명에서 스무 명으로 열 배 늘었으니 대충 결함이 여섯 배 는다고 치자. 그런데 작업물의 크기도 바뀌었다. 프로젝트 크기가 바뀌면 결함 밀도(라인당 발생하는 결함 수)도 바뀌는 것으로 알려져 있다. 예를 들어, 10 FP(기능점수)에서 100 FP로 프로젝트 크기가 열 배 늘어나면 결함 밀도가 약 여섯 배 늘어난다는 자료가 있다. 결함 밀도가 여섯 배 증가하면, 결함 숫자는 전체 프로젝트 크기 곱하기 밀도이므로 60배가 늘어나는 셈이다. 사람도 늘고, 프로젝트 크기도 늘었으므로 결함은 6 곱하기 60으로 360배가 된다. 결함 하나 고치는 데에 짧으면 1분이지만 길면 몇 달도 걸릴 수 있다는 점을 생각하면 360배는 엄청난 차이다.
악순환
프레드 브룩스(Frederick P. Brooks)는 "맨먼스 미신"(The Mythical Man-Month)이란 책에서, 일정이 늦어진 프로젝트에 인력을 추가하는 것은 프로젝트를 더 느려지게 만든다고 했다. 그리고 그 이유로 몇 가지를 든다. 새로운 개발자가 학습에 걸리는 시간이 있다는 것, 그리고 사람이 늘어나면서 사람 간의 소통 채널 숫자는 기하급수적으로 늘어나 소통 비용이 급격히 증가한다는 것이다. 이렇게 되면 개발자의 생산성이 음수가 될 수도 있다고 한다(예를 들어 버그 삽입 등을 통해). 어제 시점에서 해야 할 일의 총량보다 오늘 시점에서 해야 할 일의 총량이 더 많아지는 것이다.
그렇지만 사람들은 반사적으로 프로젝트가 늦어지면 사람을 추가한다. 이 때문에, 실패하는 프로젝트의 삶은 다음 주기를 반복하는 경우가 종종 있다. 어느 순간 일정이 촉박하다는 두려움이 엄습해 온다. 증원한다(혹은 증원 못하는 대신 품질을 포기하고 작업 시간과 속도를 높힌다). 그래서 버그가 증가하고 의사 소통이 더 복잡해진다. 버그 수정과 의사 소통에 시간을 더 소비하게 된다. 일정이 더 촉박해진다. 다시 반복. 사실 이 패턴은 살찌는 사람에게 무척 익숙하다. 살이 찐다는 두려움이 엄습해 온다. 스트레스가 쌓인다. 스트레스를 풀려고 더 먹는다. 살이 찐다. 다시 반복.
이런 이야기를 들으면 "우리는 스무 명이지만 협력 없이 각자 따로 일합니다 -- 효과적으로는 각기 일인 프로젝트인 셈이죠"라고 말하며 의기양양해 하는 사람이 있다. 그런 팀도 결국 어떻게든 협력이 필요하고 실제로도 서로 협력하고 있는 경우가 많은데, 그 협력을 제한해 놓았기 때문에 협력 자체가 병목이 되고 팀의 속도가 느려진다.
작은 팀이 강하다
사람 숫자가 적을 때에는 협력에서 상승 효과를 내는 것이 비교적 쉽다. 그래서 나는 "작은 팀이 강하다"고 말한다. 하지만 큰 팀이면서 강할 수 있다. 협력 수련이 충분히 되어 있으면 된다. 하지만, 우리가 큰 규모로도 협력할 수 있는 능력이 자라나는 속도보다 인력이 추가되는 속도가 더 빠르면 안 된다. 안타깝게도 협력을 잘 못하는 팀에서 비는 제일 소원이 증원이다.
증원을 기대하고 손 놓고 있기보다, 작은 팀이 강하다는 믿음을 갖고 적극적으로 근본적 해결책을 찾을 것을 권하고 싶다. 물론, 야근 안 하면서도 가능한 방법을 말이다. 그러면 여러분의 상상력과 협동력이 훨씬 계발될 것이다.
 [지난 developerWorks Column 보기]
|
김창준 
