데이터에 숨겨진 동작이 없기를 원해요

제 직업은 게임디자이너입니다. 어쩌다 보니 게임의 여러 요구사항이 올바른 방법으로 협업 부서에 전달되도록 산발적인 요구사항이 일관된 규칙에 기반하도록 설계하는 역할을 하기도 하고 또 어쩌다 보니 주로 엔지니어 부서와 의사소통을 담당하는 역할을 하기도 하지만 저는 엔지니어가 아닙니다. 종종 제 일을 더 빨리 하기 위해, 다른 사람이 그럴 필요 없는 일에 시간을 낭비하지 않도록 하기 위해, 명백히 기계가 더 잘 할 수 있는 일을 사람이 하고 있지 않도록 하기 위해 제한적으로 코드를 만들 때가 있기는 하지만 코드를 만드는 일이 제 주 업무가 아닙니다. 그런 적이 한 번도 없는 것은 아니지만 개인적으로는 엔지니어가 아닌 사람이 작성한 코드가 프로덕션에 들어가는 상황은 올바르지 않다고 평가합니다. 코드를 전문적으로 작성하도록 고도로 훈련 받은 엔지니어가 아닌 사람이 프로덕션 코드를 작성할 일이 발생하고 또 이 코드가 실제로 프로덕션에 영향을 끼친다면 이는 부서 별 업무 분배에 실패했다고 판단하고 개입해서 상황을 바로잡아야 한다고 생각합니다. 이런 관점에서 우리들은 코드를 작성할 필요가 없고 특히 프로덕션 코드를 작성해서는 안됩니다. 그렇다고 엔지니어들이 코드를 작성하기 위해 공부하는 여러 지식과 훈련에 관심을 가지지 않아야 한다는 것은 아닙니다. 근본적으로 우리들은 소프트웨어 개발업에 종사하고 있고 이 업계의 근간은 전산학의 발전에 뿌리를 두고 있기 때문에 우리가 직접 프로덕션 코드를 작성하지 않더라도 여기 관여하는 지식의 일부를 알고 있으면 게임디자인 업무를 수행하는데도 도움이 됩니다.

가령 우리들은 게임에 컨텐츠를 추가하고 여러 동작을 변경하기 위해 엑셀을 널리 사용합니다. 워낙 오랜 세월에 걸쳐 변함 없이 사용해 온 덕분에 다른 소프트웨어 개발 분야에서도 사용하고 있지 않을까 생각했지만 로직을 데이터 모양으로 표현한 간단한 스킬 시스템을 작성하며 둘러보니 소프트웨어에 우리들처럼 많은 옵션을 제공하고 또 우리들처럼 폭넓게 컨텐츠를 추가할 수 있는 환경을 제공하는 분야는 우리들 자신 밖에 없을 가능성이 높다는 사실을 알게 됩니다. 우리들이 엑셀에 입력한 데이터는 변환을 거쳐 아주 빠른 응답이 필요할 경우 아예 코드에 포함되어 항상 메모리를 통해 접근할 수 있는 위치로 이동하기도 하고 그보다는 덜 빠른 응답으로도 충분하고 또 데이터의 양이 많으면 관계형 데이터베이스로 이동하기도 합니다. 그렇다 보니 우리들이 엑셀에 별 생각 없이 입력하는 여러 데이터는 결국 코드나 데이터베이스 모양으로 변경될 운명이기에 이들로 변환될 것을 감안한 모양으로 입력하곤 합니다. 가령 맨 앞에 모든 행에 유일한 숫자를 넣어야 하거나 특수한 경우에는 그렇지 않을 때도 있지만 웬만하면 엑셀의 한 셀에는 한 가지 데이터만 입력해야 하고 또 첫 행에는 칼럼 이름이 있어야 하고 또 규칙에 따라 셀을 병합해 묵시적으로 엑셀 칼럼에 일종의 네임스페이스를 부여하기도 합니다. 지난 왜 데이터를 입력할 때 엑셀을 사용할까?에 우리가 주로 데이터를 입력할 때 엑셀을 사용하는 이유를 살펴봤는데 그 이유 중 하나가 바로 지금까지 언급한 엑셀 데이터가 엔지니어들의 영역에서 여러 가지 다른 모양으로 변환되어야 하기 때문이고 또 변환하기 쉬운 모양으로 쉽게 만들 수 있기 때문입니다. 이 과정에 데이터베이스, 데이터베이스를 텍스트 모양으로 표현하는 여러 가지 방법이 관여하고 있다는 기반을 알고 있으면 앞서 코드를 작성하지 않는 직업을 가지고 있으면서도 도움을 받을 수 있는 것과 비슷한 도움을 받을 여지가 있습니다.

