나는 첫 회사 생활을 게임 QA로 시작해서 2년 정도 근무를 하고,
여러 요인들로 인한 고민 끝에 개발 PM으로 직무를 바꾸고자 결심한 뒤 2달 후 새 회사 + 원하던 직무로 이직을 하게 되었다.
짧은 기간이었지만 관련하여 고민하고 정리했던 내용들을 요약해보고자 한다.
아마 나중에 시간이 된다면 각 카테고리마다 별도 게시물로 상세히 내용을 정리해 보는 것이 좋을 것 같기도 하다....
개발 PM vs 사업 PM
어떤 차이가 있을까?
업계 사람이라면 잘 알고 있겠지만, 일반적인 IT, 서비스 계열의 PM 업무와 게임 개발에서의 PM 업무는 다른 점이 많다.
그중 가장 눈에 띄는 것은, PM이라는 직군 아래에, 상세하게 개발 PM과 사업 PM이라는 단어가 따로 존재한다는 것이다.
두 직무의 차이점은 이름에서 충분히 드러난다고 생각하는데, 단적인 예시로 아래의 이미지를 보자.
한눈에 '개발 PM'의 카테고리와 '사업 PM'의 카테고리를 찾기에는, 개발 PM이 바로 노출되진 않음을 알 수 있다.
사업의 경우, 별도로 ~~ 사업에 속하는 부분으로 바로 확인이 가능한데, 개발 PM의 경우 그 소속은 '프로덕션'이다.
정확한 모집 공고 별 요건 차이를 보면 더 명확할 텐데 내용이 많기도 해서.. 요약을 하자면,
사업은 말 그대로 사업 연관으로, 외부 시장 데이터와 게임 프로젝트 사이에서 필요한 전략 수립 등 게임 <->외부 사이의 업무를 모두 진행한다.
하지만 개발 PM은 주로 한 프로젝트 내부에서, 개발 진행 상황을 면밀히 파악하며 일정 관리, 프로젝트 이슈 해결을 위한 업무를 진행한다.
개발 PM 선택의 이유
가장 큰 이유는, QA 경험을 살릴 경우 어느 정도 직무 적합도를 가지는 영역이었기 때문이다.
개발 PM의 경우, 신입 채용이 흔하지 않다.
개발 공정과 세세한 프로세스, 아트/기술/기획 각 조직의 일하는 방식을 어느 정도 이해하고 있어야 하기 때문이다.
그래서 개발 PM은 정확히 어떤 직무 출신이어야 한다는 내용을 담지는 않더라도, '게임 업계 경력이 있으며 개발 프로세스에 대한 이해가 있는' 인원을 주로 채용하고자 한다.
주로 신입 공채를 제외한 개발 PM들을 보면, 기획 출신 이력이 있는 분들이 가장 많았던 것 같다.
그리고 소수의 QA출신, 아마도 더 소수의 프로그래머 출신 정도가 있었다.
QA의 경우 주로 개발 프로세스 후반부에 품질을 검증하는 과정을 진행하는데, 단순히 버그만 찾고 리포트하는 것이 아닌 여러 업무를 하게 된다.
그중에는 빌드 목표, 컨디션에 대해 깊숙하게 관하는 것이 있을 수도 있고, 피쳐 하나하나의 개발 진행 상황을 면밀히 살펴서 그것이 완료되었을 시점에 테스트를 진행하기 위한 현황 트래킹도 진행할 것이다.
해당 업무는 어느 정도 개발 PM의 업무 (중 빌드 매니징에 관련된) 일부와 연관성을 지닌다.
나는 라이브가 아닌 개발 프로젝트의 QA 업무를 진행하면서, 다행히도 개발팀과 밀도 있는 커뮤니케이션을 진행하며 습득한 지식이 조금은 있었고, 이외에 프로세스 개선을 위해 노력했던 부분들이 도움이 되었던 것 같다.
이력에서 어떤 스킬이 도움이 되었는지는 아래에서 자세하게 정리하고자 한다.
개발 PM 직무에 도움이 된 QA 업무 이력과 스킬
1. 개발 현황 트래킹
당연히 해야 할 업무이긴 하다. 하지만 트래킹을 얼마나 효율적으로 진행했고, 공수는 적되 현황을 효과적으로 알 수 있는 방법을 어떻게 적용했는지도 중요하다.
완전히 나의 주도는 아니었지만, 처음에는 QA쪽에서, 이후 PM과 함께 현황 관리를 했던 것이 긍정적인 요소가 되었다.
해당 과정에서, 필요한 경우 자동화 툴 또는 엑셀 기능, VBA를 활용한 것도 좋은 평가를 받았던 것 같다.
2. 빌드 릴리즈/패치 리스트 체크
형상관리 툴의 데이터를 기반으로, 패치 노트 작성을 위해 커밋/서밋 리스트를 정리하여 표로 추출하는 프로그램을 직접 제작했다.
해당 업무를 진행하게 된 목표 자체는 원래 패치 노트 작성을 서포트하자는 것은 아니었고, QA에서 능동적으로 변경 사항을 체크하고 조기에 버그를 발견하자는 취지이긴 했는데.... 어찌하다 보니 패치노트 작성 용도가 되었다.
작업 중간 산출물로 나오는 여러 작업자들의 커밋 체크, 필요한 경우 코드의 변경 사항 체크를 진행하는 등 작은 작업 단위에서도 꼼꼼한 트래킹을 하고 리스크를 계산한 부분이 좋게 평가 되었다.
3. QA 이력 자체
내가 들어가게 된 포지션의 경우, QA 조직과의 밀접한 소통과 빌드 관리도 주 업무였기 때문에, QA 출신이라는 것이 이점이 되었다.
공고에 따라 원하는 업무 역할이 다르긴 하겠지만, 설명에 유관 부서 소통 중 QA, 또는 기술 부서 관련된 내용이 있다면 커뮤니케이션 강점을 내세울 수 있을 것 같다.
4. 아주 약간의 프로그래밍
전혀 절대 잘하는 것은 아니고, 파이썬의 경우 적당히 기업체 코딩 테스트 문제의 절반 정도는 Pass 할 수 있는 정도..(백준 골드 문제 정도였던가. 가물가물하다.) 활용이 가능했고, 필요에 따라 R, VBA 등 스크립팅이 가능했다.
관련해서 필요한 경우 툴을 직접 만들 수 있고, 각종 에러 메시지와 코드 자체에 대한 거부감이 없다는 점이 좋은 장점이 되었다.
위 1, 2번 영역에서도 조금씩 프로그래밍이 거론되었는데, 할 줄 안다면 생각보다 더 도움이 되는 것 같다.
실제로 회사에 들어와서도 툴 제작 등 다양한 영역에서 쓸모가 있었다.
서류 준비
우선, 나는 전체 과정에서 컨설팅 업체 또는 학원의 도움을 받지 않았다.
당시에는 진솔하게 해야지.. 하는 생각에서 그랬던 것 같은데, 지금 생각해봐도 나쁜 선택은 아니었던 것 같다.
하지만 준비가 부족했던 것도 사실이었다.
우선 이력서 / 자기소개서 / 경력기술서 총 3개의 영역으로 준비했고,
지원 시 필요에 따라 이력서와 자기소개서는 하나의 파일로 제출했다.
혼자 준비했기 때문에, 절대 정답은 아니라는 점 참고!!!!!!
1. 이력서
보통의 이력서와 큰 차이는 없다. 적당히 인터넷에서 괜찮은 워드 양식을 찾아서 작성했다.
대학교에서 했던 인턴 중 유효한 부분은 작성했는데, 당연하지만 입사 지원 시 적는 이력서의 내용은 합격 후에도 이력 사항을 남게 되니, 애매하거나 증빙이 어려운 경력은 제외하도록 하자.
2. 자기소개서
특별히 지원 시 질문이 정해져 있다면 그에 맞추어 작성하면 된다.
하지만 별도 양식이 정해져 있지 않은 경우, 아래와 같이 작성했다.
1) 기본적인 자기 소개와 강점 설명
+ QA에서 PM으로 직무 전환을 시도하게 된 배경과 이유를 납득 가능하게 설명
2) 공고에 요구된 자격 사항, 직무 역량과 관련한 경험 설명
3) PM 업무는 처음이기에, 어떤 자세로 배우고 성장할 것인지
4) 위 내용들과 관련한, 입사 후 포부 (3번에서 설명이 된다면 생략해도 될 것 같다.)
중요했던 점은, 면접에서까지 빠지지 않는 질문이기 때문에 '직무 전환 이직'의 사유를 잘 설명하는 것이다.
이외에, PM 직무 자체적 특성으로 인해 아래 요소를 잘 설명할 수 있는 것도 중요했다.
1) 프로세스 개선
2) 문제 해결
3) (매우 정성적이지만) 꼼꼼함과 성실함, 적극적 업무 태도
4) 정보 분석과 가공 능력
그리고, 위 모든 글에서 드러날 수 있는 충분한 논리와 일목요연한 설명 능력 필요.
3. 경력기술서
이력으로 적었던 기업과 조직에서, 어떤 업무를 수행했고, 그에 따라 발생한 영향과 결과를 정리했다.
자기소개에 작성한 사례를 포함하여 주요 역량과 관련이 있는 부분을 상세히 적고자 노력했다.
나의 경우 포트폴리오를 제출하지 않았기 때문에 게임 관련한 플레이 이력을 경력기술서에 함께 적었다.
4. 포트폴리오
주로 게임 개발 PM 포트폴리오는, 정말 다양한 내용들이 포함되는 것 같다.
그만큼 작성이 쉽지는 않은데, 기획, QA 등 기존 직무에서 위 자기소개 / 경력기술에 작성한 내용들을 보충할 수 있는 내용과 더불어서 아래 내용을 준비해보는 것도 좋을 것 같다.
(고민이 한창 많을 때에는, 주로 사업 PM 포트폴리오 관련 글만 찾을 수 있어 막막했던 것 같다.)
1) 게임 분석 내용... 쓸 것이라면 쓰자
2) 프로젝트 관리에 관련된 이론적 내용과 적용 (일감 관리 시트나, 게임 개발 프로세스에서 임의 마일스톤을 잡아 WBS, 간트 차트 등 작업을 해봐도 좋을 것 같다)
3) 현재의 직군에서 '관리'에 해당하는 영역을 수행한 기록
4) 개발 현황 관리 문서
5) 협업툴 활용 관련 내용
유독 정답이 없는 영역인 것 같지만, 충분히 잘 준비하고 실제 면접에서 설명할 수 있는 것이 중요하다.
면접
서류 전형을 잘 통과했다면, 다음은 보다 어렵다고 느꼈던 면접 전형이 기다리고 있다.
개발 PM 면접의 경우, 단순히 질문의 내용과 답변 결과에서 그치지 않고, 모든 대화 과정에서 커뮤니케이션 태도와 성향을 깊게 파악하기 때문에 잘 봤다 생각을 해도 떨어지는 의문의 케이스가 꽤 있을 것 같다.
면접에서의 내용은 물론 모두 잘 알고, 잘 답변하면 좋을 것이다.
그래도 조금 더 챙겨야 했던 것은...
1) 진솔함
2) 적극성
3) 학습과 배움에 대한 열린 태도
4) 긍정적인 사고
5) 논리성
이었던 것 같다.
QA에서 개발 PM으로 전직을 하는 경우와 같이 타 직군에서 이동을 할 때 중요한 것은, 진솔함이었다고 생각한다.
서류에서부터 내가 정확히 아는 것과 배워야 하는 것을 구분하는 것이 좋고, 지식 또는 주관이 있는 경우 그 내용을 확실하고 논리정연하게 설명해야 한다.
모르는 부분은 괜히 서류에서 때우지 말고, 면접에서 충분히 그것을 배울 수 있는 역량과 태도를 보이는 것이 중요했던 것 같다.
부풀려진 서류로 인해 정확한 답변을 하지 못하는 상황은 당연히 좋지 않지만, 직군 전환의 경우 마음가짐의 수준으로도 연결이 될 수 있기 때문이다.
나는 면접에 강한 편이라고 생각해서, 긴장을 하면서도 매번 결과는 좋았는데,
나중에 들어보니 질문에 답변을 잘했다는 점과 더불어서, 긍정적인 태도와 무엇이든 배우겠다는 자세가 큰 요소로 작용했다고 한다.
일을 해보니 왜 긍정적이어야 하고 잘 배워야 하는지 매일 느끼고 있기는 하다...
그리고, 나의 경우 노력의 결과로 이제 습관이 된 것이긴 하지만 두괄식, 개조식으로 말을 잘 정리해서 답변하는 것도 중요했다.
마치며..
두서가 없는 글이었지만 누군가에게는 필요한 정보이면 좋겠다.
꼭 QA에서 PM이 아니더라도, 개발 PM을 희망하는 사람이라면 조금이나마 도움이 될 것 같기도 하다.
일을 하며 느낀 점은 나중에 천천히 정리하며 좋은 정보를 남기고 공유해야겠다.
'게임 커리어 관련 > 게임 커리어 이것저것' 카테고리의 다른 글
| 하루아침에 개발PM에서 게임 기획자가 된 이야기 (2) | 2024.10.20 |
|---|