ⓒUnsplash, Ewan Buck
들어가는 글
감사하게도, 이번 회사에 입사하면서 ‘내러티브 관리자’를 맡게 되었다.
필자를 포함 10명(아웃게임, 사운드 포함)에 달하는 내러티브 팀을 운영하다보니, 신경써야할 게 이만저만이 아니었다.
특히 최근에는 유관 부서와 소통하는 과정에서 몇 가지 오해가 생긴 적도 있었는데, 사실 따지고 보면 누군가의 잘잘못이라기보다는 협업 문화가 잘 정비되지 않아서 생긴 일이었다.
그 경험 덕분에, 내러티브 관리자는 단순히 스토리를 검수하는 사람이 아니라 ‘팀이 같은 비전을 공유하게 만드는 구조를 설계하는 사람’이라는 점을 다시 느끼게 되었다.
오늘 이야기하려는 ‘소통’은 말솜씨나 문장력보다, 유관 부서가 같은 이미지를 떠올리게 만드는 비전 일치화에 가깝다.
다 같이 하나의 방향을 볼 수 있도록 하나의 선명한 기준점을 제시하는 것, 그것이 내러티브 디자이너에게 필요한 소통 역량이다.
필자가 프로젝트에 합류했을 때 내러티브 팀은 세 명이었지만, 프로젝트 내에서 내러티브의 비중이 커지면서 팀은 어느새 열 명 규모가 되었다.
처음에는 거의 들을 일이 없었던 일이지만, 시간이 갈수록 ‘내러티브에서의 소통이 조금 아쉽다’는 평가를 받았다.
사람이 늘어나면서 소통과 협업을 잘 하기 위한 관리자로서의 기조와 방향성이 부재했던 탓이다.
더 이상 부정적인 피드백이 늘어나기 전에 발빠르게 대응하기 위해 움직였고, 슬랙 팀 채널에 공유와 멘션에 대한 기조를 디테일한 부분과 예시까지 추가해서 남겨놓았다.
하지만 역시 가장 중요한 기조는 바로 나와 함께 일하는 상대방에 대한 ‘이해’였다.
결국 서로가 서로를 잘 모르니 오해와 갈등이 생기기 쉬웠던 것 같다.
처음에는 필자가 직접 다른 팀 실무자들을 찾아가 이야기를 나눴지만, 점차 우리 팀 실무자들이 각자의 협업 파트너를 꾸준히 만나도록 유도했다.
그렇게 팀과 팀 사이에 라포가 쌓이자, 예상대로 많은 오해와 갈등이 자연스럽게 줄어들었다.
이 과정을 겪으며 필자는, 내러티브 관리자에게 필요한 핵심 역량은 결국 ‘협업 구조를 설계하고 유지하는 힘’이라는 점을 깨달았다.
단순 실무자일 때는 나와 직접 연결된 사람과만 소통이 잘 되어도 큰 문제가 없지만, 관리자가 되면 말 한마디와 문서 한 줄이 팀 전체의 기조처럼 받아들여진다. 그만큼 갈등과 오해도 피하기 어렵다.
다행히 여러 시행착오 끝에 상황은 어느 정도 정리되었고, 같은 고민을 할 다른 내러티브 관리자·리더들을 위해 이 경험을 글로 남기기로 했다.
아래 소개할 두 가지 케이스는 필자가 이 회사에 합류한 뒤 실제로 겪었던 상황을 기반으로, 어떻게 협업 구조와 소통 방식을 정비해 나갔는지 정리한 내용이다.
내러티브 관리자가 프로젝트의 다른 구성원과 원활하게 협업하기 위해 어떤 부분을 신경 쓰면 좋은지, 작은 참고가 되기를 바란다.
협업 구조 만들기
협업툴 Asana 도입
프로젝트에 합류한 뒤, 필자가 가장 먼저 작성한 기획서는 다름 아닌 ‘협업툴 Asana 도입 제안서’였다.
당시 회사에서는 트렐로를 쓰고 있었다.
트렐로는 대표적인 무료 칸반 협업툴로서 확장성이 뛰어난 게 장점이지만, 조금이라도 사용자의 수가 늘어나면 기하급수적으로 복잡해진다는 단점이 있었다.
이미 복잡해질대로 복잡해져버린 트렐로는 고작 20명 정도에 불과한 프로젝트 전체 일정을 제대로 담지 못하고 있었다.
내러티브 기획서를 쓰기 전에, 전사적으로 협업 방식을 개선할 필요가 있었다.
내가 집중적으로 파고들고자 했던 지점은 바로 ‘새로운 협업툴이 좋다’가 아니라, ‘지금 이대로는 나중에 문제가 생긴다’라는 위기 의식이었다.
갑자기 하루 아침에 ‘새로운 걸 써야 한다’라고 하면, 기존에 그 툴을 잘만 사용하던 사람은 반발심이 커진다. (비록 그것이 잘 쓰고 있는 상태가 아닐지라도, 대다수 사람들은 기존의 툴을 버리는 걸 굉장히 싫어한다.)
새로운 것을 쓰자는 논지보다는, 지금 이대로 가면 나중에 힘들어진다는 논리를 폈다.
트렐로는 대중적인 협업툴이지만, 한 눈에 풀스펙을 보기 힘들고, 최신화된 기획서와 파일 찾기가 어려우며, 히스토리 파악이 까다로운 툴이었다.
그래서 필자는 이러한 세 가지 문제점을 콕 집어 아래와 같은 페이지를 구성했다.
이미 프로젝트 내부에서 트렐로가 ‘복잡해서 알아보기 어렵다’는 볼멘 소리가 나온다는 걸 입사 며칠만에 알아낸 상황이었다.
그러니 위와 같은 논리가 비록 그 근거가 다소 부실할지언정 공감은 얻기 쉬울 거라 생각했다.
다행히(?) 예상은 적중했다. 이러한 문제 제기에 아무도 이의를 제기하지 않았고, 오히려 내가 준비한 대안을 모두들 궁금해했다. Asana, 먼데이닷컴, Swit, flow 등의 협업툴을 비교하다가, 최종적으로는 ‘Asana’를 채택했다.
적어도 도입하자고 주장하던 내가 예전 회사를 다닐 때 써본 경험이 있었기 때문에 다른 툴보다 적응하는 데 유리할 거라는 판단이었다.
A/B 테스트 제안과 빠른 협업툴 도입
비록 조직 내부에 트렐로 사용에 대한 회의적인 의견이 일부 있었다고는 하나, 신입사원이 입사 며칠차에 전사적으로 사용하던 협업툴을 바꾸자는 건 사실상 혁명에 가까운 일이었을 거다.
나는 분란(Chaos)을 일으킬 의도는 하나도 없었다. 오히려 기존의 혼란(Chaos)을 줄이고, 앞으로의 협업 문화를 더 좋게 만들고 싶었을 뿐이다.
그래서 이러한 협업툴 도입에 있어 어떠한 반론이 나올지 모르니, 본격적으로 도입되기 전까지 계속 긴장의 끈을 놓지 않았다.
다른 툴을 써보자는 제안이 ‘내 의견 밀어붙이기’로 보이지 않게 하기 위해, 처음에는 A/B 테스트를 제안했다.
소수 인원을 두 그룹으로 나눠 트렐로와 Asana를 각각 써 보고, 일정 기간 뒤에 장단점을 정리해 다수 의견을 취합하자는 방식이었다.
그런데 뜻밖에 대표님 선에서 흔쾌히 ‘아사나 도입’을 결정을 내려 주셨다.
덕분에 A/B 테스트까지 갈 것도 없이 빠른 시간 내에 아사나 도입이 이루어졌고, 전사적인 사용이 결정되었다.
지금도 Asana 도입으로부터 약 1년 6개월이 경과한 지금, Asana 없이는 일이 안 될 정도로 각 부서간에 굉장히 끈끈한 Task 연결고리가 만들어졌다.
예를 들어, 앞에 있는 사람이 일정이 지연되면, 뒤에 있는 사람은 앞에 있는 사람에 의해 일을 늦게 시작하게 되는 등 업무 현황이 프로젝트 전원에게 투명하게 공개된다.
이는, 뒷 사람이 억울하게 일정이 줄어들었음에도 증명하지 못한 탓에 불가피한 야근을 하거나 일정을 잘 지키지 못하는 사람이라는 억울함을 원천 예방한다.
Asana의 장점
Asana의 기획서 공유도 편리한 편이다. 구글 드라이브 링크를 통해 공유할 수도 있고, Notion이나 기타 Wiki 주소를 붙여넣으면 신속하게 임베딩된다.
이러한 Asana의 강점을 바탕으로 우리 조직은 ‘타임라인 뷰’를 통해 10명의 Task를 동시에 트래킹하고, 필요 시 휴가나 일정 조정, 유관 부서와의 협업과 기획서 전달, 프로젝트 단위 협업 등을 모두 처리했다.
이런 일을 내러티브 팀이 나서서 진행한 이유는 단순하다.
우리 팀이 만든 컨셉에서 출발한 모든 작업이, 뒷 작업자에게 전달될수록 첫 의도가 덜 왜곡되고 투명하게 Task 처리가 되게 만들고 싶었다. 대부분의 경우, 그것이 어떠한 일이든 내러티브가 ‘컨셉’을 준비하지 않으면 그 뒤의 일은 시작조차 되지 않거나 진행되기 어렵다.
그런 내러티브가 협업을 잘 하기 위해 협업툴을 잘 챙기는 건 당연한 일이다.
특히 내러티브 팀 입장에서는, 스토리 수정이나 이벤트 추가가 어느 팀의 어떤 일정에 영향을 주는지 한눈에 볼 수 있게 되면서, ‘말로 전달하다 누락되는’ 리스크가 크게 줄었다.
물론 첫 도입부터 그런 건 아니었지만, 지금의 우리 조직은 ‘말’이 아니라 ‘기록’으로 일한다. 그 중심에 Asana가 있다.
내러티브 디자이너의 일은 멋진 세계관을 쓰는 데서 끝나지 않는다.
그 세계관이 아트, 사운드, 시스템, 라이브 운영까지 이어지는 길을 단단하게 포장하는 것, 그리고 그 길 위에서 함께 뛰는 사람들이 서로를 신뢰할 수 있게 만드는 것까지가 역할이라고 믿는다.
이런 협업툴 도입 경험은 기나긴 게임 개발 과정의 가장 앞단에서, ‘협업’을 중시한다는 게 단순히 말뿐만이 아니라 프로세스 개선을 통한 협업 문화 개선임을 다시 한번 확인할 수 있었다.
그리고 협업 구조가 어느 정도 자리 잡았을 때, 비로소 ‘무엇을 어떻게 같이 만들 것인가’를 설명하는 방향성 문서를 쓰기 시작했다.
다음으로 이야기할 것은 그 부분이다.
공유와 멘션의 룰 만들기
게임 개발의 90%는 커뮤니케이션이다
게임 개발은 1인이 아닌 이상, 결국 정보를 어떻게 주고받느냐의 싸움이다.
슬랙이든 다른 메신저든, 협업툴을 쓰는 이유는 기록을 남기고 스레드로 대화를 정리해서 “누가 언제 무엇을 말했고, 그게 어떻게 결정으로 이어졌는지”를 나중에도 추적할 수 있게 하기 위해서다.
하지만 아무리 좋은 툴을 써도, ‘언제 무엇을 누구에게 공유하고 멘션할 것인가’가 정리돼 있지 않으면 금세 또 다른 혼란이 생긴다.
이 회사에 합류했을 때 필자는 그 점에서 꽤 고생했다. 이전 직장은 비교적 탑다운에 가까운 구조였기 때문에, 리더와 사전 합의만 되면 결과물을 곧장 다른 팀과 공유하는 방식에 익숙해져 있었다.
그런데 지금 조직은 훨씬 보텀업에 가깝고, 실무자와 팀 자체의 자율성이 강했다.
필자가 “충분히 공유했다고 생각한” 문서가 사전 협의 없이 나갔다며 불편함을 낳기도 했고, 반대로 일부만 공유했더니 “왜 우리에게는 말이 없었느냐”는 서운함이 돌아오기도 했다.
공유를 해도, 안 해도 문제가 되는 상황이었다.
내러티브 관리자는 커뮤니케이션도 잘 하는 사람이어야 한다
이 과정을 겪으면서 진행한 건 “내 기준을 바꾸는 것”이 아니라 “조직과 상대방의 기준”을 파악하는 일이었다.
이 조직이 의사결정을 어떻게 내리는지, 어느 단계에서 어떤 팀이 관여하길 원하는지, 각 팀의 리드와 실무자가 협업에서 기대하는 역할이 무엇인지 하나씩 물어가며 정리했다.
동시에, 내러티브 변경이 실제로 영향을 주는 범위—예를 들어 캐릭터 설정 변경 시 컨셉 아트·애니메이션·사운드까지—를 기준으로 “언제 어디까지는 반드시 공유해야 하는가”를 명시적으로 적어 내려가기 시작했다.
공유는 단순히 ‘말을 많이한다’가 아니라, 내가 전달한 기획서를 받아들고 그것을 작업해도 기획이 바뀌거나 하는 등의 영향을 받지 않으리라는 안정감을 주는 과정임을 점차 느낄 수 있었다.
멘션 룰도 마찬가지였다. 누구든 떠오르는 사람에게 ‘@’을 거는 방식은 오히려 오해를 낳기 쉬웠다.
필자는 멘션 대상을 세 층으로 나눴다.
실제 작업을 수행하는 담당자, 그 작업에 대한 품질·방향 권한을 가진 리드나 매니저, 그리고 일정과 리소스를 추적하는 PM이다.
이 세 층 중 어디까지는 ‘반드시’ 멘션해야 하는지, 언제는 팀 단위(예: @아트팀)를 태그해야 하는지 기준을 세우고, 담당자 멘션과 참고용(FYI, CC) 멘션을 구분해서 썼다.
그렇게 함으로써 “왜 나는 빼고 얘기했냐” 혹은 (아주 드물게도) “굳이 나까지 태그할 필요는 없지 않느냐”는 볼멘 소리를 점차 줄여나갈 수 있었다.
결국 공유와 멘션의 룰을 만든다는 것은, 내 말과 문서를 중심에 두는 것이 아니라, 그 정보를 받아야 할 사람의 입장에서 커뮤니케이션을 다시 설계하는 일이다.
필자는 그걸 이해하기 위해 자리에 앉아 있는 시간보다 여러 팀을 찾아가 이야기를 듣는 데 더 많은 시간을 썼다.
각 팀이 어떤 방식의 소통을 편하게 느끼는지, 무엇을 가장 답답해 하는지 메모하고 정리하면서, 내러티브 디자이너가 아니라 “비전을 전달하는 허브”라는 마음가짐으로 공유와 멘션의 기준을 다듬었다.
함께 일할 수 있는 사람이 되자
공유와 멘션은 단순히 상대방에게 시끄럽게 알림을 주는 노이즈가 아니다.
프로젝트 전체가 같은 장면을 떠올리게 만들기 위한 가장 기본적인 신호 체계이며, 그 신호를 어떻게 설계하느냐에 따라 협업 상대방으로부터의 기획 또는 기획자에 대한 신뢰도가 달라지게 되었다.
어느 의미로 내러티브 관리자가 협업에 대해 가져야 할 마음가짐이란, 내 의도를 유지한 채 최상의 퀄리티를 만들어주는 상대방에게 유연하게 맞추는 것이라는 점을 깨닫게 되었다.
그렇게 여러 조직에서 일한 경험을 바탕으로 부단히 노력한 결과 때문이었을까, 적어도 ‘함께 일할 수 있는 사람’, ‘말이 통하는 사람’이라는 평가를 들을 수 있게 되었다.
정리: 협업툴과 체크리스트
필자가 위에서 경험했던 내용을 바탕으로, 내러티브 관리자가 원활한 협업을 위해 확인해두면 좋을 내용을 ‘체크리스트’로 만들어 보았다.
체크리스트에 있는 내용이 모든 조직에 맞지는 않겠지만, 어느 정도 그 조직의 협업 문화에 관해 조금 더 생각해볼 수 있는 기반 자료로 활용되면 좋겠다.
체크리스트 10가지
□ 현재 쓰고 있는 협업툴은 관리 주체가 명확하다.
□ 현재 쓰고 있는 협업툴은 그 도입 취지가 명확하다.
□ 현재 쓰고 있는 협업툴은 조직 내 모두가 그 정보를 신뢰한다.
□ 현재 쓰고 있는 협업툴은 우리 프로젝트의 개발 현황을 한 눈에 볼 수 있다.
□ 현재 쓰고 있는 협업툴은 나와 협업하는 협업 상대방의 일정을 확인하기 편리하다.
□ 현재 쓰고 있는 협업툴은 과거에 있었던 협의나 논의, 문서 및 기록을 추적할 수 있다.
□ 현재 쓰고 있는 협업툴은 우리 프로젝트의 마일스톤과 목표, 업데이트 플랜을 볼 수 있다.
□ 현재 쓰고 있는 협업툴은 내가 협업해야 할 조직이나 개인이 누구인지 명확하게 인식시켜준다.
□ 현재 쓰고 있는 협업툴은 만약 일정이 꼬인 경우 중재해줄 수 있는 사람이 관리자 권한을 갖고 있다.
□ 현재 쓰고 있는 협업툴은 ‘일감 관리용’, ‘정보 공유용(Wiki)’, ‘버그 트래킹’, ‘사내 메신저’ 등등 목적이 명확히 구분된다.
만약 위 항목에서 7개 이상 체크표시했다면, 그 조직은 협업툴을 사용하는 데 있어 관리가 잘 되고 있는 편이라고 인식할 수 있겠다.
다음 글에서는 이렇게 정비한 협업 구조 위에서, 내러티브 관리자가 어떤 방향성 문서를 쓰고 팀의 비전을 설계해야 하는지 다뤄보겠다.
답글 남기기