30 KiB
30 KiB
| type | scope | author | date | version | project_source | project_target | sub_scope | ||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 시행착오_아카이브 | 기획팀_통합 | 기획팀장 | 2026-04-21 | v1 | 수상한잡화점 (NerdNavis, 2025-2026) | EerieVillage (BurningTimes, 2026~) |
|
기획팀 통합 시행착오 아카이브 v1 — 시스템·컨텐츠·레벨·시나리오·밸런스·UX 총괄 관점
1. 개요 — 핵심 교훈 10건 요지
- "데이터 구조 실측 선행"이 기획팀 전체의 제1원칙이다. "WorldMap 4그룹" 추측 SOT가 Phase 4 지역 1 v1 전체를 폐기시킨 사건은 기획팀 역사상 최대 재작업 사례. CSV/JSON Export 실측 없는 기획 작업은 시한폭탄이다.
- Phase 범위 재정의는 기획팀장 재량을 넘어 PD님 승인 영역이다. Phase 3를 "설계 체계 확립"으로 재정의하고 Day 15+를 Phase 4로 분리한 결정은 PD B안 수용 전제 위에서만 집행 가능했다.
- PD님 확정 용어는 절대 변형·축약 금지. "Phase 1~4"를 "A/B/C/D"로 재매핑하거나, "지역"을 "WorldMap 그룹"으로 치환하는 것은 C22 위반이자 재작업의 직접 원인.
- 재미 판단은 기획팀 고유 영역이지만, 수치 판단은 개발팀 C11과 조율 필수. P30(재미 우선) 전제 위에 C11(자원 효율·코드 구조·범용성) 충돌이 발생하면 PM·PD님 판단으로 에스컬레이션.
- "설계 원칙 vs 임시 데이터" 분리 구조가 차기 프로젝트 자산 계승의 핵심. C9 배치 원칙·P17 배타 체크·TTK 산출·AppearGroup 가이드 4종은 수치와 독립적으로 유효해야 P29 실현.
- ★ 조건 배타 조합 P17 7종은 매 스테이지 전수 체크 의무. 단일 스테이지 위반 1건이라도 감지 시 Phase 즉시 중단 + PD 확인 (PD B 방식). 추후 발견되는 것보다 집행 초입 차단이 훨씬 저렴하다.
- 기존 SOT 맹신 금지 — "이전 문서에 쓰여 있으니까"는 근거가 아니다.
스테이지난이도곡선_v1§1의 "WorldMap_1~4 4개 그룹" 전제를 Phase 3 종결 문서·Phase 4 착수 가이드·지역 1 v1까지 무비판 계승한 결과 지역 1 v1 전면 폐기. - 어뷰징 판정 솔루션은 기획팀이 "프레임워크·경계값 산출 방법론"까지만 책임. 실 검증 로직은 서버팀 이관 (역할 경계 명확). 기획팀이 서버 검증 코드까지 설계하면 C11 개발 관점 원칙 침범.
- 병렬 호출 체계(기획팀장 + level + balance 병렬)는 청크 단위 독립 작업에 최적. Day 11~14 레벨축·밸런스축을 병렬 집행한 결과 일정 단축 + 교차 검증 품질 확보. 단 의존 작업은 순차.
- 전문 에이전트 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.mdRead (PM과의 협업 맥락)공유/조직자산/시행착오_아카이브/개발_팀장_v1.mdRead (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가지 교훈을 반복 체험했다:
- 데이터 실측 없는 기획은 모래 위의 집 — WorldMap 4그룹 사건이 증명
- PD님 확정 용어의 변형 = 재작업의 직접 원인 — C22는 선택이 아닌 필수
- 설계 원칙과 임시 수치의 분리 = 차기 프로젝트 자산 계승의 필수 조건 — P29의 실천 방법
- 기획팀의 책임은 "재미"이지만 개발 관점·PD 방향·자원 효율과의 조율 없이는 실현 불가 — P30·C11·C36·C1의 네트워크
EerieVillage 기획팀장은 이 아카이브를 **"이미 지나온 함정 지도"**로 활용하되, 장르 차이(덱빌딩 → 플랫포머)에 따른 차별화 재검토를 병행한다. 재미는 장르마다 다르지만, 재미를 설계하고 검증하고 기록하고 계승하는 방법론은 조직 자산으로 계승 가능하다.
작성 완료: 2026-04-21 BurningTimes 조직 자산 — 기획팀 통합 시행착오 아카이브 v1