들어가는 글

『관리자』로서 우리는 잘 하고 있는걸까

관리자의 과제, 원활한 협업

대부분의 게임 회사는 그저 연차가 많이 쌓이고 경력이 길다는 이유로 아무런 역량 검증 없이 ‘관리자’를 임명하곤 한다.

제대로 된 관리자의 유무는 그 팀의 명운을 가를만큼 굉장히 중요한데도 말이다.

팀원을 관리하는 관리자도 그렇게 중요한데, 프로젝트 전체를 총괄하는 PD나 PM의 역할은 얼마나 중요할 지 굳이 강조하지 않아도 알 것이다.

PD나 PM과 같은 프로젝트 총괄 직군은 프로젝트가 원활하게 진행될 수 있도록 하는 총괄 책임을 맡는다.

이런 사람들에게 가장 중요한 역량은 ‘하드 스킬’이 아니다. 자신의 ‘소프트 스킬’을 기반으로 프로젝트 구성원 전체가 원활하게 협업할 수 있는 환경을 구축할 수 있게 만드는 게 바로 이들의 제일 과제이다.

어렵지만 도전해 볼만한 과제를 향하여

우리는 입사 첫날, 뭔지도 모르고 slack이나 jira 등을 설치하거나 가입한다.

그리고 그것이 메신저나 버그 추적을 위해 필요하다는 것만 어렴풋이 알게 된 채, 그저 남들이 쓰니까 사용하게 된다.

잘 쓴 협업툴은 조직이 기대 이상의 성과를 내게 돕는다. 그러나 적절하지 않은 사용이나 쓰임새는 오히려 조직의 퍼포먼스를 저하시키고 나아가 프로젝트 전체의 기대 잠재력을 갉아먹는다.

필자는 프로젝트의 잠재력을 최대한으로 끌어올리기 위해 게임 디자이너가 할 수 있는 최선의 방책이 무엇일지 고민했고 그 해답을 ‘협업툴’에서 찾았다.

새로운 프로세스를 도입할 생각을 굳혔다고 해도, 본인이 회사 대표가 아닌 이상은 전사적으로 채택하기까지는 쉽지 않다.

회사에서는 새로운 비용이 발생한다면 그 지출이 정말로 유익한 지출인지 판단이 어려워, 새로운 지출에 보수적일 수밖에 없기 때문이다.

하지만 새로운 협업툴을 사용하는 게 스스로에게도, 나아가 팀원이나 팀 전체, 프로젝트에 도움이 된다고 판단된다면 ‘제안’ 정도는 해볼 수 있지 않을까.

우리 조직을 위해서라면, 관리자는 기꺼이 그런 제안서를 쓸 수 있는 역량을 갖추어야 한다.

이번 시간에는 그 역량을 갖추기 위해 협업툴을 선정하는 방법, 그리고 제안서를 작성하는 방법에 관해 소개한다.

---

---

협업툴이 뭐지?

협업툴의 정의

먼저 용어를 정의하는 일부터 시작해보자.

협업툴이란, 우리가 회사에서 일을 할 때 사용하는 프로그램 및 툴을 총체적으로 일컫는다.

ex) MS Word, Excel, PowerPoint, Outlook, Slack 등

우리는 회사에서 기획서를 쓰고, 장부를 계산하고, 다른 사람들 앞에서 자료를 발표하고, 메신저를 통해 커뮤니케이션하는 과정에서 어떠한 형태로든 ‘프로그램’을 사용한다.

이러한 프로그램은 ‘회사’ 또는 ‘조직’의 원활한 협업을 위해 존재하며, 이런 협업 과정에서 사용하는 모든 툴은 ‘협업툴’이라고 볼 수 있다.

SaaS

눈치 빠른 사람은 지금까지 회사에서 써온 ‘프로그램’이 협업툴과 뭐가 다르냐고 반문할 것이다.

프로그램과 앱이라는 말이 사실상 다르지 않은 시대에, 이러한 용어 하나하나의 차이를 구분지으려면 어쩔 수 없이 수십 년 전 협업 프로그램의 역사까지 거슬러올라가야 한다.

