🕑 리딩타임: 6 분

업무 효율성의 관점에서 ‘팀워크’가 중요한 이유

 

 

 

한 팀의 구성원이 되어 효과적으로 일하는 것은 좋은 품질의 결과물을 내고, 사기를 진작하고, 근속 기간을 늘리는 데 매우 중요하다. 개인적으로 팀워크를 발휘하여 일을 해야 했던 경험은 대부분 소프트웨어 엔지니어링에 한정되어 있지만, 그 경험을 통해 배운 교훈은 엔지니어링 분야에 한정되어 있지 않다.

 

효율성의 관점에서 대규모 팀을 구성하는 전통적인 관점은 프레더릭 브룩스의 ‘맨먼스 미신’이라는 이론에 기반한다. 맨먼스(Man-Month)란 한 사람이 1개월 내에 끝낼 수 있는 업무량을 나타내는 단위이다. 브룩스의 ‘맨먼스 미신’의 기본 원리에 따르면 맨먼스가 12인 프로젝트, 즉 한 사람이 1년이 걸려서 만들 수 있는 소프트웨어 프로젝트가 있다면, 이 프로젝트에 투입되는 엔지니어의 수를 12명으로 늘리기만 하면 프로젝트를 한 달 내에 끝낼 수 있다. 예정보다 일정이 늦어지는 프로젝트를 담당하고 있는 관리자라면 프로젝트에 엔지니어를 더 투입하여 일정을 맞추고 싶은 마음이 굴뚝같을 것이다.

 

하지만 이 논리의 문제점이자 이 이론을 ‘미신’이라고 부를 수밖에 없는 이유가 있다. 어느 한 프로젝트에 엔지니어가 새로 투입되면 각 엔지니어마다 팀원 모두와 의견을 나누고 조정하는 데 드는 추가적인 업무 부담이 발생한다는 점이다. 따라서 프로젝트에 소요되는 시간이 투입하는 인력과 비례하여 줄어들지 않는다. 바로 여기서 브룩스의 법칙이 적용되는데, 브룩스의 법칙이란 “지체되고 있는 소프트웨어 프로젝트에 인력을 더 투입하면 프로젝트는 더 지체된다.”는 법칙이다.

 

같은 이유에서, 일부 관리자들이나 기술 분야 전문가들은 효율성을 지나치게 극대화하고 싶은 나머지 1인 프로젝트로 조직을 구성하여 의견을 나누는 데 드는 업무 부담을 아예 없애려는 시도를 하기도 한다. Google을 비롯한 일부 회사에서는 심지어 승진 과정에서 이런 요소가 중요하게 작용한다. 따라서 엔지니어들은 프로젝트에 대한 주인 의식을 증명해 보여야 하고, 이를 위해 엔지니어들은 개개인의 프로젝트를 명확하게 한정하고 우선 순위를 정하게 된다. 이를 통해 특정 프로젝트에 대해서는 부인할 수 없는 담당자가 되고, 승진할 수 있는 가능성이 높아진다.

 

 

 

하지만 현실적으로 혼자서 일을 하는 방식에는 단점과 위험 요소가 너무 많고, 이는 결과물의 품질에 영향을 미치고 사기를 저하한다.

 

• 혼자 일을 하면 설계에 대한 피드백을 빠른 시간 내에 지속적으로 받기가 힘들어 진다. 이는 결과물의 품질 저하로 이어질 수밖에 없다. 빠듯한 피드백 주기는 생산성 주기에서 아주 중요하다. 피드백을 빨리 받으면 받을수록 잘못된 방식으로 일을 진행하는 시간을 줄일 수 있는 가능성이 높아지고, 올바른 방향을 빨리 찾을 수 있는 가능성이 높아진다. 실제로 소프트웨어 개발 현장에서 상황을 잘 파악하고 있는 같은 팀 팀원은 아주 쉽게 내 코드를 검토하고 도움이 될 만한 피드백을 줄 수 있다. 하지만 다른 프로젝트를 진행 중인 사람이 코드를 주는 것은 훨씬 어렵다. 브라이언 피츠패트릭과 벤 콜린스 서스먼은 이러한 현상을 “협업의 기술”(원서명: Team Geek)이라는 책에서 한 문장으로 잘 나타내고 있다. “소프트웨어 개발은 팀 스포츠와 같다.”

 

• 혼자 일을 하면 배울 기회가 없어진다. 위에서 살펴본 점과도 연관이 있다. 혼자서 일을 하면 상황을 같이 공유하고 반대 의견을 말해줄 사람이 없다. 또한 한 프로젝트를 완료하는 데 훨씬 더 많은 시간이 걸리기 때문에 시간이 지나도 한 사람이 경험해볼 수 있는 프로젝트의 수가 적을 수밖에 없다.

 

• 팀을 이루어 일을 하면 버스 지수(bus factor)가 높아진다. 프로젝트의 버스 지수란 팀원 중에 몇 명까지 버스에 치였을 때(혹은 건강 상의 문제가 생기거나, 퇴사를 하거나, 육아 휴직을 해야 할 때) 프로젝트가 완전히 중단되지 않을 수 있는지를 나타내는 수치다. 버스 지수가 높을 수록 프로젝트의 리스크는 낮아진다. 이 버스 지수를 높이면 이해하기 어렵고 문서화되지 않은 업무 요령을 팀원 중에 단 한명만이 알고 있는 사태를 방지하고, 지식을 함께 공유하여 유사시에 다른 사람이 쉽게 그 업무를 이어서 처리할 수 있도록 업무를 진행할 수 있다.

 

