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

안녕하세요. '호랭이 물어갈 기획놈들' 입니다. 지난 기획 실무 시리즈에서 클라이언트, 서버, 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 버튼의 이름들...