그러나 이번 글의 주제는 그러한 역사를 다루는 게 아니라 협업 그 자체의 본질에 집중하는 것이니 굳이 따분한 역사를 줄줄이 소개할 계획은 없다.

그저 협업툴이라는 개념이 2000년대 초부터 본격적으로 사용되었다는 정도로만 알고 넘어가도록 하자.

게임업계 사람들에게도 널리 알려진 메신저, ‘Slack’ 또한 SaaS의 일종이자 훌륭한 협업툴이다.

그렇다면 SaaS란 무엇일까?

Software as a Service의 약자인 SaaS는, 사용자가 소프트웨어를 로컬로 설치할 필요 없이 인터넷을 통해 소프트웨어에 접근하고 사용할 수 있게 하는 모델을 의미한다.

SaaS가 곧 협업툴이 아니라, 협업툴의 근간을 이루는 개념으로써 SaaS가 있다고 생각하면 된다.

이 SaaS라는 개념을 조금더 잘게 쪼개보면 대체로 아래의 요소를 지원한다는 사실을 알 수 있다.

• 특정 목적에 특화된 기능 지원
• 설치하지 않아도 구동 가능
• 자동 저장
• 동시 편집

SaaS라는 개념은 생소해도, 잘 생각해보면 우리 주위에 이러한 기능을 지원하는 서비스가 은근히 많다.

여기서 말하는 ‘특정 목적’을 위해 존재한다는 것은 예를 들면 사내 메신저, OKR, 근태관리, 전자결재, 백업 서비스 등 특정한 목적에 특화된 기능을 지원한다는 뜻이다.

구글에서 제공하는 구글 독스, 구글 스프레드시트 및 구글 슬라이드 등은 설치하지 않고 여러 명의 사용자가 동시 편집할 수 있는 대표적인 협업툴이다.

그래서 하나의 회사에서도 5개가 넘는 협업툴을 사용하는 경우도 충분히 있을 수 있다.

아래는 게임회사에서 흔히 사용하는 협업툴을 나열한 것이다.

• Slack
• Notion
• Confluence
• Jira
• Figma

당연히, 위에 나열한 협업툴들은 필자가 위에서 언급한 SaaS의 4가지 특징을 만족하고 있다.

협업툴의 이점

그렇다면 굳이 오피스 대신에 SaaS 기반 협업툴을 도입해야하는 까닭이 무엇일까?

협업툴을 사용하면 대표적으로 다음의 이점이 있다.

• 동시작업: 누군가가 편집하고 있는 문서를 동시에 편집하고 실시간으로 확인 가능
• 자동화: 미리 짜놓은 템플릿, 워크플로우 등을 통해 번거로운 작업 간소화
• 구조화: DB에 정의한 구조에 맞춰 정규화된 데이터가 서로 유기적으로 맞물림
• 확장성: 사용자 니즈에 맞춰 다양한 애드온(추가기능)을 활용 가능

잘 와닿지 않는다면 이렇게 생각해보자.

• 동시작업: 작업한 문서를 서로 공유할 시간을 아낀다.
• 자동화: 버튼 한번만 누르면 알아서 처리해준다.
• 구조화: (모두가) 이해하기 쉽다.
• 확장성: 내 입맛에 맞게 세팅할 수 있다.

그렇다면 오피스 프로그램, 그리고 카카오톡 등 우리가 일상에서 흔히 사용하던 프로그램으로는 위의 업무를 처리할 수 없을까?

굳이 말하자면 ‘처리할 수 있다.’

그럼에도 불구하고 협업툴을 사용하는 이유는 ‘특수목적성’과 ‘생산성(productivity)’ 때문이다.

오피스(MS word, excel, powerpoint)는 쉬운 접근성, 강력한 유연성을 자랑하지만 협업을 할 정도로 마스터하기는 어렵다.

Excel은 대부분의 경리 업무를 커버할 수는 있지만, 경리 프로그램이 제공하는 강력한 ‘자동화’ 기능을 구축하려면 오피스를 사용하는 경리의 오피스 실력이 상당히 뛰어나야 한다.

