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

4.1 Cowork 시작 템플릿

세 파일만 있으면 Cowork 기본 틀은 잡힌다. 하나라도 비면 품질이 흔들린다.

about-me.md

# 나를 설명하는 배경

- 이름:
- 역할:
- 현재 집중 과제:
- 주요 책임:
- 잘하는 것:
- 맡기고 싶은 것:
- 절대 원하지 않는 것:
- 자주 쓰는 표현:
- 싫어하는 표현:
- 참고할 내 글/자료:

about-me.md는 자기소개서가 아니라 배경 파일이다. 누구를 돕고, 뭘 중요하게 여기고, 뭘 싫어하는지 짧게 적는다.

working-rules.md

# 작업 규칙

- 애매하면 먼저 질문할 것
- 파일 삭제 전 반드시 승인 받을 것
- 출력은 기본적으로 markdown 또는 docx
- 파일명 규칙: YYYY-MM-DD-topic-v1.ext
- 초안에는 항상 불확실성을 명시할 것

작업 태도를 고정하는 파일이다. 질문 기준, 삭제 기준, 파일명 규칙, 불확실성 표기가 없으면 결과물이 팀 방식에서 쉽게 벗어난다.

보안 규칙도 한두 줄 더한다.

project-brief.md

# 프로젝트 브리프
## 목표
## 독자
## 성공 기준
## 입력 자료
## 제약 조건
## 반드시 포함할 것
## 피해야 할 것

목표, 독자, 성공 기준, 입력 자료, 금지 조건을 대화창 밖으로 빼내는 파일이다. 매번 길게 다시 쓰지 않아도 되고 재사용이 쉽다.

4.2 Claude Code 시작 템플릿

Claude Code 쪽은 권한과 검증이 먼저다. 파일 수정과 명령 실행이 같이 오기 때문이다.

최소 CLAUDE.md

# 프로젝트 작업 계약서
## 명령
- install:
- dev:
- test:
- lint:
- build:

## 경계
- api:
- domain:
- ui:

## 안전 규칙
- never edit:
- always run:
- ask before:

## 검증
- unit:
- integration:
- visual:

일부러 짧다. 명령 몇 줄, 경계 몇 줄, 금지 규칙 몇 줄이면 기본 계약은 성립한다. 분량보다 이 저장소에서 절대 놓치면 안 되는 기준을 먼저 적는 게 중요하다.

최소 .claude/settings.json

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

최신 settings 문서 기준 권한 규칙은 deny → ask → allow 순으로 평가되고 첫 매칭이 적용된다. Read(./.env) 같은 규칙은 파일 도구 접근 차단에 효과적이지만, 그것만으로 전체 실행 환경 경계가 끝나진 않는다. 실제 민감 정보 차단은 권한 규칙, 허용된 Bash 범위, 격리 실행 환경(sandbox) 정책을 같이 봐야 한다.

최소 hooks 예시

하네스 엔지니어링이 추상적으로 느껴진다면 작은 자동 개입 규칙(hook) 하나부터 시작한다.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit",
        "hooks": [
          {
            "type": "command",
            "command": "pnpm lint"
          }
        ]
      }
    ]
  }
}

편집 뒤 pnpm lint를 자동으로 돌린다. 작아 보여도 실무에서 큰 차이를 만든다. 2026년 3월 기준 공식 hooks 문서는 명령 기반, 프롬프트 기반, 에이전트 기반, HTTP hook까지 다룬다. 셸 명령은 가장 쉬운 출발점이다.

최소 review rule

---
paths:
  - "src/**/*.ts"
---

# 타입스크립트 규칙
- avoid unused imports
- keep functions small
- add tests for behavior changes

세부 규칙 파일(rule file)은 팀의 암묵지를 밖으로 꺼내는 문서다. 자주 틀리는 기준이 적혀 있으면 리뷰 품질이 사람마다 크게 흔들리지 않는다.

