본문으로 건너뛰기

부록 · 부록 B

스킬 14종

전자책 v1.0.0 · 2026-11-07 14:17 KST 기준

이 장의 차례
  1. 설치와 사용의 기본
  2. 프롬프트 작성
  3. 문서 생성
  4. 검증과 평가
  5. 시각화
  6. 개발
  7. 스킬 고르는 법

이 부록은 액티전스 스킬 카탈로그의 14종을 정리한 안내서입니다. 스킬마다 하는 일, 호출하는 말, 넣어야 할 입력, 나오는 결과, 주의할 점을 적었습니다. 스킬의 개념과 만드는 법은 11장에서 다룹니다. 파일은 actigence.ai/skills에서 내려받습니다.

설치와 사용의 기본

스킬은 SKILL.md라는 파일에 이름과 설명, 지시문을 담은 작업 묶음입니다. Claude는 설명에 적힌 조건과 사용자의 말이 맞으면 해당 스킬을 불러 씁니다.

  • 내려받기 — actigence.ai/skills에서 스킬 파일을 받습니다. 파일 하나로 된 스킬은 .md, 참고 문서가 딸린 스킬은 .zip입니다. 이 부록의 14종 중 oneshot-prototyping, fullstack-feature, debug-rootcause, seo-aeo-geo가 zip입니다.
  • Claude Code에서 — 스킬이름/SKILL.md 형태로 둡니다. 모든 프로젝트에서 쓰려면 ~/.claude/skills/ 아래에, 한 프로젝트에서만 쓰려면 프로젝트 폴더의 .claude/skills/ 아래에 둡니다. zip 스킬은 압축을 풀어 같은 위치에 넣습니다(2026년 11월 기준).
  • Claude 앱과 웹에서 — 개인 요금제에서는 설정의 스킬 메뉴(Customize > Skills)에서 zip 파일로 올립니다. 코드 실행 기능이 켜져 있어야 합니다. 팀·기업 요금제는 조직 관리자의 설정에 따릅니다(2026년 11월 기준). 메뉴 이름은 바뀔 수 있으므로 공식 도움말을 따릅니다.
  • 공식 문서 — Claude Code 스킬 문서, Claude 도움말: 스킬 사용하기(2026년 11월 기준).

사용할 때의 공통 주의점은 다음과 같습니다.

  • 스킬은 지시문이지만 파일을 만들고 명령을 실행하는 작업으로 이어질 수 있습니다. 신뢰할 수 있는 출처의 스킬만 설치하고, 함께 들어 있는 스크립트와 참고 파일을 열어 본 뒤 씁니다(11장).
  • 호출 조건이 엄격한 스킬이 있습니다. 조건에 필요한 단어가 없으면 스킬이 발동하지 않거나 중단을 알립니다. 아래 "트리거"를 그대로 쓰는 것이 안전합니다.
  • 스킬 결과도 검수 대상입니다. 숫자, 인용, 법령 내용은 사람이 확인합니다(19장).
  • 스킬 파일은 갱신됩니다. 설치본이 오래되었다면 사이트의 최신본으로 바꿉니다.

프롬프트 작성

GMP — 메타 프롬프트 프로토콜 (gmp)

  • 하는 일 — 프롬프트나 스킬 파일을 표준 구조로 설계하거나 개선합니다. 구조는 XML 태그 계층, 처음과 끝에 같은 핵심 규칙을 두는 이중 고정, 우선순위 표시, 자가검증입니다.
  • 트리거 — "프롬프트 만들어줘", "프롬프트 작성해줘", "이걸 프롬프트로", "GMP 적용", "메타 프롬프트", "스킬 만들어줘", "SKILL.md 만들어줘".
  • 입력 — 만들려는 작업 설명, 또는 고치려는 기존 프롬프트.
  • 결과 — 구조를 갖춘 프롬프트 또는 스킬 .md 파일.
  • 주의 — 프롬프트를 만들어 달라는 요청에만 쓰는 스킬입니다. "보고서 써줘", "코드 짜줘"처럼 작업 자체를 시키는 말에는 맞지 않습니다. 메타 프롬프팅의 원리는 3장을 봅니다.

문서 생성

