기획자를 철저히 망가뜨리는 방법 (1)

과연 현대 게임 개발에도 소위 ‘기획자’가 필요할까요? 개인적으로 이 질문을 오랫동안 해 왔습니다. 제 스스로가 한국에서 이 직군에 속해 생계를 유지하고 있기는 하지만 개인적으로 제 스스로가 자신이 하는 일에 얼마나 전문성을 가지고 있는지 생각해보면 이 직군이 다른 직군에 비교해 독립적으로 역할을 수행하며 프로젝트의 다른 부서가 수행할 요구사항을 정의하는 행동을 할만한 자격이 있는지 의심스러워 하곤 합니다. 상업용 게임 소프트웨어가 아닌 다른 분야의 프로젝트에 종사한 적이 없어 다른 분야의 소프트웨어 개발에 대해서는 소문을 들을 뿐입니다. 또 시간이 흐르자 이 분야에서 저와 비슷한 직군에 속해 프로젝트를 이끌어 가시던 분들이 다른 분야의 소프트웨어 개발 관리 업무로 자리를 옮기는 사례가 늘어나면서 다른 소프트웨어 개발 업계의 이야기를 들을 기회가 늘어나고 있습니다. 흥미로운 점은 소위 ‘기획자’라는 직군을 프로젝트 안에 두고 이들로부터 직접 요구사항을 수취하는 방식으로 개발하는 소프트웨어는 드문 것처럼 보인다는 점입니다. 어지간한 소프트웨어가 클라이언트는 회사 밖에 있고 이들로부터 요구사항을 수취해 프로젝트 내부에서 개발을 시작하는 것과 달리 상용 게임 소프트웨어는 다른 프로젝트의 클라이언트와 비슷한 역할을 프로젝트 내에 수직계열화 한 모양의 조직을 구성한 채 개발하는 것처럼 보입니다.

하지만 이들은 프로젝트 전체가 근거해 움직이게 될 요구사항을 도출하는 역할을 하기에는 여러 모로 문제가 있어 보입니다. 가령 이들은 실제 프로젝트의 결과물에 반응할 고객과는 거리가 있을 때가 많습니다. 가령 우리는 흔해 빠진 양산형 모바일 수집 게임을 개발하고 있는데 누군가는 어제 집에서 플레이 한 싱글플레이 오픈월드 게임에 나온 메커닉에 대해 이야기하며 우리들에게도 같은 메커닉이 필요하다고 주장하기 시작해 여러 사람들을 아주 곤란한 상태에 빠뜨리기 일쑤입니다. 이들은 그들의 요구사항을 문서로 만들고 그들이 20년 이상 전부터 사용해 온 아주 오래된 데이터 입력 방법을 고수하며 현대적인 프로젝트 파이프라인에 별 관심을 가지지 않을 뿐 아니라 이에 대한 전문성을 가지고 있어 보이지도 않습니다. 이들은 아트 에셋을 만들거나 이를 조립하는 것 같아 보이지도 않고 또 프로덕션 코드를 만들 수 있어 보이지도 않습니다. 조직 내에서 서로 의사소통을 원활하게 하는 것 같지 않아 보이기도 하는데 이는 종종 거의 비슷한 요구사항이 서로 다른 부서의 서로 다른 기획자들로부터 동시에 나와 이들 사이에 교통 정리를 하는데 노력을 쏟는 어이 없는 상황을 연출하기도 합니다. 이쯤 되면 과연 현대 상용 게임 소프트웨어 개발 프로젝트에 이들이 필요한지 자체를 근본적으로 고민할 수밖에 없게 만듭니다.

