서브컬처 게이머

들어가는 글: 팀 합류 직후

프로젝트, 조직 상황

2024년, 나는 한 지인의 소개를 받고 A사에 입사하게 되었다.

이 회사는 남성향 서브컬처 캐릭터 수집형 모바일 RPG를 만드는 회사 중 하나였다. 202X년 서비스를 목표로 신규 IP를 개발하기 위한 프로젝트였고, 내가 합류할 당시에는 개발 초기 단계였다.

장르적으로 부담스러운 키워드가 있었던 것도 사실이지만, 그래도 ‘국내에서 서비스할 수 있는 수준’이라고 생각하면 크게 무리 없겠다는 판단을 해 팀에 합류하게 되었다.

내가 합류할 때 전사 규모는 약 20명 언저리였다. 전임자(리드 라이터)는 이미 퇴사했고, 뚜렷한 인수인계서도 없는 상황이었다.

내러티브 팀은 주니어 실무자 1명과 나, 그리고 원화 팀장님이 내러티브 팀장을 겸임해서 총 세 명이었다.

목표했던 게임 출시 마감일까지는 약 1년 6개월 가량이 남아 있었다.

• 개발 규모: 소규모 (20여 명)
• 게임 장르: 남성향 서브컬처 수집형 RPG
• 잔여 기간: 1년 6개월

문제 인식

입사하고 난 뒤 일주일 회사를 다니며 인지했던 문제는 다음과 같다.

• 내러티브 없이 게임이 개발되고 있다.
• 일정-일감 관리 체계가 부실해 사실상 방치되고 있다.
• 게임의 타깃 시장과 고객이 모호하다.

입사 첫 날, 전임자가 썼던 내러티브 문서를 읽어보았다. 약 50페이지 분량의 문서였는데, 내가 생각한 방향(세컨 게임, 가벼운 전투)과 전임자가 설계한 내러티브 톤이 많이 달랐다.

그래서 방향성 차이가 컸고, 결과적으로는 새로 설계하는 쪽을 택했다.

가장 신경써야 겠다고 생각했던 부분은 내러티브 그 자체보다도 전사적인 ‘일정-일감 관리 체계’ 였다.

약 20명 규모의 사람들이 트렐로를 쓰다보니, 칸반 보드는 급격하게 복잡해지고 레거시 데이터에 의해 오염되고 있었다.

오죽하면 이미 어떤 팀은 트렐로를 쓰지 않고 그 팀 내에서 쓰는 자체적인 일정 관리 체계가 있다고 했다. 장기적으로 봤을 땐 ‘사일로 현상’이 일어날 게 뻔히 보였다.

타깃 시장과 고객이 모호하다는 점도 눈에 밟혔다. 물론 ‘서브 게임’, ‘세컨 게임’, ‘R18’ 같은 표제어는 있었다.

다만 그러한 키워드만으로는 시장에서 어떤 게임과 경쟁할 것인지, 다른 게임의 어떤 성향(페르소나)을 가진 플레이어를 모객할 것인지 불투명했다.

해결책과 그 결과

내가 처음 세웠던 전략은 아래와 같다.

• 문제점: 내러티브 없이 게임이 개발되고 있다.
  • 해결방안: 내러티브를 사실상 0부터 다시 개발하고, 현재 있는 작업물에 대한 후기획을 한다.
• 일정-일감 관리 체계가 부실해 사실상 방치되고 있다.
  • 해결방안: 현재의 협업툴 대신, 전사적으로 모두가 사용할 더 나은 협업툴을 도입한다.
• 게임의 타깃 시장과 고객이 모호하다.
  • 해결방안: (최소한 내러티브라도) 비전 문서를 준비해, 게임의 방향성을 일치화한다.

내러티브는 처음부터 다시 다 쓰기로 했다.

기존 작업물은 충분히 디테일 업이 되지 않아, 전임자의 작업물을 고스란히 계승해서 게임에 적용하기에는 무리가 있었다.

또한 게임의 방향성은 세컨 게임의 가벼운 전투를 하는 게임인데, 로스트 아크에 준하는 묵직한 내러티브의 무드가 어울리지 않았다.

그리고 내부적으로 내러티브에 대한 불만이 컸기 때문에, 내가 내러티브를 새롭게 정의한다고 해도 반대가 거의 없을 거라는 판단이 있었다.

협업툴은 국내외 협업툴을 다양하게 비교했고, 그 중 하나가 가장 돋보이는 게 있어서 선정했다. (필자가 과거 다른 회사에서 사용해본 적도 있었다.)

전반적인 툴 설명과 도입 취지를 적었고, A/B 테스트를 거쳐 점진적으로 회사에 도입하자고 제안했다.

다행히 회사에서는 예상보다 빠른 시기 내에 기존 트렐로를 버리고 새 협업툴로 일감-일정을 이전하는 쪽으로 결정을 내렸다.

그러나 새 툴을 도입해서 모두가 툴 사용에 익숙하지 않았기에, 내가 더 많은 시간을 할애해서 매뉴얼을 쓰거나 툴 사용방법을 전사 발표하는 등 내가 더 열심히 발로 뛸 수밖에 없었다.

게임 타깃 시장과 고객은 고민이 많이 됐다. PD가 해야 할 일을 내러티브가 괜히 관여하는 게 아닐까 싶었다.

하지만 깨지더라도 부딪혀보자는 생각에, 일단 내가 생각하는 세컨 게임과 현재 시장 기준으로 어떤 게임과 경쟁을 할 지, 그리고 예상 타깃 고객의 페르소나와 플레이 할 시간과 공간대 등을 정리해서 ‘내러티브 비전’ 문서를 썼다.

감사하게도, 전사 발표를 할 때 회사 최고령중 한 분이신 프로그래머분께서 내러티브가 이해가 된다고 해주셔서 굉장히 기뻤다.

이러한 노력이 결실을 맺은 것일까. 나는 아직 3개월 수습기간이 끝나기도 전에 회사에서 파트장으로 발령이 났다. B사에서 한번 ‘파트장 제의를 거절’했다가 너무 크게 데였던 탓에, 이번에는 흔쾌히 수락했다.

