팀 생산성 향상을 위한 패턴이야기

 데브피아 아키텍쳐 시삽 손영수

 (아키텍트로 가는 길 - http:/www.arload.net)

 

 

팀 생산성 향상을 위한 패턴이야기

생산성 향상은 과연 개발자 개개인의 능력에만 달려있는 문제일까요? 생산성 높은 툴, 언어, 프레임워크를 이용하는 것 이상으로, 팀플레이가 생산성에 미치는 영향력 역시 매우 큽니다. 생산적이고, 단결력 있는 팀을 만들기 위해선 어떻게 해야 할까요? 이 화두에 대한 전문가의 경험을 여러분과 함께 공유합니다.

손영수 indigoguru@gmail.com | 데브피아 Architecture 시삽과 Microsoft MVP로 활동 중이며, 데브피아 소프트웨어 공학 스터디인 Eva팀의 리더이다. 부족한 실력이지만 지식을 나눌 때는 누구보다 ‘부자’라는 자부심을 가지고 지식 나눔에 힘쓰고 있다. Pattern 전도사를 꿈꾸고 있으며, PLoP와 같은 Pattern 학회를 국내에 만들기 위해 힘 쏟고 있다.

 

팀 생산성 향상은 개발자 뿐만 아니라 프로젝트 관리자에게도 관심 있는 부분일 겁니다. 대부분의 패턴들은 소프트웨어 설계에 초점이 맞추어져 있습니다. 그러나 독특하게 조직구조와 협력을 위한 패턴들(“Capable, Productive and Satisfied : Patterns for Productivity”)이 PLOP 학회에서 발표 되었습니다. 여기서 소개되는 패턴들과 필자의 부족한 경험과 지식을 엮어 팀 생산성 향상을 위한 패턴 이야기를 풀어보고자 합니다.

첫 단추 잘 꿰기 (BOOTSTRAPPING)

시작부터 여러분에게 재미난 퀴즈를 내겠습니다. “프로젝트가 시작될 때, 가장 먼저 해야 되는 일은 무엇일까요?” 아마 대부분이 “팀 빌딩”이라고 대답하셨을 겁니다. 많은 프로젝트에서, 시스템의 물리적인 구성 (포털, DB, 분산서버, 디자인) 그대로 팀을 구성합니다. 당연하다고 생각하시는 분도 있겠지만,여기서부터 프로젝트의 첫 단추는 잘못 채워졌습니다.

Conway’s law (콘웨이의 법칙)

If you have four groups working on a compiler, you’ll get a 4-pass compiler

여러분이 하나의 컴파일러를 만들기 위해 4개의 팀을 만든다면, 여러분은 4단계(four-pass) 컴파일러를 얻게 될 것이다.

 

많은 프로젝트를 경험하신 분은, 위 법칙이 상당히 흥미로우실 겁니다. 당연히, 이미 팀이 구성된 후 요구사항을 분석한다면, 팀 구조에 맞춰 분석이 이루어지기 때문에, 팀 구조 그대로 소프트웨어 구조가 나올 수 밖에 없습니다. 소프트웨어의 특성을 파악하기도 이전에, 소프트웨어의 큰 구조를 정하는 우를 범한 것입니다. 만약 팀 구성 후, 어느 팀도 맡기 애매한 요구사항을 발견했다면, 이 사각지대를 서로 맡지 않기 위해 여러 가지 복합적인 일들(정치, 책임회피 등)이 발생하게 됩니다. 이 경우 종종 프로젝트가 산으로 올라가게 됩니다. 그야말로 길을 잃는 것이지요.

 

그럼 이런 복잡한 상태를 해결하기 위해서는 어떻게 해야 할까요? Conway는 해결책으로 Clean State (깨끗한 상태)를 제안했습니다.

 

Conway의 Clean State

Define the business mission (비지니스 미션을 정의해라)

Learn the business processes from business owners (비지니스 오너로부터 비지니스 프로세스를 배워라)

Re-engineer these business processes to fit the mission (미션에 맞게 비지니스 프로세스들을 합리적으로 재구성해라)

Structure the IT organization to support the reengineered business processes. (재구성된 비지니스 프로세스를 지원하기 위한 IT 조직을 구성해라)

 

