Claude Code 활용 매뉴얼 - 8가지 원칙

이 글에서 다루는 내용

Claude Code를 제대로 쓰기 위해 챙겨야 할 원칙 8가지를 중요도 순서로 정렬한 운영 매뉴얼입니다. 위로 갈수록 매일의 결과 품질에 직접 영향을 주는 항목이고, 아래로 갈수록 장기적인 작업 습관에 가깝습니다. 출처는 Claude Code 창시자 Boris Cherny의 공개 셋업과 Anthropic 공식 문서, 그리고 직접 써보며 확인한 동작 기준 2026년 4월 시점입니다.

번호	원칙	한 줄 요약
1	컨텍스트 관리	한 세션에 쌓인 게 많을수록 결과가 나빠진다
2	자기 검증 루프	검증 장치를 붙이고, 그 장치도 감시한다
3	Rewind 습관	메시지 더 보내기 전에 ESC 두 번
4	/clear와 /compact 운영	컨텍스트가 60%를 넘기 시작하면 정리한다
5	명시적 지시와 진짜 계획	흐릿한 프롬프트는 흐릿한 결과를 부른다
6	CLAUDE.md와 Skills 분담	항상 필요한 건 CLAUDE.md, 가끔 필요한 건 Skill
7	바닐라에서 자라는 셋업	실제 니즈를 만나기 전에 미리 박지 않는다
8	새 기능을 대하는 태도	FOMO가 아니라 열린 사고로

---

1. 한 세션에 너무 많은 걸 쌓지 않는다

Claude Code 활용에서 가장 큰 영향을 미치는 단 하나의 원칙입니다. 주고받은 메시지, 읽은 파일, 실행 결과가 모두 컨텍스트에 그대로 쌓이고, 그 양이 늘어날수록 모델은 점점 헷갈리기 시작합니다. 사용자가 할 일은 정보를 많이 주는 게 아니라, 필요한 것만 남기고 나머지는 그때그때 비우는 것입니다.

Anthropic 공식 가이드는 컨텍스트 사용률이 60~70%를 넘기면 그 시점부터 적극적으로 정리하라고 권합니다. 이 임계점이 중요한 이유는, 한계 토큰을 다 채우기 전에 이미 응답 품질이 떨어지기 시작하는 구간이기 때문입니다.

1-1. 실천 방법

• 응답이 굼떠지거나 같은 실수가 반복되면 즉시 컨텍스트 양을 확인
• 한 작업이 끝났다면 마침표를 찍는다는 감각으로 /clear
• 흐름은 살리되 양을 줄이고 싶다면 방향을 직접 지시한 /compact
• 한 세션에 여러 주제를 섞지 않는다

💡 정보를 많이 줄수록 잘하는 게 아닙니다. 필요한 것만 남길수록 잘합니다. 이 한 줄만 기억해도 절반은 챙긴 셈입니다.

---

2. 자기 검증 루프를 붙이고, 그 루프도 감시한다

Boris Cherny에게 "단 하나의 팁만 고른다면"이라고 물었을 때 그가 고른 것이 검증입니다. Claude에게 자기 작업을 스스로 검증할 방법(테스트 실행, 린트, 빌드, 스펙 확인)을 주기만 해도 결과 품질이 두세 배 올라갑니다. 검증 장치가 없으면 사용자가 유일한 피드백 루프가 되어 모든 사이클을 손으로 돌려야 합니다.

2-1. 함정 - 테스트만 통과하는 가짜 성공

같은 세션에서 코드 작성과 테스트 작성을 동시에 맡기면, 테스트가 실패할 때 코드를 고치는 대신 테스트 자체를 통과하도록 수정해 버리는 경우가 보고되어 있습니다. 학계 용어로는 reward hacking입니다. Anthropic은 Claude 4에서 이 거동이 65% 줄었다고 밝혔지만 0이 된 것은 아닙니다.

대응	방법
스펙 우선 작성	테스트나 spec을 사람이 먼저 작성하고 구현만 AI에게 맡긴다
테스트 변경 감시	PR diff에서 테스트 파일이 함께 바뀌었다면 사람이 반드시 검토
역할 분리	한 세션에서 테스트와 구현을 같이 손대지 않도록 작업을 쪼갠다

---

3. Rewind를 일상 습관으로 만든다

Claude Code 팀이 "컨텍스트 관리 잘하는 사람의 단 하나의 습관"으로 꼽은 것이 Rewind입니다. 대화창에서 ESC를 두 번 누르거나 /rewind를 입력하면 이전 체크포인트로 돌아가는 메뉴가 뜹니다. ESC 한 번은 응답을 멈추는 브레이크, 두 번은 후진 기어라고 기억하면 됩니다.

복원 옵션	대상	사용 시점
Conversation only	대화만 되돌림, 파일 변경은 유지	코드는 괜찮은데 대화가 산으로 갈 때
Code only	파일 변경만 되돌림, 대화는 유지	맥락은 유지한 채 다른 구현으로 다시 시도
Both	완전 리셋	전부 다시 시작해야 할 때

