왜 대기발령 부서의 개발은 보통 실패할까

왜 대기발령 부서의 개발은 보통 실패할까

가끔 국적을 가리지 않고 업계의 네임드들이 종종 과거의 전설에 대해 공개적으로 이야기하는 모습을 볼 수 있습니다. 여기서 이 분들은 이제는 전설로 남은 위대한 게임이 시작된 간단한 설명이 적힌 종이, 상황을 설명한 그림, 혹은 아주 간단한 프로토타입 빌드를 소개하며 위대한 게임이 바로 여기서 부터 시작됐다는 소개를 해 우리들 모두를 감동 시키곤 합니다. 저런 위대한 게임들도 우리들이 항상 하는 메모나 드로잉, 그리고 다들 어떻게든 생각을 증명해 보려고 만들어 대는 프로토타입으로부터 비롯되었으며 우리들도 잘 하면 저런 위대한 결과물을 만들어 전설이 될 수 있을지도 모른다는 생각을 하게 만듭니다.

갑자기 가슴 벅차오르는 이야기를 하다가 분위기를 깨서 죄송하지만 여기서 확실하게 말할 수 있는 것은 저건 저 분 이야기이고 우리는 그럴 수 없습니다. 이 글은 왜 우리가 그럴 수 없는지 설명하기 위한 것입니다.

현대에도 꽤 많은 회사에서 그렇게 하지만 과거에는 훨씬 더 많은 회사가, 사실은 거의 모든 회사가 프로젝트 단위로 사람을 고용하고 프로젝트가 종료되면 그 사람들을 해고했습니다. 물론 사내에서 다시 자리를 찾을 수도 있었지만 보통 절차는 흔히 생각하는 재배치가 아니라 이미 회사에서 일하고 있는 사람이 다시 회사 안의 다른 프로젝트에 이력서와 포트폴리오를 제출하고 이번에는 사내 인사평가 정보에 마저 접근할 수 있는 상대가 이를 평가해 채용 되어야만 회사 안에 자리를 유지할 수 있었습니다.

그래서 이런 상황이 되면 회사 안의 다른 조직에 이력서를 제출함과 동시에 회사 밖에도 똑같이 구직 활동을 해서 더 나은 조건을 찾아 이동하곤 했는데 게임 쪽에서만 일하다 보니 회사 안에서 다른 조직에 회사 밖에서와 똑같은 절차를 거쳐 구직 하는 행동이 이상하지 않다고 생각해 왔지만 다른 분야에서 일하시는 분들과 이야기해 보니 완전히 이상한 절차라는 점을 알게 되었습니다. 현대에도 상당수 회사에서 직원은 정규직으로 고용되지만 사실상 프로젝트 하나 단위로 고용 관계가 유지되는 일종의 무기 계약직이라고 볼 수 있습니다. 다행스럽게도 은행 같은 곳에서는 우리들을 정규직 취급 해 주지만 그 실상은 계약직이라는 점은 웃기기도 하고 또 슬프기도 합니다.

이런 고용 형태가 일반적이지 않으며 직원들 개개인에게 대단히 가혹하다는 점이 널리 알려지고 또 회사들도 나름 대로 이미지 관리를 해야 하는 세계가 시작되면서 회사에는 일종의 대기 발령 부서가 생겼는데 회사가 프로젝트에 적대적으로 굴면서 호시탐탐 프로젝트를 드랍할 이유를 찾는데 몰두하는 곳일 수록 대기 발령 부서의 규모가 큰 것 같습니다. 이전에는 드랍된 프로젝트에 남은 사람들은 알아서 그만 둬야 했지만 요즘 세상에 널리 알려진 회사에서 함부로 그런 짓을 했다가는 이후 오랜 기간에 걸친 구인 시장에서 기피 대상이 될 위험을 감수해야만 하기 때문에 이전만큼 가혹하게 굴지는 않는 것 같고요. 하지만 프로젝트는 드랍 됐고 이 인력이 회사 안에서 당장 수행할 마땅한 일이 없는 상황이 되자 이들을 수용하고 이들에게 뭔가를 시킬 명분과 시킬 일 자체가 필요해졌고 그래서 대기 발령 부서를 만들어 부서 이름에 그럴 듯한 멋진 이름을 붙여 놓은 겁니다.

회사마다 규칙이 조금씩 다르긴 하지만 대기 발령 부서는 최대한 머무를 수 있는 기간에 제한이 있고 그 안에 다른 부서로 ‘구직 과정’을 거쳐 이동하거나 해고되어야 하고 그 안에 같은 부서 안에 있는 사람들과 회사의 인정을 받을 만 한 결과물을 만들어 낸다면 그 멤버들을 주축으로 새 프로젝트를 시작할 수 있는 경우도 있습니다. 이론적으로는 다른 프로젝트의 실패 경험을 가진 여러 인력들이 모여 잠시 숨을 고르고 깊이 생각한 다음 각기 다른 직군의 인력을 모아 프로토타입을 만들어 회사에 피칭 해 프로젝트를 킥오프 할 기회를 얻을 수 있는 어떻게 생각하면 참 대단하고 또 의미 있는 규칙입니다.