4.3 실전 프롬프트 템플릿

Context-first 템플릿

먼저 이 프로젝트의 `CLAUDE.md`, 관련 rules, 그리고 내가 지정한 폴더를 읽어.
그 다음 작업을 시작하기 전에 누락된 전제가 있으면 짧게 질문해.
바로 구현하지 말고, 수정 범위와 완료 기준부터 요약해.

채워 넣은 예시.

먼저 `CLAUDE.md`, `.claude/rules/testing.md`,
`src/features/signup/`를 읽어.
그 다음 작업을 시작하기 전에 누락된 전제가 있으면 3개 이하로 질문해.
바로 구현하지 말고, 수정 범위와 완료 기준부터 요약해.
완료 기준은:
- 빈 값 제출이 막혀야 하고
- 기존 정상 제출은 유지되어야 하며
- `pnpm test -- signup`이 통과해야 한다.

"고쳐라"에서 끝나지 않고 읽을 문맥과 완료 기준이 같이 들어 있다.

Cowork 조사 브리프

이 폴더의 파일을 먼저 읽어.
그 다음 [주제]를 [성공 기준]에 맞게 조사해.
최근 자료를 우선하고, 출처 충돌과 불확실성은 분리 표시해.
가능하면 AskUserQuestion으로 빈칸부터 메워.
산출물은 `outputs/`에 저장해.

채워 넣은 예시.

이 폴더의 파일을 먼저 읽어.
그 다음 "AI 슬라이드 제작 도구 비교"를 "대표가 5분 안에 방향을 결정할 수 있을 정도로
핵심 차이만 보이는 브리프" 기준에 맞게 조사해.
최근 30일 자료를 우선하고, 가격 정보와 기능 정보가 충돌하면 분리 표시해.
가능하면 AskUserQuestion으로 대상 독자와 발표 맥락부터 메워.
산출물은 `outputs/ai-slide-tools-brief.md`에 저장해.

Claude Code 버그 수정

이 오류를 바로 고치지 말고 먼저 재현 경로와 원인 가설을 정리해.
관련 파일을 좁힌 뒤 수정 범위와 테스트 계획을 제안해.
그 다음 승인 후 구현하고, 회귀 테스트까지 돌려.

채워 넣은 예시.

이 오류를 바로 고치지 말고 먼저 재현 경로와 원인 가설을 정리해.
범위는 `src/features/signup/`와 `tests/signup.test.ts`로 우선 좁혀.
수정 전에 다음 네 가지를 먼저 제안해:
1. 재현 방법
2. 원인 가설
3. 바꿀 파일
4. 실행할 테스트
그 다음 승인 후 구현하고, `pnpm test -- signup`과 `pnpm lint` 결과를 남겨.

"어디를 먼저 보라"와 "무엇이 끝인가"를 같이 준다.

리뷰 템플릿

현재 변경분을 correctness, regression risk, missing tests, security risk 기준으로 검토해.
중요도 순서대로만 말해.
문체보다 동작 문제를 우선해.
각 항목은 아래 형식으로 정리해.
- 문제 요약
- 왜 문제인지
- 어느 파일을 봐야 하는지
- 지금 당장 필요한 수정 또는 테스트

출력 형식을 같이 주면 훨씬 덜 산만해진다.

계약형 프롬프트

한 번에 여러 조건을 줄 때는 층을 나눈다. 길게 쓰는 게 목적이 아니라 목표·문맥·형식이 섞이지 않게 하는 게 목적이다.

<goal>
무엇을 만들고 싶은가
</goal>
<context>
먼저 읽어야 할 파일이나 자료
</context>
<constraints>
포함할 것, 피할 것, 길이 제한
</constraints>
<output_format>
표 / prose / JSON / 체크리스트 중 무엇인가
</output_format>
<done_when>
무엇을 보면 끝났다고 볼 수 있는가
</done_when>
<if_unsure>
불확실하면 질문할지, 모른다고 말할지
</if_unsure>

