하나의 게임을 만들기 위해서는 다수의 다양한 직군의 사람들이 협력해야 하는 것은 당연한 일. 오늘 소개할 <야생의 땅: 듀랑고>(이하 듀랑고)를 만든 왓 스튜디오의 개발 역시 그렇습니다. 다만 왓 스튜디오만의 개발 프로세스에서 특징이 있다면, 다른 회사에 있다가 온 사람들이 적응하기 어려울 정도로 자유롭고 창의적인 조직문화를 가지고 있다는 것인데요.
이처럼 자유롭고 창의적인 조직문화는 조직이 작을 때는 좋은 효과를 내지만, 사람이 많아질수록 처리해야할 정보량이 너무 많아지면서 관리가 어려워진다는 단점이 있습니다. 이날 강연에서는 왓스튜디오의 안미루 프로젝트 매니저가, <듀랑고> 개발팀이 자유로운 조직문화와 효율적인 업무관리라는 두 마리 토끼를 동시에 잡을 수 있었던 비결을 공개했습니다.

<듀랑고> 개발팀의 조직문화는 자유롭고 개방적인 것으로 유명합니다. 다른 스튜디오에 있다가 새로 온 팀원이 상급자에게 "무엇을 할까요?" 라고 물으면, 상급자가 거꾸로 "뭐가 하고 싶으세요?"라고 묻는 식이죠.
이런 조직문화에서는 자기 의견을 적극적으로 내고, 하고 싶은 것을 표현하고 의견을 개진하는 것이 매우 중요합니다. 누구나 자유롭게 자기 의견을 표현할 수 있으니, 아이디어가 굉장히 많이 나오는 점은 특히 좋은 점이라고 할 수 있습니다.
뿐만 아니라 <듀랑고> 팀은 소통에 있어서도 유별납니다. 안미루 PM은 "수다쟁이 조직"이라는 표현을 사용하기도 했는데요. 그룹 채팅 툴인 Slack에 매일 1만 개의 문장이 쌓인다고 합니다. 말하자면 매일 거의 책 한 권 씩을 쓰면서 일을 하고 있는 것이나 마찬가지입니다.

이러한 조직 문화는 앞서 말한 것처럼 다양한 아이디어, 개성있고 독특한 결과물을 가능하게 한다는 장점이 있습니다. 하지만 단점도 없지 않습니다. 예측이 불가능하고, 정보량이 너무 많아 관리가 어려워지기 때문입니다. 즉, "주방에 요리사가 너무 많다"는 겁니다.
특히 라이브 서비스 환경에서는 서비스의 안정성과 예측 가능성이 중요합니다. <듀랑고>의 경우 2주에 한 번씩 정기적으로 업데이트를 하도록 일정이 짜여있기 때문에, 이러한 흐름에 맞추기 위해서는 더더욱 안정성과 앞으로의 업무에 대한 예측이 중요합니다.
자유로운 조직문화는 앞서 말한 것처럼 안정성이 떨어지고 예측이 불가능하다는 점에서 라이브 서비스에 있어서는 부적합한 것처럼 보입니다. 하지만 <듀랑고> 팀에게 있어 자유로운 조직 문화는 창의적인 결과물을 내기 위해서도 매우 중요했죠. 그렇다면 어떻게, 자유와 관리라는 두 가지 토끼를 동시에 잡을 수 있을까요?

<듀랑고> 팀이 선택한 방법은 크게 2가지로 나눌 수 있습니다. 넘쳐나는 정보량과 의사소통 문제는 작업관리 툴 Jira를 이용해 생산성을 높여 해결하고, 안정성과 예측 가능성의 문제는 2주 단위의 스크럼 개발 주기를 통해 해결하는 것입니다. 안미루 PM은 이해를 돕기 위해, 이 2가지 방법을 사용한 구체적인 예시로 <듀랑고>의 만우절 이벤트를 들었습니다.
라이브 개발 프로세스는 할 일 후보 모으기 - 작업 검토 - 다음 업데이트에 할 일 결정 - 2주 개발 - QA 및 패치노트 작성 - 업데이트의 단계로 진행됩니다. <듀랑고> 만우절 이벤트의 경우에는, 글 작가의 심플하지만 귀여운 그림체를 살린 2D 종이 공룡을 실제로 게임에 넣자는 아이디어에서 출발했습니다.

