brunch

You can make anything
by writing

C.S.Lewis

by 김병호 Jan 09. 2021

소프트웨어 상품개발 방법론 선정

소프트웨어 상품개발 방법론을 선정하는 것은 소프트웨어 개발 수명주기(Software Development Life Cycle)를 선정하는 것과 같다. 개발 수명주기의 유형으로는 폭포수(Waterfall), 반복적(Iterative), 증분Incremental), 애자일이 대표적이다. 폭포수는 예측형(Predictive) 또는 계획주도(Plan driven)이라고도 하는데 일반적으로 많이 알려진 폭포수라는 용어를 사용하겠다. <Agile Practice Guide>(2017)에서는 네 가지 방법론의 특징을 아래 표와 같이 설명한다.

폭포수 방법론은 한 번의 상세한 계획을 수립 후 각 단계를 순차적으로 수행 한 뒤 종료 시점에 결과물을 납품한다. 스포츠에 비유하면 외부환경의 요인이 작은 개인 기록경기(체조, 마라톤)와 유사하다. 외부 불확실성이 낮기에 상세하게 계획을 수립하고 연습하여 실전에서 계획대로 이행하는 것이 중요하다.

반복형 방법론은 프로토타입을 활용하여 분석과 설계 또는 설계와 빌드를 반복적으로 수행한다. 고객의 의견을 반영한 결과물을 종료 시점에 납품한다. 상품의 최초 출시를 위해 프로토타입을 활용하여 고객 의견을 반영하는 것이 이에 해당한다. 스포츠에 비유하면 씨름, 레슬링, 유도와 같이 단판으로 승부를 가리는 격투기와 유사하다. 격투기는 기본적인 전략을 수립하고 경기에 임하지만 상대방에 대응하면서 전략을 바꾼다.

증분형 방법론은 프로젝트 결과물을 N번으로 나누어 제공한다. 상품 출시 후 매월 기능을 보완하는 것이 이에 해당한다. 스포츠에 비유하면 양궁, 계주와 같이 개인은 각각의 기록을 내면서 단체의 성과를 판정하는 단체경기와 유사하다. 단체경기에서 개인의 기록은 하나의 증분이며 이전 선수의 기록에 따라 다음 선수의 전략이 달라진다. 마지막으로 애자일은 증분형에 기반을 두고 반복형을 혼합한 것이다.

반복 기반 애자일(Iteration-based agile)은 각 반복의 주기를 동일하게 유지하나 흐름 기반 애자일(Flow based agile)은 각 이터레이션의 주기가 업무에 따라 달라진다. 스포츠에 비유하면 구기종목이 해당되는데 농구, 축구와 같이 정해진 시간에 따라 각 세트를 경기하면 반복 기반 애자일이고 배구, 야구와 같이 정해진 기준을 충족해야 세트가 끝나면 흐름 기반 애자일이다. 예를 들어 야구감독도 야구시작전에 경기 전략을 구상하지만 매회(스프린트)를 마치면서 다음 회 경기전략을 바꾼다.

개발방법론의 수행단계, 출처: Agile Practice Guide, 2017

PMI가 발간한 Agile Practice Guide>(2017)에서 방법론의 유형을 ‘납품주기’와 ‘변화의 정도’에 따라 아래 그림과 같이 분류한다.

현실에서 적용하는 개발방법론은 앞서 설명한 네 가지 방법론을 혼합하는 경우가 많기 때문에 0과 1처럼 명확하게 구분하기 힘들며 0과 1 사이에 존재하는 수많은 실수에 가깝다. 예를 들어 0을 폭포수 방법론의 전형이라 하고 1을 애자일 방법론의 전형이라 할 때 현실에서 적용하는 방법론의 대부분은 그 사이에 존재한다.

예를 들어 신규 상품의 ‘분석’은 폭포수 방법론을 적용하고 ‘설계/빌드/테스트’는 반복형 방법론을 적용하여 출시한 후 업데이트는 흐름기반의 애자일 방법론을 적용할 수 있다. 변경의 양이 많아지는 v2.0의 상품개발은 폭포수와 애자일 방법론을 혼합하여 적용할 수 있다.

0과 1을 구분하는 기준은 요구사항 또는 기술적 불확실성을 수용하는 정도이다. 요구사항의 불확실성은 상품관리자와 상품개발팀간 의사소통 이 미흡하거나 고객 요구사항 자체가 불확실할 때 발생한다. 기술적 불확실성은 검증되지 않은 기술을 적용하거나, 해당 기업이 적용해 본 적 없는 기술을 적용할 때, 상품개발팀의 역량이 낮을 때 발생한다.

폭포수 방법론은 프로젝트 착수 초기에 모든 상품 요구사항을 상세하게 정의하고 프로젝트를 진행하면서 기술적 불확실성을 낮추는 반면, 애자일 방법론은 착수 초기에 요구사항의 불확실성과 기술의 불확실성이 높음을 인정하고 프로젝트를 진행하면서 둘 다 조금씩 낮춘다.

