진짜 목적을 숨긴 빌드업

게임의 모든 부분을 프로젝트 시작할 때부터 온전한 요구사항을 갖춘 상태로 시작하면 어떨까 하는 생각을 해본 적이 있습니다. 첫 회사에서 프로젝트가 극심한 난항을 겪으며 요구사항은 하루 아침에 사라졌다가 또 다른 어느 날 아침에 순식간에 나타나 여기 맞춰 개발을 진행하는 우리들을 곤란하게 만들었는데 이런 요구사항 중 상당수는 더 큰 요구사항을 설계하는 과정에서 우리들이 조금만 더 경험이 있었다면 미리 예측할 수 있는 것들이었습니다. 하지만 실제 요구사항을 구현하고 이들을 통합하는 과정에 가서야 문제를 알 수 있었고 일단 문제를 회피하는 선에서 요구사항을 작게 변경한 다음 다른 마일스톤에서 이번에 우리들이 겪은 문제를 본격적으로 해결하는 다른 요구사항을 설계해 개발해야 했습니다. 예상할 수 있다시피 그런 새로운 요구사항은 이전에 개발한 요구사항들의 핵심 목표를 희석할 가능성이 높았고 또 나중에 앞서 만든 기능들의 충돌을 바로잡는 일은 그 난이도가 상대적으로 높지만 새로운 기능들처럼 프로젝트 전체 관점에서는 그리 반짝이는 기능이 아니어서 이 개발에 참여한 사람들의 사기를 쉽게 저하시키기도 합니다. 이런 상황을 겪다가어느 날 프로젝트 리드님과 술을 마시다가 ‘다음엔 기획서 다 쓴 다음에 프로젝트를 시작할 거야’라는 말씀을 들었고 어린 마음에 정말 그럴 수 있으면 좋겠다는 생각을 했습니다.

결론부터 말하면 그 이후 영원히 그런 그 시대에 제가 생각한 이상적인 개발을 할 기회는 전혀 없었습니다. 이유는 너무 당연하게도 그렇게는 개발할 수가 없었기 때문입니다. 만약 게임디자이너 각각이 서로가 작성하는 서로 다른 요구사항을 깊이 이해하고 이들이 통합되어 동작하는 빌드의 모습을 머릿속에서 미리 실행해볼 수 있는 역량이 있다면 어쩌면 가능했으른지도 모릅니다. 하지만 그 정도 능력을 가진 사람 중 유명한 사람은 바로 아인슈타인이고 그 분이 이런 능력으로 해낸 것이 바로 여러 가지 사고 실험입니다. 그러니까 그런 능력이 있다면 우리들은 아인슈타인에 버금가는 업적을 쌓았을른지도 모르지만 그런 능력으로 굳이 게임디자인 같은 일을 하지 않았을 가능성이 높습니다. 우리들 대부분은 산업 초창기의 천재들과 달리 그들이 이미 자신들이 하고 싶은 새로운 도전을 찾아 떠난 다음 그 자리를 차지한 보통 사람들일 뿐이었고 우리들은 다른 사람이 담당한 게임디자인의 핵심을 파악해 자신이 작성한 디자인과 통합해 그 결과를 생각해낼 만한 능력을 갖추지 못했습니다. 그런 우리들에 얼마 동안 절망했지만 우리들보다 훨씬 똑똑한 사람들이 모여 일할 것이 분명한 항공기 설계 같은 분야에서도 서로 다른 요구사항을 반영한 설계를 통합하던 도중에 문제를 발견해 이를 수정하기 위해 설계를 대규모로 수정하고 또 그때까지 준비한 공정을 수정하고 또 그 결과물을 파기하기도 한다는 말을 듣고 그나마 이 직업을 가지고 살아갈 용기를 얻습니다.