그리고 대표님과 유관부서에서 내러티브의 새 출발을 응원해주시고 지지해주시는 상황이었기에, 나는 더 적극적으로 ‘내러티브의 확장 정책’에 힘을 쏟기로 했다.

내러티브 팀 운영 전략

규모 확장

• 목표: 프로젝트의 시그니처를 ‘아트’ 원탑보다는 ‘아트&내러티브’ 투탑으로 간다.
• 전략: 인력을 충원해 일단 ‘양’을 늘리고, 개개인의 퍼포먼스가 숙달되면 폴리싱을 통해 ‘질’을 개선한다.

A사의 아트는 이미 그 퀄리티나 팬층이 어느 정도 보장된 상황이었다. 그래서 회사에서도 아트에 거는 기대가 컸고, 이는 나도 마찬가지였다.

하지만 아트 하나만 믿고 게임을 출시하는 건 사실상 게임 개발을 방조하는 일이라고 생각했다.

내가 이전에 있던던 ‘블루 아카이브 개발팀’ 또한 아트와 내러티브의 협업이 낸 시너지가 게임을 성공시키지 않았던가.

그래서 나는 아트가 원탑으로 나서고, 내러티브가 그 앞이나 옆에서 페이스메이커 역할을 해줄 수 있는 팀을 만들고자 했다.

그렇게 실무자의 수는 꾸준히 불어나, 내가 입사한 날로부터 1년이 지났을 땐 팀원이 10명에 근접했다.

이는 회사 차원에서도 내러티브에 대해 힘을 실어주었기에 가능했다고 생각한다.

나 또한 회사가 그렇게 믿음과 신뢰를 준 만큼, 더 많은 내러티브 결과물을 내고, 유관부서와 꾸준히 협업하기 위해 노력하고자 했다.

자율성 부여

• 목표: 리더나 특정 시니어에게 병목이나 부하가 최소화되도록, 각 실무자가 자신이 ‘알아서 처리’ 할 수 있는 시스템을 구축한다.
• 전략: 팀 내 기조나 문서를 명문화하고, 모호성을 최소화하여 실무자 입장에서는 딱 일만 집중할 수 있는 구조를 만든다.

나는 A사가 내가 리더를 맡은 첫 회사였다.

그러나 살면서 리더 역할을 맡았던 적이 전무했던 건 아니었다. 그래서 어느 정도 팀 운영이라든지 팀원 관리 등은 자신이 있었다.

중요하게 생각했던 원칙 중 하나는 바로 ‘자율성’이다.

팀원 하나하나를 내가 다 마이크로컨트롤하기보다는, 그들이 가장 좋아하고 잘 할 수 있는 쪽으로 역할을 부여해, 궁극적으로는 그들이 맡은 바 일을 가장 효과적으로 처리할 수 있게 하는 ‘체계’를 만드는 게 목표였다.

그래야 관리자로서 나도 부하가 줄어들고, 팀원들도 더 신바람이 나서 일할 수 있을 거라고 생각했다.

하지만 원칙도 필요했다.

‘자율’은 ‘자유’가 아니라는 말이 있듯, 관리자가 전혀 모르는 채로 일이 진행되거나 다른 작업물과 통일성이 떨어지는 작업물이 나오는 등의 일이 있으면 그 부분은 간과하지 않았다.

다행히 팀원들의 훌륭한 팔로워십 덕분에 팀원 덕분에 매 마일스톤마다 약 80~90% 대의 목표를 달성하며 지속적으로 안정적인 업무 성취도를 낼 수 있었다.

(※목표는 언제나 120% 정도의 부하로 잡았으며, 약 80~90% 정도의 성취도는 사실상 100%를 약간 초과하는 목표 달성률이라는 점을 부연해서 달아 둔다.)

애자일 문화

• 목표: 팀 내 이슈나 현황 등을 빠르게 공유하고, 그레이 존을 최소화하여 중장기적인 개발 리스크를 최소화한다.
• 전략: 매일 스탠드업 미팅을 하고, 매주 내러티브 팀 회의, 매달 포스트모템을 개최하고 이 모든 것을 내가 지정한 ‘애자일 마스터’가 수행할 수 있게 지원한다.

애자일 문화를 도입해야겠다고 생각한 결정적 계기는, 바로 위에서도 언급한 ‘자율성’ 때문이었다.

팀원 각자에게 자율성을 부여한 대신, 그들이 어떤 식으로 업무를 처리하였고 그 상황에서 어떤 난관에 맞닥뜨렸는지 관리자로서 알 필요가 있었다.

매일 진행하는 스탠드업 미팅과 매주 진행하는 주간회의는 그러한 팀원들의 애로사항이나 고충을 생생하게 들을 수 있는 자리로써 의미가 있었다.

애자일이라고 하면 소위 말하는 ‘애자일 원칙’이라든지, 말만 애자일을 주창하고 시스템적으로는 전혀 애자일하지 않은 워터폴 방식으로 개발한다든지 하는 도시전설때문에 오히려 애자일을 떠드는 사람이 빌런이 되는 시대가 되어 버렸다.

하지만 애자일을 잘 아는 사람이 애자일 문화를 주도하면 이런 리스크는 최소화할 수 있으리라 생각했다.

나는 시니어 한 명을 애자일 마스터로 지정하고, 그와 함께 ‘애자일 책’을 같이 공부하며 흉내만 내는 애자일이 아니라 진짜 애자일을 도입하고자 노력했다.

그 덕분인지 팀원들은 일일 스탠드업 미팅에서 단순히 업무 보고만 하기보다는 그들이 가진 진짜 ‘고민’들을 이야기하기 시작했고, 관리자인 나는 그러한 고민을 청취하고 면담이나 기타 방법으로 그들의 애로사항을 해결하는 식으로 같이 협업할 수 있었다.

바빠서 면담조차 할 수 없었던 나였기에, 이러한 방법은 분명 내게도 큰 도움이 되었다.

내러티브 팀이 한 일

내러티브 팀 역할 분배

내러티브 팀은 크게 아래와 같이 구성되었다.

• 팀 리더(파트장): 1명
• 책임(시니어): 1명
• 내러티브 실무자: 5명
• 사운드 디자이너: 1명
• 시스템 디자이너: 1명