채워 넣은 예시.

<goal>
대표가 5분 안에 판단할 수 있는 경쟁사 브리프를 만든다.
</goal>
<context>
`projects/competitors/brief.md`,
`projects/competitors/source-notes.md`,
`templates/weekly-brief-template.md`를 먼저 읽어.
</context>
<constraints>
지난 7일 자료만 쓰고, 출처 충돌은 separate section으로 빼.
</constraints>
<output_format>
상단 표 1개, 그 아래 3문단 요약.
</output_format>
<done_when>
`outputs/weekly-brief.md`에 저장되고, 다음 액션이 3개 보인다.
</done_when>
<if_unsure>
근거가 부족하면 추정하지 말고 `확인 필요`로 남겨.
</if_unsure>

장문 문맥 분석

긴 보고서, 긴 로그, 긴 연구 노트를 읽힐 때는 자료를 위에, 질문을 아래에 둔다. 관련 인용을 먼저 뽑게 하면 환각이 준다.

아래 문서를 먼저 끝까지 읽어.
[문서 또는 파일]

바로 결론부터 내리지 말고 아래 순서로 진행해.
1. 관련 인용 5개를 먼저 뽑아
2. 그 인용을 바탕으로 핵심 변화 3개를 정리해
3. 확실하지 않은 부분은 separate section으로 빼
4. 마지막에 다음 액션 3개만 적어

채워 넣은 예시.

아래 문서를 먼저 끝까지 읽어.
`research/q1-market-report.md`

바로 결론부터 내리지 말고 아래 순서로 진행해.
1. 유럽 시장 변화와 직접 관련된 인용 5개를 먼저 뽑아
2. 그 인용을 바탕으로 핵심 변화 3개를 정리해
3. 확실하지 않은 부분은 `확인 필요`로 따로 빼
4. 마지막에 제품팀이 이번 주 바로 볼 액션 3개만 적어

JSON 출력 고정

자동화나 후처리가 붙을 땐 "설명 잘하기"보다 "형식 안 깨기"가 더 중요하다. 출력 스키마를 직접 적는다.

아래 형식의 JSON만 반환해.
설명 문장이나 서두는 쓰지 마.

{
  "title": "string",
  "summary": "string",
  "confidence": 0,
  "unknowns": ["string"],
  "sources": ["string"]
}

데이터가 부족하면 추정하지 말고 `unknowns`에 적어.

채워 넣은 예시.

아래 형식의 JSON만 반환해.
설명 문장이나 서두는 쓰지 마.
{
  "issue": "string",
  "root_cause": "string",
  "files_to_check": ["string"],
  "tests_to_run": ["string"],
  "confidence": 0
}

코드가 부족해서 판단이 어려우면 `root_cause`를 비우지 말고 `추가 확인 필요`로 적어.

프롬프트 / 컨텍스트 / 하네스 비교

같은 회원가입 버그를 예로 들면 세 층이 이렇게 나뉜다.

# 프롬프트
빈 값 제출 버그를 바로 고치지 말고, 먼저 재현 경로와 원인 가설을 정리해.

# 컨텍스트
`CLAUDE.md`, `.claude/rules/testing.md`,
`src/features/signup/`, `tests/signup.test.ts`를 먼저 읽어.

# 하네스
수정 뒤 `pnpm lint`와 `pnpm test -- signup`이 통과해야 한다.

셋을 한꺼번에 주면 결과가 훨씬 안정된다. 하나라도 빠지면 쉽게 흔들린다.

내 환경용 평가 루프

인터넷에서 본 좋은 프롬프트를 복사하는 것보다, 내 환경에서 같은 과제를 반복 측정하는 게 훨씬 빠르다. 작은 표 하나면 충분하다.