"A로 했더니 실패, B로 다시 해줘"라고 메시지를 보내면 실패한 A의 기록이 컨텍스트에 그대로 남아 결과에 영향을 줍니다. Rewind를 쓰면 A 시도가 없는 깨끗한 상태에서 B를 시도하게 되므로 결과의 일관성이 훨씬 높아집니다. 체크포인트는 세션이 종료돼도 유지되므로 터미널을 닫았다가 나중에 되돌리는 것도 가능합니다.

💡 매일 가장 빠르게 토큰을 아껴 주는 단축키가 ESC × 2 입니다. 메시지 한 줄 더 보내기 전에 먼저 눌러 보세요.

---

4. /clear와 /compact를 구분해 운영한다

두 명령은 비슷해 보이지만 결이 다릅니다. 어느 쪽을 언제 써야 하는지가 일상 운영의 핵심입니다.

명령	동작	언제 쓰는가
/clear	대화 기록을 통째로 비움 (복구 불가)	한 작업이 마침표를 찍고 다른 워크스트림으로 갈 때
/compact	지금까지의 대화를 요약으로 압축, 70k 토큰이 4k로 줄어드는 식	맥락은 살린 채 컨텍스트만 가볍게 만들고 싶을 때

/compact는 인자로 요약 방향을 직접 지시할 때 가장 유용합니다.

/compact 결제 모듈 리팩터링 결정사항만 남기고
초기 탐색 토론과 폐기된 안은 제외해줘.

실패한 시도가 컨텍스트에 남는 게 부담스럽다면 /clear를 누르고 한 줄 브리핑으로 새 세션을 여는 편이 더 깨끗합니다.

---

5. 명시적으로 지시하고, 진짜 계획을 세운다

"이 버그 알아서 고쳐 줘", "이 기능 만들어 줘" 같은 두루뭉술한 지시는 결과의 일관성을 떨어뜨립니다. Anthropic이 공식적으로 강조하는 방향도 같습니다. AI가 혼자 다 하는 형태가 아니라 인간이 검증한 방식을 패키지로 만들어 AI에게 시키는 형태가 맞다는 것입니다. 자율주행 차에 타도 어느 길로 갈지는 사람이 정하는 것과 같습니다.

5-1. 명시성의 차이가 결과의 차이

# 좋지 않은 예
이 컴포넌트 리팩터링 좀 해줘.

# 좋은 예
.claude/skills/refactor-react.md 의 단계대로
src/components/UserList.tsx를 리팩터링하고
원본과 새 버전의 행동 동등성을 vitest로 검증해줘.

"세세하게 다 지시해야 하는 거 아닌가" 하실 수 있는데, 그게 AI를 잘 쓰는 모습입니다. AI는 사용자의 머릿속을 모릅니다. 원하는 결과가 있으면 명시적으로 전달합니다.

5-2. Plan 모드의 결과를 그대로 수락하지 않는다

Plan 모드의 가치는 Claude와 함께 계획을 만들 수 있다는 데 있습니다. 자동 생성된 계획을 그냥 수락하지 말고, 단계마다 완료 기준을 한 줄씩 추가하고 빠진 엣지 케이스를 직접 적어 넣은 뒤에 수락합니다. 이 한 번의 편집이 한 시간짜리 디버깅을 줄여 줍니다.

---

6. CLAUDE.md와 Skills의 역할을 분리한다

두 메커니즘은 로딩 방식이 다릅니다. 이 차이를 알면 영구 컨텍스트 비용을 크게 줄일 수 있습니다.

항목	로딩 시점	컨텍스트 비용
CLAUDE.md	세션 시작 시 무조건 로드	매 세션 항상 차지
Skills	시작 시엔 이름·설명만, 모델이 필요하다고 판단하면 본문 로드	필요할 때만 차지 (progressive disclosure)

같은 분량을 20개 항목으로 가지고 있다면 CLAUDE.md로 박았을 때 매 세션 약 40k 토큰이 깔리지만, Skills로 분산하면 시작 비용이 약 2k에 그치고 사용 순간에만 본문 약 2k가 추가됩니다. 운영 원칙은 단순합니다.

• 매 세션 항상 적용돼야 하는 규칙 → CLAUDE.md
• 특정 작업에서만 필요한 워크플로우/체크리스트 → Skill

같은 맥락에서 CLAUDE.md는 짧게 유지해야 합니다. 길어질수록 중요한 규칙이 묻혀 무시될 가능성이 커집니다. 한 화면 안에 들어오는 분량(150~200줄)을 기준으로 잡고, 넘어가는 항목은 Skill로 옮기는 흐름이 가장 안정적입니다.

