시스템 기획서는 게임 기획 문서 중 가장 '설계도'에 가까운 문서입니다. 프로그래머가 이 문서만 보고 기능을 구현하고, QA가 이 문서를 기준으로 테스트할 수 있어야 합니다. 출석 보상 시스템을 예로 들어 시스템 기획서를 구성하는 방법을 정리합니다.

시스템 기획서의 목표

좋은 시스템 기획서의 기준은 단순합니다. 읽는 사람이 질문하지 않아도 되는 문서입니다. 기획자가 머릿속으로 당연하게 여긴 부분이 문서에 빠져 있으면, 개발자는 추측해서 구현하거나 기획자를 찾아와 묻게 됩니다. 어느 쪽이든 시간이 들고 실수가 생깁니다. 그래서 시스템 기획서는 '재미있어 보이게'가 아니라 '빠짐없고 모호하지 않게' 쓰는 것이 목표입니다.

기본 문서 구조

모든 시스템에 모든 항목이 필요한 것은 아니지만, 이 틀을 기본으로 두고 필요 없는 항목을 지우는 방식이 빠뜨림을 줄입니다.

규칙은 조건과 결과로 쓴다

규칙 항목은 '무엇이 어떤 조건일 때 무엇이 된다'는 형태로 쓰는 것이 좋습니다. 문장 하나에 규칙 하나만 담고 번호를 붙이면 개발자와 QA가 '규칙 3번'처럼 정확하게 지칭할 수 있습니다.

• 나쁜 예: 매일 들어오면 보상을 준다.
• 좋은 예: 계정이 서버 기준 하루 중 처음 로그인하면 출석 일차가 1 증가하고, 해당 일차의 보상을 받을 수 있는 상태가 된다.
• 좋은 예: 보상을 받지 않고 날짜가 바뀌면, 받지 않은 보상은 우편함으로 보낸다. (또는 소멸한다 — 둘 중 하나를 반드시 정한다)

두 번째 좋은 예처럼 기획자가 결정해야 하는 부분을 열어 두지 않는 것이 중요합니다. 결정하지 않은 내용이 있다면 '미정'으로 표시하고 언제까지 정할지 적어 둡니다.

순서도와 예외 처리

순서도(플로우차트)는 시스템이 어떤 순서로 판단하고 움직이는지를 도형과 화살표로 보여 줍니다. 마름모는 판단(예·아니오), 사각형은 처리, 화살표는 흐름입니다. 글로 쓰면 길어지는 분기도 순서도로 그리면 한눈에 보이고, 빠진 경로도 쉽게 찾을 수 있습니다.

1. 정상 흐름을 먼저 그립니다. 접속, 출석 확인, 팝업 표시, 보상 수령까지 한 줄로 이어 봅니다.
2. 판단 지점마다 '아니오'의 경로를 그립니다. 이미 출석했다면, 보상을 이미 받았다면 어떻게 되는지 그립니다.
3. 시간과 관련된 예외를 점검합니다. 자정 직전에 접속해 자정 이후에 수령 버튼을 누르면 어느 날짜로 처리할지 정합니다.
4. 자원 관련 예외를 점검합니다. 인벤토리가 가득 찼을 때, 보상 테이블에 데이터가 없을 때의 동작을 정합니다.
5. 통신 관련 예외를 점검합니다. 수령 중 연결이 끊기면 보상이 중복되거나 사라지지 않도록 처리 방식을 적습니다.

데이터 테이블과 연결하기

시스템 기획서는 데이터 테이블과 한 세트입니다. 문서에는 규칙을, 테이블에는 바뀔 수 있는 값을 둡니다. 출석 보상의 내용이나 주기를 문서에 직접 적어 두면 값이 바뀔 때마다 문서를 고쳐야 하지만, 테이블로 분리하면 기획자가 값만 바꿔도 됩니다. 문서에서는 '보상 내용은 출석 보상 테이블을 따른다'고 적고 테이블 구조를 함께 설명합니다.

문서를 완성하면 개발자 입장에서 처음부터 끝까지 읽으며 '이 상황에서는 어떻게 되지?'라는 질문이 떠오르는 곳을 표시해 보세요. 그 질문들이 문서에 아직 빠진 부분입니다. SBS아카데미게임학원 시스템기획 과정은 기능 명세서 구조, 플로우차트, 예외 처리 정의, 데이터 테이블과 스키마 설계를 거쳐 시스템 기획서를 포트폴리오로 완성하는 과정입니다.

자주 묻는 질문