7) 기획, 무엇을 만들지 결정하는 일
-직장인 8년차 서비스 PM편-
서비스 기획 또는 프로덕트 매니저라는 직군이 주목을 받기 시작한 것도 몇 년이 지난 지금,
회사에서 무슨 일을 하는지 묻는 질문에는 여전히 좋은 답변을 할 수 있을지 긴장하곤 합니다.
간혹 IT업계가 아닌 곳에서 일을 하고 계시는 분들께는 ‘기획’ 일을 한다고 설명하기도 하지만, 스스로 말하면서도 친절한 설명이 아님을 금방 깨닫습니다. 나의 업을 설명할 수 있는 좀 더 명확한 문장을 만들어내는 순간을 기다려왔지만, 서비스 기획이라는 일을 모두가 이해하기 쉽게 설명할 수 있는 단어가 좀처럼 쉽게 떠오르지 않았습니다.
연차가 쌓이면서 학생, 다른 업계의 직장인들, 부모님 등 다양한 대상들에게 설명을 여러 번 해보다 보니 듣는 사람의 배경지식에 상관없이 모두가 쉽게 이해하는 표현을 발견했습니다.
바로 ‘앱을 만든다'는 표현입니다.
이 설명을 들은 대부분의 사람들은 컴퓨터 프로그래밍을 하는 개발자의 모습을 떠올리며, 제게 개발은 언제 배웠는지 컴퓨터를 잘하는지와 같은 다소 난감한 질문을 주시기도 하지만 그래도 어떤 일인지 대략 감을 잡은 듯 보였습니다. 개발을 할 줄 아냐는 물음이 나오자마자 기다리기라도 한 듯 곧바로 준비한 문장을 덧붙입니다. ‘아참! 제가 개발을 직접 하진 않고 개발자한테 이런 거 저런 거 만들어 달라고 해요.’
이 말을 듣고 나면, 문과인 제가 어떻게 IT업계에서 일을 하는지 의심을 거두어들이고 비로소 이해하기 시작합니다. 이처럼 기획이라는 업을 ‘직접 만들지는 않지만 무엇을 만들지 결정하는 일’으로 정의한다면, 서비스 기획은 ‘직접 개발하지는 않지만 무엇을 만들지 결정하는 일'이라고 할 수 있겠습니다. 프로덕트 매니저라는 이름도 서비스 기획자라는 직군에 조금 더 역할이 추가되거나 빠지거나 한 정도로, 큰 차이는 없다고 보아도 무방합니다.
그런데 우리 모두는 일상적으로 무언가를 요구하는 일, 즉 ‘기획’을 생각보다 많이 하고 있다는 것을 알고 계신가요? 미용실을 떠올려보겠습니다. 어떤 스타일로 자를지 사진을 보여주기까지 하면서 구체적으로 요구하는 손님도 있는 반면, 미용사에게 모든 걸 맡기는 손님도 있습니다. 이에 대한 미용사의 반응도 각양각색입니다. 손님이 요구한 내용을 머릿결이 나쁘다는 이유로 거절을 하는 경우도 있고, 좀 더 어울릴만한 다른 스타일을 추천해주기도 합니다. 때로는 아무 말없이 잘라주었는데, 망했다는 생각이 들 만큼 어울리지 않는 머리 스타일이 되어있기도 하죠. 이때 손님을 기획자, 미용사를 개발자로 치환한다면 꽤나 실제 서비스를 만들 때의 기획자와 개발자의 커뮤니케이션 모습과 비슷해집니다.
뜬금없이 웬 미용실 이야기를 하냐고 물으신다면, 제가 생각하는 기획자란 ‘현재의 상황을 잘 이해하고 바라는 모습을 명확하게 이야기할 줄 아는 사람’이라고 생각하기 때문입니다. 실제로 제가 작성하는 기획 문서에는 ‘asis’와 ‘tobe’ 표현이 가장 많이 등장합니다. 현재의 상황을 파악하고 바라는 모습을 명확히 정의하는 것이 기획이기 때문인 것 같습니다.
실제 업무 현장에서는 한 줄의 코드로 바라는 모습을 전부 구현할 수 없기 때문에 한 가지 기능을 출시하는 데에도 수많은 코드 작업이 필요합니다. 머리를 잘못 자르면 다시 기르는 데 시간이 오래 걸리는 것처럼, 기능 출시도 마찬가지로 한 번 만들면 쉽게 변경하기 어려운 경우가 많기 때문에 당장 필요한 기능이라고 해서 마구잡이로 제품에 실을 수는 없습니다. 우리가 바라는 모습에 어울리는 것이 맞는지 신중히 판단해야 하고, 꼭 필요한 작업들만을 선정해야 합니다. 서비스를 만드는 데 필요한 기술적인 일은 개발자가 하더라도, 고객경험, 비즈니스, 일정 등의 다양한 맥락을 고려하여 ‘왜(why), 무엇(what)을 해야 할지 선정하는 것’은 기획자가 해야 하는 일이기 때문입니다.
기획자에게 프로그래밍 언어를 활용하여 코드를 작성하는 역량은 요구되지 않습니다. 다만 무엇을 해야 할지 정하는 일에 도움 되는 역량으로써 SQL, 통계적 지식 같은 데이터 분석 능력을 기대하는 경우는 많습니다. 기획자가 더 나은 판단과 선택을 하는 것을 원하기 때문입니다.
지금 생각하면 부끄러운 일이지만 저는 IT업계에서 처음 커리어를 시작했을 때, 이 부분을 잘못 이해하고 프로그래밍 언어를 터득해야 한다고 생각했습니다. 간단하게는 웹페이지의 화면과 인터랙션을 구현하는 HTML, CSS, javascript 를 배워 보기도 했습니다. 이후에는 python 같은 프로그래밍 언어 강의를 듣거나 AWS 자격증을 공부하는 등 지금 생각해 보면 삽질에 가까운 배움의 시간을 가졌습니다. 결론적으로는 이때 배운 스킬들은 현업에서는 전혀 사용할 일이 없었으므로, 무의미하다고도 볼 수 있는 시간이었습니다. 그나마 수확이 있다면 개발자의 사고 과정을 조금 더 잘 이해하게 된 것 정도일까요?
마치 외국인과 이야기할 때 외국어로 이야기하면 좀 더 의사소통이 편해지는 것처럼, 개발자가 사용하는 언어를 알고 나니 조금 더 그들이 하는 말을 이해할 수 있게 된 것이지요. 그러나 개발자로 전향을 꿈꾸는 것이 아니라면 지나친 프로그래밍 언어 공부는 필요치 않은 것 같습니다. 기획의 업을 하고 싶은 사람이라면 프로그래밍 언어 공부는 체험판 정도로 충분하다는 깨달음을 얻었던 것이죠.
그러나 시간이 지나 보니 이때의 경험이 무용지물인 것은 아니었습니다. 하나의 기능을 구현하기 위해 필요한 정보가 아주 많다는 것을 직접 체감해 볼 수 있는 시간이었기 때문입니다. 예를 들면 ‘버튼을 누르면 데이터가 저장된다'는 한 문장을 구현하기 위해서는 우선 눈에 보이는 부분인 버튼을 어떤 크기로 만들어야 하는지부터 시작해서, 데이터를 어떤 형태로 저장해야 하는지에 대한 설계, 수정은 허용할 것인지 등 제약사항에 대한 정의가 필요합니다.
‘역지사지'라는 사자성어가 가장 많이 떠오르는 시기였습니다. 기획자로부터 요구사항을 전달받아 만드는 개발자의 입장이 되어보니, 요구사항이 정교해질수록 커뮤니케이션 코스트는 훨씬 줄어드는 것을 체감했습니다. 제가 프로그래밍 수업을 들으면서 기대했던 것은 기술적 성장이었지만, 가장 큰 배움은 함께 일하는 사람이 가장 필요로 하는 것을 줄 수 있는 사람이 되어야겠다는 마음을 얻은 것입니다.
유사하게, 서비스를 만들기 위해서는 개발자와의 협업도 필요하지만 디자이너와의 협업도 필요합니다.
어떤 분야를 기획하는지에 따라 디자이너와는 이야기할 일이 없는 경우도 있습니다만, 눈에 보이는 요소를 만드는 일들은 대부분 디자이너의 손을 거칩니다. 이 역시 제가 사회초년생인 시절에는 디자인 툴을 배우는 데에만 몰두했었습니다. Sketch, Figma, Axure 같은 와이어프레임을 만드는 데에 적합한 툴부터 Adobe의 각종 소프트웨어들을 배우러 다녔습니다. 이것도 결코 아얘 무의미한 배움이었다고는 할 수 없지만, 제가 아무리 툴을 다룰 줄 안다고 해서 디자이너보다 더 좋은 시각적 작업물을 만들 수는 없었습니다. 생각하고 있는 바만 명확하게 표현할 수 있다면 손그림이든, 파워포인트든 상관없다고 말해준 선배 기획자의 조언 덕분에 집착적으로 툴을 배우는 것을 멈출 수 있었습니다.
이 시간을 통해, 프로그래밍 언어의 전문가인 개발자와 시각적 언어의 전문가인 디자이너에게 위임할 수 있는 일들은 완전히 위임하고 기획자는 기획의 언어에 집중해야 함을 깨닫게 되었습니다. 그때부터 기획 업무의 본질을 정의하기 위해 고민의 고민을 거듭했던 것 같습니다. 최종적으로 이 고민에 대한 대답, 즉 제가 정의하는 기획의 역할은 ‘현재의 상황을 올바르게 파악하고 바라는 모습을 명확히 정의해서 전달하는 것’입니다. 현재의 상황을 올바르게 판단하려면 한 분야의 스페셜리스트가 되기보다는 여러 분야의 제네럴리스트가 되어 얕은 수준으로 협업하는 사람들의 분야를 체험해 보는 것이 중요함을 이해하게 되었습니다.
만약 각 분야의 전문가에게 업무를 맡길 수 있는 상황이 아니거나 빠른 의사결정이 필요한 것이 있다면, 그 영역에 대해서는 아주 조금 더 깊게 파는 수준으로 충분합니다. 대표적으로 기획자에게 가장 유용하게 도움 되는 스킬을 꼽아 본다면, 시장 현황이나 고객 니즈 확인하는 데에 도움이 되는 엑셀이나 SQL 같은 데이터 분석 툴을 활용하여 의사결정에 도움을 받는 일입니다.
그러나 이 경우에도 SQL 전문가가 되어 모든 데이터 추출을 할 수 있는 능력을 갖겠다는 목표를 갖는 것보다는, 일을 해야 하는 이유와 이를 해결하기 위해 정확히 어떤 데이터가 필요하다고 요청할 수 있는 사람이 되는 것을 목표로 하는 것이 좋습니다. 기획자는 주로 개발자, 때에 따라서는 디자이너와 데이터 엔지니어 같은 각각의 스페셜리스트에게 목적을 달성하기 위해 필요한 요구사항을 전달하는 것이 더 핵심적인 역할이기 때문입니다.
기획자는 기획자의 입장으로, 개발자는 개발자의 입장으로 각자의 위치에서 프로덕트를 만들기 위한 저마다의 일을 한다고 생각합니다. 혹자는 기획자와 개발자가 갑을관계라고 이야기하기도 하지만, 적어도 제가 일하는 조직에서는 같은 목표를 가지고 서로 다른 역할을 하는 관계로 일하고 있습니다. 동일한 목적지를 향해 기획자는 주변을 볼 수 있는 눈과 귀가 되어, 개발자는 직접 뛰는 발이 되어 가면서 좋은 프로덕트를 만들어낼 수 있는 것이겠지요!