Clean State의 요점은 팀을 구성하기 이전, 프로젝트의 도메인 전문가나 구성원 전체가 모여, 프로세스를 정제한 후에 프로세스에 맞게 IT 조직을 구성해야 된다는 것입니다. 이렇게 함으로써 책임의 사각지대가 발생하는 것을 예방하고, 선행되는 프로세스들을 파악할 수 있습니다. 이러한 정보를 기반으로 조직을 구성(땅콩버터와 마천루를 참고할 것) 해야 합니다.

마치 하나의 객체가 하나의 책임을 가지는 SRP 처럼, 책임의 소지가 명확해지는 형태로 책임을 개개인에게 나누는 것이 가장 중요합니다. 가능한 세분화해여 개개인에게 책임을 부여해야 하며, 그럴 수 없다면, 최소 필요인원이 팀을 이루어 개개인의 책임이 커지는 상태를 유지해야만 됩니다. 또한, 미션 크리티컬 (Mission Critical)하거나, 단일성이 중요시 여겨지는 일은 가능한 팀보다는 개인에게 맡기는 것이 오히려 낫습니다.

필자는 얼마 전 개발자 개개인에게 책임의 할당이 기능이 아닌 제품 통째인 팀을 만나는 재미난 경험을 했습니다.  Microsoft Visual Studio Team System의 각 Edition 별로 개발자가 1명, 많게는 3명 정도 밖에 되지 않았습니다. 개인의 책임이 제품 하나로 할당 형태로 팀이 구성되어 있다는 것은 어떻게 받아들여야 할까? 개발자에게 책임감을 최대한 부여하고, 능력을 온전히 믿는다는 것이다.

땅콩 버터와 마천루 (Peanut Butter and Skyscraper)

프로젝트 관리자는 팀의 구성이전에, 어플리케이션의 특성을 고려하여 땅콩버터나 마천루(적합한 프로세스)를 선택해야 합니다.

땅콩 버터는 “Feature들이 중심이 되어 소프트웨어를 만드는 Bottom-Up 방식의 프로세스”를 말합니다. Bottom-Up 프로세스는 기존의 비교 대상도 없고, 전혀 새로운 소프트웨어를 만들 때 주로 사용하는 방법입니다.

 

이 방식은 견고하고, 더디지만 모든 Feature들이 골고루 기능 향상을 가져올 수 있는 장점이 있습니다. 마치 땅콩 버터 (Peanut Butter) 처럼 모든 기능들이 골고루 퍼지고 진화할 수 있어서 땅콩 버터 방식이라고 말합니다. 흔히 하위 레벨의 Framework이나 저 수준의 Library를 개발할 때는 이러한 방식이 선호됩니다.  만약 여러분의 소프트웨어가 고객의 요구사항들을 많이 받아 들여야 하고, 다양한 시나리오를 요구하는 경우인데도, Feature 에 초점을 맞춘 땅콩버터 식의 프로세스와 조직을 구성하게 되면 어떻게 될까요? 위에서 언급한 것과 같이 새로운 시나리오가 탄생하면 많은 조직들이 협업을 해야 될 뿐 만 아니라, 딱 기능을 나누기에 애매한 경우 많은 정치, 책임의 분배 문제 등이 발생됩니다.

이와 상반된 방식으로 마천루 (Skyscraper) 방식이 있습니다. 시나리오가 마천루처럼 높이 솟아 전체 소프트웨어의 기능을 구현하기 위한 좋은 기준이 된다는 것입니다. 명백한 기준이 있다는 것은 많은 시행착오를 줄일 수 있을 뿐만 아니라, 고객의 관점에서 소프트웨어를 생각할 수 있는 장점을 가질 수 있습니다. 흔히 우리가 알고 있는 시나리오를 만들고 Prototype 방식으로 개발을 해 나가는 것이라고 생각하시면 됩니다. 바로 Top-Down 방식의 프로세스가 여기에 해당되는데요.

여러분의 소프트웨어가 상위 레벨의 응용 소프트웨어로써, 많은 분들에 의해 사용한다면 당연히 시나리오 기반(Skyscraper)의 방식으로 소프트웨어를 설계하는 것이 좋을 것입니다.

