CLAUDE.md는 Anthropic의 AI 코딩 에이전트 Claude Code가 프로젝트 맥락을 이해하도록 프로젝트 루트에 배치하는 마크다운 설정 파일입니다. Andrej Karpathy의 LLM 코딩 비판에서 영감받은 65줄짜리 규칙 파일이 GitHub에서 하루 400스타를 기록하며 화제가 됐고, 2026년 2월 현재 Claude Code뿐 아니라 Cursor, Windsurf, GitHub Copilot, OpenAI Codex, Google Gemini까지 각 도구별 유사한 규칙 파일 시스템을 지원합니다.
저 사실 고백할 게 있어요.
저는 평소에 Claude랑 Cursor로 작업합니다. 코드 짜달라고 시키면 잘 짜주니까 편하죠. 근데 가끔 이런 일이 생겨요.
“이 함수 하나만 고쳐줘” 라고 했는데, 돌아온 결과물이 파일 3개를 건드리고 있어요. 심지어 안 부탁한 에러 핸들링까지 추가해놨고, 변수명도 “더 명확하게” 바꿔놨고, 타입 정의도 리팩토링해놨어요.
…나는 함수 하나만 고쳐달라고 했는데?
이거 경험 있는 분들 꽤 될 거예요. AI한테 코드 시키면 “요청한 것”보다 “AI가 좋다고 생각하는 것”을 더 많이 해오는 문제.
근데 이걸 텍스트 파일 하나로 잡을 수 있다는 이야기가 나왔습니다.
65줄짜리 텍스트가 왜 난리가 났나
2026년 2월, GeekNews에 올라온 한 글이 개발자 커뮤니티를 달궜습니다.
Andrej Karpathy — 테슬라 AI 디렉터 출신이자 OpenAI 공동창립자 — 가 몇 주간 Claude Code를 사용하면서 느낀 LLM 코딩의 고질적 문제점을 정리했어요. 그리고 이 문제점을 해결하기 위한 65줄짜리 마크다운 파일이 GitHub에 올라왔습니다.
결과요?
하루 만에 스타 400개. 총 4,000개를 돌파했어요.
저장소 이름은 forrestchang/andrej-karpathy-skills. 핵심은 CLAUDE.md라는 파일 하나입니다.
개발자들 사이에서 “이 파일 하나만 프로젝트에 넣으면 AI가 훨씬 똑똑해진다”는 반응이 쏟아졌어요.
근데 잠깐. 수조 원 투자해서 수년간 훈련한 모델인데, 고작 65줄 텍스트가 뭘 바꿀 수 있다는 걸까요?
Karpathy가 짚은 LLM 코딩의 4가지 문제
Karpathy가 지적한 건 AI 모델 자체의 한계라기보다, AI가 코드를 짤 때 반복하는 나쁜 습관이었어요.
문제 1: 생각 없이 바로 코딩
AI한테 뭘 시키면 바로 코드를 뱉어요. “잠깐, 이 부분 확인하고 갈게요”라는 과정 없이. 가정을 숨기고, 불확실한 부분도 그냥 넘어가요.
사람이라면 “이 부분 좀 애매한데, 어떻게 할까요?” 하고 물어볼 텐데, AI는 자기가 알아서 결정하고 밀어붙이죠.
문제 2: 과도한 복잡성
50줄이면 될 코드를 200줄로 짜요. “나중에 확장할 수도 있으니까” 하면서 추상화 레이어 3개 쌓고, 안 부탁한 에러 핸들링 추가하고, 제네릭 타입으로 감싸놓고.
…아직 MVP도 안 만들었는데?
문제 3: 옆집까지 리모델링
“부엌 수도꼭지 고쳐주세요” 했는데 와보니까 거실 페인트까지 새로 칠해놨어요. 요청한 부분만 고치는 게 아니라, “보니까 이것도 고쳐야 할 것 같아서” 하면서 파일 여러 개를 건드려요.
코드 리뷰할 때 진짜 화나는 포인트. 내가 바꿔달라고 한 건 3줄인데 diff가 300줄이에요.
문제 4: 목표 없는 작업
“이 기능 만들어줘”라고 하면 그냥 기능을 만들어요. 근데 “이 기능이 제대로 동작하는지 어떻게 확인할까?”라는 질문은 안 해요. 검증 기준 없이 코드만 찍어내니까, 결과물이 진짜 맞는 건지 사람이 일일이 확인해야 해요.
65줄 규칙 파일의 4가지 핵심 원칙
그래서 이 65줄 파일이 뭘 담고 있냐면, 위 4가지 문제에 대한 정반대의 행동 규칙이에요.
원칙 1: Think Before Coding (코드 치기 전에 생각부터)
"가정을 명시적으로 드러내라. 불확실하면 질문하라. 혼란스러우면 멈춰라."
AI한테 “그냥 짜지 말고, 네가 뭘 가정하고 있는지 먼저 말해”라고 시키는 거예요.
이거 하나만 넣어도 “아, 이 부분은 PostgreSQL 기준으로 작성했는데, MySQL이면 다를 수 있어요”처럼 먼저 알려주는 빈도가 늘어요.
원칙 2: Simplicity First (단순하게 먼저)
"요청하지 않은 기능, 추상화, 에러 처리를 추가하지 마라. 50줄로 될 걸 200줄로 짜지 마라."
이게 진짜 체감이 큰 원칙이에요. AI의 “과잉 친절” 문제를 정면으로 잡아요.
“나중에 필요할 수도 있으니까” 하면서 미리 만들어놓는 코드 — YAGNI(You Aren’t Gonna Need It) 원칙 위반이잖아요. 이걸 규칙으로 명시하면 AI가 정말 최소한의 코드만 작성하게 돼요.
원칙 3: Surgical Changes (수술하듯 정밀하게)
"요청된 부분만 수정하라. 인접한 코드를 '개선'하지 마라. 변경된 모든 줄이 사용자 요청에 직접 연결되어야 한다."
이 원칙 넣고 나서 diff가 깔끔해졌어요. 전에는 “함수 하나 수정” 시켰는데 파일 3개가 바뀌던 게, 이제는 진짜 그 함수만 바뀌어요.
코드 리뷰하는 사람 입장에서는 이게 천국이에요.
원칙 4: Goal-Driven Execution (목표 중심 실행)
"작업을 검증 가능한 목표로 변환하라. 각 단계마다 명확한 성공 기준을 세워라."
“기능 추가해줘” 대신 “이 테스트를 통과시켜줘”처럼, AI가 스스로 목표를 구체화하도록 유도해요.
이렇게 하면 “됐나?” 하는 애매함이 줄어들어요. 테스트 통과했으면 된 거고, 안 통과했으면 안 된 거니까.
내가 느낀 점: 규칙 파일, 진짜 효과 있나?
저도 이 파일 넣고 1주일 정도 써봤어요.
평소에 Claude랑 Cursor 쓰면서 .cursorrules도 설정해놓고, CLAUDE.md도 관리하는 편이에요. 그래서 “65줄 규칙이 뭐가 대단하다고?” 하면서 좀 회의적이었거든요.
근데 써보니까, 체감 차이가 있었어요.
특히 “Surgical Changes” 원칙이 제일 효과적이었습니다. 전에는 “이 부분 수정해줘” 하면 AI가 주변 코드까지 “개선”하는 바람에 git diff가 지저분했는데, 이 원칙 넣고 나서 변경 범위가 확실히 줄었어요.
“Simplicity First”도 좋았어요. 타입스크립트로 간단한 유틸 함수 만들어달라고 했는데, 전에는 제네릭 떡칠하면서 복잡하게 만들어오던 게 이제는 딱 필요한 만큼만 만들어와요.
다만, GeekNews 댓글에서도 나왔듯이:
“실제 써보니 효과 있는 것 같기도 하고 아닌 것 같기도 하고…” — Michiel Beijen
LLM은 비결정적(non-deterministic)이라서 “100% 확신”은 어려워요. 같은 프롬프트에 같은 규칙 파일 넣어도 결과가 매번 조금씩 달라지니까.
그래도 방향성은 확실히 잡아줘요. “항상 완벽하게 따르냐?”보다는 “대체로 이 방향으로 가는 빈도가 늘어나냐?”가 맞는 질문이고, 그 답은 “네”였어요.
솔직한 마음: 프롬프트가 모델을 이긴다?
이 현상을 보면서 묘한 감정이 들었어요.
수조 원 투자해서 만든 모델의 행동을, 65줄 텍스트 파일 하나가 바꿀 수 있다는 사실이요.
GeekNews에서 “프롬프트가 모델 자체를 이길 수 있다”는 해석이 나왔는데, 저는 이게 “이길 수 있다”보다는 **”모델한테 맥락을 제대로 줘야 제대로 일한다”**에 가깝다고 봐요.
사람도 그렇잖아요. 신입 개발자한테 “이거 만들어봐” 하면 자기 마음대로 하는데, “이 규칙 지키면서 만들어봐” 하면 결과물이 달라지죠.
AI도 똑같아요. 규칙을 안 주면 AI가 알아서 판단해요. 근데 AI의 “알아서”는 우리가 원하는 “알아서”가 아닌 경우가 많아요.
결국 컨텍스트 엔지니어링이에요. 프롬프트 한 줄 잘 쓰는 게 아니라, AI가 일하는 환경(맥락)을 제대로 설계하는 거.
Claude 말고 다른 도구에도 적용되나? 전부 확인해봤습니다
여기서부터가 핵심이에요.
“CLAUDE.md는 Claude Code용이잖아. 나는 Cursor 쓰는데?” “GPT 쓰는 사람은 어떡해?”
그래서 2026년 2월 현재, 주요 AI 코딩 도구별 규칙 파일 시스템을 전부 조사해봤습니다.
결론부터 말하면: 거의 모든 도구가 비슷한 기능을 지원해요.
한눈에 보는 비교표
| 도구 | 규칙 파일 위치 | 파일 형식 | 특징 |
|---|---|---|---|
| Claude Code | ./CLAUDE.md, .claude/rules/ | 마크다운 | 계층적 로딩 (글로벌→프로젝트→디렉토리) |
| Cursor | .cursor/rules/*.mdc | MDC (마크다운+프론트매터) | 4가지 활성화 타입 (always/auto/agent/manual) |
| Windsurf | .windsurfrules | 마크다운 | 심플한 설정, 12,000자 제한 |
| GitHub Copilot | .github/copilot-instructions.md | 마크다운 | 경로별 세분화, VS Code/JetBrains 지원 |
| OpenAI Codex | AGENTS.md | 마크다운 | 계층적 탐색, 32KB 제한 |
| Google Gemini | GEMINI.md | 마크다운 | @file.md 임포트, /memory 명령어 |
| ChatGPT | 커스텀 인스트럭션 / 프로젝트 | UI 입력 | 1,500자 제한, 프로젝트별 분리 |
재밌는 건, 전부 마크다운 기반이라는 거예요. 특별한 문법이 필요한 게 아니라 그냥 텍스트 파일이에요.
1. Claude Code: CLAUDE.md
Claude Code의 원조격이에요. 프로젝트 루트에 CLAUDE.md를 놓으면 세션 시작 시 자동으로 읽어들입니다.
파일 우선순위:
~/.claude/CLAUDE.md— 개인 글로벌 설정./CLAUDE.md— 프로젝트 레벨./src/CLAUDE.md— 디렉토리 레벨 (모노레포에 유용).claude/rules/— 주제별 분리 가능
장점: 계층 구조가 가장 정교해요. 팀 공통 규칙은 프로젝트 레벨에, 개인 선호는 글로벌에, 특정 디렉토리 규칙은 해당 폴더에.
설정 팁: /init 명령으로 기본 파일 자동 생성 가능. 5KB 이하로 간결하게 유지하는 게 핵심이에요. 매 요청마다 토큰을 소비하니까.
# CLAUDE.md 예시 (핵심만) ## 규칙 - 요청한 부분만 수정하라. 인접 코드 개선 금지. - 50줄로 될 걸 200줄로 짜지 마라. - 불확실하면 먼저 질문하라. - 모든 변경에 검증 가능한 목표를 설정하라. ## 프로젝트 - 스택: Next.js 14 + TypeScript + Prisma - 테스트: vitest, 테스트 파일은 __tests__/ 디렉토리 - 스타일: Tailwind CSS, 인라인 스타일 금지
2. Cursor: .cursor/rules/
Cursor는 2026년에 규칙 시스템이 꽤 발전했어요. 레거시 .cursorrules 파일 대신 .cursor/rules/ 디렉토리 방식을 씁니다.
4가지 활성화 타입:
| 타입 | 설정 | 언제 적용 |
|---|---|---|
| Always Apply | alwaysApply: true | 모든 상호작용 |
| Auto-attached | globs: ["**/*.tsx"] | 매칭 파일 편집 시 |
| Agent-decided | alwaysApply: false + 설명 | AI가 관련성 판단 시 |
| Manual | alwaysApply: false | @rule-name으로 수동 호출 |
이게 좋은 게, 프론트엔드 코드 편집할 때만 적용되는 규칙, 백엔드 코드 편집할 때만 적용되는 규칙을 분리할 수 있어요.
<!-- .cursor/rules/core.mdc --> --- description: 코드 품질 핵심 규칙 alwaysApply: true --- # 핵심 규칙 - 요청한 변경만 수행하라 - 추상화 레이어 불필요하게 추가하지 마라 - 불확실하면 질문하라
<!-- .cursor/rules/frontend.mdc --> --- description: React 컴포넌트 규칙 globs: ["src/components/**/*.tsx"] --- # 프론트엔드 규칙 - 함수형 컴포넌트 사용 - Props는 인터페이스로 정의 - Tailwind CSS 클래스 사용
장점: 파일별로 규칙 적용 범위를 세밀하게 제어할 수 있어요. 대규모 프로젝트에서 진가를 발휘합니다.
3. Windsurf: .windsurfrules
Windsurf는 심플한 편이에요. .windsurfrules 파일 하나를 프로젝트 루트에 놓으면 끝.
<!-- .windsurfrules --> # 코드 작성 규칙 ## 변경 원칙 - 요청된 부분만 수정 - 불필요한 리팩토링 금지 - 코드 50줄 이하로 유지 가능하면 그렇게 ## 스택 - Python 3.12 + FastAPI - 테스트: pytest
특징:
- 프론트매터 없이 순수 마크다운
- 12,000자 제한 (이전 버전은 6,000자)
- 글로벌 규칙(
global_rules.md)과 프로젝트 규칙 분리 가능
장점: 가장 단순해요. 복잡한 설정 없이 텍스트 파일 하나만 놓으면 됨.
단점: Cursor처럼 파일별 자동 적용 같은 세밀한 제어는 안 돼요.
4. GitHub Copilot: .github/copilot-instructions.md
GitHub Copilot도 커스텀 인스트럭션을 지원합니다. VS Code, JetBrains, Eclipse, Xcode 등 거의 모든 IDE에서 동작해요.
3가지 인스트럭션 타입:
| 타입 | 위치 | 범위 |
|---|---|---|
| 저장소 전체 | .github/copilot-instructions.md | 모든 요청 |
| 경로별 | .github/instructions/*.instructions.md | 특정 파일 경로 |
| 에이전트용 | AGENTS.md 또는 CLAUDE.md | AI 에이전트 |
재밌는 건, Copilot이 AGENTS.md뿐 아니라 CLAUDE.md도 읽는다는 거예요. 도구 간 호환성이 생기고 있어요.
<!-- .github/copilot-instructions.md --> # Copilot 규칙 ## 코드 스타일 - TypeScript strict 모드 사용 - 함수는 JSDoc 주석 필수 - 변수명은 camelCase ## 변경 원칙 - 요청한 부분만 수정 - 관련 없는 코드 리팩토링 금지 - 테스트 코드 함께 작성
5. OpenAI Codex: AGENTS.md
OpenAI의 Codex는 AGENTS.md 파일을 사용합니다.
계층적 탐색 순서:
~/.codex/AGENTS.override.md— 글로벌 오버라이드~/.codex/AGENTS.md— 글로벌 기본- 프로젝트 루트부터 현재 디렉토리까지 순회하며
AGENTS.md수집
32KB 제한이 있고, 가까운 디렉토리의 파일이 우선합니다.
<!-- AGENTS.md --> # Codex 에이전트 규칙 ## 코딩 원칙 - 최소 변경 원칙: 요청한 것만 수정 - 가정하지 말고 질문하라 - 코드 복잡도를 불필요하게 높이지 마라 ## 검증 - 변경 후 기존 테스트 통과 확인 - 새 기능은 테스트 코드 함께 작성
6. Google Gemini: GEMINI.md
Google의 Gemini CLI도 자체 규칙 파일을 지원해요.
고유한 기능들:
@file.md문법으로 다른 파일 임포트 가능/memory명령으로 로딩된 컨텍스트 확인.geminiignore로 특정 파일 제외
<!-- GEMINI.md --> # 프로젝트 컨텍스트 ## 스타일 - Python PEP 8 준수 - docstring Google 스타일 - 타입 힌트 필수 ## 규칙 @rules/coding-standards.md @rules/testing-policy.md
@file.md 임포트 문법이 독특해요. 규칙이 길어지면 파일을 분리하고 임포트하는 방식이 깔끔합니다.
7. ChatGPT: 커스텀 인스트럭션 + 프로젝트
ChatGPT는 파일 기반이 아니라 UI 기반이에요.
두 가지 방법:
1) 커스텀 인스트럭션 (전역)
- 설정 → 커스텀 인스트럭션
- 모든 채팅에 자동 적용
- 1,500자 제한
2) 프로젝트 (프로젝트별)
- 프로젝트 생성 → 인스트럭션 설정
- 해당 프로젝트 내 채팅에만 적용
- 파일 업로드로 추가 컨텍스트 제공 가능
- 프로젝트 인스트럭션이 커스텀 인스트럭션보다 우선
# ChatGPT 커스텀 인스트럭션 예시 (1,500자 이내) ## 코딩 규칙 - 요청한 부분만 수정해주세요 - 불필요한 추상화, 에러 핸들링 추가 금지 - 불확실하면 먼저 질문해주세요 - 코드는 최대한 단순하게 ## 응답 스타일 - 코드 변경 시 변경 이유 먼저 설명 - 가정한 부분 명시 - diff 형태로 변경 범위 보여주기
도구별 비교: 뭐가 제일 좋아?
각 도구의 규칙 파일 시스템을 써본 느낌을 정리해볼게요.
| 평가 항목 | Claude Code | Cursor | Windsurf | Copilot | Codex | Gemini | ChatGPT |
|---|---|---|---|---|---|---|---|
| 설정 난이도 | 쉬움 | 보통 | 매우 쉬움 | 쉬움 | 쉬움 | 보통 | 매우 쉬움 |
| 세밀한 제어 | 높음 | 매우 높음 | 낮음 | 높음 | 높음 | 높음 | 낮음 |
| 팀 공유 | Git으로 공유 | Git으로 공유 | Git으로 공유 | Git으로 공유 | Git으로 공유 | Git으로 공유 | 불가 |
| 계층 구조 | 3단계 | 4타입 | 2단계 | 3타입 | 계층적 | 계층적 | 2단계 |
| 글자 제한 | 5KB 권장 | 없음 | 12,000자 | 1,000줄 | 32KB | 없음 | 1,500자 |
제 추천:
- 혼자 쓴다면 → Windsurf나 Claude Code. 설정이 단순해서 바로 시작 가능.
- 팀 프로젝트라면 → Cursor. 파일별 자동 적용이 대규모 코드베이스에서 진가를 발휘.
- GPT를 주로 쓴다면 → ChatGPT 프로젝트 기능으로 프로젝트별 규칙 분리.
- 여러 도구 혼용한다면 →
AGENTS.md형식 추천. Copilot, Codex, Claude Code 모두 읽어요.
범용 규칙 파일 템플릿: 어디든 복붙 가능
제가 실제로 쓰고 있는 규칙을 도구 독립적으로 정리했어요. 어떤 도구든 복사해서 붙여넣으면 됩니다.
# AI 코딩 규칙 ## 1. Think Before Coding - 코드 작성 전 가정과 트레이드오프를 명시하라 - 불확실하면 먼저 질문하라 - 여러 접근 방식이 있으면 장단점 비교 후 제안하라 ## 2. Simplicity First - 요청하지 않은 기능, 추상화, 에러 핸들링을 추가하지 마라 - 50줄로 가능하면 200줄로 짜지 마라 - YAGNI: 지금 필요한 것만 만들어라 ## 3. Surgical Changes - 요청된 부분만 수정하라 - 인접한 코드를 "개선"하지 마라 - 변경된 모든 줄이 사용자 요청에 직접 연결되어야 한다 - 리팩토링이 필요하면 별도로 제안하라 ## 4. Goal-Driven Execution - 작업을 검증 가능한 목표로 변환하라 - "기능 추가" 대신 "이 테스트를 통과시키기" 형태로 - 각 단계마다 성공 기준을 명시하라 ## 프로젝트 정보 - 스택: [여기에 기술 스택] - 테스트: [테스트 프레임워크] - 스타일: [코딩 스타일 가이드] - 디렉토리 구조: [주요 디렉토리 설명]
이 템플릿을 가져다가:
- Claude Code →
CLAUDE.md로 저장 - Cursor →
.cursor/rules/core.mdc로 저장 (프론트매터 추가) - Windsurf →
.windsurfrules로 저장 - Copilot →
.github/copilot-instructions.md로 저장 - Codex →
AGENTS.md로 저장 - Gemini →
GEMINI.md로 저장 - ChatGPT → 프로젝트 인스트럭션에 복붙
어디든 붙여넣으면 같은 효과를 볼 수 있어요.
규칙 파일 작성 팁: 제가 삽질하면서 배운 것들
1. 짧게 시작하고 점진적으로 추가
처음부터 200줄짜리 규칙 파일 만들지 마세요. AI가 실수한 부분부터 하나씩 규칙을 추가하는 게 효과적이에요.
Day 1: "요청한 부분만 수정하라" (AI가 옆 코드까지 건드려서) Day 3: "TypeScript strict 모드 유지" (AI가 any 타입 남발해서) Day 7: "테스트 파일은 __tests__/ 디렉토리에" (AI가 아무 데나 만들어서)
이렇게 실제 문제 기반으로 쌓아가면 규칙 하나하나가 의미 있어요.
2. “하지 마라”만 쓰지 말고 “대신 이렇게”를 함께
❌ BAD: "복잡한 코드 금지" ✅ GOOD: "복잡한 코드 금지. 대신 함수를 분리하고 각 함수는 10줄 이하로."
AI한테 “뭘 하지 마라”만 말하면 대안을 모르니까 다른 방식으로 같은 실수를 해요. “대신 이렇게”를 함께 알려줘야 합니다.
3. 토큰 비용을 생각하라
규칙 파일은 매 요청마다 컨텍스트에 포함돼요. 규칙이 길면 매번 토큰이 더 소비됩니다.
Claude Code 기준 5KB 이하가 권장이에요. Windsurf는 12,000자 제한이 있고, ChatGPT는 1,500자밖에 안 돼요.
핵심만 남기세요. “이 프로젝트에서 AI가 반복적으로 하는 실수”만 규칙으로 넣으면 됩니다.
4. Git에 커밋하라
규칙 파일은 프로젝트 코드와 함께 Git으로 관리하세요. 팀원 누구나 같은 AI 품질을 경험할 수 있어요.
.gitignore에 넣지 마세요. 이건 공유해야 하는 파일이에요.
앞으로 내가 할 것들
이 글을 쓰면서 제 규칙 파일도 다시 점검해봤어요. 그리고 몇 가지 액션 플랜을 세웠습니다.
1. 범용 규칙 파일을 하나 만들어 여러 도구에 동기화
지금은 CLAUDE.md와 .cursorrules를 따로 관리하고 있는데, 핵심 규칙을 하나의 마스터 파일로 만들고 각 도구 형식으로 변환하는 스크립트를 짜볼 생각이에요.
2. 팀 규칙으로 확장
개인 규칙 파일을 팀 단위로 확장해볼 거예요. PR 단위마다 “요청한 변경만” 원칙을 두고, AI가 생성한 코드의 리뷰 기준을 규칙 파일에 명시하면 코드 리뷰 비용이 줄어들 거라고 예상해요.
3. 주기적 규칙 점검
규칙 파일도 코드처럼 유지보수가 필요해요. 한 달에 한 번은 “이 규칙 아직 유효한가?” 점검하고, 안 쓰는 규칙은 정리하려고 합니다.
FAQ (자주 묻는 질문)
Q: 규칙 파일 없이도 AI 코딩 잘 되지 않나요?
A: 간단한 작업은 그래요. 근데 프로젝트가 커지면 AI가 프로젝트 컨벤션을 모르니까 매번 “이건 이렇게 해줘”를 반복하게 돼요. 규칙 파일은 그 반복을 없애줍니다. McKinsey 연구에 따르면 AI 코딩 도구를 제대로 설정한 경우 생산성이 평균 55% 향상됐어요.
Q: 65줄이 최적인가요? 더 길면 안 되나요?
A: 65줄은 “이 정도면 충분하다”는 기준이지 최적값은 아니에요. 핵심은 간결함이에요. 규칙 파일이 길어지면 AI가 우선순위를 혼동하고, 토큰 비용도 늘어나요. Claude Code 기준 5KB 이하가 권장이에요.
Q: 여러 AI 도구를 동시에 쓰는데, 규칙 파일을 각각 만들어야 하나요?
A: 핵심 규칙은 하나의 마스터 파일로 관리하고, 각 도구 형식으로 복사하는 게 가장 효율적이에요. 위에서 제공한 범용 템플릿을 복사해서 각 도구의 규칙 파일 위치에 놓으면 됩니다. AGENTS.md 형식은 Copilot, Codex, Claude Code가 모두 읽으니 호환성이 가장 좋아요.
Q: ChatGPT에서 코딩할 때도 규칙이 적용되나요?
A: 네. ChatGPT의 “프로젝트” 기능을 사용하면 프로젝트별 인스트럭션을 설정할 수 있어요. 1,500자 제한이 있지만, 핵심 규칙(Think Before Coding, Simplicity First, Surgical Changes, Goal-Driven Execution) 4가지는 충분히 담을 수 있습니다.
Q: 규칙 파일이 정말 효과가 있다는 증거가 있나요?
A: 100% 실증은 어려워요. LLM은 비결정적이라 같은 입력에도 다른 출력을 내니까요. 다만 GitHub에서 하루 400스타를 받았고, 수많은 개발자가 “체감 차이가 있다”고 보고하고 있어요. 원문 블로그 작성자(Michiel Beijen)도 “효과가 있는 것 같기도 하고 아닌 것 같기도 하지만, 방향성은 맞다”고 인정했습니다.
결론: 65줄은 시작일 뿐
돌고 돌아 또 프롬프트 엔지니어링이냐고요?
맞아요. 근데 이번엔 좀 달라요.
예전 프롬프트 엔지니어링은 “이 질문을 어떻게 물어볼까”였다면, 지금의 컨텍스트 엔지니어링은 **”AI가 일하는 환경을 어떻게 설계할까”**예요.
CLAUDE.md든, .cursorrules든, AGENTS.md든 — 이름은 달라도 하는 일은 같아요. AI한테 “너는 이 규칙 안에서 일해”라는 울타리를 쳐주는 거.
그리고 그 울타리가 65줄이면 충분하다는 게, 이 이야기의 핵심이에요.
저도 처음엔 “65줄이 뭘 바꾸겠어” 했는데, 써보니까 다르더라고요.
여러분도 지금 쓰는 AI 코딩 도구에 맞는 규칙 파일 하나 만들어보세요. 위 템플릿 복사해서 붙여넣기만 하면 됩니다.
5분 투자로 AI 코딩 품질이 달라지는 경험, 직접 해보시면 알아요.
참고 자료
- 65줄 텍스트가 AI 코딩을 바꿨다? — GeekNews
- forrestchang/andrej-karpathy-skills — GitHub
- Using CLAUDE.MD files — Anthropic 공식 블로그
- Cursor AI Rules Guide 2026 — PromptXL
- GitHub Copilot Custom Instructions — GitHub Docs
- OpenAI Codex AGENTS.md — OpenAI Docs
- GEMINI.md Files — Google Gemini CLI Docs
🏷️ 태그: #AI코딩 #CLAUDE_MD #규칙파일 #Cursor #Windsurf #Copilot #Codex #Gemini #ChatGPT #컨텍스트엔지니어링 #프롬프트엔지니어링