보유 기획 기술 소개

이 글은 제 기획 기술에 대한 소개를 하는 내용입니다. 대학 전공과 실무 경험, 특히 제가 경험했던 기획 상황들을 전공에서 배웠던 이론들에 비추어 정리해 보았습니다. 내용은 주로 제가 20년 넘게 IT 산업 분야에서 다양한 기업들에서 일을 하면서 제가 해야 했던, 했었던 기획들에 기반합니다.

 

 

 

개인적으로 지향하는 또는 선호하는 기획에 대한 생각

 

개인적인 성향일 수 있지만 반복적이고 일상적인 작업을 좋아하지 않습니다. 그러므로 비슷한 작업을 반복하거나, 과거 기획 경험에 기반하여 업무를 하는 작업은 싫어합니다.

 

좋아하는 기획 작업은 불확실성이 강한 미래의 전략적 우위를 가지기 위한 것, 사용자 가치를 추정하고 이에 대한 IT 서비스를 설계하고 사용자 가치를 기업 자산화 하는 과정을 진행하는 것입니다.

 

실무의 예를 들면,

 

확실성하의 기획을 진행하는 SI나 웹에이전시 기획은 선호하지는 않습니다.

 

화면 설계 부분은 좋아하지는 않지만, 국내 IT 외주 시장 특성상 인력 요구가 많기에 돈을 벌기 위해 하기는 합니다. 외주 개발 분야의 기획에서 그래도 좀 더 좋아하는 것은 BA 및 비즈니스 기획을 바탕으로 기능/화면 프로세스 및 정의(목록) 하는 작업을 스토리보드(화면 설계)에 비해 선호합니다.

 

이에 반해 불확실성하의 IT 기획은 성향 상 좋아합니다.

 

서비스 가설을 수립하고 앱이나 웹 서비스를 설계하는 것은 선호합니다.

 

그러나 회사에서 자체 서비스를 개발하거나, 제가 회사를 세우고 앱/웹 서비스를 진행하지 않는 이상 이 기획 작업은 하기 어렵습니다. 특히 최근 제가 돈을 벌고 있는 외주 개발 관련 기획에서는 서비스 가설을 수립하고 앱/웹 서비스를 설계하는 기획은 거의 일어나기 어려운 기획 유형에 가깝습니다.

 

기획자로서의 가치나 상대적 경쟁력, 차별화 등을 보더라도 스토리보드(화면 설계) 분야는 고급/특급으로 분류되는 기획자의 작업으로 분류하기에는 한계가 있습니다. 한 마디로 스토리보드(화면 설계)만 놓고 보면 초급도 가능하고 중급만 되어도 고급과 크게 결과물이 다르지 않게 됩니다. 오히려 현 앱/웹 트렌드 반영이나 작업 속도 측면에서는 초/중급이 더 나을 수 있습니다.    

 

그러므로 스토리보드(화면 설계) 분야만 보면 기획 특급 분류는 어려울 수 있습니다. 실무 현장에서의 고급 또한 스토리보드(화면 설계) 실무 작업 자체보다는 스토리보드(화면 설계)를 위해 여러 기획자들을 관리(공통 및 IA, 작업 화면 목록을 바탕으로)하는 역량 측면에서 가치와 차별화를 찾기도 합니다. 

 

이런 이유들 때문에 이미 20년이 넘어가는 제 경력이나 성향 상 스토리보드나 화면 설계를 못하는 것은 아니지만 온라인 서비스 기획 및 경쟁 전략 기획에 대한 선호가 있습니다. 

 

문제는 시장 요구가 이 분야(서비스/비즈니스 관점 기획 등)는 화면(UI) 중심 외주 개발 관련 기획에 비해 많지 않다는 점이기는 합니다. 심지어 앱/웹을 개발하기 위한 기획과 앱/웹 서비스를 위한 기획의 차이를 모르는 경우도 있습니다.

 

일부 대기업의 경우 앱/웹 개발 프로젝트를 하면서 경쟁사와의 서비스 차별화 측면에서 기존 인기/유명 서비스를 따라 하는 외주 개발 방식에 대한 의문을 제기하기도 합니다. 이 때문에 외주 개발로 투입된 저에게 온라인 서비스와 앱/웹 개발을 위한 기획의 차이에 대해 묻기도 합니다.

 

