brunch

You can make anything
by writing

C.S.Lewis

by 김병호 Dec 09. 2019

98. 상품개발 조직의 유형

성공적인 소프트웨어 신상품 개발가이드

상품개발팀은 2인 이상의 조직이다. 상품개발조직을 어떻게 설계하고 운영하느냐에 따라 상품개발 성과는 달라질 수 있다. 이번회에서는 조직설계시 고려할 요소, 조직의 대표적인 유형인 기능조직, 매트리스 조직, 상품조직, 교차기능팀(Cross Functional Team)의 특징을 설명한다. 


1) 조직설계 개요 

조직설계란 조직의 구조를 정의하는 작업으로 조직별로 업무 전문화와 업무 통합 중 무엇을 강조 할 지가 핵심이다. 전문화를 강조하는 조직은 효율을 추구하고, 통합을 강조하는 조직은 효과를 추구한다. 효율은 경제성을, 효과는 목표달성을 중요시한다. 

소프트웨어 상품과 하드웨어 상품개발에 관련된 역할자들은 표*와 같으며,  상품개발 조직을 설계한다는 것은 아래 역할자들이 어떤 조직에서 어떻게 의사소통하고 협업할 지를 결정하는 것이다. 

통합(효과성)과 분업화(효율성)의 관점에서 조직설계 개념을 정리하면 다음과 같다.


내부 효율성을 강조하는 조직

업무 전문화라는 관점에서 볼 때 각 기능부서의 전문성을 최대한 발휘할 수 있는 조직 형태이다. 이를 기능조직(functional organization)이라고 하고 다음 특징을 가지고 있다.


• 표준화된 규칙과 규제를 통해서 일상 과업을 수행

• ‘규모의 경제’ 효과를 얻을 수 있으며, 인력이나 장비 중복을 최소화할 수 있고, 부서원들도 ‘동일한 언어’, ‘동일한 문화’를 가짐

• 표준화를 통해 중간 관리자의 기본적인 역량을 확보할 수 있음

• 부서간 갈등이 발생할 가능성이 높고, 조직의 목표보다 부서의 목표를 우선시함. 표준화되지 않는 문제 대응이 어려움


외부 효과성을 강조하는 조직

주어진 목표를 단기간에 달성하기에 가장 적합한 조직 형태다. 전담 TF(Full-time Task Force)가 예이며, 이를 상품 혹은 프로젝트 조직이라 하고 다음과 같은 특징을 가지고 있다.

• 목표 달성을 위해 한시적으로 다양한 기능을 통합한 조직이 만들어지고 목표 달성 후 조직을 해체

• 조직 전체로 보면 인력과 장비의 중복이 발생하고, 이질적 문화를 가진 사람들로 인한 갈등 발생

• 조직의 업무 전문성이 낮아 표준화할 수 있는 범위가 작음

• 팀원들이 1명(프로젝트 관리자)의 통제하에 있기 때문에 팀원들의 역할 조정이 쉬움


내부 효율성과 외부 효과성을 혼합한 조직

앞의 두 가지 조직 형태에서 각각의 장점을 살린 혼합(hybrid) 조직 형태다. 이를 매트릭스 조직(matrix organization)이라 하고 다음과 같은 특징을 가지고 있다.

• 기능조직과 프로젝트(제품) 조직의 장점을 살리기 위한 조직

• 명령체계(command of control)가 일원화되지 않아 갈등 발생 가능

(소속원은 기능조직의 관리자와 프로젝트 관리자의 지시를 받음)

• 조직내 전문가들을 효율적으로 활용 가능


2) 기능조직 (Functional organization) 형태의 상품개발

상품개발에 참여하는 각 역할자의 책임자를 기능부서장(FM : Functional Manager) 이라고 한다. 기능조직 형태로 수행하는 상품개발 프로젝트에서는 기능부서장의 권한이 프로젝트 관리자의 권한보다 강하다. 우선순위가 낮은 상품개발 또는 유지보수 업무는 기능조직 형태로 상품개발을 할 수 있다. 기능조직 형태로 상품개발을 하는 경우는 드문데 그 이유는 기능조직에서는 프로젝트의 목표보다 부서의 목표가 중요하기 때문이다. 기능조직 형태로  상품을 개발할 때 장점 및 단점은 아래 그림과 같다. 