⚠️ Skill은 모델이 "필요하다"고 판단해야 호출됩니다. 실제로 쓰게 하려면 프롬프트에서 .claude/skills/{name}.md 의 단계대로처럼 직접 호출을 박는 편이 안전합니다.

---

7. 셋업은 바닐라에서 자라난다

커뮤니티에서 좋다는 스킬·플러그인·서브에이전트를 한꺼번에 박고 시작하는 패턴은 결국 컨텍스트만 더럽힙니다. Claude Code 창시자 Boris Cherny는 본인의 셋업을 X에 공개하면서 "내 셋업은 놀랍게도 바닐라(vanilla)에 가깝다"고 밝혔습니다. 본인이 만든 도구임에도 거의 커스터마이징하지 않는다는 뜻입니다. Claude Code는 박스 채로도 대부분의 사용자에게 충분하기 때문입니다.

권장 순서는 다음과 같습니다.

1. 몇 주는 바닐라로 사용하면서 같은 실수, 같은 워크플로우 반복 패턴을 관찰
2. 그 패턴 하나에만 대응하는 슬래시 커맨드나 Skill을 만든다
3. 실제 니즈에 따라 셋업이 자라나도록 둔다

ℹ️ Boris의 핵심 셋업: 터미널에서 5개 Claude를 병렬로 띄움, 모델은 Opus + thinking 고정, Plan 모드로 시작해 합의된 계획만 auto-accept로 실행, 자주 쓰는 흐름은 .claude/commands/의 슬래시 커맨드로 박아 git에 커밋. 팀 단위 CLAUDE.md 한 장을 공유하고, Claude가 잘못할 때마다 그 자리에서 갱신.

---

8. 새 기능은 FOMO가 아니라 열린 사고로 대한다

Claude의 업데이트 속도는 매우 빠릅니다. 최근 몇 주만 봐도 Routines, 데스크탑 리디자인, Claude Design 같은 기능이 줄줄이 나왔습니다. 다 따라가야 한다는 불안에 휩쓸려 일단 깔고 보는 패턴은 7번 원칙과도 직접 충돌합니다.

태도	행동	결과
FOMO	"안 쓰면 뒤처진다"는 불안에 일단 설치	컨텍스트 오염, 운영 부채 누적
열린 사고	"이 기능은 왜 생겼고 내 흐름에 어떻게 들어올까" 질문	필요한 순간 즉시 채택 가능

이해해 둔 것은 필요한 순간 바로 꺼내 쓸 수 있습니다. 반대로 이해 없이 일단 깔아 둔 기능은 컨텍스트만 차지합니다. 진짜 자산은 새 기능 자체가 아니라 그 기능을 내 상황에 맞게 번역해 적용하는 능력입니다.

---

트러블슈팅

문제 1: 응답이 길어지고 무거워진다

한 답변에 너무 많은 파일이 끌려 들어가는 경우입니다. 컨텍스트 사용률이 60%를 넘기 시작했다는 신호입니다. 그 자리에서 /compact로 가볍게 만들거나 /clear로 새 세션을 엽니다.

문제 2: 같은 실수를 반복한다

한 세션에서 똑같은 패턴의 잘못이 두세 번 나오면, 그 사유를 곧장 CLAUDE.md에 한 줄로 박아둡니다. Boris의 팀도 "Claude가 잘못한 게 보일 때마다 그 자리에서 CLAUDE.md를 갱신한다"고 밝혔습니다.

문제 3: Skill을 만들어 뒀는데 안 쓴다

Skill은 모델이 필요하다고 판단해야 본문이 로드됩니다. 이름·설명이 추상적이거나 프롬프트에서 호출을 명시하지 않으면 무시됩니다. Skill 설명을 더 구체적으로 다듬거나 프롬프트에 경로를 박는 방식이 가장 확실합니다.

문제 4: 테스트만 통과하는 가짜 성공

2-1과 같은 케이스입니다. 작업을 두 단계로 쪼개고, PR diff를 머지 전에 항상 사람이 한 번 봅니다. 테스트 파일이 함께 바뀌었다면 그 변경이 정당한지 따로 확인합니다.

---

마무리

여덟 가지 원칙은 결국 한 문장으로 수렴합니다. 운전대를 사람이 잡는다. 컨텍스트는 사람이 정리하고, 검증은 사람이 설계하고, 계획은 사람이 편집하고, 셋업은 사람이 자라게 합니다. AI가 알아서 잘해 주길 바라는 자리에 사용자의 판단을 한 번씩만 끼워 넣으면, Claude Code의 잠재력이 비로소 풀리기 시작합니다.

 

• Boris Cherny의 셋업 공개: X 원문 글타래
• Claude Code 베스트 프랙티스: 공식 문서
• 세션 관리와 1M 컨텍스트: Anthropic 블로그
• Skills 공식 가이드: Extend Claude with skills
• 관련 글: Claude Code 설치 및 활용 완벽 가이드
• 관련 글: Claude 토큰 절약 팁