앞서 만약 우리들이 서로가 작성한 게임디자인을 서로서로의 머릿속에 넣고 이를 시뮬레이션 해서 미리 문제를 찾아낼 수 있으면 좋겠다는 이야기를 했는데 현재 사용 가능한 기술 중 이와 비슷한 효과를 낼 수 있는 것이 바로 컴파일 할 수 있는 고수준 언어를 사용해 요구사항을 기술한 코드를 컴퓨터를 시켜 각 운영체제와 연산장치에 맞는 코드로 바꾼 다음 이를 직접 실행 시켜 살펴보고 문제를 해결하는 것입니다. 컴퓨터는 우리들이 작성한 문서를 이해하고 이들의 동작을 시뮬레이션 해 각 문서에 기술된 로직의 문제점, 이들이 함께 동작할 때 일어날 수 있는 충돌 가능성을 미리 알려주지 못하지만 우리들의 언어를 컴퓨터가 이해할 수 있는 고수준 언어로 기술하고 이를 컴파일 해 실행해 보는 과정을 거치면 서로의 기능이 충돌해 문제를 일으키는 상황을 고객들에게 서비스를 런칭하기 전에 미리 발견하고 수정할 수 있습니다. 그리고 우리는 이런 과정을 ‘개발’이라고 부르며 현대에 미리 기획서를 잔뜩 써 놓지 않고 최소한의 피칭 문서를 가지고 경영진을 설득해 개발 자금을 확보한 다음 엔지니어들을 고용해 우리들이 작성한 게임디자인 문서를 브리핑 하고 이 분들이 기계가 이해할 수 있는 고수준 언어를 통해 실제 동작하는 빌드를 만드는 과정을 의미합니다. 비록 인간, 혹은 게임디자이너가 이해할 수 있는 문서 수준에서 문제를 발견하기는 생각보다 어렵고 상당히 많은 생각의 깊이와 꽤 많은 경험을 요구하지만 완전하지 않은 반면 기계에게 고수준 언어로 기술한 코드를 컴파일 시킨 결과를 살펴보는 일은 훨씬 적은 요구조건 만으로도 수행할 수 있습니다.

소위 기획서에 기술된 기계가 이해하기에는 충분한 수준의 논리적 정합성을 갖추지 못한 요구사항들은 먼저 엔지니어들에 의해 고수준 프로그래밍 언어로 재해석 되는 과정에서 여러 가지 문제점을 노출하게 됩니다. 자연어로 문서를 작성할 때는 요구사항이 상황의 맥락을 기술하고 각 상황마다 주요 개체, 인터페이스, 데이터의 전환 과정을 다루는데 집중하곤 하는데 이 때 맥락을 기술하는 과정에서 실제 이 요구사항이 빌드로 만들어져 동작하도록 하기 위해 필요한 온전한 조건을 정의하지 않을 때가 많습니다. 일단 이런 문서를 기반으로 고수준 프로그래밍 언어를 통해 같은 내용을 재작성 하다 보면 동작을 고수준 언어로 표현하며 요구사항의 논리적으로 온전하지 않은 부븐들이 나타나며 이는 심지어 컴퓨터에게 컴파일을 시켜 보기 이전에 논리적 정합성이 강제되는 고수준 프로그래밍 언어의 제약으로 인해 컴파일을 시작할 수도 없는 상태를 만들거나 온전하지 않은 조건 구문을 억지로 마무리 해 실제 동작할 때 아주 간단한 예외에도 쉽게 망가지는 빌드를 만드는 결과로 이어지기도 합니다. 이 과정의 핵심은 사람이 작성한 소위 기획서는 빌드가 되기까지 두 단계에 걸친 논리적 정합성을 평가받고 또 보강하게 되는데 첫 단계로 엔지니어가 기획서를 읽고 이를 고수준 프로그래밍 언어로 변환하는 과정에서 논리적 정합성을 프로그래밍 언어가 요구하는 최소한의 수준으로 맞추기 위해 요구사항을 보강하는 것, 두 번째는 그 코드를 실제로 컴파일 해 동작하는 빌드를 만든 다음 그 빌드를 테스트 하며 여러 요구사항이 통합된 상태를 직접 확인하는 것입니다.

