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

‘사보타지’를 뭐라고 표현하면 좋을까 하고 사전을 찾아보니 태업, 조업 방해, 방해 공작 같은 말로 바꿔 쓸 수 있다고 합니다. 아마도 제가 오늘 사용하려고 하는 이 말의 의미와 가장 가까운 것은 ‘방해 공작’일 것 같은데 또 그렇게 표현하자니 의미가 잘 살지 않는 것 같아 원문 그대로 사보타지라고 말하기로 하겠습니다. 제 2차 세계대전 시대에 현 CIA의 전신인 OSS에서 작성한 이 문서는 지난 2008년에 기밀 해제 되었습니다. 이 문서에는 여러 가지 방법으로 대상 조직 자체와 조직의 여러 활동을 방해하는 단순한 방법이 적혀 있습니다. 가령 보급품 배송 차량에 일부러 잘못된 길 안내를 해 보급을 지연 시킬 수 있습니다. 이 정도는 사소한 실수로 치부할 수 있고 또 보급이 하루 이틀 늦어진다고 해서 큰 문제로 이어지지는 않을지도 모릅니다. 하지만 이런 일이 하나 둘 쌓이며 조직 전체에 걸쳐 부담이 누적되고 같은 목적을 달성하더라도 훨씬 일찍 달성할 수 있었을 상황을 더 지연 시킬 수 있습니다. 이런 지연은 어쩌면 목적이 달성되어야만 했을 데드라인을 넘기게 만들어 목적을 달성하더라도 그 효과를 축소하는 효과를 줄 수도 있습니다. 만약 조직에 이 메뉴얼을 숙지하고 행동하는 사람이 한 사람이 아니라면 어쩌면 사소해 보이는 자잘한 비효율들이 누적되어 구성원들의 사기를 떨어뜨리고 무기력하게 만들어 조직의 목적에 실패하도록 만들 뿐 아니라 조직에 그 다음 단계의 공작이 더 쉽게 먹히는 상태로 만들 수 있습니다. 이 매뉴얼은 공개된 이후 여러 차례에 걸쳐, 또 여러 미디어에 의해 조명 되었지만 다들 원문을 살펴보기 보다는 어딘가 처음 인용했을 이 문서의 첫 페이지 스크린샷과 요약을 인용하곤 했는데 회사에서 일하다가 종종 너무 깊은 답답함을 느끼다가 문득 저 사람은 이 회사의 직원이 아니라 경쟁사가 보낸 스파이가 아닐까 하는 의심을 한 적이 있는데 이 참에 이 심플 사포타지 필드 매뉴얼을 직접 살펴보기로 합니다.

이 문서는 다양한 방법으로 조직의 효율을 떨어뜨리고 구성원들의 사기를 저하시키는 방법이 수록되어 있습니다. 하지만 현대에 사무실에서 일하는 사람 입장에서 일부러 화기에 가연성 물질을 가까이 두거나 수송 차량의 너트 두어 개를 느슨하게 만들어 사고를 유발하거나 보급 차량에 잘못된 길 안내를 하는 요령은 썩 도움 되지 않을 가능성이 높습니다. 물론 이런 요령들도 현대에 적용할 만 하지만 전쟁 중에 적국에 피해를 입히기에 적당하지만 같은 사무실에서 일하는 도중 가연성 물질에 불이 옮겨 붙게 만드는 행동은 조직에 피해를 끼칠 뿐 아니라 자기 자신에게도 위해를 가할 수 있으며 현대 국가에서 이런 행동은 범죄에 해당하므로 이런 부분은 건너 뛰려고 합니다. 하지만 뒷부분으로 가면 사무실에서 일할 때 실천할 수 있는 사보타지 기법들이 요원의 조직 내 위치에 따라 실행할 수 있는 간단하지만 다양한 방법이 나열되어 있는데 이들은 자기 자신을 실질적인 위험에 빠뜨리지 않을 정도로 안전할 뿐 아니라 여기 나열된 거의 모든 행동은 다만 무능해 보이거나 비호감으로 느껴질 뿐 범죄는 아니기 때문에 이를 실천한다 하더라도 실질적인 문제나 위험에 빠질 가능성은 낮아 보입니다. 심지어 현대 회사에서 이런 행동은 심플 사보타지 필드 매뉴얼을 숙지한 공작 요원이 아니더라도 회사 내의 다양한 부서와 다양한 인원들이 이미 실천하고 있는 것으로 보이는데 이쯤 되면 현대 사회에 정보기관이나 경쟁사가 얼마나 깊숙이 침투해 있는지 생각해볼 수 있습니다. 개인적으로 CIA가 이 문서에 대한 기밀을 해제한 이유는 현대에는 더 이상 요원들에게 이런 매뉴얼을 교육해 목표 조직에 침투 시키지 않더라도 이미 그냥 같은 사무실에 있는 전혀 훈련 받지 않은 김부장이 이런 행동을 더 잘 하기 때문에 굳이 훈련 받은 요원을 투입할 필요가 없기 때문이라고 생각합니다. 우리가 우리 스스로 우리가 속한 조직을 파괴할 생각이 있지는 않으면서도 이 매뉴얼을 살펴보려는 이유는 조직에서 정보기관이나 경쟁사가 파견한 스파이의 활동을 알아볼 수 있는 능력을 키우기 위함입니다. 대체로 이 분야 회사에는 겸업 금지 조항이 있으므로 이런 행동을 일삼는 사람들을 의심해 볼 여지가 충분합니다.

