Mckinsey Quarterly

시장분석?제작?품질검사까지 한 팀이… 워크셀, 복잡한 IT시스템 구축에 최고!

162호 (2014년 10월 Issue 1)

Article at a Glance – 운영

복잡한 IT 시스템을 구축할 때워크셀이라 불리는 다기능팀을 활용해 폐쇄적인 조직 구조(silo)를 허물어뜨리면 성공 가능성이 높아진다. 기존 프로젝트 팀이 소비자 요구분석, 개발, 품질검사 등의 기능 부문별로 나누어진 데 비해 워크셀은 특정 모듈을 처음부터 끝까지 책임지는 형태로 구성된다. 워크셀을 이용하면 팀원들의 책임감이 높아지고, 다른 업무를 맡은 팀원들 간의 커뮤니케이션이 좋아지며, 개발과 테스트 간의 피드백 시간이 짧아진다. 

 

편집자주

이 글은 <맥킨지쿼털리>에 실린 ‘Achieving Success in Large, Complex Software Projects’를 전문 번역한 것입니다.

 

여러 산업에서 비즈니스 가치를 창출하고 전략적 역량을 구축하는 데는 기술 중심적인 변화 프로그램의 활용이 중요하다. 많은 조직들이 IT 예산의 약 절반가량을 응용 프로그램(application) 개발에 투자하고 있는 만큼 대부분의 변화 프로젝트를 성공적으로 진행하기 위해서는 적은 비용을 들여 좀 더 신속하게 소프트웨어 프로그램을 실행하는 능력이 필요하다. 하지만 실행의 질은 아직 개선돼야 할 부분이 많다. 맥킨지와 옥스퍼드대는 공동 연구를 통해 규모가 큰 소프트웨어 프로젝트들이 평균적으로 예산을 66% 초과하며 예정된 기한을 33% 초과한다는 사실을 발견했다. 뿐만 아니라 기업의 생존 자체를 위협할 정도로 형편없이 진행되는 프로젝트가 무려 17%에 달한다는 사실도 밝혀졌다.1

 

대규모로 진행되는 일부 응용 프로그램 개발 프로젝트는 특히 까다로운 편이다. 복잡성이 높은데다 업무흐름(work stream) 간의 상호 의존도가 크기 때문이다. 통신요금 청구, 보험금 청구, 세금 납부, 핵심 소매 금융 플랫폼 등을 지원하는 시스템을 개발하기 위한 프로젝트가 여기에 포함된다. 이런 프로젝트를 진행하려면 긴밀한 조정이 필요하다. 맨 처음에 제시된 사용자 요구사항이 수정되는 빈도가 잦기 때문이다.

 

프로젝트를 긴밀하게 조정하려면 응용 프로그램 개발 과정에서 흔히 관찰되는 폐쇄적인 조직 구조를 무너뜨려야 한다. 애자일(민첩한) 소프트웨어 개발 접근법(agile software-development approach)이 폐쇄적인 조직 구조를 무너뜨리는 데 도움이 되는 경우가 많다. 하지만 애자일 접근법은 주로 소규모 프로젝트에 적용된다. 소규모 프로젝트의 경우, 사전에 미리 정해져 있는 사용자 요구사항이 많지 않은데다 이런 요구사항들을 병행 가능한 다수의 하위 프로젝트들로 깔끔하게 나눌 수 있기 때문이다.2

 

애자일, (lean) 기법3 을 따르며 검사 중심적인 개발 방식4 에서 비롯된 반복적인 응용 프로그램 개발 방식(iterative application-development practice)을 구성하는 여러 요소들은 앞서 언급한 복잡한 프로젝트에서 중요한 역할을 할 가능성이 크다. 그동안 필자들이 경험한 바에 의하면 복잡하고 규모가 큰 프로젝트를 성공적으로 진행할 때는 이런 접근방법을 다기능팀(cross-functional team)으로 대변되는 새로운 조직 구조와 결합시켜야 한다. 필자들은 이런 팀을워크셀(work cell)’이라 부른다.

 

