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

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