날아라, 스토리 보드

서비스 기획이라는 것을 처음 시작했을 때 좋았고 가장 크게 기대했던 것은 내가 상상한 것을 그대로 현실화시킬 수 있다는 점이었습니다. 그리고 이것을 바로 가능하게 해주었던 것이 바로 '스토리 보드 Storyboard'라는 것이었습니다. 아무런 배경지식이 없던 생초짜 시절에는 '기획 = 스토리 보드'라고 생각했습니다.  그리고 당연하게 스토리 보드를 잘 그려내는 것에 초점이 맞추어져 있었습니다. 기획에 필요한 전후 과정들을 모두 무시하고 단지 내 머릿속에서 그동안 상상 해오던 것들을 옮겨 그려내기 바빴습니다. 기본적인 개념조차 모른 채 말입니다. 그 결과, 제가 작성했던 스토리 보드에서는 부족한 구성 요소들이 곳곳에서 발견되었고, 논리와 타당성을 찾아보기 힘들었습니다. 저도 일을 하면서 이것에 대한 이해가 점점 늘고 필요한 것들이 하나둘씩 채워지기 시작했습니다. 이번 글에서는 제가 나름대로 바닥부터 굴러다니며 얻게 된 스토리 보드에 대한 생각을 나누어 보고자 합니다.

 

---

스토리 보드란?

스토리 보드는 단어 그대로 이야기를 담는 공간입니다. 우리가 기획하고 구현될 서비스의 형태와 흐름이 담겨 있어야 합니다. 스토리 보드는 영화나 드라마, 애니메이션, 광고 같은 영상물 제작 현장에서 시작되었습니다. 영상물에 담길 이야기를 함께 제작하는 스태프들에게 설명하기 위해 주요 장면을 스케치하여 가이드로 이용한 것입니다. 다른 말로 '콘티'라고 불리기도 합니다. 영상물 기획뿐 아니라 서비스 기획에서도 엄연히 '시나리오'라는 것이 있고 이것들은 상세히 구분될 수 있으며 이야기의 시작과 끝이 존재하는 동일한 과정입니다. 때문에 서비스 기획자들도 스토리보드를 활용하여 서비스에 담길 다양한 이야기들을 구체화하고 있습니다.

 

0. 스토리 보드 작성 도구

스토리 보드를 작성하는 도구로는 PowerPoint, Keynote, GoogleSlide, Axure, Kakao Oven 등이 있습니다. 저는 현재 Axure라고 하는 프로토타이핑 툴을 이용하여 스토리 보드를 문서화하고 있습니다. 첫 번째 회사에서는 Google Slide, 두 번째 회사에서는 PowerPoint 를 사용했습니다. 국내에서는  스토리 보드 작성 도구로서 대부분 PowerPoint 를 활용하고 있을 것입니다. 사용성이 그리 좋다고 할 수는 없지만 아무래도 대부분 회사에서 범용으로 사용되고 있기 때문인 것으로 생각합니다. 저는 몇 가지의 이유로 PowerPoint 가 정말로 불편했고, 몇 가지 이유로 Axure를 선택해 사용하고 있습니다.

 

PowerPoint가 불편했던 이유 (2010 버전 기준)

• 급작스러운 프로그램 종료 시 데이터 유실
• 번거로운 업데이트 버전 관리
• 제한된 캔버스 사이즈
• 이메일이나 메신저를 통해 파일을 주고 받으며 공유해야 하는 번거로움

 

Axure를 선택한 이유

• 페이지별 업데이트 버전 히스토리 관리 가능
• 실제 기능 동작을 쉽고 직관적으로 표현 가능
• 제한이 없는 캔버스 사이즈
• 결과물을 곧바로 퍼블리싱하여 URL을 팀원들에게 공유

 

분명 Axure 또한 진입 장벽이 높고 가격이 비싸다는 등의 단점이 분명 존재하지만, 기획 내용을 여러 가지 형태로 다양하게 구현할 수 있다는 점에 있어서는 조금 더 활용폭이 넓다고 여겨졌습니다.

Axure를 이용하여 작성하고 있는 스토리 보드

 

1. 중심 이야기부터 잘 완성하기

저는 스토리 보드가 협업 여정에 있어서 커뮤니케이션에 가장 중요하고 특화된 도구라고 생각합니다. 제품을 함께 만들어갈 다양한 포지션의 동료들에게 제품에 담긴 이야기와 의도를 잘 설명하기 위해서 언어적 능력이 부족한 저 같은 기획자에게는 찰떡인 셈입니다. 그렇기 때문에 이것에는 콘텐츠, 정책, 레이아웃 배치, 전반적인 흐름 등 서비스와 관련된 거의 모든 내용들이 집약되어 있어야 합니다. 물론 여러 사람들이 쉽고 잘 이해할 수 있게 정리하는 것이 중요합니다. 이상적으로는 별도의 리뷰 없이도 모든 사람이 스토리 보드만 보고도 이해할 수 있어야 하지만.. 단 한 번도 이것에 성공한 적은 없는 것 같습니다.

저는 보통 스토리 보드에 처음부터 너무 많은 세세한 이야기들을 담아내는데 에너지를 씁니다. 뭐든지 기록하고 남겨야 한다는 생각 때문에 스토리 보드는 지저분 해집니다. 유저 플로우를 설계하거나 스토리 보드를 설계할 때면 핵심 플로우 이외에 경우에 눈이 팔려 자꾸만 샛길로 빠집니다. 일단 가장 기본이 되는 메인 스토리를 먼저 완성시키고, 관련된 예외 케이스와 에피소드는 나중에 추가해야 합니다. 기획자 0년 차 시절, 같은 회사에 일하던 기획자 선배가 위와 같은 조언을 해주었던 것이 아직도 생생 합니다. 이 조언을 아직도 유념하며 임하고 있지만, 일을 하다 보면 사실 이 간단한 생각을 부수는 것이 아직도 힘들 때가 많습니다.

 

