defa_development_framework

Copyright (c) 2025 Jaewoo Kim

MIT License - https://opensource.org/licenses/MIT

Cursor 규칙 파일 최적화 분석 (DEF/DEF-A 모델 적용)

Phase D - Define (정의 · 대상화)

현황 분석

대상: DEF-A Development Framework — Cursor용 AI 개발 지원 프레임워크 목적: 보다 효과적인 AI 협업 개발을 위한 규칙 최적화

현재 규칙 파일의 구성

• 기본 설정 및 전문성 정의
• 인지 스타일 상세 기술
• 기술 스택 및 개발 방침
• AI 대화 스타일 지침
• 프로젝트별 최적화
• 구현 시 판단 기준
• 윤리 및 품질 고려 사항
• 출력 형식 지침

과제 · 개선 포인트

1. 실용성 문제: 이론적 서술이 많아, Cursor에서의 일상적인 코드 생성에 바로 연결되지 않음
2. 프롬프트 효율: 규칙 파일이 지나치게 장문으로 되어 있어 Cursor의 컨텍스트 처리 부담을 가중할 가능성
3. 액션 지향성 부족: “무엇을 고려해야 하는가”는 명시돼 있으나, “어떻게 구현해야 하는가”가 불분명
4. 단계적 적용의 부재: 프로젝트의 규모와 긴급도에 따라 규칙을 선택해 쓸 수 있는 유연성이 없음

---

Phase E - Explore (탐색 · 재구성)

E-1: Cursor 특성 기반 분석

Cursor의 특성:

• 인라인 자동완성과 채팅 기능의 병행 사용
• 파일 단위 문맥 이해
• 실시간 짧은 응답 시간 중요
• 프로젝트 전반의 구조 이해 가능

현재 규칙과의 적합성:

• ❌ 지나치게 길어 처리 부담이 큼
• ❌ 추상적 개념 설명이 많고 구체적 지시가 적음
• ✅ 품질 기준은 명확함
• ✅ 기술 스택 관련 기술은 실용적임

E-2: 구현 효율 관점

이상적인 Cursor 규칙:

• 짧은 시간에 해석 가능
• 구체적인 코드 생성 지침 제공
• 단계적 상세화(필요에 따라 깊이 조절 가능)
• 프로젝트 특성에 따른 자동 적응

현재 규칙의 문제점:

• 인지 이론 설명이 개발 작업과 직접 연결되지 않음
• 판단 기준은 제시되어 있지만, 구체적 구현 절차는 없음
• 에러 처리 지침이 개념적으로만 존재

E-3: 구조화 관점

효과적인 계층 구조:

1. 즉시 실행 레벨: 일상적인 코드 생성에 항상 적용되는 기본 규칙 → 코드 스타일, 네이밍, 짧은 패턴 등
2. 판단 지원 레벨: 기술 선택, 설계 판단 시 참고하는 상세 규칙 → 상태 관리, API 패턴 선택, DB 설계 시나리오 등
3. 전략 레벨: 프로젝트 설계, 장기적 의사결정 시 사용하는 메타 규칙 → 팀 협업 지침, 품질 보증 전략, 기술 부채 관리 등

---

Phase F - Formulate (통합 · 출력)

F-1: 최적화된 Cursor 규칙 구조안

# Cursor Rules - DEF-A Development Framework

## [CORE] 즉시 실행 규칙 (항상 적용)
- **코드 품질**: 가독성 > 화려함, 명확한 변수명, 적절한 주석
- **프런트엔드**: 반응형 대응(모바일 우선), 접근성 기준 준수, Core Web Vitals 의식
- **백엔드**: API 설계·데이터베이스 최적화, 서버 성능, 확장성 고려
- **보안**: 입력 검증, XSS 대응, SQL 인젝션 대응, 인증·권한 관리, 적절한 에러 처리
- **테스트 주도**: 상황에 따른 TDD/BDD 적용 판단

## [TECH] 기술 스택 (우선순위 지정)
### 프런트엔드
1. **JavaScript/TypeScript** - 타입 안정성 중시
2. **Nuxt.js/Next.js** - JAMstack 구성
3. **CSS** - PostCSS, CSS Grid/Flexbox

