NDC Replay

게임 개발사에서 개발PM(팀장)의 역할과 책임.
김영웅
저스트나인
	현재 (주)저스트나인 소속 Studio UFO 개발팀장. 개발/운영/오픈한 게임으로는 청풍명월 for Kakao / 마이 리틀 피쉬 / 헬키드 등이 있음.<br/>웹에이전시에서 온라인 브랜드 디자인 실장으로 근무하다가 게임업계로 이직
	중소규모 개발사, 혹은 일반 게임 개발사에서 개발 PM이 필요한 이유와 그 역할,<br/>PM이 개발 Studio 팀장이 되었을 때의 장점, 게임개발사의 팀장(PM)이 해야할 일.<br/>개발 팀장(PM)의 가장 중요한 업무는 개발이 아니다! 중소개발사에서 팀장(PM)으로 일하면서 겪은 일들, 개발사 PM의 비전.
[새 창에서 슬라이드 보기]
안녕하세요, 저는 저스트나인 스튜디오UFO 팀장인 김영웅이라고 하고요. 이번 세션의 강연을 진행할 수 있게 되어서 굉장히 감사하게 생각합니다. 이번 세션은 게임 개발사에서 개발 PM 팀장의 역할과 책임이라는 소재이고요. 해당 내용들은 기본적으로 모든 분들께서 개발사의 게임 PM이신 분들은 기본적인 내용들은 대부분 다 알고 계시고, 또 지금도 고민하고 계실 거라고 생각이 들어요. 그래서 기본적인 게임 개발 PM으로서 수행할 수 있는 그런 기본적인 역할들은 생략을 하고, 이번 강연에서는 스케줄 관리, 그리고 인재 자원관리, 리딩 방법과 권한 위임에 관련해서만 중점적으로 이야기를 나눠보고자 합니다. 제 소개이고요. 본 세션은 중소 게임 개발사에서 개발 PM의 역할이나 혹은 팀장을 겸임하는 경우에, PM이 팀장을 겸임하는 경우가 물론 저희 회사 말고도 종종 있으실 거라고 생각이 들어요. 그럴 때 있는 저희가 느꼈던 기록이나 방법들 관련해서 얘기를 나눠볼까 하고요. 다만 저희 팀은 스마트폰 게임 전문 개발 팀이에요. 정확히 하면, 스마트폰 게임 개발 팀이라기 보다는 신규 플랫폼 게임 개발실이라고 할 수 있고요. 지금은 스마트폰에 조금 집중이 되어있고, 향후에는 다른 플랫폼에도 진출이 가능하다는 것을 염두에 두고 팀이 꾸려졌기 때문에 기본적으로 생각하시는 온라인 게임 개발실과는 내용이 약간 다를 수도 있어요. 근데 그런 부분들은 큰 부분에서 보면 이해하시고 넘어가실 부분들이 있으시리라고 생각이 되고요. 개발 PM에서 가장 중요한 것들 여러 가지가 있을 텐데요. 일단 처음에 저희가 가장 많은 내용을 할애하는 부분은 스케줄 관리와 인재/자원관리 이 부분에 이번 강연의 거의 대부분의 시간을 할애하게 될 것 같습니다. 가장 기본적인 질문인데요. 게임 개발사에서 개발 PM이 존재하는 이유입니다. 게임 개발 PM은 사실 퍼블리셔 회사, 지금 여기 넥슨이나 옆에 있는 네오위즈나 NHN같은 큰 회사에는 사업 PM이 따로 존재를 하시죠. 그 분들과 저희 게임 개발PM의 차이에 대해서 얘기를 할 텐데, 그 전에 일단 게임 개발 PM이 존재하는 이유는 모두들 당연히 생각하시겠지만, 당연히 프로젝트가 성공을 해야죠. 이건 뭐 사실 개발 PM 뿐만 아니라 전 직군의 공통된 이야기인 것 같고요. 프로젝트 성공이라는 것에 초점을 맞추게 되면 결국은 개발 PM은 커뮤니케이션이 가장 중요한 역할 중에 하나가 되거든요. 지금 여기 계시는 분들의 회사에도 마찬가지겠지만 다들 프로그램팀, 개발팀, 아트팀, 디자인팀 다 따로따로 계실 거고요. 아, 여기서 제가 말씀 드리는 디자인 팀은 저희 회사는 기획자를 디자이너라고 부르기 때문에, 저희 회사에서는 기획자를 디자이너. 그림 그리시는 분들, 아티스트를 그냥 아티스트라고 부르기 때문에 용어에 좀 혼란이 없으셨으면 하고요. 개발 PM은 결국은 지원 방향성, DM, 그리고 기획자들이 놓치고 있는 수직구조라든가 전체적인 프로젝트가 처음부터 끝까지 동일하게 컨디션을 유지해줄 수 있는 기준선을 만들어주는 역할이라고 보면 될 것 같고요. 결론은 줄이면 똑같이 성공하기 위해서죠. 프로젝트가 성공하기 위한 준비 과정을 도와주는 사람이라고 생각하면 될 듯 합니다. 그럼 프로젝트 성공을 이야기를 해 봐야 되는데 다들 프로젝트가 성공하는데 어떻게 성공하느냐고 얘기를 하시면 저희 회사도 마찬가지고, 저 역시도 마찬가지인데, 당연히 돈을 많이 벌겠죠. 돈을 많이 벌거나, 많은 유저에게 호응을 얻거나, 시장에서 좋은 가치나 좋은 평가를 받거나, 이런 부분들이 여기 나와있는 첫 번째 항목에 해당이 되는 부분이고요. 사실 여기까지만 하더라도 프로젝트 자체는 크게 성공을 했다고 말할 수 있고요. 근데 지금 제가 여기서 말씀 드리는 부분은, 프로젝트 성공이라고 함은, 개발PM으로서의 프로젝트가 성공했는지 여부를 판단하기 위해서는 수익 구조와 유저의 흥행, 이 두 가지 부분만 가지고서는 개발 PM으로서 흥행을 했느냐, 혹은 이 프로젝트가 성공을 했느냐 여부를 판단하기에는 다소 부족한 감이 없지 않나 싶었어요. 그래서 개발 PM으로서 프로젝트 성공을 위해서는 당연히 전제조건은 많은 유저와 안정된 수익이죠. 그리고 두 번째는 회사 내에 다양한 선례들을 남길 수 있는지 여부도 상당히 중요하다고 생각합니다. 프로젝트는 실패를 할 수도 있어요. 돈을 많이 벌 수도 있고, 돈을 조금 벌 수도 있고, 유저가 뭐 천만 일 수도 있고 백만 일 수도 있고 혹은 그 이상일 수도 있겠죠. 성공이든 실패든 간에 이것을 토대로 우리 회사가, 혹은 지금 계시는 회사가 다음 프로젝트나 다음 게임 개발에서 어떠한 모멘텀을 가져갈 수 있는지 여부를 남길 수 있느냐 혹은 계속 이전 프로젝트와 동일한 현상을 반복하고 있는지 여부를 확인하는 게 프로젝트 성공의 첫 번째 열쇠가 아닌가 생각이 되고요. 두 번째는 개발진의 업무 능력이 얼만큼 향상이 될 수 있는가 입니다. 사실 이 부분은 굉장히 추상적인 부분인데요. 제가 여기서 말씀 드리는 개발진 이라고 함은 프로그래머 분들만 말씀 드리는 것은 아니고요. 디자이너, 아티스트, 개발 PM 역시 포함이 되고요. 프로젝트를 수행하고 있는 참여한 모든 인원들이 얼만큼의 업무적인, 가시적인 성과를 낼 수 있는지, 그 가시적인 성과가 반드시 시장에서의 그런 수익과 연결이 되지 않더라도 얼마나 축적된 노하우를 생성할 수 있는지 여부가 될 거고요. 네 번째는 참여하고 있는 그 개발진들의 각각의 개인적인 목표가 있을 거에요. 디자이너로 시작해서 PM이 목표이신 분들도 있고, 디자이너로 시작해서 끝날 때까지 디자인만 하실 수 있는 분들도 있으실 텐데, 개발진들의 단기적인 혹은 장기적인 비전이 해당 프로젝트에 충실히 수행이 되거나 혹은 녹아 들어져 있는지 여부를 판단하는 것도 상당히 중요한 일이라고 생각이 됩니다. 결국은 프로젝트를 매니지먼트 하는 데 있어서는, PM은 Project Management 잖아요. 그 프로젝트를 수행하고 있는 개발진들이 결국은 이 프로젝트를 만들어 나가는 주체이기 때문에 게임 개발 프로젝트 매니저는 결국은 무엇이 아니라 누군가를 매니지먼트 해야 된다는 것으로 좀 생각이 바뀌었으면 하는 마음에 강의를 준비했고요. 결국은 개발이라는 이 추상적인 행위를 전체를 수행하는 것은 결국은 개발자거든요. 제가 지금 여기 말씀 드리는 개발자에 이사님들이나 회사의 경영진 분들이 포함이 안 되어있을 수도 있고, 혹은 포함이 되어있을 수도 있어요. 근데 그런 것들을 다 포함해서, 결국은 모든 행위를 하는 그 주체가 얼만큼 비전을 가지고 얼마나 많은 모멘텀을 스스로 가져갈 수 있는지 여부가 가장 중요하지 않을까 생각이 들고요. 따라서 프로젝트 매니지먼트는 결국은 프로젝트 개발 인력과 관련된 매니지먼트고요. 사실 저는 인력이란 말을 그렇게 딱히 좋아하지는 않는데요. 인력이라는 말 보다는 인재라는 말을 더 좋아하는데, 일단 기본적으로 많이들 쓰이고 있어서 인력이라는 말을 쓰고 있고요. 얘는 곧 개발 인력들의 스케줄 관리와 산출물 관리를 통해서 결국은 프로젝트 매니지먼트가 만들어진다고 생각을 합니다. 물론 여기서 제가 지금 이번 강연에서 소개하고 있지 않은 기본적인 업무들이 있어요. 지표 관리, 출시 전략, 마케팅 전략, 운영 방안, 퍼블리셔와의 커뮤니케이션, 회사 경영진과의 유대관계 관리, 이런 기본적인 업무들이 있는데 이런 부분들을 본 강연에서 말씀 드리지 않는 이유는 이미 여러분들이 회사에서 개발 PM이시거나 혹은 각 팀장님들이 이런 부분을 충분히 신경을 쓰고 있다고 생각이 들고 있기 때문에 이 부분들은 강연에서는 말씀을 드리지 않는 거고요. 사실은 가장 기본적인 내용이 되겠죠. 그러면 프로젝트 매니지먼트는 결국 개발 인력들의 스케줄이나 산출물 관리라고 제가 말씀을 드렸는데, 이를 가장 효과적으로 하기 위해서는 각각의 팀원들이 가지고 있는 업무 능력과 업무 성향, 이 두 가지를 파악한 다음에 얼마나 더 효과적으로 동기부여를 할 수 있는지 여부가 가장 중요할 텐데요. 이 부분은 좀 더 뒤에 이야기를 하도록 하고요. 일단 먼저 스케줄 관리부터 이야기를 하겠습니다. 다들 아시겠지만 스케줄이라고 하면 전체 지도라고 보시면 되겠죠. 게임 개발의 1부터 10까지, a부터 z까지 전체가 다 녹아 들어져 있는 거고요. 이것을 크게 지도로 보시면 지도 안에 대한민국도 있고, 중국도 있고, 미국도 있듯이 지도 안에 모든 지역들이 골고루 각 팀원들로 할당이 되어 있다고 보시면 되겠죠. 그러면 스케줄 관리에 있어서 가장 중요하게 생각되는 요소는 뭐가 되느냐인데. 저희 같은 경우에는 두 가지를 보고 있습니다. 첫 번째는 마스터 플랜을 공유할 수 있느냐 없느냐, 두 번째는 돌발 이슈가 기본 스케줄에 충분히 고려되어 있는지 여부입니다. 마스터플랜이라고 함은, 지금 보시는 것은 저희 개발팀의 샘플인데요. 각각의 모든 개발진들이 개발을 시작하기 전에, 지금 제가 말씀 드리는 개발 시작이라고 함은 프로토타입이 완성이 되고, 메인 기획이 어느 정도 끝난 뒤에, 추상적인 개발이 아니라 그 개발을 확정을 짓고 예산을 확보한 다음에 실제로 그 개발을 시작하기 바로 직전의 단계를 말씀 드리는 겁니다. 이 때는 모든 개발진들에게 마스터 플랜이 공유가 되어야 하고요. 마스터 플랜이 필요한 이유는 다른 팀원들의 업무 스케줄을 파악하기 위해서인데요. 굳이 내 파트, 만약 제가 개발자면, 프로그래밍 파트가 아닌 아티스트의 파트 별 업무까지 다 파악을 하고 있어야 되는 이유는 전체 과정을 숙지를 하고 있어야 내 작업이 이슈가 생기거나 혹은 내 작업의 스케줄을 변경할 때 다른 스케줄이 어떻게 변경이 되는지 여부를 가장 손쉽게 파악할 수 있었기 때문이고, 이것을 통해서 이루고자 하는 가장 큰 목적은 모든 개발진들이 동일한 컨디션에서 동일한 목적을 가지고 게임을 끝까지 개발할 수 있는지 여부를 확인하기 위해서고요. 거기에 있어서 가장 큰 지원이 될 수 있다고 생각이 되기 때문입니다. 당연히 작업을 하다 보면, 모두 개발하시면서 느끼시겠지만 계속 뭔가가 생겨요. 하다 못해 전혀 버그가 안 날 거라고 생각하는 부분, 은 없지만, 갑자기 돌발적으로 버그가 좀 많이 나오기도 하고, 혹은 일정상에 차질이 생기기도 하고, 여러 가지 문제가 있겠죠. 그런 과정에서의 스케줄을 임의로 변경을 하게 되면 그 스케줄에 맞춰서 작업을 하게 되는 다른 팀 간에도 작업 스케줄 간에 차질이 빚어지게 됩니다. 그렇기 때문에 반드시 스케줄 관리는 PM이 통합을 해서 관리를 해야 된다, 고 생각을 하고 있고요. 이럴 때는 반드시 다른 팀과의 협의 없이는 팀 개인의 업무라고 할지라도 스케줄을 임의로 변경해서는 절대 안 되는 것을 우선 저희 팀은 원칙으로 하고 있고요. 그럼 세부 일정은 당연히 담당 개발자가 짜겠죠. 지금 여기 마스터플랜에 보이는 그런 일들은 각각의 개발자들이 예를 들어 특정 A라는 게임에 10가지의 과제를 수행하고 있으면 그 10가지를 전부 다 스케줄로 표시를 해 놓는 겁니다. 그래서 길 때는 여기 보이는 화살표가 200여개, 300여개까지 나갈 수도 있겠죠. 그런 부분들은 개인 개발자들이 직접 일정을 짜 줘야 하고요. 그러면 개발 PM은 거기서 추가로 1~3일 정도를 추가를 하는데, 이건 난이도나 그 동안 개발을 하시면서 예상 되었었던 이슈들의 처리 과정들을 통해서 난이도별로 일정을 세부적으로 좀 추가를 해 줘야 되는데요. 이유는 아까 설명을 드린 이유와 동일 하겠고요. 여기서 주의해야 될 부분은 저희가 보통 일주일, 이번 작업은 얼마나 걸릴 것 같아 하면 이번 주 안에 끝날 것 같아요, 혹은 이번 달 안에는 끝날 것 같아요 하는데 개발 PM이 작업하기 가장 좋은 부분은 일수로 계산하는 겁니다. 왜냐 하면 평일에도 반드시 휴일이 끼어 있는 경우도 있고, 공휴일이 아니더라도 회사 자체적으로 쉴 때도 있고, 혹은 회사 자체적인 행사가 있을 수도 있기 때문에 반드시 일수로 계산을 해서 작업을 해야 되고요. 그래서 휴일이 없는 주라고 하면 5일은 1주가 되겠고, 20일은 4주가 되겠고, 뭐 이런 형태가 되겠죠. 그리고 개발 PM님들에게 당부하고 싶은, 제가 부탁 드리고 싶은 말씀은 팀원들이 절대 하루 온종일 일하지 않는다는 걸 생각해주셨으면 하는 거죠. 마찬가지로 생각해보시면 회사 출근하면 옆에 팀원들하고 커피도 한 잔 하고, 담배를 태우시는 분들은 담배도 잠깐 피러 나가시고, 뭐 잠깐 이야기도 하고, 점심도 먹고, 좀 졸리면 서핑도 하고, 뭐 그렇기 때문에 하루 종일 일하는 사람은 세상에 없거든요. 그렇기 때문에 PM 분들도 본인들의 개발자들이 하루 온종일 일한다는 생각은 안 하시는 게 훨씬 더 스케줄 관리에 도움이 되지 않나, 라고 생각을 하고요. 기본적으로 야근과 주말 근무, 이런 부분들을 개발 시작하기 전에 스케줄 관리에서 그런 부분들을 철저하게 배제를 하고 들어가도 나오거든요. 저희도 사실 주말 근무나 이런 게 없는 회사는 아니기 때문에 저희도 그런 부분이 걸려있지만 이런 부분을 처음부터 고려하게 되면 그것보다 더 길어지거나 혹은 그것보다 더 나쁜 상황이 발생을 할 수 있게 되는 부분이 있어서 그런 부분들은 미리 생각을 해 주시는 게 낫지 않을까 싶고요. 이러면 가장 첫 번째 의미는 개발비가 너무 초과되는 것 아닌가 하는 부분인데요. 저희 인력이 곧 개발비죠. 그리고 일정이 곧 개발비와 직결이 되는데 이것들을 너무 길게 잡게 되면 실질적으로 개발 PM님 분들께서는 회사에서 예산을 따내셔야 되거나 혹은 대표님들께서 직접 예산을 집행하시는 경우들이 많기 때문에 이런 부분에 있어서 많이 부딪히게 될 부분들인데요. 이 부분들은 개발 PM님 분들이 직접 부딪혀서 해결을 해 주셔야 된 부분들인데 이렇게 작업을 한다 한들 사실상 딜레이가 안 생길 수는 없거든요. 돌발 이슈가 생각지도 못했던 것들이 언제든지 나오기 때문에 이렇게 기본적으로 여유 일정을 잡아놓지 않으면 전체적 스케줄에 영향을 미치게 되고요. 결국은 개발이 끝나고 나면 그 다음에 이어지는 운영 업무라든가 마케팅 운영이라든가, 이런 나머지 일련의 스케줄에도 전부 다 밀리게 되기 때문에, 특히나 이제 이런 부분들은 외부와의 협력이 가장 큰 키 포인트로 작용을 하는 부분들이거든요. 이 부분들이 개발 때문에 밀리게 되면 사실상 좋은 게임을 만들어놓고 좋은 효과를 거두기 위한 좋은 꾸밈을 가질 수 없는 형태가 되기 때문에 개발 PM님 분들께서 작업을 하실 때 후속으로 이어지는 운영 업무와 마케팅 업무도 같이 연관을 해 둬야 된다는 부분이 중요하다고 생각이 들었고요. 그리고 초반에 너무 타이트하게 일을 진행을 하다 보면 개발비를 대표나 혹은 예산을 집행하시는 분들께서는 개발비가 예를 들어 한 2억쯤 되겠지, 라고 생각을 하고 집행을 하게 되는데 실제로 거기서 2배, 3배 넘어가게 되면 기본적으로 자금을 집행하거나 자금을 준비하셨던 부분들에서 큰 오버가 나오기 때문에 이런 부분이 결국은 실제로는 손실이 아닌데 결과적으로는 손실로 이어지는 부분이 발생을 하게 되니까 이런 부분들도 염두를 해 두면 크게 길게 이어지는 부분은 아니라고 생각을 하고요. 이렇게 일정을 만들었으면, 제가 가장 중요하게 생각하는 것 중에 하나인데요. 공유입니다. 개발에 참여하는 모든 인원들이 모든 스케줄을 모두 다 공유를 하고 있어야 되는 거죠. 그것도 같은 자리에서. 그래야 서로의 얼굴을 보면서 서로가 어떤 작업이 지금 연관이 되는지를 알 수가 있는 거고, 그럴 때 추가적으로 일말의 책임감을 좀 더 가중시켜줄 수는 있겠죠. 그리고 나면 여기는 방법이 이렇게 나와있기는 한데 각각의 팀원들마다 완전히 파악을 하는 데 있어서 도움을 줄 수 있는 방법들이 여러 가지 있을 거에요. 그것은 개별 팀장님들께서 가장 잘 아시는 부분일 테고, 그런 식으로 해서 계속 리마인드를 해 줘야 하는데, 이 부분은 쓰여있지만, 못 믿어서가 아니라, 각각의 개발 팀원들에게 완전히 파악할 수 있는데 도움을 주기 위한 서포트라고 생각을 하시면 될 것 같고요. 다음 기획서 리뷰입니다. 시간이 빨리 가네요. 기획서 리뷰는 게임에 들어가는 모든 컨텐츠를 아까와 동일하게 게임에 개발 참여하는 모든 인원들이 빠지지 않고 모두 다 함께 리뷰를 하게 되는 부분이고요. 그렇게 하는 이유는 흔하게 이야기가 나오는 거지만, 기획서 읽어오세요, 라고 하면 안 읽죠, 잘. 안 읽는 게 대부분이고, 혹은 선입견을 가지게 될 수도 있고요. 그리고 메인 기획자의 입장에서는 각각이 가지고 있는 선입견들을 한방에 해결할 수 있는 가장 빠른 길이기도 하고요. 저희 청풍명월 같은 경우를 예를 들면, 최초 리뷰, 게임의 초반 기획서가 나오고 그 초반 기획서를 리뷰 하는 데는 5일 정도가 걸렸고요. 5일 전체를 사용한 거죠. 출근할 때부터 퇴근할 때까지. 이 사이에 계속 나오는 이슈들은 수정하고, 다시 리뷰하고, 수정하고, 다시 리뷰 하는 형태로 계속 진행을 했었던 거고요. 이 시간이 완성도가 높아질수록 컨셉이나 방향성에 대한 일치가 이루어진다고 생각을 하기 때문에 이 시간을 크게 아까워하지 않으셨으면 하는 바램입니다. 그 다음에 업무 능력과 성향 파악인데요. 사실 게임이라는 컨텐츠가 기본적으로 크게 자재가 들어가는 비용이 아니에요. 아시겠지만 컴퓨터, 인터넷, 전기 이런 잡다한 것들, 커피, 핫식스 이런 것들이 포함이 되는데, 그런 부분들은 사실상 중장기적인 자재가 될 수 있거든요. 그럼 결국은 게임을 개발하는데 있어서 가장 큰 자재는 게임 개발 인력의 업무 능력과 조화라고 보면 되고요. 말씀 드린 바와 같이 업무 능력은 곧 개발자의 성장이 되는 거죠. 그렇기 때문에 결국은 좋은 개발 PM이라고 하면 팀원들의 업무능력이 얼만큼 성장되는지 여부로 결국은 판단이 되는 것 같다고 생각이 됩니다. 팀원의 성향과 성격을 구분을 해야 될 텐데요. 이것은 제 개인적인 구분이기 때문에 다른 부분이 있을 수도 있고, 사실 여기에 딱 맞춰서 들어가는 구분이란 존재하지 않는 게 사실이죠. 다만 이제 각각의 팀원들이 어떠한 성향을 가지고 있는지, 혹은 어떠한 위치에서 어떠한 동기부여를 시켰을 때 가장 잘 이끌어낼 수 있는지 여부를 판단하기 위해서라고 생각하시면 되고요. 그리고 나서 이제 업무 성격이 있는데, 뭐 마찬가지죠. 너무 타이트하게 끌어당기는 게 부담스러운 사람들에게는 자유롭게 풀어줘야 할 테고, 그런 사람들에게는 오히려 직급을 주어지게 되면 직급이 사람을 만든다는 그런 말처럼, 오히려 좀 더 나은 개발환경에서 좀 더 나은 개발능력을 보여주는 케이스도 많이 보아왔기 때문에 이렇게 나눠 놨고요. 결론은 뭐가 좋느냐, 뭐가 나쁘냐, 프로토타입이 좋냐, 관리자형이 좋냐 이런 게 아니고요. 개발진이 예를 들어서 20명이 있다고 하시면, 그 개발진마다의 각각의 성향들이 있으실 거에요. 결국은 개발팀이 가장 중요한 것은 개발을 잘 하기 위해서이기 때문에, 그러기 위해서는 각각의 개발자들이 어떠한 방식으로 지원을 해줬을 때 효과적인 능률을 낼 수 있는지 여부를 판단하는 게 가장 중요하다고 생각합니다. 효과적인 동기부여 방법. 다들 생각을 하시겠지만 가장 좋은 동기부여는 돈이죠. 연봉 많이 주면 저도 좋아합니다. 진지하고요. 근데 뭐 사실 모두가 아시겠지만 현실은 그렇지 않죠. 그렇다고 하면, 동기 부여는 결국 이 일에 얼만큼 내가 스스로 직접 참여할 수 있는지, 그 마음을 가질 수 있게 만드는지 여부인데, 저희 회사에서 이를 위해서, 저희 팀에서 몇 가지 기준을 세웠어요. 첫 번째는 초반 아이디어와 개발 컨셉, 프로토타입은 파트의 구분이나 직급의 구분 없이 동일하게 제안, 발표가 가능해야 한다는 부분이고요. 지금 여기 샘플로 나와있는 것들은 저희 팀에 입사를 할 때 저희 팀에서 나누어주는 스튜디오 UFO 팀원 입사 가이드입니다. 총 해서 9개 정도 항목이 있는데, 그런 내용이고요. 두 번째는 스케줄 관리를 통한 야근을 최소화시키는 부분이고요. 꼭 당부 드리고 싶은 말씀은 정말 야근은 없어져야 합니다. 모두가 너무나 힘들어하기 때문에, 결국은 개발 딜레이가 가장 크게 일어나는 요소 중에 하나가 잦은 야근으로 인한 개발 능률 저하라고 생각이 들기 때문에 최소한 야근은 가장 없어져야 될 부분이라고 생각을 하고요. 그 다음은 근속 상패나 생일 선물 같은 회사에서 크게 부담이 되지 않더라도 저 비용으로 전달할 수 있는 감성적인 부분들이 있는지 여부를 판단해 보는 거고요. 지금 여기 샘플로 나와있는 이미지는 저희 팀에서 입사 주기마다 팀원들에게 주는 상패이고요. 보시면 1년째에는 전설의 시작이라고 되어있고, 4년쨰는 다르게 되어있는데, 기획 파트, 프로그램 파트, 아트 파트가 전부 다 다른 트리를 타게 되는 형태이고요. 네 번째는 본업 외의 업무에 대해 신경 쓰지 않도록 해 주는 건데, 이건 뒤에서 좀 더 자세히 얘기하도록 하고요. 그리고 다섯 번째는 좀 힘든 내용이긴 하지만, 개발 PM이 중간에서 빠지게 되면 개발진들이 결정을 못하게 돼요. 그렇기 때문에 야근과 주말 출근이나 혹은 긴급 상황에서는 개발 PM이 가장 먼저 있거나, 혹은 반드시 있어야 되는 상황이라고 생각이 되고요. 여기서 가장 중요한 건 개발자가 혼자 일하게 두면 안 된다는 부분입니다. 아까 잠깐 말씀 드렸던 주말 출근 관련해서도 개발자들이 주말에 혼자 나와서 출근을 하게 되면 본인은 거기에 대해서 굉장히 만족감을 느낄 수도 있지만 그게 지속이 되다 보면 결국은 이 프로젝트는 나 혼자 하나? 라는 생각으로 이어질 수 있기 때문에 그런 생각을 사전에 방지하기 위해서라도 개발 PM이 먼저 좀 나서줘야 되지 않나, 라고 생각이 되고요. 나머지 부분은 뭐 보시면 아시고요. 게임 개발 회사에서 어떤 리더십이 가장 필요할까, 라고 저 역시도 많이 고민을 했는데요. 요즘에 가장 사실 한 두 번쯤은 들어보셨을 내용이고요. 서번트 리더십이라고 하고, 결론은 각각의 게임 개발진들이 우리는 사실 사회적 이슈가 어떻든, 이렇든 저렇든 간에 게임을 만들기 위해서 여기 모여있기 때문에 본인들이 어떤 것을 하고 싶어 하는지, 내가 어떤 역할을 수행하고 싶어하는지에 대한 그런 아이덴티티가 분명한 사람들이거든요. 그렇기 때문에 이러한 사람들에게는 최소한 존중을 받고 있다고 느끼고 존중을 받으면서 일할 수 있는 여건을 만들어 줘야 된다는 거죠. 가수든, 매니저든 결국은 잘 관리해서 가수는 스타를 만드는 거고, 저희는 스타 게임을 만드는 건데, 결론은 스타 게임은 곧 스타 개발자, 혹은 그 개발자들의 업무 능력이기 때문에 원하는 목표는, 결국은 매니지먼트의 원하는 목표는 동일하다고 보시면 되고요. 아, 이건 좀 아닌 것 같고요. 그렇기 때문에 잘할 수 있는 것은 최소한 잘 할 수 있게 만들어 주어야 한다고 생각을 하고요. 프로그래머는 프로그램을 짜고, 디자이너는 디자인을 하고, 아티스트는 아트를 해야죠. 이게 사실 언뜻 보면 당연한 내용인데, 뭐 여기 내용이 좀 있지만 결론은 각 파트별로 고유의 권한을 가지고 있을 때 전문성이 살아난다는 부분을 좀 염두에 두셨으면 해요. 디자이너, 특히나 기획자 분들이 그런 부분이 많이 상충이 될 텐데, 기획자 분들은 업무들이 다 한글로 표시가 되고 있기 때문에 사실 첨언을 하기가 가장 쉽거든요. 그런 부분에 있어서 기획자들이 고유 권한을 가지지 않으면, 즉 게임 디자인에 있어서 고유 결정과, 방향성, 컨셉에 대한 가이드를 기획자가 가지고 가지 않고 프로그래머나 아티스트가 가지고 가게 되면, 혹은 개발 PM도 마찬가지죠. 제가 게임 개발의 컨셉을 확정을 하지는 않기 때문에 그런 부분에 있어서는 각각의 고유 권한을 반드시 주어야지 결국은 처음부터 말씀 드린 각각의 개발진들의 업무능력이 향상이 된다, 라고 생각이 들고요. 그렇게 따지면 결국은 팀장의 우선 업무는 관리죠. 프로그램을 병행하시면서, 혹은 기획을 병행하시면서 하시는 분들도 계실 텐데, 팀장님들께서는 최소한 그런 부분들을 갈수록 줄여나갈 수 있으셔야 된다, 라고 생각을 하고요. 그렇기 때문에 각각의 개발 PM의 주 업무로는 지금 보시는 이런 것들이 있겠죠. 총 여섯 가지인데, 이런 부분들이 사전에 먼저 준비가 되고, 그 다음에 나머지 업무들이 처리가 되어야 되지 않나, 라고 생각이 들고요. 그렇게 따졌을 때 저희 회사로 보면 초반의 헬키드, 헬키드는 제가 개발에 참여하지 않았고요. 처음에 저희 회사에서 스마트폰을 처음 냈을 때부터 지금까지, 쭉 일련의 변화들을 보면, 결론은, 제가 지금 여기 나와서 이렇게 말씀을 드릴 수 있는 이유도 저희가 이렇게 수행해 왔던 것들이 크게 잘못되지 않았구나, 라고 느끼기 때문에 이렇게 나와서 말씀을 드리게 되는 것 같고요. 결론은 개발 PM은 개인적으로는 게임 개발사에서의 개발 PM은 굉장히 매력적인 직업이라고 생각을 하고요. 지원하시는 분들이 별로 없으셔서 마음이 아프긴 합니다만, 게임의 시작과 끝을 지켜주는 그 기준과 심판은 게임 개발 PM밖에 할 수가 없거든요. 그리고 전체 작업의 A부터 Z까지를 망라해서 조율할 수 있는 능력 또한 게임 개발 PM만이 가질 수 있는 능력이라고 보고요. 그렇기 때문에 게임 개발 PM으로서의 자부심을 좀 가져도 좋지 않을까, 라고 생각이 듭니다. 여기까지입니다. 감사합니다.
TITLE	TITLE	TITLE	TITLE
TITLE	TITLE	TITLE	TITLE
전체보기