하지만 대기업이라도 법적/구조적 독과점 상황에 있는 경우, 대다수의 중견, 중소기업에서는 그냥 항상 하듯이 벤치마킹으로, 또는 다른 경쟁사 프로젝트 경험을 바탕으로 기획해 달라고 요구하기도 합니다.

 

제가 했던 기획은 주로 전략 상이나 시스템 상으로 보안을 요하는 기획들이었습니다. 화면 중심 기획의 경우 어차피 론칭을 하면 누구나 알게 되므로 론칭 후에는 보안 사항은 아니게 됩니다. 그러나 서비스 전략/시스템 관련 기획은 화면에서 보이는 것이 아니므로 론칭을 해도 보안 의무가 유지됩니다. 

 

결국 과거 경쟁사 프로젝트를 했던 것을 바탕으로 기획해 달라는 요청은 이행이 어렵습니다.

 

이런 점 때문에 기획에 대한 평가는 기획 난이도 또는 가치 측면에서 화면 기획보다는 서비스 전략/시스템 기획이 더 높은 평가를 받습니다. 당연히 외주 개발의 경우 기획 차별화나 단가 측면에서 개인적으로 화면 기획보다는 서비스 전략/시스템 기획을 선호합니다. 비록 별로 없고, 이 차이를 아는 관계자가 진행하는 프로젝트가 별로 많지 않다는 점이 현실이기는 하지만 말입니다.

 

정리하면, 반복적이고 일상적인 경향이 큰 화면/UI 설계보다는 창의력과 상상력, 논리(서비스 로직)와 전략적 포석, 경쟁 우위 등을 고려해야 하는 온라인 서비스 기획을 좀 더 선호합니다. 개인 성향상 재밌기 때문입니다. (경제적 부분은 일 자리가 별로 없기에 좋다고 할 수 없습니다.)

 

이외에도 추가 이유가 있습니다. 이는 아래의 '기획 기술 - 온라인 서비스 기획' 항목에서 더 정리해 놓겠습니다.

 

 

   

기획 기술 - 온라인 서비스 기획

 

제가 가지고 있는 온라인 서비스 기획 관련 기술에 대해 정리하였습니다.

 

 

시장분석 기술

 

온라인 서비스 니즈(필요)를 파악하기 위해서는 시장을 분석할 수 있는 능력이 필요합니다. 온라인 서비스 기획자가 시장이 필요로 하는 앱/웹 서비스가 아닌 것을 기획한다면 그 기업은 어려워질 것입니다. 돈은 쓰는데 벌지 못할 것이 명백하기 때문입니다.

 

그러므로 앞으로 개발할, 제공할 앱/웹 서비스의 기획을 위해서는 기본적으로 시장분석 기술이 필요합니다.

 

이 기술은 절대적/상대적 분석 기술 모두를 의미합니다. 아무리 회사 입장에서 너무 좋은 온라인 서비스 시장 기회를 포착했다고 해도, 경쟁사보다 더 나은 서비스를 제공할 수 없다면 그 앱/웹 서비스는 진행해서는 안될 수도 있습니다. 과거 LG 전자가 글로벌 순위 3~5위였음에도 애플과 삼성전자에 밀려 스마트폰 시장에서 막대한 적자를  본 사례를 통해 이를 알 수 있습니다.

  

• 시장분석 기술에 대한 근거

제가 시장분석 기술을 가지게 된 계기, 그리고 이 기술이 있음을 주장할 수 있는 근거를 이야기하겠습니다.

 

일단 저는 경영학과를 나왔습니다. 그리고 다양한 기업에서 마케팅(광고뿐 아니라 통합적/복합적 마케팅) 실무를 했습니다. 이후 국내 최초 다운로드하여 혼자서 즐기는 스탠얼론 모바일 게임이 나오면서 모바일 사업과 서비스 기획을 합니다. 이 과정에서 이후에는 신규 사업/서비스 기획을 합니다.

 

이 경험을 바탕으로 제가 투자하여 온라인 플랫폼 개발/서비스 기업을 세우고 개발 작업을 진행합니다. 물론 창업 결과는 별로였습니다.

 

