게임아카데미게임·웹툰·AI 진로 상담
게임기획은 시스템, 레벨, 콘텐츠, 밸런스처럼 세부 직무가 나뉘어 있어 처음에는 어디로 가야 할지 헷갈립니다. 입문 단계에서 각 분야 문서를 한 번씩 써 보고…
사업 PM은 '이 게임이 어떻게 팔리고 오래 갈까'를 책임집니다
사업 PM은 출시 전에는 시장 조사와 사업성 검토, 출시 국가와 시점, 마케팅 방향을 정리합니다. 출시 뒤에는 매출과 유저 지표를 보고 이벤트, 업데이트 일정, 상품 구성을 개발팀과 협의합니다. 퍼블리싱 계약이 있는 프로젝트라면 외부 파트너와 소통하는 창구 역할도 맡습니다.
이 직무에서 자주 쓰는 말이 BM(수익 모델)과 지표입니다. BM은 게임이 돈을 버는 방식, 예를 들어 패키지 판매나 아이템 판매, 시즌 패스 같은 구조를 말합니다. 사업 PM은 유저가 얼마나 남아 있는지, 결제는 어떻게 일어나는지를 데이터로 확인하고 다음 행동을 제안합니다. 그래서 엑셀과 데이터 해석, 보고서 작성 능력이 기본기로 꼽힙니다.
개발 PM은 '이 게임이 제때 제대로 만들어질까'를 챙깁니다
개발 PM은 기획, 아트, 프로그래밍, QA 팀 사이에서 일정과 작업 순서를 조율합니다. 마일스톤(중간 목표 시점)을 세우고, 각 팀의 작업이 어디까지 왔는지 확인하며, 막힌 곳이 생기면 원인을 찾아 우선순위를 다시 정합니다. 회의록과 작업 관리 도구를 정리하는 일이 일상의 큰 부분을 차지합니다.
개발 PM에게 중요한 것은 개발 과정에 대한 이해입니다. 원화가 나와야 모델링이 시작되고, 모델링이 끝나야 애니메이션과 이펙트가 붙는 식의 의존 관계를 알아야 일정이 현실적으로 짜입니다. 직접 코드를 쓰거나 그림을 그리지는 않더라도, 각 직군이 어떤 말로 일을 설명하는지 알아듣는 능력이 필요합니다. 일정이 밀릴 때 누구 탓인지 따지기보다 범위를 줄일지, 사람을 옮길지, 시점을 미룰지 선택지를 만들어 의사 결정을 돕는 것이 개발 PM의 실력입니다.
다섯 가지 기준으로 나란히 놓아 보면
| 기준 | 사업 PM | 개발 PM |
|---|---|---|
| 바라보는 대상 | 시장, 유저, 매출, 파트너 | 개발팀, 일정, 작업 범위 |
| 핵심 산출물 | 사업 계획서, 지표 보고서, 운영 계획 | 개발 일정표, 마일스톤 보고, 이슈 관리 문서 |
| 필요한 역량 | 데이터 해석, 시장 감각, 협상력 | 개발 공정 이해, 조율력, 리스크 관리 |
| 자주 쓰는 도구 | 엑셀, 지표 대시보드, 발표 자료 | 작업 관리 도구, 문서 협업 도구 |
| 바쁜 시기 | 출시 직후, 대형 업데이트와 이벤트 기간 | 마일스톤 직전, 출시 전 빌드 마감 |
회사 규모에 따라 두 역할이 한 사람에게 합쳐지기도 합니다. 작은 개발사에서는 PM 한 명이 일정 관리와 출시 준비를 함께 맡는 일이 흔하고, 큰 회사일수록 역할이 잘게 나뉘는 경향이 있습니다. 채용 공고의 업무 내용을 꼭 읽어 보고 어느 쪽에 무게가 실려 있는지 확인해야 합니다.
하루 일과를 떠올려 보면 성향 차이가 보입니다
사업 PM의 아침은 보통 전날 지표 확인으로 시작합니다. 접속자 수와 매출이 평소와 다르면 원인을 찾아야 하고, 이벤트 효과가 기대에 못 미치면 다음 주 계획을 손봅니다. 오후에는 마케팅, 운영, 개발팀과 회의를 하며 다음 업데이트에 무엇을 넣을지 이야기합니다.
개발 PM의 하루는 각 팀의 진행 상황을 모으는 데서 시작하는 경우가 많습니다. 어제 끝나기로 한 작업이 끝났는지, 막힌 이슈는 없는지 확인하고, 필요하면 담당자들을 모아 짧게 해결 방법을 정합니다. 갑작스러운 기획 변경이 생기면 그 변경이 일정 전체에 어떤 파장을 주는지 계산해 보고하는 것도 개발 PM의 몫입니다.
정리하면 사업 PM은 결과 숫자에 반응하며 움직이고, 개발 PM은 과정의 병목을 풀며 움직입니다. 어떤 종류의 긴장감이 나에게 맞는지 상상해 보는 것도 좋은 판단 기준입니다.
포트폴리오에서 보여 줄 것도 달라집니다
사업 PM 지원자는 실제 출시된 게임 하나를 골라 지표와 운영을 분석한 문서가 효과적입니다. 이벤트가 왜 그 시점에 열렸는지, 상품 구성이 어떤 유저를 노렸는지 가설을 세우고, 내가 담당자라면 어떤 개선안을 낼지 정리하는 식입니다. 공개된 정보만으로 논리를 세우는 과정 자체가 평가 대상이 됩니다.
개발 PM 지원자는 팀 프로젝트를 관리한 기록이 강한 무기가 됩니다. 작업을 어떻게 나눴는지, 일정이 밀렸을 때 무엇을 빼고 무엇을 지켰는지, 그 결정이 결과에 어떤 영향을 줬는지를 문서로 보여 주면 됩니다. 일정표 한 장보다 문제가 생겼던 순간과 대응 과정이 더 많은 것을 말해 줍니다.
두 경우 모두 피해야 할 것은 막연한 소감 위주의 문서입니다. '소통을 잘했다', '유저를 생각했다' 같은 문장보다 어떤 근거로 어떤 결정을 내렸는지가 드러나야 합니다. 분석 문서라면 출처와 가정을, 관리 기록이라면 날짜와 변경 이력을 남겨 두는 습관이 좋습니다.
이런 사람은 사업 PM, 이런 사람은 개발 PM
- 게임 순위와 업데이트 소식을 챙겨 보고 왜 잘 되는지 따져 보는 사람: 사업 PM
- 숫자 속에서 흐름을 찾아 설명하는 일이 즐거운 사람: 사업 PM
- 팀 과제에서 자연스럽게 일정을 짜고 역할을 나누던 사람: 개발 PM
- 여러 사람의 의견을 정리해 다음 할 일로 바꾸는 데 자신 있는 사람: 개발 PM
처음에는 어느 한쪽으로 확신하기 어려울 수 있습니다. 그럴 때는 게임 하나를 정해 사업 분석 문서와 개발 일정 문서를 하나씩 직접 써 보세요. 어느 쪽을 쓸 때 시간이 덜 아깝게 느껴지는지가 꽤 정확한 신호가 됩니다. 내 경험이 어느 PM 쪽에 더 가까운지 정리가 필요하다면, SBS아카데미게임학원 게임사업&서비스 과정 상담에서 지금까지의 경력과 관심사를 바탕으로 방향을 함께 짚어 볼 수 있습니다.
자주 묻는 질문
사업 PM은 경영학이나 마케팅 전공자만 하나요?
전공이 도움이 될 수는 있지만 필수 조건은 아닙니다. 게임 이해도와 데이터를 근거로 의견을 말하는 능력을 문서로 보여 주는 것이 더 중요합니다.
개발 PM이 되려면 개발 경험이 꼭 있어야 하나요?
직접 개발 경력이 없어도 지원할 수 있지만, 개발 공정을 이해하고 있다는 근거는 필요합니다. 팀 프로젝트 참여나 기획·QA 경력이 그 근거가 되는 경우가 많습니다.
두 PM 사이를 나중에 옮길 수 있나요?
같은 프로젝트에서 서로 긴밀하게 일하기 때문에 경력 중간에 방향을 바꾸는 사례도 있습니다. 옮기려는 쪽의 핵심 역량을 미리 쌓아 두면 전환이 수월합니다.
가까운 캠퍼스에서 게임기획 알아보기
사는 곳과 가까운 캠퍼스를 고르면 수업 내용, 오시는 길, 상담 신청을 한 번에 볼 수 있습니다.