역사적으로 의미 있는 결과를 만들어낸 기획자들을 생각해봅시다. 이들은 주로 기획자 출신이 아닙니다. 최근 국내에서 거의 나오기 어려운 장르와 플랫폼으로 게임을 만들어낸 사람들은 아티스트 출신이었습니다. 시간을 이리 저리 돌려 가며 의미 있는 결과를 만들어내고 역사에 작은 기여라도 하고 있는 사람들은 주로 직접 프로덕션 코드를 만들던 사람들일 때가 많습니다. 현대에는 미들웨어의 발전으로 이들 사이의 관계가 점점 더 모호해지는 추세이기도 합니다. 이에 비해 현대 프로젝트에 속한 소위 기획자들은 여전히 프로덕션 코드를 만드는데 직접 기여하지도 않고 또 스스로 어떤 에셋을 생산하지도 않는 것 같아 보입니다. 미들웨어는 과거에 오직 코드로 제어해야 했던 다양한 분야의 기능을 그저 도구가 제공하는 인터페이스를 조작해 만들어낸 에셋 모양으로 만들 수 있도록 하고 있고 이 범위가 극적으로 확장되고 있지만 여전히 이들은 오래된 익숙한 방법에 주로 머무르며 현대적인 개발 파이프라인의 구축과 이행을 어렵게 만듭니다. 이쯤 되면 개발팀에 이들이 근본적으로 필요하지 않다고 가정해볼 수 있지 않을까요? 그래서 오늘은 프로젝트에서 기획자들의 사기를 떨어뜨려 위축시키고 그 결과 판단을 무디게 만들어 요구사항을 제시하는 권한을 이들로부터 서서히 제거하고 또 나아가 이들을 파괴하는 여러 가지 방법을 소개하겠습니다. 이 글을 준비하면서 내용의 여러 부분이 심플 사보타지 - 조직과 회의 (1), 심플 사보타지 - 조직과 회의 (2)에 다룬 적 있는 내용과 그 뿌리가 비슷하다는 느낌이 들기는 합니다. 하지만 좀 더 게임 프로젝트에 속한 기획자들을 파괴하는데 초점을 맞추고 있다는 점이 다릅니다. 자. 그럼 시작합니다.

첫째. 이미 설명을 들은 주제를 시차를 두고 모르는 것처럼 반복해서 질문하세요. 만약 기획자가 질문에 즉답하지 못한다면 이를 강력히 비난하세요. 이번 마일스톤 업무를 시작하기 위해 기획팀으로부터 문서를 받았을 겁니다. 또 문서를 브리핑하고 주요 쟁점을 논의하는 꽤 많은 사람들이 들어와 기획자를 공격하는 회의를 거쳤을 겁니다. 이 회의에서 여러 가지 질문이 쏟아지고 또 답변이 이루어졌고 이 과정을 기록한 문서가 있을른지도 모릅니다. 하지만 회의 때 주고 받은 질문과 답변은 모두의 단기기억 저 편으로 사라지기 쉽고 또 이 과정을 기록한 문서는 하루에도 수없이 생산되는 컨플루언스 위키의 문서 더미 저 편으로 손쉽게 사라집니다. 사실 회의 때 주고 받은 온갖 질문은 그냥 회의가 끝난 직후 밖에 나가 담배 한 대 빨고 오면 다 잊어버리고 이는 인간의 단기기억이 작동하는 방법을 고려할 때 당연한 일입니다. 이미 내용은 잊어버렸고 이를 기록한 문서를 찾아보고 싶지도 않습니다. 그러니 시간이 흘러 실제로 이 일을 시작하려 할 때 의문이 생겼다면 이를 이전에 물어본 적이 있을지 고민할 필요가 전혀 없습니다. 만약 이전에 들은 답변이 기억난다 하더라도 그 사이에 어떤 변화가 일어났을 수 있으니 질문이 생길 때마다 즉시 담당 기획자에게 질문하세요. 이 방법은 내 단기기억을 희생할 필요가 없고 장기기억에 더 중요한 것들을 기억할 여지를 남겨줍니다.

그런데 담당 기획자는 문서를 작성한 시점에서 가장 최신 질문을 받는 시점 사이에 기간이 경과함에 따라 질문에 바로 답하지 못할 수 있습니다. 놀랍게도 이들은 매 마일스톤 마다 한 가지 주제에 집중하지 않기 때문입니다. 이들은 한 가지 주제에 대한 문서를 작성하고 나면 바로 다른 주제의 문서를 작성하기 시작하고 브리핑 회의 하나를 마치면 다음 날 바로 다른 주제로 브리핑 회의를 하기 일쑤입니다. 또 이들은 기 구현된 기능이 정상 동작하는지 테스트하는 일종의 BVT에 가까운 일을 수행하기도 하고 또 다음 마일스톤 계획을 수립하거나 다가온 허들에 통과하기 위한 시나리오를 준비하는데 정신이 팔려 있기도 합니다. 이번 마일스톤에 개발해야 할 중요한 주제에 집중하지 않고 이렇게 온갖 다른 일에 정신이 팔려 있기 때문에 시간이 흐른 다음에 하는 질문에 즉시 정확한 답을 하지 못할 가능성이 높은데 다른 직군도 아니고 이 주제를 가장 잘 알고 있어야 하는 담당 기획자가 이렇게 행동해서는 안됩니다. 다시는 이런 일이 일어나지 않도록 이 상황을 여러 사람들에게 공유하고 문제를 제기하고 강력하게 비난하는 것이 좋습니다. 그래야 기획자들도 긴장감을 가지고 자신이 몇 주 전에 브리핑 하며 들었던 질문들에 대한 답변을 오롯이 기억하고 또 이 질문이 나온 원인을 내제화 해 자신의 게임디자인에 반영하고 또 나아가 이를 문서화 할 수 있기 때문입니다.

