게임디자인의 분업이 만들어낸 비 존중

글을 왜 그렇게 길게 써?와 우리는 기계에 대항해 승리할 수 있을까? 같은 질문과 생각을 주고 받은 같은 자리에서 나온ㄴ 이야기 중 하나는 주니어 게임디자이너들이 프로젝트에서 종종 겪는 것처럼 보이는 협업 부서들로부터의 비존중에 대한 이야기입니다. 주니어 디자이너들의 성장을 어떻게 뒷받침할 수 있을지 이야기하다가 제가 즐겨 사용하는 방법을 이야기했는데 여기에는 주니어 디자이너가 겪는 어려움이 포함되어 있었습니다. 이상적으로는 회사 차원에서 입사 초기에 적절한 교육을 제공할 수 있으면 좋겠지만 업계 전체가 지난 오랜 세월에 걸쳐 사실상 교육의 필요성을 완전히 무시했고 개인이 알아서 배우는데 성공하면 이를 당연하게 생각하거나 개인이 이를 무사히 배우는데 실패하면 이를 개인의 성과 문제로 정의하곤 했다고 생각합니다. 새로운 스탭들을 교육할 자원도 의지도 없는 이상 경력을 요구하게 되고 영원히 경력을 쌓을 수 없게 되거나 낮은 허들을 통과해 짧은 경력을 쌓은 다음 소위 중고 신입으로 교육을 제공하지 않는 회사에 재도전 하는 것 같습니다.

중고 신입을 목표로 한 낮은 허들은 종종 커리어에 심각한 문제를 일으키기도 합니다. 개인적으로 업계에는 보이지 않는 임계선이 있는데 겉으로 보기에 다들 비슷한 장소인 판교의 반짝이는 유리 건물에 모여 비슷한 일을 하는 것처럼 보이지만 임계선 아래에서 일하는 사람들은 영원히 임계선 아래에 있는 조직에서만 일할 수 있으며 임계선 위에서 일하는 사람들은 그 위에서 경력을 쌓을 수 있다고 생각합니다. 임계선 위에서 그 아래로 내려가는 것은 쉽지만 임계선 아래에서 그 위로 올라오는 일은 아주 어렵습니다. 보이지 않는 임계선 아래에서 낮은 허들을 전전하다 보면 자신이 해 온 일이 실제보다 더 커 보이고 자신의 경력과 능력이 충분하다고 생각할 수 있지만 이를 임계선 위 관점에서 보면 별로 그렇지 않을 때가 많았습니다. 물론 상대적으로 낮은 허들을 전전하며 생계를 유지해 온 이력에 개인을 문제 삼을 수는 없습니다. 근본적으로 이는 업계 전체가 주니어 디자이너에 대한 교육의 필요성을 완전히 무시해 온 것에 대한 댓가일 뿐입니다.

또한 게임디자이너는 회사 밖에서 역량을 키울 방법을 찾기도 쉽지 않습니다. 가령 엔지니어는 자신의 예상 역할 안에서 토이 프로젝트를 수행해 이를 공개하고 또 다른 사람들이 작성한 다음 공개한 코드를 읽으며 전문성을 키울 수 있습니다. 또 기술적인 이해도가 높기에 상업용 미들웨어의 구성과 핵심 사용 방법을 더 빨리 이해할 수도 있기도 합니다. 아티스트들은 각자의 역할에 맞는 여러 산출물을 인터넷을 통해 쉽게 찾아볼 수 있어 자신의 능력이 업계 전체에서 어느 정도 수준인지 짐작할 수 있고 또 자신의 작업물을 공개해 다른 사람들의 의견을 듣는 문화가 널리 퍼져 있습니다. 이는 엔지니어들의 코드도 마찬가지입니다. 하지만 게임디자이너는 회사 밖에서 이런 기회를 찾기 쉽지 않습니다. 특히 그 스스로 엔지니어나 아티스트에 준하는 스킬을 가지고 있지 않다면 게임디자이너 스스로는 완결된 결과물을 만들어내기 아주 어렵기 때문에 회사 밖에서 전문성을 올리기는 어렵습니다. 특히 게임디자이너는 다른 사람이 작성한 기획서를 입수한다 하더라도 기획서는 단지 문서일 뿐 이 문서를 둘러싼 플레이시나리오와 개발 과정, 개발 결과에 의한 동작하는 빌드 같은 맥락이 완전히 빠져 있어 문서를 읽어 전문성을 얻기는 아주 어렵습니다.

