디자인 스프린트 — 5일 프로세스의 현실적 축소판

디자인 스프린트라는 이름을 들으면 5일 내내 회의실을 비워야 한다는 부담부터 든다. 월요일부터 금요일까지 팀 전체가 다른 업무를 전부 미뤄두고 한 문제에만 매달리는 방식은 이론적으로는 이상적이지만, 여러 프로젝트를 동시에 진행하는 팀에서는 현실적으로 불가능에 가깝다. 그렇다고 디자인 스프린트를 포기할 필요는 없다. 원래 5일짜리 프로세스가 왜 그렇게 설계됐는지 이해하면, 무엇을 남기고 무엇을 줄여도 되는지 판단할 수 있다.

1. 5일을 통째로 비울 수 있는 팀은 없다

구글 벤처스가 정리한 원조 디자인 스프린트는 실리콘밸리의 특정 조직 구조를 전제로 만들어졌다. 이해관계자를 한자리에 모을 수 있고, 5일 동안 다른 업무를 완전히 중단할 수 있는 팀이 대상이다. 그러나 여러 클라이언트 프로젝트를 병행하는 조직이나, 담당자가 다른 업무와 겸직하는 팀에서는 이런 전제 자체가 성립하지 않는다. 5일을 그대로 따라 하려다 첫날부터 일정이 무너지고, 결국 스프린트 자체를 포기하는 경우가 흔하다.

2. 무엇을 남기고 무엇을 자를 것인가

원조 스프린트의 다섯 날은 각각 문제 정의, 아이디어 스케치, 결정, 프로토타입, 테스트에 해당한다. 무엇을 풀어야 하는지 정하지 않고 시작하면 나머지 나흘이 방향을 잃고, 테스트를 생략하면 스프린트의 결과를 검증할 방법이 없어진다. 반대로 아이디어 스케치와 결정 단계는 하루로 합칠 수 있다. 여러 사람이 각자 스케치하고 바로 그 자리에서 투표로 방향을 정하면 이틀 걸리던 과정을 하루로 줄일 수 있다.

절대 줄이면 안 되는 것

문제 정의와 테스트. 방향을 잃거나 결과를 검증할 방법이 사라진다.

하루로 합칠 수 있는 것

아이디어 스케치와 결정. 각자 스케치하고 그 자리에서 투표하면 이틀이 하루로 줄어든다.

3. 압축 스프린트 진행 순서

실전에서 쓸 수 있는 3일 압축판은 이렇게 구성된다. 5일이 3일로 줄어도 문제 정의와 테스트라는 핵심 축은 그대로 유지된다.

1일차 오전 — 문제 정의에 온전히 쓴다

1일차 오후 — 곧바로 개별 스케치를 진행한다

2일차 — 스케치를 모아 팀 전체가 투표로 방향을 정하고, 종이 수준의 간단한 프로토타입을 만든다

3일차 오전 — 최소 버전 사용성 테스트를 다섯 명에게 진행한다

3일차 오후 — 결과를 정리해 다음 작업으로 넘긴다

4. 왜 원래 5일이었는가

구글 벤처스의 제이크 냅이 정리한 디자인 스프린트는 원래 실리콘밸리 스타트업이 겪던 특정한 문제에서 출발했다. 회의는 많은데 결정은 나지 않고, 아이디어는 쌓이는데 검증할 방법이 없는 상황을 해결하기 위해 닷새라는 마감을 강제로 부여한 것이다. 즉 5일이라는 숫자 자체보다 중요한 것은 마감을 두면 결정이 미뤄지지 않는다는 전제였다.

이 전제를 이해하면 압축판을 만들 때도 원칙이 분명해진다. 날짜 수를 줄이더라도 각 단계마다 그날 안에 반드시 결론을 내야 한다는 압박은 그대로 유지해야 한다. 압축의 대상은 일수이지, 마감의 강제성이 아니다. 스프린트를 3일로 줄이면서도 이 마감의 압박을 함께 완화해버리면, 짧아진 일정 안에서 오히려 결정이 더 늘어지는 역설이 생긴다.

5. 스프린트에 대한 흔한 오해

가장 흔한 오해는 스프린트를 진행하기만 하면 좋은 결과가 자동으로 나온다는 믿음이다. 스프린트는 의사결정 구조를 압축하는 도구일 뿐, 좋은 아이디어를 보장하는 장치가 아니다. 참가자들이 문제를 충분히 이해하지 못한 채 스프린트에 들어가면, 사흘이든 닷새든 비슷한 수준의 결론에 머무른다.

또 다른 오해는 스프린트가 리모트 환경에서는 효과가 떨어진다는 생각이다. 화이트보드 대신 온라인 협업 도구를 쓰고, 스케치와 투표를 비동기로 진행하도록 일정만 조정하면 원격 팀에서도 같은 구조를 무리 없이 적용할 수 있다.

동일 공간 스프린트

화이트보드와 대면 투표로 즉각적인 합의를 끌어낸다. 참가자 일정을 맞추기가 가장 어렵다.

원격 스프린트

비동기 스케치와 온라인 투표로 시간대가 다른 팀원도 참여할 수 있다. 실시간 논의의 밀도는 낮아진다.

6. 마치며

압축 스프린트의 가장 큰 위험은 끝난 뒤 결과물이 실제 개발 일정에 반영되지 않고 흐지부지되는 것이다. 스프린트는 통찰을 얻는 과정이지 그 자체로 완성된 결과물이 아니라는 점을 팀 전체가 합의하고 시작하는 것이 중요하다.

문제 정의와 테스트 단계를 줄이지 않았는가

참가자 전원이 3일 동안 다른 업무를 실제로 비웠는가

스프린트 결과를 넘겨받을 담당자와 일정이 정해져 있는가

테스트 참가자를 스프린트 시작 전에 미리 섭외했는가

스프린트 결과물이 다음 스프린트 계획에 실제로 반영됐는가

디자인 스프린트는 정해진 5일을 그대로 따라야 완성되는 의식이 아니다. 우리 팀이 실제로 비울 수 있는 시간에 맞춰 문제 정의와 테스트만은 지키는 압축판을 설계해보자.