심플 사보타지 - 조직과 회의 (2)

지난 심플 사보타지 - 조직과 회의 (1)에서 유명한 심플 사보타지 필드 매뉴얼 중 사무직 종사자들에게 의미 있어 보이는 28페이지 항목 (11)을 살펴보기 시작했습니다. 이 시리즈를 시작한 이유는 CIA가 작성한 사보타지 매뉴얼의 내용을 다룬 여러 글들이 그저 항목 (11)의 일부를 의역해 놓을 뿐 이들 하나하나의 의미를 잘 생각해본 것 같지 않아 보였기 때문입니다. 특히 항목 (11)의 (a) Organizations and Conferences부분만 다룬 경우가 거의 대부분인데 실은 그 다음에 이어지는 (b) Managers and Supervisors, (c) Office Workers, 그리고 (d) Employees에 걸쳐 자신이 처한 여러 가지 상황에 따라 최대한의 사보타지를 가할 수 있는 다양한 방법이 나열되어 있는데 대부분 이 나머지 부분은 마치 없는 것처럼 행동하고 있다는 점이 마음에 들지 않았습니다. 머나먼 과거에 작성된 이 문서를 현대의 제가 다시 끄집어내 살펴보는 이유는 우리들이 하루하루 업무를 수행해 나가며 겪는 온갖 이상한 상황들이 사실 그 상황을 주도하는 사람들이 우리들을 사보타지 하기 위해 정보기관이나 경쟁사에 고용된 사람들이라고 생각하면 그들의 행동을 더 잘 이해할 수 있기 때문입니다. 또한 만약 그들이 정보기관이나 경쟁사에 고용된 사람이 아니라면 매일같이 겪는 온갖 상황에도 불구하고 회사가 이들의 고용을 유지하고 있는 이유를 도저히 설명할 수 없기 때문이기도 합니다.

이번에는 지난 심플 사보타지 - 조직과 회의 (1)에서 (11)-(a) ‘조직과 회의’의 (1), (2), (3)을 다뤘습니다. 처음 설명을 시작할 때는 글 한 두어 개 정도면 전체를 다룰 수 있을 거라고 예상했습니다. 그래서 (11)-(d)까지 다루는데 글 네 개면 충분할 거라고 생각했습니다. 그런데 막상 각 항목을 나열하고 제가 겪은 실제 사례를 설명하다 보니 순식간에 글이 길어져 부득이하게 중간에 멈출 수밖에 없었습니다. 그래도 이 글을 쓰는 지금은 지난번 심플 사보타지 필드 매뉴얼을 읽어보기 시작한 글을 작성하고 나서 한 달 이상 지난 시점이어서 지난번보다는 좀 차분하게 이어서 다른 항목들을 다뤄 보겠습니다.

