기능·담당자·맥락으로 연결하는 게임 프로젝트 의사결정 그래프(Decision Graph) 활용법
게임 프로젝트의 결정이 기능, 담당자, 근거와 분리되면 일정과 스코프가 흔들립니다. Decision Graph로 의사결정 로그를 연결하고 변경 영향, 책임 범위, 협업 맥락을 추적하는 운영법을 단계별로 정리합니다.
TL;DR
Decision Graph는 게임 프로젝트의 기능, 의사결정, 담당자, 근거, 일정 항목을 노드와 관계로 연결하는 문서화 방식입니다. 핵심은 결정 하나에 고유 ID와 단일 책임자를 부여하고 해당 결정이 영향을 주는 기능과 근거를 연결하는 것입니다. 기능 변경이 발생하면 연결된 결정과 담당자, 일정, 리스크를 함께 검토해 변경 영향을 빠르게 판단할 수 있습니다.
게임 프로젝트의 의사결정 로그는 왜 금방 끊어지는가?
게임 개발에서 중요한 결정은 회의록, 기획서, 이슈 트래커, 메신저, 코드 리뷰에 흩어져 남습니다. 문제는 기록이 없는 것이 아니라 기록 사이의 관계가 사라진다는 데 있습니다.
예를 들어 인벤토리의 퀵슬롯을 4개로 제한했다고 가정해 보겠습니다.
기획서에는 결과만 있고 회의록에는 모바일 조작 영역을 지키기 위한 판단이었다는 근거가 남아 있을 수 있습니다. 개발자는 이 결정을 구현하지만 담당자가 바뀌면 왜 4개인지 다시 확인하기 어렵습니다. 이후 디자이너가 퀵슬롯을 6개로 늘리자고 제안하면 UI, 입력 방식, 튜토리얼, QA 범위를 모두 다시 조사해야 합니다.
이런 상황에서는 다음 질문에 답하기 어렵습니다.
- 이 기능은 어떤 결정을 전제로 만들어졌는가?
- 결정의 최종 책임자는 누구인가?
- 결정에는 어떤 사용자 테스트나 기술 검토가 근거로 사용되었는가?
- 결정을 바꾸면 일정과 스코프에 어떤 영향이 생기는가?
- 기존 결정을 대체한 새로운 결정은 무엇인가?
Decision Graph는 문서를 하나로 합치는 방식이 아닙니다. 기존 문서와 이슈를 유지하면서 항목 사이의 연결 관계를 명시하는 운영 모델입니다.
Decision Graph란 무엇인가?
Decision Graph는 프로젝트 데이터를 그래프로 보는 방법입니다. 각 항목은 노드가 되고 항목 사이의 의미 있는 연결은 엣지가 됩니다.
| 노드 유형 | 예시 | 반드시 기록할 항목 |
|---|---|---|
| 기능 | 인벤토리 퀵슬롯 | 기능 ID, 설명, 상태, 관련 마일스톤 |
| 결정 | 퀵슬롯을 4개로 고정 | 결정 ID, 결정일, 상태, 결정 내용 |
| 담당자 | 클라이언트 리드 | 이름, 역할, 책임 범위 |
| 근거 | 프로토타입 테스트 결과 | 링크, 결과 요약, 신뢰도 |
| 마일스톤 | M2 플레이어블 빌드 | 일정, 포함 범위, 완료 조건 |
| 리스크 | 모바일 입력 충돌 | 영향도, 대응 계획, 상태 |
노드 자체보다 중요한 것은 관계의 의미입니다.
| 관계 | 의미 | 예시 |
|---|---|---|
| depends_on | 기능이 결정을 전제로 함 | 퀵슬롯 UI → 슬롯 4개 고정 |
| owned_by | 결정의 책임자 연결 | 슬롯 4개 고정 → 클라이언트 리드 |
| supported_by | 결정의 근거 연결 | 슬롯 4개 고정 → 입력 테스트 |
| affects | 일정이나 리스크에 영향 | 슬롯 수 변경 → M2 일정 |
| supersedes | 기존 결정을 새 결정이 대체함 | 슬롯 4개 → 슬롯 6개 |
| conflicts_with | 서로 충돌하는 결정 | 자동 조준 허용 ↔ 정밀 조작 유지 |
flowchart LR
F["기능: 인벤토리 퀵슬롯"] --> D{"결정: 슬롯 4개 고정"}
D --> O["담당: 클라이언트 리드"]
D --> R["근거: 입력 충돌 테스트"]
D --> T["영향: M2 플레이어블 빌드"]이 구조를 사용하면 기능에서 결정을 거쳐 담당자와 근거, 일정까지 이동할 수 있습니다. 반대로 특정 결정에서 출발해 영향을 받는 기능과 리스크를 확인하는 것도 가능합니다.
어떤 항목을 Decision Graph에 포함해야 하는가?
모든 메모를 그래프에 넣으면 정보가 많아질 뿐 판단 속도는 빨라지지 않습니다. 다음 조건을 만족하는 항목부터 등록하는 것이 좋습니다.
- 기능 범위나 출시 일정에 영향을 주는가?
- 여러 직군의 작업 방식이나 결과물을 바꾸는가?
- 나중에 다시 이유를 확인할 가능성이 있는가?
- 되돌리는 데 비용이 큰가?
- 담당자 변경 후에도 유지되어야 하는가?
반대로 단순한 진행 상황이나 일회성 대화는 일반 작업 로그로 남겨도 충분합니다. Decision Graph에는 프로젝트의 방향과 의존성을 바꾸는 결정만 남기는 것이 핵심입니다.
결정 하나에 고유 ID를 부여한다
결정 ID는 제목보다 안정적이어야 합니다. 제목은 바뀔 수 있지만 ID는 변경 이력을 추적하는 기준이 됩니다.
DEC-014
기능: FEAT-022 인벤토리 퀵슬롯
제목: 퀵슬롯 수를 4개로 고정
상태: active
결정일: 2026-08-24
담당자: 클라이언트 리드
결정 내용: 모바일 화면에서 한 손 조작 영역을 유지하기 위해 퀵슬롯을 4개로 제한한다.
근거: TEST-031 입력 충돌 프로토타입 테스트
영향 마일스톤: M2 플레이어블 빌드결정 상태와 결정 버전을 분리한다
결정 상태는 현재 유효한지 나타냅니다.
권장 상태는 proposed, active, superseded, rejected, deprecated입니다.
결정이 바뀌었을 때 기존 기록을 덮어쓰면 과거에 왜 그런 선택을 했는지 확인할 수 없습니다.
기존 결정을 superseded로 변경하고 새 결정에 supersedes: DEC-014 관계를 추가해야 합니다.
Decision Graph를 어떻게 운영할까?
1단계: 기능 목록에서 결정 후보를 찾는다
먼저 기능 문서와 마일스톤 백로그를 기준으로 결정 후보를 찾습니다. 기능마다 다음 질문을 던지면 됩니다.
- 이 기능의 범위를 제한한 결정은 무엇인가?
- 구현 방식에 영향을 준 기술적 판단은 무엇인가?
- 이 기능이 취소되거나 변경되면 함께 바뀌는 작업은 무엇인가?
기능을 등록할 때부터 관련 결정 ID를 필수 필드로 두면 연결이 끊기는 문제를 줄일 수 있습니다.
아직 결정되지 않은 항목은 임시로 TBD를 사용하되 다음 결정 회의의 안건으로 등록합니다.
2단계: 결정을 원자 단위로 기록한다
하나의 결정 노드에는 하나의 판단만 담습니다.
나쁜 예시는 다음과 같습니다.
전투 카메라는 고정하고 조준 보정도 적용하며 보스전에서는 연출 카메라를 사용한다.
이 문장에는 카메라 위치, 조준 보정, 보스 연출이라는 세 가지 결정이 섞여 있습니다. 각각을 별도 결정으로 나누면 담당자와 근거, 변경 영향도 분리할 수 있습니다.
좋은 기록은 다음처럼 작성합니다.
- DEC-021: 일반 전투 카메라는 고정 시점으로 유지한다.
- DEC-022: 원거리 무기에는 조준 보정을 적용한다.
- DEC-023: 보스전 시작 시 연출 카메라로 전환한다.
이렇게 하면 DEC-022만 변경할 때 입력 시스템과 밸런스 담당자만 우선 검토할 수 있습니다.
3단계: 결정 내용과 근거를 분리한다
결정은 무엇을 선택했는지 기록하고 근거는 왜 선택했는지 기록합니다. 근거에는 문서 링크만 넣지 말고 결론을 한 문장으로 요약해야 합니다.
| 구분 | 예시 |
|---|---|
| 결정 | 퀵슬롯을 4개로 제한한다 |
| 근거 | 6개 슬롯에서 엄지 입력 충돌이 증가했다 |
| 자료 | TEST-031 프로토타입 결과 |
| 신뢰도 | 중간. 실제 기기 3종 검증 필요 |
| 재검토 조건 | 가로 화면 UI가 확정되거나 입력 방식이 변경될 때 |
근거는 플레이테스트, 성능 측정, 기술 검토, 사업 요구사항, 플랫폼 가이드라인처럼 확인 가능한 자료를 우선합니다. 개인의 선호를 근거로 사용할 수는 있지만 의견인지 사실인지 구분해야 합니다.
4단계: 담당자는 한 명으로 지정한다
결정에 여러 명이 참여할 수는 있지만 최종 책임자는 한 명이어야 합니다.
클라이언트팀, 기획팀, 전체와 같은 그룹명만 담당자로 지정하면 결정이 지연될 때 책임 범위를 확인하기 어렵습니다.
권장 구조는 다음과 같습니다.
- Owner: 최종 판단과 상태 업데이트를 담당하는 한 명
- Contributors: 조사와 검토에 참여한 사람들
- Approver: 예산, 출시 일정, 품질 기준처럼 승인 권한이 필요한 경우에만 지정
Owner가 회의에 참석하지 못했더라도 결정 노드를 확인하면 현재 상태와 다음 행동을 알 수 있어야 합니다.
5단계: 변경 요청이 들어오면 그래프를 따라 영향도를 조사한다
기능 변경 요청을 받으면 해당 기능에 연결된 결정부터 확인합니다. 그 다음 affects, depends_on, conflicts_with 관계를 따라가며 일정과 스코프를 검토합니다.
실무에서는 다음과 같은 간단한 영향도 점수를 사용할 수 있습니다.
각 항목을 1에서 5 사이로 평가합니다.
- AffectedFeatures: 영향을 받는 기능 수와 핵심도
- ChangeCost: 코드, 아트, QA, 문서 수정 비용
- ReleaseCriticality: 현재 마일스톤과 출시 일정의 긴급도
예를 들어 영향을 받는 기능이 3점, 변경 비용이 4점, 출시 중요도가 5점이면 영향도는 60점입니다. 점수 자체가 결정을 대신하지는 않지만 변경 요청을 같은 기준으로 비교하는 데 도움이 됩니다.
기능 변경 시 Decision Graph 검토 절차는 무엇인가?
다음 순서로 검토하면 회의 시간을 줄일 수 있습니다.
- 변경 대상 식별: 기능 ID 또는 결정 ID를 확정합니다.
- 직접 연결 확인: 관련 결정, 담당자, 근거, 리스크를 조회합니다.
- 하위 영향 추적: 영향을 받는 기능, 마일스톤, 테스트 케이스, 릴리스 조건을 확인합니다.
- 담당자 의견 수집: 각 노드의 Owner에게 예상 비용과 대체안을 요청합니다.
- 결정 갱신: 기존 결정을 유지할지, 새 결정으로 대체할지 기록합니다.
- 변경 전파: 기능 문서, 작업 항목, 테스트 계획의 연결 정보를 업데이트합니다.
변경을 승인했다면 기존 결정의 내용을 수정하는 대신 새 결정 노드를 생성하는 편이 안전합니다. 그래야 결정의 시간 순서와 책임 변화를 보존할 수 있습니다.
팀의 문서 도구에 Decision Graph를 적용하는 방법
전용 그래프 데이터베이스가 없어도 시작할 수 있습니다. 문서 도구, 이슈 트래커, 스프레드시트 중 하나를 기본 저장소로 정하고 각 항목에 고유 ID를 부여하면 됩니다.
최소 필드는 다음과 같습니다.
| 필드 | 목적 |
|---|---|
| ID | 다른 문서에서 참조하는 안정적인 키 |
| Type | Feature, Decision, Evidence, Risk 구분 |
| Title | 검색 가능한 짧은 이름 |
| Owner | 단일 책임자 |
| Status | 현재 유효성 |
| Rationale | 선택 이유 |
| Links | 관련 기능, 자료, 마일스톤 링크 |
| ReviewAt | 재검토 시점 또는 조건 |
운영 주기는 프로젝트 규모에 맞게 단순하게 정합니다.
- 매일: 새 결정과 변경된 상태를 기록한다.
- 주 1회: Owner가 없는 결정과 근거가 없는 결정을 확인한다.
- 마일스톤 시작 전: 스코프와 일정에 영향을 주는 active 결정을 검토한다.
- 마일스톤 종료 후: superseded 결정과 실제 결과를 연결한다.
특히 ReviewAt 필드는 중요합니다.
모든 결정을 영구적인 원칙처럼 다루지 않고 검증이 필요한 가설로 관리할 수 있기 때문입니다.
Decision Graph 운영에서 자주 생기는 문제
모든 대화를 결정으로 기록한다
대화량이 많아지면 핵심 결정이 묻힙니다. 실제 작업 방향, 비용, 일정, 품질 기준을 바꾸는 판단만 결정 노드로 승격하세요.
근거를 링크 하나로 끝낸다
링크만 있으면 문서를 다시 열어야 합니다. 근거의 결론과 검증 범위를 한두 문장으로 요약하고 원문 링크를 함께 남기세요.
담당자를 팀 단위로 지정한다
팀은 협업 단위이지 최종 책임자가 아닙니다. Owner를 한 명 지정하고 Contributors를 별도로 기록하세요.
기존 결정의 내용을 계속 덮어쓴다
변경 이력이 사라지면 회고와 분쟁 해결에 필요한 맥락을 잃습니다.
새 결정으로 대체하고 supersedes 관계를 연결하세요.
그래프를 별도 문서로 운영한다
그래프와 실제 작업 문서가 따로 놀면 중복 입력이 발생합니다. 기능 문서와 이슈에 결정 ID를 표시하고 결정 노드에서는 원문으로 연결되는 양방향 링크를 유지하세요.
자주 묻는 질문 FAQ
Decision Graph는 일반 의사결정 로그와 어떻게 다른가?
일반 로그는 결정의 시간 순서와 내용을 중심으로 기록합니다. Decision Graph는 여기에 기능, 담당자, 근거, 일정, 리스크 사이의 관계를 추가해 변경 영향을 추적합니다.
작은 팀도 Decision Graph를 사용해야 하는가?
가능합니다. 처음부터 복잡한 도구를 도입할 필요는 없습니다. 기능 ID, 결정 ID, Owner, 근거 링크, 상태 필드만 있는 표로 시작한 뒤 관계가 늘어날 때 확장하면 됩니다.
모든 결정에 승인자를 지정해야 하는가?
아닙니다. 출시 일정, 예산, 플랫폼 정책, 핵심 품질 기준처럼 팀 외부 영향이 큰 결정에만 Approver를 지정하는 것이 효율적입니다. 모든 결정에 승인자를 붙이면 일상적인 판단까지 병목이 될 수 있습니다.
마무리
Decision Graph의 목적은 문서를 많이 만드는 것이 아니라 결정의 맥락을 다시 찾는 시간을 줄이는 것입니다. 기능마다 관련 결정 ID를 연결하고 결정마다 단일 Owner와 검증 가능한 근거를 기록하면 변경 요청이 들어왔을 때 영향 범위를 빠르게 파악할 수 있습니다.
처음에는 가장 비싼 결정을 다섯 개만 골라 시작하세요. 결정 ID, 기능 링크, Owner, 근거, 재검토 조건을 꾸준히 유지하는 것만으로도 일정과 스코프가 흔들릴 때 팀이 같은 정보를 보고 판단할 수 있습니다.
