단순 베끼기는 역기획이 아니다!(원작자의 '왜'를 파헤쳐라)
안녕하세요. '호랭이 물어갈 기획놈들' 입니다.
신입 기획자들이 포트폴리오를 만들 때 가장 많이 착각하는 '단순 베끼기'를 멈추고, 화면 뒤에 숨겨진 '원작자의 왜'를 파헤치는 방법에 대해 이야기하겠습니다.
UI 스크린샷만 캡처해서 나열하는 것은 결코 '역기획이 아니다'라는 점을 실무자의 냉정한 시선으로 짚어드립니다.
신입 기획자들이 포트폴리오를 만들 때 가장 많이 착각하는 '단순 베끼기'를 멈추고, 화면 뒤에 숨겨진 '원작자의 왜'를 파헤치는 방법에 대해 이야기하겠습니다.
UI 스크린샷만 캡처해서 나열하는 것은 결코 '역기획이 아니다'라는 점을 실무자의 냉정한 시선으로 짚어드립니다.
화려한 '단순 베끼기' 문서
기획자 지망생들이 포트폴리오를 위해 가장 많이 시도하는 작업이 타사의 게임을 분석하는 것입니다.
하지만 대다수의 문서를 열어보면 실무 면접관 입장에서는 깊은 한숨부터 나옵니다.
하지만 대다수의 문서를 열어보면 실무 면접관 입장에서는 깊은 한숨부터 나옵니다.
해당 게임의 화려한 UI 스크린샷만 화면별로 수십 장씩 캡처되어 있고, "버튼을 누르면 팝업이 뜹니다" 혹은 "강화에 실패하면 장비가 파괴됩니다" 같은 단순 기능 설명만 빼곡하게 적혀 있기 때문입니다.
이것은 유저들이 게임을 플레이할 때 참고하는 게임 가이드북일 뿐, 결코 시스템 역기획서가 될 수 없습니다.
기능의 흐름만 표면적으로 나열하는 것은 남이 그린 예쁜 그림과 겉모습만 가져온 전형적인 '단순 베끼기'에 불과합니다.
눈에 보이는 것을 캡처하고 그대로 적는 것은 초등학생도 할 수 있는 단순 문서 작업입니다.
여기에는 진짜 시스템 기획에 대한 깊은 고민이나 밸런스에 대한 고찰이 단 한 줄도 들어가지 않았습니다.
이런 포트폴리오는 면접관에게 자신의 분석력을 증명하는 것이 아니라, 오히려 분석력 제로와 게임에 대한 고찰이 아닌 단순 데이터 나열 정도만 한다고 온 동네 소문내는 격 입니다.
 |
