라이브 프로젝트에서 개발 PM의 역할 ※ 오늘의 로딩팁은 PC 버전에 최적화 되어있습니다. 웹에서 보기 |
|
|
안녕 친구들! 연초는 잘 보내고 있어? 연초라면 응당 새해버프를 받아서 이것저것 시도해보고 적당히 게을러도 졌다가, 올해는 이렇게 보낼 수 없다! 갓생 살기를 도전하기도 해야겠지? 나는 현재 라이브 프로젝트에서 PM일을 하고 있는데, 라이브 서비스를 하는 것도 비슷한 느낌이야. 유저 반응이 좋으면 ‘이야 역시 우리겜 갓겜 열심히 일해야지’ 싶다가도, ‘아니..뭐 그게 나랑 상관있나..다 귀찮다..대충해야지..’싶을때도 있거든!
아무튼 그래서 오늘 레터 주제는? <라이브 프로젝트에서 개발 PM이 하는 일>이야! |
|
|
-
1. 라이브 프로젝트에 PM이 필요한 이유는 뭔가요? |
|
|
우리가 항상 하는 말이 있지? “게임 개발은 정말 많은 유관부서와 함께 하는 일이고, 각 직군별로 이해관계도 다르다!”
그렇기에 중간에서 유관부서와 각 직군 간의 업무를 조정할 수 있는 역할로 PM이 필요해. 신규 개발 단계와 달리 개발실 인원도 많아지고 함께 업무를 수행하는 관련 부서도 많아지지. 신규 개발 단계에서는 물론이고 라이브 과정에서도 PM이 있어야 하는 이유는 원활한 개발 관리를 위함이라고 생각하면 돼. |
|
|
-
2. PM이 라이브 프로젝트에서 하는 일은 뭔가요? |
|
|
1) 업데이트 일정 관리
라이브 프로젝트는 꾸준히 ‘업데이트’를 진행하지? 치명적인 버그가 발생하면 긴급패치를 하기도 해.(주로 핫픽스라고 함) 이 과정에서 생기는 협업과정을 조율하는 일을 PM이 한다고 생각하면 돼.
업데이트를 위해서는 기획자가 요구사항을 정리하고, 프로그래머가 요구사항을 구현하고, 아티스트가 그래픽 리소스를 제작하는 개발 공정을 거치게 돼. 그 이후에는 QA를 위해 QA팀과 일정을 협의하고 안내하지. 개발 과정에서 사업부와 협의를 통해 기획 방향이 변경되기도 하고, 상품의 판매 일정 등이 변경되기도 하는데….
이렇게 시시때때로 변하는 상황들을 체크하고 관련 업무의 사이드 이펙트를 챙기는 일도 PM의 중요한 업무 영역이야! 이 때문에 보통 작업 내역을 정리하고, 유관부서에 공유되는 ‘빌드노트’를 만드는 일도 대개 PM이 하게 되지! 결국, 업데이트가 정해진 날짜에 수월하게 될 수 있도록 조정하는 모든 일들이 라이브 PM의 역할이라는 거!
|
|
|
2) 핫픽스 대응
신규와 라이브가 가장 다른 점이 뭐냐?고 물으면 나는 ‘핫픽스가 있냐, 없냐’라고 생각해.
업데이트 후 이슈가 발생했을 때 급하게 대응해야하는 건이 있다면 핫픽스를 진행 해. 핫픽스는 쉽게 말하면 긴급패치/점검을 의미해. 보통 접속이 안되거나, 게임 진행 또는 밸런스에 영향을 미치는 건들에 대해 우선도를 높여 대응하는 편이야.
이슈가 발생하면 PM은 가장 먼저 이슈의 중요도를 판단하고, 핫픽스 여부와 함께 원인과 대응 방안 등을 체크해서 유관 부서에 공유해. 개발실에서 원인 파악이 끝나면 언제즈음 핫픽스가 가능할지 확인하고, 실제 점검 시간을 픽스해.
당연히 점검 시간을 픽스하는 것도 협의가 필요한 부분이야. 개발실만 준비되었다고해서 핫픽스가 되는 것은 아니고 배포를 담당하는 부서와 사업부 등 다른 부서와도 조율이 되어야 하기 때문이야.
|
|
|
쿠키런: 킹덤 - 오류 정상화를 위한 임시 점검 안내 |
|
|
다만, 라이브 서비스에는 개발PM 말고 ‘서비스 PM’이라는 직군이 있기도 해! 그런 경우는 사업/운영 소통을 마크하는 담당자가 ‘서비스 PM’인 경우도 있지. 이때 개발PM은 내부 개발실 소통에 더 힘쓰게 될거야. 어떤 게임이냐, 어떤 회사냐 등에 따라 PM이 하는 일과 구성은 다를 수 있다는 점 참고 부탁해! |
|
|
3) 개발실의 케파 파악
주기적으로 진행되는 업데이트를 개발실이 소화할 수 있는 물량으로 협의하고 간격을 조정하는 일도 PM이 할 일이야. 이는 넓은 차원에서 ‘리스크 관리’인데 물리적으로 불가능한 양을 업데이트 하게 되는 일이 없도록하고, 개발실의 케파를 파악하는 일이기도 하지. 케파를 정확히 알지 못하면 예정된 업데이트 일정을 미루거나 하는 일들이 생기지.
예컨대 신규 캐릭터를 추가해야하는 상황이라면, 이전에 개발 당시 신규 캐릭터 추가 시에 며칠이 걸렸는지 파악하겠지? 이때 사용하는 개념이 MD야. ‘한 사람이 투입되었을 때 며칠이 걸린다’는 의미로 Man Day라고 칭해.
예컨대 신규 캐릭터 추가에 드는 MD가 300일이라면 3명을 투입했을 때에는 100일이 걸린다는 계산을 할 수 있지. 이 때 하루하루는 당연히 공휴일 등을 제외한 WD(Working Day, 일하는 날) 기준으로 계산해야 하고말이야. 이어서 신규 클래스 출시에 필요한 리소스가 무엇이 있는지도 함께 파악해. 그러고나면 기획자/아트/프로그래머 등이 몇몇명이 투입되어야 할지 어느정도 감이 오게 되거든. 그거에 맞게 각 팀에 인원 할당을 요청하고, 업데이트 일정을 맞출 수 있도록 담당 인원을 붙이는 셈이야. |
|
|
케파란?
Capacity. 능력/역량이라는 영어단어지? 보통 회사에서는 어떤 기업/조직/사람이 소화할 수 있는 일이나 능력/역량 등을 말해. 예를들어 “이 일정으론 우리 케파로 불가능해요”라고 한다면 우리 개발실 손으로는 일정 내에 일을 끝낼 수 없다는 뜻이야.
|
|
|
4)유관부서와의 협업
우리가 계속 해서 강조하는 게 있지? “유관부서와 할 일이 많다!”
개발실의 유관부서라고 하면 어디가 있을까? 회사 규모가 클수록 업무가 체계화/분절화 되어 있어서 유관부서가 많아져. 지금까지 내가 거쳐온 회사들은 대개 QA팀, 사업부, 인프라/보안 등의 기술 부서, 마케팅팀, 현지화팀, 사운드 등과 직간접적으로 협업해야 했어.
개발실 내 게임개발자들이 게임 외적인 부분까지 모두 챙기기는 어려울 뿐만 아니라 비효율적이기 때문에 라이브 개발PM이 주로 개발실을 대표하여 커뮤니케이션에 나서는 경우가 많지. (물론 협업 범위와 담당 직군은 회사마다 다르다는 점 꼭 참고 부탁해! 내가 거쳐온 회사 모두 같은 팀을 대응하더라도 담당 직군은 달랐어)
|
|
|
윈도우95 발표 당시 광기에 가득찬.. (개발자를 내세우지 않는 이유) |
|
|
대표적으로 내 짬에서 쉽게 할 수 있고 자주 하게 되는 일은 마케팅용 리소스를 수급하는 일이었어. 예컨대 사업부에서 금번 업데이트에서 대표 BM으로 신규 픽업 가챠를 대대적으로 판매하려고 한다면 어떨까? 이 경우라면 나는 해당 가챠 상자 아이콘을 전달하고, 가챠에서 나오는 무기나 방어구의 모델링 리소스를 함께 전달할거야. 특정 종족에 따라 무기/방어구의 외형이 다르다면 종족별로 착용하고 있는 리소스도 함께 전달하겠지. 이런 식으로 라이브 과정에서 생기는 각종 요청들을 대응하면서 게임이 잘 서비스 될 수 있도록 돕는 것이 라이브 PM의 중요한 역할 중 하나야.
|
|
|
-
3. 라이브 개발PM이 좋은가요? 신규 개발PM이 좋은가요? |
|
|
이건 개취를 많이 타는 영역일 것 같아. 애초에 비교우위에 둘 문제도 아니지. 개인의 성향과 취향에 따라 라이브냐, 신규개발이냐는 정말 선호도가 다를거야. 나는 라이브가 압도적으로 만족스럽고 좋았어. 유저 반응이 즉각적이고, 긴급으로 올라오는 이슈들을 빠르게 쳐내고 진압(?)할 때의 쾌감이 있거든. 반면 신규 개발은 심해를 떠다니며 끊임없이 수영하는 느낌이었어.
그리고 신입이라면 일단은 라이브를 겪어보는 걸 추천해. 라이브를 하면서 게임 서비스는 이렇게 되는구나, 게임 개발은 이렇게 되는구나를 알아야 개발실이 돌아가는 프로세스를 제대로 파악해볼 수 있거든. 신규 개발은 아무래도 아직 공개되지 않았고 내부적으로도 정리가 필요한 상황이 많아. 그러다보니 이미 정리가 되어 돌아가고 있는 라이브가 신입으로서 더 배우기 좋은 환경이라고 생각해.
|
|
|
💬 뉴미
나는 라이브가 좋아. 나는 라이브가 정말 좋아.
|
|
|
-
NOTICE
오늘의 로딩팁 레터를 유익하게 읽었다면 설문조사에 참여해 주세요💙
|
|
|
발행인 오늘의 로딩팁
이메일 주소 admin@loadingtip.com
|
|
|
|
|