# 주간 에이전트 평가
## 과제 묶음
- bug-fix-a
- review-response-b
- report-draft-c
- setup-repro-d

## 지표
- 통과 비율(pass_rate)
- 사람 수정 횟수(human_edit_count)
- 총 소요 시간(total_minutes)
- 토큰 비용(token_cost)
- 대표 실패 유형(dominant_failure_mode)

## 메모
- 어떤 `CLAUDE.md` / 세부 규칙 파일 / hook 버전이 켜져 있었는가
- 어떤 skill이나 템플릿을 썼는가
- 지난주와 무엇이 달라졌는가

매주 같은 과제를 같은 기준으로 다시 본다. 프롬프트 문구보다 세부 규칙 파일, 검증 계획(Verification Plan), hook, 도구 계약(tool contract)을 바꿨을 때 통과 비율과 사람 수정량이 어떻게 바뀌는지를 봐야 최적점이 드러난다.

shortcut 방지용 구현 지시

코딩·자동화에서는 "만들어 줘"보다 "어떻게 만들면 안 되는가"를 같이 적는다.

이번 작업의 목표는 테스트 통과가 아니라 일반적으로 유지 가능한 구현을 만드는 것이야.

규칙:
1. 하드코딩이나 특수 경우 처리(special-case)로 테스트만 통과시키지 마.
2. 테스트가 잘못됐거나 요구사항이 모순되면 먼저 보고해.
3. 외부 코드, GitHub 예제, 다른 모델 결과를 가져오려면 먼저 이유를 설명해.
4. 직접 구현과 외부 참조를 구분해서 적어.
5. 수정 후에는 `Verification Plan(검증 계획)` 기준으로 무엇이 통과했고 무엇이 미확인인지 따로 적어.

모델이 결과만 맞추는 가장 싼 길로 흘러가지 않도록 성공 기준을 다시 잡는다.

Skill 제작 요청

스킬 자체를 Claude에게 만들게 할 때도 발동 조건과 결과 형식을 같이 준다.

`meeting-notes`라는 스킬을 만들어.
이 스킬은 사용자가 "회의록 만들어줘", "미팅 메모 정리해줘", "오늘 회의 요약해줘"라고 할 때 쓰이게 해.
결과 형식은 아래 순서를 따라야 해:
1. 제목
2. 날짜
3. 참여자
4. 핵심 논의
5. 결정사항
6. 액션 아이템(담당자, 기한 포함)
7. 다음 일정

정보가 없으면 추정하지 말고 `확인 필요`로 남기게 해.
가능하면 supporting file을 둘 수 있는 폴더 구조 예시도 같이 제안해.

스킬 이름, 발동 표현, 출력 형식, 금지 규칙을 한꺼번에 준다. 스킬 제작은 무슨 일을 할지보다 언제 불리고 무엇을 빠뜨리면 안 되는지가 더 중요하다.

4.4 세션 정리용 slash command 빠른 참고

오래 쓰면 프롬프트보다 세션 관리가 더 중요해진다. 아래 여섯 개만 익혀도 문맥 오염이 크게 준다.

막히면 쓰는 팁이 아니라 세션 운영 도구다. /clear, /compact, /context를 같이 익히면 오래된 로그와 이미 끝난 가설이 결과를 흐리는 문제를 줄일 수 있다.

4.5 공식 리소스 학습 경로

Release Notes는 무엇이 지금 가능한지를 가장 빠르게 갱신해 준다. Help Center는 Cowork, Skills, Connectors, 조직 관리, 앱 기능 같은 제품 표면을 이해하기 좋다. Claude Code Docs는 plugins, skills, channels, scheduled tasks, hooks, agent teams 같은 고급 기능을 체계적으로 보여 준다. API와 Agent SDK 문서는 직접 에이전트 애플리케이션을 만들거나 제품 내부로 Claude를 넣을 때 필요하다. GitHub 저장소는 실제 예시와 구조를 확인하는 데 유용하다.

