init

Prompt file imported from ilhae-ai/cursor-rules-composer (.cursor/commands/cursor-rules-composer/init.md). Copyright stays with the author.

cursor-rules-composer

지시사항(Instruction)

당신은 이 리포지토리의 구조와 아키텍처를 분석해, 적절한 Cursor Rules 파일을 생성하는 AI 어시스턴트이다. 아래 절차에 따라 .cursor/rules 디렉터리와 룰 파일들을 생성한다.

1단계: Cursor Rules의 동작 방식 이해하기

프로젝트 룰의 기본

Cursor에서 프로젝트 전용 규칙을 정의하는 방법은 두 가지가 있다.

1. AGENTS.md파일 (단일 파일 방식)

   • 프로젝트 루트 바로 아래에 위치
   • 규칙이 적거나, 단순한 프로젝트에 적합
   • 프론트매터 불필요, 파일 내용 전체가 항상 적용됨

2. .cursor/rules/디렉터리 (다중 파일 방식)

   • 룰을 카테고리별로 분리해서 관리 가능
   • 프론트매터로 적용 조건을 세밀하게 제어 가능
   • 대규모 프로젝트나 팀 개발에 적합
   • 이 프롬프트에서는 이 방식(디렉터리 방식)을 사용합니다.

프론트매터(Frontmatter)의 상세

각 룰 파일(.mdc)의 맨 위에는, YAML 프론트매터로 적용 조건을 지정한다.

패턴1: 전역(Global) 룰 – 항상 적용되는 경우

---
description: 프로젝트 전체 아키텍처 개요
alwaysApply: true
---

패턴2: 특정 파일 컨텍스트에서만 적용되는 룰

---
description: domain 계층 구현에 적용되는 룰
globs: app/domain/**/*.ts
alwaysApply: false
---

description필드

• 이 룰의 목적과 적용 범위를 간단히 설명한다.
• AI가 “언제 이 룰을 참고해야 하는지” 판단하는 힌트가 된다.
• 예: "domain 계층 구현에 적용하는 룰", "TypeScript 전반 코딩 규칙" 등

globs필드 (파일 패턴 매칭)

minimatch형식으로 파일 패턴을 지정한다.

⚠️ alwaysApply: false일 때만 지정합니다. alwaysApply: true인 경우 globs는 쓰지 않는다.

⚠️ 중요 문법 규칙

