Beginner

Claude Code深度配置指南,90%的人其实都不会用

Claude Code 심층 설정 가이드, 90%의 사람들은 제대로 사용하지 않습니다

Claude Code가 얼마나 잘听话하는지는 전적으로 숨겨진 .claude 폴더를 열었는지에 달려 있습니다.
.claude 폴더는 Claude의 제어 센터입니다. Claude가 명령을 어떻게 이해하는지, 어떤 명령을 실행할 수 있는지, 어떤 권한이 있는지, 무엇을 기억하는지 관리합니다. 이를 제대로 이해하면 Claude Code가 원하는 대로 작동하도록 만들 수 있습니다.
최근 Akshay Pachaar가 .claude 폴더의 구조를 상세히 분석한 완벽한 가이드를 공유했습니다. 저는 그의 공유를 바탕으로 이 글을 정리했으며, 기본 사용법부터 고급 설정까지 모두 다룹니다.

.claude 폴더는 무엇을 하는 곳인가요?#

.claude 폴더는 Claude에게 작업 방식을 지시하는 곳입니다.
여기에 규칙을 작성할 수 있습니다. 예를 들어 "코드를 작성하기 전에 테스트를 먼저 작성하라", "특정 명령을 사용하지 마라", "내 코딩 습관을 기억하라" 등이 있습니다. 작성 후에는 Claude가 매번 작업할 때 이를 따릅니다.
여기서 혼동하기 쉬운 점이 있습니다. 실제로 두 개의 .claude 폴더가 있습니다.
하나는 프로젝트에 있고, 다른 하나는 사용자 디렉토리에 있습니다:
프로젝트 수준의 폴더는 팀 구성을 담습니다. 이를 git에 커밋하면 팀 전체가 동일한 규칙, 동일한 사용자 정의 명령, 동일한 권한 정책을 사용합니다.
전역 ~/.claude/ 폴더는 개인 설정과 로컬 상태(예: 세션 기록 및 자동 기억)를 담습니다.

CLAUDE.md: Claude의 사용 설명서#

CLAUDE.md는 "Claude에게 주는 사용 설명서"로 이해할 수 있습니다.
Claude Code를 시작할 때마다 가장 먼저 이 파일을 열고 내용을 모두 기억한 후, 전체 대화 과정에서 이를 따릅니다.
간단히 말해: CLAUDE.md에 어떤 규칙을 쓰든 Claude는 그대로 따릅니다.
예를 들어 "코드를 작성하기 전에 테스트를 먼저 작성하라"고 쓰면, Claude는 먼저 테스트를 작성합니다.
"console.log를 사용하지 말고, 우리의 자체 logger를 사용하라"고 쓰면, Claude는 매번 기억합니다.

이 파일은 세 곳에 배치할 수 있습니다:#

  1. 프로젝트 폴더 (가장 일반적) 프로젝트 루트 디렉토리(예: 웹사이트 프로젝트 폴더)에 배치합니다. 이렇게 하면 팀의 모든 사람이 이 프로젝트를 열 때 Claude가 동일한 규칙을 따릅니다.
  2. 컴퓨터의 사용자 폴더 (~/.claude/CLAUDE.md) 이것은 개인 설정으로, 어떤 프로젝트를 열든 적용됩니다. 예를 들어 "코드에 주석을 많이 달아라"를 좋아한다면, 여기에 작성하면 Claude가 모든 프로젝트에서 이를 기억합니다.
  3. 프로젝트 내의 하위 폴더 예를 들어 프로젝트에 api 폴더가 있다면, 이 폴더에만 별도의 규칙을 설정할 수 있습니다. Claude는 이 세 곳의 파일을 모두 읽어서 합쳐서 사용합니다.

CLAUDE.md에 무엇을 써야 할까요?#

