BurningTimesAi/프로젝트/EerieVillage/기획/system/02_특성_시스템.md

---
type: 시스템_설계
scope: 특성_시스템
author: system-designer
date: 2026-04-22
version: v0.1
project: EerieVillage (기묘한 고을 : 조선퇴마뎐 / EerieVillage: Joseon Exorcist)
phase: Phase 3-B
data_source: 03_진행_시스템_초안.md §5 / PD 코어 룰 9
status: 핵심 메카닉 골격 확정 — 특성 종류·효과·획득 조건 텍스트는 content-designer 이관
---

# 02. 특성 시스템

## 1. 목적

**이 시스템이 풀고자 하는 플레이어 문제**
"죽어도 완전히 제로로 돌아가지 않는다는 안도감, 그리고 많이 플레이할수록 내 캐릭터가 근본적으로 달라진다는 성장 체감"을 제공한다.
PD 코어 룰 9(특성 사망·레벨 초기화 유지)는 런 간 영속 성장의 구조적 근거다.

**제공하는 경험**
- 카드 전손(축 A)의 낙차를 "이번 런도 쌓였다"는 누적 감각으로 완충
- 런을 반복할수록 퇴마사가 점진적으로 변화하는 정체성 강화
- 특성 조합에 따라 다음 런의 빌드 방향이 달라지는 장기적 선택 재미

---

## 2. 코어 루프

```
조건 충족 이벤트 발생 (보스 처치 / 누적 도전 / 런 중 이벤트)
    ↓
특성 후보 UI 표시 — 플레이어가 선택 or 자동 획득
    ↓
특성 저장소(persistentDataPath JSON)에 즉시 기록
    ↓
다음 런 시작 시 자동 적용
    ↓
특성 효과가 카드·아이템·전투 수식자로 작동
```

---

## 3. 규칙

### 규칙 1. 특성 3축 구조

| 축 | 명칭 | 효과 방향 | 특징 |
|----|------|----------|------|
| A축 | **능력치 특성** | 기본 수치 상향 (공격력·이동 속도·i-frame 등) | 항상 가시적 효과, 단순 |
| B축 | **해금 특성** | 새 메카닉·카드 티어·조건 해제 | 플레이 폭 확장, 강한 체감 |
| C축 | **선택지 특성** | 픽 알고리즘 변형 or 빌드 방향 편향 | 전략 방향 결정, 조합 시 시너지 |

각 획득 조건에서 세 축 중 하나의 특성이 제공된다. 한 번의 조건 충족에서 복수 축이 동시 제공되지 않는다.

### 규칙 2. 획득 조건 3종

1) **보스 처치 보상** — 보스 클리어 직후 특성 후보 K장 중 1장 선택. K 수치는 balance-designer.
2) **누적 도전 과제** — 런 수·처치 수·사망 횟수 등 메타 누적값이 임계치 도달 시 자동 획득 (선택 없음).
3) **런 중 이벤트** — 스테이지 내 특수 조건(미탐색 구역 달성 등) 충족 시 즉시 획득. 선택형 or 자동형은 content-designer·balance-designer 결정.

### 규칙 3. 상호 배타(Exclusive) 쌍 체계

특성 중 일부는 **배타 쌍**으로 설계된다. 배타 쌍의 특성 A를 보유 중이면 특성 B가 획득 후보에서 제거된다.

- 배타 쌍은 B축(해금) 및 C축(선택지) 특성에 한정 적용한다.
- A축(능력치) 특성은 배타 없음 — 중복 획득 시 효과 누적.
- 배타 쌍 목록은 content-designer가 정의. 시스템은 보유 목록과 배타 맵을 조회해 후보 필터링만 수행.

### 규칙 4. 특성 슬롯 — 무제한

특성 보유 상한을 두지 않는다. 런을 반복할수록 특성이 누적되어 캐릭터가 변화하는 것이 본 시스템의 핵심 경험이다.

- **수치 특성 상한**: A축 특성이 동일 수치 항목에 누적되는 경우, 합산 상한 캡(cap)을 적용한다. 수치는 balance-designer 영역.
- 무제한 획득이 밸런스를 붕괴시키지 않도록 각 특성의 효과 강도를 balance-designer가 캡 기반으로 설계해야 한다.

### 규칙 5. 데이터 모델 (persistentDataPath JSON 초안)

개발팀 03에서 확정한 persistentDataPath 저장 방식을 따른다. 구조 초안:

```json
{
  "traits": [
    {
      "id": "trait_001",
      "axis": "B",
      "acquired_at": "2026-01-01T00:00:00",
      "exclusive_group": "exg_001"
    }
  ],
  "trait_version": 1
}
```

- `id`: 특성 고유 식별자 (content-designer 명명)
- `axis`: A/B/C 축 분류
- `acquired_at`: 획득 시각 (디버그·통계용)
- `exclusive_group`: 배타 쌍 그룹 ID. null이면 배타 없음
- `trait_version`: 데이터 스키마 버전 (향후 특성 추가·삭제 대응용 마이그레이션 플래그)

### 규칙 6. 리셋 조건 — 절대 리셋 없음 (기본)

특성은 **어떤 이유로도 초기화되지 않는다** (PD 코어 룰 9). 이것이 축 C(영속 성장)의 본질이다.

- **예외 조건**: PD님 명시 지시로 "초기화 옵션(재도전 콘텐츠용 리셋)"을 Phase 3-C BM 설계 시 재검토 가능. 현재 파일럿 스코프에서는 리셋 없음.