이런 과정을 통해 기획서의 논리적 정합성을 보강하고 여러 기획서에 기반한 요구사항이 빌드 하나에 합쳐저 동작할 때 일어나는 여러 충돌 상황을 실제로 살펴보고 이를 해결해 나가며 개발을 진행할 수 있습니다. 그리고 이는 특별한 과정이 아니라 게임 소프트웨어를 개발해 나가는 표준 절차에 가깝다고 생각합니다. 실제로 경험해 본 적은 없지만 게임 소프트웨어에 비해 훨씬 더 강력한 논리적 정합성, 동작의 엄밀함이 요구되는 소프트웨어 산업에서는 예전의 제가 기획서를 다 써놓은 다음 프로젝트를 시작할 거라는 말을 들은 것과 비슷하게 프로젝트의 아주 많은 부분에 대한 요구사항을 엔지니어가 거의 고수준 프로그래밍 언어로 바로 옮길 수 있을 것 같은 수준으로 정의한 다음 이를 여러 엔지니어들에게 배포해 개발을 시작한다고도 합니다. 가령 은행 인프라를 지탱하는 거대한 시스템을 개발할 때 설계 단계에서 시스템을 수많은 작은 모듈로 나누어 각각의 모듈의 입력과 출력을 정의한 다음 각 모듈의 요구사항을 각각의 엔지니어들에게 전달해 엔지니어들은 더 큰 시스템 전체를 상관하지 않고 자신에게 할당된 모듈의 동작에 정의된 입력과 출력을 맞추기만 하면 이들이 모여 전체 시스템이 동작하는 형태가 된다고 합니다. 게임 소프트웨어 개발 업계에서 이런 향태로 개발하기 어려운 이유는 게임 서비스를 구성하는 여러 소프트웨어를 구분하고 이들을 각기 다른 모듈로 구분할 수는 있지만 이들 각각의 요구사항이 온전히 결정되지 않은 상태로 프로젝트가 시작되고 개발을 진행하는 도중에도 시장의 변화, 경쟁 게임의 출시 같은 여러 가지 이유로 인해 요구사항이 바뀔 수 있기 때문입니다. 만약 이런 요구사항의 변화에도 불구하고 은행 인프라처럼 전체 시스템을 설계한 다음 개발을 시작한다면 분명 게임을 런칭할 수 있겠지만 그 시점의 시장에 알맞고 또 고객들로부터 사랑 받을 수 있는 결과를 도출할 수 있을지는 잘 모르겠습니다.

그런데 게임 소프트웨어를 개발하는데 기여하는 사람들의 인간성을 고려하지 않는다면 이런 식의 개발을 할 수 있습니다. 좀 더 엄밀한 동작을 요구하는 소프트웨어처럼 전체 시스템을 모듈로 구분하고 모듈 각각의 입출력을 정의하는 방식으로 설계한 다음 이들을 시스템 전체에 대해서 관심을 가지지 않는 엔지니어들에게 배포해서 개발할 수도 있고 게임 소프트웨어처럼 요구사항이 정확하지 않은 상태에서 개발을 시작할 경우 논리적 정합성이 떨어지는 소위 기획서에 기술된 요구사항을 고수준 프로그래밍 언어로 옮기는 과정에서 논리적 정합성을 보강하고 또 여러 요구사항이 통합되어 실제 동작하는 빌드를 테스트 하는 과정에서 이들 사이의 충돌을 발견하고 이를 고객에게 전달하기 전에 해결할 수 있습니다. 하지만 실제로는 이 과정에 참여하는 모든 주체들 각각이 사람이고 또 게임 업계에서는 이들 중 상당수가 자신의 취향을 가진 각각의 고객이라는 점에서 이렇게 논리적 정합성을 올려 가는 과정을 통해 개발을 이끌어나가기는 어렵습니다. 먼저 소위 기획서를 작성하는 사람들은 개발 과정에 참여하는 다른 사람들에 비해 상대적으로 게임디자인에 대해 더 많이 생각하고 이를 시스템으로 옮기고 또 자신의 욕망을 요구사항으로 전환해 이를 문서로 작성하는 훈련을 더 많이 하는 편이기는 하지만 이들 역시 자신의 욕망과 요구사항 사이의 차이를 충분히 이해하지 못할 때가 많습니다. 이들이 작성한 기획서는 분명 특정 동작을 요구하고 있지만 이 동작 그대로 구현해 놓은 다음 살펴보면 처음 문서를 작성하며 상상했던 것과는 다른 모양으로 느껴질 수 있는데 이 차이는 개인의 상상력, 욕망을 요구사항으로 바꾸는 능력, 논리적 정합성을 유지하는 능력 따위에 따라 나타납니다.

