아마추어 게임 개발자의 프로젝트 시행착오 이야기
자! 지금부터 당신이 게임 개발자라고 상상해봐요.
누군가 당신에게 이렇게 물어봐요.
존경하는 선배님, 게임 회사에 들어가기 위해서는 무엇을 준비해야 하나요?
그럼 여러분은 어떻게 대답하겠어요?
실제 게임 개발자 중 열의 아홉은 이렇게 대답한다고 해요.
일단, 게임을 하나 만들어보세요. 가능하면 팀에 들어가거나 팀을 구성해서요.
잠깐! 게임 회사에 들어가려는 사람에게 게임부터 만들어보라니….
이게 무슨 '경력 2년 정도 있는 신입이면 좋겠어요.' 같은 소리냐고요?
사실, 우리나라에서 게임 제작은 게임 회사에 들어가야만 경험할 수 있는 건 아니에요.
고등학교나 대학교에서 게임 제작 동아리를 심심찮게 볼 수 있고 사회에서도 게임 제작 동호회나 게임 제작과 관련한 온라인 커뮤니티 등이 활발하게 운영되고 있어요. 지금 이 순간에도 수많은 아마추어 개발자들이 팀원을 모집하고 게임을 개발하고 있죠. 개발자의 답변은 게임 개발자 지망생들에게 이러한 아마추어 프로젝트를 한번 경험해보라는 의미인 거죠.
자! 그럼 다시 "일단, 게임을 하나 만들어보세요. 가능하면 팀에 들어가거나 팀을 구성해서요."라는 개발자의 답변으로 돌아와 볼까요?
답변에서 '게임을 하나 만들어보세요'라는 말의 의미는 충분히 이해할 수 있어요. 게임 개발자가 되기 위해서 실제로 게임 개발을 체험해보는 것만큼 값진 경험은 없을 테니까요. 그런데 왜 '가능하면 팀에 들어가거나 팀을 구성해서요.'라는 조건을 붙였을까요?
아마추어 게임 개발은 1인으로 할 수도 있고 2인 이상의 팀으로 할 수도 있어요. 하지만 게임 회사에서는 대부분 2인 이상의 개발팀 단위로 개발이 이루어져요. 그래서 팀 단위의 개발을 미리 경험해보라고 하는 거예요. 왜냐하면 팀 단위 개발에서는 혼자서 개발할 때는 상상하지 못했던 무수히 많은 'error'가 발생하거든요….
팀의 규모가 세명인 곳과 백 명인 곳을 동일선상에 놓고 비교하기에는 너무 큰 차이가 있지만, 둘 이상이 되면 팀이 되고 팀이 되면 팀원과의 관계와 의사소통이 중요해지죠. 단순히 내 생각을 실행으로 옮기는 것이 아니라 내 생각을 설명하고 표현하는 과정도 필요해지고요.
그런데 이 과정이 생각보다 피곤하고 힘든 과정이에요. 왜냐하면 사교적인 대화와 작업을 하기 위한 대화는 전혀 다르기 때문이죠. 사교적인 대화는 적당히 상대의 의견을 들어주거나 듣기 싫은 이야기는 어느 정도 한쪽 귀로 흘려버리면서 듣는 시늉만 할 수도 있잖아요. 하지만 함께 게임 개발을 하게 되면 한 번 논의된 결정 사항은 작업 방향에 엄청난 영향을 주고 다시 돌이키기 어렵기 때문에 세심하게 듣고 치열하게 논쟁해야 하죠. 팀 단위로 게임 개발을 하면 많은 부분에서 서로 영향을 받을 수밖에 없어요.
프로젝트가 마냥 순탄하게 개발이 진행된 것은 아니다.
상충하는 의견 때문에 리소스를 어떤 식으로 제작할지 UI(User Interface) 아티스트와 충돌한 적도 있었다. (중략) 이 논쟁은 UI 아티스트의 양보로 몇 시간 만에 마무리되었다. 자신의 의견이 더 좋지만 나의 의견도 맞는 말이고, 논쟁이 길어지면 작업이 진전되지 않을 것을 알기에 먼저 양보를 해준 것이다.
_ 『0년차 게임 개발』 '팀원과 상충된 의견' 중에서
무엇보다 모든 것이 딱 맞는 팀원과 작업한다는 건 비현실적이기 때문에 현실적인 시각을 가지는 훈련도 필요하죠. 우선, 처음 팀에 들어갈 때 혹은 팀의 구성원을 영입할 때, 서로가 원하는 바를 구체적이고 확실하게 논의해야 하죠. 그리고 그렇게 결정된 사항은 프로젝트가 끝날 때까지 변하지 않아야 해요.
예를 들어서, 시작하기 전에는 캐릭터 3개만 만들면 된다고 정해놨는데, 개발이 진행되고 구체화되면서 누군가의 욕심 때문에 "우리 작업 속도도 빠르고 결과물도 괜찮을 것 같은데, 캐릭터는 5개로 늘리고 캐릭터마다 기술도 하나씩 더 추가하고 화려한 날개도 달아서 더 재미있게 만들어보는 건 어떨까…?" 이렇게 요구 조건이 점점 늘어난다면 대부분의 개발자들은 프로젝트가 발전할 가능성보다 아예 엎어질 가능성만 높아진다고 말해요. 특히, 아마추어 개발자 팀에서는 더욱 위험하고요.
그래서 팀이 형성된 초기부터 빠르게 작업에 착수하기보다는 가급적 구체적으로 생각하고 미처 생각하지 못했던 부분에 대해서는 욕심을 버리고 다른 팀원에게 관대해질 필요가 있다고 하죠.
프로젝트 성격과 개발 성향에 따라 조금씩 다를 수는 있지만, 규모가 작고 개발 기간이 짧다면 게임 취향이 같은 사람이 함께 작업하기 좋다. 대부분의 아마추어 게임 개발은 상용화된 게임과 다르게 게임 전체의 규모가 작다. 또한 전체적인 구성을 안정적으로 구현하기보다 핵심적인 콘텐츠만 제작하는 경우가 많다. (중략)
게임의 규모가 클수록 다양한 시각이 필요하다. 서로 다른 관점을 가진 이들이 서로의 다른 의견을 교환하고 고민하면서 게임을 발전시킬 수 있을 것이다. 하지만 서로 다른 시각을 가진 이들은 만들고자 하는 게임에 대해서도 생각이 다를 수밖에 없으므로, 서로를 설득하거나 자신의 생각을 상대에게 이해시키기 위해서 더 많은 노력이 필요하다. 물론 팀원 간의 의사소통은 중요하지만 때로는 그 과정에서 모두 힘들어지고 극단적으로는 인간적인 신뢰를 잃어버릴 수도 있다.
그러므로 개발 기간이 길지 않고 게임의 분량이 크지 않다면 어느 정도 유사한 관점을 가진 이들과 대화가 더 잘 되고, 같은 방향을 지향하게 되므로 서로에 대한 이해도 빨라진다. 이것은 사소한 설득에 들어가는 시간을 줄여줘서 개발 기간이 단축되는 효과를 가져다준다.
_ 『0년차 게임 개발』 '팀 빌딩' 중에서
팀 작업은 말 그대로 팀이 함께하는 작업이죠. 아무리 좋은 실력을 갖추고 있더라도 같이 이야기할 수 없거나, 주장이 너무 강해서 타협할 수 없다면 좋은 팀원이라고 할 수 없으며 많은 이들이 같이 일하고 싶어 하지 않을 거예요. 때로는 고집을 부리는 것이 좋은 결과를 낼 수도 있지만, 때로는 다른 사람들의 의견이 자유롭게 흘러나올 통로를 막을 수도 있거든요.
그렇기 때문에 현직에 있는 개발자들이 게임 개발자 지망생들에게 "팀 단위로 협력해서 게임을 제작해보라."라고 권하는 거예요. 경험해보라는 거죠. 실제 게임 개발에 있어서 '자만심에 가득 찬 천재 개발자'보다 '적당한 실력의 소통할 수 있는 개발자'가 프로젝트를 실패가 아닌 성공으로 이끌 수 있다는 것을요.
박소현(현 3년차 게임 전투 디자이너)
: 아무래도 팀원을 처음 모집할 때 실력이 좋은 사람을 뽑으려는 경향이 있는데요. 저는 아마추어 프로젝트에서만큼은 기대가 비슷한 사람을 뽑을 것 같아요.
아마추어 프로젝트에서는 책임이나 결정권자가 굉장히 모호해요. 그래서 모두가 조금씩 만족하는 결정을 해야 하죠. 그런데 그 합의하는 과정에서 갈등이 굉장히 많이 일어나거든요? 그때, 기획안이나 게임 콘셉트에 진심으로 공감해서 찾아온 사람, 즉 기대가 비슷한 사람을 팀원으로 모집했다면 갈등이 발생할 확률이 현저히 낮았던 것 같아요.
주진영(20년차 게임 디자이너)
: 맞아요. 현업에서도 단순히 기술이 좋은 사람보다는 프로젝트 경험이 있는 사람을 선호하는 경향이 있잖아요. 프로젝트 경험이라는 게 개발 실력이 좋다는 것을 의미하기보다는 팀워크에 대한 중요성, 협의에 대한 필요성을 충분히 알고 있다는 것을 의미하거든요. 그래서 '입사 전에 이런 경험을 해보고 오면 좋겠다.'라는 심정이 반영된 거라고 생각해요.
_ 『0년차 게임 개발』인터뷰 중에서
이상적인 팀은 팀원들끼리 상승효과를 내서 개인의 능력보다 더 좋은 결과를 내는 팀이겠죠. 팀으로 작업하면 게임 개발 과정을 다양한 시각으로 살펴볼 수 있고, 실수를 서로서로 보완해줄 수 있기에 혼자 게임 개발을 할 때보다 약점이 줄어들고 더 좋은 게임을 만들 가능성이 커지니까요. 하지만 이렇게 좋은 결과를 낼 수 있는 팀은 흔하지 않아요. 오히려 개개인의 공헌도가 떨어지는 링겔만 효과가 훨씬 더 일반적인 현상이라고 할 수 있죠.
하지만 그럼에도 팀으로 작업하는 이유는 이상적인 팀이 만들어내는 시너지 때문이죠. 그리고 이상적인 팀이 되는 방법은 너무나도 쉽고 이미 널리 알려져 있기 때문이에요. 바로 서로에 대한 배려! 좋은 팀은 서로에 대한 배려로 만들어지고, 서로에 대한 배려가 있어야만 만들어져요.
그런데…. 지금까지 말씀드린 아마추어 게임 개발자들의 이야기가 비단 게임업계에만 통용되는 이야기일까요? 글쎄요. 저는 잘 모르겠네요!
참고 자료 :