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

  안녕하세요. '호랭이 물어갈 기획놈들' 입니다. 프로그래머, 아트 파트와 피 튀기는 조립 과정을 거쳐 드디어 게임이 화면 위에서 정상적으로 돌아가기 시작했습니다.  신입 기획자는 "아, 드디어 내 글자와 그림 쪼가리가 실제 게임으로 완성됐구나!"라며 안도의 한숨을 내쉽니다. 하지만 착각하지 마십시오.  진정한 지옥은 이제부터 시작입니다. 유저의 마인드로 빙의해 게임을 갈기갈기 찢어발기는 개발 후반부의 최종 보스, '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나 그래픽에만 매몰되는 치명적인 실수를 저지릅니다. 레퍼런스...

  안녕하세요. '호랭이 물어갈 기획놈들' 입니다. 신입 기획자들이 포트폴리오를 만들 때 가장 많이 착각하는 '단순 베끼기'를 멈추고, 화면 뒤에 숨겨진 '원작자의 왜'를 파헤치는 방법에 대해 이야기하겠습니다. UI 스크린샷만 캡처해서 나열하는 것은 결코 '역기획이 아니다'라는 점을 실무자의 냉정한 시선으로 짚어드립니다. 화려한 '단순 베끼기' 문서 기획자 지망생들이 포트폴리오를 위해 가장 많이 시도하는 작업이 타사의 게임을 분석하는 것입니다. 하지만 대다수의 문서를 열어보면 실무 면접관 입장에서는 깊은 한숨부터 나옵니다. 해당 게임의 화려한 UI 스크린샷만 화면별로 수십 장씩 캡처되어 있고, "버튼을 누르면 팝업이 뜹니다" 혹은 "강화에 실패하면 장비가 파괴됩니다" 같은 단순 기능 설명만 빼곡하게 적혀 있기 때문입니다. 이것은 유저들이 게임을 플레이할 때 참고하는 게임 가이드북일 뿐, 결코 시스템 역기획서가 될 수 없습니다. 기능의 흐름만 표면적으로 나열하는 것은 남이 그린 예쁜 그림과 겉모습만 가져온 전형적인 '단순 베끼기'에 불과합니다. 눈에 보이는 것을 캡처하고 그대로 적는 것은 초등학생도 할 수 있는 단순 문서 작업입니다. 여기에는 진짜 시스템 기획에 대한 깊은 고민이나 밸런스에 대한 고찰이 단 한 줄도 들어가지 않았습니다. 이런 포트폴리오는 면접관에게 자신의 분석력을 증명하는 것이 아니라, 오히려 분석력 제로와 게임에 대한 고찰이 아닌 단순 데이터 나열 정도만 한다고 온 동네 소문내는 격 입니다. <그림 1. 스타시드 역기획 예시> 간략하게 예를 들면 다들 역기획 해보라고 하면 저 이미지 캡쳐 후 모든 캐릭터 나열 후  획득한 캐릭터는 밝게 표시되고 획득하지 못한 캐릭터는 어둡게 표시한다 정도의 UI 설명들과  들어갈 텍스트 키만 나열하고 끝나는데 그게 아니라 저 도감이라는 시스템이 어째서 들어가는지  저 도감을 개발한...

  회의실에 울려 퍼지는 공포의 단어, "왜?" "그래서, 이걸 우리 게임에 왜 넣어야 하는 거죠?" 갓 입사한 신입 기획자가 밤을 새워 만들어 온 신규 펫 시스템 기획서 리뷰 시간. PD님의 입에서 이 짧고 건조한 질문이 튀어나오는 순간, 회의실의 공기는 무겁게 얼어붙습니다. 신입 기획자는 당황한 기색을 숨기지 못하고 더듬거리며 대답합니다. "어... 요즘 다른 경쟁작들도 다 펫 시스템이 있고, 유저들도 귀여운 걸 좋아하니까 들어가면 재미있을 것 같아서요." 결과는 어땠을까요? PD님과 각 파트장들의 미간은 좁혀졌고, 기획서는 그 자리에서 즉시 반려되었습니다. 아마 그 신입의 머릿속에는 '왜 내 아이디어를 무시하지? 게임은 재미만 있으면 되는 거 아닌가?'라는 억울함이 가득했을 겁니다. 끝없는 '왜' 하지만 16년 차 기획자의 시선으로 냉정하게 팩트만 말하자면, 그 기획서는 그 자리에서 반려당하는 것이 백번 맞습니다. 시스템 기획의 가장 거대하고 중요한 뼈대인 '왜(Why)'가 완벽하게 결여 되어 있었기 때문입니다. 기획자 지망생이나 이제 막 실무를 시작한 신입 기획자들이 가장 고통스러워하는 것이 있습니다. 바로 타 부서 작업자들이나 상위 포지션에서 숨 쉴 틈 없이 날아오는 끝없는 '왜'라는 질문의 연속입니다. "이 UI는 왜 하필 여기에 배치했어?" "이벤트 보상 수치는 왜 이렇게 잡은 거야?" "이 타이밍에 왜 이 시스템이 팝업으로 열려야 하지?" 많은 신입 기획자들이 이 질문을 자신의 아이디어에 대한 감정적인 '공격'이나 '텃세'로 받아들입니다. 그래서 방어적인 태도를 취하거나 남몰래 상처를 받곤 하죠. 하지만 여러분이 이 바닥에서 살아남으려면 반드시 알아야 할 냉혹한 현실이 있습니다. 게임 개발은 수십 명의 고급 인력과 수십억, 수백억의 자본이 투입되는 철저한 ...