맨 처음 하던 이야기로 돌아가 이런 배경에서 주니어 디자이너는 종종 협업 과정에서 협업 부서에 의한 비존중을 겪기도 합니다. 저는 개인적으로 협업 상황에서 문제해결 방법을 코칭 할 때 일단 문제가 일어난 다음 이를 함께 해결하는 과정을 거치기를 좋아합니다. 본격적으로 업무를 맡기기 전에 여러 기회를 통해 업무가 진행되는 모습을 적당히 체험하게 하겠지만 사실 옆에서 보는 것 만으로는 빨리 배울 수 없다고 생각합니다. 반면 직접 문서를 작성하고 이를 브리핑 하거나 협업 부서와 협의하는 과정을 직접 겪어 보면 자신이 모르는 부분을 빨리 알 수 있고 이를 해결하면서 빠르게 배울 수 있습니다. 그래서 약간 부족해 보이는 아이디어라도 빨리 문서로 만들게 한 다음 문서에 일단 핵심 아이디어가 포함됐고 이 아이디어가 목적에 부합한다고 판단하면 컨펌하고 협업 부서와 사전 협의 과정을 통해 부족한 점을 보강하도록 합니다. 이 때 업무적으로 작은 트러블이 생기면 건너 파티션에서 조용히 들으며 상황을 파악하기만 할 뿐 직접 개입하지 않습니다. 그러다가 스스로 해결할 수 없거나 대답할 수 없는 질문을 받았다고 생각하면 협의를 중단하고 돌아와 저와 함께 이를 보강한 다음 다시 시도하면 됩니다.

협업 부서에서 조금 아픈 이야기를 듣는다 하더라도 그 이야기가 업무에 직접적인 관련이 있고 또 개인을 비난하지 않는다면 파티션 너머에서 이 이야기를 듣고 있지만 그냥 두고 마음 속으로는 ‘미안해요. 좀 있다 돌아오면 설명해줄께요. 미안’ 이라고 말하곤 합니다. 그러나 이야기가 개인에 대한 비난으로 이어질 때가 있는데 그럼 바로 자리에서 일어나 상황에 개입해야 합니다. 이들을 구분하는 선은 너무 아슬아슬해서 판단하기 어려울 수 있고 사람마다 이 선의 위치가 달라 누군가는 이미 마음에 상처를 입기 시작했지만 상대는 이를 전혀 눈치 채지 못할 때도 있습니다. 그래서 적당히 낮은 쪽에 선을 정해 놓고 이를 넘기면 바로 상황을 수습해야 합니다. 우리들 모두는 처음부터 협업 과정에 필요한 모든 사항을 이해하고 또 게임디자인에 대한 큰 그림을 이해하며 시야가 서로 다른 여러 가지 질문을 연달아 들으며 잘 답변할 수 있지 않았습니다. 모두 자신의 시야에 매몰되어 시야 밖의 질문을 받으면 버벅거리는 과정을 거쳐 한 사람의 게임디자이너로 발전했고 또 다른 직군들도 마찬가지입니다. 이 과정이 개인에 대한 비존중으로 이어지는 것은 큰 문제라고 생각하고 즉시 개입해 상황을 정리하고 때에 따라서는 상급자에게 보고해야 할 수도 있습니다.