필자들은 연구를 통해 규모가 크고 복잡한 응용 프로그램 개발 프로젝트를 진행할 때 기능을 중심으로 팀을 나누는 구조가 비생산적이라는 사실을 발견했다.

 

응용 프로그램 개발 과정에서 등장하는 조정 문제

응용 프로그램 개발 프로젝트에 참여하는 3개 부문, 즉 비즈니스 분석, 개발, 검사 부문은 폐쇄적으로 활동하는 탓에 서로 간의 정보 흐름이 비효율적인 경우가 많다. (그림 1) 응용 프로그램 개발 프로젝트의 규모가 작을 때는 폐쇄적인 업무 방식이 별다른 문제가 되지 않는다. 하지만 프로그램의 규모가 크고 복잡해지면 의사소통 문제가 심각해진다. 응용 프로그램과 관련된 사용자 요구사항을 수집하는 프로젝트 관리자와 비즈니스 분석가들은 국내에 있고 개발자와 검사자는 해외에 있는 경우에는 위험이 더욱 커진다. 실제로 이런 경우가 많다. 이런 환경에서는 의사소통 속도가 더욱 느려진다. 시간대가 다른 탓에 서로 겹치는 업무 시간이 제한적이기 때문이다. 뿐만 아니라 응용 프로그램 개발에 참여하는 여러 부문들이허브 앤드 스포크방식으로 정보를 교환한다. 예컨대, 검사자가 검사 과정에서 찾아낸 코드 결함을 고위급 응용 프로그램 개발자에게 전달하면 고위급 응용 프로그램 개발자가 다시 나머지 팀원들에게 코드 재작업 업무를 맡기는 식이다. 이처럼 여러 차례에 걸쳐 업무를 전달하는 일이 반복되면 의사가 제대로 전달되지 않고 병목 현상이 발생할 가능성이 크다.

 

효과적으로 생산성과 품질을 측정하기 어렵다는 점 또한 어려움을 가중시킨다. 그 결과, 요구사항과 제품 성능 불일치라는 값비싼 문제가 발생하고 응용 프로그램 개발에 참여한 여러 부문들이 서로를 비난하게 된다. 개발팀은 사용자 요구사항이 최종적으로 합의되고 마무리된 상태에서 전달되기를 기대한다. 하지만 항상 그렇지는 않다. 응용 프로그램 개발에 참여한 모든 당사자들이 최신 요구사항이나 명확하게 정리된 요구사항에 동의하지 않은 탓에 팀 내에서 재작업이 이뤄지고 불만이 확산될 수도 있다. 폐쇄적인 업무 방식 탓에 소프트웨어 개발 수명주기를 따라 업무가 효율적으로 나눠지지 않은 채 덩어리째 이동한다. 예컨대, 유즈 케이스(use case)5 가 완성될 때마다 여러 묶음으로 나눠 검사를 하기보다 사용자 승인 검사 단계에서 한 번에 검사하는 현상이 생긴다. 이런 업무 방식 탓에 동시에 여러 프로세스를 실행해 시장 출시까지 걸리는 시간을 줄일 기회를 놓치게 된다.

 

필자들은 연구를 통해 규모가 크고 복잡한 응용 프로그램 개발 프로젝트를 진행할 때 기능을 중심으로 팀을 나누는 구조가 비생산적이라는 사실을 발견했다. 각 기능 부문은 최종 사용자에게 훌륭한 기능을 제공하기 위해 노력하기보다 소프트웨어 개발 수명주기 가운데 자신들과 관련이 있는 부분에 대해서만 책임을 진다. 의사소통 문제를 고려해 보면 처음부터 끝까지 모든 책임을 지는 프로젝트 관리자들을 모아 소규모로 팀을 꾸리는 방식도 그다지 효과적이지 않다. 이런 방식으로 구성된 팀은 과도하게 분산돼 있는 탓에 각기 다른 부문 간의 의견 차를 긴밀하게 조정하지 못하는 경우가 많다.

 

 

 

