규칙 3계층 관리 가이드
| 계층 | 판단 기준 | 예시 | |------|---------|------| | **Universal (범용)** | 바꾸면 안전에 문제가 생기는가? | 시크릿 금지, force-push 금지, R2 차단, OWASP | | **Company (
guide docs/guide/RULE_TIERS.md
이 문서는 규칙을 "무엇을 어떻게 분류하는가" 를 설명한다. "어디에 적용되는가" 는 workspace-ecosystem.md 참조.
1. 3계층 정의
| 계층 | 판단 기준 | 예시 |
|---|---|---|
| Universal (범용) | 바꾸면 안전에 문제가 생기는가? | 시크릿 금지, force-push 금지, R2 차단, OWASP |
| Company (회사별) | 조직이 통일해야 의미가 있는가? | 브랜치 전략, 커밋 형식, QA 프로세스, 자동화 모드 |
| Personal (개인) | 본인만 영향받는가? | 응답 언어, 신뢰도 레이블, 에이전트 모드 |
판단 플로우
규칙 항목을 보고:
1. "이걸 바꾸면 보안·데이터 안전에 문제가 생기나?"
→ YES → Universal
2. "이건 안전과 무관하지만, 팀/회사가 통일해야 의미 있나?"
→ YES → Company
3. "이건 누가 어떻게 쓰든 본인만 영향받나?"
→ YES → Personal
고정 분류가 아니다
3계층은 사용자가 결정한다:
- "개인 취향이지만 범용으로 밀고 싶다" → Universal로 승격
- "범용이라 했지만 회사마다 다르게 하고 싶다" → Company로 강등
예: [검증됨] 레이블은 기본 Personal이지만, "다른 사람도 이렇게 쓰면 좋겠다"면 Universal로 올리면 된다.
2. 현재 분류표
00-critical
| 섹션 | 분류 | 근거 |
|---|---|---|
| Destructive Commands BANNED | Universal | 데이터 손실 방지 |
| Before Any Destructive Action | Universal | 검증 절차 |
| Protected Branches | Company | 어떤 브랜치를 보호하느냐는 조직별 차이 |
| User Work Protection | Universal | 미커밋 변경 보호 |
| SECURITY | Universal | 시크릿/PII |
00-identity
| 섹션 | 분류 | 근거 |
|---|---|---|
| 규칙 우선순위 | Universal | 안전 위계 |
| Tie-breaker 원칙 | Universal | 충돌 해소 |
| 핵심 원칙 (진정한 도움 등) | Personal | 응답 성격 |
| 언어 규칙 (한국어/영어) | Company | 팀 구성에 따라 결정 |
| 답변 신뢰도 레이블 | Personal | 표기 방식 선호 |
| 선택지 제시 시 추천 필수 | Company | 의사결정 거버넌스 |
| 축약 플로우 명령 처리 | Company | 자동화 수준 |
01-git
| 섹션 | 분류 | 근거 |
|---|---|---|
| 금지 명령 (rebase, force-push) | Universal | 데이터 손실 방지 |
| Conflict 발생 시 abort | Universal | 안전 절차 |
| 환경 점검 (fetch, status) | Universal | 기본 절차 |
| 브랜치명 형식 | Personal | 네이밍 컨벤션 |
| 노후 기준 (3일/behind 50+) | Personal | 프로젝트 속도 |
| 커밋 형식 (conventional commits) | Company | 회사 표준 |
| Co-Authored-By | Company | AI 크레딧 정책 |
| 배포/보호 브랜치 병합 | Company | CD 파이프라인 |
| CI 규칙 (테스트 약화 금지) | Universal | 검증 우회 차단 |
02-code
| 섹션 | 분류 | 근거 |
|---|---|---|
| 하드코딩 시크릿/PII 금지 | Universal | 보안 기본 |
| 아키텍처 원칙 (과잉 엔지니어링 금지) | Personal | 팀 선호도 |
| 환경변수 추가 시 .env.example | Company | 관리 정책 |
| 검증 도구 (tsc/eslint/ruff) | Company | 프로젝트별 |
03-security
| 섹션 | 분류 | 근거 |
|---|---|---|
| 기본 보안 금지 (XSS, SQLi 등) | Universal | OWASP |
| 에이전트 보안 | Universal | 프롬프트 인젝션 방어 |
| 가역성 원칙 (R0/R1/R2) | Universal | 가역성 판정 |
| 확인 문구 재입력 방식 | Company | 승인 메커니즘 |
| STRIDE 체크 | Universal | 위협 모델 |
04-lifecycle
| 섹션 | 분류 | 근거 |
|---|---|---|
| 에이전트 모드 (auto-push 등) | Company | 자동화 수준 |
| Plan Mode 필수 (DB/인증/결제) | Universal | 고위험 사전 검토 |
| Plan Mode 자동 판단 (20줄+) | Company | 임계값 |
| AskUserQuestion 기준 | Company | 상호작용 정책 |
| 에이전트 팀 구성 | Company | 리뷰 프로세스 |
| 세션 파일/HANDOFF | Company | 협업 인프라 |
05-responses
| 섹션 | 분류 | 근거 |
|---|---|---|
| 신뢰도 레이블 | Personal | 표기 선호 |
| 차단 이유 3분류 | Personal | 커뮤니케이션 스타일 |
| 작업 완료 보고 형식 | Company | 보고 표준 |
| 리포 스캔 금지 | Universal | 효율성/보안 |
3. 승격/강등 방법
승격 (Personal → Universal)
- 해당 규칙이
core/파일의 어느 섹션에 있는지 확인 - 별도 작업 불필요 —
~/.claude/CLAUDE.md에 이미 들어있으면 모든 프로젝트에서 읽힘 - 이 문서의 분류표에서 해당 항목을 Universal로 변경
- 다른 사람에게 배포할 때 "이건 Universal이므로 override 하지 마세요" 안내
강등 (Universal → Company)
- 해당 규칙을
core/에서extensions/로 이동 - 필요한 프로파일에만
extensions:배열에 추가 - 글로벌 프로파일(
global.example.yaml)에서는 제외
회사별 override
현재 구조에서 Company 규칙을 회사별로 다르게 적용하는 방법:
- ai-rules 체계 (dev/ 프로젝트): 프로파일의
extensions:에 회사별 extension 추가 - cc-sync 체계 (dev-bs/ 프로젝트): cc-sync 자체 규칙 체계 사용 (ai-rules 관여 안 함)
4. 회사 추가 절차
새 회사(예: SK)의 프로젝트를 추가할 때:
Step 1 — 디렉토리 생성
D:\dev-sk\ ← 회사 프로젝트 폴더
workspace-ecosystem.md의 디렉토리 분류표에 추가.
Step 2 — 규칙 체계 결정
| 선택지 | 언제 |
|---|---|
| ai-rules 사용 | 개인 규칙을 기반으로 회사 규칙을 override |
| cc-sync 사용 | 이미 cc-sync를 쓰고 있는 팀 |
| 자체 체계 | 회사가 자체 CLAUDE.md 관리 |
Step 3 — ai-rules 사용 시
extensions/sk-company-rules.md작성 (회사 공통 규칙)profiles/sk-base.example.yaml생성:project: sk-base extensions: - sk-company-rules # 회사 공통 설정- 개별 프로젝트 프로파일에서 상속 (extends 기능 구현 후):
project: sk-project-a extends: sk-base target_path: "D:/dev-sk/project-a"
참고:
extends기능은 미구현. 현재는 개별 프로파일에extensions: [sk-company-rules]를 직접 추가하여 대응.
5. 이중 체계 운용
자세한 내용은 workspace-ecosystem.md의 "규칙 체계 이중 운용" 섹션 참조.
| 체계 | 적용 대상 | Universal 규칙 |
|---|---|---|
| ai-rules | dev/ 개인 프로젝트 |
~/.claude/CLAUDE.md로 자동 적용 |
| cc-sync | dev-bs/ 회사 프로젝트 |
cc-sync 자체 규칙에 포함 |
Universal 규칙(보안, 파괴적 명령 차단)은 양쪽 모두에서 적용되어야 한다.
ai-rules에서는 ~/.claude/CLAUDE.md로, cc-sync에서는 hook-templates/universal/로 각각 강제.
6. 현재 적용 위치
| 계층 | 적용 위치 | 로딩 시점 |
|---|---|---|
| Universal | ~/.claude/CLAUDE.md (글로벌) |
매 세션 자동 |
| Company (ai-rules) | 프로젝트별 CLAUDE.md |
프로젝트 진입 시 |
| Company (cc-sync) | cc-sync 자체 규칙 | cc-sync apply 후 |
| Personal | ~/.claude/CLAUDE.md (글로벌) |
매 세션 자동 |
현재 Universal과 Personal은 같은 파일(~/.claude/CLAUDE.md)에 섞여 있다.
물리적으로 분리할 필요는 없다 — 이 분류표로 논리적 구분만 하면 충분.