프로젝트를 시작하기 전에 디자인 문서가 필요한 이유

디자인 문서는 무엇을 만드는지, 왜 만드는지, 어떻게 작동할지를 설명하는 서면 계획입니다. 사용자 매뉴얼이 아닙니다. 태스크 목록도 아닙니다. 만들기 시작하기 전에 이루어지는 사고 과정입니다. 핵심적으로 디자인 문서는 세 가지 질문에 답합니다. 어떤 문제를 해결하고 있는가? 제안된 해결책은 무엇인가? 고려한 트레이드오프와 대안은 무엇인가? 나머지 모든 것, 즉 기술적 세부 사항, 범위 경계, 일정 추정치는 이 세 가지 질문에 달려 있습니다. 디자인 문서는 업계에 따라 다른 이름으로 불립니다. 소프트웨어 팀은 기술 설계 문서 또는 RFC라고 부릅니다. 게임 개발자는 게임 디자인 문서를 작성합니다. 제품 팀은 제품 요구사항 문서를 작성합니다. 형식은 다르지만 목적은 항상 같습니다. 계획을 머릿속에서 꺼내 다른 사람이나 미래의 자신이 읽고 이해할 수 있는 문서로 만드는 것입니다.

직관에 반하는 것처럼 느껴집니다. 만들기 시작하고 싶습니다. 아이디어가 머릿속에 명확합니다. 문서를 작성하는 것은 속도를 늦추는 쓸모없는 일처럼 느껴집니다. 그래서 건너뛰고 바로 구현으로 뛰어듭니다. 2주 후, 쉬울 것이라고 가정했던 기능을 아키텍처가 지원하지 않는다는 것을 깨닫습니다. 또는 팀원이 접근 방식을 적어두지 않아서 그 접근 방식에 모순되는 것을 만들었습니다. 또는 생각하지 못했던 디자인 결정에 부딪혀 이제 리팩토링해야 합니다. 디자인 문서는 이러한 문제들이 실제 시간을 낭비하기 전에 포착합니다. 무언가가 어떻게 작동해야 하는지 적어두면 세부 사항을 생각하지 않을 수 없습니다. 엣지 케이스를 발견합니다. 의존성을 알게 됩니다. "간단한" 기능이 실제로 세 가지 다른 시스템의 변경이 필요하다는 것을 깨닫습니다. 디자인 문서를 작성하는 데 드는 시간은 항상 문서가 잡아냈을 문제를 해결하는 데 드는 시간보다 적습니다. 가깝지도 않습니다. 몇 시간의 작성으로 몇 주의 재작업을 절약할 수 있습니다.

엄격한 템플릿이 필요하지는 않지만 좋은 디자인 문서는 보통 이러한 영역을 다룹니다. 개요부터 시작하세요. 이 문서가 무엇을 다루고 왜 중요한지 설명하는 한두 단락. 누구든 이 섹션을 읽고 범위를 이해할 수 있어야 합니다. 다음으로 문제를 정의하세요. 무엇이 고장났거나, 없거나, 필요한가? 구체적으로 하세요. "사용자에게 더 나은 검색이 필요합니다"는 모호합니다. "현재 목록 뷰가 필터링이나 정렬을 지원하지 않아 사용자가 과거 프로젝트를 찾을 수 없습니다"는 유용합니다. 그런 다음 제안된 해결책을 설명하세요. 이것이 문서의 핵심입니다. 무엇을 만들 계획인지, 어떻게 작동할지, 사용자 경험이 어떻게 보이는지 설명하세요. 팀의 다른 사람이 이 설명만으로 구현할 수 있을 만큼 충분한 세부 사항을 포함하세요. 고려한 대안에 대한 섹션을 추가하세요. 어떤 다른 접근 방식을 평가했나요? 왜 이것을 선택했나요? 이것은 당신의 추론을 보여주고 미래의 독자들이 결정을 이해하는 데 도움이 됩니다. 마지막으로 미해결 질문과 범위 외 항목을 나열하세요. 의도적으로 하지 않기로 결정한 것은 무엇인가요? 아직 논의가 필요한 것은 무엇인가요? 이것은 범위 팽창을 방지하고 문서가 다루는 것과 다루지 않는 것에 대해 솔직하게 유지합니다.