근본적으로 우리가 기획서 모양으로 제시한 요구사항을 클라이언트, 서버 환경에 구현하기 위한 설계는 엔지니어들의 몫이지만 우리가 요구사항을 데이터 모양으로 표현해 미래에 이 모양으로 게임에 컨텐츠를 추가하고 게임의 여러 동작을 변환하기를 원한다면 엑셀 데이터는 우리들이 설계합니다. 이전에 함께 일하던 엔지니어님과 이런 저런 이야기를 하다가 근본적으로 게임디자이너 직군이 엑셀 데이터구조를 제안하는 행동이 적절한지에 대해 의견을 나눈 적이 있습니다. 게임디자인 직군 사람들 중에는 종종 학교에서 기초 과목으로 자료구조와 관계형 데이터베이스 과목을 수강한 사람이 없지는 않습니다. 하지만 모든 게임디자인 직군 사람들에게 이 지식을 요구하고 강제할 수는 없습니다. 그러면서도 이들 모두에게 종종 기획서를 작성할 때 미래에 자신이 요구사항을 입력할 데이터구조를 자료구조나 관계형 데이터베이스 지식이 전혀 없는 사람들이 그저 다른 사람들이 이미 만들어 놓은 엑셀 파일을 살펴보고 흉내내도록 하는 업무 방식이 올바른지 서로 같은 의문을 가지고 있었습니다. 여러 이야기 끝에 이상적으로는 게임디자인에서는 논리적으로 올바르고 다른 기능과 충돌하지 않는 게임디자인을 고안해 이를 문서로 만드는데 집중하되 여기에는 엑셀 데이터구조 같은 보다 전문적인 지식을 요구하는 영역을 포함하지 않아야 하고 이는 보다 전문적인 지식과 경험을 가진 엔지니어들의 몫이 되어야 한다는데 의견을 모읍니다. 그러나 현실적으로 이렇게 일할 수 없습니다. 일단 엔지니어들은 우리들의 예상보다 훨씬 엑셀에서 일어나는 일을 잘 모르는 경우가 많은데 항상 코드 에디터와 게임 엔진, 서버 콘솔로 화면을 가득 채운 세계에서 살아 가는 사람들에게는 당연한 일입니다. 엑셀 파일은 이미 데이터 컨버팅 프로그램에 의해 엔지니어에게 익숙한 모양으로 바뀐 다음이므로 이 데이터가 엑셀에 어떤 모양으로 보일지 크게 신경 쓸 필요가 없습니다.

이런 상황이다 보니 우리들이 사용할 엑셀 워크시트 모양을 설계하는데 필요한 지식이 충분하지 않은 사람들이 워크시트를 정의할 수밖에 없고 이 과정에서 나온 설계는 엔지니어 관점에서 볼 때 이해할 수 없는 모양이거나 좀 더 나아가면 의도를 잘못 이해하게 만들 가능성도 있습니다. 그래서 개인적으로는 어쩔 수 없이 게임디자인 직군 중에서 특히 장차 게임디자인 직군 내 다양한 사람들이 사용하게 될 엑셀 워크시트를 설계할 일이 자주 일어나는 사람들은 이들이 직업적으로 코드를 만드는 사람이 아니며 프로덕션 코드를 만들어서도 안되지만 자료구조와 관계형 데이터베이스, 혹은 관계형 데이터베이스에 대한 기초적인 지식만이라도 갖추기를 권하는 입장입니다. 모든 사람들에게 이를 요구할 수는 없지만 이 일을 자주 하는 사람들에게는 이 지식이 큰 도움이 될 뿐 아니라 근본적으로 게임디자인에서 엔지니어들의 코드를 거쳐 고객에게 도달하는 게임의 동작 사이를 연결하는 데이터 파이프라인을 이해하는데도 큰 도움이 되는 것은 사실입니다. 또 개인적으로 왜 데이터를 입력할 때 엑셀을 사용할까?에 설명한 칼럼 이름 셀을 병합해 묵시적인 네임스페이스를 만들어 사용하는 방식을 선호하는데 이는 저 글에서 설명한 대로 일종의 NoSQL 데이터베이스의 도큐먼트 모양과도 비슷하게 데이터를 편한 모양으로 기술할 수 있기 때문입니다. 제 관점에서 칼럼을 병합해 데이터를 표현하는 방법은 너무 쉽게 이해할 수 있었고 떠 너무나 편안하게 데이터를 표현할 수 있었지만 모든 사람에게 그런 것은 아니었습니다. 같은 방식을 사용해 개발했던 프로젝트를 총괄했던 분은 그 분의 다음 프로젝트에서 이 방식을 완전히 철회하고 이전과 같이 한 칼럼에는 한 가지 데이터만 존재하는 방식으로 돌아갑니다. 그 때는 도무지 이해할 수 없는 결정이라고 생각했는데 한참 지난 다음에야 당시 여러 조직이 셀을 병합해 묵시적인 네임스페이스를 부여한 모양으로 만들어진 엑셀 데이터를 이해하지 못해 어려움을 겪는 조직과 사람들이 있었다는 사실을 알게 됩니다. 어떤 사람들이 이해하고 이를 편안하게 사용한다고 해서 모든 사람들이 그렇지는 않으며 또 그렇게 만들기가 사실상 불가능하다는 교훈을 얻었습니다.

