왜 우리의 서드파티 도구 도입은 실패할까?

오래 전 어느 프로젝트 디렉터님이 어디선가 인터뷰 하시는 것을 본 적이 있습니다. 정확한 워딩을 기억하지 못하지만 대략 온라인 게임을 만들다 보면 집중적으로 개발할 다른 게임과 다른 부분, 또 우리들이 처음으로 시도하는 부분에 집중해야 하지만 그렇지 않은 다른 부분들은 다른 게임과 비슷하기 때문에 최대한 다른 게임으로부터 가져다 사용해 게임을 완성했다는 내용입니다. 게임을 만들다 보면 종종 비슷한 의문을 가질 때가 있었습니다. 게임마다 파티, 길드, 업적, 인스턴스, 상호작용 등 온갖 비슷한 요소들이 있는데 매번 이들을 만들기 위해 새로운 문서를 작성하며 왜 이 짓을 매번 다시 해야 하는지 모르겠다 싶습니다. 만약 우리들이 처음 만들어진 회사에 모인 사람들이라면 모든 문서를 새로 작성해야 합니다. 우리들이 모든 문서를 새로 작성하지 않았다는 사실이 각자의 이전 회사에 알려지면 분명 좋은 결과로 끝나지 않을 가능성이 있습니다.

하지만 만약 우리들이 이전에 다른 게임을 여럿 만들어 온 회사에서 새 프로젝트를 시작하고 있다면 분명 이전의 여러 프로젝트로부터 이번 게임에 들어갈 것과 크게 다르지 않은 문서, 에셋, 빌드가 이미 회사 어딘가의 서버에 잠들어 있을 가능성이 있습니다. 몇몇 회사들은 이미 이들을 적당히 정리해서 거대한 라이브러리를 만들어 놓고 회사에 속한 여러 사람들이 라이브러리에 접근해 원하는 정보에 접근할 수 있도록 하고 있습니다. 마지막으로 경험한 이렇게 해 놓은 회사에서는 회사 전체에서 생산한 아트 에셋에 접근할 수 있도록 하고 있었는데 언리얼 에디터만으로 간단히 어떤 메커닉을 검증하고 싶을 때 순식간에 다른 게임의 레벨과 캐릭터를 가져와 걸어다니게 만든 다음 메커닉을 만드는데 집중할 수 있었습니다. 반대로 회사에서 생산한 기획서에 접근할 수 있는 절차가 있던 다른 회사에서는 기획서에 접근하기 위해 제가 속한 본부의 본부장 결재까지 올라간 다음 상대 본부의 본부장부터 실무자까지 결재선을 타고 내려가 대략 한 8명의 승인 후에야 문서를 받아볼 수 있었는데 이 과정에 2주가 걸렸습니다. 저는 당장 문서가 필요한 시점으로부터 몇 분 안에 문서를 살펴보고 싶었을 뿐이었고 문서를 못 본 이상 그냥 제가 생각하는 대로 작성해 이미 진행했고 빌드가 만들어져 이미 라이브에 나가 버렸는데 그러고도 며칠이 지난 다음에야 모든 승인이 끝난 문서를 얻을 수 있었고 결국 이 문서는 열어보지도 않았습니다.

물론 이렇게 나쁜 경험만 있는 것은 아닌데 이제 제가 고민할 차례입니다에서 과거에 그리 만족스럽지 않게 플레이 했던 게임의 기획 문서에 접근해 과거에 그 분들이 왜 그런 의사결정을 했는지 행간을 읽으며 추측해볼 수 있어 좋았고 또 다른 사례에서는 다른 팀에서 개발하며 생산한 문서 전체에 실시간으로 접근할 수 있어 그들이 과거에 했던 시행착오를 미리 살펴보고 우리는 같은 문제를 미리 우회할 수 있어 굉장히 큰 도움을 받았습니다. 하지만 이런 도움에도 불구하고 여러 가지 기능을 바닥부터 설계하기 위한 여러 문서를 생산하고 있는데 불행히도 이 문서들의 상당수는 이미 회사에서 이전에 진행했던 다른 프로젝트에 분명 똑같은 기능을 만들었을 겁니다. 우리들은 그런 문서에 충분히 자유롭게 접근할 수 있는 상황은 아니기 때문에 비록 회사 컨플루언스 서버 어딘가에 그 문서들이 있을 가능성이 높다는 사실을 알지만 그 문서를 보기 위해 어떤 절차를 거쳐야 하는지, 그런 문서가 존재하기는 하는지 등등을 알지 못하고 그런 시도를 하느니 그냥 우리가 시간을 들여 문서를 쓰는 편이 낫다고 판단한 것 같습니다. 이미 제 경험 상 다른 프로젝트의 문서를 볼 수 있는 절차가 있는 환경에서도 2주일이 걸렸는데 그런 절차가 없는 상황이라면 문서를 바닥부터 쓰는 편이 다른 프로젝트의 문서를 요청하는 절차를 바닥부터 뚫는 것보다 훨씬 나을 겁니다.