한번에 필요한 모든 부분을 살펴보고 요약하는 글은 이미 검색해 보면 수 십 개가 튀어나오기 때문에 여기서는 각 분류 별로 각 항목 하나하나를 살펴보고 이런 행동을 하는 사람을 실제로 일하며 겪은 경험을 함께 설명하려고 합니다. 가령 모든 일을 항상 채널을 통해서 진행하게 만들어야 한다는 첫 번째 항목부터 이게 정확히 무슨 말인지 이해하기 어려울 수 있습니다. 하지만 이 메시지에 어울리는 직접 겪은 경험을 함께 설명하면 이런 사보타지 행동을 하는 사람들을 쉽게 구분하고 또 내 스스로가 다른 조직이 비슷한 비효율과 사기 저하에 빠지도록 행동할 수 있는 방법을 이해할 수 있을 겁니다. 이미 인터넷 상의 수많은 글에 이 매뉴얼에 대한 번역이 돌아다니고 있기 때문에 제 번역이 원문과 어긋나거나 현대적인 의미에 어울리지 않는다고 생각하실 수 있는데 그럴 경우 읽으시는 분의 의견이 무조건 옳습니다. 이 글을 작성하는 날 이틀 전에 2024년도 수능 시험이 치러졌는데 돌이켜보면 제 수능시험 영어 성적은 썩 좋지 않았고 그 때 배운 영어로 지금까지 버티고 있는 셈이니 번역이 이상해도 전혀 이상하지 않습니다. 그럼 시작하겠습니다.

먼저 위 문서의 (11)-(a) ‘조직과 회의’ 부분을 살펴보겠습니다. (1) 모든 일을 ‘채널’을 통해 진행해야 한다고 주장하세요. 신속한 의사 결정을 위해 지름길을 택하는 것은 절대 허용해선 안됩니다. 분명 처음 그 규칙을 만든 누군가는 자신이 만든 규칙이 조직 운영에 효율을 가져올 거라고 생각했을 겁니다. 서로 다른 협업 부서 간에 걸쳐 각각의 사람들이 다른 사람들에게 알리지 않은 채 업무를 요청하기를 반복하다 보면 서로 다른 사람이 같은 업무를 요청하기도 하고 또 서로 다른 사람이 상호 배타적인 업무를 요청하기도 합니다. 또 각각의 업무가 일관되지 않은 정책을 포함하고 있을 수도 있는데 이 상태가 좀 더 심해지면 상호 배타적인 업무 모양으로 변합니다. 지난 인터랙션 오브젝트는 어쩌면 통합이 능사가 아닐지 모른다에서 인게임에서 플레이어가 상호작용 가능한 여러 가지 물체를 설계하며 든 생각을 소개했습니다. 위 글에서 처음에는 여러 상호작용 가능한 물체를 협업 부서 간에 서로 각각의 기능이 필요한 사람들이 제각각 요구사항을 전달해 개발하다 보니 거의 비슷한 기능이 서로 다른 코드베이스에 기반해 개발되었고 서로 다른 규칙, 서로 다른 정책에 의해 개발되어 겉보기에는 비슷해 보이는 물체의 상호작용 가능한 범위를 조정하기 위해 서로 다른 데이터 파일과 서로 다른 거리 단위를 사용해 수정해야 하는 일이 일어납니다. 여러 프로젝트에 걸쳐 이런 문제를 완화하기 위해 처음부터 규칙을 설계할 수 있다면 비슷한 역할을 하는 여러 물체에 걸쳐 확장될 수 있는 기반을 만들었고 중간에 개입한 경우에는 서로 다른 기능을 비슷한 기능끼리 서로 통합해 왔습니다. 그런데 이 과정에서 상호 배타적인 요구사항을 직접 조율하느라 지친 협업 부서에서 이 주제에 대해 게임디자인 전체를 대표하는 한 명의 컨텍포인트를 지정해 달라는 요구를 해 왔고 컨텍포인트로 종종 제가 지정되었습니다. 여기 까지는 꽤 괜찮은 것처럼 보입니다.

하지만 컨텍포인트의 함의는 모든 관련 업무가 통과해야만 하는 병목을 지정하는 것이 아니라 상호 배타적인 요구사항이 발생하거나 이전에 이미 개발된 기능을 또 다시 개발하려고 하는 요청이 발생할 때 이 요청이 협업 부서로 건너가기 전에 우리들 선에서 조율해 정리한 다음 협업 부서에 전달되도록 하는 것입니다. 그 외에 어지간한 요청은 명시적인 컨텍포인트가 설정되어 있더라도 여전히 이전에 업무를 수행하던 각각의 채널에 의해 수행되어야 합니다. 가령 던전에 함정을 만들기 위해 새로운 에셋이 필요하고 이미 함정 기능을 위한 구현이 충분히 준비되어 있는 상태라면 의사결정을 위한 컨텍포인트는 심지어 이런 요구사항이 있다는 사실 자체를 알 필요도 그리 크지 않습니다. 에셋이 필요한 사람이 직접 에셋을 발주하고 이 진행에 따라 기 구현된 기능에 기반해 함정을 구현해 던전에 투입하기만 하면 됩니다. 이 때 컨텍포인트에게 요구될법한 최소한의 행동은 이런 일이 진행되고 있다는 사실을 알아 두는 정도입니다. 누군가 이 주제에 대해 컨텍포인트에 질문하러 왔을 때 즉시 답할 수 있으면 가장 좋습니다. 하지만 이 과정에 컨텍포인트의 의사결정이나 소위 교통정리가 필요하지는 않기 때문에 이 업무의 존재를 모르고 있더라도 별 상관이 없습니다. 질문에 즉시 답하지 못하는 점은 아쉽지만 즉시 누구에게 질문하면 될 지 알고 있기 때문에 이 과정에 별다른 딜레이가 생기지는 않을 것이기 때문입니다. 그런데 이런 상황이 못마땅해 컨텍포인트를 일종의 채널로 지정하고 상호작용 가능한 물체를 제작하는 모든 협업부서 간 요청이 컨텍포인트를 통하게 해야 한다고 선언해 버리면 이상한 일이 일어납니다.