다음으로 이 기획서를 받아 고수준 프로그래밍 언어로 옮기는 엔지니어 역시 비슷한 상황에 놓입니다. 이들은 기획서를 작성한 사람들에 비해 상대적으로 논리적 정합성에 민감하고 컴퓨터가 동작하는 방식으로 생각하는 훈련을 반복하며 고수준 프로그래밍 언어로 표현하기 어려운 모호한 요구사항을 감지하고 이를 더 논리적 정합성을 가진 언어로 표현해줄 것을 요구하는 과정을 반복해 왔습니다. 하지만 이들 역시 일하는 시간 외에는 자연어를 사용해 주변과 의사소통하고 또 이들 역시 회사를 벗어나면 다른 게임의 고객으로써 자신의 취향과 게임에 대한 의견을 가지고 있을 가능성이 높기에 엔지니어들은 기획서에 나열된 요구사항을 곧이곧대로 고수준 프로그래밍 언어로 작성해 주지 않을 가능성이 높습니다. 직업적으로는 기획 부서에서 작성한 문서의 요구사항을 구현하는데 집중해야 할 책임을 가지고 있지만 이 문서들의 요구사항은 모호하고 종종 어제 집에서 플레이 해 본 다른 게임의 동작이 지금까지 개발해 온 빌드와 우리 프로젝트의 방향성에 더 어울리는 모양이라는 생각이 들 수 있으며 그 동안 컴퓨터가 생각하는 방식으로 생각하도록 오랜 시간에 걸쳐 훈련해 온 덕분에 굳이 여러 기능이 통합되어 구동되는 상태까지 가기 전에도 미이 며칠 전 읽은 기획서의 요구사항과 오늘 받은 기획서의 요구사항이 이미 기본적인 규칙 수준으로 서로 충돌한다는 사실을 훨씬 쉽게 눈치 챌 수 있습니다. 일단 개발이 시작된 상황에서 이런 상황을 해결하는 열쇠는 엔지니어가 쥐고 있지만 그들은 각자의 업무 일정에 제약을 받고 또 서로 다른 요구사항을 제출한 게임디자이너들과 상의해 자신이 예측한 충돌 가능성을 사전 조율하는데 익숙하지 않을 수 있습니다.

이런 배경에서 다시 게임디자이너 관점으로 돌아와 게임디자이너는 자신이 원하는 요구사항을 문서 모양으로 작성한다 하더라도 항상 그 요구사항 그대로 동작하는 빌드를 받지 못할 가능성이 높다는 사실을 인지해야 합니다. 먼저 이 요구사항은 요구사항 하나의 스코프 안에서는 논리적 정합성을 확보하고 또 고객들에게 줄 경험에 대한 기여를 예측할 수 있을지도 모르지만 같은 일을 하는 다른 사람의 문서를 포함해 넓어진 스코프에서는 요구사항이 서로 충돌해 이상한 결과를 만들어낼 수 있습니다. 만약 이런 상황을 엔지니어가 발견한다면 게임디자이너 각자의 요구사항을 서로 충돌하지 않는 모양으로 수정하거나 때로는 둘 이상의 게임디자이너가 작성한 요구사항을 하나로 통합한 결과로 요구사항을 재정의한 다음에야 개발을 시작해야 할 수도 있습니다. 또 앞서 설명한 대로 엔지니어들 각각은 그 자신이 다른 게임의 고객일 가능성이 높기에 그들이 생각하기에 자신들의 예상보다 더 나쁜 동작을 할 것으로 예상되는 요구사항에 문제를 제기하고 적어도 엔지니어 자신이 생각하기에 이보다는 더 나은 동작을 하는 요구사항으로 수정해 줄 것을 요구할 수도 있습니다. 이런 과정을 통해 게임디자이너는 빌드를 돌려받더라도 그 빌드가 처음 기획서에 기술한 요구사항과는 상당히 다른 형태일 수 있고 심지어 완전히 다른 기획서에 근거한 동작을 보이는 결과일 수도 있다는 사실을 인정하고 각 요구사항을 문서에 기술할 때 이런 실제 과정을 고려해야 합니다.