나는 팀 리더로서, 유관부서와 회의를 하거나 기타 문의사항에 응답하는 한편, 팀원들의 작업물을 검수하고 내러티브 팀 전체의 방향성을 통일하는 역할을 맡았다.

책임을 맡은 분은 내가 한창 실무에 집중하는 동안 팀원들을 관리하거나 유관부서와 소통하는 일을 주로 맡았다.

한편, 실무적으로는 그 분이 가진 ‘시스템-콘텐츠’ 역량을 기반으로 개발자와 함께 다이얼로그 시스템 등을 함께 개발하는 전담 역할을 맡았다.

내러티브 실무자들은 매 마일스톤마다 내러티브 팀이 생산해야 하는 캐릭터 기획서나 스토리 스크립트, 연출 제작 등을 담당했다.

일정 편성은 관리자가 하고, 팀원들은 작업물을 제작하고 유관부서 사람들과 회의하며 함께 작업물을 만드는 역할을 맡았다.

사운드 디자이너는 내러티브뿐만 아니라 전투나 아웃게임 등의 BGM/SFX/AMB 등의 사운드까지 모두 제작하였다.

하지만 게임의 전체적인 톤앤매너나 맥락은 내러티브 팀에서 더 많은 책임이 있었기에 내러티브 팀 팀원으로 함께 합류했다.

시스템 디자이너는 내러티브 팀의 취약점인 ‘게임 디자인과 시스템에 대한 이해도’를 보완하기 위해 ‘아웃게임 디자이너’ 포지션으로 모셔왔다.

나는 시스템 기획 경험이 있어, 게임 디자인 팀과 협업할 때 테이블이나 스키마 등에 대해서도 함께 논의하며 게임을 개발했다.

하지만 ‘메인 스토리’ 등 스토리 제작에 더 집중해야하는 시기가 오자, 시스템과 관련한 논의를 할 수 있는 시간이 물리적으로 부족했다.

그래서 나를 대신해서 내러티브 팀 입장에서 개발자와 소통할 수 있는 사람이 필요했다.

그래서 시스템 디자이너를 모셔오되, 게임 디자인 팀의 영역을 침해하지 않는 선에서 함께할 수 있는 사람 또한 내러티브 팀으로 합류해 같이 일했다.

캐릭터 생산

캐릭터 컨셉 기획 등은 내러티브 디자이너가 주로 진행했다.

이들이 기획한 작업물은 내가 1차적으로 검수했고, 크게 문제 없다면 게임디자인팀이나 아트팀에 공유해서 함께 회의를 진행하거나 아이디어를 모았다.

그 과정에서 내러티브 디자이너는 이 캐릭터가 세계관/설정/스토리를 기반으로 어떤 목적으로 쓰일 것인지를 주로 이야기했었다.

개발 중-후반부에는 캐릭터가 어떤 ‘오리지날리티’와 ‘상품성’을 기반으로 기획이 되었는지를 좀 더 많은 비중을 할애해서 기획하게 되었다.

1명의 내러티브 디자이너는 컨셉 기획에서 적게는 10개에서 많게는 약 20개의 서브태스크를 처리했다.

그래서 캐릭터 하나를 개발하는 데 들어가는 워킹데이도 약 1달 정도가 소요되었다.

가령, 5명의 내러티브 디자이너 중 3명이 캐릭터 생산에 투입된다면 약 1달 간 3개의 캐릭터에만 집중해야 아슬아슬하게 처리해낼 수 있을 정도였다.

하지만 회사 일이라는게 그것만 있는 게 아니었기에, 실무자들도 잦은 초과근무와 야근에 시달릴 수밖에 없었다.

보이스 녹음

캐릭터 컨셉 기획을 마치면, 해당 캐릭터의 내러티브 디자이너는 곧 캐릭터 ‘담당자’가 된다.

그 담당자는 기획의도와 목적에 맞는 보이스 스크립트를 작성하는 일, 그리고 그 캐릭터의 캐릭터성에 부합하는 성우를 매칭하여 직접 녹음 과정에 참여하는 일까지 담당했다.

당시 A사의 출시 목표 캐릭터 수는 타 게임 대비 엄청 많은 수는 아니었지만, 캐릭터 하나당 약 100에서 150줄의 녹음을 처리해야 했기에 업무량이 적지는 않았다. (스토리 녹음 등은 제외된 분량이다.)

또한 프로젝트 개발 공정 상, 캐릭터 스킬 기획이나 애니메이션 등이 스펙이 변경되거나 개발 공정이 변경되는 경우가 있을 수 있어 녹음은 매 마일스톤 루틴하게 진행되기보다는 개발 중후반부에 무더기로 녹음이 진행되었다.

스토리 생산

스토리를 목적과 성격에 따라 여러 개로 구분하여, 각각 정해진 분량과 목표를 팀 기조 문서에 명시했다.

가령, 메인 스토리는 캐릭터 스토리와 성격이 다르기 때문에 분량이나 등장 캐릭터, 기승전결 구조나 후킹되는 포인트 등이 다를 수밖에 없었다.

그런 점을 문서에 명시적으로 기재하여 팀원들이 헷갈리지 않도록 구조를 잡아두었다.

팀 내에서도 스토리에 욕심이 있는 사람이 많아서 모두가 스토리를 작성하기는 했지만, 모든 팀원이 메인 스토리처럼 중요도가 높고 주목도가 높은 스토리를 맡을 수 있는 건 아니었다.

캐릭터 스토리 위주로 작업을 고르게 분배하되, 그 중에서도 작성 경험이 많거나 우리 게임 스토리 스타일을 빠르게 캐칭한 팀원은 이벤트 스토리 등을 맡겼다.

이벤트 스토리의 경우에는 캐릭터 스토리에 비해 플레이어들의 기대치가 높기 때문에 시놉시스-플롯-트리트먼트-스크립트로 이어지는 구조를 요구했다.

그래서 스토리 한 편을 쓸 때 기반이 되는 문서도 많이 준비했고, 본격적인 스크립트 작성에 앞서 유관부서에 전반적인 스토리 흐름을 공유하는 등 공통의 개발이라는 인식을 맞추려고 노력을 기울였다.

아웃게임 맥락 기획

