그런데 앱이나 웹 사이트를 개발하는데 기획자가 왜 필요한 것일까?

이 글에서는 이에 대해 조금은 다른 관점에서 접근해 보려 합니다. 앱/웹 사업이나 서비스 설계가 아닌데 굳이 개발에 기획자가 필요한 이유를 우리는 수익성 측면에서 생각해 볼 것입니다. 이는 단지 스토리보드와 같은 문서가 아닌 비용에 대한 이야기입니다.

 

 

앱/웹 기획의 목적

 

가장 많은 착각 중 하나가 앱/웹 기획의 목적이 스토리보드라 보는 것입니다. 이렇게 되면 스토리보드라는 문서 산출물에만 신경을 쓰게 됩니다. 이러한 잘못된 몰입이 결과적으로 앱/웹 개발 비용을 늘리는데 일조하게 되기도 합니다. 

 

스토리보드가 그 개발 프로젝트의 핵심 기획 산출물이라고 한다면, 도착 지점과 그 과정에 대한 정확한 고려 없이 그냥 지도처럼 생긴 한창의 멋진 그림을 그리는 것과 같기 때문입니다.

 

마케팅, 경영 분야에서는 기획을 일종의 비즈니스 지도(로드맵)를 디자인하고, 이에 따라 목적지에 다다라는 과정을 관리하는 작업을 의미합니다. 이런 이유로 어떤 기획이든 정보 수집을 가장 먼저 진행합니다.

 

이렇게 기획을 하는 이유는 최적의 비용으로 원하는 결과를 얻기 위해서입니다.

 

예를 들어 서울에서 부산으로 가는 방법은 여러 가지가 있습니다. 빠르게 가는 방법도 있고 돌아서 가는 방법도 있습니다. 돈이 적게 드는 방법이 있고 많이 드는 방법도 있습니다.

 

여기서 기획은 현재 기업의 전략 포지션과 달성할 전략 포지션을 통해 서울에서 부산에 가는 가장 효율적이고 최선의 방법을 설계하는 것입니다. 이는 시간과 돈, 그리고 기업의 욕구에 기반합니다.

 

그러므로 비용은 시간에 따른 기회비용, 실제 돈의 지출, 시간과 돈의 지출 대비 얻는 만족감 등 종합적으로 평가됩니다.

 

이를 다시 앱/웹 기획에 대응해 보면 스토리보드는 기획 목적 달성을 위한 과정, 즉 지도와 같다는 것입니다.

 

현재 상황에서 기획의 목적이 서울에서 부산으로 가는 최적의 방법이고 이를 위해 지도를 그리는 것입니다. 지도를 그리는 것이 목적이 될 수는 없습니다. 지도를 잘 그렸다고 그 사람이 서울에서 부산으로 이동하는 것은 아니기 때문입니다. 이 지도를 가지고 부산에 효과적으로, 만족스럽게 도착할 수 있어야 합니다.

 

그런데 너무 잘 그린 지도를 가지고 서울을 출발하여 부산으로 가고 있는데, 지도에 적힌 정보가 틀리다면 어떨까요? 그냥 지도가 너무 깔끔하게 그려져 있으니까 잘못된 정보가 있어도 괜찮다는 사람은 없을 것입니다.

 

만약 보기 좋게 잘 그려진 지도의 정보가 잘못되었다는 것을 도중에 달게 된다면 여행자는 그 지도를 버릴 것입니다. 그리고 다른 지도를 구하려 할 것입니다.

 

 

기획 산출물의 효용성

 

만약 스토리보드가 앱/웹 기획 산출물이라고 한다면, 기획의 목적 타당해야 의미를 가질 수 있습니다. 스토리보드가 아무리 잘 작성되었더라도 목적 타당하지 않다면 의미가 없습니다. 보기에는 촌스러운 스토리보드라도 기획 목적 타당성이 높다면 보기 좋게 정리된 스토리보다 기획적 효용성은 더 높습니다.

 

하지만 기획의 목적이 스토리보드 작성이라면 의미가 달라집니다. 그럼 스토리보드는 그 자체로 결과가 됩니다. 이 문서를 가지고 앱/웹을 개발할 수 있느냐는 기획과 상관이 없는 다른 일이 됩니다. 마치 개발이 다 끝난 후 개발자들이 철수하고 앱/웹이 운영 도중 추가 개발을 하게 되었다고 이전 철수한 개발자들이 다시 들어와 일을 해야 하는 의무가 없듯이 말입니다.

 

