brunch

매거진 고객중심의 프로젝트 관리

라이킷 3 댓글 2

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 김병호 Aug 14. 2019

34. 애자일 방법론의 등장배경

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

애자일(Agile)은 ‘기민한’, ‘민첩한’, ‘유연한’을 뜻하며 애자일 방법론(또는 프로세스)은 2,000년 이후 소프트웨어 개발 및 관리분야에서 빠르게 확산되었다. 2010년대 후반부터 애자일은 소프트웨어 개발 방법론을 넘어 경영혁신의 도구로 여러 업종에 확산되고 있다. 이는 사물인터넷( IoT), 빅데이터 기술의 발전이 여러 업종의 디지털 전환( DT Digital Transformation)을 가속화하여 소프트웨어 기업, 하드웨어 기업, 서비스 기업을 구분하기 힘들어졌기 때문이다. 국내에서도 2018년 이후 금융권을 중심으로 애자일 방법론을 조직관리에 적용하는 사례가 증가하고 있다.

여러 업종에 애자일이 확산되면서 ‘애자일이 뭐야?’라는 질문은 많아지는데 간단히 답하기 쉽지 않다. 애자일을 기법에 초점을 두는 사람이 많지만, 중요한 것은 애자일이 추구하는 목적이다. 상품개발에서 애자일은 ‘불확실성이 높은 상품개발에 적합한 방법론’으로 이해해도 무방하다.

애자일 옹호자들이 이야기하는 애자일의 효과는 환상적이다. 예를 들면 ‘애자일은 더 많은 일을 하기보다 더 가치 있는 일을 작은 노력으로 하는 것입니다.’는 식이다. 세상에 공짜는 없다. 대부분 좋은 결과를 얻기 위해서는 많은 시행착오와 대가를 지불해야 한다. 애자일 적용이 일반화되면서 성공사례뿐 아니라 실패사례도 많다는 것을 기억하자.

1) 애자일 프로세스의 등장배경

애자일 프로세스(방법론)는 기존 소프트웨어 개발방법론의 문제점을 개선하기 위해서 등장했다. 기존 소프트웨어 개발방법론의 부작용에 대해 제프 서덜랜드는 2012년 인터뷰에서 다음과 같이 이야기 했다. (<애자일개발과 스크럼, 2014>에서 재인용)

그들은 돈은 충분했지만 결코 소프트웨어를 잘 만든다고는 할 수 없었습니다. 그리고 항상 납기가 지연되었고 납품된 소프트웨어는 품질에 문제가 있었습니다. 그 결과 끊임없이 관리직에게 압력을 받으며 마치 벌레 같은 취급을 당했습니다. 그들의 삶의 질을 크게 바꾸는 작은 변화는 무엇일까요? 이 질문이 나에게 던져진 최초의 질문이었고 그것이 소프트웨어 개발 방법을 개발해야겠다고 결심한 계기가 되었습니다.

애자일 진영에서 생각하는 기존 소프트웨어 개발 방법론의 주요 문제점은 다음과 같다.

- 계약과 계획준수를 중요시하는 갑과 을의 문화가 지배적이다.

갑과 을의 문화는 윈윈(win win)의 상생이 아니라 윈루즈(win lose)의 제로섬 게임을 유도한다. 계획 수립 시 최대한의 버퍼를 확보하려는 그룹(을)과 버퍼를 최대한 없애려는 그룹(갑)의 이해관계는 상충된다. 갑/을 문화는 기업 간 뿐만 아니라, 기업 내부에서도 존재한다. 갑/을 문화의 대표적인 부작용은 다음과 같다.

• 갑은 작은 예산으로, 많은 기능을, 빨리 얻고자 한다. 을은 많은 예산으로, 적은 기능을, 여유 있게 제공하길 원한다.

을의 입장에서는 일정연기와 예산추가 없는 요구사항 변경은 수용하기 힘들다. 그 결과 갑은 프로젝트 착수시점에 최대한 많은 요구사항을 계약서 또는 계획서에 명시하거나, 기능을 모호하게 표현하여 많은 기능을 포괄적으로 포함하고자 한다.

• 프로젝트 착수 이후에는 비즈니스 목표는 사라지고 프로젝트 계획서 또는 계약서 이행이 가장 중요한 목표가 된다.

착수 시 모든 것을 정확하게 예상하여 계약하거나 계획을 수립하면 역설적으로 더 많은 변경이 발생할 뿐 아니라, 계약서나 계획서에 있다는 이유만으로 불필요한 기능을 개발하는 낭비도 발생한다.

- 문서를 중시한다.

최종적으로 완성된 소프트웨어를 고객 또는 이해관계자에게 전달하기 전에 고객과 의사소통 할 수 있는 수단은 문서이다. 그러나 문서로 의사소통 하는 것은 한계가 있다. 넥타이 매는 방법을 글로 적는다고 생각해 보라. 예상보다 글로 표현하기 어려운 것도 많다. 문서가 불필요하다는 것은 아니다. 소프트웨어 요구사항 또는 진행과정 파악을 문서에만 의존하는 것은 한계가 있다는 것이다. 애자일이 확대되면서 실효성 낮은 문서가 줄어들긴 했지만, SI 프로젝트에서는 중도금 지급과 같이 행정적인 이유로 여전히 많은 문서를 작성하고 있다. 문서에 의존하여 프로젝트 진척과 품질을 평가하는 관행도 문서를 양산하는 원인이 된다.