작성 권장 사항:#

  1. 자주 사용하는 명령어 예: 프로젝트 시작 방법, 테스트 실행 방법. npm run test(테스트 실행), npm run dev(프로젝트 시작) 등.
  2. 프로젝트에서 사용하는 기술 예: "프론트엔드는 React를 사용합니다", "데이터베이스는 PostgreSQL을 사용합니다".
  3. 자주 발생하는 실수 예: "이 프로젝트에서는 var를 사용할 수 없고, letconst만 사용해야 합니다", "코드를 커밋하기 전에 반드시 테스트를 실행해야 합니다".
  4. 코드 작성 방식 예: "파일 이름은 모두 소문자를 사용합니다", "오류 발생 시 try-catch를 사용합니다", "import는 파일 맨 위에 작성해야 합니다".
  5. 폴더 구조 예: "모든 컴포넌트는 components 폴더에 배치합니다", "유틸리티 함수는 utils 폴더에 배치합니다".

작성하지 말아야 할 것:#

  1. 코드 포맷 규칙 예: "들여쓰기는 2칸인가 4칸인가", "세미콜론을 붙일 것인가 말 것인가". 이러한 것들은 Prettier나 ESLint 같은 도구로 관리해야 하며, 여기에 작성할 필요가 없습니다.
  2. 이미 상세한 문서가 있는 내용 프로젝트에 이미 완전한 개발 문서가 있다면, CLAUDE.md에는 "자세한 규칙은 docs/guide.md를 참조하세요"라고만 쓰고, 전체 문서를 복사하지 마세요.
  3. 장황한 이론 지식 "React란 무엇인가", "왜 TypeScript를 사용해야 하는가"와 같은 튜토리얼을 작성하지 마세요. Claude는 이미 이러한 것을 알고 있으므로, "우리 프로젝트는 React를 사용합니다"라고만 알려주면 됩니다.
기억하세요: CLAUDE.md는 200줄을 넘지 않는 것이 좋습니다.
파일이 너무 길면 Claude가 내용을 기억하는 데 많은 에너지를 소모하여 작업 효율이 떨어집니다. 간결하고 직접적이며 실용적으로 유지하세요.
다음은 간결하면서도 효과적인 예시입니다:
markdown
# 프로젝트 가이드

## 기술 스택

- Next.js 14 (App Router)
- TypeScript (strict mode)
- Tailwind CSS
- Prisma ORM

## 명령어

- `npm run dev` - 개발 서버 시작
- `npm run test` - 테스트 실행
- `npm run lint` - 코드 검사

## 규칙

- 모든 컴포넌트는 함수형으로 작성하며, class를 사용하지 않음
- API 라우트는 `app/api/`에 배치
- 데이터베이스 작업은 모두 `lib/db.ts`를 통해 처리
- 오류 처리는 `lib/errors.ts`의 유틸리티 함수 사용

## 파일 구조

app/ - Next.js 페이지 및 라우트
components/ - 재사용 가능한 컴포넌트
lib/ - 유틸리티 함수 및 설정
prisma/ - 데이터베이스 스키마
20줄 정도면 충분합니다. Claude가 알아야 할 모든 것을 알게 되었고, 이후 작업할 때 반복해서 물어보지 않을 것입니다.

CLAUDE.local.md#

개인적으로 선호하는 작성 방식이 있지만, 팀 전체가 이를 따를 필요는 없을 때가 있습니다.
예를 들어, 팀은 Jest를 사용하지만 당신은 Vitest를 선호한다거나, Claude가 "코드를 작성할 때 주석을 많이 달아라"라고 기억하게 하고 싶지만 다른 동료는 그럴 필요가 없을 때가 있습니다.
이럴 때 프로젝트 폴더에 CLAUDE.local.md 파일을 만드세요.
Claude는 이를 CLAUDE.md와 함께 읽지만, 이 파일은 git 저장소에 커밋되지 않으므로 개인 선호도는 자신만 알게 되고 다른 사람에게 영향을 주지 않습니다.
markdown
# 내 개인 선호도

- 테스트는 Jest 대신 Vitest 사용
- 컴포넌트 파일에는 항상 PropTypes 포함
- 커밋 메시지는 한국어로 작성

rules/ 폴더: 규칙이 너무 많으면 어떻게 해야 할까요?#

