Claude Code 활용법 정리 — 망치는 습관 3개와 살리는 습관 7개

Claude Code를 잘 쓴다는 사람들 글을 따라 했는데 결과물은 평범한 적이 있을 겁니다.
원인은 보통 "좋은 습관을 더 추가해서"가 아니라 "나쁜 습관을 안 빼서"인 경우가 많습니다. 잘못된 세팅을 그대로 두면 컨텍스트가 비대해지고, 결과 품질은 떨어지고, 토큰 비용은 그대로 나갑니다.

AI 도구를 실무 워크플로우에 붙여온 입장에서 지난 몇 달간 정리한 패턴과 Claude Code 창시자 Boris가 직접 공개한 원칙을 합쳐 정리합니다. 이 글을 끝까지 읽으면 Claude Code 활용법 핵심 10가지 원칙(망치는 습관 3개 + 살리는 습관 7개)과 검증 루프 함정 회피법까지 가져갑니다.

 

 

Claude Code 활용법의 핵심 — 더하기보다 빼기

Claude Code 콘텐츠는 "이거 깔아라, 이 스킬 써라" 류가 압도적으로 많습니다. 그런데 실제로 퍼포먼스를 떨어뜨리는 원흉은 "안 빼고 쌓아둔 것"인 경우가 많습니다. Claude Code 활용법의 출발점은 "무엇을 더할까"가 아니라 "무엇을 빼야 컨텍스트가 깨끗해지나"입니다.

 

이 글이 다룰 10가지 원칙을 한 장으로 요약하면 다음과 같습니다.

구분	원칙	효과
빼기	풀 세팅 금지	컨텍스트 슬림화
빼기	FOMO 차단	워크플로우 일관성
빼기	"알아서 해줘" 프롬프트 금지	결과 품질 안정
더하기	컨텍스트 관리	응답 정확도 ↑
더하기	진짜 계획	재작업 ↓
더하기	명시적 지시	스킬 활용률 ↑
더하기	검증 루프	품질 2~3배
실전	리와인드 ESC×2	실패 기록 제거
실전	스킬 자산화	컨텍스트 비용 0
실전	열린 사고	도구 이해 깊이

 

 

망치는 습관 3가지 — 먼저 빼야 할 것

1. 처음부터 풀 세팅 금지

Claude Code를 처음 깔자마자 GitHub에서 인기 있다는 스킬·에이전트·MCP 서버를 한꺼번에 설치하는 분이 많습니다. 결과는 대부분 같습니다. 어떤 스킬이 뭘 하는지 본인도 모르는 상태가 됩니다.

 

저는 처음에 인기 스킬 5~6개를 깔아두고 바로 실무 작업을 시킨 적이 있습니다. 결과는 Claude가 그 스킬들을 안 쓰고 자기 멋대로 동작했습니다. 명시적 호출을 안 한 게 1차 원인이지만, 더 근본적으로는 제가 그 스킬이 정확히 무슨 역할인지 모르고 깔았던 것이 진짜 이유였다고 봅니다.

나쁜 순서: 스킬 50개 + 에이전트 10개 일괄 설치 → 어떤 게 뭘 하는지 모름
좋은 순서: 바닐라 → 반복 패턴 발견 → 그 패턴 1개에 대한 스킬 추가

Claude Code 창시자 Boris도 X에서 "내 세팅은 놀랍게도 바닐라"라고 공개했습니다. 본인이 만든 툴인데 거의 커스텀 안 하고 그대로 씁니다. 좋은 걸 다 갖다 박는 게 좋은 게 아니라, 실제 니즈에 따라 자라난 세팅이 가장 좋은 세팅이라는 의미입니다.

 

상황 분기는 이렇습니다. 팀 규모가 5명 이상이고 표준 워크플로우가 필요하다면 CLAUDE.md를 150줄 안에서 잡고 시작하면 됩니다. 1인 운영이면 그것도 없이 바닐라로 1~2주 돌려보고, 반복되는 패턴이 보일 때 그 한 가지에 대해서만 스킬을 만드는 게 낫습니다.