소프트웨어 상품개발시 기능조직은 다음과 같은 단점이 있기 때문에 적용하지 않는 것이 바람직하다. 


순차적 개발 방법론과 사고방식을 가지게 만든다.

상품 요구사항 대부분은 단일 기능조직과 매핑되지 않아 여러 기능조직간에 업무 이관 낭비와 일정 지연이 발생한다.


업무이관의 낭비가 발생한다. 

여러 기능조직이 순차적인 방식으로 개발하면 이관 과정에서 엄청난 낭비가 발생하게 된다. <린 소프트웨어개발의 적용, 2007>에서는 업무이관의 어려움을 다음과 같이 설명한다.

업무를 이관한다는 것은 자전거를 탈 줄 모르는 사람에게 자전거를 건네주는 것과 같다. 당신은 그들에게 자전거 타는 방법에 관한 두꺼운 설명서를 줄 수도 있겠지만, 그것이 크게 도움이 되지 않을 것이다. 그 보다는 같이 달리면서, 속도가 붙음에 따라 생기는 균형감을 직접 느끼게 하는 편이 훨씬 좋다. 


학습기회가 제한된다.

기능조직 중심으로 상품개발을 진행하면 팀원들은 제한된 내용과 제한된 사람의 코딩만 보기 때문에 새로운 것을 보고 배울 기회가 작다.


더 가치 있는 일보다는 더 쉬운 업무를 하게 만든다.  

기능조직 중심으로 상품개발을 진행하면 고객관점에서 가치를 제공하는 피처를 제공하는 것이 힘들어 질 수 있다. 기능조직은 가장 높은 가치보다 가장 하기 쉬운 피처를 빨리 개발하도록 최적화된다. 기능조직은 기존에 출시된 버그를 수정하면서 신규 피처를 개발하기에 매우 바빠 보인다.


팀이 ‘인위적인 업무’를 수행하게 만든다.   

기능조직을 운영하는 경우 고객가치의 중요도와 무관한 기능을 개발할 수 있다. 기능조직의 리더는 해당 팀이 의미 있는 일을 하느라 바쁜 것처럼 보이기 위해 중요도가 낮은 일을 만든다. 그 결과 모든 사람들이 바쁘게 되는 국지적 최적화가 발생한다.


팀원이 지속적으로 증가한다.   

상품개발마다 각 기능조직의 업무 양은 달라진다. 예를 들어 이번 출시에는 A 기능조직의 업무가 많아 인력을 2명 충원하고 다음 출시에는 B 기능조직의 업무가 많이 인력을 2명 충원할 수 있다. 한번 충원한 인력은 해당 기능조직 안에서 담당업무가 있기 때문에 다른 기능조직으로 옮기기는 어렵다. 이런 식으로 팀원이 증가한다.


계획과 조정이 어렵다.     

상품 요구사항 개발을 위해 관련된 기능조직이 많을수록 일정계획을 수립하고 이슈 발생 시 조정이 복잡해진다. 그 결과 고객에게 가치를 전달하는 시기도  지연된다.


코드/설계가 점점 더 수준이 낮아진다.     

많은 경우 단일 기능조직이 오랫동안 유지보수 하는 코드가 조악하다. 오랜 기간 동안 복잡하고 어려운 코드를 보고 있으면 친숙해지고 깔끔해 보이기도 한다. 그 결과 코드 리팩토링에 대한 동기도 없다.


3) 상품조직 (Product organization) 형태의 상품개발

상품조직은 1920년대 듀퐁(Du Pont)사에서 사용하여 지금은 사업부조직으로 많이 적용되는 조직이다. 사업부 조직에서는 상품을 개발하고 생산하기 위한 기능부서(개발, 생산, 영업, 구매 등)를 포함하기 때문에 모든 의사결정을 사업부에서 내린다. 상품개발에 상품조직을 적용하면 상품개발을 위한 팀원이 모두 한 장소에서 특정 상품개발업무만 수행한다. 중요도가 높은 상품을 개발할 때 상품조직을 적용한다. 상품조직 형태로 중심으로 상품을 개발할 때 장점 및 단점은 아래 그림과 같다. 

4) 매트릭스 조직 (Matrix organization) 형태의 상품개발