4.6 추천 공식 읽기 순서

1. Release Notes

   현재 가능한 기능 범위를 업데이트한다

2. 기초 정의

   "What are Skills?"와 "Use Skills in Claude"로 개념 고정

3. Claude Code docs

   settings → skills → plugins → MCP → hooks → scheduled tasks → remote control → channels → agent teams 순

4. Anthropic PDF

   "How Anthropic teams use Claude Code", "Complete Guide to Building Skills"로 실제 운영 문맥 확인

4.7 Skill / Plugin / MCP 탐색 사이트

탐색 사이트는 많아도 설치 기준은 엄격해야 한다.

이걸 같이 보지 않으면 "좋아 보여서 저장해 둔 도구"만 늘고 실제 운영 자산은 남지 않는다.

4.8 학습 자료를 읽는 법

같은 "자료"처럼 보여도 역할이 다르다.

순서도 중요하다. 공식 문서로 기능의 존재와 범위를 확인하고, 커뮤니티 글로 이 기능이 어디에 꽂히는지 읽고, 저장소나 예제로 손을 움직인다.

AI 도구는 기능이 빨리 바뀐다. 무엇이 바뀌었는지 먼저 읽고, 어디까지가 공식 경계인지 다시 확인한다. 이 읽기 습관이 있어야 책을 다 읽고도 스스로 업데이트할 수 있다.

4.9 출판형 편집 체크리스트

얼핏 사소한 마감 항목처럼 보이지만 책 전체 성격을 지키는 안전장치다.

좋은 책도 결국 좋은 운영처럼 반복 가능한 검수 기준 위에서만 꾸준히 좋아진다.

4.10 조직 도입 체크리스트

목록처럼 보이지만 실제로는 책임 배분도다.

도입이 잘되느냐는 기능을 많이 켰느냐보다 누가 무엇을 어디까지 책임지는 구조를 만들었느냐에 크게 좌우된다.

4.11 용어집

비슷한 단어가 많을수록 같은 층의 개념으로 오해하기 쉽다. 역할 차이가 드러나도록 짧게 정리했다.

Agent (작업 에이전트) 작업을 수행하는 Claude 인스턴스. 문맥과 도구를 바탕으로 행동한다.

Agent Team (여러 에이전트 협업 구조) 여러 Claude Code 세션을 팀처럼 운영하는 실험 기능.

AskUserQuestion (질문 수집 도구) Anthropic 계열 제품에서 부족한 입력을 짧은 질문으로 다시 모으는 도구/패턴. 처음부터 완성된 지시문을 쓰지 못해도, 실행 전에 필요한 정보를 단계적으로 채운다.

Channel (외부 이벤트 통로) 외부 이벤트를 실행 중인 세션으로 푸시하는 경로.

CLAUDE.md 항상 로드되는 협업 계약서 성격의 지침 파일.

Connector (서비스 연결 표면) Claude 앱에서 외부 서비스를 연결하는 사용자 친화적 통합 개념.

Context Engineering (문맥 설계) Claude가 읽고 유지하는 문맥 전체를 설계하는 일.

Cowork (파일 기반 위임 작업면) 지식업무 중심의 로컬 작업 위임 인터페이스. 2026년 3월 기준 paid plan 대상의 desktop 중심 preview로 읽는 편이 안전하다.

Harness Engineering (실행 환경 설계) Claude가 돌아가는 실행 환경 전체를 설계하는 일.

Hook (자동 개입 규칙) 특정 이벤트 전후에 코드를 실행해 행동을 제한하거나 후처리하는 장치.

MCP (외부 도구 연결 규격) Model Context Protocol. 외부 서비스/도구를 Claude에 연결하는 표준 인터페이스.

Plugin (역할 패키지) skills, agents, hooks, MCP, LSP 등을 묶는 배포 패키지. 예전의 custom commands 표면도 최신 구조에서는 skills 쪽으로 수렴한다. 특정 역할을 바로 일하게 만드는 설치형 환경 묶음이다.

