# 단순 반복 업무 카탈로그 v1 (BurningTimes)

**발행일**: 2026-04-24
**근거**: PD 직접 결정 (2026-04-24 BT9) — NerdNavis 카탈로그 경험을 BT에 반영. "이 방식으로 운영해보고 추후 업무 범위는 조정할 수 있다"
**관련 규칙**: P7·P8·P33·C43

---

## 1. 카탈로그 목적

**팀원(Sonnet)에게 병렬로 위임 가능한 단순 반복 업무의 영구 SOT**.

본 카탈로그는 팀장(Opus)이 직접 처리하지 않고 팀원(Sonnet)에게 위임할 단순 반복 업무를 정의한다. 카탈로그 적용으로 Opus 토큰 부담을 분산하고 팀장이 **해석·설계·통합·재미 판단**에 집중할 수 있도록 한다.

### BT 조직 특수성 반영

BurningTimes는 **EerieVillage (기묘한 고을 : 조선퇴마뎐) 2D 플랫포머 프로젝트 + BT.Framework 조직 자산 구축**의 2대 프로젝트 체제. NerdNavis 원 카탈로그의 Unity·Sim 엔진 기반 구조는 계승하되, BT 프로젝트 실태에 맞게 조정.

## 2. 운영 원칙

1. **카탈로그 일괄 채택** (2026-04-24 PD 결정) — 25종 모두 즉시 적용
2. **운영 후 조정 가능** (PD 명시) — 운영 결과 따라 항목 추가·제외·세분 가능
3. **카탈로그 외 = 팀장 잔존 영역** — 결과 해석·신규 설계·재미 판단·영역 조율은 팀장(Opus) 직접
4. **모호 시 PD 확인 의무** (PD 명시) — 카탈로그 분류 모호 시 PM·팀장이 PD 질의 후 결정
5. **위임 결과 책임** — 팀원 산출물의 품질·정합성은 팀장이 사후 검토 의무 (P7-3)

## 3. 개발팀 카탈로그 (14종)

### 3-1. 클라이언트 (4종)
| # | 작업 | 설명 |
|---|------|------|
| 1 | Unity prefab 복제·수정 | 기존 패턴 복제 (신규 디자인 X) |
| 2 | UI 레이아웃 조정 | 기존 디자인 적용 (신규 UX X) |
| 3 | 셰이더 파라미터 조정 | 기존 셰이더 활용 (신규 셰이더 X) |
| 4 | 로컬라이제이션 텍스트 추가 | 기존 키 패턴 적용 |

### 3-2. 서버 (3종)
| # | 작업 | 설명 |
|---|------|------|
| 5 | API 엔드포인트 추가 | 기존 패턴 복제 |
| 6 | DTO 클래스 생성 | 스키마 변환 |
| 7 | 단순 CRUD 쿼리 작성 | 기존 패턴 |

### 3-3. QA (3종)
| # | 작업 | 설명 |
|---|------|------|
| 8 | 회귀 테스트 케이스 작성 | 기존 시나리오 복제 |
| 9 | 빌드 결과물 검증 자동화 실행 | 기존 스크립트 실행 |
| 10 | 테스트 결과 리포트 정리 | 데이터 집계 |

### 3-4. DevOps (4종)
| # | 작업 | 설명 |
|---|------|------|
| 11 | CI/CD 파이프라인 설정 추가 | 기존 템플릿 활용 |
| 12 | 로그 수집·분석 스크립트 실행 | 기존 스크립트 |
| 13 | 환경 변수 관리 | 설정 파일 갱신 |
| 14 | 배포 후 헬스체크 자동화 | 기존 절차 |

## 4. 기획팀 카탈로그 (11종)

### 4-1. 검증·시뮬 (5종) — BT 프로젝트 맞춤
| # | 작업 | 설명 |
|---|------|------|
| 15 | 플랫포머 레벨 기초 검증 | 기존 Tilemap 패턴 검증 · 점프 거리·플랫폼 간격 수치 확인 |
| 16 | Baseline 측정 | 동일 조건 N회 반복 + 평균 산출 |
| 17 | 스테이지별 플레이타임 측정 | 각 스테이지 순회 실행 + 타임 기록 |
| 18 | 인카운터 밀도 카운팅 | 맵별 몬스터·아이템 배치 통계 |
| 19 | Pass/Fail 카운팅 | 결과 로그 파싱 + 통계 산출 |

### 4-2. 문서 정리·검증 (3종)
| # | 작업 | 설명 |
|---|------|------|
| 20 | 기획 문서 오탈자·참조 링크 수정 | 단순 텍스트 편집 (의미 변경 X) |
| 21 | 테이블 export 검증 | xlsm → CSV 변환 후 행·컬럼 정합 |
| 22 | 백업 파일 생성 | C6-1 표준 포맷 (`{원본명}.bak_{YYYYMMDD_HHMM}.{확장자}`) |