게임 디자인 상 특정 시스템이나 콘텐츠는 내러티브 맥락이 함께할 경우 더욱 풍성해보이는 경우가 있다.

앞서 나는 우리 게임이 ‘아트’와 ‘내러티브’가 투탑 체제가 되면 좋겠다고 언급한 바 있었는데, 그렇기에 게임 디자인에 있어 더 많은 맥락을 제공하거나 더 구체적인 기획 제안서를 써서 전달하곤 했다.

특히 특정 콘텐츠는 게임 디자인적인 난이도나 밸런스 보다는 내러티브적인 감성과 분량이 더욱 중요한 경우가 있었다.

나는 해당 콘텐츠 담당자와 지속적으로 소통하며 내가 생각한 레퍼런스를 제공하거나 녹음 스크립트를 선녹음 대응하는 등, 단순히 스토리만 쓰고 캐릭터 컨셉만 기획하기보다는 좀 더 폭넓은 ‘협업’에 적극적으로 임했다.

아쉽게도 개발 중후반부에 접어들자 나는 스토리에 더 집중해야만 했고, 그래서 내가 맡았던 역할을 ‘아웃게임 디자이너’에게 넘길 수밖에 없었다.

그는 아예 그 콘텐츠를 본인이 이어서 기획서를 쓰고 개발자와 소통하는 식으로 일했다.

내러티브 팀 입장에서 개발자와 직접 소통할 일이 많지 않은데, 그 팀원 덕분에 개발자에게 생생하게 피드백을 듣거나 내러티브 팀 전체가 함께 게임 디자인적 재미를 함께 고민할 수 있었다.

리소스 기획

게임 개발 시 ‘방향성’이 빨리 정해져야하는 이유 중 하나는 바로 리소스 때문이다.

게임 데이터나 매커닉스 등은 수치를 바꾸거나 게임 시스템-콘텐츠를 보강하는 식으로 완성도를 높일 수 있는데, 리소스는 게임 디자인이 바뀌면 최악의 경우에는 폐기해야 한다.

한편, 리소스 발주는 빨리 이루어지지 않으면 개발 막바지에 가서는 사실상 발주 자체가 불가능해지기 때문에 유의해야 한다.

나는 캐릭터를 시작으로 발주 프로세스를 안정화/루틴화하려고 했고, 이어서 배경 발주나 아이콘 발주 등도 그러한 루틴화 체계를 도입하고자 했다.

그 과정에서 필자가 앞서 도입한 협업툴이나 Wiki 등은 큰 도움이 됐다.

라이브 업데이트는 짧은 시간 내에 안정적으로 꾸준히 산출물이 나와야하기 때문에 ‘루틴화할 수 있는 협업툴’은 큰 도움이 된다.

예를 들어, 하나의 캐릭터와 리소스를 먼저 하나 만들어 본다.

캐릭터 리소스 생산이 끝나면, 하나의 캐릭터 제작에 필요한 일감과 리소스 등을 일감 묶음으로 만들어 템플릿화한다.

그리고 난 뒤 여러 개의 캐릭터를 작업해보고 나서 각 작업물에 소요된 평균 시간과 일감을 정규화하면 그게 바로 ‘리소스 발주 프로세스’가 된다.

몇 개의 통계 데이터와 프로세스를 가지고 협업부서와 소통하니, 그쪽에서도 좀 더 신뢰감을 갖고 우리 팀을 대하는게 느껴졌다.

그리고 우리 팀 입장에서도 매 달 몇 개의 작업물을 요청할 수 있을지 예측가능한 수량이 그려졌다.

두 팀이 서로 덜 불안하게 리소스 발주와 생산에 임할 수 있게 된 것이다.

BGM/SFX/VFX 기획

내러티브 팀에서는 게임 스토리나 아웃게임 등에 사용될 BGM을 기획하는 일도 맡았다.

다행히 우리 프로젝트는 사운드 디자이너가 인하우스에 있었기 때문에 발주와 생산 등이 외주보다 훨씬 편리했다.

하지만 관리자 입장에서는 사운드 디자이너의 일정과 일감 또한 관리해야 하는 부담이 있는 것도 사실이었다.

그래서 사운드 디자이너의 작업에는 주로 ‘큰 틀에서의 일감’만을 주고, 대부분의 일은 자체적으로 일감을 생성하고 처리하는 식의 자율성을 부여했다.

BGM이나 SFX 등은 내러티브 디자이너가 니즈가 발생할 때마다 발주 리스트에 내용을 쌓아두면, 사운드 디자이너가 가능할 때 한번에 처리하는 식이다.

하지만 일부 전투나 VFX 등 상정 외의 일감이 들어오는 경우도 있었는데, 이 때에는 다른 업무보다 조금 더 우선순위를 높여 대응하게 하였다.

사운드 디자이너에게 자율성을 부여하자, 사운드 디자이너가 아트팀이나 게임디자인팀, 개발팀 등에 직접 찾아가 협의를 하거나 업무를 진행하는 구조가 만들어졌다.

이 부분은 매니저 입장에서는 다소 업무가 블랙박스화되는 느낌이 들었다.

하지만 ‘애자일 구조’를 도입했기 때문에 사운드 디자이너는 정기-비정기적으로 이슈와 현황을 공유했고, 덕분에 마음 편하게 사운드 디자이너에게 자율적인 구조를 계속 제공할 수 있었다.

잘 된 점과 그 한계

내러티브 팀의 존재감 부각

• 잘 된 점: 팀의 규모가 확장되고 전사 업무의 중심에 내러티브 팀이 오게 한 점

나는 입사 3개월 안에 파트장으로 승진했고, 내러티브 팀은 초기 3명에서 10명에 가까운 규모로 커졌다.

그리고 아트 만큼이나 내러티브도 우리 프로젝트에서 중요한 요소라는 인식을 전사적으로 가질 수 있게 만들었다.

좋든 싫든, 내러티브 팀은 게임디자인팀·아트팀·개발팀과 모든 주요 의사결정을 함께하는 개발의 중심에 서 있었다.

메인 로비 UI를 만들든, 내러티브적 감성이 중요한 콘텐츠를 만들든, 배경이나 아이콘 리소스를 발주하든, 그 모든 일이 내러티브의 손을 한 번은 거쳐갔다.