한편 관계형 데이터베이스 같은 기초과목에 종종 등장하는 별도의 과목이 존재하는 경우도 있지만 그렇지 않은 지식 역시 알아두면 도움이 되기도 합니다. 저는 여전히 코드를 작성하는 사람이 아니고 함수형 프로그래밍 언어로 코드를 만들 일은 더더욱 없습니다. 하지만 함수형 프로그래밍 언어의 특징과 주요 스펙을 살펴보며 한 가지 교훈을 얻었는데 코드에 숨겨진 동작을 만들지 않으려고 노력해야 한다는 것입니다. 가령 어떤 대상의 현재 상태를 숫자로 반환하는 함수가 있을 때 함수형 프로그래밍 언어 관점에서 이 함수는 오직 대상의 상태를 확인한 다음 이를 돌려주는 역할만 해야 합니다. 그런데 만약 이 함수 내부에서 여러 목적으로 자신의 동작을 파일에 기록하거나 상태를 확인할 대상에 영향을 끼치는 어떤 동작이 포함되어 있다면 이 함수는 숨겨진 동작이 있다고 볼 수 있습니다. 마치 파동함수가 붕괴되기 전 양자는 파동의 성질을 보이지만 관측을 통해 상호작용을 일으킨 다음에는 입자의 성질을 보이는 것처럼 관측 행위가 대상의 상태를 바꾸는 것과 비슷하다고 볼 수도 있을 것 같습니다. 함수는 그 이름과 주고 받을 수 있는 인자들의 스펙으로부터 대상의 상태를 확인해 반환하는 역할만을 할 거라고 예상할 수 있지만 내부적으로는 자신의 동작을 파일에 쓰는 등 예상하지 않은 동작을 포함하고 있어 나중에 문제를 해결하는데 어려움을 겪게 할 수 있습니다. 가령 그저 대상의 상태를 반환하는 함수일 뿐이지만 파일시스템 접근에 실패할 때 대상의 상태를 반환하지 못할 수 있으며 이 문제를 해결하기 위해 상태를 가져오기 위한 대상이 올바른 상태인지부터 확인하기 시작할 테지만 결국 숨겨진 동작인 파일에 쓰는 행동으로부터 문제가 일어났음을 알아채는데까지는 시간이 걸릴 수밖에 없습니다. 아마도 이런 이유로 함수형 프로그래밍 언어는 특별히 숨겨진 동작을 만들지 않는 원칙을 가지고 있는 것 같습니다.