(4) 관련 없는 문제는 가능한 한 자주 제기하세요. 회의 뿐 아니라 다른 업무 논의를 하던 도중 갑자기 그 시점까지 다루던 주제와 상관 없는 다른 주제를 갑자기 꺼내면 함께 이야기하던 사람들을 당황하게 만들 수 있습니다. 특히 그 주제가 지금 논의 중인 주제로부터 벗어나기는 하지만 다른 회의를 통해 결정하기는 해야 하는 주제이거나 이전에 이 회의에 모인 사람들의 상당수가 모였던 다른 회의에서 논의된 적 있는 주제라면 더 좋습니다. 어떤 프로젝트에 참여해 바닐라 언리얼 엔진만 덜렁 들고 일을 시작한 어느 날 리드 엔지니어의 요청에 따라 겹치지 않는 UID를 수동 생성하는 요구사항을 접수했습니다. 목적을 이해하기는 하지만 모든 엑셀 파일에 걸쳐 겹치지 않는 숫자를 기계의 명시적인 도움 없이 게임디자이너 각각이 유지관리 하라는 요구사항은 전혀 납득할 수 없었을 뿐 아니라 울화통이 치밀게 만들었습니다. 그렇다고 기술적으로 확장 가능한 구조를 위해 모든 엑셀 파일에 걸쳐 겹치지 않는 숫자를 포함할 필요가 있다는 요구사항 자체를 근본적으로 막기는 어려웠습니다. 이 요구가 아무리 어처구니 없는 것이라 할지라도 이 요구를 거절하면 마치 기술적으로 스케일 아웃 할 수 있는 미래지향적 구조를 도입하려 했으나 게임디자인의 반대에 부딪쳤다는 상태를 너무 쉽게 유발할 수 있었기 때문입니다. 그래서 근본적으로 그런 무의미한 숫자가 엑셀 데이터에 침번해 들어오는 것은 장기적으로 우리들의 생산성을 극적으로 망가뜨릴 거라고 예상했지만 논의 자체를 거절할 수가 없었습니다. 그래서 고민 끝에 최대 열 자리 숫자에 규칙을 부여해 모든 데이터에 걸쳐 겹치지 않는 숫자를 부여하는 방법을 그 자리에서 고안해 미래의 모든 게임디자이너가 자신이 데이터를 하나 추가할 때마다 모든 엑셀 파일에 걸쳐 겹치지 않는 숫자를 입력하고 있는지 확인하는 기이한 일이 일어나지 않도록 했습니다.

저는 리드 엔지니어의 어처구니 없는 요구사항에 기가 차 있었고 또 그 자리에서 게임디자이너 각각이 단일 엑셀 파일에 데이터를 추가할 때 중복되지 않는 숫자에 크게 덜 신경 쓰도록 할 방법을 즉석에서 만들어내느라 정신력을 거의 다 소모한 상태였습니다. 그래서 일단 최악의 이상한 정책이 실행되어 현재의 저 자신을 포함한 미래의 게임디자이너들이 엑셀 데이터를 만질 때마다 황당한 상황에 처하지 않을 수 있어 불행 중 다행이라고 생각하고 있었습니다만, 상대는 만만하지 않았습니다. 한 가지 주제가 자신이 처음 의도한 대로 마무리되지 않았기 때문인지는 알 수 없었지만 이 주제가 그럭저럭 마무리지어지고 결론을 내린 채 회의를 마무리하려는 찰나 새로운 질문이 꼬리를 물기 시작합니다. ‘근데 지난번에 요청 드린 다국어 지원 정책은 어떻게 되어 가나요?' 네. 이 질문은 이 회의 이전 같은 리드 엔지니어가 기획팀에 던진 질문입니다. 그 때 리드 엔지니어는 크게 세 가지 요구을 기획팀에 던진 상태였습니다. 첫째. 각 마일스톤마다 빌드를 완성하면 이를 검수할 프로세스를 구축해야 한다, 둘째. 모든 엑셀 파일에 걸쳐 중복되지 않는 숫자에 기반한 데이터를 입력할 방법을 마련해야 한다, 셋째. 다국어 지원 정책을 마련해 달라. 이 세 가지 모두 초기 팀에 세팅된지 고작 몇 주 밖에 지나지 않았고 우리가 지금까지 만든 거라곤 원작의 에셋을 가져와 새 미들웨어에 맞게 컨버팅한 다음 엔진의 기본기능을 사용해 클라이언트 기반으로 전투가 동작하는 것처럼 보이도록 만든 것 뿐이었습니다. 이 첫 번째 마일스톤의 목표는 원작의 에셋을 가져와 새 엔진에 맞게 컨버팅할 수 있는지 여부를 직접 실험해 보고 컨버팅 과정을 구축하며 그 결과로 도출된 빌드를 실제 타겟 장비에서 구동시켜 조작해 보는 것이었습니다. 그러니까 아직 검수 프로세스를 구축할 만한 수준의 빌드는 존재하지 않았고 아직 엑셀 파일은 한 개도 없었으며 다국어는 커녕 인게임에 등장하는 텍스트 자체가 없었습니다.

