기획서 발주 후 주의 사항 3가지 (안된다, 예외 처리, 예쁘게 그려주세요)

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

치열했던 기획서 리뷰 회의가 끝나고 기획이 통과되면, 이제 타 부서에 작업을 요청하는 본격적인 '발주' 단계가 시작됩니다.

문서만 쓰면 끝인 줄 알았던 기획자들이 클라이언트, 서버, 아트 파트와 부딪히며 가장 많이 깨지는 주의 사항 3가지를 16년 차 실무자의 시선으로 해부해 드립니다.

프로그래머의 '안된다'

기획서를 발주 후 세부 구현을 논의할 때 기획자(신입, 경력) 모두가 가장 두려워하는 말이 있습니다.

바로 프로그래머의 차가운 "그거 안된다"라는 거절 멘트 입니다.

이 말을 들으면 기획자 들은 자신의 기획이 완전히 부정 당했다고 착각하여 감정이 상해서 PD에게 달려가 프로그래머들이 못해준다고 일러바치며 파트 간 무의미한 세력 싸움을 벌이곤 합니다.

하지만 16년 차 실무진의 귀에는 이 말이 완전히 다른 언어로 번역되어 들립니다.

기술적으로 영원히 불가능하다는 뜻이 아니라, "현재 클라이언트 엔진 구조에서 기획자 님이 원하는 퀄리티를 100% 구현하려면 프레임 드랍이 심하게 발생하거나 일정이 한 달 이상 밀립니다." 라는 매우 현실적인 경고입니다.

여기서 당황하지 말고, 정확히 어느 부분에서 연산 병목이 생기는지 논리적으로 되물어 보십시오.

안된다는 말을 들었을 때 "왜 안 되죠?"라며 따지기보다는, "어떤 부분이 구현 불가능한 것인지 내가 원하는 결과물의 중요 사항에 대해 설명을 하면서 우회 방법이 없는지 있다면 그 부분으로 진행하자" 라고 유연하게 개발을 진행 시키는 것이 프로의 자세입니다.

실무에서 타협은 패배가 아니라, 한정된 리소스와 일정 안에서 게임을 무사히 런칭 시키는 기획자의 진정한 프로젝트 매니징 실력임을 명심하십시오.

두 번째로 프로그래머와의 협업에서 기획 놈들의 숨통을 옥죄는 것은 끝없이 터져 나오는 '예외 처리' 케이스 해결 방법 제시 입니다.

대다수의 기획자 들은 유저가 정상적으로 버튼을 누르고 보상을 받는 아름다운 '해피 패스(성공 케이스)' 하나만 그려 놓고 발주가 끝났다고 착각합니다.

하지만 논리 왕 프로그래머들은 수만 명의 유저가 동시에 몰렸을 때 DB가 터지지 않도록 데이터 무결성을 지키는 방어막을 짜는 사람들입니다.

"보상이 우편함으로 꽂히는 순간 서버 연결이 끊기면 어떻게 복구할까요?"

"네트워크 지연을 악용해 강화 버튼을 0.1초 만에 세 번 연타하면 재화는 어떻게 삭감할까요?"

<그림 1. 예외 사항 처리 기획서 내용>

서버 담당자가 이런 치명적인 질문을 던지기 전에, 기획자가 먼저 모든 경우의 수를 통제하고 에러 코드 로직을 기획 문서에 따로 페이지를 할애하여 정리해 두어야 합니다.

유저의 꼼수와 어뷰징을 막고 로그(Log)를 남기는 백엔드 규칙을 촘촘하게 설계하지 않으면, 라이브 오픈 첫날부터 아이템 복사 버그가 터지고 롤백을 해야 하는 끔찍한 대참사를 맞이하게 됩니다.

발주 후 진짜 기획력은 얼마나 화려한 기능이 있느냐가 아니라, 얼마나 많은 예외 처리 로직을 프로그래머와 협업 하여 유저의 어뷰징 또는 무한 증식 같은 버그 사항을 방어해 냈느냐로 결정됩니다.

마지막으로 신입들이 아트 팀에 리소스를 발주할 때 가장 많이 저지르는 치명적인 만행이 있습니다.

바로 기획서 한구석에 "화려하고 예쁘게 그려주세요"라고 뭉뚱그려 요청하는 1차원적인 오더입니다.

아트 디자이너들은 여러분의 머릿속을 텔레파시로 읽어내는 감성적인 마법사가 아닙니다.

그들은 명확한 수치와 규격, 그리고 직관적인 레퍼런스를 바탕으로 게임의 껍데기를 만들어내는 또 다른 형태의 깐깐한 개발자입니다.

"결제 버튼을 타격감 있게 팡 터지도록 예쁘게 그려주세요"라는 요청은 현업에서 아무런 쓸모가 없는 최악의 쓰레기 오더입니다.

<그림 2. 참고 할 레퍼런스 게임 소개>

정확히 타사의 어떤 게임을 레퍼런스로 참고해야 하는지 직관적인 시각 자료를 첨부하고 비교 설명해야 합니다.

<그림 3. 뎁스 별 UI 예시>

또한 UI 창의 뎁스(Depth) 구조, 버튼 안에 들어갈 텍스트의 최대 글자 수 제한, 이펙트가 지속되는 정확한 시간(초)을 명확한 데이터로 지시해야 합니다.

주관적인 감상을 철저하게 배제하고 규격화 된 수치와 시각 자료로 소통하십시오.

그래야만 아트 팀의 피 같은 작업 시간을 아끼고 서로 얼굴 붉히는 무한 수정 지옥을 막아낼 수 있습니다.