Claude Code 공식 문서에 복사해서 바로 쓰는 프롬프트 모음인 프롬프트 라이브러리가 있다. 이 글은 2026년 11월 2일 기준 한국어 페이지에 실린 카드 52개를 단계·역할·출처별로 세어 보고, 카드들이 공통으로 쓰는 작성 패턴 6가지와 페이지의 장단점을 정리한 것이다.
한눈에 보기
| 항목 | 내용 |
|---|---|
| 무엇인가 | Claude Code에 붙여넣는 프롬프트 카드 모음. 작업 단계와 역할 태그로 거른다 |
| 규모 | 카드 52개, 개발 단계 5개, 작업 분류 15개, 역할 태그 7개 |
| 카드 구성 | 프롬프트, 채울 칸(슬롯), "이것이 작동하는 이유", "기억하기", 출처 |
| 핵심 메시지 | 프롬프트는 대본이 아니라 시작점이다. 이유를 읽고 내 작업에 맞게 고친다 |
| 다음 단계 | 잘 되는 프롬프트는 스킬·CLAUDE.md·훅으로 옮겨 반복 가능하게 만든다 |
라이브러리를 쓰는 흐름은 위 그림과 같다. 카드를 고르고, 강조된 칸을 내 프로젝트 값으로 채워 보내고, 결과가 맞으면 다음부터는 같은 말을 다시 하지 않도록 기억시킨다. 페이지가 강조하는 것도 카드 자체보다 이 마지막 단계다.
카드 한 장에 들어 있는 것
카드는 다섯 부분으로 되어 있다.
- 프롬프트: 그대로 보내도 되는 한두 문장이다. 예를 들어 "커밋하기 전에 커밋되지 않은 변경 사항을 리뷰하고 위험해 보이는 부분을 알려 주세요".
- 슬롯:
{path},{feature},{test}처럼 강조된 칸이다. 52개 중 43개에 있고, 칸을 채우면 "입력하고 복사" 버튼으로 완성된 문장을 복사한다. - 붙여넣기 안내: 7개 카드는 먼저 자료를 넣으라고 한다. 목업·디자인·스크린샷 이미지, Terraform plan 출력, 빌드 오류, CSV 파일이다.
- 이것이 작동하는 이유: 이 문장이 왜 통하는지 한두 문장으로 설명한다. 패턴을 배우는 곳이다.
- 기억하기: 22개 카드에 있다. 같은 일을 반복하지 않게 하는 다음 단계(
/init으로 CLAUDE.md 만들기, 출력 스타일 설정 등)를 알려 준다.
페이지 맨 위에는 "먼저 시도할 다섯 가지 프롬프트"가 있다. 새 저장소 개요 받기, 동작으로 코드 위치 찾기, 실패한 테스트 고치기, 테스트 작성·실행·수정, 커밋 전 변경 검토 순서다. 처음 쓰는 사람이 읽기부터 검증까지 한 바퀴를 돌게 짜여 있다.
52개 카드는 어디에 몰려 있나
페이지의 카드 데이터를 단계별로 세면 다음과 같다.
| 단계 | 카드 수 | 대표 카드 |
|---|---|---|
| 발견 | 7 | 새로운 저장소에서 방향 잡기, 삭제하기 전에 무엇이 깨지는지 확인 |
| 디자인 | 6 | 인터뷰로 사양 작성, 목업을 작동하는 프로토타입으로 변환 |
| 구축 | 22 | 기존 패턴 따르기, 테스트에서 구현 주도, 잘못된 접근 방식 수정 |
| 배포 | 5 | 병합 충돌 해결, git 히스토리에서 릴리스 노트 작성 |
| 운영 | 12 | 프로덕션 인시던트 조사, 반복 작업을 스킬로 변환 |
구축이 22개로 전체의 40%를 넘는다. 역할 태그는 제품 12, 디자인 8, 마케팅 8, 문서 7, 온콜 7, 데이터 5, 보안 4개 카드에 붙어 있다. 개발자가 아닌 사람이 쓸 카드가 꽤 있다는 뜻이다. "저는 {role}입니다. 사용자가 {action} 때 UI부터 결과까지 어떤 일이 일어나는지 단계별로 설명해 주세요" 같은 카드는 기획자가 코드를 읽지 않고 코드베이스에 질문하게 해 준다.
출처는 일반적인 워크플로우 23, Anthropic 팀 사용 사례 13, 모범 사례 10, 에이전트 코딩 확장 가이드 3, 법률 2, 사이버보안 1개다. 모든 카드가 출처 문서로 연결되어 있어 배경을 따라 읽을 수 있다.
카드들이 공통으로 쓰는 6가지 패턴
페이지의 "이 프롬프트가 작동하는 이유" 섹션이 패턴을 직접 정리해 둔다. 이 여섯 가지가 라이브러리의 진짜 내용이다.
1. 단계가 아니라 결과를 말한다. "공개 API에 속도 제한을 추가하고 기존 테스트가 여전히 통과하는지 확인하십시오"처럼 원하는 상태만 말하고 파일은 Claude가 찾게 둔다. 파일 경로를 하나하나 짚으면 내가 놓친 파일은 계속 놓친다.
2. 스스로 확인할 방법을 준다. "마이그레이션을 작성하고, 개발 데이터베이스에 대해 실행하고, 스키마가 일치하는지 확인하십시오". 실행·테스트·비교를 같은 프롬프트에 넣으면 Claude가 한 번 시도하고 멈추지 않고 될 때까지 반복한다.
3. 참고할 대상을 가리킨다. "프로필 페이지와 동일한 레이아웃을 따르는 설정 페이지를 추가하십시오". 기존 파일이나 패턴을 지목하면 새 코드가 저장소의 기존 방식을 따른다.
4. 측정 가능한 목표를 준다. "번들 크기를 200KB 미만으로 줄이고 제거한 항목을 보여주십시오". 숫자와 기준이 있으면 언제 끝났는지가 분명해진다.
5. 자료를 직접 넣는다. 오류, 로그, 스크린샷, plan 출력을 붙여넣거나 @build.log처럼 @로 파일을 지목한다. 사람이 요약한 설명보다 원본이 정확하다.
6. 답의 형식을 정한다. "다이어그램이 있는 HTML 페이지로 설명한 후 브라우저에서 열어주십시오". 형식·길이·대상을 말하면 설명이 쓰임새에 맞는다. 매번 같은 형식을 원하면 출력 스타일로 기본값을 바꾼다.
조정(Steer) 카드가 눈에 띄는 이유
대부분의 프롬프트 모음은 첫 요청만 다룬다. 이 라이브러리에는 결과가 어긋났을 때 쓰는 "조정" 분류가 따로 있다.
- "그건 맞지 않습니다: {feedback}. 다른 접근 방식을 시도해 주세요"
- "너무 많이 변경했습니다. {scope}에 대한 변경만 유지하고 나머지 편집은 되돌려 주세요"
- "{mistake} 실수를 계속 반복하고 있습니다. 이런 일이 다시 없도록 CLAUDE.md에 규칙을 추가해 주세요"
세 번째가 특히 쓸모 있다. 같은 지적을 두 번 하고 있다면 대화에서 고칠 문제가 아니라 규칙으로 남길 문제라는 신호다. 실제로 이 블로그 저장소의 CLAUDE.md에는 "코드 변경은 npm run verify가 0으로 끝나야 완료"라는 규칙이 있다. 패턴 2(스스로 확인할 방법)를 매번 프롬프트에 쓰는 대신 규칙으로 고정해 둔 예다.
프롬프트를 기억으로 바꾸는 단계
페이지의 마지막 섹션은 카드 다음에 할 일을 말한다.
| 수단 | 언제 쓰나 | 없으면 생기는 일 |
|---|---|---|
| 스킬 | 같은 순서의 지시를 반복할 때. 팀원 누구나 /command로 실행 |
사람마다 프롬프트가 조금씩 달라 결과가 흔들린다 |
| CLAUDE.md | Claude가 배운 규칙을 매 세션에 들고 시작하게 할 때 | 세션마다 같은 실수를 다시 지적한다 |
| 훅 | 특정 사건 뒤에 매번 같은 동작을 강제할 때 | "잊지 말고 실행해"를 매번 써야 한다 |
| 계획 모드 | 크거나 위험한 변경 전에 수정할 파일 목록부터 볼 때 | 편집이 끝난 뒤에야 범위가 너무 컸다는 걸 안다 |
스킬로 만드는 기준과 구조는 Claude Code Skill 설계부터 자동 실행까지 실전 가이드에, 스킬·훅·MCP를 언제 고르는지는 MCP와 Skill, Hook의 차이 및 적용 기준에 정리해 두었다.
패턴을 적용해 고쳐 쓴 예
아래는 패턴을 연습하려고 만든 예시다. 처음 문장은 흔히 보내는 형태다.
메인 화면 말풍선 깨지는 거 고쳐줘
여섯 패턴을 대입하면 이렇게 바뀐다.
메인 페이지의 새 글 말풍선이 폭 375px 화면에서 오른쪽으로 잘린다. (결과·목표)
@screenshot.png 가 지금 상태다. (자료)
헤더 드롭다운 메뉴와 같은 위치 계산 방식을 따라 고쳐 줘. (참고 대상)
고친 뒤 375px와 1440px에서 스크린샷을 찍어 잘림이 없는지 비교하고, (자체 확인)
npm run verify 결과 줄을 붙여서 바꾼 파일 목록과 함께 보여 줘. (형식)
문장은 길어졌지만 Claude가 되물을 것이 없다. 끝났는지 판단하는 기준도 프롬프트 안에 들어 있다.
리뷰: 좋은 점과 아쉬운 점
| 구분 | 내용 |
|---|---|
| 좋은 점 | 카드마다 이유가 붙어 있어 복사로 끝나지 않고 패턴을 배운다 |
| 좋은 점 | 슬롯과 붙여넣기 안내 덕분에 무엇을 채워야 하는지가 분명하다 |
| 좋은 점 | 제품·디자인·마케팅·보안 역할 카드가 있어 개발자 밖으로 넓게 쓸 수 있다 |
| 좋은 점 | 조정 카드와 "기억하기"가 한 번 쓰고 끝나는 사용에서 반복 가능한 설정으로 이끈다 |
| 아쉬운 점 | 카드가 구축 단계(22개)에 몰려 있고 배포는 5개, 보안 역할 카드는 4개뿐이다 |
| 아쉬운 점 | 한국어 번역이 "~하십시오", "이들이 어디서 나왔는지"처럼 딱딱하다. 카드 속 프롬프트는 자연스러운 존댓말이라 본문과 말투가 다르다 |
| 아쉬운 점 | 에이전트가 읽는 마크다운판(prompt-library.md)에는 카드가 빠지고 패턴 설명만 남는다. 카드를 통째로 넘기려면 웹 페이지를 봐야 한다 |
| 아쉬운 점 | 카드는 한 번에 보내는 문장이라, 여러 단계를 이어 가는 긴 세션의 예는 다루지 않는다 |
자주 하는 실수
카드를 그대로 복사해서 보낸다. 슬롯을 채우지 않거나 예시 값(src/scheduler/queue.ts 같은 경로)을 그대로 두면 없는 파일을 찾느라 시간을 쓴다.
확인 방법을 빼고 보낸다. "테스트 작성"만 보내고 "실행하고 실패를 고쳐"를 빼면 한 번 쓴 코드로 끝난다. 확인 방법이 있어야 Claude가 한 번 시도하고 멈추지 않는다.
자료를 말로 요약한다. 오류 메시지를 "뭔가 타입 에러가 난다"로 줄이면 Claude는 원인을 추측한다. 원문을 붙이거나 @로 파일을 지목한다.
같은 지적을 대화에서만 반복한다. 두 번 이상 같은 교정을 했다면 CLAUDE.md 규칙이나 스킬로 옮겨야 다음 세션이 같은 실수를 하지 않는다.
큰 변경을 계획 없이 맡긴다. 여러 파일을 바꾸는 작업은 "변경할 파일을 나열하되 아직 편집하지 마세요" 카드나 계획 모드로 범위부터 확인한다.
점검표
- 프롬프트가 해야 할 단계가 아니라 원하는 결과를 말한다
- 실행·테스트·비교 중 하나 이상의 확인 방법이 들어 있다
- 따라야 할 기존 파일이나 패턴을 하나 이상 지목했다
- 성능·커버리지 작업에는 숫자 목표가 있다
- 오류·로그·스크린샷은 요약하지 않고 원문이나
@파일로 넣었다 - 답의 형식(표, HTML, 파일 목록 등)을 정했다
- 카드의 슬롯을 모두 내 프로젝트 값으로 바꿨다
- 여러 파일을 바꾸는 작업은 계획부터 받았다
- 두 번 반복한 교정은 CLAUDE.md나 스킬로 옮겼다
Claude Code 프롬프트 라이브러리는 문장을 빌려 쓰는 곳이라기보다 결과·검증·참고·목표·자료·형식이라는 여섯 패턴을 카드로 익히고, 잘 되는 프롬프트를 스킬과 CLAUDE.md로 옮기도록 이끄는 교재다.
댓글 0개
아직 댓글이 없습니다. 첫 댓글을 남겨보세요.