한 줄 정의

Claude Code의 고급 패턴은 "좋은 프롬프트"를 반복하는 기술이 아니라, 지침은 CLAUDE.md에 고정하고, 반복 작업은 Skill로 만들고, 복잡한 작업은 fork/subagent로 분리하는 운영 방식입니다.

왜 지금 Claude Code 고급 패턴인가

Claude Code를 처음 쓸 때는 "이 코드를 수정해줘" 같은 직접 지시만으로도 상당히 많은 작업을 처리할 수 있습니다. 하지만 팀 단위로 가면 곧 한계가 드러납니다.

사람마다 같은 작업을 다른 방식으로 시킨다
세션이 바뀌면 지침이 사라진다
한 에이전트가 탐색·구현·검토를 모두 하다 보니 맥락이 섞인다
반복 작업을 다시 설명하느라 토큰 비용과 시간이 낭비된다

Anthropic은 2026년 3월 고급 패턴 웨비나에서 이 문제를 서브에이전트, MCP, 대형 코드베이스 컨텍스트 전략으로 풀어야 한다고 제시했습니다. 즉 Claude Code의 진짜 실전 난이도는 모델 사용법이 아니라 운영 구조 설계입니다.

이 구조는 어떻게 작동하는가

다섯 계층은 독립적으로 동작하면서 서로를 보완합니다. CLAUDE.md가 규칙을 정하면, Skill이 그 규칙 안에서 절차를 실행하고, Hook이 실행 결과를 검사하며, Fork/Subagent가 맥락 충돌을 방지합니다.

CLAUDE.md: 작업 디렉토리 상위는 시작 시 전부 로드되고, 서브디렉토리는 해당 파일 접근 시 지연 로드된다
Skill: 반복 작업을 /명령 또는 자동 트리거 가능한 재사용 워크플로우로 만든다
Fork context / Subagent: 복잡한 작업을 분리된 맥락에서 실행한다
Hooks: 테스트·lint·로그 같은 자동 검사를 생명주기 이벤트에 연결한다
MCP: 외부 시스템과 도구를 에이전트에 연결한다

핵심은 "하나의 똑똑한 채팅"이 아니라, 규칙, 재사용, 분리, 자동화를 각각 다른 계층에 두는 것입니다.

가장 많이 생기는 오해 3가지

오해 1: Skill은 단순한 단축 명령이다

현실: Skill은 단축 명령보다 훨씬 큽니다. 공식 문서 기준으로 SKILL.md에는 설명, 자동 호출 조건, 허용 도구, 모델, effort(노력 수준), fork 실행 여부 외에도 argument-hint, user-invocable, agent, hooks, paths, shell 같은 확장 필드를 지원합니다. 즉 Skill은 "명령어 별칭"이 아니라 재사용 가능한 업무 프로토콜입니다.

참고로 기존 custom commands(.claude/commands/)는 그대로 동작하며, 이름이 겹칠 때는 skill이 우선합니다. disable-model-invocation: true를 설정하면 자동 실행을 막고 사람이 직접 호출할 때만 실행됩니다.

오해 2: fork는 그냥 브랜치 분기와 같다

현실: Claude Code 문맥에서 fork는 브랜치 이름만 바꾸는 수준이 아니라, 작업을 분리된 에이전트 맥락으로 보낸다는 의미가 더 큽니다. built-in /batch skill이 isolated git worktree를 쓰는 이유도 여기 있습니다. 맥락 충돌과 실수를 줄이기 위해 작업 공간 자체를 나누는 것입니다. context: fork 사용 시 agent 필드로 Explore, Plan, general-purpose 또는 커스텀 타입 중 하나를 지정할 수 있습니다.

오해 3: `CLAUDE.md`만 잘 쓰면 나머지는 필요 없다

현실: CLAUDE.md는 장기 규칙을 담는 곳이지, 모든 작업 절차를 다 넣는 곳이 아닙니다. 파일이 비대해지면 지침 준수율도 떨어집니다. 규칙은 CLAUDE.md, 반복 절차는 Skill, 자동 검사는 Hook으로 분리해야 유지보수가 됩니다.

또한 CLAUDE.md는 사용자 개인(~/.claude/CLAUDE.md), 프로젝트(./CLAUDE.md 또는 ./.claude/CLAUDE.md), 조직(Managed policy) 세 수준에서 각각 관리됩니다. 개인 지침은 모든 프로젝트에 공통 적용됩니다.

실제 활용 시나리오

시나리오 1: 코드 리뷰 준비 자동화

예를 들어 PR 전 점검을 매번 직접 지시하는 대신 review-ready skill로 만들 수 있습니다.

테스트 실행
lint 확인
변경 파일 요약
리뷰어가 봐야 할 위험 지점 정리

