Notice
Recent Posts
Recent Comments
Link
«   2026/08   »
일 월 화 수 목 금 토
1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31
Tags more
Archives
Today
Total
관리 메뉴

ComeSuji

설정(Settings)과 메모리(Memory) 본문

카테고리 없음

설정(Settings)과 메모리(Memory)

콤수지 2026. 8. 4. 09:48

클로드 코드를 쓰다 보면 "이 설정은 어디에 저장해야 하지?", "팀원이랑 같이 봐야 하는 건가, 나만 봐야 하는 건가?" 하는 고민이 생깁니다. 이번 글에서는 클로드 코드의 설정(Settings) 체계와 메모리(Memory) 체계를 기준으로 정리해봤습니다.

 

1. 설정(Settings) 파일

클로드 코드는 설정을 4단계 범위(scope)로 관리합니다. 아래로 갈수록 더 좁은 범위(개인/로컬)이고, 위로 갈수록 넓은 범위(조직 전체)입니다.

 

범위 파일 위치 적용 대상

엔터프라이즈 관리 정책 managed-settings.json 회사 IT 관리자가 배포, 조직 전체에 강제 적용 (덮어쓰기 불가)
사용자 설정 ~/.claude/settings.json 내 컴퓨터의 모든 프로젝트에 공통 적용
프로젝트 설정 (공유) .claude/settings.json 해당 프로젝트에만 적용, git으로 팀원과 공유
프로젝트 설정 (로컬) .claude/settings.local.json 해당 프로젝트 내 나만의 개인 설정, 커밋하지 않음

 

적용 우선순위는 다음 순서로 높습니다 (숫자가 낮을수록 우선):

  1. 엔터프라이즈 관리 정책 (최우선, 덮어쓰기 불가)
  2. 커맨드라인 인자 (세션 한정 임시 설정)
  3. 로컬 프로젝트 설정 (settings.local.json)
  4. 공유 프로젝트 설정 (settings.json)
  5. 사용자 설정 (~/.claude/settings.json)

참고로 permissions.allow 같은 배열형 설정은 상위 설정을 "덮어쓰기"하는 게 아니라 범위별로 합쳐지고 중복 제거되는 방식으로 동작합니다.

 

settings.local.json은 왜 .gitignore에 넣어야 할까?

 

개인 API 키나 나만 쓰는 실험적 설정이 팀 저장소에 공유되면 안 되기 때문입니다. 방법은 간단합니다.

  1. 프로젝트에 .gitignore 파일을 만든다
  2. 그 안에 .claude/settings.local.json 한 줄을 추가한다

이렇게 하면 이 파일은 자동으로 git 추적 대상에서 제외되어, 팀원과는 공유되지 않고 내 컴퓨터에만 남습니다.

 

2. 권한(Permissions) 설정 — allow / deny