전문부서의 기술역량과 상품관점에서 유연한 대응이 필요한 업무는 전문조직의 종적 관리와 횡적 통합을 동시에 고려해야 한다. 이와 같이 기능조직의 장점과 상품조직의 장점을 혼합한 조직이 매트릭스 조직이다. 매트릭스 조직의 특징은 조직원들이 두 명의 상사(dual boss)에게 보고하고 지시를 받는다는 것이다. 물론 두 명의 상사가 동일한 비중으로 관리하는 것이 아니라, 주 관리자가 있는 경우가 대부분이다. 매트릭스 조직 형태로 중심으로 상품을 개발할 때 장점 및 단점은 아래 그림과 같다. 

대부분의 조직에서 상품개발은 매트릭스 조직의 형태로 진행한다. 기술인력이 전문 부서에 소속되어 여러 개의 프로젝트(또는 유지보수)를 동시에 담당하는 것이 그 예가 된다. 매트릭스 조직에서 프로젝트 관리자는 기능부서로부터 인력을 지원받아 프로젝트를 진행하며, 각 인력은 기능부서 업무와 프로젝트 업무를 병행 수행할 수 있다. 프로젝트 관리자의 권한이 기능부서장의 권한보다 높으면 강한 매트릭스 조직(strong matrix), 둘의 권한이 거의 비슷하면 중간 매트릭스 조직(balanced matrix), 기능 부서장의 권한이 프로젝트 관리자의 권한보다 높으면 약한 매트릭스 조직(weak matrix)이라고 한다.


매트릭스 조직에서는 팀원이 기능부서장과 프로젝트 관리자 모두에게 수행업무를 보고해야 하므로 정보의 흐름이 복잡하다.프로젝트 관점에서 기능조직, 매트릭스 조직, 상품 조직의 특징을 정리하면 아래 표와 같다. 

5) 교차기능팀 (Cross Functional Team) 형태의 상품개발 


교차기능팀이란 다양한 기능을 대표하는 사람들의 그룹이다. 소프트웨어 상품개발의 경우 상품관리자, 디자이너, 설계자, 아키텍트, 테스터, 개발자 등이 교차기능팀을 구성한다. 교차기능팀의 협업방식은 매트릭스 조직형태 또는 상품조직 형태가 가능하다. 상품개발을 위해 필요한 교차기능팀의 역할자들이 한곳에 모여서 프로젝트를 진행하면 이를 홀팀(whole team)이라고도 한다. 스크럼팀도 대표적인 교차기능팀이자 홀팀이다. 

대형의 상품개발시에는 다시 내부 조직을 몇 개의 그룹으로 나누어야 한다. 내부조직을 분할하는 관점은 기능(예: 모바일앱, 웹, 서버개발)으로 또는 피처(feature)로 구분 가능하다. 

컴포넌트 팀은 아래 그림과 같이 하나의 요구사항(item)을 고객에게 제공하기 위해 여러 팀이 협업해야 한다. 단일 팀 관점에서는 단순하지만 요구사항 구현 관점에서는 복잡도가 높다. 반면 피처팀은 여러 컴포넌트를 포함하여 단일 팀  관점에서는 복잡하지만 요구사항 구현 관점에서는 복잡도가 낮다. 

컴포넌트 팀과 피처팀의 상품개발, 출처 : LeSS(Large Scale Scrum) 프레임웍 https://less.works/less/framework/index.html

컴포넌트 팀과 피처팀의 차이는 아래 표와 같다. 상품개발팀을 컴포넌트 중심으로 할지 피처 중심으로 할지는 정답이 없다. 피처팀의 장점이 많다고 판단할 수 있지만 조직운영이 뒷받침 되지 않으면 피처팀의 장점을 발휘 할 수 없고 컴포넌트 팀 보다 성과가 낮을 수 있다. 또한 모든 팀을 피처팀으로 운영할 수도 없다. 재사용 컴포넌트 관리, 기술 아키텍처 구성 및 유지를 위해서는 별도 컴포넌트 팀이 필요하다. 컴포넌트 팀에서 수행할 업무를 피처팀에서 수행하는 비중이 높을수록 전담 컴포넌트팀은 줄어 들 것이다.


https://brunch.co.kr/@kbhpmp/160


브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari