Table of contents
- 패러다임이 한 칸 옮겨갔다
- 1. Skills — 지식을 외장한다
- 2. Sub-agent — 사람을 늘린다
- 3. Routines와 /loop — 시간을 늘린다
- 4. Hooks — 손을 줄인다
- 5. Cowork와 Design — 영역을 넓힌다
- 다섯 축을 같이 묶으면
- 참고 자료
패러다임이 한 칸 옮겨갔다
2026년 봄을 기준으로, GitHub 공개 커밋의 약 4%가 Claude Code로 작성된다. 포춘 10대 기업 중 8곳이 Claude를 도입했고, 딜로이트는 47만 명 직원에게 일괄 배포했다. 숫자만 보면 “AI 코딩 도구가 널리 쓰인다” 정도의 흔한 이야기다.
흥미로운 건 사람들의 사용 방식이 달라지고 있다는 점이다. 처음 Claude Code를 만지면 누구나 똑같이 쓴다. 채팅창에 요청을 던지고, 결과를 받고, 적당히 다듬는다. 도구로서의 Claude다. 그런데 몇 주만 지나면 슬슬 다른 차원이 보이기 시작한다.
자기만의 SKILL.md를 깔아두는 사람이 생기고, 한 화면에서 서브에이전트 다섯 개를 동시에 굴리는 사람이 생기고, 새벽에 자는 동안 PR을 모니터링하도록 루틴을 걸어두는 사람이 생긴다. 단발 프롬프트가 아니라, Claude를 자기 작업 환경에 영구히 박아 넣는 방식이다. 도구를 “쓰는” 게 아니라 “운영”한다.
이 글은 그 흐름의 구체적인 모양을 정리한다. 검색해보면 따로따로 떠다니는 다섯 가지 패턴 — Skills, Sub-agent, Routines, Hooks, Cowork/Design — 을 한 축으로 묶었다. 각 패턴의 출처는 본문 끝에 모두 달았다.
flowchart LR
classDef axis fill:#4a90d9,color:#fff,stroke:#2c5d8f
classDef root fill:#5ca45c,color:#fff,stroke:#3d7740
C[Claude]:::root
S[Skills<br/>지식의 외장화]:::axis
A[Sub-agent<br/>인력의 병렬화]:::axis
R[Routines / loop<br/>시간의 자동화]:::axis
H[Hooks<br/>이벤트의 자동화]:::axis
X[Cowork / Design<br/>영역의 확장]:::axis
C --> S
C --> A
C --> R
C --> H
C --> X
다섯 축을 한 줄로 요약하면 이렇다. Skills는 지식을 외장한다. Sub-agent는 사람을 늘린다. Routines는 시간을 늘린다. Hooks는 손을 줄인다. Cowork와 Design은 영역을 넓힌다. 도구의 능력을 키우는 다섯 가지 다른 방향이다.
1. Skills — 지식을 외장한다
스킬은 Claude가 “이런 종류의 일을 어떻게 처리해야 하는지” 한 번만 적어두면, 이후 비슷한 요청이 올 때마다 자동으로 펼쳐서 참고하는 매뉴얼이다. 형식은 SKILL.md 한 장으로 통일돼 있다. YAML frontmatter에 name과 description을 적고, 본문에 절차를 적는다.
---
name: react-component
description: 디자인 시스템 토큰을 따르는 React 컴포넌트를 만들 때 사용. ARIA, 키보드 네비게이션, 스토리북 스토리까지 함께 생성한다.
---
# React 컴포넌트 생성 절차
1. `src/styles/tokens.ts`의 토큰만 사용한다 (raw hex 금지)
2. 모든 인터랙티브 요소는 ARIA role과 키보드 핸들러를 갖는다
3. `Component.stories.tsx`에 default/disabled/loading 세 가지 상태를 만든다
4. props 타입은 export한다 (외부 합성 가능하도록)
별것 아닌 것 같지만, 핵심은 “한 번 정의, 매일 복리(Build Once, Compound Every Day)“라는 슬로건에 있다. 매번 프롬프트로 같은 규칙을 반복해서 알려주는 비용이 사라진다. 팀 전체가 공유하면 코드 컨벤션이 자동으로 강제된다.
2026년 3월 기준 커뮤니티 스킬 저장소(awesome-claude-code-skills류)에는 1,234개 이상의 스킬이 모였고 GitHub 스타는 22,000개를 넘었다. 인기 있는 것들은 패턴이 비슷하다.
| 스킬 종류 | 하는 일 |
|---|---|
code-review | 팀의 리뷰 체크리스트(네이밍, 보안 패턴, 테스트 커버리지) 강제 |
frontend-design | ”기본 AI 슬롭 디자인” 대신 디자인 방향을 명시적으로 잡고 진행 |
remotion-best-practices | Remotion 영상 코드 작성 시 애니메이션·오디오 규칙 준수 |
| 라이브러리별 스킬 | 사내 SDK, 디자인 시스템, 데이터 스키마 같은 도메인 지식 주입 |
스킬을 잘 쓰는 첫 신호는 “내가 같은 설명을 두 번 이상 했다”는 자각이다. 두 번째 설명할 때, 그 설명을 그대로 SKILL.md로 옮기면 된다.
2. Sub-agent — 사람을 늘린다
서브에이전트는 메인 세션과 분리된 컨텍스트를 가진 별도의 Claude 인스턴스다. 메인이 “오케스트레이터”가 되고, 서브들이 각자의 영역을 맡는다. 결과만 메인으로 돌려보낸다.
가장 흔한 활용은 병렬 코드 리뷰다. 한 명의 리뷰어가 보안·성능·아키텍처·정확성을 다 보면 30분이 걸리는데, 네 명의 서브에이전트가 각각 한 영역씩 보고 메인이 합치면 10분으로 줄어든다는 사례가 자주 인용된다.
sequenceDiagram
participant User
participant Main as Main (orchestrator)
participant S as security-reviewer
participant P as performance-reviewer
participant A as architecture-reviewer
participant C as correctness-reviewer
User->>Main: /review (PR diff 첨부)
par 병렬 실행
Main->>S: diff 전달
Main->>P: diff 전달
Main->>A: diff 전달
Main->>C: diff 전달
end
S-->>Main: 보안 이슈 리포트
P-->>Main: 성능 이슈 리포트
A-->>Main: 아키텍처 이슈 리포트
C-->>Main: 정확성 이슈 리포트
Main->>User: 통합 리포트
설계 시 주의할 점이 두 가지 있다.
첫째, 출력 스키마를 미리 합의한다. 각 서브가 “심각도, 파일, 라인, 설명, 제안” 같은 동일 포맷으로 결과를 돌려보내야 메인이 합치는 비용이 낮다. 자유 형식으로 받아서 메인이 다시 정리하면 토큰 낭비가 크다.
둘째, 3~5명이 적정이다. 그 이상으로 늘리면 결과를 합치는 일이 새로운 병목이 된다. 이 숫자는 실무 가이드들에서 거의 합의돼 있다 — 사람 팀과 똑같다.
서브에이전트의 진짜 가치는 단순 속도가 아니라 컨텍스트 격리에 있다. 보안 리뷰어는 OWASP 체크리스트만 들고 들어가고, 성능 리뷰어는 N+1과 메모리 누수만 본다. 한 인스턴스가 모든 걸 보면 컨텍스트가 흐려져서 한쪽 시야가 약해진다. 사람을 늘린다는 표현이 정확하다.
3. Routines와 /loop — 시간을 늘린다
지금까지 Claude는 사용자가 입력해야 움직이는 도구였다. Routines는 그 전제를 깬다. 시간/이벤트/조건 기반으로 Claude를 스스로 깨운다. “크론잡을 밀어낸다”는 표현이 슬슬 나올 정도로, 자동화 도구의 무게중심이 옮겨가는 중이다.
세션 안에서 가볍게 쓸 때는 /loop로 충분하다.
/loop 5m /check-deploy
5분마다 /check-deploy 슬래시 커맨드를 실행한다. 간격을 생략하면 Claude가 직접 1분~1시간 사이의 지연을 동적으로 결정한다. 8분짜리 빌드를 기다리는 중이면 60초마다 깨어나서 캐시를 8번 무효화하는 게 아니라, “이건 시간 좀 걸리겠네”하고 270초 단위로 자기 페이스를 잡는다.
세션을 넘어 백그라운드로 돌리려면 Routines를 쓴다. 크론 표현식으로 등록하면 클라우드에서 알아서 실행된다.
0 9 * * 1-5 → 평일 오전 9시 PR 리뷰 큐 정리
*/30 * * * * → 30분마다 프로덕션 에러 로그 요약
0 18 * * 5 → 금요일 오후 6시 주간 통계 리포트 생성
쓸모 있는 적용 사례 몇 가지를 모아보면 이렇다.
- 장시간 작업 폴링: 30분 걸리는 빌드, 마이그레이션 진행 상황 확인
- PR 모니터링: 새 PR이 들어왔을 때 1차 리뷰 자동 수행
- 반복 리포트: 일일/주간 통계, 에러 트렌드, 사용 메트릭 요약
- 외부 신호 감시: API 응답 시간, 환율, 특정 키워드 등장 모니터링
핵심 차이는 Claude가 일하는 시간의 시제가 바뀐다는 점이다. 이전엔 “지금 내가 보고 있는 동안” 일했는데, 이제는 “내가 자는 동안에도” 일한다. 단, /loop는 세션 범위라 Claude Code를 닫으면 사라진다는 점은 알아두자. 진짜 백그라운드는 Routines다.
4. Hooks — 손을 줄인다
훅은 시간이 아니라 이벤트에 반응한다. Git의 pre-commit과 비슷하다. 특정 이벤트가 발생하면 미리 등록해둔 셸 명령을 자동으로 실행한다.
지원되는 대표적인 이벤트 시점은 다음과 같다.
| 이벤트 | 의미 |
|---|---|
PreToolUse | 툴 호출 직전 (편집/실행 전 검증) |
PostToolUse | 툴 호출 직후 (편집 후 자동 포맷, 테스트) |
Stop | 세션이 멈출 때 (자동 백업, 알림) |
UserPromptSubmit | 사용자가 프롬프트 제출할 때 (입력 가공) |
settings.json에 등록하는 형식이다.
{
"hooks": {
"PostToolUse": [
{
"matcher": "Edit|Write",
"hooks": [
{ "type": "command", "command": "pnpm prettier --write $CLAUDE_FILE_PATHS" }
]
}
]
}
}
Edit이나 Write가 끝날 때마다 prettier가 돌아간다. Claude에게 “포맷 잊지 마”라고 매번 말할 필요가 없다. 환경이 보장한다.
훅의 진짜 가치는 방어선 역할이다. AI 에이전트가 자율적으로 코드를 수정하기 시작하면, “이거는 절대 하지 말아라”가 프롬프트만으로 100% 보장되지 않는다. PreToolUse 훅에서 셸 명령으로 검증하면, 명시적인 파이프라인이 된다.
{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [
{ "type": "command", "command": "scripts/block-dangerous.sh" }
]
}
]
}
}
block-dangerous.sh가 rm -rf /나 git push --force 같은 위험 패턴을 탐지하면 비-제로 종료 코드로 막는다. Claude가 무슨 말을 듣고 그런 명령을 시도하든, 셸 레이어에서 차단된다. 신뢰를 모델에만 두지 않고 환경에도 두는 설계다.
5. Cowork와 Design — 영역을 넓힌다
마지막 축은 코딩 바깥이다. 2026년 1분기에 Anthropic이 두 개의 제품을 새로 밀었다.
Claude Cowork는 채팅보다 한 단계 위의 협업 환경이다. 기획 문서 작성, 요구사항 정리, 리서치 같은 비-코드 작업에 최적화돼 있다. 2월에 Windows판이 macOS와 동등한 기능으로 출시되면서 사용자층이 한 번 크게 늘었다.
흔히 보이는 워크플로우는 Cowork ↔ Code의 분업 구조다.
flowchart LR
PM[PM / 비개발자]
Dev[개발자]
Cowork[Claude Cowork<br/>PRD, 리서치]
Code[Claude Code<br/>구현]
Repo[(저장소)]
PM --> Cowork
Cowork -->|PRD 산출| Dev
Dev --> Code
Code --> Repo
PM이 Cowork로 PRD를 만들면, 개발자가 그 PRD를 그대로 Claude Code에 넘겨 구현에 들어간다. 이전 같으면 “기획 문서 → 회의 → 티켓 분해 → 개발”이던 흐름이 “Cowork 산출물 → Code”로 한 번에 이어진다.
Claude Design은 4월 17일에 정식 출시됐다. Claude Opus 4.7 기반으로, 텍스트 설명과 이미지 입력을 받아 편집 가능한 대화형 프로토타입으로 변환한다. 정적인 와이어프레임이 아니라 클릭하면 반응하는 프로토타입이라는 점이 차별점이다.
타깃이 명확하다. 디자이너 없이 PM·창업자가 빠르게 검증하고 싶을 때. 모든 디자이너의 자리를 대체한다는 게 아니라, “디자인 리소스가 부족한 팀이 0차 프로토타입을 그릴 때”가 핵심 사용처다. 실제로 Claude Design의 주된 구매층은 디자이너가 없는 초기 스타트업과 사이드 프로젝트라고 보고된다.
이 두 제품의 의미는 Claude가 더 이상 “코딩 보조”에 갇히지 않는다는 신호다. PM의 도구이기도 하고, 프로토타이퍼의 도구이기도 하다. 다섯 번째 축이 가장 새롭고 가장 불확실하지만, 가장 빨리 움직이는 영역이기도 하다.
다섯 축을 같이 묶으면
다섯 패턴은 따로 쓰지 않는다. 잘 쓰는 사람의 워크플로우는 보통 이렇게 엮인다.
- Skills로 자기 도메인 지식을 미리 주입한다 (지식)
- 작업이 들어오면 Sub-agent로 병렬 분해한다 (인력)
- 시간이 걸리는 부분은 Routines/loop로 백그라운드에 떨어뜨린다 (시간)
- 위험 행동은 Hooks로 환경에서 차단한다 (안전망)
- 코딩 바깥의 기획·디자인은 Cowork/Design으로 끌어온다 (영역)
이렇게 묶이면 Claude는 더 이상 “필요할 때 켜는 앱”이 아니다. 작업 환경에 박혀서 늘 돌아가는 운영 시스템이 된다. 켜져 있는지조차 의식하지 않는다.
물론 한계도 분명하다. Skills는 늘리다 보면 서로 충돌한다. 서브에이전트는 합치는 비용이 의외로 크다. Routines는 잘못 짜면 토큰을 새벽 내내 태운다. 훅은 너무 엄격하면 정상 작업까지 막힌다. Cowork와 Design은 아직 검증 데이터가 적다. 다섯 가지를 다 도입하라는 게 아니라, 내 작업의 어떤 축이 부족한지 보고 거기서 하나씩 시작하면 된다.
도구가 시스템이 되는 데 거창한 결심은 필요 없다. 같은 설명을 두 번 했을 때 SKILL.md를 만들기 시작하는 정도면 충분하다. 거기서부터 다섯 축이 자연스럽게 자란다.
참고 자료
- Claude Skills Complete Guide 2026: Build Once, Compound Every Day — VC Corner
- Top 10 Claude Code Skills Every Builder Should Know in 2026 — Composio
- Claude Code Agent Teams: How to Run Multiple AI Agents in Parallel — MindStudio
- Multi-Agent Orchestration: Running 10+ Claude Instances in Parallel — DEV Community
- 일정에 따라 프롬프트 실행하기 — Claude Code Docs
- Claude Design Released: How AI Design Agents Reshape Collaboration — Apiyi Blog
- What is Claude Routines — Apiyi Blog
- Everyone should be using Claude Code more — Lenny’s Newsletter




Loading comments...