Progressive Disclosure 필요한 정보만 필요할 때 로드하게 만드는 설계 원리.

Project 정적 배경 지식과 파일을 묶는 Claude의 작업 공간.

Remote Control (원격 이어받기) 이미 열린 로컬 세션을 원격에서 조향하는 기능. 새 원격 작업면이라기보다, 돌아가고 있는 데스크톱 작업을 이어서 보는 기능에 가깝다.

Scheduled Task (예약 실행 작업) 정해진 시간 또는 반복 주기로 프롬프트나 skill 호출을 실행하는 기능. Cowork는 데스크톱 앱이 열려 있고 컴퓨터가 깨어 있는 조건을 같이 확인해야 하고, Claude Code 쪽 scheduled task는 세션 스코프다.

Skill (반복 작업 절차) 특정 작업을 더 잘하도록 Claude에 가르치는 재사용형 워크플로 폴더.

Subagent (보조 작업 에이전트) 메인 세션이 특정 작업을 위임하는 독립 컨텍스트의 보조 에이전트.

4.12 자주 묻는 질문

Q. 비개발자도 Claude Code를 꼭 써야 하나?

반드시 그렇진 않다. 대부분의 비개발 실무자는 Cowork부터 시작하는 게 훨씬 빠르고 덜 위협적이다. 파일을 읽고 정리하고 보고서를 만들고 반복 업무를 예약하는 것만으로 업무 차이가 난다. 다만 장기적으로 Claude Code를 전혀 모르면 시스템 설계의 깊은 층을 남에게만 맡기게 된다. 조직 안에서 적어도 몇 명은 파일 구조, CLAUDE.md, rules, settings, hooks 같은 층을 이해해야 전체 작업 체계를 안정적으로 설계할 수 있다.

Q. Skill은 많을수록 좋은가?

아니다. Skill은 앱스토어 상품이 아니라 모델이 읽고 판단해야 하는 추가 설명서에 가깝다. 수가 많아지면 descriptor와 supporting rule만으로도 문맥 비용이 커지고, 어떤 skill을 쓸지 고르는 판단 자체가 흐려진다. 좋은 운영은 "많이 모으는 것"보다 "자주 쓰는 몇 개를 단단하게 다듬는 것"이다. 팀 전체가 매주 반복해서 쓰는 skill 몇 개만 잘 굴러도 효과가 더 크다.

Q. MCP는 많이 붙이는 게 좋은가?

아니다. MCP는 외부 도구 연결의 힘을 주지만 선택 비용과 문맥 비용도 올린다. "연결이 많으면 더 똑똑해질 것"이라는 기대는 자주 실망으로 끝난다. 프로젝트마다 실제 필요한 것만 켜고 나머지는 끈다. 비전공자 팀은 최소 연결로 시작해서 병목이 생길 때 하나씩 여는 편이 더 낫다.

Q. Prompt Engineering은 이제 중요하지 않은가?

여전히 중요하다. 다만 "프롬프트만 잘 쓰면 다 해결된다"는 시대는 지나갔다. 지금은 프롬프트가 좋아도 파일 구조, 템플릿, 규칙, 권한, 검증이 약하면 긴 작업에서 흔들린다. 반대로 구조가 잘 잡히면 프롬프트가 조금 짧아져도 품질이 유지된다. Prompt Engineering은 사라진 게 아니라, Context Engineering과 Harness Engineering 안으로 비중이 재배치되었다.

Q. 1M 토큰을 지원하면 그냥 많이 넣어도 괜찮은가?