둘째. 기획자의 담당 업무가 아닌 연관 주제에 대해 질문하고 즉시 답변을 요구하세요. 기획자가 즉답하지 못한다면 ‘기획자가 다른 분야에 대해 너무 모른다’고 소문을 내 관리자에게 간접적으로 전달되도록 하세요. 실제 세계를 구성하는 시스템으로부터 시작해 가상 세계를 구성하는 시스템에 이르기까지 여러 시스템은 이를 구성하는 여러 가지 단위 기능이나 동작의 조합으로 구성되며 이들의 상호작용을 통해 의도한 동작을 수행합니다. 때문에 기획자는 자신의 담당 분야 뿐 아니라 이와 연결된 다른 분야, 다른 업무에 높은 수준의 전문성을 가지고 있어야 합니다. 흔히 커다란 MMO 프로젝트에서 코어 메커닉을 다루는 부서와 보조 시스템을 다루는 부서를 구분해 놓곤 합니다. 코어 메커닉 담당자들이 플레이어와 대상 사이에 거리를 계산하는 적절한 방법을 이미 고안해 구현해 놓은 상태이더라도 다른 부서에서는 이 사실을 모를 가능성이 있습니다. 그래서 분명 상대와 나 사이에 거리를 계산하는 잘 동작하는 방법이 있음에도 훨씬 전문성이 떨어지는 상태로 작성한 것이 분명한 훨씬 조잡한 거리 측정 메커닉을 만들어 달라는 요구사항이 나타나기도 합니다. 때문에 코어 메커닉을 담당하지 않는 마을에 있는 상인 NPC의 상점 기능을 담당한 기획자에게 플레이어캐릭터와 상인 NPC 사이에 거리를 상호작용 가능한 거리를 측정하는 방법을 질문하는 것은 당연한 일입니다.

이 상황에서 상점 기획자는 상인 NPC와 상호작용 하려면 명백히 플레이어와 대상 사이에 거리를 측정해 이 거리가 유효한지 확인하는 메커닉이 필요하다는 사실을 알고 있겠지만 이 메커닉이 이런 요구사항을 보다 전문적으로 다루는 다른 부서에 의해 이미 개발되었다는 사실을 모른 체 훨씬 조잡한 계산 방식을 기획서에 제안했을 수 있습니다. 이런 상황을 그냥 넘어가서는 안됩니다. 기획자가 몇 명이든, 얼마나 많은 조직으로 나뉘어 있든 핑계를 댈 수 없습니다. 만약 상점을 담당한 기획자가 플레이어와 상인 NPC 사이에 거리 측정 방식을 코어 메커닉 담당 부서에서 이미 개발한 것과 같은 모양으로 제안하고 또 이를 제대로 답변하지 못하는 것은 극히 실망스러운 상황입니다. 하지만 이 상황에 즉시 문제를 제기하는 것은 적절하지 않습니다. 일단 실망스러운 답변을 들은 다음 자리로 돌아와 적당히 이 상황을 다른 사람들에게 전파해 이 상황이 그 기획자의 관리자에게 간접적으로 도달하게 만들면 이 상황에 해당하는 정확한 담당 기획자에게 피드백을 보내는 대신 모호하게 모든 기획자들에게 부정적인 피드백을 보낼 수 있습니다.

셋째. 기계가 할 수 있는 일을 사람이 하도록 요구하세요. 겹치지 않는 전역 아이디를 생성하는 일은 사람이 하기에 적합합니다. 자동화 가능한 작업을 ‘문서를 통해 취합’한 다음 별도로 ‘요청’하라고 말하세요. 프로젝트 구성원들을 서로 다른 직군으로 구분할 때 기획자들의 급여가 가장 낮다는 사실을 알고 계신가요? 그럴 만도 한 것이 이들은 에셋을 만들지도 않고 직접 프로덕션 코드를 작성하지도 않습니다. 이들이 하는 일이라곤 앞서 언급했다시피 문서를 작성하거나 낡아 빠진 엑셀 파일을 만들어내는 것 뿐입니다. 그러니 이들이 낮은 급여를 받는 것은 이상하지 않습니다. 또한 이들이 낮은 급여를 받는다는 사실은 이들을 여러 업무에 직접 활용할 때 프로젝트 전체의 비용 효율을 끌어올릴 수 있음을 의미하기도 합니다. 가령 겹치지 않는 UID를 수동 생성하는 요구사항을 기획자들이 직접 수행하게 하는 것은 아주 좋은 출발점입니다. 자신이 작성한 데이터에 책임을 지고 이 데이터가 점유하는 중복되지 않는 구분자를 직접 주의 깊게 발급하고 충돌하지 않는 상태를 만드는 것이야말로 빌드가 오동작하지 않도록 만드는 첫걸음이자 운용 비용이 가장 낮은 기획자들을 올바르게 활용하는 길입니다. 만약 이 과정을 자동화 하려고 하면 훨씬 비싼 인력의 많은 시간을 들여야 합니다. 사람이 할 수 있는 일을 기계가 수행하도록 하기 위해 기획자에 비해 훨씬 급여가 높은 다른 직군이 나서 코드를 작성하고 유지보수 할 일을 생각해보세요. 이 시간에 더 의미 있는 기능을 개발하고 이 정도 역할은 사람이 직접 하도록 하면 프로젝트 전체 관점에서 볼 때 비용을 절약하게 됩니다.

