[TIP58] 빙글빙글 돌아가는 기획자의 하루

※ 오늘의 로딩팁은 PC 버전에 최적화 되어있습니다. 웹에서 보기

내가 기획한 시스템이 만들어지고 배포되는 과정

친구들 안녕? 내가 게임 기획자를 지망할 때 가장 궁금했던 거는 기획서는 썼는데, 그래서 이게 어떤 과정을 거쳐 게임에 적용되는 것인지였어. 오늘은 게임이 개발되는 프로세스에 대해 간단히 짚어 보려고 해. 시스템 기획자의 입장에서 바라본 프로세스야!

1. 기획서 작성

1) 컨셉 기획서 작성

어떤 시스템 또는 컨셉을 기획할 것인지 간단히 작성해서 공유해. 이 때는 시스템의 의도와 목적, 기능, UI/레이아웃, 참고 레퍼런스가 포함되지. 데이터 테이블과 상세한 기능 플로우 및 예외 처리는 포함하지 않아. 자세하진 않더라도 대~충 어떤 것을 만들려고 하는지 보는 사람이 모두 '싱크'를 맞춰야 하기 때문에 시각화 된 기획서를 작성하는 것이 필요해. 같은 것을 상상했다고 생각했는데 막상 까보면 전혀 다른 시스템을 머릿속에 그리고 있을 때도 많거든.

2) 검토

선임 기획자에게 기획 내용이 적정한지 검토를 받아. 앞서 언급했듯 싱크를 맞추기 위한 작업(선임 기획자가 해당 시스템을 제대로 이해한 게 맞는지 확인)이 주가 돼. 의도와 목적, 플로우, 추후 운영 방식, 추가되거나 제거되었으면 하는 기능들에 대한 검토가 이루어 지는 과정이야.

3) 검토 내용 반영

피드백 받은 내용을 문서에 반영해야겠지? 선임 기획자를 설득하여 이해시켜야 할 수도 있고 선임 기획자의 의견에 쉽게 납득하여 문서를 고치게 될 수도 있어. 내가 주니어일 때 당시 PD님에게 가르침 받았던 것은 "피드백 받은 '그 문장' 하나 만을 변경하지 말고 필요하다면 새로 써라!" 라는 것이었어. 나는 이 조언이 아직까지도 업무를 할 때 큰 영향을 미치고 있어. 선임 기획자가 피드백 해 준 내용 하나 만을 반영하면 요상한 모양새가 될 때가 굉장히 많거든. 전체적으로 다시 살펴보고, 필요하다면 과감하게 다 뜯어야 해. 처음부터, 새로 써야할 때도 생길 수 있어 반영을 다 하고 나면 다시 검토를 받아. 앞의 2번-3번의 과정을 반복해.

4) 상세 기획서 작성

이제 본격적인 시스템 기획서를 작성해야지! 시스템이 잘 만들어진 것과는 별개로 좋은 시스템 기획서는 개발자가 찾아 오지 않는 기획서야. 간단한 개요와 상세 플로우, UI/UX, 데이터 테이블과 예외 처리를 모두 포함해야 해. 상세 기획서를 쓰다보면 컨셉 기획서 단계에서 이미 검토 받은 내용을 엎어야 할 때가 의외로 있어. 이 때는 선임 기획자와 논의하여 결정해.

5) 또 다시 검토

다시 검토를 받아야겠지?

뒷단계인 기획리뷰를 진행할 수 있는 수준의 기획서가 될때까지 ②~⑤를 반복한다고 보면 돼.

2. 기획 리뷰 진행

6) 기획 리뷰

이제는 작성한 기획서를 가지고 기획 리뷰를 진행해. 기획 리뷰는 본인의 기획서 내용을 담당 프로그래머, QA, UI 기획자에게 설명하는 자리야. 회의실에 모여 기획서 내용을 설명한 후 질의를 받지. 요청이나 제안이 오기도 해. 이를테면 QA로부터 테스트에 필요한 치트 개발을 함께 요청받을 수도 있고, 프로그래머는 더 나은 개발 방식을 제안하기도 하지.

1단계 기획서 작성이 제대로 되지 않은채로 기획리뷰에 들어가면 이런 참사가 발생한다.

7) 상세 기획서 수정

기획 리뷰에서 나온 내용을 바탕으로 기획서를 다시 수정해. 기획 리뷰에서 많은 사람들이 이해하지 못했던 부분이 있다면 좀 더 이해가 쉽도록 구성을 변경하기도 하고, 예시를 첨부하기도 하지. 질문에 답하는 과정에서 기획서에 누락 된 내용을 찾을 수도 있지. 기획리뷰에서 나온 의문점이나 빈 부분등을 모두 반영한다고 보면 돼!

