노동 착취 상태에서도 게임은 나와요

시작하기 전에 글을 다 써 놓고 다시 돌아와 읽어보니 마치 노동 착취를 일종의 필요악처럼 묘사한 것 같은 느낌이 들었습니다. 하지만 제대로 통제되고 또 의사결정권자가 자신의 의무를 이해하고 이를 수행하고 있다면 비용과 위험을 예측할 수 있고 초과 노동을 최대한 피해 가며 개발할 수 있습니다.

어느 날 타임라인을 훑다가 중국의 어느 대단한 게임과 그 개발사를 언급하며 그 개발사에서 한 해에 게임에 투자하는 엄청난 개발비용을 언급하며 그 정도 규모의 게임과 경쟁해야 하는 한국 게임들은 그저 노동 작취를 반복할 뿐이어서 게임이 나오지조차 않고 나온 게임이라도 그저 그런 뻔한 게임이라는 이야기를 읽었습니다. 나머지 부분에는 모두 동의하지만 노동 착취를 반복하며 게임이 나오지 않으며 이들 사이에 깊은 연관이 있다는 뉘앙스에는 동의할 수 없어 한 마디 말을 하고 말았습니다. 실은 그냥 게임에 집중하고 있었으면 이렇지 않았을텐데 마침 그 날 게임 서버에 문제가 있어 주말 몇 시간에 걸쳐 게임이 안정적으로 실행되지 않았기 때문에 괜한 말을 한 것이었습니다.

업계의 노동 착취 관행은 어제 오늘 이야기가 아니지만 개인적으로는 겉으로 보기에 비슷해 보이는 노동 착취에도 그나마 의미를 찾기가 불가능하지는 않은 사례와 아무리 찾아도 절대로 의미를 찾을 수 없을 사례를 구분할 수는 있다고 생각합니다.

우선 노동 착취가 일어나는 가장 큰 원인은 게임 개발이 여느 소프트웨어 개발과 비슷한 속성을 가지면서도 프로젝트를 시작할 때 요구사항이 확실하지 않아 좁은 범위의 요구사항에 맞춰 개발해 나감에 따라 요구사항이 서서히 드러나며 새롭게 드러난 요구사항에 맞춰 개발하려고 보면 현재의 상태와 잘 맞지 않아 처음부터 같은 요구사항을 개발할 때에 비해 훨씬 높은 비용이 드는데 이 과정에서 개발 인력이 고정되어 있으므로 노동 착취가 일어나게 됩니다. 또 다른 이유에는 소프트웨어의 복잡도를 예측하기 쉽지 않은 점이 있는데 사실 이 부분은 계획 단계에서 어느 정도 예측할 수 있을 지도 모른다고 생각을 서서히 바꿔 가고 있기는 합니다. 하지만 지금 까지는 예측할 엄두를 잘 내지 못하고 있습니다.

특히 온라인 멀티플레이 게임에서는 개발자가 예상한 시스템 사이의 상호작용 뿐 아니라 고객과 세계, 고객과 고객, 고객과 시스템 등 상호작용을 일으킬 수 있는 아주 다양한 요소가 있고 이들 사이를 어느 정도 닫힌 모양으로 설계해 상호작용을 최소화하거나 제한하게 만들어 전체 시스템을 통제하곤 하지만 이는 멀티플레이 온라인 게임의 근본적인 메커닉은 아닙니다. 단순한 안전장치에 가까운 행동들이 게임 전체의 의미를 퇴색시킬 수도 있습니다.

그래서 통제 가능한 범위 안에서 상호작용 가능한 범위를 늘리려고 하는데 이 과정에서 예상하지 못한 상호작용이 일어나 게임의 주요 메커닉의 동작을 망가뜨릴 수 있고 이를 해결하는데 이전에 고려한 적 없는 완전히 새로운 요구사항을 개발해야 할 수 있습니다. 이 경우에도 새로운 요구사항이 생겼음에도 개발팀 크기는 대체로 고정되어 있고 이번 마일스톤에 만들어 내야 하는 기능도 대체로 조정이 어려워 개개인의 초과노동으로 문제를 해결하곤 합니다. 즉 잘 관리되지 않는 개발에서 생기는 여러 가지 문제를 노동 착취라는 가장 간단하고 가깝고 쉬운 방법을 통해 해결하고 있습니다.