그러니 자연스럽게, 내러티브 팀의 일감은 항상 넘쳐났다.

팀원이 10명 가까이 되는 가장 큰 이유는 그렇게 팀원이 많음에도 불구하고 항상 일이 많이 들어오기 때문이었다. 팀원 모두가 야근과 초과근무에 시달렸지만, 중도 이탈자는 거의 없었다.

일이 많았던 만큼 그것을 해냈을 때 협업 부서에서 작업물을 올려주는 것을 보면서 보람을 느낄 일도 많았기 때문이었던 것 같다.

• 한계점: 주니어 위주의 팀 운영과 버거운 일정

인원은 늘어났지만, 팀 전체의 생산성은 팀원이 늘어날수록 조금씩 떨어졌다.

팀원 다수가 주니어 위주였고 그들을 온보딩/교육/퀄리티 컨트롤 할 수 있는 시니어 수가 부족했기 때문이다.

팀 기조나 기반문서 등을 정리했기 때문에 주니어라고 해도 ‘이미 익숙한 일’은 잘 처리해낼 수 있었다.

하지만, 아예 새로운 일을 맡기거나 내가 아예 보지 않아도 안심할 수 있을 정도의 상황은 거의 오지 않았다.

실제로 개발 후반부에는 “내러티브 검수 퀄리티가 예전보다 떨어진 것 같다”는 이야기가 타 팀에서 종종 들려왔다.

이는 팀 관리 업무가 이미 과부하가 걸려있는 탓에 팀원 하나하나의 작업물을 보다 세심하게 신경쓰지 못한 나의 잘못이다.

래서 팀원 규모가 커지는 것을 보고 일찌감치 ‘전문성에 따른 분업화’를 시도하였지만, 팀원 대다수가 라이팅에 뜻을 두고 있어 분업화가 까다로웠던 점도 한 가지 고민거리였다.

결국 팀 규모는 커졌지만 생산성은 거의 제자리걸음이었던 점은 아쉬운 점으로 남게 되었다.

안정적인 업무 목표 달성

• 잘 된 점: 매 마일스톤 마다 팀의 업무 목표를 명시화하고 체계적으로 분배하여 마일스톤 업무 달성률을 높게 유지할 수 있었던 점

우리 회사는 각 팀 리더가 직접 업무 목표를 설정하는 구조였고, 그래서 마일스톤마다 팀 리더가 얼마나 공격적으로 목표를 잡느냐에 따라 팀의 업무량이 크게 달라졌다.

예를 들어, 우리 팀이 설정한 목표를 좀 낮춰잡으면, 해당 마일스톤은 좀 편하게 일을 할 수도 있었다. 하지만 그렇게 안전하게만 목표를 잡다 보면, 장기적으로 프로젝트가 요구하는 수량과 퀄리티를 맞추기 어렵다고 판단했다.

우리 조직은 일단 마일스톤 시작 즈음에 대략적인 마일스톤 목표가 잡힌다.

예를 들어 캐릭터 스펙 3개 추가같은 식이다. 그러면 내러티브에서도 그 캐릭터가 빌드에 내러티브 상 풀스펙이 들어갈 수 있도록 녹음 스크립트부터 캐릭터 스토리까지 모두 제작하는 일감을 준비한다.

그 다음 마일스톤이 모두 끝나기 전, 다음 협업 파트너에게 업무가 넘어가도 그 부서에서 처리할 수 있는 ‘적정기간’에 작업이 진행될 수 있도록 일정을 편성한다.

예를 들어 빌드 마감이 3월이라면, 2월에는 협업 부서가 작업할 수 있도록 1월 말까지 내러티브 업무를 끝내는 식으로 역산해 일정을 짰다.

이렇게 일정을 매 번 미리 편성해두고 업무를 분배하자, 마일스톤이 끝날 때 즈음까지 특정 업무가 밀려서 다른 팀이 업무가 스탑되는 일이 많지 않았다.

그리고 관리자 입장에서도 팀원들에게 그때그때 업무를 주기보다는 미리 할당해 둠으로써 안정적인 일정-일감 관리 체제를 구축할 수 있었다.

• 한계점: 일감 분배와 추적 관리에 관리 코스트가 많이 들어간 점

관리 공수가 꽤 크게 발생했다.

먼저, 전사적인 마일스톤 목표를 매번 트래킹하면서 그것이 어떤 일감을 필요로 할지 예측하는 ‘선구안’이 필요했다.

그리고 해당 일감이 현실적으로 제작 가능한 시점까지 완료될 수 있는지에 대한 판단 능력도 필요했다.

결국, ‘될 지 안 될 지 잘 모르는데 일단 해보고, 계속 관찰하는’ 관리 코스트가 지속적으로 발생하게 되었다.

팀원들이 어디 아프거나 휴가라도 쓰게 되면 일정 상 딜레이가 발생할까봐 꽤 노심초사하게 됐다.

미리 예측해서 일감을 분배한 탓에, 언제까지는 선행 작업이 끝나야 그 뒤의 후속 작업이 차질 없이 진행될 수 있었기 때문이다. 어떤 업무는 타 팀에서 계획을 바꾸거나 우선순위를 조정한 탓에, 필요 시점보다 한참 먼저 된 적도 있었고, 어떤 업무는 반대로 갑자기 급해지기도 했다.

이러한 상황을 관리자 한 두 명이 유연하게 다 대처하기에는 역부족이었다.

결국 나는 내 일정 대부분을 비워두고, 팀원이 펑크가 나거나 갑작스럽게 타 팀에서 넘어오는 일은 내가 우선적으로 처리하는 식으로 일을 할 수밖에 없었다.

관리자가 실무까지 하려고 하니 매번 초과근무가 일상이 되어버리고 말았다.

라이브 대비 프로세스 정비

• 잘 된 점: 협업툴을 도입하고 리소스 발주 구조 등을 루틴화하여 라이브 체제에 대비할 수 있는 구조를 조기에 갖춘 점.

게임은 출시하기 이전과 이후가 개발 방식이 꽤 차이가 난다.