하지만 앞서 엑셀 파일에 의미 없는 숫자가 끼어들어오게 만들기를 거절하는 순간 스케일 아웃 가능한 미래 지향적인 서버 아키텍처를 도입하려던 엔지니어의 요구를 게임디자인이 묵살하는 상황을 만드는 함정에 이미 빠져 있던 것과 비슷하게 나머지 요구 역시 먼저 말을 꺼낸 사람의 의도에 맞는 모양으로 돌아가고 있었습니다. 지금 우리는 몇 명 되지도 않고 빌드에 별다른 기능이 있지도 않으니 그저 우리들이 직접 테스트 해 보는 수준이면 충분했습니다. 하지만 지금은 테스트 프로세스를 구축할 때가 아니라고 말하면 마치 테스트 절차를 미리 구축하지 않음으로써 여느 프로젝트에서 테스트 절차가 올바르게 수행되지 않아 벌어지는 일을 똑같이 겪겠다고 말하는 것과 비슷했습니다. 다국어 지원도 마찬가지입니다. 그 시점에 인게임에는 애초에 텍스트 자체가 없었습니다. 몬스터 이름 정도를 띄울까 했지만 그럴 필요 조차 없어 보였기 때문입니다. 당시 우리가 개발하기 시작하던 게임의 원작은 여러 나라에 서비스 하기 위해 텍스트와 이미지를 지역에 따라 변경하고 각 지역의 언어 별 번역 진행 상황을 관리하는 인하우스 도구를 운용하고 있었습니다. 그 도구를 우리가 사용할 수 있을지, 사용할 필요가 있을지 판단하려면 적어도 우리들이 게임에 텍스트가 좀 더 등장하는 단계까지 구축해 나간 다음 생각해도 늦지 않았습니다. 하지만 이 역시 비슷한 함정에 빠졌습니다. 우리들이 지금 다국어 지원 전략을 고려하지 않으면 미래에도 우리들은 다국어를 시스템 수준에서 지원할 계획이 없는 것처럼 몰릴 상황이었습니다. 그래서 지금 당장의 빌드를 개발하는 행동과 아무 관계 없는 문제에 빠져 하우적거리고 있었습니다.

이런 상황에서 회의를 마치기 직전에 들은 다국어 지원 전략에 대한 질문은 주섬주섬 자리에서 일어나려던 모든 사람들이 어처구니 없는 표정을 지으며 다시 자리에 주섬주섬 앉게 만들었습니다. 이번에는 아직 준비되지 않았으니 다음에 이야기하자는 말이 통하지도 않았습니다. 리드 엔지니어는 이제 간신히 엑셀 데이터에 의미 없는 숫자가 끼어들지 못하도록 하는데 에너지를 다 써 버린 우리들에게 다국어 지원 계획 또는 전략이 이른 시점부터 준비되지 않을 때 미래에 우리들이 겪을 수 있는 온갖 가상의 상황에 대한 이야기를 하기 시작했습니다. 이전에 삼평동 668번지에 있는 회사에서 한때 아주 유명했던 프로젝트 서버를 개발하던 이야기를 하며 그 대 초반에 다국어 준비를 해 놓지 않아 나중에 겪은 어려움에 대한 이야기를 들었습니다. 또 현대에 여러 나라에 걸쳐 서비스 중인 프로젝트들이 여러 언어를 하나하나 만들기도 하지만 권역 별로 대표 언어를 설정한 다음 그 언어를 지원하는데 집중해 비용을 절약하는 사례를 설명하고 또 이와 직접적인 관련이 없음에도 서버를 국가 별로 만들거나 권역 별로 묶어 운영하는 등의 다양한 정책을 처음부터 고려해야 함을 수 십 분에 걸쳐 역설했습니다. 이는 마치 지난 시간에 다룬 ‘(2) ‘연설’을 하세요. 가능한 한 자주 그리고 길게 이야기하세요.’와도 비슷한데 거기에 회의와 직접적인 관련이 없는 주제에 대한 이야기를 꺼냄과 동시에 이를 함께 적용해 큰 효과를 얻었습니다. 우리들은 정신이 완전히 망가졌습니다. 흡연자들은 자리를 떠나 오랫동안 돌아오지 않았습니다.