스토리보드는 그 차체가 기획의 목적이과 최종 결과로 보기 때문입니다. 앞서 이야기한 기획 목적 달성을 위한 산출물이 아닌 기획 과정을 끝내는 결과이기 때문입니다. 기획자는 스토리보드 작성으로 이미 부산에 도착한 것이 됩니다.

 

즉, 기획 산출물은 어떤 목적성을 가지냐에 따라 이후 평가가 달라지게 되는 것입니다.    

 

만약 기획 산출물로 스토리보드가 앱/웹 개발의 목적을 지닌다고 하면, 스토리보드의 개발 효용성이 가장 중요한 평가 기준이 됩니다. 그러나 앱/웹 개발과 별개의 보고용으로 제출되는 문서의 목적성을 지닌다면 개발이 불가능할지라도 깔끔하게 정리되고, 멋진 도형과 트렌디한 형식의 잘 읽히는 문서라는 사실이 효용성의 평가 기준이 될 것입니다.

 

 

개발 목적의 기획과 기획자

 

그런데 제목에서 우리는 '앱/웹을 개발하는데'라는 조건을 붙여 기획자의 필요성을 검토한다고 했습니다.

 

그러므로 위의 기획 효용성에서 보고용 스토리보드는 검토할 필요가 없게 됩니다. 우리가 주목해야 하는 것은 바로 앱/웹 개발 목적을 가진 기획을 하는 기획자입니다.

 

• 프로젝트 설계, 관리

기획자를 프로젝트 설계자, 관리자 관점에서 본다면 이는 마치 개발 프로젝트에서 PM/PMO가 하는 일과 비슷해집니다. 그래서 어떤 프로젝트에서는 요구 사항에서 WBS, 고객 관리에 이르는 전반적인 업무를 기획자로 투입된 인력에 맡기기도 합니다. PM은 요구 사항 정리나 WBS 작성을 한 번도 해 본 적이 없는 경우도 있습니다. 기획자가 정리한 요구 사항을 바탕으로 PMO가 각 PL의 도움을 받아 WBS를 작성하기 합니다.   

 

이 케이스의 경우 PM은 개발 대상으로 앱/웹의 범위를 모르므로 고객과 미팅을 하고 나면 계약을 벗어난 추가 개발 내용을 받아오기도 합니다.

 

그러므로 기획자의 앱/웹 개발에서 롤(역할)이 설계, 관리라면 PM은 대부분 얼굴 마담이나 프로젝트 내 수주사에서 파견한 감시역에 그치게 됩니다.

 

• 앱/웹 UI, 화면 설계

이 경우 투입된 기획자는 요구 사항을 보고 스토리보드라는 문서 형식을 통해 앱/웹 화면을 기획 툴로 그리는 작업을 합니다.

  

그렇다면 이를 그냥 이를 화면 디자인이라고 통칭할 수 있고, 디자이너의 작업과 크게 다르지 않게 됩니다. 단지 PPT  같은 기획자가 주로 사용하는 툴로 작업하느냐, 어도비나 피그마 같은 디자이너가 사용하는 툴로 작업하느냐의 차이만 있을 뿐입니다.

 

실제 문서 형식과 설명 문구만 뺀다면 디자인 기초 스케치 같은 와이어 프레임이 됩니다.

 

그래서 기획자의 롤을 이렇게 규정할 시 디자이너 출신 기획자들이 투입되고는 합니다. 그리고 이러한 문서는 보기가 좋습니다.

 

그렇다면 PPT 작업을 빼면 많은 실질적인 역할이 고급 디자이너의 롤과 겹치는 부분이 생기게 됩니다. 

 

• 앱/웹의 작동

 

문제는 디자이너는 프로그래머는 아니므로 때로는 사용 측면에서는 차이가 없지만, 현재 개발 방식으로, 개발팀 상황으로 어려운 화면이 될 수 있습니다.     

 

앱/웹의 사용자 인터페이스(UI), 화면 작동은 이미지와 이미지 간 링크만이 아니고, 서버에서 처리해야 합니다. 때로는 데이터의 연결과 저장, 호출이 UI 작동에 영향을 주기도 합니다.

 

디자인적인 UI, 화면 설계는 앱/웹의 동적 부분이 아닌 정적 부분에 치우치게 됩니다. 그러므로 디자인적으로 뛰어난 스토리보드가 앱/웹 개발적 효용성이 높은 스토리보드라고 확정할 수 없게 됩니다.

 

