아이디어를 실행으로,
따라 하는 플레이북

0-1필수 도구 설치

훅은 Bash로, 설정은 Python으로 읽힙니다. Python이 없으면 모든 설정이 기본값으로 조용히 돌아가니 반드시 설치하세요.

winget install --id Git.Git -e
winget install --id Python.Python.3.12 -e
winget install --id jqlang.jq -e
# Claude Code 네이티브 설치
irm https://claude.ai/install.ps1 | iex
# 새 터미널을 열고 확인
git --version
python --version
claude --version

세 명령 모두 버전 번호를 출력하면 성공입니다.

0-2어디에 넣을지 고르기

아이디어마다 시작하는 곳이 다릅니다.

• A. 새 실험 레포 — 아이디어 3(2주 신작 검증). 템플릿을 그대로 복제합니다.
• B. 기존 Unity 프로젝트에 이식 — 아이디어 1·2·4·5·6. 운영 중인 레포에 별도 브랜치로 넣습니다.

# A. 새 실험 레포
git clone https://github.com/Donchitos/Claude-Code-Game-Studios.git C:\work\proto-merge
cd C:\work\proto-merge

# B. 기존 프로젝트에 이식 — 템플릿을 옆에 받아 두고 필요한 것만 복사
git clone https://github.com/Donchitos/Claude-Code-Game-Studios.git C:\work\ccgs-template
cd C:\work\our-rpg                      # Assets/ 가 있는 Unity 프로젝트 루트
git switch -c ccgs/pilot
Copy-Item -Recurse C:\work\ccgs-template\.claude .\.claude
Copy-Item C:\work\ccgs-template\CLAUDE.md, C:\work\ccgs-template\project.yaml, C:\work\ccgs-template\.worktreeinclude .

B라면 기존 .gitignore 끝에 CCGS 전용 항목을 덧붙입니다. .gitattributes(Git LFS 설정)는 덮어쓰지 마세요.

Add-Content .gitignore "`n# Claude Code Game Studios`n.claude/settings.local.json`nCLAUDE.local.md`nproject.local.yaml`nproduction/session-logs/`nproduction/session-state/`n.claude/agent-memory/`n.claude/worktrees/`n.scratch/"

0-3루트에서 첫 실행하고 /start

반드시 CLAUDE.md가 있는 폴더에서 띄웁니다. 하위 폴더에서 띄우면 훅·차단 규칙·승인 모드가 로드되지 않습니다.

claude

/start

1. "어디서 시작하나요?" — A는 B(막연한 아이디어) 또는 C(명확한 컨셉), B(이식)는 D(기존 작업 있음)를 고릅니다.
2. modes.rigor를 묻습니다 — 처음에는 minimal을 고르세요. 나중에 언제든 올릴 수 있습니다.
3. 얼마나 자주 확인받을지 묻습니다 — 익숙해지기 전까지 collaborative(단계마다 승인).

세션 시작 때 현재 브랜치와 최근 커밋이 출력되고, /start가 다음 단계 하나를 안내하면 훅과 설정이 정상입니다.

0-4엔진을 Unity로 고정

/setup-engine unity

Unity 버전을 확인해 CLAUDE.md와 project.yaml의 engine·specialists·commands를 채웁니다. 학습 데이터보다 최신 버전이면 웹에서 레퍼런스를 찾아 docs/engine-reference/에 정리합니다.

빌드 명령은 "묻고 정하는" 항목입니다. 우리 빌드 타깃(Android/iOS)과 Unity 에디터 경로를 직접 알려 주세요.

0-5안 쓰는 에이전트 덜어 내기

Unity만 쓴다면 Godot·Unreal 스페셜리스트 10명은 선택지만 늘립니다. 템플릿은 원래 지우고 더하라고 만든 것입니다. 팀 구성을 바꾸는 일이니 Claude에게 맡기지 말고 사람이 직접 지웁니다.

Remove-Item .claude\agents\godot-*.md, .claude\agents\unreal-specialist.md, .claude\agents\ue-*.md
(Get-ChildItem .claude\agents).Count   # 39가 나오면 정상

0-6비용·언어 설정

디렉터 3명은 Opus를 요청합니다. 처음엔 디렉터 리뷰를 혼자(solo) 모드로 두고, 내 PC에만 적용되는 로컬 설정으로 바꿉니다.

/settings --local modes.review_mode=solo
/settings