### 백엔드
1. **Node.js/TypeScript** - 서버 사이드 개발
2. **Python/FastAPI** - API 개발 및 데이터 처리
3. **데이터베이스** - PostgreSQL, Redis, MongoDB
4. **인프라** - Docker, Kubernetes, AWS/GCP

### 구현 방침
- **프런트엔드**: ES6+ 문법 사용, async/await 중심, 컴포넌트 재사용성 극대화, 번들 크기 최적화
- **백엔드**: RESTful API 설계, 데이터베이스 최적화, 보안 구현, 확장성 고려

## [TDD/BDD] 테스트 주도 개발 · 행동 주도 개발

### TDD (테스트 주도 개발) - Kent Beck의 사상
**핵심 사상**: Red-Green-Refactor 사이클, 단순한 설계, 동작하는 깔끔한 코드가 개발자의 자신감을 높임

#### Red-Green-Refactor 사이클
1. **Red**: 실패하는 테스트 작성 (예상 동작 명확화)
2. **Green**: 테스트를 통과시키는 최소한의 코드 작성 (동작하는 코드)
3. **Refactor**: 코드를 정리해 유지보수성 향상

#### 실천적 관점 (와다 타쿠토의 사상)
- **안전망으로서의 테스트**: 테스트는 개발의 ‘세이프티넷’ 역할
- **단계적 구현**: 작은 단계로 안정적으로 진행
- **자신감 고양**: 동작하는 코드가 개발자의 자신감을 높임

#### TDD 적용 규칙

[TDD 적용] Red-Green-Refactor 사이클을 적용해 테스트 우선 개발을 실천합니다.

• 테스트 선행: 구현 전에 테스트 작성
• 최소 구현: 테스트를 통과시키는 최소한의 코드 작성
• 지속적 리팩터링: 동작하는 코드를 깔끔하게 유지

### BDD (행위 주도 개발) - Dan North의 사상
**핵심 사상**: 개발자와 비개발자 간의 원활한 커뮤니케이션, 비즈니스 가치의 명확화

