기획자가 갖추면 득이 되는 한 가지
엄청난 지식이나 스킬이 아니다.
기획자를 위한 글을 쓰겠다고 마음먹은 뒤, 기획자를 시작하려는 사람들이나 이미 현업에서 뛰고 있는 기획자들에게 꼭 전하고 싶었던 주제다.
기획자로서 갖췄을 때 득이 되는 딱 한 가지를 꼽는다면 무엇일까. 누군가는 남다른 감각, 뛰어난 이해력 또는 굉장한 업무 연관 스킬이나 지식을 말할 수도 있겠다. 그리고 이런 것들을 갖추고 있다면 좋은 것도 분명 맞는 말이다. 그렇다면 과연, 돌이켜봤을때 내가 기획자라는 직업을 오랜 시간 유지해온 것이 이런 스킬이나 지식들을 쌓아온 덕분일까. 또는 또 다른 이유가 있는 것일까.
기획자의 능력에 대한 오해
일반적으로 IT업계에서 '전문지식' 또는 '전문스킬' 을 갖췄다 하면 개발자, 디자이너를 먼저 떠올리게 된다. '전문성(expertise)'이라는 것이 보통 사람을 뛰어넘는 무언가를 수행할 수 있는 것을 뜻하기에 기획자보다는 다른 영역의 직무를 생각하게 된다. 그렇다면 기획자는 개발자나 디자이너처럼 전문적인 '스킬'이라는 것이 없을까? 그럴 리가. 기획자에게도 분명한 스킬들이 존재한다. 대량의 데이터를 추출한 뒤 그것을 분석하고 구조화하여 프레젠테이션을 하는 것, 이것들을 기획서라는 장문의 글로 보기에 편하고 알아듣기 좋게 정돈하여 작성하는 일, 수많은 사람들의 의견들이 오가는 곳에서 발언을 하고 조율을 하며 결과를 프로젝트에 잘 녹여내는 능력 등 유사 예능 프로그램의 MC들을 생각해보면 쉽다.
기획자는 단순히 기획서를
그리는 사람이 아니다.
많은 사람들이 오해하는 것 중 하나다. 기획자는 단순 문서 작성자가 아니다. 기획서를 그리는 일은 디자이너도 개발자도 할 수 있다. 잘 그려내고 못 그려내는 차이일 뿐, 기획서라는 문서는 따져보면 누구나 할 수 있다. 그러나 기획자가 하게 되는 '여러 사람의 생각을 조율하고 결과를 이끌어내어 구조화하는 일'은 아무나 할 수 없다. 뛰어난 디자이너와 천재적인 개발자 둘만 붙어서 프로젝트를 한다고 가정해보자. 과연 그것은 무사히 잘 끝날까? 서로 자신의 지식만을 믿고 목표하는 방향에 대한 설정 없이 판단하거나 중간중간 생각을 서로 조율하지 않는다면 둘은 아마도 시작도 전에 갈라서게 될 것이다.
여러 이해관계자들의 생각을 조율하는 일은 생각보다 많은 상황에 대한 이해가 있어야 한다. 앞서 말한 디자인과 개발에 대한 관심도 필요하고 굴러가는 시장의 상황도 잘 알아야 한다. 업종의 연관 지식도 쌓아야 하지만 문서를 기반으로 움직이는 직업이기 때문에 문서작성 스킬도 놓아서는 안되며 효율을 위해서는 지속적으로 업그레이드되는 툴에 대한 이해도 늘 갖춰두어야 한다. 기획자는 이토록 끊임없이 배우고 사람들과 소통하며 쌓아간 지식들을 적재적소에 꺼내어 활용해야만 한다. 다소 광범위하게 들리겠지만, 이 직업이 그렇다.
기획자는 왜 '직무 전환'을 꿈꿀까
그럼에도 많은 기획자들이 개발자 또는 디자이너의 전향에 대해 고민을 한다. 나 또한 개발자를 하겠다며 회사를 때려치우고 JAVA를 잠시 배우기도 했고 주변을 둘러봐도 디자이너 또는 개발자로 전향한 케이스를 제법 봐왔다. 왜 어째서, 도대체 유독 IT회사의 기획자는 다른 직업군에 관심을 갖게 되는 걸까.
여러 가지 이유가 있을 수 있겠다. 기획자로 살다 보면 디자이너에게는 뭐 하나 수정해달라는 요청에도 월권 취급을 당하고 개발자에게는 이해 안 되냐고 한없이 무시를 당하기도 한다. 반박을 하기도 어려운 게 기획자의 역할이 머릿속에 있는 무형의 생각을 밖으로 꺼내는 직업이기 때문에 그들의 전문성을 힘으로 하는 지적 앞에서는 사실 따박따박 받아칠 힘이 없는 것도 사실이다. 나보다는 그들이 더 전문성이 있다고 판단하기 때문이다.
개인차는 있겠지만 이때부터 현타가 오기 시작한다. 사실 상대가 실제로 실력이 있는지 검증하기가 어렵다. 디자이너의 경우 개취겠지만 그다지 디자인 감각이 있어 보이지도 않는 경우가 있고, 개발자의 경우 로직상 문제가 있는지 없는지 소스를 까보지 않고서야 제대로 개발됐는지 알 수 없는 노릇. 게다가 성격마저 더러운 사람을 만나게 되면 대체 내가 저 사람들보다 못난 게 뭐가 있어서 이토록 하대 받는가에 대해 고민이 시작되는 것이다.
일반적으로 기획자는 말에 논리가 있다면 상대방의 말버릇이나 워딩에 불편함이 좀 있어도 감수하는 편이다. 발언하는 주체의 말이 합당하다고 판단이 되면 생각보다 괜찮아한다. 그러나 간혹 개발자, 디자이너와 소통에 있어 당최 이 인간이 무슨 말을 하는지 알 수 없을 때가 있다. 툭하면 디자인 레퍼런스를 들이밀거나 개발용어로 말하니 알아듣기 어렵고 나를 무시한다는 생각이 든다. 이런 경험들이 지속되면 '직무 전환'을 꿈꾸기 시작하게 된다. 이 인간들과 소통하는 걸 이해 할바에 내가 그냥 디자인이나 개발을 하고 말지 라는 생각이 들게 되는 것이다.
필요한가, 그 전문적인 지식
꼭 직무전환을 희망하지 않더라도 기획자는 수많은 좌절을 경험하게 된다. 기획자 없어도 프로젝트가 알아서 잘 굴러가는 것처럼 느껴질 때가 생긴다. 왠지 모르게 기획자인 나는 뜬구름만 잡는 거 같고 본질적으로 산출물을 만들어내는 건 디자이너와 개발자라는 생각이 들 때가 있다. 이때쯤이 되면 그들과의 대화에서 지고 싶지 않아 연관 지식을 쌓기 위해 고군분투하기 시작한다. 그러나 꼭, 개발자나 디자이너에 준하는 수준의 전문적인 지식이 필요할까?후배들은 종종 아래와 같은 질문을 한다.
개발지식이 없으면
기획자가 힘이 없다던데요.
뭐, 틀린 말은 아니다. 개발지식이 있으면 당연히 없는 것 보다야 힘을 갖게 된다. 그러나 업계(IT)에 대한 기반 지식이 어느 정도 있다면 어설픈 수준의 개발지식은 기획자에게 오히려 독이 될 수 있음을 기억해야 한다. 아는척했다가 괜히 개발자의 성질만 돋울 뿐. 모르면 솔직하게 무슨 말인지 잘 모르겠다고 정중히 설명을 요청하는 게 경험상 일을 훨씬 수월하게 했던 것 같다. 그럼 개발지식은 기획자에게 전혀 필요 없을까?
만약 본인의 스토리(기획) 구성 능력이 구멍이 전혀 발생하지 않을 수준의 완벽한 예외적 상황까지 고려할 수 있다면 개발지식은 필요 없다고 본다. 그러나 이쪽 업계의 모든 기획자를 통틀어 아직까지 10년간 보지 못한 것 같다. 그렇기 때문에 많은 기획자들이 개발지식을 알려고 노력하는 것이다. 개발자와의 원활한 소통을 위해서도 있겠지만 나의 스토리가 좀 더 완벽해지기 위해서, 기획력을 높이기 위해서 개발지식을 배우는 것이라고 보는 것이 맞을 것 같다.
개발지식은 몇 가지의 기본적인 용어들에만 익숙해져도 개발자와 소통이 상대적으로 수월해진다. 그러나 이 개발지식을 습득하겠다고 처음부터 헤드퍼스트나 Do it 시리즈 등 유명하다는 책을 사서 공부할 생각은 버려라. 내가 코딩을 할 것은 아니지 않은가! 기획력을 더 높이기 위해, 소통을 원활히 하기 위해 개발지식을 습득하려고 하는 것이니 전문서보다는 현업을 활용하기를 추천한다.
개발지식을 습득하는 가장 좋은 방법
개발자들은 개발을 잘 아는 기획자보다 '대화가 통하는' 기획자를 선호한다. 일개는 '개발을 잘 알아야 대화가 통하지 않겠냐'라고 할 수 있겠지만 내 생각은 다르다. 상황의 전후 논리와 위계가 있다면 개발자들은 크게 반발하지 않는다. 만약 그럼에도 기획자에게 개발용어 남발하면서 대화를 하려는 개발자라면 우선 걸러라. 일반적으로 개발자는 기획자가 하고자 하는 목적을 명확히 하고 어떻게 구현이 되었으면 좋겠다는 흐름만 잘 알려만 줘도 어떻게든 구현해보기 위해 최선을 다해 방법을 고민해준다.
좋은 선생님을 찾는 것은 원래 어려워요.개발지식을 습득하기 위해 가장 먼저 해야 할 일은 바로 이런 개발자를 찾아내야 한다. 실력보다는 경험이 많은 친절하고 설명을 잘해주는 개발자가 필요하다.(...쉽지 않죠?) 회사에서 실력 좋다고 소문난 개발자를 찾겠다고 힘쓰지 마라. 아직 아무 지식도 없는 나에게는 뛰어난 개발 실력보다 나를 무시하지 않는 개발자가 필요하다.
현업의 개발자를 활용(?)하여 관련 지식을 습득하는 것이 경험상 가장 빠른 방법이다. 어디 가서 개발지식 공부하겠다고 돈 버리고 시간 버리지 말고 참된 개발자를 잘 찾는 것을 목표로 하는 것이 좋겠다. 앞서 말한 것처럼 개발자는 기획서의 스토리 구성이 탄탄하면 생각보다 크게 불만을 품지 않는다. 기획서 내에서 의문이 드는 부분들에 대한 대화가 서로 오가다 보면 자연스럽게 모르는 용어가 나올 때가 생길 거다. 그 용어들을 개발자에게 질문해가며 익혀가는 것이다. 이때, 좌절하지 않기 위해 앞서 말한 것처럼 '나를 무시하지 않는' 개발자가 필요한 것이다.
물어봤을 때는 어찌어찌 이해가 됐는데 일하다 보면 또 까먹기 일쑤. 때문에 개발자와의 대화에서 자주 나오던 개발 용어는 메모해두었다가 생각나지 않을 땐 검색해서 다시 습득하는 것을 반복한다. 그렇게 알아가다 보면 본인이 속한 회사의 시스템 연동 관계나 구조에 대해서 어느 순간 개발자의 말을 조금씩 이해하는 자신을 발견하게 될 것이다.
개발이라는 것이 기반이 정해져 있더라도 회사마다 사용하는 언어, 처리하는 방식, 구조가 모두 다르다. 그렇기 때문에 내가 개발자를 할 것이 아니면 학원에 가서 배운다 하더라도 우리회사 개발자와 소통에서 생각보다 크게 도움되지 않게 될 것이다. 기본적으로 통용되는 개발 용어들 - 일하다 보면 느끼겠지만 대화에서 오가는 개발용어가 거기서 거기다 - 이 있지만 가능하면 본인의 회사에서 회사에 맞는 개발지식을 먼저 습득하고 업무를 해본 뒤 좀 더 깊은 이해가 필요할 때, 그때 심화학습을 하는 것이 좋겠다.
개인 인공위성 1호 'OSSI-1'을 띄운 아티스트 송호준 작가를 개인적으로 좋아한다. 그의 이야기를 들여다보면 가장 크게 느껴지는 것이 어떻게든 해내겠다는 의지가 크게 보인다. 인공위성을 만드는 방법이나 원론, 지식보다 그가 인공위성을 쏘겠다는 마음가짐, 그 의지가 얼마나 중요한 역할을 했는지 알 수 있다. 좀 진부해 보일지 몰라도 내가 앞서 말하고 싶었던 기획자로의 삶을 질리지 않게 해 준 것은 바로 어떤 문제든, 일이든 해보겠다는 '의지'였다.
간혹 기획자 10년이면 이제 대충 깜냥으로 일할 수 있지 않냐는 선배를 만나기도 한다. 상당히 경계하는 빌런 유형 중 하나다. 내가 해보고 싶은 게 많은 성향 탓도 있겠지만 기획자는 기본적으로 다양하게 생각하고 새로운 시도를 지속해야 한다고 생각한다. 시간이 흘렀다고 해서 내가 남들보다 지식이 좀 더 쌓였다고 해서 긴장을 늦추면 기획자로의 삶이 따분해질 것이 분명하다. 특히 회사원으로 남게 되는 기획자는 아마도 이제 모든 것을 다 알고 있다는 착각의 늪에 도달하게 될지도 모른다.
기획자는 의지가 있어야 한다. 모르는 것은 어떻게든 알아내 내 것으로 만들겠다는 의지, 시간이 겹겹이 쌓아준 지식도 다시 점검하고 고쳐나가며 더 나은 기획자가 되겠다는 의지, 빠르게 변하는 시대를 받아들이며 뒤처지지 않겠다는 의지 같은 것들이 한 명의 기획자로의 삶을 더 빛나게 해 줄 것이라 믿는다. 그렇기에 앞으로 기획자의 삶을 살아갈 그대들이 훌륭하고 굉장한 기술을 익히려 노력하기보다는 '의지', 그 훌륭한 마음가짐을 갖추기를 바란다.