CLAUDE.md 파일은 처음에 20줄로 간결했습니다.
하지만 6개월 후, 팀이 계속해서 새로운 규칙을 추가하여 파일이 300줄이 되었습니다. 너무 길어서 아무도 읽고 싶어하지 않습니다.

해결 방법:#

300줄을 여러 개의 작은 파일로 나누세요. 예를 들어:
  • api-conventions.md (API 작성 규칙)
  • testing.md (테스트 규칙)
  • security.md (보안 규칙)
이 파일들을 모두 .claude/rules/ 폴더에 넣으세요.
Claude는 자동으로 이 작은 파일들의 내용을 모두 읽어들여, 하나의 큰 파일에 작성한 것과 동일한 효과를 내지만 관리하기가 훨씬 쉬워집니다.
예를 들어 규칙을 카테고리별로 분리합니다:
text
.claude/rules/
  ├── api-conventions.md
  ├── testing.md
  ├── security.md
  └── ui-patterns.md
각 파일은 집중도를 유지하고 업데이트하기 쉽습니다. API 규칙을 담당하는 팀원은 api-conventions.md를 편집하고, 테스트 표준을 담당하는 사람은 testing.md를 편집합니다.
더 고급 기능도 있습니다:
특정 규칙 파일이 특정 폴더에서만 적용되도록 할 수 있습니다.
예를 들어, API 규칙을 담은 api-rules.md 파일을 작성했다고 가정해 보겠습니다. 파일 시작 부분에 다음 줄을 추가하세요:
yaml
---
paths:
  - "src/api/**"
---
이렇게 하면 Claude는 src/api/ 폴더의 코드를 수정할 때만 이 규칙 파일을 읽습니다. 다른 곳의 코드를 수정할 때는 읽지 않습니다.
장점은 무엇일까요?
예를 들어, API 코드는 "반드시 JSON 형식을 반환해야 한다"는 규칙이 필요하지만, 프론트엔드 컴포넌트에는 이 규칙이 필요하지 않습니다.
이 규칙을 CLAUDE.md에 작성하면, Claude가 프론트엔드 코드를 수정할 때도 이 규칙을 기억하게 됩니다.
이제 이를 별도의 api-rules.md 파일에 작성하고 src/api/ 폴더에만 적용되도록 지정하면, Claude가 프론트엔드 코드를 수정할 때 이 규칙에 방해받지 않습니다.
yaml
---
paths:
  - "src/api/**"
  - "src/handlers/**"
---

# API 개발 규칙

모든 API 엔드포인트는 반드시:
- 통일된 JSON 형식 반환
- 오류 처리 포함
- 요청 로그 기록

commands/ 폴더: Claude 단축키#

Claude가 한 번의 명령으로 특정 작업을 완료하도록 하는 사용자 정의 단축 명령을 만들 수 있습니다.
예를 들어, 자주 Claude에게 "코드 리뷰를 도와줘"라고 요청할 때마다 긴 문장을 입력해야 합니다. 이제 /review 명령을 만들어서 앞으로는 /review만 입력하면 됩니다.

방법:#

.claude/commands/ 폴더에 markdown 파일을 만드세요.
파일 이름이 명령 이름이 됩니다.
  • review.md 생성/project: review 명령 사용 가능
  • fix-bug.md 생성/project: fix-bug 명령 사용 가능
예를 들어, .claude/commands/review.md 파일을 만들고 내용을 작성합니다:
markdown
# 코드 리뷰

최근 코드 변경 사항 리뷰:

!`git diff main...HEAD`

중점 확인 사항:
- 코드 스타일 일관성
- 잠재적 성능 문제
- 보안 취약점
- 테스트 커버리지
이제 Claude Code에서 /project: review를 입력하면 Claude가 자동으로 이 명령을 실행합니다.
여기서 핵심은 ! 백틱입니다:
!git diff main...HEAD 이 코드 줄의 의미는: 먼저 git diff 명령을 실행하고, 결과를 가져와서 Claude에게 제공하는 것입니다.
따라서 Claude가 보는 것은 "git diff"라는 글자가 아니라 실제 코드 차이 내용입니다.
명령에 매개변수 전달하기
명령을 더 유연하게 만들고 싶다면 다음과 같이 작성할 수 있습니다:
markdown
# 문제 수정