역시 이 방식도 단점이 있는데, 시나리오 기준으로 하다 보니 소프트웨어가 잘 정리된 일괄적인 구조로 설계 되기 어렵고, 특정 Feature들이 먼저 개발되는 급성장으로 인해 전제 모듈간의 불균형을 야기시킬 수 있습니다. 그리고 갑자기 시나리오가 수정된다면, 이것이 소프트웨어 구조에 많은 영향을 미치게 됩니다. 바로 땅콩버터가 언급하는 점진적이면서 균형 있는 발전이라는 장점을 잃어버리게 됩니다.

그럼 둘 다 장,단점이 있는데 ,단점을 상쇄 시키고 장점을 얻을려면 어떻게 해야 될까요? 정답은..이것들을 적절히 혼용하는 것입니다.

Milestone 형태와 같이, 초기 단계는 땅콩버터 방식을 기반으로 Infra를 구축하는데 초첨을 맞추고, Infra가 구축된 후부터는 땅콩 버터 (기본적인 기능부터 구현해서 점진적으로 기능을 추가) 방식을 유지하되, 릴리즈가 거듭될 때마다 더불어 사용 가능한 시나리오들을 점진적으로 증가시켜 테스트하는 방식이 좋은 예가 될 것입니다.

물론 이런 복합 프로세스들을 적용하기 위해서는, 잘 정의된 계획과 매 릴리즈(Milestone)가 끝난 후, 회고를 하고 그 다음 릴리즈를 준비하고 새롭게 시나리오에 적합한 팀을 구성하는 유연함(Milestone Quality)을 가진 조직문화가 필요할 것입니다.

적재 적소에 팀원 배치하기 (ROUND PEGS FOR ROUND HOLES)

개인의 선호도, 능력을 고려하여 적재 적소에 개발자를 배치하지 않으면, 시간 낭비와 개인과 팀 전체에 나쁜 영향을 미치게 됩니다. 많은 관리자들은 개발자들을 교체 가능한 단위로 봅니다. 하지만 절대 그렇지 않습니다. 사람은 자신이 가장 최고로 잘할 수 있는 일을 할 때, 가장 높은 생산성을 내는 것은 당연합니다. 먼저 관리자는 개발자의 선호도나, 성격 등을 파악하는 일이 중요합니다.

어떤 개발자는 작은 작업들을 아주 빨리 처리하는 것을 좋아하는 사람도 있는 반면에, 시간이 오래 걸리더라도 품질을 검증하고 완벽함을 기하는 성격을 가진 사람도 있습니다. 이러한 것은 단순히 이력서나 면접에서 볼 수 없는 개발자 개개인의 고유의 성격입니다. 그리고 기술 선호도도 다양합니다. 하위의 Kernel단이나 Middleware를 선호하는 개발자도 있고, 사용자가 매우 편하게 사용할 수 있는 UX 기술에 관심이 많은 개발자도 있습니다. 그러므로 개인의 작업 방식, 기술 선호도 등을 발견하고, 잘 고려하여 구축하고자 하는 시스템의 구조적인 레이어나 기술에 할당하는 것이 매우 중요합니다. 물론 모든 개발자들이 시스템의 구조나 기술들에 매칭되지 않을 수도 있습니다. 부족한 부분들은 아웃소싱으로 보완하여, 팀 내의 개발자가 제자리를 찾을 때, 드디어 합리적인 데드라인을 예측하고, 생산적인 리듬을 유지할 수 있습니다.

분할 후 정복 (Project Pulse ? 높은 생산성을 유지해라!)

등산을 가 보신적이 있습니까? 몇 번 올라간 익숙한 산과 처음 올라가는 산은 매우 느낌이 다릅니다. 몇 번 올라간 산은 어디에 약수터가 있고, 경치가 좋은 장소가 있는지 다 알기 때문에 그야말로, 즐기면서 갈수가 있습니다. 하지만 처음 오르는 산은 정상이 얼마나 가야 되는지 몰라 산을 내려오는 사람에게 이런 질문을 자주 합니다. “정상에 갈려면 얼마나 가야 되나요?” 그럼 내려오시는 분은 우스개로 “요 고개만 넘으면 되요”라고 말합니다. 그럼 힘이 나죠. “이 고개만 넘으면 되는 거구나!” 하지만 고개를 넘은 후 그것이 거짓말인 것을 압니다. 아직 정상이 보이지 않기 때문이죠. “왜 이런 거짓말을 하지?”라고 처음엔 이해를 못했지만, 나중에 알게 됩니다. 만약 그 때 하행하는 사람이 “앞으로 3시간 정도 더 가야 되요” 라고 말했다면, 과연 그 산을 오를 수가 있었을까요?

