칼럼 | 포커에서 배우는 애자일 프로젝트 교훈

CIO
CIO닷컴 칼럼니스트 데이빗 타버는 연말연시 연휴 중 온라인 텍사스 홀덤 포커를 통해 불멸의 진리를 탐구했다. 여기 그가 텍사스 홀덤으로부터 알아낸 애자일 프로젝트 관리 교훈을 소개한다.

이렇게 말하면 실망할지도 모르겠다. 필자는 그간 텍사스 홀덤 포커게임에 대해 운이나 허풍(bluffing)과 같은 것들이 있어야 이길 수 있는 게임이라고 생각해왔다. 한편으로는 IT 프로젝트 관리도 이와 크게 다를 것이 없어 보인다.

하지만 실제로 텍사스 홀덤 게임을 해보면 필요한 스킬이 분명 필요하다는 것을 알게 된다. 그리고 대부분의 상황에 있어서 명백히 옳고 그른 판단 역시 있다. 그리고 소프트웨어 프로젝트도 마찬가지다.

- 시작단계에서는 구체적으로 이용할 만한 정보를 거의 찾을 수 없다. 오로지 희망과 추정만이 가득할 뿐이다. 즉 일반적인 가능성에 근거해서 결정을 내리게 된다.

- 프로젝트 초기에 돌이킬 수 없을 정도로 약속하는 것은 카드 게임에서 카드패가 모두 주어지기도 전에 모든 판돈을 거는 것과 유사하다.

- 상황이 전개되면서 이전에 내렸던 결정은 이후 알려지는 정보로 인해 무효가 되기도 한다. 전체 프로젝트의 일부를 취소하는 등 전략상의 중요한 변화가 필요할 수도 있다.

- 상황에 따라서는, 승리를 위해 계획했던 것보다 더 많은 비용을 써야 할 수도 있다.

- 가장 많은 비용은 프로젝트의 말미에 소요되기 십상이다. 그럼에도 결과물이 그러한 투자만큼 나아질 가능성은 그다지 높지 않다.

- 개인의 고집스러움에는 대가가 따른다. 민첩함과 유연성은 항상 도움이 된다.

상기의 내용은 카드 게임과 소프트웨어 프로젝트 관리 사이의 흥미로운 유사성을 보여준다.

승리에 필요한 것이 무엇인지 알 수 있다고 확신하기
소프트웨어 프로젝트에 있어, 시작 전 자세한 요구사항 관련 문서(a detailed requirements document)를 만들고자 하는 시도가 나타난다. 소프트웨어 제품 개발 프로젝트라면 문제가 없을지도 모른다. 하지만 CRM 소프트웨어나 고객지향 경영 시스템과 같은 현업 프로젝트인 경우 자세한 요구사항 관련문서를 제작한다는 것은 불필요한 일에 그치는 경우가 많다.

왜일까? 요구사항 관련 문서가 충분히 정확할 수 없기 때문이다. 요구사항 작성 과정에 있어 우수한 직원들이 이 업무에 집중하도록 잡아 둘 수 없다. 항상 이러한 문서작성보다 더 중요한 일이 있기 마련이다. 즉 정교하지 못한 추측과 잘못된 우선순위 설정 등 쉽게 확인되지는 않는 괴리가 발생하는 것이다.

이뿐만이 아니다. 요구사항 관련 서적에 근거한 접근방법(the “requirement tome” approach)는 두 가지 가정에 근거한 것인데, 이들 가정은 많은 경우에 있어서 CRM 프로젝트 등에 있어서는 적용하기 어려운 경우가 많다.

첫 번째 가정은 프로젝트 시작 전에 정확히 어떤 것이 필요한지 알 수 있다는 것이다. 두 번째 가정은 프로젝트를 성공적으로 마무리하면 명확화된 요구사항을 달성해낸다는 것이다.

그렇다면 다음에 제시되는 상황이 프로젝트 진행에 있어 나타날 가능성이 어느 정도일지 생각해보자.

- 사용자가 완전히 정확하게 요구사항을 언급했으며 이를 여러분이 오해할 가능성은 없는 상황이다.

- 여러분은 비즈니스 프로세스, 데이터 퀄리티, 시스템 교차적 통합 이슈에 대해 잘 알고 있고 예외상황이 발생할 가능성도 없다.

- 사용자는 프로젝트 전반에 있어 세부사항과 우선순위를 변경하지 않을 것이다.


- 우선순위를 변경하거나 심지어 요구사항을 무효화시킬 만한 조직 개편(reorganization)이 발생하지 않는다.