그렇다면 노동 착취 상태와 출시 사이에는 무슨 관계가 있을까요. 타임라인에 지나간 글은 노동 착취를 반복할 뿐 게임을 출시하지도 못한다는 뉘앙스가 깔려 있었지만 이런 상태에도 불구하고 게임을 출시하지도 못하거나 런칭에 성공하는 팀 사이에는 큰 차이가 있고 이들을 단지 노동 착취 상태로 묶어서 표현하기에는 어려움이 있습니다.

초과 노동이 만연한 상태에서 게임이 나오지 않는 가장 큰 이유는 자신들이 뭘 만들어야 하는지 팀에 아무도 모르기 때문입니다. 앞에서 게임 프로젝트는 좁은 시야의 요구사항을 개발해 가는 과정에서 다른 요구사항이 서서히 정립되며 이 과정에서 이전의 기반 위에 이전에 고려하지 않은 새로운 요구사항을 개발해야 하기 때문에 비용이 높아진다고 이야기했습니다. 하지만 이런 상황에도 불구하고 요구사항의 필요성을 느끼고 요구사항을 도출해 계획을 수립하고 팀에 이 계획의 필요성을 납득 시킬 수 있다면 팀은 초과 노동에도 불구하고 제품을 완성시킬 수 있습니다.

여러 개발자들이 존경에 마지않는 해외의 최상의 클래스 개발자들도 지독한 초과 노동 끝에 제품을 출시하고 출시 직후 몇 달에 걸쳐 휴직하기도 하며 어떤 팀은 아무도 집에 못 가는 상황에서 정신이 파괴되어 버린 상위 직책자의 기행 덕분에 큰 피해를 겪고 소송에 이르기도 하는 사례가 있습니다. 하지만 이런 무지막지한 상황에도 불구하고 이들은 결국 런칭에 도달해 개발에 참여한 사람들이 상처를 포함하지만 의미 있는 성과를 이룹니다.

반면 요구사항을 도출할 줄 모르거나 의사결정을 미루거나 요구사항을 도출할 수 있을 만한 깊이있는 사고를 할 줄 모르는 누군가가 이 역할을 담당하고 있다면 팀은 아주 쉽게 서로 모든 결정을 서로에게 떠넘기고 서로는 상위 의사결정자의 의중을 ‘예측’해 요구사항을 정의한 다음 개발해 의사결정자에게 이 상태가 맞는지 확인하고 기능을 유지하거나 기능을 제거하는 악순환에 빠지기도 하는데 이 상황에서는 아예 마일스톤 비용 예측이 불가능해져 모든 사람들이 지독한 초과 노동 상태가 되지만 결코 런칭 단계에 도달하지 못하기도 합니다. 아마도 타임라인에 지나간 글이 언급한 상태가 이런 상태를 의미하는 거라고 생각합니다. 어떻게 그런 자격 없는 사람이 프로젝트에 중요한 위치에 존재할 수 있을지 의아해 하는 분들이 계실 수도 있는데 실제로 이런 사례는 이렇지 않은 사례보다 더 많습니다.

정리하면 노동 착취가 반복되는 상태라고 해서 항상 런칭에 도달하지 못하는 것은 아닙니다. 의사결정권자가 자신의 의무를 이해하고 자신의 결정을 팀에 설득할 수 있다면 초과 노동이 유지되는 상황에서도 런칭에 도달할 수 있습니다. 반대로 같은 사람이 자신의 의무를 이해하지 못하거나 의무를 수행할 만한 역량을 가지고 있지 못한 상태라면 때에 따라 이 사람의 의중을 예측해 요구사항을 정의하고 개발하기를 반복하며 자원만 소모한 채 런칭에 도달하지 못할 수 있습니다.

만약 초과 노동 상태이더라도 의사결정권자가 정상적으로 임무를 수행하고 있다면 이 프로젝트에는 신체적, 정신적인 어려움에도 불구하고 조금 더 일해 볼 도박을 할 수 있습니다. 하지만 그렇지 않다면 주머니 속의 버튼을 만지작 거릴 충분한 이유가 됩니다.