디자인 문서는 한 번 작성하고 잊어버리는 것이 아닙니다. 최고의 디자인 문서는 프로젝트와 함께 발전합니다. 만들면서 배우게 됩니다. 일부 가정이 틀린 것으로 판명될 것입니다. 계획의 일부가 바뀔 것입니다. 그것은 완전히 정상입니다. 문서는 그 변화를 반영해야 합니다. 무엇이 바뀌었고 왜 바뀌었는지 메모를 추가하세요. 더 이상 현실과 일치하지 않는 섹션을 업데이트하세요. 수정된 결정에 표시하세요. 이것은 디자인 문서를 프로젝트 역사로 만듭니다. 6개월 후 누군가 "왜 이런 방식으로 만들었나요?"라고 물을 때 답은 문서에 있습니다. 몇 달 전의 대화를 기억하는 사람에게 의존할 필요가 없습니다. 핵심은 문서를 쉽게 업데이트할 수 있게 만드는 것입니다. 실제 프로젝트와 단절된 도구에 있다면 아무도 업데이트하지 않을 것입니다. 태스크와 일정 바로 옆에 있다면 업데이트가 자연스러운 워크플로우의 일부가 됩니다. IndieDevBoard는 프로젝트 안에 있는 구조화된 섹션이 있는 디자인 문서 기능을 포함하므로 명세가 그것이 설명하는 작업에 가깝게 유지됩니다.

게임 개발을 하고 있다면 이것이 일반적으로 GDD라고 불리는 게임 디자인 문서와 어떻게 관련되는지 궁금할 수 있습니다. 관련이 있지만 다릅니다. GDD는 게임에 특화되어 있습니다. 일반적으로 게임 개념, 메카닉, 스토리, 레벨 디자인, 아트 방향, 오디오, UI 등을 다룹니다. 게임의 성경입니다. 게임에 관한 모든 것이 GDD로 설명될 수 있어야 합니다. 더 넓은 의미의 디자인 문서는 모든 프로젝트나 기능에 관한 것입니다. 게임 내의 단일 기능, API 디자인, 웹사이트 재설계, 또는 새로운 프로세스를 설명할 수 있습니다. 더 집중적이고 보통 GDD보다 짧습니다. 실제로 많은 게임 팀이 둘 다 사용합니다. GDD는 고수준의 비전 문서입니다. 개별 디자인 문서는 전투 시스템, 인벤토리, 또는 멀티플레이어 네트워킹 레이어와 같은 게임 내의 특정 시스템이나 기능을 다룹니다. GDD는 "게임에 인벤토리 시스템이 있다"고 말합니다. 디자인 문서는 인벤토리 시스템이 정확히 어떻게 작동하는지, 데이터 모델이 어떻게 보이는지, 다른 시스템과 어떻게 상호작용하는지 설명합니다.

첫 번째 시도에서 완벽한 디자인 문서를 작성할 필요가 없습니다. 기본부터 시작하세요. 무엇을 만들고 왜 만드는지 적으세요. 유용할 만큼 충분한 세부 사항으로 해결책을 설명하세요. 확실하지 않은 것에는 미해결 질문을 추가하세요. 더 익숙해질수록 자연스럽게 더 많은 구조를 추가하기 시작할 것입니다. 얼마나 많은 세부 사항이 충분한지 감이 생길 것입니다. 어떤 섹션이 프로젝트 유형에 가장 중요한지 알게 될 것입니다. 중요한 것은 시작하는 것입니다. 한 시간이 걸리는 대략적인 디자인 문서는 절대 작성하지 못하는 완벽한 문서보다 무한히 더 유용합니다. 미래의 자신과 팀원들이 감사할 것입니다.