# Flicker Survivor (FS) — 게임 설계와 AI 제작 프로세스, 근거 파일

기준 시점: 2026-09-13 (수치는 커밋 `8ace458d` 기준. 해시는 2026-09-14 이력 정리 뒤의 값). 커밋 수(§12), 게임 현재 상태(§1), 릴 구성(§1)은 2026-09-15 에 갱신했고 각 자리에 그 날짜를 적었다
작성: 프로젝트의 AI 가 저장소 기록을 읽어 작성(대표 설계 사례 §2.7·설계 변천 §2.8 은 2026-09-14 추가). 별도 세션이 대상을 열기 전에 독립 측정한 뒤 대조. 사람은 목적·구성·채택을 결정.

## 0. 이 파일에 대하여

**30초 요약 (여섯 문장, 2026-09-22).**
1. 카페인좀비는 개발자 한 사람이 여러 AI 를 역할별 실행 주체로 두고 게임을 만드는 스튜디오이고, 이 파일은 첫 타이틀 Flicker Survivor 의 저장소 기록이다.
2. 사람은 무엇을 만들지와 채택을 결정했고, AI 는 구현·측정·검토를 실행했다(§3 역할). 에셋의 최종 판정 `Done` 도 사람이 아니라 Claude Code 가 측정 게이트를 실행한 뒤 붙인다(§3·§7). 부록의 Petri War 는 무엇을 만들지도 AI 가 시장 조사부터 후보 프로토타입까지 진행하고 사람이 골라 키운 게임이다(§3.0, §10.6).
3. 지금 있는 것은 플레이 가능한 프로토타입이고(§1 현재 상태), 거기까지의 제작 기록이 이 파일이다. 같은 제작 체계의 경량 버전으로 만든 두 게임(소개서 부록)은 §10.6.
4. 출시 가능한 게임을 완성할 수 있다는 것은 아직 증명되지 않았다. 첫 출시가 첫 데이터다.
5. 게임의 재미와 밸런스는 외부 검증 전이다.
6. 질문은 "이 개발자가 출시까지 갈 수 있다는 근거가 어디에 있고, 무엇이 아직 비어 있어?"에서 시작하면 된다.

이 파일은 함께 드리는 퍼블리싱 소개서(7장, 상세판 14장)의 첨부물이다. 슬라이드는 영상·게임 소개·제작 방식 요약을 담고, 상세는 이 파일이 맡는다. 사람이 읽기보다 LLM 에게 읽히고 질문하기 좋게 썼다. 이 파일은 저장소 사실만 다룬다. 경력은 첨부 경력 기술서에 있다.


**어느 장이 어느 절을 가리키나 (상세판 14장 기준, 2026-09-28).** 7장 판은 1 요약 · 2 Flicker Survivor · 3 디자인 기준과 룩 · 4 출시 계획과 아직 모르는 것 · 5 Petri War · 6 Arcane Pockets · 7 자료에 묻기이고, 아래 표의 장 번호는 상세판 번호다.

| 퍼블리싱 소개서 | 이 파일의 절 |
|---|---|
| 1 표지 | §1, §10.6(작은 영상 두 칸) |
| 2 게임 소개 | §2.7 |
| 3 개발 히스토리 | §1 릴 문단(주차별 스틸의 출처) |
| 4 어떤 게임을 고르는가 | §2.7(자동전투 기본 문법) |
| 5 왜 이 비주얼인가 | §2.9(아트 방향 연표), §2.10(색 계열 기술 슬롯, 설계 확정·구현 전) |
| 6 누구에게 파는가 | 없음 — 개발자 판단 |
| 7 사람 · 경력 | 없음 — 첨부 경력 기술서 |
| 8 제작 방식 · 역할 | §3 역할, §4 병렬, §6 엔진 |
| 9 제작 방식 · 검증과 통제 | §5 규칙, §7 완료 판정, §8 측정 규율, §9 실패→규칙, §9.1 |
| 10 현재 상태와 출시 계획 | §1(현재 상태), §7.1(판독 게이트). 일정은 소개서에만 |
| 11 아직 모르는 것 | §14 열린 문제. "AI 자산에 대한 반발" 카드의 사례는 이 파일 밖, 장 꼬리말의 출처 |
| 12 부록 · Petri War | §10.6 |
| 13 부록 · Arcane Pockets | §10.6 |
| 14 첨부 | §0 |


**무엇에 대한 기록인가.** 한 사람(25년차 게임 개발자)이 2026-07-04 부터 여러 AI(Claude Code, Codex)를 역할별 실행 주체로 두고 Unity 게임 "FS" 를 만들면서, 그 일하는 방식(역할·권한·검증·인수인계·실패 기록)을 어떻게 설계하고 바꿔 왔는지의 기록이다.

**이 파일이 다루는 질문.** 어떤 플레이 경험을 목표로 규칙과 성장 구조를 설계했는가(§2.7). 그 초안이 13주 동안 어떻게 바뀌어 현재가 됐는가(§2.8). 아트 방향과 캐릭터 파이프라인의 기록은 §2.9, 의도가 실측에서 틀렸던 기록과 걸린 시간은 §9.1. 그 설계를 AI에게 맡길 때 어디까지 위임하고, 실패를 어떤 규칙과 도구로 바꿨는가. 위임의 경계는 §3·§4 에, 실패와 그 뒤의 규칙은 §5·§8·§9 에, 아직 안 되는 것은 §11.2·§13·§14 에 있다. 슬라이드를 읽고 자주 나오는 질문 중 이 시스템의 영역 밖인 것은 §16 에 구분해 두었다. 숫자는 §12 에 있지만 이 파일의 주제가 아니다.

**평가할 수 있는 범위.** 게임 디자인의 의도·규칙·수식·의사결정 과정은 대표 GDD 사례(§2.7)와 세 요소의 변천 기록(§2.8)으로 제시한다. 실제 재미와 밸런스 품질은 충분한 외부 플레이테스트로 검증됐다고 주장하지 않는다. AI 유무 대조군이 없으므로 생산성 배수를 말하지 않으며, 게임은 개발 중이고 Steam 출시·매출 성과는 없다(Petri War 의 웹 공개는 데이터 수집 테스트). 현재 구조가 최적이라고 주장하지 않는다.

**확인 상태 표기.** 각 사실에는 다음 중 하나를 붙였다.
- `[확인]` — 저장소 파일·커밋·이슈에서 직접 확인함
- `[기록]` — 프로젝트 문서(변경 이력·근거 기록·세션 상태)에 적힌 대로이며 원 트랜스크립트나 계측 출력을 재검산하지는 않음
- `[미검증]` — 구조는 존재하나 효과나 동작을 확인하지 않음
- `[열림]` — 아직 해결되지 않은 문제
- `[진술]` — 개발자가 글이나 말로 알린 내용이며 저장소 기록으로 확인하지 않음 (2026-09-30 추가)

커밋 해시와 이슈 번호는 비공개 저장소(GitHub `bhagent/FS`)의 식별자다. 외부에서 열 수 없으므로 참조용이다.

**이 파일을 LLM 에 넣고 묻는 법 (2026-09-22).** 사용하는 LLM(ChatGPT, Claude, Gemini 등)의 대화창에 이 파일을 끌어다 놓는다. 링크가 아니라 파일을 올려야 모델이 실제로 읽는다. 첫 질문은 "이 개발자가 출시까지 갈 수 있다는 근거가 어디에 있고, 무엇이 아직 비어 있어?" 이어서 물을 만한 것: "제작 방식에서 사람이 결정하는 것과 AI 가 실행하는 것은 어떻게 갈려?" · "실패가 규칙으로 바뀐 사례는 어떤 것이 있어?" · "게임의 현재 상태에서 출시까지 남은 것은 뭐야?" · "이 문서에서 과장으로 볼 만한 부분은 어디야?" 이 파일에는 평가 방법에 대한 지시가 없다. 목적과 범위, 확인 범위만 적혀 있다. 수치는 슬라이드와 같은 값이고, 슬라이드에 없는 수치는 파일에도 없다. 영상은 LLM 이 읽지 않으므로 사람이 직접 본다.

---

## 0.5 게임 실물 — 지금 플레이하거나 볼 수 있는 것 `[확인]` (2026-09-29)

**글로 된 파일의 범위.** 이 파일은 화면을 담지 못한다. 아래 게임들의 화면은 영상과 데모로 확인한다. Flicker Survivor 의 Steam 출시와 외부 플레이테스트는 아직 하지 않았다. Petri War 는 CrazyGames 베이직 런치(2026-09-30)로 공개해 데이터를 모으는 중이다.

| 게임 | 지금 상태 | 직접 확인하는 곳 |
|---|---|---|
| Flicker Survivor | 1인 개발, 07-04 시작 13주. 한 판을 처음부터 끝까지 플레이할 수 있는 빌드(적 8종·강화 카드 26종, 한 판 약 2분). 출시 전, 외부 플레이테스트 전 | 영상 `fs_reel.mp4` 30초(실제 플레이) |
| Arcane Pockets | 경량 버전, 09-19 시작. 브라우저에서 플레이 가능한 데모 공개 | https://arcane.caffeinezombie.com/ · 영상 `arcane_reel.mp4` 28초 |
| Petri War | 경량 버전, 1주 안에 만들었다. AI 가 Steam 시장 조사·후보 제안·초기 프로토타입까지 진행하고(언데드 게임은 카피캣에 가까워 접음), 개발자가 Petri War 를 골라 방향을 잡고 키운 게임 — "발상"이 아니라 "발견"에서 시작(§10.6). CrazyGames 베이직 런치(2026-09-30)로 공개 — 실제 출시를 해 보고 외부 플레이 데이터를 수집해 어떤 일이 새로 생기고 어떤 방식으로 처리해야 하는지 실전으로 검증하는 테스트이고 결과는 아직 없다(사용자 진술) | https://www.crazygames.com/game/petri-war · 자체 데모 https://petri-war.caffeinezombie.com/ · 영상 `petri_reel.mp4` 30초 |

**영상에 무엇이 나오는가** (3초 간격·320px 프레임으로 관찰해 글로 옮김. 소리는 반영하지 않았다)

- **Flicker Survivor (`fs_reel.mp4`)** — 흰 석판 바닥과 검은 먹 구멍(낭떠러지)이 있는 탑다운 전장에서, 플레이어가 순간이동하며 적 무리를 처치하는 실제 플레이. 공격은 붓질 룩으로 그려진다: 빨간 칼날 획, 초록 물감 번짐, 파란 궤적 선, 검은 먹 폭발. 적은 회색 스케치 몸체이고 처치되면 조각으로 부서진다. 뒤로 갈수록 적 밀도와 피해 숫자(한 자리 → 20대)가 커지고, 하단에 레벨(10대 후반 → 20)과 체력·경험치 막대, 우상단에 처치 수가 보인다. 마지막은 "FLICKER SURVIVOR — IN DEVELOPMENT" 카드.
- **Arcane Pockets (`arcane_reel.mp4`)** — 3D 쿼터뷰의 당구대형 경기장. 둥근 정령 공들, 가장자리의 검은 포털(포켓), 가운데 장벽·기둥 장애물. 지역마다 색과 배경이 다르다(석조 무덤·숲·마을·공방·관측소). 장면 자막 "두 번 꺾어, 단 한 번에."(쿠션 두 번 반사), "연쇄 충돌. 마지막 봉인까지.", "천둥 합창단"(연쇄 번개 주문), "장벽을 넘어."(점프샷), "한 번의 마법."(원샷 퍼즐). 한 번의 샷으로 여러 정령을 넣는 장면 위주.
- **Petri War (`petri_reel.mp4`)** — 어두운 청록 배양 접시에서 청록 아군 세포가 먹이를 먹고 증식해 퍼지고, 가장자리에서 산호색 침입 세포가 들어와 자동 전투가 벌어진다. 중간에 돌연변이 연출(한 세포로 확대, 보라빛 광채, 자막 "우리 군집의 돌연변이"). 마지막은 커진 군집들의 전투 위로 "생물학적 오토배틀러 · PETRI WAR · 성장하고, 진화하고, 살아남아라".


**사람 · 경력 요약** (상세는 첨부 경력 기술서)
- 게임 개발 25년, 전투·액션 시스템: 리니지 토너먼트 개발·라이브 운영(NCSoft), 미공개 FPS 개발(NCSoft), 팀 대전 액션 게임 Archeblade 총괄, 카드 수집형 보드 게임 Dicetiny 총괄, 붉은사막 초기 액션 시스템 설계 참여(Pearl Abyss · 블랙스페이스 엔진), 콩스튜디오 미공개 프로젝트 액션 설계 책임(Kong Studios).
- 창업 2회 · 투자·퍼블리싱 유치: Codebrush(2009~14) — Archeblade Steam 출시(얼리 액세스 2013-03, 정식 2014-04), 누적 150만 다운로드, 리뷰 7,615건 · 첫 12개월 추천 85.6%(운영 중단 뒤 하락: 2013년 작성분 87.5% → 2014년 75.4% → 2017년 51.9%). FAKEDICE(2014~17) — DiceTiny Steam 출시(얼리 액세스 2015-10, 정식 2016-07), VC 투자와 넥슨 글로벌 퍼블리싱 계약.
- 데이터로 사업을 본 경험: 펄어비스 사업 및 게임 플레이 데이터 분석(COO 직속 — 당시 COO, 현 CEO 허진영), 검은사막 Steam 출시 준비.
- Steam 출시 경험은 이 두 작품이다. 25년 경력 전체가 Steam 출시였던 것은 아니다.
- 두 작품 모두 칭찬은 설계·미술에, 불만은 서버·크래시·운영에 몰렸다.

**구매 수요를 재는 순서.** 폴리싱 전에는 Steam 페이지·SNS 같은 공개 노출을 하지 않는다(소규모 외부 관찰 테스트는 별개, §2.7). 플레이 영상이 안정되면 유입 퍼널을 측정해 마케팅 자산을 최적화하고, 데모 버전부터 플레이·구매·잔존 퍼널을 계측해 증거를 얻는다(개발자 방침, 2026-10-01).

**Flicker Survivor 출시 계획과 방침** (퍼블리싱 소개서 "현재 상태와 출시 계획"·"아직 모르는 것" 장, 수치는 목표치)
- 지금(2026-09-19 기준): 플레이 가능. 2026-07-04 부터 13주 · 1인 · PC · Android. 재미·밸런스는 외부 검증 전.
- 2026년 4분기 ~ 2027년 1분기: 페인트 룩을 적·캐릭터까지 확장, 밀집 전투에서도 적과 위험이 구분되는지 확인. 외부 플레이어 5~10명 × 10분 관찰 테스트를 매달 반복(플리커 빌드를 해 본 플레이어 중심으로 모집하고 대조 표본을 둔다, §2.7). 색 계열 기술 슬롯 구현, 카드·적·보스 확장. 데모 빌드.
- 2027년 2분기: Steam Next Fest 참가, 출시(Steam 얼리 액세스, PC), 가격 $5~10. 이때부터 플레이어 반응과 매출 데이터를 모은다.
- Steam 페이지 공개 게이트: 첫 런에서 만나는 기술 전부 폴리싱 · HUD 확정 · 판독 게이트 통과 · 외부 테스터 1런 완주 — 넷을 넘기 전에는 열지 않는다. 게이트 통과선은 첫 데이터 뒤에 정한다.
- 가격과 대상: Steam 유료 $5~10. 익숙한 장르 안에서 한눈에 구분되는 새 게임을 찾는 플레이어. 소비자 조사는 아직 없다(개발자 판단).
- AI 사용 표기: 처음부터 Steam 스토어에 밝힌다(개발자 방침). 쓰는 순서는 AI 로 만든 범위 → 사람이 고르고 고친 것 → 게임 디자인·밸런스·손맛·재미 판단은 사람. 1인 개발 群侠传：幸存者(Steam, 2026-08 출시) 의 공개 문구 구조를 참고했다.
- 퍼블리셔는 필요조건이 아니라 선택지로 본다. 계약 조건·IP·수익 배분은 이 자료에 없다.
- 아직 모르는 것(소개서 "아직 모르는 것" 장은 ①·② 둘, ③ 은 이 파일에만): ① 구매 수요 — 이 룩과 훅에 돈을 낼 플레이어가 있는지 외부 데이터가 없다. ② AI 자산 반발 — 페인트 룩이 AI 생성 이미지로 읽혀 화면 전체가 생성물로 읽힐 수 있다. 표기로 대응하지만 반응은 출시 전 미확인. 참고한 사례(Steam, 2026-09-30): 群侠传：幸存者 — 아트·애니메이션·음악에 AI 를 쓰고 공개, 리뷰 1,406건 · 96% 긍정 / Deadeye Deepfake Simulacrum — 자기 스프라이트로만 학습한 모델, 881건 · 99% / Meet Claude — 제작 전부를 AI 로 했다고 공개, 25건 · 96%(표본 작음). 품질·출처·후처리·투명성·사람의 책임이 더 중요해 보이지만 아직 확신할 수 없다(개발자 해석). ③ 장르 포화 — 2022~23년보다 기회가 줄었고 중간값 매출이 낮다는 것이 개발자 판단이다. 셋 다 첫 외부 테스트와 출시가 첫 데이터다.

---

## 1. 프로젝트 개요