(5) 의사소통, 회의록, 결의안에 대한 정확한 표현을 놓고 흥정하세요. 이 프로젝트에서 우리들은 이미 우리가 어떤 종류의 함정에 빠졌다는 느낌을 지울 수 없었습니다. 스타팅 멤버를 최대한 존중하기 위해 노력하고 있었지만 우리들에게 일어나는 일이 어쩌면 의도적인 트롤링일 수도 있다는 생각까지 하고 또 이 이야기를 공공연하게 나누고 있었습니다. 심각하게 이 트롤을 프로젝트로부터 제거해야 한다는 의견이 나왔지만 여러 가지 상황 상 실행할 수가 없었습니다. 한편 저는 그 시대에나 지금이나 회의록을 쓰는 사람입니다. 어떤 프로젝트에서 종종 팀에 처음 들어온 누군가에게 회의록을 작성하게 하기도 하는 것을 알고 있고 또 그런 모습을 지켜본 적도 있습니다. 하지만 개인적으로 이는 바람직하지 않다고 생각하는데 회의록은 회의에 참여한 사람들 중 책임이 있고 그 주제를 가장 잘 이해하는 사람이 작성할 때 의미를 가지기 때문입니다. 만약 주제를 잘 이해하지 못하는 사람이 고통 받으며 회의에 오간 말들의 의미를 이해하지 못한 채 단지 의사를 기록하기만 했다면 이는 회의록이 아니라 의사록이며 회의록으로써 의미를 가지지도 못합니다. 종종 회의록에 맥락도 주제도 결론도 액션플랜도 없이 그저 사람들이 각자 무슨 이야기를 했는지만 나열된 경우가 있는데 이런 회사의 자원을 낭비하는 회의록 아닌 회의록이 회의록이랍시고 나올 수 있는 이유는 책임이 있음과 동시에 회의 주제를 가장 잘 이해하는 사람이 회의록을 작성하지 않았기 때문입니다.

그런데 이 즈음에 회의록을 작성해 공유하고 나면 같은 사람으로부터 클레임을 받곤 했습니다. 가령 특정 액션 플랜의 수행 시점을 명확히 설정해야 한다는 것이었습니다. 이런 접근은 사실 대부분의 상황에 올바릅니다. 어떤 회의는 종종 결론과 액션플랜을 정의하지 않고 끝나기도 하는데 그럼 모여서 뭔가 이야기를 하기는 했지만 그 다음에는 아무 일도 안 일어나는 이상한 상황에 처하기 쉽습니다. 또한 액션플랜 각각은 수행할 정확한 대상과 끝낼 시점 또는 다음 보고 할 시점을 명확히 하는 것이 좋습니다. 우리 모두는 한 사람이 여러 가지 업무를 동시에 수행하고 있으므로 목표 완료 시점이나 우선순위를 설정하지 않으면 개인의 우선순위에서 한없이 밀려 액션플랜 항목이 필요한 시점까지 완수되지 않을 수 있기 때문입니다. 그런데 이 시점은 이제 서로 다른 회사, 다른 프로젝트에서 일하던 사람들이 처음 모여 첫 번째 빌드를 겨우 만들고 있을 뿐이었습니다. 개인적으로 극초반 마일스톤은 목표를 명확하게 지정하지 않곤 하는데 이는 우리들이 모여 일할 때 퍼포먼스를 잘 모르기 때문입니다. 초반 개발 경험이 쌓여 퍼포먼스를 예측할 수 있게 된 다음 액션플랜에 목표 일자를 언급해도 된다고 생각했습니다. 하지만 이 분은 제 그런 생각을 용납하지 않았습니다. 제 선에서는 현재 우리는 우리들의 퍼포먼스를 잘 모르므로 목표 일자를 정확히 정의할 수 없다고 말했지만 이내 같은 주제가 프로젝트에 가장 높은 사람에게 올라가 다시 저에게 돌아왔습니다. 하지만 그 분 역시 우리들이 트롤링 당하고 있다는 사실을 눈치 채고 있었기에 미안해하며 ‘우진님. 그냥 날짜 써 줘요. 어차피 이번 주에 할 거잖아요.’라고 말했습니다. 우리들은 아직 예측하기 어려운 액션플랜의 목표 일자를 기입하는데 그날 오후 내내 이야기를 주고 받아야만 했습니다.

