
게임기획자는 "이 게임이 왜 재미있는가"를 문서로 증명하는 사람입니다. 아이디어가 아무리 좋아도 프로그래머와 그래픽 팀이 읽고 바로 작업할 수 있는 문서가 아…
실수 1·2: 내 역할이 흐리고 결정의 과정이 없다
첫 번째 실수는 팀 프로젝트를 소개하면서 내가 맡은 역할이 분명하지 않은 것입니다. 게임 소개, 플레이 영상, 팀원 구성이 잘 정리되어 있어도 'PM 담당'이라는 한 줄만 있다면 평가자는 실제로 어떤 일을 했는지 알 수 없습니다. 회의를 주관했는지, 일정표를 만들었는지, 범위를 조정했는지가 구체적으로 보여야 합니다.
고치는 방법은 프로젝트 기간 동안 내가 한 일을 활동 단위로 나눠 적는 것입니다. 작업 분배, 일정 관리, 회의 진행, 이슈 정리, 외부와의 소통처럼 항목을 나누고, 각 항목에 실제로 만든 문서나 기록을 연결하세요. 역할과 증거가 짝을 이루면 설득력이 크게 올라갑니다. 팀원이 함께 한 일은 함께 했다고 분명히 표시해 두세요.
두 번째 실수는 결과만 있고 결정의 과정이 빠진 것입니다. PM의 핵심 역량은 여러 선택지 가운데 무엇을 고르고 무엇을 포기할지 판단하는 능력입니다. 프로젝트 중 중요한 결정을 두세 개 골라 당시의 상황, 고려한 선택지, 고른 이유, 그 결과를 짧게 정리해 보세요. 이 기록이 PM 포트폴리오에서 가장 중요한 부분이 됩니다.
실수 3: 계획만 있고 실제 진행 기록이 없다
세 번째 실수는 프로젝트 시작 때 만든 일정표만 넣는 것입니다. 깔끔하게 정리된 계획표는 보기 좋지만, 실제 프로젝트는 대부분 계획대로 흘러가지 않습니다. 평가자가 알고 싶은 것은 계획이 어긋났을 때 PM이 어떻게 대응했는지입니다.
처음 계획과 실제 진행을 나란히 보여 주세요. 어느 작업이 얼마나 밀렸는지, 그 원인은 무엇이었는지, 일정을 지키기 위해 범위를 줄였는지 인력을 다시 배치했는지 같은 대응을 함께 적으면 됩니다. 지연을 숨기기보다 드러내고 대응을 설명하는 편이 훨씬 PM다운 포트폴리오가 됩니다.
실수 4·5: 성과를 근거 없이 말하고 위험을 다루지 않았다
네 번째 실수는 성과를 근거 없이 서술하는 것입니다. '팀의 효율을 크게 높였다', '소통을 원활하게 했다' 같은 문장은 누구나 쓸 수 있어서 차별점이 되지 못합니다. 회의 시간이 어떻게 바뀌었는지, 마감을 지킨 작업의 비율이 어떻게 달라졌는지처럼 직접 기록해 둔 사실이 있다면 그것으로 말하세요. 기록이 없다면 무리하게 숫자를 만들기보다 바뀐 절차를 구체적으로 설명하는 편이 낫습니다.
다섯 번째 실수는 리스크 관리를 다루지 않은 것입니다. 리스크는 아직 일어나지 않았지만 일어나면 일정이나 품질에 큰 영향을 주는 문제를 말합니다. 팀원의 일정 변동, 기술적으로 어려운 기능, 외부 리소스 의존 같은 것들이 대표적입니다.
프로젝트 초반에 어떤 위험을 예상했고, 그 위험을 줄이기 위해 무엇을 했는지 정리한 목록을 넣어 보세요. 예상했던 위험이 실제로 일어났는지, 예상하지 못한 위험은 무엇이었는지까지 적으면 다음 프로젝트에서 더 나아질 사람이라는 인상을 줄 수 있습니다.
실수 6: 기획 포트폴리오와 구분이 안 된다
여섯 번째 실수는 게임 아이디어와 시스템 설명이 포트폴리오의 대부분을 차지하는 경우입니다. 기획에 관심이 많은 PM 지원자에게서 자주 보이는데, 이렇게 구성하면 평가자는 기획자 지원서인지 PM 지원서인지 헷갈리게 됩니다.
PM 포트폴리오에서 게임 내용은 프로젝트를 이해하기 위한 배경 정도로 짧게 두고, 관리 문서와 의사결정 기록을 중심에 두세요. 작업 목록, 일정표, 이슈 목록, 회의록, 리스크 목록 같은 문서가 앞쪽에 오면 PM 지원자로서의 정체성이 분명해집니다. 기획 역량도 보여 주고 싶다면 부록으로 분리하는 방법이 있습니다.
실수를 피한 PM 포트폴리오의 구성 순서
앞의 실수들을 피하려면 포트폴리오의 순서부터 PM 관점으로 짜는 것이 좋습니다. 아래는 하나의 팀 프로젝트를 중심으로 구성할 때의 예시입니다.
- 프로젝트 요약: 목표, 기간, 팀 구성, 내 역할을 한 장에
- 범위와 계획: 처음 정한 범위, 작업 목록, 초기 일정표
- 진행 기록: 실제 진행과 지연, 그때의 대응
- 주요 결정: 상황, 선택지, 고른 이유, 결과
- 리스크와 이슈: 예상한 위험과 실제 발생한 문제의 처리 과정
- 회고: 잘된 점, 아쉬운 점, 다음에 바꿀 점
이 순서대로 정리하면 평가자는 프로젝트가 시작되어 끝날 때까지 PM이 어디서 어떤 역할을 했는지 자연스럽게 따라갈 수 있습니다. 게임 소개나 플레이 영상은 요약 장에 짧게 넣거나 링크로 연결하면 충분합니다.
실수 7: 회고가 없거나 잘된 점만 있다
일곱 번째 실수는 프로젝트를 마친 뒤의 회고를 빼거나, 잘된 점만 나열하는 것입니다. PM은 프로젝트가 끝날 때마다 무엇이 잘 되었고 무엇이 문제였는지 돌아보고 다음 프로젝트에 반영하는 역할을 합니다. 회고가 없으면 이 지원자가 경험에서 배우는 사람인지 확인할 수 없습니다.
회고에는 잘된 점, 아쉬운 점, 다음에 바꿀 점을 균형 있게 담으세요. 특히 아쉬운 점에서 내 판단이 틀렸던 부분을 솔직하게 적고 그로부터 무엇을 배웠는지 정리하면, 면접에서도 자연스럽게 이야기할 수 있는 좋은 소재가 됩니다.
팀 프로젝트에서 내 역할을 어떻게 문서로 보여 줘야 할지 정리가 되지 않는다면, SBS아카데미게임학원 게임기획 과정 상담에서 PM 포트폴리오에 넣을 기록과 순서를 함께 정해 볼 수 있습니다.
자주 묻는 질문
팀 프로젝트 경험이 없으면 PM 포트폴리오를 만들 수 없나요?
가상의 프로젝트로 관리 문서를 만들어 볼 수는 있지만, 실제 협업 경험이 있으면 훨씬 설득력이 높습니다. 작은 규모라도 팀 프로젝트에 참여해 PM 역할을 맡아 보는 것을 권합니다.
협업 도구 사용 경험도 적어야 하나요?
실제로 써 본 일정 관리나 이슈 관리 도구가 있다면 적어 두는 것이 좋습니다. 도구 이름보다 그 도구로 무엇을 어떻게 관리했는지를 함께 설명하세요.
가까운 캠퍼스에서 게임기획 알아보기
사는 곳과 가까운 캠퍼스를 고르면 수업 내용, 오시는 길, 상담 신청을 한 번에 볼 수 있습니다.