[GDC2016] 기민한 공동 개발을 위해 알아야 할 두 가지

게임뉴스 | 이현수 기자 | 댓글: 3개 |
전통적인 게임 개발은 폐쇄된 환경에서 이루어졌다. 그러나 팀의 규모가 커져 팀원이 늘어나고 인접 산업과 연관이 되며 공동개발은 선택이 아닌 필수 사항이 됐다. 공동개발은 개발 패러다임을 완벽히 바꿔놓았다. 그 중 기민한 공동 개발(애자일 기법, Agile software development)이 주목받고 있다.

간단하게 말하자면 재미있는 게임을 만들기 위해 변화를 적극적으로 수용하고 더 많은 대화로 서로 협력하여 문서를 작성하기보다 실제로 작동하는 게임을 만들어 확인하자는 취지다.

공동 개발을 유지하고 진행하기 위해서 두 가지의 핵심 요소가 필요하다. 첫 번째는 완벽한 투명성이고 두 번째는 흐름이다. 25년의 경력을 가진 스타 롱 (Starr long)은 자신의 개발 경험을 바탕으로 공동 개발 시 반드시 숙지해야 할 것들을 소개했다.

스타롱은 '울티마 온라인' 개발에 참여했고 '리처드 개리엇'을 따라 '타불라 라사(Tabula rasa)에 몸을 담기도 했다. 이후 월트 디즈니를 들려 현재는 포탈라리움(Portalarium)의 수석 프로듀서를 역임하고 있다. 그는 '슈라우드 오브 아바타(Shroud of Avatar)'의 작업에 참여했다.



▲ 포탈라리움 스타 롱(Starr long) 수석 프로듀서


투명성, 활발한 의사소통



공동 개발을 진행할 때 매우 중요한 건 바로 '투명성'이다. 투명함은 '신뢰'를 쌓는 기본적인 주춧돌이 되기 때문이다. 기본적으로 게임 개발은 각기 다른 팀과 팀원 그리고 업무가 어우러지는 용광로다. 이 용광로는 신뢰라는 이름으로 주조되는데 이를 만드는 것은 '의사소통'이다. 플레이어 혹은 고객과의 의사소통도 포함해서다.

공동 개발은 체크리스트가 아니다. 일종의 도구다. 모든 팀원은 서로 헌신적이라는 가정 아래 각각 어떤 일을 했고 또 어떤 일을 하지 않았는지 서로에게 분명히 알려야 한다. 서로의 전문 분야 지식으로 이루어진 작업물과 작업 예정물 그리고 드랍시킬 요소들을 한 곳에 모으는 것이다. 그리고 일정에 차질을 주는 애로사항을 공유해야 한다.

전통적인 개발이 작업물이라는 결과에 초점을 맞추었다면 기민한 공동 개발은 사람에 초점을 맞추고 있다. 이는 활발한 의사소통을 전제로 한다.

공동 개발을 꾸려나가는 프로젝트에 소속된 사람들은 포럼과 IRC를 통해 항상 의사소통을 해야 한다. 매일매일 미팅을 하는 것은 기본이다. 의사소통의 대상은 우리 팀의 팀원일 수도, 다른 직무를 맡은 동료일 수도, 플레이어일 수도 있다. 충분한 의사소통은 서로가 해야 할 일, 아이디어 등을 문제없이 공유할 수 있게 해준다.

구성원들은 의사소통을 통해 개발 결과물에 필요한 목록을 작성하고 우선순위에 따라 작업을 시작한다. 당연히 투명성이 전제돼 있는 상태에서만 가능하다. 서로 간의 작업 진척도를 알아 투명성을 제고하며 문제점을 파악하는 작업을 거친다. 개발 도중에 문제점을 파악하여 우선순위에 따라 해결하는 것이다. 이 중에는 의사소통을 하며 얻은 유저 피드백이 존재할 수도 있다.

"사실, 개발자는 자신이 진행하고 있는 작업물의 진척 상황을 거짓으로 말을 할 수도 있다. 나도 그랬고 내 선배, 동료들도 그랬다. 과거와 같이 폐쇄적인 개발 환경에서는 가능할지 모르지만, 오늘날같이 다수의 인원이 프로젝트를 공유하는 상황에서는 어울리지 않는다.

매일 미팅이나 채팅을 통해 서로의 개발 상황을 투명하게 공개하는 것이 신뢰를 확보하는 길이다. 스크린 샷을 넣고 무슨 작업을 했는지, 어떤 스테이터스를 밸런싱 했는지, 어떤 갑옷, 무기, 스킬 등을 작업했는지 세세하고 투명하게 공개하는 자세가 필요하다."

결과물 없는 의사소통은 매우 어려우며 작동하고 있는 게임을 보여주는 것이야말로 고객에게 신뢰를 전달하는 방법이기 때문이다.



▲ 펀딩을 통해 만든 '슈라우드 오브 더 아바타'

