이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
기획 문서를 작성할 때 가장 중요하게 생각하는 건 누가 읽고 무엇을 결정하기 위한 문서인지 먼저 정의하는 것입니다. 이 두 가지가 명확하면 어떤 정보를 얼마나 담을지 기준이 생깁니다. 인턴 때 기획서를 처음 쓸 때 배경 설명을 너무 길게 쓴 적이 있었는데, 결정권자는 배경보다 선택지와 근거를 먼저 보고 싶어 한다는 피드백을 받았습니다. 그 이후로 결론을 먼저 쓰고 근거를 뒤에 배치하는 방식을 씁니다. 문서의 길이보다 읽는 사람이 원하는 곳을 빠르게 찾을 수 있는지가 더 중요합니다.
섹션 제목을 질문 형태로 쓰면 독자가 원하는 정보를 빠르게 찾는 데 도움이 됩니다. 기획 문서는 작성자의 생각을 정리하는 것이 아니라 읽는 사람의 판단을 돕는 도구라는 관점으로 씁니다.
기획 문서를 쓸 때 제가 신경 쓰는 것은 정상 흐름만이 아니라 예외 상황까지 적는 것입니다. 처음 기획서를 쓸 때 잘 풀리는 경우만 담았더니, 개발 단계에서 '입력이 잘못되면 어떻게 하느냐' 같은 질문이 쏟아져 그때마다 다시 확인해야 했습니다. 그래서 저는 이번에 다룰 범위와 다루지 않을 범위를 분명히 나누고, 오류나 예외 상황을 어떻게 처리할지까지 함께 적는 것이 필요하다고 봤습니다. 범위가 흐리면 좋은 의도의 추가들이 쌓여 일정이 무너집니다. 예외를 빠뜨리면 개발 중에 발견해 일이 꼬입니다. 기획 문서는 기능 목록을 적는 것이 아니라, 경계와 예외까지 분명히 해 재확인 비용을 줄이는 것이라고 생각합니다. 그래서 저는 정상 흐름만큼 예외 처리를 꼼꼼히 적습니다.
기획 문서에서 제가 어렵게 느낀 것은 문서와 실제가 어긋나는 순간입니다. 진행 중 기능이 바뀌었는데 문서를 그대로 두면, 나중에 그것을 믿고 본 사람이 잘못된 기준으로 일하게 됩니다. 한 번 어긋나면 아무도 문서를 신뢰하지 않습니다. 그래서 저는 변경이 생길 때마다 문서를 고치고, 무엇을 왜 바꿨는지를 이력으로 남기는 것이 필요하다고 봤습니다. 그래야 누가 봐도 최신 기준이 무엇인지 알 수 있습니다. 또 변경 이력이 있으면 '왜 이렇게 정했지'를 다시 논의하는 일도 줄었습니다. 기획 문서는 한 번 잘 쓰는 것보다 현실과 계속 맞춰 살아 있게 유지하는 것이 더 중요했습니다. 관리되지 않는 문서는 오히려 혼란의 원인이 됩니다. 그래서 저는 문서를 고칠 때 이유를 함께 남깁니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 에피드게임즈 게임 기획 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.