이 원칙은 굳이 코드를 만들지 않아고, 함수형 프로그래밍 언어를 사용하지 않아도 그저 엑셀 데이터구조를 만들고 제안하는 우리들에게도 교훈을 줍니다. 종종 다국어 지원 역시 엑셀을 사용할 때가 있습니다. 게임의 온갖 장소에서 사용되는 텍스트를 엑셀 파일 하나에 모아 놓고 각각의 키에 해당하는 값을 바꿔 여러 가지 언어를 지원하도록 만들곤 합니다. 게임에는 한번에 많은 데이터가 다국어를 지원해야 하는 경우가 자주 생깁니다. 가령 아이템 1천개가 있다면 이들 각각의 이름, 설명이 다국어에 대응 되어야 합니다. 이들 하나하나에 다국어 지원 엑셀 테이블의 키를 발급하기는 조금 귀찮으므로 어떤 프로젝트들은 다국어 엑셀 파일에 키를 발급하는 묵시적은 규칙을 만들고 다국어 시스템이 이 규칙에 따라 행동하도록 만들기도 합니다. 새로운 아이템을 정의할 때 아이템 이름과 설명 텍스트는 특별히 정의하지 않아도 미리 약속한 암묵적인 규칙에 따라 Item_{Item.Id}_Name, Item_{Item.Id}_Description에 입력하고 프로그램 역시 이 키에 의존해 텍스트를 찾아 보여주기로 합니다. 이 약속은 한동안 잘 동작하는 것처럼 보이지만 시간이 지나 담당자가 바뀌고 누군가 그만 두고 또 새로운 사람들이 들어오면서 조금씩 망가지기 시작합니다. 분명 어딘가의 문서에 이 규칙이 언급되어 있을 수도 있지만 이 문서의 존재조차 잊힐 시점이 되면 어느 날 게임 상에 새로 추가된 아이템의 이름과 설명이 안 나오는 문제를 겪게 됩니다. 하지만 지난날의 약속을 기억하는 사람이 없으면 이 간단한 약속을 지키지 않은 오동작을 찾기 위해 QA 부서에서 문제를 발견하고 담당 게임디자이너에게 지라가 날아와 이를 재현하며 원인을 찾지 못하는데 시간을 보낸 다음 엔지니어에게 전달되어 코드를 스텝 별로 따라간 다음에야 지난날의 약속을 찾아낼 수 있을텐데 이 과정 역시 시간을 필요로 합니다.

한번은 상호작용 기능을 확장하는 기획서를 검토하다가 거의 본능적으로 나쁜 냄새를 풍기는 부분에서 스크롤을 멈췄습니다. 사실 요즘에 기획서를 어떻게 검토하고 있는지 설명하기 쉽지 않습니다. 이전에는 주로 눈여겨 보는 몇 가지 부분에 집중하고 나머지는 게임디자이너의 판단에 맡기며 눈여겨 보는 항목을 설명할 수 있다고 생각했는데 시간이 지나며 이 행동이 점점 본능적이고 감각적인 모양으로 변하고 있는 것 같습니다. 그래서 별 생각 없이 문서를 살펴보다가 그냥 신경 쓰이는 부분에서 스크롤을 일단 멈춘 다음 왜 제가 스크롤을 멈췄는지 그 부분을 신경 써서 읽기 시작한 다음에야 스크롤을 멈춘 원인을 발견하곤 합니다. 이렇다 보니 제가 과연 올바르게 문서를 검토하고 있는지 점점 자신이 없어지고 있습니다. 그래서 문서를 검토할 때 내용을 확인한다기 보다는 나쁜 냄새가 나는 곳이 있는지 살펴보는, 거의 냄새를 맡아보는 수준에 가까운 행동을 하고 있다고 생각합니다. 어쨌든 이번에 감지한 나쁜 냄새는 데이터구조로부터 나고 있었는데 이전에 구축한 상호작용 방식에 한 가지 형태를 추가하려고 하고 있었습니다. 이전에 구축한 상호작용은 상호작용이 일어나는 동안 플레이어캐릭터가 상호작용 대상에 계속해서 가까이 있어야 했습니다. 가령 바닥에 놓인 상자를 열기 위해 상자에 성호작용 하면 상자가 열리는 동안 상자를 여는 애니메이션이 재생되는 상태를 유지해야 하고 상자가 완전히 열리기 전에 다른 조작을 입력하면 상호작용에 실패해 상자를 처음부터 다시 열어야 하도록 만들어져 있었습니다. 그런데 여기에 이제 상호작용을 시작한 다음 조작을 입력해 그 자리를 떠나더라도 일단 시작된 상호작용으로부터 비롯된 동작이 끝나지 않기를 바랬고 이 바램이 데이터구조에 반영되어 있었습니다.