이런 관점의 연장이라고도 볼 수 있는데 종종 우리들은 이미 누군가 만들어 놓았을 가능성이 높은 코드를 사용하는 대신 완전히 바닥부터 요구사항을 받아들여 개발하고 남들이 이미 만들어 놓은 꽤 괜찮은 도구보다 훨씬 못한 수준의 결과를 만드는데 상당한 시간을 투자하곤 합니다. 락스타는 이미 두 자릿 수 해 이전부터 모든 스크립트를 실시간으로 렌더링 되는 컷씬과 더빙으로 제작해 구질구질하게 텍스트를 읽을 필요가 없었습니다. 하지만 서기 2024년의 우리들은 아직도 게임에 등장하는 상당수 대사를 구질구질한 텍스트로 표시하고 이 텍스트가 핵심 인터페이스일 뿐 아니라 이 텍스트 인터페이스 역시 오랜 시간 이전에 경험한 일본식 텍스트 어드벤처로부터 가져온 시스템으로부터 크게 변하지 않았습니다. 이전에는 캐릭터가 2D 이미지로 말하고 그 밑에 대사창이 나타나 말했다면 이제는 게임 상의 3D 캐릭터에 직접 카메라를 갖다 대는 정도로 변했을 뿐입니다. 사실 이 변화야말로 기술이 크게 진보한 결과이지만 그 결과에 기반해서도 여전히 대사는 대사창에 나타나는 텍스트일 뿐이라는 사실은 변하지 않습니다. 이런 인터페이스를 만들기 위해 완전히 바닥부터 우리들은 텍스트를 어떻게 입력할 것인지부터 시작해 어느 시점에 연출을 누가 제어할지, 또 대사에는 선택지가 있을지, 분기가 있을지 따위의 요구사항을 완전히 바닥부터 재구축해 이를 개발하는데 여기에는 상당한 시간이 걸립니다.

이런 게임에서 텍스트로 말한다면 이 시스템을 단독으로 개발하는 경우는 없습니다. 적어도 상점 기능이 있는 NPC가 상점을 열기 전에 몇 마디 헛소리를 하게 만들기 위해, 또는 여러 NPC들이 말해야 하는 퀘스트를 만들기 위해 개발할 때 함께 텍스트로 말하는 기능을 만드는데 이 전체를 개발하는데는 비용이 상당합니다. 가령 이전에 어떤 모바일 MMO 게임을 개발할 때 게임에 들어갈 대화, 퀘스트를 바닥부터 만들었는데 일단 자동 기능 없이 개발한 다음 이 기반 위에 자동 기능을 붙이는 식으로 접근합니다. 그런데 자동 기능을 붙이기 이전에도 어지간한 게임의 뻔한 퀘스트 기능을 바닥부터 구축하고 퀘스트 진행에 따라 NPC와 대화하고 또 NPC들이 대화하며 각 상황에 맞는 인물들의 연출을 보여주고 때때로 인물이 말하며 이동하는 등 다양한 연출을 서로 다른 부서에서 필요에 따라 제어하는 시스템 전체를 안정적으로 구축하기 위해 거의 1년이 필요했습니다. 다행히 이 때 구축한 시스템은 이후 확장에 별 문제를 일으키지 않아 자동 기능을 덧붙이고 온갖 이상한 요구사항에 그때그때 대응하기 위해 새 기능을 추가하면서도 기존에 구축한 퀘스트들을 거의 손대지 않을 수 있었습니다. 하지만 결국 우리가 구축한 것은 고객 관점에서 그저 다른 게임에서도 불 수 있는 뻔한 퀘스트 시스템과 뻔한 대화 기능, 뻔한 연출 제어 기능에 불과하며 우리들인 이를 바닥부터 구축해 1년 가까이 걸렸지만 만약 좀 더 잘 정규화 된 남이 만든 코드에 기반해 개발했다면 이렇게 긴 시간을 들이지 않아도 됐을 수도 있지 않을까 싶은 생각이 들었습니다.