이런 마케팅, 사업, 서비스 기획 작업들은 기본적으로 시장분석에 대한 작업을 바탕으로 해야 합니다.

 

제가 본격적으로 외주 개발 인력 시장에 들어오게 된 계기도,

사실 SI와 웹에이전시 회사가 자체 서비스를 개발한다고 저에게 먼저 제안했기 때문입니다. 물론 이  SI와 웹에이전시 회사에는 외주를 진행하던 기획 인력이 있기는 했습니다. 그러나 자체 앱/웹 서비스를 기획하기 위해서는 기존 외주 개발 기획 인력이 아닌 다른 기획 역량의 기획자가 필요하다 판단하여 저에게 연락을 한 것입니다.  

 

이는 기본적으로 외주 개발 기획자의 경우 시장분석 기술에 대한 능력이 상대적으로 낮기 때문입니다. 레퍼런스나 화면 벤치마킹을 하기는 하지만 이를 시장분석 기술이라 하기에는 한계가 있습니다. (물론 분석, 정리 능력은 좋지만 문제 해결능력이 상대적으로 떨어지는 이유도 있기는 합니다.)

 

시장 필요에 대한 파악이나 가치 알고리즘에 대한 이해와 설계, 경쟁 우위 파악과 미래 환경에 대하여 시뮬레이션을 할 수 있는 능력 부분이 부족하기 때문입니다.

 

또한 다른 명백한 이유로 서비스 기획 관련 능력이 외주 개발 기획에서와는 다르기 때문입니다. 이에 대한 것을 몇 가지 더 정리해 보겠습니다. 

 

 

온라인 서비스 가설 수립 기술  

 

인터넷 목표 사용자와 상호 작용할 서비스 상품에 대한 설계를 위해 시장(사용자) 가설을 수립하는 기술입니다.

 

서비스 가설 능력은 온라인 서비스 사용자 니즈/욕구의 변동성과 시장 정보에 대한 확보/분석 불완전성, 여러 서비스 플레이어들이 참여하는 시장에서 발생하는 불확실성 때문에 필요한 기술입니다.

 

온라인 서비스 가설은 기본적으로 사용자를 기반으로 수립됩니다. 어떤 유형 또는 성질의 사용자들을 핵심 사용자 그룹으로 설정하느냐에 따라 서비스 가설의 내용은 달라집니다.

 

그래서 페르소나 기법 및 스토리 방식을 통해 가설을 수립하게 됩니다. 이를 경영 전략적으로는 시나리오 경영 기법의 유형에 속하는 방식이라고도 할 수 있습니다. 마케팅적으로 통합적 마케팅에서 소비자(사용자) 만족을 위한 전략적/전술적 상효작용 설계라고 할 수도 있습니다.

 

• 서비스 가설 기술에 대한 근거

경영학 전공 수업을 통해 서비스 상품 기획에 대해서 배우기도 합니다. 여기에 마케팅 4P 중 프로덕트에서 서비스에 대한 것을 가치사슬 및 마케팅 수행 전술(4P)적 측면에서 다루기도 합니다.

 

이보다 서비스 기획 특히 가설 수립 방법에 대해 지식을 전해 주는 것은 소비자 행동론 및 심리학 수업이라 할 수 있습니다.

 

불론 서비스 가설 수립이 단지 이러한 수업을 들었기에 할 수 있는 것은 아닙니다. 이러한 기본 지식을 바탕으로 시장 환경 분석 및 경쟁 분석/전략 수립에 대한 방법론, 시뮬레이선/시나리오/인바스켓 등의 방법론을 응용할 수 있어야 합니다.

 

저는 개인적으로 이러한 대학에서의 수업과 직장 생활의 경험을 융합시켰기 때문에 온라인 서비스 가설에 대한 기술적 완성도를 높였다 생각합니다.  

 

 

서비스 가설 실험/검증 환경 구축 기획 기술

 

온라인 서비스 가설 실험 환경을 우리는 흔히 앱이나 웹 서비스라 부릅니다. 서비스 기획 관점에서 앱 개발이나 웹 개발은 온라인 서비스 가설을 실험/검증을 위한 환경 구축 작업이라 할 수 있습니다.

 