- 현재 제공하는 제품이나 서비스에 실질적이고 관련성 있는 변화는 없을 것이다.

- 유통 채널과 경쟁적 환경이 프로젝트의 운명을 바꾸지 않을 것이다.

- 정부 규정, 고객과의 계약상 조건, 내부적 기준의 변화를 모두 예상할 수 있다.

이러한 모든 요건을 충족할 수 있는가? 만약 그렇다면 참으로 운이 좋다고 말할 수 있을 것이다.

프로젝트 중기에 흔히 나타나는 이러한 사항들은 초기의 설정한 요구사항에 대해 우선순위를 다시 정해야 한다는 것을 의미한다. 다시 말해, 문서에 나타나 있는 내용과 다른 부분에 우선순위를 두어야 한다는 것이다.


초기의 요구사항을 나열한 문서가 수정되어야 하기 때문에, 2주나 4주 단위로 시간 계획을 나눠 각 단계 시작점에 있어서 기존의 계획을 다시 한번 검토해 보는 것이 이에 대한 애자일 솔루션(the agile solution)이 될 것이다. 이 과정을 통해 프로젝트 구현에 따르는 전략적인 요구사항에 대한 이해를 확충해야 한다. 참고로 여러 가지 애자일 방법론을 보면 가장 최근의 세부적인 요구사항은 ‘카드’라고 불리고 있다. 이 또한 카드 게임을 연상시키는 용어다.

예산을 미리 알 수 있다고 생각하기
전통적으로 소프트웨어 예산은 비용 모델을 기반으로 이뤄지는 경우가 많다. 구체적으로 ‘요구사항(Requirements) > 업무에 대한 명세(Statement of work) > 업무 구조 분장(Work breakdown structure) > 수치 예상(Estimates)’ 의 과정이 있다. 그러나 상기 논의된 과정에도 불구하고 비용 예측은 제대로 이루어 지지 않는 경우가 태반이다.

먼저 추가적으로 고려해야 할 사항이 있다. 비즈니스 소프트웨어 프로젝트에 있어 가장 큰 비용의 요소는 바로 내부 직원의 시간, 회의, 매몰 비용으로 인한 것이다. 예산수립과정에서 이러한 부분은 간과되는 경우가 많고 잘못된 결과값으로 이어진다.

첫째 ‘(수면시간이 부족한 직원과 같은) 보이지 않고 비용이 들지 않는 자원의 경우는 과도하게 할당되고 소모되며 프로젝트의 지연을 야기한다. 둘째, 상황이 좋지 않아질 경우 (수면시간이 부족한 컨설턴트들과 같은) 명백하게 비용이 드는 자원이 개입되어 상당한 비용의 증가를 야기한다.

따라서 비용을 정확히 예측하지 못할 가능성은 높다. 하지만 성공적인 비즈니스 케이스를 분석해보면사업가치만큼 비용에 많은 초점을 두지 않는 다는 점을 알 수 있다. 사실 비용이 예상보다 조금 더 들더라도 원하던 가치를 실현시켰다면 그것이 무슨 상관이겠는가?

프로젝트를 진행하면서 으레 삐걱거리는 부분이 나타날 것이며 우선순위나 자원 배분 조정을 필요로 하게 될 것이다. 그리고 이러한 과정을 통해 기업은 당초 계획에는 포함되어 있지 않던 온갖 종류의 가치를 발견하게 된다.

사실 전체 계획은 그저 모델일 뿐이며, 모델은 새로운 사실이 나오면 극복되기 마련이다. 따라서 애자일 솔루션은 예산을 서서히 늘려가는 것이 당연하다. 각 단계마다 타임박스로 시간이 한정되어 있다. 상황 나아지면서 예측관련 에러가 상쇄되기 시작한다. 근본적으로 애자일은 초기에 모든 비용을 투여하는 것이 아니라 순차적으로 비용을 투여하는 모델임을 기억해야 한다.

물론 재무부서에서 고정된 비용을 제시하라고 요청할 수도 있다. 하지만 커스텀 소프트웨어에 있어서 이는 잘못된 가정에 근거한 환상에 불과하다. 이를 믿지 못할 경우, 중대한 CRM 시도에 커스텀 소프트웨어를 포함시키는 결과를 낳을 것이다.

*David Taber는 ‘세일즈포스닷컴 성공의 비밀(Salesforce.com Secrets of Success)’의 저자며 세일즈포스닷컴의 공식 컨설팅 업체인 세일즈로직스 CEO다. ciokr@idg.co.kr