하지만 다른 한 편으로는 업계에 들려오는 소문을 들어 보면 대기 발령 부서에서 무사히 프로젝트 단계로 넘어가 제대로 된 런칭을 경험한 프로젝트는 없거나 거의 없는 것 같습니다. 사실 그럴 수밖에 없는데 지금부터 이유를 설명하겠습니다.

맨 처음 소개한 업계의 전설들은 프로젝트를 시작할 때 자기 자신이 의사결정을 할 수 있는 위치에 있거나 자기 자신이 프로토타입이나 피칭을 보고 프로젝트의 가능성을 알아볼 수 있는 재능을 가지고 있었습니다. 텍스트 몇 줄, 그림 한 두 장, 삐걱거리는 프로토타입을 보고 미래에 이들이 발전된 모습과 고객들에게 줄 수 있는 경험, 시장에 미칠 영향을 모두 연결해 종합적으로 상상해낼 수 있는 능력을 가진 사람은 극히 드물고 그렇기 때문에 맨 처음 이야기한 사람들을 네임드라고 부르는 것입니다.

우리들이 고용된 회사에 그런 사람은 높은 확률로 존재하지 않습니다. 우리들이 프로토타입을 만들어 피칭하는 상대는 그런 선구적인 상상력이 없는데 우리가 피칭에 들이는 어마어마한 자원을 생각해 보면 알 수 있습니다. 만약 우리가 텍스트 몇 줄, 그림 몇 장, 삐걱거리는 프로토타입만 가지고 실제 우리들의 경영진에게 피칭을 한다고 가정해 볼 때 우리들이 고성과 함께 날아오는 크리스털 재떨이를 머리에 맞고 어두운 방 안에서 깜빡이는 프로젝터 불빛 앞에 멍한 표정을 지은 다음 방에서 쫓겨나지 않을 가능성은 얼마나 될까요. 때문에 상상력을 필요로 하는 준비만으로는 피칭에 결코 성공할 수 없습니다.

그렇다면 이제 초점은 대기 발령 부서에서 이런 경영진의 눈높이를 맞출 수 있는지 생각해 보면 됩니다. 프로젝트가 드랍 될 때 대기 발령 부서에서 가장 불리한 사람들은 게임디자이너입니다. 엔지니어나 아티스트들은 인력이 급한 부서에 물량으로써 투입될 수 있습니다. 하지만 게임디자이너는 당장 기능 구현에 투입할 수도 없고 에셋 물량을 생산하는데 투입하기도 어렵습니다. 그런 이유로 시간이 흐르면 대기 발령 부서에는 게임디자이너 비중이 높아지는데 이들 중 일부는 삐걱거리는 프로토타입을 만들 수는 있겠지만 이미 다른 부서로 떠나고 없는 진짜 전문가들의 도움을 받은 결과물에 비해서는 하잘 것 없는 결과를 만들어낼 수밖에 없습니다.

이제 대기 발령 부서 사람들의 시각으로는 의미 있는 도전이라고 생각하는 삐걱거리는 프로토타입을 가지고 경영진에게 피칭을 시도해 보지만 경영진들은 선구적 상상력이 없고 프로토타입을 이해할 수가 없습니다. 뚱한 눈으로 서로를 바라본 다음 아무 일도 없었던 것처럼 서로 방을 떠났다면 그나마 잘 된 일이고 누군가가 재떨이에 맞았다면 그건 좀 생각해볼 만한 상황입니다.

개인적으로는 인력을 프로젝트 단위로 고용하며 프로젝트 드랍에 따라 개인에 대한 업무가 사라지는 구조에서는 개인이 장기적으로 회사에 고용되어 경험을 쌓으며 발전하기 쉽지 않다고 생각합니다. 물론 프로젝트 단위로 개인을 고용해 그 개인이 단일 프로젝트에 최대한의 역량을 발휘하도록 하는 것은 꽤 그럴듯해 보이고 익숙하기도 하지만 달리 말하면 프로젝트의 운영을 개개인들에게 맡기고 이를 통제할 능력이 회사에는 없다는 말과 같습니다. 개인적으로 이상적인 형태는 한 회사에서 여러 프로젝트를 진행할 때 개개인이 여러 프로젝트의 여러 업무에 할당되어 단일 프로젝트가 드랍되는 이벤트가 개인의 고용 형태에 큰 영향을 주지 않는 거라고 생각하기는 하지만 깊이 생각해본 것은 아닙니다.

결론. 과거에는 프로젝트 드랍에 따라 바로 해고되었지만 요새는 대기 발령 부서로 옮겨 가는 경우가 있는데 희망과는 달리 여기서 그럴 듯한 프로젝트 피칭에 성공해 킥오프를 하고 런칭에 도달하기는 거의 불가능합니다. 대기 발령 부서에 남는 사람들의 직군 상 특징과 이들의 표현 방법으로부터 상상하지 못하는 사람들이 의사결정권한을 가지고 있기 때문인데 당장은 마땅히 해결할 방법이 마땅찮아 보입니다. 적어도 당분간은 대기 발령 부서에서 출발해 런칭에 성공한 프로젝트 소식을 들을 수 없을 겁니다.