온라인 서비스 가설이 여러 서비스 플레이어(기업) 사이에서 경쟁에서 승리하고, 사용자 필요과 욕구를 만족시켜 수익을 올리기 위해 수립되기 때문에 앱과 웹은 원론적으로 서비스 가설에 기반해야 합니다.

 

그렇지 않은 경우 앱/웹 그 차체로는 프로그램 완성도가 있을 수 있지만, 돈은 벌지 못하고 비용만 남는 애물단지 앱과 웹이 될 수 있습니다.

 

• 서비스 가설 실험/검증(앱/웹) 기획 기술 근거

솔직히 앱/웹 개발 기획 관련한 기획 기술은 무슨 공부를 해서 얻은 것은 아닙니다. 대학 때 배운 기술에 대한 이론과 회사에서 프로젝트를 하면서 알게 된 것입니다.

 

성향 상 프로젝트를 하면 데이터를 모아 분석하는 습관이 있습니다. 그냥 성향이라 하는 것이 더 정확할 것입니다. (확률/통계를 의미하는 것은 아닙니다. 또한 구글 애널리틱스나 페이스북 픽셀 같은 툴 사용 역량을 하는 것은 아닙니다.). 

 

이 과정에서 자연스럽게 온라인 서비스 가설 실험/검증 기반이 되는 앱/웹 기획에 대한 기술을 습득하게 되었습니다.

 

기획이라고 해서 모두 같은 것은 아닙니다. 산업 분야나 업무적 특성에 따라 기획 방식은 조금씩 달라집니다. 광고, 마케팅, 사업 기획, 앱/웹 개발과 운영, 온라인 서비스 설계 등 다양한 분야에서 기획을 하면서 정확히 필요한 기술적 내용과 기획 방법론에 대해 정리하는 성향이 있다 보니 자연스럽게 앱/웹 개발을 위한 기획 방법론을 정리하였습니다.

 

또 이를 프로젝트 현장에 대입하면서 수정/보완을 해 왔습니다. 지금 기획을 참여하고 있는 프로젝트의 여러 부분도 상황별 기획 방법론에 기반하여 작업하고 있고, 실제 작업 내용도 이번 프로젝트에서 처음 하거나 변형하여하는 기획 작업도 존재합니다.   

 

앱/웹 개발에서의 기획 관련에 대한 것은 다시 뒤이어 더 다루겠습니다. 

 

 

서비스 개발 이후

 

온라인 서비스 기획은 앱이나 웹의 서비스 가설 실험/검증 환경 개발이 끝이 아닙니다. 이렇게 개발된 실험/검증 환경에서 이용을 하는 사용자 데이터를 통해 온라인 서비스 가설을 검증하고 보완하는 작업 필요합니다.

 

앱과 웹 개발은 온라인 서비스 기획 측면에서 보면 해당 서비스의 시작을 알리는 단계에 지나지 않습니다.

 

서비스 가설을 검증하고 보완하는 기간 동안 서비스 기획자는 사용자를 확보하고 학습시키고 강화하는 프로그램을 진행합니다. 이를 AI 개인화, 이벤트 프로모션, 광고/홍보 등의 사용자 이용 촉진 기획 요소로 바라볼 수도 있습니다.

 

그러나 서비스 기획 측면에서 이는 서비스 가설을 검증하고 보완하는 전반적 프로세스 상에서 발생하는 이벤트 같은 것입니다. AI 개인화 추천, 이벤트 프로모션, 광고/홍보 등 또한 서비스 가설을 형성하는 부분인 것입니다. 

 

물론 온라인 서비스 기획을 구성하는 다양한 관련 기술들은 독립적으로 볼 수도 있습니다. 그러나 온라인 서비스 기획자는, 특히 역량이 높은 기획자라면 이러한 각각의 요소들을 상호 보완적 측면에서 설계하고 관리합니다. 실력 있는 서비스 기획자는 유기적/시스템적 기획을 한다는 것입니다.

 

그러므로 온라인 서비스 기획 기술은 IT 기술, 서비스 전략, 마케팅 전반을 아우르는 시스템적 사고를 바탕으로 해야 효과를 볼 수 있습니다.

 

 

 

기획 기술 - IT 개발 기획

 

