'나'라는 서비스 기획자 정의하기
기획자로 7년째 살아가고 있습니다.
'기획'으로 먹고 살기까지
기획자의 이름으로 '나도 먹고 살 수 있겠구나' 하기까지 그렇게 오래 되진 않았습니다. 햇수 상으로는 이제 7년이 넘어가는 기획자, 작년에 퇴사를 했고 독립을 했고 이리저리 부딪히면서 구르다가 이제야 저는 제 일을 스스로 정의하게 되었어요.
과거를 돌아보면 대부분 스타트업들이었고, 사수 없는 1인 기획자 체제였기 때문에 저는 '회사에서 원하는 기획자'로의 역할에 맞춰 일했습니다. 경험도 부족했고, 매일 일하느라 정신이 없었기에 저라는 사람이 구체적으로 뭘 할 수 있는 사람인지 알지 못했어요. 그나마 책이나 주변 사람들이 말하는 정보를 조합하며 제 역할을 이해했죠.
크고 작은 스타트업을 넘나들면서 자연스럽게 연봉이나 이력서는 늘어났지만, 늘 마음속에는 기획자라는 사람은 누구인지, 어디까지 내가 할 수 있는 사람인지가 계속 궁금했습니다. 그리고 창업을 하게 되면서 저는 프리랜서 기획자에서부터 UI 디자이너, 웹 디자이너를 넘나드는 '나'라는 기획자를 알아가게 되었어요.
그리고 약 1년 넘은 경험을 통해서 정의하게 된 '나'라는 서비스 기획자와 또 제가 생각하는 서비스 기획자를 나름대로 정의해 볼게요.
상품 기획과 서비스 기획 그 사이
과거로 돌아가, 저의 첫 커리어는 개발자를 위한 온/오프라인 교육을 기획하고, 운영하는 일이었어요. 쉽게 말하면 교육 매니저와 직무와도 유사했습니다. 다만 회사에서 원하는 직무는 지금 생각해도 '상품 개발'에 가까웠던 것 같습니다.
회사에서는 매달 더 빠르게, 시장의 수요를 분석하고, 시장에서 눈에 띄는, 높은 매출을 끌어올릴 수 있는 '신상품'을 만들길 원했지만, 저는 조금 다른 방향으로 '어떻게 하면 수강생들이 느끼는 경험을 매끄럽게 만들 수 있을까?'에 관심이 많았던 것이죠.
특히 제가 담당한 장기 취업 과정의 경우에는 중도 포기하는 수강생들의 컴플레인과 스트레스가 높은 편이었고, 그들의 불편함은 결국 중도 환불로 이어졌기에 어떻게든 그들의 고민을 들으려고 노력했습니다. 한 반에 20명 정도가 있어도 1인당 30분씩 '1:1 상담'을 주기적으로 진행하곤 했습니다. 그리고 효과적인 학습/성장 루트를 찾기 위해 개발자도 아닌 사람이 늘 개발자 행사에 참여하고, 심지어 두 팔 걷고 뛰어들며 자원봉사를 하며 개발자 생태계를 알아가게 되었죠.
지금 생각해 보면, 그게 사용자 경험에 귀를 기울였던 제 나름의 서비스 기획 방법이었어요. 주기적으로 상담을 한 덕분에 중도 이탈할 고객들을 붙잡아 졸업시키고, 매 기수 프로그램 진행 방식도 더 개선했어요. 해커톤을 운영하거나 참여한 후 그 방식을 교육 과정에 녹이기도 하고, 참 열정적이었던 시기였어요. 네트워킹 목적을 위해 학원 내 졸업생 행사를 주최하기도 하며 할 수 있는 것은 다 했었던 기억이 있어요.
보너스
뤼튼 GPT-4에게
상품기획 VS 서비스 기획을 물어봤어요.
- 상품 기획의 사례 : 가전제품 회사에서 세탁기를 개발할 때, 상품 기획자는 세탁기의 세탁 성능, 에너지 효율, 사용 편의성, 디자인 등을 고려하여 제품을 설계하고 기능을 결정합니다.
이를 통해 가정에서 사용하기 편리하며, 다양한 사용자 요구를 만족시킬 수 있는 세탁기를 개발할 수 있습니다. 마케팅 전략을 수립하여 타깃 고객에게 제품을 알리고 판매 채널을 구축하는 것 역시 상품 기획자의 역할입니다. (제품의 성능, 디자인 등을 개선하고 판매를 계획)
- 서비스 기획의 사례: 은행에서 모바일 뱅킹 앱을 개발할 때, 서비스 기획자는 고객이 편리하게 거래를 할 수 있는 UI/UX 디자인, 다양한 금융 서비스 제공, 거래의 안전성 등을 고려하여 앱을 설계합니다.
이를 통해 고객들이 사용하기 편리하고 안전한 모바일 뱅킹 앱을 경험할 수 있습니다. 고객들이 해당 서비스를 쉽게 찾고 이용할 수 있도록 한 마케팅 전략 수립 및 관련 인프라를 구축하는 것 역시 서비스 기획자의 업무에 포함됩니다. (서비스 기획은 고객이 얻는 경험과 만족감에 초점을 맞추어 전략을 수립)
아쉬운 점은, 그렇게 만든 교육 과정이었지만 비즈니스 목적을 달성할 수 있게 확장시키지 못했다고 생각하고 있어요. 서비스 개선에 많은 에너지를 쏟았지만, 결국 회사의 목표에는 부합하지 않아 대대적인 구조 개편이 있었고, 저도 그 시기에 새로운 커리어를 위해 그만두었습니다.
내가 경험한 서비스 기획자
이후 저는 IT서비스 기획자로 직무를 바꾸는 데 성공했고, 몇 군데의 스타트업을 거치며 웹과 앱을 설계하는 기획자로 경험을 쌓았어요.
그동안의 경험을 돌아보면 국내의 '서비스 기획자'들의 일은 대부분 유사하게 진행되었습니다.
대기업 경험은 해본 적이 없기 때문에 생략하겠지만 (10인 이하의 회사, 30인 이하의 회사, 100인 이하의 회사) 대부분 대표/리더급이 결정한 비즈니스 의사 결정에 따라 우리가 만들 웹이나 앱 개발을 위한 요구사항을 분석, 정리하고 디테일한 화면설계 문서를 만들어 개발자, 디자이너에게 문서를 전달하는 사람이었습니다.
신사업팀/스타트업 경험 당시에는, 비즈니스의 변화가 빨라서 대표/리더의 의사결정이 하루아침에 여러 번 바뀌는 경우들이 있었는데요. 이 경우 슬프게도 기획자의 입장에서는 몇 주간 고민했던 화면설계서 문서도 비즈니스 방향성과 다르면 과감히 날려버려야할 때도 있었습니다.
또한 빠른 출시를 위해서는 고객의 데이터를 살펴보면서, 구두로 요구사항을 전달하거나 와이어프레임 위주로 전달하는 경우도 많았는데요. 덧붙여 CS와 운영에 대한 역할도 같이 부담했기에 기획자 역할 범위가 넓은 편이었고요.
반대로 프리랜서 기획자로 일했을 때에는, 처음에는 각 부서간의 업무의 범위가 명확한 점에 대해 놀랐었습니다. 대신 이해관계자가 훨씬 많기 때문에 커뮤니케이션 비용이 올라고, 그렇기에 깊이 있는 사고와 꼼꼼한 문서 작성이 중요했습니다. 덕분에 그동안 기획서 테크닉이 많이 늘어났던 것 같습니다.또한 스타트업과 달리 6개월, 1년 등 스타트업에 비해 긴 기간에 걸쳐 다양한 팀들과 소통하며 워터폴(폭포수) 방식으로 진행되는 프로젝트들이었기에 여러 가지 케이스를 뜯어보며 문서 명세화에 공을 들였습니다. :)
요구사항을 명세화하는 사람
이런 과거의 경험을 토대로 제가 내린 결론은 서비스 기획자는 개발자, 디자이너에게 전달하는 '(비즈니스단의) 요구사항을 명세화하는 사람'이라고 정의 내릴 수 있었습니다.
사전적 정의로도 '명세'라는 단어는 <명세 明細 : 분명하고 자세함> 하다는 의미이니, 결국 조직의 팀 구성과 일하는 방식에 따라서 달라지겠지만 핵심 위주로 빠르게 명세하고 커뮤니케이션하면서 전달할 것이냐, 또는 모든 케이스를 뜯어보며 세부적인 것까지 명세해서 전달할 것이냐의 차이가 있었던 것이죠.
공학 관점에서의 기획자
최근에는 '소프트웨어 공학'과 관련된 서적을 살펴보면서 'SRS (소프트웨어 요구사항 명세서)'라는 용어를 발견하고 깊게 공감했었습니다. 그래서 기획자로서 '화면설계를 작성해요'라는 말보다는 '(사용자의) IT서비스 개발을 위해 필요한 요구사항을 구체적으로 명세해요'라는 서술을 하고 있습니다. 화면설계라는 어휘가 주는 느낌이 주로 와이어프레임+주석이라면 '요구사항 명세서 (명세문서)'는 더 큰 개념으로 이해되기 때문이죠.
요구사항 명세(SRS)라는 용어는 IEEE에서 설정한 국제적인 기준 용어로 사용되고 있기도 하니, 갑자기 나온 단어는 아니라는 점을 알려드립니다. 그 안에는 비즈니스 요구사항부터 정보구조도, 운영 정책, 와이어프레임, 기능정의(주석으로 처리되기도 함) 등을 개발을 위한 모든 정보를 담고 있는 문서라 설명하기도 합니다.
그림 2. 모든 프로젝트 이해관계자가 알아야 할 요구공학을 예시와 함께 알려주니 추천합니다....! * 참고서적 : 소프트웨어 요구사항 분석 3 (https://www.yes24.com/Product/Goods/38975426)
기획서를 확장하며 일도 확장하기
이런 관점에서 저는 기획자의 역할을 와이어프레임과 주석 세트에서 벗어나 조금 더 확장시켜보고 있습니다. 우리 서비스 기획자는 누군가(예 : 고객 또는 사용자)의 요구사항을 분석하고, 이해하는 전문가라는 생각을 말이지요. 고객/사용자의 요구사항을 디자이너, 개발자에게 잘 전달하기 위해 구체적으로 문서화할 수 있는 스킬을 가지고 있을 뿐만 아니라, 전문가로서 다양한 자료 분석과 인터뷰를 통해서 새로운 제안을 할 수도 있게 되는 것이죠.
'와이어프레임과 주석'으로 구성된 문서의 틀을 밖에서 접근하면 왜(WHY)가 조금 더 해소가 됩니다!
우리가 왜 이러한 문서를 만들어야 하는지, 이 지루한 문서 작업에서 진정 무엇을 전달하고 싶은지 그리고 내가 왜 이 일을 하는지를 조금 더 생각해 보게 되었고요.
보너스로 우리의 일이 얼마나 중요한지를 알게 되면 자신감도 올라가는 것도 이득이에요.
서비스 기획자가 그런 일을 하고 있기 때문에 디자이너, 개발자들이 제품을 디자인하고 개발할 수 있게 도와주고 있고요. 이제 세탁기를 팔던, 악기를 팔던, 또는 무형의 가치를 팔더라도 디지털이 들어가는 시대이니 더욱이 우리가 있어야겠죠.
기획자들은 비즈니스 가설이 실제 사용자에게 통하는지를 검증할 수 있는 결과를 만드는 사람이지 않을까요? 여기까지 오늘의 글을 마무리 지어보겠습니다.