이전에 개발에 참여한 적 있는 한 모바일 MMO 게임은 중간에 보상 정책이 완전히 바뀌어 상당한 어려움을 겪은 적이 있습니다. 처음 보상 규칙을 설계할 때는 각 몬스터가 지정된 보상을 드랍하는데 보상 각각을 지정할 때는 실제 드랍될 아이템, 수량, 아이템 자체가 드랍될 확률, 수량이 결정될 확률 따위를 각각 설정할 수 있었습니다. 이 보상 규칙은 아주 단순했지만 순식간에 비슷한 사람들이 진행하는 다른 요구사항과 충돌했는데 가령 파티릴 이뤄 사냥하는 도중에 보상이 드랍 될 경우 이를 어떻게 처리해야 하는지를 정의해야만 했습니다. 초기 MMO 게임들은 이런 상황에도 정직하게 몬스터는 자신에게 설정된 보상을 바닥에 떨어뜨린 다음 저 세상으로 떠나는데 이 때 바닥에 떨어진 보상은 딱히 권한이 설정되어 있지 않아 근처에 있는 누구나 이 보상에 접근할 수 있었습니다. 이런 규칙은 실제 세계의 동작과 아주 비슷하고 이해하기 쉬우며 만들기도 쉽지만 고객들 사이에 분쟁을 자주 일으키는 요소로 동작했는데 몬스터가 죽는데 더 많은 기여를 한 파티원이 전투에 덜 집중하면서도 보상에만 더 집중한 다른 파티원보다 더 적은 보상을 받을 가능성이 항상 있었고 심지어 주변에 서 있던 다른 사람들이 상습적으로 다른 사람의 보상을 주워 가는 일도 일어나곤 했습니다. 이 상황은 고객들을 굉장히 화나게 만들었기 때문에 몬스터가 보상을 드랍 할 때 보상은 몬스터에게 가장 큰 공헌을 한 사람에게 우산 드랍되고 기여 순서에 따라 각기 다른 보상을 드랍하는 방식으로 만들고 여기에 체력 회복과 같은 지원 역할을 한 사람이 소외되지 않도록 하는 규칙을 보강한 다음 각기 다른 사람들이 서로 다른 퀘스트를 하고 있을 때 퀘스트에 의한 아이템이 드랍되도록 규칙을 조정하는 등등등등등의 요구사항 보강을 통해 통합된 하나의 보상 요구사항이 완성됩니다.

여기까지가 초창기 MMO 게임의 보상 규칙이 아주 조금 발전한 결과인데 시간이 지나며 몬스터가 자신에게 지정된 보상 뿐 아니라 좀 더 광범위한 보상을 드랍하게 만들어 큰 성공을 거둔 사례들이 나타납니다. 이들은 몬스터 각각이 자신에게 설정된 보상을 드랍 하기도 하지만 보다 광범위한 보상 목록으로부터 낮은 확률로 더 가치가 높은 보상을 드랍할 가능성이 있도록 설정됩니다. 가령 지금까지는 마을 앞마당에 있는 잡몹들을 아무리 오랫동안 사냥해도 이들에게 설정된 최소한의 보상보다 더 많은 보상을 기대할 수 없었습니다. 이들은 영원히 자신들에게 설정된 아이템 중 일부를 확률에 따라 드랍 할 뿐이었기 때문입니다. 그렇게 사냥터가 버려지고 모든 사람들이 훨씬 큰 보상을 주는 던전 안으로 사라지면서 퍼시스턴트 월드에는 아무도 오가지 않게 되어 분명 많은 사람들이 게임을 플레이 하고 있음에도 정작 아무도 볼 수 없는 기묘한 상황이 이어졌습니다. 또 던전이 아닌 곳에서 굳이 자원을 소모해 가며 전투를 할 이유도 없어집니다. 하지만 전 세계에 걸친 몬스터들이 낮은 확률로 훨씬 더 광범위한 목록에 기반한 보상을 드랍하기 시작하면서 비록 확률이 낮다는 사실을 알지만 마을 바깥에 있는 약해 바진 비선공 몬스터들로부터도 오직 던전 안에서만 구할 수 있었던 가치가 더 높은 아이템을 구할 가능성이 생겼고 고객에 따라 더 높은 위험을 감수하는 대신 더 높은 확률의 보상을 노리는 사람들과 더 낮은 위험만 감수하는 대신 더 낮은 확률의 보상에 동의하는 사람들로 플레이 스타일이 나뉩니다.

