프롬프트 카드 12종

이 부록은 액티전스 프롬프트 라이브러리의 카드 12종을 한 장씩 정리한 안내서입니다. 각 카드를 언제 쓰는지, 무엇을 준비해야 하는지, 무엇이 나오는지를 적었습니다. 카드 본문은 길고 자주 고쳐지므로 이 책에 싣지 않습니다. 복사해서 쓸 최신본은 actigence.ai/vibe-coding-prompts에서 받습니다.

카드 쓰는 법

카드는 Claude Code에 붙여 넣는 긴 지시문입니다. 본문은 영어로 쓰여 있습니다. 지시를 정확하게 전달하기 위한 선택이며, 읽는 사람이 이해해야 할 내용은 이 부록과 카드 설명란에 한국어로 있습니다. 결과 보고는 카드가 한국어로 하도록 지시하고 있어, 실행하면 한국어 보고를 받습니다.

사용 순서는 모든 카드에서 같습니다.

1. 작업 폴더에서 Claude Code를 엽니다(9장).
2. 카드 본문 전체를 복사해 첫 메시지에 붙여 넣습니다.
3. 카드 바로 아래에 이번 요청을 한두 문장으로 덧붙입니다. 카드의 "사용 예"가 그 문장의 견본입니다.
4. 카드가 요구하는 첨부물이 있으면 함께 둡니다. 예를 들어 PRD(제품 요구사항 문서) 파일이 필요한 카드가 있습니다.
5. 결과를 받으면 19장의 검수 절차로 확인합니다.

주의할 점이 세 가지 있습니다.

• 카드는 통째로 붙여 넣습니다. 일부만 잘라 쓰면 안전장치와 검증 단계가 빠집니다.
• 카드마다 자율 실행의 범위가 다릅니다. 배포까지 확인 없이 진행하는 카드가 있으니, 실행 전에 카드 설명과 이 부록의 "주의"를 읽습니다. 배포 단계가 있는 카드는 연결된 호스팅 계정에 실제로 올라간다는 뜻입니다(20장).
• 카드 안의 모델 이름과 세부 절차는 시간이 지나며 바뀝니다. 이 부록은 카드의 목적과 입출력만 다루므로, 세부 변경과 관계없이 유효합니다.

카드는 크게 네 묶음입니다. 새 프로젝트를 시작하는 카드, 기능을 만드는 카드, 품질을 점검하고 고치는 카드, 디자인과 시각화 카드입니다. 아래 순서는 이 묶음을 따릅니다.

프로젝트 시작

원클릭 풀스택 (setup-fullstack-prototype)

• 언제 쓰는가 — 빈 폴더에서 시작해 배포된 시제품까지 한 세션에 끝내고 싶을 때. 화면 전체를 로그인 없이 눌러볼 수 있는 데모 빌드가 목표입니다.
• 준비물 — PRD 파일 한 개. PRD가 없으면 카드는 한 번 멈추고 요청합니다. PRD는 부록 B의 prd-vibecoding 스킬로 만들 수 있습니다. 데이터 저장소는 구글 시트가 기본이므로 구글 계정과 클라우드 프로젝트 사용 권한이 필요합니다.
• 산출물 — 배포된 데모, 데이터를 담는 시트, 디자인 기준 문서, 단계별 통과 기록. 카드는 네 개의 관문(데모 기능 초안, 디자인 고도화, 보안 강화, 배포와 검증)을 차례로 통과합니다.
• 주의 — 확인 없이 배포까지 진행합니다. 처음에는 연습용 계정과 폴더에서 돌립니다. 계정과 키가 만들어지므로 결과물에 어떤 키가 남았는지 마지막에 점검합니다(20장).

자동 적용 (setup-seo-aeo-geo)

• 언제 쓰는가 — 이미 운영 중인 Next.js 사이트의 검색 노출을 한 번에 손볼 때. 전통 검색 최적화(SEO), AI 답변 엔진 노출(AEO), 생성형 엔진 노출(GEO)을 함께 다룹니다. 카드는 Next.js 사이트를 기준으로 쓰여 있습니다.
• 준비물 — 깃(Git) 저장소로 관리되는 사이트 코드, 변경 사항이 없는 깨끗한 작업 상태. 더러운 상태면 카드가 중단 보고를 냅니다.
• 산출물 — 별도 브랜치에 담긴 변경, 풀 리퀘스트(변경 제안서), 적용 전후 비교 기록. 기존 파일은 직접 고치지 않고 제안 사본으로 냅니다.
• 주의 — 색인 제거 신호(noindex, 다른 주소로의 canonical, 콘텐츠 차단 등)는 증거를 확인한 뒤 경로 단위로만 적용하도록 되어 있습니다. 결과가 나오면 검색 노출이 줄지 않았는지 반드시 직접 확인합니다.

