게임디자인 직군의 슬픈 점은 나머지 부서들과 목표가 다르다는데 있다
누군가는 이 배가 가라앉을 때 함께 수장될 운명입니다. 하지만 누군가는 그렇지 않습니다. 이 상황에서 어떻게 배를 움직여 목적지에 도달할 수 있을까요?
여러 해 전에 일어난 기획팀의 다른 부서에서 진행하는 회의에 들어가 봅시다. 저는 이미 과거 이 회의에 참여한 적이 있어 이 회의에 무슨 일이 일어나고 또 어떤 결말로 끝날 지 이미 다 알고 있지만 이 글을 읽으시는 분들은 그렇지 않을 테니 여기서 무슨 일이 일어났는지 설명이 필요할 수 있음을 알고 있습니다. 또한 이 업계에서 일해보신 적이 없거나 업계에서 일해 봤지만 제가 여러 프로젝트에 걸쳐 경험해 온 이상한 상황을 겪지 않은 최고의 운을 가지고 계신 분들이라면 이런 회의 자체가 왜 발생하게 되는지에 대한 설명이 필요할 수도 있습니다. 그렇다면 설명은 회의 자체에 대한 이야기보다는 이 회의가 어떻게 존재할 수 있는지에 대한 설명부터 시작하는 것이 좋을 것 같습니다. 그 과정에서 게임 소프트웨어 개발 프로젝트의 요구사항이 기획팀으로부터 출발해 협업 부서에 어떻게 전달되고 또 어떻게 개발되는지 조금 이해할 수 있을 겁니다. 그 이야기를 마친 다음 이 문단의 첫 문장으로 돌아가 과거의 그 시점에 일어난 회의를 살펴보고 그 회의의 어느 부분이 문제였는지, 또 그런 문제가 왜 일어나게 되는지 살펴보고 마지막으로 이 글의 제목에 이미 스포일링 한 결론에 도달해 보려고 합니다. 예상하기에 이야기가 그리 짧고 간단하게 진행되지는 않을 것 같은 점 미리 양해 부탁 드립니다.
저는 처음부터 게임 소프트웨어를 개발하는 프로젝트에서 기획팀에 소속되어 일했기 때문에 다른 소프트웨어 개발 업계가 어떻게 돌아가는지 잘 모릅니다. 다만 종종 다른 업계와 이 업계 사이를 오가곤 하시는 엔지니어님들로부터 말씀을 듣기도 하고 또 다른 업계로부터 이 업계로 넘어오신 엔지니어님들로부터 그 분이 느끼시는 다른 점에 대한 설명을 듣기도 하며 어렴풋이 다른 업계가 어떻게 동작하고 있는지 추측할 수는 있습니다. 또 온라인 상에 보이는 다른 업계의 엔지니어님들의 말씀이나 행동을 살펴보고 그 분들이 어떻게 업무를 진행하고 계실지 추측해볼 수도 있습니다. 그런 과정에서 제가 알게 된 게임 소프트웨어 개발 업계의 특징은 요구사항을 내는 부서가 회사 안, 그것도 같은 프로젝트 안에 수직계열화 되어 있다는 점입니다. 여느 SI 업계에서 소프트웨어를 개발한다면 일단 소프트웨어 발주 자체가 회사 밖, 또는 최소한 회사 내 다른 부서로부터 나옵니다. 회사 밖으로부터 요구사항이 발주된다면 이들을 클라이언트라고 부를 수 있을 것 같은데 이들은 요구사항을 발주하는 주체임과 동시에 소프트웨어를 사용할 고객을 대표하기도 합니다. 이제 우리 모두가 잘 알다시피 고객들은 자신이 무엇을 원하는지 잘 모르고 설사 잘 알고 있다 하더라도 이를 엔지니어에게 잘 설명할 능력이 없기 때문에 이들로부터 나온 요구사항은 이를 잘 정리할 수 있는 능력을 가진 누군가에 의해 주의 깊게 정규화 된 다음 엔지니어 집단이 가지고 있는 역량에 따라 잘 설계되고 또 분배되어 개발되어야만 합니다. 하지만 여러 소프트웨어 개발 회사에는 엔지니어들이 가득할 뿐 그런 역할을 하는 사람이 적거나 없는데 가깝기 때문에 고객의 요구사항 변화에 따라 프로젝트 전체가 요동 치는 일이 흔하게 발생하는 것 같습니다.
가령 세계에서 가장 복잡한 소프트웨어가 미국 헬스케어 관리 시스템이라거나 국내 유명한 소프트웨어 개발사에 발주한 행정 전산망 소프트웨어가 서비스 시작 날짜에 서비스를 시작했지만 온전히 개발되지 않아 온갖 문제를 일으켜 이 시스템을 통해 실제 업무를 처리해야 하는 사람들, 그리고 이 서비스에 의해 행정 서비스를 제공 받아야 하는 사람들을 심각한 궁지에 몰아넣기도 했습니다. 또 어떤 은행의 차세대 전산 시스템 개발 사업은 엔지니어 커뮤니티에서 극도로 열악한 업무 환경으로 악명이 높았는데 심지어 이 프로젝트에 참여한 어떤 분은 지속되는 초과근무 때문에 신체에 영구적인 손상을 입은 것으로 알려졌습니다. 이런 엔지니어 커뮤니티를 통해 조금씩 드러난 어떤 은행의 차세대 전산 시스템은 작은 전문가 집단으로부터 요구사항이 발생하고 이를 엔지니어 개개인, 엔지니어 집단 등에 분산해 할당할 수 있는 일종의 모듈 단위로 구분해 설계하고 각각의 모듈마다 정확히 지정된 입력과 정확히 지정된 출력 조건이 명시되어 있으며 각각의 모듈 개발에 할당된 엔지니어는 이 모듈의 실제 동작이나 이 모듈이 포함되어 동작할 소프트웨어 또는 서비스의 맥락에 전혀 신경 쓰지 않고 모듈 자체의 입출력에만 집중해 개발할 수 있었을 것으로 보입니다. 이론적으로 작은 전문가 집단으로부터 도출된 수많은 모듈 단위로 구성된 요구사항들은 게임 소프트웨어를 개발할 때 기획팀에서 도출한 기획서와 속성이 어느 정도 비슷하기는 하지만 상대적으로 은행 전산망 소프트웨어 쪽이 훨씬 전문적인 관점에서 모듈화 되어 있고 각각의 모듈이 매우 명시적인 요구사항에 기반해 서술되어 있다는 점이 다를 거라고 예상합니다. 하지만 이런 설계를 도출할 역량이 있는 전문가 집단이라 하더라도 이들이 전체 시스템의 여러 사용자들을 대변할 만한 경험이나 지식을 가지고 있지는 않기에 그들이 전문적인 분야에 대해서는 올바른 요구사항을 도출할 수 있지만 그들이 전문성을 결코 가지기 어려운 대 고객 서비스 같은 부분에서는 어처구니 없는 경험을 아무렇지도 않게 만들어내곤 합니다.
여러 게임 프로젝트에는 기획팀 또는 이와 비슷한 이름의 부서가 프로젝트 단위에 수직계열화 된 경우가 많은데 이들의 이름이 ‘기획’으로 상당히 모호한 측면이 있지만 소프트웨어 개발 관점에서 이들은 요구사항을 제시하는 역할을 할 뿐 아니라 어느 정도 요구사항에 바탕을 둔 소프트웨어 설계 역할을 하며 동시에 그들 스스로가 어느 정도 고객의 페르소나를 연기하는 역할을 수행하는 여느 소프트웨어 개발 프로젝트에서 쉽게 찾아보기 어려운 임무를 맡고 있습니다. 이들이 생산하는 문서인 소위 ‘기획서’는 전통적인 소프트웨어 설계 관점에서 모호한 요구사항으로 가득 차 있을 가능성이 높은데 가장 큰 이유는 이 문서를 생산한 소위 ‘기획자’들은 소프트웨어 설계와 개발에 전문성을 가지고 있지 않을 가능성이 높기 때문입니다. 이들 중 일부는 컴퓨터사이언스를 전공했을 가능성도 있고 또 이들 중 일부는 직업 개발자로부터 전직했을 가능성도 있지만 그렇다 하더라도 ‘기획팀’에 속한 이들로부터 전통적인 소프트웨어 개발 관점에서 요구사항의 도출 및 이에 기반한 공학적으로 의미 있는 설계가 도출될 것을 기대하기는 어렵습니다. 또한 이들은 종종 고객의 페르소나 역할을 대신하는데 업계 초창기에는 이 역할을 직접 코드를 작성할 역량이 있는 엔지니어 자기 자신이 담당하기도 했습니다. 하지만 소프트웨어의 규모와 복잡도가 증가하며 엔지니어 스스로가 코드를 작성할 뿐 아니라 동시에 고객의 페르소나를 연기하며 요구사항을 도출하고 기초적인 설계를 함께 제시할 수는 없었기 때문에 초창기 업계를 창조한 엔지니어들은 선택을 할 수밖에 없었습니다. 현대 관점에서 기획자가 되거나, 아니면 엔지니어 역할을 유지한 채 전문적으로 기획 역할을 할 다른 사람을 고용해 함께 일해야 했고 세계에는 서로 다른 선택을 한 여러 가지 사례가 나타나게 됩니다.
아주 널리 알려진 사례를 짧게 짚고 넘어가면 책 둠의 창조자들을 읽은 이야기를 하며 가장 중요한 역할을 한 두 명의 존에 대해 각각 존에게 진 빚, 왜 존은 실패할 수밖에 없었나를 통해 설명했습니다. 한 존은 그 스스로가 한 장르와 업계를 창조한 엔지니어였는데 어느 순간 그 스스로가 엔지니어 역할과 동시에 게임디자인 역할을 함께 수행할 수 없다는 사실을 깨닫고 팀에 레벨디자이너들을 채용합니다. 그 결과 현대적인 관점의 게임디자인에는 많이 모자라지만 그 당시에는 기술적인 완성도를 자랑할 뿐 아니라 대단히 독특한 플레이 경험을 주는 퀘이크 시리즈를 만들어낼 수 있었습니다. 다른 한 존은 그 스스로가 엔지니어이기는 했지만 시간이 지나며 엔지니어 역할보다는 레벨디자이너 역할을 더 많이 수행했고 시간이 흐르자 현대적인 게임 디렉터 혹은 경영진의 역할을 더 많이 하게 됩니다. 두 번째 존 역시 초창기 장르를 창조할 때 그 당시 기술 수준을 감안할 때 천재적이라고밖에 생각할 수 없는 다양한 특징을 가진 레벨디자인을 창조했고 이는 이후 포탈 시리즈 같은 게임에 의한 도약을 이루기 전까지 수많은 게임에 의해 답습될 정도였습니다. 하지만 이 존은 그가 자신의 프로젝트를 시작할 때 여전히 자신이 엔지니어라고 생각한 나머지 근본적으로 자신이 하고 있는 일이 소프트웨어 개발이라는 사실을 망각했다고 생각합니다. 그의 조직에서 게임디자이너야말로 요구사항을 도출하는 가장 근원적인 역할을 하고 또한 그들 스스로가 고객의 페르소나 그 자체인 나머지 그 역할에 몰입해 그들 스스로의 요구사항을 뒷받침할 기술적 기반, 그리고 이를 개발할 엔지니어 집단 구축에 소홀했습니다. 첫 번째 존이 비록 게임디자인 관점에서는 여러 모로 아쉬움이 남는 퀘이크 시리즈의 게임 세 개를 출시해 적어도 엔지니어링 관점에서는 의미 있는 성과를 달성하는 사이에 두 번째 존은 당시로는 엄청난 돈을 쓰고서도 초라한 결과를 내고 말았습니다.
이런 사건으로부터 20년 이상 흐른 서기 2024년 현대 한국에 있는 여러 게임 소프트웨어 프로젝트들은 이런 실수로부터 교훈을 얻어 소프트웨어의 요구사항을 도출하는 역할을 하는 기획팀을 별도로 두고 또 이들이 생산한 기획서에 근거해 실제 소프트웨어를 개발하고 또 이에 필요한 에셋을 생산하는 각각의 팀을 같은 프로젝트 내에 수직계열화 한 구조를 채택합니다. 다만 이 과정에서 각자의 서로에 대한 이해도가 떨어지는 결과를 초래했습니다. 소위 기획팀 또는 기획자들로 불리는 집단은 그들이 소프트웨어 개발 관점에서 요구사항을 도출하고 이를 엔지니어링 관점의 설계 모양으로 도출하는 역할을 해야 했지만 이들은 과거에 비해 소프트웨어 엔지니어링 역량이 떨어지는 사람들로 구성되어 요구사항을 도출할 수는 있지만 이를 올바른 설계 모양으로 도출하는 능력은 현저히 떨어지거나 사실상 없다고 보는 것이 맞습니다. 또한 주로 영화 산업으로부터 시작된 핵심 요구사항을 내는 디렉터라는 별도의 직함을 가진 개인을 도입하기 시작하면서 이 디렉터로부터 나온 핵심 요구사항을 어느 정도 현실적인 모양으로 일종의 정규화를 거친 요구사항 모양으로 해석하는 역할로 변해 오면서 기획자 또는 기획팀의 요구사항 도출 능력은 계속해서 상대적으로 감소하는 추세입니다. 엔지니어들 역시 비슷한 문제를 겪고 있는데 과거 이들은 스스로 코드를 쓰고 스스로 문제를 해결할 수 있는 능력을 가지고 있음과 동시에 그들 스스로가 자기 자신이 개발하는 소프트웨어의 핵심 고객이었기 때문에 게임디자인에 대한 이해가 대단히 높았습니다. 특히 이들은 자기 자신이 소프트웨어를 개발할 역량을 갖추고 있음과 동시에 자기 자신이 고객으로써 페르소나 그 자체였기 때문에 요구사항에 대한 의구심을 가질 여지가 없었습니다. 고객과 엔지니어가 같은 뇌를 공유하며 살고 있었기에 이들은 같은 뇌 안에서 전자기파가 흐르는 속도로 의사소통 할 수 있었고 여기에는 이해할 수 없는 게임디자인이나 이해할 수 없는 설계, 그리고 이해할 수 없는 구현이 끼어들 여지가 전혀 없습니다.
일단 현대의 기획팀은 요구사항을 기획서라는 문서 모양으로 도출하는 역할을 하지만 핵심 요구사항은 이들로부터 나오지 않는 경우가 대부분입니다. 그래서 기획팀 구성원들 스스로가 고객으로써 페르소나를 가지지 못하는 경우가 대부분입니다. 앞서 영화 산업으로부터 단 한 명의 개인이 프로젝트의 핵심 요구사항을 제시하는 역할을 하는 소위 디렉터라는 역할을 별도로 하는 모양을 게임 소프트웨어 개발에도 가져왔다고 말했는데 영화 산업과 같이 이 단 한 명의 페르소나에 모든 것을 걸고 이를 요구사항으로 만들어내는 과정을 통해 일관성 있는 소프트웨어를 개발한 사례가 없지는 않았지만 대부분은 여러 가지 이유로 잘 동작하지 않았습니다. 개인적으로 가장 큰 이유는 디렉터라는 고객의 페르소나 역할을 할 단 한 명의 개인이 프로젝트 팀 전체에 걸쳐 올바르게 동작하기 위해서는 그에 걸맞는 지위를 부여해야만 합니다. 그렇지 않으면 고객의 페르소나를 부여한 단 한 명의 개인이 만들어낸 여러 요구사항에 의문을 가지는 사람들이 생기고 이에 대응하는 과정에서 결코 무시할 수 없는 비효율이 발생하기 때문입니다. 그래서 디렉터 직군이 올바르게 동작하기 위해서는 이 직군을 가진 개인이 프로젝트 내에서 다른 거의 대부분의 구성원들보다 조직도 상 더 높은 위치에 있어야 합니다. 이 사실이 디렉터가 나머지 모든 사람들의 관리 또는 인사 권한을 가져야 함을 의미하지는 않습니다. 하지만 최소한 서열 또는 계급에 명시적인 차이가 있지 않은 이상 핵심 요구사항을 도출하는 고객의 페르소나를 연기하는 개인은 프로젝트 전체를 움직이는데 커다란 오버헤드를 그 스스로 감내해야만 합니다. 이런 현실에도 불구하고 여전히 회사는 디렉터를 통제하고 싶은 욕망을 버릴 수 없었기에 과거 삼팀장 체제를 유지하면서도 그 중 기획팀을 담당하는 중간관리자에게 디렉터 역할을 겸임하게 함으로써 디렉터가 존재하지만 디렉터가 디렉터로써 역할을 하는데 필요한 어떤 권한도 부여하지 않는 경우가 대부분입니다.
그래서 디렉터로부터 나온 핵심 요구사항은 프로젝트 전체에 영향을 끼치지 못하고 기껏해야 그가 실제로 권한을 행사할 수 있는 기획팀에만 영향을 끼치며 기획팀은 디렉터 또는 기획팀 중간관리자의 관리 권한 혹은 인사 권한에 의해 지배되기에 나머지 부서에 비해 훨씬 잘 통제된 채 기획서를 생산할 수 있습니다. 이 과정에서 기획팀 구성원들 역시 핵심 요구사항에 의문을 가질 수 있고 또 이런 모습이 자연스럽지만 만약 일을 빨리 진행 시켜야만 하는 상황이라면 디렉터는 의문을 가진 기획팀 구성원들의 인사권을 가진 사람으로써 그 의문에 대한 설명을 생략하고 일단 진행하도록 요구할 수 있는데 이 때 기획팀의 각 구성원은 이 요구를 거절할 수 없습니다. 그렇게 기획팀은 요구사항을 기입한 기획서를 생산하지만 이 기획서는 여러 측면에서 이상한 모양이 되기 쉽습니다. 먼저 앞서 설명한 대로 이들은 소프트웨어 엔지니어링에 전문성이 부족하거나 없는 경우가 대부분이기에 이들이 기획서 모양으로 생산한 요구사항은 기술적인 한계에 무지한 모양이거나 기 구축된 코드베이스를 무시한 형태이거나 프로젝트 팀에 부여된 한정된 자원을 초과하는 모양일 수 있습니다. 또한 팀에 디렉터 직군이 존재하지만 전통적인 삼팀장 체제를 버리지 못해 디렉터가 단지 기획팀에만 영향력을 행사하는 수준으로 권한이 통제되어 있을 때 디렉터 자신은 오직 자신이 통제 권한을 가진 기획팀만을 인사 권한에 기반해 제어할 수 있는 수준으로만 설득하면 되기 때문에 기획팀으로부터 도출된 요구사항은 나머지 협업 부서를 설득하기에는 놀랄 정도로 부적절할 수도 있습니다. 게다가 디렉터 직군으로부터 인사권한에 의한 통제를 받아 충분한 설득과 이에 기반한 자신감 없이 작성된 요구사항은 이를 작성한 기획자 스스로가 이 요구사항을 도출한 고객의 페르소나를 연기할 수 없고 또 연기하려고 시도하지도 않았기 때문에 협업 부서로부터 나올 수밖에 없는 아주 작은 질문에도 답할 수 없는 상태일 때가 많습니다.
여기까지 따라오셨다면 이제 게임 소프트웨어 개발 프로젝트에서 매 마일스톤 초반에 주로 일어나는 기획서 하나 단위로 정리된 요구사항을 협업 부서에 공유하고 또 설명하며 이에 기반한 질의응답을 하고 또 개발 방향을 결정하고 마지막으로 개발 진행을 위한 액션 플랜을 도출하는 회의가 열리는 회의실에 저와 함께 들어가 저는 이미 결과를 알고 있는 회의를 저와 함께 참관해 봅시다. 오늘 이야기할 요구사항을 도출한 분은 기획팀의 한 주니어님입니다. 이 분이 기획팀 내에서 한 경험을 잠깐 설명하면 핵심 요구사항은 디렉터, 그러니까 이 분의 직속 상관으로부터 나옵니다. 주니어님은 아직 이 요구사항이 함께 동작할 게임 소프트웨어 전체의 동작을 조망할 만한 역량을 갖추지는 않은 상태여서 상사로부터 전달 받은 요구사항을 자신의 게임 플레이 경험에 녹인 적당한 수준의 요구사항을 작성한 문서를 생산합니다. 이 문서는 직속 상사의 소위 컨펌 과정을 거치는데 지금까지 이야기를 따라오신 분이라면 이 컨펌 과정이 좀 이상하다는 생각을 하실 수도 있지만 이는 이상하지 않습니다. 요구사항은 주니어님의 직속 상관으로부터 나왔으며 주니어님은 단지 그 요구사항을 문서로 만들었을 뿐입니다. 그런데 그 문서를 다시 요구사항을 낸 바로 그 사람에게 컨펌 받아야 하는 상황입니다. 이는 마치 웹사이트를 셀프 사이닝 한 인증서를 통해 서비스하면서 사실 보안 상 별 문제가 없다고 주장하는 것과 다르지 않습니다. 정작 이 컨펌 과정은 요구사항 자체의 올바름을 평가하기 보다는 요구사항을 기입한 문서 자체의 형식이나 기획자에게는 역량이 거의 없다고 여러 차례 설명한 소프트웨어 엔지니어링 관점의 설계 방식 따위에 주로 머무르며 요구사항의 올바름, 요구사항이 기 구축된 코드베이스나 기 구축된 빌드에 녹아들어 동작하는 상황에 대한 검토는 상대적으로 잘 이뤄지지 않습니다.
이론 소위 ‘컨펌’ 과정을 거친 기획서는 마치 전통적인 폭포수 모양의 개발 방식에서 문서를 다루는 것과 비슷한 방식으로 다뤄집니다. 그러니까 일단 기획팀 주니어님 입장에서 컨펌된 문서는 이제 무슨 일이 있어도 이대로 개발 되어야만 하며 그 자신에게는 이 요구사항의 일부 또는 상당부분을 변경할 권한이 없습니다. 회의에는 기획서를 작성한 주니어님, 그의 상급자, 여러 협업 부서들로부터 온 온갖 높은 분들로 가득한데 여기서 가장 서열이 낮고 또 가장 권한이 없는 사람이 바로 기획서를 작성한 주니어님 본인입니다. 이런 상황에서 회의가 시작되는데 놀랍게도 회의는 이전 그 회의는 왜 망했을까에서 언급한 분명 문서를 읽어오라고 말했지만 그 누구도 문서를 읽고 오지 않았기에 한글을 읽을 수 있는 한국어 구사자들이 가득한 회사에서도 프로젝터에 문서를 띄워 놓고 앞에서부터 읽어 내려가는 낭독회를 해야만 합니다. 그러는 사이 중간 중간 협업 부서들로부터 질문이 들어오는데 이 질문의 90% 정도는 미리 문서를 읽어 봤다면 나오지 않을 만한 질문이지만 이들은 자신들이 그런 질문을 하는 순간 문서를 읽고 오지 않았다는 사실을 자백하는 것이나 다름 없다는 사실조차 알지 못하며 나머지 사람들 역시 똑같은 상황이기에 그 질문에 답하는 주니어님 자기 자신을 제외하고는 아무도 그들 모두가 아직 물이 차 있는 수영장에서 맨몸으로 수영하고 있다는 사실을 인지하지 못합니다. 그저 문서에 이미 설명한 내용에 대한 질문에 답하는데 상당한 시간을 소모한 다음에는 이 요구사항이 왜 우리 게임에 필요한지 설명하기를 요구 받습니다. 사실 이는 이 요구사항을 처음 제안한 주니어님의 직속 상관에 의해 답변 되어야 합니다. 물론 직속 상관으로부터 설명을 들은 주니어님이 답변할 수도 있지만 요구사항의 필요성은 이 요구사항의 신뢰를 구축하는 가장 근본적인 질문 중 하나로 이 질문에 주니어님이 올바르게 답한다 하더라도 신뢰가 구축되기는 쉽지 않습니다. 하지만 이 중요한 상황에서 지금까지 만나본 대부분의 상관들은 입을 다물고 주니어님이 답하며 이는 예상대로 신뢰를 구축하는데 실패합니다.
그 다음으로 기획팀 구성원이 자신들의 부족한 소프트웨어 엔지니어링 지식에도 불구하고 어떻게든 다른 사람들이 이미 작성한 문서를 흉내내 억지로 도출한 설계를 제안하는데 당연히 이 설계는 그저 제안 수준일 뿐 이 모양으로 만들어 달라는 의미가 아니며 이미 엔지니어들 역시 그 사실을 잘 알고 있습니다. 회의에 참여한 협업 부서 구성원들은 브리핑을 통해 요구사항을 인식하고 이를 개발할 수 있는 방법을 그들 자신의 전문성에 기반해 도출해야 하는 의무를 가지고 있습니다. 하지만 회의실에 모인 사람들은 현대에 대부분의 소프트웨어 개발에 더이상 폭포수 모델이 유효하지 않다는 사실을 잘 알고 있으면서도 마치 기획서를 폭포수 모델에 기반해 다뤄야 할 것처럼 기획서를 통해 제안된 설계의 글자 하나하나까지 문제를 제기하며 시간을 보냅니다. 데이터구조가 마음에 안 들고 기존 데이터구조와 일관성이 없으며 네이밍이 잘못됐고 이 모양으로 만들면 온라인 멀티플레이 환경에서 동작하지 않을 위험이 있으며 또 이 모양으로 만들면 기존 코드베이스와 잘 통합되지 않아 개발비용이 높을 뿐 아니라 다른 더 나은 방법이 있는데 왜 이런 방법을 선택했는지에 대한 설명을 요구 받기까지 합니다. 물론 상황 상 이런 질문이 나올 수 없지 않으며 이런 질문을 해서는 안된다는 규칙도 없고 그런 질문을 한다고 해서 인사상 불이익을 받을 일도 없습니다. 하지만 회의의 목적과 회의에 참여한 사람들이 해야 할 역할로 미루어 이런 질문은 각 협업 부서의 중간관리자들이 기획팀의 주니어님에게 할만한 질문은 전혀 아니라고 생각합니다. 이들이 이 회의실에 모인 이유는 일단 요구사항의 필요성을 납득한 다음에는 그들 각자의 전문성을 발휘해 기획팀에서 극도로 부족한 전문성에 기반해 제안한 설계를 보고 이를 그대로 적용하거나 분노에 찬 날 선 질문을 통해 설계의 잘못됨을 지적하는 대신 우리 코드베이스에 어울리는 더 나은 설계를 제시하고 온라인 멀티플레이 환경에서 더 안전하게 동작할 방법을 제안하며 우리 상황에 어울리는 에셋 구성과 생산 계획을 역으로 제안하는 것입니다.
하지만 이런 회의를 가만 놔둔 채 개입하지 않고 있으면 협업 부서로부터 모인 사람들은 기획팀 주니어님의 멘탈이 원자 단위로 부서져 조금만 더 하면 핵분열을 통한 푸른 빛이 회의실을 뒤덮기 직전이 될 때까지 분노에 찬 날 선 질문을 계속합니다. 앞서 현대에는 더이상 소프트웨어를 폭포수 모양으로 개발하지 않게 됐지만 다들 기획서를 폭포수 모양으로 다루는 것처럼 행동한다고 했는데 여기에는 기획팀 주니어님 스스로가 요구사항의 일부분이나 상당부분을 변경할 권한이 없다는 점 역시 상황을 악화시키는 요소로 동작합니다. 만약 누군가가 다른 사람들과는 달리 좀 덜 격앙된 어조와 좀 더 협조적인 자세로 비슷한 결과를 도출할 수 있는 다른 방식을 제안한다 하더라도 주니어님은 이 제안을 받아들여야 하는지 그러지 말아야 하는지 즉시 판단하거나 판단 자체를 해도 되는지 자체를 판단할 수 없을 수 있습니다. 이미 기획서는 폭포수 모양의 개발에 따를 대상으로 간주되고 있어 기획서에 기입된 요구사항의 어느 한 부분이라도 수정하려면 기획서 전체가 다시 기획팀으로 돌아가 주니어님의 수정과 관리자의 컨펌 과정을 거친 다음 처음부터 회의를 다시 진행해야만 할 것 같은 상황이 됩니다. 사실 전혀 그럴 필요가 없으며 적당한 판단을 할 수 있고 또 적당한 권한을 행사할 수 있는 누군가가 빠르게 개입해 상황을 통제하고 올바른 제안을 수용해 그 자리에서 기획서에 언급되지 않았지만 요구사항을 수정하고 또 그 자리에서 제안된 더 나을 가능성이 있는 설계를 받아들이는 역할 및 결정을 수행해야 합니다. 이 때 기획팀의 중간관리자가 아무 일도 하지 않고 가만히 있으면 결국 주니어님의 멘탈이 원자 미만으로 쪼개지며 일어난 핵분열로 인해 모든 사람들이 고선량 방사능에 피폭되어 제 발로 회의실 밖으로 걸어 나갈 수도 없어야 공정하겠지만 실제로는 오직 주니어님의 멘탈만이 그런 파괴적인 변화를 겪고 오늘 나온 ‘의견’을 반영하여 다시 회의하자는 결론으로 회의가 끝나기 일쑤입니다.
이제 이 글 전체의 맨 첫 문장에 설명한 과거로 돌아가 회의를 살펴보았습니다. 밤 늦게 슬슬 일을 마무리하고 아직 지하철이 다닐 시간이어서 벚꽃이 가득 핀 판교 택시 언덕을 걸어 내려가며 그 계절의 차가운 밤공기를 들이마시다가 문득 제 앞에 고개를 숙인 채 힘없이 걸어 퇴근하고 있는 어떤 사람을 봤고 이내 그 사람이 아까 회의실에서 멘탈에 핵분열을 일으켜 고선량 방사능에 스스로 파괴된 바로 그 주니어님이라는 사실을 깨달았습니다. 그저 벚꽃을 보며 마음을 가라앉히고 또 차가운 공기를 들이마시며 홀로 역까지 걸어가는 시간을 즐길 수도 있었겠지만 그래서는 안될 것 같았습니다. 조용히 그 분의 옆에 서서 인사하고 아까 브리핑 때 모두에게 보였지만 아무도 읽지 않은 그 기획서는 직속 상관의 컨펌을 거쳤음에도 아쉬운 부분이 가득했지만 주니어님들이 작성하시는 문서 특유의 각이 잘 잡힌 모양이 인상적이었습니다. 시간이 흐를수록 문서를 각 잡고 잘 작성하기 보다는 협업 부서에 의사를 전달할 수 있으면 되는 수준으로 대강 작성하게 되는데 그럴수록 문서는 점점 더 인상적이지 않은 모양으로 바뀌어 가기 마련이고 제가 작성한 문서도 이런 변화를 피할 수 없었기에 만약 내용을 상관하지 않고 살펴본다면 주니어님의 문서가 압도적으로 훌륭합니다. 함께 천천히 판교 택시 언덕을 걸어 내려오며 그 각 잡힌 문서의 훌륭함, 협업 부서들이 질문에 이유 없는 분노를 표출하는 모습의 부당함, 저 역시 기획팀 소속이면서도 부서가 달라 상황을 이해했지만 함부로 개입하지 못했음에 대한 미안함 따위를 말했는데 이는 어쩌면 그 주니어님이 아니라 그 상황을 보고 체렌코프 현상을 일으킬 정도는 아니지만 함께 상처를 받은 저 자신에 대한 위로일지로 몰랐습니다. 참고로 이 주니어님은 이후 그런 고통을 오래도록 겪었지만 결국 이 분의 능력을 펼치기에 완벽한 위치로 이직해 정말 최고의 역량을 보이고 있습니다.
초안 기준으로 여기까지 약 1만2천글자 정도 진행했는데 이제 제목의 주제를 한번 생각해볼 때입니다. 저 역시 그 주니어님과 비슷한 경험을 수없이 겪었습니다. 저는 제 자신이 소프트웨어 엔지니어링에 전문성이 전혀 없다는 사실을 너무나 잘 알고 있었습니다. 때문에 제가 제안하는 요구사항에 포함된 설계는 그저 요구사항을 전달하는데 사용될 보조 자료일 뿐 이들 모두는 프로젝트에 수직계열화된 각 분야의 전문가들에 의해 재작성 및 재설계 되어야 한다고 생각했습니다. 하지만 실상은 전혀 그렇지 않았고 이들은 마치 기획서를 폭포수 모델의 그것처럼 다루려고 했으며 그렇게 다루려 할 때 요구사항에 온갖 문제가 있기에 이를 받아들여 재설계하기보다는 기획서 전체를 거절하고 아무 역할을 하지 않으려는 모습을 훨씬 더 자주 보여 왔습니다. 그러면 기획팀의 누군가는 그리 규모가 크지도 않은 작은 기능 하나를 고쳐서 컨펌 받고 브리핑하고 또 고쳐서 컨펌 받고 브리핑하는 똑같은, 그리고 완전히 무의미하며 무책임한 과정을 반복해서 겪어야만 했는데 어떤 프로젝트에서는 이런 과정이 원래 기획이 어렵기 때문이라는 말로 설명하려 했지만 개인적으로는 납득할 수가 없었습니다. 프로젝트에는 게임 소프트웨어 개발에 필요한 각 분야의 전문가들을 수직계열화 하고 있기에 이들의 전문성을 활용해 서로가 부족하지만 임무를 달성하는데 필요한 역량을 서로로부터 자유롭게 가져다 사용할 수 있습니다. 그래야만 합니다. 그래야만 프로젝트가 올바른 시점에 완성되고 출시되어 고객들에게 의미 있는 경험을 제시하고 또 운이 좋다면 회사에 의미 있는 경제적 성과를 만들어낼 수도 있을 겁니다. 하지만 똑같은 회의를 반복하며 기획팀 주니어님의 멘탈을 원자 단위 미만으로 쪼개는 짓을 반복해서는 그런 목표에 도달할 수가 없습니다.
그런 사실을 과연 협업 부서 사람들이 모르는 것일까요? 사실 그렇지는 않습니다. 이들도 프로젝트가 올바른 시점에 개발되어 출시해 고객들에게 전달되어야만 한다는 사실을 모르지는 않습니다. 그런 경력이 자신의 이력서에 조금이라도 더 나은 평가를 만들어준다는 사실 역시 모르지 않습니다. 다만 직군에 따라 게임 소프트웨어 개발 프로젝트에 참여하면서도 이러한 목표에 좀 더 강하게 얽매여 있는 직군과 그렇지 않은 직군이 있다는 사실에 기반해 이들의 행동을 해석할 여지가 있습니다. 먼저 엔지니어 직군들 중의 상당수에게 게임 소프트웨어 개발은 이들이 선택할 수 있는 다양한 개발 영역 중 하나일 뿐입니다. 이들은 자신의 스페셜리티에 따라 앞서 잠깐 언급한 무슨 은행의 대규모 차세대 시스템 개발에 참여할 수도 있고 미국 헬스케어 시스템을 개발하는데 참여할 수도 있습니다. 또 국내에 널리 알려진 소프트웨어 개발 회사에서 서울 시내를 가로지르는 도시고속도로의 신호연동시스템을 개발하는데 참여할 수도 있고 또 한때 힙한 분야로 여겨지던 가상화폐 개발 분야로 옮겨 갈 수도 있습니다. 이들에게 중요한 것은 코드를 작성하고 그 단위 기능이 동작하는 모습, 여기에 사용된 기술과 자신의 설계일 뿐 이들이 합쳐져 게임 소프트웨어로 완결성 있게 동작하는 모습이 그렇게까지 중요하지 않습니다. 아트 직군 역시 마찬가지입니다. 이들에게는 대부분 프로젝트 런칭 경험이 중요하지 않습니다. 이들을 채용할 때는 그저 포트폴리오를 보고 우리들이 요구와 포트폴리오가 얼마나 일치하는지를 주로 따질 뿐입니다. 그래서 프로젝트가 서서히 무너져 내리기 시작할 때 회사나 업계에서 일어나는 일에 별 관심을 가지지 않더라도 이 상황을 눈치 채기 가장 쉬운 방법은 갑자기 아무 이유 없이 게임의 아트 에셋 퀄리티가 급격히 좋아지는 것입니다. 이는 게임이 잘 개발되고 있다는 신호가 아니라 다들 업무 시간에 각자의 포트폴리오를 구축하고 있다는 의미입니다.
반면 게임디자이너의 경력은 프로젝트의 런칭에 강하게 얽혀 있습니다. 우리들은 프로젝트의 성공 여부에 관계 없이 제출할 코드도 없고 이 코드를 설명할 기술적 기반도 없습니다. 또한 우리들은 프로젝트의 런칭 여부에 관계 없이 제출할 멋진 원화나 모델, 애니메이션, 이펙트도 없습니다. 우리들이 제출할 수 있는 것은 기껏해야 요구사항을 기입한 문서, 이 문서에 의해 개발된 엑셀 데이터시트 뭉치 정도일 뿐인데 이들은 코드나 에셋과 달리 동작하는 게임의 맥락에 기반해서만 설명할 수 있기 때문에 이를 보는 채용 담당자에게 아무런 감흥도 주지 못합니다. 만약 프로젝트가 공개되어 합법적으로 제출할 수 있는 영상이 있다면 그 영상에 기반해 자신의 역할과 역량을 설명할 수 있을지도 모릅니다. 하지만 이런 상황이라면 이미 이력서에 기입된 런칭에 성공한 프로젝트 이름만으로도 높은 평가를 받기 때문에 굳이 영상을 포함한 귀찮은 설명을 할 필요조차 없습니다. 하지만 프로젝트가 공개되지 않았고 공개 이전에 이직 하려 하거나 프로젝트가 중단된 다음 이직 하려 한다면 게임디자이너가 보일 수 있는 것은 맥락을 파악하기 아주 어려운 문서 뭉치밖에 없습니다. 때문에 게임디자이너들은 업계에서 살아남기 위해 프로젝트가 최소한 공개, 런칭, 고객에 의한 평가, 경제적인 성과 달성 같은 더 큰 목표에 강하게 집착해야만 합니다.
이미 저와 함께 멘탈이 원자 단위 혹은 그 미만으로 쪼개지는 경험을 했던 회의실에 지금까지의 설명을 읽은 다음 다시 한 번 들어가 각자의 행동을 살펴봅시다. 기획서를 생산한 주니어 디자이너는 그리 선명하게 인지하지 못하고 있을 수도 있지만 자신의 다음 프로젝트와 다음 연봉이 이 프로젝트의 성과에 달려 있음이 변하지 않습니다. 때문에 어떻게든 회의를 통해 기획서의 요구사항을 개발 시키려고 안간힘을 쓰고 있습니다. 그래서 소프트웨어 엔지니어링에 압도적인 전문성을 가진 사람들의 지적에도 꿋꿋하게 버티며 자기 생각을 설명하려고 노력합니다. 또한 에셋 구성이나 구조가 우리 프로젝트에 구축된 아트 파이프라인과 일치하지 않거나 심지어 작업자들의 마음에 들지 않는다는 이유로 날 선 질문을 가장한 분노 표출에도 마땅히 대응할 수 없습니다. 혹시 그런 행동을 부당하다고 판단해 대응했다가 개발 시작이 늦춰지면 가장 큰 타격을 입는 것은 게임디자이너 자기 자신이기 때문입니다. 그래서 게임디자이너는 같은 상황에서 어떻게든 개발이 시작되기를, 진행되기를 바라는 방향으로 매달릴 수밖에 없습니다. 하지만 같은 상황에서 다른 직군 사람들은 상대적으로 프로젝트 완수에 자신들의 다음 직장이나 다음 연봉이 덜 얽혀 있기에 거의 부담을 느끼지 않고 기획서를 폭포수 모델의 그것처럼 다루고 압도적인 전문성을 가지고 있음에도 이를 사용해 전체 개발을 진행 시키기 위해 불쌍한 기획팀 주니어님을 돕는 대신 날 선 질문으로 그의 멘탈을 박살내는데 주로 동참합니다. 이런 일이 빈번히 일어나는 이유는 회의실에 모인 같은 프로젝트에 참여하는 사람들이라도 직군에 따라 서로 의도하는 바가 다르고 목표하는 바가 다르기 때문이며 이 상황에서 가장 취약한 것이 바로 게임디자이너이기 때문입니다.
게임디자인 직군의 슬픈 점은 나머지 부서들과 목표가 다르다는데 있습니다. 우리들은 이번 프로젝트에서 아무리 열심히 일하고 아무리 좋은 평가를 받으며 아무리 좋은 결과들을 생산한다 하더라도 프로젝트가 완수되어 런칭되고 공개되며 고객들에게 의도한 경험을 전달하는 수준에 도달하지 않는 이상 우리들이 여기서 몇 년에 걸쳐 한 고생은 완전히 아무런 의미 없는 일이 되고 맙니다. 때문에 모든 협업 부서와 하는 논의나 협의에서 항상 불리한 위치를 차지할 수밖에 없습니다. 게임디자인 직군을 제외한 나머지 직군은 프로젝트의 런칭이 이들의 다음 직장, 다음 프로젝트, 다음 연봉에 큰 영향을 끼치지 않습니다. 하지만 우리들은 그렇지 않습니다. 때문에 게임디자인 직군은 프로젝트 구성원 전체 중 가장 취약한 위치에 놓일 수밖에 없습니다. 이제 제가 직접, 제가 참여한, 이 글을 읽으시고 또 여기까지 따라오신 게임디자인 직군인 분들이 왜 협업 부서들과 회의할 때 그토록 고통스러운 상황을 항상 겪을 수밖에 없었는지 조금은 이해하실 수 있을 겁니다. 슬프지만 다시 말하면 이 상황은 앞으로 명백히 개선될 여지가 없다는 점 역시 납득할 수 있을 겁니다. 슬프지만 이것이 현실입니다.
물론 이렇게 암울한 현실만 있는 것은 아닙니다. 개인적으로 게임디자인 직군의 이런 취약성을 개선하고 적어도 제가 영향을 미칠 수 있는 단위 조직 안에서는 이런 취약점에 기인한 문제가 일어나지 않게 만들기 위해 꽤 오랫동안 고민해 왔고 또 행동을 통해 실험해 왔고 개인적으로는 적당한 수준의 결론에 도달했다고 생각합니다. 다음에 언젠가 기회가 닿는다면 이 개인적인 결론과 이에 기반한 행동 방법에 대해 설명해 보는 것도 재미 있을 것 같습니다. 하지만 오늘은 이미 초안 기준으로 이 자리까지 1만 6천글자나 끌어 온 관계로 그런 이야기는 다음으로 미루겠습니다. 대신 게임 소프트웨어 개발 프로젝트에서 왜 게임디자인 직군이 그토록 취약한지, 왜 항상 그 모든 회의에서 가장 곤란한 입장이 될 수밖에 없는지 살펴보았습니다. 이것이 제가 생각하는 우리 직군의 가장 슬픈 점입니다.
이번 69호에도 지난 2주간 공유한 이야기를 함께 보내 드립니다.
Woojin Kim
Woojin Kim
Woojin Kim
Woojin Kim
한창 더웠던 올(2024년) 초여름 느긋하게 가자 끄트머리에 너무 힘들어 보여 곧 떠날 것처럼 보이는 동네 친구 한 마리 이야기를 했습니다. 그리고 시간이 조금 흐른 다음 그 회의는 왜 망했을까 뒷 부분에 몇 주 만에 그 친구를 다시 만났을 때 정말 대견스럽게도 아픈 상태를 스스로 이겨내고 이전보다는 덜 아픈 모습으로 마주쳐 반갑기도 하고 또 기쁘기도 했습니다. 그리고 이제 밤 기온이 영하 한참 아래로 내려간 추운 겨울이 찾아온 어느 날 밤 집에 돌아오다가 정말 오랜만에 이 친구를 다시 만났습니다.
사실 처음에는 긴가민가 했고 또 말끔한 모습에 혹시 제가 초여름에 마주친 그 친구는 이미 떠나고 그 친구의 다음 세대가 아닐까 하는 생각을 잠깐 했습니다만, 서로 얼굴을 마주하고 눈을 마주친 채 한동안 바라본 끝에 제가 초여름에 만났던 그 친구가 맞다는 사실을 깨달았습니다. 덥고 거친 여름을 건너 또 다른 거친 겨울에 무사히 도달한 동네 친구에게 기쁜 얼굴을 바라보였습니다. 이 친구는 물끄러미 저를 바라보다가 이내 주차장의 차들 밑으로 사라졌습니다. 문득 저 자신은 올 한해 동안을 잘 건너왔을지 스스로에게 물어봅니다. 아마도 올해가 가기 전에 그 답변을 글로 만들어봐야 하지 않을까 싶었습니다.
춥고 건조한 나날이 계속됩니다. 건강에 유의하시고 또 2주 뒤에 뵙겠습니다.
