# Software Development Constitution (소프트웨어 개발 헌법)

모든 AI 어시스턴트와 개발자는 이 헌법을 따른다.
이 원칙들은 코드 품질, 보안, 유지보수성을 보장하기 위한 보편적 규칙이다.

---

## 1. 설계 원칙 (Design Principles)

### SRP (Single Responsibility Principle)
- 하나의 모듈/함수/클래스는 하나의 책임만 가진다.
- 변경의 이유가 하나뿐이어야 한다.

### DRY (Don't Repeat Yourself)
- 동일한 로직을 두 곳 이상에서 반복하지 않는다.
- 중복이 발견되면 즉시 추출한다.

### KISS (Keep It Simple, Stupid)
- 가능한 한 단순하게 구현한다.
- 불필요한 추상화 레이어를 추가하지 않는다.

### YAGNI (You Aren't Gonna Need It)
- 현재 필요하지 않은 기능을 미리 구현하지 않는다.
- 프레임워크/라이브러리 도입 전 "이거 없이 직접 구현할 수 있는가?" 먼저 질문한다.

### Composition over Inheritance
- 상속보다 구성을 선호한다.
- 깊은 상속 계층을 만들지 않는다.

---

## 2. 아키텍처 원칙 (Architecture Principles)

### Loose Coupling (느슨한 결합)
- 모듈 간 의존성을 최소화한다.
- 인터페이스를 통해 소통한다.

### High Cohesion (높은 응집도)
- 관련된 기능은 한 모듈에 모은다.
- 모듈의 내부 요소들은 강하게 연관되어야 한다.

### Separation of Concerns
- 각 계층/모듈은 명확한 역할을 가진다.
- 역할을 침범하지 않는다.

---

## 3. 코딩 원칙 (Coding Principles)

### 의미 있는 네이밍
- 변수, 함수, 클래스 이름은 목적을 드러낸다.
- 약어를 피하고 의도를 명확히 전달한다.
- 불리언은 is/has/can 접두사를 사용한다.

### 일관된 포맷팅
- 프로젝트 내 코딩 스타일을 통일한다.
- 린터/포맷터 설정을 공유하고 자동화한다.

### 함수 설계
- 함수는 하나의 작업만 수행한다.
- 매개변수는 3개 이하를 권장한다.
- 부수 효과(side effect)를 최소화한다.

---

## 4. 보안 원칙 (Security Principles)

### Defense in Depth (심층 방어)
- 단일 보안 계층에 의존하지 않는다.
- 여러 계층의 보안 검증을 적용한다.

### 최소 권한 원칙 (Least Privilege)
- 필요한 최소한의 권한만 부여한다.
- 기본값은 거부(deny by default)이다.

### 입력 검증 (Input Validation)
- 모든 외부 입력을 검증한다.
- 화이트리스트 방식을 선호한다.

### OWASP Top 10 인식
- Injection, XSS, CSRF 등 주요 취약점을 항상 경계한다.
- 사용자 입력을 신뢰하지 않는다.
- 시크릿(API 키, 비밀번호)을 코드에 하드코딩하지 않는다.

---

## 5. 테스트 원칙 (Testing Principles)

### 테스트 피라미드
- 단위 테스트 > 통합 테스트 > E2E 테스트 비율을 유지한다.
- 단위 테스트가 가장 많아야 한다.

### 의미 있는 테스트
- 구현이 아닌 동작을 테스트한다.
- 엣지 케이스와 에러 경로를 테스트한다.
- 테스트 이름은 기대 동작을 서술한다.

### 테스트 격리
- 각 테스트는 독립적으로 실행 가능해야 한다.
- 테스트 간 상태를 공유하지 않는다.

---

## 6. 에러 처리 원칙 (Error Handling Principles)

### Fail Fast
- 잘못된 상태를 조기에 감지하고 즉시 실패한다.
- 오류를 삼키지(swallow) 않는다.

### 구조화된 로깅
- 로그는 구조화된 형식(JSON 등)으로 출력한다.
- 로그 레벨(debug, info, warn, error)을 적절히 사용한다.
- 민감 정보를 로그에 남기지 않는다.

### 에러 전파
- 에러는 적절한 계층에서 처리한다.
- 처리할 수 없는 에러는 상위로 전파한다.
- 사용자에게 의미 있는 에러 메시지를 제공한다.

---

## 7. Git 원칙 (Git Principles)

### Conventional Commits
- 커밋 메시지는 `type(scope): description` 형식을 따른다.
- type: feat, fix, docs, style, refactor, test, chore

### 의미 있는 커밋 메시지
- "fix bug" 같은 모호한 메시지를 사용하지 않는다.
- 무엇을 왜 변경했는지 설명한다.

### 원자적 커밋
- 하나의 커밋은 하나의 논리적 변경만 포함한다.
- 관련 없는 변경을 함께 커밋하지 않는다.

---

## 8. API 원칙 (API Principles)

### RESTful 원칙
- 리소스 중심 URL 설계.
- 적절한 HTTP 메서드 사용 (GET, POST, PUT, DELETE).
- 상태 코드를 의미에 맞게 반환한다.

### Backward Compatibility
- 기존 API 사용자를 깨뜨리지 않는다.
- breaking change 시 버전닝을 사용한다.
- deprecation 기간을 제공한다.

### 일관된 응답 형식
- 에러 응답 형식을 통일한다.
- 페이지네이션, 필터링 패턴을 일관되게 유지한다.

---

## 9. 코드 리뷰 체크리스트

코드를 작성하거나 리뷰할 때 아래를 확인한다:

- [ ] SRP: 하나의 책임만 가지는가?
- [ ] 네이밍: 의도가 명확한가?
- [ ] 보안: 입력 검증, 인증/인가가 적절한가?
- [ ] 에러 처리: 실패 경로가 처리되었는가?
- [ ] 테스트: 핵심 로직이 테스트되었는가?
- [ ] 성능: 불필요한 연산이나 N+1 쿼리가 없는가?
- [ ] 로깅: 디버깅에 필요한 로그가 있는가?
- [ ] 시크릿: 하드코딩된 비밀이 없는가?

---

## 적용 규칙

1. **필수 원칙**: 모든 원칙은 기본적으로 준수한다.
2. **예외**: 정당한 이유가 있으면 예외를 허용하되, 그 이유를 문서화한다.
3. **점진적 개선**: 레거시 코드는 수정 시 점진적으로 원칙에 맞춘다.
4. **자율 판단**: 기술적 결정은 이 헌법을 기반으로 자율적으로 판단한다. 모호한 경우에만 사용자에게 질문한다.