아이디어가 채택됐으면 이제 할 일 후보를 모으기 시작합니다. 제목, 의도, 내용, 버전, 담당자 등을 기록하는데, 보이는 것처럼 그 외에도 여러가지 속성들을 넣고 뺄 수 있습니다. Jira의 장점은 필터링이 용이하다는 것입니다. 예를 들어 자신이 원하는 버전이면 버전 별로, 담당자면 담당자별로 쉽게 모아 보여주기 때문에 자신이 원하는 정보를 찾아서 쓰기가 쉽습니다.
이렇게 Jira에 등록되는 할 일 후보의 출처는 매우 다양합니다. 개발팀, QA팀, 운영팀, 사업팀이 모두 각자의 위치에서 필요한 작업들을 등록합니다. QA팀은 QA과정 중 발견괸 버그를 등록하고, 운영팀은 고객 문의나 동향을 등록하고, 사업팀은 제휴나 이벤트를 제안하는 식이죠. 물론 가장 많은 제안을 등록하는 것은 개발팀, 특히 게임 디자인팀입니다.

이렇게 할 일 후보가 모이면, 다음으로 작업을 검토합니다. 제안들의 작업 난이도, 그리고 작업에 걸리는 시간 등을 알아보는 것입니다. 실제로 종이 공룡 이벤트의 경우, "종이 공룡을 게임에 등장시키면 어색하지 않을까?"라는 이슈가 있었습니다만, 작업 결과 매우 귀엽고 잘 어울렸습니다. 데미지는 귀엽지 않았지만요.
이 검토 단계에서 중요한 것은, 각 분야의 전문가들이 초기 단계에서 벌써 피드백을 줄 수 있다는 점입니다. 일반적인 작업 방식에서는 작업자들이 이미 다른 부분에서 작업된 결과물을 받는 경우도 있습니다. 이 경우 이미 여기저기 작업을 해놓은 상태이기 때문에, 작업에 대한 의논이 아니라 통보가 되어버리기 일쑤죠. 하지만 <듀랑고> 팀의 방식에서는 각 분야 전문가들이 초기에 좋은 피드백을 주기 때문에 업무 진행이 더 수월해집니다. 모든 팀원이 함께 게임을 만들어나가고 있다, 라는 느낌을 받게 한다는 장점도 있습니다.

검토 절차가 끝나면, 일감 회의를 개최하고 다음 업데이트에 할 일을 등록합니다. <듀랑고>팀 에서는 "주차"라고 표현한다고 합니다. 다음 업데이트 개발 기간이 오기 전에 검토가 끝나 등록되어 있는 일들이 자동으로 다음 업데이트 후보가 되겠죠. 이 일감 회의에는 모든 사람이 참여하지는 않고, 각 직군별 리더들과 프로젝트 매니저가 참여합니다.
일감 등록 과정에서 중요한 것은 우선순위 설정과 가용한 작업력 정원을 파악하는 것입니다. 먼저 우선순위는 게임디자인팀의 의견을 중시하여 설정합니다. 전체 게임에 대해 디자인팀에서 가장 잘 알고 있기 때문이죠. 물론 다른 팀도 얼마든지 의견을 내고 함께 토론할 수 있습니다.
그렇다면 작업력은 어떻게 선정할까요? 여기에는 하나의 공식이 있습니다.
작업력 = 가용 인력 x 가용 영업일 x 50~80%
이렇게 써 놓으면 어렵지만, 쉽게 풀면 이렇게 설명할 수 있습니다. 어떤 원화를 작업해야 하는 상황에서, 원화가가 3명 있고, 작업 기간은 2주입니다. 그러면 가용인력은 3이 되고, 가용 영업일은 2주에서 휴일을 뺀 10일이 됩니다. 뒤의 퍼센트는 '버퍼', 즉 예상하지 못한 사고 등 추가 작업이 필요할 것을 대비해 남겨드는 작업력입니다. 보통 20~50% 정도를 버퍼로 남겨둔다고 합니다. 이 경우, 이 원화 작업의 작업력 공식은 이렇게 됩니다.
원화력 = 3명 x 10일 x 50~80%



