이 블로그의 앱/웹 기획 관점 정리

개인적으로 어떤 방법이 이론적이나 학문적으로 정답인 기획 방법이라고는 말할 수준은 아닙니다. 단지 다양한 분야의 포지션에서 기획 경험을 서로 비교하고, 또 앱/웹 관련 프로젝트에서의 경험을 바탕으로 제 기획 관점을 정리한 것일 뿐입니다. 이 글에서는 이 블로그의 다양한 기획 관련 글의 이해를 돕고자 배경 정보를 제공드리려 합니다.

 

 

 

왜 앱을, 웹을 기획하는가?

 

제가 다양한 프로젝트에서 기획자 또는 PM/PL을 만나면서 느낀 앱/웹 기획의 목적은 하나가 아닙니다. 크게는 이들이 가지는 프로젝트 상 미션에 의해 기획의 목적이 결정되기도 하지만, 다분히 개인적 욕망에 의해서도 기획 목적은 결정되기도 합니다.

 

개인적인 욕망이 해당 프로젝트 기획에 투영되는 경우 자신을 변호하기 위해 또는 어필하기 위해, 남에게 책임을 떠넘기기 위해, 승진을 위해, 권력욕에 의해 등 기획이 앱/웹 서비스에 기여하는 본질적 기획의 역할보다는 기획자와 기획자, 프로젝트 내에서 상호작용하는 관계 속에서 개인적 기획 역할에 치우기는 경우가 대부분입니다.

 

종종 중간 또는 말미에 기획자로 투입되는 경우 이런 상황인 경우 자주 보게 됩니다. 이런 유형의 프로젝트에 들어가면 여러 번 기획팀이 바뀌었던 사정과 이에 대한 설명을 듣게 됩니다. 실력이 부족한 기획자들을 솎아 내었고 이제 실력 있는 기획자들로 팀을 구성하는 중이라고 합니다. 

 

그런데 이미 프로젝트는 여러 달이 지난 상태입니다. 선투입 설계 인력이 투입된 시기까지 하면 상당한 시간이 더 흐른 뒤일 것입니다. 프리랜서를 요하는 앱/웹 프로젝트의 성격 상 이 말은 어패가 있는 설명입니다.

 

또한 투입되었다 철수한 기획자도 해당 프로젝트 관리자들이 뽑았던 사람들이라는 점입니다. 그리고 이미 수개월이 흘렀음에도 작성하다만 스토리보드 외에 남아 있는 기획 내용이 없는 경우가 대부분이라는 것입니다.

 

이점은 기획 분석/설계가 없었다는 것이며, 기획 디렉팅이 말로 진행되었음을 의미합니다. 이러한 여러 상황들을 종합해 보면 철수한 기획자들이 실력이 없었다기보다는 해당 프로젝트의 관리/디렉팅의 문제로 갈등을 겪다 나간 것으로 해석하는 것이 더 합리적일 것입니다.

 

3~4개월 작업하는 기획 프로젝트라도 이런 사람과 사람 간의 관계 속의 기획 작용은 의외로 해당 프로젝트의 목적에 기반한 기획 이상 프로젝트 팀 내부에서 작동하는 것을 느낄 수 있게 되기에 먼저 짚었습니다. 이러한 기획 작용이 프로젝트 시 중요하게 작용하지만 개인적 차이에 따른 변동성이 크므로 우리는 이 블로그에서는 감안은 하되 다루지 않을 것입니다. 이 케이스는 다루게 된다면 앱/웹 기획보다는 조직 설계와 관리 차원에서 일 것입니다.   

 

이외에 실질적인 앱/웹 기획을 하게 되는 이유로 크게 아래와 같이 구분될 수 있다고 생각합니다.

• 앱/웹을 통한 수익을 얻기 위해
• 앱/웹 사용자의 경험을 형성하기 위해
• 앱/웹이 작동되게 개발하기 위해
• 상용자가 보고 이용할 앱/웹 화면을 구현하기 위해

 

'앱/웹을 통한 수익'은 먼저 정리한 '온라인 앱 웹 사업기획 요약'에서 정리했습니다.

 

이후 글들에서 3가지 기획 목적을 다루게 될 것입니다.

그리고 이렇게 기획을 이유를 구분한 것은 어떤 이유냐에 따라 기획의 방식과 내용이 달라지기 때문입니다.

 

 

 