---

2. FOMO에 휩쓸리지 않기

Claude는 업데이트 속도가 빠릅니다. 최근 몇 주만 봐도 Skills, Hooks, Plugins, Subagents가 줄줄이 나옵니다. "이거 다 따라가야 한다"는 불안에 시달리기 쉽습니다.

 

새 기능을 무시하라는 게 아니라 어떤 태도로 받아들이느냐가 다릅니다.

FOMO	열린 사고
안 쓰면 뒤쳐진다는 불안	왜 생긴 건지 던지는 질문
안 쓸 거면서 일단 깔고 봄	이해한 뒤 필요할 때 사용
새 기능에 휘둘림	내 워크플로우 기준으로 선택
행동(설치)이 먼저	이해(질문)가 먼저

솔직히 새로 나오는 기능들은 당장 본인 워크플로우와 안 맞거나 필요 없을 확률이 더 높습니다. Claude Code 활용법의 갭을 만드는 건 새 기능 채택 속도가 아니라 자기 워크플로우를 얼마나 정확히 알고 있느냐입니다.

---

3. "알아서 해 줘" 프롬프트 금지

"이거 만들어 줘", "이 버그 알아서 고쳐 줘" 식의 프롬프트입니다. 한 번에 완성도 있는 결과가 나오는 경우는 거의 없습니다. 평균 품질이 나쁘다기보다, 방향이 본인이 원한 것과 다르게 가는 일이 잦습니다.

 

Anthropic이 공식적으로 강조한 방향도 같습니다. "AI가 혼자 다 하는 방향이 아니라, 인간이 검증한 방식을 패키지로 만들어 AI에게 시키는 방향." 즉 방향은 사람이 잡고, 실행은 AI가 하는 분업 구조죠.

나쁜 예: "이 버그 알아서 고쳐 줘"

좋은 예: "이 함수에서 null 체크가 빠져서 발생한 버그입니다.
         A 방식(early return)으로 수정해 주세요.
         완료 기준은 기존 테스트 통과 + 새 테스트 1개 추가입니다."

자율주행을 타도 어디로 갈지 내비게이션은 직접 찍어야 합니다. 목적지는 AI가 정하는 게 아니라 본인이 정하는 것입니다.

 

살리는 습관 4가지 — 더해야 할 것

4. 컨텍스트 관리 — Claude Code 활용법의 핵심 스킬

원칙 하나면 됩니다. 신선한 컨텍스트가 비대한 컨텍스트를 이깁니다.

대화 메시지, 읽은 파일, 실행한 명령어가 모두 컨텍스트에 쌓입니다. 채워질수록 응답 품질이 떨어집니다.

일반적인 오해	실제 동작
"정보 많이 주면 더 잘하겠지"	관련 없는 정보가 많을수록 잘못된 방향으로 빠짐
"CLAUDE.md를 길게 다 적자"	Claude는 CLAUDE.md의 약 80%만 따른다고 알려져 있음
"맥락을 다 줘야지"	진짜 필요한 것만 남기고 나머지를 쳐내야 함

실전 가이드는 두 줄로 요약됩니다.

• CLAUDE.md는 150~200줄 안에서 끝냅니다. 길수록 중요한 규칙이 무시됩니다.
• 정보를 더 주는 게 아니라 불필요한 걸 쳐내는 방향으로 일합니다.

15년차로서 본 패턴인데, CLAUDE.md가 500줄을 넘어가면 "왜 이 규칙은 안 지키지" 같은 디버깅이 잦아집니다. 규칙을 더 박으면 더 안 지킵니다. 줄이면 지킵니다.

---

5. 진짜 계획 세우기

Plan 모드를 켜라는 얘기가 아닙니다. 진짜 계획은 본인이 뭘 만들고 싶은지 명확하게 아는 것입니다.

가짜 계획	진짜 계획
"이 기능 추가해 줘"	"어떤 식으로 구현할지 + 완료 기준이 뭔지"
Plan 모드 결과를 그냥 수락	Plan 모드 결과를 편집해서 보강
AI가 알아서 정하길 기대	내가 정한 방향을 명시적으로 전달

