2. 실무 게임의 개발 과정 흐름

개발 프로세스

게임 개발은 장르와 내부 프로세스에 따라 개발 프로세스가 다르지만 대략적인 개발 과정은 비슷한 형태를 가진다. 프로젝트의 상황에 따라 다양한 상황이 발생할 수 있기 때문에 아래 내용은 참고만 하고 상황에 따라 유동적으로 대응할 필요가 있다

※. 프로젝트에 따라 다르지만 전반적인 개발 프로세스의 단계별 업무 진행 방식은 비슷하다. 또한 담당 업무에 따라 협업 파트가 많기 때문에 상황에 맞춰 유연하게 대응할 필요가 있다.

<개발이 완료되고 프로젝트 배포(또는 업데이트)까지 많은 과정이 있지만 실제 그렇게 복잡한 과정은 아니다.>

 

기획 회의

무엇을 만들지 회의하고 개발 스펙을 산정한다. 주로 일정 및 프로젝트(콘텐츠) 스펙이 거론되며 무엇을 만들지 어떻게 만들지에 대한 아이디어와 담당자 할당으로 진행된다.

-. 나는 이것을 업무 오더(Order)라 부르며, 대부분의 오더는 명확하지 않거나 대략적인 내용으로 설명되는 경우가 많다. (ex : 아이템 강화 시스템을 추가합시다 -> 오더 끝)

 

스펙 기술서

나는 기획서 작성 이전에 별도의 스펙 기술서를 작성하는데 이는 대부분 오더는 구체적인 내용을 포함하거나 오더를 지시한 사람의 입장에서도 아직 구체화되지 않은 내용을 전달할 때가 많기 때문이다. 사람은 같은 단어를 듣더라도 사람마다 생각이 각자 다르기 때문에 회의 이후 간단하게 스펙을 정리하는 기획서의 뼈대를 잡는 문서를 작성 후 기획팀 또는 상급자와의 협의 과정을 선호한다.

-. 스펙 기술서 과정은 향후 커뮤니케이션 비용을 상당히 줄일 수 있다. 미리 어떠한 것을 만들지 대략적인 정보를 정리하고 확인 과정을 통해 기획 방향을 잘못 설정할 확률을 줄여줄 수 있기 때문이다.

-. 스펙 기술서를 통해 새로운 아이디어가 생기거나 기존 오더의 논리적 오류를 미리 검증할 수 있다.

※. 때로는 기획회의 이전에 스펙 기술서를 우선 작성하고 이를 토대로 회의를 진행하는 경우도 있다. 눈으로 볼수 있는 대상이 있는 상태의 회의가 아무것도 없이 대화로 진행되는 회의보다 효율적이다.

​

▶ 스펙 기술서란?​

스펙 기술서는 매우 효과적인 기획 문서 초안 작업 문서이다. 별도의 양식에 따라 작성하기 보다는 오더 또는 자신의 생각을 대략적으로 표현하는 정도로 마무리하면 좋다. 이러한 스펙 기술서는 다른 기획자가 모두 “주제”에 대하여 명확하게 인지할 수 있어 보다 효율적인 회의 진행이 가능하다.

​

A. 회의 또는 오더의 스펙 정보를 수집해라

B. 프로젝트 스펙을 정리하고 대략적으로 어떠한 형태로 게임 내부에서 작동하는지 설명한다.

C. 스펙 기술서를 기반으로 논리적(정책, 룰의 충돌, 다른 콘텐츠와의 연계성) 문제가 없는지 검토

D. 문제점과 질문을 따로 정리하여 기획 리뷰 진행

※. 스펙 기술서를 작성하다 보면 최초 제안된 방향성으로 개발되었을 경우 예상되는 다양한 문제점을 확인할 수 있다.

<과거 모 게임의 콘텐츠도 스펙 기술서를 이용하여 커뮤니케이션 비용을 줄여 매우 빠르게 개발 되었다.>

 

기획서 작성

프로젝트 스펙과 방향성이 정리되었다면 개발에 필요한(아트 리소스 포함) 상세 기획서를 작성한다. 기획서는 프로젝트에 따라 다양한 내용을 포함해야 하는데 개발에 참여하는 직군에 따라 내용에 차이가 있다.

※. 모든 기획서가 아래 정보를 모두 포함하는 것이 아니다. 프로젝트에 따라 포함되어야 하는 내용이 다르기 때문에 각 문서 작성시에 필요한 정보만을 기획서에 첨부해야 한다.

​

▶ 서버 & 클라이언트

