로그인

회원가입 | ID/PW 찾기

NDC

[NDC 19] 주방에 요리사가 좀 많으면 어때? '듀랑고' 팀의 라이브 개발 프로세스

자유와 관리, 두 마리 토끼를 잡기 위한 왓 스튜디오의 노력

이준호(마루노래) 2019-04-26 11:46:08

하나의 게임을 만들기 위해서는 다수의 다양한 직군의 사람들이 협력해야 하는 것은 당연한 일. 오늘 소개할 <야생의 땅: 듀랑고>(이하 듀랑고)를 만든 왓 스튜디오의 개발 역시 그렇습니다. 다만 왓 스튜디오만의 개발 프로세스에서 특징이 있다면, 다른 회사에 있다가 온 사람들이 적응하기 어려울 정도로 자유롭고 창의적인 조직문화를 가지고 있다는 것인데요.

 

이처럼 자유롭고 창의적인 조직문화는 조직이 작을 때는 좋은 효과를 내지만, 사람이 많아질수록 처리해야할 정보량이 너무 많아지면서 관리가 어려워진다는 단점이 있습니다. 이날 강연에서는 왓스튜디오의 안미루 프로젝트 매니저가, <듀랑고> 개발팀이 자유로운 조직문화와 효율적인 업무관리라는 두 마리 토끼를 동시에 잡을 수 있었던 비결을 공개했습니다.

 

강연자인 안미루 프로젝트 매니저.




#<듀랑고> 팀의 조직문화: "무엇을 할까요?" 가 아니라, "하고 싶은게 뭔가요?"

 

<듀랑고> 개발팀의 조직문화는 자유롭고 개방적인 것으로 유명합니다. 다른 스튜디오에 있다가 새로 온 팀원이 상급자에게 "무엇을 할까요?" 라고 물으면, 상급자가 거꾸로 "뭐가 하고 싶으세요?"라고 묻는 식이죠.

 

이런 조직문화에서는 자기 의견을 적극적으로 내고, 하고 싶은 것을 표현하고 의견을 개진하는 것이 매우 중요합니다. 누구나 자유롭게 자기 의견을 표현할 수 있으니, 아이디어가 굉장히 많이 나오는 점은 특히 좋은 점이라고 할 수 있습니다.

 

뿐만 아니라 <듀랑고> 팀은 소통에 있어서도 유별납니다. 안미루 PM은 "수다쟁이 조직"이라는 표현을 사용하기도 했는데요. 그룹 채팅 툴인 Slack에 매일 1만 개의 문장이 쌓인다고 합니다. 말하자면 매일 거의 책 한 권 씩을 쓰면서 일을 하고 있는 것이나 마찬가지입니다.

 

 

이러한 조직 문화는 앞서 말한 것처럼 다양한 아이디어, 개성있고 독특한 결과물을 가능하게 한다는 장점이 있습니다. 하지만 단점도 없지 않습니다. 예측이 불가능하고, 정보량이 너무 많아 관리가 어려워지기 때문입니다. 즉, "주방에 요리사가 너무 많다"는 겁니다.

 

특히 라이브 서비스 환경에서는 서비스의 안정성과 예측 가능성이 중요합니다. <듀랑고>의 경우 2주에 한 번씩 정기적으로 업데이트를 하도록 일정이 짜여있기 때문에, 이러한 흐름에 맞추기 위해서는 더더욱 안정성과 앞으로의 업무에 대한 예측이 중요합니다.

 

자유로운 조직문화는 앞서 말한 것처럼 안정성이 떨어지고 예측이 불가능하다는 점에서 라이브 서비스에 있어서는 부적합한 것처럼 보입니다. 하지만 <듀랑고> 팀에게 있어 자유로운 조직 문화는 창의적인 결과물을 내기 위해서도 매우 중요했죠. 그렇다면 어떻게, 자유와 관리라는 두 가지 토끼를 동시에 잡을 수 있을까요?

 


 

#두 마리 토끼 잡기 : 작업 관리 툴 Jira와 2주 단위 스크럼을 활용한 라이브 개발 프로세스

 

<듀랑고> 팀이 선택한 방법은 크게 2가지로 나눌 수 있습니다. 넘쳐나는 정보량과 의사소통 문제는 작업관리 툴 Jira를 이용해 생산성을 높여 해결하고, 안정성과 예측 가능성의 문제는 2주 단위의 스크럼 개발 주기를 통해 해결하는 것입니다. 안미루 PM은 이해를 돕기 위해, 이 2가지 방법을 사용한 구체적인 예시로 <듀랑고>의 만우절 이벤트를 들었습니다. 


라이브 개발 프로세스는 할 일 후보 모으기 - 작업 검토 - 다음 업데이트에 할 일 결정 - 2주 개발 - QA 및 패치노트 작성 - 업데이트의 단계로 진행됩니다. <듀랑고> 만우절 이벤트의 경우에는, 글 작가의 심플하지만 귀여운 그림체를 살린 2D 종이 공룡을 실제로 게임에 넣자는 아이디어에서 출발했습니다.

 