Plan 모드의 진짜 가치는 "이 과정을 잘 몰라도 Claude와 함께 갈 수 있다"는 점입니다. 그러나 결과를 그냥 수락하지 말고 편집을 적극적으로 하시는 게 좋습니다. 빠진 엣지 케이스, 본인이 원하는 패턴, 회사 코딩 컨벤션 같은 걸 추가해 넣으면 결과 품질이 한 단계 올라갑니다.

---

6. 명시적으로 지시하기

특정 스킬을 만들어 놨더라도 Claude에게 그냥 "이거 구현해 줘"라고 하면 그 스킬을 안 쓰고 자기 멋대로 합니다. 본인의 도구·스킬·규칙을 진짜 쓰게 하려면 AI가 알아서 해 주길 바라지 말고 대놓고 시키시면 됩니다.

나쁜 예: "API 엔드포인트 추가해 줘"

좋은 예: "/skill-creator 스킬 사용해서 API 스킬을 만든 다음,
         그 스킬을 호출해서 /users 엔드포인트를 추가해 주세요."

"너무 세세하게 다 지시해야 하나" 싶을 수 있습니다. 그게 AI를 잘 쓰는 것입니다. AI는 본인의 모든 생각을 알 수 없으니, 원하는 게 있으면 명시적으로 전달하는 게 맞습니다.

---

7. 검증 루프 만들기

Boris가 "단 하나의 팁만 고른다면" 골랐던 그 팁입니다. Claude에게 자기 일을 스스로 검증할 방법을 주기만 해도 결과물 품질이 2~3배 올라갑니다.

검증 루프 없음	검증 루프 있음
본인이 유일한 피드백 루프	Claude가 스스로 돌리고 스스로 고침
만들고 → 확인 → 피드백 → 수정 (수동 사이클)	다 끝난 버전이 사람에게 옴
매번 직접 검증	자동화된 체크

예시는 다음과 같습니다. 테스트, 타입체크, 린트, 빌드 검증, 출력 스키마 검증 같은 것들입니다. Claude가 결과를 내고 → 이 검증을 돌리고 → 실패하면 본인이 다시 고칩니다.

 

⚠️ 그런데 함정이 있습니다. 검증 루프를 붙여놔도 AI가 악용할 수 있습니다.

정상 동작: 테스트 실패 → 코드 수정
악용 패턴: 테스트 실패 → 테스트 자체를 통과하도록 수정 (의미 없는 테스트)

검증 루프를 만들었다고 끝이 아닙니다. 테스트가 올바른 걸 검증하고 있는지, 그 테스트 자체도 사람이 봐야 합니다. 이 부분은 트러블슈팅 섹션에서 한 번 더 다루겠습니다.

 

실전 꿀팁 3가지

8. 세션 관리 — 리와인드(ESC × 2)

Claude Code 팀이 직접 강조한 팁입니다. 컨텍스트 관리 잘하는 사람을 가르는 단 하나의 습관을 꼽자면 그것이 바로 리와인드입니다.

 

대화 중 ESC를 두 번 누르면 나옵니다. 이전 메시지 지점으로 돌아가서 그 이후 기록을 싹 지웁니다.

일반 메시지 재시도	리와인드 사용
"A 말고 B로 해 줘"	ESC × 2 → 그 시점부터 다시
실패 기록이 컨텍스트에 남음	실패 기록 없는 깨끗한 상태
Claude가 실패에 영향받음	Claude가 깨끗한 머리로 시도

세션 관리 명령어 3개의 차이는 다음과 같습니다.

명령어	용도	사용 타이밍
ESC × 2 (리와인드)	특정 시점으로 되감기	A 시도 실패 → B로 다시 시도할 때
/clear	세션 완전 초기화	작업이 끝났을 때, 마침표 찍듯
/compact	지금까지 대화 요약	컨텍스트가 많이 차서 압축이 필요할 때

