3장. Cowork와 Claude Code 실전 플레이북

3.1 입문자를 위한 가장 현실적인 30분 온보딩

Anthropic 공식 문서는 Claude Code를 30초에 시작할 수 있다고 말한다. 설치는 맞다. 하지만 첫 체감은 설치 속도가 아니라 설치 직후 무엇을 읽히고 어디에 남길지에서 갈린다.

첫 30분의 목표는 기능 다 아는 것이 아니다. 읽을 자료, 저장 위치, 짧은 규칙 하나로 작은 일을 끝까지 굴려 보는 것.

Cowork 30분 온보딩

Cowork의 첫 30분은 설치보다 작업공간 세팅이다. 긴 프롬프트를 던지기 전에 전용 폴더부터 만들고 최소 자산을 넣는다. 빈 책상 위에 서류 쌓기 전에 서랍 이름표 붙이는 순서다.

1. 0–5분 · 전용 폴더 만들기

   CLAUDE-COWORK/ 아래 ABOUT-ME/, PROJECTS/, TEMPLATES/, CLAUDE-OUTPUTS/ 네 폴더를 만든다.

2. 5–10분 · 최소 파일 3개

   ABOUT-ME/about-me.md, ABOUT-ME/working-rules.md, PROJECTS/test-project/brief.md를 빈 파일로 먼저 둔다.

3. 10–15분 · 템플릿 하나

   TEMPLATES/weekly-brief-template.md에 "핵심 요약 / 주요 변화 / 우리에게 중요한 점 / 다음 행동" 네 섹션 구조를 적는다.

4. 15–20분 · 글로벌 지침

   매 작업 전 ABOUT-ME 먼저 읽기, 맞는 프로젝트 폴더 읽기, 결과물은 CLAUDE-OUTPUTS/에만 저장, 브리프가 비었으면 짧은 확인 질문부터.

5. 20–30분 · 작은 과제 하나

   아래 프롬프트 하나로 첫 과제를 돌린다.

먼저 ABOUT-ME/, PROJECTS/test-project/brief.md,
TEMPLATES/weekly-brief-template.md를 읽어.
이번 주 AI productivity 시장 변화 3개만 짧게 정리해.
불확실한 내용은 별도 구간으로 빼고,
산출물은 CLAUDE-OUTPUTS/test-project_weekly-brief_v1.md에 저장해.

같은 자료라도 출력 구조가 있느냐 없느냐에 따라 결과가 크게 다르다.

첫 2주, 역할별로 같이 켜 보면 좋은 기능

Cowork 첫 과제는 왜 "정리/브리프"가 좋은가

큰 자동화부터 맡기면 뭐가 잘못됐는지 구분이 어렵다. 반면 폴더 정리·회의록·리서치 브리프는 성공 기준이 명확하고, 파괴적이지 않고, context file 효과가 눈에 바로 보인다.

Claude Code 30분 온보딩

Claude Code의 첫 30분은 더 보수적으로 간다. 저장소를 열고 /init 또는 수동으로 CLAUDE.md를 만든 뒤, test / lint / build 명령을 먼저 정리한다. 그다음에야 작은 수정에 들어간다.

공구 집기 전에 작업대 옆 점검표부터 붙이는 순서다.

용어 메모:

첫날은 이 세 가지만 되면 충분하다.

• 어떤 파일을 건드릴지 안다
• 어떤 테스트·확인 명령을 돌릴지 안다
• 변경 뒤에 사람이 무엇을 다시 볼지 안다

이게 없으면 Claude Code는 "빠른 구현기"가 아니라 "빠른 혼란기"가 된다.

1. 0–5분 · 최소 CLAUDE.md

   프로젝트 설명, dev/test/lint 명령, .env* 수정 금지, 파일 삭제 전 확인 규칙을 적는다.

2. 5–10분 · 최소 권한 경계

   .claude/settings.json에 allow 목록(Read·Edit·Write·Glob·Grep·안전한 Bash)과 deny 목록(.env 읽기 차단)을 둔다.

3. 10–15분 · 작은 버그 하나 고르기

   버튼 비활성화, 빈 값 제출, 테스트 누락, 오타 정도면 충분하다.

