주제: '야생의 땅: 듀랑고' 조직 문화와 라이브 개발 프로세스 - 자유와 관리, 두 마리 토끼 잡기
강연자 : 안미루 - 넥슨코리아 / NEXON KOREA
발표분야 : 프로덕션&운영
권장 대상 : 개발 PM
난이도 : 사전지식 불필요 : 튜토리얼이나 개요 수준에서의 설명
[강연 주제] 다른 게임들도 그렇듯이 '야생의 땅: 듀랑고'도 다수의 다양한 직군 사람들이 협력하여 만들고 있는 게임입니다. 다만 다른 곳에 비해 1) 모두가 자신의 모든 작업 내용과 의견을 열심히 기록으로 남긴다. 2) 기록들에 기반해 모두가 게임에 관한 모든 정보를 실시간으로 알 수 있다. 3) 모두가 모든 것에 대해 자신의 의견을 표현할 수 있다. 는 점이 조직 문화의 특징입니다. 즉, 모두가 열심히 기록하고 열심히 듣는 문화인데, 이런 문화는 자유롭고 창의적인 조직을 만드는 데는 큰 도움이 되지만, 사람이 많아질수록 정보량이 감당이 안 될 정도로 많아지고 관리가 잘 안 된다는 문제가 있습니다.
본 발표는 자유와 관리, 두 마리 토끼를 잡기 위해 1) 이슈 트래킹 툴인 JIRA를 사용하여, 수많은 제안과 할 일 등의 정보들이 누락되지 않고 검토를 거치게 되는 과정, 2) 각 일감들이 제안->검토->일감 확정->개발->QA 등의 단계를 거쳐 배포에 이르게 되는 라이브 개발 프로세스에 대해 설명합니다.
효율적인 개발 프로세스를 만드는 일은 결코 쉽지 않다. 특히나 개발하던 게임이 라이브 서비스에 돌입하게 되면 주기적인 업데이트 일정에 맞춰 효율적인 개발 프로세스를 구축하는 게 좋다. 또한 팀의 규모도 점점 확대되면서 이런 '개발 프로세스'를 정돈하는 건 쉽지 않은 일이다. 이 과정에서 팀의 분위기를 해치거나 바뀌는 경우도 자주 발생한다.
현재 듀랑고의 프로젝트 매니저를 맡고 있는 넥슨의 안미루 선임연구원은 NDC 2019의 강연에서 '듀랑고' 팀의 사례를 들어서 효율적인 개발 프로세스를 도입하면서도 팀의 분위기를 유지하는 경험을 공유했다.
■ 자유로운 문화의 듀랑고 개발팀, '안정성 확보'를 위해서는?
강연의 서두에서 안미루 연구원은 '듀랑고'팀의 조직 문화에 대해 소개했다. 먼저 듀랑고 팀은 아주 자유롭고 개방적인 분위기를 가지고 있다. 누구나 자유롭게 자신의 의견을 표현할 수 있으며, 반응이 좋은 의견의 경우 합심해서 개발을 이어간다.
두 번째는 소통이다. 모든 팀원들이 열심히 말을 하고, 기록하며 듣는다. 그룹 채팅 '슬랙'에는 매일 1만 문장 이상의 채팅이 올라올 정도다. 또한 매달 작업 관리툴인 JIRA에는 생성 작업만 1,000개가 넘어가며, 이걸 모두가 열심히 읽고 있다.
좋게 보면 아이디어가 샘솟는다고 할 수 있고, 뭘 해야 하나 하는 일은 거의 없다. 많은 의견이 교류되다 보니 개성 있는 독특한 결과물이 나온다. 다만 반대로 보면 이는 예측하기가 힘들다. 사공이 많다는 뜻이기도 하다. 교류가 적극적으로 일어나다 보니 정보량이 지나치게 많아 따라가기가 힘든 경우도 발생한다.
이러한 자유로운 팀 분위기는 장점이지만, 예측이 힘들며 안정성은 다소 불안할 수 있다. 게임이 라이브 서비스를 이어가면서 개발을 하기에는 반드시 '안정성'을 확보해야 한다. 2주 단위로 업데이트를 진행해야 하고, 게임 개발팀뿐 아니라 운영팀이나 사업팀 등 더 많은 조직이 협력이 이뤄진다. 예상치 못한 다양한 문제도 대응해야 하고, 서비스의 안정성을 확보하기 위해서라도 개발팀의 안정성이 필요하다.
안미루 연구원은 이런 자유로운 팀의 분위기를 유지하면서 라이브 서비스에 맞춘 팀의 게임 개발 프로세스를 확보해 조화를 이루려고 노력했다. 그래서 두 가지 방법을 도입했다.
첫 번째는 넘쳐나는 정보량과 의사소통의 문제는 작업 관리 툴인 'JIRA'를 활용하기로 했다. JIRA를 이용해서 필터링 기능을 활용하여, 필요한 정보가 필요한 사람에게 전달될 수 있도록 하여 정보 처리의 생산성을 높였다.
안정성과 예측 가능성의 문제를 해결하기 위해서 게임의 업데이트에 맞춰 2주 단위의 스크럼 개발 주기로 잡았다. 개발 주기를 시작하기 전, 미리 작업 내용을 정해놓고 개발을 진행한다. 물론 이 '주기'마다 개발에 참여하는 인원은 한정되어 있다. 개발에 참여하지 못한 인원은 다음 주기 개발에 참여할 수 있는 형태다.
개발에 앞서 개발 후보들을 모으고, 해당 내용을 검토한다. 이후 업데이트의 스펙을 결정하고 참여 인력을 정한 뒤, 2주간 개발을 진행한다. 그리고 QA를 거쳐 업데이트가 적용되는 형태다. 다른 개발팀에도 많이 쓰고 있는 방법이지만, 듀랑고 개발팀은 이를 '엄격하게' 지키고 있다.
■ 듀랑고 라이브 개발 프로세스
안미루 연구원은 듀랑고가 진행했던 '만우절' 이벤트를 예시로 들어 작업 프로세스를 설명했다. 먼저 아이디어로 글 작가의 그림체를 살린 2D 종이 공룡이 나오기로 결정하고 할 일의 후보를 모았다. 할 일의 후보는 개발팀과 QA팀, 운영팀, 사업팀 등 다양한 출처에서 모이게 된다. 이렇게 할 일들은 작업 관리툴인 JIRA에 등록된다.
이어서는 이렇게 모인 작업들을 검토하는 단계다. 제안된 작업들의 난이도와 작업시간 등을 각 분야의 전문가들이 검토해보고, 이에 대한 피드백이 진행된다. 초기 단계부터 빠르게 전문가들의 피드백이 이뤄지므로, 작업자 역시 초반부터 의견을 제시할 수 있는 기회가 생긴다.
이렇게 검토가 끝난 '할 일'들은 2주마다 정기적으로 열리는 일감 회의에 상정되어 '업데이트 후보'가 된다. 검토가 끝난 할 일들은 다음 업데이트의 '후보'로서 등록된다. 이 '일감 회의'에는 각 직군의 리더와 프로젝트 매니저가 참석해 후보 목록을 체크한다.
일감 회의에서 업데이트 후보들을 훑어보고, 우선순위가 높은 순서대로 정렬한다. 그리고 이번 업데이트에서 가용한 작업력을 공유하고 '작업력 정원'만큼 후보를 채택하게 된다. 여기서 작업력이 상당히 독특한 공식으로 이뤄지는데, 작업력은 가용 인력과 가용 영업일의 곱에 약 50%~80%를 말한다. 예를 들어 원화가 직군에서 3명이 2주일동안 작업할 수 있다면, 3명 x 10일(2주 - 휴일) x 0.8로 계산해 24일이 된다.
예상치 못한 일에 대비한 버퍼로 20%~50%의 작업력은 남겨둔다. 안정성을 고려할 경우에는 50%의 작업력을 남겨두는 경우도 있다. 이렇게 정해진 '후보군'이 다음 업데이트 스펙이 되며, 선정되지 않은 후보군들은 다음 버전의 후보로 미뤄지거나 보류된다.
듀랑고 개발팀은 매 업데이트마다 약 300여 개의 JIRA 작업을 처리하지만, 한 달에 1천 개가 넘는 JIRA 작업이 생기므로 매달 400여 개 정도의 작업은 남겨지게 되는 셈이다. 하고 싶은 게 많다 하더라도, 기용할 수 있는 인력과 시간은 정해져있으므로 생기는 현실적인 부분이라고 할 수 있다.
이렇게 일감 회의를 통해 정해진 결과를 정리하고, 담당자를 배정하면 개발이 시작된다. 또한 JIRA의 WBS 플러그인을 통해 할 일을 구조화해서 팀원들이 볼 수 있으며, 각각의 카테고리도 정해져있어 담당자는 자신의 할 일도 체크할 수 있다. 이후 2주간 개발이 진행되며, 개발 마감 전에는 모든 일감이 '완료' 상태가 되어야 한다. 프로젝트 매니저는 이 과정에서 수시로 문제를 체크하고 문제를 발견하면 해결에 나선다. 그렇게 2주간의 개발 기간 동안 모든 작업이 '완료' 상태로 된다.
개발이 마감되면 해당 버전의 클라이언트를 업데이트용 브랜치로 분리한다. 그리고 더 이상 새로운 작업이 들어오지 않게 작업을 동결하며, 업데이트용 브랜치에서 QA 및 버그만 수정을 진행한다. 업데이트용 브랜치를 분리한 이후에는 바로 다음 버전의 개발이 시작된다. QA 과정과 함께 프로젝트 매니저는 각 작업들에 적힌 유저 변경점들을 취합한다. 이를 모아서 패치노트를 작성하고, 업데이트가 적용된다.
최종적으로 QA까지 마무리된 클라이언트 빌드와 패치노트는 운영팀과 사업팀에 전달된다. 이후 스토어의 검수가 진행되고, 운영팀은 개발팀이 보내준 내용을 참고하여 패치노트를 작성한다. 검수가 끝나면, 유저들에게 새로운 버전의 '듀랑고'가 찾아간다.
■ 개발 프로세스의 개선으로 잡은 '두 마리의 토끼'
이렇듯 듀랑고의 개발 프로세스는 상당한 복잡함을 보여준다. 하지만 개발과 라이브 서비스를 진행하면서 조직은 점점 거대해졌고, 구두로는 관리가 안 되는 차원에 들어온 시점에서는 매우 효과적이었다. 또한 모든 정보의 처리 창구를 JIRA로 일원화하면서 업무 누락과 변경점 누락이 크게 줄었다. 조직 복잡도는 증가했지만 반대로 일하는 오히려 늘어서 생산성이 크게 향상됐다.
여전히 팀에서는 활발한 의사소통이 이뤄졌고, 많은 의견이 교환되는 분위기는 그대로 이어졌다. 다만 업무상 전문화와 분업화가 진행되며 업무상 구획이 명확해지는 형태가 됐다. 이는 프로세스 변경의 효과라기보다는 팀의 규모가 커지면서 발생한 현상이라고 할 수 있다.
대신 단점도 생겼다. 리드타임(일감 의뢰→배포시간, 기민함)은 오히려 늘었다. 할 일의 후보는 일감 회의 전에 디자인이 완료되어 하고, 업데이트 직전에 새로운 일을 추가하기가 난감해졌기 때문이다. 대신 그만큼 안정성이 증가됐다. 물론 핫픽스 해야 할 중요한 일들의 경우는 앞서 언급했던 것처럼 제외한 작업력을 투입하여 해결한다.
물론 반응은 제각각이었다. 일감을 빠르게 정할 수 있던 게임 디자인들의 직군은 자신의 업무가 제외됐다는 아픔이 생겼지만, 반대로 작업을 해야 하는 아트팀이나 개발팀은 지나친 야근으로 이어지지 않게 관리받고 있다는 느낌을 받았다고 한다.
현재 듀랑고 개발팀은 이런 제도를 1년 가까이 안정적으로 시행 중이며, 이러한 개발 프로세스가 지속 가능하다는 형태라는 점을 검증받았다. 물론 현재도 개발 프로세스는 꾸준히 변화하며 유관 부서들도 함께 변화 중이다.
듀랑고는 이러한 개발 프로세스를 도입함으로써, 팀의 장점이던 소통력과 다양한 의견을 교류하는 분위기는 유지하면서 안정성을 얻었다. 자유와 관리, 두 마리의 토끼를 함께 잡게 된 셈이다. 안미루 연구원은 팀마다 문화가 다를 수 있어 직접적으로 대응할 수는 없더라고, 듀랑고팀의 경험을 공유함으로써 부분적으로라도 도움이 되었으면 좋겠다고 전하며 강연을 마무리 지었다.
Lavii@inven.co.kr
페이지 구독하기
다른 기사 보기
기사 제보하기