카카오톡도 마찬가지다. 서로 대화를 하는 건 문제가 없지만, 파일의 공유와 전송이 불편하고 DM 그룹화, 그리고 특정 주제에 따른 채널 설정 등이 사실상 불가능하다.

즉, 협업툴을 쓰지 않고 오피스나 카톡으로 협업툴에 준하는 환경을 구축하려면 그 툴을 협업에 맞게 커스터마이징할 수 있는 ‘특별한 천재’가 필요하다.

실제로 천재가 회사에 있다 해도 그런 천재와 함께 일하는 ‘범인’들이 그 천재가 구축한 환경을 이해할 수 있어야 한다.

만약 천재가 VBA로 생산성이 뛰어난 코드를 짰다고 해도, 그 천재가 퇴사하고 평범한 후임자가 그 프로그램을 물려받는다면 결국 머지않아 그 코드가 문제를 일으킨다.

협업툴을 쓰면 이런 복잡한 경우의 수와 불필요한 고민은 단번에 해결된다.

---

우리 조직에 맞는 협업툴 찾기

니즈 파악

자신이 어떤 협업툴 회사의 판촉 사원이 아닌 이상 ‘노션 쓰자!’ 처럼 결론부터 정해놓는 건 위험할 수 있다.

가장 먼저 해야할 건 회사에서 필요로 하는 기능을 만족하는가를 따지는 것, 즉 니즈 파악이다.

물론 노션은 협업툴 가운데 가장 ‘범용성’이 뛰어나고 유연한 툴이다.

버그 처리나 관리, 커뮤니케이션, 각 개발자 간의 테이블 공유, 참조 등등. 노션이 가능한 건 참 많다.

이처럼 다양한 면에서 노션은 ‘가능’은 하지만 특화되어있지는 않다.

버그 처리는 Jira이, 커뮤니케이션은 Slack이, 테이블 공유와 참조는 Google Spreadsheet가 노션보다 훨씬 강력하다.

회사에서 이미 위 툴을 사용하고 있다면 굳이 노션을 써야하는 이유가 사라지는 셈이다.

그렇다면 회사에서 필요한 기능은 뭐가 있을까?

아래는 게임 회사의 게임 디자이너에게 필요한 몇 가지 상황들이다.

• 컨셉 기획 및 공유
• 프로토타이핑
• 시나리오 작성
• 게임 디자인 문서 작성
• 프레젠테이션
• 스키마 구축
• Json Export
• 비주얼 스크립팅
• 플로우 차트 그리기
• 밸런스 시트 구축
• 버그 관리 및 추적
• 일감 및 일정 관리
• 빌드 노트 작성
• 파일 업로드 및 다운로드
• 형상 관리 및 버전 관리
• 등등

이중에 몇 가지는 전문적인 협업툴을 동원해야하는 경우도 있고, 엑셀이나 스프레드시트의 애드온으로 해결 가능한 것들도 존재한다.

협업툴을 도입하려면 위 목록 중에서(또는 그밖에 다양한 것들에서) 어떤 것이 우리 회사에 가장 도움이 될지 고민하는 게 필요하다.

여기까지만 보고 ‘아! 우리회사에 가장 필요한 게 뭔지 알겠네!’라고 생각하게 되었다면 다행이다. 그러면 그 기능에 특화된 협업툴을 알아보면 된다.

그리고 대부분의 협업툴 회사가 초반에는 ‘체험판 기간’을 제공하니, 프리-프로덕션 기간 동안 다양한 협업툴을 세팅해보고 비교해보면서 우리 프로젝트에 가장 적절한 툴이 뭔지 찾아가는 것도 좋다.

‘협업툴이 필요한 건 잘 알겠는데’ 정확히 뭐가 어떻게 도움이 될 지 모르겠다고?

이미 쓰고 있는게 있는데, 이걸 바꾸고 싶어도 어떻게 설득해야 할지도 모르겠다고?

그렇다면 접근법을 조금 바꿔보도록 하자.

문제 정의

필자의 경우, 회사 입사 첫날 ‘협업툴에 문제가 있다’는 점을 바로 알게 되었다.