이런 상황에서 앞서 설명한 전통적인 형태의 보상 규칙을 만든 다음 이에 따라 데이터를 집행하고 이미 충분히 개발된 상태에서 어느 날 갑작스레 이어서 설명한 형태의 보상을 집행하라고 하면 큰 문제가 생깁니다. 근본적으로 이는 두 번째 소개한 방법을 수용할 수 있도록 보상 체계를 수정하고 이에 맞춰 빌드를 고쳐야 하는 상황입니다. 앞서 개발 과정을 설명한 언어로 표현해 보면 새로운 요구사항과 기존에 구현된 요구사항이 서로 충돌하는 상황이어서 이들을 통합하는 요구사항을 게임디자이너가 자연어를 사용해 기획서 모양으로 작성한 다음 이를 이해한 엔지니어가 고수준 프로그래밍 언어를 통해 컴퓨터가 이해할 수 있는 모양으로 작성하되 이 과정에서 기존에 구축되어 있던 보상 규칙과 새로 입력하는 보상 규칙을 서로 통합한 모양으로 만들어야 합니다. 이 과정은 새로운 요구사항을 구현할 때보다 훨씬 난이도가 높은데 이미 기존에 개발이 완료되어 작동하던 코드를 다시 읽고 새로운 요구사항을 반영하기 위해 수정해야 할 부분을 특정한 다음에야 작업을 시작할 수 있기 때문입니다. 이는 코드를 처음부터 작성할 때에 비해 난이도가 훨씬 높고 심지어 기존 동작을 유지한 채 새로운 요구사항을 받아들여야 할 경우 작업 난이도를 훨씬 높입니다.

흥미롭게도 당시 우리들은 경영진 보고 직전에 이 요구사항을 접수했고 엔지니어의 도움을 청할 수 있는 상황이 아니어서 훨씬 광범위한 몬스터들을 대상으로 한 주로 낮은 확률로 구성된 새로운 보상 목록을 사용하는 로직을 새로 개발하는 대신 마치 그렇게 동작하는 것처럼 보이도록 몬스터 각각마다 낮은 확률로 구성된 새로운 보상 목록을 각각 추가해 모든 몬스터 하나하나를 처치할 때마다 각자에게 설정된 거대한 보상 데이터를 처리한 다음 최종 보상을 결정할 수 있는 모양으로 데이터를 입력합니다. 실제 동작하는 데이터를 열어 보지 않는 이상 이 결과는 새로운 시스템을 도입한 것과 외형 상으로는 구분할 수 없었고 우리들은 무사히 경영진 보고를 넘겼지만 이 상태는 개발팀에 문제를 좀 일으킵니다. 일단 몇몇 사람들이 그들이 경영진 보고 직전에 내린 명령이 순식간에 데이터를 통해 그리 효율적이지 않은 방법을 통해 실행되는 모습을 직접 보았으면서도 이미 새로운 보상 규칙에 필요한 코드가 이미 작성되어 구동되고 있는 거서처럼 착각해 이미 이 보상 규칙이 완성된 다음 정상적으로 수행할 수 있을 것 같은 요구사항을 늘어놓았습니다. 또 이전에 한번에 그렇게 많은 보상 데이터가 몬스터 하나하나마다 들어갈 것을 고려하지 않은 보상을 표시하는 인터페이스, 보상을 읽어들이는 코드 등 게임 곳곳에서 여러 가지 문제를 일으킵니다. 사실 이들은 근본적으로 새로운 보상 규칙의 요구사항을 자연어로 작성하고 이를 구현하고 여기 맞춰 데이터를 입력하는 표준 과정을 다시 진행하면 정상적으로 해결할 수 있었지만 여러 가지 정치적 상황으로 인해 경영진 보고를 위해 급하게 입력한 겉보기에는 새로운 보상 규칙이 적용되어 동작하는 것처럼 보이는 상태를 기준으로 발생하는 여러 충돌 상황을 수정하는데 집중하는 방향으로 개발이 진행되었고 나중에는 새 보상 규칙을 다시 개발하는 것에 비해 훨씬 높은 비용을 들였음에도 게임디자이너, 엔지니어, 경영진 그 누구도 만족하지 못하는 이상한 결과로 귀결되고 말았습니다.

