기획자, 기술직이 아니어도 괜찮아
기획한 것을 구현시키기 위해 ‘제대로’ 커뮤니케이션해야 한다
03. 기획자, 기술직이 아니어도 괜찮아
디자이너는 GUI를 만들고, 개발자는 소스를 코딩한다. 그런데 기획자의 역할은 그냥 커뮤니케이션하는 것뿐일까? 하루가 다르게 기술 난이도가 높아지는 프로젝트에 참여하면서, 수많은 기획자들은 스스로 자신의 역할이 작게만 느껴지는 순간을 겪는다. 새로 들어온 신입 사원이 와이어프레임은 그럴듯하게 그려내는 모습을 보고 있으면 학위라도 더 따러 가야 하는 건 아닐까, 아니면 이제라도 기술을 배워 전향해야 하는 건 아닐까 고민이 된다.
- 포스트잇이 없어도 괜찮아
- 오퍼레이터처럼 보여도 괜찮아
- 기획자, 기술직이 아니어도 괜찮아
- 신기술이 아니어도 괜찮아
- 대한민국의 기획자도 특별하다
설명하기 어려운 기획자의 업무
“그래서 기획자가 하는 일이 정확히 뭐예요?”
몇 년을 회사에서 함께한 동료에게도 이런 질문을 가끔 듣는다.
“뭔가 만들려면 기획자 통해서 하는 건 알겠는데, 디자인을 하는 것도 아니고 개발을 하는 것도 아니고. 뭘 하는 사람이에요?”
이 업무에 직접 참여하는 사람들에게 UX 기획자, 또는 PM(Product Manager), 아니면 그냥 기획자 등은 공기처럼 익숙한 단어고 직무지만, 한 발짝만 떨어져 보면 기획자는 세상에서 가장 이해하기 어려운 직업 중 하나다. 특히, 업무적으로 온라인과 관련이 없는 사람이거나 나이가 많으신 분에게는 더더욱 이해시키기가 어렵다.
“저는 이러이러한 온라인 서비스를 만들기 위해서 조사도 하고, 기획도 하고, 서비스가 사업적으로도 효과가 있도록 만들어 나가는 사람이에요.”
애써 설명해보려고 하다 보면, 머리 위 물음표가 가득한 표정들의 반문을 받는다. 아직도 나의 친척 고모는 내가 무슨 일을 하는지 모른다. ‘인터넷 쇼핑몰’에서 일한다고 대답한 엄마의 말 때문에 아직도 내가 사진 찍어서 상품 상세를 올리는 사람이라고 믿고 계신다. 물론 상품등록은 정말 중요한 직무지만, 엄밀히 말해서 그 직무는 내 직무가 아니기에 이내 설명하기를 포기하고 만다.
하지만 이런 고민은 꼭 외부인에게서만 드는 것은 아니다. 기획자 스스로도 문득, ‘내가 뭐 하는 사람일까?’ 하는 고민이 들 때가 있다. 입사한 지 며칠 안 된 신입이나 당장 입사를 꿈꾸는 대학생조차도 와이어프레임 비슷한 것을 얼추 그리는 모습을 보면 그런 생각이 든다. 과거 내 신입 시절의 한 선배는 나에게 “아무나 데리고 와서 보름만 가르치면 화면설계서는 그릴 수 있다”라는 말로 나를 불안하게 만들었다. 이런 불안은 비단 나만이 가진 부분은 아니었던 것 같다. 온라인 강의 사이트에는 전문성을 키우려는 기획자들을 유혹하는 강의가 넘쳐난다. 파이썬과 같은 개발용어나, 일러스트레이터, 아니면 새로 나온 프로토타이핑 툴이라도 배워야 한다며 핏대를 높인다. 그리고 실제로 수많은 기획자들과 기획자 지망생들이 스펙을 쌓으려고 여기에 몰린다.
이런 상황에는, 기획자의 직무 성향이 함께 손발을 맞춰서 일하는 디자이너, 개발자와는 다르다는 점이 가장 크게 영향을 준다.
정규 교육과정을 가지며, 소프트웨어라는 ‘기술’을 특기로 가진 디자이너와 개발자에 비해서, 기획자에게는 규정하기 애매한 커리어패스(Career path, 경력경로)와 경력들이 존재한다. 기획자 중에는 아예 다른 업무를 하다가 우연히 이 직무로 이동되어 온 사람도 있고, 공채로 입사했다가 발령을 받는 경우도 있다. 디자인 전공자 출신도, 개발자 출신도 있지만, 경영이나 사회학과 같은 비 IT 관련 전공자도 많다. 최근에는 UX나 HCI 전공자도 넘치지만, 실무에 배치됐을 때 업무가 과연 대학원에서 배운 것과 일치하냐고 묻는다면, 회사에 따라 다양한 상황과 대답이 나오게 된다.
기획자가 되기 위해 무엇을 준비해야 하냐는 질문에, 가장 애매하게 대답할 수밖에 없는 것도 바로 기획자다.
반면에 개발자는 분야도 공부도 그리고 언어도 굉장히 명확해 보인다. 인프라, 프론트엔드, 백엔드, 형상관리, DB 관리, 앱 개발 등등, 자신의 아이덴티티를 명확히 밝힐 수 있고, 정해진 분야를 준비하는 것도 가능하다. 디자이너도 마찬가지다. 패키지 디자인인지 BI(Branding Identity) 디자인인지, 아니면 웹 UI 디자인인지 그 구분을 명확하게 하고 포트폴리오를 만드는 것이 가능하다.
그렇다면 기획자의 이 불안감은 어쩔 수 없는 것일까? 이번 회차에서는 기획자의 기술에 대한 불안감과 현실, 그리고 기획자의 전문성에 대한 이야기를 해보려고 한다.
이슈 상황에서 등장하는 기술직 협업의 어려움
주니어 기획자가 프로젝트를 진행하면서 가장 괴로울 때는 언제일까? 책임이 막중한 시니어 기획자와는 다르게, 기획을 하는 순간이 아니다.
주니어 기획자에게 기획은 너무너무 신나고 즐거운 순간이다. 오히려 정말 괴로운 순간은 개발자, 디자이너와 상의를 하는 순간에 찾아온다. 그리고 이 고통은 주로 원하는 기획이 어떠한 이유로 개발이 어렵다거나, 혹은 디자인 산출물에 대한 이견이 발생할 때 나타난다. 용어를 알아들어야 서로 논의를 할 텐데, 폭탄 같은 단어들에 정신이 멍해지고 대응은 하지 못한다.
“개발자의 말을 하나도 못 알아듣겠어요.”
“디자이너와 UI에 대한 생각 차이가 너무 심한데 설득을 못 하겠어요.”
이런 상황에서 주니어 기획자들은 모든 이유를 자신에게 돌린다. 개발을 모르기 때문에, 그리고 디자인을 모르기 때문에 이런 문제가 생겼다고 생각한다. 그래서 코딩 학원을 찾고 디자인을 배우기 위해서 UI 관련 책을 열심히 찾아본다.
지금까지 살아오면서 학원이나 과외 등 외적인 노력으로 해결하는 것에 익숙한 우리 세대의 사람들에게는 이런 생각이 드는 것이 굉장히 자연스럽다. 하지만 진짜 슬픈 것은 그런 노력을 해도 사실상 업무에 갑작스럽게 큰 도움이 되지는 않는다는 점이다.
코딩학원이나 코딩에 관련된 서적들은 단 하나의 언어를 선택하여 함수를 하나하나 연습문제를 통해 풀어보는 방식으로 코딩을 가르친다. 물론, 아예 배우기 전보다 분명 알게 되는 것들이 많겠지만, 이미 복잡도가 올라가서 운영 중인 프로덕트를 기획하는 사람이라면 이런 방식으로 몇 달 배운다고 해도 당장 쓸 수 있는 것은 많지 않다. 더 슬픈 것은 주니어 기획자라면 아예 새로 만드는 단순한 프로덕트보다 높은 복잡도로 운영 중인 프로덕트에서 일할 확률이 높다는 점이다. 초급단계의 개발 지식으로는, 회사가 당장 코딩을 기획자에게 맡기지도 않을 뿐 아니라, 큰 기업의 경우 기획자의 직무 선에서 개발 소스 코드 자체에 접근조차 불가능한 경우가 많다. 업무에 써먹기 위해서는 개발자와 소스코드를 상의할 수준이 되어야 하는데, 만일 개발 담당 PL(Part Leader)이 있다면 이조차 월권처럼 보일 수도 있다.
애초에 문제였던 개발 용어만 생각해보자. 쉽게 생각하면 기획자를 위한 용어집 하나 나오면 베스트셀러로 올라갈 것 같다. 하지만 불행히도 그런 책은 애초에 만들 수조차 없기에 나올 수도 없다. 왜냐하면 우리가 현장에서 만나게 되는 개발 용어는 일하는 조직의 환경과 시스템에 따라 완전히 다르게 활용될 수도 있기 때문이다. 개발자는 (함수에 대해 얘기하는 것처럼 보일 때조차도)함수를 이야기하지 않는다. 개발자가 기획자와의 대화에서 시스템에 관련된 이 용어(함수)를 사용하는 것은 오로지 산출물이 가지고 있는 이슈에 대해서 공유하고 기획자와 함께 해결하기 위해서다.
그렇다면 디자이너와의 커뮤니케이션에서는 어떨까? 만약 기획자가 몇 달 학원을 열심히 다녀서 일러스트레이터와 포토샵을 익히고 덤으로 스케치(Sketch)까지 약간 배웠다고 가정해보자. 하지만 그렇다고 해도 디자이너와 대화할 때 도움이 될까? 디자이너 역시 개발자와 마찬가지다. 디자이너는 포토샵 학원에서 배운 단축키를 이야기하며 회의하지 않는다. 디자이너는 디자인 산출물에 대해서 이야기하고 있다. 이 디자인 산출물이 우리가 생각하는 고객의 UX에 적합한지, 그리고 우리가 만들려고 하는 최종적인 프로덕트와 어울리고 기존 프로덕트가 가진 가치와도 어긋나지 않는지 기획자와 상의하려는 것뿐이다.
개발 및 디자인 용어 앞에서 느끼는 당황은 외국인과 대화할 때와 비슷하다. 우리가 평생 한 번도 들어보지 않은 네덜란드어나 핀란드어로 된 문장을 듣는다면 우리는 당황하며 대답을 잘 못 하겠지만, 어쩌면 그 내용은 “안녕하세요”나 “화장실 어디에요?”와 같은 쉬운 문장이라서 손짓과 발짓으로 대답할 수 있는 말일 수도 있다. 설령 끝까지 못 알아들었다고 해도 같은 행동과 의미가 반복되면 무슨 뜻인지 알게 된다.
커뮤니케이션을 위한 모든 용어가 마찬가지다. 우리의 목표를 ‘모든 단어의 이해’가 아니라 ‘커뮤니케이션’에 둔다면, 개발 및 디자인 용어는, 외국에서 살면서 외국어를 배워가듯 익혀나갈 수 있다. 개발 및 디자인 용어로 대화를 자꾸 하고, 모르는 것은 물어보면서 익히면 된다.
사실 이런 문제는 꼭 IT 세계에서만 일어나는 것은 아니다. 광고계나 패션계, 법조계, 의료계는 각자 전문 분야에 알맞은 어휘들이 있다. 그 어휘 중에는 평소에 충분히 대체할 만한 쉬운 언어가 있는데도 의도적으로 사용되는 어휘도 있고, 책 어디에도 소개되지 않아서 일 하면서만 익힐 수 있는 어휘도 있다. IT 계열 역시, 일 속에서 살아가면서 그런 것들을 배워나가게 되어있다. 그런데 유독 IT에서 일하는 기획자들은 이런 것에 대해서 자신이 부족하다는 생각을 갖고 재빨리 채우려고 한다. 하지만 기획자는 어디까지나 ‘기획한 것을 구현시키기 위해 노력하는 사람’이다. 정말 중요한 것은 구현을 위해 협업 대상자들과 ‘제대로’ 커뮤니케이션하는 것이다.
커뮤니케이션을 통해서 시스템을 배우는 방법
좀 더 구체적으로, 기획자가 협업자들과 커뮤니케이션하는 방법에 대해서 예시를 들어 설명해보겠다.
기획자가 커뮤니케이션을 하는 근본적인 목적은 ‘문제해결’에 있다. ‘문제해결을 하는 과정’에서 대화와 질문의 방식을 바꾸면 개발 용어를 익힐 수 있다. 예컨대, 아래와 같은 대화가 있다고 해보자.
기획자: 최근 본 상품을 중심으로 PC와 모바일에서 같은 상품을 추천받게 해주세요.
개발자: 그건 불가능해요. 최근 본 상품은 DB에 저장하지 않고 쿠키에 쌓거든요.
기획자: ?????
여기서 DB가 뭔지 쿠키가 뭔지 모를 수도 있다. 거기서 당황하며 나만 몰라서 부끄럽다고 생각할 필요는 없다. 회사마다 동일한 부분도 마치 사투리처럼 쓰임과 용어가 다를 수 있다. 그때그때 물어보면 된다. 다만, 용어에 대해 질문할 때는 어휘가 아니라 ‘활용’을 물어봐야 한다. 그래야 다음에도 활용가치가 있는 정보를 배울 수 있기 때문이다.
기획자: DB와 쿠키에 저장되는 게 어떤 차이가 있는 건가요?
개발자: DB에 저장하면 어떤 디바이스에서나 같은 기록을 볼 수 있는데, 쿠키는 디바이스별로 달라요.
기획자: 그러면 최근 본 상품은 현재 사용 중인 디바이스에 따라 달라진다는 거네요?
개발자: 네, 맞아요. 그래서 지금 구조로는 기획대로 할 수 없어요.
DB가 무엇인지 쿠키가 무엇인지를 하나씩 물어봤다면, 대답을 들었어도 이해를 못 했을 수 있다. 단지 원하는 기획 요건에 관계된 기능만을 묻고 이해한다면, 대화는 쉽게 풀린다. ‘네 직업이 무엇이니’라는 뜻의 영 문장을 단어 단위로 해석하면 이해하지 못하지만, 숙어로 외워 두면 이해할 수 있는 것과 마찬가지다. 예의 대화는 ‘What do you do?’라는 문장의 두 번째 ‘do’가 ‘for living’을 함축하고 있는지를 물어 이해하려 한 것이다.
그다음 단계는 문제해결이다. 이제 용어는 정확히 몰라도 상황에 대해 이해했으니 문제해결을 위한 질문을 할 차례다.
기획자: 그럼 저희가 DB라고 하는 거기다가 최근 본 상품을 저장할 수는 없나요?
개발자: 그러면 DB를 새로 만들고 상품 상세 들어갈 때마다 이거 다 저장해야 해요. 원래 예상보다 일정이 많이 소요될 텐데요. 좀 더 검토해볼게요.
기획자: 검토해보시고 말씀해주세요.
이제 기획자와 개발자의 대화를 통해 한 가지 해결책에 대한 ‘안’이 나왔다. 현재 상황을 고려하지 않고 무조건 개발해 달라고 한 것도 아니고, 그렇다고 무조건 안 된다고 한 것도 아니다. 그리고 기획자는 쿠키와 DB의 이야기를 계속 들으면서 용어와 활용을 머릿속에서 정리해나갈 수 있었다.
외국어 교육 이론 중에 동일한 어휘를 일곱 번 반복해 들으면 뇌에 각인된다는 이론이 있다. 개발 용어도 마찬가지다. 이런 식으로 일곱 번 이상 다시 반복해서 듣다 보면, 우리 회사 시스템에서 사용되는 그 어휘의 활용을 익혀 나갈 수 있다. 그리고 한 발 더 나가서 우리 회사만을 위한 용어사전을 만들어 둔다면 기획자의 적응에 더 유용하게 활용할 수 있다.
이번에는 디자이너와의 커뮤니케이션을 생각해보자. 개발자와 기획자 간 이슈가 대부분 개발이 어렵다는 데서나 일정이 늘어진다는 데서 생긴다면, 디자이너와의 커뮤니케이션에서 이슈는 대체로 생각 차이에서 나타난다. 기획자가 처음 정리한 와이어프레임에 대해서 디자인적으로 동의하기 어렵거나 서로 생각하는 고객의 이용 동선 등이 일치하지 않는 경우, 혹은 중요 포인트에 대해서 다른 생각을 가지고 있는 경우도 있다. 그리고 기획자가 생각하지 못하는 경우인데, 디자인 관리 요소가 많아져서 실제 프로덕트를 오픈 후에 디자인 리소스가 많이 들어가는 경우나 전체 프로덕트와의 일관성이 어긋나는 경우도 있다.
Udemy의 Product Manager에 관련된 여러 클래스에서 공통으로 강조하는 내용이 있는데, 바로 “You’re not a Boss”다. PM 또는 기획자들은 프로덕트에 대해 가장 처음 생각을 정리하기 때문에 그들이 마치 주인처럼 프로젝트를 이끌어 가야 하는 것은 맞다. 하지만 이러한 끌고 감은 Manager(관리자, 조정자)가 되어야지 Boss(상위자, 상사)가 되어서는 안 된다. 특히 디자인에 대해서 유난히 조심스러워야 한다고 생각한다. 디자인 영역은 눈으로 보이는 영역이기 때문에 커뮤니케이션에서 있어서 특수성이 있다. 쉽게 말하면, 눈이 있고 입이 있으면 한마디씩 자기주장을 하기 쉬운 곳이라는 것이다. 디자이너와 같은 전문성이 없음에도 이야기할 수 있기에 기획자가 디자인에 대해서 이야기할 때는 명확한 기준 마련이 필요하다.
만약 기획자와 디자이너 사이에 산출물에 대해서 이견이 있다면 기획자가 컬러나 간격, 레이아웃 등에 대해서 지적하듯 말하는 것보다는 고객의 UX와 주요 동선, 강조해야 할 다음 단계 등에 대해서 이야기해야 한다. 만약 기획자가 와이어프레임 오른쪽에 그려놨던 각진 버튼을 둥근 버튼으로 바꿔놓았다고 해도 이 변화가 기획자가 생각하는 전체적인 흐름과 프로덕트에 영향이 없는 부분이라면 디자이너의 전문성에 대해서 인정해야 한다. 서로 논의를 통해서 R&R에 대해 범위가 제대로 정리되고 나면, 디자이너와의 신뢰로 인해 더 좋은 산출물이 나오는 경험을 할 수 있다.
기획자의 전문성
협업자와의 커뮤니케이션에 대해서 고민해본 결과 어느 정도 조정을 할 수 있었다면, 이제 시선을 있는 그대로의 기획자에게 돌려야 한다. 협업을 떠나서 기획자 자체로 어떻게 전문성을 가지고 성장해야 할까?
프로덕트 매니저, 혹은 기획자들은 프로덕트의 생애주기를 관리하는 직무를 담당한다. 즉, 처음 프로덕트의 탄생부터 성장, 운영, 쇠퇴를 모두 겪어야 한다는 것이다.
여기서 프로덕트란 하나의 웹사이트 급으로 큰 것만 포함되는 것이 아니다. 자신이 맡은 작은 서비스나 혹은 ‘푸터(footer)’처럼 평소 거의 변경 없이 작은 부분이라고 해도, 기획자가 책임지고 있는 단위라면 모두 프로덕트가 될 수 있다.
이 프로덕트를 만들기 위해서는 UX적 관점에서 고객의 니즈를 맞출 수 있어야 하고, 그것이 비즈니스적으로 가치가 있어야 하며, 기술적으로 구현이 가능한 선에서 기획할 수 있는 능력이 있어야 한다.
그렇다면 ‘UX’, ‘비즈니스’, ‘테크놀로지’ 이 세 가지 관점에서 디자이너나 개발자와는 다른, 우리만의 무기를 만들 수 있는 부분은 무엇이 있을까? 그렇다. ‘비즈니스’다. 기획자에게 비즈니스적인 사고야말로 전문성의 영역이 되어야 한다.
비즈니스에 대해서 좀 더 자세하게 들여다볼 필요가 있다. 비즈니스라는 말에서는 ‘수익구조’에 대한 것만 떠올리기 쉽지만, 사실 비즈니스 구조에는 수익구조 외에도 서비스가 주는 가치와 전체적인 핵심 프로세스, 그리고 비용과 운영의 프로세스에 대한 내용이 포함되어 있다. 또한, 이러한 핵심 프로세스를 중심으로 서비스가 활성화되고 또 성장하는 프로덕트의 생애주기를 위한 선순환에 대한 것도 포함된다. 즉, 비즈니스란 서비스가 의미 있어지기 위한 모든 것을 의미한다.
여기서 오해하지 말아야 하는 부분이 있다. UX 방법론과 UCD(User Centered Design)의 차이점이다. UX 방법론이라고 불리는 것에는 고객의 UX를 평가하는 다양한 사용성 테스트에 대한 이야기들이 등장한다. 하지만 고객의 태스크(TASK)나 이슈를 해결하기 위한 범위가 UI에 한정된 것이 아니라 서비스를 이루는 핵심적인 구성요소들에 연결이 된다면, 이것은 UCD의 영역이라고 하는 것이 맞다. UCD 또는 서비스 디자인의 영역은 엄밀히 말해서 UX라기보다는 비즈니스를 구성하는 방법에 해당하는 것이다. 예를 들어, 고객이 원하는 것이 무조건적인 최저가라고 해도 타사의 최저가를 자사에 링크 걸어서는 안 된다. 반대로 우리 웹사이트의 비즈니스가 만약 가격비교 사이트라면, 최대한 많은 비교 대상을 통해서 최저가를 보이도록 해야 할 것이다. 비슷해 보이지만 웹사이트가 가진 비즈니스적인 부분은 결국 동일한 고객의 니즈에 대한 다른 해석을 가져온다. 바로 이런 부분이 기획자가 전문성을 키워야 하는 부분이라고 생각한다.
그렇다면 비즈니스를 프로덕트에 어떻게 적용하는 것이 전문적인 것일까?
첫째, 가장 먼저 할 수 있는 것은 운영조직의 프로세스와 목표를 이해하는 것이다. 비즈니스를 이루는 핵심적인 프로세스는 결국 운영 조직이 담당하는 경우가 많다. 동일한 하나의 서비스를 다 함께 운영한다고 해도 운영조직은 각각의 목표를 가지고 움직인다. 이들의 목표와 KPI를 이해하고 서비스를 구성할 때 각 운영팀의 목표에 맞게 프로세스를 구성하는 것은 비즈니스를 서비스로 구현시키는 것에 가장 중요한 부분이 된다.
둘째, 기획자가 이해하고 있는 현업 팀 간의 견해 차이와 수익적 목표를 디자인과 개발에 지속해서 알려줄 수 있어야 한다. 디자이너와 개발자는 프로덕트의 구성 시작보다는 항상 구현이라는 단계에서 기획을 만난다. 지금까지의 논의 과정과 필요성, 우리 서비스의 중요성 등에 대해서 정확하게 전달해줘야 더 좋은 형태로 아이디어를 내고 참여할 수 있기 때문에 프로젝트 동기부여의 차원에서 이 과정은 굉장히 중요한 부분이다.
셋째, 비즈니스에 대한 이해를 바탕으로 설득력 있는 프로덕트 평가 지표를 세울 수 있어야 하고, 평가할 수 있어야 한다. 앞서 말했듯이 개발에는 언제나 한계가 있을 수 있고, 디자인에는 여러 사람들의 날 것에 가까운 주관적인 평가가 날아들기 마련이다. 기획자가 명확한 KPI를 상정하고 최종 산출물이 정상적으로 구현되었는지 평가할 수 있어야 이런 외부의 다양한 의견에 대하여 프로덕트의 가치를 설득할 수 있다. 또한, 반대로 프로덕트 개선의 결과가 비즈니스의 흐름과 반대로 흐를 경우에 빠르게 이에 대해 대처할 수도 있다.
마무리
기획자의 업무는 언뜻 보기에는 특별한 기술이 없어 보인다. 그리고 현장 속에서 느끼는 기술직과의 소통의 어려움은 기획자의 자존감마저 흐려 놓기도 한다. 하지만 기획자의 전문성은 사내의 경험을 통해 축적되고, 비즈니스와 UX를 포함한 프로덕트에 대한 고민의 깊이는 디자인과 코딩이라는 기술 사이사이에 녹아 들어가야 하는 중요한 부분이다.
물론 기획자가 디자인이나 개발을 배우는 것은 온라인 프로덕트를 제대로 만들기 위한 이해를 돕는다는 점에서 중요한 부분이 될 수 있다. 그러나 기획자가 아예 전문성을 키울 수 없다는 생각으로 어정쩡하게 고민만 하는 것은 기획자로서 전문성을 키우는 것에 도움이 되지 않는다.
어쩌면 기술에 대한 기획자의 동경은 측정되지 않는 기획자의 전문성에 대한 반발심리일 수 있다. 겪어보지 않은 디자이너와 개발자의 일에 대해서 부러워하는 시선보다는, 기획자만이 가질 수 있는 무기로 이들과 협업을 잘 할 수 있는 방법을 배워 나가는 기획자가 되어 보는 것은 어떨까.