현재 국내 IT 시장 특성상 프리랜서 기획자가 돈을 벌 가능성은 외주 개발 프로젝트에 참여하는 것입니다. 이러한 외주 개발 관련 기획은 매우 정형화되어 있습니다.

 

그러므로 솔직히 전통 기획자 관점에서 이런 업무 방식은 IT 기획 업무라기보다는 일종의 프로젝트를 구성하는 여러 단위 작업 중 기획이라 분류되는 작업의 내용을 처리하는 일이라 보입니다.

 

예를 들어 스토리보드 또는 화면 설계서를 작성하는 것과 같은 작업을 하는 것을 기획이라 합니다.

 

여기에는 기획적 요소보다는 스토리보드/화면설계 문서 작성을 할 수 있는지가 더 중요시됩니다. 외주 개발의 특성상 정해진 산출물이 존재하고 이중 기획 담당의 핵심 산출물이 스토리보드/화면설계 문서이기 때문입니다.

 

화면을 구성하기 위한 IA, 화면 개발의 총 개발비 산출을 위한 화면 목록, 개발자가 작업할 내용을 정리하는 기능 정의 등의 작업이 추가되면서 설계자 또는 기획 리더(PL) 또는 프로젝트 관리자(PM)로의 역할을 하게 될 수 있습니다.

 

제가 외주 개발 프로젝트를 하면서 느낀 것은 기획이라 부를지라도 다 같은 기획이 아니라는 것입니다.

 

먼저 이러한 외주 개발 기획은 크게 구분하여 아주 성격이 다른 SI와 웹에이전시 중심 프로젝트로 구분할 수 있습니다.

 

공공 프로젝트의 중소 컨소시엄의 원칙이 있는 관계로 개발과 화면 설계가 구분되는 성격을 지닙니다. 그래서 많은 경우 개발은 SI 회사가 기획은 주로 화면 설계를 하며 웹에이전시에서 담당합니다. 이 때문에 개발과 기획이 분리되어 융합하지 못하는 일이 자주 발생합니다. ( SI와 웹에이전시 기획은 같은 단어인 기획이라 부르지만 아주 성격이 다른 유형의 기획이기 때문입니다.) 

 

일반적으로 기획자를 웹에어전시에서 투입하여 작업하는 경우, 개발자와 화면 설계를 연결하는 통합 기획자가 필요할 수 있습니다. 그러지 않은 경우 화면 설계와 개발은 따로 놀게 되는 경우가 발생할 것입니다. 실제 제가 투입되었던 프로젝트 중 웹에이전시에서 기획을 하고 SI에서 개발을 하는 경우 기획과 개발이 융합되지 못하는 문제가 자주 일어났습니다.

 

 

외주 개발 기획의 구분

 

온라인 서비스 기획에서 서비스 가설을 바탕으로 가설 검증 환경인 앱과 웹에 대한 기본 설계가 나오게 됩니다. 이때 나오는 개발 관련 산출물은 크게.

• 목표 서비스 정의 및 정책
• 비즈니스 구조/내용(BA)
• 서비스 핵심 기능
• 디자인 아이덴티티
• 서비스 운영 기준

의 내용입니다.

 

이러한 자료는 앱과 웹 개발 분야에서 다시 크게 개발(프런트와 서버 간 인터페이스 중심), UI(프런트와 사용자 간 인터페이스) 내용으로 분류됩니다.

 

전자를 기획하는 경우 개발 기획, 후자를 기획하는 경우 화면 기획이라 부르기도 합니다. 주로 전자는 SI 기업에서, 후자는 웹에이전시에 하는 기획입니다.   

 

 

개발 기획 

 

개발자의 작업에 필요한 기획을 하는 작업을 의미합니다. 

 

저의 경우 주로 BA를 바탕으로 필요한 기능을 정리하고, 이 기능이 작동되는/이용되는 프로세스를 작업했습니다. 여기서 작동은 사용자 요구를 받아 기능 로직을 처리하여 피드백하는 프로세스를 의미하는 것은 아닙니다.

 