그럼에도 게임디자이너에 대한 비존중은 신경 쓰지 못하는 사이에 프로젝트 곳곳에서 일어나 주니어 디자이너들의 마음을 다치게 합니다. 마음을 다치면 업무 퍼포먼스에도 영향을 주며 나아가 발전 속도나 발전의 한계에 영향을 끼칠 수도 있습니다. 보다 안전한 환경에서 다양한 시도와 아이디어가 나오는 반면 안전하지 않다고 생각하는 조직에서 사람들은 쉽게 보수적으로 변하며 안전한 범위 안에서 업무를 처리하려 하고 이는 결국 낮은 성과와 낮은 평가로 연결됩니다. 개인적으로 이 상황에 개인의 잘못이 없지는 않겠지만 그리 크지도 않다고 생각합니다. 그런데 이런 주니어 디자이너에 대한 비존중이 게임디자인의 분업으로부터 일어난 것은 아닐까 하는 생각을 해봤습니다.

앞에서 설명한 엔지니어나 아티스트는 그들 스스로 완결된 결과를 만들 능력이 있습니다. 엔지니어는 직접 만져볼 수 있는 빌드를 만들 수 있고 아티스트는 직접 볼 수 있고 나아가 종종 만져볼 수 있는 결과물을 만들어낼 수 있습니다. 게임디자이너는 이들에게 업무를 요청할 권한이 있지만 그 스스로는 협업 요청을 할 수 있을 뿐 독립적으로 완결된 결과를 만들어내기는 쉽지 않습니다. 물론 게임디자이너가 엔지니어들의 스킬을 얕게 배워 이들의 일을 흉내내 결과를 만들 수 있고 이 과정에서 여러 지식을 학습할 수 있습니다. 아티스트의 영역도 마찬가지입니다. 하지만 근본적으로 게임디자이너는 이 각각의 일을 프로페셔널한 수준으로 수행하지는 않기 때문에 완결된 결과를 낼 수 있다 하더라도 그 수준이 분명 훌륭하지는 않을 겁니다. 이런 상황이다 보니 게임디자이너 각각은 협업 상황에서 엔지니어나 아티스트의 지식 수준에 비해 부족한 지식 수준으로 대화에 참여하게 되고 이 때 게임디자이너는 협업 부서 관점에서 지식이 부족해 보일 수밖에 없습니다.

멀티플레이 온라인 게임을 본격적으로 만들기 시작한 초기에는 게임디자이너의 역할을 특별히 구분하지 않았습니다. 그저 기획자는 기획서를 작성하고 이에 근거한 개발이 진행되도록 만드는 일종의 마이크로 PM 역할을 수행하며 협업 부서들로부터 결과가 나오면 이들을 조립해 실제 동작하는 빌드를 자기 손에서 만들어내곤 했습니다. 여기에는 주로 한국식 구분으로 컨텐츠디자인, 시스템디자인, PM, 전투디자인, 밸런스디자인 같은 온갖 분야가 포함되어 있었고 게임디자이너 한 명은 자신이 맡은 한 가지 기능을 위해 각 분야에 관계 없이 기능에 필요한 모든 역할을 수행하기를 요구 받았습니다. 사람에 따라 어떤 역할은 좀 더 잘할 수 있었겠지만 재능이 없는 역할도 있을 수 있었지만 한 사람이 이 과정 모두에 관여하면서 시야를 넓히고 협업 부서와 의사소통이 점점 더 잘 되는 결과로 이어집니다.

반면 한국식 구분으로 게임디자인 직군을 컨텐츠, 시스템, 전투, 밸런스, 경제 등 다양한 분야로 나누고 이들 사이의 역할을 제한함으로써 좀 더 재능이 있는 분야에 집중할 수 있게 됐고 전체적으로 개발 속도가 빨리진 것이 사실입니다. 하지만 이러한 분업에 의해 게임디자이너 각각이 프로젝트 전체를 보는 시야가 좁아졌고 이전에 비해 분업 영역 바깥에서 일어나는 일에 대한 정보를 얻을 기회가 줄어들어 개개인의 발전에 제한이 생겼다고 생각합니다. 가령 던전에 직접 몬스터를 배치하고 기믹을 설치하는 사람은 소위 컨텐츠 디자인 역할을 할텐데 이 사람이 어떤 의도를 가지고 있을 때 이 의도를 가장 잘 달성하려면 이 사람 스스로가 개발 중인 게임의 여러 영역을 이해하고 기술적인 가능성과 한계, 프로젝트 전체로부터 이끌어낼 수 있는 자원의 종류 따위를 이해하고 있어야 합니다. 그러나 분업 환경에서 자신의 역할에 매몰되어 일하다 보면 기술적인 가능성과 한계에 대한 이해가 떨어져 항상 보수적으로 익숙한 기능만을 사용한 결과를 만들거나 때때로 기술적으로 불가능하거나 게임의 핵심을 건드리는 이상한 제안을 하게 됩니다. 협업 부서 입장에서 이런 제안을 들으면 당혹스러울 수 있지만 개인적으로 이는 이 제안을 한 개인의 잘못이 아니라고 생각합니다. 이는 단지 분업 상황에서 시야가 좁아진 결과로 일어난 안타까운 상황일 뿐입니다.

