프로젝트 관리 솔루션을 찾기 전에…

성공적인 프로젝트 관리를 위해 뛰어난 프로젝트 매니저를 채용하고, 비싼 데브 옵스 솔루션을 들여오고, 데이터를 바탕으로 한 통계 분석을 실시하고, 애자일과 스크럼, 칸반을 도입하기 전에 우선적으로 해야 할 일이 있습니다. 뭐냐고요? 일하는 업무 프로세스를 체계화하고 그 체계를 전체 프로젝트 구성원에게 도입하는 일이지요.

프로젝트 매니저에게 업무 프로세스를 적절하게 관리할 권한이 없다면, 그리고 해당 프로젝트의 프로세스가 업무 진행 순서. 라고 부르기도 민망한 수준의 상황이라면 그 프로젝트는 절대로 관리가 되지 않습니다. 이건 다들 당연히 알고 있을테고.

갑작스럽게 조직이 급격하게 성장하면서 체계화 된 업무 프로세스의 도입을 생각하는 기업이나 조직이 이를 성공시키지 못하는 큰 이유 중 하나는 최고 경영자를 포함한 중간 관리자 급에서 변화된 업무 프로세스를 스스로 체득화 하지 못/안하는 경우가 의외로 많다는 점 입니다. 때문에 프로세스를 안착시키려는 조직에서는 프로젝트 매니저의 권한 배분이 매우 중요합니다. 필요하다면 CEO라도 PM의 잔소리는 들어야 마땅합니다.

대규모 인원이라면 관리는 필연적이고 이런 관리 체계를 흔드는 일은 하지 말아야 합니다. 조직간 커뮤니케이션이 안되고 정보 공유가 산발적이며, 한 가지 사안에 대해 서로 다른 이야기를 하고 있다면 우선 프로젝트에 대한 최고 책임자의 의사 결정 과정과 결정된 의사가 전파되는 과정을 지켜보기 바랍니다. 모든 문제는 거기서 부터 시작합니다.

아이들을 위한 게임 디자인 워크샵

현업 게임 개발자들을 위한 기술 교육 프로그램인 게임 디자인 워크샵 프로그램(홈페이지 링크)을 바탕으로 초등학생 고학년 ~ 중학교 학생들을 위한 게임 디자인 워크샵 프로그램을 디자인 하고, 미래기술 혁신 포럼 2019 에서 수업을 진행하였습니다.

게임 디자인 워크샵은 다양한 사례들을 직접 테스트하고 결과를 공유하는 형태의 과정으로, 이 중 게임 프로토타이핑 및 개선 과정을 경험 할 수 있는 Sissy Fighting 3000 을 바탕으로 수업을 설계하였습니다. 이와 관련한 경험담을 보고 싶으시다면 2009년도에 제가 작성한 글을 참조해 주세요.

원작에서의 변경 사항은 다음과 같습니다.

  • 실습용 게임을 새로 디자인하였습니다. 참여 연령대(초등학생 고학년 ~ 중학생)에 맞춰 아이들이 가장 많이 접해봤을 만한 주사위를 사용하는 보드 게임(ex. 부루마블, 모노폴리, 뱀주사위 놀이, 윷놀이)을 기반으로 합니다.
  • 중간 학생들에게 제시되는 퍼블리셔로 부터의 과제를 새로 작성하였습니다.
  • 수업 진행 시 게임 디자인 이론에 대한 내용은 최소한도로 줄이고, 아이들 간의 협업, 의사 소통, 자기 의견을 상대에게 설득 시키는 과정 등 프로젝트 진행에 필요한 기본 소양에 좀 더 무게 중심을 맞췄습니다.

수업은 최소 3인 ~ 최대 25인 기준으로 3시간을 기준으로 기획 되었습니다(변형하기에 따라서 집에서 가족 단위의 진행도 가능하다고 생각합니다).

여기 수업 계획서 및 필요한 관련 자료를 공개합니다.

