추석 연휴를 맞이하니 비로소 블로그에 글을 쓸 수 있는 짬이 났다.
거의 일년간 글을 쓸 시간이 없었다. 게임제작이 마무리 되나 싶었는데 결국 결론은 이대론 승산없다! 였으니. 최후의 리뉴얼을 결정하고 스튜디오의 게임 개발 구조를 완전히 갈아 엎었다. 기획-프로그램-그래픽으로 삼분되어 독립적으로 움직였던 스튜디오 개발 구조를 모두 작업 단위별로 TFT(TaskForce Team) 조직화 해서 게임에 대한 전면적인 리뉴얼을 진행중이다(일종의 스크럼 scrum 이라고 볼 수도 있을거 같다).
TFT단위의 개발 조직은 NC소프트 아이온 개발팀에서도 채택하고 있는 방식으로 알고 있는데,
우리 스튜디오에서의 TFT는 작업과 관련된 모든 인원(기획자, 프로그래머, 디자이너)를 한 그룹으로 묶고, 의사 결정에 있어서의 상하관계를 최대한 배제시켜서 자유롭게 의견을 낼 수 있게 하며, 작업에 있어서의 상당부분의 결정 권한을 실무 작업자들에게 쥐어주는 성격의 것이다.
즉 디렉터가 제시한 개괄적인 개발 방향 속에서, 작업 실무자들이 최대한 자율권을 갖고 스스로 결정하며 개발을 진행하는 구조다.
그전의 개발 구조는 전형적인 기획팀 - 프로그램팀 - 그래픽팀의 분리상태에서의 작업 진행이었다. 기획팀에서 기획 초안을 만들고, 수차례의 반복되는 회의를 통해서 최종안을 만든다. 그리고 프로그램팀과 그래픽팀은 최종안에 따라 작업을 진행하는 방식이다. 뭐 가장 일반적인 개발 방법이라고도 볼수 있겠지만 이것에는 분명 문제가 있다는 것을 경험했다.
기존 방식의 첫번째 문제는 여러번의 회의를 거쳐야 하므로 시간이 정말 오래 걸린다. 초안 문서 만들고 회의, 문서 수정하고 회의, 게다가 회의 참가하는 사람들의 머릿수가 많아질수록 점점 회의에 소모되는 시간이 많아진다. 지나치게 길어지는 회의로 인한 업무 시간의 낭비에 대해서는 궂이 설명이 필요치 않을 거다.
두번째 문제로, 이런 분리구조에서는 프로그램팀과 그래픽팀 개발자들의 열정이 점점 줄어든다. 게임을 만들어 나가는 데에 대한 모든 주도권이 기획팀에게 있으므로 프로그래머들이나 디자이너들은 기획팀에서 요구하는 기능과 리소스를 제작하는데만 충실하면 게임이 완성될 것이라 생각하고 점점 수동적인 입장으로 변해간다(일반적으로 그렇다).
이런 상황에 기획팀의 역량이 훌륭하다면 문제가 안될수도 있겠지만, 만약 기획팀에서의 결과물의 완성도가 떨어져서 많은 수정을 필요로 한다면? 변경 요청이 잦아질수록 프로그래머들이나 디자이너들 모두 상당히 스트레스를 받기 마련이다. 만들어 달라는 대로 만들어 줬는데 계속 변경요청이 들어오기 시작하면 점점 더 기획자에 대한 신뢰가 떨어지게 되는데, 이런 분리 구조에서는 기획자에 대한 신뢰가 곧 생명이기에 더욱 더 큰 문제가 된다. 제작하고 있는 게임이 성공해야만 더 나은 미래가 보장되는 게임 개발자에게 자신이 만들고 있는 게임에 대한 성공의 키를 잡고 있는 기획자를 믿지 못하게 된다면? 결과야 뻔하지 않겠나.
그런데 게임 개발중 시스템에 대한 수정, 변경 작업은 어찌 보면 필연적일 수 밖에 없다. 재미의 구현을 위해 필연적으로 수차례의 수정작업은 불가피하기 때문이다. 이런 측면에서 보면 일반적인 작업 프로세스에서의 기획팀과 다른팀간의 묵시적인 주-종관계는 그 자체로 갈등상황을 유발시킬 수 밖에 없는 구조라고 볼 수 있다.
TFT형태로 작업과 관계된 모든 인원들을 한 그룹으로 묶어서 작업을 진행하게 되면, 이런 수정작업에 대한 거부감이 많이 줄어드는 효과가 있다.
또한 TFT 방식의 개발에서 놀라운 점은 그동안 게임의 문제라고 누누히 지적되었으나 시간관계상 수정될 수 없었던 부분에 대한 수정작업이 엄청나게 빠른 속도로 고쳐지고 있다는 거다. 팀장, 실장들의 판단과 결정에 따라서 수동적으로 일을 할당 받아서 진행할 수 밖에 없었던 작업자들에게 어느정도의 자유가 부여되자, 스스로 문제를 해결하고 경우에 따라서는 가이드라인에서는 벗어났지만 더 나은 대안을 도출하는 경우도 있었다.
무엇이든 마찬가지겠지만 이런 TFT 단위의 게임 개발 구조의 단점도 있다. TFT의 자율적인 결정이 디렉터의 생각과 일치하면 좋지만, 일치하지 않는 경우에는 게임이 산으로 갈 가능성도 있다. 여러 TFT 간의 작업 진행 상황에 대한 조율이 제대로 되지 않는 경우 역시 게임이 시스템 단위로 따로 노는 상황도 발생할 수 있을거 같다.
각 TFT간 개발 상황에 대한 전체 팀원들에 대한 공유를 얼마나 잘할 수 있느냐도 중요한 문제다. TFT는 실무자들간의 즉각적인 의사소통을 우선시 하므로 개발 내용에 대한 문서화에 상대적으로 소홀해 지는 경향이 있기 때문에 작업 내용 공유에 있어서는 약간 취약한 면이 있는것 같다.
어찌됐든 내가 몸담고 있는 프로젝트는 현재 기존 개발 구조를 벗어 던지고 TFT 구조로 개발을 진행중이고, 그 결과는 조만간 나올 예정이니 곧 이 개발 방법론의 효율을 직접 알수 있을 것 같다.