4. 15–20분 · 바로 수정 금지, plan부터

   재현 경로 / 원인 가설 / 바꿀 파일 / 실행할 테스트를 먼저 짧게 정리시킨다.

5. 20–30분 · 구현 후 마무리 기준

   구현 뒤에는 pnpm test -- signup과 pnpm lint 결과를 남기고 바꾼 점을 5줄로 요약한다.

최소 CLAUDE.md 예시:

# Project Contract

## Commands
- dev: `pnpm dev`
- test: `pnpm test`
- lint: `pnpm lint`

## Safety
- never edit `.env*`
- ask before deleting files

최소 .claude/settings.json 예시:

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": ["Read", "Edit", "Write", "Glob", "Grep",
              "Bash(pnpm lint)", "Bash(pnpm test)"],
    "deny": ["Read(./.env)", "Read(./.env.*)"]
  }
}

4단계 plan 프롬프트 예시:

먼저 CLAUDE.md와 src/features/signup/, tests/signup.test.ts를 읽어.
빈 값 제출 버그를 바로 고치지 말고
1. 재현 경로
2. 원인 가설
3. 바꿀 파일
4. 실행할 테스트
를 먼저 짧게 정리해.

5단계 마무리 기준 프롬프트:

구현 뒤에는 pnpm test -- signup과 pnpm lint 결과를 남기고,
무엇을 바꿨는지 5줄 이내로 요약해.

첫 성공 과제는 화려할 필요 없다. Cowork면 폴더 정리·리서치 브리프·회의록, Claude Code면 작은 버그 수정·테스트 추가·문서 보완. 중요한 건 대단한 결과가 아니라 어떤 기준으로 믿고 어떤 기준에서 멈출지를 배우는 경험이다.

3.2 Cowork 운영법: 프롬프트보다 파일 구조가 먼저다

Cowork 사용자 글에서 반복되는 조언: 길게 쓰지 말고 폴더부터 설계해라. 추천 구조는 CLAUDE-COWORK/ 아래에 네 폴더를 두는 형태다. 보기 좋으라고 만든 게 아니라, 초기에 가장 자주 겪는 혼선을 막는 최소형이다.

특히 PROJECTS/와 TEMPLATES/를 분리하면 이번 내용과 항상 유지할 뼈대를 나누기 쉽다. 생성형 작업은 거의 항상 버전이 생기므로 client-a_weekly-brief_v1.md, client-a_weekly-brief_v2.md처럼 규칙적으로 남긴다.

초보자를 위한 가장 쉬운 시작법

처음에는 이 네 파일만 있으면 Cowork가 기본 맥락을 아는 작업면으로 바뀐다.

1. ABOUT-ME/about-me.md

   Claude가 어떤 사람을 대신해 일하는지 빠르게 이해하게 만드는 짧은 자기소개 파일.

2. ABOUT-ME/working-rules.md

   결과물 문체만큼 어떻게 행동하는지가 중요하다. 불명확하면 질문, 삭제 금지, 저장은 CLAUDE-OUTPUTS/ 고정.

3. TEMPLATES/weekly-brief-template.md

   구조가 고정되면 매번 "요약 먼저, 변화 정리, 액션"을 다시 설명 안 해도 된다.

4. PROJECTS/test-project/brief.md

   ABOUT-ME가 장기 배경이라면 이건 단기 과업 지시다.

ABOUT-ME/about-me.md 예시:

# About Me

- I run a small consulting business.
- My work is mostly strategy, research, and client communication.
- I prefer concise writing with clear recommendations.
- I dislike generic AI phrases and empty hype.

ABOUT-ME/working-rules.md 예시:

# Working Rules

- Ask questions first if the brief is incomplete.
- Never delete files without my approval.
- Save every output to `CLAUDE-OUTPUTS/`.
- If information is uncertain, mark it explicitly.

TEMPLATES/weekly-brief-template.md 예시:

# Weekly Brief

## Executive Summary
## Competitor Changes
## What Matters For Us
## Recommended Next Actions

PROJECTS/test-project/brief.md 예시:

# Brief

Create a weekly brief for 3 competitors in the AI productivity market.
Only include information from the last 7 days.
Save the result as markdown.

초보자가 가장 많이 헷갈리는 질문

3.3 Cowork 글로벌 지침 예시

# GLOBAL INSTRUCTIONS

Before every task:
- read ABOUT-ME first
- if a matching PROJECTS folder exists, read it before execution
- if a matching template exists, follow its structure

Output rules:
- create files only in CLAUDE-OUTPUTS
- never delete files without approval
- ask clarifying questions first when the brief is incomplete

이 지침은 Cowork를 반응형 챗봇이 아니라 작업 규율을 가진 비서처럼 움직이게 만든다.

이 구분이 없으면 매 과업마다 같은 설명을 반복하게 된다. 프롬프트는 길어지고, 정작 중요한 과업 내용은 묻힌다.

3.4 처음 시작하는 사람을 위한 Cowork 7일 세팅 로드맵

Cowork는 첫날에 완벽 세팅하는 도구가 아니다. 실제 업무를 하면서 규칙을 키워 가는 도구다.

3.5 Cowork에서 가장 먼저 자동화할 7가지

화려한 것보다 지저분한 폴더 정리가 비용 대비 효과를 빨리 확인하기 쉽다. 파일 분류, 리네이밍, 로그 생성만으로도 시간이 바로 줄어든다.

공통점: 구조가 고정되어 있고, 사람이 마지막 판단을 붙이면 되는 일. Cowork 자동화의 시작점은 전면 자동화가 아니라 반복적이고 검토 가능한 일을 먼저 줄이는 쪽이다.

바로 써 볼 수 있는 자동화 프롬프트 3개

1. 주간 경쟁사 브리프

   매주 월요일 오전 7시, 최근 7일치 변화만 모아 주간 브리프로 저장하는 반복 작업.

2. 아침 우선순위 정리

   매 평일 오전 8시, 오늘 캘린더와 어제 남은 액션을 합쳐 3줄 우선순위로 저장.

3. 미팅 후 후속 정리

   회의 직후 raw-notes를 읽어 합의 / 열린 질문 / 다음 액션 / 이메일 초안 네 가지로 정리.

1. 주간 경쟁사 브리프 프롬프트:

Every Monday at 7am, read PROJECTS/competitors/brief.md and
create a weekly brief.
Only include items from the last 7 days.
If sources conflict, mark them explicitly.
Save to CLAUDE-OUTPUTS/competitors_weekly-brief_YYYY-MM-DD.md.

2. 아침 우선순위 정리 프롬프트:

Every weekday at 8am, read today's calendar and yesterday's
unfinished action items.
Create a short morning brief with:
1. today's top 3 priorities
2. meetings that need prep
3. risks or overdue items
Save to CLAUDE-OUTPUTS/daily-priority_YYYY-MM-DD.md.

3. 미팅 후 후속 정리 프롬프트:

After each meeting, read the notes in PROJECTS/client-a/raw-notes.md.
Create a post-meeting draft with:
1. what was agreed
2. open questions
3. next actions with owner
4. suggested email draft
Save to CLAUDE-OUTPUTS/client-a_followup_v1.md.

앞 두 예시는 시간 기반 반복, 세 번째는 이벤트 기반 트리거에 더 잘 맞는다.

3.6 Claude Code 운영법: 작은 성공보다 좋은 가드레일이 중요하다

Claude Code는 잘 쓰면 강력하지만, 잘못 쓰면 "빠르게 망가뜨리는 도구"가 된다. 실무자의 체감 품질은 모델보다 가드레일에 더 크게 좌우된다.

필수 구성

처음 시작할 때 필요한 건 많지 않다.

여기에 worktree나 handoff 파일처럼 상태를 밖으로 꺼내는 장치가 하나만 있어도 긴 작업이 훨씬 덜 흔들린다.

왜 CLAUDE.md, rules, settings를 따로 두는가

세 파일은 비슷해 보여도 다루는 층이 다르다.

초보자 실수 1순위: 세 가지를 모두 CLAUDE.md 한 파일에 몰아넣는 것. 규칙도 흐려지고, 권한 경계도 약해지고, 읽히는 문맥도 무거워진다.

초보 개발자를 위한 최소 저장소 구조

repo/
├── CLAUDE.md
├── .claude/
│   ├── settings.json
│   ├── rules/
│   │    ├── api.md
│   │    └── testing.md
│   └── skills/
├── src/
├── tests/
└── docs/

