애자일 쇼케이스란 무엇인가?

애자일 쇼케이스란 무엇인가

연재를 시작하기 전에, 2001년에 제정된 애자일 Manifesto(매니페스토)를 잠깐 살펴보겠습니다.

애자일 매니페스토 이미지

애자일 매니페스토는 보다 좋은 품질의 소프트웨어를 만들기 위한 대전제로, 여러분이 속한 팀에서도 이를 기반으로 다양한 방식의 개선활동을 시도해볼 수 있습니다.
쇼케이스(Show case)는 지속적인 개선활동을 위한 여러 애자일 기법들 중 하나로 위에서 언급한 매니페스토를 실천하는데 가장 효과적인 기법입니다.

쇼케이스 이미지

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

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

하지만, ‘쇼케이스를 어떻게 활용해야 제품을 만드는데 도움이 되는지’를 정확히 설명할 수 있는 전문가들은 국내외에 거의 없습니다. 그래서 필자는 이번 연재에서 쇼케이스로 매니페스토를 실천하려는 분들에게 도움을 주고자 실제 경험을 이야기해볼까 합니다.
필자가 애자일을 처음 시작했을 당시 도움받을 만한 주변인이 없었기 때문에, 애자일 관련 책자에서 제시하던 기법들을 맹목적으로 따라 했습니다. 이때 시도했던 여러 애자일 방식 중의 하나가 바로 쇼케이스였습니다.

첫 번째 쇼케이스 시도

A 프로젝트가 시작될 때 필자는 당시 고객(공공 프로젝트 사업의 스폰서)에게 찾아가 앞으로 2주에 한 번씩 미팅을 통해 진행 상황을 공유하고 싶다고 이야기했습니다. 그리고 종전처럼 파워포인트나 문서가 아닌 실제 제품을 보여주겠다고 했죠. 고객은 흔쾌히 “YES”라고 답했습니다.
(나중에 그때 왜 YES라고 했는지 고객에게 물었더니, ‘프로젝트 관리를 해야 하는 입장에서 내게 진척 과정을 직접 제품으로 보여주겠다는데 왜 마다하겠나?’라고 반문했습니다. )
당시 필자가 있던 팀의 규모는 15명 정도였습니다. 두 개의 업무 영역이 있었고, 한 팀은 7명, 다른 한 팀은 8명으로 구성되어 있었습니다. 경영정보시스템 기능 개발은 7명의 팀이, 분석/통계표는 8명의 팀이 담당했죠.
운이 좋게도 필자는 이 두 팀의 일하는 방법에 대해서 제안할 수 있던 위치에 있었고, 우리는 격주로 번갈아가며 8개의 이터레이션을 고객에게 시연했습니다. 첫 주 금요일에 한 팀이 하고 나면 다음 주 금요일에는 다른 팀이 시연을 하는 방식이었죠. 고객이 행사나 휴가로 인해 시간을 내기 어려운 날에는 다른 날로 잡았습니다.

프로젝트 현황판 이미지 당시 A 프로젝트 현황판

당시 프로젝트는 매우 성공적이었습니다. 동작 기능을 데모로 직접 시연하니, 고객은 나중에 실 사용자들에게 설명해야 하는 입장에서 기능을 보다 정확히 이해할 수 있었죠. 또, 개발팀이 하는 일에 대해 고객이 투명하게 알고 있다 보니까, 이것이 곧 고객과 개발팀간의 신뢰로 이어졌습니다.
신뢰가 한번 쌓이고 나니 고객이 개발팀을 정말 이해하고 있다는 느낌이 들기 시작했습니다. 상위기관에서 무리한 요구를 했을 때에도, 고객이 개발팀을 대신해 상황을 설명하고 프로젝트의 성공을 위해 이를 막아주려고 애썼습니다. 개발팀도 자연스레 우리를 보호해주는 고객을 신뢰하게 되었고, 그들과 함께 계속해서 일하기를 원하게 되었죠.
프로젝트 종료 후에도 고객은 지금껏 진행해온 프로젝트 중 최고의 팀이었다고 개발팀을 추켜 세웠습니다. 덕분에 이 협업 사례는 사내 Best Practice가 되었고, 필자는 더욱더 자신감이 생겨 뒤에 이어진 프로젝트에서도 맹목적으로 쇼케이스를 시도했습니다.

두 번째 쇼케이스 시도

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

쇼케이스 조직도 - 각 개발팀에서 고객사인 6개 담당기관의 업무 담당

6개의 공공기관은 5개의 공통 업무를 수행하고 있었고, 필자의 팀은 이 5개의 업무 개발을 담당했습니다. 프로젝트를 시작하기 전 개발팀은 이 5개의 공통 업무가 6개 기관에서 거의 동일할 것이라 가정했죠. 따라서 개발팀은 6개 기관이 비슷한 고민을 할 것이라는 생각에 1개의 기관 화면을 중심으로 개발하여 시연한 뒤 다른 5개의 기관 화면을 개발하는 전략을 택했습니다.
하지만 쇼케이스를 할 때마다 6개 기관의 고객 모두를 불러야 하는 것이 문제였습니다. 또, 첫 쇼케이스 때 5개의 업무가 공통될 것이라는 가정이 잘못된 것이라는 것을 깨달았죠. 알고 보니 6개 기관은 거의 모든 기능에서 서로 다른 특성을 가지고 있었고, 이들을 각각 반영해야 했습니다. 이로 인해 첫 시연부터 요구 변경이 급격하게 늘어났습니다.