• 팀으로 일을 하면 책임감이 높아진다. 동료가 주는 압박감은 강력하다. 특히 존경하고 실망시키기 싫은 사람과 함께 일한다면, 개인이 최고의 성과를 내지 못하는 시기가 와서 사기가 저하된다고 하더라도 팀이 성공하기를 바라는 마음으로 이를 극복할 수 있다.

 

• 혼자서 프로젝트를 진행하면 속도가 느려지고, 이로 인해 사기가 저하될 수 있다. 프로젝트를 평가하는 것은 힘들다. 그리고 프로젝트의 일정은 늦어지기 쉽다. 1인 프로젝트에서는 엔진이 하나만 고장이 나도 프로젝트 전체가 멈출 수 있다. 슈퍼에 계산대가 하나만 있다고 생각해 보자. 한 손님에게 문제가 생기거나, 물건 하나의 가격만 확인하려고 해도 모든 계산 과정이 일시적으로 중단될 수 있다. 프로젝트에 한 명만 더 있어도 프로젝트가 진척될 수 있는 힘이 생긴다. 또한 사람들은 프로젝트에 걸린 시간을 계산할 때, 투자한 시간을 기반으로 계산하는 것이 아니라 경과한 시간을 기준으로 계산하는 경향이 있다. 실제로는 두 달 정도의 시간을 투자했지만, 걸린 시간으로 따지면 반년 정도가 경과된 프로젝트가 있다고 해보자. 조직 내에 담당자나 다른 구성원들은 전체 프로젝트 진행 속도가 너무 느리고 완성되는 데 반년이나 걸렸다고 생각하지 않을 수 없다. 이렇게 한 프로젝트를 끝내는 데 경과한 시간으로 인해서 오는 실망감은 사기를 저하시키고 기대감을 떨어뜨린다.

 

• 혼자 일할 때 프로젝트에 힘든 일이 있으면 더 의기소침해지기 쉽다. 빠져나와야 할 벙커가 있거나, 혼자 해내야 하는 단순 작업이 있거나, 이해할 수 없는 버그가 있을 때, 이 고통을 함께 나눌 수 있는 누군가가 있다면, 모든 일들이 덜 힘들고, 더 견딜만해진다.

 

• 팀으로 일할 때 프로젝트에 좋은 일이 있으면 더 동기부여가 된다. 어떤 성과를 팀원들과 함께 축하하는 일은 사기를 진작시킬 수 있는 좋은 방법이다. 혼자 일한다면 무언가를 해냈을 때 누가 하이파이브라도 해줄 수 있겠는가.

 

혼자 프로젝트를 진행하면서 사기가 저하된다는 것은 직원 만족도가 낮아지고 근속 기간이 짧아지는 것을 의미할 수 있다. 따라서 기업이 성장하려면 1인 1팀 체제는 반드시 피해야 한다고 생각한다. 팀원은 최소 2명 이상이 되어야 한다. 어떤 프로젝트에서나 한 사람이 전담할 수 있는 업무가 있을 것이다. 하지만 이러한 업무를 모아서 주제별로 팀원들이 상황을 공유할 수 있도록 만들면 따로 일하는 것보다 위의 위험 요소를 줄일 수 있고 팀원들은 공동의 목표를 위해서 협업할 수 있다.

 

진행하고 있는 프로젝트가 많거나, 다양한 분야의 제품을 생산하는 회사라면 어떻게든 해내야 할 일이 너무 많고 독립적인 여러 프로젝트를 모두 진행해야 하기 때문에 ‘1인 1팀’을 이룰 수 밖에 없다고 말할 수도 있다(모순 어법이다). 이는 한 조직의 규율이 너무 잡혀 있지 않아서 프로젝트의 우선 순위를 정하고, 프로젝트의 일부를 포기하고 순서를 정해야 한다는 신호일 수 있다. ‘캐즘 마케팅(원서:Crossing the Chasm)’이라는 책에서 제프리 무어는 첨단 기술 기업이 제품을 주류 시장에 진입시키는 데 실패하는 이유 중 하나는 집중할 수 있는 프로젝트의 수를 제한해주는 규율이 없기 때문이라고 주장했다.

 

“이는 우주 과학처럼 어려운 개념이 아니다. 하지만 일종의 규율을 나타내는 것은 맞다. 첨단 기술 경영진들에게 많이 결여되어 있는 부분이다. 대부분의 첨단 기술 기업들이 마케팅에 있어서는 틈새 전략을 피하려고 한다. 비록 틈새 시장 전략이 최선일 수는 있지만 우리에게는 시행할 수 있는 시간이 충분하다거나, 또는 지금 시행할 여력이 없다는 주장을 할 수 있다. 물론 이것도 하나의 전략이지만 진정한 해결책은 더욱 단순하게 생각하는 것이다. 시행할 수 없거나, 시행할 의지가 없어도 어떤 규율이 있으면 판매든 시간이든 이유든 우리를 멈추게 할 수 있다.”

 

그렇다고 해서 팀을 이루어서 일하는 것이 쉽다는 것은 아니다. ‘팀워크’의 좋은 점만 누리고 노력은 기울이지 않는 무임승차자를 누구나 겪어봤을 것이다. 하지만 이러한 위험 요소가 있다고 하더라도 효율적인 팀을 구성하는 방법을 찾아내고 이를 실현하기 위한 노력을 포기해야 할 이유는 될 수 없다.

 

* 본 글은 Forbes에 올라온 Why And Where Is Teamwork Important?을 번역해 가져온 내용 임을 밝힙니다.