-. 대부분의 시스템 기획 내용으로 데이터 구조 및 프로젝트에 사용되는 규칙 정리

​

▶ 컨셉(아트)

-. 화면에 필요한 리소스 목록 및 컨셉 정보를 포함하여 리소스 제작에 필요한 정보를 정리

​

▶ UI

-. UI 프레임 및 UI Flow 정보를 포함하여 UI 구성 정보를 정리

​

▶ 레벨

-. 레벨 구성에 필요한 임시 레벨 작업 및 구역 내 필요한 트리거 정보를 정리

※. 기획서에는 생각보다 많은 정보가 포함된다. 기획서 작성의 상세 내용은 별도 문서를 통해 다룬다.

 

개발 리뷰

기획서 작성이 완료되었다면 개발에 필요한 담당자에게 문서를 공유하고 소집하여 프로젝트에 대한 설명을 진행한다. 나는 이 과정을 개발 리뷰가 아닌 기술 조언을 위한 자리라고 자주 이야기하는 편인데 이는 기획서대로 만들어야 한다는 내용을 전달하기 보다는 더 효율적인 개발 방식 또는 새로운 논리적 오류 검토 및 기술 구현 가능 여부 등 다양한 의견을 수렴하기 위한 회의라 생각해서이다.

-. 기획은 개발에서 보스가 아니다. 기획자는 팀이 필요하며 자신의 프로젝트에 기여하고 있다는 심리적 안정감을 제공해야 할 의무가 있다. 기획자의 지시에 따라 개발하는 것이 아닌 함께 만들어 간다는 느낌을 전달하자.

-. 개발 리뷰는 상황에 따라 다양한 상황에 직면하게 된다. 인간 관계, 개인 성격, 시스템의 이해도 등 다양한 변수가 있다. 매끄러운 개발 리뷰를 위해서는 자신만의 스타일을 만들어야 한다.

-. 나는 개발 리뷰를 15분 내 끝낸다는 원칙을 가지고 있다. 집중할 수 있는 최대 시간이기도 하며, 프로젝트의 개발에 필요한 개념만을 전달하고 개발팀의 다른 의견이나 질문 시간에 더 많은 시간을 할애함으로써 개발팀의 프로젝트 참여를 적극적으로 유도한다.

※. 개발 리뷰에서 기획과 다른 중요한 요소로는 “개발 일정”이 항상 포함된다. 가급적 리뷰 이전에 프로젝트에 할당된 일정을 확인하도록 하자.

 

개발 리뷰 흐름	기획서 공유 -. 작성된 기획서는 개발 리뷰 이전에 담당자들에게 전달되어 미리 검토할 수 있도록 한다. 담당자 소집 -. 프로세스에 따라 프로젝트에 참여하는 담당자 또는 책임자를 소집하여 회의 진행 기획 리뷰 -. 프로젝트를 설명하고 무엇을 만들고자 하는지에 대한 기획서 기반 설명 과정 Q&A -. 프로젝트에 대한 질문 사항들을 문의하고 답변하는 시간
​ ​

<개발 리뷰는 기획서에 기반하는 단순 회의에 가깝다.>

▶ 기획서 수정

자신의 기획서가 정말 완벽하게 작성되었다면 가장 행복한 일이겠지만 대부분의 기획서는 다양한 이유에서 개발 리뷰를 통해 수정될 수 있다. (물론 개발 중에도 프로젝트 스펙이 변경되기도 한다.) 기획의 변동 사항은 향후 QA진행과 시간이 지났을 때 커뮤니케이션 오류가 발생되지 않도록 최신 정보로 갱신하는 습관을 가지는 것이 좋다.

프로젝트 개발

기획 리뷰 및 일정을 확인했다면 이제 본격적으로 직군 별 필요한 작업을 진행하게 된다. 프로젝트 규모에 따라 1일 ~ 6개월까지 다양한 시간이 소요될 수 있다. 또한 복합 콘텐츠의 경우 개발 리뷰에 포함되지 않은 다양한 추가 프로젝트 스펙이 별도 작업되어야 하는 경우도 있으며, 프로젝트 개발이 진행되는 동안 기획 담당자는 다양한 부가 업무를 수행하게 된다.

-. 기획서 작성이 완료되면 간혹 기획자의 역할이 끝났다고 생각하는 경우가 있는데 프로젝트 개발이 시작되면 본격적인 기획자의 업무가 시작된다. 개발간 발생되는 다양한 이슈를 확인하고 이를 해결하며, 필요할 경우 내부 프로세스에 따른 상급자와 협의를 통해 최대한 빠른 의사결정을 진행해야 한다. 개발 진행 사항을 살피고 팀의 목표를 달성하기 위해 다양한 역할을 수행해야 한다.

