기획서 점검 혹은 컨펌

한동안 큰 회사에 다닌 적이 있습니다. 그 회사에서는 직원들이 너무 회사 업무에만 매몰되지 않도록 배려해 다양한 교육 기회를 제공했습니다. 외부 강사를 초빙해 여러 가지 주제로 강의 자리를 만들고 이런 자리에 자유롭게 참여할 수 있게 했습니다. 또한 소속 팀의 정당하지 않은 압력 따위에 의해 교육에 참여하지 못하는 상황을 완화하기 위해 단위 기간에 걸쳐 반드시 이수해야 하는 교육 횟수를 정해 놓고 반드시 이수하도록 만들었습니다. 덕분에 회사 공지에 새로운 강의가 열리면 여기에 관심을 가지고 지켜 보게 됩니다.

감사하게도 회사에 속하지 않았으면 여간해서는 기회를 얻지 못했을 흥미로운 강의를 접할 수 있었고 큰 회사에서 겪은 다양한 문제 때문에 과연 스스로가 미래에 큰 회사에 속해 일할 수 있을지 의심스러울 때도 있지만 여전히 큰 회사가 제공하던 그런 다양한 교육과 발전 기회는 아쉽기도 합니다.

한편 그런 교육 중에 기억에 남은 시간은 각자의 성향에 따라 회사에서 인간관계를 구축하고 이를 업무에 적용해 시너지를 발휘하는 요령을 알려주는 것이었는데 지금 생각해 보면 이 강의의 뒷 부분 절반 정도는 꽤 괜찮았던 것 같지만 앞 부분 절반 정도는 인터넷에 떠도는 성격 유형 테스트와 별로 다르지 않은 것 같기도 합니다. 이 교육은 먼저 각자가 설문에 응답해 자신의 성향을 대략 파악하는 과정으로 시작합니다. 강사는 설문 결과를 익명으로 수집한 다음 결과를 살펴보고 결과에 대한 브리핑, 주로 나타나는 성격의 특성을 소개하고 각 유형에 따라 회사에서 겪는 여러 가지 상황에 어떻게 대응하면 더 좋을지 설명했습니다. 그런데 여기서 흥미로웠던 점은 비록 브리핑 대상이 된 사람들의 설문 결과는 익명이었지만 팀을 알 수는 있었는데 팀에 따라 사람들의 성향이 크게 갈렸기 때문입니다.

어떤 서비스를 시작한 지 아주 오래 된 라이브 팀에서 오신 분들은 대부분 충돌 회피 성향이 아주 강하다고 나타났습니다. 이는 좋게 말하면 자신에게 할당된 업무에 의심을 가지지 않고 성실하게 업무를 수행해 안정적으로 결과를 낸다는 의미입니다. 마치 여기는 네덜란드 선적 KONO호입니다에서 소개한 아직 이유나 정확한 할 일은 모르지만 일단 배 밖으로 발판을 내리고 배 이름을 지우기 시작하는 행동과도 비슷할 것 같습니다. 그런데 다른 면을 보면 항상 지시에 의문을 잘 가지지 않거나 의문을 가진다 하더라도 이를 표출하지 않기 때문에 지시가 잘못 되었을 경우 이를 발견할 기회를 놓친 채 그대로 실행되어 의도하지는 않았지만 잘못된 결과에 도달하게 될 가능성도 없지 않습니다.

하지만 라이브를 아주 오래 수행해 게임에 어떤 변화를 가하기 위해서는 이전까지 아주 오랜 세월에 걸쳐 게임에 쌓인 온갖 제약 사항에 철저히 따라야 하며 이들 중 어느 하나만 놓쳐도 고객들에게 직접적인 손해를 입혀 큰 불만을 온 몸으로 받아내야 할 수도 있습니다. 또한 서비스 한 지 오래 된 게임 특성 상 실수를 줄여 주는 현대적인 도구나 실시간으로 데이터를 테스트 할 수 있는 환경이 제공되지 않아 에셋을 조립할 때 아주 조심스럽게 작업해야 하고 작은 실수가 끝까지 발견되지 않은 상태로 QA까지 간 다음에야 발견되거나 그나마 발견되지 않고 아예 서비스에 도달해 버리기도 합니다.

