애자일 팀 모델에 대하여

애자일 팀 발전 모델에 대하여

Functional team, Product Team, Feature Team

조대협 (http://bcho.tistory.com)

 

개요

 

관리자(CTO)역할을 맏으면서 가장 고민중에 있는 것 중 하나는 팀을 어떻게 모델하여 최적화된 개발팀 구조를 가지느냐 이다.

근래의 개발팀의 모델은 애자일 사상에 영향을 받아서 작고, 독립적인 팀의 모델로 진화하고 있으며 대략적인 특징은 다음과 같다.

·             Self organized

·             Cross functional

·             2 pizza team

Cross functional 모델은, 하나의 팀 내에서 기획부터 디자인,개발 및 테스트를 모두 진행할 수 있는 팀 모델로 팀 안에 앱,프론트,백앤드 개발, 기획,테스터와 같은 모든 역할을 하나의 팀내에 모두 가지고 모델이다. 이런 모델을 기반을 Self organized라는 팀 모델을 가질 수 있는데, 이는 팀내의 모든 기능 유닛들이 다 있기 때문에 팀이 독립적으로 제품에 대한 기획에서 부터 개발 및 출시가 가능하게 되는 모델이다. 이러한 팀 모델은 원할한 커뮤니케이션을 전제로 하기 때문에 팀의 구조가 커지면 원할한 커뮤니케이션이 어려운 이유로 팀의 규모는 두개의 피자를 먹을 수 있는 정도의 팀구조 즉 7~8명 정도의 2 pizza team 정도의 구조를 가지게 된다

 

팀 모델과 더불어 이러한 모델을 효과적으로 적용할 수 있는 Devops와 같은 서비스 운영 모델이나, MSA (Micro Service Architecture)와 같은 아키텍쳐 모델이 발전되고 있다. 이 부분은 오늘 다루고자 하는 부분이외의 부분이기 때문에 넘어가도록 한다.

 

이렇게 Cross functional team model로 이동을 함에 있어서도 몇가지 문제들이 발생하는데, 이러한 문제를 해결하기 위한 다음 모델이 Featured team model 이다. 이 글에서는 전통적인 functional team model에서 부터, 현대 애자일이나 MSA와 함께 대두 되고 있는 Component based team model 그리고 최근에 소개되고 있는 Featured team model에 대해서 알아보고자 한다.

 

이해를 돕기 위해서 아래와 같은 일반적인 앱/웹 서비스를 예를 들어서, 이러한 서비스를 개발하기 위한 각 팀모델에 대해서 설명하도록 하겠다.

“이 서비스는 뉴스에 대한 포스팅과 함께 포스팅에 대한 댓글 기능을 제공하는 서비스이고,

모바일앱과 HTML 웹 페이지를 이용하여 사용자에게 서비스를 제공하고,

운영 시스템으로는 관리도구를 이용하여 댓글과 포스팅을 관리할 수 있다.”

 

Functional vs Cross functional team

이러한 팀 모델을 이해하기 위해서는 Functional team model과 Cross functional team model에 대해서 먼저 이해할 필요가 있다.

 

Functional team

먼저Functional team 모델은 가장 흔하게 존재하는 팀 모델중의 하나로, 개발 기술이나 역할 별로 팀을 나누는 방식이다. 예를 들어 프론트앤드 웹 개발, 앱 개발, 백앤드 개발, QA, 운영팀등으로 나눠서 팀을 관리하는 방식이다.

이 팀 모델을 앞에서 언급한 서비스에 적용하게 되면 다음과 같은 팀 모델이 나오게 된다.

 

이 모델의 장점은 기술을 각팀이 잘 통제하여 각 레이어(계층)별로 일관된 아키텍쳐와 기술 통제 모델을 가지고 갈 수 있지만, 일종의 풀(Pool)모델 처럼 각 기능이나 제품을 개발할때 마다 개발자를 그때 그때 마다 순환 배치하기 때문에 제품(프로덕트)에 대한 일관성을 가지고 가기가 힘들고, 각팀간의 인터페이스를 맞추기 위해서 커뮤니케이션 작업이 추가로 많이 소요된다.

 

Cross functional team

그래서 이러한 기술 중심의 Functional team 모델에서 발전한 것이 근래에 유행하고 있는 Cross functional team 모델이다.

Cross functional team 모델은 앞에서도 언급하였지만, 하나의 팀 안에서 기획에서 부터 프론트앤드, 앱, 백앤드 개발, 테스트 및 운영까지 모두 할 수 있는 조직 모델이다.

 

Component Team & Featured Team in Cross functional team model

Cross functional 팀은 모든 기능(역할)구조를 가지고 있는 구조라는 기본을 가지고 있는데, 이를 세부적으로 살펴보면 크게 Component team (Product Team)과 Featured team 이라는 두가지 모델로 나눠볼 수 있다.

 

근래에 가장 많이 언급되는 Cross functional team model은 component team (product team) 모델이다. 모든 역할을 가지고 있는 하나의 팀이 하나의 제품을 맞는 형태이다. 앞서 언급한 서비스 예제에 맞추어 보면 다음과 같은 구조를 따르게 된다.

 

 

특히나 근래에 마이크로 서비스 아키텍쳐 (aka. MSA)와 함께 가장 많이 언급되는 모델로, 하나의 팀이 하나의 제품을 장기간 맏아서 진행하는 형태이다.  이 경우 기획에서 부터 운영 및 기술 셋까지 완벽하게 독립적으로 운영할 수 있기 때문에, 독립성이 매우 뛰어나서 기동성이 나올 수 있기 때문에 이론적으로는 참 이상적이다.

 

이상적이기는 하지만 이 모델에는 단점이 존재하는데, 일반적으로 하나의 서비스는 하나의 제품이로만 구성되지 않으며, 서비스를 구성하는 제품간에는 유기적인 연동이 반드시 필요하다는 것이다.

위의 예를 들어보면 새로운 댓글 기능이 들어간다고 가정했을때, 이 댓글 기능은 단순히 앱 개발팀이 혼자 단독적으로 수행할 수 있는 것이 아니라, 웹 개발팀도 댓글을 개발해야 하고, 관리도구 개발팀도 이 댓글을 관리 하는 지원 시스템을 개발해야 한다.

그러면 댓글이란 기능을 개발하려면 요구 사항이 3개의 팀으로 전파되어야 하고, 이 3개의 팀의 연계 아키텍쳐가 같이 설계되어야 한다.

즉 단일 요구 사항을 분석하고, 아키텍트가 기능에 대한 전체 컴포넌트에 대한 큰 설계를 마무리 한후 각 프로덕트팀으로 설계를 내려 보내서 개발을 진행해야 한다.

<그림. Component(Product) 기반 개발팀의 개발 프로세스 >

출처 : http://www.featureteams.org/feature_team_primer12.pdf

 

실제로 필자가 몇년전에 운영했던 팀운용 방식인데, 여러 프로덕트팀을 조율하는 Chief 아키텍트의 역할이 필요하고, 또한 각 팀의 개발 역량이나 개발 분량이 다르기 때문에 개발 스케쥴이 서로 맞지 않는 일이 발생하고 결국에는 이를 조율하기 위한 Program manager와 같은 역할이 필요하다.

 

새로운 팀에서도 이러한 방식의 팀 모델링을 하려고 시도를 했으나 벽에 부딪혔다. 기획이 각 기능 단위로 나오기 때문에, 각각의 프로덕트 오너(기획자)를 팀마다 묶을 수 도 없었을 뿐더러, 그렇게 팀을 나누기에 팀의 크기에 팀원간의 역량에도 차이가 있었다.

할 수 없이 전통적인 Functional Team 모델을 사용하면서 운용을 하면서 적절한 팀 모델을 찾기 시작했다. http://bcho.tistory.com/1040

 키는 기능 단위의 팀 모델을 찾았는데, Feature Driven Development (FDD)와 같은 개발 방법론을 찾았으나, 실용적인 개발팀 모델은 찾지는 못했고, 어설프게나마 기능 우선의 개발팀 모델이 필요하다는 것을 느끼고 팀구조를 그렇게 차차 전환하던중에, Craig Larman과 Bas Vode가 작성한 “Feature Team Primer” 라는 문서를 찾게 되었다. http://www.featureteams.org/feature_team_primer12.pdf

 

잠깐 옆으로 빠지자면, Craig Larman을 처음 접한것은 1996년 Applying UML 이라는 책을 접하면서였다. 그 당시만 해도 UML에 대한 서적들은 대부분 UML에 대한 Notation이나 다이어그래밍 방법에 포커스가 맞춰져 있었을뿐, 요구 사항에서 부터 UML기반의 잘 정리된 설계 문서까지를 만들어내는 프로세스나 실용적인 방법론이 없었기 때문에 나름 상당히 감명을 받고 읽은 책이었는데, 2010년대에, 큰 조직에서 일을 하면서 애자일 방법론을 엔터프라이즈 레벨까지 확장하고 싶다고 생각하면서 찾았던것이 Enterprise Agile 방법론이나 Scaled Agile 방법론이었는데, 그러던중에 “Scaled Lean & Agile Development” 라는 책에서 또 다시 Craig Larman을 만나게 되었다.

변함없이 실용적인 내용을 담고 있었고, 그 나이에도 그러한 안목과 실용성을 잃지 않는다는게 대단하다고 느끼게 하는 분이다.

그리고 이 “Feature team primer”의 공동 저작자인 Bas Vode는 Odd-e라는 애자일 컨설팅 회사의 컨설턴트로, 국내에서 일년에 몇번 애자일 교육을 여는 분인데, 팀원들에게 애자일 스크럼 공인 자격증을 받게 하기 위해서 교육 프로그램을 찾던중에 접하게 되었다. 노키아 애자일 방법론등에 영향을 줬고, Craig Larman과 이 문서를 만들었는데, 국내에 2015년 9월달에 교육이 있었고, 오프모임까지 있었지만 (신청해놓고 못나갔다.) 못 만난게 아쉽다. 30분이라도 이야기할 시간이 있었다면 아마도 또 다른 배움이 있지 않았을까?

 

다시 본론으로 돌아와서, 이러한 제품 기반의 Cross functional team의 문제점을 해결하고자 제안된 방법론이 Feature Team 모델이다. 이 모델은 Cross functional team을 조직하고, 이 팀이 제품(프로덕트) 단위가 아니라 기능 단위로 여러 프로덕트에 걸쳐서 개발을 진행하는 모델이다.

 

이 팀 모델을 앞에서 제시한 예시 서비스에 대입해보면 위와 같은 그림이 된다.

각팀에는 기획, 프론트,백앤드,앱,QA등의 모든 역할의 사람이 들어가 있고, 각 팀은 댓글이나 포스팅과 같은 기능 단위로 전체 컴포넌트(프로덕트)에 걸쳐서 개발을 진행한다.

 

지금까지 생각에는 이게 조금 더 실리적인 방법이 아닌가 하는 결론에는 도달해 있으나, 이 Feature team 모델 역시 많은 단점과 제약 사항을 가지고 있다. 예를 들어 백앤드 개발자는 전체 백앤드에 기능을 녹여놔야 하기 때문에, 전체 백앤드의 구조를 모두 알고 있어야 한다. 프론트앤드도 웹과 관리도구에 대한 프론트엔드 개발을 해야 하기 때문에, 전체를 다 알아야 한다. 즉 개인 개발자나 기획자가 커버해야 하는 영역이 늘어나고, 손대야 하는 코드가 많아지기 때문에, 코드를 개발한 후 머지도 여러 컴포넌트에 걸쳐서 해야 하고, 손이 많이 가지만 하나의 서비스 기능에 대해서 일관성을 가질 수 있는 장점은 있다.

또 다른 문제로는 중앙 통제적으로 아키텍쳐를 드라이브하지 않기 때문에 기능별로 각각의 변종 아키텍쳐가 생겨날 수 있는 문제가 생기고 결국은 기술에 대한 통제 (Technology governance)문제가 발생한다.

 

기술적으로 한명의 엔지니어가 전체 영역을 이해하고, 거기에 각각 코드를 넣기 위해서는 많은 시간이 필요한데, 이를 줄이려면, 새로운 기능을 넣는 컴포넌트(프로덕트)가 새로운 기능을 붙이기에 잘되어 있다면 가능하다. 여기서 프레임웍과 플랫폼에 대한 니즈(needs)가 발생하는데, 새로운 기능을 쉽게 꼽아 넣을 수 있는 형태로 시스템이 개발되어 있으면 된다. 새로운 API를 넣기 위해서는 Spring REST + JPA를 레퍼런스에 따라서 개발을 쉽게할 수 있고, DB 정규화 없이도 탄력적으로 DB모델링을 할 수 있는 Document based NoSQL (eg. MongoDB, CouchBase etc)들로 잘 구성되어 있으며 가이드가 잘되어 있다면, 새로운 기능을 기존 컴포넌트에 추가하는데 크게 문제가 없다. 즉 Feature team 모델을 운영하려면, 시스템 아키텍쳐가 쉽게 이해하고 확장할 수 있는 구조로 설계되어 있어야 하고, 새로운 기능을 추가하기 쉬운 가이드나 레퍼런스 구현이 잘되어 있어야 하며, 여러 컴포넌트에 걸쳐 한명의 개발자가 기능을 추가할 수 있어야 하기 때문에, 테크놀로지(프로그래밍 언어나 프레임웍)들이 한정(표준화)되어 있고, 각 엔지니어들에게 교육되어 있어야 한다.

 

그렇다면 결론은 Feature Team 모델인가?

그렇다면 이 Feature team 모델이 모든 개발에 있어서 만병 통치약인가? 결론은 당연히 No이고, 모범 답안은 역시 “Case by case” 이다.

조직에 따라서 프로덕트 단위로 개발을 하는게 더 효율적일 수 도 있고 이런 경우에는 프로덕트(Component) 중심의 cross functional team 모델이 적합할 수 도 있다. 프로덕트에 따라서 빠르고 생산적인 개발 기술이 필요할 경우에는 Ruby on rails나 node.js 로 그 제품(프로덕트)를 개발하는 모델을 사용할 수 있다.

또는 한 조직내에서 어떤 제품은 독립성이 높고, 계속해서 기능 추가가 독립적으로 가능하다면 제품 기반의 cross functional team으로 독립 운영하고, 나머지 부분은 Feature team 모델로 운영할 수 도 있다.

즉 개발하고자 하는 서비스나 팀의 상황, 조직의 성숙도, 개발 스피드, 기술 수준, 관리 역량등 다양한 요인에 맞춰서 팀 모델을 점차적으로 변화시켜 나가고 최적의 모델을 찾는게 답이 아닌가 싶다.

 

참고 : http://www.featureteams.org/feature_team_primer12.pdf