개발 작업

기능 추가: 참고 분석 (dev-merged-3)

• 언제 쓰는가 — 새 기능을 만들기 전에 비슷한 서비스나 오픈소스를 살펴 가져올 것과 하지 않을 것을 추리고 싶을 때.
• 준비물 — 분석할 대상의 주소나 로컬 경로. 카드는 사용자가 준 출처만 분석하고 임의로 찾지 않습니다.
• 산출물 — 채택할 패턴, 버릴 패턴, 라이선스 점검 결과, 우리 프로젝트 구조에 맞게 옮긴 설계.
• 주의 — 코드를 그대로 복사하지 않고 구조와 패턴만 가져오도록 되어 있습니다. 라이선스가 맞지 않으면 그 출처는 제외하고 직접 구현안을 냅니다. 라이선스 판단은 최종적으로 사람이 확인합니다.

기능 추가: 풀스택 (dev-merged-4)

• 언제 쓰는가 — 기능 하나를 데이터 저장, 서버 처리, 화면, 테스트까지 한 번에 넣을 때.
• 준비물 — 기능 설명 한두 문단, 이미 있는 저장소. 새 프로젝트가 아니라 기존 프로젝트용입니다.
• 산출물 — 모든 계층의 변경, 되돌릴 수 있는 데이터 변경 파일, 입력 검증, 핵심 경로를 끝까지 따라가는 테스트 1건 이상.
• 주의 — 데이터 구조를 바꾸는 작업은 되돌리는 절차까지 실제로 실행해 확인하도록 되어 있습니다. 운영 데이터에 닿는 변경은 사전에 백업 여부를 확인합니다. 기능이 여러 개면 하나씩 따로 요청합니다.

기능 추가: 화면 (dev-6)

• 언제 쓰는가 — 화면과 컴포넌트, 상태 연결만 만들 때. 백엔드는 가짜 데이터로 두어도 됩니다.
• 준비물 — 만들 화면 설명, 기존 디자인 기준(있다면). 기준이 없으면 카드가 기존 코드에서 추론하고 가정을 기록합니다.
• 산출물 — 로딩, 빈 상태, 오류 세 가지 상태를 갖춘 화면, 접근성 점검, 화면 캡처를 근거로 한 독립 디자인 검토 결과.
• 주의 — 캡처로 확인된 것만 완료로 칩니다. 코드만 고치고 화면을 보지 않았다면 완료가 아닙니다.

품질과 디버깅

디버깅 (dev-merged-5)

• 언제 쓰는가 — 버그를 만났을 때. 가끔만 발생하거나 재현이 어려운 경우, 데이터가 이상한 경우도 포함합니다.
• 준비물 — 증상, 발생 조건, 오류 메시지나 화면 캡처. 가능하면 처음 발생한 시점.
• 산출물 — 근거로 확인된 원인, 수정, 수정 전에는 실패하고 후에는 통과하는 회귀 테스트, 재현 스크립트.
• 주의 — 원인이 증거로 확인되기 전에는 코드를 고치지 않는 것이 핵심 규칙입니다. 데이터가 틀린 경우 영향 범위를 실제 조회로 센 뒤 고치며, 수정 전에 되돌릴 지점을 만듭니다.

품질 파이프라인 (dev-quality-pipeline)

• 언제 쓰는가 — 기능을 만든 뒤 안정화하거나 오래된 코드를 정리할 때. 테스트 보강, 코드 리뷰, 정리를 이 순서로 진행합니다.
• 준비물 — 대상 범위(변경분, 모듈, 저장소 전체 중 하나). 테스트와 검사 명령은 카드가 저장소에서 찾습니다.
• 산출물 — 보강된 테스트, 리뷰 결과, 정리된 코드, 각 단계의 실행 결과.
• 주의 — 테스트 없는 코드는 정리하지 않고, 리뷰 전의 코드는 다듬지 않는다는 순서 규칙이 있습니다. 새 기능 추가는 이 카드의 일이 아닙니다.

추적 설계 (dev-tracking-vercel-ga4)