이런 환경에서 일하려면 모든 사람을 고통스럽게 만들 것이 분명한 새로운 시도, 새로운 기능, 새로운 게임모드와 이를 뒷받침하는 보상 체계 따위를 제안하기는 아주 어렵습니다. 또한 이런 시도에 따른 위험 부담을 제안자 개인이 다 떠안게 만드는 조직 문화와 합쳐져 이를 견디지 못하는 사람들은 모두 팀을 떠나고 오직 이 상황을 견뎌낼 강인한 정신력과 성실함을 가진 사람들이 남아 서비스를 지탱하고 있었을 겁니다.

이런 상황에서 작성된 기획서는 종종 확실한 목적과 요구사항을 표현하는 대신 자잘한 기능 마다 ‘누구와 협의해서 결정’ 같은 모호한 말이 자주 등장했는데 이런 접근은 문서를 협업 부서들에게 브리핑 할 때 그들과 부딪칠 일을 줄여 브리핑을 무난하게 넘기고 무난한 요구사항을 협업 부서들이 무난하게 동의할 수 있게 만들기는 합니다. 반면 이런 업무 스타일을 계속해서 유지하다 보면 결국 기획자 자신이 원하는 바가 무엇인지 정확히 설명할 수 없게 되는데 그럴 수밖에 없는 이유는 항상 요구사항 대부분의 필요를 스스로 판단해 결정하지 않아 오기를 반복했기 때문입니다.

제 개인적으로는 이런 상황에 순순히 응하지 않아 왔고 덕분에 낮은 허들에 소개한 대로 저와 함께 일한 경험을 결코 좋은 기억으로 남기지 않은 분들을 만들어냈습니다. 적당히 타협해서 진행하면 될 일을 괜히 자기 주장 강하게 밀어붙여 이를 둘러싼 별로 협업 부서나 상관들과 충돌할 생각이 없는 사람들을 아주 곤란하게 만들었기 때문입니다. 덕분에 사람들을 곤란하지 않게 만들면서도 원하는 바를 얻기 위한 협상 방법이나 사람들에게 프로파간다를 주입하는 비전을 설명하는 방법을 익히기도 했지만 그 이전의 저는 별로 함께 일하고 싶지 않을 사람이었을 것이 분명합니다. 어쩌면 지금도 마찬가지일지도 모르겠습니다.

이제 이런 기반 위에서 기획팀 밖으로 나갈 문서를 점검할 때 중요하게 생각하는 부분이 지금까지 설명한 사례에 기반한 것입니다. 이미 이번 마일스톤에 무슨 일을 할 것인지는 계획 단계에서 협업 부서들과 협의 된 상태여서 사양의 존재 자체가 협업 부서들 사이에 문제를 일으키지는 않습니다. 다만 기획서에 방금 설명한 충돌 회피 성향으로부터 비롯되었을 가능성이 있는 문구들이 들어가 있을 때 민감하게 반응하곤 합니다. 가령 ‘구체적인 수량은 아무개님과 협의 후 결정’ 이라든지 ‘이 기능은 필요할 경우에 추가’ 같은 말이 들어있거나 또 상황 별 플레이어 수를 표시한 문서에 '?'가 그려져 있다면 이 상황에 그냥 동의하고 진행시키면 안 된다고 생각합니다. 우리들은 그렇게 까지 충돌을 회피해 가며 일해야 하는 상황이 아니며 개인적으로 그런 업무 스타일은 우리가 더 나은 결과를 만드는데 방해가 된다고 생각하기 때문입니다.

먼저 아무개님과 협의해서 결정해야 하는 사안이 기획서에 남아 있다면 이 기획서는 아직 완성되지 않은 겁니다. 기획서를 완성하기 위해 브리핑 회의 전에 미리 아무개님과 이야기 해서 상황을 설명하고 의견을 들어 협의를 마친 결과가 기획서에 포함되어야 합니다. 그런데 이렇게 상황을 설명하고 의사결정을 요청하기 위해서는 이 기획서를 통해 달성해야 하는 목표를 문서를 작성한 스스로가 충분히 인식하고 설명할 수 있는 상태가 되어야만 합니다. 그렇지 않으면 다른 사람과 이야기를 시작한다 하더라도 정확히 무엇을 결정해야 하는지 설명할 수 없을 겁니다. 비약하면 아무개님과 협의해야 하는 사안이 기획서에 남아 있다면 어쩌면 이 문서를 작성하신 분은 목표를 정확하게 이해하지 못하고 있을 가능성이 있다고 추측해도 된다고 생각합니다.