(6) 지난 회의에서 결정된 사안을 다시 언급하고 그 결정의 타당성에 대한 의문을 다시 제기합니다. 사실 이 항목은 ‘(4) 관련 없는 문제는 가능한 한 자주 제기하세요.’와 비슷하다고 느낄 수 있습니다. 관련 없는 문제를 제기하기에 적절한 장소가 바로 회의이기 때문입니다. 이 항목이 이전 항목과 가지는 가장 큰 차이는 ‘이미 이전에 결정을 내린 사안’에 대해 이야기를 꺼내야 한다는 점입니다. 이 페이지에서 이미 이야기한 사례 안에서 이야기를 계속해 봅시다. 저는 앞서 스타팅 멤버가 막 설정되어 첫 번째 실행 가능한 빌드를 만들고 있어 아직 엑셀 파일이 단 한 개도 없는 상황에서 모든 엑셀 파일에 걸쳐 겹치지 않는 숫자를 부여하고 이를 데이터를 입력하는 게임디자이너가 직접 관리하라는 어처구니 없는 요구를 받아 이를 거절한 참이었습니다. 숫자 열 자리 범위 안에서 각 파일에 일련번호를 부여하고 각 파일에서는 일련번호보다 작은 최대 여섯 자리 숫자를 사용해 겹치지 않는 숫자를 만들기로 한 참입니다. 열 자리 숫자를 사용하는 이유는 4바이트로 표현할 수 있는 숫자가 최대 열 자리, 그것도 열 자리 숫자 전체가 아니라 4 까지만 사용할 수 있었습니다. 첫 한 자리는 권역을 구분하는 숫자로 넘겨놓아야 했습니다. 다음 세 자리는 엑셀 파일의 일련번호를 매기는데 사용하기로 했습니다. 아직 엑셀 파일이 단 한 개도 없는 시점이었지만 원작팀의 빌드를 살펴보니 이미 약 500여개의 엑셀 파일이 게임을 구축하는데 사용되고 있었습니다. 그래서 설마 엑셀 파일이 1000개를 넘기겠나 싶어 세 자리를 엑셀 파일의 일련번호에 할당했습니다. 다음 여섯 자리는 1부터 999999까지 엑셀파일 각각의 데이터를 정의하는데 사용했습니다. 그러니까 게임디자이너 각각은 단일 엑셀 파일 안에서 1부터 999999 사이의 숫자를 사용해 겹치지 않는 번호를 부여하면 엑셀 데이터 전체에 걸친 겹치지 않는 숫자는 알아서 부여되는 방식입니다.

