평소 스마트폰 앱 업데이트가 필요하다는 알림을 보신 경험이 있으실 겁니다. 대부분 디지털 서비스들은 길게는 몇 달, 짧게는 몇 주 사이로 업데이트를 합니다. 이는 단순 버그 수정에 그칠 때도 있지만, 신 기술/기능의 실험장이 되기도 합니다. 그렇게 디지털 서비스는 늘 '조용히 조금씩, 반복적 지속적으로' 진화하며 생존하고 있습니다.
업데이트 주기는 서비스의 생명력으로 볼 수 있습니다. 페이스북 앱의 경우 한달에 두 세번 업데이트가 이루어집니다. 보통 업데이트 후 변화는 너무 작은 부분이어서 일부러 찾긴 어렵고 무심코 사용하다가 "어라? 이런게 바뀌었네?" 하는 정도입니다. 하지만 지금부터 200번 업데이트 이전의 페이스북 앱을 들여다 보면, 마치 고대유물 같습니다. 반대로 업데이트가 오래 없는 경우 열에 아홉은 서비스 자체의 생명력이 끊어진 것을 볼 수 있습니다.
페이스북 모바일 앱의 현재-과거
물론 작은 업데이트에만 집중하진 않습니다. 서비스 자체의 전략 변경/개선이 필요할 땐 오랜 작업을 거쳐 연간 단위의 대규모 리뉴얼이 이루어지기도 하지요. 2년 전 인스타그램 디자인이 완전 바뀐 것을 기억하실 겁니다. 그 이후에는 페이스북처럼 작은 업데이트들을 통해 기능 실험을 반복하고 있습니다. 지금은 일상화된 동영상 프로필, '검색'의 동영상 컨텐츠 타일링 방식, 매번 새로운 컨텐츠를 보여주는 타임라인 로직 등이 대표 예 입니다. 이렇듯 디지털 서비스에겐 먼 미래 뿐만 아니라 일상에서 숨을 쉬는 것도 중요합니다. 싸이월드나 프리챌, 마이스페이스 같이 시대를 풍미했던 서비스들은 무엇보다 온전히 정점에서의 정체가 길었고, 늦었다 했을 때 잘못된 선택이 몰락을 가속화 시켰습니다.
리뉴얼 전 인스타그램
# 변화를 위한 방법들
디지털 서비스 개발의 전통적 방법론은 [폭포수 모델]입니다. '기획-설계-구현-테스트-운영'의 프로세스를 순차로 수행하는 방식인데, 이는 철저히 계획된 분업을 전제로 합니다. 많은 기업들이 보통 활용하지만, 속도와 이슈 대응 등에 있어 치명적 문제점들이 많은 모델이기도 합니다. 무엇보다 긴 일정이 필요합니다. 때문에 작은 기업을 위한 [애자일], [린] 등 새로운 방법론들도 존재합니다. 아이디어를 최소의 형태만 갖춰 빠르게 상용화 후, 반복적 테스트와 수정을 통해 점점 완성도를 끌어올리는 방식이지요. 다만 사용자에게 "미완성 상태의 출시"를 해야 한다는 점이 허들이며, 전체 프로세스에 도입되어야 하기 때문에 큰 단위의 조직/회사엔 적용이 어려운 문제가 드러나고 있기도 합니다.
Walterfall vs Agile
이런 상황에서, 구글에선 [디자인 스프린트]라는 새로운 방식을 제안합니다. 150개 이상의 스타트업과 협업하기 위해 구글 벤처스에서 개발한 방법론 인데, 현재는 구글 전사의 핵심 방법론 적용되었습니다. 우선 해결하고자 하는 문제점을 명확히 정의하고, 해결책을 디자인으로 검증하는 과정입니다. 기존 린 방식에서 서비스 구현/출시 이전 단계인 디자인을 좀 더 확장하여 집중한다고도 볼 수 있습니다. 어떻게 보면 기존의 디자인 프로토타이핑과 유사하지만, 결정적으로 1주일 단위의 반복과 좀 더 다양한 이해관계자의 참전이 필요하다는 것이 차이가 있습니다.
최초 입안자 Jake Knapp의 스프린트 소개
# 스프린트 방법
구글에서 제시되는 스프린트의 이상적 조건은 다음과 같습니다.
a. 다양한 기술과 관점의 이해관계자(개발자, 마케터, 디자이너, 운영자 등) 4~5명 / 의사 결정권자 1명
b. Understand > Sketch > Decide > Prototype > Validate 총 5단계
무엇보다 멤버 구성이 제일 중요합니다. 디자이너들만으로 제작된 프로토타입은 이후 현실성을 확보하는데 많은 에너지가 필요합니다. 때문에 다양한 기술과 관점의 이해관계자와 의사결정권자의 참여로 타당성을 검증하고 결정해가며 진행해야 스프린트의 의미가 있습니다.
그리고 단계별 소요시간을 최대 하루로 제한함으로써, 총 1주일의 사이클을 유지합니다. 옳고 그름을 따질 시간에 'moving forward'하여 검증을 하라는 거지요. 하나의 아이디어를 결정하고 최선의 안을 정해진 시간내에 빠르게 정리해야 합니다. 중간에 틀렸거나 빠진 것이 있다면 다음 검증에 다시 확인할 기회가 찾아올 것입니다.
1. Understand (How might we…)
목표를 수립하고 문제를 정의하는 단계입니다. 고객 인터뷰나 경쟁사 리서치가 필요한 경우엔 사전에 수행합니다. 고객의 문제를 해결하기 위한 질문들을 각자 포스트잇에 적고 하나로 모은 다음, 일주일 동안 해결할 중요한 질문 하나를 투표로 결정합니다.
2. Sketch (Crazy 8's)
정의된 문제의 솔루션을 가능한 빠르고 많이 그려보는 단계입니다. 참가자들은 A3용지를 8칸으로 접고, 한 칸에 1분 씩 아이디어를 그립니다. 그림을 못 그리거나, 정교하지 못해도 상관 없습니다.
3. Decide (Dot voting)
스케치들 중 가장 좋은 아이디어를 투표로 결정합니다. 유사한 아이디어는 적절히 그룹핑 하여, 하나의 아이디어로 묶을 수도 있습니다. 아이디어가 결정되면 아이디어를 보다 구체적인 사용자 시나리오를 짜냅니다. 이때 화면 아래의 시스템 문제는 개발관련 멤버가 가능 여부를 판단합니다.
4. Prototype
결정된 시나리오로 프로토타입을 만듭니다. 이때 프로토타입은 절대 완벽할 수 없습니다. 모든 기능과 디테일한 정의가 아닌, 하나의 아이디어만이 실제처럼 보이면 됩니다. 완벽함에 집착하는 순간 프로토타입은 몇 주가 되어버립니다.
5. Validate
핵심 질문이 프로토타입으로 해결 되는지 검증할 시간입니다. 제품에 편견없이 반응해줄 소규모의 테스터에게 프로토타입을 시연합니다. 그리고 이들 로부터는 '크리틱'이나 '피드백'이 아닌, 경험하는 행태와 느낌을 캐치해야 합니다.
검증 후엔 멋져 보였던 아이디어가 사실 그렇지 못했음이 드러나기도 합니다. 이때는 몇 번이고 다시 돌아갈 수 있어야 합니다. 중요한 것은 성공여부가 아닌 반복검증에 있습니다. 반복 자체가 비효율 적이라 생각될 수도 있지만, 실제 아이디어를 제품화 하는데 까지 필요한 시간과 노력을 고려한다면, 잘못을 빨리 발견하고 바로 잡는 것은 오히려 기회라 볼 수 있습니다.
# 마치며
지난 1월, 디지털 디자인팀에선 구글 UX 리드 디자이너인 조나단 정을 만나, 구글 디자인 실무의 목소리를 들을 기회가 있었습니다. 개인적으로 글로 정의된 방법론과 현장에의 간극을 어떻게 줄일 수 있을지 궁금하였는데, 그들 내부에서도 수많은 스프린트가 동작하며 다행히(?) 저마다의 상황에 맞게 쓰여지고 있는 중이었습니다. 어떤 상황이든 중요한 것은 하나의 문제 해결을 위해 바로 'moving forward'하는 것. 그리고 궁극적으로는 디지털 생명력을 지속성 있게 유지하는 것이 목표가 되어야 하지 않을까 합니다.