이거보다 나은 클로드 코드 사용법은 없습니다.
조금 세게 들리지만, 이 저장소를 보면 왜 그런 말을 하는지 바로 이해됩니다.
Boris Cherny가 README 상단에서 이렇게 말합니다.
“There is no one correct way to use Claude Code.”
클로드 코드를 만든 사람이 “정답은 하나가 아니다”라고 말하는데, 역설적으로 이 저장소는 그 말의 가장 좋은 실전 답안지처럼 보입니다.
- GitHub: https://github.com/shanraisshan/claude-code-best-practice
- 핵심 문구: “from vibe coding to agentic engineering”
이 저장소가 뭔가요?
한마디로 말하면, Claude Code를 ‘그냥 코딩 도와주는 챗봇’에서 ‘엔지니어링 시스템’으로 바꾸는 레시피 모음입니다.
일반적인 Claude Code 사용법은 대개 이렇습니다.
- 터미널에서 Claude Code를 켠다
- “이 기능 만들어줘”라고 말한다
- 결과물을 보고 고친다
- 다시 시킨다
이 방식도 충분히 좋습니다. 하지만 이 저장소가 말하는 방향은 한 단계 더 나갑니다.
“프롬프트 하나 잘 쓰기”가 아니라, 명령어·서브에이전트·스킬·워크플로우를 조립해 반복 가능한 개발 체계를 만들자는 쪽입니다.
핵심은 무엇인가요?
README를 훑으면 반복해서 나오는 축이 있습니다.
- Commands: 반복 작업을 슬래시 명령어로 만든다
- Subagents: 역할별 전문 에이전트를 둔다
- Skills: 재사용 가능한 작업 절차를 문서화한다
- Workflows: Research → Plan → Execute → Review → Ship 흐름으로 묶는다
- Settings / MCP / Hooks: 권한, 도구, 자동화 지점을 시스템화한다
즉, 좋은 Claude Code 사용법은 “모델에게 더 똑똑하게 말하기”에서 끝나지 않습니다.
좋은 사용법은 모델이 일하는 환경 자체를 설계하는 것에 가깝습니다.
왜 ‘바이브 코딩’에서 끝나면 안 되나요?
바이브 코딩은 빠릅니다. 아이디어를 던지고, 코드가 나오고, 바로 실행해보는 재미가 있습니다.
문제는 프로젝트가 조금만 커져도 금방 한계가 온다는 겁니다.
- 에이전트가 방금 한 결정을 잊음
- 테스트 없이 “다 됐다”고 말함
- 같은 설명을 계속 반복해야 함
- 리뷰와 구현이 한 덩어리로 섞임
- 안전하게 되돌릴 구조가 약함
이 저장소는 그 지점을 정면으로 다룹니다. Claude Code를 잘 쓰려면 “대화”가 아니라 작업장을 만들어야 한다는 겁니다.
가장 인상적인 패턴은요?
저는 이 패턴이 가장 좋았습니다.
Command → Agent → Skill
예를 들어 /weather-orchestrator 같은 명령어가 있다고 합시다. 사용자는 명령어 하나만 실행합니다. 하지만 내부에서는 에이전트가 역할을 나누고, 필요한 스킬 문서를 읽고, 결과를 종합합니다.
개발 업무에 적용하면 이렇게 바뀝니다.
/plan은 요구사항을 구조화/implement는 구현 담당 에이전트 호출/review는 별도 리뷰어 에이전트 호출/fix는 리뷰 결과만 반영/ship은 테스트, 문서, 커밋 전 체크리스트 수행
이건 단순 자동화가 아닙니다. 사람 개발팀의 작업 방식을 Claude Code 안에 이식하는 쪽에 가깝습니다.
초보자는 어디서부터 따라 하면 좋을까요?
처음부터 전부 따라 할 필요는 없습니다. 오히려 세 가지부터 시작하면 좋습니다.
1. CLAUDE.md부터 정리하기
프로젝트의 규칙, 금지사항, 테스트 방법, 배포 방법을 CLAUDE.md에 적어둡니다.
Claude Code에게 매번 “우리 프로젝트는 이런 구조야”라고 말하지 말고, 프로젝트가 스스로 말하게 만드는 겁니다.
2. 반복 프롬프트를 Commands로 빼기
자주 쓰는 요청이 있다면 슬래시 커맨드로 만듭니다.
예를 들어:
- “이 이슈를 읽고 구현 계획만 세워줘”
- “변경사항을 리뷰하고 위험한 부분만 지적해줘”
- “테스트 실패 원인을 추적해줘”
이런 요청은 매번 새로 쓰지 말고 명령어로 고정하는 게 좋습니다.
3. 리뷰와 구현을 분리하기
AI에게 구현과 검토를 한 번에 맡기면, 자기가 만든 결과를 너무 쉽게 통과시키는 경우가 있습니다.
그래서 구현 에이전트와 리뷰 에이전트를 분리하는 게 좋습니다. 저장소가 강조하는 subagent 패턴도 결국 이 문제를 해결하려는 방향입니다.
실무적으로 가장 중요한 메시지
이 저장소의 진짜 가치는 “Claude Code 팁 모음”이 아니라는 점입니다.
더 정확히는 AI 코딩을 개인기에서 프로세스로 바꾸는 자료입니다.
이제 코딩 에이전트는 단순히 코드를 생성하는 도구가 아닙니다. 프로젝트 규칙을 읽고, 도구를 호출하고, 테스트를 돌리고, 리뷰를 받고, 배포 전 체크리스트까지 수행하는 작업자에 가까워지고 있습니다.
그러면 질문도 바뀝니다.
예전 질문은 이거였습니다.
“Claude Code에게 뭐라고 말해야 코드를 잘 짜줄까?”
이 저장소가 던지는 질문은 이쪽입니다.
“Claude Code가 계속 잘 일하게 하려면, 어떤 작업 환경과 절차를 만들어야 할까?”
이 차이가 큽니다.
그래서 결론은요?
Claude Code를 가끔 쓰는 사람이라면 이 저장소는 팁 모음으로 보일 수 있습니다.
하지만 Claude Code를 매일 쓰는 사람이라면, 이건 거의 운영 매뉴얼에 가깝습니다.
특히 다음 세 부류에게 강하게 추천합니다.
- Claude Code를 쓰지만 결과가 매번 들쭉날쭉한 사람
- 혼자 쓰는 프롬프트를 팀 단위 워크플로우로 바꾸고 싶은 사람
- “AI 코딩”을 넘어서 “에이전틱 엔지니어링”으로 가고 싶은 사람
Boris의 말처럼, Claude Code를 쓰는 정답은 하나가 아닙니다.
하지만 지금 당장 하나의 좋은 출발점을 고르라면, 저는 이 저장소를 먼저 보겠습니다.
정답은 하나가 아니지만, 좋은 작업장은 만들 수 있습니다.