그렇게 결정하고 시간이 지난 다음 또 다른 회의에서 지금은 잘 기억나지 않는 다른 주제를 놓고 한참 이야기하다가 문득 이전과 같은 트롤러가 이 주제를 다시 끄집어냅니다. 그러니까 우리들은 이미 그렇게 하기로 했고 새로운 엑셀 파일을 추가할 때 이를 기입하고 일련번호를 부여하는 별도의 엑셀 파일을 만들어 관리하기 시작한 상황이었습니다. 전혀 다른 주제의 회의 도중 나온 ‘아무래도 기획팀에서 데이터 만들기에 여섯 자리 숫자는 부족한 것 아닌가요?’ 라는 질문은 그 회의의 주제에 집중하던 저를 포함한 여러 사람들의 뇌정지를 유발하기에 충분했습니다. 사실 이 말 자체는 일리가 있습니다. 전혀 추천하지는 않지만 문자열로 데이터를 가리키는 방법이 널리 활용되는 현대에도 여전히 숫자에 의미를 부여해 100000번은 첫 번째 대륙, 200000번은 두 번째 다륙 같은 식으로 번호에 의미를 부여하는 사람들이 있고 이들을 여러 차례 설득해봤지만 씨알도 먹히지 않았습니다. 이들은 지키기 어렵고 근미래에 어려운 문제를 일으킬 것이 확실함에도 번호에 의미를 부여하고 실제로 사용 가능한 넓은 번호 대역의 극히 일부만을 사용하며 다른 중요한 일이 넘치는 시점에 더 이상 저릿수를 늘릴 수 없는 이상한 문제를 곧잘 일으켰습니다. 하지만 이 시점에 그 이야기를 할 상황이 아니었을 뿐 아니라 이미 한참 전에 엑셀 파일이 단 한 개도 존재하지 않던 시대에 이미 결론을 낸 문제를 다시 들고 나왔습니다. 결국 이 이야기는 기획팀에서 데이터를 추가할 때 사용할 수 있는 숫자에 자릿수 제한이 있다는 점을 주지시킨다는 결론으로 마무리 되었습니다. 그런데 원래 이 회의에서 이야기하려 했던 주제는 지금도 무엇이었는지 기억 나지 않습니다.

(7) “주의"를 촉구하세요. 모두가 ‘합리적’으로 행동해야 하며 동료에게 ‘합리적’이어야 한다고 말하세요. 그렇지 않으면 사람들을 당혹스럽게 만들고 또 곤란하게 할 수 있으므로 성급한 태도를 가져서는 안됩니다. 개인적으로 개발 기간 동안에 빌드는 항상 고장 날 수 있다고 생각합니다. 우리들은 한 리파지토리를 사용하는 백 명도 넘는 사람들과 동시에 일하고 있습니다. 어떤 사람들은 자신의 작업이 다른 사람들에게 영향을 끼치기를 원하지 않거나 그 반대의 이유로 Git 같은 도구를 사용하며 브랜치 안에서 오랜 시간을 보낸다는 사실을 잘 알고 있습니다. 또 어떤 사람들은 오랜 시간에 걸쳐 브랜치에 머물면서 메인으로부터 너무 멀어지지 않기 위해 메인에서 브랜치 방향으로 머지를 반복하곤 하지만 결코 메인으로 돌아오지 않기도 합니다. 개인적으로 이런 사용이 가능하다는 이유 때문에 Git을 선호하지 않기도 합니다. 우리가 구축하는 이 거대한 바이너리 당어리는 수많은 사람들의 작업이 서로가 서로를 이용하며 동작하는 가운데 의도한 대로 움직이기 시작합니다. 새로운 코드는 새로운 데이터에 기반해 동작해야 하지만 새로운 데이터는 새 코드가 올라오기 전에는 에러로 평가됩니다. 새 에셋을 등록하려면 근거 데이터가 필요하지만 엑셀에 기입해야 하는 데이터는 실제 에셋이 없으면 문제를 일으킵니다. 이 모든 작업들은 좀 어수선해 보이고 하루 동안 최신 빌드가 멀쩡하게 동작하는 시간대가 그리 길어 보이지 않더라도 단일 브랜치에서 서로 문제를 일으키고 해결하는 지속적인 통합 과정 속에 개발된다고 생각합니다. 내 자리에서 동작하는 것처럼 보이는 데이터를 올려도 괜찮을까요? 누군가 저에게 그런 질문을 하면 저는 일단 올리고 보라고 말합니다. 물론 이 판단은 당연히 틀립니다. 데이터가 올라가고 다른 사람들 자리에 동기화 되는 순간 모두의 플레이를, 모두의 작업을 중단 시킬 수도 있습니다. 그럼 올리지 말아야 할까요? 아닙니다. 일단 문제가 전파되고 문제의 존재가 알려져야 문제를 수정하고 같은 문제가 일어나지 않도록 할 수 있습니다.

