직접 만들어야 할까?

이 업계는 한국이 중화학 공업에 기반한 고도 성장기를 겪을 때 아예 존재하지 않았습니다. 그리고 1990년대가 시작되자 소수의 천재들이 나타나 새로운 산업 분야가 나타나기 시작했지만 그 규모는 너무 작아 딱히 관심을 받을 만한 존재는 아니었습니다. 그러다가 시간이 조금 더 흘러 의미 있는 경제적 성과를 거두기 시작하면서 주목 받기 시작했고 또 산업 태동기에 전통의 게임 업계가 상업적 성과를 거두는데 큰 문제를 겪으면서 업계는 아주 빠르기 온라인 중심으로 재편됩니다. 이런 과정에서 소수의 천재들이 업계의 태동, 초기 산업 정의, 그리고 아주 빠른 온라인으로 전환 같은 굵직한 업적을 이뤄 내며 수많은 일자리를 만들어냈습니다. 덕분에 조 같은 그저 그런 사람들도 일자리를 얻을 수 있게 되었고 처음 일자리를 얻은 다음 업계 태동기의 역사를 알게 된 다음부터는 항상 산업을 일으킨 한 분 한 분의 성함을 말할 수도 있는 그 분들께 감사하는 마음을 가지고 있습니다.

업계에는 여러 가지 전설이 있습니다. 무시무시한 사장님 성격 덕분에 제대로 준비하지 않았거나 사고의 깊이가 충분하지 않은 상태로 피칭을 시도하다가 어떻게 이렇게 빨리 만들었나요?에도 짧게 언급한 공포의 재떨이가 날아오는 전설이 있는데 핵심은 하늘을 나는 재떨이 다음에 그 재떨이를 피했다가는 더 큰 화를 부를 수 있기에 맞긴 맞되 덜 아프게 맞고 아프게 맞은 것처럼 보이는 요령이 전해집니다. 어떤 게임은 본격적인 경제적 성과를 거두기 시작하자 외부로부터 투자를 받기로 했는데 투자사와 미팅 도중 투자사가 게임에 수정되었으면 하는 부분에 대한 의견을 제시했다고 합니다. 그런데 회의 참여 인원 중 한 분이 회의에 전혀 집중하지 않고 랩탑 키보드를 두드리고만 있어 상대가 기분이 상할 무렵 랩탑을 돌려 보여주며 ‘이렇게 하면 된다는 말이냐’고 회의가 끝나기 전에 요구사항을 구현한 모습을 보여줘 모두를 놀라게 한 일이 있었다고 합니다. 그러니까 랩탑에 열중하며 회의에 집중하지 않은 것이 아니라 회의에 집중해 요구사항을 접수했고 회의가 끝나기 전에 요구사항을 구현해 버린 겁니다.

이런 전설은 고대에만 있지 않습니다. 현대에도 종종 전설이 만들어지는데 어느 프로젝트에는 프로젝트의 핵심 의사결정을 할 수 있는 분이 있고 이 분은 회사와 직접 이야기를 나누며 프로젝트를 지속해 나갈 권한이 있습니다. 이쯤 되면 프로젝트 구성원들을 보호하기 위해 이 분을 나머지 구성원들과 분리된 방 안에 넣어 두고 개발로부터 거리를 두게 만드는데 이 분은 여전히 개발에 적극적으로 관여하고 또 프로젝트 구성원들이 반대하는 요구사항을 시도해 보고 싶으면 이를 구성원들에게 설득하는 대신 그냥 본인이 만들어 버린다고 합니다. 사실 이 분은 충분한 시간과 원활한 에셋 제작 환경을 제공하면 혼자서 서비스 직전의 프로젝트를 통째로 만들어 버릴 역량이 있을 겁니다. 나머지 구성원을 고용한 이유는 시간은 유한한 자원이어서 한 사람의 능력 만으로 현대의 거대한 프로젝트를 만들어내는데는 상업적으로 감당할 수 없는 시간이 들기 때문입니다. 이전에 다른 프로젝트에서도 엔지니어들이 현재 기술 기반으로는 어렵다고 했던 기능을 주말 사이에 만들어 주 초 회의에 들고 나타나 당장 빌드에 포함한다든지 하는 전설이 있었고 그 전설은 지금 이 순간에도 계속되고 있습니다.