다기능 접근방법

그동안 필자들이 경험한 바에 의하면 규모가 크고 복잡한 소프트웨어 프로젝트를 진행할 때는 워크셀을 활용하는 편이 낫다. 워크셀은 특정 응용 프로그램 모듈을 처음부터 끝까지 책임지는 다기능팀을 말한다. 워크셀을 활용하면 프로젝트 관리자는 여러 다기능팀 간의 의사소통과 업무 전달을 관리하기보다는 워크셀이 주어진 업무 모듈을 제대로 완수할 수 있도록 돕는 역할을 맡게 된다. ( 2)

 

다기능팀을 제대로 활용하면 개인적인 책임감 강화, 집단적인 책임감 강화, 의사소통 개선, 효과적인 조정, 반복 주기 단축 등 여러 가지 이점을 얻을 수 있다.

 

좀 더 커다란 책임감.워크셀 방식이 도입되면 비즈니스 분석가와 개발자, 검사자들이 하나의 긴밀한 업무 단위에 소속돼 상호 협력하며 프로세스 전반을 책임진다. 즉 사용자 요구사항, 코드 개발, 기능 검사, 재작업, 사용자 승인 검사, 고객에게 전달되는 궁극적인 기능 등이다. 이와 같은 팀 구조를 채택하면 프로젝트에 참여하는 개인과 단체가 한층 커다란 책임감을 갖게 될 뿐 아니라 단번에 업무를 제대로 완수해야 한다는 생각을 갖게 된다.

 

 

 

좀 더 원활한 커뮤니케이션.다기능팀을 활용하면 여러 부문 사이에서 조정이 제대로 이뤄지지 않은 탓에 재작업이 요구되거나 지연이 발생할 가능성이 줄어든다. 요구사항이 바뀌거나 업데이트나 설명이 필요할 때 국내외에서 프로젝트에 참여하는 여러 당사자들을 관리하기도 한층 수월해진다. 뿐만 아니라 좀 더 효율적으로 결함을 찾고 수정할 수 있다. 다기능팀 구성원들은 어떤 비즈니스 분석가나 개발자, 검사자와 이야기를 해야 할지 정확하게 파악하고 직접 의사소통할 수 있다. 팀원들이 서로 직접적으로 피드백을 주고받을 수 있는 권한을 갖고 있다고 느끼기도 한다. 팀원들이 이런 느낌을 받으면 오류가 발생할 위험이 줄어들고 재작업으로 인한 비용 역시 줄어든다. 또한 검사나 재작업에 필요한 인력이 적절히 투입될 수 있도록 스케줄 변화에 관한 정보가 적절한 시기에 전달된다. 팀원들이 사전 공개에 관한 정보를 일찌감치 공유하면 검사자가 어떤 부분을 검사하게 될지 미리 충분한 정보를 확보할 수 있다. 매일 15분씩 한데 모여 회의를 하면 현재 진행 중인 업무에 대해 논의하고 우선순위를 조정하는 데 도움이 된다. 뿐만 아니라 각 기능팀이 매일, 혹은 격일로 기획 회의를 진행할 수도 있다.

 

 

다기능팀을 활용하면 여러 부문 사이에서 조정이 제대로 이뤄지지 않은 탓에 재작업이 요구되거나 지연이 발생할 가능성이 줄어든다.

 

좀 더 짧은 반복 주기.다기능팀을 활용하면 검사 결과를 주고받는 주기를 단축할 수 있다. 규모가 작은 집단 내에서 반복 과정이 진행되는 만큼 조정 업무를 좀 더 단순하게 진행할 수 있기 때문이다. 따라서 검사자들이 개발자들에게 명확한 설명을 요구하거나 결함 수정을 요구할 때 대기 시간이 대폭 줄어든다.

 