하지만 어떤 사람들은 그런 상황이 절대로 발생해서는 안된다고 생각하는 것 같습니다. 전설의 마이크로소프트 엑셀 팀이 빌드를 깬 사람이 다음번 빌드를 깬 사람이 나타날 때까지 빌드 관리 업무를 담당하도록 해 아무 시점에나 항상 동작하는 빌드가 존재하도록 관리하는 방식이 모범 사례로 거론됩니다. 개인적으로 항상 실행 가능한 빌드가 존재하거나 반대로 빌드는 대부분의 시간대에 정상적으로 실행 가능해야 한다는 말에 동의합니다. 하지만 그 대가로 사람들이 자신의 작업을 서버로 보내 다른 사람들에게 전파되어 여러 사람들에 걸쳐 평가되고 테스트 되는 상태가 되는 것을 피하기 시작한다면 이건 문제가 있습니다. 안타깝게도 이런 문제는 일단 서버를 거쳐 다른 사람들에게 전파된 다음에야 문제가 있음을 파악할 수 있을 때가 많습니다. 분명 자기 자리에서는 잘 동작하지만요. 이 상황을 해결할 거의 유일한, 그리고 가장 값싼 방법은 일단 내 자리에서 확인한 상태를 전파 시키는 것입니다. 하지만 이런 상황이 발생하는 것 자체를 터부시 하는 분들이 정책을 수립하기 시작하면 앞서 잠깐 설명하고 지나간 뫼비우스의 띠 같은 상황이 벌어집니다. 에셋을 등록하려면 데이터가 이 에셋을 가리키고 있어야 하지만 데이터는 에셋 없이는 밸리데이션에 실패하며 에러를 냅니다. 문제를 해결하려면 반드시 이 둘을 동시에 작업해야 하는데 공교롭게도 에셋은 아트팀에서 만들고 데이터는 기획팀에서 만듭니다. 그러면 각 작업자가 서로 허들로 대화하며 하나 둘 셋을 외치며 커밋이라도 해야 할까요? 그렇지 않습니다. 빌드는 짧은 시간 동안 고장난 상태일 수도 있습니다. 개발 과정에서는 그럴 수 있습니다. 문제가 생기면, 빌드가 고장 나면 고치면 됩니다. 그 사이에 누군가 작업에 영향을 받아 당혹스럽고 또 곤란해질 수 있겠지만 그 상태를 완벽하게 피할 방법은 없습니다. 하지만 그렇게 생각하지 않는 ‘합리적’으로 생각하는 사람들이 절차를 수립하면 우리들은 통합된 환경에서 빌드 고장을 대가로 즉시 찾아낼 수 있는 문제를 처벌을 피하기 위해 미리 머릿속으로 시뮬레이션 하며 점검하는데 한나절을 보내게 됩니다.

(8) 결정의 타당성에 대해 고민하세요 - 검토중인 조치를 우리가 결정할 권한이 있는지, 다른 팀의 정책과 충돌할 수 있는지 의문을 제기하세요. 이 항목은 주로 논의에 필요한 모든 부서가 모이지 않은 회의에서 일어납니다. 가령 아트 에셋의 규칙을 결정하는 회의를 하는 중이라고 해 봅시다. 아트 에셋을 직접적으로 필요로 하는 것은 주로 엔지니어 입니다. 엔지니어는 에셋이 준비되기 전에 게임디자인과 의견 교환을 통해 에셋의 대략적인 규격을 가정하고 작업합니다. 종종 게임디자인에서 샘플 에셋을 준비해 주기도 합니다. 그러다 보면 점점 실제 아트 부서에 요구할 에셋의 형태가 뚜렷해지기 시작합니다. 아트 부서에 이 과정을 함께하며 시행착오를 겪을 여유가 있는 상황이라면 게임디자인에서 샘플 에셋을 제작하는 대신 아트팀에서 바로 에셋을 제작할 수도 있습니다만, 대부분의 아트 부서는 끝없이 밀려드는 발주서를 처리하기 위해 아침부터 저녁까지 고통 받고 있을 때가 대부분입니다. 그래서 새로운 형태의 에셋을 필요로 하는 개발이 진행될 때 아트 부서는 이 진행으로부터 떨어져 있을 때가 많습니다. 그래서 종종 아트 부서에 제작을 요청할 에셋의 최초 형태는 아트 부서가 참여하지 않은 상태에서 결정되곤 합니다. 우리들이 작성하는 발주서에도 이미 구축된 규칙에 기반한 에셋을 제작하도록 가이드하는 것이 보통입니다.