에이전트 지시문은 영어지만 대답은 한국어로 받고 싶다면 CLAUDE.md 맨 아래에 한 줄을 붙입니다.

Add-Content CLAUDE.md "`n## Team Language`n`nRespond to the user in Korean. Keep file names, keys and code identifiers in English."

/settings 출력에서 review_mode: solo 옆에 (LOCAL OVERRIDE — yaml has: …) 또는 (project.local.yaml)가 붙으면 내 PC에만 적용된 것입니다.

0-7thunder-kit 설치 (아이디어 1·2·5를 할 경우)

# 내려받은 zip을 프로젝트 루트에 풀기 (폴더 구조 유지)
Expand-Archive $HOME\Downloads\thunder-kit.zip -DestinationPath . -Force
python tools\install_kit.py           # 무엇이 바뀌는지 미리보기
python tools\install_kit.py --apply   # 적용

+ settings.json: PreToolUse(Bash|PowerShell)에 validate-gacha.sh 등록
+ live-ops-designer: '- No loot boxes with real-money purchase and ran…' 교체
+ live-ops-designer: '(loot boxes with…' 교체
적용 완료. Claude Code를 다시 시작해야 훅이 로드됩니다.

다시 실행하면 세 줄 모두 "이미 … (건너뜀)"으로 바뀝니다. Claude Code를 종료(/exit)했다가 다시 띄우세요.

0-8이식 결과를 커밋

git add .claude CLAUDE.md project.yaml .worktreeinclude .gitignore tools design docs snippets assets/data/gacha
git commit -m "chore: Claude Code Game Studios 도입 (파일럿)"

이 브랜치를 팀에 공유할지, 도입 담당자 PC에서만 시험할지 정합니다. 운영 레포의 main에는 파일럿이 끝난 뒤 병합하세요.

1-1지금 확률 데이터가 어디에, 어떤 형식으로 있는지 파악

Assets 폴더와 서버 설정 폴더에서 소환(가챠) 확률 테이블이 어디에 어떤 형식(JSON, CSV, ScriptableObject, DB 덤프)으로 있는지 찾아서 표로 정리해 줘. 파일은 수정하지 마.

결과에 따라 갈래가 나뉩니다.

• 이미 JSON → 1-2로 바로 가서 키트 형식에 맞춥니다.
• CSV·ScriptableObject·DB → 공시의 기준이 될 JSON을 뽑아 내는 변환 스크립트를 먼저 만듭니다(아래 프롬프트).

tools/export_gacha.py 를 만들어 줘. 위에서 찾은 소환 확률 원본을 읽어서 assets/data/gacha/gacha_{배너ID}.json 형식(키트의 gacha_sample_pickup.json 과 같은 키)으로 내보내는 스크립트야. 원본은 절대 수정하지 말고, 쓰기 전에 경로를 먼저 물어봐.

공시의 "진짜 원본"을 무엇으로 볼지 정합니다. 서버 DB가 진짜라면, JSON은 그 DB에서 뽑은 사본이고 배포 파이프라인에서도 같은 검사를 돌려야 합니다(1-6).

1-2데이터를 키트 형식으로 맞추기

파일 하나에 배너 하나. 이름은 gacha_[배너].json, 키는 snake_case(CCGS 데이터 규칙)입니다. 확률은 퍼센트 값입니다.

python tools\check_gacha.py --all

✓ assets/data/gacha/gacha_sample_pickup.json
✗ assets/data/gacha/gacha_halloween.json
  - 등급 SR: 아이템 확률 합 17.5% ≠ 등급 확률 18%

모든 파일에 ✓가 붙을 때까지 고칩니다. --all은 git이 추적하는 파일만 보므로 새 파일은 먼저 git add 하세요.

1-3훅이 실제로 막는지 일부러 틀려 보기

Claude에게 확률을 하나 바꾸고 커밋하라고 시켜 봅니다. 공시 갱신일은 그대로 둡니다.

gacha_sample_pickup.json 에서 hero_ara 확률을 0.8로, SSR 등급 확률을 2.1로, R 등급의 hero_han 을 39.9, R 등급을 79.9로 바꾸고 "test: 확률 조정"으로 커밋해 줘. updated_at 은 건드리지 마.

✗ assets/data/gacha/gacha_sample_pickup.json
  - 확률 구성이 바뀌었는데 disclosure.updated_at(2026-10-23)이 그대로입니다 — 공시 갱신일을 고치고 공지를 준비하세요