귀여운 종이 공룡을 실제로 게임에 넣은 <듀랑고>의 만우절 이벤트.

 

아이디어가 채택됐으면 이제 할 일 후보를 모으기 시작합니다. 제목, 의도, 내용, 버전, 담당자 등을 기록하는데, 보이는 것처럼 그 외에도 여러가지 속성들을 넣고 뺄 수 있습니다. Jira의 장점은 필터링이 용이하다는 것입니다. 예를 들어 자신이 원하는 버전이면 버전 별로, 담당자면 담당자별로 쉽게 모아 보여주기 때문에 자신이 원하는 정보를 찾아서 쓰기가 쉽습니다.

 

이렇게 Jira에 등록되는 할 일 후보의 출처는 매우 다양합니다. 개발팀, QA팀, 운영팀, 사업팀이 모두 각자의 위치에서 필요한 작업들을 등록합니다. QA팀은 QA과정 중 발견괸 버그를 등록하고, 운영팀은 고객 문의나 동향을 등록하고, 사업팀은 제휴나 이벤트를 제안하는 식이죠. 물론 가장 많은 제안을 등록하는 것은 개발팀, 특히 게임 디자인팀입니다. 

 

실제 Jira에 등록된 할 일의 예시.

 

이렇게 할 일 후보가 모이면, 다음으로 작업을 검토합니다. 제안들의 작업 난이도, 그리고 작업에 걸리는 시간 등을 알아보는 것입니다. 실제로 종이 공룡 이벤트의 경우, "종이 공룡을 게임에 등장시키면 어색하지 않을까?"라는 이슈가 있었습니다만, 작업 결과 매우 귀엽고 잘 어울렸습니다. 데미지는 귀엽지 않았지만요.

 

이 검토 단계에서 중요한 것은, 각 분야의 전문가들이 초기 단계에서 벌써 피드백을 줄 수 있다는 점입니다. 일반적인 작업 방식에서는 작업자들이 이미 다른 부분에서 작업된 결과물을 받는 경우도 있습니다. 이 경우 이미 여기저기 작업을 해놓은 상태이기 때문에, 작업에 대한 의논이 아니라 통보가 되어버리기 일쑤죠. 하지만 <듀랑고> 팀의 방식에서는 각 분야 전문가들이 초기에 좋은 피드백을 주기 때문에 업무 진행이 더 수월해집니다. 모든 팀원이 함께 게임을 만들어나가고 있다, 라는 느낌을 받게 한다는 장점도 있습니다.

 

 

검토 절차가 끝나면, 일감 회의를 개최하고 다음 업데이트에 할 일을 등록합니다. <듀랑고>팀 에서는 "주차"라고 표현한다고 합니다. 다음 업데이트 개발 기간이 오기 전에 검토가 끝나 등록되어 있는 일들이 자동으로 다음 업데이트 후보가 되겠죠. 이 일감 회의에는 모든 사람이 참여하지는 않고, 각 직군별 리더들과 프로젝트 매니저가 참여합니다.

 

일감 등록 과정에서 중요한 것은 우선순위 설정과 가용한 작업력 정원을 파악하는 것입니다. 먼저 우선순위는 게임디자인팀의 의견을 중시하여 설정합니다. 전체 게임에 대해 디자인팀에서 가장 잘 알고 있기 때문이죠. 물론 다른 팀도 얼마든지 의견을 내고 함께 토론할 수 있습니다.

 

그렇다면 작업력은 어떻게 선정할까요? 여기에는 하나의 공식이 있습니다.

 

작업력 = 가용 인력  x 가용 영업일 x 50~80%

 

이렇게 써 놓으면 어렵지만, 쉽게 풀면 이렇게 설명할 수 있습니다. 어떤 원화를 작업해야 하는 상황에서, 원화가가 3명 있고, 작업 기간은 2주입니다. 그러면 가용인력은 3이 되고, 가용 영업일은 2주에서 휴일을 뺀 10일이 됩니다. 뒤의 퍼센트는 '버퍼', 즉 예상하지 못한 사고 등 추가 작업이 필요할 것을 대비해 남겨드는 작업력입니다. 보통 20~50% 정도를 버퍼로 남겨둔다고 합니다. 이 경우, 이 원화 작업의 작업력 공식은 이렇게 됩니다.

 

원화력 = 3명  x 10일 x 50~80%

 

 

물론 이런 과정에서 다음 일감으로 선정되지 못하는 일들도 생깁니다. 이런 일들은 다음 버전의 작업 후보로 미루거나 아예 보류합니다. 이런 일감들은 이후 새로 등록된 일감들과 다시 경쟁하는 관계가 되고, 또 일감 회의를 해서 우선순위에서 살아남는 것들만 작업하는 방식으로 효율을 확보합니다. <듀랑고>팀의 경우 매달 Jira에 등록되는 작업의 수가 1000개 가까이 되지만, 이중 실제로 작업되는 것은 600개 정도, 나머지 400개는 남겨지게 된다고 합니다.