보험회사 사례

대형 보험회사 A는 글로벌 보험 청구 플랫폼을 개발하기로 마음먹었다. 프로젝트에 투입된 직원들은 총 3개의 표준시간대에 위치한 4개 도시에 흩어져 있었다. A는 기능 부문(비즈니스 분석, 개발, 검사)별로 응용 프로그램 개발 구조를 체계화했다. 물론 세 부문에 공통적으로 적용되는 프로젝트 계획이 있었다. 하지만 공통 계획은 사실상 각 기능 부문이 갖고 있는 각기 다른 3개의 프로젝트 계획을 연결하는 역할을 할 뿐이었다. 따라서 세 팀 사이에서 의사소통이 원활하게 이뤄지지 않았다. 의사소통이 제대로 이뤄지지 않자 다수의 코드 결함, 상당량의 재작업, 형편없는 업무 배열, 중요 단계 생략 등 여러 가지 문제가 발생했다. 프로젝트 전체를 책임지는 사람이 없었기 때문이다.

 

A는 결국 프로젝트 진행 도중에 기존 계획을 폐기하고 다기능팀을 활용하는 방안을 새롭게 도입했다. 새로운 방안을 도입한 A는 각 다기능팀에게 논리적으로 연계된 여러 유즈 케이스에 대한 책임을 맡겼다. 새로운 방안이 도입되자 팀원들은 자신이 맡은 역할에 대해서만 고민을 하기보다 처음부터 끝까지 제대로 된 기능을 내놓는 데 집중하기 시작했다. 새로운 접근방법은 정보 교환 속도를 높이고, 좀 더 짧은 기간 내에 요구사항을 설명하고, 좀 더 신속하게 문제를 해결하는 데 도움이 됐다. 1달 만에 코드 결함이 45% 줄어들었고, 코드 결함이 감소하자 많은 시간을 들여 재작업을 해야 할 필요성이 줄어들었다. 다기능팀을 활용하는 새로운 업무 방식 덕에 제품을 시장에 출시하기까지 걸리는 시간이 20% 줄어들었으며 현장 일선의 생산성이 개선됐다. 뿐만 아니라 비즈니스 고객들은 예정보다 앞서 최종 제품을 확인하고 고객 경험 개선에 도움이 되는 변화를 제안할 수 있었다.

 

프로젝트의 복잡성과 업무 흐름 간의 상호 의존성으로 인해 규모가 큰 응용 프로그램 개발 프로젝트를 진행하기가 쉽지 않은 경우가 있다. 응용 프로그램 모듈을 처음부터 끝까지 책임지는 다기능팀을 활용하면 비용을 줄이고, 품질을 개선하고, 진행 속도에 박차를 가할 수 있다. 이런 접근방법이 프로젝트 참가자들에게 좀 더 커다란 책임감을 부여하고, 여러 업무를 좀 더 효율적으로 조정하고, 반복 주기를 단축하는 데 도움이 되기 때문이다.

 

번역 |김현정 translator.khj@gmail.com

 

감사의 말씀

저자들은 이 글을 쓸 수 있도록 많은 도움을 주신 가이 아사드(Guy Assad), 카리시 크리시나칸산(Krish Krishnakanthan), 밍 루안(Ming Ruan), 니할 사라우기(Nihal Sarawgi)에게 감사의 말씀을 전한다.

 

스리람 찬드라세카란·사우리 구드라발레티·산제이 카니야르

스리람 찬드라세카란(Sriram Chandrasekaran)은 맥킨지 뉴욕 사무소 컨설턴트, 사우리 구드라발레티(Sauri Gudlavalleti)는 델리 사무소 컨설턴트, 산제이 카니야르(Sanjay Kaniyar)는 보스턴 사무소 부소장이다.

동아비즈니스리뷰 345호 Fake Data for AI 2022년 05월 Issue 2 목차보기