이전에는 상대 협업 부서에 실무자들 사이에 이미 구축된 각자의 채널을 통해 문서에 기반한 온전한 요청 양식을 작성하지 않더라도 각자의 친분이나 협업 수준에 따라 준비가 좀 부족한 상태이더라도 협업 요청을 할 수 있었을 것입니다. 양식에 맞춰 완벽하게 작성된 소위 발주서를 작성하지 않더라도 대강 이전에 어디선가 본 에셋의 일부를 수정한 수준의 에셋이면 충분할 것 같아 정식 발주 절차를 건너 뛰고 개인들 사이에 요청을 통해 일을 빨리 진행할 수도 있고 또 정식 발주에 따른 관리 부담이나 발주 절차를 기다리는 동안에 생기는 시간 낭비, 업무 전환 및 재전환에 따른 비효율 등을 고려할 필요조차 없습니다. 하지만 컨텍포인트를 온전히 채널로써 동작하도록 선언해 이 자체를 병목으로 만들고 나면 이전에 빠르게 수행할 수 있었을 각자가 구축한 채널이 모두 파괴됩니다. 이전 같으면 담당자에게 말해 필요한 에셋을 바로 얻을 수 있었던 상황이었지만 명시적인 채널을 통해서 일을 처리해야만 하는 상황이 되면 이제 아무리 작은 요구사항이라도 명시적인 문서 작업과 이 문서에 따른 관리 절차를 반드시 거쳐야만 합니다. 만약 에셋은 당장 필요하지만 정식 발주 절차를 거쳐야만 하고 정식 발주 절차는 일을 한 번에 몰아서 처리하기 위해 한 달에 한 번 발주서를 모아 처리하기로 되어 있다면 던전에 작은 기믹을 추가하려던 계획은 이제 한 달을 기다려야 하는 거대한 일로 변해 버립니다. 오직 이 작업을 위해 한 달을 기다렸다가는 저성과자로 낙인 찍혀 해고될 수 있으니 다른 업무로 전환하게 되고 한 달이 지난 다음 막상 에셋을 전달 받을 때는 이미 생각이 바뀌어 이 기믹을 사용하지 않기로 결정했거나 이 기믹이 이전만큼 절실하지 않게 느껴질 수 있습니다. 또한 이 모든 과정에 일어나는 태스크 전환 비용이 드러나지 않는 모양으로 계속해서 소모되고 있음은 덤입니다.

이런 과정을 반복하며 지금 당장 부서 사이에 협업이 일어나야만 당장의 과업을 해결할 수 있지만 그럴 수 없거나 그래서는 안된다는 사실을 채득하고 나면 협업을 통해 일을 진행할 수 있는 상황이 되더라도 이전만큼 일을 빨리 수행할 동인이 사라집니다. 작은 일도 정식 요청 과정을 통해 오랜 시간 기다려야 하기 때문에 애초에 그런 일을 만들지 않고 웬만하면 다른 부서와 협업 없이 직접 모든 요구사항을 통제할 수 있는 범위 안에서 할 수 있는 수준으로 요구사항을 축소하게 됩니다. 이전보다 협업을 훨씬 적게, 혹은 거의 협업하지 않으면서도 업무는 비슷하게 진행되는 것처럼 보이겠지만 결과적으로 그 결과는 이전에 빠른 협업을 통해 달성할 수 있었던 것에 비해 훨씬 수준이 낮아지겠지만 우리는 동시에 두 가지 방식으로 진행된 업무 결과를 다중우주를 통해 확인할 방법이 없으므로 협업을 최대한 회피하며 진행된 이 결과가 그렇지 않은 경우에 비해 얼마나 수준이 낮은지 알아낼 방법은 없습니다. 모든 업무가 항상 공식적인 ‘채널’을 통해 처리되도록 하고 개인들 사이에 구축된 또 다른 채널의 존재를 부정하고 이런 방식의 업무 처리를 금지하면 더 쉽게 더 나은 결과를 만들어내는데 익숙한 사람들의 업무 의지를 완전히 무너뜨릴 수 있습니다. 오늘 안에 꽤 그럴듯한 던전 기믹을 만들어낼 수 있으리라 기대한 사람들은 이제 같은 작업을 하는데 최소 몇 주를 기다려야만 한다는 사실에 좌절하고 또 오랜 시간을 기다린 다음에 비로소 획득한 에셋을 보고 이전과 똑같은 열의를 가지고 작업에 임하기는 어렵습니다. 또한 중간에 어떤 착오 때문에 작업에 누락이 발생하면 오랜 시간을 기다렸음에도 에셋을 획득하지 못하게 될 수도 있는데 오히려 이 상황은 에셋을 요청한 사람 본인에게는 별로 놀랍지 않을 수도 있습니다. 이미 에셋이 없는 상황을 가정해 어떻게든 던전 플레이가 동작하도록 만들어 놓은 다음이기 때문에 에셋이 있든 없든 던전의 동작 여부에는 별 차이가 없을 것이기 때문입니다.