또 기획자들이 필요한 행동을 직접 수행할 수 있는 환경을 구축하거나 이들의 필요를 바로바로 처리해주는 것 역시 이들보다 더 높은 급여를 받는 사람들의 생산성을 고려할 때 결코 좋은 방법이 아닙니다. 가령 엑셀 데이터를 읽어들여 런타임에 서버에서 빠르게 접근할 수 있도록 데이터베이스에 기록해 놓았다고 해 봅시다. 데이터베이스는 엑셀에 의해 구축되었으므로 엑셀 파일에서 데이터가 함부로 삭제되면 데이터베이스는 자신의 근거가 되는 데이터를 찾지 못해 데이터베이스에 기록된 데이터가 모호한 상태가 됩니다. 또 이 데이터를 참조해 동작하는 기능이 있을 가능성이 있기 때문에 함부로 데이터를 삭제하는 것은 위험합니다. 고려 가능한 방법은 특정 데이터를 삭제하려고 할 때 이 데이터를 참조하는 데이터베이스 상의 다른 데이터가 있는지 확인하고 참조관계가 남아 있다면 데이터를 삭제하지 않거나 이 참조관계를 사용자에게 알려주고 이를 엑셀 데이터 수준에서 해결한 다음 다시 삭제를 시도하게 하거나 이 과정을 직접 쿼리를 사용할 수 있는 환경을 구축하는 것일 수도 있습니다. 하지만 이 과정을 구축하는데는 기획자들에 비해 훨씬 비용이 높은 인력을 운용해야 하고 이 환경을 유지보수 하는데도 장기적으로 높은 비용이 들 것이 분명합니다. 때문에 이런 요청을 기획자들이 주로 사용하는 문서 도구에 문서 모양으로 남겼다가 한 달에 한 번, 혹은 분기에 한 번 정도 몰아 수행해 더 효율적으로 일할 수 있습니다.

넷째. 아주 작은 동작 하나하나를 질문하세요. 하나라도 답변되지 않으면 전체 업무 진행을 중단하고 다른 업무를 진행하세요. 업무 전환을 절대 알리지 마세요. 마감 직전에 특정 문의에 답변이 없어 진행하지 않았다고 말하세요. 문서는 에러를 내지 않습니다. 컨플루언스 위키에 문서를 작성할 때 문서 위쪽과 아래쪽에서 같은 대상을 지칭하는 서로 다른 단어를 사용했다고 해서 문서가 크래시 되거나 오동작 하지 않습니다. 때문에 문서는 일치하지 않는 용어와 정의되지 않는 동작으로 가득합니다. 아이템 여러 개를 선택해 한 번에 사용하는 화면에서 아이템 수량이 0일 때 수량 감소 버튼을 한번 더 조작하면 어떻게 동작해야 할까요? 레벨과 레벨 사이를 이동하기 위해 클라이언트의 로딩을 기다리는 사이에 도착한 채팅 메시지는 어떻게 처리해야 할까요? 기획자들이 작성한 문서는 이런 동작이 정확히 정의되지 않더라도 결코 오동작 하지 않습니다. 하지만 코드를 작성하는 입장에서 이렇게 정의되지 않은 상황을 처리하지 않으면 컴파일에 실패하거나 빌드가 크래시되거나 오동작 하기 일쑤입니다. 기획자는 이 모든 동작을 기획서에 엄밀하게 정의할 수 있어야 합니다. 그런 수많은 정의되지 않은 동작들이 존재한다는 사실을 알고 이에 대응할 수 있어야 진정한 기획자라고 말할 수 있지 않을까요?