그건 바로 회사에서 기존에 쓰고 있던 ‘트렐로’ 때문이었다.

트렐로는 소규모 인원과 미니 프로젝트를 진행하는 데는 알맞지만, 회사의 규모가 커질수록 복잡도가 기하급수적으로 늘어난다는 단점이 있다.

실제로 필자가 입사했을때만해도 약 20명이 트렐로를 사용하고 있었는데, 이미 트렐로의 칸반 보드 구조가 망가져 있는 상황이었다.

그 결과 아래와 같은 문제가 현재진행형으로 발생하고 있었다.

• 시각적으로 복잡함
• 사용성이 불편함
• 개개인의 일감 관리 불가능
• 조직의 일감 추적이 불가능
• 일감이 누락되거나 갱신되지 않음
• 구두 논의된 일감은 잊혀지거나 트래킹이 불가능함
• PM의 일감 관리가 불편

여기서 가장 많이 등장한 키워드가 무엇인지 캐치했는가? 바로 ‘일감’이다.

우리 회사의 경우 일감 관리 문제를 다루는 게 가장 큰 급선무였다.

그래서 필자가 협업툴을 고를 때 1순위로 꼽은 게 바로 ‘일감 관리’에서 우위에 있는 툴이었다.

이제 필자의 다음 행동이 정해졌다.

과연 어떤 툴이 일감 관리 측면에서 굉장히 뛰어난 툴인지 찾아보는 것이다.

협업툴 비교하기

자신이 지금 뭘 해야할지 한 줄로 정의할 수 있다면 chatgpt에게 도움을 요청하는 건 굉장히 유용한 방법이다.

필자는 ‘일감 관리’라는 키워드를 chatgpt에게 제시했고, 그 결과 chatgpt가 몇 가지 협업툴을 제시해주었다.

위 표에 있는 주요 기능들, 그리고 장점과 단점은 참고만하는 게 좋고 실제로는 제공하는 사이트에 들어가서 원하는 기능을 제공하는 지 정확하게 파악하는 게 좋다.

• Trello
• Asana
• Monday.com
• Jira
• ClickUp

소결론 & 정리

회사에서 아직 어떠한 협업툴도 쓰고 있지 않다면 ‘니즈 파악’ 단계에서 협업툴을 선택하고 사용하면 된다.

회사에서 이미 어떤 협업툴을 쓰고 있는데, 그 협업툴이 문제를 일으키고 있다면 ‘무엇이’ 문제인지 정의하는 것도 좋은 접근법이 될 수 있다.

후술하겠지만 필자가 ‘Asana’를 쓰자고 결론을 낸 이유도 Asana 일감 관리 기능이 트렐로보다 훨씬 특화되어 있었기 때문이었다.

회사에다가 섣불리 ‘~~협업툴’ 쓰자라는 주장을 펼치는 것보다, 현재 우리 회사가 겪고 있는게 뭔지, 그리고 우리가 겪고 있는 어떤 불편한 점을 개선해줄 수 있을지 함께 제시하는 게 더욱 설득력이 높은 제안서가 될 것이다.

---

제안서 쓰기

제안서를 써야 하는 까닭

기획자는 스스로가 ‘아! 그래! 이래서 우리는 협업툴을 써야 해!’라고 하고 끝나면 안 된다.

다른 사람들에게까지 그 필요성을 납득시킬 줄 알아야 한다.

그럴 때 필요한 게 바로 ‘제안서’다.

좋은 제안서를 쓰는 방법에 관해서는 서점에 좋은 책이 얼마든지 있으니 이번 글에서는 굳이 다루지 않겠다.

사람들은 ‘보이는 것’이 없으면 찬동하지 않는다.

그래서 제대로 된 기획자라면 사람들에게 ‘보여줘야’한다.

이제 우리의 과제는, 우리의 제안을 설파하기 위한 ‘그럴싸한’ 제안서를 쓰는 것이다.

여기서 말하는 ‘그럴싸한’이라는 표현을 조금 더 구체적으로 말하자면 이런 것들이 있다.