기획자의 사고를 지배하는 것 

 

학력고사를 보고 입학해서 공대 전자공학과를 다니다, 다시 수능을 보고 경영학부에 입학했을 때 가장 힘들었던 부분은 과목의 성격 분 아니라 단어의 목적한 의미의 차이 때문이었습니다.

 

분명 한국말이고 대화는 되는데 단어의 세부적인 의미가 공대와 경영학부는 조금씩 다른 것이 있었습니다. 이 차이는 일상에서는 아무 문제없었지만 시험에서는 문제가 발생하기도 했습니다.

 

정답을 찾는 과정과 정답을 평가하는 방식에도 차이가 있었습니다.

 

경영 한 수업에서 낸 우리 팀의 보고서는 당시 낮은 평가를 받았습니다. 그러데 1년 후 그 보고서는 같은 수업을 듣는 다른 학생들이 참고하는 보고서가 되었습니다. 이 보고서는 시나리오 경영 보고서였는데 당시 매우 잘 나가던 대기업의 위기를 시나리오 분석을 통해 지적하고 그렇지 않으면 조만간 위기를 맞을 것이라는 내용이었습니다. 당시 그 대기업은 잘 나가는 상황이었으므로 보고서 점수는 낮았지만, 실제 1년도 안되어 보고서 내용대로 그 기업이 위기를 맞은 것입니다.

 

그런데 만약 공학이었다면 같은 질문의 같은 대답이 올해와 내년 다르게 평가되는 것은 불가능합니다.

 

학력고사와 수능의 기획 관련 부분은 더 드라마틱합니다.

 

대학 입시를 준비하는 과정을 설계하는 것을 기획으로 볼 수 있습니다. 시험의 유형에 따라 3년의 시간을 연습하고 공부합니다. 이러한 시험을 잘 보는 방법이 학력고사와 수학능력시험이 완전히 달랐습니다.

 

그래서 학력고사 방식으로 공부해서 1등을 했던 학생이 수학능력 방식으로 시험을 치르면 10등 밖으로 밀리는 일도 빈번하게 일어났습니다.

 

그러므로 기획을 해야 하는 상황 및 기획 평가 기준에 따라 기회자의 사고와 업무 방식은 확실히 달라지게 됩니다. 그리고 이런 시간이 길면 길수록 사고와 업무 방식 스타일은 굳어지게 됩니다. 그리고 변화된 기획 상황 및 기획 평가 기준에 맞추어 자신의 기획 변화시키기 어려워집니다. 위에서 먼저 언급한 사람과 사라만 개인적 기획이 발생하는 원인이기도 합니다.

 

이는 앱/웹 기획이 아니라 우리가 모두 함께 경험한 고등학생 시절만 보아도 알 수 있습니다.

그리고 학력고사에 수능으로, 또 수능은 왜 그렇게 자주 바뀌는지, 더하여 왜 수시가 생겼는지 또한 교육 기획의 산물입니다.

 

 

 

기획 구분의 이유

 

제가 이렇게 크게는 4가지 유형으로 앱/웹 기획을 구분한 것은 이유가 있습니다.

 

앞서 개인적이라는 단서를 붙였듯, 이 구분은 제가 작업한 프로젝트에서 요구받게 된 기획 작업과 역할들을 차이에 따라 정리한 것입니다. 제 기준 부여된 기획자의 R&R을 차이에 따라 구분한 것이라 할 수 있습니다.

 

그러므로 같은 스토리보드라도 기획자에 따라 내용이 다르다면 다른 기획으로 구분했습니다. 예를 들어 같은 화면을 그린 스토리보드라도 이 화면에 대한 설명과 설계 내용에 따라 다르게 구분하는 것입니다.

 

이 차이는 여러 번 프로젝트를 참여해 본 경험이 있으면 분명히 알고 있을 것입니다.

 

저의 경우 분석/설계를 종종 진행했습니다. 예를 들어 앞서 진행된 프로젝트 내용을 기반하여 추가 작업을 해야 하는 경우 당연히 앞의 프로젝트를 분석한 후 우리 프로젝트를 설계하게 됩니다.

 

이때 저는 기획자이므로 분석의 대상이 전 프로젝트의 기획서가 됩니다. 전 프로젝트 기획서를 보다 의문이 생기면 남아 있던 전 프로젝트 개발자에게 문의하거나, 전 프로젝트 담당자가 모두 철수한 상황이라면 우리 프로젝트 개발자와 협의를 합니다.

 