모든 업무를 명시적인 채널을 통해 항상 정식 절차에 따라 수행하도록 강제하면 관리자 입장에서는 이전에 비해 뭔가 프로젝트 전체에 걸쳐 ‘일이 돌아가는 것 같은’ 착각을 일으킵니다. 이전에는 개인들 사이에 구축된 채널을 통해 빠르게 처리되던 일들이 정식 절차에 의해 처리되며 이전에 비해 가시성이 극단적으로 높아지기 때문입니다. 이전에 비해 팀 전체가 더 많은 일을 수행하는 것처럼 보이고 그 결과가 각각의 협업 부서 사이를 오가는 과정 전체를 감독할 수 있으므로 이전에 비해 일이 더 빨리, 그리고 효율적으로 처리된다는 느낌을 받게 됩니다. 이 느낌은 완전한 착각이지만 앞서 서로 다른 두 다중우주의 업무 결과를 비교 확인할 수 없기에 그저 이전에 진행되던 업무들의 가시성이 증가했을 뿐 업무들의 결과는 이전에 비해 나빠지고 또 업무를 수행하는 사람들의 사기를 완전히 망가뜨리고 있지만 갑작스레 늘어난 가시성을 통해 모든 일이 더 활발하게 진행되고 있는 것 같은 착각이 착각일 뿐이라는 사실을 인지할 수 있는 방법은 없습니다. 그러므로 협업 부서들 사이에 업무를 진행 시킬 때 각자가 이미 구축한 작은 채널의 사용을 완전히 금지하고 공식적인 단 하나의 채널을 통하게 해 이 채널을 담당하는 컨텍포인트를 일종의 병목으로 만들면 병목 현상으로 인해 업무가 느려지는 효과 대신 더 활발하게 업무가 일어나는 것 같은 착각을 일으켜 관리자를 기쁘게 할 수 있으니 반드시 공식 채널을 통해서만 업무를 진행하게 할 필요가 있습니다. 이 상태를 지속하면 이전에 더 빠르게 업무를 처리하던 사람들을 무기력하게 만들 수 있고 종종 이들로부터 불평을 들을 수 있는데 이런 불평을 무시하고 조금만 기다리면 이들은 견디지 못하고 프로젝트를 떠나고 처음부터 이런 체제에 순응할 만한 사람들로 바뀝니다. 그러면 모든 업무를 반드시 공식 채널을 통해 처리하며 겉보기에는 일이 더 빨리, 더 효율적으로, 더 많이 처리되는 것처럼 보이는 상태를 유지할 수 있습니다. 특히 목표 지향적으로 행동하지 않는 대부분의 그저 그런 관리자들은 이전에 비해 훨씬 높은 가시성에 기반한 풍부한 보고를 통해 상황을 완전히 착각해 대단히 만족스러워 할 겁니다.

(2) ‘연설’을 하세요. 가능한 한 자주 그리고 길게 이야기하세요. 긴 일화나 개인적인 경험담을 통해 자신의 '요점'을 설명하세요. 적절한 “애국적인” 발언을 주저하지 마세요. 이 매뉴얼이 작성된 시대상을 고려할 때 ‘애국적인 발언'의 의미를 현대적으로 고려할 필요가 있습니다. 현대에도 종종 국가의 통치 수단으로 애국이 동원되곤 하지만 과거에 비해 그렇게까지 강조되고 있지는 않은 것 같습니다. 그래서 여기서는 애국적인 발언 부분을 생략하고 나머지에 대해 이야기해보려고 합니다. 회의 때 가능한 길게 이야기하고 긴 일화와 개인적인 경험담을 늘어놓는 모습은 종종 업계 베테랑과 함께할 때 볼 수 있습니다. 이전 그 규칙은 말이 됩니다. 그런데 고객에게 어떤 경험을 주나요?에 소개한 인벤토리 크기에 제한이 없어야 한다는 요구사항에 대해 인벤토리는 약 21억 칸을 넘을 수 없기 때문에 제한이 없기는 불가능하다는 말을 들었던 바로 그 프로젝트에서 비슷한 일을 겪었습니다. 이 프로젝트에서는 겹치지 않는 UID를 수동 생성하는 요구사항이 있었습니다. 모든 엑셀 데이터의 맨 첫 번째 칼럼에는 이 규칙에 따른 모든 데이터에 걸쳐 유일한 숫자가 들어가야 했는데 이 숫자는 데이터베이스에 기록된 다음 새로운 엑셀 데이터를 입력할 때 이 데이터가 이전에 입력했던 데이터를 수정해야 하는 것인지 아니면 새로운 데이터를 추가해야 하는 것인지 결정하는 근거로 사용됩니다. 이 숫자는 각각의 엑셀 파일에 부여된 일련번호와 단일 엑셀 파일 안에서 사용하는 숫자로 된 아이디를 합쳐 큰 숫자를 만들어 중복을 회피하는 식으로 사용하기 시작했는데 현대에는 고전적인 숫자 대신 문자로 데이터를 가리키곤 하기 때문에 숫자에 의미를 부여할 필요가 거의 없어졌지만 오래 전 일을 시작한 많은 사람들은 여전히 숫자 자체에 의미를 부여하기를 원하곤 했습니다. 가령 몬스터 데이터는 그냥 1번부터 시작해 새로운 몬스터가 추가될 때마다 1씩 증가하게 해도 아무 문제가 없었지만 어떤 사람들은 첫 번째 지역 몬스터는 10000번부터, 두 번째 지역 몬스터는 20000번 부터 시작하는 번호를 붙이기를 원했습니다. 규칙이 이 정도로 단순했다면 별 일 없었겠지만 같은 몬스터가 외형이나 강함에 따른 배리에이션으로 구분됨에 따라 이들에 서로 다른 번호 체계를 부여하기 위해 10000번부터 시작하는 몬스터는 항상 배리에이션이 추가될 경우를 대비해 10010, 10020과 같이 번호를 띄워 만들고 배리에이션이 나타나면 10011, 10021과 같이 1의 자리 숫자를 사용하는 복잡한 규칙을 만들었습니다.

