메인 퀘스트: 기본기 '관리'를 획득하자
사업 PM의 관리 업무 #1
게임을 만들고 운영하는 길은 생각보다 복잡하다. 기획자, 개발자, 아티스트는 물론 투자자와 외부 파트너까지 수많은 사람들이 각자의 목표를 안고 얽혀든다. 누군가는 창작의 순수함을, 또 누군가는 시장의 수익성을 좇는다. 서로 다른 리듬이 충돌하는 순간 게임은 크게 흔들리고 만다. 일정은 늦어지고 예산은 불어나며 힘겹게 빚어낸 결과물은 시장의 기대와 엇갈릴 수 있다.
이 혼란스러운 흐름 속에서 중심을 잡는 사람이 있다. 프로젝트 매니저 즉 PM이다. 탁월한 PM은 일정 관리 그 이상의 역할을 해낸다. 게임의 방향을 제시하고 서로 다른 언어를 쓰는 팀들 사이를 이어주며 때로는 눈에 보이지 않는 리스크를 먼저 감지해 완주를 가능케 하는 사람. 복잡한 항로 위에서 팀이 좌초하지 않도록 돕는 항해사 같은 존재다.
게임 서비스를 하나의 게임이라고 생각해 보자. 우리 앞에는 출시, 운영, 종료라는 이름의 퀘스트가 놓여 있고 이 퀘스트를 성공적으로 클리어하기 위해선 다채로운 능력을 키워야 한다. 물론 처음엔 아무것도 가진 게 없다. 장비도 기술도 경험도. PM이라면 세부 직군에 상관없이 반드시 익혀야 할 기본 공격 기술 '관리'부터 차근차근 살펴보자.
PM의 역할
PM은 게임이 무사히 빛을 보도록 전체적인 여정을 기획하고 조정하는 사람이다. 일정과 자원을 관리하는 것은 물론 팀이 올바른 방향으로 나아가고 있는지 끊임없이 점검하며 위험을 막아낸다.
아울러 사업 PM은 게임이 출시에 그치지 않고 오랜 시간 살아남아 널리 회자될 수 있도록 돕기도 한다. 이를 위해 매출과 유저 지표를 분석하고 수익 모델을 기획하며 다듬는 작업을 함께 수행한다.
ℹ️ 왜 사업 '프로젝트' 매니저라는 표현을 사용할까?
게임 업계에서는 게임, 타이틀, 프로젝트가 서로 같은 단어처럼 쓰이곤 한다.
프로젝트 관리 지식 체계(Project Management Body of Knowledge, PMBOK)에 따르면 프로젝트는 고유한 제품 또는 서비스를 창출하기 위해 수행되는 유한한 활동이다. 다시 말해 프로젝트에는 명확한 시작과 끝이 존재한다.
이에 비해 특히 온라인, 모바일 게임은 출시 이후에도 끊임없이 업데이트되고 운영되는 라이브 서비스의 성격을 지닌다. 따라서 엄밀히 말해 게임 전체를 하나의 프로젝트로 보긴 어려우며 새로운 캐릭터, 콘텐츠, 시스템 같은 개별 기능을 프로젝트로 보는 것이 합당하다.
그럼에도 이 시리즈에서는 설명상의 편의를 위해 하나의 게임을 하나의 프로젝트라고 간주하겠다.
프로젝트 관리의 다섯 가지 단계
게임을 처음부터 끝까지 성공적으로 이끌기 위해서는 단계별 전략이 필요하다. PMBOK는 프로젝트 수행 과정을 착수, 계획, 실행, 감시 및 통제, 종료의 다섯 단계로 구분하며 각 단계는 유기적으로 연결되어 있다. PM이라면 이 흐름을 반드시 이해하고 있어야 한다.
착수 단계에서는 프로젝트의 공식적인 시작을 선언한다.
프로젝트 헌장을 작성하여 프로젝트의 목적과 목표, 예산, 일정 개요를 정리하고 경영진의 승인을 받아 프로젝트를 정식으로 출범시킨다. 이 과정에서 이해관계자 분석을 통해 프로젝트에 영향을 미치는 주요 인물을 식별하고 이들의 요구사항과 기대를 반영한 커뮤니케이션 전략을 수립한다. 핵심 리스크를 조기에 파악하고 문서화하는 것도 중요하다.
프로젝트가 정식으로 시작되면 다음은 계획 단계다.
계획 단계에서는 프로젝트의 목표를 달성하기 위한 구체적인 실행 전략을 수립한다. 먼저 프로젝트 목표와 산출물을 명확히 정의하고 작업분할구조(Work Breakdown Structure, WBS)를 만들어 세부 작업을 구체화한다. 이후 보다 구체적인 일정, 예산을 계획을 수립하며 주요 위험 요소에 대한 대응 전략도 마련한다.
ℹ️ 작업분할구조(Work Breakdown Structure, WBS)
작업분할구조란 프로젝트를 완성하기 위해 해야 하는 모든 작업을 세세하게 쪼개 계층적으로 정리해 놓은 것을 가리킨다. 예를 들어 게임을 만든다고 하면 아래와 같이 큰 작업을 작은 작업으로 나누어 구조화한다.
1. 게임 개발
1.1. 기획
1.1.1. 세계관 설정
1.1.2. 시스템 기획
1.1.3. 콘텐츠 기획
1.2. 아트
1.2.1. 캐릭터 디자인
1.2.2. 배경 디자인
1.3. 개발
1.3.1. 서버 구축
1.3.2. 클라이언트 개발
작업분할구조를 만드는 이유는 프로젝트에 어떤 작업이 필요한지 한눈에 파악할 수 있기 때문이다. 또 작업별 일정, 담당자를 확인하여 프로젝트를 보다 체계적으로 관리하는 데에도 유용하다.
한 마디로 프로젝트를 '보이는 상태'로 만들어주는 지도와 같다고 할 수 있다.
실행 단계에서는 게임이 윤곽을 드러내기 시작한다.
이 단계에서는 우선 기획자, 아티스트, 개발자 등 프로젝트 수행에 필요한 인력을 적절한 팀에 배치하고 각 팀의 역할과 책임을 설정해야 한다. 이후 기획, 개발, 테스트 등의 순서로 프로젝트가 진행되며 게임은 프로토타입 제작, 알파 빌드, 베타 빌드 등의 과정을 거친다.
프로젝트가 진행되는 동안에는 끊임없는 점검과 관리가 요구된다. 이것이 바로 감시 및 통제 단계다.
이 단계에서는 프로젝트가 계획대로 진행되고 있는지 확인하며 일정 지연, 예산 초과, 인력 부족 같은 문제가 발생하면 즉시 해결 방안을 모색한다. 예를 들어 오픈 베타 테스트 결과 유저의 반응이 기대에 미치지 않을 경우 유저 지표 분석이나 심층 인터뷰 등을 통해 불만족 요인을 파악하여 개선하는 식이다. 또 프로젝트의 성과를 핵심성과지표로 측정하고 요구사항 변경이 있을 경우 공식 절차에 따라 검토 및 승인한다.
마지막으로 프로젝트를 잘 매듭짓는 것이 종료 단계다.
여기에서는 최종적으로 만들어진 게임이 요구사항을 충족하는지 검토하고 이해관계자의 승인을 받아 개발을 공식적으로 마무리한다. 덧붙여 지금까지의 과정을 되돌아보며 얻은 교훈을 문서화하거나 출시 이후 운영 계획에 걸맞은 구조로 팀을 개편하기도 한다.
프로젝트 관리의 열 가지 지식
PMBOK는 프로젝트 매니저라면 아래 열 가지 지식을 반드시 지니고 있어야 한다고 주장한다. 이 지식들은 게임을 관리하는 데에도 꽤나 강력한 무기가 되어준다.
먼저 통합 관리는 전반적인 조율을 가리킨다. 다시 말해 프로젝트 착수 단계부터 종료 단계까지를 하나의 흐름으로 엮어내는 것으로써 프로젝트 헌장 작성, 관리 계획 수립, 요구조건 변경 관리, 최종 성과 보고 등을 포함한다.
범위 관리는 프로젝트가 어디까지 해야 하고 어디까지 하지 말아야 하는지를 정의하는 작업으로 불필요한 업무 확장이 발생하지 않게끔 방지하는 것이 핵심이다. 범위 관리에서는 이해관계자들의 요구사항을 수집하고 목표와 산출물을 구체화하며 작업 분할 구조를 작성해 업무를 세분화한다.
일정 관리는 프로젝트가 기한 내에 완수되도록 계획하고 조정하는 일이다. 주요 작업과 순서를 정하고 의존관계를 분석해 일정을 짜는 것이 중요하다. 간트 차트나 칸반 보드 같은 도구를 활용해 전체 흐름을 시각화하거나, 일정상 변동 사항이 발생하면 빠르게 인지 및 전파 역할도 일정 관리에 해당한다.
간트 차트는 프로젝트가 진행되는 동안 관련 일정, 작업을 타임라인 형태로 표시하기 위해 사용하는 가로 막대 차트다. ⓒ Asana
칸반 보드는 보드에 점착 메모지를 붙여 할 일을 표시하는 것처럼 작업의 종류, 우선순위, 진행 상태를 시각화하는 도구다. ⓒ Asana비용 관리는 예산을 초과하지 않도록 프로젝트 비용을 계획하고 통제하는 과정이다. 비용을 산정하고 예산을 짜는 것뿐 아니라, 진행 상황에 따라 지속적으로 비용을 추적하고 조정해야 한다. 계획만 세우고 방치하면 예산은 순식간에 무너진다.
품질 관리는 산출물이 정해진 품질 기준을 만족하는지를 점검하는 것이다. 초기 품질 기준을 세우고 개발 도중 품질 보증 활동을 통해 문제를 사전에 발견하며 최종 품질 통제를 통해 완성도를 끌어올린다.
자원 관리는 프로젝트에 필요한 인력과 물적 자원을 적절히 확보하고 배치하는 일이다. 각 팀원의 역할과 책임을 명확히 하고 자원이 부족하거나 과다하게 몰리지 않도록 균형을 잡는 것이 핵심이다.
커뮤니케이션 관리는 이해관계자 사이의 소통을 매끄럽게 이어주는 과정이다. 커뮤니케이션 계획을 세워 정보를 주고받는 경로와 빈도를 정하고 진행 상황을 정기적으로 공유하며 회의록, 보고서 같은 문서로 흔적을 남긴다.
리스크 관리는 프로젝트 진행 중 생길 수 있는 문제를 미리 파악하고 대비책을 마련하는 작업이다. 발생 가능성과 영향을 평가해 우선순위를 매기고 예방과 대응 계획을 세운다. 리스크 관리는 '문제가 터진 뒤'가 아니라 '터지기 전에'가 핵심이다.
PM은 상황에 따라 딜러, 탱커, 서포터를 오가며 열 가지 지식을 상황에 맞게 꺼내 쓰는 올라운더가 되어야 한다.
도대체 소통이 뭐길래
커뮤니케이션 관리는 프로젝트의 성공을 좌우하는 핵심 요소지만, 한편으로는 가장 뜬구름 잡는 말처럼 느껴진다. "그냥 친절하게 대화하라는 건가……?" 싶기도 하다. 여기나 저기나 '소통'을 외치니 정작 그 의미를 종잡기 어려워질 수밖에.
프로젝트에는 여러 이해관계자가 존재하며 각자의 목표와 기대가 다르기 때문에 PM이 이들의 요구사항을 파악하고 효과적인 커뮤니케이션 전략을 수립해야 한다.
예를 들어 새로운 게임을 제작하는 프로젝트의 착수 단계에서 PM은 주요 이해관계자의 요구사항을 정리해야 한다. 통상적으로 경영진은 시장 성공과 매출 극대화, 기획자는 창의적인 게임 디자인, 개발자는 기술적 실현 가능성과 일정 준수를 최우선으로 생각한다. 아티스트는 시각적 완성도, 마케터는 유저 확보 전략, 운영팀은 안정성과 문제 대응 방안을 중요하게 여긴다. 이처럼 이해관계자들의 관심사가 제각각인 상태에서 요구사항을 명확히 정리하지 않으면 프로젝트가 진행될수록 충돌이 빈번하게 발생할 수밖에 없다.
그래서 PM은 이해관계자별로 다른 커뮤니케이션 방식을 설정해야 한다. 경영진에게는 정기 보고서를 통해 시장분석과 예상 매출을 전달해야 한다. 기획자, 개발자, 아티스트와는 정기 리뷰로 시각적인 방향성을 맞추고 일정 및 기술에 관한 논의를 진행할 수 있으며 정기 리뷰에서 도출한 내용은 마케팅팀이 차별화된 광고 소재를 탐색하는 데에 도움이 될 수 있다. 운영팀과는 유저 피드백과 예상되는 문제를 공유하는 체계를 마련하는 것이 좋다.
이처럼 이해관계자들의 목표와 니즈를 명확히 정리하여 이에 맞는 커뮤니케이션 전략을 세우면 불필요한 갈등을 줄이고 프로젝트를 순조롭게 이끌 수 있다. 반면 착수 단계에서 이 작업을 소홀히 하면 일정 차질, 우선순위 충돌, 심지어 프로젝트 방향성 붕괴까지 이어질 수 있다.
PM의 역할은 그저 정보를 전달하는 것이 아니라, 각 팀이 효과적으로 협업할 수 있도록 목표와 기대를 조율하는 데 있다. 이를 위해서는 이해관계자별 맞춤형 커뮤니케이션 전략이 필요하다.
PM인 내가 기획, 개발 등 다양한 분야를 조금씩이라도 배우려는 이유도 더 부드럽고 자연스러운 소통을 꿈꾸기 때문이다. 게임을 둘러싼 수많은 사람들이 무슨 일을 하고 어떤 언어와 도구로 세상을 바라보는지 이해하려 애쓰다 보면 언젠가 그들의 마음과 생각에 조금 더 가까워질 수 있을 거라고 믿는다.
혹시 이 글을 읽고 있는 당신이 새로운 것을 배우는 일, 서로 다른 사람들과 함께 숨을 고르고 걸음을 맞추는 일을 좋아하는 게이머라면 PM이라는 모험을 한 번쯤 생각해 보는 것도 의미 있을 것이다.