※. 한 명의 기획자가 1개의 프로젝트를 진행한다고 생각하면 안된다. 한 명이 두개 이상의 프로젝트를 진행하기도 하며, 연관 복합 콘텐츠의 연관 작업자가 되었을 경우 업무 범위는 더 넓어진다.

​

▶ 테스트용 데이터 준비

-. 일부 시스템 콘텐츠는 데이터 테이블을 사용하여 동작한다. 이러할 경우 프로그램팀 개발 진행을 위해 테이블 구성 및 데이터 작성이 필요하다.

​

▶ 기획 테스트(개발 버전 테스트)

-. 개발이 어느정도 진행되면 프로젝트의 윤곽이 나온다. 이때 버전을 기준으로 자신의 기획서에 따라 기능을 테스트하며 오류 또는 기획 의도와 다른 형태로 개발된 내용을 확인하여 목표한 형태로 개발 완료될 수 있도록 피드백

​

▶ 이슈 대응

-. 기획서를 기반으로 개발하지만 사람마다 이해하는 형태가 다르기 때문에 다양한 질문에 대응할 수 있어야 한다. 아울러 개발이 진행됨에 따라 실제 처리 불가능한 부분 또는 일정에 따른 스펙 감소등 다양한 문제를 해결해야 한다.

​

▶ 추가 기획 업무(복합 콘텐츠)

-. 레이드 던전과 같이 하나의 기획 콘텐츠가 아닌 시스템, 레벨, 몬스터, 전투, 밸런스 등 다양한 항목이 포함된 콘텐츠의 경우 개발 리뷰 이후 각 세부 항목에 대한 추가 기획이 필요하다.

※. 복합 콘텐츠의 경우 모든 기획이 완료된 이후 개발이 진행될 경우 오랜 일정을 소비하게 된다. 또한 변경되는 사항에 대응하기 어렵기 때문에 전체 프로젝트 스펙에 대한 개발 리뷰 이후 세부 항목을 추가로 기획하는 형태로 진행된다.

 

QA 및 프로젝트 배포

개발이 완료되면 QA를 통해 마지막 검증 과정을 거치며, 통과했을 경우 사용자에게 프로젝트가 오픈되게 된다. 이것은 매번 반복되더라도 매우 흥분되는 경험이다. 자신과 팀의 프로젝트에 대하여 사용자에게 검증과 평가받을 수 있는 기회는 당신의 생각보다 그다지 자주 발생하지 않는다. QA는 단순 오류 확인부터 콘텐츠 개선에 대한 다양한 의견을 받을 수 있으며, 프로젝트 마무리 단계이기 때문에 QA전 몇 가지 주의 사항을 숙지해야 한다.

​

▶ 정규 데이터

QA 시작 이전에 마지막 프로젝트 배포 버전의 모든 시스템 데이터는 정규 데이터(밸런스가 완료된)가 포함 되어있어야 한다. QA는 실 사용자의 경험을 기준으로 테스트되기 때문에 임시 데이터가 포함된 프로젝트 버전으로는 QA를 진행할 수 없다.

​

▶ 기획서 최신화

실무에서 개발이 진행중 다양한 변수로 인하여 기존 프로젝트 기획에 다양한 변화가 발생한다. 기획서는 이러한 변경 사항을 최신 정보로 갱신 되어있어야 한다. QA는 제공되는 기획서를 기반으로 품질을 체크하기 때문에 기획서와 배포된 프로젝트의 간극은 모두 오류로 처리한다.

​

▶ 수정 패치

QA의 테스트 범위는 매우 넓다. QA를 위한 프로젝트 버전이 배포된 이후에는 QA결과가 나오기 전까지 별도 수정 버전을 배포하지 않는다. 만약 시스템 테이블의 숫자를 단순 1 -> 2로 변경했다 하더라도 프로젝트 버전의 변경에 따라 기존에 진행된 모든 QA일련의 과정을 다시 수행해야 하기 때문에 QA진행중 새로운 버전 배포는 하지 않으며, 개발 버전에서 수정 사항을 반영 후 다음 QA에 재 배포해야 한다.

---

여러분들의 구독과 공감(♥)은 저에게 큰 힘이 됩니다.

질문이 있으시면 방명록에 글을 남겨주세요.

---