| <그림 1. 스타시드 역기획 예시> |
획득한 캐릭터는 밝게 표시되고 획득하지 못한 캐릭터는 어둡게 표시한다 정도의 UI 설명들과
들어갈 텍스트 키만 나열하고 끝나는데 그게 아니라 저 도감이라는 시스템이 어째서 들어가는지
저 도감을 개발한 정확한 목적은 무엇이며 저 시스템이 유저의 플레이 감각을 어떻게 바꾸게 되는지
그래서 최종 결론 '왜' 개발자가 저걸 만들었는지 이 부분에 대한 깊은 생각을 해야 한다는 것 입니다.
원작자의 '왜'를 파헤쳐라
진정한 분석의 첫 단계는 무작정 캡처 프로그램을 켜고 게임 화면을 찍어대는 것이 아닙니다.
화면 너머에 숨어 있는 오리지널 기획자의 의도를 묻고, "도대체 이걸 '왜' 이렇게 만들었는가?"를 치열하게 파헤치는 것입니다.
지금 여러분 눈앞에 있는 그 시스템은 과거 어느 회의실에서 수많은 프로그래머와 PD의 날 선 비판을 방어해 내고 살아남은 치열한 결과물입니다.
"왜 하필 이 시스템의 강화 재료를 1개가 아닌 3종류로 파편화시켰을까?"라는 깊은 의문을 던져야만 합니다.
단순히 유저를 귀찮게 하려는 것이 아니라, 특정 재화의 인플레이션을 분산시켜 소모시키기 위한 원작자의 치밀한 경제 밸런스 의도일 확률이 매우 높습니다.
또는 "이 상점 팝업은 왜 하필 30레벨에 도달해야만 열릴까?"라는 질문을 던져 보십시오.
이는 초반 유저의 정보 과부하를 막고, 결제 전환율이 가장 높은 허들 구간에 과금 모델(BM)을 노출하려는 사업적 의도입니다.
이처럼 눈에 보이지 않는 설계 의도와 밸런스의 명분을 철저하게 엑셀과 수식으로 해체해 내는 것만이 '원작자의 왜를 파헤쳐라'라는 명제에 부합하는 진짜 기획입니다.
화면 너머에 숨어 있는 오리지널 기획자의 의도를 묻고, "도대체 이걸 '왜' 이렇게 만들었는가?"를 치열하게 파헤치는 것입니다.
지금 여러분 눈앞에 있는 그 시스템은 과거 어느 회의실에서 수많은 프로그래머와 PD의 날 선 비판을 방어해 내고 살아남은 치열한 결과물입니다.
"왜 하필 이 시스템의 강화 재료를 1개가 아닌 3종류로 파편화시켰을까?"라는 깊은 의문을 던져야만 합니다.
단순히 유저를 귀찮게 하려는 것이 아니라, 특정 재화의 인플레이션을 분산시켜 소모시키기 위한 원작자의 치밀한 경제 밸런스 의도일 확률이 매우 높습니다.
또는 "이 상점 팝업은 왜 하필 30레벨에 도달해야만 열릴까?"라는 질문을 던져 보십시오.
이는 초반 유저의 정보 과부하를 막고, 결제 전환율이 가장 높은 허들 구간에 과금 모델(BM)을 노출하려는 사업적 의도입니다.
이처럼 눈에 보이지 않는 설계 의도와 밸런스의 명분을 철저하게 엑셀과 수식으로 해체해 내는 것만이 '원작자의 왜를 파헤쳐라'라는 명제에 부합하는 진짜 기획입니다.
스크린샷은 '역기획이 아니다'
그렇다면 포트폴리오에서 스크린샷이나 UI 흐름도는 아예 쓸모가 없는 시각 데이터일까요?
그렇지 않습니다. 실무에서 이러한 시각 자료가 사용되는 타이밍과 본질적인 목적이 완전히 다를 뿐입니다.
스크린샷은 시스템의 뼈대와 원작자의 의도를 완벽히 분석한 뒤, 타 부서에 우리만의 개선안을 설득할 때 쓰는 소통 도구로 쓰여야 합니다.
원작자가 설계한 데이터 테이블의 확률 변수를 역산해 낸 후, 기존 시스템의 치명적인 단점을 찾아내야 합니다.
그리고 "우리는 이 맹점을 보완하기 위해 이렇게 고쳐서 새롭게 개발합시다"라는 확고한 논리를 세워야 합니다.
바로 그 타이밍에 그래픽 팀과 프로그램 팀을 직관적으로 납득시키고 설득하기 위해 꺼내는 보조 자료가 스크린샷입니다.
내가 찾은 개선안을 타 부서가 쉽게 이해하고 구현할 수 있도록 돕는 내비게이션 역할인 셈입니다.
화면만 예쁘게 오려 붙이는 껍데기 문서는 결코 '역기획이 아니다'라는 사실을 반드시 명심하십시오.
원작자의 의도를 씹어 먹고, 우리만의 논리적인 개선안을 도출하는 진짜 분석 훈련을 시작하시길 바랍니다.
그렇지 않습니다. 실무에서 이러한 시각 자료가 사용되는 타이밍과 본질적인 목적이 완전히 다를 뿐입니다.
스크린샷은 시스템의 뼈대와 원작자의 의도를 완벽히 분석한 뒤, 타 부서에 우리만의 개선안을 설득할 때 쓰는 소통 도구로 쓰여야 합니다.
원작자가 설계한 데이터 테이블의 확률 변수를 역산해 낸 후, 기존 시스템의 치명적인 단점을 찾아내야 합니다.
그리고 "우리는 이 맹점을 보완하기 위해 이렇게 고쳐서 새롭게 개발합시다"라는 확고한 논리를 세워야 합니다.
바로 그 타이밍에 그래픽 팀과 프로그램 팀을 직관적으로 납득시키고 설득하기 위해 꺼내는 보조 자료가 스크린샷입니다.
내가 찾은 개선안을 타 부서가 쉽게 이해하고 구현할 수 있도록 돕는 내비게이션 역할인 셈입니다.
화면만 예쁘게 오려 붙이는 껍데기 문서는 결코 '역기획이 아니다'라는 사실을 반드시 명심하십시오.
원작자의 의도를 씹어 먹고, 우리만의 논리적인 개선안을 도출하는 진짜 분석 훈련을 시작하시길 바랍니다.