이전에 참여한 프로젝트는 애초에 인원과 비용이 충분하지 않은 상태에서 규모가 큰 결과를 만들려 했기 때문에 처음부터 남이 만든 코드를 적극적으로 도입하려고 했습니다. 이는 여러 가지 서로 다른 실행 방식으로 나타났는데 이전 같으면 별도 사운드 부서가 알아서 별도의 솔루션을 사용해 사운드를 입력하고 우리들은 크게 신경 쓰지 않았다면 이번에는 언리얼 엔진의 사운드 기능을 적극적으로 활용해 별도 솔루션 비용을 줄이기도 했고 또 그럴듯한 물을 표현하기 위해 이미 누군가 만들어 놓은 플러그인을 구입했으며 험지를 달리는 그럴듯한 자동차를 직접 만드는 대신 누군가가 이미 만들어 놓은 확장성이 대단히 높은 자동차 플러그인을 가져와 개발합니다. 퀘스트와 대화 역시 최대한 빨리 만들기 위해 이미 누군가 만든 기능을 가져와 붙였고 이전에 1년 걸려 만들었던 퀘스트 시스템이 순식간에 게임에 나타납니다. 또 다른 프로젝트에서는 대화 도중 캐릭터들의 연출을 제어해야 했는데 이 때는 본격적으로 시네마틱을 제작할 부서도 없었고 또 우리들이 그 정도 결과를 원하는 것도 아니었으며 엔진은 그런 도구를 제공하지도 않았는데 이 때도 연출을 제어할 수 있는 도구를 게임에 붙여 하루 저녁 사이에 게임에는 트랙 단위로 인게임 오브젝트를 제어하고 말하게 만들 수 있는 그럴듯한 도구가 나타났습니다. 이런 서로 다른 경험을 하며 만약 우리들의 요구사항을 서드파티 도구들이 제공하는 방식으로 정규화하고 이들 도구에 익숙해질 수 있다면 1년 개발할 것을 돈을 들여 하루 저녁만에 개발할 수도 있다는 사실을 잘 이해하게 됩니다.

이런 시도가 항상 성공한 것은 아닙니다. 한 프로젝트에서는 캐릭터들이 연출을 표시하며 말하게 만들기 위해 이미 누군가 만들어 놓은 플러그인을 도입하려고 했으나 플러그인 개발자의 가정과 우리의 현실이 너무 달라 결국 도입하지 못한 적이 있습니다. 플러그인 제작자는 아마도 여러 대사 각각을 블루프린트 노드로 만들 수 있게 하면 노드 단위로 진행되다가 분기를 만나거나 다른 연출을 표시하거나 아이템을 주고 받는 등 다양한 동작으로 블루프린트 상에서 바로바로 연결될 수 있다고 생각했을 것 같습니다. 우리들 역시 그런 확장성에 가능성을 느끼고 이를 도입하려 했는데 일단 이 도구는 블루프린트 노드에 대사를 넣는 대신 이 대사에 대한 국제화 대응이 잘 안 되어 있어 우리들이 이 도구에 국제화 개발을 해야 할 것 같았고 또 이 도구는 대사 각각을 블루프린트 노드로 나타내면서 대사량이 많아질 경우 관리가 만만하지 않은 모양으로 변하는 문제도 있었습니다.

이런 노드를 다루는 도구에 익숙하지 않은 사람이 대사를 입력하다가 구글에 검색하면 쉽게 찾을 수 있는 블루프린트 지옥에 쉽게 빠질 수 있었습니다. 또 노드 모양으로 대사를 나열하다 보면 중간에 대사를 추가하거나 삭제할 일이 생길 때 전체 노드가 배열된 모양을 적당히 보기 좋게 조절해야 했는데 이는 실행에는 아무 영향을 주지 않지만 미래의 작업자들에게 큰 영향을 줄 수 있었습니다. 고민 끝에 도구를 도입하는 대신 많은 대사를 텍스트 에디터 환경에서 편안하게 입력할 수 있는 단순한 문법과 문법강조를 제공하는 선에서 마무리합니다.

또 한번은 비슷한 퀘스트와 대화, 그리고 시네마틱을 제어하는 또 다른 도구를 도입하려고 했다가 결국 도입을 취소했는데 이 때는 본격적으로 이 도구를 사용해 개발 기간을 절약하고 제작 효율을 올릴 생각으로 빠르게 도구를 도입합니다. 하지만 결국 도구에 요구사항을 추가하다 보니 흔히 배보다 배꼽이 더 커졌다는 말처럼 개발 비용이 증가했고 또 요구사항을 내는 입장에서는 요구사항이 빠르게 받아들여지지 않고 또 이전에 사용하던 환경과 새 환경이 크게 달라 익숙해지기 어려운 상황이었던 것 같습니다. 결국 한동안 이 도구를 사용해 뻔한 퀘스트와 뻔한 다이얼로그를 개발하려고 하다가 포기하고 바닥부터 다시 개발하는 것으로 노선을 변경합니다. 사실 이 사례를 나중에 살펴보고 게임디자인 관점에서 어쩌면 이 도구에 기반해 개발할 수도 있었을텐데 어쩌다 실패했을까 하는 의문도 들었고 또 다른 프로젝트에서도 다른 도구에 대해 비슷한 시도를 했다가 결국 포기했던 기억도 함께 겹쳐지며 비슷한 상황에 의해 도구 도입을 포기하지 않았을까 하는 짐작을 해봅니다.