/compact는 그냥 쓰지 말고 방향을 직접 지시하면 훨씬 좋은 요약이 나옵니다.

/compact 이번엔 A 작업에 집중하고 B 관련 내용은 버려.

---

9. 스킬은 자산이다

Claude 생태계는 스킬 중심으로 움직이고 있습니다. CLAUDE.md와 Skills의 차이를 명확히 하면 어디에 뭘 넣을지 헷갈리지 않습니다.

CLAUDE.md	Skills
세션 시작 시 항상 컨텍스트에 들어감	실제 필요할 때만 로드됨
길어지면 성능 저하	컨텍스트 비용 거의 없음
일반적인 규칙용	특정 작업의 레시피용

스킬 활용 순서는 둘입니다. 첫째, 남이 만든 좋은 스킬을 가져다 씁니다. GitHub에 이미 유용한 스킬이 많습니다 (예: disler/superpowers, garrytan/gstack 등). 둘째, 반복 작업이 보이면 본인 스킬로 저장합니다. 유지 비용이 거의 없는데도 자산이 됩니다.

 

스킬은 한 번 만들면 계속 쓸 수 있고 컨텍스트도 거의 안 먹습니다. 단, 만들어 놓고 안 쓰면 의미가 없으니 위 6번(명시적으로 지시하기)과 짝으로 가야 합니다.

---

10. FOMO가 아닌 열린 사고

기술적인 팁이 아닌 태도입니다. Part 1의 "FOMO 피하기"와 모순처럼 보이지만 두 개는 완전히 다릅니다.

• FOMO: "이거 안 쓰면 뒤쳐지는 거 아닌가" — 불안 기반, 행동(설치)이 먼저
• 열린 사고: "이 기능은 왜 생겨난 건가, 내 프로젝트에 어떻게 적용할 수 있을까" — 질문 기반, 이해가 먼저

진짜 좋은 능력은 남의 워크플로우를 그대로 복사하는 게 아니라, 그것을 이해해서 본인 상황에 맞게 번역해서 적용하는 능력입니다. 이건 자동화할 수 없는 부분이자, 시간이 지날수록 자산이 되는 부분입니다.

 

트러블슈팅 — 검증 루프가 망가질 때

위 7번에서 살짝 언급한 함정을 본격적으로 풀어 보겠습니다. 검증 루프를 만들었는데도 결과 품질이 안 오르거나, 오히려 더 떨어지는 경우입니다.

 

증상: 모든 테스트가 통과했다고 보고하는데, 실제로 앱을 띄워 보면 기능이 깨져 있습니다. 또는 타입체크가 통과했는데 런타임에 undefined is not a function이 터집니다.

 

원인: Claude가 테스트를 통과시키기 위해 테스트 자체를 무력화한 경우가 많습니다. 예를 들어 expect(result).toBe(42)를 만족시키지 못하니까 expect(true).toBe(true)로 바꿔놓는 식입니다. 또는 타입 에러가 나니까 as any로 캐스팅해서 통과시킵니다. 검증 장치를 형식적으로만 통과시키는 패턴입니다.

 

해결: 두 가지를 동시에 합니다.

1. 검증 루프 자체를 변경 가능 영역에서 빼냅니다. 테스트 파일은 /freeze tests/ 같은 식으로 편집을 막거나, 코드 리뷰 단계에서 테스트 변경분을 사람이 직접 봅니다.
2. 검증 결과 외에 "테스트 코드도 변경됐는지"를 확인하는 검증을 한 단계 더 둡니다. git diff --stat 결과를 같이 보여달라고 시키면 테스트 줄이 같이 변경됐는지 한눈에 보입니다.

검증 루프를 두 번째 살펴보는 것이 본인 일이 됩니다. 단 한 번만 해 두면 그다음부터는 자동화돼서 부담이 줄어듭니다.

 

정리 — 어떤 순서로 적용하면 되나

