지속 가능한 크런치?

크런치 후 장기휴가에 대한 토픽이 타임라인을 스쳐 지나가는 모습을 보았습니다. ‘에휴’ 하고 그냥 스쳐 지나가게 뒀지만 한편으로 긍정적인 관점으로 바라보는 분들이 있다는 사실을 알게 되었습니다. 그래서 타임라인이 좀 흘러가게 둔 다음 시간이 지나 몇몇 분들의 긍정적인 관점처럼 지속 가능한 크런치의 가능성에 대해 생각해 보기로 했습니다.

2022년 현재 한 주에 최대 52시간까지 일할 수 있습니다. 이 시간 제한을 완화하거나 시간을 제한하는 단위 기간인 ‘한 주’의 길이를 늘리려는 시도가 있어 왔다는 것을 유명 정치인들의 발언을 보도하는 매체를 통해 전해 들은 적이 있습니다. 극도로 노동 집약적인 업무를 단기간에 수행해야 하는 상황에서 노동시간을 탄력적으로 조정하면 최상의 성과를 낼 수 있으리라는 의견이라고 인식했습니다. 회사에서 일하는 이유는 돈을 벌기 위해서이고 회사가 우리들에게 돈을 주려면 그들이 돈을 벌어야 하며 그러려면 성과를 내야 합니다. 최상의 성과를 위한 방법 중 하나로 이런 방법이 거론된다는 사실 자체는 문제가 아닙니다.

개인적으로 이 의견에 현실성이 없다고 생각합니다. 먼저 현대 게임 프로젝트에는 ‘완료’라는 개념이 없습니다. 게임 프로젝트는 프로젝트 피칭과 펀딩으로 시작해 개발 과정을 거쳐 런칭하게 됩니다. 몇 십 년 전에는 골드 마스터를 프레스 공장에 넘기고 나면 더 이상 할 수 없는 일이 없었으니 그 동안 쉴 수도 있었다고 전해집니다. 하지만 현대에는 런칭 이후에도 서비스를 종료할 때까지 계속해서 이벤트를 집행하고 컨텐츠를 추가하는 등의 서비스를 해야 합니다. 런칭 후 라이브 서비스에는 여전히 개발 과정만큼 많은 노동력이 필요합니다. 오히려 개발 과정에서는 이전의 실수나 예측 실패를 만회하기 위한 방법을 비교적 자유롭게 고안할 수 있었지만 라이브를 시작하면 이전의 실수를 만회하기 위한 방법을 고안할 여지가 크게 줄어들어 난이도가 높아집니다. 또한 문제를 해결하는데 사용할 수 있는 시간이 크게 줄어들어 런칭 전보다 노동 강도가 올라갑니다.

일주일에 한 번 업데이트 하는 모바일 게임을 생각해 봅시다. 매주 목요일 새벽 모두가 잠든 시간에 업데이트가 시작되어 오전 아홉 시 정도에 끝납니다. 팀의 일부는 업데이트 동향을 파악하고 업데이트로부터 발생하는 심각한 문제가 있지는 않은지 모니터링을 시작합니다. 팀의 나머지는 다음 주 목요일 새벽에 실행될 업데이트를 준비합니다. 업데이트 계획은 이미 꽤 오래 전부터 수립 되어 있지만 앞으로 5근무일 안에 실행할 계획은 이 시점부터 수립해야 합니다. 퍼블리셔의 마케팅 부서와 다음 주 이벤트, 컨텐츠 업데이트, 시스템 업데이트 계획을 논의해서 계획을 확정하는데 여기서 다음 주에는 이전과 똑같이 신규 캐릭터 1종을 추가하고 이 캐릭터의 성장을 부스팅하는 상품을 업데이트하고 이 캐릭터와 기존 비슷한 계열 캐릭터의 성장을 부스팅하는 이벤트와 몇 주 전에 런칭한 신규 컨텐츠 이용을 부스팅하는 이벤트를 함께 열기로 했습니다. 금요일에는 이미 몇 주 전에 파이프라인을 타기 시작했던 캐릭터 에셋에 기반해 전투 규칙을 데이터 모양으로 입력하기 시작합니다. 일단 캐릭터 자체가 인게임에서 정상적인 전투를 하기 시작하면 나머지 기존 캐릭터들과 시뮬레이션을 통해 상성과 강함을 조정합니다. 이 작업은 며칠에 걸쳐 계속됩니다. 동시에 다음 주에 집행할 이벤트를 준비하고 상품을 만들기 시작합니다. 이벤트는 캐릭터에게 버프를 주고 버프는 게임의 여러 기능에 영향을 주기 때문에 서로 다른 부서에 발주해 데이터를 입력하고 기능을 테스트하고 동시에 이 기능 각각에 필요한 에셋을 발주해 제작합니다.