settings.json 안의 permissions 항목으로 클로드가 어떤 도구를 실행할 수 있는지 세밀하게 제어할 수 있습니다.

  • allow: 클로드가 확인 없이 바로 실행하도록 허용
  • deny: 클로드가 절대 접근하지 못하도록 차단 (예: .env, secrets/** 같은 민감 파일)
  • ask (기본값): 실행 전 매번 사용자에게 확인

헷갈릴 수 있는 부분인데, deny가 allow보다 우선합니다. 즉 무언가를 allow에 등록했더라도 deny에도 걸려 있으면 차단됩니다.

 

bash는 터미널에서 컴퓨터에게 명령을 내리는 명령어 체계이고, 클로드 코드는 이 bash 명령 실행 권한도 permissions로 제어합니다.

와일드카드(*)는 "모든 것"을 의미하는 패턴 기호입니다. 예를 들어:

{
  "permissions": {
    "allow": ["Bash(npm run test:*)", "Bash(git status)", "Bash(git diff)"],
    "deny": ["Read(./.env)", "Read(./secrets/**)"]
  }
}
  • Bash(npm run test:*) → npm run test로 시작하는 모든 명령을 허용
  • Read(./secrets/**) → secrets 폴더 하위의 모든 파일 읽기를 차단

실전 팁: 처음부터 모든 명령을 allow에 몰아넣기보다, 실제로 자주 쓰는 테스트/린트/git 조회 명령 위주로 조금씩 허용 목록을 늘려가는 방식이 안전합니다. /permissions 명령으로 세션 중에도 대화형으로 규칙을 추가·수정할 수 있고, 이렇게 수정한 내용은 settings.json에 자동 반영됩니다.

 

자주 쓰는 모드 저장하기

매번 실행 모드를 다시 설정하는 게 번거롭다면 defaultMode 값을 settings.json에 저장해두면 클로드 코드를 켤 때마다 자동으로 그 모드로 시작합니다 (예: "defaultMode": "acceptEdits").

 

3. 메모리(Memory) — CLAUDE.md

클로드 코드는 대화가 끝나면 기억을 잃지만, CLAUDE.md 파일에 적어둔 내용은 매 세션 시작 시 자동으로 불러와서 기억합니다. 새로 합류한 팀원에게 브리핑 문서를 주는 것과 같은 역할입니다.

 

/init 명령

프로젝트 루트에서 /init을 실행하면 클로드가 프로젝트 구조를 분석해서 기본 CLAUDE.md 초안을 자동으로 생성해줍니다. 다만 자동 생성된 내용에는 코드만 봐도 알 수 있는 당연한 정보(예: "이건 TypeScript 프로젝트입니다")가 섞여 있는 경우가 많으니, 불필요한 부분은 정리해서 쓰는 걸 추천합니다.

 

메모리의 종류

엔터프라이즈 정책 메모리 관리자가 배포 회사 IT 관리자가 조직 전체 개발자에게 강제 적용하는 지침
프로젝트 메모리 ./CLAUDE.md 해당 프로젝트에만 적용, git으로 커밋해서 팀원과 공유
프로젝트 메모리 (로컬) ./CLAUDE.local.md 나만의 프로젝트별 메모, 팀원과 공유되지 않음, gitignore 대상
사용자 메모리 ~/.claude/CLAUDE.md 내 모든 프로젝트에 공통 적용되는 개인 선호(스타일 등)
오토 메모리 (Auto memory) ~/.claude/projects/<프로젝트>/memory/ 클로드가 작업하면서 스스로 남기는 메모(빌드 명령, 디버깅 노트 등). CLAUDE.md와 별개 시스템으로, 기본적으로 켜져 있음

.claude/rules/*.md 라는 폴더를 만들면 CLAUDE.md 하나에 다 몰아넣지 않고 주제별로 지침을 쪼갤 수도 있습니다. 특히 paths 옵션을 지정하면 특정 경로의 파일을 다룰 때만 해당 규칙이 로딩되어, 매번 모든 규칙을 다 읽는 것보다 컨텍스트를 절약할 수 있습니다.

 

모든 프로젝트에서 지켜야 할 팀 가이드라인 예시

 

CLAUDE.md에는 이런 식의 구체적인 규칙을 적어둘 수 있습니다.

  • 들여쓰기 2칸, 세미콜론 사용, 문자열은 작은따옴표
  • 커밋 메시지는 한글로 작성
  • 브랜치명 규칙: feature/기능명, fix/버그명
  • 커밋은 작은 단위로 나눠서 진행
  • 파일 수정 전에는 변경 계획을 먼저 설명할 것
  • 한 번에 너무 많은 파일을 수정하지 말 것
  • OS: Windows 11 등 개발 환경 명시

 

CLAUDE.md가 너무 길어질 때 — @ 임포트

CLAUDE.md 파일이 계속 길어지면 클로드가 지침을 놓치거나 컨텍스트를 많이 잡아먹을 수 있습니다. 이럴 때 @경로 문법으로 다른 파일을 불러오는 방식으로 분리할 수 있습니다.

# 프로젝트 개요
프로젝트 개요는 @README.md 참고
사용 가능한 npm 명령어는 @package.json 참고
개인 설정은 @~/.claude/my-project-instructions.md 참고

 

이렇게 하면 CLAUDE.md 본문은 짧게 유지하면서, 필요한 세부 내용은 다른 문서로 관리할 수 있습니다. 다만 임포트된 파일도 세션 시작 시 함께 로딩되므로, 이 방식은 "정리정돈"에는 도움이 되지만 실제 컨텍스트 사용량 자체를 줄여주는 것은 아니라는 점은 참고하세요.

 

/memory 명령

현재 세션에 어떤 메모리 파일들이 로딩되어 있는지 확인하고, 에디터로 바로 열어서 수정할 수 있는 명령입니다. 어떤 지침이 왜 적용되고 있는지(혹은 안 되고 있는지) 헷갈릴 때 디버깅 용도로 유용합니다.

 

4. 메모리 작성 모범 사례

  • 구체적으로 작성하기: "들여쓰기를 잘 하세요" 보다 "들여쓰기는 2칸으로" 처럼 명확한 수치로 적기
  • 구조화해서 정리하기: 줄글보다는 리스트나 표 형식으로 정리하면 클로드도, 사람도 더 잘 따릅니다
  • 정기적으로 검토하기: 프로젝트가 바뀌면 CLAUDE.md도 오래된 내용이 쌓이기 마련이니 주기적으로 정리
  • 파일을 너무 길게 쓰지 않기: 지침이 너무 길어지면 오히려 잘 지켜지지 않을 수 있어서, 핵심만 간결하게 유지하고 세부 내용은 @ 임포트로 분리하는 걸 권장합니다
  • 반영이 안 될 때는 강조 표시: 지침을 줬는데도 클로드가 계속 반영하지 않는다면 (중요) 같은 표시를 붙여서 우선순위를 명확히 알려주면 도움이 됩니다

 

 

 

참고: 클로드 코드는 계속 업데이트되고 있어서 세부 옵션명이나 동작 방식은 버전에 따라 조금씩 달라질 수 있습니다. 최신 내용은 공식 문서를 확인해보세요.