[validate-gacha] 확률형 아이템 데이터 검사에 실패해 커밋을 막았습니다.

커밋이 막히고 Claude가 이유를 읽은 뒤 "갱신일을 바꿀까요?"라고 되물으면 게이트가 작동하는 것입니다. 시험이 끝나면 git checkout -- assets/data/gacha로 되돌리세요.

1-4사람이 하는 커밋에도 같은 검사 걸기

중요: Claude Code 훅은 Claude가 실행하는 명령만 지킵니다. 사람이 IDE나 SourceTree로 커밋하면 지나갑니다. git 자체의 pre-commit 훅에도 같은 검사기를 연결하세요.

# -NoNewline: 줄 끝에 CRLF가 붙으면 sh가 "exit 1\r"을 읽지 못한다
Set-Content -NoNewline -Encoding ascii .git\hooks\pre-commit "#!/bin/sh`npython tools/check_gacha.py --staged || exit 1`n"

SourceTree에서 틀린 데이터를 커밋하면 같은 오류로 실패합니다. 이 훅은 PC마다 설치해야 하므로 신규 입사자 셋업 문서에 넣으세요. 팀 전체에 강제하려면 1-6의 CI 검사가 최종 방어선입니다.

1-5공지용 확률표는 손으로 치지 않기

python tools\check_gacha.py --render assets\data\gacha\gacha_sample_pickup.json > notice-table.md

### 샘플 픽업 소환 확률 정보
공시 갱신일: 2026-10-23
| 등급 | 아이템 | 확률 |
| **SSR** | (등급 합계) | **2%** |
| SSR | 아라 (픽업) | 0.7% |
...
- 80회 안에 SSR 등급을 획득하지 못하면 80회째에 확정 지급됩니다.

공지 숫자와 데이터 숫자가 같은 파일에서 나오므로 오타가 생길 틈이 없습니다.

1-6배너마다 검수 에이전트 돌리기 + CI에 걸기

gacha-compliance 에이전트로 assets/data/gacha/gacha_sample_pickup.json 과 notice-table.md 를 design/live-ops/ethics-policy.md 기준으로 검수하고 결과를 production/qa/gacha-review-sample.md 에 써 줘.

마지막 줄에 PASS 또는 BLOCKED가 나옵니다. BLOCKED 항목에는 파일·키·고칠 방법이 적혀 있습니다.

빌드 서버(GitHub Actions, Jenkins 등)에 한 줄을 추가하면 어떤 경로로 들어온 데이터도 막을 수 있습니다.

# 예: GitHub Actions 스텝
- name: Gacha data check
  run: python tools/check_gacha.py --all

윤리 정책(design/live-ops/ethics-policy.md)의 빈칸 — 천장 상한, 미성년자 결제 정책 링크 — 을 기획·법무가 채웁니다. 이 문서가 비어 있으면 검수 에이전트도 기준 없이 판단하게 됩니다.

2-1한 번만: 경제 규칙과 윤리 정책 채우기

이코노미 디자이너는 Phase 3에서 design/live-ops/economy-rules.md를 먼저 읽습니다. 이 파일이 비어 있으면 이벤트마다 기준이 달라집니다. 키트 템플릿의 빈칸(재화별 일일 획득량, 이벤트 보상 상한, 젬 단가 원칙, 지표 기준선)을 실제 값으로 채우세요.

design/live-ops/economy-rules.md 의 빈칸을 같이 채우자. 지금 게임의 재화 획득·소모처를 Assets 데이터에서 찾아 초안을 만들고, 숫자는 내가 확인할 수 있게 출처 파일을 같이 적어 줘.

숫자는 사람이 확정합니다. 특히 "이벤트 1회 무과금 최대 획득 젬"은 이후 모든 이벤트의 상한이 됩니다.

2-2이벤트 브리프를 준비해 실행

인자는 작업 폴더 이름(slug)이 되므로 짧은 영문으로 줍니다. 내용은 바로 이어서 붙여 넣습니다.

/team-live-ops "chuseok-2026" --review lean

이벤트 개요:
- 기간: 2026-09-24 ~ 10-08 (14일), 추석 연휴 포함
- 목표: 휴면 복귀 유저 리텐션 + 신규 SSR '달토끼 아라' 픽업 소환
- 구성: 7일 출석 보상, 송편 모으기 미션(이벤트 재화), 교환 상점, 픽업 소환 배너
- 제약: 신규 아트는 캐릭터 1 + 아이콘 6개까지. 무과금 최대 획득 젬은 economy-rules.md 상한을 넘지 않을 것