문제 세부 정보를 가져와 수정方案 제공:

!`gh issue view $ARGUMENTS`

이 문제를 분석하고 수정 단계를 제안합니다.
/project: fix-issue 234를 실행하면 issue 234의 내용이 프롬프트에 직접 제공됩니다.
명령 배치 위치
프로젝트 명령 - .claude/commands/ 폴더에 배치
이 명령들은 git에 커밋되어 팀 전체가 사용할 수 있습니다.
개인 명령 - ~/.claude/commands/ 폴더에 배치
이 명령들은 자신만 사용할 수 있으며, /user:명령어이름 형식으로 표시됩니다.

skills/ 폴더: Claude가 스스로 무엇을 해야 할지 판단하게 하기#

이제 명령이 어떻게 작동하는지 알았습니다. Skills와 Commands는 매우 비슷해 보이지만, 트리거 방식이 완전히 다릅니다.

핵심 차이점을 먼저 설명하겠습니다:#

Skills는 Claude가 자동으로 호출할 수 있는 워크플로우입니다. 슬래시 명령을 입력할 필요가 없으며, 작업이 skill의 설명과 일치하기만 하면 Claude가 자동으로 사용합니다.
Commands(명령)는 TV 리모컨과 같습니다. "전원" 버튼을 누르면 TV가 켜집니다. 누르지 않으면 움직이지 않습니다.
Skills(스킬)는 에어컨의 자동 모드와 같습니다. "덥다"고 말하기만 하면 에어컨이 스스로 온도를 낮춰야 한다고 판단하고 자동으로 작동을 시작합니다.

Skills는 어떻게 생성하나요?#

각 skill은 자체 하위 폴더에 있으며, 그 안에 SKILL.md 파일이 있습니다:
text
.claude/skills/
  └── security-review/
      ├── SKILL.md
      └── DETAILED_GUIDE.md
SKILL.md는 YAML frontmatter를 사용하여 언제 사용할지 설명합니다:
markdown
---
name: security-review
description: 코드에 대한 보안 검토를 수행하고 일반적인 취약점을 확인합니다
---

# 보안 검토

\@DETAILED_GUIDE.md의 기준에 따라 코드 검토:

1. SQL 인젝션 위험 확인
2. 입력 검증 확인
3. 민감 데이터 노출 확인
4. 권한 제어 검토
"이 PR의 보안 문제를 검토해줘"라고 말하면, Claude는 skill의 설명을 읽고 작업과 일치하는지 확인한 후 자동으로 이 skill을 호출합니다. 또는 /security-review를 직접 입력하여 수동으로 호출할 수도 있습니다.

Skills와 Commands의 가장 큰 차이점:#

Commands는 하나의 파일이며, 수행할 작업이 작성되어 있습니다.
Skills는 여러 관련 파일을 포함할 수 있습니다.
예를 들어, 위의 예시에서 SKILL.md 파일은 @DETAILED_GUIDE.md를 작성했는데, 이는 "옆에 있는 DETAILED_GUIDE.md 파일을 읽어라"는 의미입니다. 이렇게 하면 skill이 해당 파일의 상세 규칙을 사용할 수 있습니다.

개인 skills는 어디에 두나요?#

~/.claude/skills/ 폴더에 두면, 어떤 프로젝트를 열든 이러한 skills를 사용할 수 있습니다.

agents/ 폴더#