그런데 상호작용 진행 중 조작에 의해 상호작용이 취소되는 경우와 취소되지 않아야 하는 경우는 각각 서로 완전히 다른 용도로 사용될 예정이었는데 가령 상자를 열기 위해서는 상자 뚜껑이 완전히 열릴 때까지 상자 앞에 서 있어야 했지만 뭔가를 호출하는 호출 버튼을 누른 다음에는 호출 대상이 도착할 때까지 그 자리에 가만히 서 있을 필요가 없었습니다. 기획서는 데이터구조는 칼럼을 추가해 상자와 비슷한 타입일 경우 지정된 시간 동안 기다려야 하고 호출 버튼과 비슷한 타입을 경우 지정된 시간 동안 기다려야 하지만 이 사이에 다른 조작을 입력해 상호작용 대상으로부터 벗어날 수 있도록 동작하도록 정의하고 있었는데 사실 내용만으로 보면 딱히 이상하지 않은 것이 사실입니다. 어차피 앞으로도 상자와 비슷한 물건은 항상 상호작용이 일어나는 시간 동안 캐릭터가 움직이지 않고 상호작용 대상 주변의 같은 위치를 유지하는 모양으로만 동작할 예정이고 또 호출 버튼과 비슷한 물건은 항상 일단 아주 짧은 상호작용이 끝나고 나면 동작이 완전히 끝날 때까지 시간이 걸리므로 상호작용 대상으로부터 벗어나는 동작만을 필요로 했습니다. 때문에 이들을 타입으로 구분한 다음 상자 타입이면 상호작용 시간 동안 플레이어가 자리를 지켜야 하는 모양으로 동작하고 호출 버튼 타입이면 상호작용을 시작한 다음 플레이어가 자리를 떠나도 되는 방식으로 동작하도록 해 달라고 엔지니어에게 요구하면 엔지니어 역시 별 문제 없이 설정된 타입에 따라 다른 동작을 하는 코드를 작성해 줄 것 같습니다. 그런데 이 엑셀 데이터는 엑셀 데이터를 주로 보고 일해야 하는 게임디자이너 입장에서 동작을 타입으로만 구분하면 앞서 설명한 함수형 프로그래밍 언어에서 주로 피하라고 가르치는 숨겨진 동작을 의도하지 않게 만들게 됩니다. 게임디자이너들은 대체로 보안 상의 이유로 코드에 접근할 수 없는 경우가 많기 때문에 오직 엑셀 데이터시트만 보고 데이터의 게임 내 동작을 예측해야만 합니다. 그런데 타입을 통한 구분은 엑셀 데이터만으로는 동작을 짐작할 수 없어질 수 있습니다.

앞서 소개한 엑셀을 사용한 다국어화 과정에서 아이템 이름과 설명을 나타내는 키를 암묵적인 약속을 통해 생성할 때 일어나는 일과 비슷한 일이 일어나게 됩니다. 처음에는 서로 다른 두 가지 타입 설정에 따라 상호작용 시간 동안 기다리는 방식이 서로 다르다는 사실을 게임디자이너와 엔지니어 양쪽 모두 잘 알고 있을 겁니다. 또한 이 사실이 문서에 잘 언급되어 있기 때문에 한동안은 이 방식에 아무런 문제가 없는 것처럼 보일 수 있습니다. 하지만 시간이 흐르며 똑같이 담당자가 바뀌고 또 누군가가 팀을 떠나고 또 다른 누군가가 들어오기를 반복하는 사이에 문서의 존재는 잊혀지고 타입에 따라 달리 사용되는 같은 값의 역할을 알고 있는 사람이 완전히 사라지는 날이 찾아오면 분명 누군가가 상자와 같이 상호작용이 일어나는 내내 움직이지 않고 기다리기를 원하며 데이터를 입력했지만 의도에 따라 동작하지 않을 때 이 문제를 스스로 해결할 수 없게 됩니다. 엑셀 데이터에는 이해할 수 없는 ‘상자 타입’과 ‘호출 버튼 타입’이라는 옵션이 있지만 데이터를 살펴봐도 그냥 이전 데이터를 복사해서 조금만 수정해 사용해 왔을 뿐 이 두 가지 타입이 정확히 어떻게 동작하는지 알고 있는 사람이 없습니다. 그러면 문제를 해결하기 위해 앞서 다국어 사례와 같이 결국 엔지니어가 이 데이터를 읽어 실행하는 코드를 스텝 별로 따라가다가 결국 타입 설정에 따라 같은 값을 다른 방식으로 사용하도록 하는 분기 코드를 발견하고 이 사실을 게임디자이너에게 알려주는 쓸 데 없는 과정을 거쳐야 문제를 해결할 수 있습니다.

