기획자, 디자이너가 애자일 소용돌이에서 살아남기 (1)

UX와 애자일을 결합하는 방법, 듀얼 트랙 애자일

백로그 그루밍 세션 中...

"사용자 스토리는 기획, 디자인 과정도 다 포함하나요?"

"네, 기획, 디자인, 개발 모든 과정을 포함해서 함께 플래닝 포커로 스토리 포인트를 산출해야 합니다."

"(기획 디자인 개발을 2주 스프린트 안에 다 한다고?) 네..."

몇 주 뒤...

"기획, 디자인, 개발 일감을 다 쪼개 주세요. 이걸 한 스프린트에 다 진행할 수 없어요!"

애자일? 한 번만 더 말해봐...

혹시 유사한 경험이 있으신가요? 이런 풍경은 스크럼(Scrum)이 도입된 곳에서 흔히 발견할 수 있습니다. 기획자라는 K-직무 개념이 존재하는 한국에만 국한된 현상이 아닙니다. 미국 실리콘 밸리에도 UX를 담당하는 사람들이 이러한 문제를 제기하곤 했죠. 저희도 비슷한 문제를 겪었습니다. 교재처럼 살펴보는 에센셜 스크럼(Essential Scrum, 한글 번역서도 있습니다.)에도 납득할 만한 해법은 찾기 어려웠죠. 애자일은, 그중에서도 스크럼은 개발자 친화적인 방법론으로 보였습니다. 2주, 3주 단위의 타임 박스(Time box)에서는 개발자 외 직무를 위한 공간은 없어 보였죠.

개발에 앞서 기획이나 디자인 같은 과정이 선행하는 것을 Big Design Up Front(이하 BDUF)라고 부릅니다. BDUF는 달리 말하면 워터폴(Waterfall) 방법론이라고 할 수 있습니다. 한편 애자일은 BDUF를 지양하고 창발적 디자인(Emergent Design)을 지향하죠. 전자는 순차적인 디자인이라면 후자는 필요에 따라서 짧은 이터레이션을 통해 산출물을 만드는 반복적인 디자인을 지칭한다고 볼 수 있습니다. 사실 이 개념도 우리가 생각하는 UX 디자인을 가리키는 게 아니라, "개발 설계" 차원에서의 디자인을 가리키는 의미에 가까운데요. BDUF와 창발적 디자인 논의 사이에서도 UX, UI의 영역은 찾아보기 어려운 것이죠.

출처: Big Design Up Front versus Emergent Design by Anthony Langsworth (2013)

사실 여기까지 들어도 창발적 디자인은 디자인 과정을 선행하지 않는 것(Zero design up-front)처럼 느껴지기 일쑤입니다. 디자인을 선행하지 않는다면, 그럼 디자인은 언제, 어떻게 하지? 하는 의문이 여전히 잔존합니다. 기능 주도 개발(Feature Driven Design, FDD)에서 이러한 의문에 대한 해답으로 제시하는 것이 JEDI(Just Enough Design Initially)입니다. 필요한 만큼만 선행적으로 디자인하자는 것이죠. 이 같은 논의들은 애자일과 UX 과정을 병합하기 위한 출발점이 됩니다. 어떻게 하면 애자일 선언 이면의 원칙(12가지 원칙)을 지키면서, 디자인 과정을 선행할 수 있을까요?

가령, 스크럼에서의 스프린트를 절차적으로 나누면 어떨까요? 기획 디자인 스프린트를 앞서 하고, 개발 스프린트를 이어서 하는 것이죠. 이것을 시차 스프린트(Staggered sprints)라고 부릅니다. Desirée Sy와 Lynn Miller는 애자일과 사용자 중심 프로세스(User-centered Design Process, UCD)를 결합해서 이러한 시차 스프린트와 Sprint 0(zero)의 개념을 제안했습니다. 시차 스프린트는 다음 편에서 설명할 몇 가지 개념, 철학과 결합하며 '듀얼 트랙 애자일'로 발전합니다. 사용자 스토리 맵으로 유명한 제프 패튼(Jeff Patton)은 듀얼 트랙 스크럼(Dual-Track Scrum)이라고 불렀죠.

