[Note#4] 애자일 쇼케이스에 대하여

이 글을 시작하기 전에, 2001년에 제정된 애자일 매니페스토를 먼저 잠깐 살펴보자.

Individuals and interactions over processes and tools 
(프로세스나 툴보다 커뮤니케이션을 통해)

Working software over comprehensive documentation
(복잡한 문서보다 동작하는 소프트웨어로)

Customer collaboration over contract negotiation
(계약협상보다 고객과의 협업으로)

Responding to change over following a plan
(그저 계획에 따르는 것보다 변화에 따라 적절히 반응하는 것으로)

애자일매니페스토

애자일 매니페스토는 보다 좋은 품질의 소프트웨어를 만들기 위해 대전제가 될 수 있는 개념이다. 여러분의 팀에서도 이 전제들을 기반으로 다양한 방식으로 스스로가 속한 팀을 개선할 수 있다.

지속적인 개선을 위해 수행할 수 있는 여러 애자일 기법들 중 쇼케이스(Show case)는 위의 매니페스토를 실천하기 위해 가장 효과적인 기법이다.

쇼케이스

쇼케이스는 필요한 이해관계자(Stakeholder)에게 동작하는 제품을 시연하는 것을 말한다. (때문에 고객 시연, 고객 데모 등으로도 불림) 이를 위에서 설명한 매니페스토와 엮어 이야기하면,

  1. 쇼케이스를 통해 프로세스/툴의 과정지표로 이야기하는 것보다 직접적으로 소프트웨어의 방향과 관련된 의사결정자들과 소통할 수 있고,
  2. 문서 중심으로 과정에 대해 고민하기 보다 실물로 제품의 실효성에 대해 얘기할 수 있고,
  3. 계약협상에 매몰되어 소프트웨어의 가치에 집중할 수 없는 것을 이를 통해 피할 수 있으며,
  4. 이해관계자의 관심사 변경이나 환경 변화에 따른 변경을 소프트웨어에 피드백으로 조기에 반영/적용 할 수 있다.

하지만, 이 쇼케이스를 어떻게 해야 제품을 만드는데 도움이 되는지에 대해서는 이야기 하는 전문가들이 국내외에 거의 없다. 이를 시도하려는 분들을 위해 이번 기고를 통해 필자의 경험을 기반으로 이에 대해 이야기해보고자 한다.

필자가 애자일을 처음 시작했을 때 필자는 당시에 도움을 받을 사람들도 주변에 없었기 때문에, 여러 애자일 책에서 제시하던 기법들을 맹목적으로 따라 했다. 당시 쇼케이스는 필자가 시도했던 방식중 하나였다.

첫 번째 쇼케이스 시도

A 프로젝트가 시작될 때 필자는 당시 고객(공공 프로젝트 사업의 스폰서)에게 찾아가 앞으로 2주에 한번씩 미팅을 통해 진행상황을 공유하고 싶다고 했다. 또한 이전처럼 파워포인트나 문서가 아닌 실제 제품을 보여주겠다고 했고 고객은 흔쾌히 “YES”라고 이야기 했다.

(나중에 흔쾌히 YES라고 답했는지 이유를 고객에게 물었는데, ‘프로젝트 관리를 해야되는 입장의 나에게 진척을 제품으로 보여주겠다는데 왜 마다하겠나?’ 라는 반문을 들었다’)

당시 필자가 있던 팀의 규모는 15명 정도였다. 두 개의 업무 영역이 있었고, 한 팀은 7명, 다른 한 팀은 8명으로 구성되어 있었다. 7명의 팀은 단순 경영정보시스템형 기능을 개발을 하던 조직이었고, 8명의 팀은 분석/통계표를 만들던 팀이었다.

운이 좋게도 이 두 팀의 일하는 방법에 대해서 필자가 제안할 수 있던 위치에 있었다. 이 두 개의 팀 모두 우리는 2주단위 8개의 이터레이션 내내 고객에게 시연을 했다. 2개의 팀은 격주로 번갈아가며 시연을 했다. 첫 째주 금요일에 한 팀이 하면 다음주 금요일에는 다른 팀이 시연을 했다. 고객이 시간이 행사나 휴가로 시간이 안되는 날에는 다른 날을 잡았다.

당시 A프로젝트 현황판

당시 프로젝트의 시도는 매우 성공적이었다. 동작하는 기능으로 데모를 통해 설명하니, 고객은 본인이 나중에 실제 사용자들에게 설명해야 하는 기능에 대해 정말 잘 이해하게 되었고, 개발팀이 하고 있는 일에 대해 투명하게 알고 있다는 느낌을 받았다. 이는 고객과 개발팀간의 신뢰로 이어지게 되었다.

한번 신뢰가 쌓이고 나니, 고객이 우리 개발팀을 정말 이해한다는 느낌이 들기 시작했다. 상위기관에서 무리한 요구가 왔을 때도, 개발팀의 상황을 설명하며 프로젝트의 성공을 위해 이를 막아주려고 애썼다. 개발팀도 자연스레 우리를 보호해주는 고객을 신뢰하게 되었고, 그와 함께 계속해서 일하기를 원하게 되었다.

그 고객은 프로젝트 종료 시, 프로젝트를 성공적으로 이끈 것을 계기로 진급까지 하게 되었는데, 이 때문이었을까… 그는 개발팀을 추켜 세우며 지금껏 해온 우리회사와의 프로젝트 중 가장 최고의 팀이었다고 이야기하고 다녔다.

고객의 도움으로, 이 협업 사례로 필자의 사내 BP가 되었고, 필자는 더욱더 자신감이 생겨 맹목적으로 이를 해보기 시작했다. 그리고 그 뒤로 이어진 프로젝트에 동일한 시도를 하게 된다.

두 번째 쇼케이스 시도

두 번째 프로젝트의 전체 구성원은 20명 정도였으며, 9명과 11명의 두 개의 팀으로 나뉘어져 있었다. 이 중 필자는 9명의 팀을 맡는 PL이었다. 당시 우리가 만드는 시스템은 6개의 공공기관에서 쓰고 있는 시스템이었는데, 각 기관마다 6명의 고객이 담당하고 있었다.

고객사 공공기관X의 담당자들과 개발팀의 구조

이 6개의 기관은 5개의 공통 업무를 수행하고 있었고, 필자의 팀은 이 5개의 업무를 개발하는 팀이었다. 개발팀이 프로젝트를 시작하기 전 가지고 있던 가정에는 이 5개의 공통 업무가 6개 기관에서 거의 동일하다는 것이었다. 개발팀은 6개 기관의 고민이 비슷할 것이라는 생각에 1개의 기관 화면을 중심으로 개발하고 시연한 뒤 다른 5개의 개발을 하는 전략을 택했다.

문제는 쇼케이스를 할 때마다 6개 기관의 고객 모두를 불러야하는 것부터 시작되었다. 첫 쇼케이스 때부터 5개의 업무가 공통이라는 가정이 잘못된 것이라는 것을 깨달았다. 6개의 기관은 거의 모든 기능에 각자의 다른 특성을 가지고 있었고, 이들을 각각 반영해야 했다. 첫 시연부터 요구변경이 급격하게 늘어나기 시작했다.

최초대비 3배 가량 늘어난 업무의 프로젝트 그래프

개발팀은 당황하기 시작했다. 공공사업의 특성상 요구변경이 늘어나도 기간이 늘어나거나 추가계약을 하기 어려운 구조였기에, 개발팀은 시간이 갈 수록 고객의 요구에 대해 방어적이 되고 있었다. 고객들은 자신들의 요구가 제대로 개발팀에 반영되지 않고 있다는 생각을 하게 되었다.

심지어, 쇼케이스를 진행 할 때, 특정 기관에 집중되어 이야기가 진행되면 다른 5명의 고객들은 그들의 시간을 낭비하고 있다는 생각을 했고, 특정 기관에만 특별한 기능을 넣으려면 다른 5개의 기관에서도 비슷한 형태의 기능이 필요하다는 주장을 하기 시작했다. 이 때마다 개발팀은 울상이 되었다.

쇼케이스를 할 수록 고객과의 신뢰가 무너지기 시작했다. 이를 극복할 수 있는 유일한 방법은 정해진 기간과 공수하에서 많은 규모의 요구사항을 수용하는 것이었다. 결국 일하는 시간을 물리적으로 늘리기 위해 야근과 주말근무를 해야했다. 프로젝트 종료까지 진행된 이 고단한 일들로 대부분의 프로젝트 팀원이 행복하지 않았다.

무엇이 문제인가?

과연 무엇이 잘못되었던 것일까?

우선 쇼케이스가 성공적으로 진행되려면 다음의 전제조건이 있어야 한다.

  1. 기능 단위가 아닌, 업무(비즈니스) 단위의 제품 책임자가 존재하고 팀이 이를 담당해야 한다.
  2. 제품 책임자는 1명이 가장 좋으며, 해당업무에 대한 오너십을 가져야 한다.
  3. 제품 책임자의 성공이 개발팀의 성공과 동일한 것이어야 한다.

(Scrum이라는 프로세스에서는 Product Owner 라는 역할로 위 3가지를 하는 담당자를 정의한다.)

두 번째 케이스 프로젝트는 5개의 기능조직으로 구성된 개발팀과 6개의 업무(비즈니스) 단위의 구성된 고객의 조직이 매트릭스로 엮어 불일치가 생기는 구조였다. 개발팀은 효율을 최대화 하기 위해 기능 단위로 인력을 나누었고, 계약을 진행한 고객은 예산을 줄이기 위해 이에 동의하였지만, 실제 실무 기관을 담당하는 다른 고객은 이에 동의할 리가 없는 구조였다.

또한 프로젝트 책임자였던 특정 고객은 이들 6개 실무기관의 고객 담당자들과 좋은 관계를 유지하는 것을 프로젝트 성공보다 중요하게 생각했다. 때문에 그들이 쏟아내는 요구사항에 대해 제어하거나 이야기하며 설득하려고 하지 않았다.

결국 위의 세 가지 조건 중 아무것도 지킬 수 없는 구조였다. 이러한 경우 쇼케이스는 프로젝트에 매우 좋지 않은 영향을 줄 수 있다. 이 글을 읽고 그래도 쇼케이스를 통해 고객의 요구를 모르는 것보다 낫다라는 주장을 할 분도 있겠으나, 첫 단추를 잘못 꿰어 놓은 상태에서는 그 단추를 풀지 않는 한 옷이 제대로 입혀지지 않는다. 책속의 이야기 처럼 고객과 개발팀이 함께 실수를 인정하고 다시 계약을 하는 일은 일어나기 어렵다.

이외의 고려해야 할 점

쇼케이스에 대한 전략을 세울 때, 주기 또한 중요한 요소가 된다. 7~12명 정도의 작은 팀에서 주기를 2주 이상으로 가져가면, 시연할 내용이 너무 많아져, 쇼케이스 자체에 너무 많은 시간을 소모할 수 있다. 이 경우 이해관계자들의 집중력이 흩어져 효과적인 쇼케이스가 되기 어렵다.

또한 주기가 너무 길어지면, 이해관계자들이 자주 확인하지 못하기 때문에 물리적인 변경의 수는 줄어들 수 있으나, 기능 자체에 대해 이해관계자들이 만족하지 못하는 리스크가 커질 수 있다.(반대로 주기가 짧아지면, 물리적인 변경은 늘어나더라도 이해관계자들이 기능에 대해 만족하는 리스크가 작아질 수 있음)

2008년 와세다 대학에서 작성된 논문에 따르면, 불확정성이 높은 프로젝트의 경우 이터레이션을 짧게 가져가는 것이 좋고, 복잡도가 높은 프로젝트 일 수록 이터레이션을 길게 가져가는게 좋다는 내용도 참고하면 좋겠다. (참조링크)