코드에 접근할 수 있는 엔지니어 관점에서 데이터 상에 설정된 타입 구분에 따라 같은 값을 다른 방식으로 처리하고 다른 방식으로 동작하는 것은 딱히 이상하지 않습니다. 이들은 코드를 직접 살펴보고 인게임 동작을 예상할 수 있기 때문입니다. 하지만 게임디자이너들은 그럴 수 없고 의지할 수 있는 것은 오직 데이터 뿐이기에 데이터가 자신의 동작을 숨김 없이 설명하는 모양으로 만드는 것을 권합니다. 가령 앞서 소개한 아이템 다국어 사례는 암묵적인 약속에 따라 아이템 이름과 설명을 나타내는 다국어 키를 생성하는 대신 다국어 키를 직접 사람이 만들게 하고 이 키를 아이템 데이터에 다시 입력하도록 하는 쪽을 권장합니다. 새로운 아이템을 만들 때마다 매번 명시적으로 새 다국어 키를 만들고 이를 다시 아이템 데이터에 봍여 넣어야 하는 과정은 귀찮게 느껴지겠지만 아이템 데이터를 살펴보면 데이터 스스로가 자신의 이름과 설명 텍스트를 어디서 어떤 근거로 가져오는지 데이터 자체에 명시되어 있기에 문서의 존재가 잊혀져도, 담당자가 바뀌어도, 시간이 흘러도 다국어 동작의 근거를 잊어버릴 수 없습니다. 타입 설정에 따라 서로 다른 상호작용 동작을 하는 사례 역시 마찬가지입니다. 같은 상황을 타입으로 구분하는 대신 명시적으로 상호작용이 일어나는 시간 동안 상호작용을 시작한 위치에 그대로 서 있어야만 상호작용이 성공하는지, 아니면 이동해도 상호작용이 유지되는지를 설정하는 설정을 만들고 설정에 따라 동작하도록 하면 됩니다. 상자 타입일 때는 서 있어야 하고 호출 버튼 타입일 때는 이동해도 된다는 규칙 대신 직접 서 있어야 함, 이동해도 됨 설정이 있기 때문에 이번에도 담당자가 바뀌고 시간이 흐르고 문서의 존재가 잊혀져도 이 데이터의 인게임 동작을 예측할 수 있습니다. 사실 잊어버리고 싶어도 잊어버릴 수가 없습니다. 데이터에 숨겨진 동작이 없기 때문입니다.

사실 이런 걱정에 좀 과도한 측면이 있음을 스스로도 알고 있습니다. 이는 마치 아직 일어나지도 않은 재해 상황에 대비하기 위해 데이터베이스가 고장났거나 게임 서버에 접속할 수 없을 때 동작을 묻는 데이터베이스가 고장 나면 게임이 어떻게 동작해야 하나요?의 상황과 비슷할 수도 있습니다. 온라인 게임은 원래 서버에 접속 된 상태로 동작해야 하고 또 게임이 실행되는 모든 순간에 데이터베이스는 반드시 사용 가능한 상태여야만 합니다. 이 상태가 깨지는 순간 게임 전체의 일관된 동작을 보장할 수 없으며 이 상황에도 어떻게든 동작하는 것처럼 보이기 보다는 게임 전체의 동작을 멈추고 장애 상황을 복구하는 것이 올바른 접근입니다. 이 관점에서 본다면 아직 시간이 지나지도 않았고 담당자가 바뀌지도 않았으며 많은 사람이 퇴사와 입사를 거치며 바뀌지도 않은 상황에서 굳이 귀찮게 매번 다국어 키를 새로 만들어 아이템 데이터에 입력하고 또 그냥 타입으로 구분해 상자와 버튼의 동작을 구분하는 간단한 방법 대신 이를 정확히 설명하는 설정을 만들 필요가 없을 수 있습니다.

하지만 우리들이 만드는 소프트웨어가 시간이 흐를수록 점점 더 복잡해지고 더 높은 제작비를 요구하며 제작 기간이 길어지고 이에 따라 인원이 바뀌는 상황을 무시할 수는 없어 보입니다. 개인적으로 이런 상황을 설명하기 위해 제가 자주 사용하는 비유는 ‘3개월 뒤의 우리들은 지금 우리가 한 약속을 기억하지 못할 겁니다’인데 실제로 그렇게 됩니다. 때문에 약간 과도한 측면이 있음을 알지만 마치 함수형 프로그래밍 언어를 사용해 코드를 작성하는 엔지니어들이 그렇게 하는 것에서 교훈을 얻어 우리가 볼 수 있는 게임의 동작을 추측할 수 있는 거의 유일한 근거인 엑셀 데이터 상에 숨겨진 동작을 만들지 않는 것을 권합니다.