이렇게 하면 사람마다 다른 품질 기준이 아니라, 저장소가 가진 공통 기준으로 검토가 이뤄집니다.

시나리오 2: 대형 코드베이스 탐색과 구현 분리

대형 저장소에서는 하나의 세션에서 "분석도 하고 구현도 하고 검토도 하는" 방식이 금세 한계를 드러냅니다. 이때 탐색용 subagent, 구현용 subagent, 검토용 subagent를 분리하면 맥락 오염이 줄어듭니다.

시나리오 3: 조직 표준 고정

CLAUDE.md에는 다음과 같은 항목이 들어가야 합니다.

패키지 매니저와 실행 명령
테스트 필수 여부
금지 라이브러리
보안과 개인정보 처리 원칙
리뷰 시 반드시 확인할 항목

이 정보가 없으면 Skill이 있어도 팀 결과물의 일관성이 무너집니다.

Skills VS `CLAUDE.md` VS Hooks

비교 항목	Skills	`CLAUDE.md`	Hooks
목적	반복 업무 절차 재사용	지속 규칙과 맥락 유지	자동 검사·외부 동작 연결
형태	`SKILL.md` + 보조 파일	markdown 지침 파일	이벤트 기반 자동 실행
적합한 내용	배포, 리뷰, 문서 생성, 코드 설명	아키텍처 규칙, 보안 정책, 코딩 컨벤션	lint, 포맷, 로깅, 승인 체크
호출 방식	자동 또는 `/skill-name`	세션 시작 시 로드 (서브디렉토리는 지연 로드)	특정 생명주기에서 자동 실행
실수하기 쉬운 점	범위를 너무 크게 잡음	모든 절차를 다 넣어 비대해짐	실패 시 원인 추적이 어려움

선택 기준: 원칙은 CLAUDE.md, 반복 절차는 Skill, 반드시 실행되어야 할 기계적 검사는 Hook으로 두면 됩니다.

실전 예시

예시 1: `deploy-check` skill

이 Skill은 사람이 직접 호출하는 쪽이 안전합니다.

---
name: deploy-check
description: 배포 전 점검을 수행한다
disable-model-invocation: true
allowed-tools: Read, Grep, Bash
context: fork
---

1. 테스트를 실행한다
2. 환경 변수 변경 여부를 확인한다
3. 마이그레이션 여부를 점검한다
4. 배포 리스크를 3줄로 요약한다

핵심은 context: fork입니다. 배포 전 점검 같은 작업은 현재 세션 맥락과 분리된 쪽이 안전합니다.

예시 2: `explain-module` skill

공통 설명 패턴을 고정할 때 유용합니다.

먼저 비유로 설명
ASCII 다이어그램 포함
변경 시 주의점 3개 정리

이처럼 구성해두면 팀의 문서화 품질이 일정하게 유지됩니다.

예시 3: 프로젝트 `CLAUDE.md`

# Project Rules

- use pnpm
- run tests before proposing final changes
- never edit generated files by hand
- for database changes, explain rollback plan

짧고 명확해야 합니다. 공식 문서에서 권장하듯, 구체적인 문장이 좋은 지침입니다.

핵심 실행 요약

항목	실행 기준
도입 단위	프로젝트별 `CLAUDE.md` 1개와 Skill 2개부터 시작
입력 규칙	규칙은 짧고 명확하게, 절차는 순서형으로 작성
검증 체계	Hook으로 테스트·lint·로그를 자동 연결
품질 지표	같은 작업 재실행 시 결과 편차, 리뷰 지적 건수, 재작업률
확장 조건	Skill 사용 빈도가 높아지면 subagent와 MCP까지 확장

자주 묻는 질문(FAQ)

Q1. Claude Code를 팀에 도입할 때 가장 먼저 해야 할 일은 무엇인가요?

CLAUDE.md부터 정리해야 합니다. 패키지 매니저, 테스트 명령, 금지 규칙, 리뷰 기준이 없는 상태에서 Skill부터 만들면 자동화만 늘고 결과는 오히려 불안정해집니다.

Q2. 모든 Skill을 자동 호출되게 만들어도 되나요?

권장하지 않습니다. 배포, 삭제, 대규모 수정처럼 위험한 작업은 disable-model-invocation: true로 두고 사람이 직접 실행하는 편이 안전합니다.

Q3. fork/subagent는 언제부터 필요해지나요?

작업이 탐색·구현·검토로 나뉘기 시작할 때입니다. 저장소가 커지거나, 같은 세션에서 너무 많은 목적을 섞게 되면 분리 이점이 분명해집니다.

업데이트 기준

본문 기준 시점: 2026-03-30 (KST)
업데이트 주기: 월간
다음 예정 리뷰: 2026-04-30

Skills 관련 글

Claude Code 고급 패턴 입문: Skills, Fork, Subagents를 어떻게 연결할까