팀 공유용과 개인 로컬용은 처음부터 분리한다. 팀 표준은 CLAUDE.md + .claude/settings.json, 개인 실험은 CLAUDE.local.md 또는 .claude/settings.local.json.

각 파일에 무엇을 넣는가

권장 기본 원칙

먼저 끝의 모습을 적는다. 바로 손대지 말고 계획부터 만든다. 큰 덩어리보다 작은 diff로 쪼갠다. 테스트·린트를 끝 기준에 포함한다. 구현과 리뷰는 가능하면 분리한다.

원칙이라기보다 재작업을 줄이기 위한 순서다.

왜 세팅이 생각보다 큰 차이를 만드는가

초보자는 품질 차이를 모델이나 프롬프트 재능에서만 찾는다. 공개 사례를 길게 보면, 일정 수준 이상부터는 세팅이 훨씬 큰 차이를 만든다.

차이는 "모델이 똑똑해서"가 아니라 사람이 매번 수동으로 메꾸던 틈을 환경이 대신 메워 주느냐다.

상태 표시줄, 허용 목록, bypassPermissions

가장 현실적인 순서:

1. allowlist로 반복 승인 피로 감소

   test/lint/build 등 안전한 명령만 미리 통과

2. project/local scope 분리

   개인 실험과 팀 표준을 구분

3. worktree 또는 백업 브랜치 분리

   큰 작업은 물리적으로 분리

4. 낮은 위험 프로토타입에서만 bypassPermissions 제한적으로

   넓은 권한 모드로 뛰기 전에 위 단계부터

비개발자에게 더 잘 먹히는 입력 방식

비개발자에게는 긴 기술 설명보다 스크린샷·에러 화면·레이아웃 참고 이미지가 훨씬 강한 입력이 된다. UI 버그라면 CSS 용어 억지로 쓰지 말고 스크린샷 붙이고 "어디가 어긋났는지 설명하고 고쳐라"가 낫다. 이미지가 마법이어서가 아니라, 말로 잘 설명 못 하는 시각 차이를 바로 문맥으로 넣을 수 있어서다.

서브에이전트와 worktree는 왜 같이 이야기되는가

한 세션이 조사·구현·리뷰·문서화까지 전부 하면 문맥이 무거워지고 판단이 흐려진다. **"병렬로 많이 돌린다"보다 "누가 무엇을 책임지는지 먼저 나눈다"**가 핵심이다.

왜 plan부터 쓰고 바로 수정하지 말아야 하는가

초보자는 속도에 끌려 바로 수정부터 시킨다. 큰 작업일수록 이 방식은 오히려 느리다.

공식 common workflows 문서 기준으로, 여러 파일을 함께 건드리는 구현·코드베이스를 먼저 읽어야 하는 조사형·방향 조정이 필요한 인터랙티브 작업은 Plan Mode가 더 잘 맞는다. 읽기 전용으로 탐색하면서 필요한 빈칸을 AskUserQuestion으로 채운 뒤 수정 계획으로 넘어간다.

3.7 처음 시작하는 사람을 위한 Claude Code 7일 세팅 로드맵

3.8 Claude Code에서 생산성이 올라가는 패턴

공개 자료와 공식 문서에서 반복되는 패턴:

왜 이 패턴들이 반복되는가

Claude Code 생산성은 결국 세 가지 병목과 싸우는 일이다.

plan 파일, handoff, recall, 병렬 세션, voice 입력은 각각 이 세 병목 중 하나 이상을 줄인다.

토큰 절약 습관

토큰 절약은 비용 문제만이 아니다. 문맥이 가벼워질수록 결과가 더 또렷해진다.

1. 파일과 범위를 먼저 지정

   "인증을 개선해 줘"보다 "이 파일의 이 함수만 고쳐 달라"가 더 싸고 더 정확하다.

2. 긴 로그는 핵심 줄만

   실패 원인 판단에 필요한 20줄과 전체 2,000줄은 결과 차이가 거의 없는데 비용은 다르다.

3. 한 세션에 서로 다른 일을 오래 쌓지 않기

   구현 끝났으면 handoff 남기고 새 세션으로. 누적 문맥 비용과 혼선을 같이 줄인다.