PRD-Vibecoding — 바이브코딩 PRD 작성 (prd-vibecoding)

  • 하는 일 — 한 줄짜리 아이디어에서 제품 요구사항 문서를 합성합니다. 사용자 선호가 결정적인 항목만 객관식으로 묻고, 데이터 모델, 화면, 권한 표는 자동으로 설계합니다.
  • 트리거 — "PRD 만들어줘", "PRD 작성해줘", "바이브코딩 PRD", "프로토타이핑 사양서", "클로드 코드용 PRD".
  • 입력 — 아이템을 설명하는 한 줄에서 몇 줄. 질문에는 객관식으로 답합니다.
  • 결과 — 단일 PRD.md. 13개 절과 자율 실행 설정 절을 포함하며, 부록 A의 원클릭 풀스택 카드와 oneshot-prototyping 스킬이 그대로 읽는 형식입니다.
  • 주의 — 사용자만 아는 사실(대상 고객, 제약 조건)은 지어내지 않고 질문으로 확인합니다. 결과를 읽고 빠진 요구가 없는지 점검한 뒤 개발에 넘깁니다(4장).

Session-Handoff — 세션 인계 문서 (session-handoff)

  • 하는 일 — 현재 세션의 확정 산출물, 결정과 근거, 제약, 범위(변경할 것, 유지할 것, 하지 않을 것)를 뽑아 다음 세션이 이어받을 .md 문서를 만듭니다.
  • 트리거 — "핸드오프 문서 만들어줘", "세션 핸드오프", "다음 세션으로 넘길 문서", "이 작업 다른 대화에서 이어가".
  • 입력 — 현재 세션의 대화와 작업 상태. 별도 첨부는 필요하지 않습니다.
  • 결과 — 확정된 내용은 원문 그대로 보존하고, 시행착오와 폐기된 경로는 걸러낸 인계 문서.
  • 주의 — 단순 요약 요청에는 맞지 않습니다. 이어받을 의도가 있을 때 씁니다. 컨텍스트가 가득 차기 전에 만들어야 내용이 온전합니다(10장, 20장).

Gov-Startup-Bizplan — 사업계획서 작성 (gov-startup-bizplan)

  • 하는 일 — 정부지원 창업사업용 사업계획서 .docx를 두 번의 패스로 작성합니다. 먼저 사실을 확인하고, 그 뒤에 본문을 씁니다.
  • 트리거 — "사업계획서 작성", "정부지원사업", "TIPS 사업계획서", "초기창업패키지", "예비창업패키지".
  • 입력 — PRD, 팀 정보, 공고문이나 제출 양식.
  • 결과 — 양식에 맞춘 .docx. 모든 수치에 기관명과 연도의 출처를 병기하고, 현재 패스에서 쓰지 않는 장은 원본 그대로 둡니다.
  • 주의 — 수치는 웹 검색으로 확인한 출처가 있어야 하며, 출처가 없는 수치는 쓰지 않는다는 규칙이 있습니다. 그래도 제출 전에 공고문 요건과 출처를 직접 대조합니다. 제출 책임은 작성자에게 있습니다.

HWPX — 한글 문서 처리 (hwpx)

  • 하는 일 — 한글(Hancom Office)의 .hwpx 파일을 생성, 읽기, 편집합니다. 내부 XML을 직접 다루는 방식입니다.
  • 트리거 — ".hwpx 파일", "한글 문서", "Hancom", "OWPML".
  • 입력 — 참고용 .hwpx 파일(있으면 구조를 최대한 그대로 복원), 바꿀 텍스트와 데이터.
  • 결과 — 표준 형식의 .hwpx 파일. 참고 문서가 있으면 서식과 쪽수가 어긋나는지 검사합니다.
  • 주의 — 실행 환경에 Python과 XML 처리 라이브러리가 필요합니다. 쪽수와 서식은 한글 프로그램에서 열어 눈으로 확인합니다.

검증과 평가

FactCheck — 7축 팩트체크 (factcheck)

  • 하는 일 — 보고서, 사업계획서, 조사 보고서 같은 근거 기반 문서를 일곱 축(사실, 논리, 가정, 수치, 맥락, 법규, 표현)으로 보수적으로 점검합니다. 의심스러우면 표시합니다.
  • 트리거 — "팩트체크해줘", "검증해줘", "사실 확인", "이거 맞는지 확인", "제출해도 되는지".
  • 입력 — 검증할 문서. 딥리서치 직후의 결과물도 대상입니다(15장).
  • 결과 — 대화에는 간결한 요약, 별도 파일에는 수정 흔적 없이 정리된 개선본.
  • 주의 — 출처 없는 수치는 자동으로 표시합니다. 핵심 사실은 웹 검색으로 교차 확인하는 방식이므로, 검색이 닿지 않는 내부 자료는 "미확인"으로 남습니다. 미확인 항목은 사람이 확인합니다.

Paper Quality Enhancer — 학술 논문 고도화 (paper-quality-enhancer)

  • 하는 일 — 논문 원고를 여덟 축(논증, 문헌, 방법론, 인용, 기여, 명료성, 재현성, 윤리)으로 분석하고, 적대적 심사를 모의해 투고 수준을 끌어올립니다.
  • 트리거 — "논문 개선", "논문 고도화", "논문 다듬어줘", "투고 전 검토", "피어리뷰 시뮬레이션", "Reviewer 2".
  • 입력 — 원고 파일, 투고하려는 학술지나 학회, 분야.
  • 결과 — 개선된 원고와 심사 보고서, 투고 등급 매칭.
  • 주의 — 단순 교정, 번역, 요약에는 맞지 않습니다. 문헌 인용은 환각 방지 절차가 있어도 실제 존재 여부를 직접 확인합니다. 연구 윤리와 저작권 책임은 저자에게 있습니다.

시각화

Infographic — 문서 도식화 (infographic)

  • 하는 일 — 사업계획서, 보고서, 제안서의 핵심을 15~20개 절의 인포그래픽 HTML로 바꿉니다.
  • 트리거 — "인포그래픽 만들어줘", "도식화해줘", "시각화", "문서에 넣을 그림".
  • 입력 — 원문 문서. 원문의 목차 순서가 그대로 도식의 순서가 됩니다.
  • 결과 — 흰 배경, 검은 글자, 한 가지 포인트 색, 가로형 레이아웃의 HTML.
  • 주의 — 수치는 원문 그대로 쓰고 반올림이나 추정을 하지 않습니다. 개인정보는 마스킹합니다. 결과의 숫자를 원문과 한 번 대조합니다.

Gov-Doc-Infographic — 정부지원 도식화 (gov-doc-infographic)

  • 하는 일 — 정부지원사업 제출용 사업계획서나 연구개발계획서를 심사위원 친화 형식으로 도식화합니다.
  • 트리거 — "사업계획서 인포그래픽", "사업계획서 도식화", "연구개발계획서 도식화", "계획서에 넣을 그림".
  • 입력 — 제출용 계획서 원문.
  • 결과 — 전체 인포그래픽 HTML 하나와, 문서 초반 개요 표의 칸에 넣는 소형 인포그래픽 HTML 하나.
  • 주의 — 마케팅 이미지나 SNS용 그림, 발표 슬라이드에는 맞지 않습니다. 일반 문서는 위의 Infographic을 씁니다. 제출 양식의 분량과 형식 요건은 공고문으로 직접 확인합니다.

Matjip-Scout — 근본 맛집 탐색 (matjip-scout)

  • 하는 일 — 지역과 상황(접대, 데이트, 혼밥, 회식, 출장)을 받아 오래되고 검증된 식당만 골라 리포트로 냅니다.
  • 트리거 — "맛집 추천해줘", "맛집 찾아줘", "근본 맛집", "출장 맛집", "회식 장소".
  • 입력 — 지역, 상황, 인원이나 선호가 있으면 함께.
  • 결과 — 추천 목록, 기준 미달로 제외한 후보와 사유, 탐색 방법과 신뢰도 안내가 담긴 .md.
  • 주의 — 심층 연구(Deep Research) 모드에서만 제대로 동작하며, 일반 모드에서는 모드 전환을 안내하고 멈춥니다. 영업 여부, 휴무일, 메뉴는 방문 전에 식당에 직접 확인합니다. 일상 업무와는 거리가 있으나, 조사형 스킬의 예시로 실습에 쓰기 좋습니다(15장).

개발

