게임업에 종사하면서 애자일(Agile)이라는 말을 대표, 본부장, 실장, 팀장 등 다양한 관리자들에게 어떤 형태로든 지속적으로 듣고 지시 받아 왔습니다. 그리고, 요구사항은 "애자일=높은 생산성"으로 귀결되어 집니다.
그렇다면 한번 애자일 선언문을 보겠습니다.
보시다시피, "애자일"은 "높은 생산성"을 보장하지 않습니다. 오히려, 오른쪽에 무게를 더 두어 개발 과정에 "사람"이 있음을 알려주고 있습니다.
그렇기에 "애자일"을 지시 받은 현장에서는 "워터폴"과 "애자일" 어딘가 중간 지점을 선택하는 경우가 있습니다.
우선, 게임 제작 관련 산출물 중 비교적 단계가 단순한 것을 예시로 워터폴,애자일을 비교해보겠습니다.
워터폴 방식의 3D 캐릭터 모델링 공정을 생각해 보겠습니다. (어쩌면 일반적일 수 있는...)
- 기획자가 캐릭터 컨셉 및 설정(동작, 스킬 등)의 세부 문서를 작성 합니다.
- 원화가가 문서를 바탕으로 디자인 합니다.
- 3D모델러가 디자인을 바탕으로 T 자세의 캐릭터를 만듭니다.
- 애니메이터가 설정 문서에 맞춰 동작을 연결 합니다.
- 이펙터가 스킬 등에 VFX를 적용 합니다.
- 문서를 만든 기획자가 3D 모델링을 확인 합니다. (문제가 없다면 여기서 종료 됩니다.)
- 만약, 기획자가 의도한 모델링이 아니거나 기획자의 생각이 바뀌었다면 우리는 어쩌면 서로에게 불편한 감정을 느끼게 될지 모릅니다.
이 공정에 나름의 애자일 방식을 적용한다면,
기획자와 원화가는 대화를 통해 스케치를 얻습니다. 이제 기획자, 원화가는 3D 모델러에게 스케치를 보여주며 두 사람이 생각한 것을 들려줍니다. 이해한 3D모델러는 제작을 시작 합니다. 3D 모델링이 제작되는 동안 기획자는 애니메이터, 이펙터에게 갑니다. 그리고 자신이 생각한 스킬과 동작을 표현(?)하고 제작 동의한 동작을 기록하여 두 사람에게 남깁니다. 3D모델러는 '기획자, 원화가, 애니메이터, 이펙터'에게 자신이 만들고 있는 모델링을 "컨셉, 크기, 스킨 등"을 중간 확인 요청합니다.
이견이 없다면 모델링은 지속 제작되고 완료되면 이해관계자 모두에게 공유 합니다. 마지막으로 애니메이터, 이펙터는 동작과 스킬을 붙이고 그 과정에서 기획자에게 중간 결과를 공유 합니다. 동작과 스킬까지 완료되었고 기획자가 만족했다면 게임 내 배치 합니다.
글의 분량과 상황을 비교했을 때, 워터폴 방식은 문서가 완비되었거나 모두가 동일한 인지를 갖는다면 상당히 빠른 제작을 기대할 수 있습니다. 더불어, 이해관계자 모두는 시작과 종료 일정이 명확하기에 완벽한 계단 모양의 간트를 얻을 수 있습니다. 그러나, 산출물에 대한 중간 의사소통이 적거나 없기에 변수가 생길 경우 이해관계자들은 다음 일정에 영향을 반영해야하는 리스크가 발생 합니다.
애자일 방식을 보겠습니다. 문서 작성을 기다릴 필요는 없습니다. 또한, 지속적 의사소통으로 변수 발생의 가능성도 낮습니다. 그러나, 이해관계자들의 업무 집중도 차이가 있을지언정 동일 시간대에 동일한 일감을 대응하고 있습니다. 시작과 종료일을 명확히 판단할 수 없기에 각 이해관계자의 다음 일정을 쉽게 약속할 수 없습니다.
게임은 사업,운영 측면에서 업데이트 일정과 컨텐츠가 매우 명확하게 결정되어 고정되는 특징을 가지고 있습니다.
그렇기에 개발실은 결정된 결과물과 일정을 지켜야하는 강한 의무를 가지게 됩니다.
우리는 이제 "애자일=높은 생산성"을 지시 받은 상태에서 이해관계자 간의 오해를 줄이고 개발 일정이 지켜질 수 있도록 최선의 선택을 해야 합니다.
Water-Scrum-Fall (Wagile??)
"사업, 운영, 개발" 간 A, B, C의 세 개 내역을 포함하는 업데이트를 준비하기로 결정 했습니다.
A 내역에 대한 기획서가 나왔습니다. Kick-Off 미팅을 시작 합니다. 참여가 필요할 것이라 예상되는 이해관계자를 모으고 회의 과정에서 불필요한 이해관계자는 퇴장 합니다.
이해관계자가 모두 결정되었고 그들은 업데이트 날짜를 엄수해야 하는 긴장감을 가지게 되었습니다. 제작 과정에서 모두가 기획 내용과 의도를 이해해야 합니다. 변수가 발생한다면 일정에 매우 큰 리스크가 될 수 있습니다.
매일 아침 스크럼 회의를 하고 있습니다. 이 과정에서 기획자가 기획서의 실수를 공지 합니다. 내용이 변경되었고 일정에 맞는 최대한의 해결책을 다시 수립합니다. 스프린트 리뷰 역시 진행하였고 다소 아쉽지만 일정 내 결과물이 나왔습니다.
물론, 다른 내역인 B, C에 대한 스크럼도 진행 중 입니다. 이해관계자는 A, B, C간 작업 기간이 겹쳐서는 안됩니다.
우리는 날짜를 지켜야만 했고, 개발 과정 중 오해에 따른 변수도 줄여야 했습니다. 잘 지켜진 것 같습니다.
이 글을 쓰게된 계기는 어느 모임에서 서로가 알고 경험한 "애자일(Agile)"이 미묘하게 달라서 차이점을 찾던 중 수집한 내용을 보관하고자 기재하게 되었습니다. 따라서, 알아가는 과정 중이니 잘못된 정보가 있거나 의견이 있으시다면 언제든지 댓글을 주셨으면 합니다. 감사합니다!
'개발관리(Project Manager) > 보관' 카테고리의 다른 글
| [PM/개발관리] PMO(Project Management office) 도입 (0) | 2022.11.21 |
|---|