작업물뿐만이 아니다. 예산을 집행하는 것도 투명하게 공개해야 한다. 특히 킥스타터 같은 클라우드 펀딩을 이용해 게임을 개발하고 있다면 반드시 투명하게 공개해야 한다. 크라우드 펀딩은 굉장히 많은 투자자로 이루어져 있고 이들은 자신의 권리를 행사하기를 바란다. 일반적인 투자사와 달리 상충하는 의견들이 여기저기서 나오고 부딪히는 과정에서 지치기도 한다. 그렇기에 예산 집행 과정을 올바르게 공개하고 그들의 피드백을 어느 수준까지 포옹할지 언제 작업할지도 같이 공개해야 한다.

롱은 "QA 팀은 예를들어 버그를 발견한다든지, 버그를 발견한다든지, 버그를 발견한다든지, 게임의 치명적인 문제를 발견했다든지 했을 때, 개발진에 빠르고 정확하게 공유하고 개발 파트는 이를 받아들여 수정하는 것 역시 투명함을 토대로 쌓아 올린 신뢰 관계 속에서 더 높은 효율을 보인다."라고 말했다.

또한 그는 "개발진은 플레이어를 좋아하고 플레이어는 우리가 만든 게임을 좋아하고 게임은 우리가 만든다. 이러한 사실을 확실히 인지하고 몇 명이 어떤 일을 하고 있는지 정확히 공개하고 공유해 높은 수준의 신뢰를 쌓아야 한다.

인간은 실수하기 마련이다. 그러므로 서로 간 신뢰를 쌓아서 프로젝트에 지장이 없도록 할 필요가 있다. 예를 들면 '이건 이번에 잘못했는데, 다음에는 이렇게 해볼래?' 혹은 '이건 이렇게 하지 말고 이렇게 바꿔봐' 같은 말로 말이다."라고 신뢰의 중요성을 다시 한 번 강조했다.


리듬감, 단기목표



기민한 공동 개발의 최우선 순위는 가치 있는 게임을 일찍 그리고 지속해서 전달해 고객을 만족하게 하는 것이다. 이를 위해서 개발자들은 유지 보수를 포함한 매일 업데이트, 주간 업데이트, 월간 업데이트 나아가 분기별 대형 업데이트를 고려해야 한다. 롱은 월간 대규모 업데이트가 게임에 가장 잘 어울린다고 말했다.

"일정 주기를 통해 팀에 리듬감을 더할 수 있다. 주기를 통해서 평가하고 다시 계획하는 과정을 반복한다. 2~4주 간격으로 하면 좋다고 생각한다. 게임에 영향을 주는 대규모 업데이트는 4주 정도가 적절하다."

지속적인 결과물을 만드는 것과 동시에 기술적으로도 충분한 탁월함을 유지하기 위해서는 리듬감을 유지해야 한다. 기술적 탁월성과 좋은 설계에 대한 지속적인 결과물의 전달이 민첩함을 높이기 때문이다. 기민함을 중시하는 과정은 지속 가능한 개발을 장려, 요구한다. 일정한 속도를 계속 유지할 수 있어야 한다.

가장 중요한 것은 '무엇'보다는 '언제'가 중요하다는 것이다. 주기가 확실하지 않으면 철야를 하게 될지도 모른다. 그렇게 되면 프로젝트에 연관된 모든 팀은 스트레스를 받을 것이다. 심지어는 가족들에게도 스트레스가 전염될 수 있다. 여자친구가 "자기야 다음 주에 놀러 갈까?"라고 물어왔을 때 "안돼. 우리 진척 상황이 아직 결정된 게 없어서 못 가."라고 대답하게 될 확률이 높아진다.

기민한 공동 개발에서 말하는 리듬감은 단기 목표를 달성하는 방식으로, 단기 목표는 전력질주를 가능케 한다. 장기 목표로만 진행되는 프로젝트는 갈수록 지치기 마련이다.

"데드라인 전 철야, 철야를 했음에도 출시 혹은 업데이트 지연에 따른 비난과 스트레스, 압박으로 인해 출시 혹은 업데이트를 했어도 유저들의 욕구를 충족시키지 못하는 것들이 발생하는데 이는 팀이 리듬감을 유지하지 못했기 때문이다."





결론 의사소통 + 단기목표+ 방향성 체크



과거에는 이전 단계가 완료되어야 다음 단계로 넘어갈 수 있었던 문제가 있었던 것에 반해, 기민한 공동 개발은 이 일련의 과정을 잘게 나누어 여러 번 반복한다. 요구 사항을 수집하고 개발하고 피드백을 받아 다시 요구 사항을 수집하는 순환구조다.

팀 혹은 직군마다 역량은 서로 다르기 마련이다. 하지만 이러한 순환구조에서 단기 목표를 끊임없이 리뷰하고 이를 반복하면 팀의 능력에 맞는 일정 예측이 가능해진다.

팀원들 간의 원활하고 투명한 소통으로 리스크를 지속적으로 제거하고 테스트가 가능한 결과물을 공개해 개발 방향성을 체크하는 과정을 반복하는 것이 핵심이다.



댓글

새로고침
새로고침

기사 목록

1 2 3 4 5