<그림 1. 컨트롤러 UI 기획서 첫장>   프로그래머의 깊은 한숨 며칠 전 회사 근처 식당에서 20년 차 클라이언트 프로그래머(플머) 형과 점심을 먹고 있었습니다. 식사를 마치고 근처 커피숍에서 신규 입사자 친구들 이야기를 하던 중, 플머 형이 삶이 힘들다는 표정을 지으며 깊은 한숨을 내쉬었습니다. "형, 무슨 일 있어? 왜 또 누가 고풍스러운 빨간색으로 옵션 창 꾸며 달래?" 제 농담에 플머 형은 쓴웃음 지으며 대답했습니다. "그건 아무 빨간색이나 대충 칠이라도 하면 되는 건데, 유저가 뒤로 가기 누르거나 초기화 시키면 어떻게 할 것인지 예외 사항 처리가 하나도 안 되어 있잖아. 매번 이걸 어떻게 말해줘야 하냐." 그 푸념을 듣다 가만히 생각해 보니 문득 제 옛날에 처음 작성했던 기획서 내용에 빠뜨렸던 부분들이 하나둘 생각나기 시작했습니다. "나도 그랬는데..." 프로그래머가 사랑하는 기획서 신입 기획자 시절, 와우? 던파? 이런 게임보다 100배는 더 잘 나가는 세상에 둘도 없는 천상천하 유아독존 같은 멋진 시스템을 가진 게임을 만들겠다는 미친 생각으로 회사에 입사했습니다. 하지만 실무에 첫발을 내딛는 그 순간, 기획자를 가로막는 '프로그래머'라는 까칠하고 공포스러운 험난한 파도가 절 기다리고 있었습니다. 이들의 가장 큰 특징은 일 할 때 감성이나 막연한 느낌 따위는 완전 무시하고 철저한 논리와 계산만이 가득한 대문자 T 아저씨들이었습니다.  특히 기획서에  "유저가 설정 취소를 누르면 해당 사항을 인지할 타이밍에 토스트 툴팁을 띄워줍니다"라는  소리를 적는 순간, 몇 번의 한숨과 나와 기획서를 번갈아 가며 눈을 희번뜩거리고는  "그 타이밍이 언제라는 거죠? 명확하게 그 순간을 가져와 주셔야 그렇게 만들 수 있습니다."란  말을 하며 회의를 끊어버렸죠. 즉 기획자에게 있어 프로그래머란 ? 내 기획의 허점을 파고드는 검증자이자 상상을 현실로 구...

 패치노트 요약 1. 감이 아닌 데이터, '지표 설계'로 증명한 기획   2. 라이브 서버의 생존, '글로벌 구조 최적화'   3. 16년 차 시스템 기획자의 '진짜' 패치노트를 엽니다