개인적으로는 현대에 문자 형태의 이름으로 숫자를 대신할 수 있기 때문에 숫자에 의미를 부여하는 방식은 너무 낡았고 또 다른 부서가 이해하기 어려우며 작업을 오직 이 규칙을 이해한 사람들만이 수행할 수 있도록 하는 일종의 사일로링을 방조하는 나쁜 정책이라고 생각했지만 오랜 옛날부터 이런 방식으로 작업해 온 사람들을 설득하기는 거의 불가능했습니다. 그런데 이렇게 숫자에 의미를 부여하는 방식으로 아이디를 부여하다 보면 어느 순간 숫자 자릿수가 부족해지는 순간이 반드시 찾아옵니다. 10000번부터 시작한 첫 번째 지역 몬스터는 어느새 아홉 번째 지역의 마지막 몬스터인 99990번 몬스터가 추가되고 그 다음 몬스터를 추가하려 하거나 그 다음 지역이 나타나는 순간 이상한 문제가 생깁니다. 앞서 이 숫자 자체를 데이터 파일의 일련번호의 일부로 사용해 데이터 전체에 걸친 유일한 숫자로 사용한다고 했는데 이미 이 숫자는 최대한 사용할 수 있는 열 자리 숫자를 모두 사용하고 있었기 때문에 더 이상 자리를 늘릴 수가 없었습니다. 전체 데이터에 걸쳐 유일한 숫자는 총 열 자리로 첫 두 자리는 패키지 번호, 다음 세 자리는 엑셀 데이터 번호, 그 다음 다섯 자리는 실제 엑셀 데이터에서 사용할 번호로 할당했는데 실제 엑셀 데이터에 할당된 숫자에 의미를 부여하며 중간을 마구 건너 뛴 덕분에 아홉 번째 지역의 마지막 몬스터 99990번을 추가하고 나자 더 이상 새로운 지역에 새로운 몬스터를 추가할 수 없는 상황이 일어났습니다. 이 문제를 해결하기 위해 소집된 회의에 저도 초대되었지만 개인적으로 이 회의에 들어가고 싶지 않았습니다. 회의에 들어올 게임디자인과 엔지니어 양쪽 모두가 이미 무슨 소리를 할 지, 그리고 그 소리가 서로에게 어떻게 들릴지 완전히 예측 가능했고 굳이 그 꼴을 눈 앞에서 직접 보고 싶지는 않았기 때문입니다. 게임디자인은 분명 요즘 세상에 숫자에 의미를 부여하지 말고 문자로 된 별도의 구분자를 통해 데이터를 구분하는 방법을 제안했지만 완전히 무시되었기 때문에 의미를 부여한 숫자의 자리수를 늘리기를 원했습니다. 엔지니어들은 이미 우리가 사용할 수 있는 최대 자리수인 10자리를 모두 사용하고 있는 상황이었으므로 자리수를 늘릴 수 없는 상황이었기 때문에 또 다시 인벤토리는21억 칸 까지만 만들 수 있기 때문에 부한한 인벤토리 크기는 불가능하다든지 아무리 늘려도 42억 이상의 숫자를 사용할 수는 없다는 이야기를 늘어놓을 것이 뻔했습니다.

이 예측은 회의 시작 10분이 채 지나기도 전에 현실이 됩니다. 이 문단이 ‘연설’, 과거의 경험담'으로 시작되었음을 기억하고 계실 수도 있습니다. 이미 저는 게임디자인의 요구사항이 우리가 처한 상황을 고려할 때 별로 설득력이 없다고 생각하고 있었지만 이에 대응하는 엔지니어들의 설명은 더더욱 저를 맥 빠지게 만들었습니다. 예상 대로 그들은 컴퓨터가 숫자를 세는 방법으로부터 설명을 시작해 우리들이 사용하는 숫자가 최대 42억 얼마까지만 늘어날 수 있으며 만약 여기서 자릿수 한 자리를 늘리기 위해서는 숫자 하나를 표현하기 위해 지금까지 사용하던 저장 공간의 두 배를 사용해야만 하는데 지금까지 그들이 게임 서버를 만들며 그런 데이터구조를 사용해 서버를 만들어본 적이 없기 때문에 경험이 없는 문제가 발생할 수 있고 그런 문제를 고작 열 번째 지역의 첫 번째 몬스터를 규칙에 맞는 숫자를 부여하기 위한 용도만으로 그런 위험을 감수할 수는 없다는 이야기를 늘어놓았습니다. 여기까지 이미 시간은 한참이나 흘러 있었고 저는 이 자리가 문제를 해결하기 위한 자리인지 아니면 자료구조 과목의 첫 수업 시간인지 헛갈리기 시작했습니다. 발언을 계속하고 있는 엔지니어 부서의 리드님이 방금 전까지는 같은 프로젝트를 개발하고 있는 회사원으로 보였지만 눈을 감았다 뜨자 자료구조를 설명하고 있는 교수님처럼 보였고 조금만 더 지나면 중간고사 공지를 할 것만 같아 보입니다. 하지만 여기서 끝났다면 연설이라고도 할 수 없었을 겁니다. 그저 자료구조 기초조차 모르는 게임디자이너들에게 이를 알려주면 열 번째 지역의 첫 번째 몬스터를 만들기 위해 기존에 비해 공간을 두 배 더 많이 사용하는 데이터를 사용하라는 요구사항을 철회할 거라고 예상한 모양입니다. 하지만 예상하셨겠다시피 그런 일은 일어날 수가 없었습니다. 이미 숫자에 함부로 의미를 부여해서는 안되고 또 현대에 그럴 필요도 없다는 말을 어떻게 해서도 설득할 수 없었던 상황이었기 때문입니다.