그렇게 이해하면 초반에 더 빨리 흔들린다. 큰 컨텍스트는 가능성을 넓히지만, 긴 문맥을 잘 다루려면 구조가 더 중요하다. 공식 가이드도 자료를 구분해서 넣고, 질문 위치를 분명히 하고, 필요한 구간을 먼저 인용하게 만드는 long context 설계를 권한다. 실무에서는 "다 넣는다"보다 "무엇을 상시로 두고 무엇을 필요할 때만 부를까"를 먼저 정한다.

Q. 그럼 최적의 셋팅은 어떻게 찾는가?

직접 해 보는 게 가장 빠르다. 내 업무에서 자주 하는 작업 세 가지를 고르고, 범위를 좁힌 버전과 넓힌 버전, 강한 모델과 균형형 모델, 긴 세션과 handoff(인수인계 메모) 뒤 새 세션을 각각 비교한다. 어떤 조합이 빨랐는지, 사람 수정이 얼마나 줄었는지, 토큰과 시간이 얼마나 들었는지를 재 보면 내 환경 최적점이 보인다. 팁은 인터넷에서 배우되 최종 감각은 경험으로 잡힌다.

Q. OpenClaw와 같은 수준의 장기 에이전트를 만들 수 있나?

부분적으로 가능하다. Remote Control, Channels, Scheduled Tasks, Plugins, MCP, Handoff, 지속 세션을 조합하면 "계속 이어지고, 멀리서 조향되고, 일을 넘겨받는" 운영 경험을 상당 부분 비슷하게 만들 수 있다. 다만 제품 철학과 권한 모델은 다르다. Cowork의 예약 실행은 데스크톱 앱과 컴퓨터 상태에 기대고, Remote Control은 돌아가던 작업을 이어 조향하는 기능이지 완전한 모바일 독립 작업면은 아니다. 중요한 건 이름을 따라 하는 것이 아니라 장기 실행형 시스템이 왜 기억·권한·handoff·검증·원격 개입을 필요로 하는지를 이해하고 자기 작업 구조 안에 재구성하는 것이다.

Q. Cowork를 감사 로그가 남는 공식 기록 시스템처럼 써도 되나?

그렇게 읽으면 운영에서 무리가 생긴다.

Cowork는 초안 생성, 자료 정리, 저위험 분석 보조에는 강하지만 규제 대상 문서의 최종 기록과 승인 이력을 대신하는 시스템은 아니다. 감사 가능성이 필요하면 Git, 문서관리, 결재 기록, 별도 work log를 함께 둔다.

4.13 바로 복붙하는 스타터 카드

본문을 다 읽지 않아도 손을 움직여 볼 수 있는 카드 묶음이다. 설명을 오래 읽을수록 시작이 늦어진다. 여기서는 "상황, 파일, 첫 프롬프트, 끝나는 기준"만 짧게 준다.

카드 1. 비개발 실무자의 첫 주간 브리프

먼저 만들 파일

• ABOUT-ME/about-me.md
• ABOUT-ME/working-rules.md
• PROJECTS/weekly-brief/brief.md
• TEMPLATES/weekly-brief-template.md

첫 프롬프트

먼저 `ABOUT-ME/`, `PROJECTS/weekly-brief/brief.md`,
`TEMPLATES/weekly-brief-template.md`를 읽어.
이번 주 [시장/회사/경쟁사] 변화 3개를 대표용 브리프로 정리해.
추측은 별도 구간(separate section)으로 빼고,
최종 파일은 `CLAUDE-OUTPUTS/weekly-brief_v1.md`에 저장해.

끝나는 기준: 요약, 핵심 변화, 우리에게 중요한 점, 다음 액션이 모두 있어야 한다.

카드 2. 회의록에서 바로 PRD 초안으로

먼저 만들 파일

• PROJECTS/new-feature/meeting-notes.md
• PROJECTS/new-feature/open-questions.md
• TEMPLATES/prd-template.md

첫 프롬프트