개인적으로 이런 서드파티 도구를 도입하는데 실패하는 가장 큰 이유이자 사실 거의 유일한 이유는 도구를 도입하는데 따라 바꿔야 하는 관점을 바꾸지 않기 때문이라고 생각합니다. 도구 도입을 검토하기 전까지 우리들은 어떤 기능이라도 바닥부터 개발하고 이를 위해 요구사항을 바닥부터 수집하는 과정을 익숙하게 받아들여 왔습니다. 이미 다른 게임에 수없이 사용한 것과 똑같은 방법, 똑같은 기능일 뿐이지만 이를 실제 기능을 사용할 사람들로부터 요구사항을 바닥부터 수집하고 이에 기반해 우리들에게 익숙한 가령 엑셀 같은 도구로 입력할 수 있도록 환경을 구성하고 이에 따른 입력 방식, 출력 방식을 기술한 문서를 작성하곤 했습니다. 물론 항상 일이 이런 식으로 진행된 덕분에 저 같은 이른바 ‘시스템 디자이너’들이 생계를 유지할 수 있었습니다.

또한 지금까지 개발해 놓은 상태의 맥락에 대한 고려 없이 당장 맞닥뜨린 한 가지 상황을 해결하기 위한 요구사항을 추가하는 것 역시 딱히 깊이 생각하지 않고 실행하곤 했는데 이 역시 이런 상황을 조율하는 역할을 통해 회사에 고용되어 생계를 유지할 수는 있었지만 종종 새로 나타난 요구사항이 이전에 개발되어 온 요구사항의 맥락과 완전히 달라 요구사항의 진짜 의미를 파악하고 이를 기존에 개발하던 맥락에 어울리는 모양으로 바꾸는 과정은 글자로 써 놓으면 그럴듯하지만 실제로는 서로 어이없어하는 두 부서 사이를 조율해야 하는 썩 즐겁지 않은 모양의 일일 때가 많습니다.

이런 관점에서 도구를 도입하면 이상적으로는 도구가 제공하는 기능의 목록을 살펴보고 이 제한 안에서 표현하려는 자세로 일하는 방식을 바꿔야 합니다. 어쩌다 게임에 절실히 필요한 기능을 도구에 추가할 수 없지는 않습니다. 그런데 도구 도입에 실패한 몇몇 사례들을 돌이켜보면 도구 사용자들은 도구의 도입에도 불구하고 이전에 바닥부터 개발하고 또 지금까지 개발해 온 맥락을 크게 고려하지 않은 채 새로운 요구사항을 내거나 도구가 제안하는 워크플로우에 적응하려는 경향을 잘 나타내지 않는 것 같습니다. 가령 어떤 도구를 도입했는데 이 도구는 값 입력을 블루프린트로만 받는다면 이제부터는 작업을 블루프린트 에디터 상에서 해야 합니다. 도구 도입에도 불구하고 이전과 같이 엑셀을 사용하겠다고 주장하면 도구를 도입한 이유가 크게 줄어듭니다. 또 도구가 제공하는 기능의 한계에 적응하기도 해야 하는데 만약 우리들이 엔지니어들의 도움 없이 집에서 간단한 구현체를 만든다면 사용하는 도구의 한계에 철저히 의지해야만 합니다. 가령 언리얼 에디터에서 블루프린트로 접근할 수 있는 범위 안에 반드시 있어야 하며 이를 구현을 통해 돌파하기는 사실상 불가능합니다. 덕분에 스타크래프트 1 에디터에서 변수 개념이 없자 변수 대신 맵 구석에 유닛을 원하는 갯수만큼 스폰 시킨 다음 하나 씩 죽여 가며 값을 불러 오는 괴상한 방법이 횡행한 것입니다.

하지만 도구 도입에 실패할 때 종종 도구의 한계를 살펴보는 대신 도구에 존재하지 않는 요구사항에 집중하다 보면 결국 어떤 도구도 도입할 수 없고 애초에 그냥 바닥부터 만들었으면 됐을 상황에 도구 도입을 검토하기 위해 시간을 써버리는 결과로 이어지는 것 같습니다. 남들은 플러그인을 구입해 빠르게 진행하는 개발을 왜 우리들은 항상 바닥부터 개발하기를 반복하고 또 도구를 도입하려 하다가 쉽게 실패할까요. 근본적으로 우리들이 엔지니어를 포함한 거의 모든 기능을 수직계열화 한 팀에서 일하고 있다는 점이 오히려 이미 누군가 만들어 놓은 도구를 도입하는데 어려움을 겪게 만드는 것이 아닐까 싶습니다.