• 따옴표로 감싸지 않는다: 큰따옴표(")나 작은따옴표(')로 묶지 마시오.
• 여러 패턴은 콤마(,)로 연결: 배열형식(-을 사용한 목록)이 아닌 쉼표(,)로 구분한다.
• 콤마 앞뒤에 공백 넣지 않기: 콤마(쉼표) 앞뒤에 공백을 넣지 마시오.

기본패턴

# ✅ 올바른 예시: 특정 디렉터리 아래 모든 Go 파일
globs: app/domain/**/*.ts

# ✅ 올바른 예시: 특정 디렉터리의 모든 TypeScript/TSX 파일
globs: src/components/**/*.{ts,tsx}

# ✅ 올바른 예시: 여러 디렉터리 패턴 (콤마로 연결, 공백 없음)
globs: lib/view/**/*.dart,lib/viewmodel/**/*.dart,lib/mixin/**/*.dart

# ✅ 올바른 예시: 여러 테스트 파일 패턴
globs: **/*_test.tsx,**/*_test.ts

# ❌ 잘못된 예시: 큰따옴표로 감쌈
globs: "app/domain/**/*.go"

# ❌ 잘못된 예시: 리스트(배열) 형식 사용
globs:
  - app/domain/**/*.go
  - app/model/**/*.go

# ❌ 잘못된 예시: 콤마 뒤에 공백 있음
globs: app/domain/**/*.ts, app/model/**/*.ts

패턴 문법 요약

• **: 디렉터리 깊이에 상관없이 매칭(app/**/domainはapp/domain, app/foo/domain, app/foo/bar/domain등)
• *: /를 제외한 임의 문자열
• ?: 임의의 1문자
• {a,b}: a 또는 b (예: *.{js,ts}는.js 또는 .ts)
• [0-9]: 숫자 범위
• [!a-z]: a-z 이외
• ,: 여러 패턴 구분 (공백 없이)

복수 패턴 예시

# Go domain, model 계층
globs: app/domain/**/*.go,app/model/**/*.go

# TypeScript 컴포넌트/훅
globs: src/components/**/*.{ts,tsx},src/hooks/**/*.{ts,tsx}

# 여러 테스트 파일 패턴
globs: **/*_test.go,**/*.test.ts,**/*.spec.ts

# Dart 프레젠테이션 계층
globs: lib/view/**/*.dart,lib/viewmodel/**/*.dart,lib/mixin/**/*.dart

alwaysApply필드

룰을 언제 적용할지 제어합니다.

• alwaysApply: true (전역 룰)

  • 어떤 파일을 편집하든 항상 적용
  • 프로젝트 전반의 방향·아키텍처·언어 공통 규칙에 사용
  • 예: architecture.mdc, go-guidelines.mdc, general-rule.mdc
  • ⚠️ 성능 때문에 너무 많이 만들지 말 것 (3~5개 정도가 적당)
  • 이 경우 globs는 사용하지 않는다.

• alwaysApply: false (컨텍스트 의존, 기본값)

  • globs패턴과 일치하는 파일을 편집할 때만 적용
  • 레이어/모듈별, 특정 영역별 룰에 사용
  • 예: domain-rule.mdc(대상:app/domain/**/*.go)
  • 📌 대부분의 규칙은 여기를 사용

룰이 적용되는 방식

1. 파일 편집 시작: 현재 편집 중인 파일의 경로를 확인
2. 패턴 매칭: 각 룰 파일의 globs와 비교
3. 룰 선택:
   • alwaysApply: true룰은 항상 포함
   • 편집 파일이 globs와 일치하는 룰을 추가로 포함
4. 최종 컨텍스트: 일치하는 모든 룰이 AI의 컨텍스트에 로딩됨

예시: app/domain/user/user_entity.go를 수정하는 경우

• ✅ base/architecture.mdc (alwaysApply: true)
• ✅ base/go-guidelines.mdc (alwaysApply: true)
• ✅ app/domain-rule.mdc (globs: app/domain/**/*.go)
• ❌ app/usecase-rule.mdc (globs: app/usecase/**/*.go – 매칭되지 않음)

룰 분류 – 추천 디렉터리 구조

.cursor/rules/
├── base/          # 프로젝트 공통 기본 룰 (보통 alwaysApply: true)
├── app/           # 레이어/모듈/기능별 룰 (대부분 alwaysApply: false)
└── testing/       # 테스트 관련 룰 (alwaysApply: false)

1. base/ - 프로젝트 전체에 적용되는 기본 룰

항상 적용되는 공통 룰들:

• architecture.mdc (alwaysApply: true)

  • 전체 아키텍처 개요, 설계 철학, 의존 방향 등
  • 모든 구현 판단의 기준이 되는 핵심 문서

• {언어명}-guidelines.mdc (alwaysApply: true)

  • 언어별 코딩 컨벤션
  • 예: go-guidelines.mdc, typescript-guidelines.mdc, python-guidelines.mdc
  • 네이밍, 포맷팅, 에러 처리, 모범사례 등

• general-rule.mdc (alwaysApply: true)

  • 프로젝트 공통 규칙: 작업 진행 방식, 품질 기준, 출력 포맷(문서, PR 템플릿 등), 커밋 규칙 등

• 기타 필요에 따른 룰 (alwaysApply: true/false)

  • api-rule.mdc: API 설계 가이드
  • security-rule.mdc: 보안 규칙

2. app/ - 애플리케이션 레이어/모듈별 룰

아키텍처 레이어에 따른 상세 룰 (보통 alwaysApply: false):

클린 아키텍처 예시:

• domain-rule.mdc (globs: app/domain/**/*.{go,ts})
• usecase-rule.mdc (globs: app/usecase/**/*.{go,ts})
• infrastructure-rule.mdc (globs: app/infrastructure/**/*.{go,ts})
• presentation-rule.mdc (globs: app/presentation/**/*.{go,ts})

MVC/MVVM 예시:

• model-rule.mdc (globs: src/models/**/*.ts)
• view-rule.mdc (globs: src/views/**/*.{vue,tsx})
• controller-rule.mdc (globs: src/controllers/**/*.ts)

기능(도메인) 모듈 기준 예시:

• auth-rule.mdc (globs: src/modules/auth/**/*)
• payment-rule.mdc (globs: src/modules/payment/**/*)

3. testing/ - 테스트 관련 룰

테스트 코드를 위한 룰(alwaysApply: false)：

• test-rule.mdc

  description: 테스트 코드 전반에 대한 규칙
  globs: **/*_test.go,**/*.test.ts,**/*.spec.ts
  alwaysApply: false

  • 테스트 파일 네이밍 규칙
  • 테스트 구조 (테이블 기반 테스트 등)
  • 모킹/스텁 전략
  • 커버리지 목표
  • 레이어별 테스트 전략 등

모범사례

✅ 이렇게 하는 걸 추천

1. 디렉터리 기반 룰 관리 사용

   • .cursor/rules/아래에 분리 관리
   • 카테고리별로 나누면 가독성과 유지보수성이 좋아짐

2. alwaysApply: true는 정말 필요한 것만

   • 너무 많으면 성능에 영향
   • 공통 룰 3–5개 수준이 적당

3. globs는 구체적으로

   • **/*처럼 너무 넓은 패턴은 지양
   • 예: app/domain/**/*.go처럼 의도가 명확하게

4. 파일 이름은 역할이 드러나게

   • domain-rule.mdc, user-service-rule.mdc처럼 봐도 감이 오도록
   • 팀원이 내용을 추측할 수 있는 이름으로 만들기

5. 가능하면 실제 구현 예시 링크 포함

   • 표준 Markdown 링크 형식으로 실제 코드에 링크
   • 규칙의 구체적인 적용 예를 보여준다

❌ 이렇게는 피하기

1. 너무 잘게 쪼개진 룰

   • 파일 하나당 룰 하나 이런 식 → 관리지옥
   • 관련 내용은 하나의 룰 파일에 묶기

2. 중복된 규칙

   • 같은 내용이 여러 곳에 있으면 나중에 충돌·불일치 발생

3. 애매한 globs

   • 의도치 않은 파일에까지 매칭될 수 있음
   • 꼭 실제 디렉터리 구조 기준으로 점검할 것

트러블슈팅

룰이 적용되지 않는 것 같을 때

1. globs패턴부터 체크

   # 파일 경로가 패턴과 일치하는지 확인
   # 예: app/domain/user/user.go가 app/domain/**/*.go와 일치하는지

2. 파일 확장자 확인

   • .mdc확장자를 쓰고 있는지
   • YAML 프론트매터 문법 에러 없는지

3. alwaysApply설정 확인

   • 항상 적용하고 싶으면 alwaysApply: true
   • 특정 영역만이면 alwaysApply: false+ 올바른globs

성능이 떨어지는 것 같을 때

1. 전역 룰(alwaysApply: true) 개수 줄이기

   • 꼭 필요한 것만 남기고 나머지는 컨텍스트 룰로 전환

2. 룰 내용도 너무 장문으로 만들지 않기

   • 요점 위주로 정리해서 AI 컨텍스트 부담 줄이기

2단계: 리포지토리 분석

이제 실제 리포지토리를 분석해야 합니다. 최소 다음 정보를 파악하세요.

2-1. 기본 정보 수집

• 프로젝트 이름: 리포지토리명, package.json, go.mod 등
• 사용 언어: 주요 언어 및 버전
• 프레임워크: 사용 중인 메인 프레임워크/라이브러리
• 기술 스택: 데이터베이스 종류, API 방식 (REST / gRPC / GraphQL 등), 기타 핵심 기술

2-2. 디렉터리 구조 파악

list_dir같은 도구를 쓴다고 가정하고, 단계적으로 구조를 조사합니다.

조사 절차:

1. 루트 디렉터리

   • 프로젝트 루트에서 list_dir 실행하여 주요 디렉토리를 찾는다
   • 애플리케이션 코드가 어디에 있는지 확인 (app/, src/, lib/등)

2. 주요 디렉터리 상세

   • 확인한 주요 디렉터리에 대해 다시 list_dir실행
   • 레이어 구조 존재 여부 확인 (domain, usecase, infrastructure, presentation등)
   • 기능/모듈 구조 여부 확인 (features/, modules/, services/등)

3. 중요 서브 디렉터리

   • 아키텍처 패턴 파악에 필요한 깊이(보통 2–3 depth)까지만 확인

특히 볼 것:

• 앱 코드 위치 (app/, src/, lib/등)
• 레이어 구조 디렉터리 유무(domain, usecase, infrastructure, presentation등)
• 모듈/피처 구조 유무(features/, modules/등)
• 테스트 파일의 배치 패턴(**/*_test.go, **/*.test.ts등)
• CLI 및 특수 명령의 유무(cmd/, cli/, scripts/등)

효율적인 조사 요령:

• 모든 디렉토리를 확인할 필요가 없다.
• 아키텍처 패턴을 식별하는 데 필요한 정보에 집중한다.
• 확실하지 않은 경우 주요 디렉토리를 우선적으로 확인한다.

2-3. 아키텍처 패턴 판별

리포지토리의 아키텍처 패턴을 자세히 파악합니다. 이것은 app/ 규칙 작성의 기초가 되는 중요한 단계입니다.

레이어드 아키텍처 계열

클린 아키텍처 / 어니온 아키텍처

• 특징: domain, usecase, infrastructure, presentation처럼 계층 분리
• 의존 방향: 外바깥 → 안쪽(presentation → usecase → domain)
• 예: app/domain/, app/usecase/, app/infrastructure/, app/presentation/

헥사고날(Ports & Adapters)

• 특징: core(도메인)、ports(인터페이스)、adapters(구현)
• 디렉토리 예: src/core/, src/ports/, src/adapters/

전통적인 3계층

• 특징: 프레젠테이션 계층, 비즈니스 로직 계층, 데이터 액세스 계층
• 디렉토리 예: src/controllers/, src/services/, src/repositories/

MVC / MVVM

• 특징: Model, View, Controller(또는 ViewModel)로 분리
• 디렉토리 예: src/models/, src/views/, src/controllers/

기능/모듈 기반 아키텍처

Feature 기반

• 특징: 기술적인 레이어가 아닌 기능(피쳐)별로 디렉토리 분할
• 각 피쳐 내에 고유의 model/view/controller 등을 가짐
• 디렉토리 예: src/features/auth/, src/features/payment/, src/features/user/

모듈러 모노리스

• 특징: 독립 모듈(응용프로그램)이 단일 리포지토리에 공존
• 각 모듈에는 자체 도메인, 유스 케이스 등이 있다.
• 디렉토리 예: app/modules/cms/, app/modules/table/, app/modules/pickup/

마이크로서비스 스타일

• 특징: 각 서비스는 디렉토리에서 분리되어 독립적으로 배포 가능
• 디렉토리 예: services/user-service/, services/order-service/

프레임워크 특화 아키텍처

Rails스타일(Ruby on Rails)

• 디렉토리 예: app/models/, app/controllers/, app/views/, app/helpers/

Django스타일(Python)

• 디렉토리 예: apps/blog/, apps/shop/(각 앱에models.py, views.py등)

Next.js스타일（React）

• 디렉토리 예: app/, pages/, components/, lib/

NestJS스타일（Node.js/TypeScript）

• 디렉토리 예: src/modules/users/, src/modules/auth/(각 모듈에 controller.ts, service.ts등)

기타 패턴

간단한 기능별 분류

• 특징: 명확한 레이어나 모듈은 없고, 기능 카테고리로 분류
• 디렉토리 예: src/api/, src/utils/, src/helpers/, src/services/

플랫 구조

• 특징: 깊은 계층 구조가 없으며 src / 부하에 직접 파일 / 디렉토리
• 디렉토리 예: lib/auth.ts, lib/db.ts, lib/utils.ts

특정 방법의 체크리스트

아래 질문에 답해 아키텍처 패턴을 식별하세요:

1. 레이어 구조가 있는가?

   • domain, usecase, infrastructure, presentation 같은 기술적 레이어가 분리되어 있는가
   • YES → 레이어드 아키텍처 계열

2. 기능/모듈 단위로 분리되어 있는가?

   • features/, modules/, services/같은 디렉토리 구조
   • 각 디렉토리가 독립된 기능을 제공하는가
   • YES → 기능/모듈 기반 아키텍처

3. 프레임워크 규약을 따르는가?

   • Rails, Django, Next.js등 프레임워크 고유의 디렉토리 구조
   • YES → 프레임워크 특화 아키텍처

4. 명확한 구조가 없는가?

   • 단순한 분류 또는 플랫 구조
   • YES → 기타 패턴

주의: 복합 패턴도 존재함(예: 모듈러 모노리스 + 각 모듈 내부는 클린 아키텍처)

2-4. 코딩 규약 확인

기존 코드에서 아래 항목을 확인해야 함:

• 파일, 클래스, 함수, 변수의 네이밍 규칙
• 디렉토리 네이밍 패턴 (snake_case, kebab-case, PascalCase 등)
• 에러 핸들링 방식
• 의존성 주입(DI) 방식
• 테스트 전략 (유닛/통합 테스트 등)

3단계: 샘플 참고

sample/rules/디렉토리에는 참고용 샘플 규칙이 포함됨. 이 샘플은 Go + 클린 아키텍처 예제로 되어 있음.

샘플 참고 시 주의할 점:

• 샘플은 Go 언어 기준이지만, 실제 리포지토리가 다른 언어라면 해당 언어에 맞게 변환해야 함
• 디렉토리 구조가 다르면 globs 설정도 조정해야 함
• 샘플을 그대로 가져오지 말고, 반드시 사용자 프로젝트의 실제 구조와 맞추어 커스터마이징해야 함
  • 특히 패키지명·디렉토리명·도구명 절대 그대로 쓰지 말 것

4단계: 룰 파일 생성

다음 단계에 따라 규칙 파일을 생성합니다:

4-1. 디렉토리 구조 만들기

.cursor/
└── rules/
    ├── base/
    ├── app/
    └── testing/

4-2. base/규칙 만들기

base/architecture.mdc

• alwaysApply: true
• 내용에 포함할 항목:
  • 프로젝트 개요
  • 기술 스택
  • 아키텍처 설명
  • 디렉토리 구조
  • 레이어 구조와 책임
  • 데이터 흐름
  • 의존성 방향
  • 개발 관행
  • AI 개발 가이드라인

base/{언어명}-guidelines.mdc

• alwaysApply: true
• 언어별 코딩 규칙:
  • 포맷 규칙
  • 명명 규칙
  • 오류 처리
  • 언어별 모범 사례
  • 병렬 처리 및 메모리 관리 등

base/general-rule.mdc

• alwaysApply: true
• 전체 프로젝트에 적용되는 일반적인 규칙:
  • 작업 분석 및 계획 방법
  • 작업 실행 절차
  • 품질 관리
  • 결과 보고서 형식
  • 중요한 주의사항

4-3. app/규칙 만들기

중요: app/규칙은 2-3단계에서 확인한 아키텍처 패턴에 따라 생성됩니다. 획일적으로 "레이어"로 취급하는 대신 저장소의 실제 구조에 맞추십시오.

기본 정책

1. 명확한 구조가 있는 경우에만 작성

   • 레이어, 모듈, 피처 등 명확한 분할이 있는 경우
   • 그 구조에 따라 적절한 규칙 파일 만들기

2. 구조가 불분명한 경우는 작성하지 않는다

   • 플랫 구조나 간단한 분류의 경우
   • base/의 규칙으로 충분히 커버할 수 있는 경우는, app/디렉토리 자체를 만들지 않는다

3. 규칙 파일 세분성

   • 소규모 프로젝트 : 거친 규칙으로 충분
   • 대규모 프로젝트: 자세한 규칙 필요

아키텍처 패턴별 규칙 작성 지침

패턴 1: 레이어드 아키텍처(DDD/클린 아키텍처 등)

특징: domain, usecase, infrastructure, presentation등의 레이어로 분리

규칙 파일 예:

.cursor/rules/app/
├── domain-rule.mdc
├── usecase-rule.mdc
├── infrastructure-rule.mdc
└── presentation-rule.mdc

domain-rule.mdc의 예:

---
description: domain계층 구현에 적용되는 규칙
globs: app/domain/**/*.go
alwaysApply: false
---

# Domain계층 구현 규칙

## 역할
- 비즈니스 로직의 중심
- 엔티티 및 값 객체 정의
- 리포지토리 인터페이스 정의
- 도메인 서비스 구현

## 상세 구조 및 명명 규칙
[실제 디렉토리 구조를 기반으로 설명]

## 구현 포인트
- 도메인 중심 설계의 주체를 따르십시오.
- 엔티티는 상태와 행동을 가지고
- 값 객체는 불변
[...]

## 구현 예
- Entity: [user_entity.go](../../../app/domain/entity/user_entity.go)
- Value Object: [user_id.go](../../../app/domain/value_object/user_id.go)
- Repository Interface: [user_repository.go](../../../app/domain/repository/user_repository.go)

각 레이어의 규칙에 포함할 내용:

• 역할: 레이어의 책임과 경계
• 종속성: 허용되는 종속성 방향(예: domain 계층에 대한 종속성만)
• 금지사항: 다른 레이어에 대한 부정한 의존 등
• 명명 규칙: 파일, 클래스, 함수의 명명 패턴
• 구현 규칙: 기본 구조, 오류 처리, 트랜잭션 관리 등
• 안티패턴: 피해야 할 구현
• 구현 예: 기존 코드에 대한 링크 (표준 Markdown 링크 형식)

패턴 2 : 피쳐베이스 / 모듈러 모노리스

특징: 기능 및 모듈별로 디렉토리가 나뉘며 각 디렉토리가 독립적입니다.

규칙 파일 예:

옵션 1: 공통 기능 규칙

.cursor/rules/app/
└── feature-rule.mdc

---
description: 각 기능/모듈 구현 규칙
globs: src/features/**/*
alwaysApply: false
---

# 피쳐 구현 규칙

## 역할
각 기능은 독립적인 비즈니스 기능을 제공

## 피쳐 내의 권장 구조
src/features/{feature-name}/
├── components/  # UI components
├── hooks/       # React hooks
├── services/    # Business logic
├── types/       # Type definitions
└── index.ts     # Public exports

## 모듈 간 종속성 규칙
- 다른 기능에 대한 직접적인 의존은 피한다.
- 공통 기능은 `src/shared/`에 배치
[...]

옵션 2: 주요 기능별 개별 규칙

.cursor/rules/app/
├── auth-feature-rule.mdc
├── payment-feature-rule.mdc
└── user-feature-rule.mdc

각 파일에는 해당 기능별 비즈니스 규칙 및 제약 조건이 포함되어 있습니다.

각 규칙에 포함할 내용:

• 피처의 책임 범위: 무엇을 다루고 무엇을 다루지 않는가?
• 모듈의 구조: 권장 디렉토리/파일 구성
• 다른 모듈과의 경계: 종속성 규칙, 공개 인터페이스
• 공통 기능 사용법: shared/common디렉토리 사용 방법

패턴 3: 기존 MVC/3계층 아키텍처

특징: models, views, controllers/handlersに分離

규칙 파일 예:

.cursor/rules/app/
├── model-rule.mdc
├── controller-rule.mdc
└── view-rule.mdc

각 규칙에 포함할 내용:

• 각층의 책임: 모델은 비즈니스 로직, 컨트롤러는 라우팅 등
• 디자인 정책: Fat Model 또는 Fat Controller(프로젝트 정책에 따라)
• 데이터 흐름: Controller → Model → View 데이터 흐름
• 명명 규칙: UserController, user_model.py등

패턴 4: 프레임워크 특정 아키텍처

Rails, Django, Next.js등의 경우: 프레임워크 약관에 따라 규칙 만들기

예(Next.js):

.cursor/rules/app/
├── app-router-rule.mdc      # app/디렉토리 규칙
├── api-route-rule.mdc       # API routes규칙
└── components-rule.mdc      # components/규칙

패턴 5: 단순/평면 구조

판결 기준: 다음과 같은 경우에는 app/ 디렉토리를 만들지 않는다.

• 명확한 레이어나 모듈 구조 없음
• 소규모 프로젝트에서 base/ 규칙으로 충분
• 디렉토리가 얕고 기능 카테고리도 불명확

대처법:

• base/규칙으로 전체 커버
• 필요한 경우 .cursor/rules/api-rule.mdc와 같은 최소한의 규칙 만 추가

규칙 생성 결정 흐름

1. 명확한 레이어/모듈 구조가 있는가?
   ├─ YES → 각 레이어/모듈별로 규칙 파일 작성
   └─ NO → 다음

2. 기능 카테고리로 분류가 가능한가?(api/, utils/, services/등)
   ├─ YES → 주요 기능 카테고리별로 규칙 파일 만들기
   └─ NO → 다음

3. app/룰이 필요합니까?
   ├─ 명확한 구조가 없고 base/의 규칙으로 충분 → app/ 디렉토리를 작성하지 않는다
   └─ 특정 영역에 고유한 규칙 필요 → 최소한의 규칙 파일 만들기

규칙 파일의 공통 형식

각 규칙 파일에는 다음 요소를 포함합니다(아키텍처에 따라 조정):

필수 항목:

• 프론트마터: description, alwaysApply(alwaysApply: false의 경우는 globs도 기재)
• 역할: 이 영역의 책임
• 실장 규칙: 기본적인 구현 방법, 명명 규칙

권장 항목:

• 세부 구조 및 명명 규칙: 디렉토리 구조 및 파일 명명
• 실장 포인트: 실장 시 주의점, 모범 사례
• 종속성: 다른 영역과의 종속성 규칙
• 안티패턴: 피해야 할 구현
• 테스트 규칙: 테스트를 작성하는 방법(해당되는 경우)
• 구현 예 : 기존 코드에 대한 링크 (표준 Markdown 링크 형식)

구현 예제 링크의 중요성

각 규칙 파일에는 반드시 실제 코드에 대한 링크를 포함해야 합니다. 중요: 링크는 .cursor/rules/하하에서 본 상대 경로로, 반드시 ../../../로 시작합니다.

## 구현 예
- Entity: [user_entity.go](../../../app/domain/entity/user_entity.go)
- Repository Interface: [user_repository.go](../../../app/domain/repository/user_repository.go)
- Repository Implementation: [user_repository.go](../../../app/infrastructure/repository/user_repository.go)

이렇게 하면 AI가 특정 코딩 스타일을 참조할 수 있습니다. 자세한 설명 방법은 5단계를 참조하십시오.

4-4. testing/규칙 만들기

testing/test-rule.mdc

• globs: 테스트 파일 패턴
  • 복수 패턴은 쉼표로 구분하여 지정
  • 예: **/*_test.go,**/*.test.ts,**/*.spec.ts
• alwaysApply: false
• 내용:
  • 테스트 파일 명명 규칙
  • 테스트 함수 명명 규칙
  • 테스트 구조(테이블 구동 테스트 등)
  • 모의 사용법
  • 어설션 방법
  • 테스트 커버리지 목표
  • 레이어별 테스트 전략

5단계: 구현 예제 링크 추가

각 규칙 파일에는 실제 코드에 대한 링크를 포함해야 합니다. 이렇게 하면 AI가 특정 코딩 스타일을 참조할 수 있습니다.

링크 설명의 중요한 규칙

⚠️ 반드시 지켜야 할 기법

1. 표준 Markdown 링크 형식만 사용

   • [표시명] (상대 경로)형식 사용
   • 'mdc:'와 같은 접두사는 절대로 붙이지 않음

2. 상대 경로의 정확한 계산

   • 규칙 파일 위치에서 프로젝트 루트로 돌아가기 상대 경로 사용
   • .cursor/rules/의 디렉토리 구조에 따라../의 수를 조정

상대 경로 계산 방법

.cursor/rules/아래의 규칙 파일에서 프로젝트 루트로 돌아가려면 다음 계층 수의 ../가 필요합니다:

• .cursor/rules/base/xxx.mdc → 프로젝트 루트 : ../../../
• .cursor/rules/app/xxx.mdc → 프로젝트 루트 : ../../../
• .cursor/rules/testing/xxx.mdc → 프로젝트 루트 : ../../../

수식: 규칙 파일의 깊이에 따라 ../ 추가

• .cursor/ = 1계층
• rules/ = 2계층
• base/ 또는 app/ 또는 testing/ = 3계층
• 총 3계층 = ../../../

올바른 링크 설명 예

케이스1: .cursor/rules/app/domain-rule.mdc에서 app/domain/entity/user.go로의 링크

## 구현 예
- Entity: [user.go](../../../app/domain/entity/user.go)
- Value Object: [user_id.go](../../../app/domain/value_object/user_id.go)

케이스2: .cursor/rules/base/architecture.mdc에서 다양한 파일에 링크

## 참고 구현
- Domain계층: [user_entity.go](../../../app/domain/entity/user_entity.go)
- Usecase계층: [user_usecase.go](../../../app/usecase/user/user_usecase.go)
- Infrastructure계층: [user_repository.go](../../../app/infrastructure/repository/user_repository.go)

케이스3: .cursor/rules/testing/test-rule.mdc에서 테스트 파일에 링크

## 테스트 구현 예
- Entity Test: [user_test.go](../../../app/domain/entity/user_test.go)
- Usecase Test: [user_usecase_test.go](../../../app/usecase/user/user_usecase_test.go)

❌ 잘못된 설명 예

# 실수1 : mdc : 접두사를 사용하고 있습니다.
- Entity: [user.go](mdc:app/domain/entity/user.go)

# 실수2: 상대 경로의 계층 수가 부족
- Entity: [user.go](app/domain/entity/user.go)
- Entity: [user.go](../app/domain/entity/user.go)

# 실수3: 절대 경로 사용
- Entity: [user.go](/app/domain/entity/user.go)

# 실수4 : 프로젝트 루트에서 전환 할 수없는 설명
- Entity: [user.go](../../app/domain/entity/user.go)  # ../가 2개밖에 없다

링크 추가 체크리스트

구현 예제 링크를 추가할 때 다음을 확인하십시오:

• 표준 Markdown 링크 형식[표시명] (상대 경로)를 사용합니다.
• 'mdc:'와 같은 접두사를 붙이지 않음
• 규칙 파일의 계층 구조에 따라 정확한 상대 경로 (일반적으로../../../)
• 링크 대상 파일이 실제로 존재함
• 프로젝트 루트에서 올바르게 전환 할 수있는 상대 경로

6단계: 확인 및 피드백

생성한 규칙 파일에 대해 다음을 신고하세요:

1. 생성된 파일 목록
2. 각 파일의 목적과 적용 범위
3. 특기사항:
   • 이 리포지토리 고유의 디자인 패턴
   • 샘플에서 크게 변경된 점
   • 추가로 필요할 수 있는 규칙

중요한 참고 사항

아키텍처에 대한 참고 사항

• 아키텍처에 맞는 유연한 디자인: 샘플은 DDD/양파 아키텍처이지만 리포지토리의 아키텍처가 다르면 해당 구조에 맞게 규칙을 설계하십시오.
• app/ 디렉토리는 필수는 아니다: 명확한 레이어/모듈 구조가 없는 경우, app/를 만들지 않고 base/와 testing/만으로 구성하는 것도 유효합니다
• 규칙의 입도는 상황에 따라: 소규모 프로젝트에서는 대략적인 룰로 충분하며, 대규모 프로젝트에서는 상세한 룰이 필요합니다.
• 실제 구조 우선: 샘플 구조에 무리하게 맞추는 대신 리포지토리의 실제 구조를 존중하십시오.

구현에 대한 참고 사항

• 프로젝트 특정 용어를 적절히 바꾸기: 샘플에 포함된 고유 명사("ToGo", "CMS", "Table" 등)는 리포지토리에 맞게 변경하십시오.
• globs 설정은 정확하게: 파일 패턴이 실제 디렉토리 구조와 일치하는지 확인하십시오.
• 설명은 한국어로: 규칙의 내용은 한국어로 작성해 주십시오(프로젝트의 언어 설정에 따라 조정 가능)
• 구현 예는 실제 파일로 : 링크는 실제로 존재하는 파일을 참조하십시오
• 단계적으로 생성: 우선 base/를 작성하고 확인 후 app/와 testing/를 작성하는 흐름이 권장됩니다.

구현 예 링크에 대한 참고 사항

• 표준 Markdown 링크만 사용: [표시명](상대 패스)의 형식으로, 「mdc:」등의 접두사는 절대로 사용하지 않는다
• 상대 경로는 반드시 ../../../에서 시작: .cursor/rules/하(3계층째)에서 본 프로젝트 루트에 대한 상대 경로는 항상../../../
• 링크 동작 확인: 생성 후 실제로 링크가 작동하는지 확인한다(파일이 존재하고 상대 경로가 올바른지)
• 5단계의 상세를 참조: 구현예 링크의 정확한 기술 방법은 단계 5에 상세하게 설명되어 있으므로 반드시 참조할 것

판단을 잃은 경우

• 심플하게 유지: 불필요한 규칙은 만들지 않는 것이 좋다. 망설이면 최소한의 규칙으로 시작
• 단계적으로 추가: 처음에는 대략적인 규칙으로 운용하고 필요에 따라 상세화
• 샘플은 참고: 샘플은 하나의 예일 뿐입니다. 리포지토리에 가장 적합한 모양을 추구함

시작 신호

준비가 되면 '리포지토리 분석 시작'을 선언하고 2단계부터 순서대로 실행합니다.