크리에이티브 커먼즈 라이선스
이하의 저작물(수업 계획서 및 준비물 인쇄 자료)은 크리에이티브 커먼즈 저작자표시-비영리-동일조건변경허락 4.0 국제 라이선스에 따라 이용할 수 있습니다.

쓸모있는 기획서 작성하기

먼저 쓸데없는 양심선언을 하자면 나는 기획서를 대단히 장황하게 써서 프로젝트에 참여하고 있는 사람들이 그 기획서를 꼼꼼하게 읽지 않으면 패닉상태에 빠지도록 만드는데 특이한 재주가 있다. 한마디로 한더미의 문서 쓰레기를 만드는데 아주 익숙하다는 이야기인데, 현재로써는 그러한 재주아닌 재주를 버리고 싶은 생각도 아직은 별로 없다. 왜냐고 하면(아주 짧은 경험에 근거한 판단이지만) 거의 대부분의 기획자들이 그러한 문서를 양산해 내는데 선수인지라, 프로그램 팀이든 그래픽 팀이든 그런 유형의 알아보기도 힘들고 개발에 별로 도움도 안 되는 기획서에 다들 익숙해져 있기 때문이다.

기획자가 작성하는 기획서란 문서는 기획자가 보더라도 그 의미를 파악하기 힘들 정도로 장황한 것이 일반적이다. 기획서가 지나치게 복잡해지는 이유는 사실 그리 대단한게 아니다. 기획자는 자신이 의도한 게임을 만들고 싶어서 문서에 이것 저것 서술해 놓기 시작한다. 넘치는 아이디어를 주체하지 못해서 아이디어만 간단하게 정리해도 벌써 십수 페이지 분량이 나와버린다. 뭐, 거기서 끝나면 좋겠지만, 어디 기획서란게 ‘이렇게 만들어 주세요’라고만 직직 갈겨 쓰면 그만인 것인가? 시스템의 구동 원리 따위를 장황하게 쓰면 기획서의 분량은 수십 페이지로 늘어난다. 자, 그럼 끝인가? 그렇다고 생각한 기획자가 각 팀(또는 부서)에 문서를 넘기기 시작하면 그 때 부터 사고가 발생한다. 프로그래머들은 기획서에 자신들이 알아야 할 로직이나 데이터 명세가 없다고 아우성이고, 그래픽 디자이너들은 구체적인 디자인 가이드나 스펙이 없다고 난리를 치기 시작한다. 그들의 요구를 반영하여 기획서에 모든 사항을 집어넣기 시작한다. 페이지는 벌써 세번째 자리를 근접하기 시작한다. 기하급수적으로 늘어난 문서의 양 때문에 가독성은 애초에 기대하기도 힘들다. 때문에 다른 팀원들은 자신이 요구하는 사항이 없다고 투덜거리기 시작하면, 기획자는 그들을 문서도 보지도 않고 만사 투덜거리기만 하는 ‘투덜이 스머프’정도로 여기기 시작한다.

능숙한 기획자(경험이 많고 게임 제작 전반에 걸쳐 제작 프로세스를 파악하고 있는 기획자)라면, 각 필요에 맞는 문서 양식 Template 을 만들어 문서를 쪼개놓기 시작 할 것이다. 사업 전략 부서나 마케팅 부서에 필요한 프로젝트 개요서라던가, 프로그래머에게 필요한 UML 구조도, 그래픽 팀에 필요한 컨셉 가이드 같은 문서들을 만들어 각각 뿌려놓는다. 하지만, 여기에도 문제가 전혀 없는 것은 아니다. 수정사항이 발생 할 때 마다 모든 문서들을 다시 갱신해야 하는데, 이것 저것 쪼개 놓은 문서들을 일일이 찾아가면서 수정하는 것도 사실 보통 고역이 아니다. 그래도 각 파트는 자신들이 필요한 부분만 떼어내어 찾아 볼 수 있기 때문에 쪼개진 문서를 좀 더 선호한다. 때문에 그 정도 수고는 차라리 감수하는 편이 낫다.