너무나 큰 장기적인 목표는 팀원들을 지치게 만듭니다. 장기적인 목표를 단기적인 목표로 나누어 팀원들에게 목적의식과 방향성을 제시해야 합니다. 굳이 개발자 스타일로 말하자면 분할 후 정복 (Divide and Conquer)이겠군요.

마일스톤 방식

실제 Microsoft 같은 경우는 위 그림처럼 프로젝트 진행 시, 수많은 목표를 세부적인 목표인 작은 Milestone으로 나눕니다. 물론 Milestone이 가져오는 장점은 여러 가지가 있지만, 팀원들이 구체적인 목표에 집중할 수 있는 방향성과 동기를 제공하게 됩니다. 그리고 개발자들이 이 Milestone에 집중해서 문제를 완벽히 이해하고 해결하기 위한 문제 공간을 만들어, 거기에 집중할 수 있도록 끊임없이 독려해야 합니다. 물론 생산성을 높일 수 있는 문제공간에 참여할 수 있게 특별한 보상체제를 만들어야 합니다. 그러면 자연스럽게 개발자들은 협력하게 되고, 서로의 부족함을 채워 생산성을 향상시킬 수 있습니다. 그리고 생산성의 리듬이 끊어지는 주된 원인인 새로운 개발이나 다른 업무를 지금하고 있는 Milestone이 끝나기 전에 할당해서는 안됩니다. 사람이 하나의 목적을 가지고 정진할 때 가장 높은 생산성이 나는 것 당연한 일입니다.

하나의 Milestone이 종료되면, 바로 다음 Milestone에 들어가지 않고, 회고와 함께 그 다음 Milestone에 들어가기 위한 준비작업을 해야 합니다. 회고를 통해 서로간에 부족한 점을 되짚고, 생산성 게임에 승리한 사람에게는 적절한 보상과 함께, 약간의 휴식, 팀 재정비, 개발 환경 셋팅, 요구사항이나 피드백으로 인한 변경사항을 체크하고 방향을 재 설정함으로써, 다음 Milestone 역시 높은 생산성을 낼 수 있게 준비하는 단계가 필요합니다.

생산성에 대한 보상에 대한 기준 확립도 매우 중요합니다. 합리적인 기준 없이, 야근을 많이 하는 사람이나, 기술적인 난이도를 고려하지 않은 채 단지 모듈이나 컴포넌트 개수로 보상(고과, 물질적 등)을 준다면, 팀원들은 흥미를 잃고 공정성에 대한 회의를 느끼며 심한 경우 팀을 떠날 수도 있습니다. 필자는 이런 경우를 여러 번 보아왔습니다. 비젼과 목표 그리고 합리적인 보상, 이 중 어느 것도 제시하지 못하는 프로젝트라면, 생산성은 고사하고 팀원들이 하나 둘 사라지는 블랙홀현상을 대면할 준비를 해야 될 겁니다.

단결력 있는 팀 (Cohesive Team)

인생처럼 소프트웨어 프로젝트는 끊임없는 문제들의 연속이라고 할 수 있습니다. 먼저 고객의 요구 사항을 파악하고, 이 요구사항을을 해결하기 위한 제정적, 인원적, 문화적 제약 사항들을 찾아내고, 답을 찾아내고 범위를 설정하는 것 등 다양한 문제를 만나게 됩니다.  프로젝트 초기부터 이러한 문제들을 몇몇 숙련된 개발자나 아키텍트들 만의 숙제가 아닌 팀원 모두의 문제로 이끌어내는 것이 중요합니다. 이것은 프로젝트가 시작되는 초기부터 적용되어야 할 가치입니다.