### 4-3. 데이터·컨텐츠 정리 (3종)
| # | 작업 | 설명 |
|---|------|------|
| 23 | CSV·JSON 파싱·집계 | 통계 산출 (해석은 제외) |
| 24 | 로그 grep·파일 mtime 확인 | C39 실측 데이터 수집 |
| 25 | 플레이버 텍스트·대사 정렬·단순 정정 | 오탈자·줄바꿈·맞춤법 교정 (작성은 제외 — 시나리오 디자이너 영역) |

## 5. 카탈로그 외 — 팀장 잔존 영역 (Opus 직접)

### 5-1. 공통 잔존
- 결과 **해석** (Pass/Fail 원인 분석·트렌드 판단)
- 신규 **설계** (시스템·기능 신설)
- 영역 간 **조율** (충돌 해결·우선순위 결정)
- **헌법·코어룰·프로젝트룰 영향** 변경

### 5-2. 개발팀 잔존
- 아키텍처 설계 결정
- 클라이언트-서버 인터페이스 정의
- 신규 시스템 도입 판단
- 성능 최적화 전략·보안 설계
- BT.Framework 조직 자산 설계·개선 (P29 영역)

### 5-3. 기획팀 잔존
- **재미·밸런스 판단** (P30 직접 영역)
- **시나리오 작성** (창작 영역 — 시나리오 디자이너)
- 신규 시스템·컨텐츠·레벨·조건 체계 설계
- 세계관·로어·대사 창작

## 6. 카탈로그 운영 절차

### 6-1. 위임 흐름
1. PM·팀장이 작업 수령 시 **카탈로그 매칭 확인**
2. 매칭 시 → 팀원(Sonnet) 직접 위임 (P33 병렬 활용)
3. 미매칭 시 → 팀장(Opus) 직접 처리 또는 PM·PD 확인
4. 팀원 산출물 수령 후 → **팀장 사후 검토 의무** (P7-3)

### 6-2. 카탈로그 갱신 절차
1. 운영 중 신규 단순 반복 패턴 발견 → PM 또는 팀장이 후보 식별
2. PM 분기별 review (C35-10 패턴 분석 정합)
3. PD 승인 후 본 SOT 갱신 + 버전 증가 (v1 → v2)

### 6-3. 위반 감지
- 카탈로그 외 작업을 팀원에 위임 → pm-auditor·dev-auditor·plan-auditor 감사
- 카탈로그 영역 작업을 팀장이 직접 처리 (Opus 토큰 낭비) → pm-auditor 감지

## 7. 연관 규칙

- **P7** 위임 원칙 (P7-1 PM 직접 팀원 위임 권한)
- **P8** 모델 정책 (3층 책임 분담)
- **P33** 서브에이전트 병렬 활용 (P33-1-A PM 직접 팀원 병렬 호출)
- **C29** 업무 자율 수행 체계
- **C43** PD 호칭별 직접 하달 체계 (단순 반복 예외)
- **C35** pm-auditor 의무 참여 (카탈로그 외 위임 감사)
- **C36** PM 재량 상한 (카탈로그 자체 정의는 PD 영역)

## 8. 변경 이력

| 버전 | 일시 | 변경 내용 | 근거 |
|------|------|----------|------|
| v1 | 2026-04-24 | 25종 BT 버전 신설 (NerdNavis 경험 반영) | PD 직접 결정 |

## 9. 기각안

### 기각안 1. "NerdNavis 원본 그대로 이식"
- **내용**: Region1~21·R20·★ 조건 등 NerdNavis 특유 용어·항목 그대로 유지
- **기각 사유**: BT 프로젝트(EerieVillage 2D 플랫포머 + BT.Framework)는 NerdNavis 프로젝트(덱빌딩 Prove-2-of-3)와 장르·구조 이질. 용어 혼선 유발 · BT 에이전트 혼란 가중
- **대안**: BT 프로젝트 실태에 맞게 재작성 — Region → 스테이지, ★ 조건 매핑 → 인카운터 밀도 카운팅, 시드 sweep → 레벨 기초 검증 등

### 기각안 2. "카탈로그 없이 팀장 자체 재량 판단"
- **내용**: PM·팀장이 매 건마다 판단하고 위임 결정
- **기각 사유**: (1) 판단 기준 주관성 → 팀장별 위임 기준 상이 (2) Opus 토큰 낭비 지속 (3) 분기별 PM 감사에 객관 기준 없음
- **대안**: SOT 카탈로그 보유 + 분기별 review 갱신

### 기각안 3. "기획팀 카탈로그에 '재미 판단'·'시나리오 작성' 포함"
- **내용**: 시나리오·컨텐츠 창작도 Sonnet 병렬로 분산 처리
- **기각 사유**: **P30 재미 우선 원칙 직접 영역 침범**. 재미·밸런스 판단·창작 영역은 기획팀장·시나리오 디자이너의 잔존 영역. Sonnet 분산 시 품질 저하 + 일관성 붕괴
- **대안**: 5-3 "기획팀 잔존" 영역으로 명시 분리 + Opus 직접 처리 의무화