저는 경력이 비슷한 다른 분들에 비해 관리, 리딩 역할을 훨씬 늦게 시작했습니다. 여러 이유가 있겠지만 일단 한 사람의 어른으로 철이 드는데까지 다른 사람들보다 더 긴 기간이 걸리는 바람에 아직 정신적으로 너무 어린 저에게 관리자 역할을 맡길 생각이 잘 들지 않았기 때문이 가장 큰 원인이라고 생각합니다. 다른 이유로는 산업의 태동기에 기여한 천재들과는 비교할 수 없이 멍청하지만 나름 제가 실무를 수행하는 범위에 한해서는 나름 잘 동작했고 특히 프로젝트를 지금 막 시작해 아무 것도 없을 때 개발 체계를 수립하고 초기 설계를 담당해 개발이 궤도에 오르는데 기여하거나 처음 보는 다른 프로젝트의 기능으로부터 우리 게임에 어울리는 설계를 도출해 개발을 진행 시키는 역할로도 그럭저럭 동작했습니다. 신기하게도 상당 수 프로젝트에서 이런 역할을 수행할 사람이 충분하지 않아 제 역할을 관리로 돌리면 당장 제 역할을 해 낼 사람이 사라져 저를 더 오랫동안 실무에 남겨 둬야 하는 이유도 있었습니다. 이는 시간이 지나자 급여 수준을 결정하는데 문제를 일으켰는데 주로 연차가 쌓이면 직급을 올리고 올라간 직급에 따라 급여를 책정했지만 저는 연차가 쌓였지만 여전히 실무 수준에 머물렀기 때문에 회사의 기존 규칙 대로 급여를 책정하면 같은 연차의 다른 사람들보다 적은 급여를 받을 수밖에 없었기 때문입니다. 올해(2024년) 들어 나를 얼마에 팔 것인가 같은 고민을 하며 이전에 일어났던 일을 생각해보니 큰 회사에서 저를 빼내려고 했던 회사에 제 현재 급여를 제시하자 더 낮은 실무자 수준을 예상했다가 이와 다르자 엄청 당황해 하던 적도 있습니다.

그런데 일을 계속하다 보니 계속해서 실무 수준으로 프로젝트에 기여하는데는 한계가 있다는 생각을 하게 됐습니다. 이런 고민을 하는 시점에도 여전히 저는 적어도 제가 하는 일에 대해서는 꽤 괜찮은 전문성, 자원 - 대체로 시간 - 이 부족한 상황에서 빨리 대안을 찾아내는 일, 또 스트레스 상황에서 적당한 수준으로 동작하는 등의 실무 수준에서 장점을 가지고 있었지만 서서히 언제까지나 에이스로 살 수는 없다는 생각을 하고 있었습니다. 또 제가 제 자리에서 아무리 잘 한다 하더라도 제가 영향을 끼칠 수 있는 범위에는 명백한 한계가 있으며 그 영향을 확장하고 더 넓은 범위에 전문성을 통한 도움을 주며 더 큰 기여를 하기 위해서는 실무 수준에 머무르기를 고집해서는 안된다는 생각을 합니다. 이전에는 별 관심 없던 학교를 마치고 회사에 처음 오신 주니어님들이 회사와 업무에 적응하도록 돕고 적당한 시점에 최대한 짧은 의미 있는 조언을 하기 위해 노력하고 또 제가 직접 해버릴 수도 있지만 팀원님들이 업무를 수행하며 부딪치는 문제를 제거하는데 관심을 가지기 시작합니다. 이런 업무 중 처음에는 특히 평가 업무가 너무나 귀찮고 고통스러웠는데 이 역시 결국 프로젝트 전체의 퍼포먼스를 위해 개선사항을 파악하기 위해서는 필요한 일이라는 점에 동의하게 되었습니다.