앱/웹의 작동 관점에서 보게 되면 정적 화면 측면뿐 아니라 이 화면을 이용 시 발생되는 작업 프로세스에 대한 정리가 스토리보드에 포함되어 있어야 이를 개발하는데 도움이 된다는 것을 의미합니다.

 

그러므로 앱/웹의 작동에서 보면 기획자의 작업은 고급 개발자의 설계 작업과 겹치는 부분이 생기게 됩니다.

 

• 앱/웹과 사용자

 

이러한 앱/웹의 작동 조건 때문에 더 나은 화면과 UI 디자인을 가진 앱/웹의 사용자 경험이 그렇지 않은 앱/웹의 사용자 경험에 미치지 못하게 되는 것입니다.

 

이를 우리는 과거 페이스북과 싸이월드의 싸움을 통해 경험하였습니다. 그리고  2010년 이후 다양한 앱 서비스 스타트업들이 등장하고 이들 중 일부가 유니콘으로 성장하는 과정도 보아왔습니다.

 

이를 통해 반드시 기능이 많거나 디자인이 뛰어난 앱이 유니콘이 되는 것은 아니라는 것을 보아 왔습니다.

 

이러한 현상을 기획자 관점에서는 앱/웹 사용자 경험의 차이 때문으로 봅니다. 그리고 사용자 경험을 구성하는 것은 일정 이상의 기능과 이 기능의 작동, 일정 수준 이상의 디자인과 인지 부담 등의 복합적 결과라는 사실을 주목합니다.

 

 

앱/웹에서 기획자의 역할 

 

지금까지 장황한 내용들을 보면 한 가지 결과에 다다르게 됩니다.

 

앱/웹 기획자의 롤이 어떤 관점에서 보든지 조금씩 겹치는 업무 분야가 있다는 사실입니다. PM인 PMO, 디자이너, 개발자(프로그래머) 등 기획자의 업무는 어떻게 보더라도 조금씩 겹치는 부분이 있는 것입니다.

 

이러한 기획자의 특성 때문이 해외 개발 현장에서 개발자 범위에 프로그래머와 디자이너, 사업 기획, 마케팅 기획은 있어도 우리나라와 같은 기획자는 없는 것입니다.

 

또 다른 관점에서 보면 모두 겹치기에 앱/웹 개발에 참여하는 전체 인력의 업무를 조율하고 진행시키는데 유용할 수도 있습니다. 물론 이러면 PM과 역할이 너무 겹치게 되기는 합니다.

 

그런데 한 가지 포인트를 하나 더 생각해보아야 합니다. 왜 이런 검토를 했느냐는 것입니다.   

 

우리는 기획자가 어떤 일을 하는 것인지에 대한 R&R을 왜 이야기하고 있는 것일까요? 어떻게 보면 이런 논의가 있다는 사실만으로 기획자는 앱/웹 개발의 필수 인력이라기보다는 스탭(지원 업무)에 가깝습니다.

 

그러므로 가치 사슬에서 지원 업무의 역할을 통해 기획자의 필요성을 추정할 수 있다고 생각 듭니다.

 

가치 사슬에서 보면 핵심 과업은 해당 가치 생산에 직접적으로 필요한 작업을 의미합니다. 예를 들면 개발자나 디자이너 같이 이들이 없다면 앱/웹이 개발될 수 없는 작업을 하는 인력이 핵심 과업 담당자입니다.

 

그런데 앱/웹의 가치가 만들어지는데 굳이 필요하지 않은 부분인 스텝(지원) 부분 가치 사슬에 포함되는 데는 이유가 분명 있을 것입니다.

 

• 경쟁 때문에 존재하는 부문

 핵심 가치 생산 부문이 아닌 지원 부문의 필요는 경쟁 때문입니다. 사용자는 앱/웹이 론칭되면 반드시 이용하는 것은 아닙니다. 선택이라는 것을 합니다.

 

여기서 핵심 가치 생산 부문만으로 개발된 앱/웹의 문제가 생기게 됩니다. 바로 매출입니다.

 

론칭된 앱/웹은 경쟁을 해야 하고, 이 경쟁에서 살아남은 앱/웹만이 매출을 올리게 됩니다. 우리는 2010년 이후 수십 억, 수백 억 개발비를 들인 앱/웹들이 소리 소문 없이 사라지는 것을 많이 보아왔습니다.

 