한편 이런 상황 속에서는 어지간히 경험이 쌓인 게임디자이너라도 자신의 욕망을 투영하는 요구사항을 기술한기획서를 가지고 개발을 진행시키기 아주 어렵습니다. 게임디자이나 개개인이 현실을 충분히 자각하고 있다 하더라도 현실 감각이 떨어지는 경영진이나 고위 의사결정자로부터 내려오는 얼토당토않은 요구사항을 기술해 개발을 진행 시키는 과정에서 이미 너무 많은 에너지를 소모해 버리곤 하기 때문에 좀 더 미래를 바라본 요구사항을 작성할 기회를 잡기 쉽지 않습니다. 엔지니어들 역시 게임디자이너들이 작성한 요구사항으로부터 이미 다른 기능과 충돌 가능성, 더 나은 방법 따위를 제안할 수 있을 것 같지만 마일스톤 목표 달성이나 경영진 보고 일정 같은 다른 이유 대문에 게임디자이너와 엔지니어 사이의 이터레이션을 통해 충분히 개선할 수 있는 그저 그런 요구사항을 그저 고수준 프로그래밍 언어로 옮기는데 집중하며 에너지를 잃어버릴 수 있습니다. 이런 상황이 지속되다 보면 게임디자이너, 엔지니어 양쪽 모두 그들이 원래 수행해야 하는 보다 긴 시각에 기반한 요구사항 도출과 자연어를 사용한 기술, 보다 컴퓨터가 생각하는 방식으로 생각하도록 훈련된 기반 위에서 서로 다른 요구사항들이 충돌하거나 고객으로써 알고 있는 더 나은 방식에 대한 제안을 거쳐 중장기적으로 비용을 줄일 수 있는 방법이 동작하지 않게 되는데 이 상황 속에서는 개발에 참여한 각자가 서로를 신뢰하지 못하는 상태에 이릅니다.

여기까지 상황이 발전하면 종종 엔지니어들이 게임디자이너들의 제안을 거부하는 상황에 이르는데 앞서 이터레이션의 열쇠를 엔지니어들이 가지고 있기에 이들에게 더 많은 권한과 시간을 부여해 요구사항을 개선할 수 있다고 말한 것과 같이 이들이 게임디자이너들의 그저 그런 제안을 거부하기 시작하면 개발 전체를 아주 쉽게 지연 시킬 수 있습니다. 프로젝트가 한번 이런 상태에 빠지면 인원을 전부 교체해야 간신히 해결할 수 있을 정도로 해결이 어려운 상태에 빠지지만 그렇다고 실제로 그런 방법을 실행할 수 있는 조직은 소수입니다. 물론 실제로 그런 해결 방법을 실행해 프로젝트를 위기 상태로부터 벗어나게 만드는 결과를 얻은 사례가 없지는 않지만 이는 구성원들 모두에게 지나치게 가혹하고 치명적입니다. 대신 게임디자이너 관점에서 목적을 숨긴 빌드업을 통해 거절될 가능성이 높은 쉽게 실제 목적을 인식할 수 있는 모양의 요구사항 대신 실제 요구사항을 전체 모습을 짐작하기 쉽지 않은 여러 가지 모양으로 분리한 다음 각각의 논리적 정합성을 갖춰 개발을 진행하는 방식으로 프로젝트 전체에 치명적인 수단을 사용하지 않는 범위 안에서 개발을 진행할 수 있습니다. 전체 의도를 함부로 노출하지 않는 방식으로 요구사항을 작성하는 가장 큰 이유는 엔지니어 조직에서 게임디자이너의 뻔한 요구사항을 받아들이기를 때때로 거절하는 상황에서 의도를 쉽게 읽히는 모양의 요구사항은 더 높은 확률로 거절 될 수 있기 때문입니다.