프로젝트에 대한 전반적인 이해 없이 목표를 상실한 채, 상명하복의 일방적인 명령 전달방식으로 진행되는 프로젝트의 개발자에게는 높은 생산성을 기대하기 힘듭니다. 요구사항을 다 같이 이해하고, 팀의 자원적 한계, 특정 도메인 지식을 공유하여 왜 이렇게 소프트웨어 아키텍쳐가 나왔는지 팀원들 전체가 이해해야 하며, 더 나은 방법이 있는지 이야기하는 시간을 가져야 합니다. 이러한 문제 공간(Problem Space)에 끊임없이 팀원들을 참여시키고 흥미를 가질 수 있게 자극한다면 팀의 응집력은 자연스럽게 증대됩니다.

 

팀원들을 문제 공간(Problem Space)에 적극적으로 참여하기 위해서는, 실제 사용자들과 팀원들이 대화를 하게 하십시오.

예) 요구 사항을 파악하기 위해, 직접 방문하여 직접 업무를 파악하게 하고, 언제든지 커뮤니케이션 할 수 있도록 하는 것이 중요합니다. 예를 들어 회사의 전산 시스템을 자동화하는 경우 회계를 담당하는 팀원들은 회계 부서와 물류 관련 팀원들은 물류 부서를 만나게 하여, 서로 쉽게 대화할 수 있게 분위기를 조성해 주는 것이 중요합니다.

가끔씩 현장 방문을 통해, 팀원들이 시스템이 가지고 있는 도메인 특성이나 문화를 경험하게 하십쇼.

예) 만약 섬유 회사를 전산화 한다면, 컴퓨터 언어만 아는 개발자가 정말 고객이 요구하는 시스템을 만들어 줄 수 있을까요? 작태, 나염의 정의도 모르면서 섬유회사의 업무를 전산화하기는 불가능합니다. 직접 고객을 방문해서 몇 일간 관련 업무를 해봄으로써 회사의 상황을 파악하는 것이 좋습니다. 실제 필자는 섬유회사에서 일주일 정도 팀들과 어울려 주문부터, 기계가 돌아가는 모습, 창고 관리까지 전체 프로세스를 느껴보고 관련 문서를 수집함으로써, 회사의 흐름을 파악 한적이 있습니다.

잠자고 있는 도메인 전문가(Project Sponsor)를 찾아서 대화해라.

예) 도메인 전문가를 찾아 도움을 청해야 합니다. 전문가라고 하니 거창하지만, 그 분야에 작년에 은퇴한 사람을 만나거나, 그 분야에 종사하는 지인들을 찾아가는 것도 좋은 방법입니다.  많은 질문과 대화를 통해 요구사항을 파악하고, 도메인 지식을 쌓고, 애매모호한 용어들이나 개념들을 명확하게 만들 수 있습니다. 이것으로 팀원들이 동기부여를 할 수 있는 좋은 계기가 됩니다.

문제 공간(Problem Space)에서 중요한 결정사항 등을 검증하고 공유하십시오.

 

숨어있는 잠재력에 주목해라! (Production Potential)

프로젝트 초기에 팀원들이 많은 대화와 어떠한 일들을 하고 있음에도 불구하고, 이상하게 진도가 잘 나가지 않는 것 같아 보일 때가 있습니다. 프로젝트 디렉토리 안에 소스 코드들이 며칠 동안 전혀 변화가 없는 게 아니겠습니까? “과연 개발자는 뭘 하고 있는 거지? 10달 중에 2달이 지났으면 이미 2/10은 완성되어야 되는 것 아닌가?”하며 초조해 하기도 합니다.

프로젝트는 끊임없는 문제의 이해와 학습으로 인해 만들어 집니다. 특히 프로젝트 초기에는 산출물들(클래스, 디자인, Micro Architecture)로 진척도를 판단해서는 안됩니다. 그리고 초기에 이러한 산출물들이 버려져도 놀랄 필요가 없습니다. 이것은 문제 이해도 높아졌고, 프로젝트 메커니즘이 좀더 명확해졌음을 의미합니다. 역으로 프로젝트 후반에 잘못된 설계와 메커니즘이 발견 되었을 때의 여파를 생각해 보시길 바랍니다.

그러므로 결과물 외에도, 다양한 측면에서 여러 가지 행위들에 적정한 가중치를 두어 팀의 진척도를 측정해야 합니다. 예를 들어 소스코드, 설계, 아키텍쳐, 문서들과 같이 눈에 보이는 것 못지 않게 팀원들이 가지는 프로젝트의 자신감, 이해도, 툴과 언어의 익숙함 등과 같이 눈에 보이지 않는 것 역시 중요합니다. 이러한 잠재적인 요소들을 생산 잠재력이라고 하며, 이 생산 잠재력을 어떻게 활성화시키고 끌어내느냐에 따라, 소프트웨어 생산성에 크게 영향을 미칩니다.