• 언제 쓰는가 — 사이트 운영을 시작하거나, 전환(가입, 신청, 결제)을 측정하지 못하는 기존 사이트에 추적을 붙일 때.
• 준비물 — 사이트 코드, 측정할 행동 목록, 분석 도구 계정. 호스팅이 Vercel이고 분석 도구가 GA4인 구성이 가장 자세히 정의되어 있고, 다른 구성은 같은 기능을 다른 방식으로 구현합니다.
• 산출물 — 이벤트 설계, 구현 코드, 중복 집계 점검, 데이터 품질 점검 방법.
• 주의 — 동의 관리와 개인정보 규정(한국 개인정보 보호법 등)이 설계에 포함됩니다. 어떤 정보를 수집하는지는 반드시 사람이 검토하고, 방침 문서와 일치시킵니다(13장, 부록 D).

디자인과 시각화

디자인 변경 (dev-13)

• 언제 쓰는가 — 기능 구현이 끝난 뒤 화면 하나나 컴포넌트 하나의 모양을 다듬을 때. 큰 구조 변경 없이 손질하는 용도입니다.
• 준비물 — 대상 화면, 기존 디자인 토큰(색과 글자 규칙을 모아둔 정의). 범위를 밝히지 않으면 카드가 가장 좁은 범위로 가정합니다.
• 산출물 — 범위 안의 변경, 변경 전후 캡처, 범위 밖에서 발견한 문제의 후속 목록.
• 주의 — 범위 밖 파일은 눈에 띄는 결함이 있어도 고치지 않고 목록에만 올립니다. 전면 개편은 이 카드가 아니라 아래 재설계 카드입니다.

디자인 감사와 개선 (dev-14)

• 언제 쓰는가 — 프로젝트 전체의 사용성을 점검하고 싶을 때. 검사 담당 다섯 갈래(현황, 일관성, 접근성, 상호작용, 흐름)가 동시에 점검합니다.
• 준비물 — 실행 가능한 프로젝트. 어떤 항목을 고칠지는 감사 보고서를 본 뒤 사용자가 정합니다.
• 산출물 — 종합 감사 보고서, 우선순위 선택지, 선택한 항목만 실행한 변경.
• 주의 — 우선순위 결정은 사람의 몫입니다. 카드는 감사 결과를 임의로 전부 고치지 않습니다. 이미 결정이 있다면 그 출처를 밝히고 진행합니다.

디자인 전면 재설계 (dev-design-overhaul)

• 언제 쓰는가 — Claude Code로 만든 프로젝트의 디자인 전체를 하나의 토큰 체계로 다시 짤 때. 기능과 데이터 흐름은 그대로 두고 레이아웃과 화면 구성까지 바꿉니다.
• 준비물 — 프로젝트, 그리고 원하는 분위기·참고 자료·제약이 있으면 지정 칸에 적습니다. 지정하면 최우선으로 반영됩니다.
• 산출물 — 방향 선언과 기각한 대안, 통합 토큰, 화면별 적용 결과, 기능 회귀 점검, 렌더 캡처.
• 주의 — 기존 기능이 그대로 동작하는지 변경마다 확인하도록 되어 있습니다. 시작 전에 저장소를 커밋해 두고, 결과가 마음에 들지 않으면 되돌릴 수 있게 합니다(9장).

발표자료 HTML (dev-slides-html)

• 언제 쓰는가 — 기획안이나 보고서 문서 하나로 발표 자료를 만들 때. 결과는 파일 하나의 HTML입니다.
• 준비물 — 원문 문서(.md 등). 이미지 생성 도구(12장)가 연결되어 있으면 장면 이미지를 생성해 넣습니다.
• 산출물 — 슬라이드 구성표, 생성 이미지, 도식, 한국어 슬라이드 전체가 담긴 단일 HTML.
• 주의 — 생성 이미지 안에 글자가 들어가지 않도록 장면을 설계하고, 삽입 전에 눈으로 확인하는 절차가 있습니다. 이미지 생성에 실패하면 빈칸을 채우지 않고 어느 슬라이드인지 보고합니다. 발표 전에 숫자와 문장을 원문과 대조합니다.

카드 고르는 법

상황별로 가장 먼저 볼 카드는 아래와 같습니다.

카드 목록과 설명은 actigence.ai/vibe-coding-prompts에서 계속 갱신됩니다. 카드의 개념 배경은 actigence.ai/manual의 사용설명서와 부록 C의 용어 사전을 참고합니다.

이 책 본문의 복사용 프롬프트

카드와 별개로, 각 장의 본문과 실습에는 바로 복사해 쓰는 짧은 프롬프트가 있습니다. 상황별로 찾을 곳을 모았습니다. 대괄호 안은 본인 내용으로 바꿉니다.