또 그 동안은 전혀 관심을 두지 않던 관리, 리더십, 카리스마의 유지 같은 주제에 관심을 가지고 다른 선배 관리자들의 행동을 관찰해 적당히 가공한 다음 따라하거나 리더십 관련 책을 찾아보고 제가 수행해야 할 임무 범위를 이해하려고 노력했는데 리더십은 파보면 파볼수록 저 자신을 한계까지 밀어 붙이고 그 상태에 익숙해지기를 원하는 것 같아 보입니다. 특히 리더십 분야에서 개인적으로 의미 있게 읽고 이후 여러 생각과 행동에 영향을 준 '네이비씰 승리의 기술'로부터 영감을 많이 받았습니다. 우리들은 전쟁을 하고 있지도 않고 실수하면 누군가가 죽는 상황에 놓여 있지도 않지만 그런 상황에 놓여 있는 사람이 생각하고 행동하는 방식을 모방하면 보다 평화로운 상황에서 큰 의미를 찾을 수 있다는 생각을 합니다. 특히 이 책은 제 주변에서 일이 잘못되어 갈 때 그 일에 대한 책임을 물을 사람을 찾기 보다는 일을 해결할 방법을 찾는데 집중하라고 조언합니다. 사회에서는 여러 상황에 걸쳐 잘못된 일에 책임 질 사람을 찾는데 집중하고 또 이 일을 아주 잘 수행하는 사람들이 있습니다. 하지만 만약 이 상황이 일이 잘못 되었을 때 누군가가 죽거나 크게 다칠 뿐 아니라 그 영향이 저 자신에게도 문제를 일으킬 수 있다면 한가롭게 책임 질 사람을 찾고 있을 수 있을까요? 절대 그렇지 않습니다. 책임은 나중에 생각하고 일단 지금 당장의 상황을 해결하는데 집중해야 아무도 죽지 않고 무사히 부대로 복귀할 수 있을 겁니다. 이 책은 이런 생각을 심어줍니다.

그렇게 실무와 관리 사이에 적당한 균형을 유지하며 프로젝트의 좀 더 넓은 범위에 걸쳐 기여하기 시작하며 든 걱정은 결국 이렇게 관리에 집중하다 보면 과거에 그럭저럭 해 나갔고 또 저를 대체할 사람이 그리 많지 않은 실무 영역을 통한 기여를 영원히 잃어버리지 않을까 하는 것입니다. 물론 이전에 비해 기여할 수 있는 범위가 넓어진 점은 개인적으로 새롭고 흥미로운 주제였지만 다른 한 편으로는 서서히 이전처럼 실무 수준에서 문제해결을 위해 고민할 일이 상대적으로 줄어들었고 제가 직접 그런 고민을 하는 대신 고민 자체를 다른 사람에게 할당해야 했습니다. 그리고 관리 업무만 하고 있으면 너무 심심하니까 팀에 수행할 재미 있는 일을 멤버들에게 할당한 다음 남은 딱 봐도 재미 없어 보이는 뻔하고 작은 일을 조금 주워다가 수행하고 보니 저만 재미 없는 일을 맡아 이게 대체 뭔가 싶어 불만이 조금 생기기도 합니다. 이러면서 점점 더 실무 수준에서 문제 해결을 수행하는 능력이 사라질 거라고 봤고 이렇게 능력 없이 직급만 높은 사람이 되어 어느 날 회사로부터 명예퇴직 신청 대상자 메일을 받은 다음 떨리는 손으로 회신하는 최후를 맞이할 것만 같았습니다.

하지만 걱정과 달리 아직 그런 미래에 도달하지 않았을 뿐 아니라 멤버들이 일하는데 방해가 되는 일을 미리 찾아내 제거하거나 잘못된 요구를 받더라도 이를 거절하기 어려운 상황일 때 개입해 요구를 올바른 모양으로 바꾸거나 요구가 올바른 부서를 향하도록 조절하기도 하고 종종 전투력을 앞세워 절차를 무시하고 원하는 것을 얻으려는 분들께 그보다 강한 전투력을 발휘해 다시는 그런 행동을 하지 못하게 하거나 부서 사이에 언어가 달라 서로를 오해하고 있을 때 끼어들어 서로의 언어를 통역해 문제를 해결하는 역할 역시 실무와 비교해 전문성을 갖추기에 충분히 깊이 있는 분야라는 점을 배웁니다. 또 누군가에게 싫은 소리를 해서 분위기를 망치는 대신 저 자신이 그 싫은 소리에 의한 결과를 실천해 서서히 분위기를 바꿔 가거나 좁은 시야 속에서 큰 그림을 인지하지 못해 고통 받는 분이 계실 때 큰 그림을 직접 설명하고 또 시야를 조금 넓혀 같은 주제를 다시 고민해보는 요령을 설명하고 이 생각하는 방법을 직접 적용해 즉시 문제를 완화하는 경험을 하며 처음 실무 영역을 줄이며 가졌던 걱정을 조금씩 줄여 가고 있습니다. 물론 말은 이렇게 하지만 종종 아쉽고 또 실무 수준에서 너무 당연한 주제에 대해 질문할 때 부끄러움을 느끼는 건 어쩔 수가 없습니다.

