SW 개발 조직의 Build Up, 협업
Agile Note 여덟 번째
말콤 글래드웰은 그의 책 'Tipping point'에서 균형이 깨지고 예상하지 못한 일들이 폭발적으로 증가하는 시점에 대해서 얘기합니다. 변화가 극적으로 시작되는 순간이기도 합니다. 물리학에서 'State Transition'은 상전이 현상을 일컫는 용어인데, 예를 들면 기온 변화라는 스펙트럼 안에서 얼음이 물로 변하는 지점, 물이 다시 기화하는 지점 등이 '상전이(State Transition)'가 일어나는 지점이자 다른 상태로 급격히 변화하는 시점이라고 합니다.
조직 또는 팀은 다양한 캐릭터를 가진 사람들의 공동체이고, 공동체를 이루고 있는 숫자, 즉 규모에 따라 다른 특색을 보이기도 합니다. 5~6명이 모인 그룹에서 나타나는 특징과 20~30명의 그룹에서 나타는 특징, 또는 100명 이상의 대규모 그룹에서 나타나는 특징은 다를 수밖에 없다고 합니다. 물리학자이자 바이오테크 기업의 창시자인 사피 바칼은 룬샷에서 조직의 특징을 다음과 같이 언급합니다.
"기업 조직은 스타트업의 경우 창의적 아이디어, 특이한 기획 등이 조직 안에서 존중받으며 개인의 목적보다는 협업에 방점에 찍힌 형태로 흘러가는 것이 자연스럽다. 그러나 팀(조직)의 규모가 일정한 숫자, '매직넘버'를 넘어서는 경우 자신의 안위와 경력관리에 초점을 맞추는 방향으로 동기부여의 균형점이 이동한다."
"그래서 일정 규모 이상으로 불어난 팀이 창의적 활동과 협업, 그리고 조직의 일사불란함과 대기업적인 특징이 같이 유지되는 현상을 동적평형이 유지된다고 말하며, 지속적인 양방향 피드백이 필요하다."
이런 균형 상태의 유지는 '상전이(State Transition)'의 지점에서 특정 상태로의 이동 직전에 있는 상황으로 비유할 수 있습니다. 얼음도 아니고 물도 아닌 살얼음이 끼어 있는 상황이라고 할까요. 다시 말하면 스타트업의 창의적, 창발적 특성과 대규모 조직의 운영, 관리, 복제, 확장 등의 특징이 한쪽으로 치우지지 않고 유지되기 이해 동적평형이 필요한 것입니다. 서로 다른 구성원들 간의 팽팽한 줄다리기가 존재하는 현상이기도 합니다.
이번엔 'Tipping Point'의 관점에서 팀을 보겠습니다. 서두에 언급했듯이 티핑포인트 역시 균형점이 깨지고 특정한 상황으로 치닫는 순간 또는 지점을 이야기합니다. 조직의 관점에서 예를 들어 보겠습니다. 약 20명 정도가 모인 팀이라고 가정하고 이 팀 안에 2~3명의 강한 캐릭터를 가진 구성원들이 팀원들을 자신들이 원하는 방향으로 몰아가려고 합니다. 그러나 여전히 남은 17~18명의 구성원들은 영향을 받지 않습니다. 그러나 강한 캐릭터를 가진 팀 구성원의 숫자가 5~6명에 이를 때 전체 팀의 색깔이 완전히 변하게 된다고 가정한다면, 티핑포인트에 도달했다고 얘기할 수 있습니다.
특정 목적을 위해서 임의로 구성된 집단은 당연히 강한 캐릭터를 가진 몇 사람들에 의해서 분위기가 주도될 가능성이 높습니다. 분위기를 해치고 조직을 잘못된 방향으로 이끌 개연성이 큰 사람들의 캐릭터가 'Tipping Point'를 넘어서는 순간, 합리적 협업을 기대하기 힘들 것입니다. 소프트웨어 개발 프로젝트를 관리하는 입장에서 개발팀을 빌드업할 때 우리는 당연히 합리적이고 효율적인 협업을 하는 팀을 머릿속에 그리면서 구성원들을 선택하게 되겠지만, 우리의 선택이 조직을 잘못된 방향으로 끌어갈 사람들을 티핑 포인트 이상으로 선택하게 될 개연성도 배제할 수는 없습니다.
소프트웨어 개발팀은 다양한 기술셋을 가진 구성원들을 그 경험치에 따라서 적절한 배합으로 구성하게 됩니다. 팀의 규모는 해당 개발을 위한 대상 업무의 성격에 따라 달라질 것이고 규모가 매우 큰 업무를 애플리케이션으로 개발하는 프로젝트라면 몇 개의 소규모 팀으로 나누어질 것입니다. 만약 애자일 방식으로 팀을 구성한다면 여러 개의 스크럼팀이 Scrum of Scrum의 형태로 구성될 것입니다.
앞선 애자일 노트에서 언급했듯이 우리의 개발현장은 다양한 그룹으로 구성됩니다. 개발사업을 주관하는 IT 서비스 기업, 전문 솔루션을 제공하는 기업, 특정 업무에 정통한 기업, 프리랜서 그룹 등 다양한 구성체들이 공공 및 기업수요에 부응하고자 프로젝트팀을 빌드업합니다. 우리는 우리가 구성하는 개발팀이 최대의 효율성과 합리성을 발휘하는 팀이 되길 원합니다.
가장 중요한 의사결정을 해야 할 지점에 뛰어난 리더십을 가지고, 성공을 위해 같은 비전을 공유한 리더들을 티핑포인트를 채울 만큼의 숫자로 조직도에 배치하고,
요소요소의 핵심 영역을 기술적으로 감당하고, 동료 개발자들과 공감할 수 있는
기술 리더들을 배치하는 것,
누구의 업무라고 말하기 힘든 회색지대를 감당할 수 있는 Hustle Player들이 있는 것 등이 우리가 원하는 이상적인 'Team Build Up'의 형태가 될 것입니다.
기간과 비용이 정해진 프로젝트의 개발팀을 빌드업할 때 가장 주의해야 할 요소는 결국 팀의 구조를 어떻게 설계할 것인가 라는 질문에 명확한 답을 하는 것입니다.
가장 좋은 해결 방법은 IT 서비스 업계 전체가 좀 더 고도화된 산업구조를 갖는 형태로 변모하는 것이지만 개인 또는 기업의 힘만으로는 여전히 해결해야 할 과제들이 많은 것 같습니다. 미국 영화산업의 본거지인 헐리우드의 예를 들고 시사점을 찾아보겠습니다.
예전 헐리우드의 영화산업구조는 대형 스튜디오가 주도하는 시스템이었습니다. 큰 규모의 잘 통제된 기업처럼 움직였고, 중앙집권적 관리하에 자원의 효율적 배분, 합리적인 인력의 배치 등 나름의 장점을 가지고 오랫동안 헐리우드 영화산업의 주류 메커니즘으로 작동해 왔습니다.
1990년대 이후 이런 헐리우드 구조가 붕괴되기 시작했습니다. 기존 헐리우드 스튜디오와는 다른 독립적 영화기업들이 출현하고 새로운 영화 제작에 대한 요구가 있을 때, 즉각적으로 제작팀이 꾸려지는 'On- Demand' 형태의 영화산업 메커니즘이 본격화되었습니다. 각 분야의 전문인력들은 더 이상 특정한 소속회사를 갖지 않게 되었습니다. 그물처럼 짜인 헐리우드의 인적 네트워크는 전형적인 'On-Demand' 형태의 팀빌딩과 계약체계, 실행구조가 정착되었고 매우 성공적이라고 평가받고 있습니다.
즉, 헐리우드의 인적 네트워크망에서는 개인과 그룹의 평판 비즈니스가 거의 완벽하게 작동하고 있습니다.
'도날드 덕'이라는 촬영기사와 그가 소속된 촬영 그룹은 뛰어난 창의성을 가지고
영상을 만들어내며 기타 조명, 설치, 로케이션 등 타 팀/그룹과도 협업이 잘되기로
소문이 나있다.
평판 비즈니스가 완벽하게 작동할 경우 우리 업의 생태계가 좀 더 건강한 형태로 발전할 수 있는 가능성이 매우 높아질 것입니다. 대기업에서 중소업체 그리고 프리랜서 커뮤니티까지 함께 일하는 방식으로 생태계가 구성되는 있는 우리 업에서 조직 내부의 상호 피드백을 통한 발전적 균형유지 그리고 소수의 우수한 핵심인력들을 통한 효율적 팀 운영이 가능하려면 결국 조직 내부와 바깥의 생태계가 건강한 모습을 갖추고 있어야 한다는 것입니다.
평판 비즈니스가 제대로 작동하지 않는다면 팀빌딩을 위한 기본적인 선택지가 거의 없다고 봐야 할 것입니다. 우리가 선택하는 개인과 그룹이 선한 영향력을 가지고 있는지 악한 영향력을 가지고 있는지의 판단을 할 수 없다면 말입니다.
왜 평판 비즈니스가 제대로 작동하지 않는 것일까요? 우리가 속해 있는 산업 도메인 자체가 정체되어 있기 때문에 새로운 인력들을 수혈할만한 매력이 없는 것이 가장 큰 요인일 것입니다. 바꾸어 말하면 우리가 일하는 업계에 만약 10년 전 또는 그 이전의 사람들과 별로 바뀐 것이 없고 새로운 인물들의 출현도 극히 제한적인 상태에서는 서로의 평판을 점검할 생각조차 하지 않게 됩니다.
왜냐하면 서로에게 불리한 비즈니스 게임이 될 테니까요. 우린 그저 서로 돌아가면서 서로의 자리를 봐주며 품앗이하는 형태의 산업으로 전락하게 됩니다. 기업 조직 내부의 상황도 별반 다르지 않습니다. 기업 내부의 평판 비즈니스가 제대로 작동하지 않는다는 의미는 조직 내부의 구성원들이 함께 'Aging'화 되는 상황에서 인적자원의 변화가 매우 적으며 인력구조가 역삼각형이 되는 것을 의미합니다. 마찬가지로 평판의 의미 자체를 상실하게 되는 것입니다.
이야기를 풀어나가다 보니 IT 서비스 산업의 문제점에 대한 얘기들이 많이 언급되는 것 같습니다. 산업 구조적으로 선결되거나 또는 같이 고민되어야 할 문제가 많다는 의미로 해석하면 될 것 같습니다. 우리는 어쨌든 시장에서 조달 가능한 인적자원들과 내부의 자원들로 팀을 빌드해야 하는 현실이 바뀌는 건 아닐 테니까요.
IT 서비스 업계에서 수주형 소프트웨어 개발 프로젝트에 팀을 구성할 때 첫 번째 난관에 봉착하는 부분은 전체 팀 구성 인력 중 자사 인력 비율을 30% 가져가는 것도 힘들다는 사실입니다. 적게는 10%에서 많게는 30% 정도의 비율로 주관사업자가 제공하는 인력들이 팀을 이루게 됩니다. 프로젝트를 공동 주관하는 협력회사도 상황이 별반 다르지 않습니다. 그리고 프로젝트팀의 하부를 구성하는 하도급사들은 상황이 더 열악합니다.
원근 각지에서 모여드는 용사들로 빌드업된 팀이 원하는 기술셋과 경험치를 가지고 있을 리는 더욱 기대하기 힘든 상황일 겁니다. 우리는 오랜 기간 같이 일해온 동료들과 협업하는 게임이 아닌 특정 목적을 위해서 임시막사를 짓고 정해진 기간만큼 사용할 도구와 협업하는 방식과 문화를 만들어야 합니다. 생면부지의 사람들이 어느날 갑자기 모여서 일하는 곳에서는 일을 하는 구조와 필요에 의해 디자인된 협업방식이 필요합니다.
그렇게 디자인된 룰 안에서 다른 변주들이 의미가 있을 것이라고 판단됩니다. 우리가 관리 가능한 인력들, 즉 해당 인력들의 Technial Skill과 Soft Skill에 대해 잘 이해하고 있고, 예측 가능한 인력들을 중심으로 핵심 영역에 배치할 수 있는 인력구조는 우리 스스로 갖추어야 하고, 외부의 그룹과 프리랜서 커뮤니티를 활용할 수밖에 없는 입장에서는 어떻게 평판을 관리하고, 스크리닝 시스템을 갖추어야 할 것인지에 대한 답을 찾아야 할 것입니다. 비록 평판이 의미가 없어지는 상황일지라도 그렇습니다.
해당 업에서 오랜 기간 일한 경험치를 기반으로 어떻게 하면 좋은 개발팀을 꾸릴 수 있을까라는 짧은 글을 쓰고 싶었는데 스스로 더 혼란에 빠진 듯한 느낌이 많이 듭니다. 제가 속해서 일하는 업계가 그만큼 어렵다는 반증이기도 한 것 같습니다.
[이 글은 일반 기업체에 속한 IT 조직이 아닌, IT 서비스 업계 또는 SI 업계의 관점에서 쓴 글입니다.]