• 현황 – 지금의 협업툴과 그 문제점
• 앞으로 발생할 수 있는 문제
• 바꾼 협업툴이 지원하는 기능
• 앞으로 나아질 것으로 기대되는 것들
• 앞으로 가능해지는 것들
• 새 협업툴 도입 계획

1. 낯설게하기 – 뭐가 불편한지 모르는 사람에게 뭐가 불편한지 보여주어라

무언가를 바꾼다는 것은, 그 이유가 명확해야 한다.

사람들은 기본적으로 보수적이다. 특히 ‘변화’에는 그에 걸맞은 어떠한 이유가 있어야한다.

‘권위’는 가장 쉬운 무기다. 대표가 하자고 하면 말없이 따르면 된다.

하지만 ‘팀원’이나 ‘관리자’가 대표를 설득해 현재 환경에 변화를 가져오는 건 쉽지 않은 길이다.

새로운 도입보다 바꾸는 게 어려운 이유다.

무언가를 바꿔야한다는 것을 명확하게 설득시키려면, 기존의 것이 무엇이 ‘문제점’이었는지 짚을 수 있어야 한다.

더도 말고 덜도 말고 3개면 충분하다. 3가지의 키워드로 핵심을 찌르고, 그중 단 하나라도 상대방의 머리에 남길 수 있으면 성공이다.

용어는 쉬울수록 좋다. 안타깝게도 필자는 쉬운 용어 선정에 약한 탓에 위와 같은 사전에도 없을 법한 용어를 사용했었다.

이럴 때는 ‘아이콘’을 사용해서 시각화를 하는 게 좋다. 적당히 무언가 ‘문제가 있구나’라는 이미지만 남겨도 상대의 머리 속에 ‘아! 변화가 필요하구나!’라는 이유를 만들어줄 수 있다.

2. 전망하기 – ‘파국’을 예고하는 예언은 머리속에 강하게 각인된다

앞으로 발생할 문제를 짚어주는 것도 강력한 설득 재료가 된다.

우리 회사에서는 Wiki가 없었고, 이는 필자와 같은 내러티브 디자이너에게는 앞으로 고생길이 훤히 보이는 일이었다.

실제로 캐릭터 발주서나 기획 문서도 온갖 곳에 파편화된 채 존재하고 있었다.

이런 문제들은 당장은 눈에 보이지 않을 정도로 사소하게 느껴지더라도 점점 시간이 지날수록 그 문제를 해결하는 노력과 공수가 기하급수적으로 늘어난다.

만약 모든 Wiki를 Word로 작성했다가, Word 파일이 깨지거나 Excel로 옮겨야한다고 생각해보자. 그러면 얼마나 막막할 지는 모두가 공감할 것이다.

이런 환경에서 SaaS는 빛을 발한다.

그리고 이런 Wiki에 특화된 협업툴을 사용한다는 건 그런 고민까지도 협업툴이 함께 해결해줄 수 있음을 의미한다.

3. 변화 보여주기 – 여기에 밝은 미래가 있음을 보여라

변화가 가져올 새로운 모습을 보여주는 것을 빼놓고서는 설득이 아무런 의미가 없어진다.

PT 도중에 누군가가 ‘그거, 그래서 지금이랑 뭐가 다른지 모르겠는데요?’라고 해버리면 발표자도 청중들도 혼란에 빠지기 십상이다.

그런 난감한 일을 막기 위해서라도 앞으로 어떤 기능이 ‘새롭게’ 가능해지는지, 그리고 그것이 가져올 편리하거나 유용한 점을 소개하는 게 필요하다.

변화를 짚어줄 때는 이쁜 ‘룩앤필’을 가진 이미지를 보여주는 게 좋다.

구식 UI/UX를 가진 새로운 툴을 들고오면, 다른 누구보다 아트 직군에서 반발할 가능성이 커진다.

기획자가 아트 직군, 그리고 프로그래머 직군이 어떤 성향을 갖고 있는지 미리 파악해두는 소프트 스킬이 있다면 그런 불편한 상황이 발생할 일은 미리 예방할 수 있다.

