서비스 기획 스쿨

안녕하세요 글쓰는 직장인 쿨캄준입니다.

​

오늘은 일독을 마친 책 "현업 기획자 도그냥이 알려주는 서비스 기획 스쿨, 사수 없이 시작하는 웹/앱 프로덕트 실전 입문서"에 대해 글을 쓰고자 합니다.

​

필자는 사실 게임업계에 입문을 하고자 했을 때 가장 지망했던 포지션이 기획자였습니다. 원하던 프로젝트는 메이플스토리M이었습니다. 원인은 메이플을 정말 좋아했기 때문입니다. 초등학교, 중학교 시절에 PC 버전을 플레이했고, 오늘날에도 메이플스토리M을 플레이하고 있습니다. 오픈 때부터 했으니 이제 대략 5~6년은 플레이했네요. 그러나 경력 3년 이상 채용뿐이 없었고, 그래도 도전해 보자는 마음에 지원하고 매일 결과를 기다렸으나, 메이플스토리 모바일 기획자 포지션은 모두 탈락하게 됩니다.

​

그래도 게임을 좋아했기에 게임업계에서 일하고자 하는 마음이 있었고, 필자의 강점을 살려 해외 사업개발 직무로 일을 하게 되었습니다. 그리고 이제 어느 정도 경력을 쌓고 나서 보니 직무에 대해 알고 있는 게 적지는 않더라고요. 그래서 시작하게 된 것이 CCJ의 사업개발 이야기 블로그 글 시리즈입니다. 그리고 필자 또한 도그냥과 같이 사업개발 직무에 대해 최대한 많은 사람들에게 쉽게 알리고자 책을 집필하고 있습니다.

​

본 책은 필자에게는 이루지 못한 메이플M 기획자의 삶에 대해 또는 기획자가 하는 일에 대해 알 수 있었던 책입니다. 그리고 필자가 쓰고 있는 책을 어떠한 방식으로 써 나가면 좋을지 참고할 수 있는 책이었습니다. 오늘도 서론이 길었습니다. 그럼 필자가 밑줄 친 내용을 살펴보시죠.

​

현업 기획자 도그냥이 알려주는

서비스 기획 스쿨

이미준 저

​

"하나의 서비스가 나오려면 회사의 비즈니스 방향을 이해하고, 이용자를 분석하여 전략을 짜야 하며, 이를 구현하기 위해 어떤 데이터가 필요한지, 우리의 시스템은 그게 가능한지, 그리고 이것을 운영하기 위해 고객이 보지 않는 곳에서 업무자들은 어떤 일을 해야 하는지 등을 정의하고 만들어내야 한다. 이 모든 프로세스를 겪어보지 않고는 서비스 기획을 온전히 배웠다고 할 수 없다."

​

"많은 이들이 서비스 기획자와 디자이너를 구분하지 못한다. 그래픽을 다루는 직무가 아닌데도 서비스 기획자의 업무를 UI를 설계하는 것으로 치부하거나 UX만 전문적으로 연구하는 사람으로 선을 긋는다. 하지만 실제 이 직무에 종사하는 사람들이 일하는 모습을 보면 디자인 툴을 사용하지 않는데도, 개발을 하는 직무가 아닌데도, 온라인 서비스를 만드는 프로젝트 한가운데에서 일하고 있음을 확인할 수 있다."

​

"모호한 인식은 서비스 기획자를 뜻하는 수많은 명칭에서 드러난다. 여러 기업의 구직 광고를 보면 웹기획자, 앱기획자, 웹마스터부터 시작해서 UX기획자, UX디자이너, UX/UI 기획자, 프로덕트 오너, 프로덕트 매니저, 서비스 기획자 등등이 나오지만 상세 설명을 읽어보면 결국은 똑같은 일을 하는 직무를 뜻한다는 것을 알게 된다."

​

"서비스 기획은 한국에만 있는 직무일까? 이 글을 처음부터 읽었다면 눈치챘겠지만 영어로 된 직무명이 있다. 적어도 내가 지향하는 서비스 기획자는 해외에서 '프로덕트 매니저 Product Manager'라고 불리는 사람과 하는 일이 비슷하다."

​

"좀 더 세부적으로 이야기해 보자면 전략 기획자와 서비스 기획자는 이런 점이 다르다. 첫째, 전략 기획이 비즈니스 생태계에서 살아남을 비즈니스 모델을 만드는 것이라면, 서비스 기획은 사용자 반응을 보며 계속해서 이 모델을 정교화시키는 피봇을 빠르게 실행하여 시스템 속에서 작동시킨다. 끊임없이 살아 움직이는 서비스에 계속 피를 돌게 하는 역할이다. 둘째, 전략 기획자가 언제 어디서나 방향을 잃지 않도록 하늘에 북극성을 띄워주는 사람이라면, 서비스 기획자는 그 북극성을 목표로 어떻게 바다를 헤져 나갈지 선원들과 상의해서 노를 저어가는 사람이다. 파도가 강할 때와 약할 때, 나무로 만든 통통배로 갈지 철로 된 선박으로 갈지에 따라 방법이 달라질 테지만 어쨌든 북극성을 따라가도록 하는 게 서비스 기획자의 업무다. 예를 둘어 전략 기획에서 '고객의 경험을 관리하여 긴밀하게 서비스를 이용하도록 해야 한다'라고 정의하면, 서비스 기획자는 시스템적으로 긴밀한 연결 관계를 만들기 위한 구체적 고민을 해야 한다. 그래서 서비스 기획자에게는 화려한 스포트라이트가 비추는 성공 스토리보다는 실패 스토리가 넘쳐나고 최초의 북극성을 만든 CEO보다 드러나지 않는다. 하지만 북극성이 의미하는 게 무엇인지 아는 것부터 어떻게 노를 저어가는 게 좋을지 선원들과 상의하는 사람은 바론 서비스 기획자다."