그런 사실을 엔지니어들이 눈치 챘기 때문이었는지는 모르겠지만 자료구조 수업은 그렇게 끝나지 않고 이번에는 바로 이어서 그 분이 오래 전 현재 삼평동 668번지에 위치한 회사에서 게임 역사에 길이 남아 있는 어떤 게임의 대단한 서버를 만들던 시대의 이야기로 넘어갑니다. 그 시대에 게임 서버를 만들며 열악한 상황 속에서 최대한의 성능을 끌어내고 또 그런 성능이 여러 동시접속자를 처리할 수 있도록 하기 위해 데이터를 조금이라도 아껴야 했고 더 적은 메모리를 사용해야만 하는 요구사항에 직면했으며 그런 상황 속에서도 멀쩡히 돌아가는 서버를 개발하기 위해 숫자는 항상 최대 21억 또는 약 42억을 초과하지 않는 범위 안에서만 사용하고 이런 기반 위에 구축한 서버의 여러 예측 가능한 동작과 여러 문제 해결 방법을 이해하게 되었다는 이야기를 듣습니다. 사실 나머지들은 이런 그 분의 게임 서버 개발의 역사 강의가 그리 낯설지 않았는데 그도 그럴 것이 회의가 조금만 길어지면 이 분으로부터 과거에 게임 서버를 만들며 겪었던 사례들을 원하지 않더라도 들을 기회가 여러 차례 있었기 때문입니다. 몬스터 아이디에 부여할 숫자 한 자리를 늘리기 위해 8바이트를 사용하는 숫자를 사용해야 한다고 말하는 사람이나 실제 데이터는 몇 개 되지도 않는데 이미 다섯 자리를 초과하는 숫자를 사용해야 한다고 말하는 쪽 양쪽 모두 어떤 방향으로든 설득하고 싶은 생각이 전혀 들지 않았습니다. 한 쪽은 이미 애초에 이 체계를 결정하면서 숫자 모양으로 된 아이디를 대신할 표현 방법이 있으니 그걸 사용하면 된다고 말했지만 완전히 무시당했고 다른 한쪽은 자료구조 수업과 게임 서버 개발의 역사 수업을 늘어놓고 있는 마당이었습니다. 차라리 회의에 들어오는 대신 화장실에 가서 걸려오는 전화를 무시하고 있었더라면 지금보다는 덜 불행했을 것 같은데 이미 저는 회의에 들어와 있었고 아무 말도 할 수가 없었습니다. 결국 기존 첫 두 자리를 패키지 번호로 사용해 최대 42가지 패키지를 구분하려던 것을 한 자리로 줄여 최대 4가지 패키지를 구분하도록 하고 여전히 엑셀 데이터 구분에 세 자리, 그리고 나머지 여섯 자리를 엑셀 데이터 각각이 사용할 수 있는 숫자로 할당하기로 합니다.

사실 이 의사결정에서 서로 간의 요구사항은 아주 간단합니다. 게임디자인은 몬스터 데이터에 여섯 자리 숫자를 사용하기를 원했고 서버에서는 최대 열 자리 숫자를 사용하는 제한을 유지하기를 원했습니다. 그렇다면 이 안에서 조율해 자리를 조절해 열 자리 숫자를 유지하면서도 열 번째 지역의 첫 번째 몬스터를 100010번으로 시작하도록 할 방법을 찾는데 집중하면 됐습니다. 여전히 개인적으로는 현대에 숫자로 된 엑셀 데이터 관점에서 일종의 로컬 아이디 개념인 숫자에 과거와 같이 어떤 의미를 부여하는 행위가 올바르다고 생각하지 않습니다. 숫자에 의미를 부여하기 시작하면 아주 쉽게 업무에 사일로링을 유발하고 방금과 같은 어처구니 없는 문제에 쉽게 내몰릴 수 있으며 신규 인원의 온보딩을 고통스럽게 만들 뿐 아니라 이 자체가 아무런 의미도 없습니다. 다른 한편으로는 자료구조에 대한 일장 연설을 들으면서도 여전히 아이디에 8바이트 숫자를 사용해서는 안되는 이유를 납득하지도 못했습니다. 분명 뭔가 이유가 있을테지만 자료구조 관점의 이해를 요구 받는다고 해서 갑자기 서버에서 사용하는 모든 숫자가 반드시 최대 4바이트여야만 하는 이유를 납득할 수는 없었고 그 연설은 아무런 도움이 되지 못했습니다. 더군다나 바로 뒤에 이어진 현재 삼평동 668번지에 있는 회사의 전설적인 게임들의 게임 서버를 만들던 이야기 역시 더더욱 의사결정에는 아무런 도움이 되지 못합니다. 이 모든 이야기가 진행되는 내내 저는 아무 말도 하지 않고 혹시 누군가 저에게 말을 걸까 무서워 숨소리도 내지 않은 채 조용히 어두운 구석에 앉아 있었습니다. 평소 같으면 키보드를 두드려 회의록이라도 작성했겠지만 이번에는 소리를 낼까 무서웠고 소리를 내면 저에게 누가 말을 걸까 무서워 아무 소리도 내지 않았고 덕분에 아무런 기록도 남기지 않았습니다. 연설은 그렇게나 무섭습니다.