이런 상황을 절대 그냥 넘어가서는 안됩니다. 기획서에 정의되지 않은 동작 하나하나의 구체적인 동작 시나리오를 질문하고 이들 모두가 기획서에 완벽하게 정의되어 있어야 하는 당연한 요구를 전달하세요. 만약 정의되지 않은 동작을 임의로 개발했다가 이 동작이 문제를 일으켜 여러 사람들로부터 책임 추긍을 받게 될 수 있습니다. 아이템 수량이 0인 상태에서 수량 감소 버튼을 한번 더 누르게 하는 대신 수량이 0일 때 버튼을 비활성 상태로 바꿀 수 있습니다. 이를 통해 문제를 일으킬 수 있는 정의되지 않은 동작이 일어날 가능성을 줄였지만 나중에 가서 모든 버튼은 일단 눌려야 하며 버튼이 눌리는데 따른 동작이 예상과 다를 경우 이를 고객에게 알려줘야 한다는 식으로 요구사항이 변경 및 확장된다면 이 상황을 만든 사람이 책임을 추긍 받을 수 있습니다. 때문에 기획서에 정의되지 않은 동작을 절대 임의로 개발하지 말고 모든 상황을 기획자에게 질문에 동작을 정의한 다음 그대로 진행해야 합니다. 만약 동작 정의가 늦어진다면 전체 개발이 늦어지는 것은 당연합니다. 답변이 늦어진다면 개발을 중단하고 이 사실을 마감 전에 밝혀 상황의 책임이 전적으로 기획자에게 있음을 명확히 밝히는 것 역시 중요합니다.

다섯째. 의사결정은 반드시 기획자의 상관과 하고 이를 공유하지 마세요. 담당 기획자가 이를 문제 삼으면 이미 상관과 협의했다고 말하세요. 실무 기획자들 상당수는 연차가 높지 않고 분명 그리 충분한 경험을 가지고 있지도 않을 가능성이 높습니다. 이들은 사실상 직속 관리자나 그보다 더 높은 곳에서 내려온 명령에 따라 문서를 작성하는 일종의 워드프로세서 역할을 합니다. 기획서를 통해 전달 받은 요구사항을 그대로 수행한다면 썩 효율적이지 않을 것 같은 느낌이 들어 협의를 통해 요구사항을 조정하고 싶지만 그저 워드프로세서 역할을 하는 담당 기획자에게 말하면 빠른 답변을 기대할 수 없습니다. 사실 이 담당 기획자는 사실상 아무런 권한도 없기 때문에 아주 간단한 질문이라도 자신의 관리자, 또는 그보다 높은 누군가에게 질문을 해 답변을 받은 다음 답변을 전달하는 메신저 역할 이상을 기대할 수 없습니다. 어차피 답변은 항상 관리자 이상으로부터 얻을 수 있다면 굳이 담당 기획자에게 직접 질문해 시간을 낭비하고 또 워드프로세서를 메신저로 사용할 필요도 없습니다. 처음부터 담당 기획자 대신 실제 의사결정이 가능한 상급자와 대화하세요. 원하는 의사결정을 훨씬 빨리 얻어 시간을 절약할 수 있습니다. 그리고 시간이 지난 다음 담당 기획자가 자신의 예상과 실제 개발이 서로 다른 모양으로 진행되고 있다는 사실을 알게 될텐데 이 때 이미 당신의 상관과 협의했으니 상관에게 문의하라고 말하세요.

여섯째. 인하우스툴은 최대한 엔지니어 친화적으로 만드세요. 눈에 보이지 않는 인터페이스를 만들면 좋습니다. 가령 오브젝트를 배치할 때 마우스 클릭 대신 엔터 키를 누르도록 하고 이를 인터페이스에 표시하지 않으면 큰 도움이 됩니다. 미들웨어가 극적으로 발전하면서 이전 시대와 같이 여러 가지 인하우스 도구를 개발할 필요는 많이 줄어들었습니다. 가령 오래 전 참여한 어떤 게임은 모든 인하우스 도구가 게임 클라이언트에 기반해 동작했는데 인터페이스 프리뷰 도구, 이펙트 프리뷰 도구 역시 게임 클라이언트에 기반해 동작했습니다. 인터페이스 프리뷰 도구는 단지 설정과 에셋을 읽어와 인터페이스를 프리뷰하고 인게임 상에서 조작해볼 수는 있었지만 이를 직접 만들 수는 없었습니다. 그래서 인터페이스를 만드는 사람은 그래픽 에셋을 규격에 맞춰 만들고 이를 텍스트 파일에 지정된 명령어를 사용해 규칙에 맞게 불러오도록 하며 머리 속으로 상상해 적당한 모양을 만들었는지 그려 본 다음 마지막으로 클라이언트를 실행해 프리뷰 해 결과를 확인해야 했는데 이런 환경에서도 잘 동작하는 인터페이스를 문제 없이 개발해 냈습니다. 이펙트도 비슷했는데 기술적인 문제 때문에 인게임 클라이언트에서 파티클 시스템에 의한 이펙트와 애니메이션에 의한 이펙트를 동시에 사용할 경우 이들을 동시에 프리뷰 할 수 없었습니다. 때문에 이펙터는 서로 다른 방식의 에셋을 만든 다음 머리 속에서 이들이 합쳐져 표시될 모양을 상상해야만 했는데 이런 상황 속에서도 훌륭한 이펙트를 만들어냈습니다.