이러한 과정을 거쳐 일감 회의가 끝나면, 일감별로 필요한 직군별 업무를 생성하고 담당자를 배정합니다. 그러면 본격적으로 2주간의 스크럼 개발 과정이 시작됩니다. PM들은 스크럼 별로 생성된 보드를 실시간으로 체크하면서 작업의 상태를 확인하고, 마감일 전에 모든 일이 완료될 수 있도록 관리합니다.


#<듀랑고>팀의 해법, 그 결과는?

결과적으로 <듀랑고> 개발팀이 도입한, Jira와 2주 스크럼이라는 방법은 관리의 측면에서 매우 좋은 효과를 낳았습니다. 각 작업가자 해야하는 일과 필요한 정보를 쉽게 알 수 있고, 관리자도 현재 상황을 실시간으로 파악할 수 있었습니다.

모든 정보 처리의 창구를 Jira로 일원화하니, 업무의 누락 역시 많이 줄어들었죠. 특히 변경점이 누락되지 않는 부분도 중요했습니다. 변경점이 누락되어서 패치노트에 기입되지 않으면 이른바 '잠수함 패치'가 되니까요. 조직에 사람이 많아지고 복잡해지면 흔히 비효율성이 늘어나고는 하는데, <듀랑고> 팀의 경우 오히려 생산성이 좋아져 패치노트가 더 길어지기도 했습니다.

그렇다면 자유의 측면에서는 어땠을까요? 활발한 의사소통과 의견 교환이 자유로운 분위기는 여전하다고 합니다. 다만 업무상 전문화와 분업화는 계속해서 진행되고 있습니다. 초기에는 밸런스만 담당하는 사람이 따로 없었는데, 지금은 밸런스 담당자가 따로 생기는 식으로 말이죠. 예전처럼 모든 직군이 다같이 모여 이야기하는 일은 힘들어졌지만, 이것은 프로세스 자체의 문제라기보다는 사람이 많아지면 어쩔 수 없는 문제이기도 합니다.

한편 일감을 의뢰하고 그것을 배포하는 데에 걸리는 시간은 늘어났습니다. 모든 할 일 후보는 일감회의 전에 디자인이 완료되어 등록되어 있어야 하니까요. 업데이트 직전에 새로 할 일을 추가하는 식으로는 일할 수 없게 된 것이죠. 기민성이 조금 떨어지는 것처럼 보일 수는 있지만, 대신 전에 비해 안정성이 확보됐습니다.



#새로운 프로세스, 사람들의 반응은?

전반적으로 사람들의 반응은, 프로세스의 앞쪽에 있는 사람과 뒷쪽에 있는 사람에 따라서 조금 갈렸다고 합니다. 프로세스의 앞에 있는 사람들, 예를 들어 게임디자인팀의 경우엔 자신이 낸 아이디어가 일감으로 선정되지 못하고 버려지는 것을 계속해서 봐야하니 아쉬울 수밖에 없겠죠. 하지만 프로세스의 뒤에서 작업에 투입되는 사람들은 행복도가 상당히 증가했다고 합니다. 지나친 야근이 발생하지 않도록 업무량이 관리되고 있다는 느낌을 받기 때문입니다.

<듀랑고> 팀이 이런 라이브 개발 프로세스를 시행한 지는 이제 1년이 거의 다 되어 갑니다. 지금까지 잘 되어 왔으니, 앞으로도 이러한 방식을 유지할 예정입니다. 다만 이 상태로 고정한다는 뜻은 아닙니다. 현재의 개발 프로세스 역시 수많은 '업데이트'를 통한 결과였기 때문이죠. 프로세스는 수많은 수정을 거치며 변화해왔고, 앞으로도 계속 변화할 것이라고 안미루 PM은 덧붙였습니다.



#프로젝트 매니저, 쉬운 일은 아니지만, 매력적이고 즐거운 직업

마지막으로 안미루 PM은 다소 사적인 이야기를 꺼냈습니다. 바로 자신이 프로젝트 매니저로 일하며 느끼는 보람에 대한 것이었습니다.

강연자는 수학 전공자이고, 문제를 푸는 것을 참 좋아한다고 합니다. 다만 예전에는 수학 문제를 풀었다면, 지금은 동료들과 조직의 문제를 풀어나가고 있습니다. 어려움을 겪는 동료들의 고충을 들어주고, 또 이에 대한 깔끔한 해결을 제시, 해결됐다는 이야기를 들으면 기쁨을 느낀다며, 앞으로 더 많은 조직이 프로젝트 매니저의 필요성에 대해서 느낄 수 있기 바란다는 말과 함께, 안미루 PM은 강연을 마무리했습니다.

"프로젝트 매니저는 행복한 직업입니다."

최신목록 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10