기획의 프로세스는 기능이 작동하는 코드를 블랙박스로 가정해서 사용자가 기능 이용의 목적과 기능을 사용하기 위해 제공하는 정보를 바탕으로 필요로 하는 피드백을 정리하는 것이 주가 됩니다. (이는 온라인 서비스를 위해 어떤 정보가 필요하고, 정보가 어떻게 움직여야 하는지 정의하는 설계라 할 수 있습니다.) 

 

이러한 기능 프로세스를 바탕으로 작성되는 스토리보드는 화면 목록을 바탕으로 작성되는 스토리보드와 매우 다른 특성을 보입니다. 이름은 같은 스토리보드이지만 완전까지는 아니더라도 많이 다른 문서라 해도 틀린 말은 아닙니다.

 

제 개발 기획 경험에 보면 SI 프로젝트와 웹에이전시 프로젝트에서 요구하였던 스토리보드 달랐습니다. 심지어 웹에이전시 기획자가 작업한 스토리보드와 진행된 개발과 싱크를 맞추는 역할로 투입된 적도 있었습니다. 

 

실제 개발 기획에서 만난 개발자는 종종 기획자를 처음 본다는 분도 있었습니다. 심지어 제 기획 작업 내용을 보고 기획자가 이런 일도 하느냐고 물어보시는 분도 있었습니다.

 

심지어 저는 시스템 분석/설계 단계 개발자와 함께 투입되기도 하였습니다.

 

개발자가 코드를 중심으로 레거시 시스템을 분석을 한다면, 저는 비즈니스 로직 측면에서 분석을 합니다. 그리고 이 두 분석을 논리적으로 융합하여 해당 시스템의 작동 원리 및 설계 내용을 파악하여 TOBE 시스템을 설계하였습니다.

 

오래된 시스템의 경우 대부분 설계서는 물론 매뉴얼도 없는 경우가 있습니다.

 

운영자가 쓰고 있는 기능만 이용하고, 이를 인수인계하여 다음 운영자도 사용하고 있는 경우도 많습니다. 그래서 안 쓰는 기능과 중복되는 기능도 많고, 심지어 왜 그렇게 되는지 모르는 경우도 있었습니다. 시스템에 문제가 생기면 해결하기 위해 그냥 하드코딩 한 시스템도 있습니다. 이 때문에 시스템 속도는 느려지고 문제가 가능성과 보안 위협은 높아진 상태였습니다.

 

이 수준까지 오면 레거시 시스템은 개발자만으로 분석이 불가능하게 됩니다. ERP 같은 내부 시스템임에도 TOBE 설계가 개발자만으로 불가능하게 됩니다..

 

이런 프로젝트의 경우 초기 레거시 분석/설계 시 개발자와 함께 기획자로 투입되어 작업하기도 했습니다.

 

• 개발 기획 기술 근거

솔직히 제가 개발자는 아니므로 대학에서 전공을 한 것은 아닙니다. 또한 실무적으로 코딩을 하지도 않았습니다.

 

그냥 프로젝트를 하면서 개발자와 협업을 하면서 자연스럽게 알게 된 것뿐입니다.

그래서 왜 제가 이를 아는지는 모르겠습니다. 그냥 일을 하다 보니 알고 있는 것뿐입니다. 

 

물론 비즈니스 구조나 프로세스에 대한 것은 일부는 경영학 전공 지식을 활용하여 이해하기도 하기는 했습니다.

 

SI 전통 방식은 폭포수 개발 방식은 분업화와 공정 최적화 지식을 바탕으로 이해하였습니다. 

애자일 개발 방식의 경우 JIT와 플랫폼/셀 생산 방식을 바탕으로 이해를 하였습니다.

 

이런 식으로 실무 현장의 경험과 과거 전공 때 배운 내용을 융합하여 이해하면서 개발 기획에 대한 기획 기술적 바탕을 만들어 왔습니다. 

        

 

화면 기획 (화면 설계 기술 근거 포함)

 

저는 2000년대 초반 아직 웹에이전시가 거의 없던 시절, 현재 웹에이전시 역할을 온라인 광고 대행사들이 하던 시기 두 개의 온라인 광고 대행사(디킴스, 코마스)에서 기획을 하였습니다. 

 