반면 현대에는 미들웨어가 자체적으로 인터페이스 비주얼 에디터를 제공하고 이펙트를 실시간으로 수정할 수 있는 환경을 제공합니다. 이런 상황 속에서 여전히 인하우스툴을 별도로 개발하고 이를 유지보수 하는데 높은 비용을 사용하는 것이 과연 올바를까요? 그렇지 않다고 생각합니다. 때문에 인하우스툴을 최대한 개발하지 않되 어쩔 수 없다면 최대한 엔지니어 친화적으로 개발해야 합니다. 먼저 엔지니어에게 편안한 인터페이스를 사용합니다. 미들웨어에 호환되는 인터페이스를 사용하면 미래에 미들웨어 버전이 변경될 때 영향을 받아 필요 없었을 수정을 해야 할 수도 있고 또 미들웨어 인터페이스의 여러 제약을 받아 개발이 복잡해질 수 있기 때문이기도 합니다. 또 인하우스툴에 인터페이스를 붙일수록 유지보수에 어려움이 생기므로 인터페이스를 최소화 하는 접근 역시 의미 있습니다. 가령 현재 상태를 확정할 때 화면에 표시된 ‘확인’ 버튼을 클릭하게 만들려면 버튼을 배치하고 버튼이 상황에 따라 올바른 위치에 표시되도록 해야 하므로 일이 복잡해집니다. 하지만 이 때 특정 키를 누르거나 특정 명령어를 입력하도록 만들면 인터페이스로 같은 기능을 구현할 때에 비해 훨씬 더 일을 단순하게 만들 수 있습니다. 이런 조작 방법은 기획팀 내에서 구전되므로 걱정하지 않아도 됩니다.

일곱째. 크래시리포트를 수집하지 마세요. 크래시를 겪으면 크래시리포트를 직접 복사해 슬랙에 붙여넣도록 하세요. 실수로 창을 닫고 재실행했다고요? 그럼 무슨 크래시가 발생했는지 알 방법이 없네요. 혹시 아무 일도 안 일어난 거 아닌가요? 개발 중인 빌드는 불완전합니다. 특히 앞서 소개한 정의되지 않은 동작들로 인해 빌드는 쉽게 크래시 될 수 있습니다. 빌드가 크래시 될 때 크래시리포트를 화면에 표시하지만 엔지니어가 아닌 입장에서 이런 크래시리포트는 그저 암호문처럼 보일 겁니다. 어떤 소프트웨어 프로젝트는 개발 중 크래시리포트를 수집할 뿐 아니라 고객들로부터도 크래시리포트를 수집해 크래시 되지 않도록 한다고도 알려져 있습니다만 개발 단계에서 크래시리포트를 수집하는 것은 쓸 데 없는 일을 만들 뿐입니다. 아직 개발 중이기에 크래시가 발생하면 크래시를 겪은 사람이 직접 슬랙에 스택 트레이스를 붙여 넣고 크래시가 발생한 상황을 설명하게 하세요. 그러면 단순히 크래시 리포트를 자동화된 방법으로 수집할 때에 비해 이를 해결할 더 구체적인 힌트를 함께 얻을 수 있습니다.