현대에 가까워지며 게임디자인 직군은 좀 강한 분업 환경으로 변해 가고 있습니다. 몬스터 설정하는 사람은 몬스터 설정만 하고 시스템 설계하는 사람은 오직 이 일만 담당합니다. 이렇게 분업 환경을 조성할 수록 소프트웨어를 개발하는 관점에서 일정 예측이 쉬워지고 문제 발생 지점을 예측하기 편해지며 나아가 높은 분들의 ‘이 기능은 언제 완료됨?’ 같은 어려운 질문에 자신 있게 답할 수 있는 장점이 있습니다. 반면 분업 환경에 놓인 개개인의 관점에서는 분업의 결과가 빌드에 적용된 결과를 이해하기 쉽지 않고 자신의 업무 범위 바깥으로 시야를 넓힐 이유도 적으며 그 바깥에 있는 여러 기술적 배경이나 제약에 관심을 가질 이유도 별로 없습니다. 이런 상황에서 게임디자이너는 협업 부서에 황당한 제안을 할 수밖에 없고 이는 직군이나 개인의 문제가 아니라 프로젝트 차원에서 분업 환경에도 불구하고 교육에 의해 차츰 해결해 나가야 하는 상황입니다.

여기에 조금 더 말을 보태면 현대에 여러 직군이 과거에 비해 훨씬 더 강하게 분업화 되어 이에 속해 일하는 개개인의 시야를 좁히고 있는데 지금까지 설명한 바와 같이 이런 상황이 개개인의 전체 개발에 대한 이해도를 낮추고 있습니다. 이상적으로는 프로젝트 차원에서 교육을 통해 해결해 나가야 하지만 그런 이상적인 시나리오는 보통 달성할 수 없기에 게임디자인 내부에서 문제를 완화할 방법 역시 찾아야 합니다. 개인적인 경험 상 팀에서 자기 손으로 직접 완결된 결과를 만들어낼 수 있는 직군은 상대적으로 협업 과정에서 일어나는 비 존중 상황을 덜 겪는 것 같아 보입니다. 직접 완결된 결과를 만들어내는 과정에서 기술적인 이해와 한계 인식이 개선되기 때문이라고 생각합니다. 분업 체계를 설계할 때 구성원 각각의 업무가 스스로 완결된 결과에 도달하도록 구성하거나 개개인에게 문서를 작성하고 데이터를 넣고 또 기믹을 배치하는 수준에서 나아가 이들이 통합된 결과를 직접 만져보고 개선하는 과정을 포함해 시야, 기술 수준 등을 개선하도록 노력해야 합니다.

분업 환경에서 게임디자이너에 대한 비 존중은 분명 있습니다. 이는 효율을 위해 개개인의 발전 보다는 분업에 집중한 결과이기도 하고 또 분업에 집중하면서도 개개인의 역량을 개선할 방법을 찾는데 소홀한 결과이기도 하며 업계 전체적으로는 장기간에 걸쳐 교육을 완전히 포기한 결과이기도 합니다. 결국 이를 개선해 개개인의 역량을 끌어 올려야 장기적으로 프로젝트 또는 회사 수준의 생산성을 올릴 수 있을 겁니다.