언제 새 세션으로 갈아타야 하나

3.9 "템플릿"의 역할: 둘 다 다르지만 둘 다 중요하다

템플릿이 없으면 Claude는 매번 0부터 구조를 상상한다. 그러면 사용자는 "왜 이번엔 다르게 나왔지"를 반복해서 묻게 된다. 템플릿은 창의성을 죽이는 게 아니라 반복 작업에서 구조적 잡음을 줄이는 장치다.

3.10 초보 개발자를 위한 Claude Code 루틴

세 작업 모두 다르게 보이지만 원칙은 같다: 범위를 잡고, 기준을 적고, 바꾸고, 검증한다.

버그 수정 루틴

먼저 CLAUDE.md와 관련 테스트 파일을 읽어.
이 에러를 바로 고치지 말고 아래 순서로 진행해.
1. 재현 경로
2. 원인 가설
3. 수정 후보 파일
4. 필요한 테스트
승인 후에만 구현하고, 마지막에 회귀 위험을 3줄로 요약해.

기능 추가 루틴

새 기능을 바로 구현하지 말고 먼저 acceptance criteria를 정리해.
관련 파일을 찾고, 어느 파일을 건드릴지 제안한 뒤,
1. 설계 요약
2. 수정 범위
3. 테스트 계획
을 먼저 보여 줘.
그 다음 구현하고 self review까지 해.

리팩터링 루틴

이 리팩터링의 목표는 동작 변경 없이 중복을 줄이는 것이다.
먼저 범위를 src/auth/로 제한하고,
현재 안전망이 되는 테스트를 확인해.
그 다음 중복 제거 계획을 제안하고,
구현 뒤에는 동작 변경 여부와 위험 지점을 따로 적어.

3.11 팀 리드용 Claude Code 도입 체크리스트

3.12 역할별 추천 패턴

3.13 비교: Claude Code vs Cowork vs Codex vs OpenClaw

OpenClaw가 드러낸 수요

OpenClaw가 중요한 건 신기한 기능이 많아서가 아니라, 사용자가 오래전부터 원한 수요를 한 덩어리로 드러냈기 때문이다.

Claude 생태계는 같은 수요를 목적별 표면으로 나눠 흡수하고 있다.

차이는 묶는 방식과 신뢰 경계에 있다. OpenClaw는 숙련 사용자가 자기 하드웨어·채널을 한 운영면으로 묶는 쪽, Anthropic은 로컬·원격·데스크톱·조직 설정을 분리해 각 표면마다 더 명시적 정책을 두는 쪽.

왜 Anthropic이 이 방향으로 확장하는가

표면은 계속 늘어나지만 실제로 누적되는 건 CLAUDE.md, 프로젝트 brief, 템플릿, plan.md, handoff.md, 출력 폴더 구조 같은 공통 지식 레이어다. 긴 경로 외우기보다 workspace, research, deck, handoff처럼 역할이 보이는 이름이 낫고, rules와 brief를 먼저 읽힌 뒤 일을 던지는 편이 안정적이다.

무엇을 기준으로 비교해야 하나

3.14 보안과 거버넌스: 실제로 중요한 것

보안은 나중 문제처럼 보이지만, 시작할 때 조금만 정해도 훨씬 덜 피곤해진다.

이 항목들은 사소해 보이지만 조직이 어디까지 Claude를 신뢰하고 어디서부터 사람 검토를 강제할지의 기본선이다. 반드시 문서로 남겨야 한다. 언제 사람 검토가 필요한지, 무엇이 고위험 작업인지, 어떤 도구는 누가 설치할 수 있는지, 어떤 로그·산출물을 보존할지. 적지 않으면 시간이 지날수록 모두가 다른 기준을 상상한다.

흔한 실패

3.15 개인 생산성을 팀 생산성으로 바꾸는 법

개인이 잘 쓰는 것과 팀이 잘 쓰는 것은 다르다. 팀은 다른 사람이 이어받을 수 있어야 하고, 결과가 누구 손에 가도 비슷한 품질을 내야 한다.

팀 전환 순서

1. 개인 규칙을 CLAUDE.md로 최소화

   공용 계약서로 올리기