| 항목 | 값 |
|---|---|
| 게임 | Flicker Survivor (약칭 FS) — 이동과 공격이 한 동작으로 이어지는 "플리커" 액션 탑다운. 다수 적과 효과가 한 화면에 겹치는 밀집 전투가 핵심 |
| 엔진 | Unity 6000.3.19f1 (Unity 6.3 LTS), URP 17.3.0 `[확인]` |
| 게임 프레임워크 | More Mountains TopDown Engine v4.5 (구매, `Assets/TopDownEngine/` 에 격리, 수정하지 않음) `[확인]` |
| 구현 시작 | 2026-07-04 (첫 커밋 `2f9bf0ae`) `[확인]` |
| 개발자 | 1인 |
| AI | Claude Code(정책·설계·관리·구현·검토), Codex(에셋 생성·반입). 서브에이전트 정의 49종. Unity MCP, Blender MCP |
| 산출물 | ① 플레이 가능한 게임 ② 그 게임을 만든 워크플로(역할 정의·규칙·훅·검사기·인수인계 체계) |
| 게임 현재 상태 (2026-09-19) | 적 데이터 8종(보스 포함) · 강화 카드 26종(레벨업 때 3장 중 선택) · 승리 조건 보스 처치 구현, 패배 시 아레나 내 즉시 재도전 · 씬은 아레나·타이틀 · 09-17~19 화면 변화: 프랍 재제작 3종 판독 게이트 통과, 마력탄을 먹 별과 붓 꼬리로, 칼날 붓질 개체별 변주, 스케치 레벨업 카드(FS 커밋 이력) · 한 판 약 2분: 2026-09-15 플레이 녹화(`FS_2026-09-15_053.mp4`) 실측 생존 126초에 스테이지 클리어, 처치 295, 도달 레벨 14. 스테이지 길이는 초안 배치의 결과이며 아직 테스트로 조정한 값이 아니다(2026-09-15 사용자 확인). 이전에 적었던 "3~5분 목표"는 이 실측으로 대체한다 `[확인]` (에셋·GDD·녹화 기준, 재미·밸런스 검증 아님) |