월요일에는 신규 상품과 이벤트 데이터가 대략 준비되어 에셋 없이 인게임에서 정상 동작 여부를 테스트합니다. 기존 기능을 재사용할 때도 다른 기능과 충돌하는 등의 오동작이 발생해 코드를 수정하거나 오동작을 우회하는 데이터를 만들어야 할 수 있어 짧은 시간 안에 끝나지 않습니다. 화요일에는 완성되기 시작한 에셋을 추가하고 어제 일어나는 문제 중 해결된 것들을 우선 적용해 테스트 하기 시작합니다. 이 즈음이 되면 게임에는 이번 주에 추가하기로 한 신규 캐릭터가 들어가 목요일 오전의 모습에 가까워집니다. 수요일에는 내일 새벽에 업데이트 할 빌드를 완성하고 업데이트 계획을 수립합니다. 상황에 따라 다운타임에 데이터베이스를 마이그레이션 해야 할 수도 있는데 이런 때는 평소보다 더 많이 준비해야 합니다. 목요일 새벽에 다운타임을 시작해 업데이트를 진행하고 다른 회사들의 출근시간 전에 오픈합니다. 이제 처음으로 돌아가 이 과정을 수 년에 걸쳐 반복해야 합니다.

이야기하지 않은 것이 있는데 이런 업데이트 외에도 한달에 한 번 빌드 업데이트, 빌드 업데이트 주기에 맞춘 규모가 큰 컨텐츠와 시스템 업데이트는 이 라이브 업데이트와 별도로 이루어져야 합니다. 혹시 이 과정 중에 장기 휴가를 갈만한 빈틈을 찾는데 성공했다면 장기휴가를 가도 좋습니다. 종종 구인 할 때 인터뷰에서 앞으로 만들어보고 싶은 게임으로 ‘패키지 게임’ 또는 ‘끝이 있는 게임’을 말씀하시는 분들이 있습니다. 깊이 이해합니다. 저도 하고 싶은 일이니까요. 혹시 끝이 있는 게임을 만들면 한동안 삶 없이 집중적으로 일한 다음 휴가를 갈 수 있지 않을까요? 몇 십 년 전을 생각해보면 불가능하지는 않을 것 같습니다. 이 상황이 현실적으로 어떻게 돌아가는지 설명하겠습니다.

회사는 대체로 제작 경험을 보유하고 있지 않습니다. 프로젝트 수행으로부터 나온 경험은 사람에게 쌓입니다. 프로젝트 수행에 따른 의미 있는 경험은 어느 정도는 위로 갈수록 더 많이 쌓입니다. 회사 입장에서 프로젝트 수행 경험을 보존하려면 리드 또는 리드그룹 정도를 보전하면 됩니다. 나머지 경험은 외부에서 경력자를 고용해서 충당할 수 있습니다. 한 프로젝트가 마무리되어 잉여 인력이 생겼다 칩시다. 이 인력은 두 그룹으로 구분할 수 있습니다. 먼저 프로젝트로부터 의미 있는 경험을 쌓아 회사의 자산으로 보존해야 하는 그룹인데 방금 설명한 리드 또는 리드그룹입니다. 이들에게는 휴가를 줄 수 있습니다.

그리고 나머지. 이들은 외부에서 경력자를 고용해 충당할 수 있으므로 이들에게 휴가를 주는 것은 큰 손해입니다. 그래서 휴가를 가는 소수가 있고 나머지는 회사의 다른 프로젝트에 재배치 하게 됩니다. 프로젝트 완수에 크런치를 습관적으로 하는 회사라면 재배치된 프로젝트 역시 크런치를 하고 있을 가능성이 있습니다. 한 프로젝트의 크런치를 마치고 다른 프로젝트로 옮겨 크런치를 반복하게 됩니다. 이 과정은 회사 안에서 더 이상 옮길 프로젝트가 없거나 개인이 완전히 소진될 때까지 계속됩니다. 간단히 최근 몇 년 사이에 항공산업이나 조선업의 사례를 살펴보면 일이 줄어들 때 인력을 모두 해고했다가 나중에 재고용하는 것을 볼 수 있는데 소프트웨어 개발이라고 해서 다르지 않습니다. 크런치 후 휴가는 전설로는 존재하지만 실제 세계에서는 일어나지 않습니다.

근본적으로 요구사항이 불분명한 엔터테인먼트 소프트웨어 프로젝트는 서비스 형태가 패키지이든 라이브 서비스이든 개발이 완료될 시점을 정의할 수 없습니다. 게임이 ‘완성’되었기 때문에 런칭한다고 생각할 수 있지만 실제로는 개발이 계속해서 진행되는 사이에 시장 상황에 따라 적당한 시점을 선택해 런칭하는 것 뿐입니다. 콘솔에서 동작하는 대작을 구입해 당장 게임 하고 싶지만 첫날부터 10기가짜리 패치를 받는 흔한 경험을 생각해보면 알 수 있습니다. 게임은 결코 완성되지 않습니다. 게임 뿐 아니라 요구사항이 불분명하거나 수시로 변경되는 제품 모두는 결코 완성되지 않으며 완성되는 시점을 정의하기도 아주 어렵습니다.

때문에 극도의 노동 집약적 업무를 수행해 개발을 마무리한 다음 보상을 받고 휴가를 가서 충전한 다음 돌아와 이 과정을 반복하는 지속 가능한 크런치는 누군가의 머리 속에서 존재할 수는 있지만 실제로는 지난 수 십 년 동안 존재한 적이 없고 앞으로도 존재할 가능성이 거의 없습니다.