현업(게임) 시스템 기획자의 실무 노트

안녕하세요. '호랭이 물어갈 기획놈들' 입니다. 지난 기획 실무 시리즈에서 클라이언트, 서버, QA 파트와의 피 튀기는 전쟁을 다루었지만, 정작 게임의 첫인상을 결정짓는 '아트 파트(원화, 3D 모델링, 애니메이션, 이펙트, UI/UX)' 와의 협업 이야기는 깊게 다루지 않았습니다. 혹시 이전 글들을 보시고 "아트는 그냥 기획서 대충 넘겨도 알아서 그려주나? 그냥 '고풍스러운 빨간색' 같은 뜬구름 잡는 소리만 안 하면 되는 거 아닌가?" 라고 오해하셨을 수도 있습니다. 제가 지난 글에서 아트 파트의 비중을 줄였던 진짜 이유가 있습니다. 보통 신입이나 주니어 기획자가 어설픈 발주서를 들고 가도, 아트 파트의 실무자분들이 기획서의 빈틈을 알아서 찰떡같이 채워주며 상당히 관대하고 원만하게 작업을 진행해 주시는 경우가 많기 때문입니다. 하지만 진짜 치명적인 문제는 바로 여기서 발생합니다. 이렇게 아트 팀에서 원만하게 기획의 구멍을 메워주다 보니, 신입/주니어 기획자들은 어느 순간 아트 작업자들을 내 머릿속을 꿰뚫어 보는 '독심술사' 로 착각하는 오만에 빠지게 됩니다. 그래서 오늘은 17년 차 현업 기획자의 시선에서, 이런 치명적인 착각을 부수고 아트 팀과 소통할 때 절대 잊지 말아야 할 '3가지 실무 유의점' 을 뼈 때리게 해부해 드립니다. '기획 의도'를 명확하게 설명하십시오 연출이나 UI가 포함된 기획서를 쓸 때, 신입이나 주니어 기획자들이 가장 흔하게 저지르는 1차원적인 실수가 있습니다. 바로 단순한 텍스트 나열로 '외형' 만 묘사하는 것입니다. 예를 들어, 핵심 BM인 '가챠(뽑기)' 화면 연출을 기획한다고 가정해 보겠습니다. 흔히들 이런 식으로 발주서를 씁니다. "확인 버튼을 누르면 불빛이 번쩍거리고, 주먹으로 내려치기 직전의 괴수가 나와 눈을 부라리고 있는 상...

  안녕하세요. '호랭이 물어갈 기획놈들' 입니다. 프로그래머, 아트 파트와 피 튀기는 조립 과정을 거쳐 드디어 게임이 화면 위에서 정상적으로 돌아가기 시작했습니다.  신입 기획자는 "아, 드디어 내 글자와 그림 쪼가리가 실제 게임으로 완성됐구나!"라며 안도의 한숨을 내쉽니다. 하지만 착각하지 마십시오.  진정한 지옥은 이제부터 시작입니다. 유저의 마인드로 빙의해 게임을 갈기갈기 찢어발기는 개발 후반부의 최종 보스, 'QA(Quality Assurance) 파트'와의 피 말리는 전쟁이 기다리고 있습니다. 오늘은 16년 차 실무자의 시선에서, 기획자의 멘탈을 부수는 QA 테스트의 현실과 대처법을 뼈 때리게 해부해 드립니다. 살아있는! '버그 제조기' QA 파트는 절대 일반 유저 처럼 얌전하게 게임을 플레이 하지 않습니다.  그들은 기획자의 상식을 파괴하는 '살아있는 버그 제조기'이자 극한의 테스터들입니다. 보상 받기 버튼을 0.1초 만에 50번 연타 하는 것은 기본입니다. 아이템 받기 버튼 후 보상 획득 팝업 창으로 넘어가는  중간에 AOS Back 버튼을 미친 사람에 빙의해 연타 후 앱을 강제로 꺼버리고, 절대로 동시에 눌릴 리 없다고 생각했던 UI에 출력 된 네 개의 모든 버튼을 자기 옆 사람의 손가락까지 이용해 기어코 동시에 눌러버립니다. 기획서에 적힌 '아름답고 정상적인 플로우' 따위는 이미 그들의 머릿속에 존재하지 않습니다. 기획자가 미처 생각하지 못했던 시스템의 구멍, 룰과 룰이 충돌하는 심연의 공간에서만 살아왔던 사람처럼 집요하고 잔인하고 처절할 정도로 파고들어 기어이 클라이언트 또는 서버에서 크래쉬를 뱉게 만듭니다. 내가 만든 완벽하고 아름다운 내 자식 같은 게임이 QA 파트의 손에 넘어가자마자 걸레짝이 되어버리는 것을 실시간으로 목격할 때, 신입 기획자의 멘탈은 그야말로 산산조각이 납니다. 사적으로 만나면 정말 선하고 가정에 충실한 사람들이 개발자와 기획자의...

  안녕하세요. '호랭이 물어갈 기획놈들' 입니다. 데이터 테이블에 더미 데이터를 꽉꽉 밀어 넣고 잠시 꿀 같은 휴식을 취했다면, 이제 신입 기획자들의 멘탈을 산산조각 낼 '2차 위기'가 찾아올 시간입니다. 타 파트에서 개별적으로 제작되던 UI, 아트 리소스, 그리고 클라이언트와 서버의 패킷 통신이 드디어 하나의 게임으로 조립되는 시점입니다.  기획서엔 없었던 치명적인 맹점들이 터져 나오는 리소스 조립 단계의 현실을 16년 차 실무자의 시선으로 해부해 드립니다. 1. 무더기 예외 사항 작업이 어느 정도 진행되면 아트 팀에서 이미지 리소스와 이펙트 리소스 , UI 까지 쏟아져 나오고 , 클라이언트 프로그래머는 기획서의 룰에 맞춰 서버 담당자와 패킷 ( 데이터 ) 을 주고받는 연동 작업을 시작합니다 . 그리고 바로 이 시점에 , 별일 없을 줄 알았던 기획서에 숨겨져 있던 알지 못했던 이슈들이 나 좀 해결해 달라고 미친듯이 나타납니다 . " 보상 획득 팝업에 버튼을 눌러 보상을 받는 중 출력되는 0.5 초의 애니메이션 중간에 클라이언트를 강제로 꺼버리면 , 보상은 지급해야 하나요 롤백해야 하나요 ?" " 서버 지연으로 패킷이 늦게 도착해서 랭킹이 변경될 수 있는데 되는데 이건 어떻게 처리하죠 ?" 머릿속으로 상상만 하며 문서를 쓸 때는 절대 보이지 않았던 , 물리적인 리소스와 네트워크 환경이 맞물리면서 발생하는 ' 무더기 예외 사항 ' 이 쏟아집니다 . 프로그래머들의 날카로운 질문 공세 속에서 , 신입 기획자는 자신의 문서가 얼마나 단순한 예외처리 몇 개만 작성한 반쪽짜리 문서인지 처절하게 깨닫게 됩니다 . 이때 당황해서 프로그래머에게 잡아 먹힐 행동은 절대 하지 마세요 ! 추가로 이것도 모르냐는 헛소리로 프로그래머를 자극시키지 마십시오 .  발생한 예외 사항들을 리스트업 하고 , 룰의 충돌을 막는 예외 사항 처리 방식을 기획서에 빠르게 추가 업데이트 하는 것이 진짜 실무 기획자의 몫...

  안녕하세요. '호랭이 물어갈 기획놈들' 입니다. 기획서 발주와 초반 일정 회의가 끝났다고 해서 기획자의 업무가 끝난 것은 결코 아닙니다. 오히려 타 부서가 요리할 수 있도록 식재료를 다듬는 '테이블 지옥'이 시작됩니다.  발주 직후 기획자가 정신을 똑바로 차리고 챙겨야 할 실무 3가지를 16년 차의 시선으로 짚어드립니다. 더미 데이터 입력 기획자들이 기획서 발주를 마치면 가장 많이 하는 치명적인 착각이 있습니다. 이제 내 손을 떠났으니 프로그래머가 결과물을 가져올 때까지 멍 때리고 기다리면 된다고 생각하는 것입니다. 하지만 실무는 그렇게 호락호락하지 않습니다.  보통 데이터 테이블의 뼈대(구조)는 사수나 프로그래머가 엔진 로직에 맞춰 미리 세팅해 줍니다. <그림 1. 데이터 구조 설계 예시> 신입이 해야 할 첫 번째 임무는 그 저 위의 껍데기 테이블 구조에 자신이 기획한 내용의 수치들을 일괄 데이터 화 시켜 테이블에 숫자 및 문자로 꽉꽉 채워 넣는 것입니다. '엑셀' 또는 '회사 전용 데이터 툴'을 열고 아이템 ID, 기본 스탯, 확률 수치 등을 개발팀이 테스트 진행하며 개발할 수 있도록 테스트 케이스에 맞춰서 실수 없이 입력해야 합니다. 이 기초적인 데이터 입력 과정에서 오타를 내거나 컬럼을 밀려 쓰면, 프로그래머가 테스트를 돌릴 때 클라이언트가 뻗어버리거나 메신저 또는 조용히 자리로 찾아오는 치명적인 상황이 발생합니다. 기획서의 화려한 아이디어보다 중요한 것은, 타 부서가 즉시 요리할 수 있도록 식재료(데이터)를 완벽하게 손질해서 테이블에 올려두는 꼼꼼함입니다. 발주가 끝났다면 마우스에서 손을 놓지 말고 즉시 데이터부터 밀어 넣으십시오. 스트링 테이블 작업 더미 데이터 입력으로 시스템이 굴러갈 뼈대에 살을 붙였다면, 그다음으로 챙겨야 할 것은 유저의 눈에 직접 보이는 '텍스트'입니다. 게임 내에 들어가는 모든 시스템 메시지, 아이템 이름, NPC 대사, UI 버튼의 이름들...

  안녕하세요. '호랭이 물어갈 기획놈들' 입니다. 치열했던 기획서 리뷰 회의가 끝나고 기획이 통과되면, 이제 타 부서에 작업을 요청하는 본격적인 '발주' 단계가 시작됩니다. 문서만 쓰면 끝인 줄 알았던 기획자들이 클라이언트, 서버, 아트 파트와 부딪히며 가장 많이 깨지는 주의 사항 3가지를 16년 차 실무자의 시선으로 해부해 드립니다. 프로그래머의 '안된다' 기획서를 발주 후 세부 구현을 논의할 때 기획자(신입, 경력) 모두가 가장 두려워하는 말이 있습니다. 바로 프로그래머의 차가운 "그거 안된다"라는 거절 멘트 입니다. 이 말을 들으면 기획자 들은 자신의 기획이 완전히 부정 당했다고 착각하여 감정이 상해서 PD에게 달려가 프로그래머들이 못해준다고 일러바치며 파트 간 무의미한 세력 싸움을 벌이곤 합니다. 하지만 16년 차 실무진의 귀에는 이 말이 완전히 다른 언어로 번역되어 들립니다. 기술적으로 영원히 불가능하다는 뜻이 아니라, "현재 클라이언트 엔진 구조에서 기획자 님이 원하는 퀄리티를 100% 구현하려면 프레임 드랍이 심하게 발생하거나 일정이 한 달 이상 밀립니다." 라는 매우 현실적인 경고입니다. 여기서 당황하지 말고, 정확히 어느 부분에서 연산 병목이 생기는지 논리적으로 되물어 보십시오. 안된다는 말을 들었을 때 "왜 안 되죠?"라며 따지기보다는, "어떤 부분이 구현 불가능한 것인지 내가 원하는 결과물의 중요 사항에 대해 설명을 하면서 우회 방법이 없는지 있다면 그 부분으로 진행하자" 라고 유연하게 개발을 진행 시키는 것이 프로의 자세입니다. 실무에서 타협은 패배가 아니라, 한정된 리소스와 일정 안에서 게임을 무사히 런칭 시키는 기획자의 진정한 프로젝트 매니징 실력임을 명심하십시오. 끝없는 추가 '예외 처리' 두 번째로 프로그래머와의 협업에서 기획 놈들의 숨통을 옥죄는 것은 끝없이 터져 나오는 '예외 처리' 케...

  안녕하세요. '호랭이 물어갈 기획놈들'입니다. 기획서를 아무리 완벽하게 써도, 회의실에서 입을 여는 순간 모든 신뢰를 깎아 먹는 치명적인 발표 습관들이 있습니다. 오늘은 신입 기획자들이 리뷰 회의에서 무의식적으로 저지르는 ' 최악의 발표 습관 3가지 '를 실무자의 냉정한 시선으로 해부해 드리겠습니다. 최악의 발표 습관 1: 화면만 줄줄 읊는 '국어책 낭독' 신입 기획자들이 리뷰 회의에 들어오면 가장 먼저 하는 치명적인 실수가 있습니다. 스크린에 기획서를 띄워놓고, 거기에 적힌 글자를 토씨 하나 틀리지 않고 그대로 줄줄 읊는 이른바 '국어책 낭독' 습관입니다. 회의실에 앉아 있는 프로그래머와 아트 디자이너들은 여러분의 목소리보다 눈으로 기획서를 읽고 궁금한 내용까지 체크할 정도로 읽는 속도가 훨씬 빠릅니다. 다 큰 어른들을 모아놓고 동화책을 읽어주듯 문서를 낭독하는 것은, 개발팀의 피 같은 업무 시간을 낭비하는 최악의 민폐 행동입니다. 발표는 기획서라는 오디오북을 재생하는 시간이 결코 아닙니다. 기획서에 적힌 '기능'을 그대로 읽지 말고, 그 기능을 그렇게 배치할 수밖에 없었던 기획자의 '숨겨진 의도'를 입으로 설명해야 합니다. "여기에 확인 버튼이 있습니다"라고 화면을 읽는 대신, "유저의 재화 손실을 막기 위해 뎁스를 하나 더 파서 확인 버튼을 배치했습니다"라고 설득하십시오. 화면만 줄줄 읊는 앵무새 같은 발표는 회의 시작 3분 만에 참석자 전원의 스마트폰을 켜게 만들 뿐입니다. 쉽지 않겠지만 옆자리 사수 기획자나 다른 기획자 분들께 발표를 들어달라고 하고 미리 연습과 훈련을 진행해야 합니다. <그림 1. 발표자 시점 슬라이드 노트 대본> 정 안된다면 위의 그림과 같이 아예 발표 관련 대본을 PPT 하단 슬라이드 노트에 적어두세요! 최악의 발표 습관 2: 시선을 분산시키는 '어설픈 손동작' 두 번째로 뼈를 때리...

  안녕하세요. '호랭이 물어갈 기획놈들'입니다. 오늘은 입사 직후 주어지는 2~4주간의 튜토리얼을 무사히 넘기기 위한  '신입 기획자 생존기'를 다룹니다. 수습 탈락을 피하기 위해 반드시 거쳐야 하는  '레퍼런스 게임 분석'과 '자사 게임 비교'의 실무적인 팁을 16년 차의  냉정한 시선으로 팩트 폭행해 드립니다. 신입 기획자 생존기 (수습 탈락의 현실) 신입 기획자가 회사에 입사하면 보통 2~4주간의 잔혹한 튜토리얼, 즉 수습 평가 기간을 거치게 됩니다. 이 기간의 생존 미션은 보통 5단계로 진행됩니다.  1단계:  타사의 레퍼런스 게임 플레이.  2단계: 우리가 만드는 자사 게임 플레이. 3단계: 두 게임의 차이점과 우리 게임의 약점 도출.  4단계: '왜 이렇게 만들었을까'를 고민한 타사 시스템 역기획.  5단계: 기획팀 전체 리뷰입니다. 이 숨 막히는 '신입 기획자 생존기'에서 수습 탈락의 고배를 마시는 80%의 이유는 보고서를  유저의 감상문 처럼 쓰기 때문입니다. 회사는 여러분에게 게임 평론을 하라고 월급을 주는 것이 결코 아닙니다."타격감이 좋습니다", "성장 동선이 지루합니다" 같은 뜬구름 잡는 소리는 수습 탈락으로 가는 가장 빠른 지름길입니다. 단순히 재미있다, 재미없다를 넘어 왜 그런 감정이 들도록 설계되었는지 시스템의 톱니바퀴를 역추적하는 훈련이 반드시 선행되어야 합니다. 유저의 허물을 완벽하게 벗어던지고, 철저하게 프로의 시선으로 게임의 뼈대를 해체할 수 있는지 증명해야만 살아남을 수 있습니다. 레퍼런스 게임 분석 (원작자의 '왜' 파헤치기) 생존을 위한 첫 번째 핵심 미션은 타사의 잘나가는 타이틀을 철저하게 뜯어보는 ' 레퍼런스 게임 분석 '입니다. 이때 대다수의 신입들은 평소 집에서 게임을 하듯 겉으로 보이는 화려한 UX나 그래픽에만 매몰되는 치명적인 실수를 저지릅니다. 레퍼런스...