기획서는 길게 쓴다고 좋은 문서가 아닙니다. 프로그래머가 읽고 질문 없이 구현할 수 있고, 그래픽 팀이 필요한 리소스 목록을 바로 뽑을 수 있어야 합니다. 수…
결정권자라기보다 결정을 준비하는 사람
게임 회사의 회의에는 기획자, 프로그래머, 아티스트, QA, 사업 담당자 등 여러 직군이 함께 들어옵니다. 프로젝트의 큰 방향은 대개 디렉터나 PD가 최종 판단합니다. 그렇다고 기획자가 회의에서 의견만 말하는 사람은 아닙니다. 대부분의 회의에서 '이번에 정해야 할 것'을 정의하고, 가능한 선택지를 만들어 오고, 결론을 문서로 정리하는 사람이 기획자입니다.
실무에서 기획자의 영향력은 회의 전에 이미 결정됩니다. 선택지 없이 '어떻게 할까요?'라고 묻는 회의는 길어지고 결론도 흐려집니다. 반면 '세 가지 안이 있고, 각각의 장단점과 개발 비용은 이렇습니다. 저는 두 번째 안을 추천합니다'라고 준비해 오면 회의는 짧아지고, 결론은 대개 기획자의 안을 중심으로 정해집니다. 결정을 잘 준비하는 것이 곧 결정에 참여하는 방법입니다.
회의 종류별로 기획자가 정하는 것
| 회의 | 기획자가 주로 정하는 것 |
|---|---|
| 기획 리뷰 | 기능의 목적, 동작 규칙, 화면 흐름, 예외 상황 처리 |
| 일정·작업 회의 | 이번 기간에 넣을 기능과 미룰 기능, 작업 순서 |
| 밸런스 회의 | 성장 속도, 보상량, 난이도 같은 수치의 기준과 목표 |
| 업데이트 준비 회의 | 이벤트 내용과 기간, 보상 구성, 공지할 내용 |
| 이슈 대응 회의 | 문제 상황의 임시 조치와 보상 여부, 재발 방지 방향 |
회의 이름은 회사마다 다르지만, 기획자가 다루는 질문은 비슷합니다. 이 기능은 왜 필요한가, 어디까지 만들 것인가, 정상적인 경우와 예외적인 경우에 각각 어떻게 동작하는가, 그리고 언제까지 무엇부터 할 것인가입니다. 이 네 가지 질문에 답이 정해지면 다른 직군이 작업을 시작할 수 있습니다. 라이브 서비스 중인 게임이라면 여기에 '유저에게 어떻게 알릴 것인가'라는 질문이 하나 더 붙습니다. 바뀐 규칙을 공지로 어떻게 설명할지까지 정해야 회의가 끝납니다.
회의에서 가장 자주 정하는 것은 예외 처리다
기획서를 처음 쓰는 사람은 기능이 정상적으로 동작하는 흐름만 적기 쉽습니다. 예를 들어 친구에게 아이템을 선물하는 기능이라면, 선물을 고르고 보내고 받는 과정만 적습니다. 그런데 회의에서 프로그래머와 QA가 묻는 질문은 대부분 예외 상황입니다. 받는 사람의 가방이 꽉 차 있으면 어떻게 되는지, 보내는 도중 연결이 끊기면 아이템은 어디로 가는지, 하루에 몇 번까지 보낼 수 있는지 같은 질문입니다.
이런 질문에 그 자리에서 정할 수 있는 것은 정하고, 더 검토가 필요한 것은 언제까지 답을 줄지 정해 둡니다. 예외 처리가 정해지지 않으면 프로그래머가 임의로 구현하게 되고, 나중에 기획 의도와 다르다는 이유로 다시 만드는 일이 생깁니다. 회의 전에 예상되는 예외 상황을 미리 목록으로 만들어 가면 회의가 훨씬 효율적으로 끝납니다.
기획자가 혼자 정하지 않는 것
기획자가 모든 것을 정하지는 않습니다. 기능을 코드로 어떻게 구현할지, 서버 구조를 어떻게 짤지는 프로그래머가 판단합니다. 캐릭터와 배경의 그림체, 색감 같은 시각적 방향은 아트 디렉터와 아티스트가 이끕니다. 유료 상품의 가격이나 마케팅 일정처럼 사업적인 판단은 사업 담당자와 함께 정합니다.
좋은 기획자는 이 경계를 잘 압니다. '이 버튼은 이 색으로 해 주세요'보다는 '이 버튼은 화면에서 가장 먼저 눈에 띄어야 합니다'처럼 목적을 전달하고, 표현 방식은 전문 직군에 맡깁니다. 구현 방식에 대해서도 '이렇게 만들어 주세요'가 아니라 '이런 동작이 필요한데, 개발 비용이 큰 부분이 있을까요?'라고 묻습니다. 그래야 각 직군이 가진 전문성을 살린 더 좋은 해결책이 나옵니다.
결정을 빠르게 만드는 회의 준비물
회의가 길어지는 가장 큰 이유는 같은 것을 서로 다르게 상상하고 있기 때문입니다. 글로만 된 기획서를 보면 사람마다 화면을 다르게 떠올립니다. 그래서 기획자는 회의 전에 상상의 차이를 줄일 자료를 준비합니다. 대략의 화면 배치를 그린 와이어프레임, 버튼을 눌렀을 때 어디로 이동하는지 보여 주는 흐름도, 비슷한 기능을 가진 다른 게임의 화면 캡처 같은 것들입니다.
수치를 정하는 회의라면 표 한 장이 큰 역할을 합니다. 보상량을 지금보다 늘리면 유저가 목표 단계에 도달하는 시간이 얼마나 짧아지는지 간단한 계산표로 보여 주면, 감으로 하는 논쟁이 숫자를 보는 논의로 바뀝니다. 준비물이 완벽할 필요는 없습니다. 손으로 그린 스케치라도 모두가 같은 그림을 보고 이야기할 수 있게 해 주면 충분합니다.
결정 뒤에 기획자가 하는 일
회의에서 결론이 나도 그것을 기록하지 않으면 며칠 뒤 서로 다르게 기억합니다. 그래서 기획자는 회의가 끝나면 결정된 내용, 보류된 내용, 누가 언제까지 무엇을 할지를 정리해 공유합니다. 결정 사항은 기획서에도 바로 반영하고, 바뀐 부분을 표시해 둡니다. 특히 회의 중에 바뀐 수치나 규칙은 놓치기 쉬우니 기획서의 수정 이력을 꼼꼼히 남기는 습관이 중요합니다.
- 결정 사항: 무엇을 어떻게 하기로 했는지 한 줄씩
- 보류 사항: 더 확인이 필요한 질문과 답을 줄 사람, 기한
- 후속 작업: 담당자별 해야 할 일과 마감
- 변경된 문서: 수정한 기획서와 바뀐 위치
신입 기획자에게 처음 맡겨지는 일이 회의록 정리인 경우가 많은 것도 이 때문입니다. 회의록을 잘 쓰는 사람은 무엇이 결정이고 무엇이 의견인지 구분할 줄 알게 되고, 그 감각이 쌓이면 회의를 이끄는 기획자로 자랍니다. 회의에서 쓸 선택지와 근거를 만드는 연습이 필요하다면, SBS아카데미게임학원 게임기획 과정 상담에서 직접 써 본 기획서를 함께 보며 어떤 질문이 빠져 있는지부터 확인해 보시기 바랍니다.
자주 묻는 질문
신입 기획자도 회의에서 의견을 내도 되나요?
근거가 있는 의견이라면 환영받는 경우가 많습니다. 다른 게임 사례나 간단한 데이터처럼 의견을 뒷받침할 자료를 함께 준비하면 설득력이 커집니다.
회의에서 반대 의견이 나오면 어떻게 해야 하나요?
반대하는 이유를 먼저 정확히 듣고, 그 걱정을 해결할 수 있는 대안이 있는지 찾습니다. 그 자리에서 결론이 나지 않으면 확인할 내용과 다음 논의 시점을 정해 두는 것이 좋습니다.
가까운 캠퍼스에서 게임기획 알아보기
사는 곳과 가까운 캠퍼스를 고르면 수업 내용, 오시는 길, 상담 신청을 한 번에 볼 수 있습니다.