게임 디자인 문서(GDD) 버전 변경 시 영향받는 개발 태스크 AI 자동 추적 방법
게임 디자인 문서(GDD)가 바뀔 때 어떤 개발 태스크가 영향을 받는지 AI가 자동으로 찾아 우선순위와 담당자까지 갱신하는 방법을 설명합니다. Git diff, 문서 구조화, 작업 연결 규칙, 신뢰도 검토 절차로 누락과 과잉 알림을 줄입니다.
핵심 요약
게임 디자인 문서(GDD) 변경 사항을 Git diff로 수집한 뒤 변경된 기능, 수치, 규칙을 구조화하고 Jira나 Linear의 태스크와 연결하면 영향받는 작업을 AI가 자동으로 추적할 수 있습니다. 핵심은 AI가 모든 작업을 임의로 수정하게 하는 것이 아니라 문서 변경과 태스크 간의 근거, 영향도, 신뢰도를 함께 제시해 담당자가 빠르게 승인하도록 만드는 것입니다.
게임 디자인 문서 변경 영향 추적은 왜 어려운가?
GDD는 단순한 설명서가 아니라 기획, 클라이언트, 서버, 아트, QA가 공유하는 요구사항의 기준점입니다. 문제는 한 문장의 변경이 여러 팀의 작업에 동시에 영향을 준다는 데 있습니다.
예를 들어 다음과 같은 변경을 생각해 보겠습니다.
플레이어의 대시 무적 시간을 0.4초에서 0.2초로 줄이고 대시 중 피격 판정을 적용한다.
이 변경은 다음 작업과 연결될 수 있습니다.
| 변경 내용 | 영향받을 가능성이 높은 태스크 | 예상 영향 |
|---|---|---|
| 무적 시간 0.4초 → 0.2초 | 대시 상태머신 구현 | 파라미터 수정 및 밸런스 검증 |
| 대시 중 피격 판정 적용 | 전투 충돌 판정 | 로직과 피격 이벤트 수정 |
| 대시 생존성 감소 | 전투 밸런스 조정 | 적 공격 주기 재검토 |
| 피격 연출 변경 가능성 | 대시 피격 VFX, SFX | 신규 연출 또는 조건 수정 |
| 규칙 변경 | QA 대시 테스트 케이스 | 테스트 조건과 기대 결과 갱신 |
문서와 태스크가 서로 다른 도구에 있거나 담당자가 변경 내용을 수동으로 전달하면 다음 문제가 발생합니다.
- 이미 구현 중인 기능이 변경됐지만 기존 태스크가 그대로 남는다.
- 문서 변경과 관련 없는 작업까지 모두 재검토해 알림 피로가 커진다.
- QA 테스트 케이스가 최신 규칙을 반영하지 못한다.
- 일정 재산정이 늦어져 스프린트 후반에 작업이 몰린다.
따라서 필요한 것은 단순한 문서 요약이 아니라 버전 간 차이를 개발 작업 단위로 변환하는 영향 분석입니다.
AI는 GDD 변경과 개발 태스크를 어떻게 연결하는가?
안정적인 자동 추적은 다음 네 가지 데이터를 함께 사용합니다.
| 데이터 | 역할 | 예시 |
|---|---|---|
| 문서 diff | 무엇이 변경됐는지 확인 | dash.invulnerability: 0.4 → 0.2 |
| 문서 구조 | 변경 위치와 기능 범위 파악 | 전투 시스템 > 이동기 > 대시 |
| 태스크 메타데이터 | 작업의 담당 팀과 상태 확인 | Client, In Progress |
| 과거 연결 기록 | 비슷한 변경의 처리 방식 참고 | 대시 수치 변경 → QA-184 |
1. GDD를 구조화된 데이터로 관리한다
AI가 긴 문장 전체를 읽고 추측하게 만들기보다 중요한 설계 요소에 고유 ID를 부여하는 것이 좋습니다. GDD를 Markdown으로 관리한다면 기능별 섹션과 파라미터 이름을 일정하게 유지할 수 있습니다.
feature_id: combat-dash
name: 대시
owner_team: client
parameters:
invulnerability_seconds:
value: 0.4
unit: seconds
affects:
- damage_collision
- dash_state_machine
- combat_balance
rules:
- 대시 중에는 피격되지 않는다
qa_cases:
- dash-invulnerability-01실제 문서에서는 사람이 읽기 쉬운 설명을 유지하되 다음 항목을 함께 표시하는 방식을 권장합니다.
feature_id: 기능을 식별하는 고유 IDparameter_id: 변경 가능한 수치의 고유 IDowner_team: 기본 담당 팀depends_on: 선행 기능이나 시스템qa_cases: 연결된 테스트 케이스source_version: 변경이 승인된 문서 버전
2. 태스크에 문서 연결 정보를 저장한다
태스크 제목만으로 문서와 작업을 연결하면 동명이 기능이나 비슷한 작업을 구분하기 어렵습니다. 태스크에 다음과 같은 필드를 추가합니다.
task_id: COMBAT-241
title: 대시 상태머신 구현
team: client
status: in_progress
gdd_refs:
- combat-dash
- dash_state_machine
depends_on:
- COMBAT-198
acceptance_criteria:
- 대시 시작부터 종료까지 상태 전이가 동작한다
- 무적 시간 파라미터를 데이터 테이블에서 읽는다gdd_refs는 AI가 가장 먼저 확인하는 연결 고리입니다. 명시적인 연결이 없을 때만 기능명, 파라미터명, 태스크 설명의 의미 유사도를 보조적으로 사용합니다.
3. 변경을 의미 단위로 분류한다
모든 텍스트 변경이 동일한 영향을 만들지는 않습니다. AI 분석 결과에 변경 유형을 포함하면 우선순위를 정하기 쉽습니다.
| 변경 유형 | 예시 | 기본 영향도 |
|---|---|---|
| 수치 변경 | 공격력 100 → 80 | 중간 |
| 규칙 변경 | 대시 중 피격 가능 | 높음 |
| 상태 변경 | 기능을 보류 상태로 전환 | 높음 |
| 범위 변경 | 지원 플랫폼 추가 | 중간 |
| 표현 변경 | 설명 문장 수정 | 낮음 |
| 삭제 | 적 스폰 규칙 제거 | 높음 |
AI는 Git diff와 문서의 구조를 이용해 변경을 다음과 같은 분석 항목으로 변환할 수 있습니다.
change_id: GDD-1.5-combat-dash
source_version: 1.4
target_version: 1.5
feature_id: combat-dash
change_type: rule_and_parameter
summary: 대시 무적 시간이 감소하고 대시 중 피격 판정이 추가됨
changed_fields:
- invulnerability_seconds
- damage_collision
candidate_tasks:
- task_id: COMBAT-241
relation: direct
reason: 대시 상태머신이 무적 시간 파라미터를 사용함
impact: high
confidence: 0.96
- task_id: QA-184
relation: direct
reason: 기존 대시 무적 테스트의 기대 결과가 변경됨
impact: high
confidence: 0.93GDD 변경 영향 분석을 어떻게 구현할까?
가장 실용적인 방식은 규칙 기반 필터와 LLM 분석을 결합하는 것입니다. 규칙 기반 필터가 후보 태스크를 좁히고 LLM이 변경 의도와 영향 근거를 설명하도록 역할을 나누면 비용과 오탐을 줄일 수 있습니다.
flowchart LR
A[GDD v1.4] --> B[Git diff 수집]
B --> C[변경 요소 추출]
C --> D[태스크 후보 필터링]
D --> E[AI 영향 분석]
E --> F[신뢰도와 근거 생성]
F --> G[담당자 승인]
G --> H[태스크와 일정 갱신]1단계: 문서 버전 차이를 수집한다
문서 저장소에 Git을 사용한다면 기준 버전과 현재 버전 사이의 diff를 가져옵니다. 단순히 변경된 줄 수만 세지 말고 섹션, 기능 ID, 파라미터 ID를 함께 추출해야 합니다.
git diff v1.4..v1.5 -- docs/combat.md자동화 작업은 다음 정보를 보존해야 합니다.
- 이전 문서 버전과 새 문서 버전
- 변경된 섹션 경로
- 변경 전 값과 변경 후 값
- 문서 작성자와 승인 상태
- 분석 실행 시각
2단계: 규칙 기반으로 태스크 후보를 좁힌다
첫 번째 필터는 명시적 참조를 사용합니다. gdd_refs에 변경된 feature_id나 parameter_id가 있으면 직접 영향 후보로 분류합니다.
두 번째 필터는 의존성 그래프를 사용합니다. 직접 연결된 태스크가 서버 API, 데이터 테이블, QA 케이스에 의존한다면 해당 작업을 간접 영향 후보로 추가합니다.
세 번째 필터에서만 의미 검색을 적용합니다. 임베딩 기반 검색이나 LLM 분류를 사용할 때는 전체 태스크를 매번 전송하지 말고 제목, 설명, 수용 기준, 문서 참조 필드만 사용합니다.
candidates = explicit_refs(changed_features)
candidates += dependency_neighbors(candidates)
candidates += semantic_matches(change_summary, task_index)
candidates = deduplicate(candidates)3단계: AI가 영향도와 근거를 판정한다
AI의 출력은 반드시 구조화된 스키마로 제한하는 것이 좋습니다. 예를 들어 direct, dependency, semantic, none 중 하나의 관계만 선택하도록 하고 근거 문장을 필수로 받습니다.
relation: direct
action: update_acceptance_criteria
impact: high
confidence: 0.91
reason: 대시 피격 규칙이 변경되어 충돌 판정 로직의 수용 기준을 수정해야 함
recommended_changes:
- 대시 중 피격 이벤트 허용 조건 추가
- 무적 시간 0.2초 검증
requires_human_review: true신뢰도는 자동 실행 여부를 결정하는 참고값입니다. 확률처럼 해석하지 말고 조직 내부의 운영 지표로 사용해야 합니다. 예를 들어 다음 기준을 둘 수 있습니다.
| 신뢰도 | 처리 방식 |
|---|---|
| 0.90 이상 | 담당자 승인 대기 후 태스크 갱신 |
| 0.70~0.89 | 검토 큐에 등록하고 알림 발송 |
| 0.70 미만 | 자동 변경 없이 후보 목록에만 표시 |
자동 갱신 대상도 제한해야 합니다. 태스크 설명의 변경 제안, 관련 문서 링크 추가, QA 검토 태스크 생성은 비교적 안전하지만 담당자 변경, 완료 처리, 마감일 단축, 스프린트 이동은 반드시 사람의 승인을 거치게 합니다.
영향도를 일정과 우선순위에 반영하는 방법
영향 분석의 목적은 관련 태스크를 많이 찾는 것이 아니라 일정과 범위 판단을 빠르게 돕는 것입니다. 따라서 각 결과에는 최소한 다음 네 가지 정보가 있어야 합니다.
- 무엇이 바뀌었는가
- 어떤 태스크가 영향을 받는가
- 왜 영향을 받는가
- 언제까지 어떤 결정을 해야 하는가
간단한 우선순위 모델은 다음처럼 구성할 수 있습니다.
여기서 각 값은 0에서 1 사이로 정규화합니다. Scope는 영향을 받는 팀과 태스크 수를, Dependency는 선행 관계의 중요도를 Risk는 일정이나 품질에 미치는 위험을 나타냅니다. 이 수식은 정답을 계산하는 공식이 아니라 태스크 정렬을 위한 일관된 기준입니다.
예를 들어 다음과 같이 운영할 수 있습니다.
| 결과 | PM이 확인할 내용 | 권장 액션 |
|---|---|---|
| 높은 영향도 + 높은 신뢰도 | 현재 스프린트 작업이 규칙과 충돌하는지 | 태스크 갱신 및 담당자 확인 |
| 높은 영향도 + 낮은 신뢰도 | AI가 연결 근거를 충분히 찾았는지 | 기획자와 기술 담당자 공동 검토 |
| 낮은 영향도 + 높은 신뢰도 | 단순 수치나 문구 변경인지 | 문서 링크와 참고 메모만 갱신 |
| 간접 영향 후보 다수 | 의존성 그래프가 과도하게 넓은지 | 알림 범위와 기준 조정 |
알림은 변경 요약 중심으로 작성한다
알림 메시지에 GDD 전체 내용을 붙이면 담당자가 핵심을 놓치기 쉽습니다. 다음 형식을 사용하면 의사결정에 필요한 정보만 전달할 수 있습니다.
[GDD 영향 분석] combat-dash v1.4 → v1.5
변경: 무적 시간 0.4초 → 0.2초, 대시 중 피격 허용
영향 태스크: COMBAT-241, QA-184
영향도: High
권장 조치: 상태머신 수용 기준과 대시 테스트 케이스 갱신
근거: combat-dash.invulnerability_seconds, damage_collision
승인 필요: 클라이언트 담당자, QA 담당자이 메시지는 Slack, Microsoft Teams, Jira 댓글, Linear 업데이트 등 팀이 실제로 사용하는 채널로 보낼 수 있습니다. 단, 알림 전송 자체보다 분석 결과를 원본 태스크와 문서에서 다시 확인할 수 있게 링크를 남기는 것이 중요합니다.
자동 추적 시스템의 운영 규칙은 무엇인가?
문서 변경을 곧바로 일정 변경으로 취급하지 않는다
GDD가 수정됐다고 해서 모든 태스크의 마감일을 자동으로 바꾸면 운영 리스크가 커집니다. AI는 영향 후보와 예상 추가 작업량을 제시하고 PM 또는 담당 리드가 일정 변경을 승인하도록 설계해야 합니다.
분석 결과를 재현할 수 있게 저장한다
나중에 왜 특정 태스크가 영향받았는지 확인할 수 있어야 합니다. 다음 감사 로그를 남기는 것이 좋습니다.
- 분석에 사용한 GDD 버전
- 변경된 필드와 diff
- 검색된 태스크 목록
- AI 모델 버전과 프롬프트 버전
- 최종 승인자와 승인 시각
- 승인 후 실제로 수정된 태스크 필드
오탐과 누락을 측정한다
자동화 품질은 AI의 답변이 그럴듯한지보다 실제 업무 결과로 평가해야 합니다. 매 스프린트마다 다음 지표를 확인합니다.
| 지표 | 의미 |
|---|---|
| 영향 태스크 재현율 | 사람이 찾은 영향 태스크 중 AI가 찾은 비율 |
| 오탐률 | 영향 없음으로 판정된 후보의 비율 |
| 승인 소요 시간 | 알림부터 담당자 승인까지 걸린 시간 |
| 문서-태스크 불일치 수 | 스프린트 종료 시 남은 연결 오류 |
| 변경 후 재작업률 | 문서 변경을 놓쳐 다시 작업한 비율 |
초기에는 재현율을 높이는 데 집중하고 이후 오탐을 줄이는 순서가 현실적입니다. 다만 재현율을 높인다는 이유로 모든 태스크에 알림을 보내면 시스템이 빠르게 무시될 수 있으므로 팀별 임계값을 따로 조정해야 합니다.
도입 절차: 작은 범위에서 검증하기
- 전투나 인벤토리처럼 문서 구조와 태스크 연결이 비교적 명확한 기능 하나를 선택합니다.
- GDD에
feature_id,parameter_id,owner_team을 추가하고 관련 태스크에gdd_refs를 입력합니다. - 과거 문서 버전 3~5개를 사용해 변경 영향 분석을 재생합니다.
- 기획자, 프로그래머, QA가 실제로 영향받았다고 판단한 태스크와 AI 결과를 비교합니다.
- 오탐과 누락 사례를 분류해 프롬프트, 문서 규칙, 태스크 메타데이터를 수정합니다.
- 검증이 끝난 뒤 Slack 알림과 이슈 트래커 갱신을 제한적으로 활성화합니다.
- 담당자 승인 로그와 스프린트 지표를 기준으로 자동화 범위를 넓힙니다.
처음부터 모든 GDD를 연결하려 하지 않는 것이 좋습니다. 문서 ID와 태스크 메타데이터가 정리되지 않은 상태에서 AI만 추가하면 분석 결과를 신뢰하기 어렵기 때문입니다.
자주 묻는 질문(FAQ)
GDD가 Markdown이 아니어도 자동 추적할 수 있나요?
가능합니다. Notion, Confluence, Google Docs 등에서 변경 이력과 섹션 정보를 API로 가져올 수 있다면 동일한 구조를 만들 수 있습니다. 다만 버전 ID와 문서 섹션의 안정적인 식별자가 필요합니다.
AI가 태스크를 자동으로 수정해도 되나요?
문서 링크 추가나 검토 메모 작성처럼 되돌리기 쉬운 변경은 조건부 자동화를 적용할 수 있습니다. 마감일, 담당자, 우선순위, 완료 상태처럼 일정에 직접 영향을 주는 필드는 승인 단계를 두는 것이 안전합니다.
문서에 기능 ID를 넣을 수 없는 팀은 어떻게 시작해야 하나요?
우선 기능명, 시스템명, 파라미터명, 태스크 라벨을 표준화하고 기존 태스크에 문서 링크를 추가하는 것부터 시작합니다. 이후 반복적으로 등장하는 기능에 고유 ID를 부여하면 의미 검색 의존도를 줄일 수 있습니다.
정리
GDD 버전 변경 시 영향받는 개발 태스크를 AI로 추적하려면 문서 diff, 구조화된 기능 ID, 태스크 메타데이터, 의존성 정보를 함께 관리해야 합니다. 가장 안전한 운영 모델은 규칙 기반 후보 검색과 AI의 영향 분석을 결합하고 신뢰도와 근거를 표시한 뒤 사람이 일정 및 범위 변경을 승인하는 방식입니다.
이렇게 구축하면 문서 변경을 단순 공지로 끝내지 않고 클라이언트, 서버, 아트, QA의 실제 작업과 연결할 수 있습니다. 결과적으로 변경 누락을 줄이고 스프린트 계획과 협업 의사결정을 더 빠르게 만들 수 있습니다.