일부 작업은 너무 복잡해서 Claude가 전문가의 도움을 요청하게 하고 싶을 때가 있습니다.
예를 들어:
Claude에게 "이 500줄 코드를全面 검토해줘"라고 요청했다고 가정해 보겠습니다.
Claude가 주 대화에서 이 작업을 수행하면, 각 파일의 검토 과정, 발견된 모든 작은 문제, 각 단계의 분석을 모두 표시합니다. 채팅 기록이 수백 개의 중간 메시지로 도배되어 전혀 읽을 수 없게 됩니다.
이때 agent를 사용합니다.
Agent는 Claude가 "백그라운드"에서 작업을 수행하게 하는 것입니다. 모든 코드를 조용히 검토한 후, 최종 결과(예: "3개의 보안 문제, 5개의 성능 문제 발견")만 알려줍니다. 채팅 기록은 깨끗하게 유지되며 유용한 결론만 볼 수 있습니다.
Agent는 특정 작업을 전담하는 "작은 도우미"입니다. .claude/agents/ 폴더에 markdown 파일을 만들어서 지시합니다:
text
.claude/agents/
  ├── code-reviewer.md
  ├── security-auditor.md
  └── performance-analyzer.md
code-reviewer.md 예시:
markdown
---
name: code-reviewer
description: 코드 품질, 스타일 및 모범 사례 검토
tools: [Read, Grep, Glob]
model: claude-3-5-haiku-20241022
---

당신은 코드 리뷰 전문가입니다. 코드를 검토할 때 다음 사항에 중점을 둡니다:

1. 코드 스타일 일관성
2. 잠재적 버그 및 경계 조건
3. 성능 문제
4. 유지보수성

구체적인 개선 제안을 제공하고, 특정 코드 줄을 인용하세요.
Claude는 백그라운드에서 이 agent를 시작하여 독립적으로 작업을 수행하게 합니다. Agent가 작업을 완료하면 발견 사항을 간결한 보고서로 정리하여 알려줍니다. 주 대화는 수백 개의 중간 과정으로 도배되지 않습니다.
tools 필드는 agent가 사용할 수 있는 도구를 제한합니다. 코드 리뷰 agent는 Read, Grep, Glob만 필요하며, 파일 쓰기 권한은 필요하지 않습니다.
model 필드는 사용할 AI 모델을 결정합니다. 간단한 작업은 Haiku(저렴하고 빠름)를, 복잡한 작업은 Sonnet 또는 Opus(비싸지만 더 똑똑함)를 사용합니다. 이렇게 하면 비용을 절약하고 효율성을 높일 수 있습니다.
개인 agents는 ~/.claude/agents/에 두면 모든 프로젝트에서 사용할 수 있습니다.

settings.json: 권한 및 프로젝트 구성#

.claude/settings.json 파일은 Claude가 허용하고 허용하지 않는 작업을 제어합니다. 여기서 Claude가 실행할 수 있는 도구, 읽을 수 있는 파일, 특정 명령을 실행하기 전에 물어볼 필요가 있는지 여부를 정의합니다.
전체 파일 예시:
json
{
  "$schema": "https://cdn.gooo.ai/schemas/claude-settings.json",
  "allow": [
    "Bash(npm run *)",
    "Bash(make *)",
    "Bash(git *)",
    "Read",
    "Write",
    "Edit",
    "Glob",
    "Grep"
  ],
  "deny": [
    "Bash(rm -rf *)",
    "Bash(curl *)",
    "Read(.env)",
    "Read(secrets/**)"
  ]
}

각 부분의 역할#

$schema 줄 - 구성을 작성할 때 편집기가 입력 가능한 항목을提示하여 오류를 방지합니다. 이 줄을 삭제하지 마세요.#

allow 목록 - Claude가 직접 수행할 수 있는 작업으로, 매번 물어볼 필요가 없습니다:#

  • 프로젝트 명령 실행 (npm run *, make *)
  • git 기록 확인 (git *)
  • 파일 읽기/쓰기 (Read, Write, Edit, Glob, Grep)