4. 막타 – 그들의 고민을 미리 해결하라

이러니 저러니 해도 모든 일에는 ‘순서’가 있고 ‘절차’가 있다.

아무리 좋은 툴을 들고 온다고 하더라도 결론이 ‘그래서요… 해야합니다.’라고 해 버리면 그 제안서를 받아든 입장에서는 나의 숙제처럼 느껴지게 된다.

실제로 이러한 마무리가 좋지 못했던 제안서는 도중에 아무리 멋진 제안을 하더라도 그 결말부 하나가 빈약했다는 이유로 재검토 대상이나 홀딩이 되기도 한다.

쉽게 말해, ‘내가 이미 네가 할 고민을 대신 해놨어!’라는 내용이 필요하다.

이러한 새로운 변화를 불러오기 위해서는 간략하게나마 그 계획이 있으면 좋다.

그리고 그 계획이 현실성이 있어 보일수록, 디테일해보일수록 설득력은 배가된다.

비록 귀찮은 수고가 드는 일이지만, 열심히 쓴 제안서가 흐지부지 홀딩되는 결말을 맞이하는 것에 비해서는 훨씬 가성비가 좋은 일이 아닐까?

이러한 몇 가지 포인트들을 짚어주면서 제안서를 받아든 사람들(대표나 관리자), 또는 PT를 했다면 그 청자들에게 변화가 그리 힘들지 않은 것이라고 보여주는 게 좋다.

---

정리하는 글

이번 글에서는 협업툴이 무엇인지, 왜 도입해야하는지, 그리고 어떤 협업툴이 있고 어떻게 전사적으로 도입할 수 있을지 알아보았다.

게임 디자이너라면 이러한 신규 툴 도입에 관해 그다지 관심이 없는 사람이 훨씬 많을 것이다.

오히려 ‘왜 게임 디자이너가 그런 걸 신경써야 해?’라고 생각하는 사람도 충분히 있을 수 있다.

필자가 현업에서 느꼈던 건 생각보다 많은 사람이 원활한 협업을 하는 데에 있어 무엇이 좋은 방법인지 모른 채 계속 고통받고 있다는 점이었다.

개개인의 일감 관리나 일정 관리가 망가지기 시작하면, 점차 회사 전체적으로 ‘블랙박스’가 커지게 된다.

이 블랙박스가 이제 PD나 대표가 도저히 컨트롤 할 수 없을 정도로 커지게 되면 회사는 불안해진다.

게임업계에 ‘크런치 모드’가 만연한 이유이다. 그 누구도 일정이 정상적으로 가는지 모르니 이대로 가면 망할 수도 있겠다는 ‘불안감’이 우리를 지옥으로 끌고가는 것이다.

그 어떤 협업툴도 우리 모두가 올바른 방향으로 갈 수 있도록 비전을 제시해주지는 않는다.

그건 대표가, PD가, 디렉터가, 그리고 게임 디자이너가 할 일이다.

이런 깃발 흔드는 사람이 올바른 방향을 제시해주면, 협업툴은 그가 제시한 방향대로 회사 구성원 모두가 쉽고 편안하게 따라갈 수 있도록 ‘도와줄’ 뿐이다.

그리고 시간이 흐를수록 회사와 프로젝트, 조직과 구성원 개인이 모두 건강해질 수 있는 방향에 더 가까워질것이다.

그래서 필자는 이러한 협업의 가치와 미래에 관해 고민하는 게임 디자이너가, 그렇지 않았던 게임 디자이너보다 앞서나갈 수 있다고 믿는다.

지금까지 그래왔듯, 앞으로도 우리에게 필요한 역량은 ‘소프트 스킬’이 될 것이다.

그러한 소프트 스킬을 조금이라도 더 남들보다 돋보이게 되기 위해서라도 우리는 오늘, 내일, 그리고 미래에 같이 일할 사람들과 어떻게 같이 일할지(협업) 고민해야 한다.

그리고 그들은 기억할 것이다.

아. 그 사람이랑 같이 일할 땐 편했었다고. 즐거웠다고. 그리고 다시 같이 일하고 싶다고.