가령 우리가 만드는 게임에 특정 게임의 보상 규칙을 추가해야만 하는 상황이지만 이미 앞서 여러 차례의 정치적인 문제 때문에 어쩔 수 없이 진행한 고통스러운 개발 경험 때문에 게임디자인을 불신하고 어지간한 요구사항을 거절하게 된 엔지니어들과 일해야 할 대 특정 게임의 보상 규칙을 추가해야 한다고 곧이곧대로 요구사항을 작성한 기획서로 대화를 시작하면 큰 어려움에 처할 수 있습니다. 이미 엔지니어들은 다른 게임의 고객으로써 보상 규칙을 가져오려는 게임에 대해 알고 있고 이 의사결정이 그리 올바르지 않다고 생각할 수 있습니다. 가장 좋은 방법은 정면으로 대응해 의사결정이 올바름을 설득하는 것이지만 자원이 부족한 상황에서 이런 선택은 오히려 게임디자이너와 엔지니어 양쪽 모두의 성과를 망가뜨리는 결과로 끝날 수 있습니다. 때문에 게임디자이너 관점에서 특정 게임의 보상 규칙을 눈에 잘 띄지 않는 몇 가지 조각으로 나눠 서로 다른 요구사항으로 포장해 전달하고 이들 각각이 별도로 개발되도록 만든 다음 나중에 이들을 조립해 실제 의도에 맞는 기능으로 완성 시키면 엔지니어들과 직접 맞서지 않고서도 요구사항을 달성하고 양쪽 모두의 성과를 유지할 수 있습니다. 그리고 다행스럽게도 이런 과정을 거치다 보면 상황이 개선되어 이전보다는 좀 덜 의도를 숨긴 상태의 요구사항을 개발할 수 있게 됩니다.

진짜 목적을 숨긴 요구사항을 빌드업 하기 위해 완전히 다른 이야기부터 시작해 꽤 멀리 돌아 왔습니다. 처음에는 게임디자이너 관점에서 게임 소프트웨어를 설계하는 방식의 특성에 대해 살펴봤습니다. 어떤 소프트웨어는 훨씬 많은 부분을 미리 설계한 다음 개발을 시작하는 방식으로 개발되지만 게임 소프트웨어는 그 특성 상 그와 같은 개발 방법을 사용하기는 어려워 보입니다. 대신 게임디자이너 스스로, 그리고 엔지니어 스스로가 여러 파이프라인에 걸쳐 개발이 진행되는 여러 가지 요구사항에 대한 전문성을 갖추고 실제 빌드 단계에 도달하기 전에 각자의 전문성에 기반해 대안을 제시하고 의사소통 과정을 통해 요구사항을 수정한다면 더 나은 결과에 도달할 수 있습니다. 하지만 여러 가지 정치적인 이유 때문에 이런 이상적인 개발을 하기는 어려우며 꽤 자주 서로를 대하는 에너지가 사라져 한계에 다다르고 요구사항을 신뢰하지 못해 개발을 거부하는 상황에 처할 수 있습니다. 이런 상황을 극단적으로 해결하는 방법은 이런 문제에 빠진 모든 인원을 교체하는 것이고 실제 성공한 사례가 여러 건 있지만 이 방법은 각각에게 가혹하고 치명적입니다. 대신 게임디자인 관점에서 진짜 목적을 숨긴 채 요구사항을 분해해 각각의 개발을 진행 시키고 결국 이들을 빌드업 해 원래 목표로 삼은 요구사항을 조립해 낼 수도 있습니다. 이는 게임디자인에 가혹할 수 있지만 프로젝트 전체를 유지한 상태로 신뢰가 부족한 상태의 프로젝트로부터 성과를 도출하는 한 가지 방법입니다.