(3) 가능하면 위원회에 사안을 회부하여 더 연구하고 고려할 수 있도록 하세요.” 위원회는 가능한 한 5명 이상으로 구성하세요. 팀에 일어나는 여러 가지 문제나 새로운 규칙을 만들 때 주로 팀장급 이상이 모인 회의에서 결정하곤 합니다. 이 회의의 흥미로운 점은 이들이 모여 결정하는 주제의 상당수는 이들 각각에게 전문성이 거의 없는 주제였다는 점입니다. 가령 실무자가 자신이 수행하려는 업무의 카운터파트 또는 컨텍포인트가 누구인지 알 수 없는 상황으로부터 어려움을 겪어 왔고 이 주제가 회의에 회부되었다고 해 봅시다. 다들 이 주제가 어떤 문제라고 인식할 수는 있겠지만 이 자리에 모인 사람들 대부분은 이미 실무를 그만둔 지 수 년이 지난 사람들이 대부분이어서 현대에 실무자들에게 어떤 일이 일어나고 있는지 전혀 모르고 있거나 그들이 겪는 어려움을 과소평가하는 경향을 강하게 보입니다. 각자가 의견을 말하고 또 각자의 의견에 대한 자신들의 생각을 말하며 문제를 완화하기 위한 어떤 방법이라도 논의될 수 있겠지만 근본적으로 이들은 실무자들이 처한 상황에 대해 거의 아무런 전문성이 없으며 이들이 방 안에 모여 앉아 아무리 오래 이야기하더라도 이들이 도출한 결론은 문제를 완화할 가능성이 거의 없을 겁니다. 이들은 문제를 겪는 당사자가 아니며 이들에게 당사자들에 준하는 전문성을 기대할 수 없기 때문입니다. 하지만 이들은 어찌 됐건 문제를 해결할 방법을 찾아내야 한다는 압력을 받기는 하기 때문에, 그리고 그 방법은 성공적이어야만 한다는 압력 또한 받기 때문에 적어도 이 방 안에 모인 사람들 관점에서는 말이 되는, 그러나 이들 스스로는 절대 실천하지 않고 또 실천할 필요조차 없는 이상한 규칙을 만들어 자랑스럽게 공지사항이랍시고 발표합니다.

종종 개발 목표를 달성하기 위해 여러 부서에 걸친 태스크포스를 만들 때가 있습니다. 태스크포스 하면 뭔가 멋져 보이고 여기 속한 각자의 업무 우선순위를 완전히 재 조정할 수 있기 때문에 종종 목표를 달성하는 좋은 방법으로 여겨지기도 합니다. 그런데 태스크포스가 나머지 조직에 비해 더 잘 동작하는 것처럼 보이는 가장 큰 두 가지 이유는 먼저 이들에 태스크포스에 속함으로써 업무 우선순위를 태스크포스의 목표에 해당하는 업무로 스스로 재설정 할 수 있는 권한을 가지기 때문입니다. 다른 한 가지 이유는 태스크포스 스스로가 직접 의사결정 권한을 가지기 때문입니다. 만약 태스크포스 형태를 통하지 않고 업무를 수행할 때 사소한 의사결정이라도 중간관리자 이상이 모인 회의에서 하나하나 결정해야만 한다면 당연히 업무 진행은 느려지고 의사결정을 하기에 충분한 전문성을 가진 실무자들이 의사결정에 참여하지 못한 채 전문성이 현저히 떨어지는 중간관리자 그룹의 덜떨어진 의사결정을 무기력하게 기다릴 수밖에 없습니다. 이에 비해 태스크포스 조직은 전문성이 부족한 중간관리자 그룹의 의사결정에 기대지 않고 그들 스스로 의사결정 할 수 있기 때문에 의사결정 각각에 대한 전문성이 높은 사람들이 의사결정에 참여할 뿐 아니라 그들 스스로 빠르게 결정을 실험하고 결과에 따라 진행 및 철회할 수 있기 때문에 빠른 개발이 일어날 수 있습니다. 그런데 태스크포스가 나머지 조직에 비해 더 효율적으로 업무를 수행하는 것처럼 보인다면 사실 그 나머지 조직은 이미 심각한 문제를 겪고 있다는 반증이나 다름없습니다. 오직 태스크포스 같은 별도의 조직 구성을 통해서만 전문성이 있는 사람들에 의한 의사결정과 업무 우선순위에 대한 직접 조정, 빠른 실험과 실패를 반복할 수 있다는 의미이며 나머지 조직에서는 이 모든 행동을 할 수 없다는 의미이기 때문입니다. 의사결정은 전문성이 현저히 떨어지거나 거의 없다시피 한 중간관리자 이상이 모인 회의에서 괜히 시간만 오래 끈 다음 결정되고 그런 의사결정 결과는 전문성이 떨어질 뿐 아니라 이를 실행하지 않을 사람들에 의해 결정되므로 종종 부적절할 뿐 아니라 현실성이 없기까지 하며 이런 의사결정이라도 수행하기 위한 우선순위 설정을 실무자 스스로 할 수 없는 이상 태스크포스를 제외한 나머지 조직은 온전히 업무를 수행할 수 없다고 봐야 합니다.