2-3단계마다 고르고 넘어가기

각 단계가 끝나면 선택지가 나오고, 승인해야 다음으로 갑니다. 모든 초안은 production/live-ops/chuseok-2026/에 따로 쌓입니다.

3·4단계는 동시에 돌아갑니다. 끝나면 초안을 모아 design/live-ops/seasons/S[N]_[이름].md(시즌 문서), …_analytics.md, …_comms.md로 정리하는데, design/에 쓰기 전에 한 번 더 묻습니다.

2-4데이터로 옮기고 밸런스·공시 검사

economy.md 의 픽업 배너를 assets/data/gacha/gacha_chuseok_2026.json 으로, 교환 상점을 assets/data/shop/shop_chuseok_2026.json 으로 만들어 줘.

/balance-check assets/data/shop/shop_chuseok_2026.json

python tools\check_gacha.py assets\data\gacha\gacha_chuseok_2026.json
python tools\check_gacha.py --render assets\data\gacha\gacha_chuseok_2026.json > production\live-ops\chuseok-2026\notice-table.md

/balance-check가 이상값·재화 흐름 불균형을 표로 보여 주고, 검사기가 ✓를 내면 통과입니다. 이어서 1-6의 검수 에이전트를 comms.md와 함께 돌리세요.

2-5패치 노트와 공지, 종료 후 회고

/patch-notes 1.18.0 --style brief

git 이력과 체인지로그를 플레이어 언어로 바꿔 줍니다. 이벤트 공지는 comms.md를 다듬어 씁니다.

이벤트가 끝나면 실제 지표를 넣고 비교를 시킵니다.

추석 이벤트 결과야: 참여율 41%, 복귀 유저 3,200명, 픽업 매출 목표 대비 87%. production/live-ops/chuseok-2026/analytics.md 의 목표와 비교해서 원인 가설과 다음 이벤트에 바꿀 점을 production/live-ops/chuseok-2026/retro.md 로 정리해 줘.

회고에서 확인된 기준(예: 출석 7일보다 5일이 완주율이 높다)은 economy-rules.md에 반영해야 다음 이벤트부터 공장이 그 기준으로 일합니다.

3-1D1 — 검증할 질문과 중단 기준을 먼저 적기

판정 날에 기준을 정하면 늘 "조금만 더"가 됩니다. 첫날 문서로 박아 둡니다.

design/kill-criteria.md 를 만들어 줘. 검증할 질문은 "머지 퍼즐에 방치형 성장을 붙이면 첫 3분 안에 '한 판 더'가 나오는가".
PROCEED 기준: 테스터 8명 중 5명 이상이 요청 없이 2판째를 시작.
KILL 기준: 3명 이하. 그 사이면 PIVOT. 쓰기 전에 경로를 확인해 줘.

질문은 하나만. "재미있는가"처럼 넓은 질문은 판정이 안 됩니다.

3-2D2 — 한 장짜리 기획서

/brainstorm 머지 퍼즐 + 방치형 성장, 세로 화면 한 손 조작

minimal에서는 대화 몇 번으로 끝나는 "린 브리프" 흐름이 돕니다. 한 줄 컨셉 2~3개 중 하나를 고르면 제목·피치·코어 루프·승패 조건·MVP(최대 7개)·제외 범위·만드는 순서를 채워 design/game-brief.md에 씁니다.

MVP가 7개를 넘으면 에이전트가 먼저 "너무 길다"며 덜어 낼 항목을 제안합니다. 그게 정상입니다.

3-3D3–6 — 버리는 시제품 만들기

/prototype 머지 3단계와 오프라인 보상만 있는 한 화면 --path html

--path는 세 가지입니다. 처음엔 html을 권합니다 — 휴대폰 브라우저로 바로 돌려 볼 수 있어 빌드 시간이 0입니다. 손맛(터치 반응, 연출)이 질문의 핵심이면 engine, 규칙만 보면 되면 paper를 고릅니다.

코드는 prototypes/ 아래에만 생깁니다. 이 폴더엔 느슨한 규칙(prototype-code.md)이 적용되고, 가설이 적힌 README가 필수입니다.

3-4D7–9 — 플레이테스트 기록과 분석

/playtest-report new

관찰 양식(첫 5분 인상, 흐름, 버그, 정량 데이터)이 나옵니다. 다른 팀 동료 8명에게 설명 없이 휴대폰을 건네고, 한 명당 양식 하나씩 메모합니다. "2판째를 스스로 시작했는가"를 반드시 적으세요.

