애자일은 정말 디자인을 배제하나요?

본문은 요즘IT와 번역가 Chase가 함께 만든 해외 번역 콘텐츠입니다. 필자인 Shamsi Brinn는 UX 분야에서 일하면서 여러 웹 프로젝트를 담당하고 있으며, 디자이너와 개발자들이 서로 협업할 수 있도록 열정적으로 돕고 있습니다. 이번 글은 훌륭한 개발 방법론 중 하나인 '애자일'에서 다소 홀대받는 디자인 업무를 어떤 방법으로 대처해야 하는지 설명하고 있습니다. 어떤 방식으로 애자일의 단점을 보완하는지 함께 살펴보겠습니다.

디자인을 배제하는 애자일에 대처하는 방법

먼저 간략히 제 소개를 하겠습니다. 저는 UX 분야에서 일하고 있고, 여러 웹 프로젝트를 리딩하고 있습니다. 그리고 사실 이 글의 제목과 정반대로 애자일이 없던 때로는 절대 돌아가고 싶지 않을 정도로 애자일을 사랑합니다.

그런데도 이 글에 애자일에 다소 회의적인 제목을 붙인 것은 이유가 있습니다. 애자일은 소프트웨어나 웹 개발 조직에게는 훌륭한 방법론이지만 일반적으로 디자인과 탐색 단계(discovery)[1]는 홀대하기 때문입니다. 애자일 방법론에서 탐색은 이미 이루어졌다고 가정하고, 몇 가지 목표와 러프한 스펙 문서가 준비되면 프로젝트를 시작합니다.

그런데 이렇게 작성된 스펙이 사업 목표와 유저의 니즈에 부합하는 최적의 솔루션인지 검증되었다고 할 수 있을까요?

애자일의 단점을 보완하는 방법

보통 디자인 업무를 홀대하는 애자일을 보완하기 위해 고안된 몇 가지 디자인 방식을 소개하겠습니다.

‘디자인 스프린트’는 보통 간편하게 2주 정도로 진행하는 업무 기간입니다. 이 기간에 모든 탐색 단계를 끝내는 것을 목적으로 하고, 마지막에 산출물 전달이 이루어집니다. 컴팩트하고 열정적인 이 방법은 훌륭하지만, 근본적으로 짧은 기간의 워터폴 방식이라 애자일과는 조금 다릅니다.

‘스프린트 제로’는 디자인 스프린트와 유사하지만 조금 더 애자일합니다. 한 번의 스프린트[2]를 통해 참여자들이 앞으로 어떤 일을 할지에 대해 정립합니다. 다만 팀원 전체가 참여하지도 않는 단 한 번의 스프린트로는 업무에 충분하지 않을 수 있습니다. (스프린트 제로에 대해 더 알고 싶다면 별도의 글을 참고해주세요)

‘XP’는 위에 소개한 두 방식과 다르게 디자이너를 ‘반복적인 업무(Iteration Cycle, 이터레이션 사이클)’를 하는 팀에 포함시킵니다. XP에 참여한 디자이너는 팀에 소속되어 작은 산출물 단위로 작업합니다. 하지만 작은 단위의 빠른 산출물에 중점을 두기 때문에 UX 연구를 위한 시간이 없기 때문에 탐색과 검증이 여전히 부족합니다.

제가 가장 좋아하는 디자인 방식은 ‘듀얼 트랙 애자일(Dual Track Agile)’입니다. 디자인과 탐색 업무가 먼저 진행되었기 때문에 디자이너와 개발자가 스프린트와 같은 빠른 속도로 협업할 수 있습니다. 이 방식이 아쉬운 부분은 디자이너와 개발자 사이의 ‘공유 언어’가 없다는 점입니다(공유 언어에 대한 개념은 다음 문단을 참고해주세요).

듀얼 트랙 애자일 방식은 디자이너와 개발자를 한 팀이 아닌 긴밀한 협업조직 정도로 인식하는데, 디자이너가 개발자와 커뮤니케이션을 위해 일회용 산출물을 작성하는 데 시간을 낭비하게 됩니다.

노 핸드오프 방식

저는 듀얼 트랙 애자일의 변형된 방식을 우연히 사용하게 됐고, 이를 ‘노 핸드오프(No Handoff)’라고 부르고 있습니다. 노 핸드오프 방식은 디자인과 개발 사이의 긴밀한 협업을 강조하는 것에 더해 프로젝트 첫날부터 프로토타입을 만들도록 합니다(프로토타이핑에 대한 훌륭한 리뷰를 보려면 Alberto Savoia의 The Pretotyping Effect를 살펴봐 주세요). 그리고 이 프로토타입은 점진적 개선을 통해 최종 제품이 됩니다.

