게임디자인 직군의 슬픈 점은 나머지 부서들과 목표가 다르다는데 있다

여러 해 전에 일어난 기획팀의 다른 부서에서 진행하는 회의에 들어가 봅시다. 저는 이미 과거 이 회의에 참여한 적이 있어 이 회의에 무슨 일이 일어나고 또 어떤 결말로 끝날 지 이미 다 알고 있지만 이 글을 읽으시는 분들은 그렇지 않을 테니 여기서 무슨 일이 일어났는지 설명이 필요할 수 있음을 알고 있습니다. 또한 이 업계에서 일해보신 적이 없거나 업계에서 일해 봤지만 제가 여러 프로젝트에 걸쳐 경험해 온 이상한 상황을 겪지 않은 최고의 운을 가지고 계신 분들이라면 이런 회의 자체가 왜 발생하게 되는지에 대한 설명이 필요할 수도 있습니다. 그렇다면 설명은 회의 자체에 대한 이야기보다는 이 회의가 어떻게 존재할 수 있는지에 대한 설명부터 시작하는 것이 좋을 것 같습니다. 그 과정에서 게임 소프트웨어 개발 프로젝트의 요구사항이 기획팀으로부터 출발해 협업 부서에 어떻게 전달되고 또 어떻게 개발되는지 조금 이해할 수 있을 겁니다. 그 이야기를 마친 다음 이 문단의 첫 문장으로 돌아가 과거의 그 시점에 일어난 회의를 살펴보고 그 회의의 어느 부분이 문제였는지, 또 그런 문제가 왜 일어나게 되는지 살펴보고 마지막으로 이 글의 제목에 이미 스포일링 한 결론에 도달해 보려고 합니다. 예상하기에 이야기가 그리 짧고 간단하게 진행되지는 않을 것 같은 점 미리 양해 부탁 드립니다.

저는 처음부터 게임 소프트웨어를 개발하는 프로젝트에서 기획팀에 소속되어 일했기 때문에 다른 소프트웨어 개발 업계가 어떻게 돌아가는지 잘 모릅니다. 다만 종종 다른 업계와 이 업계 사이를 오가곤 하시는 엔지니어님들로부터 말씀을 듣기도 하고 또 다른 업계로부터 이 업계로 넘어오신 엔지니어님들로부터 그 분이 느끼시는 다른 점에 대한 설명을 듣기도 하며 어렴풋이 다른 업계가 어떻게 동작하고 있는지 추측할 수는 있습니다. 또 온라인 상에 보이는 다른 업계의 엔지니어님들의 말씀이나 행동을 살펴보고 그 분들이 어떻게 업무를 진행하고 계실지 추측해볼 수도 있습니다. 그런 과정에서 제가 알게 된 게임 소프트웨어 개발 업계의 특징은 요구사항을 내는 부서가 회사 안, 그것도 같은 프로젝트 안에 수직계열화 되어 있다는 점입니다. 여느 SI 업계에서 소프트웨어를 개발한다면 일단 소프트웨어 발주 자체가 회사 밖, 또는 최소한 회사 내 다른 부서로부터 나옵니다. 회사 밖으로부터 요구사항이 발주된다면 이들을 클라이언트라고 부를 수 있을 것 같은데 이들은 요구사항을 발주하는 주체임과 동시에 소프트웨어를 사용할 고객을 대표하기도 합니다. 이제 우리 모두가 잘 알다시피 고객들은 자신이 무엇을 원하는지 잘 모르고 설사 잘 알고 있다 하더라도 이를 엔지니어에게 잘 설명할 능력이 없기 때문에 이들로부터 나온 요구사항은 이를 잘 정리할 수 있는 능력을 가진 누군가에 의해 주의 깊게 정규화 된 다음 엔지니어 집단이 가지고 있는 역량에 따라 잘 설계되고 또 분배되어 개발되어야만 합니다. 하지만 여러 소프트웨어 개발 회사에는 엔지니어들이 가득할 뿐 그런 역할을 하는 사람이 적거나 없는데 가깝기 때문에 고객의 요구사항 변화에 따라 프로젝트 전체가 요동 치는 일이 흔하게 발생하는 것 같습니다.