원샷 프로토타이핑 (oneshot-prototyping)

  • 하는 일 — PRD 하나로 빈 폴더에서 배포까지 한 세션에 진행합니다. 부록 A의 원클릭 풀스택 카드와 같은 절차를 스킬로 묶은 것입니다.
  • 트리거 — "프로토타이핑"이라는 단어가 있고, 요청에 PRD가 첨부되었거나 작업 폴더에 PRD 파일이 있을 때 두 조건이 함께 맞아야 발동합니다. 예: "이 PRD로 프로토타이핑 해줘". "프로토타입 만들어줘"만으로는 발동하지 않습니다.
  • 입력 — PRD 파일.
  • 결과 — 배포된 데모, 구글 시트 저장소, 디자인 기준, 단계별 통과 기록.
  • 주의 — 배포와 계정 준비까지 자동으로 진행합니다. 연습 환경에서 먼저 돌립니다(20장). 필요한 연결(디자인 도구 등)이 없으면 같은 기준의 로컬 경로로 진행합니다.

풀스택 기능 구현 (fullstack-feature)

  • 하는 일 — 기존 저장소에 기능 하나를 그 기능이 닿는 모든 계층에 넣습니다. 설계, 구현, 검증, QA(품질 확인) 네 역할이 붙습니다.
  • 트리거 — "풀스택"과 "구현" 두 단어가 함께 있을 때만 발동합니다. 예: "즐겨찾기 기능 풀스택으로 구현해줘".
  • 입력 — 기능 설명이나 요구 문서, 이미 있는 저장소.
  • 결과 — 전 계층 변경, 테스트, 관문별 결과표.
  • 주의 — 기능 하나 단위입니다. 여러 개면 나누어 요청합니다. 새 프로젝트 시작이나 버그 수정에는 맞지 않습니다. 부록 A의 "기능 추가: 풀스택" 카드와 같은 계열입니다.

디버깅 (debug-rootcause)

  • 하는 일 — 증상에서 근거로 확인된 원인까지 추적해 고치고 회귀 테스트로 마감합니다. 가설 세 개를 동시에 세워 반증하며, 재현 시나리오를 잡기 전에는 코드를 고치지 않습니다.
  • 트리거 — 메시지에 "디버깅"이라는 단어가 있을 때만 발동합니다. 예: "로그인 빈 화면 디버깅 해줘". "버그 고쳐줘", "에러 나는데"만으로는 발동하지 않습니다.
  • 입력 — 증상 설명, 오류 로그, 화면 캡처.
  • 결과 — 원인 규명, 수정, 회귀 테스트.
  • 주의 — 같은 문제를 다시 잡는 테스트까지 남기는 것이 완료 조건입니다. 운영 데이터가 얽힌 경우 수정 전 백업 여부를 확인합니다(20장).

SEO · AEO · GEO 적용 (seo-aeo-geo)

  • 하는 일 — 운영 중인 사이트에 검색 노출 최적화 세 가지를 별도 브랜치에서 적용하고 풀 리퀘스트로 마감합니다.
  • 트리거 — "SEO"라는 단어가 있을 때만 발동합니다. 예: "이 사이트에 SEO 적용해줘". "검색 노출 올려줘" 같은 표현만으로는 발동하지 않습니다.
  • 입력 — 깃으로 관리되는 사이트 코드, 깨끗한 작업 상태.
  • 결과 — 브랜치와 풀 리퀘스트(본문이 최종 보고서), 문서 세트, 생성만 된 데이터베이스 변경 파일.
  • 주의 — 새 프로젝트를 만드는 작업에는 맞지 않습니다. 기존 파일은 직접 고치지 않고 제안 사본으로 내며, 적용 전후의 크롤 도달성과 성능 지표를 비교합니다. 데이터베이스 변경은 생성만 하고 적용은 사람이 합니다.

스킬 고르는 법

하려는 일 스킬
프롬프트, 스킬 파일 만들기 gmp
아이디어를 개발 사양서로 prd-vibecoding
작업을 다음 세션에 넘기기 session-handoff
제출 전 문서 검증 factcheck
문서를 그림으로 infographic / gov-doc-infographic
한글 파일 다루기 hwpx
PRD로 시제품 배포까지 oneshot-prototyping
기존 저장소에 기능 하나 fullstack-feature
버그 원인 추적 debug-rootcause
운영 사이트 검색 노출 seo-aeo-geo

최신 스킬 목록과 설명은 actigence.ai/skills에서 확인합니다.