또한 크래시리포트를 자동으로 수집할 때에 비해 정말 중요한 크래시에만 대응할 수 있습니다. 만약 크래시리포트를 자동으로 수집하면 별로 중요하지도 않은 상황에 발생하는 크래시리포트가 그저 자주 일어났다는 이유 만으로 중요하게 여겨질 수 있습니다. 종종 클라이언트는 종료 과정에서 메모리를 해제하다가 크래시됩니다. 이런 크래시는 종료 절차가 시작된 다음에 일어나기에 사용자 입장에서 크래시가 발생했는지 자체를 파악할 수 없을 가능성이 높은데 이를 자동으로 수집하면 눈에 띄지도 않는 크래시를 해결하는데 자원을 소모해야만 합니다. 만약 프로젝트 구성원들이 자신이 직접 경험한 크래시에 한해 스택 트레이스를 붙여 넣고 상황을 설명하도록 만들면 이 행위를 할만큼 중요하고 절실한 크래시에 한해 보고를 받을 수 있습니다. 이 문제를 해결하는 것은 방금 소개한 존재하는지 조차 알 수 없는 수 없는 크래시리포트를 해결하는 것에 비해 훨씬 효율적입니다. 또한 기획자들로 하여금 스택 트레이스를 붙여 넣기 전에 이 크래시가 이 메시지를 작성하는 수고를 감수할 만큼 중요한 것인지 다시 한 번 생각하게 만들어 엔지니어들이 정말 중요한 일에 집중할 수 있도록 합니다. 그러니 크래시리포트를 자동으로 수집하지 마세요.

여덟째. 기획서를 최대한 주의깊게 천천히 검토하고 처음부터 끝까지 한 번에 검토하세요. 중간에 생긴 질문을 절대 바로 피드백 하지 말고 모았다가 4주 뒤에 한 번에 보내세요. 여러 기획서를 한 번에 받았나요? 모든 기획서를 검토하는데 8주를 소모한 다음 모든 피드백을 한 번에 보내세요. 기획자들이 작성한 기획서는 다른 프로젝트라면 클라이언트로부터 수취한 요구사항과 비슷한 위상을 가집니다. 이 요구사항은 소프트웨어가 개발될 본질적인 목적을 담고 있습니다. 때문에 기획서는 아주 주의 깊게 검토해야 합니다. 앞서 설명한 대로 문서에 정의된 동작 뿐 아니라 정의되지 않은 동작이 있지는 않은지 세밀하게 살피는 것이 좋습니다. 일단 문서 검토를 마친 다음 개발을 시작하면 더 다양한 정의되지 않은 상황들이 나타날 겁니다. 물론 그럴 때마다 기획자에게 질문할 수도 있고 또 앞서 설명한 대로 담당 기획자와 이야기하는 대신 상관에게 이야기 해 빠른 의사결정을 유도할 수도 있습니다. 하지만 가장 좋은 것은 본격적인 개발을 시작하기 전 문서를 철저하고 충분하게 검토해 그런 질문을 할 상황을 최소화 하는 것입니다. 아무리 간단한 기획서라도 맨 앞 첫 번째 글자부터 맨 마지막 글자에 이르기까지 단 한 글자도 빼놓지 않고 검토하고 중간에 정보 집적도가 높은 스크린샷이나 다이어그램, 테이블 등이 나타나면 다른 텍스트를 검토할 때에 비해 훨씬 더 깊이 집중해 문서를 살펴봐야 합니다. 이 절차는 많은 시간을 요구합니다. 때문에 기획서를 검토하는데 충분한 시간을 요구하세요. 문서를 검토하는데 몇 주를 사용하는 것은 문서를 신중하게 검토하기 위한 최소한의 요건입니다.

마일스톤 초반에 여러 기획서를 한 번에 받았을 수 있습니다. 이는 문서 하나를 검토할 때에 비해 훨씬 더 신중하고 주의 깊게 문서 하나하나를 검토해야 할 뿐 아니라 여러 문서에 걸친 사양이 서로에게 주는 영향을 함께 분석해야만 합니다. 서로 잘 의사소통 하지 않는 것처럼 보이는 기획자들이 각자 작성한 문서들에는 분명 중복된 요구사항이 서로 완전히 다른 모양으로 기입 되어 있을 수 있습니다. 또 각각의 개발을 진행한 다음에서야 서로의 영향을 파악해 요구사항 변경을 협의하는 절차가 필요해질 수 있습니다. 이런 절차를 근본적으로 필요하지 않게 만들기는 어렵지만 최대한 긴 시간에 걸쳐 한 번에 받은 여러 문서들을 주의 깊게 검토하고 또 여러 구성원들로부터 의견을 듣고 토의를 거친 다음 결론을 내도 늦지 않습니다. 가령 경국대전은 세조 때부터 편찬을 시작해 성종 때 완성했습니다. 여기에는 30년 이상이 소요되었으며 수많은 학자들의 토론, 검토와 수정이 뒤따랐습니다. 이런 사례를 본받아 최대한 신중하게 기획서를 검토하고 여기에 드는 시간을 아깝다고 생각하지 않아야 합니다. 또한 여러 기획서의 검토는 거의 비슷한 시점에 끝나기 마련입니다. 우리들이 경국대전의 편찬과 같이 30년 동안 이 일에 임하기는 어렵지만 4주 또는 8주 후에 결론을 내리고 피드백을 보내는 수준의 신중함을 보일 수 있으며 이는 매우 바람직합니다.