이러한 잠재력을 이끌어내기 위해선, 피그말리온(Pygmalion) 효과를 이용하는 것입니다. 그리스 신화에 나오는 애기로, 조각가 피그말리온은 자신의 눈에 비친 여인들이 모두 결점투성이라고 생각하고 평생 독신을 고집했습니다. 어느 날 그는 상아로 아름다운 여인의 모습을 조각했는데 그 아름다움에 빠져 신들에게 조각상을 자신의 아내로 만들어달라고 기도했고, 그의 사랑에 감동한 아프로디테 여신이 그의 소원을 들어주었습니다. 이후 간절한 기대가 현실에 반영되는 것을 설명하는 것으로 칭찬과 자신감을 일으켜 주어 팀원들을 이끌어 내는 방법입니다. 관리자가 자신에게 높은 기대를 갖고 있다고 생각하면, 그 기대에 부응하기 위해 향상된 성과를 만들게 됩니다.

그리고 팀이나 부서별 집단 보상과 팀 별 게임 (여러 팀들이 골고루 1등을 경험할 수 있는 단합게임)과 같은 이벤트를 열어 팀 활성화를 촉진해야 합니다.

이 외에 프로젝트 중반에, 특정 부분에 집중적으로 오류가 반복 발생하는 하거나, 미처 예측하지 못한 반복적인 작업으로 시간이 많이 걸려 프로젝트 진척 율에 영향을 미치는 경우가 있습니다. 이것 또한 생산성을 악화시키는 요소입니다. 버그를 계속해서 고치는 악순환을 끝내기 위해 관련 담당자들을 모아 문제를 점검하고 에러를 쉽게 걸러낼 수 있게 클래스를 재 설계하거나, 자동화를 통해 생산성의 리듬이 최상이 유지 될 수 있게 해야 합니다.

 

인수 인계는 이렇게! (EFFECTIVE HANDOVER)

프로젝트 도중 누군가 팀을 떠난다면, 어떻게 하시겠습니까? 퇴직하는 경우도 있지만, 갑작스러운 병가나 사고, 그리고 조직 개편 등으로 흔히 일어나는 일입니다. 이처럼 인수인계는 프로젝트에서 빈번하게 발생하는 일입니다. 인수 인계를 한다는 것은 어플리케이션의 도메인, 아키텍쳐에 대한 지식, 프로젝트의 역사 등을 다 전달해야 된다는 의미입니다. 만약 몇 년에 걸친 장기 프로젝트라면, 실로 그 지식은 방대하게 됩니다.

생산성에 미치는 악영향을 최소화 하기 위해서는 떠나는 개발자가 미 완료한 일, 버그, 문서 작업을 빨리 진행할 수 있도록 다른 일을 시켜서 흐름을 끊어서는 안됩니다. 그리고 인수 인계는 새로운 사람에게 시키는 것 보다는 같은 일을 해왔던 팀 동료나 팀원들에게 분배 하는 것이 가장 바람직합니다. 이러한 것들을 대비해 틈틈히 문서와 산출물을 점검하고, 주기적인 지식 공유(문제 공간에 몰두하게 함)를 할 수 있게 만들어야 합니다.

그리고 신규 팀원은 프로젝트의 역사나 도메인의 지식 등이 부족하기 때문에, 바로 어떠한 일을 맡아서 하는 것보다는, 코드 리펙토링(Code Refactoring), 설계와 사용자에게 제공하는 문서 업데이트, Test Script 작성과 테스팅을 시킴으로써 전체 프로젝트의 흐름을 파악하고, 프로젝트에 당장 직접적인 도움을 줄 수 있는 일을 맡기는 것이 바람직합니다. 그 후 적재 적소에 팀원 배치하기(ROUND PEGS FOR ROUND HOLES)를 통해서 적합한 일을 배치하면 됩니다.

 

 

 

공간 확보의 중요성 (Team Space & Arranging Furniture)

