스토리보드조차 작업할 줄 모르면서 알고리즘, 프로세스를 디자인하려 하지 말아라

요즘 온라인 서비스 프로젝트를 하다 보면 생각보다 현학적 자세를 가진 기획자들이 많은 걸 볼 수 있습니다. 지금 막 기획을 시작한 사람 같은데 있어 보이는 장표를 그리고 이를 보며 만족하는 모습을 보게 됩니다. 물론 스토리보드는 내용이 맞지 않고 기본적인 정의조차 되어 있지 않습니다.

 

 

기획의 기본

 

기획의 기본은 목표에 대한 구체화 및 이를 달성하기 위한 과정의 설계입니다. 그러나 온라인 서비스 현장에서 요즘 많이 볼 수 있는 모습은 잘하지도 못하는 알고리즘이나 프로세스를 그려놓고 있는 것입니다.

 

이러한 알고리즘과 프로세스는 스토리보드의 흐름을 깨 놓고 기능의 프로세스를 파악하는데 혼란만 줍니다. 더 심각한 것은 기본적인 온라인 서비스 기획서 구성조차 할 줄 몰라 페이지에 따라 메뉴를 다르게 표현한다거나 같은 메뉴가 다른 프로세스 상에 존재하는 등 기본의 기본조차 지켜지지 않은 스토리보드를 작성하고 있다는 점입니다.

 

보통 이런 기획서는 갑이 작성하여 을에게 주거나, 을이 작성하여 병에게 줍니다. 그리고 프로젝트 비용 또는 지체상금, 계약 이행의 조건을 걸어 은근히 압박을 합니다.

 

 

프로세스와 스토리보드

 

프로세스가 잘 작성되었다면 스토리보드의 작성은 매우 쉬워집니다. 프로세스 내용에 따라 살만 붙이면 되기 때문입니다. 그러나 프로세스가 잘못되었다면 스토리보드의 흐름은 엉망이 됩니다.

 

결국 프로세스가 디자인이 있는데 스토리보드가 엉망이라면 프로세스가 잘못되었거나, 스토리보드 작성 기획자가 프로세스를 이해하고 있지 못하는 것을 의미합니다. 만약 프로세스와 스토리보드를 만든 기획자가 같다면 개발 목표 서비스에 대한 이해가 없는 상태로 현학적 자세로 프로세스를 그린 것이라 생각할 수 있습니다.

 

블로그나 유튜브를 통해 또는 다양한 학습 플랫폼을 통해 공부할 수 있는 상황이 되는 요즘 이런 모습은 더 많이 나타납니다. 대부분의 블로그나 유튜브 도는 학습 플랫폼의 내용은 깊이가 있는 것이 아닌 돈을 벌기 위한 과장된 내용이 상당하기 때문입니다.

 

이렇게 기획에 대해 글을 쓰고 있는 저도 어려워하는 알고리즘조차 너무나 쉽게 작성하고 스토리보드에 넣는 자심 감은 이 때문이라 생각할 수밖에 없습니다.

 

  

서비스 개발 모듈을 이야기하고 사용할 모듈을 정의하지 않는다

 

 현학적이라 느끼는 이유는 또 있습니다. 이런 스토리보드에는 모듈 사용에 대해 적으면서 어떤 모듈을 사용할지 정의하지도 알아보지도 않고 있습니다. 오히려 모듈을 개발하라는 듯이 과정과 화면을 그려놓고 있습니다. 

 

그러다 보니 쓸데없는 곳에서 내용이 길어지고, 쓸데 있는 부분을 빠뜨리게 됩니다. 

 

스토리보드 내용은 중간중간 끊기도 흐름을 이해하기 어렵게 됩니다. 더 큰 문제는 이런 스토리보드는 기획자의 상상 속에서 또는 다른 서비스의 모습을 베낀 내용이라는 것입니다. 때로는 어떤 회사가 수 십억의 개발비를 들여, 수년간, 수 십 명의 직원들과 고생하면서 만든 서비스를 화면 하나 그려놓고 다 만들었다 생각하기도 합니다.

 

당연히 다른 서비스에 있는 기능 플로우기에 고민 없이 그린 것이므로 어떤 모듈을 사용할지 고민할 필요가 없었던 것은 아닐까 생각 듭니다. 그 기능 흐름을 만들기 위해 고민하고 밤새워 개발했던 개발자들의 노고는 회원가입 후 로그인해서 본 것만으로 다 기획했다고 생각하는 것은 오만을 넘어 기획자로 위험한 행동이라 생각합니다.

 

 

서비스 정의, 정책, 기능 정의 등 기본에 충실하자

 

물론 이 블로그에서 서비스 프로세스에 대한 이야기를 했습니다. 서비스 프로세스를 이해하기 위해 20여 년 마케팅 기획과 온라인 사업 기획, 서비스 기획, 개발 기획 등 수많은 프로젝트를 진행하면서 성공과 실패를 통해 학습을 해 왔습니다. 이를 블로그 내용 몇 개를 본 것 만으로 알 수 있다고 생각하는 것은 자신에 대한 오만입니다.

 

서비스 프로세스를 만들기 위해서 서비스를 정의할 줄 알아야 하고, 정책을 이해할 수 있어야 합니다. 여기서 나오는 기능에 대해 알아야 하며 서비스 정의, 정책, 기능의 관계를 복합적으로 그릴 수 있어야 합니다.

 

과거 공대생일 때 단지 족보라 불리는 과거 문제와 답을 외우면 시험을 풀 수 있다 생각하는 학생들을 많이 보았습니다. 간단한 문제인 경우 족보가 해답일 수 있습니다. 그러나 복잡한 문제는 족보 또한 해답이 될 수 없습니다.

 

한 교수님은 미리 시험에 낼 문제를 알려줍니다. 그러면 학생들은 족보를 찾아 외우고 시험에 들어옵니다. 그럼 교수님은 변수의 범위를 살짝 바꾸는 형태로 문제를 비틉니다. 그러면 과거 족보는 문제를 푸는데 아무 소용이 없게 됩니다.

 

온라인 서비스 시장도 이와 같습니다. 사용자 1위 서비스가 인기를 끌던 시기와 지금의 시장은 변수의 범위가 다릅니다. 또한 온라인 서비스는 생각보다 복잡한 요소들의 상호작용에 의해 인기가 결정됩니다.

 

그러므로 단지 사용자 많은 서비스 몇 개를 사용해 보았다는 것만으로 앞으로 인기 있을 서비스를 만들 수는 없습니다. 오히려 현재 1위 서비스는 자신의 노하우를 알려주는 척하면서 비슷한 서비스를 만들도록 유도할 것입니다. 비슷한 서비스를 다른 기업이 만들어 서비스한다는 것조차 사용자들에게는 기존 서비스의 우수함을 인지시키는 요인이 되기 때문입니다.