
Claude Code를 그냥 “코드 대신 써주는 챗봇”처럼 쓰면 금방 한계가 옵니다. 핵심은 반복 작업을 Skills, slash command, CLAUDE.md, MCP로 묶어두고, 매번 같은 품질 기준으로 실행하게 만드는 것입니다.
내 프로젝트에 맞는 Claude Code 작업 규칙을 2개만 정해보고, 다음 커밋부터 테스트 생성과 PR 요약에 먼저 적용해보세요.
먼저 넣을 만한 조합은 명확합니다. 개인 프로젝트라면 테스트 생성, 리팩터링 리뷰, 버그 재현, PR 요약, 문서화, 보안 점검, UI 스냅샷 확인 순서로 세팅하는 것이 가장 체감이 큽니다.
지금 쓰는 프로젝트에
CLAUDE.md를 만들고, 아래 7개 중 2개만 먼저 붙여보세요. 테스트와 PR 요약부터 시작하면 실패 비용이 낮습니다.먼저 추천하는 Claude Code Skills 조합
여기서 말하는 스킬은 Claude Code가 반복적으로 수행할 작업 지시, 컨텍스트 규칙, 명령 흐름을 묶은 운영 단위로 보면 됩니다. 공식 기능명과 폴더 구조는 버전에 따라 바뀔 수 있으니, 실제 적용 전에는 Anthropic 문서를 확인하는 것이 안전합니다.
1. 테스트 생성 스킬: Vitest·Jest 프로젝트에 가장 먼저
가장 돈값 하는 스킬은 테스트 생성입니다. “이 함수 테스트 짜줘”가 아니라, 프로젝트의 테스트 스타일과 파일 위치, mock 방식까지 정해둬야 결과가 안정됩니다.
예를 들어 TypeScript SaaS 프로젝트라면 tests 위치, Vitest 사용, API mock은 msw 우선, 실패 테스트를 먼저 만들고 구현 변경은 최소화하라는 규칙을 적어둡니다.
2. 리팩터링 리뷰 스킬: Cursor와 병행할 때 효과적
Cursor에서 빠르게 구현하고 Claude Code로 구조 리뷰를 맡기면 흐름이 좋습니다. 이 스킬에는 “동작 변경 금지”, “public API 유지”, “복잡도 높은 함수부터 제안” 같은 제한을 넣어야 합니다.
무작정 리팩터링을 맡기면 파일을 너무 많이 건드립니다. 그래서 저는 작은 단위의 diff를 기준으로 3개 이하의 변경 제안만 요구하는 쪽을 권합니다.
3. 버그 재현 스킬: 에이전트가 길을 잃지 않게 만드는 장치
Claude Code가 버그를 고치기 전에 반드시 재현 절차를 쓰게 만들면 성공률이 올라갑니다. 로그 확인, 실패 테스트 작성, 원인 후보 정리, 수정, 재실행 순서로 고정하는 방식입니다.
Playwright를 쓰는 프론트엔드라면 “브라우저 콘솔 오류와 네트워크 오류를 먼저 확인” 같은 규칙이 특히 유용합니다.
용도별 비교표: 무엇부터 만들까?
| 스킬 | 잘 맞는 상황 | 추천 도구 | 주의할 점 |
|---|---|---|---|
| 테스트 생성 | 레거시 코드에 안전장치가 필요할 때 | Vitest, Jest, Playwright | 테스트 파일 위치와 mock 규칙을 명시 |
| PR 요약 | GitHub 협업, 코드리뷰 시간이 긴 팀 | GitHub, Slack | 변경 이유와 리스크를 분리해서 쓰게 하기 |
| 문서화 | README, API 문서가 계속 밀릴 때 | Notion, Markdown | 없는 기능을 추측해 쓰지 못하게 제한 |
| 보안 점검 | 환경변수, 인증, 권한 로직이 있는 앱 | GitHub Secret Scanning, npm audit | 자동 수정 전 수동 확인 필수 |
| UI 확인 | Next.js, React 화면 변경이 잦을 때 | Playwright, Figma | 디자인 판단보다 깨짐 감지에 집중 |
실제로 써먹는 셋업 예시
가상의 예로, Next.js와 Supabase로 만든 작은 예약 관리 SaaS를 Claude Code로 관리한다고 해보겠습니다. 이때 루트에 CLAUDE.md를 두고 “DB 마이그레이션은 직접 실행하지 말 것”, “테스트 없는 수정은 완료로 보지 말 것”, “UI 문구 변경은 한국어 톤을 유지할 것”을 적습니다.
그다음 test-writer, bug-reproducer, pr-summary 같은 작업 지시를 분리합니다. MCP를 쓴다면 GitHub MCP로 이슈와 PR 맥락을 가져오고, 필요할 때만 파일 변경을 허용합니다. n8n이나 Zapier를 붙이면 PR 생성 후 Slack 알림까지 자동화할 수 있습니다.
이 구성의 장점은 명령이 짧아진다는 점입니다. “예약 취소 버그 재현하고 최소 수정해줘”라고만 말해도, 에이전트가 재현 → 테스트 → 수정 → 요약 순서로 움직이게 됩니다.
이런 사람에게 이렇게 추천합니다
혼자 만드는 빌더
처음부터 거창하게 만들 필요 없습니다. 테스트 생성 + 문서화만 있어도 배포 전 불안감이 줄어듭니다. 특히 사이드 프로젝트는 나중에 돌아왔을 때 맥락을 잃기 쉬우므로 문서화 스킬이 생각보다 중요합니다.
팀에서 쓰는 개발자
팀이라면 PR 요약 + 리팩터링 리뷰 + 보안 점검을 우선 추천합니다. 코드 품질보다 먼저 맞춰야 할 것은 협업 언어입니다. “어떤 기준으로 변경을 설명할지”를 통일하면 리뷰 시간이 줄어듭니다.
자주 막히는 지점
가장 흔한 실수는 스킬을 너무 똑똑하게 만들려는 것입니다. “전체 앱을 분석하고 개선해줘”보다 “이 PR에서 테스트 누락 가능성이 있는 파일만 찾아줘”가 훨씬 낫습니다.
또 하나는 권한 문제입니다. Claude Code가 명령어를 실행할 수 있는 환경에서는 데이터 삭제, 마이그레이션, 배포 명령을 함부로 실행하지 못하게 막아야 합니다. 운영 DB와 연결된 프로젝트라면 읽기 전용 규칙을 먼저 두세요.
FAQ
Claude Code Skills와 CLAUDE.md는 다른가요?
역할이 겹칠 수 있지만 목적을 나누면 편합니다. CLAUDE.md는 프로젝트 전체 규칙, 스킬은 테스트 작성·버그 재현처럼 반복되는 작업 흐름으로 생각하면 됩니다.
Cursor를 쓰고 있어도 Claude Code가 필요할까요?
Cursor는 편집기 안에서 빠르게 고치는 데 좋고, Claude Code는 터미널 기반으로 여러 파일·테스트·Git 흐름을 이어가기 좋습니다. 둘 중 하나만 고르기보다 구현은 Cursor, 검증과 정리는 Claude Code로 나누면 실용적입니다.
처음 만들 스킬은 몇 개가 적당한가요?
처음에는 2~3개면 충분합니다. 테스트 생성, 버그 재현, PR 요약부터 시작하고 실제로 반복되는 작업이 보일 때 하나씩 추가하세요.
오늘 바로 적용할 한 가지
지금 프로젝트에서 가장 자주 하는 일을 하나 고르세요. 그리고 그 작업의 “입력, 금지할 행동, 완료 기준”을 세 줄로 적어 Claude Code에 고정해두면 됩니다. claude code skills 추천 목록을 많이 모으는 것보다, 내 저장소에서 실패하지 않는 작은 규칙 하나가 더 효과적입니다.
관련 링크
- claude code 추천 mcp: 실제 빌드에 먼저 붙일 서버 6개와 선택 기준
- 컨텍스트 엔지니어링 실전: AI 에이전트에 실제 문맥을 전달하는 3가지 패턴
- Claude Code 실전 워크플로: 에이전트로 코드 생성·테스트·배포까지 빠르게 연결하는 방법
- 관련 태그 더 보기
- 카테고리 더 보기
- 검색 결과 더 보기
- 참고 링크