생산성을 증대시키기 위해선, 팀만의 고유한 색깔을 유지할 수 있는 여러가지 장치를 만드는 것이 중요합니다. 그 중에 가장 중요한 것이 팀만의 공간(Team Space)입니다.

팀원들이 모여 자유롭게 이야기를 할 수 있는 공간이 없다면, 단결력 있는 팀 문화나 문제공간(Problem Space)을 만들지 못할 뿐만 아니라, 근무 중 잠시 쉴 곳이 없어, 그들만의 공간을 찾아 회사 밖으로 나 갈수도 있습니다. 그리고 대화의 단절이 발생해 중복된 코드를 여러 명이 개발할 수도 있으며, 심하면 팀의 파벌과 정치적 요소가 등장할 수도 있습니다. 그러므로 휴식을 취할 수 있는 편안함과 단결력을 높이기 위한 팀만의 색깔이 있는 공간이 필요합니다.

 

문제공간(Problem Space)에 모든 팀원이 집중할 수 있는 공동 공간의 창출은 팀플레이의 가장 기반이 되는 요소 입니다. 그리고 업무와 연관성이 깊은 사람끼리, 가까운 곳에 자리를 배치해 언제든지 조그만 미니회의나 Pair 프로그래밍, 리펙토링이 가능할 수 있는 문화를 만들어야 합니다.

 

위와는 역으로 팀원 개개인이 자기만의 영역을 구축할 수 있도록 만들어 주어야 합니다. 고양이 같은 경우는 주위에 있는 나무, 수풀, 담, 문 등 주위 환경을 탐사한 후, 자신만의 영역을 표시한 후 쉰다고 합니다. 하물며 개발자는 그 누구보다 보다 자신만의 영역을 중요시 생각합니다. 다른 산업과 달리 소프트웨어 자원은 개발자 머리 안에 있으며, 이것을 추출하는 작업은 매우 높은 집중력을 요구하는 작업입니다.

 

“Rapid Development” 에서 언급한 것과 같이 문제에 완벽하게 몰두하는 작용을 촉진하는 Flow State(흐름 상태)에 진입하기 위해서는 15분 이상의 시간이 필요합니다. 하지만 국내 대다수의 개발자들은 정신적인 작업의 중요성을 무시 당한 채, 상사의 관리의 용이성이나 영업 또는 고객의 요구에 빠른 대응을 위해 낮은 칸막이와 소음이 심한 최악의 환경에서 일하고 있습니다.

믿기 어려우시겠지만, 개발자는 책상도 꾸미고, 화초도 키우는 것을 넘어서 Debugging 툴로 인형을 사용하기도 합니다. 개인 공간 존중은 개발자가 만들어내는 산출물(코드, 설계)의 생산성에 큰 영향을 미칩니다.

좋은 예로 IBM의 산타 테레사 사무실은 개인 공간과 사무실 환경의 개선을 통해 11% 정도의 생산성이 증가 효과를 얻었습니다.

집중력이 향상 될 수 있는 조용한 환경 제공과 더불어, 개개인의 코드가 성능에 나쁜 영향을 미치거나 Code Convention을 어기지 않는 한 개발자 스타일 을 존중함으로써 (적재 적소에 팀원 배치하기 패턴)을 동시에 적용함으로써 더욱 높은 생산성의 향상을 가져 올 수 있습니다.

 

맺음

어느 분야든 마찬가지지만, 특히 소프트웨어 분야에선 가장 중요한 것은 사람입니다. 이 글에서 소개된 패턴들이 결코 팀 생산성의 완벽한 해답은 될 수 없지만, 프로젝트 관리자가 조금이나마 “주먹구구식 관리”를 떠나 “소프트웨어 특성과 팀원을 이해하는 관리”의 시작이 되길 바랍니다. 그리고 열악한 환경에서도 데드라인의 맞추기 위해, 묵묵히 일하고 있는 개발자 여러분들에게 고개를 숙이며 글을 맺습니다.

참고 자료

Paul Taylor et al, “Capable, Productive and Satisfied : Patterns for Productivity”, PLOP 98

Steve McConnell , “Rapid Development”, Microsoft Press

김병전, “숨겨진 잠재 능력 끌어내기” , 매경이코노미 제 1464호

Kryzysztof Cwalina, “Framework Engineering”, Microsoft TechED