2. 시작과 끝이 있는 플로우 담기

저는 기획 초창기 시절, 스토리 보드의 활용 단계를 단순 Wireframe을 만들어 내는 것으로 극히 제한했습니다. 하지만 덩그러니 놓여있는 화면과 그것을 설명하는 자잘한 텍스트들은 보는 이로 하여금 답답함을 유발할 수밖에 없습니다. 특히나 UI를 동작하는 형태로 표현할 수 없고 화면 한 페이지, 한 페이지를 모두 작성해야 하는 PowerPoint와 같은 툴을 사용할 때 이 상황은 더욱 심각해질 수밖에 없습니다. 때문에 화면 내에서 이루어지는 흐름, 화면과 화면을 이어주는 흐름. 이 흐름들을 잘 정리한 플로우 차트를 담아 해결할 수 있다고 생각합니다. 이것에는 시작과 끝이 있어야 합니다. 그 과정은 당연히 논리적 이어야 합니다. 저는 이 플로우 차트 작성을 즐겨 이용하는데, 그 이유는 성격이 급해서 단순 두뇌로만 생각을 나열해 보기에는 빈틈이 너무 많기 때문입니다. 어떤 흐름의 과정을 하나하나 나열하다 보면, 차근차근 순서화할 수 있고 빈틈이 생기더라도 그것이 눈에 바로 보이기 때문에 쉽게 인지하고 수정할 수 있습니다.

몇 가지 도형만을 이용해서 플로우 차트를 작성할 수 있다.

 

3. 연필로 스케치 하기 ✍️

툴을 이용하여 스토리 보드를 바로 작성하고 내용을 수정하는 일을 반복하는 것은 많은 비효율성을 초래했습니다. 스토리 보드 작성 초기에는 정해진 것이 많지 않기 때문에 수정 및 보완해야 할 부분이 당연히 많을 수밖에 없습니다. 또한 너무 자세한 내용을 꽉꽉 채우게 된다면 분명 전체를 뜯어고쳐야 하는 순간이 올 수밖에 없습니다. PowerPoint와 같은 툴에서 버튼 이름 하나, 디스크립션 하나 수정하려고 하면.. 생각만 해도 끔찍하네요. 굉장한 리소스 낭비가 아닐 수 없습니다. 다른 프로젝트의 아티클이나 블로그 글들을 읽다 보면 화이트보드나 넓은 캔버스 종이에 스토리 보드를 근사하게 스케치해놓은 것을 종종 확인할 수 있었습니다. 비록 그들처럼 근사하게 잘 그려낼 수는 없지만, 스케치만큼 유연성을 폭넓게 가져갈 수 있는 것이 없다고 생각했습니다. 그래서 웬만큼 내용이 결정되기 전까지는 간단한 스케치를 통해 스토리 보드의 초안을 잡으며 진행하기 시작했습니다. 논외로 연필의 슥슥 하는 소리가 나를 그럴듯하게 만들어주는 것 같기도 했습니다.

UI 스케치를 시도하기 시작한 작년 가을, 정말 비루한 스케치 실력이다.

 

스케치를 통해 어느 정도 결정된 내용이 있다면, 툴을 이용해 스토리 보드에 옮겨 작성한다.

 

요즘엔 빠르게 스케치하여 내용을 공유하고 빠르게 구현해내는 민첩한 형태가 많이 이루어지고 있습니다. 빠른 시일 내에 성과를 내기 위한 단위 조직에서는 스토리 보드를 모두 다 그려놓고 진행하는 프로젝트는 점점 줄어들고 있는 것 같습니다. 별도의 스토리 보드를 작성하지 않더라도 구현 전 단계가 스케치에서 마무리될 수 있다고도 생각합니다.

 

---

마치며,

언제나 결과가 명확하게 보이는 일을 할 수 있다는 것은 기대감을 갖게 합니다. 스토리 보드는 나의 생각을 시각적으로 output 시킬 수 있는 유일한 수단이라고 생각합니다. 내가 만약 개발자였다면 생각한 바를 그대로 코딩 구현하고 작동시켜 보며 생각의 오류를 탐색했을 것입니다. 하지만 기획자는 그 분야 전문성에 제약이 있기 때문에 스토리 보드는 무엇보다 소중한 판입니다. 그런 의미에서 스토리 보드를 작성하고 있는 순간은 '내가 기획자로서 살아가고 있구나'를 몸소 실감시켜주는 순간이라고 생각합니다. 꼭 그 결과가 좋지 않더라도 나의 생각에 대해 피드백을 받고 다른 방향으로 피벗(pivot) 하여 개선할 수 있는 길을 열어줄 수 있다고 생각합니다. 때문에 성장에 있어서도 중요한 기점이 스토리 보드를 통해 발생할 수 있다고 생각합니다. 지금 이 순간에도 PowerPoint 를 켜고 수십수백 페이지 안에 레이아웃을 배치하고 넘버링을 얹으며 디스크립션을 반복하여 작성하고 있을 우리 기획자 분들께 응원의 말씀을 드리며 저의 글이 조금이나마 도움이 됐으면 합니다.

 

---

Axure를 더 잘 알고 싶다면, Axure 장인의 브런치 한 입 어떠세요?

https://brunch.co.kr/@cysstory#articles