게임 기획 실무: 리소스 조립 중 생기는 일 (무더기 예외 사항, 원작자 의도, 최종 마침표)

안녕하세요. '호랭이 물어갈 기획놈들' 입니다.

데이터 테이블에 더미 데이터를 꽉꽉 밀어 넣고 잠시 꿀 같은 휴식을 취했다면, 이제 신입 기획자들의 멘탈을 산산조각 낼 '2차 위기'가 찾아올 시간입니다.

타 파트에서 개별적으로 제작되던 UI, 아트 리소스, 그리고 클라이언트와 서버의 패킷 통신이 드디어 하나의 게임으로 조립되는 시점입니다.

기획서엔 없었던 치명적인 맹점들이 터져 나오는 리소스 조립 단계의 현실을 16년 차 실무자의 시선으로 해부해 드립니다.

1. 무더기 예외 사항

작업이 어느 정도 진행되면 아트 팀에서 이미지 리소스와 이펙트 리소스, UI까지 쏟아져 나오고, 클라이언트 프로그래머는 기획서의 룰에 맞춰 서버 담당자와 패킷(데이터)을 주고받는 연동 작업을 시작합니다.

그리고 바로 이 시점에, 별일 없을 줄 알았던 기획서에 숨겨져 있던 알지 못했던 이슈들이 나 좀 해결해 달라고 미친듯이 나타납니다.

"보상 획득 팝업에 버튼을 눌러 보상을 받는 중 출력되는 0.5초의 애니메이션 중간에 클라이언트를 강제로 꺼버리면, 보상은 지급해야 하나요 롤백해야 하나요?"

"서버 지연으로 패킷이 늦게 도착해서 랭킹이 변경될 수 있는데 되는데 이건 어떻게 처리하죠?"

머릿속으로 상상만 하며 문서를 쓸 때는 절대 보이지 않았던, 물리적인 리소스와 네트워크 환경이 맞물리면서 발생하는 '무더기 예외 사항'이 쏟아집니다.

프로그래머들의 날카로운 질문 공세 속에서, 신입 기획자는 자신의 문서가 얼마나 단순한 예외처리 몇 개만 작성한 반쪽짜리 문서인지 처절하게 깨닫게 됩니다.

이때 당황해서 프로그래머에게 잡아 먹힐 행동은 절대 하지 마세요! 추가로 이것도 모르냐는 헛소리로 프로그래머를 자극시키지 마십시오.

발생한 예외 사항들을 리스트업 하고, 룰의 충돌을 막는 예외 사항 처리 방식을 기획서에 빠르게 추가 업데이트 하는 것이 진짜 실무 기획자의 몫입니다.

만약 자신이 신입이던 낮은 연차의 기획자이시면 무조건 절대적으로 자신의 사수 또는 상급자와 같이 대동하여 어떠한 방식으로 해결하는지 보고 듣고 깨지고 배워야 합니다.

절대 깨지는 것을 두려워하시면 안 됩니다. 그 긴장된 상황에서 어떠한 방식으로 해결하는지 이때 사수 또는 상급자는 무슨 이야기를 하는지 귀 기울여 들어보세요! 다음에 이런 일이 생길 때 유연하게 대처하기 위한 공부라고 생각하세요!

수많은 예외 사항과 버그의 늪에 빠져 예외 사항들을 하나하나 처리하다 보면, 기획자들은 자연스럽게 기획 초기 단계에 참고했던 '레퍼런스 게임'을 다시 켜게 됩니다.

그리고 그 게임을 다시 플레이 하는 순간, 이전에는 전혀 보이지 않던 엄청난 진실을 마주하게 됩니다.

"아! 그래서 이 버튼을 누른 직후 애니메이션이 흐르는 0.5초 동안 터치를 원천 봉쇄하기 위해 백 그라운드에 투명한 딤(Dim) 처리를 해 두었구나!"

"왜 굳이 이렇게 불편한 단계(Depth)를 한 번 더 거치게 만들었을까 불만이었는데, 이게 바로 서버 패킷이 꼬이며 랭킹이 뒤바뀌는 것을 방지하기 위한 필수 안전장치였네."

눈앞에서 직접 조립된 결과물이 별것 아니라고 생각하며 그냥 넘어가고 난 다음 버그로 망가지는 것을 보고 나서야, 레퍼런스 게임을 만든 '원작자의 의도'를 뼛속 깊이 이해하게 되는 것입니다.

단순히 타겟 게임의 겉모습만 베껴오는 것은 누구나 할 수 있습니다.

하지만 우리 게임을 조립하며 맞닥뜨린 치명적인 문제들을 통해 "원작자는 왜(Why) 이런 시행착오를 거쳐 이런 룰을 세팅했을까?"를 끊임없이 역추적하고 내 것으로 흡수하는 과정이 기획자의 진짜 레벨을 결정짓습니다.

어떤 것을 만들더라도 무조건 저 개발자는 ‘왜!’ 이렇게 만들었을까? 란 의문을 가지고 작은 것도 쉬이 넘기지 말고 체크하며 검증하고 기획하는 것을 연습하세요!

프로그래머, 아트 파트와 피 튀기는 논의를 거쳐 무더기로 쏟아진 예외 사항들을 하나하나 처리합니다.

어색했던 UI 팝업의 타이밍을 맞추고, 서버와 클라이언트의 싱크를 조율하며 삐걱거리던 톱니바퀴에 기름을 칩니다.

그렇게 파편화되어 있던 리소스들이 어느 순간 기획자의 의도대로 안정적으로 맞물려 돌아가며 모니터 화면 위에 예쁘게 출력되는 순간이 옵니다.

이 순간이야 말로, 단순히 워드나 PPT로 문서를 다 썼을 때가 아니라 진정한 의미에서 기획의 '최종 마침표'를 찍는 상황입니다.

우리가 예시 이미지를 통해 텍스트로 상세 내용을 작성했던 개발의도와 해당 콘텐츠의 재미가 엑셀과 코드를 넘어, 유저가 직접 만질 수 있는 실체로 조립되었을 때의 그 짜릿한 쾌감.

이것이 바로 기획자들이 그 많은 야근과 스트레스를 견디며 게임을 개발하는 진짜 이유일 것입니다.

다만 여기서도 중요한 부분이 있는데 무조건 자신이 기획한대로 명확하게 동작하는지 조금이라도 틀린 부분은 없는지 그리고 기획서 내용과 다르게 협의를 거치며 변경된 부분이 정확하게 들어갔는지 확인합니다.

그럼 이제 개발팀 내부에서의 1차적인 조립은 마무리되었습니다.

다음은 유저의 마인드로 빙의 해 게임을 갈기갈기 찢어발기는 버그 생성자이자 살아있는 버그 제조기인, QA 파트와의 치열한 전쟁이 기다리고 있습니다.