아홉째. 피드백을 상세히 보내지 마세요. 그냥 안된다고 하면 충분합니다. 시간을 들여 기획자들이 작성한 기획서를 주의 깊게 검토했습니다. 이제 피드백을 해야 합니다. 여러 가지 의견이 있을 겁니다. 그대로 수행해도 될 것 같아 보이는 항목이 있는가 하면 근본적인 재정의가 필요한 항목도 있습니다. 또 기획서 각각을 독립적으로 살펴볼 때 발견할 수 없었던 문제가 이들의 상호작용을 고려해 살펴보며 발견한 문제도 있습니다. 하지만 이러한 구체적인 피드백을 전달한다 하더라도 담당 기획자들은 자신이 담당한 문서에 제기된 문제를 해결하는데 집중할 가능성이 높습니다. 담당자 각각이 자신이 담당한 기획서에 제기된 구체적인 문제를 수정하면 이 기획서들을 다시 독립적으로 검토할 때는 문제가 수정된 것처럼 보이겠지만 이 기획서들이 다시 모여 서로 상호작용 할 때 일어날 수 있는 문제는 전혀 해결되지 않았을 겁니다. 심지어 담당 기획자들이 각자 독립적으로 요구사항을 수정한 덕분에 이들이 뒤섞여 만들어지는 상호작용에 의한 결과는 앞서 기획서들을 신중하게 검토한 모든 과정을 완전히 처음부터 다시 하게 만들 가능성이 높습니다. 때문에 구체적인 피드백을 하는 것은 별로 좋은 아이디어가 아닙니다. 그냥 안된다고 하세요. 안되는 이유는 기획자들이 자신의, 그리고 다른 사람의 문서를 살펴보며 스스로 알아내야 합니다. 이 과정을 통해 장기적으로 기획자들 역시 기획서를 제출하기 전에 기획팀으로부터 나가는 여러 문서를 살펴보고 이들 사이에 일어나는 상호작용을 신중하게 검토하는 자세를 갖추도록 할 수 있을 겁니다. 다만 이들로부터 기획서가 늦게 나오면 개발을 시작할 수 없으므로 이 상황에 따른 책임 소재를 명확히 해 놓아야 합니다.

열째. 20년 전에 출시된 게임의 동작을 예로 들며 ‘이렇게 까지 해야 하나요?’라고 질문하세요. 사실 20년 전에 나온 게임이나 현대에 개발 중인 게임은 근본적으로 서로 크게 다르지 않습니다. 2004년에 출시된 어떤 게임은 아주 많은 퀘스트를 동시에 수행하며 플레이 하도록 만들어졌는데 이 게임의 출시 즈음에 출시를 계획했던 여러 비슷한 장르 게임들이 이 퀘스트 시스템을 구축하고 퀘스트를 개발하는데 1년 이상의 추가 개발기간을 소모하게 만들었습니다. 그런데 이로부터 20년이 지난 현대에도 여전히 비슷한 장르 게임은 비슷한 퀘스트 시스템에 기반하고 있습니다. 그래픽 수준을 보면 뭔가 아주 많이 바뀐 것 같지만 그 근본을 살펴보면 별로 바뀌지도 않았습니다. 그럼에도 기획자들은 다른 게임의 사소한 특징을 가져와 이 기능이 필요하다고 말할 때가 있습니다. 하지만 그런 기능이 있다고 해서 매출이 증가하지도 않고 또 그런 기능이 없다고 해서 서비스에 큰 악영향을 주지도 않습니다. 겉보기에는 별 것 아닌 것처럼 보이지만 실제로는 비용이 높은 기능일 수도 있는데 기획자들은 그런 실제 개발 비용에는 별 관심이 없어 보입니다. 이럴 때 20년 전에 출시한 게임이 현대에도 똑같이 서비스 하고 있음을 근거로 굳이 이렇게 까지 해야 할까? 라고 질문하면 좋습니다. 기획자는 자신이 요구하는 기능의 근본적인 목적을 숙지하고 있지도 않고 또 이 기능의 비용을 알지도 못합니다. 때문에 이렇게 물으면 제대로 답하지 못할 겁니다. 개발할 거리를 줄였으니 출시에 좀 더 가까워졌습니다.

아직 여러 가지 방법 중 한 절반 정도만 소개했을 뿐입니다. 기획자들을 파괴하는 다양한 방법들이 남아 있으니 기획자를 철저히 망가뜨리는 방법 (2)에서 계속합니다.