개발팀은 당황했습니다. 공공사업의 특성상 요구 변경이 늘어나도 프로젝트 기간을 늘이거나 추가 계약을 하기가 어려운 구조였기 때문입니다. 시간이 흐를수록 개발팀은 고객의 요구에 방어적으로 대응했고, 이로 인해 고객들은 자신들의 요구가 제대로 반영되지 않고 있다는 생각을 갖게 되었습니다.
심지어 쇼케이스를 진행할 때, 특정 기관에 집중되어 이야기가 진행되면 다른 5명의 고객들은 자신들의 시간이 낭비되고 있다는 생각을 했고, 특정 기관에 특별한 기능을 넣으려고 하면 다른 5개의 기관에서도 비슷한 형태의 기능이 필요하다는 주장을 하기 시작했습니다. 이때마다 개발팀은 울상이 되었고, 쇼케이스를 하면 할수록 고객과의 신뢰가 무너지는 것을 느꼈습니다.

이를 극복할 수 있는 유일한 방법은 정해진 기간과 공수 안에서 대량의 요구사항을 수용하는 것이었습니다. 결국 일하는 시간을 물리적으로 늘려 야근과 주말 근무를 해야 했습니다. 프로젝트 종료까지 진행된 이 고단한 일들로 당시 대부분의 프로젝트 팀원이 행복하지 않았습니다.
무엇이 문제인가? 과연 무엇이 문제였을까요?
우선 쇼케이스가 성공적으로 진행되려면 다음의 전제조건이 필요합니다.

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

두 번째 케이스 프로젝트는 5개의 기능조직으로 구성된 개발팀과 6개의 업무(비즈니스) 단위로 구성된 고객의 조직이 매트릭스로 엮여 불일치가 생길 수밖에 없는 구조였습니다. 개발팀은 효율을 높이기 위해 기능 단위로 인력을 나누었고, 계약 당사자인 고객도 예산을 줄이기 위해 이에 동의하였지만, 따지고 보면 실무를 담당하는 다른 기관의 고객은 이에 동의할 수 없는 구조였습니다.
게다가 프로젝트 책임자였던 특정 고객은 이들 6개 실무기관의 고객 담당자들과 좋은 관계를 유지하는 것을 프로젝트의 성공보다 중요하게 생각했습니다. 때문에 그들이 쏟아내는 요구사항에 대해 제어하거나 설득하려고 하지 않았습니다.
결국 위의 세 가지 조건 중 아무것도 지킬 수 없는 구조였던 것이죠. 이런 경우 쇼케이스는 프로젝트에 매우 좋지 않은 영향을 줄 수 있습니다. 물론, 이 글을 읽으면서 어떤 사람은 고객의 요구를 모르는 것보다 쇼케이스를 통해 파악하는 것이 낫다고 주장할 수도 있지만, 첫 단추를 잘못 꿰어 놓은 상태에서 그 단추를 풀지 않는 한, 옷을 제대로 입을 수 없다고 생각합니다. 또, 드라마처럼 고객과 개발팀이 함께 실수를 인정하고 다시 계약을 하는 일도 일어나기 어렵습니다.

이외의 고려해야 할 점

쇼케이스에 대한 전략을 세울 때, 주기 또한 중요한 요소입니다. 7~12명 정도의 작은 팀에서 쇼케이스의 주기를 2주 이상으로 정하면, 시연할 내용이 너무 많아져 쇼케이스 자체에 너무 많은 시간을 소모할 수 있습니다. 이럴 경우 이해관계자들의 집중력이 흩어져 효과적인 쇼케이스가 되기 어렵습니다. 또, 주기가 길어지면서 이해관계자들이 자주 확인하지 못해 물리적인 변경의 수가 줄어들 수 있지만, 기능 자체에 대해 이해관계자들이 만족하지 못하는 리스크가 발생할 수도 있습니다. 반대로 주기가 짧아지면, 물리적인 변경은 늘어나더라도 이해관계자들이 기능에 대해 만족해 상대적으로 리스크가 줄어들 수도 있습니다.
마지막으로, 2008년 와세다 대학에서 작성된 논문(Investigating the relationship between project constraints and appropriate iteration length in agile development through simulations)에 따르면, 불확정성이 높은 프로젝트의 경우 이터레이션을 짧게 가져가는 것이 좋고, 복잡도가 높은 프로젝트일수록 이터레이션을 길게 가져가는 게 좋다고 하니 참고하시길 바랍니다.



▶   해당 콘텐츠는 저작권법에 의하여 보호받는 저작물로 기고자와 삼성SDS에 저작권이 있습니다.
▶   해당 콘텐츠는 사전 동의없이 2차 가공 및 영리적인 이용을 금하고 있습니다.

이 글이 좋으셨다면 구독&좋아요

여러분의 “구독”과 “좋아요”는
저자에게 큰 힘이 됩니다.

subscribe

신황규
신황규 IT테크놀로지 전문가

삼성SDS 개발실

애자일의 다양한 프랙티스를 통해, 삼성이 보다 좋은 S/W를 개발할 수 있도록 개발문화를 개선하는 일을 하고 있습니다.