influence/.cursor/rules/safe-development-practice.mdc

# 🛡️ 안전한 개발 실천 규칙 (Safe Development Practice)

## 핵심 원칙: "기존 기능 우선 보호"

**모든 기능 수정, 추가, 버그 픽스 시 기존 정상 기능들이 영향받지 않도록 사전 체크 및 안전장치 적용이 최우선**

---

## 📋 필수 체크리스트

### Phase 1: 사전 영향도 분석 (Pre-Impact Analysis)
- [ ] **기존 기능 매핑**: 수정할 영역과 연관된 모든 기존 기능 식별
- [ ] **API 의존성 분석**: 기존 API 엔드포인트, 요청/응답 형식 확인
- [ ] **데이터베이스 스키마 확인**: 테이블, 제약조건, 인덱스 영향도 분석
- [ ] **프론트엔드 연동 확인**: 컴포넌트, 라우팅, 상태관리 영향도 분석

### Phase 2: 안전한 설계 (Safe Design)
- [ ] **독립적 구조**: 새 기능은 기존 기능과 분리된 독립적 구조로 설계
- [ ] **하위 호환성**: 기존 API 스펙, 데이터 형식 유지
- [ ] **점진적 적용**: 한 번에 여러 영역 수정하지 않고 단계별 적용
- [ ] **롤백 계획**: 문제 발생 시 즉시 이전 상태로 복구 가능한 계획 수립

### Phase 3: 구현 중 안전장치 (Implementation Safeguards)
- [ ] **새로운 API 엔드포인트**: 기존 API 수정 대신 새 엔드포인트 생성
- [ ] **별도 메서드/함수**: 기존 로직 수정 대신 새 메서드 생성
- [ ] **데이터 아카이브**: 기존 데이터 삭제 대신 비활성화 또는 아카이브
- [ ] **조건부 활성화**: 플래그나 설정을 통한 새 기능 조건부 활성화

### Phase 4: 테스트 및 검증 (Testing & Validation)
- [ ] **기존 기능 회귀 테스트**: 모든 기존 기능 정상 작동 확인
- [ ] **API 응답 검증**: 기존 API 응답 형식 및 데이터 정확성 확인
- [ ] **데이터 무결성 검증**: 데이터베이스 제약조건, 관계 정상 확인
- [ ] **UI/UX 검증**: 기존 화면 및 사용자 플로우 정상 작동 확인

---

## 🚫 금지사항 (Never Do)

### 기존 코드 직접 수정 금지
```javascript
// ❌ 기존 함수 직접 수정
function existingFunction() {
  // 기존 로직
  // 새로운 로직 추가 - 위험!
}

// ✅ 새로운 함수 생성
function newFeatureFunction() {
  // 새로운 로직
}
```

### 기존 API 스펙 변경 금지
```javascript
// ❌ 기존 API 응답 형식 변경
{
  "success": true,
  "data": [], // 기존 구조 변경 - 위험!
  "newField": "새 필드 추가" // 브레이킹 체인지
}

// ✅ 새로운 API 엔드포인트
POST /api/new-feature
{
  "success": true,
  "data": {
    "newStructure": "새 구조"
  }
}
```

### 데이터베이스 파괴적 변경 금지
```sql
-- ❌ 기존 테이블/컬럼 삭제
DROP TABLE existing_table;
ALTER TABLE users DROP COLUMN important_field;

-- ✅ 새로운 테이블/컬럼 추가
CREATE TABLE new_feature_table (...);
ALTER TABLE users ADD COLUMN new_optional_field VARCHAR(255);
```

---

## 🔧 안전한 수정 패턴

### 1. 기능 확장 패턴
```javascript
// 기존 기능 유지하면서 확장
class OriginalService {
  existingMethod() {
    // 기존 로직 그대로 유지
  }
  
  newMethod() {
    // 새로운 기능 추가
  }
}
```

### 2. 조건부 분기 패턴
```javascript
function processRequest(type) {
  if (type === 'existing') {
    return existingLogic(); // 기존 로직
  } else if (type === 'new') {
    return newLogic(); // 새 로직
  }
}
```

### 3. 데코레이터/래퍼 패턴
```javascript
function enhancedFunction(originalFunction) {
  return function(...args) {
    // 새로운 전처리
    const result = originalFunction(...args); // 기존 로직
    // 새로운 후처리
    return result;
  };
}
```

---

## 📊 영향도 매트릭스

| 수정 영역 | 기존 기능 영향도 | 안전장치 |
|-----------|------------------|----------|
| 새 API 추가 | 🟢 낮음 | 독립적 엔드포인트 |
| 기존 API 수정 | 🔴 높음 | 하위 호환성 보장 |
| 새 DB 테이블 | 🟢 낮음 | 독립적 스키마 |
| 기존 DB 수정 | 🟡 중간 | 비파괴적 변경만 |
| 새 UI 컴포넌트 | 🟢 낮음 | 별도 컴포넌트 |
| 기존 UI 수정 | 🟡 중간 | 조건부 렌더링 |

---

## 🚨 긴급 상황 대응

### 기존 기능 장애 발생 시
1. **즉시 롤백**: 새 기능 비활성화 또는 이전 버전 복구
2. **원인 분석**: 어떤 변경이 기존 기능에 영향을 주었는지 분석
3. **긴급 패치**: 기존 기능 복구를 최우선으로 처리
4. **재설계**: 안전한 방식으로 새 기능 재구현

### 롤백 절차
```bash
# 1. 즉시 이전 상태로 복구
git revert HEAD
git push origin main

# 2. 데이터베이스 복구 (필요시)
mysql -u root -p < backup_before_change.sql

# 3. 캐시 클리어
redis-cli FLUSHALL
```

---

## 📝 체크리스트 템플릿

### 기능 수정 전 체크
```markdown
## 기능 수정 안전성 체크리스트

**수정 날짜**: ___________
**수정자**: ___________
**수정 내용**: ___________

### Phase 1: 영향도 분석
- [ ] 관련 기존 기능 목록 작성
- [ ] API 의존성 확인
- [ ] 데이터베이스 영향도 확인
- [ ] 프론트엔드 영향도 확인

### Phase 2: 안전한 설계
- [ ] 독립적 구조 설계
- [ ] 하위 호환성 보장
- [ ] 롤백 계획 수립

### Phase 3: 구현
- [ ] 새로운 엔드포인트/메서드 사용
- [ ] 기존 코드 직접 수정 없음
- [ ] 조건부 활성화 적용

### Phase 4: 테스트
- [ ] 기존 기능 회귀 테스트 완료
- [ ] 새 기능 정상 작동 확인
- [ ] 데이터 무결성 확인
```

---

## 💡 베스트 프랙티스

1. **"기존 기능 우선"** 마인드셋 유지
2. **점진적 개발**: 작은 단위로 나누어 안전하게 구현
3. **충분한 테스트**: 새 기능과 기존 기능 모두 테스트
4. **문서화**: 변경사항과 안전장치 상세 기록
5. **팀 공유**: 변경사항을 팀원들과 사전 공유 및 리뷰

**"새로운 기능을 추가하되, 기존의 가치를 지켜라"**
description:
globs:
alwaysApply: false
---