게임업계 뒷이야기 - 잘못된 애자일의 결과

- 고민 없는 실험정신은 최악의 길 -

 

오늘은 좀 큰 주제라 길게 얘기해보고자 한다. 요즘은 좀 덜한 감이 있지만 업계를 한 번 휩 쓸고 간 애자일(※)의 돌풍으로 인해 발생하였고 발생 중인 다양한 실수에 대한 이야기이다.
업계에서 나름 네임 밸류가 있던 모 PD는 예전부터 게임 개발보다 속칭 R&D라고 하는 연구 개발 쪽에 큰 관심이 있었는데, 그런 그에게 있어 새로운 개발·관리 형태로 주목받던 애자일 방법론은 매우 구미가 당기는 방식이었다.

예측과 다른 상황이 자주 발생하는 게임 개발에 있어 실시간으로 서로 소통하는 것을 중시하는 애자일에 큰 흥미를 가진 그는 신규 프로젝트를 진행할 때 꽉 짜여진 계획을 잡고 진행하는 기존의 폭포수 모델이 아니라 상시 팀원들끼리 의견을 나누면서 진행하는 애자일 형태로 프로젝트를 진행하기로 했는데, 이 과정에서 실제 게임을 개발할 사람들의 성향을 고려하지 않았으며 이것이 이후 큰 비극을 가져왔다.

애자일 도입을 결정함에 따라, 그 구체적인 형태로 아침마다 모든 팀원이 모여 현재 각자의 작업 현황을 돌아가면서 보고하는 아침 회의와 함께 기존의 팀장 - 팀원으로 구성된 수직구조가 아닌 수평적인 조직 구조를 짜게 되었다. (물론 수평적인 구조에서 PD 자신은 예외.)

 

아무튼 우여곡절 끝에 시작된 새로운 개발은 초반에는 큰 문제가 없는 듯 진행되었지만, 시간이 지나고 조직이 커지면서 예상대로 다양한 문제가 발생하였다.

아침 회의의 경우, 프로젝트 초기에는 구성원 전원이 팀장급의 큰 의욕을 가지고 자나 깨나 프로젝트의 성공을 생각하는 사람들로 구성되었고, 하루가 다르게 빠른 개발이 진행되던 초기에는 회의 시간도 오래 걸리지 않았으며 정보 교환도 나름대로 의미가 있었지만, 사람이 늘어나고 대규모 작업 위주가 되는 중반으로 넘어가면서부터 문제가 심각해졌다. 

반응형

회의 자체에 소비되는 시간이 늘어난 것은 물론, 다른 파트와 연동하여 작업하는 사람이 아니거나 당장 자신과 관련된 시급한 이슈가 없는 팀원의 경우 아침 회의 내내 스마트폰만 들여다보고 있다가 자기 차례가 되면 언제나 똑같은 내용을 짧게 발표하는 식으로 회의가 점점 형식적인 형태로 변해가고 있었고, 시간이 갈수록 회의를 진행 중인 PD를 제외한 모든 사람이 아침 회의에 부정적인 생각을 가지게 되었다.

수평적인 조직 구조 역시, 초반에는 자유롭게 의견을 주고받는 형태가 될 것으로 PD는 기대 했지만 역시나 의견을 내거나 의욕적인 사람은 정해져 있는데다가, 수동적으로 움직이는 팀원이 늘어남에 따라 구성원 내의 의욕과 실력의 격차가 갈수록 커졌다.

자연스럽게, 누가 보더라도 전체 또는 각 파트를 리드하여 조율할 사람과 실제 실무에 집중할 사람이 실질적으로 나뉘게 되었지만, 포지션의 상하가 없어져 지시가 불가능한 구조이다 보니 전반적으로 매우 비효율적인 상황이 되었으며 팀 내에 이를 악용하는 사람까지 발생하는 등 부작용은 계속 커져갔다.

결국 프로젝트는 초기 계획의 3배가 넘는 시간을 소비하였음에도 진행이 지지부진한 상황이 되면서 결국 외부로부터 압박이 들어오게 되었고, 이와 함께 내부로부터의 반발도 본격적으로 표면화되어 결과적으로 PD는 자리에서 물러나게 되었고 아침 회의는 폐지되었으며 각 파트마다 책임을 질 팀장들이 선임되었다.

다행히 이후 프로젝트는 매우 순조롭게 진행되고 되었다.

초가집을 만들 때와 고층 건물을 만들 때 필요한 노하우와 개발 방식이 다르며 개발 중의 상황에 따라 적합한 적용 및 대응이 필요한데, 내부 구성원들이 전부 백전노장의 실력자들이 아니고 초급자부터 중급자까지 다양하게 섞여있는 상황에서 고민 없이 무작정 도입해 버린 애자일 방법론은 무책임 그 자체라고 밖에 볼 수 없다.

 

주변을 보면 진지한 고민 없이 새로운 기술이나 방법론이 나오면 무작정 적용해보고자 하는 성향의 개발자나 관리자가 가끔 보이는 것이 안타까울 뿐이며, 가급적 실제 적용하기 전에 왜 그런 방식이 현장에서 지금까지 쓰이지 않았는지와 함께 현재 조직에 과연 그것이 유용하게 적용될 것인지를 꼭 생각해봤으면 한다.

---

* 애자일(agile) 소프트웨어 개발 방법론'의 준말. 한때 IT 소프트웨어 및 게임업계 등에서 큰 화제와 다양한 적용시도가 있었던 개념으로, 무계획적 개발과 철저한 스케줄링 개발의 절충점을 취하며 유동적이고 소규모 · 수평적인 개발을 지향한다. 공산품 개발과는 달리 개발 작업의 예측이 힘들고 불완전하며 돌발 상황이 속출하는 소프트웨어 개발 특유의 문제를 제어해가며 '우수'한 소프트웨어를 신속하면서도 효율적으로 개발하기 위해 제창되었던 방법,

세계 레벨의 S급 개발자만 모여 있다는 밸브 같은 회사에서도 애자일이 그리 매끄럽게 돌아가는 건 아니라고 하더군요