​

"하지만 한 가지는 명확하다. 어디에서 일을 하든 처음에는 부끄러움을 무릅쓰고 이 살마 저 사람에게 물어가며 비즈니스 정책과 시스템을 파악해야 한다는 것이다. 일을 잘하려면 필요한 부분이기도 하지만 어쩌면 그게 이 일에 가장 빠르게 애착을 갖는 방법일 수 있다. 마음에 드는 이성과 연애를 시작할 때 그가 좋아하고 싫어하는 모든 것을 알고 싶은 것과 마찬가지다."

​

"서비스 기획자 혹은 프로덕트 매니저는 비즈니스, UX, 기술 영역을 망라하여 프로덕트(서비스)를 구현하기 위해 기획하고 관리하는 사람을 말한다. 쉽게 말하면 비즈니스 모델상의 수익 구조, 고객과의 접점, 지향점 등을 종합하여 서비스를 만들고 성장하도록 관리한다는 의미다."

​

"서비스 기획자의 역할은 '문제없이 서비스를 구현하기 위해 필요한 모든 것을 할 수 있도록 만드는 것'이다. 여기서 '모든 것을 한다'는 말은 UX를 분석하여 얻은 비즈니스 이슈를 해결하고 구현해 내는 것이다. 그러자면 법적/기술적으로 발생할 수 있는 문제를 찾아내고 그것을 적절한 방식으로 해결해나가야 한다."

​

"그렇다면 현장에서 서비스 기획을 할 때 가장 중요한 점은 무엇일까? 앞서 서비스 기획은 UX를 분석하여 얻은 비즈니스 이슈를 해결하고 구현해 내는 것이라고 했다. 즉 가장 중요한 것은 바로 '문제 해결'이다. 문제 해결책은 UI적인 것일 수도 있고, 프로세스에 관한 것일 수도 있고, 신기술을 도입하는 것일 수도 있다."

반응형

"본인의 기획이 부족하다는 사실도, 기획된 프로덕트에 문제가 있다는 사실도 프로젝트가 진행되어야만 알 수 있다. 서비스를 고민하는 부분이 서비스 기획자의 역량과 자질이라면 프로젝트를 순조롭게 진행하는 것은 스킬의 영역이다. 발로 물을 차는 법을 배우지 못하면 수영을 할 수가 없듯 프로젝트에 참여해서 진행하는 방법을 모르면 원하는 서비스를 만들어낼 수 없다."

​

"서비스 기획자가 고민을 얕게 하면 프로젝트 수행은 굉장한 난항을 겪게 된다. 특히 개발이나 디자인으로 해결하지 못하는 법적인 문제가 발견된다거나 사업적으로 해결 못할 외부 요인이 나타나면 프로젝트는 파행에 치닫고 워터폴 방식인데도 요건을 자꾸 바꾸고 추가하게 되면서 진행 순서가 뒤죽박죽 꼬이게 된다."

​

"기획자는 결국 기획을 해야 한다. 어떤 프로젝트 방법론을 선택하느냐보다는 머릿속에 뭉게뭉게 피어있는 기획을 (문서가 있든 없든) 프로젝트 팀원에게 구체적으로 전달할 수 있어야 하고, 팀원 스스로 자신이 무엇을 만들고 있는지, 무슨 일을 해야 하는지 알 수 있게 해야 한다. 기획자의 기획은 비즈니스 모델에 대한 이해를 바탕으로 해당 시스템 구조 내에서 구현 가능한 IT 기술과 고객에게 의미있는 UX를 만들어주는 UI가 포함된 것이어야 한다. 어느 것 하나도 기획자 혼자 만들어낼 수 있는 것들이 아니다. 그렇기에 기획자는 설명하고 또 설명해야 한다. 방법론에 맞는 방법으로 소통하고 또 소통해야 한다."

​