하지만 프로젝트는 진행되면서 점차 아메바 마냥 그 형태가 뒤죽박죽 계속 변동이 생기기 시작하면서, 기획자가 감당할 수 있는 문서의 양을 넘겨버리는 한계점이 오게 된다. 점차 갱신이 누락되는 문서가 생기고, 문서에 기반한 커뮤니케이션은 점차 무너지기 시작한다. 커뮤니케이션이 동기화가 점차 깨지기 시작하면서 서로간에 엉뚱한 결과물을 가지고 프로젝트는 점차 기괴한 형상으로 변해버린다. 무엇이 문제일까? 장황함을 없애기 위하여 여러 탬플릿을 이용하고, 가독성을 높이기 위해 문서를 쪼개어 관리하는 수고도 아끼지 않았건만, 결국 문서의 내용은 뒤쳐지기 시작하고, 팀원들은 전부 결과에 대한 동상이몽을 꾸게 되어버렸다.

혹자는 이러한 문제를 수시로 바뀌는 프로젝트에 있다고 생각한다. 이른바 ‘기획이 완벽하면 기획서가 바뀔 이유도 없고, 프로젝트에 변화가 생겨 프로젝트가 뒤죽박죽이 될 일도 없다(즉, 모든것은 기획자 탓이다)’라는 생각인데, 이는 크게 잘못된 생각인데, 그런 ‘전능’을 발휘 할 수 있는 기획자는 이 세상에 없다는 것과, 그런 능력을 가진 기획자라면 이 세상을 변화시킬 일을 기획하지 고작 게임 프로그램 따위나 만드는 것은 우주적인 낭비이기 때문이다. 보통은 기획자도 인간이고, 프로젝트는 많은 절충과 합의에 의해서 이루어지는 것을 생각한다면 그런 일은 일어날 수도 없고, 일어나서도 안된다(신과 함께 게임을 만들고 싶은가?).

사실 모든 문제의 원흉은 기획서를 바라보는 사람들의 근본적인 인식에 있다. ‘기획서’의 가장 큰 기능과 목적은 ‘커뮤니케이션’이다. 팀원간에 생각을 공유하고, 동일한 목표를 찾아냄으로써 그 목표를 향해 매진하게 만들기 위해서 서로간의 커뮤니케이션이 중요한 것은 사실이며, 기획서는 이러한 커뮤니케이션 활동에 커다란 도움을 준다. 하지만 커뮤니케이션에 많은 도움을 주는 기획서마저도 ‘문자’를 기반으로한 커뮤니케이션 행동이기 때문에 때에 따라서는 의미가 와전되거나, 곡해 될 수 밖에 없다. 애초에 완벽한 기획서가 존재 할 수 없는 가장 큰 이유이다. 그럼에도 불구하고 사람들은 ‘기획서’를 ‘완벽한 커뮤니케이션 수단’으로 생각하고 모든 커뮤니케이션을 기획서로 해결하려고 들기 때문에 사고가 발생하는 것이다.

나는 팀원들과 커뮤니케이션 하는데 있어서 지나치게 기획서에 의존하는 행태를 버려야 한다고 생각한다(기획서를 버리라는 의미는 아니다). 조금은 모자란 기획서를 쓰더라도, 팀원들과 한번 더 대화하고, 의견을 나눔으로 써 팀원들 간의 생각을 동기화 시키는 편이 아무도 읽지 않을 장황한 기획서를 쓰느라 에너지를 낭비하는 것에 비하면 훨씬 낫다. 커뮤니케이션을 위해 필요하다면 과감하게 기획서 뿐만이 아니라, 오디오 혹은 비디오등의 다양한 방법을 이용하는 것도 방법이다-걱정마시라, 테라 단위 용량의 하드디스크와 고화질의 동영상 촬영이 가능한 디카는 옛날에 비하면 무척이나 저렴해졌다. 팀원간의 커뮤니케이션을 개선하는 것에 좀 더 많은 신경을 써라. 그것이 쓸데없이 완벽한 기획서를 작성하는 것 보다 훨씬 더 쓸모있는 기획서 작성 방법이다.