기획자는 어떻게 '성장'을 정의할 것인가
평범한 1년 차 주니어 기획자의 고민
요 며칠 약속이 취소되어 시간이 붕 뜨게 됐다.
계획에도 없던 시간이 생겼으니,
오래전부터 공부하고 싶었던 것들을
검색해보며 아카이빙 해두었다가
주말에 아이스커피를 한잔 시켜놓고
즐거운 마음으로 공부를 하고 있었다.
그러다가 문득,
'성장하지 않으면 죽는다'라는 문장이,
불현듯 내 머릿속을 스쳤다.
(왜인지는 잘 모르겠고... 공부가 하기 싫어서?ㅎㅎ)
IT업계에서 종사하는 사람들이라면
직무에 상관없이 대부분이 겪고 있을,
일종의 만성적인 강박.
'성장하지 않으면 죽는다'라는 문장은,
분명 우리를 끊임없이
앞으로 나아가게 하는 원동력이 된다.
하지만 위 문장의 구조를 좀 더 자세히 뜯어보면,
우리가 '성장'을 쫓는다기보다는,
'성장하지 않음'이 우리를 쫓는 형상에
더욱 가깝다고 볼 수 있다.
나의 강박은, 성장에 대한 '갈망'인가,
아니면 도태에 대한 '두려움'인가.
어찌 됐건 이러나저러나,
강박에 시달려야 한다는 사실이 변하지 않는다면,
우리는 먼저 이 '성장'이라는 것이
대관절 무엇인지 나름대로 정의하는 것이
가장 중요한 숙제가 되겠다.
이해를 위해 그림을 그려보았다.입사하자마자 신입임에도
꽤나 큰 프로젝트를 맡았던 나는,
내 인생의 우선순위에서 프로젝트를 제외한
나머지 모든 것을 덜어냈다.
제대로 아는 것이 하나도 없는 데다,
터무니없이 실력이 부족한 신입 기획자가
수년간의 경험이 있는
여러 개발자들과 디자이너들에게
프로젝트의 청사진 하나를 대뜸 건네며
'우리는 이 방향으로 가야 한다'라고 설득하는 것이
끔찍한 농담거리가 되지 않기 위해.
나는 내 인간관계와 일상생활을 뒤로하고,
참으로 많은 밤을 지새웠다.
다행히도 여러 고마운 사람들의 도움으로 인해,
맡았던 프로젝트는 나름 성공적으로 진행됐고,
함께 일을 진행했던 다른 개발자, 디자이너 분들은
내가 신입 기획자라는 것을
프로젝트가 끝나고 한참 후에야 알게 됐다고.
그런 나를 조용히 지켜보시던 몇몇 시니어 분들은
내가 "너무 빨리 지칠까" 걱정이 된다고 하셨고,
개인적으로 내가 멘토로 모시는 형님께서는
그런 나를 보며 호통을 치시기도 했다.
불나방처럼 뛰어드는 열정은
많은 신입들이 경험하는 커다란 실수 중 하나이며,
'번아웃'은 누구나 반드시 오게 되어있다는 것.
그리고 그렇게 온 '번아웃'은 추후
여러 사람들에게 더욱 큰 피해를
안겨줄 수 있다는 것.
당시에는 '번아웃'이라는 개념을 이해하기 힘들었다.
그도 그럴 것이,
또래 학생들에 비해 인생의 길을 돌아돌아
(나보다 훨씬 더 많이 도신 분들도 많겠지만)
마침내 그토록 꿈꾸던 기획자가 되었는데,
어떻게 '지친다'라는 말이 용납될 수 있단 말인가.
최근에는 우연히 몇몇 기획자 분들과
사내 스터디를 진행할 기회가 생겼는데,
기획에 대한 이런저런 이야기를 나누다가,
연차에 상관없이 모든 기획자가 고민하는
보다 '근본적인 질문'에 대해
이야기를 나누게 되었다.
"기획자는 무엇을 하는 사람인가?"
"좋은 기획자가 되기 위해서는
어떤 역량을 갖춰야 하는가?"
여러가지 이야기들이 나왔고,
바라보는 관점에 따라 다르게 정의할 수 있지만,
결국 내가 정의한 "기획자"란 다음과 같다:
우리가 지금
무엇을 실행해야 하는지를 잘 찾아내고,
실행해야 할 그 무엇이
'반드시' 잘 되게 하는 사람.
한국에서 '기획자의 롤'에 대한 의문은
꽤나 오랫동안 존재해왔다.
가령, "외국에는 기획자가 없는데
왜 한국에만 이런 직무가 있는가"처럼.
최근에는 'Product Owner', 'Project Manager',
'Product Designer'와 같은 직무들이
외국에서 먼저 핫하게 떠오르며
이러한 의문점들이 이제는 조금
old-fashioned 하게 보이게 됐지만,
여전히 많은 곳에서 비슷한 의문은
계속해서 제기되고 있다.
그러나 한 가지 확실한 것은,
외국에서 최근의 PO, PM과 같은
개념이 생기기 전까지
기획자 '타이틀'은 없었지만,
기획자 '일'은 분명히 있었다는 것.
회사와 조직의 상황에 따라 기획자의 '일'은
여러 조각으로 파편화되어
어떤 부분은 창업자가 맡기도 하고,
어떤 부분은 사업개발팀이 맡기도 하며,
어떤 부분은 데이터 분석팀이 맡고,
어떤 부분은 디자이너가,
또 어떤 부분은 개발자가 맡아 왔을 뿐이다.
이렇게 바라보면,
기획자에게 필요한 역량은 조금 명확해진다.
적어도 나와 같은 '서비스 기획자'라는
타이틀을 달고 있다면,
다음과 같은 일을 모두 할 수 있어야 한다.
1. [프로덕트의 방향성과 가치 창출]
우리는 창업자나 CEO처럼,
프로덕트가 우리 이용자들 뿐만 아니라
그 밖의 산업 혹은 사회에 제공할 수 있는
가치와 방향성에 대해 깊게 이해하고
고민할 수 있어야 한다.
(가장 어려운 부분이라 생각)
2. [사업 지속성과 이익 창출]
우리는 사업 개발팀처럼,
프로덕트가 '지속 가능한' 가치를
더욱 크게 창출할 수 있도록,
사업적인 측면을 이해하며 프로덕트와 사용자 간의,
공동의 이익을 실현할 수 있어야 한다.
3. [현상을 통한 문제 발견과 근거있는 해결방안]
우리는 데이터 분석 팀처럼,
프로덕트 내 데이터를 끊임없이 들여다보며
문제가 발생하지는 않았는지,
우려가 되는 부분은 없는지,
더 발전할 수 있는 부분은 없는지
혹은 어떤 부분에서 사용자들의
페인 포인트가 발생하는지,
그리고 어떤 방법이 문제들을 해결하는데
가장 효과적인지, 찾아낼 수 있어야 한다.
4. [아이디어의 실현과 사용자 경험 설계]
우리는 디자이너처럼,
보이지 않는 개념을 시각화할 줄 알아야 한다.
위 1-3에서 열거했듯이
서비스의 가치와 방향성에 대해 고민하고,
사업적인 측면에서 더 큰 이익을 달성할 수 있도록,
데이터를 통해 얻은 인사이트를 바탕으로
어떻게 서비스에 반영할 수 있을지,
사용자 흐름과 서비스 내 화면들을
와이어 프레임으로 그려낼 수 있어야 한다.
디자이너처럼 아름다운
최종 UI 결과물을 낼 수도 없고,
사실 그럴 필요도 없지만, 꽤나 상세한 부분까지
플로우와 그림은 그릴 수 있어야 한다.
이에 따른 정책도 챙겨야 할 테고.
(UX 디자이너, 프로덕트 디자이너들의 롤과
일맥상통하는 부분이며, 많이 겹치기도 한다.
무엇에 더 중점과 강점을 두느냐에 따라
타이틀이 달라지는 듯 하지만,
결국 비슷하다고 생각)
5. [최종 결과물이 나오기까지의 책임자]
디자이너와 비슷한 맥락으로,
우리가 개발자가 될 필요는 없지만,
적어도 개발자들이 "왜" 개발을 해야 하는지
공동의 목표를 이해시킬 수 있어야 하고,
프로젝트를 진행함에 있어서
기술적인 이슈는 없는지,
일정에 착오는 없는지,
나타난 오류의 문제는 무엇이고
이를 해결하기 위해서는
어떤 의사결정을 해야 하는지 등등,
발생할 수 있는 다양한 문제들에 대해서
원활한 커뮤니케이션을 할 수 있도록
그들의 사고방식이나 기본적인 개발 용어는
이해할 수 있어야 한다.
.
.
.
쓰다보니 내가 정의한 기획자의 롤과 역할이
다소 어마어마해 보인다.
물론 나는, 위 역할들을 잘 해내기에는
턱없이 부족한, 입사한지
아직 1년도 채 되지 않은 병아리 기획자다.
(아마도 조직에서 가장 위험한 존재가 아닐지...)
자. 그렇다면, 다시 본론으로 돌아와서.
우리는 '성장'을 어떻게 정의해야 할까?
어차피 성장에 대한 스트레스를
기어코 받아야만 한다면,
이왕이면 스트레스도 '잘' 받는 것이
중요하지 않을까?
무분별하게 스트레스를 관리하지 못해
'번아웃'이 온다면, 그 피해는 우리뿐만이 아니라
우리 팀원들, 조직들에게도 전해질 수 있다.
그리고 무엇보다, '성장'에 대한 스트레스 때문에
정작 우리가 원하는 '성장'을
더 이상 할 수 없는 역설이 발생한다면
그것이야말로 진정한 비극이 될 것이다.
IT업계에서 기술은
눈을 깜빡일 때마다 발전하고 있다.
그리고 주니어 기획자들에게는
언제나 기술에 대한 막연한 갈증이 있다.
"누구는 디자이너만큼이나
디자인 툴을 잘 다룰 줄 안대"
"누구는 개발을 배우며 밤마다 코딩을 한대"
이런 대단한 기획자들의 이야기가 들릴 때마다,
나는 죄책감에 시달렸다.
맡은 과제들을 잘 해결하기 위해
하루 종일 시간을 들여도 모자른데,
어떻게 저 사람들은 비슷한 연차에
자기 계발과 사이드 프로젝트까지
세마리 토끼를 다 잡을 수 있는 거지?
나는 저들에 비해 게으르고 도태한 기획자인 걸까?
나는 이렇게 남들과 비교하며
스스로를 꽤 오랫동안 괴롭혔다.
물론 한 때, 나도 없는 사비를 털어가며
비싼 디자인 툴들과 인강들을 구입해 공부했었다.
애플의 HIG와 구글의 머터리얼 디자인을 찾아보며
직접 와이어프레임부터
프로토타입까지 만들어 보기도 했다.
한 때, (그리고 지금도) 취미삼아
개발 공부를 끄적끄적하고는 있지만
결론적으로, 기획자는 디자인과 개발을
디자이너들과 개발자들만큼 잘할 수도 없고,
잘할 필요도 없다.
취미로 공부하는 사람들과
우리 스스로를 비교할 필요가 없다.
남들이 하는 것을 '나도' 따라 할 필요가 없다.
우리 스스로가 잘못 정의한 '도태'와
불필요한 '두려움'에 시달릴 필요가 전혀 없다.
Elon Musk의
The First Principles Method으로 생각해보자.
기획자의 가장 Fundamentals는 무엇인가?
스케치나 프레이머를 잘 다루는 기획자는
훌륭한 기획자가 아니다.
JS와 MangoDB, Python을 자유롭게 쓰는
기획자는 훌륭한 기획자가 아니다.
훌륭한 기획자는
How는 전문가들에게 맡기고,
Who-Why-What을 잘하는 사람이다.
그러므로, 우리는 취미로
디자인과 개발을 배우고 있는
몇몇 기획자들을 보며
스스로 도태되고 있다고 생각할 필요가 없다.
우리에게 필요한 성장은 그러한 것이 아니며,
에너지를 원치 않는 곳에
불필요하게 소비할 필요는 없기 때문이다.
적어도 내게 필요한 성장은, 다음과 같다:
1. [프로덕트의 방향성과 가치 창출]
업계의 여러 서비스들의 동향을 파악하고,
관련된 기사나 아티클을 많이 찾아보자.
새로 생긴 비슷한 업계,
혹은 요즘 핫하다는 서비스들은 꼭 한번 써보자.
유저로서 나만의 경험은 어떤지 정리해보자.
2. [사업 지속성과 이익 창출]
인터넷을 조금 찾아보면
기업들의 재무제표를 확인할 수 있다.
굳이 재무제표까지 찾아보지는 않더라도,
BM이 어떻게 돌아가고 있고,
서비스 별로 어떤 부분이
매출에 크게 기여하고 있는지 알아보면 좋다.
우리 서비스의 매출을 늘리기 위해서는
무엇을 할 수 있을까?
3. [현상을 통한 문제 발견과 근거있는 해결방안]
데이터를 보고 의미있는 인사이트를
뽑아내려는 연습이 필요하다.
이건 사실 많이 어렵다.
내가 있는 조직은 데이터 툴이 너무 잘 되어있어서
별도로 데이터를 뽑기 위해
프로그래밍 언어를 몰라도
쉽게 데이터에 접근할 수 있다.
최대한 많은 데이터들을 찾아보며,
인사이트를 뽑아보고
나보다 잘 아는 사람들에게 물어보며
내가 분석한 내용이 맞는지 물어보는 것도 좋다.
또한, 한 평생 데이터 툴이 잘 갖추어져 있는 곳에
일할 수 있는 확률은 매우 낮은 편이므로,
데이터에 관심이 많다면,
약간의 공부를 하는 것도 도움이 될 것 같다.
라이터가 없이 부싯돌로도
불을 붙일 줄 알면 좋을 것 같은 느낌적인 느낌.
(RGRG?)
4. [아이디어의 실현과 사용자 경험 설계]
이건 그냥..
요즘 잘 되는 서비스들 많이 써보고,
UI가 왜 이렇게 배치되었을지 고민하며
UX에 대해서 많이 고민해보는 것이 좋을 듯하다.
서비스에 기능이 많아질수록
화면이 정말 너무 복잡해지는데,
선택과 집중을 할 수 있는 의사결정권은
내게 전혀 없으므로...ㅋㅋ
나는 아직도 화면 설계 능력이 많이 부족하다.
5. [최종 결과물이 나오기까지의 책임자]
개발을 할 줄 몰라도,
뭐가 어떻게 돌아가는지는 알아야 한다.
궁금한 건 이것저것 찾아보고, 메모해놓는다.
전반적인 얕고 넓은,
특정 개발 분야에 대한 인트로 느낌으로 가르쳐주는 개발 관련 영상들을 찾아보는 것도 꽤 도움이 된다.
물론 영상 시리즈를 끝까지 다 보고
머릿속에 넣을 자신은 당연히 없다.
.
.
.
글쎄.
내가 생각한, 현재 내 레벨에서의
기획자로서 성장 목표는 이 정도다.
이 외의 들리는 소음들에 대해서,
나는 스스로를 남들과 비교하며
자책하지 않으려고 노력하겠다.
내게는 이미 훌륭한 디자이너,
개발자 동료분들이 있으니까 말이다
나는, 내가 스스로 정의한
우리가 지금
무엇을 실행해야 하는지를 잘 찾아내고,
실행해야 할 그 무엇이
'반드시' 잘 되게 하는 사람.
이 되는 것에,
오로지 '훌륭한 기획자'가 되는 것에,
나만의 강박을 느끼도록 하겠다.
도태에 대한 '두려움'이 아닌,
성장에 대한 '갈망'을 말이다.