---

## 4. 상태와 전이

| 상태 | 설명 | 전이 조건 |
|------|------|----------|
| 미획득 | 특성 풀에 존재하나 플레이어 미보유 | 획득 조건 충족 + 플레이어 선택 or 자동 획득 → 보유 |
| 보유 | persistentDataPath에 기록, 효과 발동 | 절대 전이 없음 (리셋 없음 원칙) |
| 잠금(Locked) | 배타 쌍에 의해 획득 불가 상태 | 배타 특성 보유 → 잠금. 해제 조건 없음 |

---

## 5. 인풋 / 아웃풋

**입력**
- 보스 클리어 이벤트 (스테이지 시스템)
- 누적 도전 과제 임계치 도달 (메타 진행 데이터 감시)
- 런 중 이벤트 트리거

**시스템 반응**
- 특성 후보 UI 표시 (선택형) or 즉시 적용 알림 (자동형)
- JSON Write (persistentDataPath)
- 다음 런 시작 시 특성 효과 자동 로드

**필요한 피드백 종류 (ux-designer 연계)**
- 특성 획득 시 강조 연출 (영속 획득임을 체감하게)
- 현재 보유 특성 목록 UI (어떤 특성이 쌓였는지 확인 가능)
- 배타 특성 잠금 상태 시각화

---

## 6. 타 시스템 연동

| 연동 시스템 | 연동 방식 |
|------------|----------|
| **카드 시스템** (01_카드_시스템) | B축 특성이 픽 알고리즘 가중치 수정 or T2/T3 해제 조건 완화 |
| **전투 시스템** (04_전투_기본_스펙) | A축 특성이 공격·이동·i-frame 수치에 수식자 적용 |
| **스테이지 구조** (05_스테이지_구조_초안) | 보스 처치 이벤트 발화 → 특성 획득 트리거 |
| **개발팀 persistentDataPath** (개발팀 03) | JSON 저장·로드 구현 책임 (개발팀 영역) |

---

## 7. 엣지 케이스

1) **배타 쌍 전부 잠김으로 후보 소진**: 후보 풀에서 배타 필터 적용 후 0장이 되는 경우 → 배타 없는 A축 특성으로 강제 대체. content-designer가 A축 여분을 충분히 설계해야 한다.
2) **동일 특성 중복 획득 시도**: 이미 보유한 특성 ID가 후보에 나타나지 않도록 보유 목록 필터를 항상 먼저 적용.
3) **trait_version 불일치 (마이그레이션)**: 게임 업데이트로 특성 ID 변경·삭제 시 version 필드로 감지 → 구버전 ID는 무효 처리(손실 없이) + 마이그레이션 로직은 개발팀 책임.
4) **첫 런 (특성 0개)**: 특성 없이도 게임이 정상 작동해야 한다. 모든 특성 효과는 "있을 경우 추가 적용"이며, 기본 게임플레이는 특성 독립적으로 설계한다.

---

## 8. 기각안

1) **런 내 임시 특성(런 종료 시 소멸) — 기각.** 카드 시스템(축 A)과 역할 충돌. 03_진행_시스템_초안 §7 기각안 3번 계승. 런 내 임시 효과는 카드로 담당.

2) **특성 슬롯 N개 상한 — 기각.** 슬롯 상한은 "어떤 특성을 버릴까"라는 별도 결정 레이어를 요구하고, 영속 성장 경험을 "희소성 관리"로 왜곡한다. 축 C의 본질(도전 지속성 제공)이 무력화된다. 수치 캡(규칙 4)으로 밸런스를 제어하는 방향이 구조 단순성·경험 우위.

3) **특성 구매형(메타 재화 소모) — 기각.** BM 미확정 상태에서 런 간 재화 루프와 특성 획득을 결합하면 범위 초과. 획득 조건을 재화 종속으로 만들면 BM 방향에 따라 시스템 구조 전면 변경 필요. Phase 3-C BM 설계 이후 재검토 안건으로 보관.

4) **특성 선택 없이 전량 자동 획득 — 기각.** 자동 획득은 선택의 즐거움을 제거한다. 보스 처치 후 K장 선택 구조(규칙 2-1번)는 "이 특성을 선택하는 것이 내 빌드 방향에 맞는가"라는 소규모 전략 결정 지점을 제공한다. 단, 도전 과제 기반 자동 획득(규칙 2-2번)은 리워드 성격이므로 예외 허용.

---

## 9. 열린 이슈 (balance·content·ux·개발팀 이관)

1) **[content]** 특성 종류·ID·효과 텍스트 전체 리스트 — 3축 분류 + 조선 퇴마 세계관 반영 명칭.
2) **[content]** 배타 쌍 맵 정의 — 어떤 특성들이 배타 관계인가.
3) **[balance]** A축 특성 수치 캡 설정 — 어느 수준에서 성장을 막을 것인가.
4) **[balance]** 보스 처치 후 특성 후보 K장 수치.
5) **[content]** 누적 도전 과제 항목 및 임계값 설계.
6) **[ux]** 특성 획득 연출·보유 목록 UI·배타 잠금 시각화.
7) **[개발팀]** persistentDataPath JSON 스키마 최종 확정 + 마이그레이션 로직 구현.

---

## 10. 변경 이력

| 일시 | 변경 | 사유 | 기안 |
|------|------|------|------|
| 2026-04-22 | v0.1 시스템 설계 초안 | BT6-Plan Phase 3-B PD 지시 | system-designer |