프로토타입의 가장 큰 장점은 사용자, 디자이너, 개발자, 임원진까지 모든 관계자가 프로젝트 진행 상황을 이해할 수 있게 하는 ‘공유 언어’로써의 기능입니다. 눈으로 볼 수 있는 프로토타입이 있기 때문에 모든 이해 관계자들이 각자의 상상이 아닌 실재하는 것을 기준으로 정확한 소통을 할 수 있는 것이죠.

"빠르게 실패하면 쉽게 복구할 수 있고, 몇 가지 사항을 변경하고 가정을 다시 테스트하거나 다음 아이디어로 넘어갈 수 있습니다."

— Alberto Savoia

프로토타입은 모든 단계에서 테스트할 수 있는 장점도 있습니다. 초기 단계에서부터 사용자 테스트를 할 수 있고 정적인 와이어프레임을 사용한 테스트보다 유용한 피드백을 얻을 수 있습니다. 또한, 기본적인 프론트엔드 개발이 가능한 디자이너라면 와이어프레임을 빠르게 프로토타입으로 만들어서 개발자에게 프로덕트의 구현 목표를 보여줄 수 있습니다. 이는 상호 이해의 차이를 좁히는 리소스 낭비를 줄일 수 있습니다.

MVP 프로토타입의 또 다른 이점은 디자인을 단계적으로 표현할 수 있는 것입니다. 워터폴 방식처럼 디자인을 다 끝내고, 유저를 대상으로 하는 기능 테스트를 진행하면 원하는 피드백을 얻지 못할 수 있습니다. 유저가 눈에 바로 보이는 디자인에 더 집중하기 때문입니다. 예를 들어 속도와 기능에 대한 테스트에서 “그런데 저는 이 색이 마음에 안 드네요"와 같은 피드백만 듣게 될 수도 있습니다. 하지만 각 기능의 검수를 마친 후 디자인하는 순서로 일이 진행되면 테스트에서 의도된 피드백을 얻을 수 있습니다.

“우리는 주변의 문화 산물(artifacts)에서 우리의 정체성을 찾습니다.”

— Kyle Chayka

심리적으로 시각적 변화는 유저가 공격적으로 느낄 수 있어 주의가 필요합니다. 이 점에서 프로토타이핑은 훌륭한 수정 관리 방식입니다. 시각적 변화의 중요성에 관련해서 최근 Kyle Chayk가 트위터 스타일 업데이트에 대해 기고한 글을 인용하겠습니다.

“우리는 주변의 문화 유물(artifacts)에서 정체성을 찾습니다. 그리고 그 유물의 외형이 급변한다면 우리가 디지털 공간에서 공유하는 것들이 정말로 우리의 것이라고 느끼기 어렵습니다. 즉, 시각적 변화로 인해 사용자가 제품을 낯설게 느끼게 되면 소속감조차 잃어버릴 수 있습니다. 반면 변화를 점진적으로 도입하면 사용자가 자연스럽게 적응할 수 있습니다. 또, 피드백을 위한 시간을 제공하기 때문에 모두가 원하는 방식으로 변화할 수 있습니다.”

결론

이 글을 읽는 여러분이 표준 애자일에서 제한된 역할과 UX의 부족에 불만을 품은 디자이너이거나, 스펙 문서에 기반한 추측보다 더 실제 검증과 방향성을 필요로 하는 개발자라면, 새로운 애자일 방식을 고려해 보세요.

이 글에서 소개된, 그리고 제가 사용한 노 핸드오프 방식은 디자인과 개발 간의 상호의존성을 보장합니다. 애자일 방식에 지속적인 발견과 검증의 힘을 더한 노 핸드오프를 사용하면 프로젝트를 성공으로 이끌 수 있을 것입니다.

[1] 고객의 문제를 정의하고 솔루션을 탐색하고, 검증하고자 하는 가설과 목표를 세우는 단계
[2] 반복적인 개발 주기. 회사에서 정하는 이터레이션이 개발 주기가 된다. 계획 회의부터 제품 리뷰가 진행되는 날짜까지의 기간이 1 스프린트이다.

<참고>

Sohaib, Osama & Solanki, Hiralkumari & Dhaliwa, Navkiran & Hussain, Walayat & Asif, Muhammad. (2019). Integrating design thinking into extreme programming. Journal of Ambient Intelligence and Humanized Computing. 10. 10.1007/s12652–018–0932-y.

“Are Agile Methods Good for Design? | ACM Interactions.” ACM Interactions, 

Chayka, Kyle. “Why Twitter’s New Interface Makes Us Mad | The New Yorker.” The New Yorker, The New Yorker, 19 Aug. 2021,

“Dual Track Development is not Duel Track.” Jeff Patton and Associates,

“The No-Handoff Manifesto.” No Handoff — Stop Throwing Your Work over the Fence!, 

<원문>

Is Agile an anti-design pattern?

위 번역글의 원 저작권은 Shamsi Brinn에게 있으며, 요즘IT는 해당 글로 수익을 창출하지 않습니다.