여기서 ‘위원회’는 현대에 실제 의사결정을 필요로 하는 이 의사결정에 참여하기에 충분한 전문성이 있고 또 의사결정의 결과를 실제로 수행해야 하며 의사결정의 결과에 의해 업무에 큰 영향을 받는 사람들과는 동떨어진 중간관리자 이상의 사람들이 모여 자신들이 제대로 알지도 못하는 주제에 대한 의사결정을 해야 한다는 압력을 받는 사람들의 집단을 말한다고 생각합니다. 간단히 의사결정 권한을 이를 실제로 필요로 하는 실무자 수준으로 내리고 빨리 실행해 보고 빨리 실패하게 만들면 된다는 사실을 모든 사람들이 알고 있고 또 이 과정에서 어떤 경험에 기반한 조언이 필요하다면 중간관리자 이상은 요청을 받았을 때만 제한적으로 개입해 의사결정 자체에 영향을 주는 대신 각각의 의사결정이 일어날 때 자신이 예측한 결과를 설명한 다음 바로 빠져 의사결정 자체에 영향을 최소화 하면서도 의사결정이 올바르지 않은 방향으로 일어날 가능성을 줄일 수 있습니다. 또한 의사결정을 실무자 수준으로 내림으로써 실무자들 각각은 충분한 전문성에 기반한 의사결정을 내릴 가능성이 높아지고 의사결정을 반복함에 따라 의사결정을 더 잘 할 수 있도록 훈련되는 효과도 있습니다. 하지만 이런 과정을 무시하고 옆 나라의 선조들이 그랬던 것처럼 모든 의사결정을 각각의 분야에 비전문가들인 중간관리자들이 모인 ‘위원회’에서 실무자들이 처한 상황과 문제를 별로 깊이 이해하지도 못한 사람들이 모여 의사결정을 반복한 결과 계속해서 이상한 명령을 내린 끝에 결국 핵폭탄을 얻어 맞는 결과로 끝난 사례로부터 아무런 교훈을 얻지도 못한 채 현대에도 여전히 실무에서 겪는 아무리 작은 의사결정이라도 전문성이 떨어지는 중간관리자 이상의 ‘위원회’가 직접 결정해야 한다는 어떤 강박에 사로잡혀 있는 것 같습니다. 이 점을 활용해 의사결정 과정을 지연 시키고 의사결정을 이 문제에 대한 전문성이 떨어지는 사람들이 한 방에 모여 각자의 정보 접근성이 현저히 떨어지는 상태에서 결정하게 만들고 단지 이 위원회의 결정이라는 이유만으로 명백히 이상한 결정이라도 실무 선에서는 이를 따를 수밖에 없는 상황을 만들면 그 결과를 굳이 너절하게 설명하지 않더라도 조직의 목표를 크게 위협할 수 있습니다. 이 방법의 장점은 과거나 지금이나 이 방법이 명백히 이상하다는 사실을 위원회의 구성원들이 절대로 납득하지 않기 때문에 매우 안전하게 조직의 목표를 망가뜨릴 수 있다는 점입니다. 위원회 구성원들은 자신들이 실무에 비해 충분한 전문성을 확보하고 의사결정을 하고 있다고 생각하고 이 점에 대한 반례를 들으면 이를 자신들 전체에 대한 공격이라고 생각해 강하게 반응하곤 하기 때문에 그저 조용히 이 전문성이 떨어지는 위원회에 그들이 모르고 있던 의사결정거리를 전달하기만 해도 프로젝트 전체의 목표를 위협하고 실무 선의 사기를 크게 떨어뜨릴 수 있으며 이 상황을 만들어낸 자신은 거의 아무런 피해를 입지 않을 수 있습니다.

지금까지 (11)-(a) ‘조직과 회의’ 부분의 전체 여덟 가지 항목 중 세 가지 항목을 살펴보기만 했을 뿐인데도 이야기가 너무 길어져 끊어 가는 것이 좋겠습니다. 마치 이 이야기 자체가 회의에서 회의 주제와 아무런 관계도 없는 일장 연설을 초안 기준으로 이미 1만5천글자 이상 떠들고 있는 것과 별로 다를 것이 없어 보입니다. 단지 세 가지 항목을 살펴봤을 뿐인데도 우리들 주변에 정보기관이나 경쟁사에서 파견한 스파이가 얼마나 많이 암약하고 있는지 느낄 수 있을 겁니다. 지금까지 제가 일해 본 회사 거의 전부는 취업 규칙에 겸업 금지 조항을 포함하고 있습니다. 그런데 정보기관으로부터 파견되어 회사와 정보기관 양쪽으로부터 급여를 받는다 하더라도 이를 겸업 금지 조항을 위반했다고 해석하기는 쉽지 않을 것 같습니다. 하지만 경쟁사에서 파견되어 경쟁사로부터 받은 사보타지 활동으로부터 급여를 받고 동시에 현재 명시적으로 고용된 회사로부터 급여를 받는다면 이는 어쩌면 겸업 금지 조항을 위반하고 있다고 해석할 수 있지 않을까 싶은 생각이 듭니다. 그렇잖아도 회사로부터 인플레이션을 도저히 따라가지 못하는 급여를 받으며 가난하게 사는 마당에 주변 사람들은 어쩌면 그렇게 부유한 생활을 하는지 궁금했는데 꽤 많은 사람들이 경쟁사에 고용되어 사보타지 활동을 활발하게 수행하며 양쪽 모두로부터 급여를 받고 있지 않은가 싶은 생각을 해봅니다. 이제 다섯 가지 항목이 남았는데 이들은 다음 글에서 살펴보겠습니다.