deny 列表 - Claude 绝对不能做的事:#

  • 删除文件(rm -rf
  • 访问网络(curl
  • 读密码文件(.envsecrets/
如果某项内容不在这两个列表里的,Claude 会先问你再做。
settings.local.json:个人权限覆盖
CLAUDE.local.md 一样的思路。用来放你个人的权限设置,比如你想在自己电脑上让 Claude 能删文件,但不想让团队其他人也这样。这个文件不会提交到 git,所以只有你自己用得到。

全局 ~/.claude/ 文件夹#

这个文件夹放的是你个人的设置,里面主要有这几样东西:
  • ~/.claude/CLAUDE.md - 你的个人习惯。比如“我喜欢代码多写注释”,写在这里,Claude 会应用在所有项目里。
  • ~/.claude/projects/ - Claude 和你每个项目的聊天记录,还有它自己记的笔记。输入 /memory 就能看。
  • ~/.claude/commands/~/.claude/skills/ - 你自己做的快捷命令和技能,在所有项目里都能用。
平时不用管它。但要是 Claude 莫名其妙“记得”一些你压根没说过的事,或者你想删掉某个项目的记忆,就来这里翻。

完整结构#

把前面讲的所有东西放在一起,就是这样:
text
项目级别 (.claude/)
├── CLAUDE.md              # 团队指令(必须)
├── CLAUDE.local.md        # 你的个人覆盖(gitignored)
├── settings.json          # 团队权限
├── settings.local.json    # 你的权限覆盖(gitignored)
├── rules/                 # 模块化指令
│   ├── api-conventions.md
│   ├── testing.md
│   └── security.md
├── commands/              # 团队自定义命令
│   ├── review.md
│   └── fix-issue.md
├── skills/                # 团队可复用工作流
│   └── security-review/
│       ├── SKILL.md
│       └── DETAILED_GUIDE.md
└── agents/                # 团队专业子 agents
    ├── code-reviewer.md
    └── security-auditor.md

全局级别 (~/.claude/)
├── CLAUDE.md              # 你的全局偏好
├── projects/              # 每个项目的会话和记忆
│   └── your-project/
│       ├── transcripts/
│       └── memory.md
├── commands/              # 你的个人命令
├── skills/                # 你的个人 skills
└── agents/                # 你的个人 agents

新手怎么开始?#

如果你是第一次用,按这个顺序来就行:
第一步:让 Claude 自己生成一个起点
在 Claude Code 里输入 /init,它会看你的项目,自动生成一个 CLAUDE.md 文件。然后你把里面不重要的删掉,只留最关键的几条。
第二步:设置权限
创建 .claude/settings.json 文件,告诉 Claude 什么能做、什么不能做。至少要写两条:允许它运行你的项目命令(比如 npm run dev),禁止它读 .env 文件(里面有密码)。
第三步:做一两个快捷命令
想想你最常让 Claude 干的事,比如“审查代码”、“修 bug”,给它们做成命令。以后直接输入 /review 就行,不用每次打一堆字。
第四步:规则太多了就拆开
等你的 CLAUDE.md 文件越写越长,就把它拆成几个小文件,放在 .claude/rules/ 文件夹里。API 的规则单独一个文件,测试的规则单独一个文件,这样好管理。
第五步:加上你的个人习惯
在你电脑的用户文件夹里创建 ~/.claude/CLAUDE.md,写上你自己的偏好。比如“我喜欢先写类型再写代码”、“我喜欢用函数式写法”。这样不管打开哪个项目,Claude 都记得你的习惯。
做完这五步,基本就够用了。95% 的项目只需要这些。至于 skills 和 agents,那是你有特别复杂的重复工作时才用得上的高级功能。

最后说几句#

.claude 文件夹就是用来告诉 Claude:“我是谁、我的项目是干嘛的、你该怎么干活”。
你写得越清楚,Claude 就越少犯错,你就越少返工。
最重要的是 CLAUDE.md 这个文件,先把它写好,其他都是锦上添花。
别一上来就想把所有功能都用上。从简单的开始,慢慢加东西。
本文基于 Akshay 内容深度整理:
https://x.com/akshay_pachaar/status/2035341800739877091
🫶感谢看到这里,如果对你有帮助,欢迎关注我的 X 账号 👉@imaxichuhai,我会持续分享 AI 思考、AI 工具使用体验等内容。
也欢迎关注我的公众号: