[NDC 2021] 게임 PD가 되어 보니
•Als PPTX, PDF herunterladen•
5 gefällt mir•1,800 views
저는 운 좋게도 게임 PD로서 지난 10년 동안 몇 개의 게임을 개발하고, 서비스하는 경험을 가질 수 있었습니다. 본 세션에서는 제가 그동안 개발했던 게임들을 간단히 돌아보고, 개발 과정에서 시행착오를 통해 배운 것들을 살펴보려고 합니다. 개인적인 경험이라 편향이 있을 수 있겠지만, 게임 PD나 디렉터 커리어를 목표로 하시는 분들께 참고가 될 수 있으면 좋겠습니다.
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie [NDC 2021] 게임 PD가 되어 보니
Ähnlich wie [NDC 2021] 게임 PD가 되어 보니 (20)
[NDC 2021] 게임 PD가 되어 보니
- 1. 게임 PD가 되어 보니 김용하 NATGAMES MX STUDIO PD
- 2. 2 닐 드럭만 사쿠라이 마사히로 김동건
- 3. 3 좋더라 게임 PD가 되어 보니
- 4. 4 좋더라 게임 PD가 되어 보니
- 5. 5 게임 PD가 되어 보니 PD가 되기 전에 알았다면 좋았을 것 실패를 통해 배운 것
- 6. 6 큐라레 마법도서관 포커스온유 블루아카이브 게임 개발 21년차 PD 발표자 소개
- 7. 7 PART #1 게임 PD가 하는 일 PART #2 커리어 포스트모템 PART #3 PD가 해야 하는 것 PART #4 PD가 하지 말아야 하는 것 PART #5 해보니 좋았던 것 PART #6 요약
- 8. 8 01 게임 PD가 하는 일
- 9. 9 개발 최종 의사 결정권을 가지고 완성과 서비스를 책임지는 사람 ⓒNDC 2013 이은석 - 게임 디렉터가 뭐하는 건가요 프로듀서 디렉터 저는 넥슨에서는 디렉터, 스마일게이트, 넷게임즈에서는 PD가 되더라고요 게임 PD : 게임 개발 책임자
- 10. 10 게임 PD : 게임 개발 책임자 개인적으로는 PD라고 쓰고 총괄 디렉터 / Project Director 로 읽는 것을 선호합니다 개발 인원 마이크로 컨트롤 디렉팅 개발 방향성과 / 우선 순위 결정
- 11. 11 보통 프로젝트의 시작점에 해당되지만, 중간에 개발 방침이 변경되거나 새로 PD가 되는 경우 게임 컨셉을 구체화하고 개발 비용을 추산하며 개발 달성방법을 제안한다 하는 일 1. 게임의 큰 그림을 구상하고 제안
- 12. 12 하는 일 1. 게임의 큰 그림을 구상하고 제안 게임의 핵심 컨셉
- 13. 13 하는 일 1. 게임의 큰 그림을 구상하고 제안 포커스온유 제안서에 실제로 사용했던 사진 핵심은 간결해야 함 지금까지 이런 수사는 없었다. 낮에는 치킨장사 밤에는 잠복근무. [극한직업 로그라인]
- 14. 14 하는 일 1. 게임의 큰 그림을 구상하고 제안 초면에 설득하기는 굉장히 힘들다 경영진과의 사전 교감이 선행되어야 함 사업 선례를 제시하는 편이 수월 - 리OO2에서 스킨을 SF로 바꾼 게임입니다. 코어 게이머들한테 호평 받은 OO 게임을 캐주얼하게 만들어 볼 거예요!
- 15. 15 하는 일 1. 게임의 큰 그림을 구상하고 제안 인원 기간 개발 비용 추산 미들웨어 비용이나 외주 비용 등도 포함 당연하게도 프로젝트의 예상 매출은 개발 비용보다 커야 합니다.
- 16. 16 하는 일 1. 게임의 큰 그림을 구상하고 제안 들게 될 비용은 항상 예상 보다 크다 비용을 과소평가하면 뜨거운 맛을 보게 됨 특히 초기 인원이 모자라지 않아야 프로젝트가 굴러갑니다. 뜨거운 맛의 예 ) 마감이 다가오지만 완성도는 떨어지고, 작업할 사람이 부족하고, 늘어난 개발 기간 만큼 기대는 높아지고, … ⓒ강철의 연금술사
- 17. 17 하는 일 1. 게임의 큰 그림을 구상하고 제안 개발 달성 방법을 어필 투입된 비용의 산출물을 볼 수 있는 각 단계 마일스톤 계획
- 18. 18 하는 일 1. 게임의 큰 그림을 구상하고 제안 기간별 산출물은 경영진과의 약속 달성하지 못하면 점수가 계속 깎임 대표님께서 항상 지켜 보고 계십니다! 이 내용은 [PD가 해야 하는 것 1]로 이어집니다. 마일스톤 개요의 예
- 19. 19 하는 일 1. 게임의 큰 그림을 구상하고 제안 요약 비용 컨셉 달성방법 가능한 한 명확해야 하며, 개발 기간 동안 꾸준히 명확해지는 모습을 보여야 합니다.
- 20. 20 하는 일 2. 게임의 주요 요소를 디렉팅 요 내용은 고대로 [PD가 해야 하는 것 2,3,1]로 이어지기 때문에 구체적인 설명은 스킵합니다. 동료를 적시에 충원하고 약속한 마일스톤 결과를 도출한다
- 21. 21 정리 : PD가 하는 일 게임의 큰 그림을 구상하고 제안하며 개발 과정을 감독하여 게임이 만들어지도록 한다. 밥 로스, 그림을 그립시다
- 22. 22 02 부끄럽지만 커리어 간단 리뷰
- 23. 23 개발 입문 ~ 팀장 Kingdom Under Fire (2000) Shining Lore (2002) Mabinogi (2004) Mabinogi Heroes (2010) 킹덤언더 파이어 샤이닝로어 마비노기 NDC를 만든 것이 가장 큰 성과 판타그램 ~ 넥슨 (1999~2011)
- 24. 24 개발 입문 ~ 팀장 좋았던 것 프로그래머에서 디렉터, NDC 기획과 리드, 직군장까지 다양한 테크를 타 봄 똘똘한 동료들과 다양한 조직 문화를 경험
- 25. 25 개발 입문 ~ 팀장 잘 하지 못한 것 마일스톤 완수보다 차별화에 집중 인력 충원 또한 보수적으로 하다 보니 정작 개발 일정 완수를 못했다
- 26. 26 개발 입문 ~ 팀장 교훈 1. 도전과제는 딱 하나만, 과하지 않게 2. 스스로의 약점 파악 : 나는 관리를 못해 PD의 약점은, 커버할 수 있는 동료가 곁에 있다면 보완할 수 있습니다.
- 27. 27 PD 입문 프로젝트 B6 아이덴티티 게임즈 (2011~2012) 풀스케일 MMORPG 좋은 동료들과 꽤 좋은 느낌으로 개발했으나 외부 환경 변화를 극복하지 못함 Project B6 Action Prototype ⓒ김용하
- 28. 28 PD 입문
- 29. 29 개발 입문 ~ 팀장 좋았던 것 ‘잘되는 개발’을 경험 리더십을 커버해주는 동료들이 있었음
- 30. 30 개발 입문 ~ 팀장 잘 하지 못한 것 개발 외적인 리스크를 과소평가했음
- 31. 31 PD 입문 교훈 경영 리스크 vs 전망 있는 투자 경영진과의 지속적인 공감대가 필요하다 마일스톤을 달성하고 PT를 잘해도 프로젝트는 드랍될 수 있습니다. 허들은 이미 나와 있는 결정을 확인하는 자리일 뿐.
- 32. 32 PD로 게임 첫 출시 ! 큐라레 마법도서관 스마일게이트 iO스튜디오 (2012~2017) 실시간 탱딜힐 멀티플레이 CCG
- 33. 33 PD로 게임 첫 출시 ! 좋았던 것 조직 세팅 ~ 출시 !!! ~ 라이브 서비스 처음에 생각했던 엣지를 어떻게든 구현 Inven 큐라레 마법도서관 인터뷰 레바 큐라레 콜라보
- 34. 34 PD로 게임 첫 출시 ! 잘 하지 못한 것 엣지 이외의 부분이 부실 서비스를 오래 지속시키지 못함 게임을 균형있게 개발하지 못한 탓
- 35. 35 PD로 게임 첫 출시 ! 교훈 장기 서비스할 기반을 갖추고 출시해야 함 적극적으로 위임하고 넓은 시야로 개발했어야
- 36. 36 PD로 가장 사심을 쏟았던 프로젝트 포커스온유 스마일게이트 (2017~2018) VR 코스프레 촬영 미연시 R&D ~ 스테이지 1까지 개발 Focus on you ⓒSmilegate
- 37. 37 좋았던 것 최초 의도(사심) 달성 캐릭터 상호작용으로 플레이어와의 거리감을 좁힘 PD로 가장 사심을 쏟았던 프로젝트 잘 하지 못한 것 완성하지 못하고 퇴직
- 38. 38 현재 PD를 맡고 있는 프로젝트 개발 초기에 작성한 비전PT 블루아카이브 모에 XCOM 넷게임즈 MX스튜디오 (2018~)
- 39. 39 03 PD가 해야 하는 것 잘하지 못하면 프로젝트가 산으로 가거나…
- 40. 40 PD가 해야 하는 것 경영진의 신뢰 획득 좋은 동료를 구하는 것 선택과 집중 01 02 03
- 41. 41 1. 경영진의 신뢰 획득 프로젝트가 수익을 낼 수 있는가? PD는 경영진의 확신을 유지해야 한다 기대 비용
- 42. 42 약속한 마일스톤 결과를 도출한다 1. 경영진의 신뢰 획득 약속한 개발 상세가 완성되도록 함 마일스톤에 R&D가 포함되어 있으면 뜨거운 맛을 보게 됨 팀이 커지면 애자일은 사실 잘 안된다 마일스톤을 길게 잡는 경우 조립과 폴리싱 기간을 고려 시행착오
- 43. 43 더 중요한 것은 프로젝트를 보는 경영진의 관점 1. 경영진의 신뢰 획득 프로젝트의 리스크 VS 프로젝트에 대한 기대치 시장의 변화, 경영 여건의 변화에 따라 경영진의 관점은 바뀔 수 있습니다.
- 44. 44 프로젝트 방향과 산출물이 경영 관점에 부합하고 있다는 꾸준한 컨센서스 허들은 계기일 뿐, 결과는 허들 전에 이미 나와 있습니다 1. 경영진의 신뢰 획득
- 45. 45 경영진이 바뀌는 경우라면 OTL 처음부터 다시 신뢰를 쌓아야 함 1. 경영진의 신뢰 획득 실제로는 창업하는 경우 외부 요인의 영향을 더 받게 됩니다
- 46. 46 게임의 품질을 결정하는 가장 중요한 요소 2. 좋은 동료를 구하는 것 만드는 사람 시간과 다른 비용은 퀄리티에 기여하는 효율이 떨어짐
- 47. 47 프리 프로덕션까지의 스타팅 멤버 방향을 정하고 조직을 리드하게 됨 처음부터 믿을 수 있는 동료들과 함께 할 수 있다면 제일 좋습니다만… 2. 좋은 동료를 구하는 것
- 48. 48 들어오는 이력서만으로는 한계가 있음 발로 뛰어 다니며 구해야 함 모든 방법을 동원 헤드 헌터, 지인 소개, 트위터, 페북, … 2. 좋은 동료를 구하는 것
- 49. 49 동료를 구하는 것만 잘 하면 PD 역할 절반은 한 것 이후엔 무임승차… ㅎㅎㅎ 2. 좋은 동료를 구하는 것
- 50. 50 제대로 동료들을 구했다면 PD가 중간에 빠져도 게임은 완성될 수 있다! 2. 좋은 동료를 구하는 것
- 51. 51 Ex) 기술적인 약점, 기획적인 약점, 관리적인 약점, 성격적인 약점, … 2. 좋은 동료를 구하는 것 PD 본인의 약점을 커버할 수 있는 동료
- 52. 52 게임 감독 / 디렉팅 무엇을 취하고 무엇을 버릴 것인가? 무엇을 게임의 핵심으로 끝까지 지킬 것인가? 3. 선택과 집중
- 53. 53 3. 선택과 집중 등장 캐릭터 수 전투의 룩 조작 요소 게임 플레이 컬렉션 게임이니까 캐릭터 많이 등장하는 근접 액션 만들기 빡셈 완전 자동 총격전은 심심함 전투 조작 요소를 넣으면 전략까지 복잡도를 높이기 힘들겠군 초기 블루아카이브 구상 과정 (단순화)
- 54. 54 3. 선택과 집중 가장 살려야 할 포인트에 집중 Pepe ⓒMatt Furie
- 56. 56 3. 선택과 집중 차별화하기 위한 선택 대부분은 합리적인 반대에 부딛침 하지만 PD는 필요하면 리스크를 져야 함
- 57. 57 3. 선택과 집중 반대를 극복하고 목표에 도달하기까지 많은 비용과 멘탈 에너지가 들어감 안되면 포기해야 할 때도 있지만 목표가 유효하다면 게임의 핵심 요소로 굳힐 수 있음
- 58. 58 3. 선택과 집중 선택한다는 것은 뭔가를 포기한다는 것 • • • • • • • •
- 59. 59 3. 선택과 집중 명랑한 세계관의 학생들이 전투에서는 갭모에 Bluearchive ⓒNatgames, Yostar
- 60. 60 3. 선택과 집중 멘탈 일정 VS 스타일 정합성 VS 리텐션 ARPU VS PD는 선택을 하고 책임을 진다 모든 선택에는 리스크가 있다 정답은 없지만, 왜 선택했는지에 대한 일관적인 논리와 주관이 필요합니다. 그리고 잘못된 선택을 했다면 빠르게 고백하고 수정해야 합니다.
- 61. 61 04 PD가 하지 말아야 하는 것 프로젝트를 망치는, 빠지기 쉬운 함정
- 62. 62 하지 말아야 할 것 일정의 낙관 마이크로 컨트롤 깨진 유리창 방치 01 02 03
- 63. 63 1. 일정의 낙관 Hofstadter's Law It always takes longer than you expect, even when you take into account Hofstadter's Law. 호프스태터의 법칙
- 64. 64 1. 일정의 낙관 몰리게 된다 번아웃 사기가 떨어진다 다음 일정에 영향
- 65. 65 1. 일정의 낙관 대처 품질 도달이 목표인 태스크는 본인이 크리티컬 패스를 책임져야 한다 주변 사람이 녹게 되니 케어 필요 관리 역량이 있는 동료를 본인보다 신뢰한다 매 일정마다 조직의 달성 역량을 재평가한다 쉬운 척도 : 몇 개를 만들 것인가, 몇 명이 만들 것인가
- 66. 66 2. 마이크로 컨트롤 조직이 커짐에 따라 품질도 PD가 컨트롤하기 보다는 위임 게임 요소 개별적인 품질보다 조립된 게임으로서의 방향성이 더 중요해짐
- 67. 67 2. 마이크로 컨트롤 PD 없이 점점 일이 잘 돌아가지 않게 됨 나쁜 징조
- 68. 68 2. 마이크로 컨트롤 대책 비전을 맞췄으면 디테일에서 손을 뗀다 PD가 없어도 실무가 돌아가야 정상 한 발 물러나서 게임 전체 방향성을 살핀다
- 69. 69 2. 마이크로 컨트롤
- 70. 70 3. 깨진 유리창 방치 깨진 유리창 하나를 방치해 두었더니 그 지점을 중심으로 범죄가 확산 사소한 무질서를 방치하면 점점 주변으로 무질서가 확산 되어감 Broken Window ⓒpaulsbarlow7
- 71. 71 3. 깨진 유리창 방치 조직간 엇박자 동료간 불화
- 72. 72 3. 깨진 유리창 방치 하지만, 방치하면 점점 고질적인 문제가 된다
- 73. 73 3. 깨진 유리창 방치 대책 관망 보다는 빠른 대응 인사팀과 상담 혹은 공론화
- 74. 74 05 해보니 좋았던 것 직무 수행에 도움이 되었던 것 두 가지
- 75. 75 1. 빠른 비전 확인 : 스테이지 1 유저에게 어필할 수 있는 게임의 핵심 요소들을 플레이할 수 있는 형태로 확인 스테이지 1 : 게임 핵심 요소를 보여주는 완결된 스테이지
- 76. 76 1. 빠른 비전 확인 : 스테이지 1 Focus on you 첫번째 스테이지 게임 플레이 ⓒ배돈 TV (유튜브)
- 77. 77 블루아카이브 프로토타이핑 과정 1. 빠른 비전 확인 : 스테이지 1
- 78. 78 1. 빠른 비전 확인 : 스테이지 1 명랑한 세계관의 학생들이 전투에서는 갭모에
- 79. 79 1. 빠른 비전 확인 : 스테이지 1 찡! 게이머 센서가 반응하는 순간 이런 징조들을 빠르게 확인하고, 더해갈 수 있으면 길을 잃지 않는데 큰 도움이 됨 이를 찾기 위한 스테이지 1
- 80. 80 2. 지속적인 메시지 전파 왜 시작했고 무엇을 만들고 있으며 어떻게 만들어 갈 것인지 조직 내외에 꾸준히 전달
- 81. 81 2. 지속적인 메시지 전파 PD가 진행하는 주간 브리핑 같은 것도 좋은 방법 텍스트만으로는 집중도가 떨어지므로 비주얼 중심으로 구성하는 것을 추천
- 82. 82 2. 지속적인 메시지 전파 많은 인원이 참가하는 작업이나 오래 걸리는 작업의 경우 방향성을 알리는 PT를 따로 준비
- 83. 83 2. 지속적인 메시지 전파 개발 회의마다 회의록 작성하고 전체 공개
- 84. 84 06 요약
- 85. 85 게임 컨셉을 구체화하고 개발 비용을 추산하며 개발 달성방법을 제안한다 동료를 적시에 충원하고 약속한 마일스톤 결과를 도출한다 개발 PD가 하는 일
- 86. 86 함정에 빠지지 마세요 팁 드립니다 스테이지 1 PD 주간 브리핑
- 87. 87 화수분 같은 에너지 흔들리지 않는 멘탈
- 88. Thank you for your attention.
Hinweis der Redaktion
- 넷게임즈 MX 스튜디오에서 PD를 맡고 있는 김용하입니다. 프로젝트 관리나 개발 방법론에 대한 발표는 종종 봤던 것 같은데 PD 관점에서의 애환이랄까, 시행착오에 대한 발표는 잘 없더라고요. 그래서 준비해 봤습니다. 이 발표에서는 ‘게임 PD가 되어 보니’ 라는 제목으로, PD 직무에 대한 리뷰를 해보려고 합니다. 어쩌면 굉장히 개인적인 경험담이 될지도 모르겠네요. PD에 대해 이렇게 생각해볼 수도 있구나 정도로 봐주시면 좋을 것 같습니다.
- 발표할 용기를 얻기 위해 제가 존경하는 개발 PD 분들 사진을 모셔 봤습니다. 유명한 분들이니 굳이 설명을 하지는 않겠습니다. 게임 개발 책임자, PD, 총괄 디렉터라고 하면, 아마 대부분 위와 같은 분들을 떠올리실 거예요. 개발자 크레딧에서 제일 앞에 등장하시는 분들이죠. ‘나도 나중엔 저렇게 되고 싶다…’ 그런 꿈을 가지고 업계에 들어왔습니다. 아 물론 제가 어렸을 적 버전의 존경하던 분들은 조금 달랐지만요.
- 게임 업계에 들어오고도 세월이 꽤 지나 나름 어찌어찌 하다 보니 제가 PD가 되었더라고요. 게임 개발 PD… 머리속에 그리던 게임이 실체화 되고, 플레이어 분들이 즐겁게 플레이하시는 반응을 볼 때는 많은 보람을 느끼죠. 뭔가를 남겼다는 성취감도 있고요. 좋아하는 성우의 싸인을 얻는다거나 하는 서프라이즈 이벤트도 생길 수 있죠.
- 하지만! 제가 요령이 없었던 건지 개발하는 동안, 라이브 서비스 하는 동안의 상당 부분은 ‘진짜 이 고생까지 해야 되나..’ 했던 기억이 많네요. ‘PD가 되어 오래오래 행복하게 살았답니다’ 같은 엔딩은 오지 않았어요. 참고로 좋아하는 코스플레이어와 결혼을 했지만, 꼬꼬마 개발자 때 일이니까 이것도 PD와는 상관 없는 거였어요!
- 저는 상당히 많은 시행착오를 했기 때문에.. PD 커리어를 고려하시는 다른 분들께 ‘이런 건 알고 계시면 좋을 거예요.’ 같은, 지금 생각해보면 조금 꼰대같은 세션을 준비하게 됐습니다. 이 발표에서는 제가 PD를 하며 겪었던 시행착오들을 말씀 드리고, 여기서 나름대로 얻은 교훈을 정리해 보려고 해요. 프로젝트 제안에서 출시 까지를 다룹니다.
- 제 소개를 간단히 하겠습니다. 저는 20세기에 프로그래머로 업계에 들어온 21년차 개발자입니다. 최근에 PD를 맡은, 그리고 출시된 게임은 큐라레, 포커스온유, 블루아카이브가 있습니다. 어째 장르랄까 그림체의 벡터가 편중되어 있는 것 처럼 보이는 것은 오해고요. MMORPG나 액션 같은 장르도 개발했어요. 출시까지 가지 못했지만… 후후
- 자, 이 세션은 이런 순서로 진행됩니다. PD가 하는 일이 뭔지 설명 드리고, 제 PD 커리어를 간단히 포스트모템 하겠습니다. 이를 통해 깨달은, PD가 잘 해야하는 것, 절대 하지 말아야 하는 것 그리고 해보니 좋았던 것을 차례로 설명 드릴거예요.
- 첫번째 챕터, 게임 PD가 하는 일입니다. PD가 하는 일에 대해 얘기하려면, PD가 뭔지 정의를 해야 할텐데요.
- 프로듀서 이 사이 어딘가 디렉터 이 내용은 2013년 이은석 디렉터님이 NDC에서 발표하셨던 자료에 잘 정리되어 있습니다. 한 페이지만 가져와 봤는데요. 짧게 줄여서 말하면, PD는 게임 개발 책임자, 의사결정권을 가지고, 완성을 책임지는 사람이라고 할 수 있을 것 같습니다. 한국에서는 개발책임자 직함으로 디렉터, 총괄 디렉터, PD, 프로듀서가 막 혼용되어 쓰이고 있는데요. 이게 엄밀하게 나누기 힘들 때가 많아요. 제가 하는 역할을 살펴봐도, 프로듀서와 디렉터 사이 어딘가에 있는 것 같은데요. 실제 직함을 봐도 넷게임즈에는 PD인데, 넥슨에 보내는 문서 기준으로는 디렉터가 되더라고요.
- 개인적으로는 PD라고 쓰고 총괄 디렉터 / Project Director 로 읽는 것을 선호합니다 왜 이렇게 혼재되어 쓰이는가 하면, 프로젝트의 개발 인원에 따라 개발 책임자의 관점이 달라지기 때문입니다. 소규모 팀일 때는 직접 코딩을 하고 테이블 값을 다루는 수준으로 실무를 하다가, 규모가 어느 이상이 되면 점점 더 큰 단위의 작업으로 관점을 바꾸게 되거든요. 즉, 개발 인원이 30명 내외인 초기 단계에서는 디렉터, 이후로 인원이 늘어나면 점점 프로듀서에 가까워지는 거죠. 개인적으로는… 저는 관리만 전념하는 것 보다 개발 실무자이고 싶은 에고가 있어서인지 PD를 프로듀서 보다는 총괄 디렉터로 해석하는걸 선호합니다. 각설하고요.
- 개발책임자인 PD가 하는 일을 말씀드리면, 첫번째는 개발 제안입니다. 어디로 가겠다는 깃발을 꼽는 일이죠. 여기서부터 프로젝트가 시작됩니다. 제안에는 구체적인 게임 컨셉, 개발에 필요한 비용, 그리고 단계별 달성 방법이 포함되어야 합니다. 이걸 각각 구체적으로 설명해볼게요.
- 게임의 핵심 컨셉 먼저 컨셉. 제안에서 가장 중요한 부분은 어떤 게임을 만들 것인가 입니다. 이게 참 힘들어요. 세상에 없는 게임을 말로 설명하고 설득해야 되니까요. 그래서 다양한 설명을 붙이고 장표를 만들고 하게 되는데요.
- 핵심은 간결해야 함 ‘한 두 문장으로 줄이기’(logline) 같은 테크닉도 있고, 그림 혹은 사진 한 두 장으로 설명할 수도 있다 결정적인 한 페이지로 게임의 핵심을 어필할 수 있는가가 중요한 것 같습니다. 내용을 한 두 문장으로 요약한 것을 로그라인이라고 하는데, 헐리우드에서 각본을 투자자들한테 피칭할 때 많이 쓰는 기법이라고 하더라고요. 예를 들면 이런 거죠. ‘지금까지 이런 수사는 없었다. 낮에는 치킨장사 밤에는 잠복근무.’ 어떤 영화의 로그라인 일까요? 보신 분들은 금방 아실 것 같은데..극한직업 입니다. 게임 컨셉도 이렇게 한 두 문장으로 와 닫을 수 있는 핵심 컨셉이 있으면 좋다는 건데요. 꼭 이대로 문장으로만 할 필요는 없습니다. 게임에서는 키 비주얼을 만들거나 가상 스샷을 만들어 보거나 하는 방법도 많이 쓰입니다. 오른쪽에 있는 사진은, 포커스온유 제안서에 넣었던 건데요. 예전에 코스프레 사진 찍었던 경험을 살려서 VR 미연시를 만들겠습니다. 했던 것이 어필이 되더라고요. 민망함을 감수하고 PT에 넣었습니다.. 물론 제안서에 달랑 저것만 있었던 것은 아니고 R&D했던 게임플레이 영상도 있었습니다만. 저런 사진 같은게 있으면 필살기로 쓸 수 있죠.
- 초면에 설득하기는 굉장히 힘들다 경영진과의 사전 교감이 선행되어야 함 사업 선례를 제시하는 편이 수월 - 리OO2에서 스킨을 SF로 바꾼 게임입니다. 하지만 항상 필살기를 준비할 수 있는 건 아니죠. 현업에서는 핵심 기획을 짠 하고 PT해서 OK 받는 것 보다는 경영진과 지속적인 미팅을 하면서 빌드업하는 경우가 많습니다. 경영진이 시장을 보는 관점을 파악하고, 사업 선례를 통해 설명하는 편이 보다 설득력을 가질 수 있습니다. “모모 MMORPG의 BM을 기반으로 SF 비주얼의 게임을 만들겠습니다“ 이렇게 말할 수 있으면 설명하기 쉽죠. 그렇게 쉽게 설명할 수 있는게 아니라면 경영진과의 미팅 기간 동안, R&D나 프로토타이핑을 통해 어느 정도의 형태를 갖추고 제안하는 편이 좋습니다.
- 개발 비용 추산 제안에서 두번째로 챙겨야 하는 부분은 비용입니다. 비용의 대부분은 인건비와 그 부대 비용이기 떄문에, 간단히 말하면 인원 X 기간이 될텐데요. 이건 클 수록 리스크가 되겠죠. 엔진 비용이나 외주 비용도 포함 시켜야 하고요 그리고 너무 당연한 얘기지만 매출 목표는 이 비용보다 커야 합니다!
- 들게 될 비용은 항상 예상 보다 크다 비용을 과소평가하면 뜨거운 맛을 보게 됨 목표를 세울 때는 행복회로를 태우게 되지만, 치러야 할 비용은… 리스크이기 때문에, 아무래도 보수적으로 추산하게 되는 것이 인지 상정입니다. 하지만 세상은 등가 교환 아니겠습니까. 들아가는 비용, 특히 초기 인력은 모자라지 않게 설정해야 프로젝트가 정상적으로 굴러갈 수 있습니다. 비용을 타이트하게 잡으면 계속 뜨거운 맛을 보면서 멘탈이 깎이게 됩니다. 저는 인력은 지를 수 있는 한도까지 제안서에 적어 보시는 걸 추천합니다. 나중에 깎이더라도 일단 질러 보세요.
- 그리고 보통 제안서의 마지막에는 마일스톤 계획이 들어 갑니다. 개발 산출물을 확인하는 단위가 마일스톤인데요. 산출물은 플레이어블한게 가장 좋고, 이게 여의치 않으면 영상이나 리소스 이미지 등으로 갈음하게 됩니다.
- 기간별 산출물은 경영진과의 약속 달성하지 못하면 점수가 계속 깎임 마일스톤은 개발 방법론을 다룬 자료에서 많이 보셨을 프리프로덕션이니 알파니 하는 단계 별로 끊는데. PD 입장에서 보면, 숙제 검사 받는 타이밍이라.. 아무래도 각 검사 기간을 길게 잡고 싶어지죠. 업계 표준(?)은 3~6개월 정도인데요. 실제로는 꾸준히 자잘하게 경영진에게 보여 줄 기회를 만들 수 있으면 좋습니다. 오랫 동안 어필이 안된 상황에서 덜컥 크리티컬한 지적이 나오면 아주 곤란해지거든요. 이건 뒤에 나올, PD가 해야 하는 것 1번과 이어지는 내용입니다.
- 단어로 요약하면, 컨셉과 비용과 달성방법이라고 할 수 있겠네요. 프로젝트가 시작되면, PD는 이것이 계획대로 실체화되는 것을 꾸준히 증명해야 합니다. 그것이 바로 PD가 하는 일 두 번째인데요.
- 바로 계획대로 게임을 완성하는 거죠. 동료를 적시에 충원하고, 게임 요소를 감독해서 약속한 대로 마일스톤 결과를 낸다. 그리고 출시를 한다.. 이 챕터에서는 각각 따로 설명 하지 않겠습니다.. 뒤에 [나올 PD가 해야하는 것]에서 고대로 다시 얘기할 내용이거든요. 요 페이지만으로 넘어 갈게요.
- PD가 하는 일을 한 문장으로 정리하면 이렇게 되네요. 게임의 큰 그림을 구상하고 제안하며 개발과정을 감독하여 게임이 만들어지도록 한다. 이렇게 적으니 되게 간단하네. 하지만 저는 이걸 잘 못해서 그 고생을… 아.. 그래서..
- 제가 그동안 개발했던 프로젝트들을 살펴보겠습니다. 경험했던 시행착오에 대해 먼저 말씀드리는 것이 좋을 것 같아서요. 이건 리뷰보다는 포스트모템에 가깝겠네요.
- 제가 게임업계에 들어온 건 1999년 말이었어요. 판타그램이라는 회사에서 킹덤언더파이어 라는 RTS를 만들고 있었는데, 거기서 게임 로직 프로그래머로 업계에 입문을 했고요. 샤이닝로어 개발 이후에는 2002년 넥슨에 입사해서 마비노기팀과 마영전 팀에 프로그래머를 했어요. 총 10년이 넘는 기간 동안 팀장, 디렉터로 개발했던 프로젝트가 몇 개 있었지만, 부끄럽게도 중간에 모두 드랍 되어서 출시할 수 없었습니다. 이 기간에 제가 성공적으로 만들어냈다고 말할 수 있는 건 NDC 정도네요. 2007년 첫 NDC부터 2010년 NDC까지 행사를 기획하고 주재했었습니다. NDC는 게임은 아니었지만요 ㅋ
- 어쨌든, 이 기간 동안 좋았던 것은 다양한 조직에서 별의 별 테크를 타봤다는 거네요. 프로그래머도 하고 기획도 하고, 직군장으로 입사 문제도 내고 면접관도 많이 해봤고, 게임 디렉팅 경험도 얻었어요. 돌아보면 많이 미숙했었는데, 당시 같이 일했던 동료들에게 아직도 미안합니다.
- 마일스톤 완수보다 차별화에 집중 인력 충원 또한 보수적으로 하다 보니 정작 개발 일정 완수를 못했다 결국 디렉팅한, 함께 만들던 게임을 출시하지 못했으니까요. 당시 기획이나 기술 목표를 돌아보면, 상당히 도전적인 것들을 많이 시도했어요. 15년 전이었는데요. 퀘스트 자동 생성이라던가, 자동으로 동기화되는 네트워크 오브젝트라던가, 캐릭터 치마에 지글본이 아니라 천 물리를 도입하고, Spherical Harmonic lightin을 쓰고 막.. 게임 자체에 집중했어야 하는데 너무 무리수를 뒀어! 이게 돌아가긴 하는데, 기존 방법보다 딱히 좋은 티가 안나는 거예요. 새로운 시도를 하더라도 작작 했어야지, 가성비를 뽑는데 실패한거죠. 그런데서 힘을 빼다 보니 정작 컨텐츠 진도를 못 뽑고, 일정 완수를 못하니 드랍될 수 밖에요.. 뼈아프다.
- 도전과제는 딱 하나만, 과하지 않게 스스로의 약점 파악 : 나는 관리를 못해 그래서 얻은 교훈은 첫번째로, 게임에 새로운 시도는 가성비 따져서 딱 하나만 해야겠다. 였습니다. 기획하다보면, 게임에 막 새로운 거 넣고 싶어지잖아요. 하나 하나 파다 보면, 게임 개발 진도는 제자리 걸음이더라고요. 물론 이건 제 포스트모템에서의 얘기고, 조직마다, 사람마다 캐파가 다를 수는 있겠습니다. 두번째는, 스스로에 대한 객관적인 시각입니다. ‘나는 관리는 잘 못하는구나.’ 일정 관리나 업무 분장 관리, 조직 멘탈 관리 같은 거는 제가 소질이 없더라고요. 아니 조직 관리를 잘 못하는데 PD를 할 수 있나요? 동료를 통해 보완하고, 그만큼 본인 강점을 살릴 수 있다면 가능합니다. 그래서 저의 경우는 PM이나 관리 능력에 강점이 있는 동료가 바로 옆에 있는 편입니다
- 풀스케일 MMORPG 좋은 동료들과 꽤 좋은 느낌으로 개발했으나 외부 환경 변화를 극복하지 못함 이상의 교훈을 얻고서 PD로서 본격적인 개발을 시작했던 것이 아이덴티티에서 개발한 프로젝트 B6였습니다. 영웅전 크리에이티브 디렉터였던 이상균 디렉터, 지금은 넷이즈에 있는 김덕영 디렉터, 인디씬에서 최고로 잘나가는 한대훈 대표 등 당시 조직은 거의 올스타팀이었고, 결과물도 굉장히 잘나왔어요. 1년만에 서로 다른 방향성의 프로토타입을 두 개 만들었고.. 둘 다 그럴듯했어! 그럼에도 불구하고 드랍됐습니다. 어느새 회사의 방향성에 맞지 않는 프로젝트가 됐더라고요...
- 마지막으로 만들었던 액션 프로토타입 영상을 가져와봤습니다. 복수의 적들을 상대하는데, 공격을 막고 꺾고 잡아서 벽에 던지는 액션을 실현한 것이 특징이었습니다. 서버 클라이언트 환경에서요! 참고로, 당시 작업물의 권한은 모두 제가 양도 받았기 때문에 저작권 문제는 없습니다.
- ‘잘되는 개발’을 경험 리더십을 커버해주는 동료들이 있었음 프로젝트가 드랍되긴 했지만, 유능한 동료들과 시너지효과를 낼 수 있는 개발이 어떻게 돌아가는지를 이 때 알았습니다. 앞서 제가 관리 능력이 약점이라고 했습니다만, 당시 동료들은 제 부족한 리더십을 보완할 수 있는 분들이었어요. 목표를 명확하게 잡고, 욕심을 덜어내고, 일정 대로 목표를 완수하는 개발을 했던 것이, 벌써 10년 지났지만 아직도 좋은 기억으로 남아 있네요.
- 개발 외적인 리스크를 과소평가했음 문제는 개발 외적인 환경 변화에 선제적으로 대처하지 못했다는 거였어요. 당시 회사의 경영진이 바뀌었고, 신규 프로젝트 투자 여력이 줄고 있었는데, 그럼에도 저는 개발 진도만 잘 뽑으면 되는 거라고 생각했어요. 순진했달까, 안이했던 거죠. 사실 지금 돌아봐도 이런 상황은 풀기 어려운 문제라고 생각하는데요, 더 긴밀하게 경영진과 관점을 맞추고 교감을 했다면 다른 결과가 있지 않았을까 하는 아쉬움이 남습니다.
- 경영 리스크 vs 전망 있는 투자 경영진과의 지속적인 공감대가 필요하다 여기서 얻은 교훈은, 게임 개발이라는 것이 회사 입장에서는 사업 투자에 속하는 것인 만큼, 경영진의 투자 관점에 부합하는지 끊임없이 확인해봐야 한다는 것입니다. 투자에 충분한 이유가 있고, 그 이상의 가치를 만들 수 있다는 공감대가 있어야 하죠. 이 때 생긴 지론입니다만, 개발 허들 자리에서 PT만으로 프로젝트 드랍이 결정되지 않습니다. 허들은 이미 난 결정을 확인하는 자리일 뿐입니다.
- 그 다음 프로젝트가 큐라레 마법도서관이었습니다. PC MMORPG를 더 만들 생각이 들지 않아서, 모바일로 전향했어요. 확산성밀리언아서를 한동안 굉장히 재미있게 했었거든요. 캐릭터 컬렉션 게임을 만들되, 본인이 가진 캐릭터 덱을 써서 다른 플레이어들과 실시간 협력 전투를 할 수 있도록 하면 MMORPG의 레이드 하는 느낌으로 재미있을 것 같다고 생각해서 시작한 프로젝트입니다. 2012년 말에 개발에 들어가서 2014년 3월에 출시했고, 4년 동안 서비스했던 게임이예요.
- 조직 세팅 ~ 출시 !!! ~ 라이브 서비스 처음에 생각했던 엣지를 어떻게든 구현 좋았던 것! 그렇게 만든 게임은 실제로 재미가 있었습니다! 처음에 생각했던 것 보다 좀 마니악한 게임플레이가 되어 버렸지만요. 출시하고 4년이나 서비스할 수 있었어요. 플레이어분들의 과분한 사람도 받았습니다. 서비스하는 동안 123시간 점검 같은 정말 다양한 우여곡절을 겪었는데, 이건 여백이 모자라니 넘어가도록 하죠.
- 엣지 이외의 부분이 부실 서비스를 오래 지속시키지 못함 게임을 균형있게 개발하지 못한 탓 하지만 게임을 더 오래 서비스하지 못한 것이 가장 큰 아쉬움으로 남습니다. 처음에 생각했던 엣지는 어떻게든 구현을 했지만, 장기적으로 서비스할 수 있는 성장 기반과 플랜을 갖추지 못하고 출시를 했어요. 그리고, 그 원인으로는 엣지 뿐 아니라 게임의 전반적인 기능 요소들을 균형있게 개발하지 못했던 것이 컸던 것 같습니다.
- 그래서 얻은 교훈, 제안서에서야 엣지의 어필이 중요하지만, 출시하려면 중장기 서비스 플랜을 갖추고 출시해야겠구나. PD가 엣지만 파고 있을게 아니라, 더 큰 시야에서 게임의 형태를 잡았어야 했구나. 그러려면 좀 일찍 업무를 나누고 위임할걸 그랬네.. 많은 생각이 들었죠.
- 큐라레 직후에 사실 모바일 프로젝트를 하나 더 진행했습니다만, 당시는 뭘 만드는 것이 좋을지 확신을 갖지 못해 자진 드랍했었고요. 그래서 진짜 명확한 관점이랄까, 사심을 가지고 시작한 프로젝트가 포커스온유였습니다 코스프레 사진 찍던 경험을 살려서 촬영 게임플레이가 중심인 VR 미연시를 만든다는 걸 허락해 주셨던 당시 경영진에 감사 드리고 싶습니다. VR은 처음이라, 개발 들어가기 전에 선행 R&D에서 시행착오를 했었지만, 막판에 이렇게 하면 되겠다는 감이 왔어요. 그렇게 만들었던 첫번째 스테이지 데모가 워낙 호평이었기에, 이후에는 탄탄대로… 일 것 같았습니다만, 개인 사정상 이후 개발을 이어가지 못하고 도중에 퇴직하게 됐네요. 그래도 끝까지 남아서 게임을 완성시킨 동료분들께 감사 드립니다.
- 좋았던 것 : 미연시로서는 VR에서 나름 의미 있는 결과물을 냈다고 생각합니다. 혹시 여건이 되시는 분은 플레이해보시면 좋겠네요. 아쉬운 점은, 제 손으로 출시를 하지 못한 점이었네요.
- 그리고 커리어에서의 현재 지점입니다만, 블루아카이브라는 게임의 PD를 맡아 게임을 출시하고 서비스를 이어 오고 있습니다. 이 게임은, 미소녀 엑스컴을 만들면 재미있겠다는 지점으로부터 구체화된 게임인데요. 결과물을 보고 이게 무슨 엑스컴이야 라고 하실 수도 있겠지만, 제 관념적으로는 엑스컴에서 시작된 게임이었고, 저는 의도대로 게임이 만들어졌다고 생각합니다. 요 내용은 뒤에 [선택과 집중] 편에서 다시 얘기할게요.
- PD가 여러가지 잘 할 수 있으면 좋죠. 기술적으로 강점을 가진 PD가 있고, 아트에 강점을 가진 PD, 기획에 강점이 있는 PD 등.. 커리어에 따라 강점이 있는 분야는 다들 다를 거라고 생각합니다. 하지만 제가 생각했을 때, 제일 중요한 것들. 잘 하지 못하면 프로젝트가 산으로 가거나 드랍될 수 있는 것들을 꼽아보려고 합니다.
- 큰 제목을 먼저 살펴 볼게요. 첫번째는 경영진의 신뢰를 얻는 것 두번째는 좋은 동료를 구하는 것 세번째는 선택과 집중입니다. 중요하다고 생각하는 순서대로 적어봤습니다. 사실 이것은 앞서 PD가 하는 일이라고 말했던 것, 동료를 적시에 충원하고, 게임 요소를 감독하여, 약속한 마일스톤 결과를 도출한다. 이것의 조금 다른 버전이라고 할 수 있는데요. 순서 대로 설명 드리겠습니다.
- 첫번째는 경영진의 신뢰입니다. 앞서, 프로젝트를 제안할 때 비용 추산이 꼭 필요하다고 말씀드렸는데요. 회사 입장에서 보면, 개발 프로젝트가 그 이상의 수익을 낼 수 있다는 기대를 가지고 프로젝트를 시작하는 것이죠. 개발이 시작되면 시간에 따라 이 비용은 자동적으로 꼬박꼬박 적립됩니다. 자비가 없어요. PD는 이 비용이 가치가 있다는 증명을 해서 꾸준히 회사의 기대치를 유지할 필요가 있습니다.
- 약속한 개발 상세가 완성되도록 함 마일스톤에 R&D가 포함되어 있으면 뜨거운 맛을 보게 됨 그러려면 말했듯, 계획했던 마일스톤을 차근차근 달성해낼 필요가 있습니다. 계획대로 게임 개발! 이게 사실 참 어렵죠. 특히나 마일스톤을 타이트하게 잡았다면 말이죠. 여기서 제가 경력이 부족했던 시절에 가장 뼈저리게 얻은 교훈이 있는데요. R&D라고 적고 시행착오라고 읽는 그것이 마일스톤에 포함되면, 특히 그것이 마일스톤의 주 달성 목표가 되면 굉장히 힘들어진다는 점입니다. 게임이 다 정해져 있는 기획과 구현 레퍼런스에 따라, 리소스만 양산해서 완성하는 거라면, 마일스톤 달성이 그나마 용이할텐데, 뭔가 새로운 것을 넣고 싶어 지잖아요? 그럼 그 마감 일정을 생각대로 정하기가 쉽지 않습니다. 제 경우는 R&D가 필요한 부분은 프로젝트 제안서 쓰기 전에 미리 해두거나, 시행착오를 고려해서 프리프로덕션 기간을 충분히 준비해 두거나.. (사실 이게 쉽지 않지만요) 마일스톤 목표에서의 우선순위를 낮추어 진행하는게 낫더라고요. 우선순위를 낮춘다는 건, 잘 안되면 포기할 수 있는 요소로 간주하는 거예요. 퇴로가 있어야 합니다. 개발 마일스톤을 어떤 식으로 나누고, 결과를 내기 위해 어떤 프로세스를 쓰느냐.. 까지는, 발표 범위를 벗어나므로 자세히 설명하지 않겠습니다만, 어쨌든 PD는 온갖 잡일을 포함하여 마감을 지키고, 약속했던 대로 마일스톤 결과물을 만들어 내야만 합니다.
- 더 중요한 것은 프로젝트를 보는 경영진의 관점 그런데 이 챕터의 내용은 마일스톤 달성이 아니라 경영진의 신뢰잖아요. 왜일까요? 실제로는 마일스톤을 “계획대로” 진행하는 것 만으로 충분하지 않더라고요. 사실 더 중요하게 챙겨야 하는 것이 있습니다. 바로 프로젝트를 보는 경영진의 관점입니다. 다른 말로는 비전이라고도 할 수 있을 것 같은데요, 이것이 프로젝트 처음 시작했을 때와, 그 1,2년 후가 다를 수 있다는 것입니다. 경영진의 관점이 달라진다면? 그럼 프로젝트를 평가하는 기준도 달라질 수가 있는 거죠. 평가 기준이 달라진다면 기존에 계획했던 대로의 마일스톤 달성은 의미가 없어질 수 있습니다. 그렇기 때문에 PD는 경영진의 관점을 민감하게 확인할 필요가 있습니다. 경영 관점에서 프로젝트에 리스크라고 생각하는 것이 있을지, 만들고 있는 것이 회사가 바라고 있는 방향에 맞는지 말이죠.
- 프로젝트 방향과 산출물이 경영 관점에 부합하고 있다는 꾸준한 컨센서스 (허들은 계기일 뿐, 결과는 허들 전에 이미 나와 있습니다) 만약 회사의 경영 관점과 프로젝트가 나가는 방향이 어긋난 상황이라면, 마일스톤을 진행함에 따라 감점이 누적되다가 어느 순간 심판의 날이 오게 됩니다. 마일스톤 결과를 평가하는 자리를 허들이라고 하죠. 무슨무슨 프로젝트가 회사 허들을 통과하지 못하고 드랍됐다는 얘기 들어보신 적이 있으실 텐데요. 실제로는 프로젝트의 드랍 여부는 허들에서의 PT 한 번을 잘 못했다고 결정되지는 않습니다. 감점이 누적된 결과인 거죠. 따라서, PD는 프로젝트 방향이 경영 관점에 맞는지, 지금의 득점을 하고 있는지 감점을 받고 있는지를 계속 피드백 받고, 필요하다면 기존 마일스톤 계획을 적극적으로 수정해야 합니다. 정기적으로 직접 경영진을 만나서 물어보고, 확인하고 어필하는 자리를 가져야 합니다.
- 최고 난이도는 경영진, PD 바로 위의 본부장님이나 대표님, 이사님이 새로 오시는 경우인데요. 이게 2년 3년 개발하다 보면 한 번은 경험할 수 있습니다. 이 때는 제안서를 새로 쓰는 느낌으로 신뢰를 다시 구축해야 해요. 프로젝트를 책임지는 PD의 가장 중요한 업무입니다! 물론, PD 자신이 대표이사면 이런 문제는 없겠습니다만, 대신에 더 큰 문제, 개발 비용 조달과 운용, 투자자들과의 관계 같은 것들을 신경 써야겠죠.
- 게임의 퀄리티를 결정하는 가장 중요한 요소 = 만드는 사람 PD가 잘 해야하는 것 두번째는 인재 등용! 바로 프로젝트를 함께할 동료를 구하는 것입니다. PD의 업무라고 앞서 “동료의 적시 충원”을 얘기했습니다만, 마일스톤 마다 기획자 몇 명, 프로그래머 몇 명, 아트 몇 명… 이렇게 충원한다고 계획을 하죠. 단순히 이 숫자를 채우기만 하는 건 의미가 없습니다. “좋은 동료”, 프로젝트를 캐리할 수 있는 동료를 구해야죠. 게임의 품질, 완성도, 재미 같은 걸 좌우하는 요소가 뭘까 생각해 보면요. 게임 엔진? 충분한 개발 기간? 개발 프로세스? 이런 것들도 퀄리티에 기여하는 부분이 있지만, 결국은 맨파워가 핵심입니다. 앞서의 경영진과의 신뢰 관계 구축이 프로젝트가 생존하기 위한 기본기라고 하면, 게임이 어느 정도의 품질로 만들어질까는 전적으로, 얼마나 좋은 동료와 일할 수 있느냐에 달려 있습니다.
- 프리 프로덕션까지의 스타팅 멤버 게임의 방향을 정하고 프로젝트를 리드 특히 프로젝트의 초기 멤버가 중요한데요, 이 분들과 함께 개발 방향을 정하고, 이 분들이 이후의 리드를 맡게 되고 대부분의 경우 그대로 프로젝트 끝까지 가기 때문입니다. 제일 좋은 건 처음부터 믿을 수 있는 동료들과 함께 시작하는 거겠지만, 프로그램, 아트, 기획.. 파트별로 다 갖춰서 형편 좋게 시작할 수 있는 기회는 거의 없더라구요.
- 그럼 PD는 어떻게든 좋은 동료를 구해 와야겠죠. 담담하게 얘기하면 뭐 어떻게든 할 수 있는 것 아닌가.. 싶을 수 있겠지만 이게 굉장히 어렵습니다. 회사에 들어오는 이력서만으로 리드급 멤버를 뽑을 수 있을까요? 솔직히, 이건 회사마다 차이가 크더라고요. 확실히 큰 회사의 어드밴티지가 있습니다. 이런 어드밴티지를 누리기 힘들다면, 발로 뛰는 수 밖에 없습니다. 보이는 친구들마다 소개팅 좀 시켜 달라고 졸랐던 때가 있으셨을지 모르겠는데요. 그보다도 훨씬 더 절실하게 구인을 하게 됩니다. 갑자기 다른 PD분한테서 연락 오면 보통 이런 쪽이예요. ‘이러저러한 프로젝트인데 TD 좀 소개시켜줄 수 있나요, 괜찮은 AD 없을까요.’ 그러면 ‘저도 구하고 있어요 소개시켜 주세요’ 라고 반사를 시전하는데… 뭐 이건 농담이지만.. 정말 모든 방법을 동원합니다. 포폴 같은 것 볼 수 있는 사이트를 순회하거나 구인하는 직군의 커뮤니티에 들어가서 스캔하고 구인 포스팅 올리기도 하고, 이런 저런 분들 연락 드리고 직접 찾아 뵈어야죠. 저는 사실 내향적인 성격이라 이런 영업 활동(?)은 맞지 않는다고 생각했는데.. 정말 절실하면 하게 되더라고요.
- 동료를 구하는 것만 잘 하면 PD 역할 절반은 한 것 그렇게 까지 구인에 신경을 써야 하는 이유는, 다시 말씀드리지만, 결국 게임 품질을 결정하는 것은 동료들이기 때문입니다. 이것만 잘할 수 있다면 PD 역할의 절반은 한 거라고 볼 수 있죠. 이후엔 동료들이 알아서 잘 만들어 주니 개발에 무임승차… 까지는 아니더라도, 안정적으로 개발 파이프라인이 돌아가게 됩니다.
- 제대로 동료들을 구했다면 PD가 중간에 빠져도 게임은 완성될 수 있다! 실제로 포커스온유의 경우, 스샷에 보이는 스테이지 1까지의 개발은 제가 주도했다고 말할 수 있지만, 직후에 제가 퇴직했는데도 남은 분들이 출시까지 잘 마무리 하시더라고요. 이제 그 분들의 게임이죠. 나 필요 없었나? 하는 현타도 좀 있었는데요.. 결국 게임을 채우고 완성하는 것은 동료들인 것입니다.
- 좋은 동료를 말할 때, 한가지 첨언하고 싶은 것이 있는데요. PD도 인간인 만큼 모든 걸 잘 할 수는 없습니다. 각자 강점과 약점이 있죠. 그런데 PD의 약점은 프로젝트 전체의 리스크가 될 수 있습니다. 따라서 PD는 이를 커버해줄 수 있는 동료를 가까이에 두어야 합니다. 약점은 기술적인 것일 수도 있고, 기획적인 것일 수도 있고, 성격적인 부분일 수도 있습니다. 예를 들면… 좀 개인적인 얘기가 되겠지만, 저는 좀 내향적인 성격이라, 외향적인 커뮤니케이션을 하는 동료가 주기적으로 태클을 걸어 주는 편이 조직에는 좋았고, 제가 부족한 관리적인 부분을 챙겨줄 수 있는 동료가 꼭 필요하더라고요. 특정 직군, 특정 포지션을 충원하는 것도 중요하지만, PD 본인의 약점을 알고, 이를 보완할 동료도 중요하다는 말씀을 드리고 싶었습니다.
- PD가 잘 해야 하는 것, 마지막은 선택과 집중입니다. PD가 게임 요소를 감독한다고 말씀 드렸는데요. 감독이라는 것은 결국 계속되는 선택과 집중이라고 볼 수 있을 것 같습니다. 머리속에 있었던 게임을 실체화 하기 위해서 무엇을 취하고 무엇을 버릴까. 이것을 반복해서 무엇이 이 게임의 핵심인가를 정하고 지켜 나가는 거죠.
- 구체적으로, 블루아카이브를 처음에 기획할 때의 선택 과정을 좀 많이 단순화 해서 가져와 봤습니다. 먼저 차세대 캐릭터 컬렉션 게임을 어떻게 만들까 생각했습니다. 화면에 등장할 캐릭터를 어느 정도로 할까? 많이 보여주자. 컬렉션 게임이니까. 전투 방식은 그럼 총격전으로 해야겠네, 캐릭터가 많이 등장하는데 근접 액션까지 하면 정신 없겠고, 리소스 비용도 많이 들 것 같어. 대신 전투 조작 요소는 어느 정도 필요해지겠네. 총격전을 완전 자동으로 하는 게임, 구체적으로 말하면 소녀전선 같은게 이미 있고, 그대로 만들 수는 없잖아. 그럼 개별 전투를 어느 정도 시간을 써서 플레이 하도록 해야 할테고, 소녀전선 처럼 전략맵을 크고 복잡하게 만드는 식의 레벨링은 못하겠구만. 그래도 전략맵은 있으면 좋겠어. … 이렇게 보니까 명확한 결정 과정 처럼 보이는데, 실제로는 각 단계마다 많은 논의를 하고 처음부터 다시 생각하고를 반복했습니다.
- ‘그럼 미소녀 엑스컴같이 만들면 되겠네! 모에 엑스컴. 그러니까 우리 스튜디오 이름은 MX다’ 라고 어느날 피디는 알수 없는 말을 했습니다. 그게 어떻게 엑스컴이 되는데? 동료들은 물었습니다. 대체 뭘 어떻게 만들고 싶은 걸까요. 피디는 엑스컴에 대한 이런 저런 얘기를 하며 다양하게 페이퍼 프로토타이핑을 해보자고 했습니다. 그렇게 다시 선택의 고통이 시작되었죠. 실화입니다.
- 이렇게 해보면 어떨까 하는 니즈 별로 다양한 프로토타이핑, 가상 스샷 작업을 진행했습니다. 이 중에서 결국은 선택을 해야 하는데요. 이 과정에서 뭘 우선 순위에 두고 게임을 만들 것인가를 정하게 됐습니다.
- 이 과정이 즐겁지만은 않은데요, 정답이 없는 선택들의 결과를 결국 PD가 책임져야 하기 때문이죠. 나름의 논리에 기반해서 선택을 하는데요, 그런데 여기에 남들이 해본 적이 없는 선택지가 있다면 정말 고르기 까다롭습니다. 그걸 하면 안되는 백 가지 합리적인 이유를 듣게 됩니다. 쉬운 길은 그런 선택지를 안만드는 거긴 한데.. 저는 PD라면 한 두개 정도는 그런 걸 차별화 포인트를 살려야 한다고 생각하는 편이라서 힘든 지점이 생기더라고요. 그래도 꼭 필요하다면, 선택 해야죠. 리스크를 지더라도 결과를 만들어 내는게 PD의 역할이라고 생각합니다.
- 반대를 극복하고 목표에 도달하기까지 많은 비용과 멘탈 에너지가 들어감 안되면 포기해야 할 때도 있지만 목표가 유효하다면 게임의 핵심 요소로 굳힐 수 있음 그리고 PD는 그 선택지가 유효하다는 것을 증명하기 위해, 정말 많은 에너지를 쏟을 필요가 있습니다. 사실 잘 안돼요. 어느 이상 안되면 포기하거나 돌아가야 됩니다. 이렇게 해보면 될 것 같은데를 n 번 하다 보면 길을 잃고 헤매게 되니까요. 어디까지 해본다는 선은 확실히 그어 둘 필요가 있습니다. 다행히 그런 시도 중에 선택지가 유효해서 살릴 수 있다는 결론이 난다면, 게임의 핵심요소로 가져갈 수 있겠죠.
- 그리고, 선택한다는 것은 결국 다른 것을 포기한다는 것입니다. 블루아카이브의 경우는 전투에서 캐릭터가 매력적으로 보이는 것을 최우선 순위에 두었고, 이에 딸린 요소로 은엄폐 하며 이동하는 전투를 선택했습니다. 다른 것들은 어느 정도 타협을 하기로 했죠. 실제 선택 과정은 많이 복잡했습니다만 많이 단순화 시켰구요. 처음에 생각했던 캐릭터가 많이 나오는 반자동 총격전에 이 요소를 더해서…
- ‘모에 엑스컴’이라는 것의 최종 개념도는 이렇게 정리가 되었습니다. 실시간으로 파티 캐릭터들이 지속적으로 은엄폐 전진하면서 총격전을 하는 게임인거죠. 캐릭터 수와 화각을 고려하면 6등신을 포기하고 SD로 가야 했고요, 캐릭터 스킬은 직접 사용하되, 캐릭터 이동은 자동으로 진행되도록 할 수밖에 없겠다고 선택했습니다. 당시 이것이 최선의 선택이었는지는 모르겠습니다만, 지금 돌아봐도 다행히 크게 틀린 선택은 아니었던 것 같아요.
- 블루아카이브 초기의 선택에 대한 예를 들어봤습니다만, PD는 프로젝트 내내 다양한 선택을 하고 책임을 집니다. 게임이 어떻게 실체화 될 지 뿐만 아니라, 무엇을 우선하는 조직을 만들지, 일정을 우선할지 멘탈 케어를 할지, 비주얼에서 스타일을 추구할지 정합성을 추구할지, … 정답은 없죠. 하지만 왜 그런 선택을 하는지에 대한 PD의 주관과 논리는 일관되게 유지할 필요가 있습니다. 그리고 선택이 틀릴 수 있는데, 이 경우는 빠른 고백과 수정이 필요합니다. 고백이라고 했는데, 잘못된 길을 따라온 동료들에게 미안하기 때문입니다.
- 다음으로, PD가 하면 안되는 것들, PD가 빠지기 쉬운 함정에 대해서 얘기해 볼게요.
- 첫번째는 일정을 낙관하는 것 두번째는 마이크로 컨트롤 세번쨰는 깨진 유리창을 방치하는 것입니다. 여기서부터는 조금 빨리 진행하겠습니다. 왜냐면, 이건 너무 당연한 것 아닌가? 나만 잘못했던 것이 아닌가? 하는 기분이 들거든요.
- 먼저 일정인데요. 호프스태터의 법칙이라는 것이 있습니다. 일정보다 늦어질 것을 고려해도 여전히 일정보다 시간이 더 걸린다. 그만큼 일정을 정확히 추산하기 힘들다는 얘기죠. 비관적으로 추산해도 늦어지는 것이 순리인데, 사실 PD 입장에서 마일스톤을 늘어놓고 보면 낙관적으로 추산하고 싶어 집니다. 행복회로 돌리는 거죠. 그렇게 낙관적으로 추산하면 어떻게 될까요.
- 마감 막판에 일이 몰리게 되고, 동료들이 번아웃 되는 것을 실시간으로 볼 수 있습니다. 허덕이며 마감을 하다가 원래 목표를 채우지 못하면 팀 사기가 떨어지고, 이 번아웃과 사기 저하는 다음 일정에 영향을 주게 됩니다. 그렇게 악순환이 계속되는 거죠.
- 대처 방법은… 일정을 비관적으로 추산하자도 있겠지만, 구체적으로 몇 가지를 얘기해볼게요. PD가 게임 요소, 예를 들어 ‘타격감’이라는 것을 설정하고 그 품질 목표를 직접 설정했다면, 본인이 그 목표를 달성하는 과정을 디테일하게 챙겨야 합니다. 어떻게 조정해야 그 목표를 달성할 지는 PD만 판단할 수 있는데, 이 피드백이 느려지면 일정을 지킬 수 없기 때문입니다. 대신 이 과정에서 담당자들의 업무 부하가 높아지게 되므로, 별도의 케어를 할 필요가 있습니다. 그리고, PD가 각 일정의 목표를 우격다짐으로 설정할 것이 아니라, PM 과 같은 동료의 현실적인 피드백에 기반해서 설정해야 합니다. 매 일정마다 얼마나 갈 수 있었는지를 측정해서 다음 일정 계획에 고려하는 것으로 피드백의 정밀도를 높일 수 있습니다.
- 조직이 커짐에 따라 (대략 30명 넘어가면서) 품질도 PD가 컨트롤하기 보다는 위임 게임 요소 개별적인 품질보다 조립된 게임으로서의 방향성이 더 중요해짐 PD가 하지 말아야 할 것, 두번째는 마이크로 컨트롤입니다. 바로 전 페이지에서 품질은 직접 챙겨야 한다고 얘기했는데 바로 말을 뒤집네? 라고 하실 수도 있을텐데요. 개발 초기에 PD가 강점을 가지고 있는 부분을 직접 챙기는 것, 예를 들어 ‘타격감’이라는 것을 위해 필요하면 코드를 작성하고, 테이블을 고치면서 직접 결과물을 컨트롤하는 것은 개발 진행에 도움이 될 수 있습니다. 하지만, 조직이 커지고 게임 개발 진도가 나가면서 챙겨야 할 게임 요소들이 늘어나면 PD는 판단 권한을 위임해야 합니다. 개별 요소의 품질보다 조립된 게임으로서의 방향성이 더 중요해지기 때문이죠.
- PD가 개별 요소의 품질에 현혹되어 계속 챙기다 보면 담당 실무자는 점점 스스로 판단하지 못하고, 판단하지 않으려 함 PD 없이 점점 일이 잘 돌아가지 않게 됨 그런데 위임이 쉽지만은 않은데요. 예를 들어, PD가 직접 챙기는 게임 요소… 앞서 ‘타격감’을 들었습니다만, 이걸 타이밍이던 이펙트던 직접 튜닝해서 괜찮은 결과물을 내다 보면 PD 본인이 더 챙기고 싶은 생각이 들 수 있습니다. 이건 내가 챙겨야 돼.. 이런 상황이 되면, ‘타격감’을 실제로 챙겨야 할 담당자, 기획자가 될 수도 있고 이펙터가 될 수도 있겠습니다만, 그 분들은 스스로 ‘타격감’이라는 것을 판단하지 못하고, 또 판단하지 않으려고 하게 되면서 PD 없이 ‘타격감‘ 과 관련된 개발 요소는 돌아가지 않게 되는 위임하기 더 어려워지는 악순환이 생길 수 있는 거죠. 이거 손을 떼도 될까 걱정이 됩니다.
- 하지만 사실은, PD가 없어도 잘 돌아갑니다. PD가 생각한 품질 목표가 ‘타격감‘ 이라는 것이 뭔지는 한 번만 맞춰보면 됩니다. 손을 떼고 위임을 하는 편이 결과물이 더 잘 나오는 것이 정상이구요. PD가 들어가는 실무 회의도 점점 줄여야 합니다. 블루아카이브도 처음에 기획 회의 전부 들어가다가, 프로덕션 단계 들어가니깐 기획 실장 아저씨가 ‘PD님 이제 회의 다 들어오는 건 그만하세요.’ 라고 해서 아쉬웠었는데요. 하지만 그게 맞죠. 프로젝트 진도가 나갈때마다 한발씩 뒤로 물러서면서 게임을 전체적인 방향성을 살펴야 합니다.
- 방향을 잘 잡았고 위임이 되어 있다면, 개발 중간에 PD가 빠져도 게임은 출시될 수 있는 것입니다.
- PD가 하지 말아야 할 것, 세번째는 깨진 유리창을 방치하는 것입니다. 개진 유리창 하나를 방치해 두는 것 만으로 그 지점을 중심으로 범죄가 확산된다는 이론이 있는데요. 사소한 무질서라도 방치하는 경우 무질서가 확산된다는 거죠. 반론도 있긴 하지만 저는 이 얘기가 개발에서도 새겨볼 필요가 있다고 생각합니다.
- 프로젝트가 1년이 넘어가면 조직에 취약점이 조금씩 생기게 되는데요. 방치하다 악화되는 경우를 몇 번 경험했거든요. 업무적인 문제면 문제를 발견하고 해결하는 것이 비교적 용이하겠지만 사람들 사이의 문제가 가장 어려운 것 같습니다. 크게 나눠서 보면, 조직간 업무 방식과 이해 관계가 충돌하거나 서로 엇박자가 계속되는 경우. 그리고 구성원 사이에서 불화가 생기는 경우를 들어볼 수 있을 것 같습니다.
- 여러 명이 엮여 있어 조심스러움 말하면 더 문제가 될 것 같음 하지만, 방치하면 점점 고질적인 문제가 된다 이런 것들은 문제를 발견하는 것도 어렵고, 말하는 것도 조심스럽고. 그래서 일단 좀 더 두고 보자 하게되는 경우도 많은데요. 그대로 방치하면 점점 고질적인 문제가 되어서 조직 전체의 리스크가 될 수 있습니다. 언제 부터인가 동료들이 말없이 하나 둘씩 나가는 거죠. 그러기 전에 조치를 취해야 합니다.
- 제가 둔감해서 그런지 몰라도, 제 생각에 이거 걱정 해야 되나.. 생각이 들 정도면 이미 많이 진행된 거더라고요. 빠른 대응이 필요합니다. 기본적으로는 면담입니다만, 내부에서만 끙끙댈 것이 아니라 인사팀과 상의하는 편이 더 부드럽게 진행되는 경우가 많더라고요. 인사팀은 조직내에서 해결하기 힘든 경우에 대한 옵션을 가지고 있습니다.
- 마지막 파트, PD로서 해보니 좋았던 것 두 가지를 꼽아 보려고 합니다.
- 유저에게 어필할 수 있는 게임의 비전을 플레이할 수 있는 형태로 확인 첫번째는 스테이지 1의 제작입니다. 여기서 스테이지 1이란 게임의 핵심 요소를 플레이해볼 수 있는 하나의 완결된 스테이지를 얘기하는데요. 이 스테이지 1을 빠르게 개발하고 플레이해보는 것이 이후 개발에 큰 도움이 되었습니다.
- 유튜버가 플레이한 포커스온유의 스테이지1 내용 일부를 잠깐 틀어봤는데요. 음성인식을 통한 캐릭터와의 커뮤니케이션, 이건 직접 플레이해봐야 알 수 있는 부분입니다만, 플레이어에게 접근해오는 캐릭터의 실재감, 메인 게임 플레이인 사진 촬영 등이 들어 있죠. 개발 당시 이 스테이지 1이 동작하는 빌드를 뽑으면서 개발팀 스스로도 이렇게 하면 되겠구나 하는 확신을 얻을 수 있었습니다. 이걸로 허들을 넘었는데, 이후에 여러 곳에서 플레이해보겠다고 찾아 오시더라고요.
- 이건 블루아카이브의 스테이지 1을 만들기 전 프로토타이핑인데요. 앞서 보셨던 상상도를 실제로 게임으로 구현해보는 과정입니다. 뷰를 바꿔 본다거나, 적들 타입을 어떻게 할 지, 엄폐물을 어떻게 배치하고 사용할 지 같은 테스트를 다양하게 했습니다.
- 이 테스트 결과를 다듬고, 비주얼 노림수를 넣어서 2018년 연말에 스테이지 1을 완성했습니다. 비주얼이 짧은 기간임에도 괜찮게 뽑혔고, 실시간으로 파티 캐릭터들이 은엄폐 전진하며 총격전을 하는 게임이라는 플레이 컨셉이 잘 표현이 되어서 굉장히 만족한 빌드입니다. 사실 이 영상은 뒤에 더 멋진 부분이 있는데, 이후 개발의 스포가 될 것 같아서 적당히 커트했네요. 여튼, 이 빌드 덕분에 스튜디오 내외부에 어떤 게임을 만들 것이라는 비전 공유가 확실히 됐어요.
- 게임 빌드를 조립하고 테스트하다 보면 ‘이건 되겠는데?’ 하는 느낌이 찡! 하고 올 때가 있는데요. 예전에 재미있게 했던 게임들에서 경험했던 것과 비슷한 흥분이나 신선함을 내가 만든 게임에서 느끼게 되면 정말 신나죠. PD가 개발에서 선택을 하고 책임을 지는 것이 중요하다고 말씀드렸는데요. 그 결과로 이런 긍정적인 경험을 할 수 있다면 개발하는 게임에 더 확신을 가지고 앞으로 나갈 수 있습니다. 그래서 저는 가능한한 빠르게 선택을 하고, 빠르게 스테이지 1에 해당하는 결과를 만들어 보시기를 권하고 싶습니다.
- 두번째로 좋았던 것은 꾸준한 조직내 메시지 전파입니다. 왜 이 프로젝트를 시작했고, 무엇을 지금 만들고 있으며, 앞으로 어떻게 만들어 갈 것인지. PD는 알고 있습니다만, 동료들 모두가 같은 온도로 인식하고 있지는 않으니까요.
- 구체적인 예를 들면, 저희 스튜디오에서는 전원을 대상으로 매주 월요일 오전에 주간 리뷰 PT를 진행하고 있습니다. 지난주에 우리가 뭘 했고, 이번주 주안점은 무엇이고… 그런 내용인데요. 텍스트가 많으면 집중도가 떨어지기 때문에, 아트 결과물 위주로 정보를 배치하고 텍스트가 필요한 부분은, 중요한 공유 사항 위주로 요약해서 전달하고 있습니다.
- 특정 토픽 위주로 담당자들 사이에서 공유해야 할 사항은 별도로 공유하는 자료를 만들고 있습니다. 이 부분은 저희 AD님이 워낙 잘 해주고 계신데요. 이 타이밍에 잠깐 광고 하자면, 이번 NDC에 저희 AD님이 블루아카이브 아트디렉팅에 대해 녹화하신 세션도 있으니 그것도 꼭 보시면 좋을 것 같습니다.
- 그리고, 저희 조직의 경우 회의 내용, 특히 기획 회의는 모두 원노트에 기록하고 검색할 수 있도록 하고 있습니다. 개발 히스토리 검색할 때, 누가 어떤 과정으로 어떤 결정을 내렸는지 추적할 수 있는게 굉장히 유용하더라고요. 또, 너무 기본적인 내용이고 어디서나 쓰고 계실 것 같아서 따로 페이지를 만들지는 않았습니다만 Slack도 적극적으로 사용하고 있습니다. 취미 생활별 채널까지 포함하면, 저희 스튜디오 인원보다 개설된 채널 수가 더 많더라고요. 물론 개발 스튜디오마다 분위기는 다를 수 있겠습니다만, 저의 경우는 꾸준히 전체 브리핑을 하고, 개발 내역을 공유하는 것이 팀웍을 다지는데 큰 도움이 되고 있다고 판단하고 있습니다.
- 세션을 마무리 하는 페이지가 왔네요.
- 개발 PD는 게임 컨셉을 구체화 하고 실현에 드는 비용을 추산하며 달성할 수 있는 방법을 제안합니다. 제가 게임 한번 개발해보겠습니다. 라고 말을 꺼내는 사람이고요. 제안이 통과되면 동료를 충원해서 개발 감독을 하고 약속한 대로 결과를 만들어 내야 합니다. 말을 꺼냈던 대로 게임의 완성까지를 책임져야 하는 사람입니다. 이 과정에서 PD가 꼭 챙겨야 할 중요한 것은 경영진 눈치를 잘 살펴야 하고 TO 내에서 가급적 비싼 인재를 구하는게 좋고 포기하면 편하다는 것입니다 농담처럼 얘기했지만, 앞에 설명 드렸던 내용을 다시 보시면요.. 같은 내용입니다.
- 그리고 PD라고 쓰고 김용하라고 읽게 되는데, 제가 여러 번 빠졌던 함정을 알려 드렸습니다. 일정은 고집 부리지 말고 PM의 판결을 신뢰하시고요. PD가 실무에 집착하지 않는 것이 프로젝트에 이득입니다. 그리고, 조직 내에서 감정적으로 충돌이 생길만한 이슈가 감지되면 즉각 조치하세요. 마지막으로 팁 두 가지. 만들고 있는 게임의 핵심 차별화 요소는, 조립된 게임의 형태로 최대한 빠르게 확인해 보시길 바랍니다. 고되지만 주간 브리핑을 꾸준히 진행하면 조직 얼라인에 크게 도움이 됩니다.
- 아마 이 세션을 보고 계신 분들은 대부분 게임 PD 혹은 디렉터를 지망하고 계시거나 이제 막 그런 직무를 시작하신 분들일 거라고 생각합니다. 게임 PD가 되어 보니, ‘이렇게 까지 해야 하나…’ 하는 순간을 많이 겪게 되더라고요. 게임 개발 프로젝트가 진행되도록 하는데 생각보다 많은 에너지가 필요하고요. 멘탈이 시시때때로 시험에 들게 됩니다. 하지만, 그런 어려움을 넘기고 게임을 낼 수 있다면, 그 이상의 성취감을 느낄 수 있는 직무라고 생각합니다. 부족하나마 제 경험담이 여러분께 도움이 되었으면 합니다. 끝까지 봐주셔서 감사합니다.