/playtest-report analyze production/playtests/2026-11-merge-notes.md

세션별 피드백이 정리되고 다음에 손댈 우선순위 상위 3개가 나옵니다. "design/kill-criteria.md 기준과 비교해 줘"를 덧붙이면 판정 기준 대비 결과도 함께 봅니다.

3-5D10 — 판정하고 다음 걸음

/prototype은 마지막에 PROCEED / PIVOT / KILL / NOT ASSESSED 중 하나로 보고서를 쓰고 creative-director 검토를 붙입니다. 아무도 처음부터 끝까지 플레이해 보지 않았으면 NOT ASSESSED입니다 — 추측으로 PROCEED를 주지 않습니다.

최종 결정은 회의에서 사람이 합니다. 보고서는 근거 자료입니다.

# PROCEED라면 — 본 개발 모드로
/settings modes.rigor=standard
/create-stories

KILL이어도 실패가 아닙니다. 2주 만에 "만들지 말 것"을 하나 알아낸 것입니다. 보고서는 다음 아이디어의 근거로 남겨 둡니다.

4-1현황 진단

/project-stage-detect

영역별 완성도 개요, 빠진 문서 목록(Gaps), 추천 다음 단계가 나옵니다. 설계 문서가 하나도 없는 운영 프로젝트라면 거의 모든 칸이 비어 있는 게 정상입니다.

4-2이전 계획 세우기

/adopt

있는 문서(기획서, 위키 내보내기 등)를 CCGS 형식 기준으로 감사하고, 빈칸을 BLOCKING/HIGH/MEDIUM/LOW로 분류한 순서 있는 계획을 docs/adoption-plan-[날짜].md로 씁니다. 범위를 좁히려면 /adopt gdds, /adopt infra처럼 줍니다.

계획에서 먼저 문서화할 핵심 시스템 3개를 고릅니다. 추천: 담당자가 한 명뿐인 시스템, 장애가 잦은 시스템, 신규 입사자가 가장 먼저 만지는 시스템.

4-3코드에서 설계 문서를 거꾸로 쓰기

/reverse-document design Assets/Scripts/Gacha
/reverse-document design Assets/Scripts/Battle
/reverse-document architecture Assets/Scripts/Core

한 번에 하나씩 실행합니다. 에이전트가 코드를 분석한 뒤 "왜 이렇게 했는지"를 묻는 질문을 합니다. 예: "천장 카운트가 배너 간에 이월되는데 의도인가요?" 담당자가 답한 내용이 문서의 핵심 가치입니다.

초안을 보여 주고 승인을 받은 뒤 design/gdd/ 또는 docs/architecture/에 씁니다. 코드가 너무 적어 문서화할 게 없으면 스스로 "부족함"을 판정하고 멈춥니다.

4-4역할별 온보딩 문서 만들기

/onboard client-programmer
/onboard live-ops-designer

프로젝트 요약, 역할, 아키텍처, 지켜야 할 규칙, 담당 영역 현황, 흔한 함정, 첫 과제, 물어볼 질문 목록이 담긴 문서가 나옵니다. 다음 입사자에게 실제로 건네 보고 빠진 점을 받아 고칩니다.

4-5문서를 살아 있게 유지하기

문서는 코드가 바뀌는 순간부터 낡습니다. 두 가지를 습관으로 만듭니다.

# 설계가 바뀌면 — 영향받는 다른 문서까지 찾아 고치기
/propagate-design-change design/gdd/gacha.md
# 스프린트마다 한 번 — 문서끼리 모순 찾기
/consistency-check

문서 변경도 코드 리뷰처럼 담당자 승인을 거치도록 PR 규칙에 넣을지 팀이 정합니다.

5-1최저 지원 기기 기준으로 예산 적기

키트의 snippets/project-yaml-mobile.yaml을 참고해 project.yaml의 platform·performance 블록을 고칩니다. 값은 가장 낮은 지원 기기(Tier C) 기준입니다 — 거기서 통과하면 나머지도 통과합니다.

/settings performance.target_framerate=30
/settings performance.frame_budget_ms=33.3
/settings performance.memory_ceiling_mb=1200
/settings performance.draw_call_limit=150

숫자는 예시입니다. 5-2의 실측 뒤에 확정하고, 그 전까지 performance.enforce는 warn으로 둡니다.