불확실성을 관리하기 위해서는 복합성(complication)과 복잡성(complexity)을 구분해야 한다. 복합성과 복잡성이 불확실성을 초래하는 방식은 다르다. 기계의 작동은 복합적이고 사람의 심리는 복잡하다. 기계를 구성하는 요소는 많아도 구성요소 간의 상호작용은 예측 가능하다. 예측이 어렵고 시간이 많이 걸릴 뿐이다. 기술적 불확실성은 복합성과 관련된 경우가 대부분이다. 요구사항의 불확실성이 높아지면 복잡성이 높아진다. 자녀 교육은 복합성은 낮지만 복잡한 문제이다. 국제 금융 시스템은 복합성도 높고 복잡성도 높다.

시스템 구성요소가 많은 은행의 차세대 정보시스템 구축은 복합성이 높은 프로젝트이고, 우버나 에어이엔비의 초기 상품개발은 고객의 반응을 예측하기 힘들기 때문에 복잡성이 높은 프로젝트이다. 우버나 에어이엔비의 사업을 확장하는 프로젝트는 복합성과 복잡도가 모두 높은 프로젝트가 된다.

복합성과 복잡성이 매우 높아지면 예측이 힘들기 때문에 애자일 방법론을 사용하는 것이 좋지만 복합성이 높은 프로젝트는 계획수립에 보다 많은 시간을 투입하는 것이 좋다. Agile Practice Guide>(2017)에서는 복합성과 복잡성을 아래 그림과 같이 설명한다.

좋은 방법론은 적용이 용이하고, 적용 한 이후 효과가 높다. 방법론을 선정할 때 유의사항은 다음과 같다.

- 좋은 방법론의 기준은 개인의 가치에 따라 다르다.

예를 들어 새로운 것을 배우기 좋아하는 사람들은 기존의 이론보다 새로운 이론을 선호할 것이다. 반면 뭔가를 새로 배우고 적용하기 싫어하는 사람은 새로운 방법론 효과가 명확히 검증되기 전까지 익숙한 방법론을 선호할 것이다.

- 방법론 적용효과(예: 생산성)를 믿기 힘들다.

XX 방법론이나 툴을 적용했더니 생산성이 YY%만큼 향상되었다는 주장은 신뢰하기 힘들다. 프로세스와 툴을 홍보하는 거의 모든 사람들이 생산성 향상을 수치로 이야기한다. 그러나 상세한 분석방법(샘플링, 결과 조사기준 등)을 공개하지 않으니 어느 정도 믿어야 할지 가늠할 수 없다. 설사 그것을 믿는다 해도 내 조직, 내 프로젝트에서 같은 결과가 나온다고 보장할 수 없다.

- 프로젝트 생산성이나 품질은 방법론만으로 설명하기 힘들다.

프로젝트의 생산성이나 품질에 영향을 미치는 요인은 복잡하다. 예를 들어 프로젝트 관리자의 역량이 뛰어나고 팀워크가 좋으면 그 팀은 어떤 방법론을 적용해도 성공할 가능성이 높다.

- 방법론과 ‘조직 팀 개인’ 간에 궁합이 있다.

모든 조직, 모든 팀원, 모든 상황에 잘 적용되는 방법론은 없다. 같은 한약이라도 사람의 체질에 따라 효과가 다르듯이 특정 방법론은 특정 조직, 특정 팀 또는 특정 상황에 적용하면 성과가 높을 수 있다. 우리 팀, 우리 조직에 맞지 않는 프로세스는 아무리 좋아도 성과는 없고 부작용만 생길 수 있다.

모든 방법론은 특정 상황에서 특정 조건을 전제로 적용할 때 성과를 창출할 수 있다. 따라서 A 방법론이 B 방법론보다 절대적인 비교우위에 있지 않다. 전통적인 개발 방법론(폭포수 방법론)의 단점을 이야기하곤 하지만, 어느 프로젝트가 애자일과 궁합이 맞지 않다면 폭포수 방법론을 적용할 때 보다 더 나쁜 결과를 초래할 수 있다.

상품관리자와 프로젝트 관리자는 내 팀에 적합한 방법론은 무엇이고, 적용효과를 높이기 위해 방법론을 어떻게 변경하여 적용할지 고민해야 한다. 조직에 따라 상품관리자나 프로젝트 관리자가 재량을 가지고 방법론을 변경 적용할 수 없다면, 제대로 수행할 액티비티와 구색만 갖출 액티비티를 구분하는 것도 방법이다.

상품개발에 애자일 방법론 적용이 적합한지를 판단하기 위해서는 ‘조직의 문화’, ‘상품개발팀’, ‘프로젝트’의 카테고리를 종합적으로 분석해야 한다. Agile Practice Guide>(2017)에서 소개한 ‘애자일 적합성 평가 도구(Agile suitability filter tools)’를 정리하면 아래 표와 같다. 각 분석항목이 1점에 가까울수록 애자일 적용이 적합하다.