게임 개발 PM은 생각보다 설명하기 어려운 직무다.
어떤 회사에서는 일정 관리자를 의미하고, 어떤 회사에서는 프로젝트 전체의 흐름을 조율하는 사람을 의미한다. 또 어떤 조직에서는 개발팀과 기획팀 사이의 커뮤니케이션을 담당하기도 하고, 라이브 서비스 일정, QA, 빌드, 이슈 관리까지 폭넓게 맡기도 한다.
그래서 “게임 개발 PM은 무슨 일을 하나요?”라는 질문에 하나의 정답으로 답하기는 어렵다.
다만 여러 조직에서 게임 기획자이자 개발 PM 업무를 수행하면서 느낀 것은 있다.
게임 개발 PM은 단순히 일정을 관리하는 사람이 아니다. 팀이 같은 방향을 보고 움직일 수 있도록 정보를 정리하고, 문제를 발견하고, 의사결정이 필요한 지점을 드러내며, 프로젝트가 앞으로 나아가도록 돕는 사람에 가깝다.
이번 글에서는 내가 실무에서 느낀 게임 개발 PM의 역할과, 기획자 출신 개발 PM으로서 강점을 발휘할 수 있었던 부분, 그리고 개발 PM을 지망하는 사람들에게 전하고 싶은 이야기를 정리해보려고 한다.
게임 개발 PM은 일정 관리만 하는 사람이 아니다
PM이라고 하면 가장 먼저 떠오르는 이미지는 보통 일정 관리다.
언제까지 기획서를 작성해야 하는지, 개발은 언제 시작되는지, QA는 언제 들어가는지, 빌드는 언제 나오고, 언제 전달해야 하는지 관리하는 역할이다. 물론 일정 관리는 PM의 중요한 업무다.
하지만 게임 개발 현장에서 PM의 역할을 일정 관리로만 이해하면 많은 부분을 놓치게 된다.
게임 개발 일정은 단순히 달력에 날짜를 적는다고 지켜지는 것이 아니다. 기획, 개발, 아트, QA, 운영 등 여러 파트의 작업이 서로 맞물려 돌아갈 때 비로소 의미가 있다.
예를 들어 하나의 콘텐츠를 개발한다고 해도 기획자는 콘텐츠 구조와 규칙을 정리해야 하고, 개발자는 기능을 구현해야 하며, 아트팀은 필요한 리소스를 제작해야 한다. QA는 정상 동작과 예외 상황을 확인하고, 운영팀은 업데이트 공지나 유저 커뮤니케이션을 준비해야 할 수도 있다.
이 모든 일은 따로 진행되는 것처럼 보이지만 실제로는 서로 강하게 연결되어 있다.
- 기획서가 늦어지면 개발 착수가 늦어진다.
- 개발 중 기획이 변경되면 일정과 리소스가 다시 흔들릴 수 있다.
- QA에서 구조적인 문제가 발견되면 출시 일정에 영향을 줄 수 있다.
- 의사결정이 늦어지면 팀 전체가 애매한 상태로 대기하게 된다.
이때 PM은 단순히 “언제까지 해주세요”라고 말하는 사람이 아니다.
PM은 현재 프로젝트가 어떤 상태인지 파악하고, 막히는 지점이 어디인지 확인하고, 누가 어떤 결정을 해야 하는지 드러내는 역할을 한다. 각 파트가 같은 정보를 기준으로 움직이게 만드는 것도 중요한 일이다. 특히 실제 업무에서는 정말 다양한 변수가 발생하기 때문에 시시각각 빠른 판단이 필요하다.
다시 말해 PM은 일정을 관리하는 사람이기도 하지만, 더 정확히는 프로젝트의 흐름을 관리하는 사람이라고 생각한다.
조직마다 PM에게 요구하는 역할은 다르다
게임 개발 PM이라는 직무가 어려운 이유 중 하나는 회사마다 요구하는 역할이 매우 다르다는 점이다.
어떤 회사에서는 PM이 일정 관리와 회의 운영에 집중한다. 어떤 회사에서는 개발 조직의 업무 배분과 우선순위 정리를 맡는다. 어떤 회사에서는 기획 PM처럼 콘텐츠 방향성이나 개발 스펙 조율에 깊게 관여한다.
라이브 조직에서는 업데이트 일정, 이벤트, QA, 핫픽스, 공지 일정까지 함께 관리하기도 한다. 스타트업이나 작은 조직에서는 PM이 사실상 기획, 운영, QA, 일정 관리, 외부 커뮤니케이션을 모두 겸하는 경우도 있다.
그래서 개발 PM을 준비하는 사람이라면 먼저 이 점을 이해해야 한다.
PM이라는 직무명만 보고 업무 범위를 단정하면 안 된다.
같은 PM이라도 조직의 규모, 개발 단계, 게임 장르, 회사 문화, 리더십 구조에 따라 실제 업무는 크게 달라진다.
- 신규 개발 프로젝트의 PM과 라이브 서비스 PM은 다르다.
- 대형 조직의 PM과 소규모 조직의 PM도 다르다.
- 일정 관리 중심의 PM과 기능 조율까지 맡는 PM도 다르다.
이런 점에서 PM은 직무 정의가 명확한 듯하면서도, 실제로는 조직의 문제와 필요에 따라 계속 달라지는 역할이라고 생각한다.
좋은 PM이 되기 위해서는 “PM은 이런 일을 한다”는 고정된 목록을 외우는 것보다, 이 조직에서 지금 프로젝트가 앞으로 나아가기 위해 무엇이 필요한가를 읽는 능력이 더 중요하다.
기획자 출신 PM으로서 강점을 발휘할 수 있었던 부분
나는 원래 기획 업무를 수행하면서 개발자와 직접 소통하고, 내 업무 일정도 직접 관리해온 경험이 있었다.
이전에는 항상 PM이 없는 조직에서 일했기 때문에, 기획자라고 해서 기획서만 작성하고 끝나는 환경은 아니었다. 내가 맡은 기능이나 콘텐츠가 실제로 개발되고, 테스트되고, 반영되기까지의 과정을 계속 따라가야 했다.
기획서를 작성한 뒤 개발자에게 전달하고, 구현 중 발생하는 질문에 답하고, 일정이 늦어질 것 같으면 우선순위를 조정했다. QA에서 이슈가 나오면 다시 스펙을 확인하고, 필요하면 기획을 수정하기도 했다.
그런 경험은 개발 PM 역할을 수행할 때 큰 도움이 되었다.
기획의 의도를 이해할 수 있다
기획자 출신 PM은 단순히 문서에 적힌 기능 목록만 보는 것이 아니라, 이 기능이 왜 필요한지, 어떤 유저 경험을 만들기 위한 것인지, 어떤 부분이 핵심이고 어떤 부분은 조정 가능한지 비교적 빠르게 파악할 수 있다.
개발 중에는 항상 선택의 순간이 생긴다.
- 시간 안에 모든 것을 완성하기 어렵다면 무엇을 먼저 구현해야 하는가?
- 어떤 스펙은 유지해야 하고, 어떤 스펙은 줄여도 되는가?
- 현재 이슈가 게임의 핵심 재미에 영향을 주는가, 아니면 후순위로 미룰 수 있는가?
이런 판단을 할 때 기획적 이해는 큰 도움이 된다.
개발자와의 커뮤니케이션에서 맥락을 이해하기 쉽다
기획자 출신이라고 해서 개발을 모두 이해하는 것은 아니다. 하지만 기능이 실제로 구현되는 과정에서 어떤 질문이 나올 수 있는지, 기획서의 어떤 부분이 모호하게 받아들여질 수 있는지는 어느 정도 예측할 수 있다.
예를 들어 기획서에는 “보상을 지급한다”고 적혀 있어도, 개발 입장에서는 여러 질문이 생길 수 있다.
- 보상은 언제 지급되는가?
- 중복 수령은 어떻게 막는가?
- 인벤토리가 가득 찼을 때는 어떻게 되는가?
- 오류가 발생하면 어떻게 처리하는가?
기획자는 의도 중심으로 생각하기 쉽고, 개발자는 구현과 예외 상황 중심으로 생각한다. PM은 이 둘 사이에서 질문이 누락되지 않도록 도와야 한다.
기획자 출신 PM은 이런 간극을 비교적 잘 감지할 수 있다.
일정과 스펙의 관계를 이해하기 쉽다
기획 변경은 단순히 문서 몇 줄을 고치는 일이 아니다. 그 변경이 개발 일정, 아트 리소스, QA 범위, 밸런스 검증, 운영 공지까지 영향을 줄 수 있다. 퍼블리셔가 있다면 변경된 기획서 공유도 빠질 수 없다.
기획 업무를 직접 해본 사람은 스펙 변경이 얼마나 자연스럽게 발생하는지도 알고, 동시에 그 변경이 얼마나 큰 파급을 만들 수 있는지도 체감한다.
그래서 PM 역할을 할 때 “이건 작은 변경 아닌가요?”라고 쉽게 말하기보다, 변경의 영향 범위를 먼저 확인하려고 하게 된다.
이것은 기획자 출신 PM이 가질 수 있는 중요한 강점이라고 생각한다.
PM이 없던 조직에서 배운 것
PM이 명확하게 존재하지 않는 조직에서는 기획자나 파트 리더가 사실상 PM 역할의 일부를 수행하게 되는 경우가 많다.
나 역시 그런 환경에서 일하면서 자연스럽게 일정 관리, 업무 조율, 개발자와의 소통, 이슈 정리의 필요성을 느꼈다.
처음에는 그것이 별도의 PM 업무라고 생각하지 못했다. 그냥 내가 맡은 기능을 끝까지 책임지려면 당연히 해야 하는 일이라고 생각했다.
하지만 시간이 지나면서 알게 된 것이 있다.
게임 개발에서 좋은 아이디어나 좋은 기획서만으로는 결과물이 나오지 않는다. 결국 결과물을 만들기 위해서는 누군가가 계속해서 흐름을 봐야 한다.
지금 무엇이 결정되었는지, 무엇이 아직 애매한지, 어떤 이슈가 막고 있는지, 다음 단계로 넘어가기 위해 누가 무엇을 해야 하는지 정리해야 한다.
PM이 없는 조직에서는 이런 일이 명확한 담당자 없이 흩어지기 쉽다. 그러면 같은 이야기를 여러 번 반복하게 되고, 결정된 줄 알았던 내용이 다시 논의되고, 누군가는 알고 있지만 다른 누군가는 모르는 정보가 생긴다.
프로젝트는 꼭 큰 문제만으로 늦어지는 것이 아니다. 정보 누락, 애매한 책임 범위, 늦어지는 의사결정, 정리되지 않은 회의 내용 같은 것들이 쌓이면서 늦어진다.
PM 역할의 중요성은 바로 이런 지점에서 드러난다.
PM은 모든 문제를 직접 해결하는 사람이 아니다. 하지만 문제가 보이지 않는 상태로 방치되지 않게 만드는 사람이다.
PM은 팀을 통제하는 사람이 아니다
PM이라는 역할을 이야기할 때 가끔 통제나 관리의 이미지가 강하게 붙는다.
일정을 체크하고, 업무를 배정하고, 진행 상황을 확인하고, 지연을 압박하는 사람처럼 보일 때도 있다. (실제로 개발자들은 PM이 나타나면 스트레스를 받거나 주니어분들은 벌벌 떠는 것도 봐왔다)
하지만 내가 생각하는 좋은 PM은 팀을 통제하는 사람이 아니다.
오히려 팀이 더 잘 일할 수 있도록 복잡한 정보를 정리하고, 막힌 부분을 드러내고, 불필요한 혼란을 줄이는 사람에 가깝다.
좋은 PM이 있는 팀은 모든 문제가 사라지는 팀이 아니다. 문제가 더 빨리 보이고, 더 명확하게 공유되고, 더 빠르게 결정되는 팀이다.
PM은 프로젝트의 모든 답을 가지고 있는 사람이 아니다. 하지만 프로젝트가 어디에서 막히고 있는지, 무엇을 결정해야 하는지, 어떤 리스크를 먼저 봐야 하는지 계속 질문하는 사람이다.
그 질문이 팀을 앞으로 움직이게 만든다.
개발 PM을 지망하는 사람들에게
개발 PM을 지망하는 사람들에게 가장 먼저 말하고 싶은 것은, PM이라는 직무를 너무 좁게 보지 않았으면 한다는 점이다.
PM은 일정표를 예쁘게 정리하는 사람이 아니다. 회의를 많이 여는 사람도 아니다. 모든 사람에게 일을 시키는 사람도 아니다.
개발 PM은 프로젝트가 실제 결과물로 이어지는 과정을 돕는 사람이다.
그러기 위해서는 기획도 알아야 하고, 개발 프로세스도 이해해야 하며, QA와 빌드, 라이브 운영의 흐름도 알아야 한다. 처음부터 모든 것을 잘 알 수는 없지만, 최소한 각 파트가 어떤 고민을 하고 어떤 기준으로 일하는지 이해하려는 태도가 필요하다.
특히 게임 개발 PM을 목표로 한다면, 작은 기능이라도 처음부터 끝까지 따라가보는 경험을 해보면 좋다. 아이디어가 기획서가 되고, 기획서가 개발되고, QA를 거쳐 실제 유저에게 전달되는 과정을 경험해보면 PM 업무의 본질을 이해하기 쉬워진다.
또 회의록이나 업무 정리를 단순 기록이 아니라 의사결정 도구로 만들어보는 연습도 중요하다. 회의에서 누가 무슨 말을 했는지보다 중요한 것은 무엇이 결정되었고, 무엇이 미정이며, 다음 액션이 무엇인지다.
개발자와 대화할 때도 “가능한가요?”에서 멈추지 않고, “어떤 부분이 어렵나요?”, “어떤 선택지가 있나요?”, “일정에 어떤 영향이 있나요?”까지 질문해보는 습관이 필요하다.
PM은 처음부터 완성된 전문가로 시작하기 어려운 직무다. 오히려 여러 경험이 쌓이면서 점점 더 넓은 시야를 갖게 되는 직무에 가깝다.
기획 경험, QA 경험, 운영 경험, 개발 협업 경험, 라이브 서비스 경험은 모두 PM 역량으로 연결될 수 있다.
중요한 것은 내가 직접 만든 산출물만 보는 것이 아니라, 그 산출물이 팀 안에서 어떻게 만들어지고, 어떤 과정을 거쳐 유저에게 전달되는지를 보는 시야다.
앞으로 Blue Play Lab에서 다뤄보고 싶은 이야기
이번 글은 게임 개발 PM이라는 역할에 대한 첫 번째 정리다.
앞으로는 이 주제를 조금 더 구체적으로 나눠서 다뤄보고 싶다.
- 게임 개발 일정은 왜 자주 밀릴까?
- 좋은 게임 기획서는 무엇이 다를까?
- 개발자가 이해하기 쉬운 기획서는 어떻게 작성할까?
- PM은 회의록을 어떻게 정리해야 할까?
- 라이브 서비스에서 PM은 어떤 역할을 할까?
- AI 자동화는 게임 개발 PM 업무를 어떻게 도와줄 수 있을까?
게임 개발 PM은 정답이 정해진 직무라기보다, 조직과 프로젝트의 상황에 따라 계속 달라지는 역할이다.
그래서 더 어렵고, 동시에 더 흥미로운 직무라고 생각한다.
내가 경험한 것들이 모든 회사와 모든 프로젝트에 그대로 적용되지는 않을 것이다. 하지만 실제 게임 개발 현장에서 기획자이자 PM 역할을 수행하며 느낀 점들이, 게임 개발 PM을 준비하는 사람이나 게임 개발 협업 구조를 이해하고 싶은 사람에게 작은 참고가 되었으면 한다.
결국 좋은 PM은 프로젝트 위에 서 있는 사람이 아니라, 프로젝트 안에서 팀이 앞으로 나아가도록 돕는 사람이라고 생각한다.
Blue Play Lab에서는 앞으로 게임 기획, 개발 PM, 라이브 서비스, 그리고 AI 자동화를 활용한 업무 개선에 대해 계속 기록해보려 한다.
게임을 만드는 사람들의 실무와 고민, 그리고 더 나은 개발 방식을 함께 탐구하는 공간으로 만들어가고 싶다.
비슷한 고민을 하고 있는 기획자나 PM이라면 댓글로 의견을 남겨주세요. 앞으로 이 주제에 대해 더 구체적인 실무 글을 이어가보겠습니다.