주제: 전지적 참견 시점 - 게임개발 PM
강연자 : 안광섭 - 넥슨코리아 / NEXON KOREA
발표분야 : 프로덕션&운영 - 커리어
권장 대상 : 게임개발PM에 대해 궁금하거나 희망하는 학생, 현업자
난이도 : 사전지식 불필요 : 튜토리얼이나 개요 수준에서의 설명
[강연 주제] 우리는 어떠한 일을 진행하기 전에 계획을 세웁니다. 그 계획은 이루고자 하는 것에 비례해 거대해 집니다. 우린 이 계획을 지키기 위해 어떠한 노력을 할까요? 게임을 개발하는 것은 무척 재미있는 일이지만 매우 높은 복잡성을 가지고 있습니다. 이러한 게임 개발을 진행하는데 있어 우리는 모두 그럴듯한 계획을 세웁니다. 이 계획은 얼마나 잘 수행될까요? 본 세션에선 개발 일정관리부터 팀 내 커뮤니케이션, 로드 밸런싱, 동굴 속의 카나리아 등 다양한 역할을 수행하는 게임 개발PM 직무와 프로젝트를 달성하는 방법에 대해 이야기 합니다.
넥슨 왓스튜디오 소속의 안광섭 PM은 '이해봄'이라는 가명으로 인터넷상에서 여러 가지 다양한 활동을 전개해오고 있다. 24일부터 진행된 NDC 2019를 통해 이해봄 PM은 '전지적 참견 시점 - 게임개발 PM'이라는 주제로 게임 개발PM이 게임 개발 과정에서 어떤 역할을 하고 있는지, 또 주로 어떤 업무를 맡고 있는지에 대해 상세하게 설명하는 자리를 가졌다.
■ 일은 언제나 계획보다 늦게 끝난다? - 호프스테터의 법칙과 계획 오류
본격적인 강연에 들어가기 앞서, 이해봄 PM은 게임을 개발할 때 PM이 왜 필요한지에 대하여 호프스태터 법칙와 계획 오류에 대한 개념, 그리고 로저 뷸러의 연구를 사례로 설명을 시작했다.
호프스테터 법칙은 퓰리처상과 미국 국가도서상을 수상한 더글라스 리처드 호프스테터( Douglas Richard Hofstadter) 교수가 제창한 것으로, 쉽게 설명하면 '어떤 일을 마치는데 예상한 것보다 오랜 시간이 걸리는 현상'을 일컫는다.
그리고 같은 현상에 대해 심리학자이자 행동경제학자인 아모스 트버스키와 카너먼은 '계획오류'라는 이름을 붙였는데, 이들은 모두 그 사례로 호주 시드니의 오페라하우스를 꼽았다. 해당 오페라하우스를 처음 건축하기로 결정했을 때는 6년의 건축 기간과 7백만 달러의 건설 비용이 들 것으로 계획했지만, 완공까지는 16년이라는 기간과 1억 달러라는 비용이 들어갔다.
또 하나의 사례가 있다. 바로 캐나다의 심리학자 로저 뷸러와 그의 연구팀이 진행한 계획오류에 대한 실험이다. 로저 뷸러는 대학교 졸업반을 대상으로 한 실험을 통해 학생들에게 졸업논문을 작성할 때 소요되는 시간을 1)최선의 예상, 2) 낙관적 예상, 3)비관적 예상 총 세 가지로 적어 낼 것으로 과제로 주었는데, 정작 학생들은 자신들이 생각한 가장 비관적인 예상보다도 많은 시간을 졸업논문을 작성하는 데 사용했다.
로저 뷸러는 이와 같은 결과가 자신이 믿고 싶은 긍정적인 결과에 맞춰 생각하는 경향에 바탕을 둔다고 봤는데, 이는 계획 오류가 어떤 일의 성공 가능성을 지나치게 낙관하는 경향, 즉 낙관적 편향에 의한다고 이야기한 카너먼의 주장을 뒷받침하는 근거가 되었다.
이해봄 PM은 이처럼 한 프로젝트를 완성하는 데 계획한 시간보다 더 많은 시간이 소요되는 것은 게임을 개발할 때도 발생할 수밖에 없다고 이야기하며, 계획에 따라 게임을 완성하기 위해 팀을 돕는 것이 PM의 역할이라고 설명했다.
■ 프로젝트 매니저와 연예인 매니저 - 크게 다르지 않은 둘의 공통점
그렇다면 개발PM은 개발 단계에 있어 무슨 일을 할까? 이해봄 PM은 MBC의 예능 프로그램인 '전지적 참견 시점'을 언급하며 연예인 매니저와 프로젝트 매니저(PM) 사이에 유사한 점이 생각보다 많다고 전했다.
전지적 참견 시점은 연예인이 아닌, 연예인의 매니저를 조명하는 것으로 인기를 끌고 있는 예능 프로그램이다. 이해봄 PM은 "프로젝트 매니저라고 하면 무언가를 관리하는, '보스'같은 이미지로 생각하시는 분들이 많은데, 그보다는 연예인의 매니저에 가깝다고 생각한다"며, "연예인의 매니저가 연예인의 스케쥴을 관리하고, 새로운 프로그램을 잡고, 섭외 요청에 대응하기도 하듯, 프로젝트 매니저는 프로젝트의 스케쥴을 관리하고, 일감을 잡고, 추가 요청에 대응하게 된다"라고 설명했다.
다음으로 이해봄 PM은 개발 과정에서 PM의 역할에 대해 크게 네 가지로 분류해 설명했다. PM의 역할은 ▲디자인 및 기획 단계, ▲담당자 지정 및 개발 계획 수립 단계, ▲개발 진행 단계, ▲배포 및 후속 조치 단계에 따라 나뉜다는 것이 그의 설명이다.
[■ 디자인 및 기획 단계 ]
이 단계는 무엇을 만들까 하고 고민하는 단계로, 기획자나 게임 디자이너가 진행해야 하는 것이 있다면 PM은 그에 대한 명세서가 작성되어 있는지 확인해야 한다. 명세서는 기획서라고 해도 무방하다.
이때 PM으로서 확인해야 할 것은 디테일이 부족한 문서의 경우 개발에 참여하는 모든 파트가 이해할 수 있도록 구현하기 위해서는 많은 난항을 겪는다는 것이다. 개발 PM은 프로그래머 등 실무자들이 바로 작업에 투입될 수 있을 수준까지 문서가 작성될 수 있도록 디자이너 및 기획자에게 전달하는 역할을 한다.
또 중요한 것은 작업에 대한 우선순위를 배정하는 것이다. 이해봄PM은 게임에서 해결해야 할 이슈를 중요도 순서로 S,A,B,C 등급으로 배정한다고 했을 때, S등급은 해결되지 않으면 게임 진행이나 운영이 불가능한 이슈, A는 플레이에 지대한 지장을 주는 이슈, 또는 스노우볼링되서 일이 불어나는 이슈 등을 상정한다고 전했다. 이렇게 이슈별로 우선순위를 정하게 되면 추후 일감이 충돌할 때를 대비할 수 있는데, 물론 구성원들이 이슈별 우선순위에 대해 모호해하지 않도록 기준을 명확히 설정하는 것도 중요하다.
이렇게 문서들이 모이게 되면, 이해봄 PM은 이들을 구조화해서 어떤 작업들이 있는지 파악하기 쉽도록 하는 것이 좋다고 설명했다. 이와 함게 그는 WBS(Work Breakdown Structure)라고 불리는 구조에 대한 설명을 이어나갔다.
WBS를 쉽게 예를 들면 하나의 큰 피쳐(Feature)를 구성하고 있는 태스크(Task)와 그 하위 태스크들로 작업을 구분해두는 형식이다. 만약 게임에서 어린이날 이벤트를 준비해야 한다면 이벤트 자체가 피쳐가 되며, 이를 구성하는 어린이날 배너 및 이벤트 퀘스트가 태스크가 된다. 그리고 이벤트 퀘스트를 완성하기 위해 필요한 기획과 조립, 로직, 보상 등은 하위 태스크가 되는 셈이다.
이해봄 PM은 "이런 형태의 WBS 구조로 작업을 구분해 놓으면 작업 자체가 체크리스트가 될 수 있다. 또한 필요한 것들을 세부적으로 알아보기 쉬우며, QA단계까지 넘어갈 경우 이 자체를 Test Case로 활용할 수도 있다. 필요한 부분을 테스트해달라고 요청하기도 수월해지는 것이다"고 덧붙였다.
[■ 담당자 지정 및 개발 계획 수립 단계]
다음으로 이해봄 PM은 담당자를 지정하고, 개발 계획을 수립하는 단계에서 왓스튜디오는 '일감 회의'라는 것을 진행한다고 설명했다. 일감회의의 원칙은 '문서가 없는 일은 진행하지 않는다'가 원칙으로, 이는 문서를 통해 일의 규모를 파악할 수 있도록 하기 위함이다.
각 파트의 장들은 일감회의에 참석하기 전에 문서를 읽어본 뒤, 검토하는 과정에서 각 문서에 대한 작업일을 산정한다. 이후 일감회에서는 산정된 작업일을 배치해 확정하며, 추가적으로 기획자의 의도와 실무자가 이해한 것이 일치하는지 맞추는 과정도 함께 진행한다.
이해봄 PM은 이러한 과정에서 PM은 작업에 대한 완충일(버퍼)를 확보하는 역할을 한다고 전했다. 다음 PT 자료와 같이 A,B,C 작업을 10일 안에 완수해야 한다면 그 절반 정도를 완충일로서 확보한다는 것이다. 그는 "휴가를 갑자기 써야 한다든지, 건강상의 문제 등 버퍼의 이유는 생각보다 다양하다. 그렇기 때문에 절반 정도의 버퍼로 잡았다고 해도 작업일이 맞아떨어진 적은 많지만, 그 전에 작업이 끝나는 경우는 드물었다"고 전했다.
다시한번 이해봄 PM은 이러한 경우를 대비해 작업의 문서화를 강조했다. 문서화는 전체적인 커뮤니케이션 과정에서도 요긴하게 사용되며, 기술적 한계나 제한 사항을 명확히 판단하는 것과 변수를 줄이는 데도 도움이 되기 때문이다. 또한 게임이 출시된 이후 포스트모템 과정에서도 활용될 수 있다.
[■ 개발 진행 단계]
개발 진행 단계에 들어서게 되면, 모든 개발자들은 위에서 말한것처럼 희망적인 생각을 한다. 프로젝트가 안정적으로 진행되고, 버그도 나오지 않기를 희망하지만 현실은 엄연히 다르다. 이 단계에서는 PM들 또한 꼼꼼해지는 시점이 된다.
이해봄 PM은 개발 진행 단계에서 PM의 역할에 대해 크게 '체크하기'와 이삭 줍기로 나눌 수 있다고 말하며 설명을 이어나갔다.
▲ 체크하기
체크하기는 말 그대로 일감회의나 기획 단계에서 수립했던 계획이 잘 진행되고 있는지 체크하는 것이다. 다만 주의할 것이 있다면 작업자의 입장에서는 이러한 PM의 체크를 '감시'로 받아들일 경우가 있다는 것이다. 이해봄 PM은 작업자가 PM의 체크를 감시로 받아들이고, "다 잘되고 있다" 등 모호한 대답을 주고받다 보면 마일스톤의 끝에 다다라서 곤란해질 수 있다며 PM은 감시하는 것이 아니라 프로젝트를 완수할 수 있도록 길잡이 역할을 하고 있다는 것을 어필할 필요가 있다고 전했다.
▲이삭줍기
개발을 진행하다 보면 우선순위 경쟁에 밀려서 작업이 안 되는 일들이 존재할 수 있다. 또한, 기획자의 입장에서는 다 전달했다고 생각하고, 작업자의 입장에서는 다 했다고 생각해 아무도 챙기지 않게 되는 일도 생길 수 있다. 이해봄 PM은 이러한 작업들을 '이삭줍기'한 뒤, 다음 일감회의에서 상정하거나, 추후 업데이트에 언급하는 역할을 해야한다고 설명했다.
[■ 배포 및 후속조치]
이 단계는 그동안 어떤 작업이 어떤 순서로, 언제 진행됐는지에 대한 경과를 누구보다 더 잘 알고 있는 PM이 활약하는 단계다.
이해봄 PM은 과거 듀랑고에서 진행했던 벚꽃 이벤트를 사례로, WBS의 내용을 토대로 정리한 업데이트 내용을 운영팀에게 전달하면, 운영팀에서 유저들에게 더욱 친숙한 문장으로 업데이트 노트를 작성한다고 전했다. 중요한 것은 이러한 업데이트 노트의 초안도 PM이 작성한다는 것이다.
점검 또한 PM이 진행한다. 점검 공지가 제대로 배포되었는지, QA가 잘 끝났는지, 이후 공지가 제대로 나갔는지 확인하는 역할을 맡게 되며, 긴급점검에 대한 대처도 PM이 맡는다는 것이 이해봄 PM의 설명이다. 그렇다고 해서 모든 점검을 맡는다는 것은 아니다. 긴급점검에 필요한 인력을 모으고, 최대한 빠른 조치가 가능하도록 선도하는 역할을 한다는 의미다.
또한 이 단계에서는 각종 커뮤니티를 통해 올라오는 유저들의 반응이 운영팀을 통해 PM에게 많이 전달 되는 시기이기도 하다. 그러나 PM이 커뮤니티의 글 하나로 긴급 점검을 짤 수는 없기 때문에, 이해봄 PM은 직접 인프라 수치 등을 확인하거나, QA팀에 검증하는 등의 과정을 통해 현상을 확인한 뒤 작업자들에게 알려주는 것이 중요하다고 설명했다.
■ PM은 감시자가 아니라 결정을 돕는 사람- 게임개발 PM의 업무적 행동 4가지
개발 과정에서 PM의 역할을 설명한 이해봄 PM은 이어서 개발 PM의 업무적 행동에 대한 네가지를 설명하기 시작했다. 그에 따르면 개발 PM은 크게 ▲상기시키기, ▲분배하기, ▲전달하기, ▲결정하기 와 같은 업무를 통해 프로젝트를 완성하는 것을 돕는다.
▲ 상기시키기
게임이 개발에 들어가게 되면, 한가지 마일스톤에서 한 사람이 하나의 일만 하는 경우는 없다. 보통 한사람이 여러 가지 일을 맡게 되는데, 문서 뿐 아니라 구두로 전달받는 작업 사이에서 몇몇 작업을 놓치는 경우가 발생한다. 이럴 때 PM은 놓친 작업을 상기키는 역할을 하는 것이다.
WBS 구조 상에서 설명하면, PM은 각각의 태스크에 작업자가 배정이 되지 않은 것은 없는지, 또 시작일과 마감일이 제대로 적혀 있는지, 변동은 없는지 등의 사항을 꼼꼼치 체크하게 된다. 또 작업자가 해당 태스크를 맡았다는 것을 제대로 인지하고 있는지 확인하는 것도 중요하다. 이 경우 보통은 다양한 협업툴을 이용하면 어떤 인원에게 어떤 작업이 배정되어 있는지 보다 가시성 있게 전달하는 것이 가능하다.
▲ 분배하기
업무가 진행되다 보면 소위 '병목 현상'이 자주 발생했다. 개발 과정에서는 주로 러닝 코스트(Learning Cost)가 드는 경우가 대부분인데, 작업자가 배정받은 작업에 대해 파악하는 기간이 소요되면서 지연이 발생하는 경우다. 이해봄 PM은 이러한 경우 또한 PM이 먼저 파악하고 병목 현상을 해소하는 것이 중요하다고 설명했다.
▲ 전달하기
PM은 보통 "일정이 얼마 남지 않았다" 또는 "변경사항이 생겼다"와 같은 안좋은 메시지를 전달하는 역할을 하게 된다. 안좋은 일을 전달하고 싶은 사람은 없겠지만, 그럼에도 누군가는 말해야 하는 사항이기 때문이다.
하지만 이러한 전달에도 그 방법이 중요하다. 이해봄 PM은 "우리는 어떤 정보를 전달할 때, 빠르게 전달하는 것에 집중하는 경향이 있어서 밀도 낮은 정보를 전달하고는 한다. 그러나, 그냥 "계획이 바뀌었다"라고만 말한다면 전달받는 사람에게 혼란을 일으키게 된다"고 설명했다.
따라서, 계획이 변경됐음을 전달할 때에는 어떤 이유로 계획이 바뀌었고, 어던 식으로 바뀔 것인지 상대방이 파악할 수 있도록 전달하는 것이 중요하다.
▲ 결정 돕기
마지막 PM의 업무는 올바른 결정이 나오게끔 돕는 것이다. 이해봄 PM은 "PM은 엄청난 권한을 가진 상급자가 아니"라며, 어떻게 하면 빠르고, 최고의 결정이 나올 수 있게 도와주는 역할을 한다고 설명했다. 점검으로 예를 들면 필요한 추가 조치 사항 등등을 결정해 주는 것이 PM의 역할이라고 볼 수 있다.
이러한 결정이 가능한 이유는 PM이 기간 작업과정을 구조화해서 파악하는 위치에 있기 때문이다. 아이템 버그를 예로 들면 PM은 이번 마일스톤에서 아이템 생성 로직을 건드렸었는지, 그렇다면 관련 작업에는 어떤 것이 있었고, 그 담당자는 누구인지 빠르게 파악할 수 있다. 이후 해당 담당자에게 물어보게 되면 문제에 대한 접근을 보다 빠르게 할 수 있는 것이다.
■ 개발 PM이 되고 싶다면 - 다음과 같은 역량이 필요합니다
마지막으로 이해봄 PM은 개발 PM으로서 가져야할 역량 네 가지를 소개하며 강연을 마무리했다. 여기 해당하는 네 가지 역량은 각각 ▲맥락적 이해와 ▲새로운 지식 습득, ▲신뢰 주기 및 ▲타협하기다.
▲맥락적 이해
업무적 맥락은 기억에 의존하기 힘들다. 따라서 문서화하는 것이 매우 중요한데, 이해봄 PM은 왓스튜디오의 경우 자신의 일상을 기록하고, 이를 통해 어떤 문제를 개선했다고 하는 사례가 있다면 좋은 포트폴리오로 보고 있다고 전했다. 그 요지는 기록을 잘 남기고, 해당 기록을 통해 원인을 찾아낼 수 있느냐 하는 역량이다.
이해봄 PM은 원인을 찾는것 자체는 '왜?'라는 질문이 필요하고, 그 끝에는 항상 누군가를 탓할수 밖에 없기에 다들 망설이게 된다고 전했다. 그럼에도 불구하고 '왜?'라는 질문을 통해 원인에 다가가다 보면 좋은 결과가 나오는 경우가 많다는 것이다.
이와 관련한 이야기로 이해봄 PM은 경영학과에서 전해져 내려오는 토마스 제퍼슨 기념관에 대한 우화를 설명했다. 해당 우화는 기념관 벽과 바닥이 계속 부식되는 현상을 전등 타이머를 설치해 해결했다는 우화로, 원인을 찾아내 더 적은 비용으로 문제를 해결했다는 주제를 담고 있다.
▲ 새로운 지식 습득
PM은 다양한 직군의 전문가들과 함께 업무를 진행한다. 그만큼 모든 직군을 완벽히 이해하지는 못하더라도 어느정도 이해할 수는 있어야 한다는 것이 이해봄 PM의 설명이다.
그는 넓게 다양한 분야를 섭렵하는 제너럴리스트가 되기 위해서는 주변에 있는 스페셜리스트들에게 물어보는 것이 가장 좋은 방법이라며, "함께 프로젝트에서 일하는 분들은 적어도 해당 프로젝트에 있어서는 스페셜리스트나 다름이 없다. 기분들에게 항상 물어보고, 테스트 파일을 읽어보면서 공부하면 사례조사하는 자료가 될 수 있다"고 전했다. 언제나 궁금한 것이 있다면 물어보는 것이 중요하다.
▲ 신뢰 주기
"이번 일감은 이것이 전부입니다"와 같이 본의 아닌 거짓말(?)을 해야 하는 PM의 입장에서 작업자들에게 신뢰를 주는 것은 어려운 일이 아닐 수 없다. 이해봄 PM은 "믿음이 무너지는 단계는 약속을 지키지 않은 시점이 아니라, 그 뒤에 어떤 행동이 따랐느냐에 달렸다"며, 이후 대안책을 제공하는 것도 한가지 방법이 될 수 있다고 전했다.
▲ 타협하기
개발 프로세스를 어떻게든 완수해야하는 PM의 입장에서 타협은 다소 이상하게 들릴 수 있지만, 언제든 타협을 해야하는 시점은 생기게 마련인데, 이러한 상황이 되면 PM은 정성적인 역할을 통해 변경된 사항을 작업자들에게 전달하는 역할을 맡게 된다.
마지막으로 이해봄 PM은 3년간 개발 PM의 역할을 맡아오면서 느낀점에 대해 "이만큼 다양한 직군과 매일같이 이야기하며, 새로운 것을 배우는 직군은 없는 것 같다"며, "PM의 덕목으로는 잘 적고, 잘 정리하고, 잘 결정하자는 세가지를 가장 강조하고 싶다"고 이야기하며 강연을 마무리했다.
Frann@inven.co.kr