- 프로세스나 툴 적용을 중시한다.

많은 조직에서 소프트웨어 개발 프로세스를 통제하면 소프트웨어 개발 결과를 통제 할 수 있다고 생각한다. 좋은 프로세스 적용을 통해 고품질의 소프트웨어가 나온다고 생각한다. 이러한 인식은 테일러의 동작연구 이후 경영학 및 기업전반에 뿌리내린 과학적 사고방식이기도 하다. 좋은 프로세스의 결과로 좋은 결과가 나오는 것은 이견이 없지만, 좋은 프로세스는 절대적인 것이 아니라 상황에 따라 상대적이다. 과학적 관리의 미명하에 각 조직에 맞지 않는 소프트웨어 개발 프로세스와 툴을 적용하는 경우가 많다.

- 성과가 나쁠 때 계획 또는 통제의 실패로 인식한다.

프로젝트 수행도중 예상하지 못했던 변경사항이 발생하면 계획이나 통제가 부실했기 때문으로 인식하고 더 완벽한 계획수립과 통제를 하고자 한다. 이런 상황을 <스크럼, 2008>에서는 다음과 같이 설명하고 있다.

분명 개발자가 방법론이 지시한 내용을 제대로 하지 않았을 거야. 진행상황을 정확하게 보고하지 않았을 수도 있고 방법론의 지시 내용을 따르지 않았을 수도 있지. 방법론 개발회사는 방법론만 따르면 예측 가능한 결과를 얻을 수 있다고 했는데, 이걸 개발자들이 제대로 완수해내지 못한 거야.

이상 애자일 방법론의 등장배경이 되는 문제점들을 요약하면 아래 그림과 같다.

위에서 설명한 소프트웨어 개발의 문제점을 극복하고자 애자일 진영에서는 2001년 <애자일 선언 Agile Manifesto>를 발표하였다.

프로세스나 도구에 앞서 개인과의 상호작용을

정리를 위한 포괄적인 문서에 앞서 작동하는 소프트웨어를

계약 협상에 앞서 고객과의 협력을

계획 준수에 앞서 변화에 대한 대응을

우리는 왼쪽 항목의 가치를 인정하면서도 오른쪽 항목을 더 중요하게 여긴다.

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

애자일 선언의 내용을 살펴보기 전에 유의할 사항이 두가지 있다.

- 애자일 선언은 개발팀의 관점에서 작성되었다.

애자일 선언은 경영층이나 상품기획의 관점이 아니라 상품개발팀의 관점에서 읽어야 한다. 이를 대표하는 사람은 프로젝트 관리자이다. 물론 상품관리자의 입장에서도 애자일 선언은 유효하지만 보다 적합한 주체는 프로젝트 관리자이다.

- 애자일 선언 당시 B2C 소프트웨어 상품은 유행하지 않았다.

2001년 당시 어떤 소프트웨어 개발이 주류였을까? 애자일 선언을 하는 시점에서는 모바일 앱도 없었고 따라서 B2C 소프트웨어 상품이 활발하게 팔렸던 시점은 아니다. CD로 제공되는 게임이나 유아 교육용 소프트웨어 정도였다. 따라서 당시 소프트웨어 상품개발팀의 고객은 주로 기업이었다. 따라서 B2C 상품기획이나 개발과 관련된 독자들은 애자일 선언이나 애자일 원칙에 나오는 ‘고객’은 B2C 상품의 고객이 아니라 ‘기업내부 이해관계자’로 이해해야 한다. B2B 소프트웨어 개발팀의 상품관리자 또는 프로젝트 관리자의 입장에서 애자일 선언문 내용을 이해하는 것도 좋은 방법이다.

애자일 선언문의 의미를 신상품 개발관점에서 하나씩 살펴보자

- 프로세스나 도구에 앞서 개인과의 상호작용을

협력(cooperation)과 협업(collaboration)은 다르다. 협력은 업무를 분업화하여 수행한다. 상품관리자는 요구사항을 정의하고, 디자이너를 화면을 그리고, 개발자는 코딩을 하고, QA(품질보증인력)는 테스트를 한다. 협력은 각 역할자들이 작업을 독립적으로 진행한다. 반면 협업은 각 역할자들이 상호작용을 통해 각자의 작업에 영향을 미친다. 협력은 결과를 한꺼번에 통합하는 방식이 많고 협업은 조금씩 점진적으로 통합하는 방식이 많다.

최근 협업을 지원하는 도구가 많지만, 전통적으로 협업보다는 협력을 지원하는 도구가 많았다. 신상품 성공을 위해서는 여러 역할자들의 긴밀한 상호작용 즉, 협업이 필요하다. 상호작용을 위해서는 도구나 프로세스보다 다른 역할자의 의견을 인정하고 신뢰해야 한다. 협업을 통해 상호작용 하는 팀에서는 문제해결을 위한 창의적인 아이디어가 나올 가능성이 높다.