나는 앞서 다른 회사에서 2주에 1명의 캐릭터를 출시하는 조직에 있었는데, 미리 준비해둔 스펙 없이 격주로 캐릭터를 준비해야하는 탓에 매번 일정에 쫓겼다.

패치 노트를 쓰거나 데이터 테이블을 라이브에 맞춰 미리 준비하는 일도 보통이 아니었다.

실수로 한 번 누락이라도 하면 운영팀이 보상을 발송해야하는 등 타 팀에 민폐를 끼치는 결과를 낳기 때문에 매 업무가 긴장의 연속이었다.

그래서 나는 A사 게임이 출시하기 전까지 ‘라이브 친화적 프로세스’를 도입해, 출시 이후에 우왕좌왕하기 전에 미리 충분히 준비하고 출시할 수 있는 구조를 만들고자 했다.

일감 관리는 A툴, 일정 관리는 B툴로 역할을 분리해 단일화했고, 라이브 업데이트 때마다 템플릿을 복제해 내용만 채우면 자동으로 일정·일감이 갱신되도록 구조를 설계했다.

비록 그런 구조를 만들게 되기까지 꽤 많은 시간이 소요되고 노력이 필요하긴 했지만, 한번 구축해 두니 다른 팀에서도 편리하게 사용하는 등 나름 체계적으로 잘 정돈된 프로세스를 구축할 수 있었다.

• 한계점: 툴/프로세스 정비 때문에 정작 내가 해야 하는 스토리 작성/관리 업무 등에 소홀해진 점

한 번에 이렇게 프로세스를 짤 수 있으면 좋았겠지만, 사실 그러한 ‘라이브 친화적 프로세스’를 도입하기까지 꽤 많은 시행착오가 필요했다.

가령, 협업툴을 도입하려면 그 ‘비용’에 준하거나 그 이상의 편익을 얻어낼 수 있으리라는 ‘설득’의 과정이 필요하다.

회삿돈을 10원이라도 쓰면 그 사유와 증빙이 필요한 이 시대에, 수백에서 수천의 비용이 나가는 협업툴을 도입하자는 설득은 굉장히 까다로운 일이었다.

그래서 나는 협업툴은 설득할 수 있어도 위키는 결국 ‘무료 위키’를 사용하는 쪽으로 구조를 잡았다.

하지만 이는 결국 두 차례의 위키 이사로 이어졌고, 약 두 달 동안 나는 위키 이전 작업에 매달리느라 정작 내가 해야 할 본업에 제대로 집중하지 못했다.

물론 이사 이후에는 생산성이 높아지긴 했지만 짧은 개발기간 중에 2달 가까이 내가 원래 해야 했던 업무를 미루거나 지연시킬 수밖에 없었던 점은 뼈아픈 실책이었다.

잘 안 된 점과 실책

생각보다 더 컸던 관리 공수

• 예상했던 것: 사람의 수를 늘리면 내가 맡는 일이 줄어 부하가 줄어들 것이라는 예측
• 현실: 일은 줄었지만, 각 작업자를 관리하는 관리 코스트가 늘어남

입사했을 때부터 퇴사하는 그날까지 나는 회사에서 가장 오래 일하는 사람 중 하나였다.

특히 프로젝트 후반에는 아침 8~9시에 출근해서 밤 10~11시에 퇴근하는 경우가 많았다. 그러나 객관적으로 봤을 때 내 일감이 너무 많았던 것 때문은 아니었다. 오히려 관리 공수가 내 업무의 상당 부분을 차지했다.

앞서 언급했듯 우리 팀은 약 10명 가까이 달하는 큰 조직이었다. 나 혼자서 그들 모두의 작업물을 검토하고 피드백을 하자니 너무 많은 시간이 소요되었다. 내가 해야 할 일은 그밖에도 회의를 참석하거나 유관부서의 문의사항에 대응하거나, 기타 위에서 내려오는 과제를 처리하는 일 등이 있었다. 그 중 대부분은 우리 팀원에게 분배할 수 없는 일들도 상당수였다.

팀원 피드백이 밀리면 그 팀원의 일감에도 바로 빨간불이 들어온다. 내가 피드백을 하는 도중에 회의에 끌려가거나 작업이 끊기면, 다시 자리로 돌아왔을 때 ‘어디까지 봤지?’를 떠올리고 흐름을 다시 잡는 데 꽤 큰 전환 비용이 들었다. 팀원에게도 미안하지만, 나도 나로써는 어쩔 수 없는 경우가 많았다. 실제로 ‘메인 스토리’에 집중할 때는 나는 내 모든 관리 공수를 ‘책임님’께 떠넘기며 나 혼자 골방에 틀어박혀 글만 쓰는 ‘폐관수련’을 하는 식으로 일할 수밖에 없었다.

팀 규모가 5~6명일 때까지는, 나 혼자서도 어느 정도 관리를 할 수 있었다. 그때는 내가 직접 1~2시간씩 시간을 내 OJT를 맡고, 애자일 문화 도입이나 포스트모템도 주관할 수 있었다. 하지만 시간이 갈수록 그런 일은 꿈도 꾸기 어려워졌고, 점차 내게 주어진 일감을 제 시간 내에 쳐낼 시간마저 부족해졌다. 그렇다고 해서 내가 관리 코스트를 놓아버리면, 안그래도 타팀에서 내러티브 작업물에 대한 신뢰도에 의심을 품는 마당에 더 큰 신뢰 상실로 이어질 것 같아 두려웠다. 그래서 나는 그야말로 ‘사면초가’의 상태에서 배수진을 친 심정으로 어떻게든 지금의 위치에서 잘 하는 수밖에 없었다.

내러티브 영역을 넘어 더 큰 부분에 욕심낸 것

• 예상했던 것: 내러티브 외에도 프로젝트 곳곳에 비어있는 영역을 채워놓으면, 타 팀에게 감사나 인정을 받게 될 것
• 현실: 내러티브 팀은 자꾸 일을 크게 벌인다는 나쁜 인식이 심어짐

나는 우리 프로젝트의 성공을 위해서는 내러티브 팀의 역할이 중요하다고 생각했고, 단순히 캐릭터 컨셉을 채우고 스토리를 쓰는 것 외에도 게임의 전반적인 톤앤매너(비주얼 등)나 유저가 직접 경험하는 아웃게임 경험(인터랙션 등)에도 내러티브가 의견을 내야 한다고 생각했다.