이런 과정을 통해 기획서 내용의 성격과 특성을 구분했습니다. 그래야 무엇이 부족하고 잘 되어 있는지, 어디서 문제가 시작되었는지 알 수 있기 때문입니다.

 

그리고 회사에서 온라인 사업 기획과 함께 앱/웹의 서비스 기획을 할 때, 내가 투자해서 온라인 서비스를 기획할 때, 그리고 프리랜서로 기획할 때 등 상황에 따른 각 기획자의 R&R을 확인하고 이러한 R&R이 어떤 기획을 도출하게 되는지 분석하였습니다.

 

다행히 저는 이 모든 케이스의 기획을 해본 경험이 있습니다. 물론 이것으로 모든 기획 케이스를 다 경험해 보았다 할 수 있는 것은 아니지만 상황 차이를 알기에는 충분한 정도는 되었다 생각합니다.

 

더해 다른 분야에서의 기획 경험을 추가하여 기획 구분에 활용하였습니다.

 

많은 외주 개발 프로젝트가 보안 환경에서 작업을 하게 합니다  당연히 기획자도 이 보안 환경에서 기획을 해야 합니다. 만약 해당 기획자가 철수한다면 작업 문서들은 프로젝트 관리 시스템에 올리고 개인 컴퓨터는 포맷을 합니다. 원칙적으로 기획 문서를 가지고 나갈 수 없는 환경인 것입니다.

 

그런데 종종 기획자 채용 시 기획 포트폴리오를 요구하기도 합니다. 이 경우 두 기획은 다른 것으로 볼 수 있습니다. 이 또한 또 다른 사례로 차이를 확인할 수 있습니다.       

 

보안 환경 프로젝트라도 디자인은 피그마, 어도비 등을 통해 진행하기도 합니다. 그러므로 디자인은 보안 환경이 아닌 인터넷 환경 또는 외부 환경에서 작업한 후 프로젝트 관리 시스템(PMS)에 적용됩니다.

 

그러므로 보안 환경 프로젝트라도 피그마, 어도비 등 기반 기획이라면 기획자가 자신이 한 기획 내용을 가지고 있을 수 있습니다. 그런데 보안 환경에서 해야 할 기획이 인터넷 환경에서 하는 것과 같을 수는 없습니다. 프로젝트 보안에 문제가 생기기 때문입니다.

 

그래서 이 경우 앱/웹 기능이나 작동 설계나 정책 등이 포함된 기획은 보안 환경에서 진행하고, 이러한 내용들을 정리하여 화면에 투영하는 화면 설계 등의 기획은 피그마 등에서 진행하는 것입니다.

 

결국 이 같은 프로젝트의 기획자라도 보안 환경에서만 기획해야 하는 기획자와 피그마 등 인터넷 환경에서 기획하는 기획자는 다른 기획을 하는 기획자인 것입니다.

 

그리고 기획은 역량으로 확인할 수 있지 산출물로 확인하기는 어렵습니다. 여러 기획자가 투입되는 경우 다른 기획자의 산출물에도 접근할 수 있습니다. 이를 통해 이후 다른 프로젝트 지원 시 이를 자신의 작업으로 이야기하기도 합니다. 

 

물론 같이 한 기획을 딱 잘라 누가 한 것이라 이야기하기 어려울 때도 있습니다. 이런 점을 이용하여 모두 자신이 주도한 것으로 만들기도 합니다.

 

더해 제가 20년 정도 다양한 분야에서 기획을 하면서 항상 존재하는 기획자는 다른 사람이 한 작업을 공식적으로 가로채는 기획자입니다. 이런 기획자는 주로 높은 위치에 있는 경우가 많습니다.

 

이런 기획자에 대한 실무자들의 공통된 말은 모른다는 것입니다. 하지만 TV 등 언론에는 최고 전문가로 나오고 있을 때도 있습니다.

 

그러므로 저는 기획자를 실제 작업하는 기획의 내용과 특성, 목표와 이 과정의 설계를 기준으로 크게 구분하고 있습니다. 이 차이는 산출물이 아니라 달성되는 목표의 결과와 내용으로 정의되어야 한다고 개인적으로 생각합니다.