"요청사항의 목표와 방법이 회사 서비스의 거대한 방향성에 부합하는지 제로베이스에서 판단해야 한다. 때문에 현업부서와의 미팅에서 가장 중요한 질문은 방법적인 부분이 아니라 현업이 요청하게 된 '진짜 목표'를 파악하는 것이다. 최근의 현업 실무자들은 웹/앱 서비스에 관심이 많기 때문에 타사 UI를 캡쳐해온다던가 와이어프레임에 준하는 형태로 그려와 방법적인 부분을 명확하게 요청하기도 한다. 하지만 이것은 현업부서의 목표에 맞추어 현업 실무자가 선택한 하나의 대안일 뿐이다. 회사 서비스의 비즈니스 전략과 맞지 않을 수도 있고, 애초에 기술적으로 불가능할 수도 있다. 서비스 기획자는 현업부서가 원하는 진짜 목표를 기반으로 전체 프로덕트의 방향성에 맞는 대안을 새로 고민해야 한다."

​

"서비스 기획자에게 필요한 덕목은 요청된 사안이 불가능하더라도 현업 실무자가 말하는 요청사항의 배경과 목표를 듣고 함께 대안을 찾으려 노력하는 자세에 있다. 그러려면 먼저 요청사항의 필요성에 공감해주어야 한다. 그 요청이 사내 높은 사람의 비논리적인 지시에 의한 것일 수도 있다. 들어보지도 않고 배타적일 필요는 없다. 그 다음은 직무적 신뢰감을 주는 것이다. 현업부서 입장에서는 서미스 기획자도 기술직이다. 서비스 기획자가 시스템이 어쩌고저쩌고 하면 알아듣기 어려워 한다. 최대한 상황을 쉽게 설명해주고 대안을 제시할 수 있어야 한다."

​

"'서비스의 완결성'은 고민의 깊이와 넓이에 의해 결정된다. 그리고 이러한 고민이란 서비스 기획의 3요소인 자사의 IT 구조와 역량, 비즈니적 이해, 고객의 UX에 대한 분석을 바탕으로 서비스 전략을 만들어내는 과정을 뜻한다."

​

"정책은 수십 가지가 생각날 수도 있고 한 가지도 생각나지 않을 수도 있다. 하지만 처음부터 걱정할 필요는 없다. 어차피 프로젝트를 진행하다 보면 서비스 완성도를 위해 지속적으로 정책이 추가된다. 다만 숙련된 기획자는 이런 것을 떠올리는 속도가 상대적으로 빠를 뿐이다."

​

"현업부서에서 서비스 운영 개발 요청서를 받았을 때 법적으로 문제가 될 만한 부분은 없는지 점검해야 한다는 것 쯤은 알고 있을 것이다. 개인정보를 활용한다면 개인정보보호법에 대한 부분을 고려해야 하고, 특정 회사와 계약해서 진행되는 서비스라면 계약 조건에 대한 부분을 검토해야 한다."

​

"어떤 양식으로 요구사항 정의서를 쓰나냐는 사실 중요한 것이 아니다. 이 요청사항을 하루라도 빠르게 전달해서 협업자들이 앞으로 해나가야 할 일의 중요성이나 방향성, 스펙에 대한 감을 잡고 파악할 수 있도록 하는 것이 중요하다. 그들도 받자마자 컴퓨터 앞에 가서 바로 코딩할 수 있는 것이 아니기 때문이다. 비즈니스 전략 기획의 산물이 서비스 기획이라면 개발자의 역할은 이 서비스 기획을 실제로 구현되게 만드는 것이다. 우리가 고민한 시간만큼 또 다른 고민이 시작된다. 그래서 개발하기에 잘 정리된 내용이 아니면 난감해야할 때가 많다."

​

"IT 서비스와 관련된 무언가를 진행하고 있다면, 비공식적으로라도 오픈하고 개발부서에 수시로 물어보는 것이 중요하다. 법무도, 개발도, 재무도 우린 그 무엇도 정확하게 예상할 수 없다. 심지어 해당 기간에 개발자의 일정이 비어있지 않으면 어쩔 텐가? '기획안만 잘 준비하면 개발은 착착 진행되겠지'라고 생각하는 건 지금 똥을 만들고 있다는 뜻이다. 온라인 서비스는 눈에 보이지 않는 부분이 훨씬 많다. 일을 혼자하려고 해서는 안 된다."

​

"물론 해당 기획 건을 공유할 때는 주의해야 할 점이 있다. 기획은 여전히 초안이기 때문에 기획 내용을 설명할 때 '이렇게 하고 싶다'라고 해야지 '이렇게 정했다'라고 해서는 안 된다. 이 작은 차이가 협업을 하는 태도와 분위기를 결정짓는다. 기획한 바를 설명하되 개발 가능성에 대해서는 개발 담당자가 더 고민하고 찾아볼 수 있도록 여지를 주는 것일 필요하다. 얼토당토않은 내용을 기획해서 찾아가도 이를 해결해주려는 개발자를 만나려면 나부터 가는 말을 곱게 해야 한다."

​

"사실 어떤 선배 기획자라도 전체 서비스를 통괄하고 시스템 정책을 모두를 알고 있을 수는 없다. 서비스는 멈춰있지 않다. 계속 변한다. 따라서 새로운 서비스를 기획하여 추가하기에 앞서 현행 시스템 정책과 서비스 상태를 파악해야 한다."

​

"정책을 정한 이유를 알고 싶으면 기획자 선배에게 묻고, 서비스 로직을 파악하고 싶다면 개발자 선배에게 묻자."