상품개발의 의사소통 과정은 ‘이해 → 공감 → 동의’의 순서로 발전한다. 상호작용 없이 도구나 프로세스로 할 수 있는 수준은 ‘이해’에 머무른다. 프로세스나 도구는 절대적으로 필요하지만 그것만으로는 부족하다. 긴밀한 상호작용을 하는 팀에서는 상품개발 후반부에 발생하는 변경이나 재작업이 적다.

신상품을 개발할 때 역할자들의 상호작용을 극대화하는 방법은 모든 역할자가 한 장소에서 근무하는 것이다. 한 장소에서 근무하면 지식 이전을 위한 프로세스나 도구의 필요성이 낮아진다.

- 정리를 위한 포괄적인 문서에 앞서, 작동하는 소프트웨어를

문서를 중시하는 조직은 수직적 의사결정 또는 지시에 익숙한 관료조직일 가능성이 높다. 문서는 경영층을 기쁘게 하거나 안심시켜 주기 위해 만드는 경우가 많기 때문이다. 고객은 문서를 필요로 하지 않는다. 문서를 중시할수록 고객과 현장에서 멀어진다. 고객을 중시하는 수평적 협업조직에서는 작동하는 소프트웨어가 중요하다. 물론 작동하는 소프트웨어를 만들기 위해 사용자 스토리(상품 요구사항)는 필수 문서이다.

작동하는 소프트웨어는 고객에게 릴리즈하는 것을 전제로 하기 때문에 사용자 매뉴얼, 운영자 매뉴얼도 포함한다. 작동하는 소프트웨어는 내부 품질검증을 위해서도 중요하다. 통합 빌드를 구축하고 실행시켜야 결함을 발견할 수 있다.

- 계약 협상에 앞서 고객과의 협업을

어느 한쪽이 손해를 보면서 협업을 하는 것은 힘들다. 주문형 소프트웨어 개발(SI)에서 협업보다 협상을 추구하다가 갈등과 앙금만 남기는 경우도 많다. 계약에 기반한 프로젝트에서 협상보다 협업을 하려면 어느 한쪽이 손해를 보지 않는다는 전제가 필요하다. 상품개발을 진행할 때에는 고객과 협업하는 것이 아니라 내부 이해관계자와 협업해야 한다.

조직 내부 프로젝트는 계획서만 있을 뿐 계약은 없다. 하지만 조직내부도 상품개발을 요청하는 조직과 상품개발을 수행하는 조직이 나뉘어 있다. 이 두 조직은 계획의 협상보다 비즈니스 목표달성을 위해 상호 협업해야 한다. 협상을 중요하게 여기면 개발팀은 최소한의 범위와 최대한의 일정과 예산을 받으려 할 것이고 요청부서 또는 경영층은 그 반대로 행동할 것이다. 뿐만 아니라 협상을 중시하는 조직은 불확실한 신상품의 성공보다 자기 조직의 이해관계를 우선한다. 조직을 평가하는 지표(KPI: Key Performance Indicator)가 복잡하고 다양한 조직에서는 이러한 현상이 심화된다. 부서 이익을 우선시 하는 사일로(silo) 조직에서 상품 성공을 위한 협업은 허울 좋은 구호에 지나지 않는다.

- 계획 준수에 앞서 변화에 대한 대응을

프로젝트의 계획 준수보다 비즈니스 목표 달성이 중요하다. 계획 준수의 관점에서는 프로젝트 범위, 일정, 예산 모두가 중요하다. 그러나 비즈니스 우선순위는 변경될 가능성이 높고, 우선순위가 바뀌면 범위 • 일정 • 예산 중 하나 이상을 변경해야 한다. 상품개발은 비즈니스 불확실성이 높기 때문에 아무리 신중하게 계획을 수립해도 프로젝트를 진행하는 도중 계획 변경을 초래하는 많은 변수가 발생한다. 계획된 기능을 모두 개발하는 것보다 주어진 기간내에 최대한의 가치를 제공하는 것이 중요하다.

아래 그림의 왼쪽은 계획을 준수하기 힘들다. 기능(범위)을 상수로 두고 일정과 예산을 변수로 두는 것인데 기능이 변할 때 그에 맞게 일정을 연기하거나 예산을 추가하기 어렵기 때문이다. 반면 오른쪽은 계획준수가 용이하다. 일정과 예산을 상수로 두고 그에 맞추어 기능을 개발하면 되기 때문이다. 경영층이나 고객의 불만은 있을 수 있어도 계획을 준수하지 못할 이유가 없다. 오른쪽의 그림은 상품개발팀이 주어진 기간내에 팀원이 최선을 다한다는 신뢰를 기반으로 할 때 가능하다. 왼쪽 그림을 계획기반의 개발, 오른쪽 그림을 가치기반의 개발이라 한다.