카테고리 없음

.clinerules로 나만의 규칙 설정 - Cursor Rules 무료 대체 (9편)

isony 2026. 9. 21. 08:14
반응형

.clinerules로 나만의 규칙 설정 - Cursor Rules 무료 대체 (9편)

정보 기준: 2026년 9월 / 메인 도구: Cline v3.8x / 언어: Python

 

핵심 기능 편(5~8편)까지 마쳤습니다. 이제 실무·고급 편입니다. 진짜 전문가처럼 Cline을 쓰는 방법을 다룹니다.

첫 번째는 .clinerules입니다. 매번 "들여쓰기는 4칸으로", "이 라이브러리 써줘"라고 반복하는 대신, 규칙을 파일로 저장해서 Cline이 항상 내 방식대로 코드를 짜게 만드는 기능입니다. Cursor의 Rules 기능을 무료로 대체합니다.

  • .clinerules가 뭔가
  • 폴더 방식으로 만들기 (2026 표준)
  • 실전 규칙 파일 예시
  • 글로벌 규칙 vs 프로젝트 규칙
  • 규칙 켜고 끄기 & 조건부 적용
  • .clinerules 잘 쓰는 법

 

.clinerules가 뭔가

먼저 개념입니다. .clinerules는 Cline에게 주는 "우리 팀 규칙" 입니다.

규칙 없이:
  매번 "들여쓰기는 2칸으로", "const 써줘",
  "이 라이브러리로" → 매 대화마다 반복!

.clinerules 사용:
  규칙을 파일에 한 번 적어두면
  Cline이 항상 그 규칙대로! → 매번 설명 불필요!

쉽게 말하면, Claude의 CLAUDE.md, Cursor의 Rules와 같은 개념입니다. 코딩 표준을 파일로 관리하는 거죠. Claude Code 시리즈의 CLAUDE.md 편을 보셨다면 익숙할 겁니다.

한 번 규칙을 정의하면, 그 프로젝트의 모든 대화에 자동으로 적용됩니다. 매번 스타일을 설명하는 번거로움이 사라지죠.

 

폴더 방식으로 만들기 (2026 표준)

여기서 중요한 점! 옛날 방식(단일 .clinerules 파일)이 아니라 폴더 방식이 2026년 표준입니다.

프로젝트 루트에 .clinerules/ 폴더를 만들고, 관심사별로 파일을 나눕니다.

프로젝트/.clinerules/
├── 01-architecture.md   (아키텍처)
├── 02-style.md          (코딩 스타일)
├── 03-testing.md        (테스트)
└── 04-security.md       (보안)

두 가지 원칙이 있습니다.

1. 관심사별로 분리! (아키텍처/스타일/테스트를 각 파일로)
2. 파일당 150줄 이내

Cline이 .clinerules/ 폴더의 모든 .md/.txt 파일을 읽어서 하나로 합칩니다. 그래서 파일을 여러 개로 나눠도 다 적용됩니다. 관심사별로 나누면 관리도 쉽고, 나중에 특정 규칙만 켜고 끄기도 편합니다.

 

실전 규칙 파일 예시

규칙 파일은 그냥 마크다운으로 쓰면 됩니다. 어렵지 않아요.

02-style.md 예시입니다.

# Python 코딩 스타일

## 코드 규칙
- 들여쓰기는 4칸 (스페이스)
- 함수/변수는 snake_case
- 타입 힌트를 항상 붙일 것

## 라이브러리
- HTTP 요청은 requests 대신 httpx 사용

이렇게 적어두면 Cline이 코드를 짤 때 항상 이 규칙을 따릅니다. 들여쓰기, 명명 규칙, 선호 라이브러리까지 내 스타일대로요.

중요한 원칙: 규칙은 실제 팀 선호를 기반으로 쓰세요.

✅ "우리는 서버 상태 관리에 React Query를 쓴다"
❌ "상태 관리는 베스트 프랙티스를 써라" (모호함)

구체적일수록 Cline이 정확히 따릅니다.

 

글로벌 규칙 vs 프로젝트 규칙

규칙에는 두 종류가 있습니다. 개인 취향은 글로벌, 프로젝트별은 워크스페이스로 관리합니다.

글로벌 규칙

모든 프로젝트에 공통 적용
• 내 개인 취향 (들여쓰기, 응답 스타일 등)
• VS Code 설정 폴더에 저장

프로젝트(워크스페이스) 규칙

이 프로젝트에만 적용
• 프로젝트 루트의 .clinerules/
• git으로 팀원과 공유!

충돌하면? 프로젝트 규칙이 글로벌보다 우선합니다. 더 구체적인 규칙이 이기는 거죠.

예를 들어, 개인적으로는 4칸 들여쓰기를 선호(글로벌)하지만, 특정 프로젝트가 2칸을 쓴다면(프로젝트) 그 프로젝트에서는 2칸이 적용됩니다.

 

규칙 켜고 끄기 & 조건부 적용

규칙이 많아지면 필요한 것만 켜서 쓰는 게 효율적입니다. Cline은 이걸 위한 기능을 제공합니다.

토글 팝오버

채팅 입력창 아래 버튼으로
규칙을 클릭 한 번에 켜고 끄기
예: React 작업할 때만 react-rules 켜기

조건부 규칙 (paths)

특정 파일에서만 규칙 적용
예: *.py 파일엔 파이썬 규칙만
YAML frontmatter로 지정

왜 필요할까요? 규칙이 많으면 컨텍스트가 무거워집니다(토큰 낭비). 필요한 것만 켜면 빠르고 정확합니다. 예를 들어 백엔드 작업 중엔 프론트엔드 규칙을 꺼두는 식이죠.

 

.clinerules 잘 쓰는 법

마지막으로 실전 팁입니다.

1. 3~5개로 시작

처음엔 핵심 규칙만!
너무 많으면 컨텍스트 과부하

2. 실제 선호 기반

✅ "우리는 httpx를 쓴다"
❌ "베스트 프랙티스를 써라" (모호)

3. git으로 공유

.clinerules/를 커밋하면
팀 전체가 같은 규칙 사용!

이게 강력합니다. 규칙을 git에 올리면 팀원 모두가 같은 코딩 표준으로 AI 코딩을 하게 됩니다. 코드 일관성이 크게 올라가죠.

4. 주기적 업데이트

새 기술 도입/규칙 변경 시
오래된 규칙은 삭제!

 

마무리

이번 편의 핵심입니다.

  1. .clinerules = 코딩 표준을 파일로 — Cursor Rules 무료 대체
  2. 폴더 방식이 표준 — 관심사별 분리, 150줄 이내
  3. 그냥 마크다운으로 — 실제 팀 선호 기반으로
  4. 글로벌 vs 프로젝트 — 프로젝트가 우선
  5. git 공유로 팀 표준화

이제 Cline이 항상 내 방식대로 코드를 짭니다. 매번 스타일을 설명할 필요가 없어지고, 팀이라면 모두가 같은 표준을 따르게 됩니다. 이게 실무에서 AI 코딩을 "제대로" 쓰는 첫걸음입니다.

다음 편에서는 MCP 연결로 도구 확장을 다룹니다. Cline에 외부 도구(DB, GitHub 등)를 연결해서, 코딩을 넘어 실제 시스템과 연동하는 강력한 기능입니다. Cline의 진짜 강점이죠.

.clinerules를 만들어보고 궁금한 점이 있으면 댓글로 남겨주세요.

 

 

반응형