하지만 이 논의를 망가뜨리고 싶으면 이전까지 단 한 번도 그렇게 행동한 적이 없으면서도 이렇게 딱 한 마디만 말하면 됩니다. ‘이거 아트에서도 동의한 건가요?’ 당연이 동의하지 않았습니다. 왜냐 하면 전달된 적이 없으니까요. 이상적인 상황에서 개발 초반의 시행착오 과정에 아트 팀이 포함되어 함께 에셋 규격을 만들어 가야 합니다. 그런데 현실적으로 그런 여유나 이를 담당할 부서나 담당자를 보유한 개발팀은 많지 않습니다. 그렇다면 아트 부서의 시행착오 참여를 생략하는 대신 나머지 부서가 아트 팀에 제작을 요청할 첫 에셋 규격을 정해 제안해야 합니다. 이 상황에서도 분명 시행착오는 발생하겠지만 이 시점까지 거쳐 온 것 만큼 큰 시행착오는 아닙니다. 이런 상황을 알고 또 지금까지 이렇게 행동해 왔으면서도 ‘아트에 물어보고 진행해야 하니 다른 회의를 잡읍시다’라고 말하면 진행을 한 주 늦출 수 있습니다. 이런 행동을 프로젝트 전체에 걸쳐 딱 여덟 번만 하면 그 프로젝트는 최소 두 달 늦어지는 겁니다. 효과가 엄청납니다.

지금까지 (11)-(a) ‘조직과 회의’의 모든 항목을 살펴봤습니다. 사실 이 문서가 작성된 시점으로부터 수십 년이 흐른 미래 사람이 볼 때 이 매뉴얼의 여러 항목은 서로 조금씩 중복된 지시를 하고 있습니다. 빠른 결정을 방해하고 현 시점에 이미 없는 자신의 경험을 반복해서 말하며 이 시점에는 중요하지 않은 주제를 언급해 회의가 늘어지고 또 원래 결정하려던 목표를 잊어버리거나 집중하지 못하게 만듭니다. 이런 여러 가지 행동들을 일하며 여러 번 보셨을 겁니다. 이런 행동을 지속적으로 일삼는 사람들도 있습니다. 놀라운 점은 이런 사람들이 인사평가에서 그들의 상사들로부터 높은 평가를 받고 회사에 계속해서 고용된다는 점입니다. 우리는 동작하는 빌드를 성해 고객들과 대변해야만 회사에 돈을 벌어다 주고 또 우리들의 커리어를 유지할 수 있습니다. 하지만 모두가 그렇지는 않습니다. 이는 이전 게임디자인 직군의 슬픈 점은 나머지 부서들과 목표가 다르다는데 있다에 소개했고 슬프지만 이는 합리적입니다. 하지만 그 선을 넘는 사람들이 있고 이들은 정보기관이나 경쟁사에 고용된 스파이일 가능성이 높습니다. 다음에는 (b) Managers and Supervisors, (c) Office Workers, (d) Employees 항목을 천천히 살펴보겠습니다. 어제 우리들을 곤란하게 만들었던 그 사람은 경쟁사에 고용된 사람들일 수 있습니다. 그들이 그럴 수밖에 없음을 이해하려고 노력해 봅시다.