---
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 몬스터 미등장 근본 원인