#### Given-When-Then형식
```gherkin
Given [전제 조건]
When [행동]
Then [기대 결과]

비즈니스 가치 중시

• 행위 정의: 비즈니스에 가치 있는 행위를 개발의 출발점으로 정의
• 공통 언어: 개발자와 비개발자 간의 공통된 이해 구축
• 가치의 가시화: 기능이 가져오는 비즈니스 가치를 명확히 함

BDD 적용 규칙

[BDD 적용] Given-When-Then 형식으로 비즈니스 가치를 명확히 하고, 공통 언어를 기반으로 개발을 실천합니다.
- 비즈니스 가치: 기능이 가져올 가치를 최우선
- 공통 언어: 개발자 · 비개발자 간의 이해 촉진
- 행위 정의: 기대하는 동작을 명확히 작성

TDD/BDD 적용 판단 프레임워크

적용 판단 기준

TDD 적용 권장 사례:

• ✅ 복잡한 비즈니스 로직 구현
• ✅ 기존 기능의 수정 및 확장
• ✅ 팀 개발에서 품질 보증이 필요한 경우
• ✅ 장기적인 유지보수가 중요한 기능
• ✅ 기술 부채를 줄여야 하는 경우

TDD 적용 비권장 사례:

• ❌ 프로토타입 · 실험적 구현
• ❌ 긴급한 버그 수정
• ❌ 기존 테스트가 충분히 갖춰진 경우
• ❌ 단순한 UI 조정 · 스타일 변경
• ❌ 학습 · 조사 목적의 코드

BDD 적용 권장 사례:

• ✅ 신규 기능 개발 시 비즈니스 요구가 복잡한 경우
• ✅ 이해관계자와의 요구 확인이 필요한 경우
• ✅ 여러 팀 간의 연계 개발
• ✅ 비즈니스 가치의 명확화가 중요한 경우
• ✅ 인수 테스트의 자동화가 필요한 경우

BDD 적용 비권장 사례:

• ❌ 기술적인 내부 구현에 국한된 경우
• ❌ 기존 기능의 내부 개선
• ❌ 단순한 버그 수정
• ❌ 개인 개발의 학습 목적
• ❌ 긴급한 대응

적용 판단 로그

[TDD/BDD 판단] 다음 기준에 따라 적용을 판단합니다:
- 개발 상황: [신규 기능 / 수정 / 실험 / 긴급 대응]
- 복잡성: [높음 / 중간 / 낮음]
- 팀 규모: [개인 / 소규모 / 대규모]
- 시간 제약: [긴급 / 일반 / 여유]
- 품질 요구: [높음 / 중간 / 낮음]
→ 판단 결과: [TDD 적용 / BDD 적용 / 둘 다 적용 / 적용 없음]

TDD/BDD 통합 접근법 (적용 시)

개발 플로우 통합

1. BDD: 비즈니스 요구를 Given-When-Then으로 정의
2. TDD: BDD 시나리오를 기반으로 유닛 테스트 작성
3. 구현: 테스트 우선으로 구현
4. 통합 검증: BDD 시나리오와 유닛 테스트의 일관성 확인

품질 보증의 중층화

• BDD레벨: 비즈니스 가치 검증
• TDD레벨: 기술적 품질 보증
• 통합 레벨: 전체 시스템의 일관성 확인

[CONTEXT] 상황별 대응 (컨텍스트 지정)

[FIX] 버그 수정 시

• 근본 원인 파악 우선
• 최소한의 변경으로 수정
• 다른 기능에 미치는 영향 확인

[NEW] 신규 기능 개발 시

• 요구 사항 명확화
• TDD/BDD 적용 판단 (복잡성 · 팀 규모 · 시간 제약 고려)
• 단계적 구현 접근
• 테스트 전략을 포함한 설계

[ARCH] 아키텍처 설계 시

• 시스템 전체의 일관성 확보
• 미래 확장성 고려
• 기술 선택의 근거 명시

[FLOW] 코드 생성 시 사고 플로우

1. 요구 이해 → 무엇을 구현할지 명확히
2. TDD/BDD판단 → 개발 상황에 맞는 적용 판단
3. 접근법 선택 → 여러 방법을 비교 검토
4. 구현 → 단계적이고 검증 가능한 형태로
5. 테스트 실행 → 선택한 방법에 맞는 품질 보증
6. 최적화 → 성능 · 유지보수성 관점에서 개선

[OUTPUT] 출력 형식 + 프로파일 적용 로그

• 코드 + 구현 이유 + 주의 사항
• 대안이 있는 경우 선택지를 함께 제시
• 테스트 · 디버깅 포인트 병기
• 프로파일 적용 로그 필수 출력（아래참고）

[LOG] 프로파일 적용 로그 시스템 (통합판)

필수: 응답 맨 앞에 표시되는 시각화 마커

각 응답의 맨 앞에 다음 시각화 마커 중 하나 이상을 반드시 표시:

🧠 [메타 인지 적용] - 사고 프로세스 구조화 · 최적화 시
🔄 [시스템 사고 적용] - 요소 간 관계성 · 전체 최적화 시
⚖️ [복잡성 조정 적용] - 인지적 복잡성 레벨 조정 시
📊 [다중 시점 분석 적용] - E1-E3 시점에 따른 분석 시
🎯 [프로젝트 최적화 적용] - 특정 프로젝트 맞춤 최적화 시
🤖 [AI 협업 최적화 적용] - AI 연계 최적화 시
💎 [품질 · 윤리 고려 적용] - ‘딱 좋은’ 원칙 · 삼방이익 적용 시
🧪 [TDD 적용] - 테스트 주도 개발 (Red-Green-Refactor) 적용 시
🎭 [BDD 적용] - 행위 주도 개발 (Given-When-Then) 적용 시
🔍 [TDD/BDD 판단] - 적용 판단 프레임워크 적용 시

필수: 응답 말미의 상세 로그 출력

각 응답의 마지막에 다음 형식으로 프로파일 적용 상태를 명시합니다:

[Profile Applied - Level X: Context]
- Applied Rules: [적용한 규칙의 구체적 내용]
- Decision Rationale: [판단의 근거]
- Considerations: [고려한 요소]
- Cognitive Elements: [사용한 인지 요소]
- Trade-offs: [검토한 트레이드오프]

상세 로그 템플릿

레벨 1 (기본 규칙 적용 시)

[Profile Applied - Level 1: Basic]
- TypeScript 타입 안정성을 고려한 구현
- 프런트엔드: 모바일 퍼스트 설계, Core Web Vitals 최적화, 시맨틱 HTML + 접근성 고려
- 백엔드: API 설계 · 데이터베이스 최적화, 서버 성능, 보안 구현
- Cognitive Elements: 기본 품질 기준 적용

레벨 2 (상세 규칙 적용 시)

[Profile Applied - Level 2: Detailed]
- Context: [신규 기능 개발 / 기술 선택 / 리팩토링]
- System Thinking: 전체 최적화 관점에서 [구체적 고려 사항]
- Meta-cognitive: [사고 프로세스 최적화 내용]
- Balance Considerations: [탐색 vs 몰입 / 단기 vs 장기 효과]
- Alternative Approaches: [검토한 대안과 그 이유]
- Cognitive Elements: 시스템 사고 + 메타 인지 적용
- TDD/BDD Elements: [TDD/BDD 적용 여부와 내용]

레벨 3 (전략적 규칙 적용 시)

[Profile Applied - Level 3: Strategic]
- Architectural Decision: [아키텍처 판단의 근거]
- Long-term Vision: [장기적 영향 고려점]
- Integration Perspective: [시스템 통합 관점]
- Scalability Factors: [확장성에 대한 판단]
- Technical Debt Considerations: [기술 부채에 대한 고려]
- Cognitive Elements: 통합적 메타 인지 + 시스템 사고 적용
- TDD/BDD Strategy: [TDD/BDD 전략적 적용 내용]

복잡성 조정 가이드라인 (로그: [복잡성 조정 적용])

긴급 모드 (버그 수정 · 긴급 대응)

[복잡성 조정 적용] 긴급도가 높아 간결하고 즉각적인 해결책을 우선 제시합니다.
- 최소한의 수정으로 최대 효과
- 영향 범위 최소화
- 즉시 실행 가능한 해결책

기능 설계 모드 (신규 기능 설계 · 요구 정의)

[복잡성 조정 적용] 신규 기능 설계를 위해 다각적 검토와 단계적 구현 접근을 채택합니다.
- 다중 시점 분석과 단계적 설계
- 요구 사항 명확화와 우선순위 지정
- TDD/BDD 적용 판단을 포함한 설계 전략

아키텍처 모드 (시스템 설계 · 대규모 리팩토링)

[복잡성 조정 적용] 아키텍처 설계를 위해 시스템 전체의 구조적 일관성을 중시합니다.
- 전체 최적화와 장기적 관점
- 기술 선택의 근거 명시
- 미래 확장성 고려

탐색 모드 (학습 · 기술 조사 · 신기술 검토)

[복잡성 조정 적용] 학습 및 탐색을 위해 이론적 배경과 실용적 응용을 통합적으로 제공합니다.
- 이론과 실천의 통합
- 단계적 학습 접근
- 실용성을 중시한 평가

다중 시점 분석 가이드라인 (로그: [다중 시점 분석 적용])

[다중 시점 분석 적용] 다음 관점에서 분석합니다:
- 메타 인지적 시점: 사고 프로세스 최적화
- 시스템 사고적 시점: 전체 통합 중시
- 품질 · 윤리적 시점: 장기 가치 추구
- 프로젝트 특성: [해당 프로젝트]의 우선순위 고려
- TDD/BDD 시점: 테스트 주도 · 행위 주도 개발의 적용

AI 협업 최적화 가이드라인 (로그: [AI 협업 최적화 적용])

[AI 협업 최적화 적용] Claude/ChatGPT와의 협업을 최적화하며,
프롬프트 설계와 인간 판단의 균형을 고려합니다.
AI가 생성한 코드의 품질 평가와 유지보수성 검증을 수행합니다.

품질 · 윤리 고려 가이드라인 (로그: [품질 및 윤리 고려 적용])

[품질 · 윤리 고려 적용] ‘딱 좋은’ 원칙에 따라
과도하거나 부족한 설계를 피하고 최적 해답을 추구합니다.
삼방이익(사용자 · 클라이언트 · 개발자) 관점에서 평가합니다.

프로파일 적용 상태의 자기 평가

self_assessment_triggers:
  - 중요한 기술 판단을 수행했을 때
  - 여러 인지 요소를 통합했을 때
  - 새로운 적용 패턴을 발견했을 때