3. 개발 협업

8) 데이터 테이블 전달

샘플 데이터를 넣어 데이터 테이블을 개발자에게 전달해. 데이터를 관리하는 담당자가 따로 배정되어있다면 테이블 구조 및 활용에 대한 인수 인계가 필요하지. 만약 데이터를 작성하는 입장에서 테이블 구조가 번거롭거나 기존 규칙과 다르다면 테이블 구조 변경을 요청받을 수도 있어.

9) 개발 대응

본격적으로 개발이 시작되면 각종 요청에 대응해야 해. 중간 중간 질문을 하러 오기도 하고, 작업하다 보니 이런이런 방식이 더 편하겠다며 데이터 테이블 구조 변경을 (또) 요청하기도 해. 샘플 데이터를 더 다양하게 요청하기도 하지.

10) TC 작성

개발 된 시스템을 대상으로 테스트 할 항목을 작성해. TC는 QA만 작성하는 것이 아니야. 어떤 항목을 중점적으로 테스트 해야 하는지, 어떤 항목이 '반드시' 테스트가 되어야 하는지 등을 포함하면 좋아. 기획자 본인이 해당 시스템을 가장 잘 아는 사람이기 때문에, 기획자가 작성한 TC를 바탕으로 테스트가 꼭 필요해.

11) 개발 테스트

작성한 TC를 기반으로 테스트를 진행해. 테스트를 하다보면 기능은 잘 구현되었는데 어색하게 느껴진다거나 불편한 부분을 찾을 수도 있어. 필요하다면 개선해야겠지? 다만 이 단계에서는 볼륨이 아주 큰 수정은 이루어질 수 없어. 개선 사항은 중요도 및 볼륨에 따라 일정이 추후로 잡히기도 하고, 즉시 수정으로 잡힐 수도 있어. 연차가 쌓이면 개선의 볼륨이 어느 정도인지 알 수 있지만, 초반에는 잘 모를 수 있으니 선임 기획자 및 담당 개발자와 논의가 필요해.

12) 데이터 작성

실제 라이브에 들어갈 데이터를 작성해. 데이터를 본인이 작성한다면 '밸런스 기획'이 필요할 수도 있지. 밸런스 기획 또는 콘텐츠 기획자가 있다면 다른 파트에서 진행해.

13) 테스트

실 데이터를 기반으로 재테스트를 진행해. 샘플 데이터로는 잘 동작했는데 실제 데이터로는 동작하지 않는 경우가 생각보다 상당히, 자주 발생해.

4. 업데이트 대응

14) 공지 및 개발자노트 내용 검토

기획자 본인이 이 시스템을 가장 잘 아는 사람이라는 것, 다시 한번 강조할게. 운영 팀에서 공지, 가이드, 개발자노트 등을 작성하여 PM을 통해 전달받으면 해당 내용이 모두 올바르게 작성되어 있는지 검토해야 해. 본인이 강조하고 싶은 이 시스템의 재미나 목적 등을 포함해 달라고 요청할 수도 있어.

<신의 탑 : 새로운 세계> 개발자노트

개발자 노트는 보통 디렉터 명의(?)로 나오지만, 실제 세부 내용들은 담당 기획자들이 확인하고 기입한다.

15) 업데이트 당일 점검 대응

점검 중에는 유저들이 접속하지 못하도록 한 후, 게임 전체 플로우에 대한 테스트를 진행하곤 해. 이 때 문제가 발생하면 문제에 대응해야 하지. 점검 내 테스트가 진행되지 않거나 문제에 모두 대응하지 못한 경우 점검이 연장돼(ㅠㅠ) 보통 이 단계에서 대응할 수 있는 것은 '데이터' 대응인데,. 시스템 기획의 경우 대부분 빌드 스펙이라 모바일의 경우 마켓 검수가 필요하거든. 시스템 자체에 문제가 있을 경우 빌드 업데이트가 필요하므로, 최악의 경우 시스템 자체의 오픈을 미루어야 할 수도 있어.

16) 라이브

서버가 오픈되고 유저들이 시스템을 이용하지. 욕이 있을 수도 있고 칭찬이 있을 수도 있어. 대부분의 케이스에서는 수명이 연장되지만... 그래도 열심히 읽어. 유저들의 반응을 읽고 동향을 파악하는 것은 중요해. 이슈가 발생 된 것 같은 조짐(?)이 보인다면 재빠르게 대응해야 하고 말이지. 점검 당일은 보통 큰 이슈가 없다고 선임 기획자에게 전달받기 전까지는 자리를 지켜야 해.