그래서 ‘여러 부서와 걸쳐있는 일’에도 내러티브가 수동적인 목소리를 내기보다는 오히려 문서를 먼저 준비하거나 적극적으로 의견을 개진하는 등 보다 적극적으로 업무에 임했다.

나는 그렇게 일하는 게 다른 팀이 힘을 쏟아야하는 영역을 줄이고 우리 프로젝트가 더 잘 되는 길이라고 믿었다. 하지만 뒤늦게 들어온 피드백은 그러한 진행 방식이 오히려 ‘일을 벌인다’는 느낌이었다는 점이 충격이었다.

오히려 타 팀에서는 내러티브가 그렇게까지 말을 하니 일단 들어보자는 것이었고, 그들은 그들 나름의 생각과 방식이 있었던 것 같다. 하지만 내러티브 팀이 문서와 구체적인 액션 플랜까지 서둘러 내놓아 버리자, 협업 부서 입장에서는 자신들과 충분한 협의 없이 일이 진행되는 느낌을 받아, 오히려 우리의 일처리 방식에 불쾌함을 느낀 것 같았다.

그들이 그런 감정과 느낌을 받았던 것 같다는 신호를 캐칭했을 땐, 이미 우리 팀에 대한 인식이 나빠진 뒤였다.

그들이 그런 인식을 갖고 있다는 것을 알게 되자, 오히려 말을 하거나 의견을 내는 게 더욱 소극적이고 조심스러워졌다.

지금 돌아보면, 처음부터 충분히 생각을 공유하고 그들이 ‘핸들’을 쥐게 둔 채 나는 조수석에서 돕는 역할을 했다면, 이렇게까지 큰 저항은 없었을 것이라는 아쉬움이 남는다.

자율성의 그림자: 퀄리티의 저하

• 예상했던 것: 팀원 각자가 더 즐겁게 일할 수 있어 결과물이 좀 더 진정성 있고 팀원 각자의 ‘색깔’이 묻어나길 기대
• 현실: 결과물의 전반적인 퀄리티가 낮게 나와, 그것을 개선하기 위한 폴리싱 등의 추가 공수가 투입됨

팀원에게 자율성을 부여한 건 어디까지나 그들이 더 즐거운 마음으로 일하게 하여 그들이 ‘덕질하는 마음으로 회사일을 하기를 바라는 마음’ 때문이었다.

실제로 나는 이전 회사에 다녔던 경험을 바탕으로, 내게 주어진 자율성의 크기가 클수록 더 신나는 마음으로 일을 했었다. 그리고 그게 나쁘지 않은 결과를 냈다고 생각해, 그 구조를 팀에 도입하였다.

그러나 예상과 달리, 팀원들이 내는 결과물의 양과 질은 들쭉날쭉했고, 그중 일부는 처음부터 다시 작업해야 할 정도였다.

팀 내 기조 문서도 있고 어느 정도 원하는 방향성과 결은 전달했음에도 불구하고, 그들 하나하나에게 내가 정확히 어떤 수준을 원하는지 전달하지 못한 탓이다.

나는 마이크로피드백을 좋아하지 않는다. 그런 피드백을 받는 것도, 남에게 세세하게 주는 것도 모두 피로와 공수가 많이 드는 일이라 가능하면 피하고 싶다.

하지만 당시의 나는 그런 피드백이라도 하지 않으면 우리 팀이 생산하는 결과물의 전반적인 퀄리티가 낮아질 것이 눈에 보였다.

일부 작업은 퀄리티 편차가 커서, 담당 범위를 조정하거나 리더가 직접 폴리싱하는 방식으로 보완했다.

해당 담당자에게 일정을 더 주고 보강을 맡길 수도 있었겠지만 당시의 나는 그들에게 똑같은 업무를 다시 시키는 것보다는 하루라도 빨리 그 작업물을 빌드에 실을 수 있을 정도의 퀄리티가 나오기를 바랐다.

하지만 그러한 방식 탓인지, 우리 팀원들은 성장할 기회를 얻지 못했고 계속 내가 생각했던 방향성과는 조금 다른 작업물을 가져오게 되었다. 서로가 기대와 예상이 어긋난 채로 일하다보니 어쩌면 서로 불편한 동거를 지속하고 있었던 셈이다.

만약 팀원 대다수가 주니어가 아니라 시니어였다면 그런 일이 없었을까. 나는 그렇게 생각하지 않는다.

오히려 시니어는 그들의 색깔이 너무 강한 나머지 서로가 서로를 잡아먹으려고 하거나 말을 안 들었을 것이다. ‘하나의 방향을 바라봐야 한다’는 나의 믿음과 오히려 정 반대로 행동했을 가능성이 높다고 생각한다.

하지만 주니어 위주의 팀에서는 내가 아예 새로 작업을 해야 하는 경우가 잦았던 만큼, 결국 ‘주니어와 시니어의 비율을 적절히 섞어 구성하지 못한 것’이 내 리더로서의 뼈아픈 실책이었다.

다시 같은 자리에 선다면

리더 역할 범위 재설정

• 요약: 사람 수가 N명을 넘으면 어떤 형태로든 ‘서브 리더’를 세운다.

나는 내가 감당할 수 있는 관리 범위를 과신했다. 그 결과는 ‘관리 공수 폭탄’으로 돌아왔고, 팀 전체에 대한 평가까지 함께 떨어졌다.

내가 감당할 수 있는 팀원의 수는 최대가 다섯 명 정도였던 것 같다. 이 부분을 깨달은 게 너무 늦은 게 실책이다.

다행히(?) 후반에는 회사에서도 ‘유닛’이라는 개념으로 내가 맡았던 파트를 여러 리더를 내세우는 식으로 쪼개주었다. 하지만 그렇게 조치가 이루어졌을 때는 이미 너무 늦은 감이 있었다.

나는 내가 맡았던 영역 중 ‘아웃게임’이나 ‘사운드’ 등의 영역은 각각 해당 영역의 전문가인 ‘시스템 디자이너’나 ‘사운드 디자이너’에게 넘길 수 있었다.

