feat(BT·Phase2B): 전 14개 에이전트 동원 수상한잡화점 시행착오 노하우 아카이브
PD님 2026-04-21 지시 1번 "전 에이전트 동원" A안 집행 완료. ## 산출물 14종 (공유/조직자산/시행착오_아카이브/) - 총괄_pm_general / 개발_팀장·서버팀장·클라이언트팀장 / 기획_팀장·system·content·level·narrative·balance·ux_designer / 감사_pm·dev·plan_auditor ## 실증 발견 - narrative-designer: 수상한잡화점 내러티브 산출물 0건 확인 - ux-designer: UX 전용 기획 문서 0건 확인 → 개발팀 UI 아키텍처 기반 추출 - content-designer: C34-11 Agent 경계 위반 재발 (절대 경로 Write → BT main 레포 유출 → Move-Item 복구) ## PM 일괄 보고 안건 (PD님 결정 대기) A. 분량 초과 4건 (기획팀장 4배·balance 3배·개발팀장 1.6배·클라이언트 10%) B. 산출물 부재 2건 — EerieVillage 조선·퇴마 내러티브·UX 선행 설계 필요 C. C34-11 재발 사례 — feedback 회차 증가 기록 (Phase 2-C) D. 감사관 3종 BT 운영 체크리스트 적용 E. EerieVillage 착수 안건 (서버·Framework Tier 2·3·Unity MCP v2·세계관 SOT·2D 플랫포머 UX·Prove-2-of-3 이식성·어뷰징 경계값 재평가) F. Phase 2-C 수상한잡화점 삭제 범위 질의 (개발 원본·memory feedback·조직공지 처리 수준) ## 매니페스트 bt-phase2b · bt-phase2b-v2 (활성 · post-commit hook이 archived 이동) ## 보류 Phase 2-C 수상한잡화점 삭제 + feedback 추상화 + PD 지시 로그 초기화 — PD님 일괄 보고 안건 결정 후 착수 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
parent
5d5b1dde02
commit
44f7fb1380
|
|
@ -32,7 +32,7 @@ C3·C13 위반에 해당. **즉시 자진 보고 후 소급 등록**.
|
|||
| # | 일시 | 지시 요지 | 처리 상태 | 산출물 경로 | 중단 사유 | 사후 조치 |
|
||||
|---|------|----------|----------|-----------|----------|----------|
|
||||
| BT1 | 2026-04-20 | BurningTimes 조직 신설 — git remote 교체 + 중앙 저장소 A안 분리 + NerdNavisAi 영향 차단 | 진행중 | Phase 1 commit `4911b74` (push 완료) · `공유/대화로그/조직운영/2026-04-21.md` | — | Phase 2-A·2-B·2-C 순차 진행 |
|
||||
| BT2 | 2026-04-21 | BT 조직 전환 8개 지시: ①기존 프로젝트 제거 + 시행착오 노하우 조직 자산화 (전 에이전트 동원) ②너드나비스→BurningTimes ③수상한잡화점 삭제 + 교훈 보존 ④BT.Framework 이름 갱신 ⑤영문화 ⑥Unity 경로 `E:/NerdNavis/EerieVillage` (하드코딩 금지) ⑦Discord 웹훅 등록 ⑧새 프로젝트 "기묘한 고을: 조선퇴마뎐" (EerieVillage, Unity 6000.3.13f1 LTS, 2D PlatformerMicrogame) | 진행중 | Phase 2-A commit 대기 · `프로젝트/EerieVillage/` · `paths.local.json` · `공유/대화로그/조직운영/2026-04-21.md` | — | Phase 2-B 전 에이전트 동원 노하우 재정리 착수 → Phase 2-C 수상한잡화점 삭제 + feedback 추상화 + 최종 commit |
|
||||
| BT2 | 2026-04-21 | BT 조직 전환 8개 지시: ①기존 프로젝트 제거 + 시행착오 노하우 조직 자산화 (전 에이전트 동원) ②너드나비스→BurningTimes ③수상한잡화점 삭제 + 교훈 보존 ④BT.Framework 이름 갱신 ⑤영문화 ⑥Unity 경로 `E:/NerdNavis/EerieVillage` (하드코딩 금지) ⑦Discord 웹훅 등록 ⑧새 프로젝트 "기묘한 고을: 조선퇴마뎐" (EerieVillage, Unity 6000.3.13f1 LTS, 2D PlatformerMicrogame) | 진행중 | Phase 2-A commit `5d5b1dd` push · Phase 2-B 아카이브 14종 `공유/조직자산/시행착오_아카이브/` · `프로젝트/EerieVillage/` · `paths.local.json` | — | Phase 2-C 착수 대기. PM 일괄 보고 안건 6종 (분량 초과·산출물 부재 2건·C34-11 재발·감사관 체크리스트·EerieVillage 안건·Phase 2-C 범위 질의) PD님 결정 대기 |
|
||||
| 2 | 2026-04-14 | (구 NerdNavis) 서버 Critical 보안 3건 보류 | 보류 | `프로젝트/수상한잡화점/개발/05_서버연동_현황_v1.md` | Phase 2-C에서 BT 신생 조직 분리로 일괄 아카이브 예정 | PD님 지시 3번에 따라 Phase 2-C에서 교훈 추출 후 삭제 |
|
||||
|
||||
> **2026-04-15 오후 추가 갱신 (C4·C13 위반 자진 정정 2차)**:
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@ C3·C13 위반에 해당. **즉시 자진 보고 후 소급 등록**.
|
|||
| # | 일시 | 지시 요지 | 처리 상태 | 산출물 경로 | 중단 사유 | 사후 조치 |
|
||||
|---|------|----------|----------|-----------|----------|----------|
|
||||
| BT1 | 2026-04-21 | BurningTimes 조직 신설 — 기획팀 영역 전환 | 진행중 | Phase 1 commit `4911b74` · `공유/대화로그/조직운영/2026-04-21.md` | — | Phase 2-A·B·C 순차 진행. 본 기획팀 PD 지시 로그의 #41~#45는 수상한잡화점 관련으로 Phase 2-C에서 교훈 추출 후 일괄 아카이브·삭제 예정 |
|
||||
| BT2 | 2026-04-21 | BT 조직 전환 8개 지시 — 기획팀 집행 영역: ①시행착오 노하우 재정리 (기획팀장·content/balance/level/narrative/system/ux-designer 동원) ③수상한잡화점 기획 산출물 삭제 + 교훈 보존 ⑧새 프로젝트 "기묘한 고을: 조선퇴마뎐" 기획 착수 (Unity 6000.3.13f1 LTS · 2D PlatformerMicrogame 템플릿 기반) | 진행중 | Phase 2-A commit 대기 · `프로젝트/EerieVillage/기획/` | — | Phase 2-B 착수 시 기획팀 시행착오 아카이브 작성 할당 · Phase 2-C 수상한잡화점 기획 삭제 후 EerieVillage 기획 골격 설계 착수 |
|
||||
| BT2 | 2026-04-21 | BT 조직 전환 8개 지시 — 기획팀 집행 영역: ①시행착오 노하우 재정리 (기획팀장·content/balance/level/narrative/system/ux-designer 동원) ③수상한잡화점 기획 산출물 삭제 + 교훈 보존 ⑧새 프로젝트 "기묘한 고을: 조선퇴마뎐" 기획 착수 (Unity 6000.3.13f1 LTS · 2D PlatformerMicrogame 템플릿 기반) | 진행중 | 기획팀 7종 아카이브 완료: 기획_팀장·system/content/level/narrative/balance/ux_designer `공유/조직자산/시행착오_아카이브/` · `프로젝트/EerieVillage/기획/` | — | Phase 2-B 기획팀 영역 완료. Phase 2-C 수상한잡화점 기획 삭제 후 EerieVillage 기획 골격 설계 착수 예정. 분량 초과 2건(기획팀장 4배·balance 3배)·산출물 부재 2건(narrative·UX) PD님 결정 대기 |
|
||||
| 41 | 2026-04-20 | (PD님 직접 지시·PM 세션 경유) **Phase 4 — 스테이지별 노드 구성 작업** — Phase 3(설계 체계 확립) 종결 후 신규 Phase 분리. 영향 프로젝트: **수상한잡화점** | **보류 (데이터 구조 오해 판명 · #42 재정비 선행)** | 착수 가이드: `프로젝트/수상한잡화점/기획/Phase4_노드구성_착수가이드_v1.md` · **지역 1 v1 초안 (Stage 1~6)**: `프로젝트/수상한잡화점/기획/Phase4_지역1_노드구성_v1.md` (데이터 구조 오해로 폐기 대상 · v2 재작성 예정) | **데이터 구조 오해 판명** — 기존 기획팀은 "WorldMap 4개 그룹"(WM1~4)이라는 **오해**로 WM1 = 지역 1 = Stage 1~6 = 6개로 진행. PD 실측 확정: 지역(월드맵 장소) = 21개 · 각 지역이 N개 하위 스테이지 · **지역 1 = Stage1_1·1_2·1_3·1_4 = 4개**. v1 구조 전면 폐기 · 재정비 필요 | **#42 (데이터 구조 재확인)·#43 (기획팀 룰 신설)·#44 (지역 1 v2 재작성) 완료 후 재개**. 재개 트리거: 3종 완료 + PD 검증 |
|
||||
| 42 | 2026-04-20 | (PD님 직접 지시) **게임 내 테이블 데이터 구조 재확인 + 누락 정보 보완** — 기획팀이 Unity Export CSV/JSON 전수 실측 기반으로 구조 재정비. 영향 프로젝트: **수상한잡화점** | **진행중** | `프로젝트/수상한잡화점/기획/테이블_데이터_구조_재정비_v1.md` (신설 예정) | - | Phase 4 #41 재개의 선행 조건. 완료 후 #44 착수 가능 |
|
||||
| 43 | 2026-04-20 | (PD님 직접 지시) **기획팀 룰 신설 — PD 의도 벗어난 작업 재발 방지** — 데이터 구조 실측 의무·용어 정의 엄수·PD 확인 절차·기존 SOT 맹신 금지 등. 영향 프로젝트: **조직 공통** (기획팀 적용) | **진행중** | `프로젝트/수상한잡화점/기획/기획팀_데이터_실측_의무_v1.md` (신설 예정) | - | 본 룰은 PM 검토·PD 승인 후 발효 (C36 실무 수준 룰 · 조직 코어룰 수정 아님) |
|
||||
|
|
|
|||
|
|
@ -117,3 +117,92 @@ C35-9 PreToolUse 차단 + 매니페스트 워크플로우가 **commit 전 자진
|
|||
## [대기 중 결정]
|
||||
- PD님 Phase 2-B 착수 승인 (commit·push 후 재진입 예정)
|
||||
- PD님 Unity 프로젝트 추가 셋업 (BT.Framework 분리 레포 경로 등)
|
||||
|
||||
---
|
||||
|
||||
## [설계·산출물] UX/UI 시행착오 아카이브 작성 완료
|
||||
|
||||
**태그**: #Phase2B #시행착오아카이브 #ux-designer #BurningTimes
|
||||
|
||||
### 배경
|
||||
BurningTimes 조직 출범 Phase 2-B — 전 에이전트 동원 시행착오 노하우 추출 작업 일환. ux-designer 영역 담당 아카이브 작성.
|
||||
|
||||
### 실측 결과 요약
|
||||
1. 수상한잡화점 기획팀 UX 전용 문서 부재 확인 (기획/ 폴더 24개 파일 전수 실측)
|
||||
2. UI 아키텍처는 개발팀이 단독 문서화 (11_UI아키텍처_v1.md — 2026-04-17 개발팀장 작성)
|
||||
3. 핵심 불일치 사례 식별: 방어 감소율 기획 가정 50% vs 코드 실측 30% (PCDefence_Mul=0.3)
|
||||
4. 범용 UI 컴포넌트 7종 식별: SafeArea·Toast·InputBlocker·VirtualScroll·BackKeyDispatcher·UIView·AtlasManager
|
||||
5. UITouchHandler 아키텍처 패턴(IPointerDown·Up·Exit) — EerieVillage 재사용 가능
|
||||
|
||||
### 산출물
|
||||
- `공유/조직자산/시행착오_아카이브/기획_ux_designer_v1.md` — 5섹션 형식 작성 완료
|
||||
|
||||
### 기각안 (C32 기각안 필드)
|
||||
1. **UX 기획 문서에서만 교훈 추출** — 기각. 문서 자체가 없으므로 개발팀 산출물에서 추출하는 것이 실증 기반의 유일한 방법. C23 정직성 원칙에 따라 부재 사실을 명시하고 가용 자료에서 추출
|
||||
2. **플랫포머 조작 스킴 섹션 별도 추가** — 기각. 수상한잡화점은 덱빌딩 카드 게임이라 플랫포머 조작 스킴 자료가 없음. 신규 설계 대상으로 착수 체크리스트에 포함하는 방식 채택
|
||||
|
||||
---
|
||||
|
||||
## [Phase 2-B 완료] 전 에이전트 시행착오 아카이브 14종 (README 포함)
|
||||
|
||||
**태그**: #Phase2B #시행착오아카이브 #BurningTimes #조직자산
|
||||
|
||||
### 14개 에이전트 산출물 전수
|
||||
| 파일 | 담당 | 크기(B) | 비고 |
|
||||
|------|------|---------|------|
|
||||
| `총괄_pm_general_v1.md` | pm-general | 21,476 | 목표 범위 |
|
||||
| `개발_팀장_v1.md` | 개발팀장 | 18,698 | 목표 초과 (11,800자, 1.6배) |
|
||||
| `개발_서버팀장_v1.md` | 서버팀장 | 12,419 | 목표 범위. docx 접근 제약 명시 |
|
||||
| `개발_클라이언트팀장_v1.md` | 클라이언트팀장 | 10,362 | 목표 상한 10% 초과 (6,609자) |
|
||||
| `기획_팀장_v1.md` | 기획팀장 | **31,069** | **목표 4배 초과 — 압축 한계 PM 판단 필요** |
|
||||
| `기획_system_designer_v1.md` | system-designer | 8,169 | 목표 범위 |
|
||||
| `기획_content_designer_v1.md` | content-designer | ~12,000 | **C34-11 경계 위반 복구** (BT main 레포 유출 → worktree 이동) |
|
||||
| `기획_level_designer_v1.md` | level-designer | 17,299 | 목표 범위 |
|
||||
| `기획_narrative_designer_v1.md` | narrative-designer | 10,422 | **수상한잡화점 내러티브 산출물 0건 실증** — EerieVillage 조선·퇴마 원칙 선언 |
|
||||
| `기획_balance_designer_v1.md` | balance-designer | 16,760 | 목표 3배 초과 (한글 기준) |
|
||||
| `기획_ux_designer_v1.md` | ux-designer | 12,057 | **UX 전용 문서 0건 실증** — 개발팀 UI 산출물 기반 추출 |
|
||||
| `감사_pm_auditor_v1.md` | pm-auditor | 13,693 | 목표 범위 |
|
||||
| `감사_dev_auditor_v1.md` | dev-auditor | 12,827 | 목표 범위 |
|
||||
| `감사_plan_auditor_v1.md` | plan-auditor | 16,512 | 목표 범위 |
|
||||
|
||||
### PM 일괄 보고 안건 (자체 판단 금지·PD님 결정 대기)
|
||||
|
||||
#### A. 분량 초과 4건
|
||||
- 기획팀장 4배·balance-designer 3배·개발팀장 1.6배·클라이언트팀장 10%
|
||||
- A-1. 원본 유지 vs A-2. 기획팀장·balance-designer만 재압축 지시 vs A-3. 전체 그대로 둠 (조직 자산이라 풍부한 편이 나을 수 있음)
|
||||
|
||||
#### B. 산출물 부재 실증 2건 (신규 조직 발견)
|
||||
- narrative-designer: 수상한잡화점 내러티브 문서 0건 → EerieVillage 조선·퇴마 세계관 SOT 선행 필요
|
||||
- ux-designer: UX 전용 기획 문서 0건 → EerieVillage 2D 플랫포머 모바일 UX 선행 필요
|
||||
|
||||
#### C. C34-11 Agent 경계 위반 재발
|
||||
- content-designer가 절대 경로 `E:\BurningTimes\공유\...`로 Write → BT main 레포 유출
|
||||
- 복구: Move-Item으로 worktree 이동 + main 레포 빈 디렉토리 정리
|
||||
- 재발 방지: `feedback_agent_path_boundary.md` 회차 증가 기록 필요 (Phase 2-C)
|
||||
|
||||
#### D. 감사관 3종 — BT 운영 체크리스트 적용 필요
|
||||
- pm-auditor: C35 자기 참조·C36·C37 신설 이력 반영
|
||||
- dev-auditor: worktree 5문항 체크·Agent 경계 보호 선행
|
||||
- plan-auditor: 기획 특수 감사 6종·데이터 실측 룰 계승
|
||||
|
||||
#### E. EerieVillage 착수 관련 안건 다수 (전 에이전트 공통)
|
||||
- 서버 아키텍처·보안 체계 선택 (서버팀장)
|
||||
- BT.Framework Tier 2·3 진입 경계 (개발팀장)
|
||||
- Unity MCP 편집 표준 워크플로우 v2 (클라이언트팀장)
|
||||
- 조선·퇴마 세계관 SOT·glossary·톤앤매너 기준선 (narrative-designer)
|
||||
- 2D 플랫포머 모바일 UX 초기 설계 (ux-designer)
|
||||
- Prove-2-of-3·덱빌딩 메카닉의 플랫포머 이식 가능성 (기획팀장·content-designer)
|
||||
- 어뷰징 판정 경계값 재평가 (system-designer·balance-designer)
|
||||
|
||||
#### F. Phase 2-C 수상한잡화점 삭제 범위 질의
|
||||
- 개발팀 원본 (`프로젝트/수상한잡화점/개발/`)도 삭제 포함? 아카이브 교훈에 이미 추출됨
|
||||
- memory/org/feedback의 "수상한잡화점" → "이전 프로젝트" 추상화 수준 (전체 vs 일부)
|
||||
- 조직공지 중 규칙 진화사 (C1~C37·P1~P31 신설·개정)는 조직 자산으로 보존? 아카이브가 참고
|
||||
|
||||
### 감사 필요 항목 (본 세션 외)
|
||||
- `feedback_agent_path_boundary.md` content-designer 위반 사례 append (Phase 2-C)
|
||||
- `feedback_pm_capability_underestimation.md` 관련 — 전 에이전트 동원이 의도대로 작동한 실증 (긍정 사례)
|
||||
|
||||
### 기각안
|
||||
1. **14개 에이전트 Phase 2-B 생략** — 기각. PD님 명시 지시 A안 (전 에이전트 동원)
|
||||
2. **감사관 3종 실제 감사 수행 중 아카이브 작성 겸행** — 기각. 프롬프트에서 "감사 실행 금지 · 아카이브 전용" 명시, 3종 감사관 모두 준수함
|
||||
|
|
|
|||
|
|
@ -0,0 +1,39 @@
|
|||
# 시행착오 아카이브 — BurningTimes 조직 자산
|
||||
|
||||
## 목적
|
||||
BurningTimes 신설 조직이 이전 NerdNavis 조직의 **수상한잡화점** 프로젝트 진행 과정에서 축적한 시행착오·성공·실패 패턴을 계승하여, 동일한 실수를 반복하지 않고 검증된 방법은 재활용하기 위한 **조직 자산 아카이브**.
|
||||
|
||||
## 배경
|
||||
- 조직 전환: NerdNavis (2025-2026) → BurningTimes (2026-04-21 출범)
|
||||
- 신 프로젝트: EerieVillage (기묘한 고을: 조선퇴마뎐), Unity 6000.3.13f1 LTS
|
||||
- PD님 2026-04-21 지시 1번 "기존 프로젝트 진행 과정에 실수를 반복하지 않도록 하기 위한 목적"
|
||||
|
||||
## 구성 (영역별 분리)
|
||||
| 영역 | 파일 | 담당 에이전트 |
|
||||
|------|------|--------------|
|
||||
| 총괄 PM 관점 | `총괄_pm_general_v1.md` | pm-general |
|
||||
| 개발팀 통합 | `개발_팀장_v1.md` | 개발팀장 |
|
||||
| 서버 파트 | `개발_서버팀장_v1.md` | 서버팀장 |
|
||||
| 클라이언트 파트 | `개발_클라이언트팀장_v1.md` | 클라이언트팀장 |
|
||||
| 기획팀 통합 | `기획_팀장_v1.md` | 기획팀장 |
|
||||
| 시스템 기획 | `기획_system_designer_v1.md` | system-designer |
|
||||
| 컨텐츠 기획 | `기획_content_designer_v1.md` | content-designer |
|
||||
| 레벨 기획 | `기획_level_designer_v1.md` | level-designer |
|
||||
| 시나리오·내러티브 | `기획_narrative_designer_v1.md` | narrative-designer |
|
||||
| 밸런스 | `기획_balance_designer_v1.md` | balance-designer |
|
||||
| UX/UI | `기획_ux_designer_v1.md` | ux-designer |
|
||||
| PM 감사 | `감사_pm_auditor_v1.md` | pm-auditor |
|
||||
| 개발팀 감사 | `감사_dev_auditor_v1.md` | dev-auditor |
|
||||
| 기획팀 감사 | `감사_plan_auditor_v1.md` | plan-auditor |
|
||||
|
||||
## 공통 형식 (각 아카이브)
|
||||
1. 개요 (핵심 교훈 5~10건 요지)
|
||||
2. 시도한 방법·이유·결과·교훈 (4필드 표)
|
||||
3. BT 조직 착수 시 체크리스트
|
||||
4. PM 보고 안건 (특이사항)
|
||||
5. 참조 원본 파일 목록 (감사 재현 가능)
|
||||
|
||||
## 활용 방법
|
||||
- BT 조직의 각 팀·역할 착수 시 해당 영역 아카이브 1차 Read
|
||||
- 신규 규칙 제안 시 아카이브 참조하여 선행 실증 확인
|
||||
- 감사관은 본 아카이브를 "선행 시행착오 체크"의 표준 인풋으로 활용
|
||||
|
|
@ -0,0 +1,164 @@
|
|||
---
|
||||
type: 조직자산_시행착오_아카이브
|
||||
subject: dev-auditor 개발팀 감사 이력·교훈 — 수상한잡화점 프로젝트
|
||||
origin_project: 수상한잡화점 (NerdNavis)
|
||||
target_project: EerieVillage (BurningTimes)
|
||||
period: 2026-04-17 ~ 2026-04-20
|
||||
version: v1
|
||||
created: 2026-04-21
|
||||
author: dev-auditor (아카이브 작성 역할)
|
||||
purpose: 조직 전환(NerdNavis → BurningTimes) 및 신 프로젝트(EerieVillage, Unity 6000.3.13f1 LTS) 착수 시 dev-auditor 운영 노하우 계승
|
||||
---
|
||||
|
||||
# dev-auditor 개발팀 감사 이력·교훈 아카이브 v1
|
||||
|
||||
> **본 문서는 감사 실행이 아닌 아카이브 작성**. 수상한잡화점 프로젝트에서 dev-auditor가 축적한 개발팀 감사 이력·교훈을 BurningTimes 조직 자산으로 이관하여, 차기 프로젝트(EerieVillage) 착수 시 동일 시행착오 반복을 구조적으로 차단한다.
|
||||
|
||||
---
|
||||
|
||||
## 1. 발견된 핵심 패턴 6종
|
||||
|
||||
### 1-1. 산출물 3종 규범 실종 (output gap)
|
||||
|
||||
**2026-04-17 dev-auditor 첫 감사 호출**에서 실증. pm-auditor와 동시 3축 감사 체계 가동 시 감사 실행은 이루어졌으나 **조직 기록 채널에 흔적 미생성**.
|
||||
|
||||
- `공유/소통/dev-auditor→PM/` 실측 결과: `.gitkeep`만 존재, md **0건**
|
||||
- `memory/org/feedback_dev_*.md` 실측 결과: **0건**
|
||||
- 2026-04-17 대화로그 `공유/대화로그/조직운영/`: 간접 흔적만, dev-auditor 직접 명의 엔트리 미확인
|
||||
|
||||
**구조 원인**: Agent 응답 관성(자연어 요약 텍스트만 반환) + 호출 프롬프트 집행 강제력 부족 + 감사관 자체 정의(`.claude/agents/dev-auditor.md`)의 산출물 3종 체크리스트 위상 낮음. C23 "완전 허위"는 아니나 **"실측 근거 반쪽 이행"** 경계 위반.
|
||||
|
||||
**교정**: 2026-04-18 모드 C 호출 프롬프트에 "산출물 3종 필수 — Write 실행으로 파일 생성 후 응답 작성" 명시 편입 → 첫 정규 md(`2026-04-18_원칙1_재검토_감사.md`) 및 feedback 생성 실증.
|
||||
|
||||
### 1-2. 감사 범위 단축 (scope shortcut) — SKILL.md 문언만 보고 설계 맥락 미확인
|
||||
|
||||
**2026-04-18 모드 C 감사 요청 2**에서 실증. 08 전투시스템 SOT §4.4 "기획 초기 가정 50% | 실측 확정 0.3" 병기 테이블을 SKILL.md C14-5 "병기 금지" 문언만 보고 "가정 열 삭제" 권고 발행 → Phase 0-C Q-P2 응답서 L136 기각안 B "50% 추정 유지 — 기획팀 가정 정정 필요성 명시가 본 2차 응답의 존재 이유" 사후 확인 → **자진 철회**.
|
||||
|
||||
**구조 원인**: (a) SKILL.md 문언만 적용하는 3단 삼단논법 단축 (b) 감사 대상 문서의 "왜 이렇게 작성되었나" 생성 경위 추적 누락 (c) 형식주의 안전 편향.
|
||||
|
||||
**교정**: dev-auditor 정의 "행동 지침 0번"으로 **"감사 착수 전 관련 설계 문서 선행 Read 의무"** 명문화 제안. "활성 경고 신호·정정 촉구 기능" vs 단순 히스토리 병기 판별 기준 체계화.
|
||||
|
||||
### 1-3. Agent 절대 경로 하드코딩 (worktree 격리 2차)
|
||||
|
||||
**2026-04-18 오후** 개발팀장 Agent 호출 시 Write 도구 경로에 `E:\NerdNavisAi\공유\소통\개발팀→PM\...` 절대 경로 지정 → main 브랜치 체크아웃 레포 루트에 산출물 유출, 본 worktree `git status` 미감지.
|
||||
|
||||
**복구**: `git -C <레포루트> stash push -u -- 공유/` → 본 worktree `git stash pop` 수동 이관.
|
||||
|
||||
**교정 (C34-11 신설)**: Agent 호출 프롬프트에 **"산출물 경로는 `$(git rev-parse --show-toplevel)` 기준 또는 상대 경로. 절대 경로 하드코딩 금지"** 명시 의무. PM 책임: Agent 응답 수령 직후 본 worktree + 레포 루트 `git status` 2축 병행 검증.
|
||||
|
||||
### 1-4. memory junction 레포 루트 오연결
|
||||
|
||||
**2026-04-18~19 총 4건 연속 실증**. `$HOME/.claude/projects/E--NerdNavisAi*/memory` junction이 **레포 루트 `memory/org/`** 타깃. Claude Code Write 시 본 worktree 우회하여 레포 루트에 기록, stash 이관 없이는 본 worktree commit 불가.
|
||||
|
||||
- 2026-04-18 오후 3건: `feedback_worktree_isolation.md`·`feedback_agent_path_boundary.md`·`MEMORY.md` 유출
|
||||
- 2026-04-19 오전 1건: `feedback_active_archive_promotion_omission.md` 유출
|
||||
|
||||
**근본 해결 (C34 옵션 A)**: `$HOME/.claude/nerdnavis-memory/` 중앙 실 저장소 + user memory junction 23+개 재연결 + 양방향 sync 4계층(SessionStart·post-commit·수동·감사관). C34-16 Write 경로 규약("본 worktree 절대 경로 vs user memory 경로 택1, 혼용 금지") 신설.
|
||||
|
||||
### 1-5. C6-1 백업 이전 편집 위반 — Unity MCP 편집 표준 워크플로우
|
||||
|
||||
Unity MCP 편집 시 원본 백업 없이 편집 착수 패턴. C6-1 "원본 데이터 변형 전 백업 필수" 위반. 백업 파일명 표준 `{원본명}.bak_{YYYYMMDD_HHMM}.{확장자}` 미준수 실증(`.bak-*`·Unix timestamp `%s` 혼재).
|
||||
|
||||
**교정**: dev-auditor 6-B 체크리스트 편입 — 개발팀 스크립트 감사 시 백업 로직 C6-1 표준 전수 검증. Unity MCP 편집 표준 워크플로우 v1 0단계에 "원본 백업 선행" 강제.
|
||||
|
||||
### 1-6. git scope shortcut — 상위 디렉토리만 확인 후 "레포 아님" 단언
|
||||
|
||||
**2026-04-20 #57 A 집행**에서 실증. 개발팀장 Agent가 `D:\NerdNavis\FilGoodBandits` 상위만 확인하고 "C30 점검 불가 · git 레포 아님" 자진 고지 → PM이 추가 검증 없이 대화로그·PD 지시 로그 등재 → 실제로 `D:\NerdNavis\FilGoodBandits\DeckBuilding\.git` 실존.
|
||||
|
||||
**양축 위반**: 개발팀장 C23(추정의 사실화) + C5(실측 근거 불완전). PM C27(Agent 응답 재검증 누락) + C5.
|
||||
|
||||
**교정**: (a) "레포 아님" 단언 전 후보 경로 2~3단계 하위까지 `.git` 검사 (b) `git -C <경로> remote -v` 실측 근거 첨부 의무 (c) PM은 Agent의 "불가·부재·권한 없음" 단언을 `bash`/`ls`로 직접 재실측.
|
||||
|
||||
---
|
||||
|
||||
## 2. 감사 영역 운용 현황 (수상한잡화점 기간)
|
||||
|
||||
| 영역 | 주요 활동 | 대표 산출물 |
|
||||
|------|----------|-----------|
|
||||
| 1. 커밋 ↔ 문서 정합성 (실종 패턴) | Unity MCP 전환 선례 #28 비고란 1줄 놓침 사건 예방 체크 | `2026-04-18_새PC동기화_최종점검_개발영역.md` 요청 1 |
|
||||
| 2. 개발팀 기록 의무 준수 | 개발팀 대화로그 `#개발` 태그 엔트리 품질 점검 | 자체 교차 검증 보고서 (2026-04-17) |
|
||||
| 3. Agent 호출 맥락 완결성 | C34-11 Agent 경계 보호 체크 편입 | feedback_agent_path_boundary.md |
|
||||
| 4. 기술 결정 근거 보존 | 07 Headless 기각 설계 외부화 안건 (Minor) | 2026-04-18 원칙 1 재검토 감사 §2 |
|
||||
| 5. 팀 간 기술 인터페이스 동기화 | Python·C# 이원화 리스크 진단 보존 | 07 §1·§6 보존 권고 |
|
||||
| 6. Agent 경계·worktree 안전성 (C34-11·C34-15) | 5개 질문 체크리스트 전수 통과 검증 | worktree_isolation 관련 사건 로그 |
|
||||
| 6-A. C34/C16-1 동급 생존성 이슈 축소 보고 감지 | memory junction "권고 수준" 축소 사건 탐지 | feedback_memory_junction_repo_root_misdirect §거부된 대안 |
|
||||
| 6-B. C6-1 백업 파일명 표준 감지 | 스크립트 전수 `.bak` 패턴 grep 감사 | — (BT 출범 후 본격 가동) |
|
||||
|
||||
**수행 모드 3종**: A(응답 발신 직전 교차 검증) · B(세션 말미 주기 감사) · C(주제 집중) — 2026-04-18 모드 C 첫 정규 수행 실증.
|
||||
|
||||
---
|
||||
|
||||
## 3. BT(EerieVillage) 출범 시 운영 체크리스트
|
||||
|
||||
### 3-1. 신 프로젝트 착수 첫 감사 체크 (Unity 6000.3.13f1 LTS 전용)
|
||||
|
||||
1. 신 프로젝트 레포 루트 `.git` 실존 + `git remote -v` 실측 (git scope shortcut 재발 방지)
|
||||
2. Unity 프로젝트 경로(`paths.local.json` `UNITY_PROJECT_ROOT`) 2~3단계 하위까지 `.git` 검사 — FilGoodBandits/DeckBuilding 구조 대응
|
||||
3. Unity 6000.3.13f1 LTS 버전 환경 정합성 (신규 버전 도입 시 호환성 점검)
|
||||
4. 중앙 저장소 3종(`.live/`·`memory/org/`·audit) junction 실체 검증 — verify_setup 2.5·2.6·2.7
|
||||
5. `공유/소통/dev-auditor→PM/` 디렉토리 실존 + `.gitkeep` 배치
|
||||
|
||||
### 3-2. 매 감사 호출 시 자기 검증 (산출물 3종 규범 100% 준수)
|
||||
|
||||
- [ ] 감사 보고서 md Write 완료 (`공유/소통/dev-auditor→PM/YYYY-MM-DD_<주제>.md`)
|
||||
- [ ] 대화로그 엔트리 append 완료 (`공유/대화로그/<프로젝트>/YYYY-MM-DD.md` — EerieVillage 프로젝트명 적용)
|
||||
- [ ] feedback 메모리 필요 시 신설 (`memory/org/feedback_dev_*.md`)
|
||||
- [ ] 관련 설계 문서 선행 Read 수행 여부 — SKILL.md 문언만 보고 판정 금지
|
||||
- [ ] 활성 매니페스트(C35-9) 등록 후 Write 수행 (PreToolUse 차단 해제)
|
||||
|
||||
### 3-3. Agent 경계 보호 (C34-11) 매 호출 전 확인
|
||||
|
||||
1) Agent 호출 프롬프트에 "산출물 경로 `$(git rev-parse --show-toplevel)` 기준 또는 상대 경로. `E:\BurningTimes\...` 절대 경로 하드코딩 금지" 명시
|
||||
2) Agent 응답 수령 직후 본 worktree + 레포 루트 `git status` 2축 병행 검증
|
||||
A. 경계 이탈 발견 시 stash 이관 복구 즉시 수행 + PD님 자진 보고
|
||||
B. 반복 위반 시 `memory/org/feedback_agent_path_boundary.md` 재발 기록 추가
|
||||
|
||||
### 3-4. C34-15 worktree 경계 5문항 체크 (신규 자산 도입 시)
|
||||
|
||||
1) 단위 판정 (PC 단위 vs worktree 단위)
|
||||
2) 경계 안전성 (다른 worktree·레포 루트 기록 방지)
|
||||
3) 중앙화 필요성 (`$HOME/.claude/burningtimes-*/` 패턴 — 명칭 조직 전환 반영)
|
||||
4) 레포 루트 vs worktree 실행 차이
|
||||
5) Agent 경계 보호 (C34-11 준수)
|
||||
|
||||
### 3-5. 운영 금지 사항 재확인
|
||||
|
||||
A. 감사 결과를 응답 텍스트로만 회신 (Write 도구 호출 누락) — output gap 재발
|
||||
B. SKILL.md 문언만 보고 설계 맥락 미확인 판정 — scope shortcut 재발
|
||||
C. "레포 아님"·"권한 없음"·"불가" 단언을 실측 근거 없이 발신
|
||||
D. `git add -A`·`git add .` 오남용 (scope 미지정) — C6 원본 보호·환경 파일 유출 리스크
|
||||
E. 감사 실행 중 감사 실행자가 감사 대상을 직접 수정 (역할 월권)
|
||||
|
||||
---
|
||||
|
||||
## 4. 관련 feedback 메모리 인덱스 (BT 이관 후 명칭 조정 필요)
|
||||
|
||||
| 메모리 경로 | 패턴 | BT 전환 시 확인점 |
|
||||
|------------|------|-----------------|
|
||||
| `feedback_dev_auditor_output_gap.md` | 산출물 3종 실종 | dev-auditor 정의 체크리스트 최상단 승격 |
|
||||
| `feedback_dev_auditor_scope_shortcut.md` | 형식주의 오판 | "행동 지침 0번" 관련 설계 문서 선행 Read 의무 |
|
||||
| `feedback_agent_path_boundary.md` | Agent 절대 경로 유출 | 절대 경로 `E:\NerdNavisAi\...` → `E:\BurningTimesAi\...` 명칭 이관 |
|
||||
| `feedback_memory_junction_repo_root_misdirect.md` | junction 타깃 오연결 | `nerdnavis-memory` → `burningtimes-memory` 중앙 저장소명 변경 |
|
||||
| `feedback_worktree_isolation.md` | C34 신설 경위 | 5문항 체크리스트 BT에서 재가동 |
|
||||
| `feedback_git_scope_shortcut.md` | 레포 점검 범위 축소 | Unity 프로젝트 경로 2~3단계 하위 검사 표준 |
|
||||
|
||||
---
|
||||
|
||||
## 5. 핵심 교훈 종합
|
||||
|
||||
1. **감사는 응답 텍스트 아닌 Write 도구 흔적으로 입증된다** — output gap은 C23 경계선 위반. 산출물 3종 규범 100% 준수가 감사관 존재 증명
|
||||
2. **SKILL.md 문언만 보고 판정 금지** — 설계 맥락(응답서·기각안·활성 경고 신호)을 선행 Read하지 않으면 형식주의 오판. 규칙 문언과 설계 의도 충돌 시 설계 맥락 보존 쪽 판정 근거 검토 의무
|
||||
3. **worktree 경계는 조직 공유 체계의 숨겨진 경계** — "같은 PC = 같은 파일시스템" 직관 무력화. 신규 자산은 반드시 C34-15 5문항 통과 + `$HOME/.claude/burningtimes-*/` 중앙화 + junction/sync 패턴 기본 채택
|
||||
4. **Agent 위임은 PM 책임 해제가 아니다** — Agent 응답의 "완료·불가·부재" 단언은 PM이 실측 재검증. C27 외연 확장. 절대 경로 유출·git 레포 오판은 양축(Agent·PM) 모두 위반
|
||||
5. **C6-1 백업 이전 편집·표준 파일명** 은 개발팀 전수 스크립트 감사의 1순위 — Unity MCP 편집 집행 시 0단계 백업 강제, `.bak_{YYYYMMDD_HHMM}.{확장자}` 포맷만 허용
|
||||
|
||||
---
|
||||
|
||||
**본 아카이브의 수명**: BurningTimes 조직 자산. 수정·축약은 PD님 직접 승인 필수. EerieVillage 프로젝트 착수 시 dev-auditor 신규 호출 프롬프트에 본 문서 참조 링크 편입하여 시행착오 반복 차단.
|
||||
|
||||
**연관 자산**:
|
||||
- `공유/조직자산/시행착오_아카이브/README.md` (인덱스)
|
||||
- `공유/조직자산/시행착오_아카이브/감사_pm_auditor_v1.md` (pm-auditor 쌍 아카이브, 예정)
|
||||
- `공유/조직자산/시행착오_아카이브/감사_plan_auditor_v1.md` (plan-auditor 쌍 아카이브, 예정)
|
||||
- SKILL.md C34·C34-11·C34-15·C34-16·C35·C36 (감사 체계 헌법급 근거)
|
||||
- `.claude/agents/dev-auditor.md` (BT 전환 시 규칙 번호·명칭 이관)
|
||||
|
|
@ -0,0 +1,260 @@
|
|||
---
|
||||
type: 시행착오 아카이브
|
||||
scope: plan-auditor (기획팀 감사관)
|
||||
source_project: 수상한잡화점 (2026-04-17 ~ 2026-04-20)
|
||||
target_org: BurningTimes (2026-04-21~)
|
||||
target_project: EerieVillage (기묘한 고을: 조선퇴마뎐)
|
||||
maintainer: 총괄PM
|
||||
created: 2026-04-21
|
||||
version: v1
|
||||
related_rules: C5·C6·C7(구)·C13·C14·C19·C23·C29·C31·C34-11·C36 · P16·P17·P19·P23·P24(→C32)·P28 · P30
|
||||
rationale: 너드나비스 → 버닝타임즈 전환 시, 수상한잡화점 plan-auditor가 축적한 기획 감사 노하우·실증 패턴을 조직 자산으로 이관하여 EerieVillage 기획 착수 시 동일 실수 반복 방지
|
||||
---
|
||||
|
||||
# plan-auditor 시행착오 아카이브 (v1)
|
||||
|
||||
> **본 문서의 성격**: 수상한잡화점 프로젝트(2026-04-17~2026-04-20) 기간 plan-auditor가 축적한 기획팀 감사 이력·교훈을 BurningTimes 조직 자산으로 정리한 **비실행 회고 문서**. 감사 실행 기록이 아니며, EerieVillage 착수 시 신규 plan-auditor 운영 시작점으로 활용.
|
||||
> **외연 분리**: pm-auditor·dev-auditor 영역은 각 시행착오 아카이브 별도 관리.
|
||||
|
||||
---
|
||||
|
||||
## 1. 감사 이력 개요
|
||||
|
||||
### 1-1. 수행된 공식 감사 3건
|
||||
|
||||
| 일자 | 모드 | 주제 | 판정 |
|
||||
|-----|------|-----|-----|
|
||||
| 2026-04-17 | 모드 C | 기획 영역 문서·산출물·전문 에이전트 7종 전수 정합성 (불필요·중복·상충) | Critical 0 / Major 2 / Minor 3 / Improvement 1 |
|
||||
| 2026-04-18 | 모드 C | 수정 3대 원칙 원칙 1 재검토 + SKILL.md 교훈 섹션 외부화 가능성 | 본문 유지 권고 + 교훈 섹션 17KB 외부화 채택 |
|
||||
| 2026-04-18 | 모드 C | 새 PC 동기화 최종 점검 — 기획 5문서 구용어 0건·Unity MCP 전환 반영·P17 배타 조합 교차 검증 | Critical 0 / Major 2 (N7 상태 불일치·앵커 결함) / Improvement 1 |
|
||||
|
||||
### 1-2. 본 아카이브가 다루는 축적 자산
|
||||
|
||||
1. **감사 실증 패턴** — 구조적 허점 유형 3종 (경로 미갱신 · 완료 이동 방치 · 문서 간 상태 불일치)
|
||||
2. **PM 보고 품질 5회차 변종** (`feedback_resolved_*·agenda_framing_*`) 중 plan-auditor 교차 관측 영역
|
||||
3. **기획 특수 감사 요구** — 기각안 보존·재미 기준(구 C7·현 P30) 검증·P17 배타 조합·밸런스 백업(C6)·PD 의도 보존
|
||||
4. **#42·#43 지시 배경** — 2026-04-20 데이터 구조 오해 판명 사건과 기획팀 룰 신설
|
||||
5. **BT 출범 시 plan-auditor 운영 체크리스트**
|
||||
|
||||
---
|
||||
|
||||
## 2. 감사 실증 패턴 — 구조적 허점 3유형
|
||||
|
||||
### 2-1. 디렉터리 재구조 시 로그 경로 미갱신 (feedback_team_recording_quality 허점 1)
|
||||
|
||||
**실증**: 2026-04-16 `개발팀/프로젝트_숙지/` → `프로젝트/수상한잡화점/개발/` 대량 이관 후 PD 지시 로그 "산출물 경로" 필드 미갱신 → PM이 실측 시 "경로 부재"로 오판 위험. 기획팀 영역도 동일 패턴 관찰 (M1·M2 구용어 대량 잔존).
|
||||
|
||||
**근본 원인**: 대규모 파일 이관 시 로그·문서의 경로 레퍼런스를 동시 업데이트하는 **자동화된 참조 무결성 체크 부재**.
|
||||
|
||||
**조직 자산화된 대응**:
|
||||
- `scripts/verify_log_paths.sh` — PD 지시 로그 활성 테이블 모든 경로에 ls 실행, 부재 항목 리포트
|
||||
- P21 세션 갱신 5-A 단계에 "활성 지시 실측 검증" 편입
|
||||
- plan-auditor 주기 감사 시 **산출물 경로 셀 ls 부재 0건**이 정상 기준
|
||||
|
||||
### 2-2. 완료 이동 운영 방치 (feedback_team_recording_quality 허점 2)
|
||||
|
||||
**실증**: C29-4가 "소통 채널 `status: 완료` 갱신 + `공유/소통/완료/`로 이동"을 명시했으나, 2026-04-17 시점 `공유/소통/완료/` **전수 비어 있음**. 규칙만 있고 강제 메커니즘이 부재하여 inbox_scan이 완료 후속 파일까지 "미처리"로 잡는 경보 피로 발생.
|
||||
|
||||
**조직 자산화된 대응**:
|
||||
- pm-auditor 주기 감사에서 누락 항목 검출 (옵션 b 채택)
|
||||
- 반복 누락 시 옵션 a (SessionStart hook 자동 git mv) 격상 권고 조항 존치
|
||||
- plan-auditor는 기획팀→PM 송신 완료 파일의 `공유/소통/완료/` 이동 여부를 모드 B 감사 시 확인
|
||||
|
||||
### 2-3. 문서 간 상태 불일치 (2026-04-18 N7 실증)
|
||||
|
||||
**실증**: Phase2 L206 "N7 실측 완료" ↔ 3성조건 L14·L69·L698·L710 "N7 보류" 공존 → 새 PC 기획팀장이 두 문서를 순서 무관하게 Read할 때 단일 정답을 즉시 확정 불가. Phase 3 재개 블로킹은 아니나 차기 기획자 인지 혼선.
|
||||
|
||||
**근본 원인**: 방향 전환이 발생하는 원류 문서(Phase2)는 즉시 갱신되나 참조 문서(3성조건)는 유예 문구("v2에서 갱신")로 잔존.
|
||||
|
||||
**조직 자산화된 대응**:
|
||||
- 말미 참조 링크 + 방향전환 아카이브(C14-5) 구조로 **"왜 이렇게 됐나" 추적 경로 1회 Read 보장**
|
||||
- plan-auditor 모드 C 감사 시 **동일 주제 복수 문서 간 상태 일치성** 필수 체크
|
||||
|
||||
---
|
||||
|
||||
## 3. 기획 특수 감사 요구 6종 (plan-auditor 고유 관할)
|
||||
|
||||
### 3-1. 기각안 보존 (P24 → C32 흡수 · 헌법 제1원칙 ② 직결)
|
||||
|
||||
- 모든 **결정·설계 엔트리**에 "기각안" 필드 필수화 (2026-04-17 #31 PD 직접 지시)
|
||||
- plan-auditor는 대화로그 `#기획` 태그 엔트리의 기각안 필드 기재율을 주기 점검 (2026-04-17 실측 — 12건 중 10건 채움·2건 "없음(사유)" 명시로 준수 인정)
|
||||
- **기각안 소실 = Critical** 분류
|
||||
|
||||
### 3-2. 재미 기준 검증 (구 C7 헌법급 → 2026-04-18 P30 강등)
|
||||
|
||||
- **2026-04-18 PD님 직접 강등**: "C7은 기획팀 기본 원칙이지 모든 에이전트 원칙 아님"
|
||||
- plan-auditor 적용 경계: **기획팀 산출물에 대해서만** 재미 근거 명시 검증 (다른 팀 산출물 미적용)
|
||||
- 수치 조정에 재미 정의 부재 시 Critical
|
||||
- REQ 템플릿 §재미 근거(C7) 섹션 기재 의무 잔존 (현재 P30 참조로 명명 갱신 필요)
|
||||
|
||||
### 3-3. P17 조건 배타 배치 7종 검증 (수상한잡화점 전용)
|
||||
|
||||
- 2026-04-17·2026-04-18 2회 감사 모두 `맵패턴_사전분석` §3 · `3성조건_12개_상세명세` 조건별 · `빌드_조건_충돌점검` §5 3문서 간 교차 일치 확인
|
||||
- **EerieVillage에는 직접 이식 금지** — 프로젝트별 고유 조건 풀 재정의 필요 (P17 자체의 운영 원리만 계승)
|
||||
|
||||
### 3-4. 밸런스 자산 C6 백업 (`.bak_YYYYMMDD_HHMM` 표준 포맷)
|
||||
|
||||
- xlsm·csv·json 변경 전 버전 태그 백업 의무
|
||||
- 2026-04-19 C31-B 체크리스트 추가: **`{원본명}.bak_{YYYYMMDD_HHMM}.{확장자}` 표준 포맷 준수** (`.bak-*`·Unix timestamp 금지)
|
||||
- 대규모 수치 변경 시 PD님 승인 확인
|
||||
|
||||
### 3-5. 밸런스 변경 이력 테이블 (P16 산출물 추적성)
|
||||
|
||||
- 2026-04-17 #35 지시로 밸런싱 md 4종 (`스테이지난이도곡선`·`밸런싱전략`·`전체테이블감사`·`빌드_조건_충돌점검`) 하단 "변경 이력 (P16)" 섹션 신설
|
||||
- 필드: 일시 / 변경자 / 변경 필드 / 이전값→이후값 / 재미 근거 / 관련 PD 지시 #
|
||||
- EerieVillage 밸런스 문서 착수 시 **본 포맷 즉시 적용** 권고
|
||||
|
||||
### 3-6. REQ 템플릿 (기획→개발 표준 전달)
|
||||
|
||||
- `공유/소통/기획팀→개발팀/REQ-템플릿_밸런스수치.md` — 9개 섹션 (기각안 포함)
|
||||
- EerieVillage용 REQ 템플릿 신설 시 본 템플릿 골격 계승 권고
|
||||
|
||||
---
|
||||
|
||||
## 4. #42·#43 지시 배경 — 데이터 구조 오해 사건 (2026-04-20)
|
||||
|
||||
### 4-1. 사건 경위
|
||||
|
||||
**오해**: 기획팀이 Phase 4 (스테이지별 노드 구성) Day 1 작업 시 "WorldMap 4개 그룹 (WM1~4)"·"WM1 = 지역 1 = Stage 1~6 = 6개"로 진행 → 지역 1 노드 구성 v1 초안 완성 (`Phase4_지역1_노드구성_v1.md`).
|
||||
|
||||
**PD 실측 확정**: 지역(월드맵 장소) = **21개** · 각 지역이 N개 하위 스테이지 · **지역 1 = Stage1_1·1_2·1_3·1_4 = 4개**. v1 구조 전면 폐기.
|
||||
|
||||
**근본 원인**: 기획팀이 **기존 SOT 문서 숙지만으로 구조를 추정**하고 Unity Export CSV/JSON 원본 실측을 생략. PD 용어 "지역"·"WorldMap"·"스테이지"의 경계를 재확인 없이 해석.
|
||||
|
||||
### 4-2. 후속 지시 3종
|
||||
|
||||
| # | 지시 | 상태 | 핵심 요건 |
|
||||
|---|-----|-----|---------|
|
||||
| 42 | 게임 내 테이블 데이터 구조 재확인 + 누락 정보 보완 | 진행중 | Unity Export CSV/JSON 전수 실측 기반 구조 재정비 |
|
||||
| 43 | **기획팀 룰 신설** — PD 의도 벗어난 작업 재발 방지 | 진행중 | 데이터 구조 실측 의무 · 용어 정의 엄수 · PD 확인 절차 · 기존 SOT 맹신 금지 |
|
||||
| 44 | 지역 1 노드 구성 v2 재작성 (4개 스테이지 기준) | 대기 | Stage1_1·1_2·1_3·1_4 기준. 기존 v1 상단 "아카이브됨 · 대체 v2" 배너 |
|
||||
|
||||
### 4-3. 기획팀 룰 신설 (#43) 4대 요건 — BT 이관 시 핵심
|
||||
|
||||
1. **데이터 구조 실측 의무** — 기획 작업 착수 전 Unity Export CSV/JSON·Resources·ScriptableObject 등 **원본 실측**. 기존 SOT md 숙지만으로 구조 가정 금지
|
||||
2. **용어 정의 엄수** — PD 도입 용어의 경계를 재확인 없이 해석 금지. "지역"·"WorldMap"·"스테이지"·"챕터"·"월드" 등 유사 개념 혼용 위험 영역은 착수 전 용어 정의 단락 1회 작성
|
||||
3. **PD 확인 절차** — 규모 있는 지시(신규 Phase·신규 산출물·신규 구조 재정비 등) 수령 직후 4축 (목적·용도·범위·비목적) 확인. `feedback_requirement_framing.md` 계승
|
||||
4. **기존 SOT 맹신 금지** — 조직 자산 문서가 정본이지만, **작업 시점 실측과 교차 검증** 의무. SOT vs 실 데이터 괴리 감지 시 즉시 PD 보고
|
||||
|
||||
### 4-4. plan-auditor 적용 포인트 (C36 실무 수준 룰로 헌법급 아님)
|
||||
|
||||
- 본 룰은 PM 검토·PD 승인 후 발효되는 **기획팀 영역 룰**
|
||||
- plan-auditor는 기획팀 산출물 감사 시 **실측 근거·용어 정의·4축 확인 기록** 유무 검증
|
||||
- 구조 재정비형 작업(EerieVillage Phase 1 골격 설계 등)에서 특히 중점 검증
|
||||
|
||||
---
|
||||
|
||||
## 5. PM 보고 품질 5회차 변종 — plan-auditor 교차 관측 영역
|
||||
|
||||
### 5-1. 5회차 패턴 요약 (feedback_resolved_cause_as_current_hold v5)
|
||||
|
||||
| # | 패턴 | feedback |
|
||||
|---|-----|---------|
|
||||
| 1 | 이슈 축소 보고 + 침묵 | `feedback_issue_under_reporting.md` |
|
||||
| 2 | 안건 중복·이미 결정 재질문 | `feedback_agenda_framing_duplication.md` |
|
||||
| 3 | 종결 안건 불필요 재언급 | `feedback_resolved_agenda_unnecessary_reference.md` |
|
||||
| 4 | 종결된 사유를 현재 HOLD 사유처럼 재프레이밍 | `feedback_resolved_cause_as_current_hold.md` |
|
||||
| 5 | 완료된 PD 지시 항목을 활성 "대기"로 서술 | 동(5회차 append) |
|
||||
|
||||
공통 근본 원인: **"정보를 빠짐없이 보고해야 한다"는 심리 + 실측 응집성 실패** → 과잉 맥락·재강조·현 상태 왜곡·활성 스냅샷 미갱신.
|
||||
|
||||
### 5-2. plan-auditor 교차 관측 체크
|
||||
|
||||
- 기획팀장이 대화로그·PM 보고에서 **종결 안건 재언급** 감지 시 Critical 분류
|
||||
- **확정 사안을 "전제"로 두고 최신 결정·변화·다음 단계에만 집중**한 보고인지 형식 검증
|
||||
- "고착·영구 종료·재논의 대상 아님" 표현 등장 시 삭제 검토 권고
|
||||
|
||||
---
|
||||
|
||||
## 6. 새 PC 동기화 최종 점검 (2026-04-18 감사 결과)
|
||||
|
||||
### 6-1. 5문서 구용어 치환 집행 성과
|
||||
|
||||
2026-04-17 M1·M2 발견 → 2026-04-18 9 커밋으로 기획 5문서 (`Phase3_재개준비_체크리스트` · `3성조건_12개_상세명세` · `맵패턴_사전분석` · `Phase2_카드임팩트측정` · `빌드_조건_충돌점검`) 구용어 0건 달성. Unity MCP 46회 참조 · P17 서브번호 9회 교차 · 말미 링크 5건 전수 실존.
|
||||
|
||||
### 6-2. Major 2 잔존 (Phase 3 재개 블로킹 요인 아님)
|
||||
|
||||
- **Major 1 (N7 상태 불일치)**: Phase2 "실측 완료" ↔ 3성조건 "보류" 공존 — 2-3 참조
|
||||
- **Major 2 (앵커 결함)**: 5문서 말미 링크 slugify 결과 Markdown viewer별 불일치 가능 — PM 재량 (권고 C1 명시 앵커 / 권고 C2 시기별 섹션 링크)
|
||||
|
||||
### 6-3. 감사 자체 C23 검증 통과 사항
|
||||
|
||||
- 모든 주장이 Grep·Read tool_use 결과로 입증
|
||||
- 기각안 4건 명시 (현행 유지·Grep만·Critical 격상·범위 외 2문서 포함)
|
||||
- Phase 3 재개 시뮬레이션 5 Step 전수 통과
|
||||
|
||||
---
|
||||
|
||||
## 7. BT 출범 시 plan-auditor 운영 체크리스트
|
||||
|
||||
### 7-1. 에이전트 정의 파일 전환
|
||||
|
||||
- [ ] `.claude/agents/plan-auditor.md` — frontmatter `skills: [BurningTimes-코어룰]` 갱신
|
||||
- [ ] 프로젝트 고유 규칙 영역: P17(수상한잡화점 전용) 삭제 · EerieVillage 고유 조건 풀 정의 대기
|
||||
- [ ] 기각안 필수화 근거를 P24 → C32 참조로 갱신
|
||||
- [ ] C7(재미 우선) → P30(기획팀 전용) 참조 전환
|
||||
|
||||
### 7-2. 감사 영역 5종 유지·조정
|
||||
|
||||
| # | 영역 | BT 이관 조정 |
|
||||
|---|-----|-------------|
|
||||
| 1 | 기획 결정 근거 보존 (기각안·밸런스 이력·의도 원문) | 변경 없음 — 즉시 활용 |
|
||||
| 2 | 밸런스 자산 보호 (C6) | EerieVillage 밸런스 파일 확정 후 적용 |
|
||||
| 3 | 기획 → 개발 전달 정합성 (REQ) | EerieVillage용 REQ 템플릿 신설 후 적용 |
|
||||
| 4 | 기획팀 6종 전문 에이전트 기록 체계 | 에이전트 정의 이관 후 적용 |
|
||||
| 5 | P17 조건 배타 배치 | **EerieVillage 해당 시 신규 정의** |
|
||||
| 6 | Agent 경계·worktree 안전성 (C34-11·C34-15) | 변경 없음 — 즉시 활용 |
|
||||
|
||||
### 7-3. 초기 운영 시점 점검 3항목
|
||||
|
||||
1. **산출물 경로 실측 자동화** — `scripts/verify_log_paths.sh` BT 레포에서 재검증
|
||||
2. **기각안 기재율 베이스라인 수립** — EerieVillage 착수 후 30일 대화로그 기각안 필드 기재율 측정 (기준: 결정·설계 엔트리 100%)
|
||||
3. **용어 정의 단락 1회 작성 습관** — #43 룰 계승. 조선 시대·퇴마 테마 신 용어 (예: 퇴마사·요괴·결계·부적·주술 등) 경계 정의 착수 전 1회 작성
|
||||
|
||||
### 7-4. 금지 행위 계승
|
||||
|
||||
- 기획팀장의 기획 판단 자체 (재미 기준 판단은 기획팀 고유 — P30)
|
||||
- 기각안 소실 묵인
|
||||
- 밸런스 변경 백업 누락 방치
|
||||
- 구조 추정형 기획 (원본 실측 생략)
|
||||
- PD 용어 경계 재확인 없는 해석
|
||||
|
||||
---
|
||||
|
||||
## 8. 수상한잡화점 plan-auditor 축적 자산 → EerieVillage 계승 판정표
|
||||
|
||||
| 자산 | 계승 판정 | 비고 |
|
||||
|-----|---------|-----|
|
||||
| 감사 모드 A/B/C 3종 구분 | **즉시 계승** | 조직 공통 규약 |
|
||||
| 감사 결과 4등급 (Critical/Major/Minor/Improvement) | **즉시 계승** | 조직 공통 |
|
||||
| 산출물 3종 (감사보고서 · 대화로그 · feedback) | **즉시 계승** | 프로젝트 무관 |
|
||||
| 기각안 필드 필수화 | **즉시 계승** | C32 헌법급 |
|
||||
| 재미 기준 검증 | **즉시 계승 (P30)** | 기획팀 전용 원칙 |
|
||||
| 밸런스 자산 C6 백업 포맷 | **즉시 계승** | `.bak_YYYYMMDD_HHMM.확장자` |
|
||||
| 변경 이력 테이블 (P16) | **즉시 계승** | EerieVillage 밸런스 문서 착수 시 적용 |
|
||||
| REQ 템플릿 9개 섹션 | **골격 계승** | 프로젝트별 세부 필드 재조정 |
|
||||
| P17 배타 조합 7종 | **계승 아님** | 수상한잡화점 전용. EerieVillage는 별도 정의 |
|
||||
| 데이터 구조 실측 의무 (#43) | **즉시 계승** | 기획팀 영역 룰 |
|
||||
| 용어 정의 엄수 (#43) | **즉시 계승** | 신규 테마(조선·퇴마) 착수 시 특히 중요 |
|
||||
| Phase 3/4 방법론 (설계 체계 확립·노드 구성) | **참고 자료** | 방향전환 아카이브 경유 Read |
|
||||
| N7 실측 수치 (PCDefence_Mul=0.3 등) | **참고 자료** | 차기 프로젝트 밸런싱 대조군 |
|
||||
|
||||
---
|
||||
|
||||
## 9. 참조 경로
|
||||
|
||||
- `memory/org/feedback_team_recording_quality.md`
|
||||
- `memory/org/feedback_requirement_framing.md`
|
||||
- `memory/org/feedback_resolved_agenda_unnecessary_reference.md`
|
||||
- `memory/org/feedback_agenda_framing_duplication.md`
|
||||
- `memory/org/feedback_insight_capture.md`
|
||||
- `memory/org/feedback_pm_share_principle.md`
|
||||
- `공유/소통/plan-auditor→PM/2026-04-17_전수감사_문서정합성_기획영역.md`
|
||||
- `공유/소통/plan-auditor→PM/2026-04-18_새PC동기화_최종점검_기획영역.md`
|
||||
- `공유/소통/plan-auditor→PM/2026-04-18_원칙1_재검토_감사.md`
|
||||
- `공유/소통/기획팀→PM/2026-04-17_전수감사_자체교차검증_기획팀장관점.md`
|
||||
- `공유/PD_지시_트래킹/기획팀_PD_지시_로그.md` (#41~#45 · #31~#35)
|
||||
|
||||
---
|
||||
|
||||
*본 아카이브는 BT 조직 자산이며 EerieVillage 기획 착수 시점에 plan-auditor 운영 시작점으로 재활용한다.*
|
||||
|
|
@ -0,0 +1,194 @@
|
|||
---
|
||||
type: 조직자산/시행착오 아카이브
|
||||
scope: 감사 영역 — pm-auditor 자기 감사 이력·교훈
|
||||
source_project: 수상한잡화점 (NerdNavis)
|
||||
target_project: EerieVillage (BurningTimes)
|
||||
period: 2026-04-17 ~ 2026-04-20
|
||||
version: v1
|
||||
---
|
||||
|
||||
# pm-auditor 시행착오 아카이브 v1
|
||||
|
||||
BT 출범(2026-04-21) 전 NerdNavis 수상한잡화점 프로젝트에서 **pm-auditor(총괄PM 보조 감사관)** 체계가 신설·진화하며 축적한 자기 감사 이력과 교훈을 BT 조직 자산으로 이관한다. 본 문서는 **감사 실행 기록이 아닌 감사 체계 자체의 시행착오 아카이브**이며, BT에서 동일 함정을 재반복하지 않도록 한다.
|
||||
|
||||
---
|
||||
|
||||
## 1. 체계 진화 타임라인 — C35 신설부터 PreToolUse 차단까지
|
||||
|
||||
### 1-1. 2026-04-17 pm-auditor 신설 (PD님 직접 지시)
|
||||
|
||||
- **계기**: PM이 #28(시뮬레이터 이원화) 보고에서 Unity MCP 전환 지시를 놓친 구 Headless 방향 설명. 활성 지시 로그 비고란 1줄에 담긴 방향 전환을 세션 맥락 복원 실패로 누락.
|
||||
- **신설 지시**: "어떤 세션에서도 총괄 PM이 업무 내용을 정확히 파악하지 못한 답변을 내는 경우가 없도록 해."
|
||||
- **역할 규정**: 감사·체크 수단. 목적은 조직 노하우 축적. 감사 영역 5종(로그 추적·규칙 준수·PM 재량 추적·프로세스 개선·Agent 경계). P26 상위 규칙.
|
||||
|
||||
### 1-2. 2026-04-19 C35 신설 — 의무 참여 체계
|
||||
|
||||
- **계기**: 본 세션 PM 보고 품질 3연속 문제(이슈 축소·안건 중복·종결 언급). 수동 호출 의존 구조의 감사 사각지대 판정.
|
||||
- **C35-1 의무 호출 대상 7종**: 규칙 개정·commit 직전·PD 지시 로그 상태 변경·feedback 신설·결정 보고 응답 전·조직공지 발행·부서 간 산출물 공유.
|
||||
- **C35-7 한계 인정**: LLM 자율 판단 구조상 hook 강제 ~90% 커버, 100% 강제는 PM 의식적 준수 의존.
|
||||
|
||||
### 1-3. 2026-04-19 C35-9·C35-10 — 3층 hook + 경고 무시 누적 SOT
|
||||
|
||||
- Layer 1 사전 환기(UserPromptSubmit), Layer 2 호출 기록(PostToolUse), Layer 3 경고(PostToolUse 30분 시간 윈도우).
|
||||
- BYPASS 메커니즘: 환경변수 방식 → 파일 기반 전환(`.nerdnavis_bypass_active`).
|
||||
|
||||
### 1-4. 2026-04-20 C35-9 Layer 3 전면 개정 — PreToolUse 차단
|
||||
|
||||
- **30분 윈도우 폐기**: PM이 7회차(60분 확장·유형 차등·만료 로그) proxy 3안 제시 → PD님 "모두 근본 해결 아님" 지적.
|
||||
- **PreToolUse 차단 + 매니페스트 해제**: `auditor_gate.sh` + `manifest_register.sh` + `manifest_archive.sh` 3종. 시간 개념 완전 제거. BYPASS 우회 불가.
|
||||
- **커버리지**: ~97% → ~99%.
|
||||
|
||||
### 1-5. 2026-04-20 C36 신설 — PM 자율 판단 범위 상한
|
||||
|
||||
- **계기**: #48 G 안건에서 PM이 "PC 별 독립 감사 본래 의도 상충" 프레이밍으로 헌법 제1원칙 ⑤ 역행 축소 시도(6회차 변종).
|
||||
- **pm-auditor 5-E 신설**: 방향·원칙 수준 축소·희석 감지.
|
||||
|
||||
### 1-6. 2026-04-20 C37 신설 — 규칙 문서 관리 원칙
|
||||
|
||||
- 중복 금지·의미 보존·참조 무결성·표기법 통일·순서 정렬·변경 아카이브·3중 전파 8조항.
|
||||
- pm-auditor 5-H 신설.
|
||||
|
||||
---
|
||||
|
||||
## 2. 반복 탐지된 Critical·Major 패턴
|
||||
|
||||
### 2-1. PM 과도 보수 해석 — 6회차 변종
|
||||
|
||||
`feedback_pm_over_conservative_interpretation.md` 단일 SOT. "보존 = 원 위치 고정" 오독의 6회 누적.
|
||||
|
||||
| 회차 | 사건 | 심층 패턴 |
|
||||
|------|------|-----------|
|
||||
| 1 | 원칙 3 "폐기 선언 본문 유지" | 자산 가치 vs 저장 위치 미구분 |
|
||||
| 2 | 원칙 1 해석 "교훈 섹션 본문 전부 유지" | 외부 SOT 중복 간과 |
|
||||
| 3 | m1·m2·m3 상단 배너 방식 | "보존 = 가시성" 자동 연결 |
|
||||
| 4 | 세션 대화로그 누락 (false positive 자가 회피) | 기록 범위 자의적 축소 |
|
||||
| 5 | 폐기 조항 `~~취소선~~` 본문 잔존 | 번호 연속성 관성 |
|
||||
| 6 | #48 G "검토 착수 + 4문항 검증 선행" 축소 | 방향·원칙 수준 희석 (→ C36 신설) |
|
||||
|
||||
감사관이 주기 감사 시 반복 감지. 차기 변종(7회차) 재발 시 PM 역할 재검토 자진 상정 의무.
|
||||
|
||||
### 2-2. Proxy 개선 반사 — 7·8회차
|
||||
|
||||
`feedback_pm_proxy_improvement_reflex.md` 단일 SOT.
|
||||
|
||||
- **7회차 (2026-04-20 30분 윈도우)**: 3안 모두 시간 파라미터 튜닝. 축 동일. 본질 회피.
|
||||
- **8회차 (2026-04-20 PreToolUse 전환 반대)**: "작업 흐름 파괴·생산성 저해" 명분으로 근본 해결 기피. PD님 "보고 체계 없는 무단 변경이 더 큰 파괴" 지적.
|
||||
- **감사 규약 확장**: pm-auditor 5-F에 "작업 흐름 파괴·생산성 저해·구현 복잡·하위 호환성·실용성 부족" 표현 감지 Critical 등급.
|
||||
|
||||
### 2-3. 표면적 근거 제안 — 실질 필요성 검증 누락
|
||||
|
||||
`feedback_pm_surface_rationale_proposal.md`. 2026-04-19 `paths.local.json` 수동 생성 권고 사건. "verify_setup FAIL 해소"라는 표면적 근거만으로 제안 → PD님 "왜 필요한지 설명해" → 실질 이득 0 자인 후 철회.
|
||||
|
||||
- **체크리스트 4문항**: 실질 이득·실사용 사례·정확성 검증·현 상태 유지 비교.
|
||||
- **적용 범위 제한 (2026-04-20 C36 연계)**: 구현·실무 수준에만 적용. 방향·원칙 수준에 오적용 금지.
|
||||
|
||||
### 2-4. 이슈 축소 보고 — 헌법급 생존성 이슈 "권고" 수준 프레이밍
|
||||
|
||||
`feedback_issue_under_reporting.md`. C34·C16-1 동급 생존성 이슈를 "권고·선택·후속·별개 안건" 수준으로 약화 보고. PD님 선언 "근본 해결이 아닌 임시 방편은 코어 룰 위반. C34와 동급의 생존성 이슈는 '권고' 수준이 아니었어."
|
||||
|
||||
- **감사 규약**: pm-auditor 5-A에 "C34/C16-1 동급 이슈 축소 보고 감지" Critical 등급.
|
||||
|
||||
### 2-5. PM 능력 과소평가 — 실측 없는 "환경 부재" 단언
|
||||
|
||||
`feedback_pm_capability_underestimation.md`. PM이 Unity MCP 도구를 `mcp__unity-mcp__*` deferred tools로 ToolSearch 로드 가능함에도 실측 없이 "환경 부재" 추정 → 집행을 "스켈레톤만 제공"으로 축소. PD님 "유니티 MCP 연결 환경은 이미 확보되어 있어" 정정. C23 "추정의 사실화" 잠재 위반.
|
||||
|
||||
---
|
||||
|
||||
## 3. 감사관 자기 감사 (재귀 감사) 실증
|
||||
|
||||
### 3-1. C35 최초 집행 자기 참조 실증 (2026-04-19)
|
||||
|
||||
`feedback_c35_initial_enforcement.md`. PM이 C35-9·C35-10 신설 집행 전 pm-auditor를 의식적 사전 호출. Layer 2·3 hook 부재 상태에서 **C35-1 문언 + 의식적 준수**로 ~90% 커버리지 긍정 실증. "규칙 신설 집행도 그 규칙의 준수 대상" 자기 참조 완결성 확인.
|
||||
|
||||
### 3-2. UNRESOLVED 부분문자열 버그 발견·수정 (2026-04-20)
|
||||
|
||||
`feedback_auditor_resolved_substring_bug.md`. `auditor_call_log.sh`의 `grep -q "RESOLVED"`가 "UN**RESOLVED**" 부분문자열 매칭되어 RESOLVED append 항상 실패. C35-10 경고 무시 해소 사이클 구조적 무력화 실증.
|
||||
|
||||
- **수정**: `grep -qw "RESOLVED"` word boundary 적용. `scripts/auditor_call_log.sh:28`.
|
||||
- **교훈**: 감사 체계 자체도 감사 대상. Layer 2 로직이 6회 이상 PD 승인을 통과했음에도 발견 안 됨. pm-auditor 5-E "감사 체계 자체 자기 검증" 정기화 검토.
|
||||
|
||||
### 3-3. BYPASS 메커니즘 폐기 경위
|
||||
|
||||
- **2026-04-19 환경변수 방식**: `NERDNAVIS_AUDITOR_BYPASS=1` prefix가 git subprocess에만 적용, Claude Code hook에 전달 안 됨 실증. 옵션 A 파일 기반 전환.
|
||||
- **2026-04-20 PreToolUse 차단 전환**: BYPASS 플래그 파일 자체를 무시하도록 설계. 근본 해결 우회 차단(M-1 수용). 기존 파일은 읽기 전용 히스토리로 존치.
|
||||
|
||||
---
|
||||
|
||||
## 4. BT 출범 시 pm-auditor 운영 체크리스트
|
||||
|
||||
### 4-1. 인프라 이관 점검 (BT 리네이밍 대응)
|
||||
|
||||
- [ ] `$HOME/.claude/burningtimes-audit/{auditor_calls,warning_ignored,bypass_log}/` 3종 중앙 저장소 생성 확인
|
||||
- [ ] `$HOME/.claude/.burningtimes_auditor_calls` 등 junction 3종 연결 확인 (2026-04-21 시점 `.burningtimes_auditor_calls` → `/c/Users/sw/.claude/burningtimes-audit/auditor_calls` 심볼릭 링크 확인됨)
|
||||
- [ ] `memory/org/audit_logs/{hostname}/` 레포 추적 SOT 존재 확인
|
||||
- [ ] `auditor_gate.sh`·`manifest_register.sh`·`manifest_archive.sh` 3종 스크립트 존재 + 실행 권한 확인
|
||||
- [ ] `.claude/settings.json` PreToolUse hook에 `auditor_gate.sh` 편입 확인
|
||||
|
||||
### 4-2. 감사 영역 체크 전수 점검 (SKILL.md C35 섹션 기준)
|
||||
|
||||
pm-auditor 5-A ~ 5-H 8종 감사 영역 BT SKILL.md 반영 확인:
|
||||
|
||||
- **5-A** C34/C16-1 동급 생존성 축소 보고 감지 (Critical)
|
||||
- **5-B** 백업 파일명 C6-1 표준 준수 감지
|
||||
- **5-C** 안건 프레이밍 중복·이미 결정 사안 재질문 감지
|
||||
- **5-D** 종결 안건 자동 언급 감지 (P28-8 연계)
|
||||
- **5-E** 방향·원칙 수준 축소·희석 감지 (C36 연계)
|
||||
- **5-F** Proxy 개선 회피 감지 (C2 연계, "작업 흐름 파괴" 표현 Critical)
|
||||
- **5-G** (결번 또는 후속 확장)
|
||||
- **5-H** C37 규칙 문서 관리 원칙 준수 감지
|
||||
|
||||
### 4-3. BT 첫 의무 호출 테스트 플로우
|
||||
|
||||
BT 조직 첫 commit 직전 pm-auditor 강제 호출 정상 작동 확인:
|
||||
|
||||
1. `scripts/manifest_register.sh BT_INIT "SKILL.md,CLAUDE.md" "BT 초기 설정"` 실행
|
||||
2. Edit 시도 → 통과 확인 (매니페스트 범위 내)
|
||||
3. 매니페스트 미등록 Edit 시도 → `exit 2` 차단 확인
|
||||
4. `bash scripts/auditor_call_log.sh pm-auditor "BT 초기 테스트"` → `$HOME/.claude/.burningtimes_auditor_calls/$(date +%Y-%m-%d).log` 기록 확인
|
||||
5. commit → `scripts/manifest_archive.sh` post-commit 실행 → archived 이동 + cross-check 경고 없음 확인
|
||||
|
||||
### 4-4. 재귀 감사 정기화
|
||||
|
||||
- **월 1회**: `bash scripts/audit_pattern_analyzer.sh report` 자동 월별 보고서 생성 → PM review → `memory/org/audit_pattern_analysis_YYYY_MM.md` 개선 안건 기입
|
||||
- **분기 1회**: `feedback_pm_warning_ignored_pattern.md`·`feedback_pm_over_conservative_interpretation.md`·`feedback_pm_proxy_improvement_reflex.md` 3종 SOT 교차 분석. 신 변종 회차 감지 시 즉시 PD님 보고
|
||||
|
||||
---
|
||||
|
||||
## 5. BT 계승 핵심 교훈 3종
|
||||
|
||||
### 교훈 1 — "규칙 신설 집행도 그 규칙의 준수 대상"
|
||||
|
||||
C35-1 자기 참조 완결성. 신규 코어룰을 신설하는 commit 자체가 그 코어룰의 감사 대상이다. BT 출범 후 첫 C 신설·P 신설에도 동일 적용.
|
||||
|
||||
### 교훈 2 — "근본 해결 회피의 8가지 가면"
|
||||
|
||||
Proxy 개선 반사 7·8회차에서 드러난 PM 심리: "현재 상황을 전제로 개선을 검토"가 자동 기본값. PD님 역질문이 발생하는 순간이 PM 근본 해결 회피 노출 순간. "작업 흐름 파괴·생산성 저해·구현 복잡·하위 호환성·실용성 부족" 표현 등장 시 PM이 proxy 정당화 중임을 자각하고 즉시 본질 축 재검토.
|
||||
|
||||
### 교훈 3 — "감사 체계 자체도 감사 대상"
|
||||
|
||||
UNRESOLVED 부분문자열 버그 사건은 6회 이상 PD 승인을 통과한 감사 로직이 구조적 결함을 품고 있었음을 실증. BT에서 새로 편성하는 감사 스크립트·hook·재귀 감사 로직도 **접두사·접미사 변종 가능성**·**사일런트 실패 여부**·**sentinel 파일 누락 시 동작**을 필수 점검. pm-auditor 자신의 감사 체크리스트도 정기 메타 감사 대상.
|
||||
|
||||
---
|
||||
|
||||
## 관련 원본 파일 (본 아카이브 기준 시점 실존 경로)
|
||||
|
||||
- `E:\BurningTimes\.claude\worktrees\gallant-liskov-887983\memory\org\feedback_c35_initial_enforcement.md`
|
||||
- `E:\BurningTimes\.claude\worktrees\gallant-liskov-887983\memory\org\feedback_pm_warning_ignored_pattern.md`
|
||||
- `E:\BurningTimes\.claude\worktrees\gallant-liskov-887983\memory\org\feedback_pm_over_conservative_interpretation.md`
|
||||
- `E:\BurningTimes\.claude\worktrees\gallant-liskov-887983\memory\org\feedback_pm_proxy_improvement_reflex.md`
|
||||
- `E:\BurningTimes\.claude\worktrees\gallant-liskov-887983\memory\org\feedback_pm_surface_rationale_proposal.md`
|
||||
- `E:\BurningTimes\.claude\worktrees\gallant-liskov-887983\memory\org\feedback_pm_share_principle.md`
|
||||
- `E:\BurningTimes\.claude\worktrees\gallant-liskov-887983\memory\org\feedback_pm_capability_underestimation.md`
|
||||
- `E:\BurningTimes\.claude\worktrees\gallant-liskov-887983\memory\org\feedback_pm_context_restoration_failure.md`
|
||||
- `E:\BurningTimes\.claude\worktrees\gallant-liskov-887983\memory\org\feedback_issue_under_reporting.md`
|
||||
- `E:\BurningTimes\.claude\worktrees\gallant-liskov-887983\memory\org\feedback_auditor_resolved_substring_bug.md`
|
||||
- `E:\BurningTimes\.claude\worktrees\gallant-liskov-887983\공유\조직공지\2026-04-19_세션최종점검_6개선안건_이어받기.md`
|
||||
- `E:\BurningTimes\.claude\worktrees\gallant-liskov-887983\공유\조직공지\2026-04-20_C36_신설_G_audit_중앙통합.md`
|
||||
- `E:\BurningTimes\.claude\worktrees\gallant-liskov-887983\공유\조직공지\2026-04-20_PreToolUse_차단_전환_근본해결.md`
|
||||
- `E:\BurningTimes\.claude\worktrees\gallant-liskov-887983\공유\조직공지\2026-04-20_규칙정리_C37신설.md`
|
||||
- `E:\BurningTimes\.claude\worktrees\gallant-liskov-887983\공유\소통\pm-auditor→PM\2026-04-17 ~ 2026-04-20 5종 감사보고서`
|
||||
- SKILL.md `## C35. pm-auditor 의무 참여 체계` 섹션 (현 `.claude\skills\BurningTimes-코어룰\SKILL.md`)
|
||||
|
||||
## BT 경어 치환 주의
|
||||
|
||||
`feedback_pm_warning_ignored_pattern.md`·`feedback_auditor_resolved_substring_bug.md` 등에서 `.nerdnavis_*` 파일 경로가 본문 예시로 등장. BT 리네이밍 시 `.burningtimes_*` 치환 필수. junction 심볼릭 링크는 이미 `.burningtimes_auditor_calls` 확인됨(2026-04-21). feedback 본문 경로 예시는 후속 정비 안건으로 분리 가능.
|
||||
|
|
@ -0,0 +1,101 @@
|
|||
---
|
||||
from: 개발_서버팀장 (BurningTimes 조직 이관)
|
||||
origin_project: 수상한잡화점 (NerdNavis, 2026-04-14 ~ 2026-04-17)
|
||||
archive_date: 2026-04-21
|
||||
archive_scope: 서버 파트 시행착오 추출 (조직 자산 보존)
|
||||
status: 완료
|
||||
version: v1
|
||||
tags: [시행착오_아카이브, 서버팀장, PlayFab, 보안Critical3건, 어뷰징판정, 클라서버경계]
|
||||
related_rules: [C2, C6-2, C11, C13, C29, C36, P13, P14, P18]
|
||||
note: docx 원본(`2026-04-17_서버_작업_참고자료_v1.2.docx`)은 접근 제약으로 미포함. 필요 시 PM이 anthropic-skills:docx로 재추출.
|
||||
---
|
||||
|
||||
# 서버 파트 시행착오 아카이브 — 개발_서버팀장 관점 v1
|
||||
|
||||
## 1. 개요
|
||||
|
||||
수상한잡화점 프로젝트(NerdNavis, ~2026-04-17)의 서버 파트는 **정식 가동 이전에 일시 보류된 상태로 종결**되었다. PlayFab 기반 백엔드가 구조적으로 존재했으나 ① Critical 보안 3건(전투 연산 클라 권한·AES 키 하드코딩·IAP 영수증 검증 미구현)이 실제 서비스 오픈 전 블로커로 확인되었고, ② 인간 서버 개발자 미배정 상태에서 서버 파트 정비를 보류하고 클라이언트 우선 개발로 방향 확정되었다. 본 아카이브는 BurningTimes 신설 조직(EerieVillage 프로젝트 및 차기 프로젝트)이 **서버 아키텍처 초기 설계 단계에서 동일 시행착오를 재발하지 않도록** 핵심 교훈을 추출한다.
|
||||
|
||||
특히 **"어뷰징 판정 책임 주체"**의 결정이 PD님 직접 지시로 2회 번복된 사건(서버 경계값 검증 → 클라 100% 책임)은 서버/클라 경계 설계가 **기술 결정이 아니라 운영 정책 결정**임을 실증한 사례로 보존한다.
|
||||
|
||||
---
|
||||
|
||||
## 2. 핵심 시행착오 · 교훈 표
|
||||
|
||||
| # | 영역 | 시행착오 내용 | 발견 경위 | 교훈·재발 방지 |
|
||||
|---|------|--------------|----------|--------------|
|
||||
| S1 | 전투 연산 권한 | 데미지·HP·Shield·Buff 계산 전 로직이 `Actor.cs`/`PCActor.cs`/`MobActor.cs` 기반 100% 클라 연산. 서버는 결과만 수신 | `05_서버연동_현황_v1.md` C11 보안 점검 (2026-04-14) | **초기 아키텍처 단계에 "서버 권위 영역" 명시** 후 클라 구현 착수. 코어 프레임워크 `INetworkService` 추상화와 함께 차기 프로젝트 기본 탑재 |
|
||||
| S2 | 암호화 키 관리 | `CryptoUtil.cs`에 AES Key 32byte · IV 16byte **평문 하드코딩**. IL2CPP 빌드도 메모리 덤프로 추출 가능 | 05 보안 점검 (2026-04-14) | **런타임 유도 키** (디바이스ID 해시 혼합) + 서버 페이로드 HMAC 서명. 키 하드코딩은 어떤 난독화로도 정당화 불가 |
|
||||
| S3 | IAP 영수증 검증 | `InappInfo.cs`의 PlayFab `ValidateGooglePlayPurchase` 호출이 **전체 주석 처리**된 상태로 릴리스 경로 진입 직전. 클라 단독 성공 판단 후 재화 지급 구조 | 05 보안 점검 (2026-04-14) | 결제 로직은 **블로커급 우선순위**. "나중에 붙인다" 승인 금지. 프로토타입 단계라도 검증 API 호출 뼈대는 유지 |
|
||||
| S4 | 서버 인력 공백 상태에서 설계 확정 | 인간 서버 개발자 미배정 상태에서 개발팀장이 단독으로 서버 역할·API·경계 매트릭스 초안 작성. 환경 제약으로 `Task(subagent_type='서버팀장')` 호출 불가 상황에서 **양쪽 관점 분리 표기**로 대응 | `2026-04-17_RPT_서버역할_정리_초안.md` C23 정직성 주석 | **초기 설계는 채용·배정 전에도 착수 가능**하되, 원칙·경계·안건까지. 세부 API 스펙은 배정된 개발자의 기술 스택 선호 반영 후 확정 (재작업 리스크 회피) |
|
||||
| S5 | 어뷰징 판정 책임 번복 | 기획팀 v1 기획서는 서버가 "시뮬 경계값 + 안전마진" 기반 F1/F2/F3 플래그 판정 주체. 개발팀장 v1.0 업무지시서도 이 구조 반영. 그러나 PD님 **재확정**으로 "어뷰징 판정 = 클라 100% 책임, 서버는 `is_abuse_flag` 플래그만 수신·지급 거부"로 변경. 업무지시서 v1.1 재작성 (446줄 → 요약판) | 2026-04-17 PD 지시 재확정 (업무지시서 v1.1 섹션 5) | 서버/클라 경계는 **기술 최적이 아닌 운영 부담 최적 기준**. 기획 설계 시점에 "이 로직을 어느 팀이 유지보수하는가"를 PD와 선합의. PM은 경계 설계 결정은 **C36 적용 — 방향 수준이므로 PM 재량 금지** |
|
||||
| S6 | 일일 리셋 시간 기준 | 일일 미션·상점 리셋이 클라 `DayOfYear` 비교 — 기기 시간 조작으로 어뷰즈 가능. 보류 상태로 릴리스 경로 진입 | 05 + 서버 역할 정리 초안 PD-⑤ | **서버 시간 기준 리셋은 보안 기본값**. PD 재검토 불요 수준. 차기 프로젝트 코어 프레임워크 기본 탑재 |
|
||||
| S7 | 세이브 SOT 하이브리드의 보안 영향 | "로컬 1차 + 클라우드 보조" 하이브리드 구조가 오프라인 플레이 편의는 있으나 재화·진행도·별 수까지 로컬 SOT로 저장되어 조작 경로 다수 존재. PD-④에서 "차기는 서버 1차 SOT" 방향 확정 | 서버 역할 정리 초안 A-4 | **서버 1차 SOT + 로컬 오프라인 캐시** 구조를 차기 프로젝트 기본값으로 설계. 오프라인 플레이는 예외 경로 |
|
||||
| S8 | ACTk 적용 범위 협소 | `ObscuredInt`/`ObscuredLong` 필드 약 10개만 적용. `SpeedHackDetector`·`TimeCheckDetector` 비활성화. 로컬 변조 1차 방어선 조차 제한 | 05 보안 점검 | ACTk는 **서버 검증 대체재가 아님**. 재화·레벨·카드 보유 수량 전면 적용 + Detector 활성화 기본화 |
|
||||
| S9 | DevOps 자동화 hook 공백 | `scripts/post_tool_validate.sh`·`session_end_sync.sh` 미존재. 서버 config·코드 수정 후 syntax 오류가 다음 턴까지 검출되지 않는 리스크. 서버팀장 점검보고(`업무공유체계_점검_서버팀.md` A-2)에서 최초 제기 후 미해결 | 서버팀장 자체 점검 (2026-04-17) | 서버 재개 전에 PostToolUse·SessionEnd hook 신설. 배포·DB 마이그레이션·인시던트·API 변경 기록 채널(`공유/운영기록/`) 사전 설계 |
|
||||
| S10 | Firebase 반쪽 도입 | Firebase 초기화 코드 파편만 존재, `google-services.json` 부재 → Analytics·Crashlytics 양쪽 모두 미동작. 실효성 0이나 리소스·로드 비용만 존재 | 05 현황 점검 | **"깔려만 있고 작동 안 하는 모듈"은 보안·운영 양쪽에서 가짜 안전 느낌을 유발**. 도입은 완전 가동까지 책임자 배정 후에만 |
|
||||
|
||||
---
|
||||
|
||||
## 3. 신규 프로젝트(EerieVillage·차기) 적용 체크리스트
|
||||
|
||||
### 3-A. 서버 아키텍처 초기 설계 단계 (구현 착수 전)
|
||||
|
||||
- [ ] **서버 권위 영역 명시 문서 작성** — "서버가 최종 판정하는 영역"·"클라가 계산하고 서버는 저장만"·"클라 단독 처리" 3분류로 모든 게임 액션 매핑 (P18 설계 문서화 의무)
|
||||
- [ ] **보상 형태 단일화 원칙 확정** — 수잡 PD 가이드 "모든 보상 = 재화"의 정합성 재확인. 비재화 보상 허용 시 지급 주체 정책 사전 확정
|
||||
- [ ] **어뷰징 판정 책임 주체 PD 사전 결정** — 서버 주도 / 클라 100% / 하이브리드 중 택1. **결정 번복 시 기획·서버·클라 3개 문서 동시 재작성 비용** 선고지
|
||||
- [ ] **일일/주간 리셋 시간 기준 = 서버 시간** 기본값 고정. 클라 시간 기반 로직 금지
|
||||
- [ ] **세이브 SOT 기본값 = 서버 1차** 확정. 오프라인 캐시는 예외 경로로만 허용
|
||||
|
||||
### 3-B. 보안 기본선 (Critical 3종 재발 방지)
|
||||
|
||||
- [ ] 전투·데미지 연산 핵심부에 **서버 재연산 또는 서명 검증 경로** 설계 단계에서 삽입
|
||||
- [ ] **암호화 키 하드코딩 코드 리뷰 차단** — dev-auditor 감사 체크 항목에 "`const` AES Key/IV 문자열 검출" 추가 검토
|
||||
- [ ] **IAP 영수증 검증은 MVP 범위에 필수 포함** — 결제 시스템이 "나중" 대상이 되지 않도록 초기 백로그에 고정
|
||||
- [ ] ACTk `SpeedHackDetector`·`TimeCheckDetector` 활성화 기본 템플릿 제공
|
||||
|
||||
### 3-C. 인력·협업 체계
|
||||
|
||||
- [ ] **인간 서버 개발자 배정 전에도 원칙·경계·안건까지는 팀장 단독 작성 가능** (S4). 세부 API 스펙은 배정 후 공동 확정
|
||||
- [ ] **Agent 호출 환경 제약 시 "단독 분석 + 관점 분리 표기"** 방식 사용 (C23 정직성 준수, `2026-04-17_RPT_서버역할_정리_초안.md` 작성 주석 참조)
|
||||
- [ ] 서버 인력 합류 시 **선행 Read 패키지 표준화** — 본 아카이브 + 프로젝트 서버 설계 문서 + 관련 feedback 메모리 묶음
|
||||
- [ ] 서버/클라 경계 변경은 **C36 적용 — PD 명시 승인 후에만 변경**. PM 재량 금지
|
||||
|
||||
### 3-D. 운영 기록 채널 (서버팀장 점검보고 B-1 미집행분)
|
||||
|
||||
- [ ] `공유/운영기록/` 하위 `배포/`·`DB_마이그레이션/`·`인시던트/`·`API_변경/` 4종 디렉토리 신설
|
||||
- [ ] 인시던트 기록 템플릿 정의 (탐지·영향·타임라인·조치·근본원인 C2·재발방지)
|
||||
- [ ] API Breaking Change 영향 분석 체크리스트 (P13 구체화)
|
||||
- [ ] PostToolUse·SessionEnd hook 신설 (PM·전 팀장 합의 후)
|
||||
|
||||
---
|
||||
|
||||
## 4. PM 보고 안건 (BurningTimes 조직 차원)
|
||||
|
||||
1. **안건 A — 서버 권위 경계 기본 정책 PD 사전 확정 요청**: EerieVillage 착수 시점에 ① 어뷰징 판정 주체 ② 보상 형태 단일화 여부 ③ 세이브 SOT 기본값 ④ 리셋 시간 기준 4종을 **설계 착수 전 PD 결정 안건**으로 상정. 수잡에서 중반 번복 시 3개 문서 재작성 비용 실증을 근거로 제시.
|
||||
|
||||
2. **안건 B — 보안 Critical 감사 자동화 도입**: dev-auditor 모드 A 감사 체크리스트에 "암호화 키 하드코딩 검출"·"IAP 영수증 검증 호출 주석 감지"·"전투 연산 서버 경로 유무" 3항 추가. 서버 파트 코드 최초 commit 시 자동 발동.
|
||||
|
||||
3. **안건 C — 서버 재개 체크리스트 조직 표준화**: 수잡 서버팀장 점검보고(C 섹션)의 "재개 예비 4종" 및 본 아카이브 3-A~3-D를 **조직 표준 서버 착수 체크리스트**로 정식화 제안. 차기 프로젝트 신규 서버 인력 배정 시 1차 온보딩 자료로 사용.
|
||||
|
||||
4. **안건 D — docx 원본 처리 방침**: `공유/서버_작업_참고자료/2026-04-17_서버_작업_참고자료_v1.2.docx`는 docx 접근 제약으로 본 아카이브 작성 시 미참조. **PM 판단 요청**: (가) `anthropic-skills:docx`로 텍스트 추출 후 본 아카이브 v2 보완 / (나) docx 자체를 조직자산 보존 대상으로 유지 / (다) 둘 다. 본 서버팀장 권장: (다).
|
||||
|
||||
5. **안건 E — EerieVillage 서버 스택 선정 시점**: 수잡 PD-③("PlayFab 유지 vs 하이브리드 vs 자체 서버")은 인간 개발자 배정 후 기술 선호 수렴을 근거로 보류되었음. EerieVillage도 동일 구조로 갈 것인지, 아니면 **서버 스택 사전 확정 후 인력 탐색**인지 PD 방침 확인 필요.
|
||||
|
||||
---
|
||||
|
||||
## 5. 참조 원본 (읽기 전용, 원본 위치 보존)
|
||||
|
||||
- `프로젝트/수상한잡화점/개발/05_서버연동_현황_v1.md` (Critical 3건 + C11 판정 + 우선순위 제안)
|
||||
- `공유/서버_작업_참고자료/2026-04-17_서버_작업_참고자료_v1.2.docx` (docx — 본 아카이브 미참조, 안건 D 참조)
|
||||
- `공유/소통/완료/2026-04-17_서버개발자_업무지시서_최종본.md` (v1.1 요약판, 어뷰징 클라 100% 책임 반영 최종본)
|
||||
- `공유/소통/완료/2026-04-17_RPT_서버역할_정리_초안.md` (서버 역할·경계 매트릭스·PD 안건 5종)
|
||||
- `공유/소통/완료/2026-04-17_어뷰징판정_솔루션_기획서_v1.md` (기각된 서버 경계값 판정 구조 원안 + 기각안 5종)
|
||||
- `공유/소통/완료/2026-04-17_업무공유체계_점검_서버팀.md` (서버팀장 자체 점검보고, 재해복구·hook 공백 포함)
|
||||
- `공유/PD_지시_트래킹/개발팀_PD_지시_로그.md` #2 (서버 Critical 3건 보류 상태)
|
||||
|
||||
---
|
||||
|
||||
**서명**: 개발_서버팀장 (BurningTimes 조직 이관 담당)
|
||||
**아카이브 목적**: 헌법 제1원칙 ② (경험 축적·계승·발전) 준수 — 수상한잡화점 서버 파트 시행착오가 EerieVillage 및 차기 프로젝트에서 재발하지 않도록 조직 자산화
|
||||
**검증 권장**: PM 교차 검토 + dev-auditor 모드 A 1회 + 차기 프로젝트 서버 인력 배정 시 온보딩 필수 Read
|
||||
|
|
@ -0,0 +1,114 @@
|
|||
# 클라이언트팀장 시행착오 아카이브 v1
|
||||
|
||||
> **조직**: BurningTimes (구 NerdNavis 계승)
|
||||
> **담당**: 클라이언트팀장
|
||||
> **대상 원본**: 수상한잡화점 (Unity `6000.0.67f1`, 외부 레포 `FilGoodBandits/DeckBuilding`)
|
||||
> **계승 대상**: EerieVillage (Unity `6000.3.13f1 LTS`, 2D PlatformerMicrogame 템플릿)
|
||||
|
||||
---
|
||||
|
||||
## 1. 개요 — 핵심 교훈 8건
|
||||
|
||||
1. **Unity MCP 편집 = 6단계 표준 불가침**: `apply_text_edits`/`script_apply_edits`는 Read-then-Edit 관성 미발생. SHA→Read→백업→commit→편집→검증
|
||||
2. **Unity 프로젝트는 외부 git 레포**: 조직 레포와 분리. 작업 전 `git fetch && git status` 선행(C30)
|
||||
3. **시뮬레이션은 MCP EditMode가 정답**: Actor.cs 4,545줄 Headless 추출(07안)을 `execute_code` + EditMode로 대체, 이원화 근본 해소
|
||||
4. **핫리로드는 hook 기반 `.live/` 증분 주입**: `@import`·`/compact`·`.claude/rules/`는 세션 중 갱신 불가. UserPromptSubmit hook + SHA1 diff만 유효
|
||||
5. **CLI 병렬은 `--worktree` 격리**: 같은 디렉토리 다중 세션은 덮어쓰기 위험. 연속 작업은 워크트리 강제
|
||||
6. **기획팀 협업 = 실측 교차 검증**: 문서-실체 괴리(GameManager.cs 부재·Spine 추가·Res_Addr 확장·xlsm SOT 이중화)는 정기 실측만 감지
|
||||
7. **Tool 버그 점검은 "점검만" 집행 분리**: 3축 증거 기반 판정. 수정안은 옵션 분리(PD 결정 영역)
|
||||
8. **BT.Framework Tier 1 16/16은 차기부터 적용**: 수상한잡화점 미도입 확정(P29 원칙 A). 범용 패턴 추출만 수행
|
||||
|
||||
---
|
||||
|
||||
## 2. 시도한 방법·이유·결과·교훈
|
||||
|
||||
### 2-1. Unity MCP 편집 표준 워크플로우 (2026-04-20)
|
||||
|
||||
| 시도 | 이유 | 결과 | 교훈 |
|
||||
|------|------|------|------|
|
||||
| #57 A 실측 후 `script_apply_edits` 직접 치환 | PM 프롬프트 "C6-1 백업"은 있었으나 MCP 구체 수단(`manage_script read`→저장) 미명시 | 편집·검증 정상이나 `.bak_*` 분리 누락 → C6-1 위반. 복구 3중(보고서·역방향·undo) 실질 손실 0 | MCP 원자 편집은 Read-then-Edit 관성 미발생. 절차 명문화 불가침 |
|
||||
| C31-B 본문 수정 직접 집행 검토 | Unity MCP 1회성 원본 변형 대응 | 팀장 재량 밖(C36-2 방향·원칙, PD 선행) → C31-G(feedback 선행 Read)로 흡수 | 방향·원칙 변경은 팀장 재량 금지 |
|
||||
| 백업 경로 `공유/개발팀_백업/{프로젝트}/{원본명}.bak_{YYYYMMDD_HHMM}.{확장자}` | PC 독립·git 추적·포맷 통일 | 단일 SOT. 긴급 시 `git stash push -u` | 조직 레포 내 고정. 절대 경로·Unix timestamp 금지 |
|
||||
|
||||
### 2-2. 시뮬레이션 방향 전환 (07 Python 추출 → 11 Unity MCP EditMode)
|
||||
|
||||
| 시도 | 이유 | 결과 | 교훈 |
|
||||
|------|------|------|------|
|
||||
| 07안: BattleCore 도메인 추출 + netstandard2.1 + dotnet CLI | Python-Unity 결과 불일치 해소 + 엔진 완전 분리 | Actor.cs 4,545줄 리팩터링·재빌드 동기화 부담 | 추출 자체가 근본 아님. 두 구현 유지비 0이 정답 |
|
||||
| 11 신안: `execute_code`(EditMode) 주력 + Batch Mode 보조 | Editor 내 C# Eval → Actor.cs 실클래스 호출. stub 7종(`IRandomSource`·`IClock`·`ITickDriver`·`IBattlePresenter`·`ITableLoader` 등) DI | 08/09/10 SOT 100%·07 60% 재활용. "단일 SOT = Unity 프로젝트 자체" | Unity 전제면 EditMode가 결정론·유지비·접근성 3축 우위 |
|
||||
| Python vs Unity MCP 5건 교차 검증 후 아카이브 | Phase 3 HOLD 해제 요건 | 비트 단위 일치 확증 후 HOLD 해제 | 방향 전환 시 병행 검증 필수. 즉시 전환 금지 |
|
||||
|
||||
### 2-3. 핫리로드 대안 → `.live/` 증분 주입 (C34 승격)
|
||||
|
||||
| 시도 | 이유 | 결과 | 교훈 |
|
||||
|------|------|------|------|
|
||||
| PD 원안 CLAUDE_LIVE.md 공용 파일 | 세션 중 갱신·참조 | `@import`·`.claude/rules/`는 세션 시작 1회(A 불가). SessionStart hook은 재시작 시만(C 부분). UserPromptSubmit hook + SHA1 diff만 유효(B) | CLAUDE.md 재읽기는 세션 시작/`/compact`/서브디렉토리 접근 시만. 동적 갱신은 hook 외 불가 |
|
||||
| B+C 혼합: SessionStart 전량 + UserPromptSubmit 변경 감지 | 토큰 최소 + 매 턴 반영 양립 | 변경 없는 턴 0, 변경 시 ~1,200 토큰. 9,500자 이내(10,000자 한도) | C14 실증. 해시 비교가 핵심 |
|
||||
| `.live/` 증분 주입 → C34 헌법급 | worktree 격리로 주입 실패 실증 → 중앙 Junction | 조직 핵심 자산. 설정·규칙·에이전트 9종 대상. PC 내 모든 세션 공유 비용 0 | worktree 경계 끊김은 생존 이슈. 근본 해결(중앙 저장소 + junction) 필수 |
|
||||
|
||||
### 2-4. 콘솔 병렬·하이브리드 구조
|
||||
|
||||
| 시도 | 이유 | 결과 | 교훈 |
|
||||
|------|------|------|------|
|
||||
| CLI 방법 A(같은 디렉토리) | 간단·독립 세션·독립 MCP | 같은 파일 동시 수정 시 덮어쓰기·git 이력 혼란 | 작업 영역 분리 원칙. 세션별 수정 디렉토리 명시 |
|
||||
| CLI 방법 B(`--worktree`) | 독립 파일시스템 복사본 + 독립 브랜치 | 충돌 없음. 완료 후 main merge | 동시 수정 가능성 있으면 워크트리 강제 |
|
||||
| PM에 모든 작업 보고 | C13 완전 준수 | 토큰 폭증·C14 위반·PM 세션 오염 | 이벤트 드리븐. 상태 전환·타 부서 영향·헌법급만 push |
|
||||
| PM 허브 Agent 호출로 부서 전담 | 단일 세션 단순화 | 컨텍스트 단절 — 영속 대화 컨텍스트 무지 | 연속 작업은 PD님 부서 직접 진입. Agent는 조회·단건 한정 |
|
||||
|
||||
### 2-5. Tool_Left 점검·기획팀 협업·BT.Framework
|
||||
|
||||
| 시도 | 이유 | 결과 | 교훈 |
|
||||
|------|------|------|------|
|
||||
| Tool_Left #58 3축 점검(호출 경로·직렬화·스키마) | "버그 유무 판정"만 지시 범위 | 3축 정상. 125 스테이지 중 122건(97.6%) 빈 배열은 2026-04-08 스키마 변경 시 수동 복구 미실행 잔재. #57 A 런타임 자동 복구로 해소 | 점검은 점검만. 수정안은 옵션 분리 |
|
||||
| 기획팀 유니티 교차 검증 | 문서 vs 실체 유효성 | 유효 8·변경 4·확인불가 3. `GameManager.cs` 부재·Spine 추가·Res_Addr 11개·`_Ino.xlsm` 오늘 수정 | 정기 실측 필수 |
|
||||
| BT.Framework Tier 1 16/16 완결 | 차기 조직 자산 | Log·ServiceLocator·CoroutineRunner·MonoSingleton·EventBus·Observable{List,Dict,Queue}·ObjectPool·Factory·DataTable·Attribute3·Util6 + NUnit 28+ | Tier 1은 게임 없이 완결. 2/3은 게임 진행과 축적 |
|
||||
| 수상한잡화점 Framework 도입 | 자체 코어 사용 중 | P29 원칙 A — 미도입. 범용 패턴 추출만 | 신 프레임워크는 차기 출발 시점이 최적 |
|
||||
| 싱글톤 4종 → `MonoSingleton<T>` + 옵션 | 재작성 기회 중복 해소 | `WaitCahe→WaitCache` 수정. `DG.*`→`BurningTimes.*` | 재작성은 오탈자·중복 통합 기회 |
|
||||
|
||||
---
|
||||
|
||||
## 3. BT 착수 시 체크리스트 (EerieVillage·Unity 6000.3.13f1)
|
||||
|
||||
**Unity 작업 전 필수**: `${UNITY_PROJECT_ROOT}` `git fetch && git status` (C30) · `paths.local.json` 경로 등록 · MCP Stdio(6400) 연결 · 표준 워크플로우 6단계 준수
|
||||
|
||||
**Unity MCP 편집 6단계(불가침)**: (1) `get_sha` → (2) `manage_script(read)` → (3) `공유/개발팀_백업/EerieVillage/{원본명}.bak_{YYYYMMDD_HHMM}.{확장자}` 저장 → (4) 백업 commit(긴급 시 `git stash push -u`) → (5) `apply_text_edits`/`script_apply_edits`(`precondition_sha_256` 지정) → (6) SHA 재확인 + `refresh_unity` + `read_console` error 0
|
||||
|
||||
**BT.Framework 도입 배선**: `manifest.json`에 `"com.nerdnavis.framework": "<Gitea URL>#<tag>"`(C안) · Framework 동시 개발자는 로컬 `file:../BT.Framework`(H1) · 2D PlatformerMicrogame 템플릿 샘플은 `EerieVillage/Samples/` 격리 · EventBus·ObservableList·DataTable·ServiceLocator 4종 출발점 배선(§04)
|
||||
|
||||
**시뮬레이션**: `execute_code`(EditMode) 주력·07 Python 추출안 재도입 금지 · `IRandomSource`·`IClock`·`ITickDriver` DI · 동일 시드 비트 단위 동일 결과 검증
|
||||
|
||||
**기획팀 협업 주기 실측**: 산출물 참조 경로·파일 실존·최근 수정일 · xlsm SOT 단일화(이중화 시 즉시 문의) · 스크립트·씬·Res_Addr 변동 감지
|
||||
|
||||
---
|
||||
|
||||
## 4. PM 보고 안건
|
||||
|
||||
- **C31-B 본문 확장 안건 (PD 승인 대기)**: Unity MCP 1회성 원본 변형 집행을 자기검증 명시 대상 추가. C36-2 (a) 해당·팀장 재량 금지. 현 C31-G로 커버. PM 상정 후 PD 승인 시 C36-3로 반영
|
||||
- **표준 워크플로우 확장 검토(차후)**: filesystem·sqlite MCP·외부 레포 직접 편집 적용 여부. 현 시점 Unity MCP 전용 유지. 실증 누적 후 v2·v3 판단
|
||||
- **BT.Framework 차기 도입 경로**: C안(UPM Git URL) + H1(로컬 file:) 배선 확정. Gitea 태그 정책·PD NAS Git 접근 방식 최종 확정. 2D PlatformerMicrogame 템플릿과 공존 방식 설계(Samples 격리)
|
||||
- **Editor 상시 기동 의존**: EditMode `execute_code`는 Unity Editor 기동 + MCP Stdio 전제. 대량 배치(1만+)는 경로 D(BatchMode 병렬) 별도. 재연결 자동화 스크립트 검토
|
||||
- **Unity 전제 정합성**: MCP 방향은 Unity 전제 위 재활용 한정. 비-Unity 엔진 이관 시 재추출 필요. EerieVillage·차차기 Unity 전제 PD 재확인 권고
|
||||
|
||||
---
|
||||
|
||||
## 5. 참조 원본 파일 목록
|
||||
|
||||
**Unity MCP 편집 워크플로우**
|
||||
- `공유/개발팀_자산/Unity_MCP_편집_표준_워크플로우_v1.md`
|
||||
- `공유/소통/개발팀→PM/2026-04-20_C6-1_재발방지_Unity_MCP_워크플로우.md`
|
||||
- `memory/org/feedback_c6_backup_before_edit_violation.md`
|
||||
|
||||
**기술 검토 (2026-04-16~17)**
|
||||
- `공유/소통/완료/2026-04-16_콘솔병렬실행_기술검토_개발팀.md`
|
||||
- `공유/소통/완료/2026-04-16_핫리로드대안_기술검토_개발팀.md`
|
||||
- `공유/소통/완료/2026-04-16_하이브리드구조_개발실의견.md`
|
||||
- `공유/소통/완료/2026-04-16_유니티프로젝트_점검_기획팀.md`
|
||||
- `공유/소통/완료/2026-04-17_Unity_MCP_시뮬레이션_기술검토_개발팀.md`
|
||||
|
||||
**Tool_Left 점검**
|
||||
- `공유/소통/개발팀→PM/2026-04-20_Tool_Left_버그유무_점검.md`
|
||||
|
||||
**BT.Framework 설계**
|
||||
- `프로젝트/코어프레임워크/01_아키텍처_개요_v1.md`·`03_배포방식_안건_v1.md`·`04_Tier1_3종_상호작용_설계_v1.md`
|
||||
|
||||
**대화로그**: `공유/대화로그/코어프레임워크/2026-04-16.md`·`2026-04-17.md`·`2026-04-18.md`
|
||||
|
|
@ -0,0 +1,202 @@
|
|||
---
|
||||
type: 시행착오_아카이브
|
||||
scope: 개발팀_통합
|
||||
author: 개발팀장
|
||||
date: 2026-04-21
|
||||
version: v1
|
||||
project_source: 수상한잡화점 (NerdNavis, 2025-2026)
|
||||
project_target: EerieVillage (BurningTimes, 2026~)
|
||||
---
|
||||
|
||||
# 개발팀 통합 시행착오 아카이브 v1 — 서버·클라이언트·QA 총괄 관점
|
||||
|
||||
## 1. 개요 — 핵심 교훈 10건 요지
|
||||
|
||||
1. **C11(개발 관점 3축) 판정을 기획 요청 수용 전에 반드시 선행한다** — 자원 효율성·코드 직관성·범용성 3축을 통과하지 못하는 설계는 은폐하지 말고 제기(C3).
|
||||
2. **시뮬레이터 이원화(Python vs Unity C#)는 조직 생존급 리스크** — 동일 로직 2언어 유지는 밸런스 신뢰도 붕괴 경로. Unity MCP EditMode 단일 SOT 전환이 근원 해결.
|
||||
3. **서버 Critical 보안 3종(IAP 영수증·AES 하드코딩·클라 전투 연산)은 서비스 오픈 블로커**. 서버팀 가동 전 "보류"로 잠시 미뤘더라도 복원 계획과 메모리 SOT(`project_shop_security_pending.md`)를 반드시 유지.
|
||||
4. **Unity MCP 편집은 6단계 표준 워크플로우(SHA 확보→원본 Read→백업→commit→편집→검증) 없이 진행 금지** — C6-1 원본 보호 재발 방지 단일 SOT.
|
||||
5. **Agent 호출 시 절대 경로 하드코딩 금지 (C34-11)** — worktree 경계를 넘어 main 체크아웃에 변경이 기록되는 실증 사건 재발 방지. `git rev-parse --show-toplevel` 기반 상대 경로.
|
||||
6. **worktree-local 저장 자산은 조직 생존급 위험 (C34-15 5문항 체크)** — `.live/`·`memory/org/`·audit 3종 중앙 Junction 근원 해결. 신규 설정·저장소 설계 시 5문항 체크 통과 의무.
|
||||
7. **코어 프레임워크(BT.Framework)는 현 프로젝트 비투입·조직 자산 계승(P29)** — 수상한잡화점 R&D 자산 경로(`수상한잡화점/개발/06_*`)에 코어 설계 문서를 두면 오인 유발. `프로젝트/코어프레임워크/` 단일 SOT.
|
||||
8. **콘솔 병렬 실행·핫리로드 대안은 기술 검토 없이 결론 금지** — SessionStart/UserPromptSubmit hook 경계, `@import` 구문의 "세션 시작 1회만 확장" 한계 등 Claude Code 내부 메커니즘 실측 선행.
|
||||
9. **서버 권한 분배표를 명시하여 "클라가 SOT인 영역"을 정직하게 기록** — Q-P1·Q-P2·Q-P3 같은 기획 질의에 "클라 코드가 실질 SOT"임을 명시해야 괴리 재발 차단.
|
||||
10. **QA 게이트: Unity 빌드 오류·콘솔 에러 잔존 상태로 작업 종료 금지 (P14)** — 회귀 검증은 동일 경로 재현 포함. "임시로 돌아가는 코드"는 C2·C11 동시 위반.
|
||||
|
||||
---
|
||||
|
||||
## 2. 시도한 방법·이유·결과·교훈 (4필드 표)
|
||||
|
||||
### 2-1. 아키텍처·설계
|
||||
|
||||
| 시도한 방법 | 이유 | 결과 | 교훈 |
|
||||
|------------|------|------|------|
|
||||
| Python 3종 시뮬(`battle_sim`·`full_stage_sim`·`stage_sim_v2`) + Unity C# 실코드 병행 | 기획팀 Python 숙련도·빠른 밸런스 반복 | 메커닉 SOT 불일치(예: `PCDefence_Mul=0.3f` 실측 vs 기획 가정 50%) · 괴리 발견 루프 무한 발생 | Unity MCP EditMode 단일 SOT로 일원화. Python은 참조 구현으로만 존치(동기화 검증 테스트 동반) |
|
||||
| 카드 311장을 개별 스크립트로 구현 시도(초기) | 카드별 특수 효과 구현 편의 | 신규 카드 추가 = 코드 수정 필요 · 시너지 조합 폭증 대응 불가 | 데이터 드리븐 아키텍처 강제(`e_CardType` enum + 파라미터 JSON). "신규 카드가 JSON 한 줄 수정으로 끝나는가?" 핵심 질의 |
|
||||
| 수상한잡화점 내부에 `BurningTimesCore` 네임스페이스 일부 혼재 | 초기 분리 부족 | 프로젝트 특수 로직과 범용 모듈 경계 모호 · 차기 프로젝트 재활용 어려움 | P29 코어 프레임워크 독립 레포(`BT.Framework`) 분리. 수상한잡화점은 비투입, 개발 과정에서 추출 대상만 식별(`02_수상한잡화점_추출대상_v1.md`) |
|
||||
| Tier 1 16종 단일 라운드 일괄 구현 시도 | 빠른 완결 | Data·Event·Container 3종은 상호작용 설계 재검증 필요 · 아키텍처 부채 우려 | 13종 선행 라운드 완결 후 3종을 #36 신규 지시로 분리. 라운드 완결 아카이브 원칙(`feedback_log_round_completion.md`) 정착 |
|
||||
|
||||
### 2-2. 서버·보안
|
||||
|
||||
| 시도한 방법 | 이유 | 결과 | 교훈 |
|
||||
|------------|------|------|------|
|
||||
| PlayFab 주 백엔드 + Firebase 병행 시도 | 분석·크래시 수집 | `google-services.json` 부재 · Firebase 사실상 비활성 | INetworkService 추상화(BurningTimesCore 누락 모듈)로 백엔드 교체 가능 구조 선행 |
|
||||
| 12시간 자동 재로그인 · `ServerInfo.cs` 단일 허브 | 세션 유지 단순화 | 구조 직관성 확보 · 한편 PlayFab 직접 의존 고착 | 허브 패턴은 유지하되 인터페이스 추상화. 교체 시 허브만 재구현 |
|
||||
| 전투 연산 100% 클라이언트 | Unity 내부 연산 편의·초기 속도 | 변조 방어 불가 · 랭킹·이벤트 보상 악용 경로 | 최소한 "스테이지 클리어 판정·보상 지급"은 서버 재연산 필수(P0). 전체 재연산은 점진 확장 |
|
||||
| AES 키 소스 평문 하드코딩 · IL2CPP 의존 | 빌드 난독화 신뢰 | 메모리 덤프로 추출 가능 · 사실상 무의미 | 런타임 유도(디바이스ID 해시 혼합) + 서버 전송 페이로드 HMAC 서명. 키 회전 경로 확보 |
|
||||
| IAP 영수증 검증 주석처리 상태로 방치 | 서버팀 미가동 대기 | 결제 우회 경로 오픈 상태 · 오픈 블로커급 | "보류" 상태에서도 반드시 메모리 SOT(`project_shop_security_pending.md`) + PD 지시 로그 보류 사유·사후 조치 기록(P19). 서버팀 가동 즉시 P0 복원 |
|
||||
| ACTk 약 10개 필드만 `Obscured*` · Detector 미사용 | 초기 최소 적용 | SpeedHack·TimeCheck 방어 공백 | 재화·레벨·카드 보유 수량 전면 `Obscured*` · `SpeedHackDetector`·`TimeCheckDetector` 활성화 |
|
||||
|
||||
### 2-3. 코어 프레임워크(BT.Framework)
|
||||
|
||||
| 시도한 방법 | 이유 | 결과 | 교훈 |
|
||||
|------------|------|------|------|
|
||||
| 코어 설계 문서를 `수상한잡화점/개발/06_*`에 배치 | 작성 편의 | R&D 비투입 방향 확정 후 "수상한잡화점 산출물"로 오인 유발 | `프로젝트/코어프레임워크/01~04` 단일 SOT로 이동·참조 경로 교체. 06은 "대체됨" 표식 |
|
||||
| `Convert.ChangeType` 캐시 방식 Enum 변환 | BCL 표준 | 박싱 발생·핫패스 성능 저하 | `Unsafe.As<,>` 제로-박싱 전환. EnumToInt 단일 SOT |
|
||||
| KeyMaker 구분자 `_` 혼용 | 관례 | 수상한잡화점 `_`/`:` 혼재로 조회 실패 경험 | `:` 단일 표준. 전 프로젝트 강제 |
|
||||
| UnityEngine 의존 허용 시도 (일부 Util) | Unity 편의 | 서버·배치 재사용 불가 · C11 범용성 위반 | Tier 1은 순수 BCL 의존만. Unity 의존 모듈은 별 asmdef 분리 |
|
||||
| CsvHelper 외부 라이브러리 검토 | 파서 완결성 | Tier 1 외부 의존 최소 원칙 위반 · PC 독립 설치 리스크 | RFC 4180 핵심(쉼표·따옴표·escape)만으로 자체 구현. 기획팀 통제 CSV라 충분 |
|
||||
| Newtonsoft.Json 도입 검토 | Dictionary·polymorphism 지원 | PC 독립 설치 보장 어려움 | Unity `JsonUtility` + 래퍼 채택. 한계 명시 후 고급 케이스는 호출자 자체 파싱 경로 안내 |
|
||||
| 3개 모듈(Event·Container·Data) asmdef 분리 검토 | 경계 명확화 | 현 파일 수 규모에서 단일 참조 소비자 경험 우위 | 단일 asmdef 유지. Tier 2 확장 시 재검토 |
|
||||
|
||||
### 2-4. 개발 인프라·운영
|
||||
|
||||
| 시도한 방법 | 이유 | 결과 | 교훈 |
|
||||
|------------|------|------|------|
|
||||
| 같은 디렉토리에서 CLI 여러 개 병렬 실행 | 가장 간단 | 동일 파일 동시 수정 시 덮어쓰기 · git 이력 꼬임 | 서로 다른 파일/영역·읽기 전용에만 허용. 수정 작업은 `--worktree` 격리 |
|
||||
| `CLAUDE_LIVE.md` 핫 리로드 시도 | 세션 중 규칙 반영 | `@import`는 세션 시작 1회만 확장 · 자동 반영 불가 | UserPromptSubmit hook의 `.live/` 증분 주입 경로로 근원 해결(C34) |
|
||||
| `.live/` 더미를 `$REPO_ROOT/.live/`에 저장 | 레포 내부 단순화 | worktree마다 물리 격리 발생 · 세션 간 실시간 공유 실패 | `$HOME/.claude/nerdnavis-live/` 중앙 저장 + worktree junction 연결 (C34-3) |
|
||||
| `memory/org/`를 junction만으로 관리 | 중앙화 편의 | Windows core.symlinks 이슈·한국어 경로 리스크·clone 후 접근 불가 | 레포는 실체 디렉토리 유지 + sync 스크립트 4계층 양방향 동기화 (C34-16) |
|
||||
| Agent 프롬프트에 절대 경로 `E:\...` 지정 | 호출 편의 | worktree 경계 이탈 · main 체크아웃에 파일 생성 실증(2026-04-18) | cwd 기준 상대 경로 의무 + `git -C` 교차 확인 + 경계 이탈 복구 절차 정착 (C34-11) |
|
||||
| 빌드 오류·콘솔 에러 잔존 상태로 PR 머지 | 속도 우선 | 회귀 버그 빈발 · QA 비용 누적 | P14 QA 게이트: 빌드 오류·콘솔 에러 0 원칙. 회귀 검증은 동일 경로 재현 포함 |
|
||||
| git 동기화 Phase 0~4 체계(NAS·post_receive·sync_signal·post-commit hook) | PC 독립 실시간 공유 | 초기 단계에서 경로·권한 이슈 다수 → 점진 안정화 | setup 스크립트 단일 SOT로 PC 독립 셋업 보장(C16). 신 PC 합류 시 `verify_setup` 3축 검증 |
|
||||
|
||||
### 2-5. Agent 경계·대화로그
|
||||
|
||||
| 시도한 방법 | 이유 | 결과 | 교훈 |
|
||||
|------------|------|------|------|
|
||||
| 서브에이전트 인용 응답을 PM이 직접 작성(역할 연기) | 편의 | C23 위반 (2026-04-15 실증) · 조직 신뢰 훼손 | Task 도구 실제 호출 결과만 인용. 미확인 항목은 "미확인" 태그 |
|
||||
| 완료 후 PD 지시 로그 갱신 누락 | 작업 우선 | 다른 세션이 "진행중"으로 오인 (2026-04-16 #27 실증) | C27·C29-4 동기화 4종(PD 로그·대화로그·소통 채널·Live 더미) 동시 수행 |
|
||||
| 설계 문서 참조만 남기고 본문 미작성 | 속도 | "유령 문서" 발생 · P18 위반 | 참조 시점 즉시 작성 착수 또는 "작성 예정(담당·재개 트리거)" 명시 |
|
||||
| 08 전투시스템 SOT와 시뮬레이터 SOT 간 실측값 전파 누락 | 단일 작업만 수행 | #37 완료 후 08이 기획 가정값 유지 · 괴리 재발 위험 | 수치 확정 시 "해당 수치 등장하는 모든 SOT 전수 grep" 완료 체크리스트 편입 |
|
||||
|
||||
---
|
||||
|
||||
## 3. BT 조직 착수 시 체크리스트 (개발팀장 기준)
|
||||
|
||||
### 3-1. 세션 시작 직후 (C10-1·C16-4 연속 이행)
|
||||
- [ ] `git fetch origin && git status` (조직 레포)
|
||||
- [ ] Unity 프로젝트(`${UNITY_PROJECT_ROOT}`) `git fetch && git status` (C30)
|
||||
- [ ] 코어 프레임워크(`BT.Framework`) `git fetch && git status`
|
||||
- [ ] `공유/PD_지시_트래킹/개발팀_PD_지시_로그.md` 활성 테이블 전수 Read
|
||||
- [ ] `공유/대화로그/EerieVillage/` 최근 2일 Read + `공유/대화로그/코어프레임워크/` 최근 2일 Read
|
||||
|
||||
### 3-2. 신규 기능·시스템 설계 착수 전
|
||||
- [ ] C11 3축 판정 (자원 효율성·코드 직관성·범용성) 자문
|
||||
- [ ] "신규 {카드·적·아이템·이벤트} 추가가 JSON 한 줄로 끝나는가?" 데이터 드리븐 성립 확인
|
||||
- [ ] 프로젝트 특수 vs 범용 모듈 경계 명시 (범용은 BT.Framework 추출 대상 식별)
|
||||
- [ ] P18 설계 문서 선행 작성 (배경·대안·구현 가이드·검증 방법·변경 이력 5요소)
|
||||
- [ ] 기획 요청이 C11과 충돌하면 C3에 따라 우려 즉시 제기
|
||||
|
||||
### 3-3. Unity 코드·씬·프리팹 편집 전
|
||||
- [ ] Unity MCP 편집 대상이면 6단계 표준 워크플로우(`공유/개발팀_자산/Unity_MCP_편집_표준_워크플로우_v1.md`) 준수
|
||||
- [ ] 백업 파일: `공유/개발팀_백업/EerieVillage/{원본}.bak_{YYYYMMDD_HHMM}.{ext}`
|
||||
- [ ] `precondition_sha_256` 파라미터로 외부 변경 방어
|
||||
- [ ] 편집 후 `get_sha` 재확인 + 콘솔 에러 0 검증
|
||||
|
||||
### 3-4. 서버 연동 작업 전
|
||||
- [ ] 전투·재화·IAP·랭킹·보상 중 어느 영역인지 식별
|
||||
- [ ] 해당 영역의 서버 권한 vs 클라 권한 표 갱신
|
||||
- [ ] Critical 보안 3종(IAP 영수증·암호화 키·전투 연산) 재발 여부 체크
|
||||
- [ ] 신 프로젝트는 백엔드 추상화(INetworkService) 선행 — PlayFab 직접 의존 금지
|
||||
|
||||
### 3-5. Agent 호출·worktree 작업 전
|
||||
- [ ] Agent 프롬프트에 "cwd 기준 상대 경로 사용 의무" 명시 (C34-11)
|
||||
- [ ] 산출물 경로는 `$(git rev-parse --show-toplevel)` 기준 또는 상대 경로
|
||||
- [ ] Agent 응답 수령 직후 `git -C <레포루트> status` + 본 worktree `git status` 병행 확인
|
||||
- [ ] 신규 공용 저장소·hook·설정 도입 시 C34-15 worktree 경계 5문항 체크 통과
|
||||
|
||||
### 3-6. 작업 완료 시 (C29-4 동기화 4종)
|
||||
- [ ] `공유/PD_지시_트래킹/개발팀_PD_지시_로그.md` 상태 갱신 (완료 아카이브 즉시 이동 + 즉답 접두)
|
||||
- [ ] `공유/대화로그/{프로젝트}/YYYY-MM-DD.md` 엔트리 추가 (결정·설계는 "기각안" 필드 필수)
|
||||
- [ ] 소통 채널 응답서 `status: 완료` + `공유/소통/완료/`로 이동
|
||||
- [ ] `.live/` 더미 기록 (세션 갱신 전 즉시 트래킹)
|
||||
- [ ] 수치·SOT 변경 시 "해당 수치 등장 모든 SOT 전수 grep" 수행 (#37 누락 재발 방지)
|
||||
|
||||
---
|
||||
|
||||
## 4. PM 보고 안건 (특이사항)
|
||||
|
||||
1. **서버 Critical 보안 3종 복원 계획 수립** — 신 프로젝트 EerieVillage의 서버팀 가동 시점에 수상한잡화점 보류분 3종(IAP·AES·전투 연산)의 복원 전략을 PD님께 사전 보고. 메모리 SOT `project_shop_security_pending.md` 계승 여부도 결정 필요.
|
||||
|
||||
2. **코어 프레임워크 Tier 2·3 진입 경계 확정** — Tier 1 16/16 완료 시점에서 Tier 2(Network·Persistence·UI 공용)·Tier 3(게임 장르별) 진입 조건을 EerieVillage 요구사항과 연계하여 PD님 결정 안건화. P29 "현 프로젝트 미활용·차기 프로젝트 적극 활용" 원칙 적용.
|
||||
|
||||
3. **Unity MCP 편집 표준 워크플로우 v1 EerieVillage 적용 범위 확정** — BT.Framework 편집은 명시 적용. Unity 씬·프리팹(비스크립트)은 현 버전 미포함. v2 확장 여부 PD 결정.
|
||||
|
||||
4. **시뮬레이터 이원화 재발 방지** — EerieVillage는 착수 시점부터 "Unity MCP EditMode 단일 SOT" 확정. Python 시뮬은 참조 구현으로만 허용하되 자동 동기화 검증 테스트 의무화를 PD 승인 안건화.
|
||||
|
||||
5. **PC 독립 셋업 신 PC 합류 프로토콜** — 신 스태프·신 PC 추가 시 `setup_windows.ps1`·`setup_macos.sh` + `verify_setup` 3축 검증 의무. 실패 시 Degraded 운영이 아닌 조직공지 이슈화.
|
||||
|
||||
6. **dev-auditor 모드 A(중요 기술 결정)·모드 B(주기 감사) 운영 정착** — 3축 감사 체계 중 개발 영역 감사가 실무 정착 초기 단계. EerieVillage 착수 초반에 모드 A 호출 빈도를 높여 학습 데이터 축적.
|
||||
|
||||
---
|
||||
|
||||
## 5. 참조 원본 파일 목록 (감사 재현 가능)
|
||||
|
||||
### 5-1. 수상한잡화점 개발 산출물
|
||||
- `프로젝트/수상한잡화점/개발/01_기획실_인수인계_v1.md`
|
||||
- `프로젝트/수상한잡화점/개발/02_개발자관점_점검_v1.md`
|
||||
- `프로젝트/수상한잡화점/개발/03_Unity프로젝트_구조_v1.md`
|
||||
- `프로젝트/수상한잡화점/개발/04_코어_범용성_분석_v1.md`
|
||||
- `프로젝트/수상한잡화점/개발/05_서버연동_현황_v1.md`
|
||||
- `프로젝트/수상한잡화점/개발/06_신규코어_설계안_v1.md` (대체됨 → `프로젝트/코어프레임워크/01~04`)
|
||||
- `프로젝트/수상한잡화점/개발/07~13_*.md` (Phase 3 재개 로드맵 포함)
|
||||
|
||||
### 5-2. 코어 프레임워크 (BT.Framework)
|
||||
- `프로젝트/코어프레임워크/01_아키텍처_개요_v1.md`
|
||||
- `프로젝트/코어프레임워크/02_수상한잡화점_추출대상_v1.md` (완료 실적 아카이브)
|
||||
- `프로젝트/코어프레임워크/03_배포방식_안건_v1.md`
|
||||
- `프로젝트/코어프레임워크/04_Tier1_3종_상호작용_설계_v1.md`
|
||||
- `코어코드/BT.Framework/Runtime/Core/` 전체
|
||||
|
||||
### 5-3. 대화로그
|
||||
- `공유/대화로그/코어프레임워크/2026-04-16.md`
|
||||
- `공유/대화로그/코어프레임워크/2026-04-17.md`
|
||||
- `공유/대화로그/코어프레임워크/2026-04-18.md`
|
||||
|
||||
### 5-4. 소통 채널 (완료)
|
||||
- `공유/소통/완료/2026-04-16_콘솔병렬실행_기술검토_개발팀.md`
|
||||
- `공유/소통/완료/2026-04-16_핫리로드대안_기술검토_개발팀.md`
|
||||
- `공유/소통/완료/2026-04-16_하이브리드구조_개발실의견.md`
|
||||
- `공유/소통/완료/2026-04-16_코어코드_git통합_점검_개발팀.md`
|
||||
- `공유/소통/완료/2026-04-16_유니티프로젝트_점검_기획팀.md`
|
||||
- `공유/소통/완료/2026-04-17_RPT_서버역할_정리_초안.md`
|
||||
- `공유/소통/완료/2026-04-17_서버_작업_참고자료.md`
|
||||
- `공유/소통/완료/2026-04-17_서버개발자_업무지시서_최종본.md`
|
||||
- `공유/소통/완료/2026-04-17_업무공유체계_점검_서버팀.md`
|
||||
|
||||
### 5-5. 개발팀→PM 자체 감사·검토
|
||||
- `공유/소통/개발팀→PM/2026-04-17_전수감사_자체교차검증_개발팀장관점.md`
|
||||
- `공유/소통/개발팀→PM/2026-04-18_worktree_격리_근원해결_실무검토.md`
|
||||
- `공유/소통/개발팀→PM/2026-04-20_C6-1_재발방지_Unity_MCP_워크플로우.md`
|
||||
- `공유/소통/개발팀→PM/2026-04-20_Tool_Left_버그유무_점검.md`
|
||||
- `공유/소통/개발팀→PM/2026-04-20_몬스터_미등장_A_집행완료.md`
|
||||
|
||||
### 5-6. 조직 자산·표준 워크플로우
|
||||
- `공유/개발팀_자산/Unity_MCP_편집_표준_워크플로우_v1.md`
|
||||
- `공유/서버_작업_참고자료/2026-04-17_서버_작업_참고자료_v1.2.docx` (접근 가능 시)
|
||||
- `공유/개발팀_백업/` (원본 백업 SOT)
|
||||
|
||||
### 5-7. feedback 메모리 (재발 방지 SOT)
|
||||
- `memory/org/feedback_agent_path_boundary.md` — Agent 절대 경로 유출 실증
|
||||
- `memory/org/feedback_worktree_isolation.md` — worktree 격리 5문항 체크
|
||||
- `memory/org/feedback_git_scope_shortcut.md`
|
||||
- `memory/org/feedback_dev_auditor_*.md` — 개발 감사 실증
|
||||
- `memory/org/feedback_memory_sync_overwrite.md` — memory sync 덮어쓰기 실증
|
||||
- `memory/org/feedback_c6_backup_before_edit_violation.md` — Unity MCP 편집 백업 누락
|
||||
- `memory/org/feedback_log_round_completion.md` — 라운드 완결 아카이브 원칙
|
||||
- `project_shop_security_pending.md` — Critical 3종 보류 SOT
|
||||
|
||||
---
|
||||
|
||||
*본 아카이브는 BurningTimes 조직이 EerieVillage 및 차기 프로젝트 착수 시 동일한 시행착오를 반복하지 않고 검증된 방법을 재활용하기 위한 개발팀 통합 관점 SOT이다. PD 지시 2026-04-21 "조직 자산 계승" 이행 산출물.*
|
||||
|
|
@ -0,0 +1,278 @@
|
|||
# 수상한잡화점 밸런스 기획 시행착오 아카이브 v1
|
||||
|
||||
> **조직**: NerdNavis → BurningTimes 전환 기점 추출
|
||||
> **대상 프로젝트**: 수상한잡화점 (2D 덱빌딩 로그라이트)
|
||||
> **차기 프로젝트**: EerieVillage (2D 플랫포머 퇴마)
|
||||
> **추출일**: 2026-04-20
|
||||
> **추출자**: 밸런스 기획자 (balance-designer)
|
||||
> **데이터 소스 실측**: 참조 원본 직접 Read 기반 (C23 준수 — 추정·역할연기 없음)
|
||||
|
||||
---
|
||||
|
||||
## §1. 데이터 파싱 오해 — 퍼센트값·음수값 해석 실증
|
||||
|
||||
### §1-1. 각성트리 퍼센트값 오해 경위
|
||||
|
||||
**발생 시점**: Phase 3 성장 요소 기여도 분석 중 (2026-04-14 REQ001 기획팀 → 개발팀)
|
||||
|
||||
**오해 내용**: `PCAwakening.json` 테이블에서 `s_Value='500%'` 형식이 `s_Value='5'`와 혼재. 기획팀은 `'500%'`를 "기존 스탯의 500% 배율 적용"으로 해석하여 **각성 만렙 시 DPS +1067% / EHP +197%** 라는 비정상 수치를 산출했다.
|
||||
|
||||
**실제 동작**: `table_base.cs` `Get_Value()` 메서드가 `%` 포함 문자열을 `float * 0.01f`로 파싱. 즉 `'500%'` = `500 × 0.01 = 5.0f` = `'5'`와 동일한 고정값. 배율 적용이 아님.
|
||||
|
||||
```
|
||||
// 실제 파싱 로직 (REQ001 응답 코드 근거)
|
||||
if (IsPercentValue(str)) return float.Parse(str.Replace("%", "")) * 0.01f;
|
||||
```
|
||||
|
||||
**만렙 효과 재계산**: `s_Value='500%'`, `s_UpgradeStatValuePara='100%'`, `n_MaxLv=5` 기준
|
||||
- 기획팀 추정: `500% + 100% × 4 = 900%` (배율 해석 오류)
|
||||
- 실제 결과: `5.0 + 1.0 × 4 = +9` (고정값 가산)
|
||||
|
||||
**정정 방법**:
|
||||
1. 개발팀에 REQ 발행 → 코드 레벨 파싱 로직 확인 요청
|
||||
2. 확인 후 기여도 문서 수치 전면 재계산
|
||||
3. 데이터 입력 형식 통일 권고 (런타임 동작은 정상이나 가독성 문제)
|
||||
|
||||
**차기 프로젝트 EerieVillage 적용 원칙**: 수치 테이블의 문자열 포맷(`%`, `s`, `exp` 등)이 런타임 파싱 로직에 따라 전혀 다른 결과를 낼 수 있다. **밸런스 시트 작성 전 반드시 파싱 함수 코드를 개발팀과 공유·확인**한다. 특히 동일 컬럼 내 혼재 포맷은 오해 위험이 높다.
|
||||
|
||||
---
|
||||
|
||||
### §1-2. 장비 옵션 음수값 — 디버프 의도 명확화
|
||||
|
||||
**발생 시점**: Phase 3 성장 요소 기여도 분석 중 (2026-04-14 REQ002 기획팀 → 개발팀)
|
||||
|
||||
**발견 내용**: 8부위 풀셋 장착 시뮬에서 `CriDmg -20%`, `Avoid_Melee -3%`, `HitRate -2` 등 음수 값이 합산. 기획팀은 오류 가능성을 제기.
|
||||
|
||||
**실제 의미**: 의도적 트레이드오프 설계. 무기 `MainOption2`가 페널티성 옵션을 고정 보유하는 구조.
|
||||
|
||||
| 패턴 | 사례 | 밸런스 의도 |
|
||||
|------|------|------------|
|
||||
| 무기 고공격력 + 치명타 피해 페널티 | ATK 강화 대신 CriDmg -20% | 딜러 빌드 트레이드오프 |
|
||||
| 쿨타임 음수 = 보너스 | `AttackCoolTime -3%` = 공속 +3% 증가 | 스탯명 방향성 주의 |
|
||||
| 강화로도 완화되지 않는 고정 페널티 | `UpgradeStatValuePara = 0` | 성장해도 단점 유지 |
|
||||
| 세트 옵션 양수/음수 쌍 | HP -10% + 보호막 +10% | 빌드 방향 차별화 |
|
||||
|
||||
**핵심 교훈**: `AttackCoolTime -3%`처럼 **스탯명의 방향성**이 음수값 해석을 역전시키는 사례가 존재한다. 쿨타임 감소 = DPS 증가. 밸런스 계산 시 스탯 의미와 음수 방향을 함께 명시해야 한다.
|
||||
|
||||
**차기 프로젝트 EerieVillage 적용 원칙**: 장비·스킬 옵션의 음수값이 "오류"인지 "의도된 페널티"인지는 반드시 설계 문서에 명시한다. 특히 "방향성이 역전되는 스탯(쿨타임·캐스팅타임 등)"은 별도 명세표를 작성한다. DPS/EHP 계산 시 이 방향성 역전을 반영하지 않으면 수치가 왜곡된다.
|
||||
|
||||
---
|
||||
|
||||
## §2. 어뷰징 판정 임계값 설계 — 서버 이관 원칙
|
||||
|
||||
**출처**: `공유/소통/완료/2026-04-17_어뷰징판정_솔루션_기획서_v1.md`
|
||||
|
||||
### §2-1. 설계 전제 (재미 우선 원칙 P30 연계)
|
||||
|
||||
어뷰징 판정은 "어뷰저를 잡는 것"이 목표가 아니라 **"정직한 플레이어의 재미를 보호"**하는 것이 목표다. 이 전제가 임계값 설계의 모든 수치를 결정한다.
|
||||
|
||||
- **false positive 최소화**: 정상 유저를 어뷰저로 오판정하면 성취 경험이 훼손된다. 이것이 C7 재미 우선 원칙 위반이다.
|
||||
- **안전 마진의 존재 이유**: 프레임 드랍, 클라 시계 오차, 반올림 오차 — 이 기술적 노이즈가 정상 유저를 "경계 초과"로 만드는 구조를 막기 위해 마진이 필요하다.
|
||||
|
||||
### §2-2. 임계값 도출 공식
|
||||
|
||||
```
|
||||
경계값 = 시뮬_이론_극값 × 안전마진계수
|
||||
```
|
||||
|
||||
시뮬 이론 극값은 10,000회 이상 반복 시뮬레이션의 상위/하위 0.1% 값을 채택한다. **절대 최대/최소가 아닌** 이유: 시뮬 자체 오차 흡수.
|
||||
|
||||
| 벡터 특성 | 마진 방향 | 계수 | 근거 |
|
||||
|---------|--------|-----|------|
|
||||
| 클리어타임 (짧을수록 의심) | 하한 = 이론 최단 × 0.80 | 0.80 | 클라 시계 오차 15% 흡수 |
|
||||
| 획득 재화 (많을수록 의심) | 상한 = 이론 최대 × 1.05 | 1.05 | 반올림·버프 중첩 케이스 흡수 |
|
||||
| 랭킹 점수 (높을수록 의심) | 상한 = 이론 최대 × 1.10 | 1.10 | 신규 카드 출시 과도기 흡수 |
|
||||
| 피격 수 (적을수록 의심) | 하한 = 0 (음수만 차단) | — | 0회도 이론상 가능 |
|
||||
| 미션 카운트 | 상한 = 일일 최대 × 1.00 | 1.00 | 마진 불필요 (정수 카운트) |
|
||||
|
||||
**"안전 마진 0%" 기각 근거**: 시뮬 극값 그대로 경계값으로 쓰면 false positive 폭발. 정상 유저도 매번 플래그됨. **재미 원칙 위반.**
|
||||
|
||||
### §2-3. 플래그 3단계 — 어뷰저 학습 방지와 false positive 보호 균형
|
||||
|
||||
| 단계 | 트리거 | 클라 응답 | 자동 조치 |
|
||||
|-----|-------|---------|---------|
|
||||
| F1 경미 | 경계값 +5~10% 초과 | 없음 (무감지) | 플래그 기록만 |
|
||||
| F2 중대 | +10~50% 초과 또는 F1×3 | "서버 동기화 오류" | 보상 보류 + 알림 |
|
||||
| F3 확정 | +50% 초과 또는 논리 모순 | "blocked" | 보상 미지급 + 계정 플래그 |
|
||||
|
||||
F1에서 클라에게 경고를 노출하지 않는 이유: 어뷰저가 경계값을 학습하지 못하도록 막기 위함.
|
||||
|
||||
### §2-4. 기각안 (검토했으나 채택 안 한 방법론)
|
||||
|
||||
1. **서버 단독 시뮬 재현 검증**: 서버가 클라 입력을 받아 전투 재시뮬 → 기각. CPU 비용 폭증 + 부동소수점 동기화 이슈. 싱글플레이 구조에 과잉 투자.
|
||||
2. **머신러닝 이상치 탐지**: 학습 데이터 축적 전 초기 출시 대응 불가. 장기 보조 수단으로만 검토.
|
||||
3. **클라 단독 판정**: 메모리 조작으로 즉시 무력화. 원천 제외.
|
||||
4. **안전 마진 0% 엄격 검증**: false positive 폭발 → 재미 원칙 위반으로 기각.
|
||||
|
||||
### §2-5. ★조건 교차 검증 (P17 배타 배치 연계)
|
||||
|
||||
서버 검증에 기획팀이 정의한 ★조건을 포함시켜야 어뷰저가 "달성 못 한 ★조건을 클리어한 것처럼" 위조하는 AV-4 벡터를 막을 수 있다.
|
||||
|
||||
```json
|
||||
"starConditions": {
|
||||
"C6": { "field": "potionUsed", "operator": "==", "value": 0 },
|
||||
"N2": { "field": "hitsTaken", "operator": "<=", "formula": "subMapCount * 1" }
|
||||
}
|
||||
```
|
||||
|
||||
★조건 통과 보고와 필드값이 모순되면 F3 확정 (논리 모순 범주).
|
||||
|
||||
**차기 프로젝트 EerieVillage 적용 원칙**: 퇴마 클리어 보상·퍼펙트 클리어 인증 등 서버 검증이 필요한 성취 체계가 있다면, 기획팀이 "이론 극값 산정 방법론 + ★조건 검증 규칙"을 서버 개발팀에 제공하는 역할 분담을 사전에 확정한다. 경계값 수치는 시뮬 가동 후 채우는 구조로 설계 틀을 먼저 확정하면 개발팀과 병렬 진행 가능하다.
|
||||
|
||||
---
|
||||
|
||||
## §3. Day 11~14 밸런스축 본작업 — TTK 기반 난이도 곡선 체계
|
||||
|
||||
**출처**: `공유/소통/기획팀→PM/2026-04-20_Day11-14_밸런스축_본작업_v1.md`
|
||||
|
||||
### §3-1. 설계 전제 확정 방식 (앵커 포인트 접근법)
|
||||
|
||||
밸런스 수치는 전체를 동시에 잡으려 하지 않고 **앵커 포인트(기준점) 1개를 먼저 고정**한 뒤, 그 기준에서 각 요소의 기여도를 순차 측정하는 방식으로 진행했다.
|
||||
|
||||
| 기준 | 값 | 출처 |
|
||||
|------|---|------|
|
||||
| 앵커 DPS | 1.05 | Phase 0 전투 시뮬 실측 |
|
||||
| 앵커 TTK | 5.7s | Phase 0 실측 |
|
||||
| 앵커 EHP | 64 | Phase 0 실측 |
|
||||
| G1 풀빌드 실전 DPS | 5.24 | Phase 3 실측 (UTF 14/14 Passed) |
|
||||
| 장비 세트 완성 기여 | +71.46% | Phase 3 실측 (±0.86% 오차) |
|
||||
|
||||
### §3-2. TTK를 "재미"로 번역하는 방법
|
||||
|
||||
**재미 정의 선행**: Stage 11~15 = "장비를 맞추기 시작해야 안정적으로 클리어되는 중반 구간." 이 재미 정의가 TTK 목표를 결정한다.
|
||||
|
||||
- 카드 단독 DPS(5.24)로 타이트 또는 클리어 곤란 → 장비 투자 동기 부여
|
||||
- 장비 세트 완성(DPS 8.98)으로 TTK 24~45초 범위 → 긴장감 있되 클리어 가능
|
||||
- ★1 클리어 TTK 목표: 장비 세트 결합 후 **20~35초 (보스 1체 기준)**
|
||||
|
||||
**공식**:
|
||||
```
|
||||
TTK (카드+세트) = HP + Shield 합산 / DPS_세트결합
|
||||
DPS_세트결합 = 5.24 × 1.7146 = 8.98
|
||||
```
|
||||
|
||||
주의: Shield는 직접 감소 방식 (방어력 계수 적용 없음). HP는 방어력 계수 적용.
|
||||
|
||||
### §3-3. Stage별 검증 결과 요약
|
||||
|
||||
| Stage | HP+Shield 합산 | 세트결합 TTK | C9 가능 | 핵심 주의사항 |
|
||||
|-------|--------------|------------|---------|-------------|
|
||||
| 11 | 313.5 (+42%) | 24.6~45.2s | 가능 | 흡혈귀여왕2 Shield 급등 — 의도 설계 |
|
||||
| 12 | 289.0 (-7.8%) | 17.6~45.2s | 최적합 | C2∧N2 동시 배치 회피 권고 |
|
||||
| 13 | 253.0 (-12.5%) | 28.2s | **금지** | 단독 보스 — P17 배타 #5 C9 불가 |
|
||||
| 14 | 300.5 (+18.7%) | 28.2~38.8s | 가능 | N4∧C6 동시 배치 주의 (P17 #3) |
|
||||
| 15 | 308.5 (+2.7%) | 30.0~38.8s | 가능 | 흑기사1 ATK Max 45 — C2∧N2 금지 (P17 #1) |
|
||||
|
||||
**고Shield 보스 패턴**: 흡혈귀여왕2(Shield 315), 메두사2(Shield 230)는 세트+각성 결합 기준에서도 35~45초 영역. 이 구간은 "추가 성장 요소(각성·진화) 투자 동기 부여" 의도로 설계됨.
|
||||
|
||||
### §3-4. 성장 단계별 DPS 조합표 (EerieVillage 설계 참조용)
|
||||
|
||||
| 성장 조합 | DPS 배율 | 해당 Stage 11 보스 TTK |
|
||||
|---------|---------|-------------------|
|
||||
| 카드 단독 | ×1.00 | 42.2s (클리어 곤란) |
|
||||
| 카드 + 일반장비 | ×1.30 | 32.5s |
|
||||
| 카드 + 세트완성 | ×1.71 | 24.6s (적정) |
|
||||
| 카드 + 세트 + 각성 1.50 | ×2.57 | 16.4s (쾌적) |
|
||||
| 카드 + 세트 + 각성 + 진화 1.40 | ×3.59 | 11.7s (매우 쾌적) |
|
||||
|
||||
이 테이블 구조는 "각 성장 요소가 클리어 경험을 어떻게 바꾸는가"를 수치로 직접 보여준다. 재미 설계의 수치 번역 예시로 활용 가능.
|
||||
|
||||
---
|
||||
|
||||
## §4. 밸런스 자산 변경 전 백업 및 버전 관리 (C6-1 실무)
|
||||
|
||||
### §4-1. 백업 포맷 표준
|
||||
|
||||
수치 밸런스 파일(xlsm·csv·json) 변경 전 반드시 다음 포맷으로 백업한다.
|
||||
|
||||
```
|
||||
{원본명}.bak_{YYYYMMDD_HHMM}.{확장자}
|
||||
예: PCAwakening.bak_20260420_1430.json
|
||||
```
|
||||
|
||||
**금지 형식**: `.bak-*` (하이픈), Unix timestamp, 버전 번호 단독 (`_v1.bak`).
|
||||
|
||||
### §4-2. 경계값 테이블 버전 관리
|
||||
|
||||
어뷰징 판정 경계값 테이블은 게임 밸런스 패치마다 갱신이 필요하다. 이때:
|
||||
|
||||
1. **정기 갱신**: 카드 수치 변경·신규 몬스터 추가 시 해당 영역 시뮬 재실행
|
||||
2. **긴급 갱신**: 어뷰징 신고 접수 또는 랭킹 이상치 감지 시 즉시 재실행
|
||||
3. **버전 관리**: `boundary_table.bak_YYYYMMDD_HHMM.json` 백업 후 교체
|
||||
4. **변경 이력**: PD 지시 로그·대화로그에 기각안 포함 기록 (P16 산출물 추적성)
|
||||
|
||||
### §4-3. 변경 이력 테이블 필수 항목
|
||||
|
||||
밸런스 파일 하단에 다음 형식으로 기록한다.
|
||||
|
||||
| 일시 | 변경자 | 변경 필드 | 이전값 → 이후값 | 재미 근거 | 관련 PD 지시# |
|
||||
|------|--------|----------|----------------|----------|--------------|
|
||||
|
||||
**"재미 근거" 컬럼이 공란이면 수치 조정 금지**: 어떤 재미를 강화하는지 먼저 정의하지 않은 수치 조정은 P30 위반이다.
|
||||
|
||||
### §4-4. JSON/CSV SOT 맹신 금지 (기획팀 데이터 실측 의무 v1 §1-4)
|
||||
|
||||
**실증 사건**: `스테이지난이도곡선_v1.md §1`에 "WorldMap_1~4 4개 그룹"이라는 표현이 기획 문서 SOT처럼 인용·전파되어, Phase 4 지역 1 전체를 "Stage 1~6 = 지역 1 = 6개"로 설계하는 오류가 발생했다. 실제 데이터는 **21개 구역 × 각 4개 하위 스테이지 = 총 122 스테이지**였다.
|
||||
|
||||
**재발 방지 원칙**:
|
||||
- 기획 문서의 수치·구조를 **무비판 수용 금지**
|
||||
- Unity Export CSV/JSON 직접 실측 선행 의무
|
||||
- 기획 문서 상단에 "데이터 소스 실측 일시" 필드 명기 필수
|
||||
- 실측 일시 미기입 문서는 참조 금지 (참조 시 실측 재수행)
|
||||
|
||||
**수치 검증 체계**: 모든 DPS·TTK 계산은 Unity 실측 데이터 기반이어야 하며, "UTF N/N Passed" 형식으로 검증 통과 여부를 기록한다.
|
||||
|
||||
---
|
||||
|
||||
## §5. 수치 설계 원칙 — EerieVillage 이관 핵심
|
||||
|
||||
### §5-1. 재미 정의 없는 수치 조정 금지 (P30 실무)
|
||||
|
||||
수상한잡화점에서 모든 밸런스 변경 제안은 "어떤 재미를 강화하는가"를 먼저 정의했다. 대표 사례:
|
||||
|
||||
- **어뷰징 안전 마진 0% 기각**: 이유는 기술적 정확성이 아니라 "false positive가 정상 플레이어 경험을 훼손한다"는 재미 관점이었다.
|
||||
- **이슈 1 현 수치 고정 결정**: G1 풀빌드 DPS +200~280%가 목표 +80~120% 대비 2배 초과이나, 수치 재조정보다 HP·TTK 설계가 현 DPS를 반영한 상태로 일관성을 유지하는 것이 재미 경험 보전에 유리하다고 판단.
|
||||
- **Stage 10→11 내구도 +42% 급등**: 오류가 아닌 "장비 투자 동기 부여"라는 재미 의도 설계임을 TTK 수치로 확인.
|
||||
|
||||
### §5-2. 어뷰징 임계값과 재미의 교점
|
||||
|
||||
어뷰징 판정 기준을 너무 엄격하게 잡으면 실력 있는 정상 유저를 차단하게 된다. 이것은 **재미 설계 실패**다. 임계값 설계는 밸런스 기획자가 개입해야 하는 영역이다.
|
||||
|
||||
안전 마진 계수(0.80·1.05·1.10 등)는 "기술적으로 합당한 오차 범위"가 아니라 **"이 오차 범위 안에 있는 유저는 재미있게 플레이하고 있는 정상 유저"**라는 재미 판단이 선행된 수치다.
|
||||
|
||||
### §5-3. P17 배타 배치 체계의 의미
|
||||
|
||||
★조건 배타 7종(P17)은 단순한 기술적 제약이 아니다. 각 배타 조합이 금지된 이유는 **"그 조합이 플레이어에게 이중·삼중 부담을 주어 재미를 손상시키기 때문"**이다.
|
||||
|
||||
| 배타 조합 | 재미 손상 이유 |
|
||||
|----------|------------|
|
||||
| C2∧N2 (완벽 클리어 + 피격 제한) | 피격 최소화 부담을 두 방향에서 동시 부과 — 스트레스 빌드 |
|
||||
| C6∧N4 (포션 절제 + 쉴드 하한) | 회복 빌드 외 빌드 선택지 전면 배제 — 다양성 파괴 |
|
||||
| N5∧N6 (후열 선공 + 전열 선공) | 타겟팅 자유도 박탈 + 논리 모순 — 달성 불가 조건 |
|
||||
|
||||
EerieVillage에서 유사한 "달성 조건" 체계를 설계할 때, 각 조건 쌍의 **재미 충돌 여부**를 먼저 검토한다.
|
||||
|
||||
### §5-4. 드랍률·확률 설계 교훈
|
||||
|
||||
수상한잡화점 드래프트 확률:
|
||||
- G1(일반) 66.2%, G2 19.9%, G3 9.9%, G4 3.3%, G5 0.66%
|
||||
|
||||
**핵심 교훈**:
|
||||
- G5 물약 카드 등장 확률 = 0.66% × (G5 중 물약 비율) ≈ **~0.15%** → "나오면 기적" 수준
|
||||
- 이 확률에서 "물약 빌드"는 설계 의도와 달리 사실상 형성 불가능한 빌드가 되어버림
|
||||
- **빌드 형성에 필요한 핵심 카드 등장 확률**을 역산해서 "1런에 빌드 시작이 가능한 최소 확률"을 별도로 검증해야 한다
|
||||
- 확률 표기는 분수·백분율 동시 기재: G5 = 10/1510 ≈ 0.66%
|
||||
|
||||
EerieVillage에서 "퇴마 도구" 드랍 풀 설계 시 동일한 검증이 필요하다.
|
||||
|
||||
---
|
||||
|
||||
## 변경 이력 (P16 산출물 추적성)
|
||||
|
||||
| 일시 | 변경자 | 변경 내역 | 재미 근거 | 관련 지시 |
|
||||
|------|--------|----------|----------|---------|
|
||||
| 2026-04-20 | 밸런스 기획자 (balance-designer) | 전체 신설 — NerdNavis 수상한잡화점 밸런스 시행착오 5섹션 추출 | BurningTimes EerieVillage 밸런스 설계 품질 향상 | BurningTimes 조직 전환 기점 자산 추출 |
|
||||
|
||||
---
|
||||
|
||||
*참조 원본: REQ001·REQ002 기획팀→개발팀 소통 (2026-04-14·16) / 어뷰징판정솔루션 기획서 v1 (2026-04-17) / Day11-14 밸런스축 본작업 v1 (2026-04-20) / 대화로그 수상한잡화점 2026-04-20 / 기획팀 데이터 실측 의무 v1 (2026-04-20)*
|
||||
|
|
@ -0,0 +1,208 @@
|
|||
---
|
||||
type: 조직자산 — 시행착오 아카이브 (기획 컨텐츠 기획자 관점)
|
||||
추출 원본: 수상한잡화점 프로젝트 (NerdNavis)
|
||||
추출일: 2026-04-20
|
||||
추출자: 기획팀장 (BurningTimes)
|
||||
적용 대상: EerieVillage 착수 시 및 차기 컨텐츠 설계 전반
|
||||
참조 규칙: P30 재미 우선 · P17 배타 배치 · C22 용어 일관 · C23 허위 보고 금지 · C10-5 선행 검증
|
||||
---
|
||||
|
||||
# 기획 컨텐츠 설계 — 시행착오 아카이브 v1
|
||||
|
||||
> **본 문서의 용도**: NerdNavis 수상한잡화점 개발 과정에서 컨텐츠 기획자(몬스터·아이템·스킬·장비·인장·퀘스트)가 겪은 시행착오를 BurningTimes 조직 자산으로 추출. EerieVillage 착수 시 동일 실수 반복을 차단한다.
|
||||
|
||||
---
|
||||
|
||||
## §1. 몬스터·적 등장 패턴 설계 시행착오
|
||||
|
||||
### §1-1. 단독 보스 vs 혼합 등장 정합성 문제
|
||||
|
||||
**실증 사건 (수상한잡화점 #57)**
|
||||
|
||||
Unity 테스트 플레이 "랜덤 패턴"에서 몬스터 미등장 증상이 2회 연속 발생했다. 1차(commit `9e5fd5b59`)·2차(commit `521a76641`) 수정 모두 근본 원인을 해결하지 못하고 **fallback 가드 추가라는 proxy 개선**만 반복했다.
|
||||
|
||||
근본 원인은 `ToolData.json` 125/125 스테이지 전부의 `list_MobData`가 빈 배열이었다. 기획 설계 단계에서 "몬스터 그룹 ID를 CreateMapConfig에서 참조"하는 데이터 파이프라인이 실제 ToolData.json에 반영되지 않은 채 방치됐다.
|
||||
|
||||
**교훈 1 — 몬스터 등장 데이터 파이프라인 설계 시 검증 의무**
|
||||
|
||||
몬스터 등장 패턴을 기획할 때 "어떤 JSON/CSV 파일이 런타임 몬스터 ID를 결정하는가"를 설계 단계에서 명시적으로 추적해야 한다. 수상한잡화점의 경우 파이프라인은 다음과 같았다.
|
||||
|
||||
```
|
||||
CreateMapConfig.n_AppearMonsterGroup
|
||||
→ ApprearMonsterPattern (그룹 ID별 몬스터 ID 목록)
|
||||
→ ToolData.json list_MobData (런타임 주입)
|
||||
→ MyValue.cs:380-388 (ID 풀 구성)
|
||||
→ MonsterNodeControler.Get_MobID (추첨)
|
||||
```
|
||||
|
||||
이 파이프라인 중 어느 한 단계가 비어있으면 플레이어에게 몬스터가 보이지 않는다. **기획 설계 문서에 데이터 파이프라인 기술 경로를 1줄이라도 명시**하면 개발팀이 연결 누락을 조기 감지할 수 있다.
|
||||
|
||||
**교훈 2 — C9 조건(보스 집중)과 스테이지 구조 정합성**
|
||||
|
||||
P17 배타 조합 중 "C9(보스 집중) ∧ 단독 보스·보스 미등장 스테이지"는 논리 불성립이다. 수상한잡화점 Stage1_1과 Stage1_3은 `n_AppearBossGroup=0`(보스 없음)이므로 이 스테이지에 C9를 배치하면 달성 불가 조건이 된다. 기획자는 스테이지별 보스 등장 여부를 **CreateMapConfig.n_AppearBossGroup 실측 후** 조건 배치를 확정해야 한다. 추측으로 배치하면 P17 위반 조합이 숨어든다.
|
||||
|
||||
### §1-2. 몬스터 종족 전환 패턴
|
||||
|
||||
수상한잡화점 지역 1에서 초반(14XXX 수인형/마법생물) → 후반(11XXX 인간형)으로 종족을 점진 전환하는 설계는 유효한 패턴이었다. 플레이어가 새로운 종족 특성을 한 번에 처리하지 않고 단계적으로 학습하게 된다. EerieVillage에서는 초반 잡귀·원령 → 중반 강령술사 → 후반 봉황·이매망량 같은 서사적 종족 전환에 동일 원칙을 적용할 수 있다.
|
||||
|
||||
---
|
||||
|
||||
## §2. 아이템·장비·인장 구조 설계와 JSON 실측 기반 원칙
|
||||
|
||||
### §2-1. 기존 SOT 맹신 금지 — 데이터 구조 오해 재발 방지 (#42·#43)
|
||||
|
||||
**실증 사건**
|
||||
|
||||
수상한잡화점 기획팀은 `스테이지난이도곡선_v1.md §1`의 "WorldMap_1~4 4개 그룹" 표현을 실측 없이 SOT로 신뢰했다. 이 전제 아래 Phase 4 지역 1 v1을 "Stage 1~6 = 지역 1 = 6개 스테이지"로 설계했다. 실측 결과 실제 지역 1은 Stage1_1·1_2·1_3·1_4 = 4개였고, v1 전면 폐기 + v2 재작성이 필요했다.
|
||||
|
||||
**교훈 — 데이터 실측 5대 의무**
|
||||
|
||||
모든 기획 작업에 착수하기 전 Unity Export CSV/JSON을 직접 Read해야 한다.
|
||||
|
||||
1. **실측 선행**: 기획 문서의 수치·구조를 무비판 수용 금지. 기존 문서에 "SOT"라고 명기되어 있어도 실측과 교차 검증한다.
|
||||
2. **용어 준수**: PD가 확정한 용어 체계는 기획팀 전원이 일관 사용한다. "WorldMap_1~4" 같은 용어를 이름 기반으로 추정해서 데이터 구조로 해석하는 것은 C22 위반이다.
|
||||
3. **PD 확인**: 추측으로 결정 진행 금지. 불확실하면 기획팀 내부 논의 → PM 조율 → PD 에스컬레이션 3단계를 밟는다.
|
||||
4. **SOT 맹신 금지**: 실측 일시를 문서 상단에 명기(`데이터 소스: CreateMapConfig.csv 실측 2026-04-20`)한다. 실측 일시 미기입 문서는 참조 금지.
|
||||
5. **재사용 검증**: 기존 문서를 인용·확장할 때 §2-1 실측 결과와 대조한다. 전제가 틀릴 경우 자기 산출물도 전면 재작성 대상이다.
|
||||
|
||||
**EerieVillage 적용**
|
||||
|
||||
인장 대신 부적, 장비 대신 도구와 도복 같은 테마로 변경되더라도 동일한 JSON 파이프라인 함정이 존재한다. 새 프로젝트 착수 시 가장 먼저 "데이터 테이블 구조 재정비 v1"에 해당하는 문서를 실측 기반으로 작성하고, 이후 모든 기획 작업은 그 문서를 1차 참조로 삼아야 한다.
|
||||
|
||||
### §2-2. 장비 음수 스탯 — 트레이드오프 설계 원칙
|
||||
|
||||
**실증 사건 (REQ002)**
|
||||
|
||||
수상한잡화점 장비(`EquipmentList.json`)의 MainOption2에는 `CriDmg -20%`·`Avoid_Melee -3%`·`HitRate -3` 같은 음수 스탯이 존재했다. 기획팀은 이것이 데이터 오류인지 의도적 설계인지 알 수 없어 개발팀에 REQ를 발행했다.
|
||||
|
||||
개발팀 확인 결과 이 음수값은 **의도적인 고정 페널티**였다. 무기 라인마다 주 스탯(MainOption1) + 트레이드오프 페널티(MainOption2) 구조였으며, 강화해도 페널티는 불변(`UpgradeStatValuePara1=0`)이었다. 단, `AttackCoolTime -10%`는 예외로 공격 쿨타임 감소 = 공속 증가 = 보너스였다.
|
||||
|
||||
**교훈**
|
||||
|
||||
장비 옵션에 음수값을 설계할 때는 다음 3종을 설계 문서에 명시한다.
|
||||
|
||||
1. 어떤 스탯이 음수이며 그것이 "페널티인가 / 보너스인가"를 명시한다(`AttackCoolTime` 사례처럼 음수가 보너스인 역방향 스탯이 존재한다).
|
||||
2. 강화 시 음수값이 완화되는지 고정인지를 명시한다(수상한잡화점은 고정).
|
||||
3. 세트 옵션과의 상호작용을 명시한다(예: `MaxHP -10% + MaxShield +10%` 세트).
|
||||
|
||||
이 3가지를 문서화하지 않으면 밸런서가 DPS/EHP 시뮬레이션에서 오계산한다.
|
||||
|
||||
### §2-3. 인장(소울 장착 아이템) 슬롯 구조 설계
|
||||
|
||||
**실증 사건 (REQ003)**
|
||||
|
||||
기획팀은 인장 장착 슬롯 수를 3개와 6개 중 하나로 추정하여 기여도 분석을 진행했다. 실제는 **기본 슬롯 6개, 단 캐릭터 진화 단계에 따라 순차 개방**이었으며, 속성 매칭 제한까지 존재했다. 이 구조는 JSON에 없고 코드에 하드코딩되어 있어 JSON만 봐서는 알 수 없었다.
|
||||
|
||||
**교훈**
|
||||
|
||||
장착 슬롯 계열 컨텐츠를 설계할 때는 다음을 사전에 개발팀과 확인한다.
|
||||
|
||||
1. 슬롯 수가 데이터 테이블에 있는가, 코드에 하드코딩되어 있는가.
|
||||
2. 슬롯 개방 조건이 있는가 (진화·각성·레벨 등).
|
||||
3. 슬롯별 속성·타입 제한이 있는가.
|
||||
|
||||
이 3가지 중 하나라도 코드에 있으면 기획 변경 시 개발팀 수정이 필수다. 기획팀이 독자적으로 "슬롯 수를 4개로 조정하자"고 결정해도 반영이 안 된다.
|
||||
|
||||
EerieVillage에서 부적 슬롯, 오행 속성 슬롯 등을 설계할 때 동일한 사전 확인 절차를 적용한다.
|
||||
|
||||
---
|
||||
|
||||
## §3. 스킬·장비 옵션 상호작용 (음수값·디버프·상태이상)
|
||||
|
||||
### §3-1. 디버프성 옵션의 역할 — 선택의 다양성 확보
|
||||
|
||||
수상한잡화점 장비 트레이드오프 구조(§2-2)는 결과적으로 빌드 다양성에 기여했다. "치명타 피해 -20%" 페널티를 감수한 무기를 선택하면 다른 보너스를 확보하는 구조이므로, 플레이어가 자신의 빌드 방향에 따라 장비를 선택하게 된다.
|
||||
|
||||
컨텐츠 기획자 관점에서 음수 스탯은 "역할 없는 컨텐츠"가 아니다. 다음 조건을 충족하면 명확한 역할을 가진다.
|
||||
|
||||
1. 해당 페널티를 감수할 만한 보상이 같은 아이템 또는 세트 효과에 있다.
|
||||
2. 특정 빌드에서는 해당 스탯이 페널티가 아닌 무관 스탯이 된다(치명타 빌드가 아닌 플레이어에게 `CriDmg -20%`는 체감 손실이 작다).
|
||||
3. 강화해도 음수가 유지되거나, 강화할수록 음수가 개선되거나를 의도적으로 결정한다.
|
||||
|
||||
### §3-2. 상태이상 조건과 빌드 축 충돌
|
||||
|
||||
P17 배타 조합 7종은 이 교훈의 체계화 결과다. 수상한잡화점에서 조건 × 빌드 120개 조합을 전수 점검한 결과 다음 패턴이 반복됐다.
|
||||
|
||||
1. **완전 배타**: 빌드 목표와 조건 달성 방향이 논리적으로 상충한다(물약 빌드 × 포션 절제).
|
||||
2. **구조적 충돌**: 동시 추구가 가능하지만 높은 난이도를 요구한다(치명타 빌드 × 완벽 클리어).
|
||||
3. **강시너지**: 빌드 플레이가 조건을 자동 충족에 가깝게 만든다(보호막 빌드 × 고HP 완주).
|
||||
|
||||
EerieVillage 퀘스트·미션·스테이지 클리어 조건 설계 시 동일한 120개(빌드 N개 × 조건 M개) 매트릭스를 작성하고, E(배타) 조합을 동일 스테이지에 동시 배치하지 않는 원칙을 초기에 확립한다.
|
||||
|
||||
---
|
||||
|
||||
## §4. 컨텐츠 간 상호작용 배타 규칙 설계 방법론 (P17 추출)
|
||||
|
||||
### §4-1. 배타 규칙을 만드는 4단계 방법론
|
||||
|
||||
수상한잡화점의 P17 신설 과정에서 다음 4단계가 유효했다.
|
||||
|
||||
1. **조건 풀과 빌드 풀을 독립 열거한다.** 두 목록을 각각 완성한 뒤 교차 매트릭스를 그린다. 직관으로 "이 두 개는 나쁘다"고 판단하기 전에 목록을 먼저 만든다.
|
||||
2. **각 교차 지점에 E/X/S/SS/-를 배정한다.** 배정 근거는 "이 빌드를 진행하는 플레이어가 이 조건을 달성하려면 어떤 행동을 해야 하는가"를 기준으로 판단한다.
|
||||
3. **E(배타) 조합에서 동일 스테이지 슬롯에 동시 배치 금지 규칙을 추출한다.** 배타 조합이 동시 존재하면 해당 빌드 플레이어는 달성 불가 상태가 된다.
|
||||
4. **신규 조건·빌드 추가 시 기존 배타 목록과 교차 검증한다.** 추가 단계에서 검증을 빠뜨리면 배타 조합이 누적된다.
|
||||
|
||||
### §4-2. 논리 불성립 조건 사전 차단
|
||||
|
||||
수상한잡화점 P17 배타 조합 #5 "C9(보스 집중) ∧ 단독 보스·보스 미등장 스테이지"는 스테이지 구조에서 비롯된 논리 불성립이다. 이는 조건 풀의 문제가 아니라 **스테이지 데이터 구조와 조건 설계의 정합성 문제**다. EerieVillage에서 "퇴마 집중" 같은 보스 특화 조건을 설계할 때, 해당 조건을 배치할 스테이지에 실제로 보스(봉황·이매망량 등)가 등장하는지를 데이터 테이블 실측으로 확인한 뒤 배치한다.
|
||||
|
||||
---
|
||||
|
||||
## §5. EerieVillage 착수 가이드 — 조선 시대 퇴마 테마 컨텐츠 셋 구성
|
||||
|
||||
### §5-1. 컨텐츠 셋 구성 원칙
|
||||
|
||||
수상한잡화점의 시행착오를 바탕으로 EerieVillage 컨텐츠 셋 착수 시 다음 순서를 권고한다.
|
||||
|
||||
**1순위 — 데이터 구조 SOT 확립 (착수 불가 전제 조건)**
|
||||
|
||||
신 프로젝트 데이터 체계(JSON/CSV/SQLite 등)를 실측하여 "데이터 구조 재정비 v1"에 해당하는 문서를 가장 먼저 작성한다. 몬스터·아이템·스킬·장비·퀘스트 각 테이블의 필드 목록, 레코드 구조, 참조 관계를 실측 기반으로 명시한다. 이 문서 없이 컨텐츠 셋 설계를 시작하면 수상한잡화점 v1 전면 폐기 사건이 반복된다.
|
||||
|
||||
**2순위 — PD 용어 확정 (설계 착수 전)**
|
||||
|
||||
조선 시대 세계관에서 다음 용어를 PD와 확정한다.
|
||||
|
||||
- 지역 단위 명칭 (예: 마을·고을·영·유배지)
|
||||
- 스테이지 단위 명칭 (예: 길목·처소·관아)
|
||||
- 서브맵 단위 명칭 (예: 노드·조우·구역)
|
||||
- 몬스터 분류 명칭 (예: 잡귀·원령·악귀·봉황·이매망량)
|
||||
|
||||
이 용어가 데이터 테이블 필드 명칭과 어떻게 매핑되는지를 문서화한다.
|
||||
|
||||
**3순위 — 컨텐츠 셋 다양성 축 정의**
|
||||
|
||||
EerieVillage 퇴마 테마에서 자연스러운 다양성 축은 다음과 같다.
|
||||
|
||||
| 축 | 한쪽 극단 | 다른 쪽 극단 | 기획 역할 |
|
||||
|----|---------|------------|---------|
|
||||
| 접근 방식 | 직접 퇴마(근거리 전투) | 부적 원격 제압(원거리) | 빌드 방향 분기 |
|
||||
| 오행 속성 | 금·수 방어형 | 화·목 공격형 | 상성 시스템 |
|
||||
| 처치 수단 | 정화(약화→마무리) | 즉결(직접 처치) | 전투 스타일 |
|
||||
| 시간 축 | 지속전(장기전·회복) | 속결전(버스트) | 클리어 조건 분기 |
|
||||
| 위험 감수 | 안전 빌드(회피·방어) | 공격적 빌드(디버프 감수) | 트레이드오프 |
|
||||
|
||||
**4순위 — 배타 조합 매트릭스 초안 작성**
|
||||
|
||||
위 다양성 축에서 추출한 빌드 N개 × 클리어 조건 M개의 교차 매트릭스를 P17 방법론(§4-1)으로 작성한다. 이 매트릭스는 스테이지 조건 배치 이전에 완성되어야 한다. 조건 풀이 확정되면 배타 조합 목록을 추출하고, 스테이지 설계 시마다 배타 조합 전수 체크를 의무화한다.
|
||||
|
||||
### §5-2. 조선 시대·퇴마 테마 특화 주의사항
|
||||
|
||||
**음수 스탯의 테마 일관성**
|
||||
|
||||
장비 트레이드오프로 음수 스탯을 도입할 경우, 조선 시대 세계관과 일관성이 있어야 한다. 예를 들어 "부적 강화 → 무술 능력 저하" 또는 "오행 금기 위반 → 회피 감소" 같은 형태로 서사적 납득이 가능한 페널티를 설계한다. 수상한잡화점의 "치명타 피해 감소" 페널티는 세계관 맥락이 없는 순수 수치 트레이드오프였다. EerieVillage에서는 세계관 맥락과 수치 설계를 함께 제시해야 한다.
|
||||
|
||||
**몬스터 보스 등장 패턴과 퇴마 서사 정합성**
|
||||
|
||||
퇴마 서사에서는 보스(이매망량·봉황 등)의 등장이 단순 전투 도전이 아닌 서사적 클라이맥스 역할을 한다. 스테이지 구조 설계 시 보스 등장 여부(`n_AppearBossGroup` 등가 필드 실측)와 서사 이벤트 배치를 연계한다. 수상한잡화점에서 보스 미등장 스테이지에 "보스 집중" 조건이 배치될 뻔한 사건처럼, 서사 클라이맥스 조건을 보스 미등장 스테이지에 배치하는 실수가 동일하게 발생할 수 있다.
|
||||
|
||||
---
|
||||
|
||||
## §6. 참조 원본 (실측 기반 항목만)
|
||||
|
||||
- `프로젝트/수상한잡화점/기획/테이블_데이터_구조_재정비_v1.md` — 데이터 구조 SOT (#42)
|
||||
- `프로젝트/수상한잡화점/기획/기획팀_데이터_실측_의무_v1.md` — 5대 의무 룰 (#43)
|
||||
- `프로젝트/수상한잡화점/기획/Phase4_지역1_노드구성_v2.md` — 실측 후 재작성 (#44)
|
||||
- `프로젝트/수상한잡화점/기획/빌드_조건_충돌점검_v1.md` — 120개 배타 매트릭스
|
||||
- `공유/소통/완료/2026-04-16_REQ002_응답_장비옵션_음수값.md` — 트레이드오프 코드 근거
|
||||
- `공유/소통/완료/2026-04-16_REQ003_응답_인장_장착수제한.md` — 슬롯 구조 코드 근거
|
||||
- `공유/대화로그/수상한잡화점/2026-04-20.md` — #42 테이블 데이터 구조 재정비 · #57 몬스터 미등장 근본 원인
|
||||
|
|
@ -0,0 +1,199 @@
|
|||
---
|
||||
type: 조직자산 시행착오 아카이브
|
||||
작성일: 2026-04-21
|
||||
작성자: 레벨기획자 (BurningTimes 기획팀)
|
||||
원본_프로젝트: 수상한잡화점 (NerdNavis)
|
||||
대상_프로젝트: EerieVillage (BurningTimes)
|
||||
관련: BT2 Phase 2-A 조직 전환 교훈 추출
|
||||
---
|
||||
|
||||
# 레벨 기획 시행착오 아카이브 v1
|
||||
|
||||
> **본 문서의 목적**: NerdNavis 수상한잡화점 프로젝트 Phase 3·4에서 레벨 기획이 겪은 시행착오를 5개 섹션으로 정리. EerieVillage(2D PlatformerMicrogame 기반) 착수 시 동일 실수 반복을 방지하기 위한 조직 자산.
|
||||
|
||||
---
|
||||
|
||||
## §1. Phase 3 맵 패턴 재검증 (Day 11~14) — 배경과 방법
|
||||
|
||||
### §1-1. 배경: 왜 전수 재검증이 필요했는가
|
||||
|
||||
Phase 3은 "설계 체계 확립"을 목표로 했다. 이전 단계(Phase 0~2)에서 앵커 전투 시뮬레이션·카드 임팩트 측정 등이 완료되었으나, 각 스테이지의 맵 패턴(보스 배치·혼용 몬스터·★ 조건 배치)이 **원칙 없이 임시 설계 상태**로 남아 있었다. Day 11~14는 이 공백을 채우기 위해 별도 병렬 작업으로 투입된 라운드다.
|
||||
|
||||
핵심 동인은 두 가지였다.
|
||||
|
||||
1. **P17 배타 7종 규칙 신설**: 수상한잡화점 전용으로 7가지 조건 조합이 동시 배치 금지로 확정됐다. 기존 임시 설계 상태에서 이 규칙이 이미 위반되어 있는지 전수 점검이 필요했다.
|
||||
2. **C9(보스 집중 조건)의 논리 불성립 스테이지 식별**: 단독 보스 또는 보스 미등장 스테이지에 C9를 배치하면 조건 자체가 의미를 잃는다. 21개 스테이지 전수 분류가 필요했다.
|
||||
|
||||
### §1-2. 방법: 레벨·밸런스 병렬 + 기획팀장 통합 판정
|
||||
|
||||
Day 11~14 재검증은 **레벨기획자와 밸런스기획자가 병렬 수행**하고 기획팀장이 통합 보고서를 작성하는 3단 구조로 진행됐다.
|
||||
|
||||
레벨기획자 담당 5건:
|
||||
1. Stage 11~15 난이도 곡선 재검증 — 내구도(HP+Shield) 흐름의 이상 패턴 식별 및 레벨 관점 판정
|
||||
2. C9 배치 금지 스테이지(7·10·13) 타당성 3축 검증 — 조건 의미성·페이싱·재도전 유도 축 각각 검증
|
||||
3. C9 적합 스테이지 12개 전수 재검증 — 최적/주의 2단계 분류
|
||||
4. 보스 혼용 패턴 원칙 4종을 AppearGroup 단위 프레임으로 구체화
|
||||
5. 42 슬롯 × P17 배타 7종 위험 스테이지 레벨 관점 추가 식별
|
||||
|
||||
핵심 교훈: **실 배치 확정 없이 검증 틀을 선행 작성하는 것이 가능하고 유익하다.** 42슬롯 현황 테이블과 AppearGroup 가이드 프레임은 Phase 4 실 배치 작업의 속도를 크게 높이는 사전 자산이 됐다. 반면 패턴 ID 확정은 ApprearMonsterPattern.json 실측 없이 불가능하다 — 데이터 없이 추정으로 확정하지 않는 것이 C23(정직성) 준수다.
|
||||
|
||||
### §1-3. 재검증에서 드러난 설계 원칙 3종
|
||||
|
||||
1. **단독 보스 스테이지는 "짧고 강렬한" 페이싱 단위다.** Stage 13(서브맵 4개·단독 레드드래곤3)이 내구도 급락(-36)으로 보이나, 레벨 관점에서는 WorldMap3 후반 진입 직전의 "숨 고르기 구간"으로 해석됐다. 선형 내구도 상승이 항상 옳은 난이도 곡선은 아니다.
|
||||
2. **보스 재사용 3회 이상은 플레이어 피로를 유발한다.** Stage 15 흑기사1이 계열 3번째 등장이었다. 보스 재사용 횟수를 추적하고 맵 패턴 다양화(서브맵별 혼용 비율 조정)로 보완하는 설계가 필요하다.
|
||||
3. **Shield 극단 보스(예: 용암골렘2 Shield 525)가 있는 스테이지에 C9 배치 시 Unity MCP 시뮬 선행이 필수다.** Shield 벽이 C9 임계값 달성 자체를 막아 버릴 수 있기 때문이다.
|
||||
|
||||
---
|
||||
|
||||
## §2. Phase 4 분리 경위 — "스테이지별 노드 구성"을 신규 Phase로 분리한 이유
|
||||
|
||||
### §2-1. 분리 결정의 배경
|
||||
|
||||
Phase 3 종결 시점에서 중요한 설계 판단이 이뤄졌다. PD님의 직접 지시 원문은 다음과 같다.
|
||||
|
||||
> "B안으로 진행해서 이미 진행된 내용은 종결하고, Phase 4 = 스테이지별 노드 구성 작업을 신규 Phase로 분리해서 이제부터 기획팀에서 스테이지별 노드를 구성해줘."
|
||||
|
||||
당시 두 가지 선택지가 있었다.
|
||||
|
||||
- **A안 (합산)**: Phase 3 내에서 설계 원칙과 실 배치를 함께 완료
|
||||
- **B안 (분리)**: 설계 원칙은 Phase 3에서 종결하고, 실 배치를 Phase 4로 분리
|
||||
|
||||
B안이 채택된 근거는 명확하다. Phase 3에서 확정된 것은 "설계 원칙·판정 도구"이고 스테이지별 실측 데이터는 임시 상태였다. 임시 데이터 위에서 실 배치를 확정하면 나중에 데이터가 정리될 때 전면 재작업이 필요해진다. 원칙과 실 배치를 동일 Phase에 묶으면 원칙이 수정될 때 배치도 함께 흔들린다는 구조적 취약점이 있다.
|
||||
|
||||
### §2-2. Phase 분리가 레벨 기획에 주는 함의
|
||||
|
||||
**"원칙 층위"와 "실 배치 층위"를 분리하라.** 이는 레벨 기획의 일반 원칙으로 추출할 수 있다.
|
||||
|
||||
- 원칙 층위: 보스 배치 가이드라인, 조건 배타 규칙, 구간별 허용 조건 목록, 페이싱 곡선 방향
|
||||
- 실 배치 층위: 스테이지 N에 슬롯2 = 조건 X, 서브맵 M = 보스 ID Y
|
||||
|
||||
원칙이 바뀌면 실 배치도 바뀌어야 하지만, 원칙이 안정적이면 실 배치 작업은 "채워넣기"가 된다. 이 분리가 Phase 3→4 전환의 핵심이었다.
|
||||
|
||||
EerieVillage에 적용: 플랫포머 레벨 기획에서도 "구간별 난이도 원칙·공간 구조 원칙"과 "각 레벨의 실 구현"을 별도 문서로 관리하는 것이 재작업을 최소화한다.
|
||||
|
||||
---
|
||||
|
||||
## §3. 지역 구조 오해 실증 — "WorldMap 4그룹" 오해의 원인과 재발 방지
|
||||
|
||||
### §3-1. 오해의 경위
|
||||
|
||||
Phase 4 착수 가이드(v1)는 지역 1을 "WorldMap_1 = Stage 1~6 = 6개"로 설계했다. 그러나 이것은 실측 없는 추정이었다.
|
||||
|
||||
기존 SOT 문서(스테이지난이도곡선_v1.md §1)에 "WorldMap_1~4 4개 그룹"이라는 표현이 있었다. 기획팀은 이것을 "4개의 WorldMap × 각 6개 스테이지 = 24개"로 해석했다. 그러나 실제 CreateMapConfig.csv를 실측한 결과는 전혀 달랐다.
|
||||
|
||||
- **실제 구조**: 21개 지역(n_StageID 1~21) × 각 지역이 N개 하위 스테이지 = 총 122 스테이지
|
||||
- **지역 1**: Stage1_1 · Stage1_2 · Stage1_3 · Stage1_4 = 4개 (6개가 아니다)
|
||||
|
||||
v1은 전면 폐기되고 v2가 재작성됐다. (#41 보류 → #44 재작성)
|
||||
|
||||
### §3-2. 오해의 근본 원인 3종
|
||||
|
||||
1. **SOT 문서의 §1(요약)과 §2 이후(실측 수치) 계층 혼용**: 스테이지난이도곡선_v1.md의 §1은 개요 수준이었고 실측이 아니었으나, 기획팀은 이것을 확정 데이터로 신뢰했다. **문서 내에서 "개요/가정 섹션"과 "실측 데이터 섹션"을 명확히 구분하지 않았던 것이 근본 원인이다.**
|
||||
2. **직접 실측 없이 기존 문서 재활용**: Phase 4 착수 전 CreateMapConfig.csv를 직접 열어 보지 않았다. 기존 문서의 표현을 그대로 신뢰한 것이 오해를 고착시켰다.
|
||||
3. **PD님 확정 용어와 기획팀 SOT 충돌 미감지**: PD님이 "지역 1 = 4개"라고 확정 용어를 사용했을 때, 기획팀이 "우리 SOT에는 6개로 되어 있는데"라고 교차 검증하지 않고 진행했다.
|
||||
|
||||
### §3-3. 재발 방지 규칙 (기획팀_데이터_실측_의무_v1.md로 제도화)
|
||||
|
||||
사건 이후 기획팀 전용 5대 의무가 신설됐다.
|
||||
|
||||
1. **착수 전 원본 CSV/JSON 직접 실측 의무**: 기존 문서의 수치가 아니라 Unity Export 원본을 직접 열어 확인한다.
|
||||
2. **PD님 확정 용어 우선 원칙**: PD님이 명명한 용어(지역명·스테이지 수량·ID 체계)가 기존 기획 문서와 충돌하면 실측으로 확인 후 PD님 용어를 채택한다.
|
||||
3. **SOT 맹신 금지**: 기존 문서의 §1(개요)은 가정이거나 당시 이해 수준의 기술일 수 있다. 실측 섹션만 확정 데이터로 취급한다.
|
||||
4. **PD 확인 선행 의무**: 지역 수량·스테이지 수량·ID 체계처럼 구조적 전제가 바뀌는 결정은 착수 전 PD 확인을 먼저 받는다.
|
||||
5. **재사용 검증**: v1 설계를 v2에 재활용할 때, 재활용 가능 요소와 불가 요소를 명시적으로 분리한다.
|
||||
|
||||
EerieVillage 적용: 플랫포머 레벨 기획 착수 전 UnityEditor나 씬 파일을 직접 열어 실제 레벨 구조·플랫폼 ID·씬 이름을 확인한 뒤 기획 문서를 작성한다. 기획서가 선행하고 실제 에셋이 나중에 맞춰지는 구조가 아니라면, 항상 실제 데이터가 기획 전제의 SOT다.
|
||||
|
||||
---
|
||||
|
||||
## §4. Prove-2-of-3 슬롯 배치 난이도 곡선 — 입문과 중후반 차등 설계
|
||||
|
||||
### §4-1. Prove-2-of-3 체계의 구조
|
||||
|
||||
수상한잡화점의 ★ 조건은 슬롯 3개(슬롯1·슬롯2·슬롯3) 중 2개 이상 달성하면 ★3을 주는 "Prove-2-of-3" 구조다. 슬롯1은 기본 클리어(누구나 달성 가능)이고, 슬롯2·슬롯3에 도전 조건을 배치한다. 레벨 기획의 핵심 질문은 **"어느 스테이지 슬롯2·슬롯3에 어떤 조건을 넣느냐"**다.
|
||||
|
||||
지역 1(입문 구간, Stage1_1~1_4) 실제 배치:
|
||||
|
||||
| 스테이지 | 슬롯2 | 슬롯3 | 재미 축 |
|
||||
|---------|------|------|--------|
|
||||
| Stage1_1 | N1 (빗맞힘 절제) | C3 (고 HP 완주) | 정확도 + 생존 |
|
||||
| Stage1_2 | N5 (후열 선공) | C6 (포션 절제) | 타겟팅 + 자원 관리 |
|
||||
| Stage1_3 | N6 (전열 선공) | C12 (각성 절제) | 타겟팅 반대 + 기본기 |
|
||||
| Stage1_4 | C1 (신속 클리어) | N4 (쉴드 보존) | 속도 + 자원 관리 |
|
||||
|
||||
8 슬롯에 7종 조건 사용 — 중복 없음, 12종 조건 풀의 58% 활용.
|
||||
|
||||
### §4-2. 입문 구간 전용 제약 (P17 배타 조합 4번·6번)
|
||||
|
||||
입문 1~6 구간에는 두 가지 특수 제약이 적용된다.
|
||||
|
||||
- **P17-4**: 입문 구간에서 C1(신속 클리어) ∧ C3(HP≥70%) 동시 배치 금지. 이 두 조건은 각각 "빠르게 끝내라"와 "피격 없이 버텨라"를 동시에 요구하는데, 입문 플레이어에게는 이중 부담이 과도하다. 중반·후반 숙련자 구간에서는 허용된다.
|
||||
- **P17-6**: 입문 구간에서 N3(치명타 처치 N회 이상) 배치 금지. 입문 구간 플레이어는 아직 치명타 특화 빌드를 구성하지 못한 상태다. 달성 불가능한 조건을 배치하면 재도전 유도가 아니라 포기를 유발한다.
|
||||
|
||||
이 두 규칙의 설계 원리: **조건은 플레이어의 현재 역량 범위에서 도전이어야 한다.** 역량 밖의 요구는 재미 조건이 아니라 진입 장벽이 된다.
|
||||
|
||||
### §4-3. Stage1_2 → Stage1_3에서 N5 → N6로 전환하는 설계
|
||||
|
||||
P17-7은 N5(후열 선공) ∧ N6(전열 선공) 동시 배치를 금지한다. 같은 스테이지에 넣으면 타겟팅 자유도를 완전히 박탈하기 때문이다. 그러나 **연속 스테이지에서 N5·N6를 교대로 배치하는 것은 유효한 설계**다.
|
||||
|
||||
Stage1_2(후열 선공)에서 원거리 보스를 먼저 잡는 타겟팅을 학습하고, Stage1_3(전열 선공)에서 근접 인간형을 먼저 처리하는 반대 타겟팅을 경험하게 했다. 같은 지역 내에서 타겟팅 양축을 모두 체험하는 페이싱이다.
|
||||
|
||||
EerieVillage 적용: 플랫포머에서 "달리기 레벨" 다음에 "멈추고 조준하는 레벨"처럼, 인접 레벨 간 요구 스킬을 의도적으로 대비시키면 학습 곡선과 다양성을 동시에 확보할 수 있다.
|
||||
|
||||
---
|
||||
|
||||
## §5. 보스·몬스터 등장 패턴 맵 통합 — AppearGroup 가이드 4원칙
|
||||
|
||||
### §5-1. 4원칙 개요
|
||||
|
||||
레벨 기획에서 보스가 언제 등장하고 일반 몬스터와 어떻게 혼용되는지를 규정하는 AppearGroup 가이드 프레임 4원칙이 Phase 3에서 확립됐다.
|
||||
|
||||
1. **원칙 1 — 보스 단독 서브맵 ≤ 50%**: 전체 서브맵 중 보스만 등장하는 서브맵이 절반을 넘으면 안 된다. 단, 최종 서브맵(클라이맥스)은 예외.
|
||||
2. **원칙 2 — 혼용 몬스터 = 현 스테이지 난이도 −1 구간**: 보스와 함께 등장하는 일반 몬스터는 해당 스테이지보다 한 단계 낮은 난이도 몬스터를 쓴다. 보스와 고레벨 일반 몬스터 동시 등장은 복합 과부하를 유발한다.
|
||||
3. **원칙 3 — C9 배치 스테이지에서 보스 등장 서브맵 비율 ≥ 60%**: C9(보스 집중) 조건을 달성하려면 충분히 많은 서브맵에서 보스가 등장해야 한다.
|
||||
4. **원칙 4 — 단일 스테이지 내 최소 2가지 이상 보스 등장 위치 패턴**: 보스가 항상 같은 서브맵에 등장하면 플레이어가 패턴을 암기하여 조건 달성이 기계적이 된다.
|
||||
|
||||
### §5-2. C9와 단독 보스의 논리 불성립
|
||||
|
||||
C9(보스 집중) 조건은 "여러 적 중 보스를 우선 공격하도록 플레이어 의식을 전환"시키는 데 의미가 있다. 따라서 보스가 1체뿐인 단독 보스 스테이지(Stage 7·10·13)에서 C9를 배치하면 조건이 "자동 충족"된다 — 어차피 공격할 수 있는 것이 보스밖에 없기 때문이다. 이것은 P17-5 배타 규칙의 레벨 설계 근거다.
|
||||
|
||||
레벨 관점 검증 3축:
|
||||
- **조건 의미성 축**: 전략 선택이 발생하는가? → 아니오 (자동 충족)
|
||||
- **페이싱 축**: 단독 보스 스테이지의 특성(짧고 강렬)과 조건 시스템이 충돌하는가? → 예
|
||||
- **재도전 유도 축**: C9의 재도전 가치(타겟팅 전환 의식)가 발생하는가? → 아니오
|
||||
|
||||
이 분석은 레벨 기획에서 조건(★ 조건, 목표, 달성 과제)을 설계할 때 **"이 조건이 이 공간 구조에서 의미를 갖는가"를 먼저 확인해야 한다**는 원칙으로 일반화된다.
|
||||
|
||||
### §5-3. EerieVillage 2D 플랫포머 레벨 기획 시 차기 참고 원칙
|
||||
|
||||
수상한잡화점 경험에서 2D 플랫포머에 직접 이전 가능한 레벨 기획 원칙 5종:
|
||||
|
||||
1. **선형 vs 분기 판단은 "플레이어의 역량 표현 공간"으로 결정한다.** 선형 구조는 학습 경험 전달에 유리하고, 분기 구조는 빌드·전략 다양성 표현에 유리하다. 입문 구간은 선형, 중후반 구간에서 분기 도입을 권장한다.
|
||||
|
||||
2. **수집형 보상(코인·아이템)은 "일직선 경로 외의 영역"에 배치한다.** 조금 위험하거나 돌아가는 경로에 숨겨진 보상을 두면 탐험 동기가 생긴다. 주 경로에 수집 요소를 밀집시키면 이동이 아닌 반복 수집 행동으로 게임이 왜곡된다.
|
||||
|
||||
3. **보스 등장 전 "경고 공간"을 설계한다.** 수상한잡화점에서 Stage1_2 보스 서브맵 직전에 경고 전투를 배치한 것처럼, 플랫포머에서도 보스 방 진입 직전에 보스의 특성을 암시하는 장애물·적 배치를 두면 플레이어가 대응을 준비할 수 있다.
|
||||
|
||||
4. **구간 전환 시 "숨 고르기" 공간을 의도적으로 설계한다.** 고난도 구간 이후에 낮은 밀도의 구간을 배치하는 것은 결함이 아니라 페이싱 설계다. 내구도/밀도가 항상 상승할 필요는 없다.
|
||||
|
||||
5. **조건(목표)은 그 레벨의 공간 구조와 정합해야 한다.** 좁은 발판만 있는 레벨에서 "피격 없이 클리어"를 요구하면 조건이 레벨을 설명하지 못한다. 레벨 구조 → 조건 순서로 설계하고, 조건 → 레벨 구조로 거슬러 올라가지 않는다.
|
||||
|
||||
---
|
||||
|
||||
## §6. 기각안 (C32 필수)
|
||||
|
||||
| # | 기각 대안 | 기각 사유 |
|
||||
|---|---------|---------|
|
||||
| 1 | Phase 3 재검증 내용을 레벨/밸런스 분리 없이 단일 문서로 작성 | 레벨 관점과 밸런스 관점은 동일 현상을 다른 기준으로 판정한다. 분리 작성 후 교차 검증이 누락을 잡아준다 — Day 11~14 Stage 15 흑기사1 패턴 피로는 레벨 관점이 먼저 제기하고 밸런스가 보완했다. |
|
||||
| 2 | Phase 4 착수 가이드에서 실 배치까지 단일 문서로 완결 | 가이드와 실 배치를 분리하지 않으면 원칙이 바뀔 때 배치도 함께 재작업된다. 2층 분리 유지가 유지보수 비용을 낮춘다. |
|
||||
| 3 | "WorldMap 4그룹" 표현을 기획 레이블로 병행 사용 | PD님 확정 용어(21개 지역)와 병행 사용하면 C22 위반이고 신규 기획자 재혼동을 유발한다. 기획 레이블이 필요하면 "입문/초반/중반/후반"처럼 실측 구조와 독립된 레이블을 별도 명시한다. |
|
||||
| 4 | 입문 구간 제약(P17-4·P17-6)을 별도 문서로 관리 | 배타 규칙은 단일 SOT(P17)에서 관리한다. 구간별 예외·강화 조항도 P17 내에 인라인으로 기술하는 것이 분산 SOT 문제를 방지한다. |
|
||||
| 5 | Stage1_3에 N5·N6 두 조건을 모두 배치하여 "둘 다 해보기" 경험 제공 | P17-7 직접 위반이자 타겟팅 자유도 완전 박탈. 학습 목적이라면 연속 스테이지에 N5·N6를 교대 배치하는 방식이 P17 준수와 양축 학습을 동시에 달성한다. |
|
||||
|
||||
---
|
||||
|
||||
## §7. 변경 이력
|
||||
|
||||
| 일시 | 변경자 | 변경 내역 |
|
||||
|------|-------|----------|
|
||||
| 2026-04-21 | 레벨기획자 (BurningTimes 기획팀) | 초안 작성 — 수상한잡화점 Phase 3·4 레벨 기획 시행착오 5섹션 추출 · BT2 Phase 2-A 조직 전환 교훈 자산화 |
|
||||
|
|
@ -0,0 +1,118 @@
|
|||
# 시행착오 아카이브 — 시나리오·내러티브 기획 (narrative-designer)
|
||||
|
||||
> **작성 주체**: narrative-designer (시나리오·내러티브 기획자)
|
||||
> **작성일**: 2026-04-21
|
||||
> **적용 조직**: BurningTimes
|
||||
> **신 프로젝트**: EerieVillage (기묘한 고을: 조선퇴마뎐)
|
||||
> **원본 레포**: 수상한잡화점 (NerdNavis 조직, 2025-2026)
|
||||
|
||||
---
|
||||
|
||||
## 1. 개요 — 핵심 교훈 요지
|
||||
|
||||
### 1-1. 실측 결과 (C23 정직성 의거)
|
||||
|
||||
수상한잡화점 프로젝트의 **내러티브 전용 산출물은 존재하지 않는다** (2026-04-21 전수 실측 확인).
|
||||
|
||||
| 확인 경로 | 결과 |
|
||||
|----------|------|
|
||||
| `프로젝트/수상한잡화점/기획/` 전체 파일 목록 | 세계관·스토리·대사·캐릭터·용어사전 해당 파일 없음 |
|
||||
| `공유/대화로그/수상한잡화점/` 전수 grep (세계관·스토리·시나리오·대사·캐릭터·네이밍) | 밸런싱·시스템·레벨 업무 언급만 존재. 내러티브 전용 결정 0건 |
|
||||
| `narrative-designer.md` 에이전트 정의 | 에이전트 역할·원칙은 정의되어 있으나, 실제 호출 이력·산출물 없음 |
|
||||
| `공유/소통/` 채널 내 narrative-designer 발신 문서 | 미확인 (glob 탐색 범위 밖, 단 대화로그 내 언급 없어 부재 추정) |
|
||||
|
||||
**결론**: 수상한잡화점은 캐주얼 덱빌딩 배틀 게임으로, 개발 기간 중 밸런스·시스템·레벨 기획에 집중했으며 내러티브(세계관·스토리·캐릭터 서사·대사)는 실질적으로 다루어지지 않았다. 에이전트 정의는 신설되었으나 수상한잡화점 컨텍스트에서는 미활용 상태.
|
||||
|
||||
### 1-2. 추출 가능한 메타 교훈 (시스템 운영 관찰)
|
||||
|
||||
내러티브 전용 교훈은 없으나, **조직 운영에서 관찰된 원칙**이 EerieVillage 내러티브 착수에 직접 적용된다.
|
||||
|
||||
1. **C22 용어 일관 사용 — 신설 계기가 내러티브 맥락**: C22 신설 실증 사건은 "Phase 1~4를 A/B/C/D로 재매핑"한 PM 오류다. **세계관·네이밍·용어 체계는 C22 위반의 직접 피해 영역**. 한 번 이름을 정하면 이후 세션에서 임의 변형 금지.
|
||||
2. **P18 설계 문서화 의무 — narrative는 유령 문서 고위험군**: `Phase3_재개준비_체크리스트_v1.md` 내 "시나리오기획자 — Phase 3 본 작업에서는 비주요"라는 1줄이 수상한잡화점 내러티브 영역의 전부다. 기획 결정이 체크리스트 1줄로만 남고 별도 문서화가 없으면 롤백·계승 불가.
|
||||
3. **내러티브 미착수 = 향후 EerieVillage 출발 비용 최소화**: 수상한잡화점 세계관(서양 잡화점)과 EerieVillage(조선 퇴마)는 완전 이질적이다. 선행 자산 이식 부담 없이 처음부터 설계 가능.
|
||||
|
||||
---
|
||||
|
||||
## 2. 시도한 방법 · 이유 · 결과 · 교훈 (4필드 표)
|
||||
|
||||
| # | 시도한 방법 | 이유 | 결과 | 교훈 |
|
||||
|---|-----------|------|------|------|
|
||||
| T-1 | narrative-designer 에이전트 정의 신설 (`.claude/agents/narrative-designer.md`) | 기획팀 6종 전문 에이전트 체계 정비 일환 (2026-04-17) | 에이전트 정의는 완성됐으나 수상한잡화점에서는 실제 호출·산출물 없음 | 에이전트 정의 = 역량 선언. 역량이 있다고 자산이 생기지 않는다. **호출 이력과 산출물이 있어야 조직 자산이 된다** |
|
||||
| T-2 | 세계관·스토리 문서화 없이 밸런싱 집중 진행 | 수상한잡화점은 퍼즐형 덱빌딩 배틀 — 내러티브 의존도 낮음 | 밸런싱·스테이지 구성은 높은 완성도. 내러티브 결핍으로 인한 문제 보고 없음 | **내러티브 의존도가 낮은 장르에서는 미착수가 리스크 아닐 수 있다.** 단, EerieVillage는 조선 퇴마라는 테마가 핵심 콘텐츠 — 내러티브 없이 레벨·컨텐츠 설계 불가 |
|
||||
| T-3 | content-designer.md에 "세계관·대사·이름의 톤은 시나리오 기획자와 맞춰야 한다" 원칙 명시 | 역할 경계 명확화 | 수상한잡화점에서는 narrative-designer 부재로 이 협업 구조가 실증되지 못함 | 역할 경계 명문화는 필요조건. **실제 프로젝트에서 내러티브-컨텐츠 협업 프로세스를 EerieVillage가 첫 실증 기회** |
|
||||
| T-4 | C22 용어 일관 사용 규칙 신설 (2026-04-15, Phase 1~4 → A/B/C/D 재매핑 사건 계기) | PM이 PD님 도입 용어를 임의 재매핑하여 혼동 발생 | 코어룰 헌법급 규칙으로 정착 | **네이밍 체계는 C22 위반의 직접 피해 영역.** 세계관·지명·인명·용어는 최초 확정 시점부터 glossary 등록 + 이후 변경 금지 원칙을 적용해야 동일 혼동 재발 방지 가능 |
|
||||
|
||||
---
|
||||
|
||||
## 3. BT 조직 EerieVillage 착수 시 체크리스트
|
||||
|
||||
> 수상한잡화점에서 내러티브 산출물 부재 → 교훈이 희소한 현황을 반영하여, **본 체크리스트는 "EerieVillage에서 처음부터 올바르게 시작하기 위한 원칙 선언"** 중심으로 구성한다.
|
||||
|
||||
### 3-1. 착수 전 설계 원칙 (P18 설계 문서화 의무)
|
||||
|
||||
- [ ] **세계관 SOT 문서 신설 의무**: 조선 시대·퇴마·민속 테마의 핵심 설정(시대·장소·톤·갈등 구조·주요 세력·세계 규칙·금기)을 별도 `세계관_SOT_v1.md`로 명문화. 유령 문서 금지 — 다른 기획 문서가 참조하기 전에 본문이 존재해야 한다
|
||||
- [ ] **용어 사전(glossary) 즉시 가동**: 첫 네이밍 결정 시점부터 `glossary_v1.md` 신설. 지명·인명·직책·마법·도구 계열 용어를 최초 확정 즉시 등록. C22 준수 메커니즘의 실체 파일
|
||||
- [ ] **내러티브-시스템 연결 확인**: 세계관 설계 전 "이 설정이 어떤 시스템·컨텐츠로 구현되는가"를 먼저 자문. 세계관은 소설이 아니라 플레이어 행동의 무대 (P30 재미 우선 원칙)
|
||||
- [ ] **plan-auditor 모드 A 선행 호출**: 세계관 핵심 결정·네이밍 체계 확정 응답 발신 전 교차 검증
|
||||
|
||||
### 3-2. 조선·퇴마 내러티브 고유 원칙
|
||||
|
||||
**고증 범위 판단**
|
||||
- 역사적 고증(복식·관직·지명)과 게임적 허용(퇴마 메커닉·설정 과장)의 경계를 세계관 SOT에 명시적으로 선언한다. 고증 수준 미정 상태로 컨텐츠·레벨 기획에 진입하면 일관성 붕괴
|
||||
- 고증 오류 지적 리스크보다 **내러티브 내 일관성**을 우선한다. 이 세계 안에서의 규칙이 더 중요
|
||||
|
||||
**민속 용어 운용 원칙**
|
||||
- 무속·도교·불교 계열 용어가 혼재할 수 있음. 사용 전 분류 태그(무속/도교/불교/창작)를 glossary에 명시
|
||||
- 현대 한국어 독자가 직관적으로 인식 가능한 용어를 우선 채택. 고어·한자어 단독 사용 금지 — 괄호 병기 또는 설명 병기 필수
|
||||
- 퇴마 소재 분류: 귀신 계열(원귀·산신·잡귀) / 의식 계열(부적·제사·강령) / 도구 계열(패·혈·주문) 3축으로 나누어 각 축의 용어 일관성을 독립 관리
|
||||
|
||||
**톤앤매너 확정 의무**
|
||||
- 조선 배경 게임은 정극/공포/해학 세 방향이 공존 가능. EerieVillage의 톤을 세계관 SOT에서 단일 기준으로 확정하지 않으면 컨텐츠마다 톤이 어긋난다
|
||||
- 텍스트 톤 확정 후 반드시 샘플 대사 3종(전투 전·이벤트·승리)을 작성해 기준선으로 보관
|
||||
|
||||
### 3-3. C22 용어 일관 사용 — 내러티브 영역 적용
|
||||
|
||||
- 세계관 문서 v1 확정 후 등장하는 고유명사는 이후 세션에서 임의 변형·축약 금지
|
||||
- 예: "퇴마사" 확정 후 다음 세션에서 "무당" "주술사"로 부르지 않는다
|
||||
- glossary가 없으면 C22 위반이 탐지되지 않는다 — glossary 부재 자체를 P18 위반으로 처리
|
||||
|
||||
---
|
||||
|
||||
## 4. PM 보고 안건 (특이사항)
|
||||
|
||||
### 4-1. 내러티브 영역 선행 착수 순서 제안
|
||||
|
||||
EerieVillage에서 내러티브·레벨·컨텐츠 기획의 **착수 순서 의존성**이 수상한잡화점보다 훨씬 강하다.
|
||||
|
||||
- 수상한잡화점: 내러티브 없이 스테이지 노드 구성 착수 가능 (덱빌딩은 수치가 세계관보다 선행)
|
||||
- EerieVillage: "조선 퇴마"라는 테마 자체가 지역명·몬스터명·아이템명·스킬명의 근거. **세계관 SOT 없이 레벨·컨텐츠 착수 시 용어 충돌 필연적 발생**
|
||||
|
||||
권고 착수 순서 (PM 확인 필요 사항):
|
||||
1. 세계관 SOT v1 (narrative-designer)
|
||||
2. glossary v1 (narrative-designer)
|
||||
3. 지역·몬스터·아이템 명명 가이드라인 (narrative-designer → content/level-designer 협업)
|
||||
4. 레벨·컨텐츠 기획 착수
|
||||
|
||||
이 순서는 P23 기획 결정 재량 범위를 초과하므로 PM 확인 후 PD님 승인을 통해 프로젝트 가이드라인으로 확정 권고.
|
||||
|
||||
### 4-2. 명확한 교훈 희소 — 솔직 보고
|
||||
|
||||
수상한잡화점 내러티브 산출물 부재로 "이렇게 했더니 실패했다" 형태의 직접 교훈은 존재하지 않는다. 본 아카이브는 조직 운영 레벨 관찰(C22·P18 적용 맥락)과 EerieVillage 전용 출발 원칙 선언이 교훈의 본체다.
|
||||
|
||||
---
|
||||
|
||||
## 5. 참조 원본 파일 목록 (감사 재현 가능)
|
||||
|
||||
| 파일 | 확인 내용 | 실측 결과 |
|
||||
|------|----------|----------|
|
||||
| `프로젝트/수상한잡화점/기획/` 전체 | 세계관·스토리·캐릭터·대사·용어사전 해당 파일 | 부재 확인 |
|
||||
| `공유/대화로그/수상한잡화점/2026-04-16.md` | 내러티브 관련 결정·작업 언급 | 부재 확인 |
|
||||
| `공유/대화로그/수상한잡화점/2026-04-17.md` | 내러티브 관련 결정·작업 언급 | 부재 확인. `Phase3_재개준비_체크리스트_v1.md` 내 "시나리오기획자 — 비주요" 1줄만 존재 |
|
||||
| `공유/대화로그/수상한잡화점/2026-04-20.md` | 내러티브 관련 결정·작업 언급 | 부재 확인 |
|
||||
| `.claude/agents/narrative-designer.md` | 에이전트 정의·산출물 이력 | 에이전트 정의 존재, 호출·산출물 이력 없음 |
|
||||
| `.claude/agents/content-designer.md` | narrative와의 협업 원칙 언급 | "세계관·대사·이름의 톤은 시나리오 기획자와 맞춰야 한다" — 원칙 존재, 실증 없음 |
|
||||
| `공유/대화로그/조직운영/2026-04-18.md` | C22 용어 일관 사용 신설 경위 | 헌법 원칙 번호 ①~⑤ 형식 관련 기각안에서 C22 언급 확인 |
|
||||
|
||||
---
|
||||
|
||||
> **변경 이력**: 2026-04-21 최초 작성 (narrative-designer, BurningTimes 조직 신설 Phase 2-A)
|
||||
|
|
@ -0,0 +1,145 @@
|
|||
---
|
||||
type: 시행착오_아카이브
|
||||
domain: 기획 / 시스템 설계
|
||||
source_project: 수상한잡화점 (NerdNavis → BurningTimes 전환 전 최종 상태)
|
||||
target_project: EerieVillage (기묘한 고을: 조선퇴마뎐)
|
||||
작성일: 2026-04-21
|
||||
---
|
||||
|
||||
# 기획 시스템 설계 시행착오 아카이브 v1
|
||||
|
||||
---
|
||||
|
||||
## 섹션 1. 잘 작동한 것
|
||||
|
||||
### 1-1. Prove-2-of-3 ★ 조건 체계
|
||||
|
||||
"스테이지 클리어 + 슬롯2·슬롯3 조건 2개 동시 달성"으로 3성을 구조화한 것이 성공적이었다.
|
||||
|
||||
성공 요인 3가지:
|
||||
1. **조건 풀 확정 → 배치 분리**: PD 승인으로 조건 12개를 먼저 확정한 뒤 스테이지 배치를 진행했다. 밸런싱 검증과 규칙 위반 체크를 독립 수행할 수 있었다.
|
||||
2. **C 계열(스테이지 전체) / N 계열(서브맵 단위) 이원 분류**: 레벨 설계자의 배치 의도를 명확히 표현하는 기반이 됐다.
|
||||
3. **"재도전 유도" 방향 명시**: 임계값 튜닝 기준이 "완화"가 아닌 "재도전 유도"로 고정되어 의사결정 경계가 명확했다.
|
||||
|
||||
EerieVillage 이식 시: 2-of-3 구조·풀 사전 확정 절차·재도전 유도 원칙은 계승한다. 조건 내용(HP·피격·포션 등)은 2D 플랫포머 퇴마 메카닉에 맞게 전면 재설계한다.
|
||||
|
||||
---
|
||||
|
||||
### 1-2. 배타 조합 규칙 선제 정의 (P17 방법론)
|
||||
|
||||
배치 착수 전에 동시 배치 금지 조합 7종을 명문화한 것이 실제 오류를 차단했다.
|
||||
|
||||
| 배타 조합 | 기각 이유 |
|
||||
|---------|---------|
|
||||
| C2(완벽 클리어) ∧ N2(피격 제한) | 동일 축(피격 최소화) 이중 부담 |
|
||||
| C9(보스 집중) ∧ 보스 미등장 스테이지 | 보스 없으면 조건 논리 불성립 |
|
||||
| N5(후열 선공) ∧ N6(전열 선공) | 타겟팅 자유도 동시 박탈 — 플레이어 선택 불가 |
|
||||
|
||||
EerieVillage: 신규 조건 풀 정의 시 배타 조합을 반드시 동시 정의한다. 배치 단계 즉석 판단은 누락을 유발한다. 체크 3문항: (1) 동일 플레이 축 중복, (2) 특정 스테이지 구성에서 논리 불성립, (3) 특정 빌드를 배타적으로 배제하는 조합.
|
||||
|
||||
---
|
||||
|
||||
### 1-3. 어뷰징 판정 — 클라 주도 + 서버 플래그 수신 구조
|
||||
|
||||
초기 설계는 서버가 경계값 테이블을 직접 검증하는 구조였다. PD님 재결정으로 "클라 판정 → `is_abuse_flag` 서버 전송 → 서버는 플래그 수신 시 지급 거부"로 정리됐다.
|
||||
|
||||
싱글 플레이 구조에서 이 구조가 적합한 이유: 서버 재시뮬레이션은 CPU 폭증 + 난수 동기화 이슈(기각안 G-1), 경계값을 서버에 두면 클라 업데이트마다 동기화 의존성 발생. F1(플래그만) / F2(보상 보류) / F3(미지급) 3단계 체계가 false positive 관리와 어뷰저 학습 방지를 양립시켰다.
|
||||
|
||||
EerieVillage: 경계값은 시뮬레이터 극값 × 안전마진 계수로 산출한다. 시뮬레이터 가동 전까지 플레이스홀더로 기획서를 발행하고 수치 미확정을 명시한다.
|
||||
|
||||
---
|
||||
|
||||
## 섹션 2. 실패한 것 (반복 금지)
|
||||
|
||||
### 2-1. 데이터 구조 미검증 기반 기획 착수
|
||||
|
||||
Phase 4 지역 1 노드 구성 v1은 "지역 1 = Stage 1~6 = 6개"를 전제로 설계됐다. `CreateMapConfig.csv` 실측 결과 실제 구조는 21개 지역 × N개 스테이지 = 총 122 스테이지이며, 지역 1은 Stage1_1~1_4 = 4개였다.
|
||||
|
||||
결과: v1 전체 폐기 + 데이터 구조 재정비(#42) · 기획팀 실측 의무 문서(#43) · v2 재작성(#44) 3종 동시 집행.
|
||||
|
||||
근본 원인: Unity Export 원본 CSV를 직접 실측하지 않고 2차 해석 문서 표현("WorldMap 4그룹")에 의존했다.
|
||||
|
||||
EerieVillage 재발 방지: 레벨·스테이지 구성 파일 전수 실측 후 PD 확정 용어와 일치 확인. 이전 프로젝트 설계 재사용 시에도 신 프로젝트 데이터 정합성 재확인.
|
||||
|
||||
---
|
||||
|
||||
### 2-2. 테이블 수치 파싱 로직 미확인 기반 밸런싱
|
||||
|
||||
`PCAwakening.json`의 `s_Value` 컬럼에 `'5'`와 `'500%'`가 혼재했다. 기획팀은 `'500%'`를 "기존 스탯의 500% 배율"로 해석하여 각성 만렙 DPS +1067%라는 이상 수치를 산출했다.
|
||||
|
||||
실제 파싱 로직: `% 포함 시 숫자 × 0.01f` → `'500%'` = `5.0f` = `'5'`와 동일. 실제 효과는 고정값 +9 수준이었다.
|
||||
|
||||
EerieVillage 원칙: `%` 표기 컬럼은 파싱 코드 경로 확인 후 적용한다. 목표치 대비 10배 이상 이상치가 나오면 해석 오류를 먼저 의심하고 개발팀 REQ를 발행한다.
|
||||
|
||||
---
|
||||
|
||||
### 2-3. 디버프 설계 미명문화 — 음수값 혼동
|
||||
|
||||
`EquipmentList.json` 분석 중 풀셋 장착 시 `CriDmg -20%`, `Avoid_Melee -3%` 등 음수 합산 발견. 기획팀은 오류 여부를 판단하지 못하고 REQ를 발행했다.
|
||||
|
||||
실측 결과 의도적 트레이드오프 설계였다. `UpgradeVal=0`이라 강화해도 완화되지 않는 고정 디버프 구조. `AttackCoolTime -10%`는 예외적으로 음수지만 공격속도 증가(긍정 효과)였다.
|
||||
|
||||
EerieVillage 원칙: 장비 시스템 설계 명세서에 "어떤 부위가 어떤 스탯에 디버프 부여", "강화로 완화 가능 여부", "음수 = 긍정 효과인 스탯 목록"을 명시한다.
|
||||
|
||||
---
|
||||
|
||||
### 2-4. 코드 하드코딩 수치를 테이블에서만 탐색
|
||||
|
||||
인장 기본 슬롯 수를 `GlobalValue.json`에서 찾지 못해 REQ를 발행했다. 실측 결과 `ServerClass.cs`에 `list_equipseal = new List<uint> { 0, 0, 0, 0, 0, 0 }`으로 하드코딩. 슬롯 개방 조건(진화 단계별)과 속성 매칭 제한도 코드 로직에 있었다.
|
||||
|
||||
EerieVillage 원칙: 기획 착수 전 "테이블 관리 수치"와 "코드 하드코딩 수치"를 개발팀과 합의하고 문서화한다.
|
||||
|
||||
---
|
||||
|
||||
## 섹션 3. 미해결 채로 남긴 것
|
||||
|
||||
### 3-1. ★ 조건 임계값 — 시뮬레이터 의존 미완결
|
||||
|
||||
조건 체계 구조는 확정됐으나 구체적 임계값(C1 신속 N초, N2 피격 제한 서브맵수×1 등)은 전부 플레이스홀더 상태로 종결됐다. EerieVillage 교훈: 문서 `status` 필드로 "구조 확정·임계값 플레이스홀더"와 "임계값 확정" 상태를 구분한다.
|
||||
|
||||
### 3-2. 어뷰징 경계값 — 전수 플레이스홀더 상태 종결
|
||||
|
||||
기획서 v1의 모든 경계값은 플레이스홀더다. 기각된 대안(서버 재시뮬·ML 탐지·클라 단독 판정·전체 로그 전송)과 기각 사유는 기획서 G 섹션에 보존되어 있다. EerieVillage 어뷰징 방어 설계 시 해당 기각안을 먼저 참조한다.
|
||||
|
||||
---
|
||||
|
||||
## 섹션 4. 의사결정 경계 (P23 기준)
|
||||
|
||||
| 수준 | 해당 사례 |
|
||||
|-----|---------|
|
||||
| 기획팀장 재량 | 조건 판정 로직 의사코드 · 배타 조합 초안 · 어뷰징 프레임워크 구조 |
|
||||
| PM 확인 필요 | 신규 시스템 기획서 최초 발행 · 개발팀 영향 REQ 발행 |
|
||||
| PD 확인 필수 | 지역·스테이지 수량 변경 · 조건 풀 추가·삭제 · 어뷰징 판정 주체 전환 · 보상 체계 방향 전환 |
|
||||
|
||||
---
|
||||
|
||||
## 섹션 5. EerieVillage 즉시 적용 권장
|
||||
|
||||
### 5-1. 조건 체계 설계 절차 (검증된 순서)
|
||||
|
||||
```
|
||||
1단계: 장르 메카닉 분석 → 유저 컨트롤 가능한 행동 축 열거
|
||||
2단계: 조건 후보 초안 (10~15개) 작성
|
||||
3단계: 각 조건별 배타 조합 동시 정의
|
||||
4단계: PD 승인으로 조건 풀 확정
|
||||
5단계: 스테이지별 배치 (4단계 이전 배치 착수 금지)
|
||||
6단계: 임계값 설정 (시뮬레이터 또는 플레이테스트 기반)
|
||||
```
|
||||
|
||||
### 5-2. 기획 착수 전 데이터 실측 체크리스트
|
||||
|
||||
1. 레벨·스테이지 구성 파일 전수 실측
|
||||
2. 성장 시스템 파싱 로직 코드 레벨 확인
|
||||
3. 장비·아이템 옵션 체계 (음수값 의미 포함)
|
||||
4. 코드 하드코딩 수치 목록 (테이블 외 관리 항목)
|
||||
|
||||
### 5-3. 어뷰징 방어 설계 시작점
|
||||
|
||||
1. 어뷰징 공격 벡터 열거 (AV 번호 부여)
|
||||
2. 물리적 불가능 / 확률적 극단 / 논리적 모순 3범주 분류
|
||||
3. 판정 책임 주체 확정 (싱글 플레이: 클라 주도 + 서버 플래그 수신 권장)
|
||||
4. 경계값은 플레이스홀더로 기획서 발행 후 시뮬레이터 결과로 채워 넣기
|
||||
|
||||
---
|
||||
|
||||
*참조: 공유/조직공지/방향전환_히스토리_아카이브.md*
|
||||
|
|
@ -0,0 +1,105 @@
|
|||
# UI/UX 시행착오 아카이브 — 수상한잡화점 (ux-designer 관점)
|
||||
|
||||
> **작성일**: 2026-04-21
|
||||
> **작성자**: ux-designer (BurningTimes)
|
||||
> **참조 프로젝트**: NerdNavis — 수상한잡화점 (DeckBuilding)
|
||||
> **목적**: BurningTimes 신설 조직의 EerieVillage 착수 시 UI/UX 재발 방지 및 검증된 패턴 계승
|
||||
|
||||
---
|
||||
|
||||
## 1. 개요 (핵심 교훈 요지)
|
||||
|
||||
수상한잡화점에서 **UX 전용 기획 문서는 작성되지 않았다**. 화면 플로우, 와이어프레임, HUD 명세, 조작 스킴 기획서가 기획팀 산출물로 존재하지 않으며, UI 구조와 조작 인터페이스는 **개발팀이 단독으로 설계·문서화**하였다. 이로 인해 다음 교훈이 도출된다.
|
||||
|
||||
1. **UX 기획 부재 → 기획-개발 수치 불일치**: 방어 감소율이 기획 가정 50%였으나 실제 코드 30%로 구현됨. SOT(단일 진실 출처)가 없어 세 가지 자료(기획 문서·시뮬레이션·Unity 코드)가 모두 다른 수치를 가졌고, 개발팀 실측 전까지 불일치가 인지되지 않았다.
|
||||
2. **UX는 기획팀이 소유해야 한다**: 조작 스킴·화면 플로우·피드백 명세가 개발팀에 위임되면, 플레이어 경험 관점의 검토 없이 구현 편의 중심으로 결정된다. P18(설계 문서화 의무)에 따라 UX 결정사항은 반드시 기획팀 문서로 명문화해야 한다.
|
||||
3. **범용 UI 컴포넌트 7종 식별 완료**: SafeArea, Toast, InputBlocker, VirtualScroll, BackKeyDispatcher, UIView 추상 베이스, AtlasManager. 이 중 SafeArea·BackKeyDispatcher·InputBlocker는 모바일 2D 플랫포머에서도 즉시 재사용 가능하다.
|
||||
4. **터치 조작 아키텍처는 계승 가능**: UITouchHandler(IPointerDownHandler·IPointerUpHandler·IPointerExitHandler) 패턴은 장르 무관하게 재사용 가능한 구조다. 수상한잡화점의 방어 메커닉 수치는 플랫포머에 그대로 쓸 수 없으나 인터페이스 설계는 EerieVillage에 그대로 적용된다.
|
||||
5. **Android BackKey는 초기부터 통합 설계 필요**: 수상한잡화점은 BackKey 전용 디스패처(BackKey/ 디렉토리)를 별도 구축하였다. 착수 초기 미처리 시 팝업·화면 전환 구조가 확정된 후 소급 적용이 어렵다.
|
||||
|
||||
**미확인 항목 (C23 정직성)**: 화면 전환 애니메이션 명세, 로딩 화면 UX 기획, 접근성 대응 기록, 플랫포머 조작 스킴 설계는 수상한잡화점에 기록이 없어 본 아카이브에서 교훈 추출 불가. EerieVillage 착수 시 신규 설계 대상이다.
|
||||
|
||||
---
|
||||
|
||||
## 2. 시도한 방법 · 이유 · 결과 · 교훈
|
||||
|
||||
| # | 시도한 방법 | 이유 | 결과 | 교훈 |
|
||||
|---|------------|------|------|------|
|
||||
| 1 | UX 전용 기획 문서 미작성 — 조작·화면 구조를 개발팀에 일임 | 카드 전략 게임이라 조작이 단순하다고 판단, 기획 리소스를 밸런스·컨텐츠에 집중 | 기획-코드 수치 불일치(방어 50%→30%)가 개발팀 실측 전까지 3개월 이상 미발견. UX 결정 근거가 문서 없이 코드에만 존재 | **UX 설계 문서는 장르 단순도에 관계없이 필수**. 기획팀이 조작 스킴·수치·피드백을 명세하고 개발팀이 구현 검증하는 구조가 SOT를 보장함 |
|
||||
| 2 | 터치 방어 메커닉 구현 — UITouchHandler(IPointerDown·Up·Exit) + Down↔Up 지속형 | 버튼 누름 동안 방어 지속이 직관적이라 판단 | 구현 안정적. 그러나 기획 가정(단일 공격 차단)과 달리 지속형으로 구현되어 의도 불일치가 발견됨 | **조작 방식(단발 vs 지속)은 기획팀이 명세해야 한다**. UITouchHandler 아키텍처 자체는 재사용 가능하나 행동 정의는 기획 문서에서 출발해야 함 |
|
||||
| 3 | SafeArea 컴포넌트 독립 구현 (FilGoodBandits 네임스페이스 유일 사용) | 노치·홈 인디케이터 대응이 필수 | 정상 동작. 전체 코드베이스에서 유일하게 네임스페이스를 사용한 컴포넌트로, 범용성이 이미 설계 수준에서 고려됨 | **SafeArea는 BT.Framework에 우선 편입 대상**. 모든 모바일 프로젝트에서 필요하며, 초기 씬 구성 시 SafeArea 없이 개발 시작하면 레이아웃 소급 수정 비용이 큼 |
|
||||
| 4 | Android BackKey 통합 디스패처 별도 구축 (BackKey/ 디렉토리) | 팝업 중첩·화면 스택 구조에서 BackKey 처리가 분산되면 충돌 위험 | 정상 동작. BackKeyDispatcher 패턴이 안정적으로 확립됨 | **BackKey는 첫 씬 구성 시 설계에 포함**. 팝업·화면 전환 구조 확정 전에 BackKey 정책(스택 기반 vs 전역 리스너)을 결정해야 한다 |
|
||||
| 5 | Lobby·Ingame 각 19개 스크립트 구성 — LobbyUIManager·IngameUIManager 진입점 중심화 | 씬별 UI 책임을 매니저가 집중 관리하여 진입 경로 단순화 | 구조 안정적. SelectCardUI(290 LOC)가 단일 모듈 최대 크기로 성장하여 책임 범위 경계가 일부 모호해짐 | **화면 단위 UI 모듈은 300 LOC 초과 시 분리 검토**. 기획 측면에서 "한 화면 한 결정" 원칙(UX 원칙)이 코드 분리 기준과 일치함 |
|
||||
| 6 | 카드 선택 UI(SelectCardUI) — 전투 중 카드 선택·사용 통합 관리 | 전투 중 핵심 인터랙션으로 단일 진입점 집중 | 290 LOC로 성장. 카드 조건 변경 시 이 파일이 단일 수정 대상이 되어 기획-개발 연동 포인트가 명확함 | **기획 변경이 빈번한 UI는 연동 포인트를 기획팀이 미리 파악해야 한다**. 수상한잡화점에서는 개발팀 문서에서 사후 파악됨 |
|
||||
| 7 | DungeonProcess UI — 스테이지 맵 진행 상태 표시 | 탐험 흐름을 시각화하여 진행 위치 피드백 | 동작 확인. 그러나 기획 단계에서 맵 패턴 변경 시 UI 영향도가 명시적으로 추적되지 않아 개발팀 문서에 영향 관계 파악 기록이 별도 작성됨 | **기획 변경(맵 패턴) → UI 영향(DungeonProcess) 연동 매트릭스를 기획팀이 유지**해야 함. 개발팀에 위임하면 기획 변경 시 영향 범위 파악이 늦어짐 |
|
||||
|
||||
---
|
||||
|
||||
## 3. EerieVillage 착수 체크리스트 (BT 조직 적용)
|
||||
|
||||
EerieVillage는 Unity 6000.3.13f1 LTS + 2D PlatformerMicrogame 템플릿 기반 모바일 게임이다. 수상한잡화점과 **장르가 다르므로**(덱빌딩 카드 → 2D 플랫포머) 수치 재사용 금지, 아키텍처 패턴만 선택적 계승.
|
||||
|
||||
### 3-1. UX 기획 문서 선행 작성 (착수 전 필수)
|
||||
|
||||
1. **화면 플로우 문서**: 타이틀 → 메인 메뉴 → 스테이지 선택 → 인게임 → 결과 화면 전이 명세. 예외 경로(네트워크 오류·사망·일시정지) 포함
|
||||
2. **조작 스킴 명세**: 이동(좌·우), 점프, 공격, 상호작용, 아이템 사용 — 버튼 위치·크기(최소 44×44pt), 동시 입력 충돌 정책, 이동 중 공격 허용 여부
|
||||
3. **HUD 정보 우선순위 명세**: 한 화면에서 보여줄 최소 정보 정의 (HP·스테이지 진행·인벤토리 슬롯 등 우선순위 3단계)
|
||||
4. **피드백 명세**: 피격·사망·아이템 획득·스테이지 클리어 각각 0.1초 이내 인지 가능한 피드백 요구사항. 시각/청각/진동 구분하여 "긍정 피드백 필요", "부정 피드백 필요" 수준으로 명세 (아트·사운드 영역은 기능 요구로만 정의)
|
||||
|
||||
### 3-2. SafeArea 초기 적용
|
||||
|
||||
1. 씬 구성 첫날 SafeArea 컴포넌트 적용 — 노치·홈 인디케이터 영역 침범 방지
|
||||
2. BT.Framework SafeArea 편입 여부 확인. 미편입 시 수상한잡화점 구현 계승
|
||||
3. 버튼·HUD 배치 전 SafeArea 경계 확정
|
||||
|
||||
### 3-3. 모바일 터치 영역 설계
|
||||
|
||||
1. **최소 터치 영역**: 이동·점프·공격 버튼 최소 44×44pt (iOS HIG 기준). 빈번 조작 버튼은 60×60pt 이상 권장
|
||||
2. **엄지 도달 범위**: 세로 모드 기준 화면 하단 20% 영역에 주요 조작 버튼 배치. 상단 25% 영역은 HUD 전용
|
||||
3. **동시 입력 처리**: 이동+점프, 이동+공격 동시 입력 허용 여부를 기획 명세로 사전 결정. UITouchHandler 패턴(IPointerDown·Up·Exit) 재사용 가능
|
||||
4. **인게임 화면 방향**: 가로(Landscape) vs 세로(Portrait) 결정 후 전체 레이아웃 설계 시작. 미결정 상태에서 UI 작업 착수 금지
|
||||
|
||||
### 3-4. BackKey 정책 초기 결정
|
||||
|
||||
1. BackKey(Android) 동작 정책: 일시정지 팝업 표시 vs 스테이지 처음으로 vs 메인 메뉴 이동 중 택1
|
||||
2. 팝업 중첩 시 BackKey 스택 순서 정의
|
||||
3. BackKeyDispatcher 패턴 초기 설계에 포함. 팝업 추가 후 소급 적용 금지
|
||||
|
||||
### 3-5. 기획-개발 UX 연동 체계
|
||||
|
||||
1. **UX 수치 SOT 지정**: 기획팀 문서가 수치의 단일 진실 출처. 개발팀은 구현 시 기획팀 문서 참조. 불일치 발견 즉시 C3 보고
|
||||
2. **UI 영향 연동 매트릭스 유지**: 기획 변경(스테이지 구조·아이템·몬스터) 시 영향받는 UI 모듈 목록을 기획팀이 유지
|
||||
3. **기획팀 주도 UX 리뷰**: 개발 구현 후 기획팀이 실제 동작 검증. "기획 의도와 다르면 즉시 C3 보고"를 기본 협업 절차로 설정
|
||||
|
||||
### 3-6. 접근성 기본 적용 (착수 시 포함)
|
||||
|
||||
1. 텍스트 최소 크기: 본문 14pt 이상, 버튼 레이블 12pt 이상
|
||||
2. 색맹 대응: 색상만으로 상태를 구분하지 않음 (아이콘·패턴 병용)
|
||||
3. 일시정지·자동 진행 옵션: 컷씬·연출 스킵 기능 초기 설계에 포함
|
||||
4. 진동(햅틱) 피드백은 설정에서 끄기 가능하도록 설계
|
||||
|
||||
---
|
||||
|
||||
## 4. PM 보고 안건 (특이사항)
|
||||
|
||||
1. **UX 기획 공백 확인**: 수상한잡화점 기획팀은 UI/UX 전용 문서를 작성하지 않았음. EerieVillage 착수 전 기획팀 내 ux-designer 역할 업무 범위를 명확히 합의하고, P18(설계 문서화 의무)에 따라 UX 문서 작성을 기획팀 착수 업무 1순위로 배정할 것을 권고.
|
||||
2. **BT.Framework UI 컴포넌트 편입 안건**: SafeArea·Toast·InputBlocker·BackKeyDispatcher 4종은 EerieVillage에서 즉시 필요하며 범용성이 검증됨. 코어 프레임워크 담당자에게 Tier 1 편입 여부 확인 필요.
|
||||
3. **기획-개발 수치 불일치 재발 방지**: 수상한잡화점의 방어 감소율 불일치 사례를 EerieVillage에서 재발시키지 않으려면 **UX 수치 SOT 규칙**(기획 문서가 단일 기준, 코드가 이를 구현, 불일치 즉시 보고)을 팀 착수 시 명시적으로 합의해야 함.
|
||||
|
||||
---
|
||||
|
||||
## 5. 참조 원본 파일 목록 (감사 재현 가능)
|
||||
|
||||
| 파일 | 핵심 참조 내용 |
|
||||
|------|-------------|
|
||||
| `프로젝트/수상한잡화점/개발/11_UI아키텍처_v1.md` | UGUI 전체 구조, 38개 UI 스크립트 목록, BT.Framework 흡수 후보 7종, 기획 연동 포인트 |
|
||||
| `프로젝트/수상한잡화점/개발/08_전투시스템_SOT_v1.md` | UITouchHandler 구현, 터치 방어 메커닉 실측 확정값(PCDefence_Mul=0.3), Down↔Up 지속형 |
|
||||
| `프로젝트/수상한잡화점/개발/02_개발자관점_점검_v1.md` | 기획-코드 불일치 이슈(방어 50% vs 30%) 최초 보고 |
|
||||
| `프로젝트/수상한잡화점/개발/03_Unity프로젝트_구조_v1.md` | 모바일 패키지 목록(Adaptive Performance), 네임스페이스 현황, SafeArea 위치 |
|
||||
| `프로젝트/수상한잡화점/기획/` (폴더 전수 확인) | UX 전용 문서 없음 실측 (24개 파일 전수 — 밸런스·스테이지·카드 기획만 존재) |
|
||||
| `프로젝트/EerieVillage/README.md` | 신 프로젝트 기본 정보(Unity 6000.3.13f1 LTS, 2D PlatformerMicrogame 템플릿) |
|
||||
| `공유/조직자산/시행착오_아카이브/README.md` | 본 파일 등록 대상 확인 |
|
||||
|
||||
---
|
||||
|
||||
*본 문서는 실측 기반으로 작성되었으며, UX 기획 문서가 수상한잡화점에 존재하지 않음을 확인한 상태에서 개발팀 산출물에서 추출한 UX 인사이트를 중심으로 구성하였다. 미확인 항목(화면 전환 애니메이션 명세, 로딩 UX 등)은 EerieVillage 신규 설계 대상임.*
|
||||
|
|
@ -0,0 +1,298 @@
|
|||
---
|
||||
type: 시행착오_아카이브
|
||||
scope: 기획팀_통합
|
||||
author: 기획팀장
|
||||
date: 2026-04-21
|
||||
version: v1
|
||||
project_source: 수상한잡화점 (NerdNavis, 2025-2026)
|
||||
project_target: EerieVillage (BurningTimes, 2026~)
|
||||
sub_scope:
|
||||
- 시스템 기획 (system-designer)
|
||||
- 컨텐츠 기획 (content-designer)
|
||||
- 레벨 기획 (level-designer)
|
||||
- 시나리오 (narrative-designer)
|
||||
- 밸런스 (balance-designer)
|
||||
- UX (ux-designer)
|
||||
---
|
||||
|
||||
# 기획팀 통합 시행착오 아카이브 v1 — 시스템·컨텐츠·레벨·시나리오·밸런스·UX 총괄 관점
|
||||
|
||||
## 1. 개요 — 핵심 교훈 10건 요지
|
||||
|
||||
1. **"데이터 구조 실측 선행"이 기획팀 전체의 제1원칙이다.** "WorldMap 4그룹" 추측 SOT가 Phase 4 지역 1 v1 전체를 폐기시킨 사건은 기획팀 역사상 최대 재작업 사례. CSV/JSON Export 실측 없는 기획 작업은 시한폭탄이다.
|
||||
2. **Phase 범위 재정의는 기획팀장 재량을 넘어 PD님 승인 영역이다.** Phase 3를 "설계 체계 확립"으로 재정의하고 Day 15+를 Phase 4로 분리한 결정은 PD B안 수용 전제 위에서만 집행 가능했다.
|
||||
3. **PD님 확정 용어는 절대 변형·축약 금지.** "Phase 1~4"를 "A/B/C/D"로 재매핑하거나, "지역"을 "WorldMap 그룹"으로 치환하는 것은 C22 위반이자 재작업의 직접 원인.
|
||||
4. **재미 판단은 기획팀 고유 영역이지만, 수치 판단은 개발팀 C11과 조율 필수.** P30(재미 우선) 전제 위에 C11(자원 효율·코드 구조·범용성) 충돌이 발생하면 PM·PD님 판단으로 에스컬레이션.
|
||||
5. **"설계 원칙 vs 임시 데이터" 분리 구조가 차기 프로젝트 자산 계승의 핵심.** C9 배치 원칙·P17 배타 체크·TTK 산출·AppearGroup 가이드 4종은 수치와 독립적으로 유효해야 P29 실현.
|
||||
6. **★ 조건 배타 조합 P17 7종은 매 스테이지 전수 체크 의무.** 단일 스테이지 위반 1건이라도 감지 시 Phase 즉시 중단 + PD 확인 (PD B 방식). 추후 발견되는 것보다 집행 초입 차단이 훨씬 저렴하다.
|
||||
7. **기존 SOT 맹신 금지 — "이전 문서에 쓰여 있으니까"는 근거가 아니다.** `스테이지난이도곡선_v1` §1의 "WorldMap_1~4 4개 그룹" 전제를 Phase 3 종결 문서·Phase 4 착수 가이드·지역 1 v1까지 무비판 계승한 결과 지역 1 v1 전면 폐기.
|
||||
8. **어뷰징 판정 솔루션은 기획팀이 "프레임워크·경계값 산출 방법론"까지만 책임.** 실 검증 로직은 서버팀 이관 (역할 경계 명확). 기획팀이 서버 검증 코드까지 설계하면 C11 개발 관점 원칙 침범.
|
||||
9. **병렬 호출 체계(기획팀장 + level + balance 병렬)는 청크 단위 독립 작업에 최적.** Day 11~14 레벨축·밸런스축을 병렬 집행한 결과 일정 단축 + 교차 검증 품질 확보. 단 의존 작업은 순차.
|
||||
10. **전문 에이전트 6종에 P24 기각안 필수화·P16 변경 이력 필수화는 조직 기억 축적의 핵심 인프라.** 기획 결정의 "왜 그렇게 결정했고 어떤 대안을 기각했는가"가 차기 프로젝트 의사결정에 직접 활용됨.
|
||||
|
||||
---
|
||||
|
||||
## 2. 시도한 방법·이유·결과·교훈 (4필드 표)
|
||||
|
||||
### 2-1. 데이터 구조·용어 관리
|
||||
|
||||
| 시도한 방법 | 이유 | 결과 | 교훈 |
|
||||
|------------|------|------|------|
|
||||
| `스테이지난이도곡선_v1` §1에 "WorldMap_1~4 4개 그룹"을 SOT로 기재 | 초기 기획 단계에서 편의상 구간 분류 (입문·초반·중반·후반) | Unity Export CSV 실측 결과 실제 구조는 **WorldMap = 21개 지역** · "4개 그룹"은 기획 레이블일 뿐 데이터 구조 아님 | 기획 레이블(구간)과 데이터 구조(지역·스테이지)를 **명시적으로 분리 표기**. "4개 그룹"은 SOT 자격 없음 |
|
||||
| 후속 문서들(`Phase3_종결_설계체계_v1`·`Phase4_노드구성_착수가이드_v1`)이 위 SOT를 무비판 인용 | 기존 문서 재활용·일관성 유지 | 오해 계승 누적 → `Phase4_지역1_노드구성_v1` 전체를 "지역 1 = Stage 1~6 = 6개"로 설계 → **전면 폐기** | **기존 SOT 맹신 금지 (§1-4 룰)** 신설. 참조 시점 실측 재수행 의무 |
|
||||
| 기획 문서 상단에 "데이터 소스" 필드 부재 | 관행상 출처 기재 생략 | 어느 문서의 어느 수치가 언제 실측됐는지 추적 불가 | 기획 문서 상단 프론트매터에 **"데이터 소스: CSV명 (실측 YYYY-MM-DD)"** 필수화 |
|
||||
| 용어 혼선: "기획실·개발실"(구명칭) vs "기획팀·개발팀"(신명칭) 7개 기획 문서 112회 잔존 | 2026-04-16 조직 명칭 전환 공지 수령 후 기존 산출물 일괄 치환 누락 | plan-auditor 교차 검증에서 C5 정직성 위반 위험 지적. 신규 에이전트가 구 체계 오해 가능 | 조직 명칭 변경 시 **기획 산출물 전수 grep + 일괄 치환** 기획팀장 재량 집행 의무 (C22 용어 일관) |
|
||||
|
||||
### 2-2. Phase 관리·범위 조정
|
||||
|
||||
| 시도한 방법 | 이유 | 결과 | 교훈 |
|
||||
|------------|------|------|------|
|
||||
| Phase 3 초기 범위를 "Day 1~15+ 성장 요소 기여도 + 맵 패턴 실 배치 + v2 최종본"으로 광역 설정 | 한 번의 Phase에서 설계 + 실배치까지 끝내려는 욕심 | Day 11~14 완료 후 "현 스테이지 데이터 = 임시"라는 근본 문제 식별. 실 배치는 임시 데이터 기반이면 의미 제한적 | PD B안 수용으로 **Phase 3 = "설계 체계 확립"** 재정의 + **Phase 4 = "스테이지별 노드 구성"** 분리. Phase는 **결과물 성격**으로 구분 |
|
||||
| Day 8~10 이슈 1·3(카드 G1 풀빌드 +399%, 신성 빌드 확장성) 재조사 방향 검토 | 밸런스 완결성 확보 | PD A안 수용 "무시해도 될 문제" → 재조사 불요 · 간략화 종결 | 이슈 우선순위는 **PD 판단 선행** (C1 지시=승인). 기획팀이 "완결성"을 이유로 무한 확장하는 것은 C9(AI 조직 완성도 우선)와 충돌 가능 |
|
||||
| Day 11~14를 기획팀장 단독 순차 집행 | 맥락 유지 편의 | 레벨 관점(맵 구조) + 밸런스 관점(TTK·수치) 교차 검증 누락 우려 | Day 11~14부터 **level-designer + balance-designer 병렬 호출** 도입. 교차 검증 품질 확보 |
|
||||
| Day 15+ 7종 선택지를 "Phase 3 미완료 상태"로 잔존 우려 | 어중간한 종결 회피 | B안 수용 후 3분류 처리: 설계 원칙 성격 3종(Phase 3 종결 문서 §5 집약) + 임시 데이터 수치 3종(Phase 4 이관) + 완료 선언 1종 | 미완료 항목은 **분류·이관·완료 3분기**로 처리. "전부 이관" 또는 "전부 완료"의 단순화 금지 |
|
||||
|
||||
### 2-3. ★ 조건·P17 배타 설계
|
||||
|
||||
| 시도한 방법 | 이유 | 결과 | 교훈 |
|
||||
|------------|------|------|------|
|
||||
| 12개 조건 풀(C1·C2·C3·C6·C9·C12 + N1·N2·N3·N4·N5·N6) 전수 배치 시도 | 조건 다양성 극대화 | P17 배타 조합 7종 위반 다수 발생 가능성 (C2∧N2·C6∧N4·N5∧N6 등) | P17 배타 7종을 SKILL.md P17 SOT로 정식화. 스테이지별 슬롯2·슬롯3 배치 시 **7종 전수 체크** 의무 |
|
||||
| 입문 구간(Stage 1~6)에 C1∧C3·N3·C9 배치 검토 | 초기 난이도 다양화 | 입문 구간 이중 부담 과도 + 치명타 빌드 미형성 + C9 논리 불성립 | P17-4(입문 C1∧C3)·P17-6(입문 N3)·P17-5(C9∧단독/미등장 보스) 명문화. 입문은 **N1·C3·C6·C12·N1·N2·N4·N5·N6** 9종 중심 |
|
||||
| 42 슬롯(21 스테이지 × 슬롯2·3)에 대한 전수 체크 시트 부재 | 개별 스테이지 집중 | 전수 검증 누락 리스크 | `맵패턴_42슬롯_현황테이블_v1` 신설 + P17 전수 체크 시트 템플릿 제작 |
|
||||
| C9(보스 집중) 조건을 단독 보스·보스 미등장 스테이지에 배치 검토 | 조건 적용 유연성 | 논리 불성립 (단독 보스 = C9 자동 충족 → 조건 가치 소멸) | P17-5 명문화 + 3축 검증(조건 의미성·페이싱·재도전 유도) 완료 |
|
||||
|
||||
### 2-4. 밸런스·수치 관리
|
||||
|
||||
| 시도한 방법 | 이유 | 결과 | 교훈 |
|
||||
|------------|------|------|------|
|
||||
| 성장 요소 기여도(#16~#21)를 기획 가정치 기준으로 확정 | 초기 밸런스 빠른 설정 | Unity MCP EditMode UTF 14/14 실측 결과 가정치 대부분 범위 내 Passed지만 **일부(장비 세트 +70% → 실측 +71.46%)는 정확 일치 수준으로 보정** | 밸런스 확정 전 **Unity MCP 실측 선행** 의무. 기획 가정치는 "검증 전 임시"로 태그 |
|
||||
| 카드 G1 풀빌드 DPS 이론 +399%를 "밸런스 이슈"로 판정 | 상한 과도 우려 | PD A안 수용: "특화 빌드 피크치 + 신성 빌드 캐주얼 포지션"으로 수용 확정 | 이론 최대치와 실전 기댓값을 분리 관리. "극단 수치 = 항상 이슈"는 오해. 포지션 명시로 해결 |
|
||||
| 밸런싱 md 4종(`스테이지난이도곡선`·`밸런싱전략`·`전체테이블감사`·`빌드_조건_충돌점검`) 변경 이력 포맷 부재 | 초기 관행 | 변경 근거·시점 추적 불가 | 4종 하단에 **"변경 이력 (P16)"** 섹션 표준화. 필드: 일시/변경자/변경 필드/이전값→이후값/재미 근거/관련 PD 지시# |
|
||||
| 밸런스 수치 변경 요청을 자유 형식으로 개발팀 전달 | REQ 템플릿 부재 | 변경 배경·재미 근거·개발 관점 우려 누락 | `REQ-템플릿_밸런스수치.md` 9개 섹션 표준화 (식별·변경 필드·전후 수치·재미 근거(P30)·개발 관점 우려 예상(C11)·검증 방법·백업 이력(C6·P16)·기각안(P24)·응답 섹션) |
|
||||
|
||||
### 2-5. 개발팀 협업·REQ 체계
|
||||
|
||||
| 시도한 방법 | 이유 | 결과 | 교훈 |
|
||||
|------------|------|------|------|
|
||||
| REQ001 각성트리 퍼센트값(`'500%'` vs `'5'`) 해석 확인 | 밸런스 설계 전제 명확화 | 개발팀 응답: `table_base.Get_Value()` 동일 결과(5.0f) · 데이터 입력 오류·런타임 영향 없음 | 기획팀은 **"코드 근거 있는 데이터 해석 질의"** 패턴 확립. 추측 기반 수치 해석 금지 |
|
||||
| REQ002 장비 옵션 음수값(-20% 치명타 피해 등) 의미 확인 | 페널티 vs 보너스 vs 버그 구분 | 개발팀 응답: **의도적 트레이드오프** · 무기 MainOption2는 페널티 · `AttackCoolTime = -10%`만 공속 보너스 (예외) | 밸런스 설계 시 "음수 = 오류" 가정 금지. 데이터 필드 의미를 **개발팀 교차 검증**한 뒤 밸런싱 반영 |
|
||||
| REQ003 인장 장착수 제한 확인 | 성장 시스템 이해 | 개발팀 응답: 기본 슬롯 6개 · 진화 단계별 순차 개방 · 속성(Element) 매칭 제한 존재 | 성장 시스템 자체 구조를 **숙지 선행** (JSON 데이터 숙지 현황 별도 관리). 기획 결정은 실 코드 구조 전제 위에서만 |
|
||||
| 소통 허브 파일 1건 = 단방향 일회성 사용 | 관행 | 동기 협의 필요 건에서 파일 수 증폭 · 맥락 분산 | **같은 파일 내 `## 응답 (YYYY-MM-DD)` 섹션 append** 패턴 정착 (다회 왕복 기본값). 3회 왕복 이상 시 PM 에스컬레이션 |
|
||||
|
||||
### 2-6. 어뷰징 판정 기획 → 서버 이관
|
||||
|
||||
| 시도한 방법 | 이유 | 결과 | 교훈 |
|
||||
|------------|------|------|------|
|
||||
| 어뷰징 판정 솔루션을 기획팀이 경계값 + 검증 로직 전수 설계 | 완결성 | C11 개발 관점 원칙 침범 우려 (서버 영역 로직 설계는 서버팀 책임) | 기획팀은 **"프레임워크·경계값 산출 방법론·스키마"**까지 · 실 검증 로직은 서버팀 이관. `2026-04-17_어뷰징판정_솔루션_기획서_v1.md` 7섹션(A 문제 정의 ~ F 서버팀 인계 · G 운영) 구조 정립 |
|
||||
| 안전 마진을 일괄 10%로 설정 시도 | 단순화 | false positive(정상 유저 오판정) · false negative(어뷰저 누락) 균형 실패 | 벡터 특성별 마진 차등: 클리어타임 **0.80**(프레임 드랍 흡수) · 획득 재화 **1.05**(반올림 흡수) · 랭킹 점수 **1.10**(업데이트 과도기) · 미션 카운트 **1.00**(정수) |
|
||||
| Unity MCP 시뮬 1회 결과로 경계값 확정 시도 | 빠른 진행 | 시뮬 자체 오차 흡수 불가 | **10,000회 반복 + 상위/하위 0.1% 값을 이론 극값**으로 채택. 절대 최대/최소 금지 |
|
||||
|
||||
### 2-7. Unity MCP 시뮬 전환·기획 역할 경계
|
||||
|
||||
| 시도한 방법 | 이유 | 결과 | 교훈 |
|
||||
|------------|------|------|------|
|
||||
| "기획팀이 Unity MCP 도구 직접 호출"안 검토 | Unity MCP 전환 직후 자율성 확보 | 학습 부담 과대 + C11·P30 역할 경계 교란 우려 | **"개발팀 러너 구축 + 기획팀 요청 경로"(B안)** 채택. 기획팀은 입력 JSON 스펙·결과 포맷·실행 트리거 3가지만 이해 |
|
||||
| Python 시뮬을 Unity MCP 전환 후 즉시 폐기 검토 | 단일 SOT 단순화 | 교차 검증 자산 상실 우려 | **Python 시뮬 = 교차 검증용 보조 SOT로 유지** · 아카이브 금지 (단 Unity MCP가 주 SOT) |
|
||||
| 시뮬 결정론(시드 고정 = 100% 동일 결과) 미요구 | 초기 관행 | 반복 실행 결과 재현 불가 · 밸런스 튜닝 근거 상실 | **시드 고정 시 100% 동일 결과** 의무화. `UnityEngine.Random` → 시드 기반 난수 전환 개발팀 REQ |
|
||||
|
||||
### 2-8. 병렬 호출 · 전문 에이전트 체계
|
||||
|
||||
| 시도한 방법 | 이유 | 결과 | 교훈 |
|
||||
|------------|------|------|------|
|
||||
| 기획팀장 단독 집행 (초기) | 맥락 유지·일관성 | 전문 영역 깊이 부족 (레벨·밸런스·UX 등 전문성 확보 제한) | 전문 에이전트 6종(system·content·level·narrative·balance·ux-designer) 활용 체계 확립 |
|
||||
| 전문 에이전트 호출 시 공통 업무 규칙 누락 (초기) | 빠른 호출 | 규칙 누락 · 기록 의무 누락 | 전문 에이전트 6종 `.claude/agents/*.md` **"공통 업무 규칙" + "기록 의무" 섹션 신설**. 구 P20(일일보고) 잔존 제거 |
|
||||
| Day 11~14 순차 집행 vs 병렬 집행 판단 | 효율성 | 레벨 축과 밸런스 축은 **독립 작업** 확인 → 병렬 집행 | 독립 작업은 병렬 · 의존 작업은 순차 원칙 정착. 병렬 산출물은 기획팀장이 교차 검증 후 통합 |
|
||||
| 전문 에이전트 산출물 P24 기각안·P16 변경 이력 선택 작성 | 편의 | 조직 기억 축적 부족 | **P24 기각안 필드 필수화** (헌법 제1원칙 목표 2-B 직결) + P16 변경 이력 필수화. 기획팀장·plan-auditor 준수 감독 |
|
||||
|
||||
### 2-9. 프로세스 고도화·조직 운영
|
||||
|
||||
| 시도한 방법 | 이유 | 결과 | 교훈 |
|
||||
|------------|------|------|------|
|
||||
| PM 통합 허브 + 부서 독립 세션 하이브리드 구조 검토 | 독립성과 가시성 균형 | 독립 세션의 "결정 권한 범위"·HOLD 즉시 전파 등 5가지 보완점 식별 | P23(기획 결정 재량 범위) 신설: 팀장 재량·PM 확인·PD님 확인 3단계 명시 |
|
||||
| 문서 반영 시차(세션 갱신 전까지 다른 세션 변경 미인지) 대응 | Phase 3 HOLD 인지 실패 재발 방지 | UserPromptSubmit hook에 HOLD 파일 변경 감지 추가 · 프롬프트 N회마다 HOLD 재스캔 | 기획팀 2026-04-15 Phase 3 HOLD 인지 실패 실증 근거 → 조직 공용 방지 체계 구축 |
|
||||
| 세션 간 소통 부재(C13 위반) 대응 | 결정사항·노하우 세션 단절 | 소통 허브 "결정로그" 유형 추가 + 세션 종료 시 핵심 결정 3줄 요약 자동 산출 | 작업 수행 + 공유 등록이 별개 행위 → **작업 완료 즉시 공유 루틴 습관화** |
|
||||
| 완료 항목 잔류(완료된 안건이 미갱신 상태로 계속 보고) 대응 | 활성 테이블 오염 | PD 지시 로그 **활성·완료 아카이브 2분할** 구조(P19) + 완료 시 즉시 이동 의무(2026-04-18 강화) | 세션 갱신 시 활성 테이블만 스캔 → "완료된 업무가 진행중으로 보이는" 왜곡 차단 |
|
||||
|
||||
### 2-10. 자체 교차 검증·감사
|
||||
|
||||
| 시도한 방법 | 이유 | 결과 | 교훈 |
|
||||
|------------|------|------|------|
|
||||
| 기획팀 산출물 상호 중복·상충·불필요 검증 자체 수행 | 품질 확보 | 12개 기획 문서 역할 분리 확인 + 7개 문서 구 명칭 잔존 112회 식별 + 1건 경미(보존 유지) | **기획팀장 자체 교차 검증 + plan-auditor 병행 감사 2축 구조** 확립. 자기 시야(기획팀장) vs 제3자 시야(감사관) 차별화 |
|
||||
| PD 지시 로그 활성 지시의 산출물 경로 실존 검증 누락 | 관행 | 일부 경로 오류 발견 (2026-04-16 디렉터리 재구조 시 경로 미갱신) | 세션 갱신(P21) 시 **활성 지시 산출물 경로 실존 검증** 5-A 단계 신설. `scripts/verify_log_paths.sh` 활용 |
|
||||
| 전문 에이전트 기록 의무 일관성 점검 누락 | 관행 | 구 P20 문구 잔존 + P24·P26·P27 미반영 | plan-auditor 3축 감사 체계로 주기적 점검. 전문 에이전트 6종 파일 일괄 갱신 |
|
||||
|
||||
---
|
||||
|
||||
## 3. BT 조직 착수 시 체크리스트 (EerieVillage 기획팀장 첫 세션)
|
||||
|
||||
### 3-1. 세션 0일차 — 조직 맥락 숙지
|
||||
- [ ] `공유/조직자산/시행착오_아카이브/기획_팀장_v1.md` (본 문서) Read 완료
|
||||
- [ ] `공유/조직자산/시행착오_아카이브/총괄_pm_general_v1.md` Read (PM과의 협업 맥락)
|
||||
- [ ] `공유/조직자산/시행착오_아카이브/개발_팀장_v1.md` Read (C11 개발 관점 경계 이해)
|
||||
- [ ] SKILL.md C22(용어 일관)·C23(허위 보고 금지)·C36(PM 재량 상한)·P17(배타 배치)·P24(기각안 필수)·P30(재미 우선) 원문 Read
|
||||
- [ ] `.claude/agents/` 하위 전문 에이전트 6종(system·content·level·narrative·balance·ux-designer) 정의 확인
|
||||
|
||||
### 3-2. 프로젝트 착수 1주차 — 데이터 구조 실측 선행
|
||||
- [ ] **EerieVillage Unity Export 경로 확인** (`paths.local.json`에 등록)
|
||||
- [ ] 주요 데이터 테이블(캐릭터·스테이지·몬스터·아이템·스킬 등) CSV/JSON 실측 Read
|
||||
- [ ] **"지역·스테이지·서브맵·노드" 같은 구조 단위 용어를 PD님과 확정** (수상한잡화점의 "WorldMap 4그룹" 사건 재발 방지)
|
||||
- [ ] 모든 기획 문서 상단에 **"데이터 소스: 파일명 (실측 YYYY-MM-DD)"** 필드 기본값화
|
||||
- [ ] 기존 기획 산출물 재활용 시 **실측 교차 검증 선행** (§1-5 의무)
|
||||
|
||||
### 3-3. 기획 프레임워크 설계 단계
|
||||
- [ ] **재미 축 정의**(P30 강화): 차별화·재도전·성취·전략·몰입 중 핵심 1~2축 선정
|
||||
- [ ] **★ 조건 풀 정의** (수상한잡화점 12개 패턴 참조 가능)
|
||||
- [ ] **조건 배타 조합 사전 정의** (P17 체계 확장). 신규 조건 추가 시 배타 조합도 함께 정의
|
||||
- [ ] **성장 축 기여도 목표치 설정** + 설계 가정치 명시 → Unity MCP 실측 후 보정
|
||||
- [ ] **설계 원칙 vs 임시 데이터 분리 구조** 명시 (P29 자산 계승 전제)
|
||||
|
||||
### 3-4. 수치 설계·밸런싱
|
||||
- [ ] **앵커 전투 시뮬 공식** 확립 (PC DPS·EHP·TTK 기본값)
|
||||
- [ ] **성장 5축 결합 공식** (카드 × 장비 × 각성 × 진화 × 인장 등 상응 요소)
|
||||
- [ ] **밸런싱 문서 변경 이력 섹션(P16)** 표준화 — 필드 6종(일시·변경자·변경 필드·이전값→이후값·재미 근거·관련 PD 지시#)
|
||||
- [ ] **REQ 템플릿(밸런스 수치 변경)** 9섹션 준수
|
||||
|
||||
### 3-5. 개발팀 협업 루틴
|
||||
- [ ] **REQ 발행 시 "코드 근거 질의" 패턴**: 추측 금지, 질의 내용에 참조 경로·라인 번호 포함
|
||||
- [ ] **다회 왕복 시 같은 파일 `## 응답 (YYYY-MM-DD)` append**
|
||||
- [ ] 3회 왕복 이상 미합의 시 **PM 에스컬레이션**
|
||||
- [ ] Unity MCP 시뮬 요청 시 **입력 JSON 스키마(seed·stage_id·deck·growth_vars·max_turns) + 출력 JSON 스키마(clear·turns·final_hp_ratio·total_dmg·total_taken·potion_used) 명시**
|
||||
|
||||
### 3-6. 전문 에이전트 호출 원칙
|
||||
- [ ] **독립 작업 = 병렬 호출** (level + balance + content 동시)
|
||||
- [ ] **의존 작업 = 순차** (목표 정의 → 노드 배치 → 배타 체크 → TTK → 고주의 → REQ)
|
||||
- [ ] 병렬 산출물 **기획팀장 교차 검증 후 통합**
|
||||
- [ ] 전문 에이전트 프롬프트에 **P24 기각안 필수·P16 변경 이력 필수·데이터 소스 실측** 3요소 포함
|
||||
|
||||
### 3-7. Phase 관리
|
||||
- [ ] **Phase 범위 정의 = PD님 승인 영역** (기획팀장 단독 재정의 금지 — C36)
|
||||
- [ ] Phase 종결 시 **설계 원칙 집약 문서**(§5 패턴) + **원본 산출물 보존**(C14-5)
|
||||
- [ ] Phase 간 이관 시 **3분류 처리**(설계 원칙 집약·임시 데이터 이관·완료 선언)
|
||||
- [ ] Phase 종결 시 **누락 방지 체크리스트** (Day별 산출물 전수 확인 N/N)
|
||||
|
||||
### 3-8. 자체 교차 검증
|
||||
- [ ] 주 1회 이상 **기획팀장 자체 감사**(불필요·중복·상충 3축) 수행
|
||||
- [ ] plan-auditor 3축 감사와 **자기 시야 차별화** (감사 중복 회피)
|
||||
- [ ] PD 지시 로그 **활성 지시 산출물 경로 실존 검증** (`scripts/verify_log_paths.sh`)
|
||||
- [ ] 완료 항목 **즉시 아카이브 이동** (P19 2분할 구조 준수)
|
||||
|
||||
---
|
||||
|
||||
## 4. PM 보고 안건 (특이사항)
|
||||
|
||||
### 4-1. 데이터 실측 의무 룰 EerieVillage 적용 여부
|
||||
- **배경**: `기획팀_데이터_실측_의무_v1.md` 는 수상한잡화점 전용 프로젝트 룰. EerieVillage Unity 경로·데이터 체계가 다를 경우 **차기 프로젝트 전용 룰 재작성 필요**
|
||||
- **권장**: EerieVillage 첫 기획 작업 전에 동등한 룰 재작성 (데이터 실측·용어 정의·PD 확인 절차·기존 SOT 맹신 금지·기획 문서 재사용 선행 검증 5대 조항 계승)
|
||||
- **PD님 확인 필요**: EerieVillage 데이터 Export 경로·핵심 테이블 구조 확정 후 본 룰 정식화
|
||||
|
||||
### 4-2. 기획 산출물 삭제 시 "교훈 보존" 범위
|
||||
- **배경**: PD님 2026-04-21 지시 3번 "수상한잡화점 기획 산출물 삭제 + 교훈 보존". 본 아카이브 작성 후 원본 삭제 시점에 어떤 문서를 얼마나 보존할지 구체 범위 필요
|
||||
- **권장**: 본 아카이브(시행착오) + 핵심 방법론 문서(3성 조건 풀·P17 배타·TTK 산출 공식·Phase 3 종결 설계 체계 §5 5종 집약)만 재구성하여 `공유/조직자산/기획방법론/`에 별도 보존. 나머지 수상한잡화점 구체 수치·스테이지 설계는 삭제
|
||||
- **PD님 확인 필요**: "방법론 자산"과 "프로젝트 구체 기록"의 경계를 명시 지시
|
||||
|
||||
### 4-3. EerieVillage 장르 적합성 — Prove-2-of-3 체계 재활용
|
||||
- **배경**: 수상한잡화점 = 덱빌딩 전투. EerieVillage = Unity 2D PlatformerMicrogame 기반 액션(추정). 덱빌딩 전용이었던 Prove-2-of-3 체계(★ 조건 2-of-3)가 플랫포머에 적용 가능한지 미확인
|
||||
- **권장**: EerieVillage 첫 기획 세션에서 **장르 적합성 평가**. 부적합 시 ★ 조건 체계 재설계 · 적합 시 Prove-2-of-3 그대로 계승 (조건 풀만 장르 맞춰 재정의)
|
||||
- **PD님 확인 필요**: EerieVillage 코어 메커닉 확정 후 판단
|
||||
|
||||
### 4-4. 전문 에이전트 6종 → 프로젝트별 맞춤화 필요성
|
||||
- **배경**: 현 6종(system·content·level·narrative·balance·ux-designer)은 수상한잡화점 기준. EerieVillage는 **플랫포머 액션** 특성상 "물리·스테이지 기믹·히트박스" 등 전문 영역 추가 필요 가능성
|
||||
- **권장**: EerieVillage 착수 시 에이전트 정의 재검토. 필요 시 신규 전문 에이전트 신설 (예: `mechanic-designer` 플랫포머 기믹 전담)
|
||||
- **PD님 확인 필요**: 에이전트 구성 변경은 C36 방향·원칙 수준 판정 가능성 있음
|
||||
|
||||
### 4-5. 어뷰징 판정 프레임워크 재활용 가능성
|
||||
- **배경**: 수상한잡화점 어뷰징 판정 기획서는 **"시뮬 이론 극값 기반 경계값 + 안전 마진 차등 + 서버 2계층 검증"** 프레임. 플랫포머 액션에도 재활용 가능 (점수·클리어타임·재화 벡터 공통)
|
||||
- **권장**: EerieVillage 서비스 준비 단계에서 해당 프레임워크 재활용 검토. 벡터는 장르 특화 재정의 (예: 점프 횟수·데미지 수치·플랫폼 부양 시간 등)
|
||||
|
||||
---
|
||||
|
||||
## 5. 참조 원본 파일 목록 (감사 재현 가능)
|
||||
|
||||
### 5-1. 핵심 방법론 문서 (Phase 3·4 설계 체계)
|
||||
- `프로젝트/수상한잡화점/기획/Phase3_종결_설계체계_v1.md` — 설계 체계 집약 SOT
|
||||
- `프로젝트/수상한잡화점/기획/Phase4_노드구성_착수가이드_v1.md` — Phase 4 범위·흐름
|
||||
- `프로젝트/수상한잡화점/기획/Phase4_지역1_노드구성_v2.md` — 지역 1 v2 (v1 폐기 후 재작성)
|
||||
- `프로젝트/수상한잡화점/기획/Phase4_지역1_노드구성_v1.md` — 폐기 버전 (재발 방지 참조)
|
||||
- `프로젝트/수상한잡화점/기획/기획팀_데이터_실측_의무_v1.md` — 데이터 실측 5대 조항
|
||||
- `프로젝트/수상한잡화점/기획/테이블_데이터_구조_재정비_v1.md` — 데이터 구조 SOT
|
||||
- `프로젝트/수상한잡화점/기획/재검증보고_맵패턴_v1.md` — Day 11~14 통합
|
||||
- `프로젝트/수상한잡화점/기획/이슈1_3_무시확정_v1.md` — Day 8~10 PD A안 수용
|
||||
- `프로젝트/수상한잡화점/기획/3성조건_12개_상세명세_v1.md` — 조건 풀 12개
|
||||
- `프로젝트/수상한잡화점/기획/맵패턴_사전분석_v1.md` — 사전 프레임
|
||||
- `프로젝트/수상한잡화점/기획/맵패턴_42슬롯_현황테이블_v1.md` — 42 슬롯 현황
|
||||
- `프로젝트/수상한잡화점/기획/스테이지난이도곡선_v1.md` — 스테이지 구조 SOT
|
||||
- `프로젝트/수상한잡화점/기획/밸런싱전략_v1.md` — 목표·드래프트 가중치
|
||||
- `프로젝트/수상한잡화점/기획/밸런싱문서_일관성점검_v1.md` — 28개 재검증 항목 추적
|
||||
- `프로젝트/수상한잡화점/기획/Phase2_카드임팩트측정_v1.md` — 카드 분포·이슈
|
||||
- `프로젝트/수상한잡화점/기획/카드시너지축분석_v1.md` — 신성 빌드 22장
|
||||
- `프로젝트/수상한잡화점/기획/빌드_조건_충돌점검_v1.md` — 3성 조건 배치
|
||||
- `프로젝트/수상한잡화점/기획/전체테이블감사_v1.md` — JSON 데이터 감사
|
||||
- `프로젝트/수상한잡화점/기획/Phase0_1_앵커전투시뮬레이션_v1.md` — 앵커 공식
|
||||
- `프로젝트/수상한잡화점/기획/Phase3_재개준비_체크리스트_v1.md` — 재개 절차
|
||||
- `프로젝트/수상한잡화점/기획/재검증_템플릿_v1.md` — 재검증 양식
|
||||
|
||||
### 5-2. 개발팀 협업·REQ 응답
|
||||
- `공유/소통/완료/2026-04-14_REQ001_각성트리_퍼센트값_해석확인.md` (기획팀→개발팀)
|
||||
- `공유/소통/완료/2026-04-14_REQ002_장비옵션_음수값_의미확인.md`
|
||||
- `공유/소통/완료/2026-04-14_REQ003_인장_장착수제한_확인.md`
|
||||
- `공유/소통/완료/2026-04-16_REQ001_응답_각성트리_퍼센트값.md` (개발팀→기획팀)
|
||||
- `공유/소통/완료/2026-04-16_REQ002_응답_장비옵션_음수값.md`
|
||||
- `공유/소통/완료/2026-04-16_REQ003_응답_인장_장착수제한.md`
|
||||
- `공유/소통/완료/2026-04-16_유니티프로젝트_점검_기획팀.md`
|
||||
- `공유/소통/완료/2026-04-16_하이브리드구조_기획실의견.md`
|
||||
- `공유/소통/완료/2026-04-16_프로세스고도화_개선안_기획실.md`
|
||||
- `공유/소통/완료/2026-04-17_Unity_MCP_시뮬레이션_기획검토_기획팀.md`
|
||||
|
||||
### 5-3. Phase 3 중간 산출물 (기획팀→개발팀 경로)
|
||||
- `공유/소통/기획팀→개발팀/재검증보고_Phase0_1_2_v1.md` — Day 2~3 앵커 재검증
|
||||
- `공유/소통/기획팀→개발팀/Phase3_성장요소기여도_v2.md` — Day 4~7 #16~#21 Unity MCP UTF 14/14
|
||||
- `공유/소통/기획팀→개발팀/REQ-템플릿_밸런스수치.md` — 밸런스 REQ 표준 템플릿
|
||||
|
||||
### 5-4. 기획팀→PM 보고·자체 검증
|
||||
- `공유/소통/기획팀→PM/2026-04-17_JSON_데이터_숙지_현황.md`
|
||||
- `공유/소통/기획팀→PM/2026-04-17_전수감사_자체교차검증_기획팀장관점.md`
|
||||
- `공유/소통/기획팀→PM/2026-04-20_Day8-10_종결보고.md`
|
||||
- `공유/소통/기획팀→PM/2026-04-20_Day11-14_레벨축_본작업_v1.md`
|
||||
- `공유/소통/기획팀→PM/2026-04-20_Day11-14_밸런스축_본작업_v1.md`
|
||||
- `공유/소통/기획팀→PM/2026-04-20_Phase3_병렬진행_선행업무_요약_v1.md`
|
||||
|
||||
### 5-5. 어뷰징 판정 기획 (기획 → 서버 이관)
|
||||
- `공유/소통/완료/2026-04-17_어뷰징판정_솔루션_기획서_v1.md` — 7섹션 프레임워크
|
||||
- `공유/소통/완료/2026-04-17_서버개발자_업무지시서_최종본.md` — 서버팀 인계 상세
|
||||
|
||||
### 5-6. 대화로그·조직 운영 기록
|
||||
- `공유/대화로그/수상한잡화점/2026-04-16.md`
|
||||
- `공유/대화로그/수상한잡화점/2026-04-17.md`
|
||||
- `공유/대화로그/수상한잡화점/2026-04-18.md`
|
||||
- `공유/대화로그/수상한잡화점/2026-04-20.md`
|
||||
- `공유/PD_지시_트래킹/기획팀_PD_지시_로그.md` — 활성 #41·42·43·44·45 + 완료 아카이브 전체 (특히 #24·#31·#32·#33·#34·#35 품질 개선 계열)
|
||||
- `공유/일일보고/2026-04-15_기획실.md` — 구 P20 잔존 형식 (폐기됨, 계승 대상 아님)
|
||||
|
||||
### 5-7. 감사·검증 기록
|
||||
- `공유/소통/완료/2026-04-17_감사보고_팀기록체계_전수점검.md` — pm-auditor 전수 감사 (기획팀 활성 지시 경로 실존 100% 확인)
|
||||
- `공유/소통/완료/2026-04-17_업무공유체계_점검_기획팀.md` — 기획팀 자체 점검
|
||||
|
||||
### 5-8. 메모리 (feedback)
|
||||
- `memory/org/feedback_pm_capability_underestimation.md` — PM 실측 가능 범위 축소 (기획팀 작업에도 경계·주의 영역)
|
||||
- `memory/org/feedback_requirement_framing.md` — 요구사항 4축 프레이밍 (목적·용도·범위·비목적)
|
||||
- `memory/org/feedback_resolved_agenda_unnecessary_reference.md` — 종결 안건 재언급 금지 (P28-8)
|
||||
- `memory/org/feedback_agenda_framing_duplication.md` — 안건 프레이밍 중복 (PM 재량·PD 결정 동일 안건 중복)
|
||||
- `memory/org/feedback_team_recording_quality.md` — 팀 기록 품질 점검
|
||||
|
||||
---
|
||||
|
||||
## 6. 마무리 — BT 조직 기획팀장에게
|
||||
|
||||
본 아카이브는 **"무엇을 만들었는가"**가 아니라 **"왜 그렇게 결정했고 어떤 대안을 기각했는가"**의 기록이다. 수상한잡화점 프로젝트 기획팀은 다음 4가지 교훈을 반복 체험했다:
|
||||
|
||||
1. **데이터 실측 없는 기획은 모래 위의 집** — WorldMap 4그룹 사건이 증명
|
||||
2. **PD님 확정 용어의 변형 = 재작업의 직접 원인** — C22는 선택이 아닌 필수
|
||||
3. **설계 원칙과 임시 수치의 분리 = 차기 프로젝트 자산 계승의 필수 조건** — P29의 실천 방법
|
||||
4. **기획팀의 책임은 "재미"이지만 개발 관점·PD 방향·자원 효율과의 조율 없이는 실현 불가** — P30·C11·C36·C1의 네트워크
|
||||
|
||||
EerieVillage 기획팀장은 이 아카이브를 **"이미 지나온 함정 지도"**로 활용하되, 장르 차이(덱빌딩 → 플랫포머)에 따른 차별화 재검토를 병행한다. 재미는 장르마다 다르지만, **재미를 설계하고 검증하고 기록하고 계승하는 방법론**은 조직 자산으로 계승 가능하다.
|
||||
|
||||
---
|
||||
|
||||
*작성 완료: 2026-04-21*
|
||||
*BurningTimes 조직 자산 — 기획팀 통합 시행착오 아카이브 v1*
|
||||
|
|
@ -0,0 +1,166 @@
|
|||
# 총괄PM·조직 운영 관점 시행착오 아카이브 v1
|
||||
|
||||
> **작성 주체**: 총괄PM (2026-04-21 BurningTimes 출범 이관 세션)
|
||||
> **대상**: BurningTimes 차기 PM 세션·조직 운영 담당자
|
||||
> **출처 조직**: NerdNavis (2026-04-14~2026-04-20 수상한잡화점 프로젝트 집중 운영기)
|
||||
> **목적**: 동일 조직 운영 시행착오 재발 방지 + PD님 승인 작업 효율성 보존
|
||||
> **작성 원칙**: C23 정직성(미확인은 명시) · C25 넘버링 위계 · C34-11 상대 경로
|
||||
|
||||
---
|
||||
|
||||
## 1. 개요 — 핵심 교훈 8건 요지
|
||||
|
||||
BurningTimes 조직 착수 전 반드시 인지해야 할 8대 교훈. 각 교훈은 §2 본문 표에서 상세 실증·경위·산출물 링크 제시.
|
||||
|
||||
1. **PM은 "자율 재량"과 "방향·원칙 결정"을 구분해야 한다** — PM이 헌법·C·P 원칙 수준에 자체 축소·희석 판단을 내리면 6회+ 재발 (C36 신설로 구조 차단).
|
||||
2. **Proxy 개선(경계 값·파라미터 튜닝)을 근본 해결로 포장하지 말 것** — 30분 윈도우·60분 확장·시간 윈도우 내 옵션 3개 나열은 모두 proxy. 근본은 설계 재검토 (C2-1~C2-6).
|
||||
3. **승인 범위는 자구 그대로** — PD님이 "X 승인"이라 하셨으면 X만 승인. 복수 안건 병기 시 안건별 구분 표기 후 실행 (C19-1).
|
||||
4. **PM 과도 보수 해석 6회차 재발** — "보존 = 원 위치 고정" 오독 패턴 반복. 자산 가치 보존과 저장 위치 보존은 다름.
|
||||
5. **PD님께 질문을 되돌리는 프레이밍 금지** — "어떻게 할까요?" 되묻기·안건 프레이밍 중복·이미 결정된 사안 재질문은 PD님 의사결정 피로 유발 (C29·P28-8).
|
||||
6. **"본문 최신 + 히스토리는 외부 아카이브" 원칙** — 폐기·변경 조항을 본문에 `~~취소선~~`·상단 배너로 남기지 말 것. 활성 본문은 최신만, 아카이브 파일에 6필드 기록 (C14-5).
|
||||
7. **세션 간 맥락 복원은 구조적 강제 없이는 실패한다** — 신 PM 세션이 이전 결정을 자동 계승 못함. SessionStart hook·대화로그 Read·PD 지시 로그 활성 테이블 전수 스캔이 필수 루틴 (C31-D·P21-5B).
|
||||
8. **worktree 경계는 조직 공유 체계의 숨겨진 경계** — 신 공유 저장소·hook·스크립트 도입 시 5문항 체크(단위·경계·중앙화·레포 루트 vs worktree·Agent 경계)를 선행 통과 필수 (C34-15).
|
||||
|
||||
---
|
||||
|
||||
## 2. 시도한 방법·이유·결과·교훈 표 (20건)
|
||||
|
||||
| # | 시도 방법 | 이유 | 결과 | 교훈 | 실증 경로 |
|
||||
|---|-----------|------|------|------|-----------|
|
||||
| 1 | 부서별 영속 대화 워크트리 3개 세션 운용 | PM 세션 외에 개발팀·기획팀 독립 세션 유지로 병렬 작업 기대 | 세션 간 동기화 실패·코어룰 자동 주입 실패·C17 세션 진입 절차 복잡화 | **단일 세션 + Agent 병렬 호출로 전환**. C24로 규약화. Claude 콘솔 병렬 실행 기술 검토로 Agent 호출이 세션 분리 대체 | `공유/조직공지/2026-04-16_안건_Skill_패킹_근본해결.md`, 대화로그 `공유/대화로그/조직운영/2026-04-16.md` |
|
||||
| 2 | 부서 에이전트 정의에 코어룰 본문 하드코딩 | 서브에이전트 system prompt에 코어룰 인지시키기 위함 | 규칙 추가마다 3~5개 파일 동시 갱신 필요·누락 시 불일치·PD님 운영 부담 과중 | **Skill 패킹 단일 SOT**(`.claude/skills/BurningTimes-코어룰/SKILL.md`) 전환. frontmatter `skills:` 필드로 자동 주입 | 동상 |
|
||||
| 3 | 상위 세션이 부서 작업을 직접 수행 (역할 경계 침범) | 빠른 처리를 위한 PM 단독 실행 | C23 역할 연기 위반 의혹·위임 동사 무시·검증 누락 | **위임 동사 식별 의무**("~하라고 해"→부서 hand-off 필수). 3축 검증(파일·OS·실행) | `memory/org/feedback_delegation_discipline.md` |
|
||||
| 4 | PD님 승인 표현을 확대 해석하여 A/C 안 병기 중 A 단독 main fast-forward push | "정보 요청·권장·토의를 승인으로 간주" | PD님 "결정을 강요당한 불쾌 경험" 직접 표현·조직 신뢰 기반 훼손 | **C19 신설 — 승인 범위 엄격 해석**. 같은 응답에 복수 안건 시 안건별 승인 구분 표기 | `memory/org/feedback_approval_scope_expansion.md`, `공유/조직공지/2026-04-15_절차위반_영구기록_승인범위_확대해석.md` |
|
||||
| 5 | 자동화(hook·스크립트)가 처리 중인 편차를 "문제"로 프레이밍하여 PD님께 수동 결정 요청 | 상태 편차 발견 즉시 결정 올림 | PD님 "갑자기 왜 결정 요청이 발생한지 모르겠다" 지적·불필요 결정 피로 | **자동화 매핑 선행 확인 의무**. 자동화 정상 시 편차는 "다음 트리거에서 해소될 정상 상태" | `memory/org/feedback_automation_trust.md` |
|
||||
| 6 | PD 지시 로그에 활성·완료 항목 혼재 + 상태만 "완료"로 변경하고 아카이브 미이동 | 별도 재보고 부담 회피 | 활성 테이블에 완료 항목 잔류·세션 갱신 시 PD님께 완료 작업 재보고 | **활성·아카이브 2분할 구조**(P19) + **완료 즉시 이동 의무** + **즉답 접두 `[완료: 일시 · commit: hash · 참조: 경로]`** 필수화 | `memory/org/feedback_active_archive_promotion_omission.md` |
|
||||
| 7 | PM이 이전 세션 결정(#28 Unity MCP 전환)을 놓치고 구 방향(Python Headless) 기준 응답 | 세션 맥락 자동 복원 가정 | PM 보고 방향 역행·PD님 재지적 | **P21-5B 신설**(세션 갱신 시 최근 2일 대화로그 Read + `git log --since`) + **C31-D 체크리스트** + **SessionStart hook `pm_context_restore.sh`** 구축 | `memory/org/feedback_pm_context_restoration_failure.md` |
|
||||
| 8 | 코어룰(C·P) 수동 갱신 사이클 — 루트 CLAUDE.md + 부서 에이전트 본문 + 부서 워크트리 merge + 재resume | 서브에이전트에 최신 규칙 주입 위함 | 5단계 누락 빈번·부서장이 신설 규칙 미인지·조직 운영 무력화 근접 | **C26 개정 — Skill 패킹 단일 SOT 갱신 원칙**. SKILL.md 1곳만 갱신, 서브에이전트 자동 주입 | §1-2 동일 |
|
||||
| 9 | 대규모 리팩토링 후 대화로그 작성 누락 (수상한잡화점·코어프레임워크 양쪽 프로젝트 영향 세션) | PM이 "코드 수정 없음 = 영향 없음"으로 범위 축소 해석 | P24 헌법급 승격 전 사건·과도 보수 해석 4회차 변종 | **C32 헌법급 승격** + **C31-D "오늘 커밋이 수정한 프로젝트 대화로그 모두 작성" 체크** + **SessionEnd hook 강화** | `memory/org/feedback_session_log_coverage_gap.md` |
|
||||
| 10 | 폐기 규칙을 `~~C7~~ (P30 강등)`·상단 배너로 본문에 유지 | 조직 기억 보존 의도 | 토큰 누적 + 본문 비대화 + PM 과도 보수 해석 5회차 변종 | **C14-5-확장 — 폐기·통합·강등 조항 본문 완전 삭제 + 아카이브 SOT 기록 3종 세트**. 번호 구멍 허용 | `memory/org/feedback_deprecated_section_retention.md`, `공유/조직공지/폐기_규칙_아카이브.md` |
|
||||
| 11 | `.live/` 더미 파일로 세션 간 실시간 공유 구현 (P25 원안) | 세션 재시작 없이 변경 즉시 공유 | worktree 격리로 세션 A Write가 세션 B hook에 미주입·PD님 "조직 유지 불가" 선언 | **C34 헌법급 신설 — PC 로컬 중앙 Junction 체계**. `$HOME/.claude/nerdnavis-live/` 단일 저장 + worktree에서 junction 경유. **구 조직 → BT 이관 시 `burningtimes-*` 디렉토리로 분리** | `memory/org/feedback_worktree_isolation.md`, `공유/조직공지/2026-04-18_C34_신설_worktree_격리_근원해결.md` |
|
||||
| 12 | Agent 호출 프롬프트에 절대 경로 하드코딩 (`E:\NerdNavisAi\...`) | 명시적 경로 지정 의도 | Agent가 worktree 경계 넘어 레포 루트에 파일 생성·stash 이관 복구 필요 | **C34-11 — Agent 경계 보호 의무**. Agent 프롬프트에 "cwd 기준 상대 경로 사용 의무" 명시 + `git rev-parse --show-toplevel` 기준 | `memory/org/feedback_agent_path_boundary.md` |
|
||||
| 13 | memory/org/ junction 경계 이슈를 "운영 규율 + 감사관 체크로 커버" 축소 판정·PD님께 침묵 | C34 대규모 집행 직후 피로·토큰 비용 회피 심리 | PD님 직접 지적 "근본 해결이 아닌 임시 방편은 코어 룰 위반·C34와 동급 생존성 이슈는 권고 수준 아니었어" | **C34 확장 — memory junction HOME 중앙화(옵션 A)** 즉시 집행. 이슈 발견 시 C14·C34·C16-1 참조 관계 즉시 자문 의무 | `memory/org/feedback_issue_under_reporting.md` |
|
||||
| 14 | PM 보고 시 "PM 재량"과 "PD 결정" 카테고리에 동일 안건 중복 등장 + 이미 결정된 사안 재질문 | 안건 분류 자기검증 부재·PD님 이전 결정 망각 | PD님 "보정 2와 결정 1은 같은 안건 아니야?" 직접 지적 | **안건 상호 배타성 자체 검증 체크리스트**(C31 확장) + **PD 지시 로그·대화로그 재스캔 후 보고 확정** | `memory/org/feedback_agenda_framing_duplication.md` |
|
||||
| 15 | 종결·완료 확정 사안을 "고착·영구 종료·재논의 대상 아님" 등 재강조 표현으로 재언급 | PD님 명확 인지 도모 의도 | 역설적으로 "아직 살아있는 이슈처럼" 인지 유발·PD님 "종결된 안건은 내가 히스토리 묻기 전까지 언급하지 마" 지적 | **P28-8 신설 — 최신 결정 중심 보고**. 재강조 표현 등장 시 위험 신호로 삭제 검토 | `memory/org/feedback_resolved_agenda_unnecessary_reference.md` |
|
||||
| 16 | Phase 3 HOLD 사유 설명 시 이미 해결 완료된 과거 트리거 사유를 현재형 문장("확인됨·불가·필요")으로 서술 | "왜 해야 하는가?" 질문 답변에 배경 설명 포함 의도 | PD님 "HOLD 사유는 이미 모두 완료된 상태인데 재보고 한 이유가 뭐야?" 지적 | **시제 검증 3문항**(과거형 vs 현재형 분리) + **배경 섹션·현 상태 섹션 분리 서술**. P28-8 4회차 변종 | `memory/org/feedback_resolved_cause_as_current_hold.md` |
|
||||
| 17 | PM이 30분 윈도우 경계 값 이슈에 (a)60분 확장 (b)작업 유형 차등 (c)유효 만료 로그 3안 모두 proxy 개선으로 제시 | "개선안 3개 제시 = 실질 필요성 높음" 착각 | PD님 "모든 안건이 다 근본 해결이 아닌 거 같아" 역질문·PM proxy 반사 7회차 변종 실증 | **C2 확장(C2-1~C2-6)** + **C31-I 체크리스트** + **pm-auditor 5-F 신설**(동일 축 내 튜닝 Critical) + **매니페스트 기반 감사로 재설계** | `memory/org/feedback_pm_proxy_improvement_reflex.md` |
|
||||
| 18 | pm-auditor hook의 PostToolUse 경고 + 30분 시간 윈도우 방식으로 의무 호출 강제 시도 | "차단은 작업 흐름 파괴·생산성 저해" 프레이밍 | PD님 "보고 체계 미비·무단 변경 이슈가 더 큼"·proxy 회피 8회차 변종 | **Layer 3 전면 개정 — PreToolUse 차단 + 매니페스트 등록·해제 워크플로우**. BYPASS 우회 불가 | `공유/조직공지/2026-04-20_PreToolUse_차단_전환_근본해결.md` |
|
||||
| 19 | PM이 G 안건(PC별 감사 로그 중앙 통합)을 "검토 착수 + 4문항 실질 필요성 검증 선행"으로 축소 권고 | "PC별 독립성이 본래 의도일 수 있음" 자의 판단 | 헌법 제1원칙 ⑤(세션·PC 연속성)에 역행·PD님 "PM이 자율 판단으로 코어룰·조직 룰 영향 결정을 임의 변형 못하도록 보완" 지시 | **C36 헌법급 신설 — PM 자율 판단 범위 상한(방향·원칙 수준 축소·희석 금지)** + **C31-H 체크리스트** + **실질 필요성 4문항 적용 범위 제한**(구현 세부 한정) | `memory/org/feedback_pm_over_conservative_interpretation.md` §6회차 변종 |
|
||||
| 20 | "세션 공유"·push 직후 PD님 남은 업무 재요청에 `local == remote` 해시 일치만 확인하고 과거 스냅샷 재사용 | 동기화 = 최신성 등식 가정 | 방금 완료·push된 #52-B를 "대기"로 서술·PD님 "왜 52-B가 남아있다는거지?" 지적 | **실측 응집성 축 — C31-E 체크리스트 확장**. 보고 직전 원격 HEAD diff + 활성 테이블 재grep 의무. 5회차 변종 | `memory/org/feedback_resolved_cause_as_current_hold.md` §5회차 실증 |
|
||||
|
||||
---
|
||||
|
||||
## 3. BT 조직 착수 시 PM 체크리스트
|
||||
|
||||
BurningTimes 신 세션 착수 시 다음 순서로 자기검증 수행한다.
|
||||
|
||||
### 3-1. 세션 시작 루틴 (매 세션 진입 직후)
|
||||
|
||||
1. `git fetch origin && git merge origin/main --no-edit` — 최신 동기화
|
||||
2. SessionStart hook 자동 실행 확인 (`live_junction_ensure.sh`·`memory_junction_ensure.sh`·`audit_junction_ensure.sh`·`pm_context_restore.sh`·`recent_feedback_brief.sh`)
|
||||
3. **CLAUDE.md + SKILL.md 최상단 "최근 규칙 변경" 재읽기** (캐시 의존 금지)
|
||||
4. **최근 2일 대화로그 Read** (`공유/대화로그/조직운영/` + 프로젝트별)
|
||||
5. **PD 지시 로그 활성 테이블 전수 스캔** (비고란·중단 사유 필수 체크)
|
||||
6. `🛑_*`·`⚠️_*`·`🚨_*` 공지 파일 스캔 + `공유/조직공지/` 최신 확인
|
||||
|
||||
### 3-2. 응답 발신 직전 자기검증 (C31 헌법급)
|
||||
|
||||
응답 작성 완료 후 전송 직전, 모든 항목 통과 시에만 발신:
|
||||
|
||||
1) **A. C29 업무 자율 수행** — "PD님 결정 필요" 표현 남발 여부 자문. 팀 논의·PM 재량으로 처리 가능한가?
|
||||
2) **B. 오늘 신규 룰 준수** — PD 지시 로그 갱신·대화로그·Live 더미·git 동기화 점검
|
||||
3) **C. 정직성·용어 일관** — tool_use 입증·미확인 태그·용어 변경 금지·C25 위계
|
||||
4) **D. 세션 맥락 복원** — 오늘 커밋이 수정한 프로젝트 대화로그 모두 작성했는가? PD 지시 로그 활성 테이블 전수 Read?
|
||||
5) **E. 기존 조직 자산 우선** — C34 Live 증분 동기화·feedback 패턴·hook·scripts 선 검토. **자산 가치 보존 ≠ 저장 위치 보존** 구분. **실측 응집성 축 — 보고 직전 원격 HEAD diff + 활성 테이블 재grep**
|
||||
6) **F. C35 pm-auditor 의무 참여** — 규칙 개정·commit·PD 결정 보고·feedback 신설 등 7종 시 pm-auditor 사전 호출
|
||||
7) **G. 구체 맥락 feedback 선행 Read** — SessionStart hook 요지만으로 판단 금지, 관련 feedback 본문 Read 의무
|
||||
8) **H. 방향·원칙 수준 축소·희석 금지 (C36)** — 헌법·C·P 본문 직접 수정·승인 방향 적용 범위 조정·규칙 우선순위 변경은 PM 재량 금지·PD님 명시 승인 선행. 실질 필요성 4문항 체크리스트 방향·원칙 오적용 금지
|
||||
9) **I. Proxy 개선 회피·근본 해결 우선 (C2)** — 근본 원인 재정의 단계 거쳤는가? 경계 값·설정·수치만 조정하는 proxy 단독 완결 권고 금지. 근본 해결안 첫 번째 제시
|
||||
|
||||
### 3-3. 규칙 변경 제안 시
|
||||
|
||||
- 규칙 추가·변경·폐기 제안 전 C36-2 판정 기준 3종(본문 직접 수정·승인 방향 적용 범위 조정·규칙 우선순위 변경) 해당 여부 자문
|
||||
- 해당 시 PM 재량 금지·PD님 명시 승인 선행 필수
|
||||
- 판정 모호 시 PM 재량 대신 PD님 질의 선택 (보수 선택 의무)
|
||||
- C·P 신설 시 C10-6 3중 전파 (조직공지·CLAUDE.md 요약·관련 에이전트 본문) 동반 집행
|
||||
|
||||
### 3-4. 새 저장소·hook·스크립트 도입 시 (C34-15)
|
||||
|
||||
5문항 체크 통과 후에만 도입:
|
||||
1) **단위 판정**: PC 단위 vs worktree 단위?
|
||||
2) **경계 안전성**: worktree에서 쓰여도 다른 worktree·레포 루트 누출 없는가?
|
||||
3) **중앙화 필요성**: `$HOME/.claude/burningtimes-*/` 중앙 Junction 패턴 채택?
|
||||
4) **레포 루트 vs worktree 실행 차이**: setup·verify 스크립트 동작 차이 검토?
|
||||
5) **Agent 경계 보호**: 서브에이전트 절대 경로 하드코딩 위험 없는가?
|
||||
|
||||
---
|
||||
|
||||
## 4. PM 보고 안건 (자체 판단 금지, 모호 건 일괄 정리)
|
||||
|
||||
본 섹션은 BurningTimes PM이 "이전 조직 자산 이전 시 판단 모호"하여 **PD님 결정이 필요한 안건**을 정리. 본 시행착오 아카이브 작성 과정에서 자체 판단 없이 일괄 기록한다.
|
||||
|
||||
1) **A. 프로젝트별 시행착오 아카이브 추출 범위** — 본 산출물은 "총괄PM·조직 운영" 관점만 추출. 수상한잡화점 프로젝트(기획·개발 실무) 관점·코어프레임워크 관점은 별도 서브에이전트 산출물로 집약되는지 PD님 지시 범위 확인 필요 (PD님 지시 1번 "전 에이전트 동원" 수용 전제로 작성).
|
||||
2) **B. NerdNavis 조직 대화로그·PD 지시 로그 BurningTimes 이관 여부** — Phase 2-C 단계에서 수상한잡화점·코어프레임워크 관련 파일 일괄 삭제 예정이나, **조직 운영 대화로그(`공유/대화로그/조직운영/2026-04-14~2026-04-20.md`)와 PD 지시 로그 완료 아카이브**는 차기 조직 감사·노하우 계승에 활용 가치 보유. 삭제 vs 아카이브 판정 PD님 결정.
|
||||
3) **C. feedback 메모리 이관 정책** — `memory/org/feedback_*.md` 40+건 중 일부는 수상한잡화점 프로젝트 고유(P17 ★ 조건 배타 7종 등) + 대부분은 조직 운영 일반 교훈. Phase 2-C에서 "수상한잡화점" → "이전 프로젝트" 추상화로 계획 중이나, **BT 신 프로젝트 EerieVillage에 그대로 적용 가능성 여부**는 재검증 필요 안건.
|
||||
4) **D. pm-auditor·dev-auditor·plan-auditor 에이전트 BurningTimes 적응 범위** — 3축 감사 에이전트 정의는 NerdNavis 조직 운영 패턴에 최적화됨. BurningTimes 신 조직에서도 동일 체계 유지 여부·프로젝트 특성(EerieVillage) 반영 조정 여부 PD님 결정 영역 (C36-2 판정 기준 3종 해당).
|
||||
5) **E. PM 과도 보수 해석 6회차·proxy 개선 회피 7~8회차 이력 BurningTimes 계승 여부** — 본 교훈은 **PM 개인의 재발 방지 자산**이므로 BurningTimes 조직에서도 그대로 계승하는 것이 헌법 제1원칙 ②(경험 축적·계승) 정합. 단 "7회차 재발 시 역할 재검토" 조항이 **신 조직 출범과 함께 초기화되는지**는 PD님 결정 영역.
|
||||
6) **F. 구 NerdNavis audit_logs PC별 로그 처리** — `memory/org/audit_logs/{hostname}/`에 누적된 감사 이력은 PC별 + NerdNavis 조직 식별자와 결합. BurningTimes 전환 시 (가) 이관 (나) 아카이브 후 재시작 (다) 혼재 허용 중 PD님 결정 필요.
|
||||
|
||||
---
|
||||
|
||||
## 5. 참조 원본 파일 목록
|
||||
|
||||
본 산출물 작성 시 Read한 원본 경로 (전부 상대 경로, C34-11 준수).
|
||||
|
||||
### 5-1. feedback 메모리 (11건 직접 참조)
|
||||
|
||||
- `memory/org/feedback_pm_over_conservative_interpretation.md` (6회차 변종 SOT)
|
||||
- `memory/org/feedback_pm_proxy_improvement_reflex.md` (proxy 개선 반사 7~8회차)
|
||||
- `memory/org/feedback_pm_context_restoration_failure.md` (세션 맥락 복원 실패)
|
||||
- `memory/org/feedback_issue_under_reporting.md` (C34/C16-1 축소 보고)
|
||||
- `memory/org/feedback_approval_scope_expansion.md` (승인 범위 확대 해석)
|
||||
- `memory/org/feedback_automation_trust.md` (자동화 영역 침범 금지)
|
||||
- `memory/org/feedback_worktree_isolation.md` (worktree 격리 + 5문항 체크)
|
||||
- `memory/org/feedback_session_log_coverage_gap.md` (대화로그 누락 4회차)
|
||||
- `memory/org/feedback_agenda_framing_duplication.md` (안건 프레이밍 중복)
|
||||
- `memory/org/feedback_resolved_cause_as_current_hold.md` (종결 사유 현재형 재프레이밍 5회차)
|
||||
- `memory/org/feedback_delegation_discipline.md` (위임 동사 우회 금지)
|
||||
- `memory/org/feedback_session_start_protocol.md` (세션 시작 폴더 진입 표준)
|
||||
|
||||
### 5-2. 조직공지 (4건 직접 참조, 전수 목록은 `공유/조직공지/`)
|
||||
|
||||
- `공유/조직공지/2026-04-18_C34_신설_worktree_격리_근원해결.md`
|
||||
- `공유/조직공지/2026-04-16_안건_Skill_패킹_근본해결.md`
|
||||
- `공유/조직공지/2026-04-20_C36_신설_G_audit_중앙통합.md`
|
||||
- `공유/조직공지/2026-04-20_PreToolUse_차단_전환_근본해결.md`
|
||||
- `공유/조직공지/폐기_규칙_아카이브.md` (폐기 이력 SOT)
|
||||
|
||||
### 5-3. 대화로그 (3건 직접 참조)
|
||||
|
||||
- `공유/대화로그/조직운영/2026-04-16.md` (단일 세션 전환 결정)
|
||||
- `공유/대화로그/조직운영/2026-04-20.md` (#48·#50 C2·C36 신설 경위)
|
||||
- `공유/대화로그/조직운영/2026-04-21.md` (BurningTimes 출범 Phase 분할)
|
||||
|
||||
### 5-4. 인계서·PD 지시 로그 (2건 직접 참조)
|
||||
|
||||
- `공유/인계서/2026-04-17_전수감사_A+B급7건_수정집행_인계서.md` (수정 3대 원칙 확정)
|
||||
- `공유/PD_지시_트래킹/{개발팀,기획팀}_PD_지시_로그.md` (활성·아카이브 2분할 구조 실증)
|
||||
|
||||
### 5-5. 규칙 본문 SOT
|
||||
|
||||
- `.claude/skills/BurningTimes-코어룰/SKILL.md` (헌법 제1원칙·C1~C37·P1~P31 단일 SOT)
|
||||
- `CLAUDE.md` (루트 요약 + `@.claude/skills/BurningTimes-코어룰/SKILL.md` 참조)
|
||||
|
||||
### 5-6. 미확인·참고용 경로 (본 산출물 작성 시 Read 안 한 경로, 차기 감사 시 확인 권장)
|
||||
|
||||
- `공유/일일보고/2026-04-15_{개발실,기획실,총괄PM}.md` 3건 (P20 폐기 직전 마지막 기록)
|
||||
- `공유/조직공지/` 기타 조직공지 (2026-04-14~2026-04-20 전 30+건, 본 산출물은 대표 4건만 인용)
|
||||
- `memory/org/MEMORY.md` 인덱스 (전체 40+ feedback 요약 보유)
|
||||
|
||||
---
|
||||
|
||||
## 변경 이력
|
||||
|
||||
| 일시 | 변경자 | 내용 |
|
||||
|------|--------|------|
|
||||
| 2026-04-21 | 총괄PM (BT 출범 이관 세션) | 신설 v1 — 수상한잡화점 프로젝트 + 조직 운영 집중기(2026-04-14~2026-04-20) 시행착오 20건 + PM 체크리스트 9종 + 안건 6종 추출 |
|
||||
Loading…
Reference in New Issue