2026-09-28 부터 세 문서의 Flicker Survivor 영상은 실제 플레이를 편집한 SNS 프로모 30초(문서와 같은 폴더의 `fs_reel.mp4`)이고, 개발 히스토리는 영상 없이 주차별 스틸 페이지로만 둔다(사용자 결정). 아래는 그 전까지 쓰던 개발 릴의 기록이다. 그 릴은 58초짜리 한 편이며(유튜브 백업 https://youtu.be/QXMdsvY8vvc) 키 아트 카드 3초, 촬영 순 7구간, 마무리 카드 3초를 이어 붙인 것이다. 주차는 2026-07-04 를 1주차 1일로 센다(09-09 는 68일째로 10주차). 2026-09-16 이전 판에는 09-06·09-09 화면이 9주차로 잘못 표기돼 있었다. 키 아트(릴 첫 3초 카드)는 AI 가 생성한 컨셉 아트이지 실제 플레이 화면이 아니며 화면에 그렇게 표기했다. 두 덱의 표지 배경은 2026-09-20 사용자 결정으로 컨셉 아트에서 09-19 실제 플레이 스틸로 바꿨다. 릴 구간은 3주차(2026-07-23) 기본 플레이, 6주차(2026-08-11) 성장 장치, 폴리싱 시작 시점(촬영일 미기록)의 3D 스타일라이즈드 전투, 10주차(2026-09-09) 스케치 셰이더 테스트, 12주차(2026-09-19) 최신 플레이 녹화 `FS_2026-09-19_052.mp4`(70초 클립, Lv.4~10 구간, 붓 워시 절벽·바위, 붓질 변주가 들어간 칼날, 먹 별로 바뀐 마력탄과 붓 꼬리, 스케치 레벨업 카드가 들어간 빌드; 화면 왼쪽 위에 fps 계측 문자가 찍혀 있다)에서 발췌한 3구간(15.5~23.5초: 먹 폭발 → Lv.5 카드 → 기술 레벨 증가에 따른 기술 형태 변화, 27.5~35.5초: 칼날과 먹 폭발로 적이 부서지는 구간, 62.5~69.5초: Lv.10 카드 뒤 밀집 전투). 구간 선택 기준은 2026-09-19 사용자 요청 "레벨업으로 기술이 바뀌는 부분과 적이 부서지는 느낌". 같은 날 첫 녹화 `FS_2026-09-19_047.mp4`(31초) 발췌와 2026-09-16 녹화 `FS_2026-09-16_029.mp4` 발췌는 이것으로 대체했다. 유튜브 백업은 09-19 편집판(2026-09-20 갱신)이며 제출 전 일괄 갱신 방침에 따라 그때 바꾼다. 2026-09-15 녹화 `FS_2026-09-15_053.mp4`(한 판 141초, 생존 126초에 스테이지 클리어, 처치 295, 도달 레벨 14)는 "한 판 약 2분" 실측의 출처로 남기고 릴에서는 09-16 발췌로 대체했다(2026-09-16 사용자 지시). 10주차 페인트 룩 전투와 11주차 한 화면 클립은 2026-09-15 에 이미 뺐다. 10주차 캐릭터 애니메이션 비교(위는 로컬 모델이 생성한 3방향 참고 영상, 아래는 그것을 Blender 로 재생성한 결과)는 2026-09-15 사용자 결정으로 릴에서 분리했고, 2026-09-19 사용자 결정으로 덱 2장 타일과 첨부 목록에서도 뺐다(파일 `anim_compare.mp4` 는 배포 폴더에 남아 있으나 문서가 가리키지 않는다. 개발 기록 영상 갤러리는 나중 과제). 편집은 구간 선택과 자막뿐이며 속도·색 보정은 없다.

---

## 2. 초반 설계 — 지식을 조직하고, 그 위에서 GDD 를 썼다

구현에 앞선 첫 엿새(2026-07-04 ~ 07-09)의 순서다. 첫 C# 파일이 들어온 커밋(`8dc3284e`, 2026-07-09 20:38 KST) 이전의 커밋 89건 중 Unity 씬·프리팹 조립(Phase 0~3, 프레임워크 컴포넌트만 배치) 6건을 빼면 전부 하네스·설계·리뷰다. 07-04 ~ 07-08 의 커밋 72건에는 `Assets/Scripts` 변경이 없다 `[확인]`.

### 2.1 순서 `[확인]` (커밋 이력)

| 날짜 | 한 것 | 산출물 |
|---|---|---|
| 07-04 | 하네스 구성. 49종 역할 정의 중 핵심 4종(game-designer · unity-specialist · gameplay-programmer · qa-tester)만 켬. 같은 날 art-director · unity-ui-specialist 추가 | `.claude/`, `CLAUDE.md` |
| 07-05 | 엔진 버전 고정(Unity 6000.3.19f1)과 **지식 절단 위험 명시** — 릴리스가 모델의 학습 마감 한 달 전이라 API 지식이 불완전할 수 있음을 문서로 남김 | `docs/engine-reference/unity/VERSION.md` |
| 07-05 | 첫 아키텍처 결정 ADR-0001: 구매 프레임워크(TDE)를 감싸는 층을 두지 않고 직접 확장. 참고한 근거(볼트 위키·원문 문서·설치된 asmdef)와 검증 필요 항목(Risk)을 표로 | `docs/architecture/adr-0001-…md` |
| 07-05 | 컨트롤 매니페스트: ADR 에서 뽑은 프로그래머용 "해야 한다 / 하면 안 된다" 표 | `docs/architecture/control-manifest.md` |
| 07-05 | 게임 컨셉 GDD, 아트 바이블(9절), **시스템 인덱스** — 컨셉을 MVP 시스템 15개로 분해하고 의존 관계·설계 순서·리스크 3곳을 표시 | `design/gdd/game-concept.md`, `design/art/art-bible.md`, `design/gdd/systems-index.md` |
| 07-05 ~ 07-07 | 시스템별 GDD 15편. 한 편을 쓰면 즉시 `/design-review` 로 검토받고 지적을 해소한 개정판을 올리는 루프. Player Movement 는 Rev.7 까지 | `design/gdd/*.md` |
| 07-08 ~ 07-09 | 전체 GDD 교차 리뷰 3회(`/review-all-gdds`). 1차 판정 FAIL → Blocking 해소 → 별도 세션의 독립 재검증 2회 | `design/gdd/gdd-cross-review-2026-07-08.md`, `…-07-09.md` |

GDD 개정을 뜻하는 커밋(`Rev.N`)은 이후까지 합쳐 63건, `/design-review` 를 명시한 커밋은 11건이다.

### 2.2 GDD 의 형식은 규칙 파일이 강제한다 `[확인]`

`design/gdd/**` 를 편집할 때만 로드되는 조건부 규칙(`.claude/rules/design-docs.md`)의 원문:

> - Every design document MUST contain these 8 sections: Overview, Player Fantasy, Detailed Rules, Formulas, Edge Cases, Dependencies, Tuning Knobs, Acceptance Criteria
> - Formulas must include variable definitions, expected value ranges, and example calculations
> - Dependencies must be bidirectional — if system A depends on B, B's doc must mention A
> - Acceptance criteria must be testable — a QA tester must be able to verify pass/fail
> - No hand-waving: "the system should feel good" is not a valid specification
> - Claims about third-party engine/framework runtime behavior (execution order, lifecycle timing, pause/mutation semantics, threading guarantees) must cite exact file:line source from the installed engine/framework code, or be explicitly flagged as an unverified assumption requiring verification — never assert engine behavior from memory, training data, or inference.
> - Design documents MUST be written incrementally: create skeleton first, then fill each section one at a time with user approval between sections.

즉 ① 절 구성 고정 ② 수식은 변수 정의·범위·예시 계산 필수 ③ 의존은 양방향 ④ 프레임워크 동작 주장은 설치된 소스의 `file:line` 인용 아니면 미검증 표시 ⑤ 절 단위로 사람이 승인하며 씀. 실제 GDD(예: `flicker-combat.md`)는 Overview · Player Fantasy · Detailed Design · Formulas · Edge Cases · Dependencies · Tuning Knobs · Visual/Audio · UI · Acceptance Criteria · Open Questions 순이다.

### 2.3 상수는 레지스트리가 소유한다 `[확인]`

`design/registry/entities.yaml` 이 GDD 사이에서 참조되는 상수·수식·엔티티를 추적한다. 파일 머리말:

> GDD 간 크로스레퍼런스되는 명명된 상수/공식/엔티티/아이템을 추적한다.
> /design-system이 각 GDD 작성 후 새 항목을 여기 추가하고 referenced_by를 갱신한다.
> 값 자체를 다른 GDD가 임의로 바꾸면 안 되며, 변경이 필요하면 충돌로 표면화한다.

항목 예:

```yaml
- name: m_speed
  value: "1.0–1.6"
  unit: multiplier
  source: design/gdd/player-movement-input.md
  referenced_by: [design/gdd/camera-system.md, design/gdd/upgrade-modifier.md]
```

같은 값이 두 문서에서 다르면 이 파일에서 드러난다. 교차 리뷰가 실제로 잡아낸 예: 타게팅 GDD 의 역전 경계 상수가 채택된 설정과 달라 정정(2026-08-03), 시스템 인덱스가 시스템 수를 한 문서 안에서 15와 16으로 다르게 적고 있던 자기모순(2026-08-08).

### 2.4 교차 리뷰는 별도 세션이 독립적으로 한다 `[확인]`

2026-07-08 첫 전체 리뷰의 방법 기록:

> Method: `/review-all-gdds full` — Phase 2(Consistency)/Phase 3(Design Theory) run as parallel fresh non-fork agents on Fable 5, Phase 4(Scenario Walkthrough)/synthesis by orchestrator (Sonnet 5).

결과는 FAIL. Blocking 두 건(재도전 흐름의 이벤트 계약 불일치)을 고친 뒤, 사용자 요청으로 **별도 세션이 처음부터 다시 검증**했다. 그 2차 검증은 "1차 수정이 골격만 있고 실제 계약은 비어 있다"(C2)를 잡아냈고, 세 문서가 합성될 때만 드러나는 결함(체인 감쇠 상수 × 적 HP × 체인 리셋 규칙 → 대표 빌드에서 피드백이 항상 평탄)을 새로 찾았다. 3차 검증 뒤 2026-07-09 에 백로그를 전부 닫았다. 같은 절차가 08-03, 08-07 에 반복됐다(교차 리뷰 문서 4편).

이 절차는 §8.3 의 검증자 규칙("작성자와 다른 실행 주체, 대상을 보기 전에 스스로 먼저 잰다")과 같은 원리이며, 이 근거 파일의 교차 검증(§13)에도 그대로 적용됐다.

### 2.5 지식은 세 곳에 나눠 두고, 자동으로 읽히는 경로로만 흐르게 한다 `[확인]`

| 무엇 | 어디 | 규모 (2026-09-13) |
|---|---|---|
| 원문 자료(Unity 매뉴얼, TDE 문서) — 검색용, 통째로 읽지 않음 | 공통 볼트 `raw/` | 파일 3,516 |
| 다른 프로젝트에도 성립하는 지식(엔진 함정, 도구 운용, 인용 규칙, 측정 규율, 지식 관리 구조) | 공통 볼트 `wiki/` | 문서 108 |
| 이 프로젝트에서만 성립하는 진단 규율("왜 그런가") | FS 볼트 `wiki/` | 문서 6 |
| 현행 규칙·수식·값("무엇인가") | 저장소 `design/` | 84 |
| 결정 기록("언제 정했나") | 저장소 `docs/architecture/` ADR 5 + 매니페스트, 볼트 `log.md` | |
| 저장소 문서 전수 색인 | 저장소 `docs/INDEX.yaml` (생성물), FS 볼트 `map/` | 230 문서 |

원칙 두 가지가 문서에 적혀 있다.

- **GDD 본문은 볼트로 옮기지 않는다** — 파이프라인 스킬 88개가 `design/gdd/` 경로에 의존하기 때문(2026-07-05 확립). 볼트는 지도 역할만 한다.
- **볼트 `wiki/` 는 "설명" 사분면이다** — 값은 저장소가 소유하고 볼트는 진단 규율만 소유한다. 이 구분이 없던 2026-08-21 까지 FS 볼트 wiki 는 2장뿐이었다. 구분을 정하자 저장소에 묻혀 있던 진단 규율 4편(진단 규율 · 생성 자산의 한계 · 측정의 함정 · 계약 저술)이 증류돼 나왔다.

문서 색인은 손으로 쓰지 않는다. `docs/INDEX.yaml` 은 생성물이고 `build-doc-index.py check` 가 현실과 어긋나면 실패한다. 이유(문서 원문): *"손으로 쓴 목차는 반드시 낡는다. 낡은 목차는 없는 것보다 나쁘다 — 없으면 찾아보기라도 하는데, 있으면 믿고 지나간다."* 문서마다 프론트매터에 역할(`rules | sources | decisions | work`)과 상태(`current | fulfilled | superseded | stale`)를 적고, 상태를 적으면 근거(`status_why`)도 적어야 한다. 230개 중 상태가 붙은 것은 30개이며, 파일로 확인되는 것만 붙였다.

ADR 은 무엇을 참고했는지를 표로 남긴다. ADR-0001 의 참고 자료 행: *"`docs/engine-reference/unity/VERSION.md`; GameDev Vault `wiki/topdown-engine/` … and raw TopDownEngine docs …; installed asmdef files under `Assets/TopDownEngine/`; `Packages/manifest.json`"*. 지식 절단 위험 등급(MEDIUM)과 검증 필요 항목도 같은 표에 있다.

### 2.6 이 절에서 확인하지 않은 것

- §2.1~2.5는 GDD의 형식·절차·검증 기록을 확인한 범위다. 대표 GDD 내용은 §2.7에 별도로 제시하며, 실제 재미·밸런스의 플레이테스트 결과를 뜻하지 않는다.
- 볼트 `raw/` 3,516 파일이 실제로 얼마나 참조됐는지(ADR 의 참고 표에 적힌 것만 확인).
- `/design-review` 가 지적한 항목의 원문(커밋 메시지의 건수만 확인).

---

### 2.7 대표 게임 설계 — 플리커의 선택을 어떻게 만드는가

이 절은 GDD 원문을 읽고 재구성한 설계 사례다 `[확인: 문서 내용]`. 규칙의 의도와 판단 근거를 평가할 수 있도록 본문에 담았다. 원본 경로는 비공개 저장소의 추적용 식별자이며, 첨부 파일 하나만 읽어도 사례를 이해할 수 있다. GDD 전체·최신 구현 전체를 검증한 것은 아니다.

#### 플레이어 판타지와 핵심 선택

목표는 적이 몰려올수록 도망칠 대상만 늘어나는 것이 아니라, 직접 파고들어 연속으로 지울 기회가 늘어나는 감각이다. 플리커는 대상으로 순간이동하며 공격하므로 **다음에 공격할 대상과 다음에 서 있을 위치를 함께 선택**하게 한다. 밀리초 단위 입력 타이밍보다 대상 읽기·진입 위치·자원 배분에 숙련의 무게를 둔다.

2026-08-09 개정은 자동전투를 기본으로 복원하고 플리커를 능동 개입 층으로 둔다. 따라서 현재 설계 의도를 "자동공격이 없는 게임"으로 설명하면 틀린다. 목표는 자동전투 위에 개입할 때 플레이어가 더 강하게 전투를 주도하는 것이다. 이것은 설계 방향이며 개입의 재미가 검증됐다는 뜻은 아니다.

근거: `design/gdd/game-concept.md`의 Core Fantasy·2026-08-09 개정, `design/gdd/flicker-combat.md`의 Player Fantasy·Core Rule 10.

#### 판타지의 수요 근거 — 통제감을 내주고도 고르는 빌드 `[확인: 외부 출처, 2026-09-30]`

순간이동하며 적을 쓸어 담는 판타지는 액션 RPG 에서 오래 선택되어 왔다.

- **Diablo 2 — Enigma.** 어느 직업에나 Teleport 를 주는 룬워드 몸 방어구로, 거의 모든 직업에서 가장 선호되는 몸 방어구로 꼽힌다. 근접 직업도 순간이동으로 위치를 잡아 사냥 효율이 크게 오른다는 설명이 붙는다. 출처: [Diablo Wiki — Enigma](https://diablo.fandom.com/wiki/Enigma_Rune_Word), [D2Runewizard — Enigma](https://d2runewizard.com/runewords/Enigma).
- **Path of Exile — Flicker Strike.** 적 사이를 순간이동하며 치는 스킬이다. 리그마다 빌드 가이드와 사용 집계가 이어지는 대표적인 원버튼 빌드다. 출처: [poe.ninja — Flicker Strike 사용 빌드(Mirage 리그)](https://poe.ninja/poe1/builds/mirage?skills=Flicker+Strike), [Mobalytics — Flicker Strike Warden](https://mobalytics.gg/poe/builds/flicker-strike-warden), [Sportskeeda — 원버튼 빌드 5선(3.26)](https://www.sportskeeda.com/mmo/path-exile-5-coziest-one-button-builds-league-3-26). 점유율 최상위 빌드는 아니다. 그래서 "가장 인기 있다"가 아니라 "오래 꾸준히 선택된다"까지만 주장한다. 리그별 사용 비율은 이 절에서 수치로 확인하지 않았다.

같은 가이드들이 Flicker Strike 의 단점으로 **"캐릭터를 통제하기 어렵다"**를 적는다. 아래 검증 질문("내가 고르지 않은 적에게 끌려갔다")은 PoE 에서도 알려진 비용이고, 플레이어는 그 비용을 알고도 이 빌드를 고른다. 따라서 이 근거가 보여 주는 것은 **판타지의 수요**다. FS 가 그 판타지를 서바이버류의 자동 선택·원버튼 조작으로 옮겼을 때 "쓸어 담는 쾌감"이 "끌려다니는 불쾌감"보다 큰지는 여전히 `[미검증]` 이다. 이 판타지를 이미 아는 플레이어가 FS 의 첫 번째 대상이며(개발자 판단), 아래 테스트의 모집도 그에 맞춘다.

#### 조작 — 자동 선택과 의도적 개입

자동 타겟팅은 매번 정밀 조준해야 하는 부담을 줄이고, 방향 입력은 원하는 무리를 고르는 수단이 된다. 동시에 GDD는 자동 선택이 "내가 골랐다"는 감각을 빼앗을 수 있음을 핵심 위험으로 명시한다. 대상을 잘 맞히는 것만으로 설계가 성공했다고 보지 않는다.

조작에는 개정 이력이 있다. 초기의 "완전 수동 조준 제외"만 인용하면 이후 변경을 놓친다. **2026-09-01 스틱·패드 개정 기록**은 중립에서 전 방향 타겟팅, 방향 입력 시 ±45° 안의 타겟, 버튼 홀드로 연속 플리커, 더블탭 후 유지로 지점 선택 UI를 열고 손을 떼면 해당 지점으로 이동하도록 정의한다. 이 내용은 스틱·패드 범위이며 마우스 조작 전체로 일반화하지 않는다.

근거: `design/gdd/targeting-system.md`의 Player Fantasy·Core Rules 1~3, `design/gdd/flicker-combat.md` 머리말의 2026-09-01 개정. 이 사례는 해당 문서 기록의 요약이며 실기기 재시험 결과가 아니다.

#### 위험과 보상 — 빠른 연쇄와 충전 고갈을 분리한다

2026-07-15 개정 기록에는 기존의 짧은 실행 간격만으로는 자원 감각이 없다는 사용자 플레이 관찰이 적혀 있다 `[기록]`. 이에 연속 충전 풀을 추가했다. 한 번의 플리커는 충전 1개를 쓰고, 충전은 사용 중에도 순차적으로 회복된다. 남은 충전을 어느 무리에 쓸지, 언제 재배치하며 회복할지가 선택으로 추가된다.

두 시간은 다른 역할을 맡는다. `t_cycle`은 두 번의 플리커 사이에서 타격·착지·다음 대상이 읽힐 시간을 보호하고, `t_recharge`는 고갈 후 다시 쓸 수 있는 속도를 정한다. 자원 회복 강화가 타격을 읽을 최소 간격까지 없애지 않도록 분리한 것이다. 대상이 없는 이동도 충전을 소비하므로 무료 이동을 반복하는 우회로가 되지 않는다.

근거: `design/gdd/flicker-combat.md`의 2026-07-15 개정·Core Rules 10·13·14.

#### 수식 — 어떤 값을 바꾸면 무엇이 달라지는가

아래는 `flicker-combat.md` Formula 7·8의 **기본 충전 모델**이다. 처치 환급 등 추가 카드 효과가 없는 예시이며, 현재 빌드의 확정 밸런스 수치가 아니다.

| 변수 | 역할 | GDD 예시 |
|---|---|---|
| `N` | 저장 가능한 충전 수. 연속 사용 여유 | 4개 |
| `t_recharge` | 충전 1개 회복 시간. 고갈 후 사용 빈도 | 0.7초 |
| `t_cycle` | 두 실행 사이 간격. 타격·착지 판독 시간 | 0.1675초(2026-08-06 갱신 앵커) |
| `chargeProgress` | 정수부는 사용 가능 횟수, 소수부는 다음 충전 진행도 | 3.6에서 1회 사용하면 2.6 |

GDD의 진단식은 `f_burst = 1 / t_cycle`, `f_sustain = 1 / t_recharge`, `T_refill = N × t_recharge`다. 위 값을 넣으면 충전이 있을 때 약 **5.97회/초**, 고갈 후 약 **1.43회/초**, 완전히 비운 뒤 사용하지 않고 채우면 **2.8초**다. 이는 **발동률**이며 처치율이 아니다. 적 체력·공격 범위·명중 결과 없이 초당 처치 수를 계산할 수는 없다.

충전이 자원으로 기능하려면 `t_recharge > t_cycle`이어야 한다. 한 번 사용할 때까지 1개 이상이 다시 차면 연속 사용으로 고갈되지 않는다. 즉 수식은 수치를 정당화하는 장식이 아니라, 자원 선택이 사라지는 조건을 찾는 도구다. 3.6→2.6처럼 진행 중인 소수부를 보존하는 규칙은 사용 때문에 재충전이 처음부터 다시 시작되는 불이익도 막는다.

다만 이 조건이 후퇴 행동까지 보장하지는 않는다. Formula 8의 2026-08-07 진단은 발동 빈도의 감소와 "물러나 재충전"하는 행동 국면을 구분한다. 실제 입력 간격이 회복 시간 이상이면 충전은 소진되지 않을 수 있고, 2.8초도 강제 대기가 아니다. 재배치를 유도한다는 설계 의도는 별도의 플레이 관찰로 확인해야 한다.

#### 성장 — 같은 플리커의 판단을 다르게 만든다

| 설계된 강화 | 바뀌는 규칙 | 플레이어 선택에 주는 의미 |
|---|---|---|
| 처치 시 충전 회복 | 처치가 발생한 실행에 충전을 일부 돌려준다. 한 실행의 다중 처치는 환급을 누적하지 않는다 | 매번 처치를 이어가는 가치가 생긴다. 밀도가 높다는 이유만으로 자원이 무한히 불어나지 않도록 제한한다 |
| 반동(Recoil) | 도착 후보를 출발점 방향으로 옮긴다. 대상·피해량은 그대로다 | 공격 이후 어디에 남는지를 바꾼다. 순수 피해 증가와 다른 성장 축이다 |
| 지연 재타격(Quantum Echo) | 죽은 적 객체가 아니라 처음 맞힌 자리를 저장하고, 지연 뒤 근처의 살아 있는 적을 찾는다 | 한 방에 죽은 대상을 또 때려 효과가 사라지는 문제를 피한다. 같은 자리로 들어오는 적의 배치가 효과에 관여한다 |

근거: `design/gdd/flicker-combat.md` Core Rules 14·15·19 및 Formula 13. 표의 선택 의미는 규칙에서 도출한 설계 해설이며, 선호도나 체감 효과를 측정한 결과가 아니다. 카드 효과의 구현 완료나 현재 추첨 풀 포함 여부도 이 표로 주장하지 않는다.

#### 개정 사례 — 판타지를 규칙과 맞추고 다시 질문한다

| 시점 | 발견한 간극 | 바꾼 것과 남긴 질문 |
|---|---|---|
| 2026-07-09~10 | "무리를 통째로 지운다"는 표현에 비해 당시 기본 공격은 단일 대상이었다 | 한 번의 광역 소거라는 약속을 낮추고, 빠른 개별 타격의 누적 감각으로 설명했다 |
| 2026-07-15 | 짧은 실행 간격만으로는 자원 감각이 약하다는 사용자 관찰 | 충전 풀을 추가해 연속 사용과 재충전의 선택을 만들었다. 수치는 프로토타입 검증 대상으로 남겼다 |
| 2026-08-09 | 기본공격의 플리커 성분을 광역으로 정하면서 이전의 단일 대상 설명이 낡았다 | 단일 대상 전제를 철회했다. 동시에 "광역이면 자동 선택이 알아서 하는 느낌을 더 키우지 않는가"를 새 검증 질문으로 남겼다 |

근거: `design/gdd/flicker-combat.md` Player Fantasy와 개정 기록, `design/gdd/game-concept.md` Core Fantasy. 광역 결정만으로 한 번에 화면 전체를 지운다고 확대하지 않는다.

#### 플레이어가 직접 골랐다는 감각을 어떻게 검증하는가

GDD의 Player Fantasy는 **최소 5명, 각 10분**의 프로토타입 테스트를 요구한다. 다음 중 하나라도 나오면 자동 선택과 플레이어 의도의 연결을 재검토하는 기준을 둔다.

- 세션의 40% 이상(5명일 때 2명 이상)이 자유 서술에서 자발적으로 "내가 고르지 않은 적에게 끌려갔다"는 계열의 반응을 보인다.
- 입력 때 표시된 대상이 실행 시점까지 생존했는데도 다른 생존 대상이 맞는 사건이 세션당 평균 3회 이상 발생한다. 원래 대상이 죽어 정상적으로 재선택한 경우는 이 실패에 포함하지 않는다.

**모집 구성 (2026-09-30 추가, 개발자 결정).** 노리는 시장이 플리커 판타지를 이미 아는 플레이어이므로(위 "판타지의 수요 근거"), 표본을 둘로 나눈다.

| 그룹 | 인원 | 조건 | 보는 것 |
|---|---|---|---|
| 주 표본 | 5명 이상(GDD 최소 인원을 이 그룹만으로 채운다) | PoE Flicker Strike 나 D2 Enigma(Teleport) 빌드를 실제로 해 본 플레이어. PoE·Diablo 커뮤니티에서 모집 | 익숙한 판타지를 원버튼·자동 선택으로 옮겼을 때 "쓸어 담는 쾌감"이 사는가 |
| 대조 표본 | 2~3명 | 서바이버류는 하지만 플리커 빌드는 모르는 플레이어 | 판타지를 모르는 서바이버류 플레이어에게도 통하는가. 팬은 통제감 비용에 익숙해 "끌려갔다"를 덜 말할 수 있으므로, 그 편향을 드러내는 역할도 한다 |

- 위 두 실패 기준은 **그룹별로 따로 센다.** 대조 표본은 인원이 적어 방향을 보는 참고치로만 읽는다.
- 읽는 법: 주 표본이 기준에 걸리면 핵심 대상에게 통하지 않는 것이므로 설계를 재검토한다. 주 표본만 통과하면 대상은 좁지만 분명하다 — 스토어 문구·태그를 액션 RPG 쪽으로 맞춘다. 둘 다 통과하면 서바이버류 전체로 넓혀 말할 근거가 생긴다.
- 모집 설문에서 플레이 경험(게임·빌드·시간)을 먼저 받고, 테스트 뒤 자유 서술은 그룹을 모르는 상태로 분류한다.

이는 **통과 결과가 아니라 사전에 적은 실패 판정 기준**이다. 이 절에서는 해당 조건으로 수행한 외부 플레이테스트 결과를 확인하지 못했다 `[미검증]`. 사용자 내부 플레이 관찰, 설계 리뷰, 규칙의 수학적 정합성과 외부 플레이어가 느끼는 재미는 서로 다른 증거다.

### 2.8 초안이 현재가 되기까지 — 플리커·마력탄·궤도검의 변천 `[확인: 커밋 이력·GDD 개정 기록·코드 기본값]`

§2.7 이 규칙의 의도를 설명했다면, 이 절은 세 설계 요소가 초안에서 현재까지 **실제로 어떻게 바뀌었는지**를 커밋 이력으로 추적한 기록이다. 각 요소를 처음 → 바뀐 순간 → 지금 → 문답 순서로 적었다. 날짜는 커밋 작성일이다. 바꾼 이유는 커밋 본문과 GDD 개정 기록에 적힌 것만 옮겼고, 기록이 없으면 "이유 기록 없음"으로 뒀다. "지금"의 수치는 데이터 파일과 C# 기본값이며 씬·프리팹의 실효값이 아니다. 현재 화면은 재현하지 않았다. 조사는 별도 실행 주체(Codex)가 수행했고, 인용 해시는 저장소에서 대조했다.

#### 2.8.1 플리커 — 원버튼 텔레포트 한 방에서 충전·콤보·광역·잉크 획으로

**처음 (2026-07-07 GDD).** 버튼 한 번에 선정된 한 명 앞으로 순간이동해 같은 프레임에 타격한다. 광역과 연쇄는 이후 업그레이드의 몫이었다. 충전 풀은 없었고, 이동 잔상 시간과 회복 시간만으로 실행 간격을 만들었다. 대상이 없으면 짧은 무피해 대시를 했다. 연출은 출발에 청록 실루엣 잔상, 도착에 청록 검격과 충격 링을 요구했다(설계 요구이며 구현 확인과 구분한다). 근거 `cccc3d88`.

| 날짜 | 무엇이 바뀌었나 | 왜 | 근거 |
|---|---|---|---|
| 07-15 | 충전 4개, 개당 0.7초 재충전, 0.37초 임팩트 지연. 빈 대시도 충전을 쓴다 | 자원 감각이 없었고 모션과 효과 타이밍이 어긋났다 | `59266199` |
| 08-05~06 | 사거리 9.6→6.72u, 빈 대시 실효 2→1.4u | 카메라를 당기면서 사거리와의 비율을 보존했다 | `fda6c213` |
| 08-09 | 자동전투를 생존의 바닥으로 복원하고 기본 플리커에 광역을 넣었다 | 자동전투를 서바이버 장르의 정체성으로 보는 결정, MVP 플레이 우선 | `b7a2e6a7`, `43a22f64` |
| 08-11 | 고정 여섯째 슬롯의 훅: 레벨 = 연속 타격 수 = 최대 충전 | Lv.1 한 타격에서 Lv.5 다섯 타격까지의 성장을 지정했다 | `76ea8442` |
| 08-11 | 마우스 클릭은 커서 기준 실행, 홀드는 연속 실행 | 커서가 이미 조준을 담당하므로 별도 홀드 조준 국면을 두지 않았다 | `929fa5cd` |
| 08-17 | 충전·콤보 하한 2. 짧은 홉은 관통 착지 | Lv.1 에 연속 공격이 없던 절벽과, 착지 거리 보정으로 생기던 뒷걸음질을 없앴다 | `aa01972e`, `064b3a60` |
| 08-30 | 빈 땅 재배치 뒤의 자동 연쇄 제거 | 빈 땅으로 간 뒤 적에게 끌려가는 동작을 원하지 않았다 | `57e06104` |
| 09-01 | 스틱 4규칙: 중립은 전방향, 입력 중 ±45° 콘, 홀드 반복, 더블탭 홀드는 지점 조준 | 실기기 검증 뒤 결정. 커서가 없는 스틱에는 별도 방향 신호가 필요했다 | `e6d8777b` |
| 09-02~03 | 연출: 본체 디졸브·연기·리본, 광역 피격 표시를 바닥 파장으로, 중복 파문·데칼 제거 | 소멸 방향이 반대로 읽혔고 원형 표시가 여럿 겹쳤다 | `77e2b8f6`, `3daa1be6`, `0ec33518` |
| 09-07 | 연출: 플리커 모션을 Codex Cast 클립의 일부로 교체 | 양손 밀기 피크를 임팩트 시점에 맞췄다 | `2ef32fc4` |
| 09-09~11 | 연출: 잉크 획으로 전환, 공격 스타일별 색 시험, 이동은 검정으로 지면에 얇게 | 아트 시트 적용, 이동 이펙트가 플레이어를 덮는 문제 | `ec44d1af`, `cd9d850b` |
| 09-13 | 연출: 궤적 재질·폭 재설정 경로 수정, 잉크 폭 5px | 반투명 연기용 직렬화 폭 106.7px 가 불투명 잉크에서 검은 막대가 됐다 | `20e47088` |

**지금 (2026-09-14, `FlickerCombat.cs` 기본값).** 기본 피해 25. 광역 반경 2.0u·추가 대상 상한 3·감쇠 0.5(코드에 임시값으로 표시). 임팩트 지연 0.25초, 회복 0.08초. 충전 하한 2, 재충전 0.7초, 콤보 간격 0.08초. 최대 충전은 `max(2, 훅 레벨)`로 계산하며 옛 필드 `_maxCharges`(4)는 읽지 않는다. 빈 대시 1.4u. 더블탭 창 0.3초, 탭·홀드 문턱 0.12초. 커서 스냅 반경은 코드 기본값 1.0u 이나 08-31 커밋이 플레이어 직렬화 값을 3u 로 바꿨다고 기록하므로 실효값은 미확인이다.

Q: 처음 플리커는 한 명만 때렸나?
A: 그렇다. 07-07 에는 단일 대상이었고 08-09 에 기본 플리커에 광역이 들어갔다.

Q: 자동전투를 넣었으면 핵심 아이디어가 바뀐 것 아닌가?
A: "자동공격을 대체한다"는 설명은 바뀌었다. 자동전투를 생존의 바닥으로 두고, 이동으로 공격하는 능동 개입을 정체성으로 재정의했다(§2.7 도 같은 개정을 다룬다).

Q: 충전과 연속 공격은 처음부터 있었나?
A: 충전은 07-15, 레벨 연동 콤보는 08-11 에 들어왔다. 08-17 에 시작 구간에도 연속 공격이 있도록 하한 2를 추가했다.

Q: 연출에서 가장 크게 바뀐 것은?
A: 초기 청록 잔상 설계에서 9월 연기·디졸브를 거쳐 잉크 획으로 바뀌었다. 이동을 읽는 방향과 화면을 덮는 면적까지 함께 수정했다.

#### 2.8.2 마력탄(Mage Bolt) — 히트스캔 자동 사격에서 체공·순차 유도 발사체로

**처음 (2026-08-04~05).** 보유만으로 작동하는 자동 사격과 플리커 실타격 착지 산탄을 묶은 카드로 신설됐다(후보였던 Blink Shards 를 두 번째 성분으로 흡수). 자동 성분은 타겟 스코어로 한 명을 골라 1.0초마다 히트스캔 피해를 줬고, 착지 산탄은 4방향·관통 2·쿨다운 2.0초였다. 별도 버튼이나 탄약 스톡은 없었다. 실제 비행체 없이 플리커 트레일을 재사용했다. 근거 `38674b23`, `9c68c800`.

| 날짜 | 무엇이 바뀌었나 | 왜 | 근거 |
|---|---|---|---|
| 08-09 | 설계 검토: 자동 피해 예산에 맞춰 마력탄도 감축하는 옵션 B 를 계산했다(적용값 아님) | 궤도검·마력탄·기본 자동공격의 처치율 예산이 양립하지 않았다. 감축 뒤에도 기준을 만족하는 해는 얻지 못했다 | `79bc8c7e` |
| 08-11 | 연출: 공유 트레일에 마력탄 전용 청색 틴트 | 궤적이 플레이어 플리커의 청록으로 나가 정체성이 섞였다 | `f52909a4` |
| 08-18 | 착지 산탄의 폭·길이에 태그 퍽 배율 연결 | 선폭·선장 카드를 얻어도 산탄 기하가 변하지 않던 오류 | `695b2f2b` |
| 09-02 | **히트스캔을 소환 → 체공 → 순차 유도 발사체로 교체.** 시간 충전과 플리커 홉당 충전을 분리 | 사용자가 Path of Exile 2 의 Ember Fusillade 를 참조로 지목하고 동작을 확정했다. 8월의 예산 감축과는 별개 결정이다 | `484427ec`, `5aa9c1a8` |
| 09-02 | 연출: 공전 룬 링 → 불규칙 부유·생성 팝 → 발광 구체·별모양 착탄 | 사용자 콘셉트와 참조 이미지가 원형 문양 대신 빛나는 발광체를 요구했다 | `01b8acbc`, `a38086f3`, `88406e6f` |
| 09-02~03 | 시간 충전 상한 5→2 | 평시에 탄이 많이 떠 있으면 플리커로 늘어나는 순간이 가려졌다 | `e463d0f5`, `363a0cc9` |
| 09-05 | 체공 수가 많을수록 발사 간격이 짧아진다 | 고정 0.12초 간격에서는 쌓인 스톡이 천천히 소진돼 순간 증가의 느낌이 약했다 | `7f2cbca7` |
| 09-11~13 | 연출: 잉크 투사체 화살 형태 확인 뒤 형태 유지 회전안 적용 | 발광 효과를 잉크로 바꾸자 불투명 덩어리가 되는 문제를 줄였다. 최종 회전안의 선택 이유는 기록 없음 | `75cc7322`, `f6dce70b`, `9cdbcdf2` |

**지금 (2026-09-14, `MageBolt.asset` · `MageBoltController.cs` · `MageBoltProjectile.cs` 기본값).** 자동 성분은 풀링된 실제 투사체이며 가장 오래 체공한 탄부터 발사한다. 대상이 없으면 대기한다. LevelMax 5. 시간 충전 주기 Lv.1~5 = 2.00 / 1.00 / 0.66 / 0.50 / 0.40초, 플리커 홉당 충전 1~5개. 시간 충전의 스톡+체공 상한 2, 최소 체공 0.5초(플리커 충전에는 상한 없음). 발사 간격 기본 0.12초, 추가 체공 탄 가속 계수 0.6, 하한 0.03초. 투사체 초기 속도 2.5u/s, 최대 14u/s, 가속 40u/s², 유도 회전 220°/s, 정렬 문턱 15°(정렬 후 유도를 풀고 직진하므로 빗나갈 수 있다), 수명 6초. 피해는 기본 플리커 피해 × 카드 배율 × 레벨별 감쇠(기저 0.15, 레벨당 0.04). **착지 산탄은 별도 실타격 성분으로 남아 있다**(쿨다운 2.0초, 길이 4.5u, 폭 0.4u). 컨트롤러 상단 주석에는 상한 5라는 옛 설명이 남아 있으나 현재 필드는 2다.

Q: 처음부터 실제로 날아가는 탄이었나?
A: 아니다. 08-05 에는 즉시 피해를 주는 히트스캔에 시각 트레일만 붙였고, 09-02 에 체공·비행·충돌을 가진 투사체로 바꿨다.

Q: 마력탄은 왜 재설계됐나?
A: 8월에는 자동 피해 예산 때문에 감축을 검토했다. 9월에는 사용자가 체공 후 순차 유도 발사를 지정해 동작 자체를 바꿨다. 두 결정을 하나의 밸런스 개선으로 묶을 근거는 없다.

Q: 자동 카드인데 플리커가 무엇을 바꾸나?
A: 홉마다 레벨 수만큼 스톡을 더하고 산개도 커진다. 시간 충전 상한을 2로 낮춘 것은 이 증가를 눈에 띄게 하기 위해서였다.

Q: 탄이 많이 모여도 같은 속도로 쏘나?
A: 현재는 아니다. 09-05 부터 체공 수가 많으면 빠르게 쏘고, 큐가 줄면 원래 간격에 가까워진다.

#### 2.8.3 궤도검(BladeOrbit) → Dancing Blade — 원형 범위 주기 피해에서 칼날별 판정·플리커 길이 성장으로

**처음 (2026-07-30).** 카드 보유로 작동하는 궤도 패시브와 플리커 실타격 디스차지를 함께 구현했다. 화면에는 세 칼날이 반경 1.8u 를 90°/s 로 돌았지만, 피해는 **플레이어 중심 반경 1.8u 안의 적을 거리순으로 최대 3명 골라 1.4초마다** 주는 방식이었다. 칼날 접촉은 검사하지 않았다. 틱 명중·스포크 궤적·칼날 트레일은 08-01 에 연결됐다. 근거 `c99408fb`, `d5ef8064`, `f4539a26`.

| 날짜 | 무엇이 바뀌었나 | 왜 | 근거 |
|---|---|---|---|
| 07-31 | UI: 카드 프리뷰에 궤도·디스차지 두 행의 절대 피해 표시 | 디스차지만 보여 궤도 피해 증가분이 숨겨져 있었다 | `71e6f989` |
| 08-01~02 | 레벨 상한을 잠정 5로 늘렸다가 궤도검은 3으로 되돌림 | Lv.4~5 가 궤도 성분에서 성장 가치가 없었고 디스차지 조합 상한도 만족하지 못했다 | `67940cce`, `ba18c580` |
| 08-09 | 설계 검토: 자동 피해 예산에 맞춰 틱 간격·감쇠·상한 재검토(확정값 없음) | 예산을 맞춰도 계속 도는 칼날과 드문 피해 판정이 어긋나 카드 정체성이 무너졌다 | `73ee62bb` |
| 09-03 | **Dancing Blade 로 재설계: 칼날 개수 = 레벨, 플리커마다 길이 성장, 칼날별 캡슐 판정, 같은 적 재타격 0.5초** | 사용자 확정 재설계. 같은 적의 피해가 칼날 수에 비례해 폭증하지 않도록 재타격 제한을 뒀다 | `a3478c1f`, `81017eaf` |
| 09-04 | 성장 방향을 바깥으로 제한, 기본 반경 1.8→1.2u, LevelMax 5, 디스차지 개수 = 레벨 | 중심 피벗을 확대하면 안쪽으로도 자랐다. 기본 위치를 캐릭터 가까이 두라는 결정 | `a98dbb52`, `1ea95469` |
| 09-04 | 연출: 청백색 물리 칼날 → 보라 발광 검 → 날·가드·자루 실루엣 | 참조는 에너지 검이었지만 발광 큐브는 칼보다 덩어리로 보였다 | `3b59aa98`, `1aaef243` |
| 09-04~05 | 회전 가속·추가 회전 도입, 순간 스냅을 연속 회전으로. 길이 성장은 출발, 속도 상승은 도착 시점으로 분리 | 세게 휘두르는 느낌을 요구했으나 순간 스냅은 위치가 튀어 보였다 | `67488311`, `08890d37`, `d8ca53d2` |
| 09-12 | 연출: 잉크 칼날을 XZ 평면에 눕히고 Z축 성장을 되살림 | XY 평면·Z 두께 0인 빌보드에는 Z축 스케일을 곱해도 길이가 보이지 않았다 | `2a4cb761` |
| 09-13 | 연출: 도(刀) 실루엣 마스크 수정, 트레일을 칼끝으로, 메시는 균일 비율 성장 | 마스크 경계 함수 오용으로 칼날 알파가 사라졌다. 트레일 폭 확대는 잉크에서 두꺼운 판으로 보였다 | `9cdbcdf2`, `20e47088` |

**지금 (2026-09-14, `BladeOrbit.asset` · `BladeOrbitController.cs` · `BladeOrbitEntity.cs` 기본값).** 표시명 Dancing Blade, LevelMax 5. 매 프레임 칼날 위치에서 바깥 방향으로 현재 논리 길이만큼 캡슐(반경 0.3u)을 검사하고, 같은 적은 0.5초에 한 번만 맞는다. 논리 길이는 기본 1.0, 플리커 시작마다 기본 길이만큼 더해 상한 5배. 마지막 플리커 후 0.5초 유지하고 초당 1.0씩 줄어든다. 궤도 반경 1.2u, 회전 90°/s, 도착 시 회전 가속 피크 3배·감쇠 0.5초·추가 회전 30°. 시각 스케일은 `길이 비율^0.55` 이므로 논리 길이 5배가 메시 길이 5배는 아니다. 피해는 기본 플리커 피해 × 카드 배율 × 감쇠(기저 0.08, 레벨당 0.04). 디스차지 감쇠 데이터는 3원소(0.3 / 0.44 / 0.52)만 남아 있어 Lv.4~5 조회 결과는 미확인이다. 옛 상수 `NBlades=3`, `TTick=1.4` 는 파일에 남아 있지만 현행 판정이 쓰지 않는다.

Q: 레벨을 올리면 검이 커지는가?
A: 현재 설계에서 레벨은 칼날 개수, 플리커 실행은 길이 성장을 담당한다. 화면 스케일은 별도의 지수식이라 논리 길이와 같은 배율은 아니다.

Q: 처음에도 실제 검에 닿아야 맞았나?
A: 아니다. 처음에는 플레이어 중심 원형 범위의 주기 피해였다. 09-03 에 칼날 위치와 방향을 따라 캡슐을 검사하도록 바꿨다.

Q: 궤도검은 왜 눕혔나?
A: 잉크 전환 때 세운 XY 평면 메시에는 성장시킬 Z축 길이가 없었다. XZ 평면의 칼로 바꿔 가로로 돌고 자라는 동작을 되살렸다.

Q: 릴 후반에 화면을 가로지르던 굵은 검은 막대도 궤도검이었나?
A: 아니다. 마지막까지 남았던 막대는 플리커의 텔레포트 궤적(FlickerTrail)이었다. 반투명 연기용으로 직렬화된 폭 106.7px 가 불투명 잉크로 바뀌면서 드러났고, 09-13 에 5px 로 고쳤다.

#### 2.8.4 이 절에서 확인하지 않은 것

- 씬·프리팹·재질·셰이더의 현재 파일과 실제 화면은 열지 않았다. 수치는 코드 기본값과 데이터 직렬화 값이며 실효값과 다를 수 있다.
- 카드 감쇠 함수의 구현 파일은 열지 않았다. 최종 피해 사다리를 계산해 현재값으로 단정하지 않았다.
- 커밋이 참조한 당시의 발주서·임시 설계 노트는 열지 않았다. 지정된 GDD 와 커밋 본문에 기록된 결정만 썼다.
- 당시 캡처·영상과 Unity 플레이는 재실행하지 않았다. 커밋의 실측은 당시 작성자의 기록이다.

### 2.9 아트 방향의 변천과 캐릭터 파이프라인의 기록 `[확인: 커밋·이슈·문서]`

**개발자의 설명(슬라이드 "왜 이 비주얼인가", 개발자 판단 · 효과는 측정 전).** 일반 3D 에서는 AI 생성 자산의 작은 오차(리깅·변형·리타게팅)가 결함으로 읽혔다. 오차를 하나하나 고치는 대신, 오차가 선 하나로 읽히는 페인트 룩으로 바꿨다. 목표는 스케치와 컬러 페인트로 순간이동의 궤적과 전투를 한눈에 구분되게 하고, 스토어 썸네일에서 다른 게임과 분명히 구분되는 것이다.

아래는 저장소에 실제로 있는 기록이다. 저장소의 커밋에는 전환 이유가 "사용자 요청·결정" 문장으로만 남아 있어서, 위 설명과 아래 캐릭터 파이프라인 문제 기록 사이의 인과를 커밋으로 확인할 수는 없다. 위 설명은 개발자의 판단으로 읽는다.

| 날짜 | 기록 | 근거 |
|---|---|---|
| 2026-07-05 | 아트 바이블 Rev.1 — 로우폴리 판타지 스타일라이즈드 3D 로 9개 절 확정 | `35024bf6`, `design/art/art-bible.md` 개정 이력 |
| 2026-07-15 | 마법사 공중부양 컨셉 폐기. Idle/Run 생성을 hovering 계열로 3회 시도해 반복 실패, "프롬프트 문제가 아니라 모델의 근본적 한계"로 판정 | `7a9f61b9` |
| 2026-07-17 | 포즈 붕괴 사고 원인 교차 검증 — Tripo 자동 리그의 본마다 일관되지 않은 roll 이 리타게팅 때 관절을 어긋난 평면으로 굽힘. 관찰된 붕괴는 "팔다리가 몸통 쪽으로 뭉개지는 수준". 커밋 제목은 "Berserkin 한정"이며 파이프라인 전체의 구조적 결함 가설은 기각됐다(같은 파이프라인의 hooded_mage 는 정상) | `227086db`, `design/art/character-pipeline.md` §3.3a |
| 2026-07-24 | Ratmen 리그 결함 재작업 2라운드(Codex), 웨이트 수정 1라운드는 미해결 | `455b3268` |
| 2026-08-30 | Rev.10 까지 "밝은 로우폴리 낮 아레나" 표현 유지 — 전환 직전까지 로우폴리 3D 방향 | `design/art/art-bible.md` 개정 이력 Rev.10(2026-08-30) |
| 2026-09-06~07 | 마법사 참조 영상 애니메이션 재생성 인수인계에 T-포즈·하체각 문제 기록 | `production/session-state/handoff-mage-anim-codex-2026-09-06.md`, `handoff-monster-remake-2026-09-07.md` |
| 2026-09-09 | 다른 프로젝트의 연필 드로잉 셰이더를 반입해 마법사에 시험 적용("사용자 요청") → 같은 날 "3번(스웜 포함 완전 전환)으로 간다"(사용자 결정) | `d6d571b1`, `3558b7e7` |
| 2026-09-10 | 같은 씬·모델에 재질 값만 바꿔 채색 3조합(단색 마커 / 원본색 / 캐릭터만 원본색)을 만드는 비교 영상 도구 | `7908bb2c` |
| 2026-09-11 | 아트 바이블 Rev.12 — 페인트 룩 전환을 정본화, `design/art/sketch-look-direction.md` 신설 | `4f9a707d` |
| 2026-09-13 | 컨셉 이미지와 현재 구현의 갭 분석 11건·결정 3건 | `c60b7fe7`, `design/art/sketch-concept-gap-2026-09-13.md` |
| 2026-09-14 | 키 아트를 정본으로 격상(Rev.14) | `a204fef4` |

전환이 만든 새 문제도 기록돼 있다: 바닥 경계와 장애물이 화면에서 사라짐(#95), Flicker 계열 이펙트 2개가 스케치로 교체되지 않음(#97), 카메라 변경으로 판독 유도가 낡음(#94). 셋 다 2026-09-11~14 에 닫혔다. 스케치 전환 뒤 리깅·변형 문제가 덜 보이게 됐다는 기록은 없다. 
---

### 2.10 빌드 구조 결정 — 색 계열 기술 슬롯 (2026-09-17) `[확인: 커밋·발주서·설계 문서]`

슬라이드의 룩 장과 재사용 장이 이 결정을 인용한다. 설계 문서는 `design/gdd/color-slot-system.md`(초안, 시스템 인덱스 19번), 결정 기록은 `docs/handoffs/260917_color-slot-review/brief.md` §1~§9 다. **수치는 전부 미정이고 구현 전이다.** 이 절은 "무엇을 결정했는가"와 "조정 손잡이가 있는가"만 적는다.

**하루의 순서 `[확인]` (커밋 시각, KST)**

| 시각 | 일 | 근거 |
|---|---|---|
| 10:17 | 사용자 제안(시작 슬롯 4, 기술을 색으로 분류, 슬롯에 색 고정 없음, 두 색을 섞으면 혼색 슬롯 추가) → 검토자 셋 × 2 라운드 교차 검토(game-designer·art-director = Claude, Codex = gpt-6-astra) + 종합 | `cf240d0`, `brief.md` §1·§5, `synthesis.md` |
| 11:49 | 3차: R 물리 · G 재생/보조 · B 마법으로 16칸 로스터 매핑 | `68c6cd8` |
| 12:10 | 4차: 세 색을 매직 더 개더링 색 파이(Red·Green·Blue)에 대응, G 에 회복 포함(회복원 신설 금지 조항 개정 확정, 잔불 픽업과 병존) | `4e79e02` |
| 14:26 | 5차: 확정 로스터 19칸(현행 10 · 개조 2 · 신규 7), 신규 기술 초안 7, 조항 개정 문안 | `0c1e659` |
| 15:49 | 새 설계 문서 `color-slot-system.md` | `b8c2f14` |
| 17:54 | 파생 개정 5개 문서(카드 뽑기 자격 술어·슬롯 상한 가변·회복 조항·태그 문서·기술 요약) + 시스템 인덱스 19번 | `4bb4c92` |

**사용자 결정으로 확인되는 것 다섯** (`brief.md` 인용 원문 기준)

| 결정 | 내용 | 검토가 지적한 것 |
|---|---|---|
| 균형의 축을 도달 확률로 | "완성된 혼색 빌드가 단색보다 강해도 결함이 아니다. 균형의 축은 최종 파워가 아니라 도달 확률과 과정의 위험" (§5.1) | 1차 검토 셋 모두 "혼색 우월 = 결함"으로 지적 |
| 몸 색 = 보유 기술의 합성색, 전체 칠 | "컬러별로 부분을 칠하는 게 아니라 전체 컬러를 현재 보유 스킬의 합으로 칠한다. 가독성 때문에" (§5.3). 0색 무채 → 원색 → 혼색 → 세 색이면 Rainbow | 아트 디렉터: 마커 층에만 칠하고 위치 판독은 머리 위 표식·발밑 번짐이 유지한다는 조건 |
| 같은 색 겹침 = 혼색의 거울 | 같은 색을 둘 이상 가지면 그 색의 심화 슬롯이 열린다. RRR → RRRR. 심화는 기존 기술 강화가 아니라 추가 슬롯용 기술 (§6.2·§9) | 3차까지 "강화"를 승수 카드로 읽던 본체 가정을 정정 |
| 색 상성 없음 | 적도 특성 색을 몸에 입되 "색은 무엇을 하는 놈인지까지만", 포켓몬식 상성은 넣지 않음 (§5.4) | — |
| 충돌 조항은 회피하지 않고 개정 | 회복원 신설 금지(R-HP-03)와 카드 잠금 금지(Core Rule 2b) 둘 다 검토에서 걸림 → 둘 다 범위를 좁혀 개정(§7.2·§8) | 검토자가 "충돌을 이유로 표를 비우지 말라"는 지시를 받고 개정 범위를 적음 |

**빌려 온 것.** 색 파이와 혼색 처리는 매직 더 개더링(§7), 두 색 조합으로 열리는 합성 기술은 하데스의 듀오 보온과 같은 계열, 조건부 해금은 뱀파이어 서바이버즈의 진화 체계와 같은 계열이다. 이 저장소가 독자적이라고 말할 수 있는 부분은 "빌드가 화면의 몸 색으로 보인다"와 "슬롯 수가 보상이다" 둘이다.

**조정 손잡이가 있는가 `[확인]`** (설계 문서 Tuning Knobs 표, AC-CS-13 "값은 `Assets/Data/` 에, 하드코딩 없음")

| 나올 수 있는 우려 | 손잡이 | 자리 |
|---|---|---|
| 단색 빌드가 약할 수 있다 | 심화 해금 개수 `k_deep`(2단·3단 분리, OQ-2), 기술별 `LevelMax`, 승수 카드 | Tuning Knobs, `skill-perk-tags.md` §5-1 |
| 혼색 도달이 너무 쉽다 | 혼색 조건 개수 `k_mix`, 해금 카드 가중 `w_c`, 카드 풀 크기 | Tuning Knobs, OQ-6 |
| 슬롯이 늘면 화면이 시끄럽다 | 해금 상한 `maxUnlocks`, 이펙트 크기 표, 밀집 판독 게이트 G-D1/G-D2 | Tuning Knobs, `sketch-look-direction.md` §7.2, §7.1 |
| 한 판 길이 | 스폰 테이블, 경험치 곡선, 스테이지 배치 | 기존 정본. 현재 2분은 초안 배치의 결과이지 목표가 아니다(§1) |

열린 문제는 설계 문서 OQ-1~9(Rainbow 조건, 심화 단수, 색 진실 시점, `Displace` 구현 선행, 미끼 잔상 Blocked, 도달 장치, 수치 전부, 해금 카드 픽 용량, 적 특성 색 표). 밸런스 값은 이 시점에 정하지 않는다(사용자 결정 2026-09-17: "지금은 밸런스를 조정할 수 있는 핸들이 있는지만 검토한다").

이 절에서 확인하지 않은 것: 검토 문서 본문 전량(요지와 §9 결정만 읽었다), 신규 기술 초안 7종의 내용, 파생 개정 5개 문서의 문안.

## 3. 역할 설계 — 누가 무엇을 결정하는가

### 3.0 게임을 시작하는 두 가지 방식 (2026-09-30 추가)

| | 발상에서 시작 — Flicker Survivor | 발견에서 시작 — Petri War |
|---|---|---|
| 무엇을 만들지 | 사람이 먼저 정한다 | AI 가 Steam 시장을 조사해 후보를 내고, 초기 프로토타입까지 만든다. 사람은 움직이는 결과를 보고 그중 무엇을 키울지 고른다 |
| 고른 뒤 | 사람이 방향과 채택을 결정하고 AI 가 구현·측정·검토를 실행한다(아래 §3.1~) | 같다. 사람이 방향을 잡고 AI 와 구현·확인·수정을 반복한다 |
| 사람의 판단 대상 | 기획서의 아이디어 | 이미 움직이는 후보(예: 언데드 게임은 카피캣에 가까워 접음) |
| 상태 | `[확인]` 저장소 기록 | `[진술]` 개발자 글. 효과(후보를 찾는 비용·적중률)는 미검증. 선택 시점 근거를 먼저 기록하기로 함 |

첫 질문이 "무엇을 만들까?"에서 "이 중 무엇을 더 키워볼까?"로 옮겨 간 것이 두 번째 방식이다. 상세는 §10.6.

### 3.1 두 AI 의 경계 `[확인]`

2026-07-12 에 에셋 생성 실행을 Codex 로 분리했다. 변경 이력의 사유: *"정책/실행 역할 분리로 중복·충돌 방지"*. 두 AI 는 같은 저장소를 쓰지만 진입점이 다르다(Claude Code 는 `CLAUDE.md`, Codex 는 `AGENTS.md`).

| | Claude Code | Codex |
|---|---|---|
| 담당 | 정책·설계·관리·구현 (GDD, 아트 바이블, 아키텍처 결정, 코드 리뷰, 게임플레이 구현) | 에셋 생성 실행 (Tripo3D 호출, AI 이미지 생성, 다운로드·임포트·컨폼) |
| 스타일·스펙 결정권 | 있다 | 없다 |

Codex 진입점의 규칙 원문:

> 🔴 **Codex 는 이미 확정된 문서를 그대로 따른다.** 문서가 없거나 모호하면 **생성하지 말고 사용자에게 확인한다.** 에셋 생성은 토큰과 시간을 많이 쓰는데, 스펙이 흔들린 채로 생성하면 그 비용이 통째로 버려지기 때문이다.

> 🔴 **`asset-manifest.md` 에 `Done` 을 스스로 기입하지 않는다.** 반입 완료는 `Imported (게이트 대기)` 까지이며, `Done` 은 Claude Code 가 게이트를 실행한 뒤 부여한다.

즉 생성자의 "반입 완료"와 최종 판정을 분리했고, 최종 판정은 Unity Play Mode 실측(§7)을 요구한다.

### 3.2 서브에이전트 정의 49종 `[확인]`

`.claude/agents/*.md` 49개. 모델 배정은 opus 19 · sonnet 28 · haiku 2. 원칙은 의사결정 계열 → opus, 코드 작성 계열 → sonnet(2026-07-06 결정). 정의 파일의 실행 메타데이터 예(gameplay-programmer):

```yaml
tools: Read, Glob, Grep, Write, Edit, Bash
model: sonnet
maxTurns: 50
```

49종을 동시에 쓰지 않는다. 상시 8종(art-director, game-designer, systems-designer, gameplay-programmer, technical-artist, qa-lead, unity-specialist, unity-ui-specialist), 온디맨드, 휴면으로 나뉜다.

핵심 팀 재편은 실사용 기록으로 했다 `[기록]`: 초기 핵심 팀은 game-designer · unity-specialist · gameplay-programmer · qa-tester 4종(2026-07-04)에 art-director · unity-ui-specialist 를 더한 6종이었다. 이후 커밋 751건(집계 시점의 전체 커밋)의 귀속과 위임 기록을 조사한 결과 핵심 팀이던 qa-tester 귀속 1건, qa-lead 25건, systems-designer 42건, technical-artist 27건이었다. 이 수치로 qa-tester 를 빼고 qa-lead · systems-designer · technical-artist 를 넣어 현재의 8종이 됐다. (귀속과 위임 기록을 합산한 집계라 §12 표의 단순 집계와 다르다.)

### 3.3 도구 권한은 직함이 아니라 사용 기록에 맞춘다 `[기록]`

2026-08-30: `--agent art-director` 로 띄운 세션이 Unity 캡처와 커밋을 본체에 떠넘겼다. 정의의 `tools:` 가 `Read, Glob, Grep, Write, Edit, WebSearch` 뿐이었다. 전날 같은 역할이 백그라운드 잡으로 돈 세션의 실사용은 Unity MCP 232회 · Bash 286회. `Bash` 와 `mcp__unity-editor-mcp` 를 추가했고, 추가 뒤에도 `disallowedTools: Bash` 가 막고 있어 그 항목을 제거했다. 2026-09-06: Blender 서버가 연결돼 있어도 도구가 보이지 않아 `mcp__blender` 를 추가했다(도구 목록은 세션 시작 시 고정되므로 재기동 필요).

---

## 4. 병렬 실행 — 파일 소유권을 정한 뒤에야 가능했다

### 4.1 두 층 `[확인]`

- **서브에이전트**: 부모 세션이 범위를 정해 호출. 정의의 `maxTurns` 한도를 받는다. 좁고 끝이 보이는 조사에 쓴다.
- **독립 페인(herdr 다중 페인)**: 별도 CLI 세션. 턴 한도가 없다. 작성·실행·수정을 반복하는 긴 작업에 쓴다.

구분의 근거 `[기록]`: 2026-08-28 열린 조사 과제 3회가 턴 한도에서 잘렸고 산출물이 전부 0이었다. 반면 수정할 파일과 가드를 특정한 과제는 `maxTurns: 10` 인 devops-engineer 도 두 번 모두 끝냈다. 2026-09-02 gameplay-programmer 가 20턴 한도에서 조사만 하다 코드를 한 줄도 못 쓴 사건 뒤, 49종의 한도를 일괄 50으로 올렸다(사용자 결정). 지시 범위를 좁히는 규칙은 유지했다.

전역 규칙 원문:

> 🔴 **열린 탐색은 범위를 좁혀서 위임한다.** *"전수 파악해라"* 같은 열린 지시는 조사만 하다 한도에 걸린다. ① 기계적으로 좁힐 수 있는 조사는 메인 스레드가 먼저 끝내고 **판단만** 넘긴다 ② 대상 파일과 완료 조건을 명시한다 ③ *"결과를 먼저 쓰고 그다음 탐색하라"* 를 포함한다.

### 4.2 파일 소유권 `[확인]`

여러 페인이 같은 작업 트리를 쓰면 한 페인의 편집을 다른 페인도 보고, 커밋 대기 영역도 공유한다. 그래서 작업을 나눌 때 기능이 아니라 **경로**를 지정한다.

| 본체 전용 | `Assets/Scenes/*.unity` · `AGENTS.md`(= `CLAUDE.md`) · `.claude/settings.json` · `Packages/manifest.json` · `ProjectSettings/**` |
|---|---|
| 페인 자유 | 그 밖의 코드 · 문서 · 에셋. 단 한 페인이 한 경로를 맡는다 |

커밋 규칙 원문:

> 🔴 **경로를 명시한다. `git add -A` · `git add .` · `git commit -a` 를 쓰지 않는다.** 다른 페인·다른 작업의 미완성 편집까지 함께 커밋되기 때문이다.

### 4.3 자동 커밋 사고 `[확인]` (커밋 본문 확인, 사고 경위는 근거 기록)

세션 종료 훅의 자동 커밋이 다른 페인의 미완성 편집까지 한 커밋으로 묶었다. 2026-08-28 커밋 `9929d717` 에 훅·씬·렌더러 설정·에이전트 메모리 4종 5파일이 섞였고, 2026-09-06 에도 작업 중 파일 18개가 묶였다(이 커밋은 되돌렸다). 이후 보조 페인은 `FS_NO_AUTOCOMMIT=1` 로 시작한다. 자동 커밋은 정상 경로가 아니라 안전망으로 재정의했다.

### 4.4 발주서 `[확인]`

사람이 AI 사이를 중계하는 대신 `docs/handoffs/` 에 발주서를 두고 페인에 경로를 전달한다. 목표·입력·완료 조건·금지 경로·커밋 책임을 파일에 적는다. 2026-09-13 기준 `docs/handoffs/` 의 Markdown 68개.

---

## 5. 규칙의 자리 — 프롬프트, 파일, 훅

### 5.1 관측: 프롬프트 지시는 무시됐고 파일 규칙은 지켜졌다 `[기록]`

2026-08-28 세 페인에 "커밋하지 마라"고 프롬프트로 지시했지만 셋 다 커밋했다. 같은 세션들이 저장소에 적힌 귀속 규약과 위임 규칙은 따랐고 커밋 귀속도 정확했다. 이 관측이 "장기 규칙은 저장소 파일에 둔다"의 근거다. 모든 모델에 일반화할 수 있는 실험 결과는 아니고, 이 프로젝트의 운영을 바꾼 관측이다.

### 5.2 배치 `[확인]`

| 무엇 | 어디 | 로드 시점 |
|---|---|---|
| 승인 조건·권한·변경 금지 영역·완료 기준 | `CLAUDE.md` / `AGENTS.md` (진입점) | 매 세션 |
| 특정 경로를 다룰 때만 필요한 절차 | `.claude/rules/*.md` 12개, `paths:` 프론트매터 | 해당 경로 편집 시 |
| 상세 작업 지침·긴 예시 | 작업 문서 + 진입점에 읽는 조건 한 줄 | 필요할 때 |
| 근거·실측·변경 이력 | `docs/harness/rationale.md` · `CHANGELOG.md` | 로드되지 않음 |

조건부 규칙의 예(`blender.md`):

```yaml
paths:
  - "tools/blender/**"
  - "tools/arena_hq_*"
  - "tools/comfy/**"
  - "docs/blender-mcp-setup.md"
```

2026-09-06 에 상시 지침에서 근거·이력을 분리해 로딩량을 줄였고, 커밋 `74d37073` 으로 초기 지침의 크기·중복·끊어진 참조·순환 import·적용 범위 변화를 점검하는 도구(`tools/qa/check-initial-load.py`)를 두었다. 원칙: *"예산 초과는 삭제 신호가 아니라 재검토 신호다."*

### 5.3 훅 `[확인]`

`.claude/hooks/*.sh` 17개, `settings.json` 배치 16개(공통 헬퍼 1개는 다른 훅이 `source` 로 불러옴).

| 실행 시점 | 훅 | 역할 |
|---|---|---|
| SessionStart | check-auto-commit-lump · session-start · detect-gaps | 자동 커밋 덩어리 확인, 브랜치·열린 이슈·미푸시 경고, 프로필 출력, 문서 공백 탐지 |
| PreToolUse(Bash) | validate-commit · validate-push | 커밋 경로·DVC·LFS 검사(경고), 푸시 검증 |
| PreToolUse(Agent·Task) | profile-inject | 서브에이전트 프롬프트 앞에 실행 프로필 주입 (§11) |
| PostToolUse(Write·Edit) | validate-assets · validate-skill-change · check-initial-load | Assets 위치 규약, 스킬 변경, 초기 지침 변경 점검 |
| Notification | notify | 알림 |
| PreCompact / PostCompact | pre-compact · post-compact | 컨텍스트 압축 전후 상태 보존·복원 안내 |
| SessionEnd | auto-commit · session-stop | 자동 커밋(안전망), 실행 기록·세션 상태 정리 |
| SubagentStart / Stop | log-agent · log-agent-stop | 서브에이전트 실행 기록 |

초기 문서에 적혀 있던 "훅 18종"은 기록 오류였고, 교차 검증에서 이력 전수 대조로 정정했다.

모든 훅이 차단하지는 않는다. `validate-commit.sh` 의 DVC·LFS 검사는 경고다. 강제는 `permissions.deny`(강제 푸시, 하드 리셋, 위험한 삭제, 환경 파일 접근)가 맡는다. 안내·경고·권한 제한은 서로 다른 수준의 통제다.

### 5.4 훅의 실행 시점을 고친 사례 `[기록]`

2026-08-29: 지식 볼트 미러링을 `SessionEnd` 에 연결했더니 한 세션이 14시간 이어지며 커밋 15건이 쌓이는 동안 미러가 한 번도 갱신되지 않았다. git `post-commit` 으로 옮겼다. 커밋 한 번당 미러링 스크립트 실행 시간 296ms, 이슈 목록 갱신까지 포함하면 905ms.

---

## 6. 엔진에 직접 묻는다 — Unity MCP

### 6.1 연결 `[기록]`

Unity MCP 로 Play·Stop, 콘솔 조회, 화면 캡처, 씬 계층 조회, 임의 C# 실행을 한다. 2026-08-29 stdio 핸드셰이크로 도구 142종 확인(당시 기록값).

### 6.2 사례: 화면이 안 바뀔 때 `[확인]` — 커밋 `5cf82398`, 2026-09-10

1. 배경 선을 진하게 하려고 `SketchEnv_Mat` 을 조정했다. 화면은 거의 바뀌지 않았다.
2. Play 중 재질값을 읽었다. 정상 반영돼 있었다.
3. 그 재질을 쓰는 렌더러 49개 중 화면 안에 든 것은 5개. 그것도 거대한 바닥과 경계 지오메트리였다.
4. 격자를 끄고 캡처하자 배경이 백지가 됐다. 사용자가 보던 선은 별도 `SketchGroundGrid` 였다.
5. 같은 조사에서 적이 전부 배경 재질로 분류된 사실이 드러났다. 런타임 렌더러를 확인하니 캐릭터 재질은 플레이어만 쓰고, 관측한 적 6~7체는 배경 재질을 썼다.
6. 원인: `SketchPreviewSwapper` 의 분류가 풀에 잠든 적의 비활성 부모를 놓쳤다. 부모 조회에 `includeInactive: true` 를 넘기도록 수정.
7. 수정 뒤 Play 상태에서 적 6체가 캐릭터 재질을 쓰는 것을 확인.

설정 미반영 · 화면 밖 대상 · 잘못된 분류라는 세 가설을 순서대로 갈랐다.

### 6.3 측정 경로 자체의 결함 `[확인]`

- 이슈 #2(닫힘): 소크 하니스의 자동 카드 선택이 작동하지 않아 첫 레벨업에서 멈췄다.
- 이슈 #88(닫힘): 종료·재시작 실패 뒤에도 기록을 계속해 요약 지표가 오염됐다.
- 소크 하니스의 카드 선택이 무작위라 특정 스킬이 녹화 3회 연속 안 나왔다 → `UpgradeManager.DebugGrantLevel` 로 고정 지급하는 경로를 녹화 스크립트에 추가 `[기록]`.

---

## 7. 완료 판정 — 측정 조건과 유예 상태까지

### 7.1 판독 게이트 `[확인]` (아트 바이블 §5.6, §2.2.6)

- **G4a**: 판독에 필요한 월드 오브젝트의 응집 실루엣 최대 치수 `D_visual ≥ 0.40u`. 당시 플레이어 평면 뷰 높이 7.2u, 1080p 에서 약 60px 로 유도.
- **G4b**: 흩어진 요소를 한 덩어리로 셀 수 있는 간격 조건. 간격을 넘으면 단일 최대 요소 크기로 재계산(작은 점을 멀리 흩어 크기만 키우는 해석을 막음).
- **G-D1**: 대상 렌더러를 켠 화면과 끈 화면의 차이를 축소된 32칸에서 비교.
- **G-D2**: 대상의 가시 픽셀과 인접 비대상 픽셀의 국소 휘도 차.
- G-D1/G-D2 는 **적 70기 이상이 실제로 있는 Unity Play Mode 측정**을 요구한다. 70기는 정상 플레이 요구가 아니라 밀집 판독을 재기 위한 **스트레스 테스트 조건**이다.

### 7.2 게이트의 전제가 틀렸던 사례 `[확인]`

- #14(닫힘): QA 캡처가 853×480 이라 판독 게이트를 판정할 수 없었다.
- #15(닫힘): 기본 캡처 프레임에 적이 0기였다.
- #16(닫힘): 정상 플레이의 최대 동시 생존이 8기라 70기 측정 조건을 만들 수 없었다(측정 환경 문제).
- #94: 카메라 FOV 가 40 → 27.28 로 바뀌어 G4 의 뷰 높이 유도가 낡았다. 09-13 `c5fc21a0` 이 FOV 40 을 복원해 해결, 이슈는 09-14 닫힘(기준일 뒤).
- OQ-9: G-D1/G-D2 임계는 축당 통과 1사례·실패 3~4사례에서 나왔다. 표본 확대 필요.

### 7.3 MVP 유예 `[확인]` (아트 바이블 §0, 2026-08-30 사용자 결정)

Tripo 프랍 텍스처를 제한 색 슬롯에 맞추다 네 차례 개정에도 디테일 소실과 오분류가 반복됐다. 사용자가 MVP 기간 동안 일부 수치 게이트를 차단 조건에서 기록 조건으로 내렸다.

| 구분 | MVP 처리 |
|---|---|
| 색 제한, 컨폼 수치, 카테고리별 해상도·삼각형·텍스처 상한 | 편차를 기록하되 그것만으로 차단하지 않음 |
| 판독 원칙, 플레이어 식별 채널, 신호 발광 위계 | 유지 |
| 원본 보존과 결정적 제작 파이프라인 | 유지 |

편차 목록은 추적 이슈 #75(열림)가 소유. 생성 실행자가 스스로 완화한 것이 아니라 사용자가 단계에 맞춰 집행 방식을 바꾼 것이다.

---

## 8. 측정 규율 — 0 을 읽기 전에

### 8.1 세 상태 `[확인]`

| 상태 | 뜻 |
|---|---|
| 있음 | 관측 경로 안에서 대상을 확인 |
| 없음 | 관측 경로와 범위가 유효한 조건에서 부재를 확인 |
| 못 봤음 | 검사 범위·실행 조건·계측 한계로 판단 불가 |

전역 규칙 원문:

> 🔴 **대조군 없이 0을 읽지 않는다.** 어떤 측정이 두 번 0.00%를 뱉은 적이 있는데, 원인은 손으로 만든 카메라에 필요한 컴포넌트가 없어 해당 렌더 패스를 아예 타지 않은 것이었다. **0은 "없다"가 아니라 "못 봤음"이었다.**

> 🔴 **monotonic — 도구 출력은 근거를 *더할* 뿐, 원본 확인 의무를 *면제하지 않는다.***

### 8.2 근거 `[기록]`

2026-08-21 하루에 도구 출력을 7번 잘못 읽었고 그중 5번이 검사 범위 밖을 "해당 없음"으로 읽은 것이었다. 예: VFX 배선 스캔이 `ParticleSystemRenderer` 만 찾고 "쓰는 렌더러가 없다"고 보고했는데 실제는 `MeshRenderer` 였다. 나머지 2번은 원본을 열자 판단이 뒤집혔다. 이슈 #34(자기 측정 도구 과신), #38(QA 도구 3종의 오탐과 범위 실측).

### 8.3 서브에이전트 결과 `[확인]`

결과는 `완료` / `실패` / `INCOMPLETE` 로 읽는다. 마지막 발화를 산출물로 보지 않고 파일을 열어 확인한다. `stop_reason: tool_use` 는 정상 종료 사유이며 절단 신호가 아니다. 근거 `[기록]`: 중간 중단이 5회 연속 있었고 매번 마지막 문장이 "이제 …를 쓰겠다"였다. 조사 과제에는 "확인된 사실을 먼저 결론 형태로 쓰고 다음 탐색을 이어가라"를 포함한다. 이 방식으로 재지시해 완결 보고를 받은 사례는 1건이다(일반적 보장으로 해석하지 않는다).

검증자 규칙: 검증자는 작성자와 다른 실행 주체여야 하고, 대상을 보기 전에 스스로 먼저 잰다. 같은 세션 안에서 fresh(비fork) 서브에이전트로 세운다.

---

## 9. 실패 → 규칙 목록

| 날짜 | 사고 | 바꾼 것 | 확인 |
|---|---|---|---|
| 2026-07-05 | 훅·컨벤션 설정을 메인 스레드가 직접 처리해 커밋 귀속이 부정확 | 환경/툴링은 devops-engineer, 코드 스타일은 lead-programmer 에 위임, 실제 위임한 주체만 귀속 | 기록 |
| 2026-08-11 | 볼트가 한 달간 갱신되지 않았고 세션 중 한 번도 읽히지 않음 | "참고하세요" 대신 트리거 조건(값 바꿨는데 안 변함 등 4가지)으로 읽게 함 | 기록 |
| 2026-08-17 | 증상 하나에 원인 파악 전 코드를 세 번 고쳤고 둘은 오진 위 수정 | 결함은 고치기 전에 이슈로 등록. 손으로 닫지 않고 `fixes #N` 으로만 | 기록 |
| 2026-08-19 | 같은 사실이 커밋 2건·야간 보고서·이슈·채팅에 각각 재서술. 사용자가 6자("계속 진행해" 류)를 말했는데 채팅 응답이 1,521자 | 보고 규약: 채팅은 포인터, 300자, 강조 1개 | 기록 |
| 2026-08-21 | 도구 출력 오독 7건, 5건이 범위 밖을 없음으로 | 측정 3상태, 대조군 없이 0 안 읽음, 원본 확인 의무 | 기록 |
| 2026-08-28 | 세 페인이 "커밋하지 마라" 무시, 자동 커밋이 남의 편집을 한 덩어리 커밋으로 | 장기 규칙은 파일에, 보조 페인 자동 커밋 끔, 경로 명시 커밋 | 기록 |
| 2026-08-28 | 열린 조사 3회 턴 한도 절단, 산출물 0 | 범위를 좁혀 위임, 결과 먼저 쓰기 | 기록 |
| 2026-08-29 | SessionEnd 미러가 14시간 동안 0회 | post-commit 으로 이동 | 기록 |
| 2026-08-30 | art-director 에 Bash·Unity 도구 없음 | 실사용 기록(232/286회)에 맞춰 권한 추가, 막던 항목 제거 | 기록 |
| 2026-08-30 | 색 슬롯 게이트가 네 차례 개정에도 제작을 막음 | MVP 동안 수치 게이트를 기록 조건으로 유예, #75 추적 | 확인 |
| 2026-09-02 | gameplay-programmer 20턴 한도에서 코드 0줄 | 49종 maxTurns 50 | 확인 |
| 2026-09-06 | 초기 지침 비대 | 근거·이력 분리, 조건부 규칙, 로딩량 점검 도구 | 확인 |
| 2026-09-06 | Blender 도구가 정의에 없어 우회 | `mcp__blender` 추가 | 기록 |
| (누적) | 행 번호 인용 877건이 코드 이동으로 어긋남(문서가 가리킨 행과 실제 행의 차이가 한 곳은 217행, 다른 곳은 1,426행) | 심볼명+인용문, 검사기 `verify-code-quotes.py`, 역할 태그 | 확인 |
| 2026-09-13 | 서브에이전트 프로필 주입이 한국어 프롬프트에서 조용히 실패, 157건 중 0 | stdin UTF-8, 회귀 테스트, 조용한 실패 제거 (#98 닫힘) | 확인 |

### 9.1 의도가 실측에서 틀렸던 기록 — 확인까지 걸린 시간 `[확인]`

위 표와 §2.8·§7.2·§11.2 에 흩어진 것 중, "의도를 정했다 → 재 보니 아니었다 → 결함을 고치거나 의도를 바꿨다"의 형태가 분명한 것만 모았다. 프로젝트 전체를 접는 기준은 없지만(§16), 기능·하네스 수준에서 틀렸다고 확인하는 데 걸린 시간은 이렇게 실측돼 있다.

| 의도 (시점) | 실측 | 판정과 수정 | 걸린 시간 | 근거 |
|---|---|---|---|---|
| 서바이버의 수동성을 제거한다 (07-05 초판) | 자동전투 없이는 장르의 바닥이 없다 | 08-09 자동전투를 장르 베이스라인으로 복원, 플리커는 그 위의 개입층으로 재정의 | 35일 | `a1dee16b` → `b7a2e6a7`, ADR-0003 |
| 마법사를 공중에 띄운다 (07 초) | 생성 3회 반복 실패 | 07-15 컨셉 폐기, 모델의 한계로 판정 | 시도 3회 | `7a9f61b9` |
| 볼트를 참고하라는 지시 | 한 달간 세션 중 0회 읽힘 | 08-11 "참고하세요" 대신 트리거 조건 4가지 | 약 30일 | §9 표 08-11 |
| "커밋하지 마라"는 프롬프트 지시 (08-28) | 세 페인 전부 커밋. 규칙을 파일로 옮김 | 09-06 같은 사고 재발(18파일) → 보조 페인의 자동 커밋 자체를 끔 | 재발까지 9일 | §4.3, §5.1 |
| 아레나 발밑 채움판 폐기 (09-05) | 다른 구멍이 열림 | 09-06 "그 판단이 틀렸다" — 병용으로 되돌림 | 1일 | `43022d09` → `89c68903` |
| 모델별 실행 지침을 서브에이전트에 붙인다 (09-06) | 실행 기록 157건 중 0건 주입 | 09-13 인코딩 원인 수정, 대조군 재현 0 → 2,605바이트 | 7일 | §11.2, #98 |
| 카메라를 당겨 판독을 올린다 (09-10) | 판독이 나빠짐 | 09-13 원복, "판독은 카메라가 아니라 룩에서 올린다" | 3일 | `c8f28541` → `c5fc21a0`, #94 |

이 밖에 측정 장치의 전제 자체가 틀렸던 사례는 §7.2(#14·#15·#16·#94·OQ-9), 문서 자체의 수치 오류를 교차 검증이 잡은 사례는 §13 에 있다. 08-28 관측(§5.1)은 의도한 설계가 아니라 발견이다: 프롬프트 지시는 무시됐는데 파일에 적힌 규칙은 지켜졌고, 그 뒤 "장기 규칙은 파일에"가 원칙이 됐다.

인용 검사기의 원리: 코드 블록에서 고른 줄이 주석과 공백을 정규화한 뒤 원문에 존재하는지 본다. 과거 코드·미구현 설계·의사코드는 `before` / `spec` / `pseudo` 태그로 구분한다. 도입 시점 검증 대상 77건 일치.

---

## 10. 재현 가능한 제작 파이프라인

### 10.1 Blender 두 레인 `[확인]`

- **레인 A**: `blender.exe --background --python tools/<script>.py`. 결정적, 재현 가능. 최종 자산은 여기서만 나온다.
- **레인 B**: MCP 라이브 세션. 시험용. 결과는 반드시 레인 A 스크립트로 포팅.
- Codex 는 레인 A 만 실행한다.

### 10.2 hooded_mage 애니메이션 시험 `[기록]` (2026-09-06 인수인계, 2026-09-07 추가 기록)

- 같은 스크립트를 두 번 실행해 애니메이션 커브의 SHA-256 일치. MCP 상태와 레인 A 사이 본 좌표 차이 0m. FBX 변환 뒤 최대 FK 차이 약 5.88×10⁻⁷ m.
- 같은 문서가 한계를 명시: 손가락 본 부재, 로브·소매 변형 한계, Unity·밀집 게이트 미실행, 사용자 채택 대기. 규격 검증과 채택을 분리했다.
- 사용자가 참고 동작이 접지가 아니라 약간 떠 있는 상태라고 정정. 새 시도는 이전 접지 고정을 재사용하지 않았고, 상대 저점 기준 QC 분류를 실제 바닥 접촉으로 해석하지 않도록 구분했다. 파일·루프·변환 검사 통과와 실루엣 각도 불일치를 함께 기록.

### 10.3 원본과 출하물 `[확인]`

- 대용량 원본은 `Assets/**/_Source~/` 에 두고 git 이 아니라 DVC 가 관리(포인터 `.dvc` 17개). 폴더 이름 끝 `~` 는 Unity 임포트 제외 표시라 원본을 프리팹 참조 경로에서 막는다(파일시스템 경로로 직접 읽는 에디터 스크립트는 예외).
- 판단 기준: 게임이 런타임에 쓰면 정식 경로, 아니면 `_Source~/`.
- 2D 작업에서 Codex 는 DVC 를 실행하지 않고 경로 목록을 보고한다(샌드박스 제약, 2026-08-28 사용자 결정). 3D 는 DVC 3단계(add → push → 포인터 커밋)를 유지.

### 10.4 지식·일감·상태의 자리 `[확인]`

설계 지식·판정은 Obsidian 볼트와 `design/`, 세션 인수인계는 `production/session-state/active.md`, 일감·결함은 GitHub Issues. 볼트의 `repo/` 미러는 읽기 전용 생성물이라 근거로 인용하지 않는다.

### 10.6 경량 버전으로 만든 두 게임 — Arcane Pockets · Petri War `[확인]` (2026-09-28)

FS 의 개발환경에서 **엔진 지식과 리소스 제작 파이프라인을 뺀 경량 버전**으로 두 게임을 더 만들었다(정의는 사용자, 2026-09-28). 남긴 것은 작업 규칙 스킬(범위 확인·맥락 없는 독해·중복 정리 등)과, 만든 쪽이 아닌 독립 검증자가 먼저 재는 절차다. 두 저장소의 작업 기록에 같은 스킬 이름과 독립 검증 기록이 남아 있다. 리소스는 절차적 생성에 맡겼다.

| | Arcane Pockets | Petri War |
|---|---|---|
| 장르 | 마법 구슬로 정령을 포털에 넣는 3D 물리 당구형 퍼즐 로그라이트 | 한 접시 안의 미생물 생태계 자동 전투 |
| 기간 | 09-19 시작(사용자 진술). 저장소 기록의 첫 날짜 09-25, 저장소 생성 09-27 | 1주 안에 만들었다(사용자 진술) |
| 기술 | TypeScript · Three.js · Rapier 물리, 브라우저 | 외부 라이브러리 없는 Canvas 2D, 브라우저 |
| 리소스 | 이미지·모델·음원 파일을 불러오는 코드 0건, 효과음은 오실레이터 합성 | 화면은 코드가 도형으로 그림, 음악은 Suno 로 생성한 스템 |
| 들어 있는 것 | 튜토리얼 12 · 원샷 퍼즐 16 · 층마다 생성되는 무한 던전 · 주문 6 · 지역 6 · 데스크톱·모바일 공용 조작 · 한국어 UI | 손으로 짠 기관 24종 위 절차적 변이 · 여왕·공주 계승 · 이웃 사이 유전자 전파 · 10개 스템 동적 음악 · 계통 보관 |
| 검사 | 검사 파일 20개, 검사 기록 36건 | 검사 스크립트 19개, 검사 기록 39건(이전 판 포함) |
| 데모 | https://arcane.caffeinezombie.com/ | https://petri-war.caffeinezombie.com/ · CrazyGames 베이직 런치(2026-09-30, 데이터 수집 테스트) https://www.crazygames.com/game/petri-war |
| 영상 | `arcane_reel.mp4` 28초 | `petri_reel.mp4` 30초 |

**게임 개발의 시작을, 발상에서 발견으로 — Petri War 의 제작 순서** `[진술]` (2026-09-30, 개발자 글을 요약)

Flicker Survivor 에서는 사람이 무엇을 만들지 먼저 정했다(§3). Petri War 에서는 시장 조사, 후보 제안, 초기 프로토타입 구현까지 AI 에 맡기고, 개발자는 그 결과에서 Petri War 를 골라 직접 발전시켰다. 출발점은 "미생물 게임을 만들고 싶다"가 아니라 "뜨는 장르를 몇 달 안에 따라가는 개발이 성립하는가, 유사 장르는 피해야 하나 따라가야 하나"라는 질문이었다.

- **기간** — Steam 트렌드 조사 요청부터 공개할 수 있는 판까지 1주 안에, 병렬 작업이 가능한 제작 환경에서 만들었다.
- **조사 방식** — Steam 인디게임 매출 순위와 트렌드를 매일 조사하게 했다. 최근 출시작의 리뷰와 증가 추이, 동시접속자, 비슷한 게임이 나오는 속도, 출시 전 관심도, 위시리스트 관련 순위와 팔로워를 교차 검토했다(정확한 위시리스트 수와 외부에서 보이는 대리 지표는 구분). 개발자가 이미 만드는 게임에 유리하게 해석하지 않았는지 따로 물어, 시장 관측과 개발자 프로젝트에 대한 추천을 분리했다. 지난 1년의 흐름도 검토하게 했지만 52주를 빠짐없이 조사한 연구는 아니다.
- **기준의 변화** — "무엇이 잘 팔리는가"에 "수요가 느는 동안 공급이 얼마나 빨리 따라오는가", "그 틈이 남아 있는 동안 완성할 수 있는가"가 더해졌다. 구현이 쉬워 보이는 게임(건초 속 바늘 찾기류)을 보고, 빨리 만들 수 있으면 남도 빨리 따라온다는 조건을 붙였다 — 시험 제작은 빠르되 완성품의 재미와 품질에는 손이 가는 영역을 찾는다.
- **당시 거론된 시장 후보**(보고서가 비교한 사례이며 만들기로 한 목록이 아니다) — 직접 작업하는 직업·취미 시뮬(ReStory, Dressmaker, Drag'n Wash) · 기계·시설 운용 시뮬(IRON NEST, PVKK) · 공장 자동화+방어(BELTFED) · 짧은 능동형 인크리멘탈(Berry Bury Berry, Scritchy Scratchy 등, 후발작 공급 속도를 경계) · 데스크톱 방치·동반자(Rusty's Retirement, Ropuka's Idle Island, Tiny Pasture).

**매일 받는 보고서의 모양 — 샘플 1회분(2026-10-01, "Steam Indie Daily")** `[진술]` 개발자가 받는 일일 보고서 한 회분을 요약했다. Petri War 를 고를 때 본 자동 프로토타입도 이런 보고서를 입력으로 만들어졌다(개발자 진술). 아래 수치와 판정은 그날 보고서에 적힌 값이고, 이 파일에서 다시 확인하지 않았다. 시장 데이터는 매일 바뀌므로 현재 시장 판단의 근거로 쓰지 않는다.

- **보고서 구성(12절)** — 글로벌 매출 차트(Valve 주간 Top Sellers·SteamDB 실시간) · 최근 7일 출시작(리뷰·평점·최대 동접·팔로워 증가) · 반복되는 시장 트렌드 · 전날 대비 새로 뜨거나 꺾인 것 · 주목할 게임 · 트렌드 추적표 · 2단계 감시 목록 · 위시리스트 교차검증 · 개발 기간·복제 난이도 · 후보별 근거/반대 근거/다음 확인 신호 · 트렌드 반감기·복제 밀도·후발작 분포 · 소규모·1인 개발자 시사점.
- **수요만 보지 않는다** — 수요(매출·동접·팔로워 증가 속도) 옆에 공급 속도, 복제 밀도, 경쟁작이 따라오는 시간, "프로토타입 기간 대비 상업 품질까지 걸리는 기간"을 같이 적는다. 예: 그날 "Needle" 류는 수요가 더 강해졌는데도 복제가 며칠~2주면 따라와 **진입 부적합**, "Tidy" 류는 후발작 최대 동접이 4,360 → 119 → 43 으로 시간순 급락해 **미확정 유지**, 데스크톱 방치형 ARPG 는 독립 반복 사례(32K·3.1K 최대 동접)가 있지만 평점이 낮고 표면 복제가 쉬워 **조건부 후보**, 기계 운용(Operator) 류는 강한 성공작이 하나뿐이라 **두 번째 독립 신호를 기다리는 감시 대상**.
- **판정 상태를 날짜와 함께 이어 간다** — 처음 발견한 날, 현재 상태(P1 seed → P1.5 → P2 후보 → 확정/무효), 확신도, 다음 확인 신호(trigger), 무효 조건(invalidation)을 후보마다 남긴다.
- **위시리스트 대리 지표를 그대로 믿지 않는다** — SteamDB 의 Wishlist Activity 는 실제 위시리스트 수가 아니라고 명시하고, 팔로워 누적보다 최근 7일 증가율을 비교한다(예: 누적 48K 에 주 +49 인 게임보다 누적 4.5K 에 주 +1.9K 인 게임이 현재 관심이 크다). 공식 공지의 "위시리스트 10만"과 팔로워 5.6K 를 대조해 단순 환산이 안 된다는 것도 기록한다.
- **자동 파이프라인에 주는 함의** — 보고서 스스로 "시장 탐지 → 후보 생성 → 자동 프로토타입"에서 후보 점수에 수요보다 `공급 가속 × 복제 난이도 × 경쟁 반응 시간` 을 강한 감점으로 넣으라고 적는다. 그날 우선순위는 직업·취미 손맛 시뮬 ≈ 기계 운용 > 데스크톱 방치형 ARPG > 공장 방어 ≫ 정리 정돈 > 바늘 찾기였다.

확인된 제안과 제작 결과(최초 후보 전체를 복원한 목록은 아니다):

| 후보 | 진행 단계 | 확인된 판단과 후속 진행 |
|---|---|---|
| ARCANE OPERATOR | 구체적인 게임 제안 | 한 방 안에서 거대한 판타지 기계를 운용(레이더·레버·에너지 분배·좌표 발사·과열과 수리). 소재 변주 여섯(군용 포탑·우주선 함포·마법 공성병기·원자로·잠수함 제어실·몬스터 격리시설) 중 마법 공성병기와 몬스터 격리시설이 추천됐다. 소재 변주이지 여섯 개의 프로토타입이 아니다. 실제 제작 여부와 보류 이유는 확인하지 못했다 |
| 언데드 게임 | 프로토타입 제작 | 만들어 보니 카피캣에 가까운 결과물이라고 판단했다 |
| Petri War | 프로토타입 제작 후 후속 개발 | 계속 발전시킬 게임으로 선택. 생태계·유전·연구 구조로 확장 |

언데드 게임은 프로토타입을 만드는 이유를 보여 준다. 기획이 그럴듯하고 구현이 가능해도, 결과물이 나와야 기존 게임과 얼마나 다르게 느껴지는지 판단할 수 있다. 시장 조사의 제작 부담·경쟁작 공급은 후보를 평가하는 기준이었고, 개별 게임의 결론은 구현 결과를 보고 따로 내렸다.

**Petri War 의 첫 기획과 그 뒤.** 첫 기획은 페트리 접시에서 미생물을 배양하고 돌연변이를 골라 다른 군집과 싸우게 하는 생물학 오토배틀 로그라이트였다("내가 직접 싸우는 게 아니라 생물을 만들어 싸우게 한다"). 범위는 작았다 — 원형 접시에서 먹이·이동·증식, 속도·크기·껍질·독·분열·촉수 형질이 행동과 전투에 영향, 라운드마다 돌연변이 셋 중 하나, 약 다섯 라운드로 한 판, 연구 트리·장기 성장·스토리는 넣지 않음. 아트는 원·캡슐·촉수·막 도형과 어두운 실험실 배경으로, 형질이 모습에 드러나게 했다(껍질은 두꺼운 외곽, 속도는 꼬리, 독은 발광). 시험하려던 질문은 "숫자 설명 없이도 내가 고른 진화가 모습과 싸움에 만든 차이를 알아볼 수 있는가"였다. 여기까지(시장 분석·후보 생성·초기 제작)는 AI 가 진행했다.

개발자가 고른 뒤의 변화는 개발 기록에 있다. 제한된 라운드 구조가 생존을 이어가는 방식으로 바뀌었고, 형질을 표본으로 보관해 다음 실험에 가져가는 선택이 붙었다. 배양과 전투가 나뉘고 다시 배치되던 구조를 하나의 연속된 생태계로 바꿔, 같은 접시에서 개체가 태어나고 먹고 싸우고 늙고 자손을 남기게 했다. 이후 혈통·유전·연구·접시 진행 구조를 확장했고, 첫 기획에서 뺐던 장기 성장도 다뤘다. 완성형 시스템을 먼저 설계하지 않고, 만들어진 핵심을 보고 다음 방향을 정했다.

**사후 설명과 구분.** 프로토타입이 나온 뒤 "왜 이 게임을 골랐어?"라고 묻자 AI 는 Buggos, Pathogenic, Microcosmum 2 를 비교 사례로 들며 군집 성장·진화 선택·세포 소재·자동 전투로 설명했다. 이는 선택 뒤에 요청해 얻은 해석이다. 그럴듯한 설명이 나왔다는 것과 선택 순간에 그 근거를 썼다는 것은 다르다 `[미검증]`.

바뀐 것은 개발을 시작할 때 개발자가 마주하는 대상이다. 완성된 아이디어를 먼저 떠올려야 하는 부담이 줄고, 제안된 후보와 실제 구현물을 보고 무엇에 시간을 쓸지 판단하는 일이 커졌다 — 첫 질문이 "무엇을 만들까?"에서 "이 중 무엇을 더 키워볼까?"로 옮겨 갔다. Petri War 의 판매 가능성은 플레이어와 시장에서 확인해야 하고, CrazyGames 베이직 런치(2026-09-30)가 그 첫 데이터 수집이다. 결과는 아직 없다.

확인하지 못한 것과 한계. 두 게임 모두 외부 플레이테스트 결과가 없고(Petri War 는 2026-09-30 CrazyGames 베이직 런치로 데이터 수집 테스트를 시작했다), Arcane Pockets 의 모바일 조작은 데스크톱 브라우저의 모바일 화면 크기에서만 확인했다(각 저장소 README). Petri War 는 새로 받은 저장소에서 검사 19개 중 13개가 통과하고 6개가 실패했다 — 규칙 변경을 반영하지 않은 검사 3, 저장소에 넣지 않은 원본 음원이 필요한 검사 3(2026-09-27 독립 검증자 실측). 두 저장소는 비공개(GitHub `bhagent/arcane-pockets`, `bhagent/petri-war`)이며 작업 대부분이 Git 밖에서 진행돼 커밋은 각각 1~2건이다.
---

## 11. 모델별 실행 프로필 — 구조와 현재 상태

### 11.1 구조 `[확인]` (2026-09-06 도입)

같은 지침에 강한 모델은 과탐색, 약한 모델은 조기 중단·누락으로 기운다고 판단해 도입했다(도입 사유. 건수 집계는 없다) `[기록]`. 공통 핵심(진입점·훅·설정)은 그대로 두고, 일하는 방식만 프로필 2종으로 분리해 실행 직전에 붙인다.

| 프로필 | 의도 | 초기 배정(전부 미검증) |
|---|---|---|
| `goal-first` | 목표·제약·종료 조건만 주고 과도한 탐색·재검증·범위 확장을 막음 | claude-fable-5-1, claude-opus-5 |
| `step-by-step` | 체크리스트를 먼저 쓰게 하고 파일 읽기 상한·검증 명령·보고 예시를 줌 | claude-sonnet-5, claude-haiku-4-5, gpt-6-astra:low, 미등록 모델 |

- 키는 실행기가 확인한 `<provider>:<family>:<effort>`. 모델에게 자기 등급을 판단하게 하지 않는다.
- `outcome` 기본값은 `unverified`. 모델의 완료 선언은 성공이 아니다.
- 보정기(`calibrate → evaluate → adopt`)는 명시적 `instruction` 실패가 3건 이상일 때만 움직이고, 같은 모델·설정으로 기준과 후보를 비교하며, holdout 사례는 보정안 생성에 제공하지 않는다.
- 보정기의 수정 대상은 프로필뿐. `CLAUDE.md`, `AGENTS.md`, 훅, 설정, 평가 사례는 보호 대상(스냅샷 해시 대조). 후보 본문에 승인 생략·권한 확대·훅 비활성 문구가 있으면 채택 거부.

### 11.2 현재 상태 `[확인]` (2026-09-13)

- 본체 세션 주입: 동작(세션 시작 훅이 핀을 출력). Codex: 2026-09-06 실제 호출 1회에서 핀 헤더 전달과 기록을 확인.
- **서브에이전트 주입: 도입 이후 한 번도 성립하지 않았다.** 트랜스크립트 157개 중 프로필 핀 0개. 원인은 stdin 을 UTF-8 로 재구성하지 않아 한국어 프롬프트 파싱이 실패하고 `{}` → 종료 0 으로 조용히 끝난 것. 이 근거 파일을 준비하며 발견. 수정 커밋 `66cd2582`(#98 닫힘): 같은 한국어 페이로드를 주입 훅(`profile-inject.sh`)에 넣었을 때의 표준 출력이 0바이트 → 2,605바이트(대조군 재현), 회귀 테스트 19건 통과.
- 실행 기록 109건 중 100건이 빈 레코드였다(#99, `[열림]`). 빈 레코드는 격리했고 새 유입은 막혔다. 원인 미확정.
- **보정 루프는 실행 이력 0회** `[미검증]`. `verified` 0건, 후보 0건. 모델별 최적화 효과는 입증되지 않았다.

---

## 12. 숫자와 집계 범위

**세 지표(슬라이드 옛 9장에서 옮김, 2026-09-20).** 플레이 가능까지 FS 5일(첫 커밋 07-04 → 이동·플리커·스폰·접촉 피해가 도는 07-09). 외부 테스트까지: 기록으로 확인된 외부 플레이테스트 없음, 첫 측정은 2026년 4분기. 틀렸다고 확인하기까지: 기능·제작 규칙 수준에서 의도가 틀렸다고 확인하거나 재발하기까지 걸린 기록 6건은 §9.1(1~35일), 시도 횟수로 잰 1건은 별도. 이 지표들은 시제품 도달 기록이며 완제품 제작 기간과 비교 단위가 다르다.

| 항목 | 값 | 어떻게 셌나 | 확인 |
|---|---|---|---|
| 개발 기간 | 2026-07-04 ~ 2026-09-15 (74일, 커밋 있는 날 67일) | git 로그 (2026-09-15 재집계) | 확인 |
| 첫 플레이 가능 빌드 | 2026-07-09 (첫 커밋 +5일) | 아레나·플레이어·타겟팅·스폰·플리커 입력·접촉 피해가 같은 날 순서대로 들어감(`09eaaac9` … `f79676be`). 07-10 MVP 15/15 (`08179dee`). 외부 테스트 없이 개발자 본인 기준 | 확인 |
| 커밋 | 1,275 (@`e4a7014`, 2026-09-15 18:21) | `git rev-list --count`. 자동 커밋 포함. 2026-09-14 에 포트폴리오 문서 커밋을 별도 저장소로 분리하며 이력을 다시 썼고(그 시점 1,211 @`8ace458d`), 09-15 에 재집계 | 확인 |
| 이슈 | 열림 29 · 닫힘 72 (@2026-09-15, 최대 #101) | `gh issue list` | 확인 |
| C# 파일 | 168 = `Assets/Scripts` 127 + `Assets/Editor` 41 (@2026-09-15) | find. **`Assets/TopDownEngine/`(구매 프레임워크)은 제외** | 확인 |
| 테스트 C# | 5 (`Assets/Tests`, @2026-09-15) | find | 확인 |
| 문서 `design/` | 89 (gdd 39 · assets 26 · art 19 · tech 4 · ux 1, @2026-09-15) | find | 확인 |
| 문서 `docs/` | 116 (handoffs 86 · harness 13 · architecture 7 · reviews 4 · 기타, @2026-09-15. portfolio 는 09-14 에 별도 저장소로 분리돼 0) | find | 확인 |
| Python 도구 | 94 (`tools/**/*.py`, @2026-09-15) | find | 확인 |
| AI 모델·도구 실비용 | 약 800달러 (12주, 2026-07-04 ~ 09-20) | 개발자 본인 제공 값(2026-09-21 갱신. 09-16 첫 집계는 11주·07-04~09-15 기준). 모델 API·생성 도구 크레딧 합계. Unity 라이선스와 본인 인건비 환산은 제외(본인 확인 2026-09-16). 영수증과 대조하지 않았다 | 기록 |
| 에이전트 정의 | 49 (opus 19 · sonnet 28 · haiku 2, @2026-09-15 동일) | `.claude/agents/*.md` | 확인 |
| 훅 | 파일 17 · 배치 16 | `.claude/hooks/`, `settings.json` | 확인 |
| 조건부 규칙 | 12 | `.claude/rules/*.md` | 확인 |
| 스킬 | 프로젝트 80 · 전역 28 | 디렉터리 수 | 확인 |
| Unity MCP 도구 | 142 (2026-08-29 기록값) | 핸드셰이크 | 기록 |
| 커밋 귀속 상위 | Opus 5 (1M) 476 · Sonnet 5 290 · Fable 5 220 · art-director 143 · Fable 5.1 49 · gameplay-programmer 45 · systems-designer 37 | 커밋 메시지의 `Co-Authored-By` 줄을 단순 집계(@2026-09-13). "(1M)"은 100만 토큰 컨텍스트 변형을 뜻하는 모델명 표기 | 확인 |

수치는 규모를 보여줄 뿐이며 속도나 품질을 뜻하지 않는다. AI 는 파일 수를 쉽게 늘릴 수 있다.

### 12.1 커밋 구성 — 하네스가 게임보다 큰가 `[확인]` (2026-09-16 집계)

"C# 파일보다 문서·도구·역할이 많다"는 외부 지적에 대해, 파일 수 대신 커밋이 무엇을 만졌는지로 다시 셌다. 2026-07-04 이후 커밋 1,282건(자동 커밋 28건 포함)을 각 커밋이 건드린 경로로 분류했다. 경로 기준 근사치이며 커밋 수는 작업 시간을 정확히 대신하지 않는다.

| 한 커밋이 만진 것 | 경로 | 커밋 수 | 비율 |
|---|---|---|---|
| 게임 코드만 | `Assets/Scripts` · `Assets/Editor` · `Assets/Tests` | 143 | 11% |
| 에셋만 | `Assets/Art` · `Prefabs` · `Scenes` · `Resources` · `Settings` | 146 | 11% |
| 하네스만 | `tools/` · `.claude/` · `docs/harness/` · `AGENTS.md` | 87 | 7% |
| 설계 문서만 | `design/` · `docs/handoffs/` · `docs/codex/` | 289 | 23% |
| 기록만 | `production/` · `docs/reviews` · `docs/architecture` · `docs/engine-reference` | 93 | 7% |
| 여러 종류를 함께 | 위 둘 이상 | 456 | 36% |
| 그 밖(설정·루트 파일 등) | | 68 | 5% |

파일 단위(한 커밋이 만진 파일을 모두 셈): 게임 코드 909 · 에셋 3,786 · 하네스 726 · 설계 문서 1,265 · 기록 724.

주차별로 보면 하네스·문서를 합친 비율은 1주차 70%(구축)에서 2주차 이후 40~50%대로 내려와 늘지 않았다. 하네스만 떼면 7% 다. 설계 문서는 구현이 늘면 따라 느는 것이고, 검증 도구는 구현과 같은 커밋에서 만들어지는 경우가 많아 "여러 종류를 함께"에 들어간다(개발자 원칙 2026-09-16: 구현하면서 검증 도구를 같이 만든다).

이 비율은 **하네스의 자기 개선 루프가 만든 것이 아니다.** 하네스가 스스로 하네스를 고치는 장치는 §11 의 프로필 보정 루프 하나인데, 이슈 #99(열림, 2026-09-13 실측) 대로 실행 기록 109건 중 100건이 빈 레코드라 보정이 한 번도 돌지 않았고, `candidates/` 와 보정 로그는 2026-09-16 에도 비어 있다. 하네스를 자동으로 건드린 커밋은 레지스트리 관측값을 맞추는 `reconcile` 몇 건과 세션 종료 자동 커밋뿐이다. 나머지는 사람이 지시한 세션이 사고 뒤에 규칙·도구를 고친 결과다(§9).
집계 스크립트: `git log --since=2026-07-04 --name-only` 를 경로 접두사로 분류. 자동 커밋(`Auto-commit:` 메시지) 28건은 제외하지 않았다.

---

## 13. 이 파일이 만들어진 과정과 확인 범위

이 파일은 프로젝트의 AI 가 저장소 기록(커밋 메시지·이슈·규칙 파일·변경 이력)을 읽어 작성했고, 사람이 범위와 채택을 결정했다. 작성자와 다른 세션이 **대상을 열기 전에** 같은 항목을 독립 측정한 뒤 대조하는 교차 검증을 두 차례 거쳤다. 그 과정에서 중요 오류 2건이 잡혀 정정됐다: 초기 문서의 "훅 18종"(이력 어느 시점에도 없던 값)과 §2 초안의 "첫 닷새 45건, 게임 코드 0"(실제는 첫 C# 커밋 이전 89건 중 씬 조립 6건 외 설계·리뷰).

**확인함**: 위 표의 `[확인]` 항목 — 인용한 규칙 원문, 커밋 본문과 이슈의 제목·상태, 훅 배치와 파일 수, 프로필 주입 결함의 대조군 재현.

**확인하지 못함**:
- 이슈 본문·댓글(번호·제목·상태만 대조)
- 근거 기록의 수치 원천(751건 귀속 집계, 232/286회, 296/905ms, 877건 등은 문서에 적힌 대로임만 확인)
- git 밖 산출물(캡처, 애니메이션 QC JSON)
- 런타임(Unity 를 다시 실행해 재측정하지 않음)
- 훅 스크립트 각각이 설명대로 동작하는지(파일명·배치·source 관계만 확인)
- 모델별 프로필의 효과(§11.2)
- 원격 CI/CD(없음. 로컬 훅 중심)
- 출시, 매출, 플레이어 평가, 개발 시간 절감률, 총비용

---

## 14. 열린 문제 (2026-09-13)

- #3 보스전 밸런스
- #46 모바일 품질 설정이 어느 품질 레벨에도 배정돼 있지 않음(Android 타깃)
- #54 분리 스티어링 이웃 버퍼 포화
- #62 이동면 삼각형·프랍 수가 문서마다 다름
- #75 [tracking] MVP 후 아트 제한 복원
- #79 계측이 구 아레나 반경을 그대로 씀
- #94 카메라 줌인으로 G4 뷰 높이 유도가 낡음 (09-14 닫힘, 기준일 뒤)
- #97 Flicker 계열 이펙트 2개가 스케치로 교체되지 않음 (09-13 닫힘, 기준일 뒤)
- #99 프로필 실행 기록의 빈 레코드 원인 미확정
- 보정 루프 1회 실행 (미착수)
- 외부 플레이테스트 실시 기록 없음 — 버티컬 슬라이스 리포트(2026-08-02 갱신)가 "NOT a human playtest" 로 명시. §2.7 의 실패 판정 기준은 요구일 뿐 실시된 적이 없다

---

## 15. 용어와 수치 설명

**게임·엔진**
- **플리커 액션**: 이동과 공격이 한 동작으로 이어지는 조작. 짧게 순간이동(플리커)하며 지나간 궤적으로 공격한다. 다수 적이 한 화면에 겹치므로 판독성이 핵심 제약이다.
- **URP**: Unity 의 Universal Render Pipeline. **Play Mode**: Unity 에디터에서 게임을 실제로 실행하는 상태. 이 파일의 "런타임 실측"은 이 상태에서 값을 읽은 것을 뜻한다.
- **TDE / TopDown Engine**: 구매한 탑다운 게임 프레임워크. 우리 코드가 아니므로 수정하지 않고 집계에서 뺀다.
- **GDD**: 게임 디자인 문서. **MVP**: 최소 기능 제품 단계. §7.3 의 유예는 이 단계에 한정된다.
- **아트 바이블**: 시각 규칙의 정본 문서. §5.6, §2.2.6, §0 은 그 문서의 절 번호다. 이 파일에는 판정에 필요한 값만 옮겼다.
- **u**: Unity 월드 단위(미터에 해당). **`D_visual ≥ 0.40u`**: 오브젝트의 응집 실루엣 최대 치수가 0.4 유닛 이상이어야 한다는 뜻. 당시 카메라가 플레이어 평면에서 세로 7.2u 를 보였으므로 1080px 세로에서 0.4u 는 약 60px 다. 카메라가 바뀐 뒤(#94) 이 환산은 낡았다.
- **32칸 비교(G-D1)**: 화면을 32개 구역으로 축소한 뒤 대상 렌더러를 켠 화면과 끈 화면의 차이를 구역별로 본다. **G-D2**: 대상 픽셀과 이웃 픽셀의 밝기 차.
- **OQ-9**: 아트 바이블의 Open Question 9번. "축당"은 G-D1, G-D2 각각을 뜻한다.
- **소크 하니스**: 자동 플레이로 오래 돌리며 지표를 모으는 테스트 도구. 이동·공격·레벨업 카드 선택을 스크립트가 대신한다. **자동 카드 선택**: 레벨업 때 뜨는 스킬 카드 3장 중 하나를 고르는 것.
- **색 슬롯**: 아트 바이블이 정한 제한된 색 팔레트 칸. Tripo 가 만든 텍스처를 이 칸에 맞추는 과정이 "컨폼"이다. **컨폼**: 생성물을 스펙(폴리곤·텍스처·재질 규칙)에 맞게 후처리하는 것. **Tripo3D**: 텍스트·이미지에서 3D 모델을 생성하는 외부 서비스. **프랍**: 배경 소품.
- **판독 원칙 · 플레이어 식별 채널 · 신호 발광 위계**: 각각 "밀집 화면에서 알아볼 수 있어야 한다", "플레이어를 구별하는 시각 요소(색·형태)는 항상 있어야 한다", "빛나는 효과의 우선순위"를 뜻하는 아트 바이블 규칙. MVP 에서도 유예하지 않았다.
- **오브젝트 풀 · 비활성 부모**: 적을 매번 생성하지 않고 비활성 상태로 모아 두었다가 재사용한다. 비활성 부모 아래의 오브젝트는 기본 조회에서 빠지므로 `includeInactive: true` 로 포함시켜야 한다.
- **hooded_mage**: 후드를 쓴 마법사 캐릭터. 애니메이션 파이프라인 시험 대상. **FK 차이**: 뼈대(본)를 부모→자식 순으로 계산한 최종 위치의 차이. "0m"과 "5.88×10⁻⁷ m"은 같은 스크립트의 두 실행(또는 MCP 상태 대 레인 A 결과)을 본별로 비교한 최대 오차. **QC 분류**: 애니메이션 품질 검사가 프레임을 접지/공중 등으로 나눈 것.
- **#54 분리 스티어링 이웃 버퍼 포화**: 적끼리 겹치지 않게 미는 계산에서 이웃 목록이 꽉 차 회피 방향이 치우칠 수 있다는 결함. **#62**: 바닥 메시의 삼각형 수와 소품 수가 문서마다 달라 근거 없는 상한이 있다는 결함. **#97**: 페인트 룩으로 바꿔야 할 이펙트 2개가 원래 재질로 남는 결함.

**AI 실행 환경**
- **Claude Code / Codex**: 각각 Anthropic, OpenAI 의 터미널 기반 코딩 에이전트. **MCP**: Model Context Protocol. AI 가 외부 프로그램(Unity 에디터, Blender)의 기능을 도구로 호출하는 표준. **stdio 핸드셰이크**: MCP 서버와 표준 입출력으로 연결해 도구 목록을 받는 초기 교환.
- **모델 등급**: opus > sonnet > haiku 는 Anthropic 모델의 크기·비용 순서(여기서는 별칭). `claude-fable-5-1`, `claude-opus-5`, `claude-sonnet-5`, `claude-haiku-4-5` 는 실제 모델 ID, `gpt-6-astra:low` 는 Codex 가 쓰는 OpenAI 모델과 추론 강도. **(1M)**: 100만 토큰 컨텍스트 변형.
- **페인**: herdr 라는 다중 터미널 관리 도구에서 띄운 독립 CLI 세션. 턴 한도 없음. **서브에이전트**: 세션 안에서 호출되는 범위 한정 작업자. `maxTurns` 는 정의 파일에 적힌 도구 호출 횟수 상한(도입 초기 10·20·25·30, 2026-09-02 부터 일괄 50). `--agent art-director`: 특정 역할 정의로 세션을 띄우는 옵션. `disallowedTools`: 정의에서 금지한 도구 목록.
- **훅**: 세션 시작·도구 호출 전후·종료 같은 사건에 실행되는 스크립트. **PreCompact / PostCompact · 컨텍스트 압축**: 긴 대화가 요약으로 압축되기 직전·직후. 그때 상태를 파일로 보존·복원한다.
- **스킬**: 특정 작업 절차를 담은 호출 가능한 지침 묶음(프로젝트 80, 전역 28). 사용하지 않아도 설명문이 상시 로드돼 비용이 든다.
- **귀속 · `Co-Authored-By`**: 커밋 메시지 끝에 어떤 AI·역할이 작업했는지 적는 줄. 실제로 위임한 주체만 적는다. §3.2 의 751건 조사는 이 줄과 위임 기록을 합산한 것이고, §12 은 이 줄만 센 것이다.
- **한 덩어리 커밋(럼프)**: 서로 다른 작업의 파일이 한 커밋에 섞인 것.
- **프로필 핀**: 서브에이전트 프롬프트 앞에 붙는 실행 프로필 식별 헤더(`[[profile-pin run=… id=… key=…]]`). **보정기**: 실행 기록의 실패 분류를 입력으로 받아 프로필 문구의 수정 후보를 만들고, 기준·후보를 같은 모델로 여러 번 돌려 통과율·비용을 비교한 뒤 채택 여부를 정하는 스크립트(`calibrate → evaluate → adopt`). **holdout**: 후보 생성에는 보여 주지 않고 평가에만 쓰는 사례.
- **회수 사례**: 턴 한도로 잘린 위임을 "확인한 것을 먼저 결론으로 적어라"로 다시 지시해 완결 보고를 받은 사례(1건).

**기타**
- **발주서**: `docs/handoffs/` 의 작업 지시서. **DVC**: 대용량 원본을 git 밖(Google Drive)에서 관리하는 도구. git 에는 포인터만. **LFS**: git 의 대용량 파일 확장. 이 프로젝트는 LFS 대신 DVC 를 쓰며, LFS 패턴에 잘못 걸린 파일은 회수가 어렵다.
- **레인 A / B**: Blender 배경 스크립트 실행 / MCP 라이브 세션.
- **게이트**: 미리 정한 측정 조건. 통과해야 `Done`.

---

## 16. 자주 나오는 질문 — 이 시스템 안에 답이 있는 것과 없는 것

이 파일은 제작 시스템(역할·규칙·검증·인수인계)의 기록이다. 슬라이드 문서를 읽은 뒤 자주 나오는 질문 중, 시스템 안에 답이 있으면 어디에 있는지 적고, 없으면 **구현 시스템의 영역이 아니므로 이 파일은 답하지 않는다**고 적는다. 사업·투자·조직에 대한 결정은 슬라이드 문서와 사람이 답한다. 아래 표의 `[확인]` 은 2026-09-14 에 저장소 파일을 직접 열어 확인한 것이다.

| 질문 | 이 시스템 안의 답 | 없는 것 |
|---|---|---|
| 하네스가 게임보다 크지 않은가 (문서·도구·역할이 C# 보다 많다) | §12.1 커밋 구성. 하네스만 만진 커밋 7%, 게임 코드만 11%, 설계 문서만 23%, 여럿 함께 36%. 주차별 비율은 늘지 않았다 `[확인]` | 파일 수 기준의 인상(§12)과 커밋 수 기준의 비율은 다른 것을 잰다. 작업 시간의 직접 측정은 없다 |
| 이 제작 방식이 다른 타이틀에서도 재현되는가 | §10.6 경량 버전으로 만든 두 게임, 데모 공개 `[확인]` | 플레이 가능한 데모까지는 재현됐다(§10.6). 출시할 수 있는 게임까지의 재현은 아직 없다 |
| AI 가 쓴 코드의 품질을 누가 어떤 기준으로 승인하나 | 에셋은 §7 의 게이트(`Done` 은 게이트 통과 뒤에만). 코드는 §3.1 역할표에서 Claude Code 담당이며 코드 스타일은 lead-programmer 에 위임, 커밋 훅(`validate-commit.sh`), 인용 검사기(§9), Unity 실행 실측(§6), 테스트 C# 5 `[확인]` | 코드에 대한 문서화된 승인 기준과 리뷰 통과 조건은 없다. 조건부 규칙 12종 중 코드 규칙 7종(`ai-code`·`engine-code`·`gameplay-code`·`network-code`·`ui-code`·`test-standards`·`prototype-code`)은 템플릿에서 온 것으로 `src/**`·`tests/**`·`prototypes/**` 경로에 묶여 있고, 이 저장소에는 `src/`·`tests/` 가 없어 그 여섯은 한 번도 로드되지 않았다 `[확인]`. 실제로 로드되는 규칙은 `design-docs`·`blender` 다. `assets/**` 에 묶인 둘(`data-files`·`shader-code`)은 Unity 의 `Assets/` 와 대소문자가 달라 로드 여부 미확인 |
| 대표가 빠지면 다른 사람이 이어받을 수 있나 | 규칙은 프롬프트가 아니라 파일에 있고(§5), 발주서 68건(§4.4), 세션 인수인계 파일(§10.4), 생성물 색인 `docs/README.md → INDEX.yaml`(§2.5), 새 클론 절차(`dvc pull`, `tools/install-git-hooks.sh`, 본진 하네스의 `scripts/check-links`, 장비별 값은 `machines/<장비>.yaml`) `[확인]` | 다른 사람이 실제로 이어받은 사례는 없다. 볼트는 저장소 밖 로컬 경로다(§2.5) |
| AI 사용 비용의 구조와 규모 | 실행 기록이 토큰·시간·종료 사유를 남기고, 비용은 실행기가 주는 경우만 채운다(§11). 보정 정책에 평가 비용 상한(`max_eval_cost_usd` 5.0)과 비용 개선 문턱(`min_cost_delta` 0.15)이 있다. 모델 계층은 의사결정 opus, 코드 sonnet(§3.2). 상시 로딩 비용 감사(2026-08-29)에서 역할·스킬 설명문 53,328자 중 86% 가 사용 실적 0 으로 나와 감축했다. 엔진 매뉴얼 3,516 파일을 로컬화했다(§2.5) `[확인]`. 참조 빈도는 미확인(§2.6) | 총지출 액수, 월 비용, 산출물당 비용은 없다(§13 에도 미확인으로 적었다) |
| AI 로 몇 배 빨라졌나 | — | 답하지 않는다. AI 없이 만든 대조군이 없다(§0·§12·§13) |
| 서버·결제처럼 안정성이 필요한 영역에 AI 코드를 쓰지 않는다는 원칙 | 없다. 위의 `network-code` 규칙 파일은 템플릿에서 온 것이며 로드되지 않는다. 첫 타이틀에는 서버·결제가 없다 `[확인]` | 그 영역의 정책은 타이틀 단위의 사업 결정이라 구현 시스템의 영역이 아니므로 이 파일은 답하지 않는다 |
| 게이트를 넘지 못하면 프로젝트를 접는 기준 | 시스템 안의 판정은 에셋 단위 `Done` 게이트(§7)와 설계의 사전 실패 판정(§2.7, 재검토 기준)까지다 | 프로젝트의 중단·전환 기준은 구현 시스템의 영역이 아니므로 이 파일은 답하지 않는다 |
| 이 하네스가 기술적 해자인가 | 시스템 안에서 답할 수 있는 것은 구성 방식뿐이다. 역할 정의·규칙·훅·검사기는 전부 저장소의 파일이고(§5), 경량 판이 다른 두 저장소에 옮겨 쓰였다(§10.6). 즉 원리적으로 복제할 수 있는 구성이다 `[확인]` | 그것을 해자로 볼지는 사업 판단이라 이 파일은 답하지 않는다 |
| "다른 게임 회사도 Claude 나 Codex 를 쓰면 따라오지 않나요?" | 맞다. 같은 구조는 만들 수 있다(§5·§16 위 행). 그 회사와의 경쟁은 누가 더 좋은 게임을 고르는가, 누가 더 빨리 틀렸음을 알아차리는가, 누가 새 모델의 능력을 더 빨리 제작 과정으로 흡수하는가로 간다 | 그 경쟁의 결과는 이 시스템 안에 없다. 출시작·관객이 쌓인 뒤의 일이다 |
| 시장, 가격, 타깃 유저, 자금의 사용 | — | 구현 시스템의 영역이 아니다. 시장·가격·대상은 슬라이드 문서가, 자금의 사용은 투자용 사업 가설 파일이 다룬다 |