지난 백수 생활 도중 이전 권고사직에 의해 퇴사하신 분들과 만나 이야기하다가 그 중 한 분이 취업과 별개로 멤버들을 모아 사이드 프로젝트를 준비하고 있다는 말씀을 들었습니다. 사실 엔지니어나 아티스트처럼 스스로 결과를 낼 수 있는 스킬을 대체로 가지고 있지 않은 게임디자인 직군은 사이드 프로젝트를 수행하고 이를 성공 시키기 아주 어렵습니다. 현대에는 강력한 미들웨어를 통해 엔지니어 수준의 지식과 스킬을 가지고 있지 않아도 어느 정도 동작하는 결과를 만들 여지가 있고 또 이미 완성된 에셋을 무료 혹은 낮은 비용으로 확보할 수도 있어 이전 시대에 비해서는 동작하는 뭔가를 게임디자이너가 직접 만들어낼 여지가 훨씬 많아진 것은 사실입니다. 하지만 그렇게 만들어진 결과물은 아이디어가 훌륭하다 할지라도 현대 고객들의 높아진 눈높이에 의해 쉽게 저평가될 수 있습니다. 루리웹의 어느 글에 달린 답글에서 오래 전에 출시된 게임의 리메이크 개발 소식에 열광하는 사람들 사이에 오래 전 개발된 그 원작 스크린샷을 보고 ‘이 병맛 게임은 뭐냐’고 묻는 사람들을 보고 웃어야 할지 울어야 할지 알 수 없는 복잡한 감정을 느끼기도 합니다. 하지만 각 분야의 전문가가 모인다면 이야기는 달라집니다.

물론 각자는 서로 다른 곳에 고용되어 회사의 일을 가장 높은 우선순위로 수행해야 하기에 각 분야의 전문가가 모였다 하더라도 사이드 프로젝트가 원활하게 진행되기는 쉽지 않을 수 있습니다. 또 이전에는 회사의 지원을 아무렇지도 않게 받으며 개발하던데 비해 사이드 프로젝트는 그런 지원을 전혀 받을 수 없어 난처한 상황에 쉽게 처할 수도 있습니다. 가령 형상관리도구를 설정하고 또 이에 알맞는 미들웨어를 결정하고 각자의 개발환경을 구축하며 서로 의사소통하는 일관된 방법을 구축하는 등의 일은 회사에서 수행하는 프로젝트에서는 전혀 신경 쓸 일이 아니었겠지만 그런 도움 없이 직접 수행하는 사이드 프로젝트에서는 하나하나가 돈을 지불하거나 아니면 조잡한 결과물을 사용해야 하는 것 사이의 의사결정이 되기 쉽습니다. 또 인원이 적고 인원 각자의 커버리지가 넓어져 회사에서 각 직군의 업무범위에 따라 일하던 것에 비해 업무범위가 달라질텐데 여기에 적응하지 못하면 이유 없는 억울함에 빠져 프로젝트를 그만 두는 결말로 끝날 수도 있습니다. 이런 온갖 문제 가능성에도 불구하고 각 분야의 프로페셔널을 모아 사이드 프로젝트를 시작한다면 성공 가능성은 훨씬 높아지고 또 회사에서 채우지 못한 욕망을 채울 적당한 방법이 될 수도 있습니다.