먼저 빼고, 그다음에 더하는 순서를 추천합니다. 처음부터 풀 세팅하지 말고 바닐라로 1~2주 돌리면서 본인 반복 패턴을 본 다음, 그 패턴 한 가지에 대해서만 명시적으로 지시할 수 있는 스킬을 만들고, 검증 루프를 붙입니다. 컨텍스트가 차오르기 시작하면 ESC×2로 리와인드하거나 /compact로 방향 지시 요약을 합니다. 이 사이클을 몇 번 돌리면 Claude Code 활용법이 본인 워크플로우 안에서 자라납니다.

"신선한 컨텍스트가 비대한 컨텍스트를 이긴다." — Claude Code 활용법의 핵심 한 줄

동일 환경이면 위 가이드 순서 그대로 따라가도 됩니다. 1인 개발자면 CLAUDE.md 없이 시작해도 무방하고, 팀 규모 5명 이상이면 150줄 안에서 잡고 시작하시면 됩니다.

 

자주 묻는 질문

Q. Claude Code CLAUDE.md는 몇 줄까지 써도 되나요?

A. 150~200줄 안에서 끝내는 쪽을 권장합니다. 길어질수록 Claude가 그 안의 규칙을 따르는 비율이 떨어진다고 알려져 있습니다(약 80%선). CLAUDE.md는 세션 시작 시 항상 컨텍스트에 들어가니, 길수록 다른 작업의 컨텍스트 여유 공간이 줄어드는 셈. 일반 규칙은 CLAUDE.md, 특정 작업 레시피는 Skills로 분리하시면 됩니다.

 

Q. 리와인드(ESC × 2)와 /clear는 뭐가 다른가요?

A. 리와인드는 이전 특정 메시지 지점으로 되돌아가고 그 이후 기록을 지웁니다. 반면 /clear는 세션 전체를 통째로 초기화. A 방식으로 시도했다가 실패해서 B 방식으로 다시 가고 싶을 때는 리와인드가 맞고, 작업 자체가 끝나서 마침표 찍듯 다음 작업으로 넘어갈 때는 /clear가 맞습니다.

 

Q. 검증 루프는 어떻게 만들면 되나요?

A. 가장 간단한 건 기존 테스트·타입체크·린트를 검증 루프로 지정하는 것. "이 작업 끝나면 npm test && npm run typecheck 돌려서 결과 확인하고, 실패하면 고쳐 주세요"처럼 명시적으로 지시하면 됩니다. 검증 루프를 만들 때는 "테스트 자체는 변경하지 말 것" 같은 가드도 같이 박아 두시는 편이 안전합니다.

 

Q. 스킬을 만들어도 Claude가 안 쓰는데 왜 그런가요?

A. 명시적으로 호출 안 했을 확률이 높습니다. Claude는 스킬이 있는 줄 알아도 본인이 알아서 그 스킬을 골라 쓰지 않습니다. "/{스킬명} 사용해서 ~~ 해 주세요" 식으로 대놓고 시키면 호출됩니다. 또 다른 방법으로는 CLAUDE.md에 "X 작업은 /Y 스킬을 사용한다"는 규칙을 박아두는 방식도 있습니다.

 

Q. 처음부터 gstack이나 superpowers 같은 스킬 모음을 깔아도 되나요?

A. 권장하지 않습니다. 본인이 그 스킬들이 뭘 하는지 모르는 상태에서 깔면 Claude가 그걸 안 쓰거나, 쓰더라도 결과를 본인이 검토할 수 없게 됩니다. 1~2주 정도 바닐라로 돌려보고 반복 패턴이 보일 때 그 한 가지에 대해서만 추가하는 쪽이 자라나는 세팅에 가깝습니다.

 

📎 이 카테고리의 다른 글

• Claude Code 창시자와 해커톤 우승자의 공통 꿀팁 7가지 — 2026-04-05
• Claude Code 필수 설정 가이드 — 2026-03-20
• 단 1달러도 내지 않고 Claude Code를 사용하는 방법 — 정확한 세팅 가이드 — 2026-03-23

같은 AI 활용법 카테고리에서 이어서 읽기

 

---

설치 환경: Windows 11, Node.js v24, Claude Code, Claude Max