또 기획자는 미래를 뻔뻔하게 찍을 수 있어야 합니다. 설사 찍은 결과가 틀렸다 할지라도 이를 겁내서는 안됩니다. 이 그림은 미래를 예상하려고 시도한 글 중 하나인 마스토돈 커뮤니티는 오래 못 갈 거라고 봐요에서 점쟁이도 아니면서 마치 점쟁이처럼 미래를 예측하려고 시도하는 자신의 행동을 영화 속 한 장면에 비유한 것입니다.

영화 미드웨이(2019)에서 레이튼은 진주만 공습을 예측하지 못했지만 경질되지 않고 니미츠 제독과 함께 일하게 되는데 영화 속에서 제독은 레이튼의 입장을 이해하지만 어느 순간 휘하의 고위 장교들이 가능성에 기반해 군대를 움직일 수 없는 상황 역시 이해했기 때문에 레이튼에게 ‘불가능한 요구라는 점을 알지만’으로 시작하는 미래를 정확히 예측하는 발언을 할 것을 요구합니다. 영화 속에서 레이튼은 일본군이 나타날 위치, 시각, 방향을 정확하게 말하는데 사실 이는 엄청난 모험입니다. 미래는 가능성으로밖에 표현할 수 없음을 알고 있으면서도 그런 식으로 표현하기 위해서는 준비와 생각과 또 용기가 필요했을 겁니다.

기획자도 마찬가지라고 생각합니다. 아직 개발되지 않았으며 개발 가능할 지 스스로 판단할 수 없는 요구사항을 문서로 만들어 협업 부서들과 함께 일해 결과를 만들어 내야 합니다. 그런데 그런 요구사항을 나열한 문서에 기획자가 지금 정확히 예측하기에는 나중에 변할 가능성이 높고 또 지금까지 들은 정보만으로는 판단 자체가 어려운 항목이 있을 수 있습니다. 그렇다고 그런 결정들을 미룬 채 문서를 비워 두면 개발 비용이 증가하고 협업 부서들에게 이 요구사항의 완성된 모습을 상상하기 어렵게 만들기도 합니다. 어떤 전투 모드를 플레이 할 인원을 아무 것도 없는 상태에서 정확히 적어 넣기는 부담스러울 수 있습니다. 하지만 이런 상황을 위해 기획자에게 다양한 게임 플레이 경험을 종종 요구하는 것이기도 합니다. 우리들은 아예 없던 것을 만들고 있지 않기 때문에 이전 까지 경험에 기반해 말이 되는 숫자를 써 낼 수 있습니다.

그래서 기획팀 밖으로 나가기 전에 문서를 검토할 때 이 두 가지에 특히 민감하게 반응합니다. 우선 협업 부서와 협의가 필요하기 때문에 아직 결정하지 않은 항목입니다. 협의가 필요하다면 기획서 완성 전에 협의해야 합니다. 협의를 위해서는 요구사항의 목적과 형태를 설명할 수 있는 상태여야 할 겁니다. 또 미래에 요구사항이 바뀔 수 있더라도 지금까지 얻은 정보에 기반해 지금 시점에는 정확한 요구사항을 제공해야 합니다. 미래에 바뀔 것 같다면 지금 정확한 요구사항과 함께 미래에 바뀔 지도 모른다고 생각하는 이유와 범위를 함께 언급하면 됩니다. 여기서 가장 중요한 점은 현 시점 기준으로는 정확한 요구사항을 제공하는 겁니다.

사실 여전히 다른 분이 작성한 문서를 검토하는 일은 불편하게 느껴집니다. 내가 뭐라고 문서를 검토하고 피드백을 내고 수정 요구를 하나 싶기도 하고요. 다른 한 편으로는 개인적으로 옳다고 생각하는 점을 요구해 적어도 그 안에서는 부끄럽지 않은 문서를 내보내고 협업 중에 일어나는 문제 해결에 적극적으로 나서 결국 목적을 달성하고 팀을 보호하는 것이 제 입장에서 해야 하는 일이 아닌가 싶기도 합니다.

오늘은 소위 기획서 컨펌을 할 때 어떤 점에 특히 중점을 두고, 또 조심하고 있는지 정리해 봤습니다. 이 주제는 긴 시간을 두고 다른 글을 통해 시각의 변화를 추적해 보는 재미가 있지 않을까 하고 기대 중입니다.