핵심 가치 생산 부분으로만 온전한 앱/웹만 만드는 것을 목적으로 한 서비스들은 비용 회수가 없는 비용 지출만 하고 사라질 가능성이 매우 높다는 사실을 이미 경험적으로 알고 있습니다.  

 

• 수익을 올리는 방법

앱/웹의 매출이 없다면 문제지만, 작다고 문제가 되는 것은 아닙니다. 문제는 매출과 비용의 밸런스와 성장입니다.

 

우리는 다양한 공시 자료와 뉴스를 통해 경쟁하는 기업들 중 매출이 더 많은 기업이 적자이고, 매출이 더 적은 기업은 흑자인 것을 보았습니다.

 

그러므로 수익에 있어 단순한 매출 규모가 중요한 것이 아닌 이 매출을 올리기 위해 사용된 비용이 얼마인지도 보아야 한다는 사실을 알고 있습니다.

 

이를 앱/웹 개발에 대입하여 생각하면 이렇게 말할 수 있습니다.

 

• 같은 앱/웹을 얼마 큼의 비용으로 개발하였는가

같은 앱/웹이라도 개발 비용이 크다면 더 많은 매출을 올려가 이익을 낼 수 있게 됩니다. 그러므로 얼마나 효율적으로 개발할 수 있느냐는 수익성에 큰 영향을 주는 요소입니다.

 

앱/웹 개발 비용은 동일 기간 투입 개발 인력에 비례합니다. 같은 인력 규모라도 개발 기간이 길어진다면 비용은 올라가게 됩니다.

 

하지만 개발에 있어 더 큰 문제는 위의 것들이 아닙니다. 개발이 거의 끝나가는 시점 치명적인 문제를 인식하게 되는 경우가 비용을 가장 크게 높이는 것입니다.

 

이 경우 개발을 다시 처음부터 해야 합니다. 그러면 2개의 개발 프로젝트를 통해 하나의 앱/웹을 개발하는 것이 되는 것입니다. 그러므로 단순히 기간이 늘어나거나, 인력이 투입이 많아 생기는 비용 증가와 차원이 다른 증가를 나타내게 됩니다.

 

이러한 문제는 개발 초기에는 나타나지 않습니다. 반드시 개발이 거의 끝나가야 인식할 수 있게 되는 사실이 더 리스크 한 것입니다.

 

하지만 이런 문제의 해결책은 간단합니다. 설계, 기획을 하고 이에 따라 작업하면 되는 것입니다. 

 

기획, 설계를 했다고 해서 문제가 안 생기지는 않습니다. 하지만 문제를 빨리 인식할 수 있게 됩니다. 이를 통해 문제의 파급을 축소할 수 있게 됩니다.

 

이런 이야기는 공학적으로나 경영적으로 기본입니다. 바둑을 두거나 축구를 즐길 때도 승리를 목적으로 한다면 사전에 기획(계획)을 하고 이에 따라 게임을 만들어 갑니다.

 

그냥 놀 때도 하는 이러한 기획을 하지 않는다면, 하더라도 잘하지 않는다면 앱/웹 개발에 문제가 생기는 것은 당연합니다.  조기 축구처럼 건강과 재미를 위해 하는 스포츠와는 다르게, 앱/웹 개발은 프로 축구와 같이 전문가들이 모여하는 전문적인 작업이기 때문입니다.

    

그러므로 앱이나 웹 사이트를 개발하는데 왜 기획자가 필요하냐는 질문은, 최적의 비용으로 최선의 앱/웹을 개발하기 위한 것이라 답할 수 있습니다.

 

지금 개발 프로젝트에 투입되어 있는 기획자가 스토리보드 그리기 등 형식적인 작업을 하고 있는지, 개발에 필요한 기획을 하고 있는지를 보면 해당 프로젝트에 필요한 기획자인지 알 수 있을 것입니다.

 

그리고 이를 스토리보드가 아닌 기획 자료를 통해 쉽게 알 수 있습니다. 사람의 뇌의 인지 및 작업 효율은 생각보다 과정 데이터의 영향이 크게 받기 때문입니다. 과정 데이터 없이 최종 처리를 하라고 하면 뇌의 처리 효율이 떨어지게 됩니다. 이 또한 다양한 인지 실험을 통해 검증되었습니다. 그리고 이 결과를 적용한 것이 개인화, 큐레이션, 추천 서비스입니다.