그러나 내가 끝까지 놓지 못했던 건 바로 내러티브 디자이너가 올리는 결과물에 대한 검수였다.

만약 내가 그들에 대한 검수 권한마저 그 아랫단계로 내릴 수 있었다면 내가 이토록 관리 공수에 쫓기며 힘들게 하루하루를 보내야했던 경우는 줄지 않았을까.

리더는 어쩔 수 없이 외롭다. 그래서 더더욱, ‘중간 리더’를 세워 내 고민을 함께 나누고 앞으로 팀을 어떻게 운영할지 함께 비전을 그려갔어야 했다.

협업 방식과 ‘선’의 재설정

• 요약: 각 팀이 원하는 ‘영역’을 캐치하고, 내러티브는 그들이 원하는 영역이나 빠져있는 부분을 ‘도와준다’는 선을 제시한다.

나는 내러티브 팀이 프로젝트 개발 단계에서 어디까지는 반드시 관여해야 하고, 어디부터는 제안만, 무엇은 과감히 내려놓으면 좋을지 판단과 구분을 잘 하지 못했다. 그 결과 어떤 팀에게는 불쾌감이나 불안감을 주었던 것 같다.

내러티브 팀은 기획 직군 중에서도 가장 폭넓은 분야의 사람들과 넓고 얕게 교류하는 특성이 있는 듯하다.

게임디자인팀은 물론이고 아트팀, 개발팀, 그리고 PM이나 운영 부서, 위로는 대표(PD)님까지도 그 교류 대상에 포함된다. 그들 모두 각자 중요하게 여기는 가치와 우선순위가 있다.

내러티브 팀 리더였던 나 역시, 나만의 우선순위를 갖고 있었다. 앞으로는 그들이 중요하게 생각하는 요소를 먼저 듣고, 그 목표를 이루기 위한 방안 중에서 ‘내러티브가 도울 수 있는 일’을 몇 가지 추려 제안하는 방식으로 소통해야 한다. 그러면 서로 소통이 어긋나거나 불편함이 생길 지점도 훨씬 줄어들 것이다.

반대로, 다른 팀에서도 내러티브 팀 입장에서 불쾌하거나 불편한 선을 종종 넘어올 때가 있다. 그럴 때마다 매번 정색하며 선을 넘지 말라고 말하지 않는 이유는, 그들의 의견이나 생각 또한 존중하기 위함이었다.

하지만 리더가 그 선을 명확하게 긋지 않다보니 우리 팀원들이 다른 팀 리더나 시니어에게 휘둘리는 경우도 종종 있었다. 결국 리더는 다른 팀의 선을 넘지 않으면서도, 동시에 그들이 우리 팀의 선을 넘지 않도록 지켜내야 한다는 것을 뒤늦게 깨달았다.

자율성과 기준의 균형 재설계

• 요약: 수습기간에는 ‘마이크로피드백’ 기간으로 잡고, 이후에는 자율성을 보장한다.

나는 팀원들에게 최대의 자율성을 보장해주고 싶었다. 하지만 그들의 색깔을 살리고 개성을 살리는 길은 멀고도 험난했다.

오히려 그들의 일을 내가 대신 처리해준다는 느낌을 받을 때는 새삼 억울하다는 느낌이 들 때도 있었다. 하지만 그 또한 내가 관리를 잘못한 실책이었다.

실무자가 관리자가 원하는 방향과 다르게 작업했다는 건, 애초에 관리자가 그들에게 원하는 바를 충분히, 명확하게 설명하지 못했다는 뜻이기도 하다.

이는 내가 아무리 팀 기조 문서를 준비하고 몇가지 템플릿을 준비했다고 해서 자동으로 다 해결되는 일이 아니었다.

‘자율’을 보장하려면, 그 전에 충분한 사전 ‘조율’이 선행되어야 한다는 사실을 뒤늦게 깨달았다.

제 아무리 바빠도, 새로 합류한 팀원이 1인분을 하기 위해서는 나는 진득하게 그들과 함께하며 그 작업물 하나하나를 세심하게 검토하고 의견을 주었어야 했다.

오히려 그렇게 투자하는 시간이 나중에 내 시간을 절약해주었을 테니까.

또한 팀원 구성도 중요하다.

10년차 시니어와 0년차 신입에게 똑같은 ‘자율’과 똑같은 ‘피드백’을 줄 수는 없다. 사람마다 그 정도와 시간은 달라야 한다.

시니어에게는, 그들이 주니어에게 ‘내가 원하는 방식’을 자연스럽게 전파할 수 있도록 내 방향성과 비전을 더 명확하게 맞춰두는 것이 필요하다.

시니어는 오히려 머리가 굳기 쉽기 때문에, 내가 그 방향성을 잘 전달하지 않으면 그들 나름대로 자신들이 가진 에고나 성향에 맞춰 주니어를 이리저리 헷갈리게 만들 수 있다.

팀 리더는 시니어에게 모든 것을 맡기는 대신, 그들이 자신의 방식만으로 팀원을 휘둘리지 않도록 곁에서 계속 지켜봐야 한다.

아무리 바쁘더라도, 내 손으로 뽑은 팀원은 끝까지 내가 책임지고 관리해야 한다.

내가 아무리 바쁘고 다른 중요한 과업이 있다고 하더라도, 그렇게 하지 않으면 궁극적으로는 나와 그 사람 모두를 곤경에 빠트리는 날이 올 수도 있기 때문이다. 그러한 교훈을 이렇게 뒤늦게 깨닫게 된 것 같다.

정리하는 글: 다시 앞으로,

이 글은 나와 함께 일했던 특정 누구를 저격하거나 내가 몸담은 조직을 비판하기 위한 글이 아니다. 그들과 함께한 내가 부족했음을 기록하고 기억하기 위함이다.

A사 내러티브 팀 경험은, 내가 얼마나 많이 할 수 있는가보다 ‘어디서 멈추고, 무엇을 나누어야 하는가’를 배우게 해 준 시간이었다.

다음에 합류하게 될 조직에서는 이러한 경험과 교훈을 바탕으로 나만의 기준을 더 분명히 하여, 오랫동안 신뢰와 사랑받는 내러티브 조직을 만드는 데 기여하고 싶다.