2. path-specific rules로 분해

   경로별 세부 기준 분리

3. 효과적인 skill 3개 공용 배포

   가장 자주 쓰는 흐름부터

4. code-review / test hook 표준화

   품질 장치 공용화

5. 조직 수준 plugin·connector·channel 정책

   마지막에 정책 레이어

3.16 30/60/90일 도입 로드맵

3.17 역할별 스타터 번들

앞 장들을 읽고도 막히는 이유는 비슷하다. 내 상황에서 무엇을 먼저 만들고 무엇을 먼저 시켜야 하는지가 손에 안 잡히기 때문. 긴 설명 대신 직무별 시작 묶음을 바로 제시한다.

비개발 실무자 스타터 번들

정리 → 초안 → 전달 흐름이다. 회의록·주간 브리프·리서치 요약·파일 정리처럼 결과가 빨리 보이는 일.

먼저 ABOUT-ME/, PROJECTS/week-brief/brief.md,
TEMPLATES/weekly-brief-template.md를 읽어.
이번 주 [주제] 변화 3개를 대표가 3분 안에 이해할 수 있게 정리해.
불확실하거나 출처가 충돌하는 내용은 separate section으로 빼고,
산출물은 CLAUDE-OUTPUTS/week-brief_v1.md에 저장해.

초보 개발자 스타터 번들

새 기능 전체가 아니라 작은 버그·테스트 누락·문서 보완처럼 범위가 좁고 검증 가능한 일부터.

먼저 CLAUDE.md, .claude/rules/testing.md,
src/features/signup/, tests/signup.test.ts를 읽어.
버그를 바로 고치지 말고 plan.md에 아래 네 가지를 먼저 적어.
1. 재현 경로
2. 원인 가설
3. 수정 범위
4. 실행할 테스트
내 확인 뒤에만 구현하고,
마지막에는 handoff.md에 바뀐 점과 남은 위험을 5줄 이내로 남겨.

연구자 / 분석가 스타터 번들

"잘 요약해 준다"가 아니라 **"읽은 것을 실험과 재현 계획으로 바꿔 준다"**는 체감이 중요하다. 요약 하나가 아니라 주장 표·충돌 표·재현 계획으로 나눈다.

먼저 papers/와 experiments/ 폴더를 읽어.
이 논문을 요약에서 끝내지 말고 아래 순서로 정리해.
1. 핵심 주장
2. 실험 조건
3. 재현에 필요한 환경
4. 지금 우리 환경에서 바로 검증할 수 있는 최소 실험
claim-table.md, disagreement-table.md, reproduction-plan.md를
각각 업데이트해. 과장이 아니라 검증 가능한 주장만 남겨.

에이전트 팀 운영자 스타터 번들

에이전트 팀은 숫자가 아니라 프로토콜이 성능을 만든다. 에이전트를 많이 붙이는 것보다 같은 plan.md와 decision-log.md를 보게 하는 것이 먼저.

이번 작업은 세 역할로 나눠 진행해.
- planner: plan.md에 범위, acceptance criteria, 위험 요소를 먼저 적어
- builder: 승인된 범위만 구현하고 implementation-notes.md를 갱신해
- reviewer: review-findings.md에 correctness, regression risk,
  missing tests만 적어
모든 역할은 decision-log.md를 먼저 읽고, 새 결정을 내리면 거기에 남겨.
마지막에는 handoff.md에 다음 세션이 바로 이어받을 수 있게 상태를 정리해.

결국 무엇부터 시작해야 하는가

입문자·초보자·활용자·개발자·연구자를 나눠 말했지만 공통 구조는 같다.

1. 읽을 문맥을 밖에 빼 놓는다

   작업 시작 전 Claude가 어디를 봐야 하는지 명시

2. 결과를 저장할 파일을 먼저 정한다

   어디에 남길지 고정

3. 완료 기준을 눈에 보이는 문장으로 적는다

   모호한 "잘 해줘" 금지

4. 사람의 확인 지점을 미리 정한다

   어디서 멈추고 검토할지

3.18 국내 공개 자료에서 자주 보이는 Claude Code 운영 루틴

도구는 조금씩 다르게 쓰지만, 오래 버티는 운영 습관은 비슷하다.