먼저 `meeting-notes.md`, `open-questions.md`, `prd-template.md`를 읽어.
회의 내용을 바로 PRD 초안으로 옮기되,
확정된 요구사항과 아직 비어 있는 결정사항을 분리해.
애매한 것은 추정하지 말고 `질문 필요`로 남겨.
산출물은 `PROJECTS/new-feature/prd-v1.md`에 저장해.

끝나는 기준: 목표, 사용자 문제, 범위, 비범위, 미해결 질문(open questions)이 각각 분리되어 있어야 한다.

카드 3. 초보 개발자의 안전한 버그 수정

먼저 만들 파일

• CLAUDE.md
• .claude/settings.json
• plan.md
• handoff.md

첫 프롬프트

먼저 `CLAUDE.md`, 관련 테스트 파일, 버그가 난 폴더를 읽어.
바로 고치지 말고 `plan.md`에
1. 재현 경로
2. 원인 가설
3. 수정 범위
4. 테스트 계획
을 먼저 적어.
승인 후 구현하고,
마지막에는 `handoff.md`에 바뀐 점과 남은 위험을 적어.

끝나는 기준: 코드 수정과 테스트 결과, 남은 위험이 각각 분리되어 있어야 한다.

카드 4. 연구자의 논문 읽기에서 재현 계획까지

먼저 만들 파일

• papers/claim-table.md
• papers/disagreement-table.md
• experiments/reproduction-plan.md
• experiments/run-log.md

첫 프롬프트

이 논문을 요약에서 끝내지 말고,
`claim-table.md`에는 주장과 근거를,
`disagreement-table.md`에는 애매하거나 충돌하는 지점을,
`reproduction-plan.md`에는 지금 환경에서 바로 검증할 최소 실험을 적어.
불확실한 수치는 추정하지 말고 원문 기준으로 남겨.

끝나는 기준: "좋은 논문이었다"가 아니라 "이번 주 바로 돌릴 최소 실험"이 나와야 한다.

카드 5. 에이전트 팀 충돌 줄이기

먼저 만들 파일

• plan.md
• decision-log.md
• implementation-notes.md
• review-findings.md
• handoff.md

첫 프롬프트

planner(계획 담당), builder(구현 담당), reviewer(검토 담당) 세 역할로 나눠 진행해.
planner는 `plan.md`에 acceptance criteria(완료 기준)와 위험을 적고,
builder는 승인된 범위만 구현하며 `implementation-notes.md`를 갱신하고,
reviewer는 `review-findings.md`에 correctness(정확성)와 regression risk(회귀 위험)만 적어.

새 결정을 내리면 모두 `decision-log.md`에 남기고,
마지막에는 `handoff.md`로 다음 세션이 바로 이어받게 해.

끝나는 기준: 에이전트 답변이 많아도 공용 파일이 안 바뀌면 실패다.

카드 6. 파일명 짓기 규칙

좋은 파일명은 "나중의 나"와 "다음 세션의 Claude"가 둘 다 바로 이해할 수 있어야 한다.

파일명은 개발자 취향이 아니라 작업 흐름의 표지판이다. 날짜, 주제, 버전이 보이면 사람도 Claude도 덜 헤맨다.

4.14 이 책 다음 증보판에서 확장할 파트

증보 방향은 기능을 더 많이 나열하는 쪽이 아니라, 더 많은 상황과 화면과 운영 구조를 풀어 주는 쪽이다.

4.15 장 끝 참고 출처

앞 장들의 공통 내용을 템플릿과 용어 중심으로 다시 정리한 부록이다. 세부 인용은 각 장의 참고 출처를 따른다. 실전 시작점으로 쓰고 싶다면, 본문에서 자신에게 가장 가까운 장을 하나 골라 읽고 돌아오는 편이 좋다. 부록은 정답이 아니라 본문에서 이해한 구조를 손에 잡히는 파일과 규칙으로 바꾸게 해 주는 연결부다.

3부

구조를 깊게 이해한다. 문맥, 하네스, 확장을 설계한다.