과거 SKT 프로모션 사이트 제작 단가 기준(개발 단가표)을 만들기도 했습니다. 이 제작 단가 기준은 지금 웹에이전시가 개발 화면 본수 중심으로 개발 비용을 산정하는 것과 비슷합니다. 또한 현행 개발자 인력 단가인 개발자 등급별 월평균 비용 책정 방식과 유사했습니다.

 

그러므로 UI나 화면 설계에 대한 것은 이미 아주 오래전부터 하였다고 할 수 있습니다.

 

특히 디자인의 경우 KTF 대리점 POP, 전단/포스터, 프로모션 제작물 디자인 담당으로 일을 했었습니다. 이 당시 디자인 총괄 기획자로 신세기 통신(017) 디자인 담당자의 미팅 요구를 대응하기도 했고, KTF 최초 디자인 경쟁 입찰에서 리젝션 피(rejection fee)를 도입하기도 했습니다.

 

디자인에 대해서는 온/오프라인에서 경험이 있었습니다.

 

그럼에도 이후 자체 (회사의) 온라인 서비스 개발과 SI 개발 기획을 주로 하다 보니, 시간이 흘러서 기획 작업 하게 된 웹에이전시 프로젝트에서 너무 많은 기획자들과 일을 하는 상황이 초기에는 당황스럽기도 했습니다.

 

물론 이후 프로젝트를 많이 하다 보니 같은 시스템 서로 다른 버전의 웹에이전시 기획과 SI 기획의 자료를 얻게 되었고 이를 분석하여 기획자가 많은 또는 적은 이유를 찾게 되었습니다. 

 

개인적으로 직접 고용이 아니고는 프리랜서로 화면 설계 작업은 단가 때문에 잘하지 않습니다. 또한 너무 단순 작업이라 제 성향 상 힘들기도 합니다.

 

 

 

온라이 서비스와 서비스 가설 검증 환경 구축 기술 전반 정리

 

여기에서 지금까지 이야기한 제 기획 기술 관련 내용을 간단히 요약하고 글을 마치겠습니다. 

 

보유 기획 기술 요약

 

여러 기획 작업을 하다 보니 온라인 사업 기획과 서비스 기획, 앱/웹 시스템 기획은 아주 다른 기획이라는 점을 분명히 느끼게 됩니다.

 

본질적으로 온라인 사업 기획과 서비스 기획은 불확실성하의 기획입니다. 그러나 앱/웹 시스템 기획은 확실성하의 기획입니다.

 

• 온라인 사업 기획과 서비스 기획은 불확실성하의 기획인 경우

온라인 사업 기획과 서비스 기획은 기획 변수와 기획에 따른 변화 가능성이 큰 결과에 대한 계획과 관리입니다.

 

같은 기획이라도 상황이나 운에 따라 결과는 다를 수 있습니다. 그러므로 기본적으로 온라인 사업 기획과 서비스 기획의 계획은 결정된 사항이 아닌 진행에 따라 대응해야 하는 기준을 정하기 위한 것이 됩니다. 

 

이점에서 기획 내용은 반드시 그런 것이 아닌 기획 후 시간이 지나 변한 환경에 따라 변할 수 있는 것입니다. 

 

• 앱/웹 시스템 기획

이에 반하여 앱/웹 시스템 기획은 확실성하의 기획입니다.

 

비즈니스와 정책, 기능을 정의하고 이에 맞추어 개발이 진행되기 때문입니다. 만약 기획 내용이 개발 중에 바뀐다면 개발을 다시 해야 하는 일이 발생할 수 있습니다. 심지어 지금까지 개발은 쓸 수 없게 될 수도 생길 수 있습니다.

 

• 확실성과 불확실성을 만드는 또 다른 이유

기획 기간도 온라인 사업 기획과 서비스 기획은 상당히 긴 기간을 기준을 합니다. 이에 반해 앱/웹 시스템 기획은 1년 안쪽에서 길어야 2년 안쪽에 해당하는 상대적으로 짧은 기간을 기준으로 합니다.

 

이점에서 온라인 사업 기획과 서비스 기획, 앱/웹 시스템 기획은 완전히 다른 기획 방법론에 지배를 받게 됩니다.

 

이러한 정리를 한 것은 제가 이러한 기획 전반을 모두 경험하고 충분한 경험 데이터를 확보하였다는 것을 증명하는 것이라 생각합니다.