출처 : Adapting Usability Investigations for Agile User-Centered Design by Desirée Sy (2007)

하지만 린 UX(Lean UX)의 저자 제프 고델프(Jeff Gothelf)는 많은 사람들이 시차 스프린트 모델을 잘못 해석하고 적용했다고 말합니다. Desirée Sy는 이 모델에서 디자이너와 개발자의 긴밀한 협력이 중요하다고 주장했지만, 많은 사람들은 이 과정들이 별개로 이루어지고 오직 핸드오프 단계에서만 커뮤니케이션이 발생한다고 착각했다는 것입니다. 잠깐만요. 이건 기획/디자인과 개발을 구분하고 순차적으로 진행하는 미니 워터폴(Mini Waterfalls)이 아닌가요? 다시 BDUF로 회귀한 것만 같습니다.

여기서 애자일 철학을 상기할 필요가 있습니다. 그중에서도 공유된 이해(Shared Understanding)가 중요하죠. 공유된 이해란 제품 팀원들 간에 제품 구현에 필요한 정보를 동기화한 상태를 이야기합니다. 만약 같은 기간(스프린트)에 각자가 다른 문제에 골몰하면, 문제에 대한 공유된 인식이나 경험 같은 것을 얻기가 어려워집니다. 그럼 결국 원활한 핸드오프로 귀결되기도 어렵거니와, 핸드오프가 이뤄진 뒤에도 지속적인 대응과 수정으로 인한 리소스 낭비가 수반하기 일쑤죠. 기껏 교차 기능 조직(Cross-Functional Teams)으로 여러 직무를 묶어놓고, 한 자리에 앉혔는데 소통이 이뤄지지도 않고 딴생각만 품고 있는 상황이 되는 것입니다.

출처 : I’m Glad We All Agree by Jeff Patton  (2018)

문제는 더 있습니다. 공유된 이해가 형성되지 않았을 때는 핸드오프를 위한 문서 작업도 그만큼 늘어납니다. 커뮤니케이션의 공백이 발생한 만큼 작성해서 설명해야 할 문서도 그만큼 비례해서 많아지기 때문입니다. 또한 요구사항 분석 및 기획 단계에서 개발자가 참여하지 않기 때문에, 프로덕트 발견 단계에서 검증해야 하는 것들을 사전에 식별할 기회도 그만큼 줄어들게 됩니다.

인스파이어드(Inspired)의 저자 마티 케이건(Marty Cagan)은 개발에 앞서 4가지 위험을 사전에 식별해야 한다고 말한 바 있습니다. 가치 위험(Value Risk), 사용성 위험(Usability risk), 실현 가능성 위험(Feasibility Risk), 사업 유효성 위험(Business Viabililty Risk)이 그것입니다. 이런 위험들을 식별하는 것은 제품 관리자(Product Managers) 혼자서는 불가능하죠. 릴리즈 이후에 검증 작업이 일어나게 되는 것은 정확히 애자일에서 지양하는 부분이기도 합니다.

출처 : What is Product Discovery? by Feri Fekete (2021)

제프 고델프는 린 UX에서 이러한 단점들을 이야기하면서, 시차 스프린트는 워터폴 조직이 애자일 과정으로 전환하는 단계에서 사용할 수 있는 과도기적 방식이라고 이야기합니다. 이제 좀 해법을 찾은 것 같았는데, 아직도 답은 요원한 것 같습니다. 그러면 어떻게 해야 할까요? 그가 제안하는 방식은 다음 아티클에서 소개하겠습니다. :) 다음 아티클에서는 제프 고델프, 마티 케이건 등 현업에서의 여러 애자일 구루들이 이야기한 해법에 대해서 다루겠습니다.