1. plan을 먼저 고정하고 구현은 나중에

바로 고치기보다 plan.md나 짧은 작업 계획부터 잡는 흐름이 가장 자주 나왔다. 범위를 먼저 고정하면 Claude가 다른 파일까지 넓게 읽지 않고, 사람도 무엇을 검증할지 빨리 잡는다.

# Plan
- 재현 경로
- 원인 가설
- 수정 범위
- 실행할 테스트

2. 실수한 내용은 팀 공용 규칙으로 올린다

Claude가 같은 실수를 하면 그 자리에서 고치고 끝내지 않고 CLAUDE.md나 rules 파일에 짧게 남긴다. 다음 세션·다음 사람·다음 에이전트가 같은 실수를 덜 반복한다.

3. 반복 작업은 slash command나 skill로

몇 번만 반복해도 명령으로 올리는 습관. 테스트 실행·리뷰·lint·handoff 정리·브랜치 diff 읽기처럼 반복 구조가 분명한 작업은 긴 프롬프트를 치지 않는다.

/project:review
/project:fix-issue 123
/project:handoff

4. 검증 없는 자동화는 믿지 않는다

실무 개발자 영상일수록 "코드를 잘 썼다"보다 **"무엇으로 검증했나"**가 더 중요하게 나온다. 테스트·브라우저 확인·포맷 훅·타입 체크·리뷰 노트가 빠지면 아무리 그럴듯한 출력도 바로 믿지 않는다.

구현이 끝나면 아래 순서로 확인해.
1. 관련 테스트 실행
2. 실패한 테스트가 있으면 원인 요약
3. 바뀐 파일과 남은 위험을 handoff.md에 기록

5. bypass보다 allowlist가 먼저

빠른 데모에는 전체 허용이 편해 보여도, 팀이 같이 쓰기 시작하면 결국 허용 목록·훅·리뷰 규칙이 필요해진다.

1. 읽기·테스트 명령을 allowlist에

   자주 쓰는 안전 명령만 미리 허용

2. 포맷·타입 체크는 hook으로

   자동화로 빼기

3. 정말 위험한 명령은 deny로

   막아 두기

4. 남는 예외만 사람 승인

   최소 개입

6. 토큰은 모델보다 세션 경계와 MCP 절제로

토큰을 많이 쓰는 사용자 팁을 모아 보면 결국 모델 선택 하나보다 세션 운영이 더 크게 작동한다. 작업 끝나면 세션 정리, 큰 MCP는 상시로 많이 켜 두지 않기, 긴 로그는 핵심 줄만, 어려운 문제에만 더 강한 모델.

7. 병렬 세션은 역할 분리가 먼저

고급 사용자는 여러 세션을 동시에 띄우지만, 같은 파일을 동시에 건드리지 않는다. 보통 plan · implement · review · research처럼 역할을 나누고 plan.md, decision-log.md, handoff.md로 다시 합친다.

세션 수보다 공용 상태 파일이 먼저다.

이 루틴을 내 작업에 붙이는 순서

1. plan.md부터 만든다

   범위와 기준을 밖에 꺼내기

2. 같은 실수를 CLAUDE.md에 짧게 남긴다

   반복 실수 차단

3. 자주 쓰는 작업 하나를 command로

   반복 구조 자산화

4. 마지막에 테스트와 handoff

   검증과 인계

이 네 가지만 잡혀도 "가끔 잘 되는 세션"에서 "다시 돌려도 덜 흔들리는 워크플로우"로 넘어간다.

3.19 장 끝 참고 출처

장 실행 카드: 템플릿, 체크리스트, 학습 경로

앞 장에서 개념과 첫 사용 흐름을 봤다면 이제는 실제 파일을 만든다. 문서 초안·정리는 Cowork 템플릿으로, 코드 수정·검증은 Claude Code 템플릿으로. 중요한 건 템플릿을 많이 모으는 일이 아니라 지금 필요한 일 하나에 맞는 출발점을 만드는 것.

세일즈 제안서·재무 모델·감사 준비 문서처럼 형식이 반복되는 결과물일수록 템플릿 효과는 커진다. 읽을 자료·출력 형식·검증 기준만 먼저 고정해도 결과물의 흔들림이 크게 줄어든다.