이런 이야기를 전해 듣고 부러워하다가 문득 게임디자이너가 어디까지 직접 수행할 수 있으면 좋을지 그 업무범위를 설정하는 문제를 생각해 봤습니다. 게임디자인의 분업이 만들어낸 비 존중에서 현대에 효율을 위해 분업을 선택한 게임디자인 분야는 각자가 그들 스스로는 동작하는 빌드를 만들어내기 어렵기 때문에 아주 쉽게 다른 직군에 비해 불리한 입장에 처할 수 있습니다. 분업에 따라 각자의 지식은 점점 더 얕아져 다른 직군으로부터 간단한 질문에도 답하기 어려운 상황에 처할 수 있는데 이런 상황이 일어날 때마다 게임디자인 직군을 향한 협업 부서의 신뢰가 낮아져 어려운 상황이 만들어지기도 합니다. 하지만 게임디자인 직군 각각이 적어도 각자의 파이프라인 전체를 이끌어 가는 형식으로 분업 하면 상대적으로 속도는 느려질 수 있지만 파이프라인을 시작하는 것도 마무리하는 것도 게임디자인 직군이 담당하며 이 과정의 다양한 단계에 개입하기 위한 스킬이 필요하므로 협업 부서로부터 신뢰 수준을 유지할 여지가 더 큽니다.

하지만 시간이 지날 수록 역할이 바뀌어 가며 프로젝트의 좀 더 넓은 영역에 영향을 줄 수 있는 역할로 옮겨 가며 마치 완전히 분업화 된 게임디자이너의 지식 범위와 시야가 좁아 협업 부서로부터 받은 간단한 질문에도 자신 있게 답하지 못하는 상태가 될 수 있지 않을까 하는 걱정을 하게 됩니다. 이전에 겪은 어느 프로젝트에서 실무와 그리 멀지 않은 게임디자인 쪽 관리자가 형상관리도구를 아예 사용하지 않아 이 분이 게임을 플레이 하도록 만들기 위해서는 개발 빌드가 아니라 항상 배포 과정을 거친 패키징 된 환경을 제공해야만 했는데 이 과정은 자동화 되어 있기는 하지만 시간이 꽤 걸렸고 간단한 변경사항을 확인하는데도 평소의 몇 분 대신 몇 십 분이 걸려 썩 경험이 좋지 않았습니다. 이런 식으로 실무와 멀어질수록 프로젝트에 기여할 수 있는 범위는 넓어지지만 프로젝트에 ‘직접’ 기여할 수 있는 범위는 줄어들며 이에 따라 업무를 통한 카리스마의 유지는 점점 더 어려워진다고 생각합니다. 그래서 한동안은 걱정을 좀 내려놓고 영향을 줄 수 있는 범위를 늘리고 한 명의 실무자로써 기여하는 역할에서 여러 사람이 원활하게 일할 수 있도록 돕는 역할에 집중하고 공부했지만 이번에 다른 분의 사이드 프로젝트 이야기를 들으니 또 마냥 일선에서 멀어지는 것이 올바른 일인가 하는 고민을 다시 하게 만듭니다.

그런 고민 도중 과거에 이 산업을 일으킨 천재들의 전설을 떠올리며 그들은 회사 전체를 책임지고 있으면서도 여전히 직접 기능을 커밋 했고 이런 분들은 지금 이 순간에도 어떻게 이렇게 빨리 만들었나요?에 소개한 것처럼 프로젝트의 가장 높은 곳에 있으면서도 여전히 구성원들을 직접 설득하기 쉽지 않을 때 스스로 빌드에 개입해 결과로 설득하고 있습니다. 이런 사례를 보며 마냥 순진하게 실무로부터 그냥 멀어져 관리자 역할을 더 잘 수행해 가는 것이 마냥 올바르지 않을 수도 있겠다는 생각을 해봤습니다.

직접 만들 수 있어야 할까요? 이전에는 확실히 그렇다고 망설이지 않고 답할 수 있었습니다. 한동안은 그 대신 여러 사람들이 원활하게 일하도록 기여하는 쪽이 프로젝트에 더 큰 영향을 줄 수 있다고 생각했습니다. 하지만 시간이 흐르며 여러 일을 겪자 마냥 그게 개인 관점에서 옳은 일이 아닐 수도 있겠다는 생각을 하며 갈팡질팡 하고 있습니다.