5-2실기기 기준선 측정

키트의 docs/performance/device-tiers.md에 등급별 대표 기기와 목표를 적고, Tier C 실기기에서 Unity Profiler(개발 빌드)로 로비·전투·소환 연출을 각 3분씩 측정합니다. 결과는 production/qa/perf/에 날짜별로 남깁니다.

이 측정은 사람이 합니다. Claude는 실기기를 만질 수 없습니다. 대신 측정 결과를 정리시킬 수 있습니다.

production/qa/perf/2026-10-28-tierC.csv 는 Galaxy A 시리즈 실기기 측정값이야. 구간별 평균·1% Low FPS, 최대 메모리를 device-tiers.md 의 예산과 비교한 표로 정리해 줘.

5-3코드 수준 병목 찾기

/perf-profile full

예산 대비 판정과 순위가 매겨진 최적화 후보(핫패스 할당, Update 남용, 과도한 Draw Call 원인 등)가 나옵니다. 실측 데이터 없이 코드만 본 항목은 그렇다고 표시됩니다.

5-4테스트 기반 깔기 (한 번만)

/test-setup
/test-helpers

Unity Test Framework 기준으로 테스트 폴더 구조와 실행 명령(project.yaml의 commands.test)을 맞추고, 자주 쓰는 픽스처·헬퍼를 만듭니다.

5-5업데이트마다 도는 QA 루틴

# QA에 넘기기 전 — 실패하면 QA 준비 안 된 빌드
/smoke-check --platform mobile
# 고친 버그에 회귀 테스트가 있는지
/regression-suite audit
/regression-suite update

화면을 바꾼 스토리는 실행 증거(스크린샷)가 있어야 /story-done이 닫아 줍니다. 모바일은 기기 화면을 직접 찍어 production/qa/evidence/에 넣습니다.

adb exec-out screencap -p > production\qa\evidence\story-042-lobby.png

v1.2.0부터 증거 옆에 stamp.txt가 남아, 이후 관련 코드가 바뀌면 "다시 찍으세요"라고 알려 줍니다.

5-6기준이 안정되면 경고를 차단으로

/settings performance.enforce=block

두세 번의 업데이트 동안 예산이 현실적이라는 게 확인된 뒤에만 올립니다. 너무 빨리 올리면 팀이 예산을 우회하는 법부터 배웁니다.

6-1하드코딩 문자열 찾고 표로 뽑기

/localize scan
/localize extract

scan은 코드·UI에 박힌 문자열 목록을, extract는 키가 붙은 문자열 표를 만듭니다. 바꾼 코드는 다음 빌드에서 화면이 그대로인지 꼭 확인합니다.

6-2번역 브리프 만들기

/localize brief

번역 업체나 번역가에게 그대로 넘길 문서입니다. 게임 개요, 말투, 캐릭터 용어집, 세계관 용어집, 번역 금지 목록, 플레이스홀더({0} 등) 설명, 글자 수 제한이 들어갑니다.

캐릭터 이름을 현지화할지 음차할지 같은 결정은 브리프를 보내기 전에 사람이 확정합니다.

6-3번역본 검증과 문화 검토

/localize validate
/localize cultural-review
/localize rtl-check      # 아랍어 등 오른쪽→왼쪽 언어가 있을 때만

validate는 누락 키, 깨진 플레이스홀더, 글자 수 초과를 잡습니다. cultural-review는 숫자·색·제스처·종교 표현처럼 지역별로 문제가 될 수 있는 항목을 짚습니다.

6-4문자열 동결

/localize freeze

동결 이후 문자열을 바꾸려 하면 쓰기 훅(validate-write.sh)이 "동결이 활성 상태이니 변경을 Post-Freeze Changes에 기록하거나 동결을 먼저 해제하라"는 경고를 냅니다. 막지는 않고 알립니다.

6-5현지화 QA, 출시 판정, 데이원 패치

/localize qa
/launch-checklist 2026-12-01
/day-one-patch known-bugs

/launch-checklist는 코드·콘텐츠·QA·스토어·인프라·커뮤니티·운영 7개 영역을 훑고, 사람만 확인할 수 있는 항목(스토어 심사 상태, 법무 승인 등)을 따로 묻습니다. 출시 직후 문제는 /day-one-patch가 롤백 계획과 QA 게이트를 갖춘 작은 스프린트로 처리합니다.

Go/No-Go는 체크리스트 결과를 보고 사람이 서명합니다.