2013년 어느날, 동갑내기 사장님은 ‘기획이 무엇인지’에 대해서 과외를 하라는 지령을 내렸다. 일을 시작한 지는 햇수로 꼬박 2년을 채우고 몇 달이 더 지난 시점이었다. IT 업계에 익숙하지 않으며 이런 분야는 처음 접하는 본부장님에게 한 달 동안 기획에 대해 파악할 수 있게 과외를 해주어야 했다.
내 머리 속은 복잡하게 돌아갔다. 그런 어려운 문제를 던진 사장님 탓도 아니고, 이 터무니없는 과외를 받아야하는 본부장님 탓도 아니다. 결론을 내리지 못한 채로 기획이 무엇인가, 에 대해서 설명을 해야하는 나 자신에게 있었다. 내 스스로에게도 여전히 그러한 질문에 대한 답을 주지 못했고, 이를 유예한 채로 2년을 보냈기 때문이었다.
기획자란 무엇일까
정작 누군가를 가르칠 정도로 나는 알고 있을까. 설령 알고 있다고 하더라도 그걸 남에게 가르칠 만큼인가에 대해서 의구심을 가졌다. 어쩌면 이번 한 달 간은 나 역시 ‘기획이 무엇일까’ 라는 질문에 대한 답을 찾아가는 여정이 될 수도 있겠다 싶었다.
다른 무엇보다 신기했던 경험은, 아무 것도 모르는 상태에서도 주어진 타이틀이 기획자이기 때문에 같이 일을 하던 디자이너와 개발자 모두 나에게 질문을 던졌다. 그 시점은 출근한 지 채 일주일도 되지 않던 시점이었는데도, 그랬었다. 다들 이 업계에서 잔뼈가 굵은 사람들인데도 굳이 결론을 스스로 내고 정리하려 들지 않았다.
‘너의 의도가 뭐니?’ ‘네가 생각하는 방향이 뭐니?’ ‘이게 이렇게 하면 어떻게 되는데?’ 쏟아지는 질문들 속에서 휑하니 띄워놓은 키노트 화면만 보고 나는 다시 또 망연자실 ‘다시 해올게요’ 만 연발했다.
’랜덤으로’ 나오게 해주세요. 라는 말이 얼마나 더 많은 규칙을 동반해야 하는지 알 턱이 없던 그 때의 나는 기획서에 박아놓은 무책임한 ‘네 글자’의 무게가 사흘분의 고민거리였다는 것을 늦게 알았다.
기획서를 남들에게 보내기 전에 알았어야 했고, ‘수정했습니다’라며 자꾸 휙휙 보내는 습관부터 고쳤어야 했다. 그나마 다행이었던 것은 이 때 같이 일하던 사람들은 느릿느릿한 내 속도를 기다려주었다는 사실이다.
그 때 들었던 말을 다시 기억해보면, 기획의도에 대해서 스스로 잘 생각해보라는 충고였다. 네가 왜 이렇게 만들었는지 너는 알고 있어야 해, 라는 말은 당연한 일이다. 실제로 코드를 작성해 만든 것은 개발자일 수 있어도 이 것이 어떻게 만들어져야한다는 상상은 모두 기획자가 하는 일이다.
상상을 하고 방향을 제시하고 이 쪽으로 가야해, 라고 말을 하는 것이 기획자가 하는 일이다. 손을 뻗어 방향을 모든 사람들에게 알려주는 일이 기획자의 일이기 때문에, 자신의 손짓에 함께하는 사람들이 움직인다는 생각을 항상 하고 있어야 한다.
내가 잘못 쓴 기획서때문에 어린아이는 아빠 얼굴을 보지 못하고 잘 수 있고, 예정되었던 데이트에 나가지 못해 연인과 헤어질 수도 있다. 그 모든 문제가 급작스러운 게 아니라 내 손에서 파생된 문제일 수 있다. 그런 일은 좀 싫었다. 되도록이면, 그러지 않았으면 했다.
기획자는 상상하는 사람이다
가장 현실적으로 발바닥이 땅에 쫙 달라 붙어있는 사람들 중 베스트는 개발자이다. 실제로 맨땅에 놓고 구조부터 정하고 만들어 붙여 올리는 일을 하다보니 이들은 매우 합리적이고 논리적이다.
물론 이들 역시 자신이 만드는 영역에 대해서는 상상력이 풍부하지만 ‘구현 가능한가’ 를 중심으로 상상하기 때문에 기획자가 하는 상상과는 종류가 조금 다르다. 비슷한 이유로 디자이너 역시 기획자보다는 조금 더 육지와 가깝다. 큰 모니터 전체에 포토샵을 띄운채로 정말로 눈에 보이는 화면을 만들고 세밀하게 잡다보면, 상상이 개입할 여지가 줄어들게 된다.
각자의 성향때문이라도 기획자는 다른 이들에 비해 상상을 많이 해야하는 입장이지만, 이에 더 추가하자면 아무 것도 나오기 전에 예외케이스까지 최대한 뽑아내야 하기 때문에 실제로 뭐가 어떻게 돌아가는 지에 대해서 상상을 해야만 한다.
순방향으로 쭈욱 잘 진행되었을 때는 이 다음에 어떤 게 나와야 괜찮을까, 이 경우 문제는 없을까, 그리고 이렇게 진행되면 이 다음에 무슨 일이 일어나야 할까. 보이지 않아도 생각해야 하고 보이지 않아도 상상해야 한다.
기획자는 문제의 해결책을 제시하는 사람이다
IT업계에서 생겨나는 상당히 많은 문제들의 진짜 해결사는 개발자다. 기획자는 그 해결책을 제시만 한다.
그런데 문제를 던지기만 하는 사람은 기획자가 아니다. 단순히 강성사용자이거나, 혹은 관계자이거나 그저 직원이거나 CS일 수도 있다. QA에서 제시하는 문제일 수도 있다. 각종 채널로 문제점은 들어오는데 결국 그 것을 말하는 사람들은 해결에 대해서 고민을 하는 사람들이 아니다. 고민하고 해결책을 내놓는 사람이 기획자이다.
그렇기때문에 이 순간 기획자가 내놓는 말, 제시하게 되는 안은 만족스럽지 못하더라도 해결책이 되어야만 한다. 고민을 해보고 이 방향이다 아니다 역시 가늠이 필요하다. 물론, 대부분 온전하게 괜찮은 해결책을 내놓지는 못한다. 임시방편에 그칠 수 있더라도 그 순간에서만큼은 최선일 수 있는 안을 생각하기 위해 노력해야 한다.
기획자는 ‘이것을 해야만 하는 이유’를 제시하는 사람이다
결국 기획자는 디자이너와 개발자를 납득을 시키고 이 방향성으로 가야 하는 이유를 내놓아야만 하는 사람이다. 대부분은 해당 프로젝트에 할당되어서 함께 일을 하게 된다. 솔직히 말해서 말이 안 되는 것을 가져와도 못 해주지는 않는다. 디자이너와 개발자는 기획자들이 생각하는 것보다 일을 더 잘 하기 때문에 뭐가 되든 나오기는 한다.
그렇지만 이 부분이 왜 이렇게 되어야 하는 지, 이 방향을 잡은 이유가 무엇인지 명확하게 전달하지 않으면 처음에 자신이 상상한 대로 나오지 않게 될 것이고 그 상황에 대해서 다시 한 바퀴 쭈욱, 일을 또 하게 된다.
진짜로 만드는 건 기획자가 아니다. 만들어 주시는 개발자와 디자이너가 있을 뿐이다. 그 사람들을 설득하지 못하면, 사용자와 소비자도 설득 못한다.
canada goose outletWomen s Sexy Underwear and Their Sexy Lingerie
