Vibe Coding · Skills & Logic
프로그램 말고 스킬을 설계하라 — 바이브 코딩의 Agent Skills·로직 기반 운영
고정 프로그램 대신 AI가 알아서 일하게 만드는 방법
대본에 맞는 이미지 자동 배치처럼 보이는 기능을 프로그램으로 박아두면, 그 순간엔 돌아가도 수정할 때마다 코드·옵션·UI를 고쳐야 합니다. 바이브 코딩 툴(Cursor, Codex, Claude Code 등)에는 스킬(SKILL.md)과 로직을 심어 두고, 사람은 목표만 말하고 AI가 절차를 고르게 하는 편이 나 혼자 쓰는 작업에는 훨씬 가볍습니다. 이 글은 그 개념을 업계 흐름(Anthropic Agent Skills)과 함께 정리합니다.
게시 2026-06-12
Part 1 · 시작
한 문장으로 압축하는 개념
「고정된 프로그램을 짜지 말고, AI가 알아서 일하게 만드는 스킬과 로직을 설계하라.」
프로그램은 어떻게(How)를 코드에 박아 둡니다. 스킬·로직은 무엇을·왜(What/Why)만 주고, How는 AI가 그때그때 판단합니다. 그래서 「45초짜리 만들어줘」에서 「30초로 줄여줘」까지 자연어 한 줄로 끝납니다.
핵심 한 줄
프로그램 말고 스킬
고정된 프로그램을 짜지 말고, AI가 알아서 일하게 만드는 스킬과 로직을 설계하라는 뜻입니다.
업계 흐름
Agent Skills
Anthropic이 2025년에 공식화한 Agent Skills는 2025년 12월 개방형 표준으로 확장됐습니다. 개인 취향이 아니라 업계가 향하는 방향입니다.
사용자 입력
말 한마디
「45초짜리 만들어줘」「30초로 줄여줘」처럼 목표만 말하면 됩니다. 코드를 열어 옵션을 고칠 필요가 없습니다.
운영 부담
갱신·조작 ↓
프로그램은 사람이 계속 수정·갱신해야 살아 있습니다. 스킬은 AI가 상황에 맞게 판단하고 필요한 도구를 꺼냅니다.
읽는 순서
- 이 글은 「왜 프로그램보다 스킬인가」→ 「사례 비교」→ 「Agent Skills 정의·점진적 공개」→ 「배경 타임라인」→ 「설계·메타 스킬」→ 「CLI/MCP·보안」 순으로 읽도록 짰습니다.
- 용어가 헷갈리면 본문을 먼저 읽고, 마무리 직전 「핵심 용어 사전」에서 2열 카드로 훑어도 됩니다.
- 실무로 바로 들어가려면 「프로그램 vs 스킬 사례」와 「스킬 만드는 실전 순서」만 골라 읽어도 충분합니다.
이 저장소도 같은 철학
wiki-posting, column-posting, site-media-upload, keopuba 등은 모두 스킬 문서 + AI + CLI 조합입니다. 절차는 SKILL.md에, 실행은 에이전트가 터미널·API로 처리합니다.
Part 1 · 시작
프로그램화가 왜 골치 아픈가
예전에 바이브 코딩으로 이미지 배치·편집 파이프라인을 프로그램으로 만들었을 때, 뭔가 바꾸려면 AI에게 「여기 수정해줘」를 반복하고, 확인하고, 또 깨진 곳을 고치는 일이 작업보다 길어졌습니다.
- 「여기 수정해줘」→ 확인 → 또 어긋남 → 다시 수정 → 또 클릭 → 다른 기능이 깨짐 → 또 고침… 수정 자체가 별도의 노동이 됩니다.
- 영상 길이를 45초에서 30초로 바꾸려면 코드에서 초 단위 옵션을 찾고, 연쇄 영향을 검증해야 합니다.
- 이미지 자동 배치·음성 합성·편집 파이프라인을 프로그램으로 박아두면, 그 순간엔 돌아가도 결국 평생 관리할 짐이 됩니다.
- 편하려고 만든 도구가 도구를 모시는 구조로 바뀝니다. 갱신과 조작을 사람이 떠안아야 합니다.
프로그램이 맞는 경우도 있음
강의 판매·모객·다수 사용자용 SaaS라면 프로그램(버튼·UI·고정 출력)이 설득력 있습니다. 다만 나 혼자 쓰는 반복 작업을 GUI 프로그램으로 굳히면 유연함을 통째로 버리는 경우가 많습니다.
Part 2 · 개념
프로그램 vs 스킬·로직
아래 표가 본질적인 차이입니다. 프로그램은 How를 사람이 고정하고, 스킬은 What/Why만 주고 How는 AI에게 맡깁니다.
| 구분 | 프로그램 | 스킬·로직 |
|---|---|---|
| 본질 | 코드로 고정된 절차(How를 전부 박음) | 개념·목적·판단 기준(What/Why만 주고 How는 AI) |
| 결정 주체 | 사람이 모든 분기를 미리 정의 | AI가 상황을 보고 판단 |
| 수정 | 코드·옵션·UI를 직접 고침 | 자연어 한 줄로 지시 변경 |
| 모호한 지시 | 정해진 입력만 받음 | 「이미지 재배치해줘」「45초짜리 만들어줘」 수준도 처리 |
| 유연성 | 설계된 케이스만 | 그때그때 스킬·CLI·코드를 조합 |
| 운영 부담 | 사람이 계속 갱신·조작 | AI가 스스로 절차 선택·실행 |
| 적합한 용도 | 판매·모객·다수 사용자용 완성품 | 나 혼자 쓰는 작업 흐름·반복 업무 |
| 재현성 | 동일 입력 → 동일 출력(결정적) | 같은 지시도 실행마다 해석·순서가 달라질 수 있음 → 스크립트·DoD로 보완 |
스킬은 추상화된 로직입니다. 「이미지 재배치해줘」처럼 포괄적인 지시도, AI가 관련 스킬을 읽고 CLI·코드· 다른 스킬을 조합해 처리합니다. 사람은 목표와 방향만 제시합니다.
Part 2 · 개념
프로그램 방식 vs 스킬 + CLI — 실전 사례
추상 비교만으로는 체감이 어렵습니다. 아래는 이 저장소·운영에서 실제로 마주치는 네 가지 시나리오입니다. 왼쪽은 전용 프로그램으로 굳히는 방식, 오른쪽은 스킬 문서 + 에이전트 + CLI입니다.
롱폼 영상 → 45초 숏폼 만들기, 나중에 30초로 줄이기
프로그램 방식
FFmpeg 옵션·타임라인·자막 위치를 GUI나 설정 파일에 고정. 「45초」 버튼과 「30초」 버튼을 코드로 따로 만듦.
왜 골치 아픈가: 후킹 문구·컷 포인트가 바뀌면 타임라인 전체를 손으로 다시 맞춤. 「여기만 2초 줄여줘」도 코드·UI 수정 → 테스트 반복.
스킬 + CLI 방식
video-longform-to-shortform 스킬 + segments.json + edit_plan. 사용자는 「30초로 줄여줘」「후킹 A안으로」만 말함. AI가 스킬을 읽고 cut-concat-branded·export 스크립트를 그때그때 조합.
이점: 길이·후킹·브랜딩 변경이 자연어 한두 줄로 끝남. 절차는 스킬에, 실행은 CLI가 담당.
칼럼 한 편 작성·사이트에 등록
프로그램 방식
칼럼 에디터 웹앱을 만들어 폼에 제목·본문·FAQ를 넣고 「발행」 버튼으로 TSX·Router·navData를 생성하는 전용 프로그램.
왜 골치 아픈가: TOC 패턴·JSON-LD·im-not-ai 윤문·4곳 등록 규칙이 바뀔 때마다 에디터 코드를 고침. 예외 케이스(이미지·TTS)마다 UI 분기 추가.
스킬 + CLI 방식
column-posting 스킬: 조사 → column-content.ts·page.tsx → ColumnPageRouter·staticColumns·columnNavData 등록 → (선택) site-media-upload·tts. 에이전트가 파일을 직접 편집.
이점: 새 섹션 타입·FAQ 규칙은 SKILL.md만 고치면 됨. 프로그램 UI를 안 만듦.
커밋 → 푸시 → 빌드 → Cloudflare 배포
프로그램 방식
배포 대시보드 앱: Git 상태 표시, 체크박스로 파일 고르고, 빌드 로그 뷰어, 배포 버튼. 내부에서 npm·wrangler 호출.
왜 골치 아픈가: gitignore 규칙·PowerShell here-string·wrangler 500 재시도 안내가 바뀔 때마다 대시보드 코드 수정. 로컬 전용 경로 실수로 스테이징하는 버그도 앱이 막아야 함.
스킬 + CLI 방식
keopuba 스킬: git status → 파일별 git add → commit → push → npm run build → deploy:upload. 금지 경로는 gitignore-local-only 규칙 + 스킬 본문에 명시.
이점: 「커푸배」 한마디로 절차 실행. 규칙 변경은 스킬·Rules만 갱신.
위키 본문에 이미지·인포그래픽 삽입
프로그램 방식
이미지 업로드 전용 데스크톱 앱: 프롬프트 입력, god-tibo 호출, CDN URL 복사, 위키 JSON에 붙여넣기 단계를 화면으로 고정.
왜 골치 아픈가: 한글 라벨 필수·4K 검증·wiki-posting 4단계 윤문 등 정책이 늘 때마다 앱 업데이트. 다른 에이전트(Codex/Cursor)와 공유 안 됨.
스킬 + CLI 방식
wiki-posting → im-not-ai → site-media-upload 스킬 체인. CLI로 god-tibo-imagen 실행 후 /api/wiki/posts에 POST.
이점: 정책은 스킬 문서에 모음. 툴이 바뀌어도 같은 SKILL.md를 Cursor·Claude Code가 읽음.
공통 패턴 — 그러나 트레이드오프도 있음
프로그램은 「버튼·옵션·화면」을 늘리며 How를 고정합니다. 스킬+CLI는 What만 바꾸면 AI가 스킬을 다시 읽고 명령·파일 편집 순서를 맞춥니다. 판매용 제품이 아니라 나 혼자 쓰는 파이프라인일수록 오른쪽이 유리한 경우가 많습니다. 다만 스킬+AI는 매번 똑같이 동작한다는 보장은 없고, 정확성·보안이 중요한 단계는 스크립트·프로그램으로 보완해야 합니다.
Part 2 · 개념
Agent Skills란 무엇인가
Anthropic이 2025년에 정식으로 내놓은 Agent Skills는 2025년 12월 개방형 표준으로 확장됐습니다. 개인 취향이 아니라 업계가 향하는 방향에 가깝습니다.
앤트로픽의 비유: 「스킬을 만드는 건 새 직원에게 줄 업무 매뉴얼을 쓰는 것과 같다.」 모든 행동을 일일이 명령하지 않고, 판단 기준과 절차를 문서로 전달하면 직원(=AI)이 상황에 맞게 처리합니다.
기술적으로는 SKILL.md가 들어 있는 폴더 하나입니다. 지침, reference 문서, 필요하면 스크립트를 함께 둡니다. Cursor의 .cursor/skills/, Claude Code의 skills 디렉터리가 같은 패턴입니다.
Part 2 · 개념
점진적 공개(Progressive Disclosure)
AI 컨텍스트 창은 한정돼 있습니다. 모든 스킬 본문을 한꺼번에 넣으면 둔해지고 헷갈립니다. 점진적 공개는 책의 목차 → 본문 → 부록처럼 필요할 때만 깊이 읽는 설계입니다.
1단계
목차만 올려둠
AI는 시작할 때 모든 스킬의 name과 description만 가볍게 인지합니다. 「이런 스킬이 있구나」 수준의 목차입니다.
2단계
필요할 때 본문 로드
사용자 지시를 보고 해당 작업에 맞는 스킬이 필요하다고 판단하면, 그때 SKILL.md 본문 전체를 읽습니다.
3단계
깊은 자료는 더 필요할 때만
reference.md, 스크립트, 예시 파일은 특정 상황에서만 열어봅니다. 컨텍스트 창을 아끼면서 정보량을 사실상 무제한으로 확장합니다.
이 저장소의 cursor-skill-list 스킬도 1단계 라우팅 인덱스 역할을 합니다. 에이전트는 먼저 인덱스만 읽고, 해당 SKILL.md를 엽니다.
Part 2 · 개념
스킬 안의 코드 — 오해 방지
- 「스킬을 쓰라」는 「코드를 절대 쓰지 말라」는 뜻이 아닙니다.
- 정렬·PDF 추출·고정 변환처럼 매번 머리로 계산하기 비효율적인 일은 스킬 안에 스크립트를 넣고, AI가 필요할 때만 실행합니다.
- 차이: 프로그램에서는 코드가 주인이고 사람이 코드를 섬깁니다. 스킬에서는 코드가 AI의 연장(도구)이고, 쓸지 말지를 AI가 결정합니다.
- 이 저장소의 wiki-posting, column-posting, site-media-upload도 같은 철학입니다. 절차는 문서(스킬)에, 실행은 AI+CLI가 합니다.
비결정성과 재현성 — 스킬의 약점을 짚고 보완하기
스킬+AI 방식의 가장 큰 약점은 비결정성입니다. 프로그램은 입력이 같으면 출력이 같지만, AI가 스킬을 해석하는 방식은 실행마다 미묘하게 달라질 수 있습니다. 회계·정산·규제 보고처럼 「매번 똑같이」가 생명인 작업은 프로그램이 유리합니다. 반면 콘텐츠·사이트 운영처럼 유연함이 더 중요한 작업은 스킬이 유리하고, 그 안에서도 정확성이 필요한 단계(해시 검증, lint, 고정 스크립트)만 scripts/로 박아 재현성을 확보합니다. 즉 스킬 안에 코드를 두는 진짜 이유 중 하나는 「AI의 유연함 + 코드의 결정성」을 섞기 위함입니다.
Part 2 · 개념
스킬이 탄생한 배경 — 왜 지금 주목되나
위에서 Agent Skills가 무엇인지, 점진적 공개와 스킬 안의 코드가 왜 필요한지 봤다면, 이제 「왜 지금」인지가 자연스럽게 이어집니다. 스킬은 어제 갑자기 생긴 유행어가 아닙니다.
2024년 11월
MCP(Model Context Protocol) 공개
Anthropic이 AI와 외부 도구·데이터를 연결하는 개방 프로토콜을 내놨습니다. 「연결 규격」이 먼저 정리됐고, 그다음 「업무 매뉴얼」 형태의 스킬이 따라온 셈입니다.
2025년
Agent Skills 공식화
Anthropic 엔지니어링 블로그 「Equipping agents for the real world with Agent Skills」에서 SKILL.md·점진적 공개·폴더 단위 패키징을 제시했습니다. 비유는 「새 직원에게 줄 업무 매뉴얼」.
2025년 12월 9일
agentskills.io·Agentic AI Foundation
name·description·SKILL.md 형식이 벤더 중립 명세(agentskills.io)로 정리됐고, MCP는 Linux Foundation 산하 Agentic AI Foundation에 기부됐습니다. Cursor·Claude Code·API 업로드 경로가 같은 패턴을 따릅니다.
2025~2026년
에디터·CLI 에이전트에 내장
Cursor는 .cursor/skills/, Claude Code는 .claude/skills/·~/.claude/skills/, Codex도 SKILL.md 기반 워크플로를 지원합니다. Commands가 Skills로 통합되는 흐름도 Claude Code 문서에 나옵니다.
정리하면, 에이전트가 파일·셸을 쓸 수 있게 된 것이 전제이고, 그 위에 재사용 가능한 절차 문서가 스킬입니다. 프로그램은 그 절차를 실행 파일로 굳히고, 스킬은 문서로 남겨 AI가 매번 해석합니다.
Part 3 · 설계
스킬 설계 — 무엇을 넣고 어떻게 짜야 하나
스킬은 「긴 프롬프트 한 방」이 아니라 유지보수 가능한 매뉴얼입니다. Anthropic·agentskills.io·Claude 공식 가이드가 공통으로 말하는 항목을 이 저장소 관점에서 정리했습니다.
SKILL.md에 반드시 들어갈 것
- YAML frontmatter: name(폴더명과 일치)·description(무엇을·언제 쓸지·트리거 키워드)
- description은 짧고 정확하게 — Claude Code는 스킬당 description+when_to_use 합쳐 약 1,536자까지 목록에 실리고, 전체 스킬 description 합산 약 15k자 예산을 넘으면 일부 스킬이 목록에서 누락될 수 있음
- 완료 기준(DoD): 「어디까지 하면 끝인지」 체크리스트
- 금지 사항: git add -A, docs 커밋, force push 등 실수 방지
- 연관 스킬 링크: wiki-posting → im-not-ai → site-media-upload처럼 다음에 읽을 문서
본문에 넣으면 좋은 것
- 단계별 절차(1→2→3), 실패 시 재시도 규칙
- 입력·출력 예시(한두 개면 충분)
- 프로젝트 고유 경로·API·CLI 명령(복사 가능한 수준)
- 「스킬 절차 vs 일반 추론」 충돌 시 스킬 우선 문구
분리·보조 파일
- SKILL.md 500줄 넘으면 reference-*.md로 쪼개기(agentskills.io·Anthropic 가이드 권장)
- scripts/: PDF 추출·정렬·검증처럼 매번 같은 계산은 코드로
- assets/: 템플릿 JSON, 프롬프트 초안
- cursor-skill-list: 스킬이 많을 때 라우팅 인덱스(1단계 discovery)
설계 시 자주 하는 실수
- description이 모호해 에이전트가 스킬을 안 꺼냄 → 트리거 키워드를 description에 직접 넣기
- How를 SKILL.md에 코드처럼 박음 → What/Why·DoD만 두고 How는 AI에게
- Rules와 스킬 역할 혼동 → 전역 금지는 .mdc, 작업 절차는 SKILL.md
- 한 스킬에 모든 걸 넣음 → 칼럼·위키·배포처럼 쪼개고 연관 링크로 엮기
최소 SKILL.md 골격
--- name: my-workflow description: ○○할 때 사용. 트리거: 키워드1, 키워드2 --- # 목적 · DoD · 금지 · 단계 · 연관 스킬 링크
Part 3 · 설계
스킬을 만드는 스킬 — skill-creator·create-skill
처음부터 SKILL.md를 손으로 쓰지 않아도 됩니다. 메타 스킬(meta skill)은 「스킬 작성법」 자체를 가르치거나, 대화만으로 초안을 만들어 줍니다. skill-creator 같은 메타 스킬과 워크플로를 따르면 보통 30분 안팎에 첫 기능 스킬 초안을 만들 수 있다는 체감이 많습니다(처음부터 손으로 쓰면 더 걸릴 수 있음).
| 환경 | 이름 | 역할 | 부르는 법 |
|---|---|---|---|
| Claude (claude.ai·Claude Code) | skill-creator | 자연어로 스킬 초안 생성·SKILL.md 포맷 검토·트리거 문구 제안 | 「Help me build a skill for …」「skill-creator로 이 워크플로 스킬 만들어줘」 |
| Claude Code | skills-ref validate | SKILL.md·폴더 구조·용량 제한(명세 기준) 검증 CLI | 터미널에서 skills-ref validate ./my-skill |
| Cursor | create-skill | 요구사항 수집 → 디렉터리·SKILL.md·reference·scripts 레이아웃 가이드 | 「스킬 만들어줘」「create-skill 따라 새 스킬 작성」 |
| Cursor (이 저장소) | cursor-skill-list | 기존 스킬 목록·분기표·오라우팅 방지(갤러리 vs 색칠 vs site-media 등) | 새 스킬 추가 후 cursor-skill-list/SKILL.md에 등록 |
| 범용 (에이전트 대화) | (대화형 메타) | 잘 끝난 작업을 스킬로 역설계 | 「방금 잘된 방법을 스킬로 정리해줘」「이 절차를 SKILL.md로 만들어줘」 |
스킬을 만든 뒤에는 description에 트리거가 들어갔는지, DoD가 측정 가능한지, 연관 스킬이 cursor-skill-list에 등록됐는지를 점검합니다. Claude 쪽은 skills-ref validate로 구조 검증을 돌릴 수 있습니다.
Part 3 · 설계
스킬 만드는 실전 순서
단계 1
먼저 막 만들지 말 것
AI에게 실제 작업을 시켜보고, 어디서 헤매는지·무엇을 모르는지 관찰합니다. 부족한 부분만 스킬로 채웁니다. Claude의 skill-creator나 Cursor create-skill은 이 단계 이후에 쓰는 도구입니다.
단계 2
name·description을 정확히
AI는 스킬 목록의 이름과 설명만 보고 「지금 꺼낼까」를 판단합니다. 트리거 키워드를 description에 넣는 것이 중요합니다.
단계 3
성공 패턴을 스킬로 고정
작업이 잘 끝났으면 「방금 잘된 방법을 스킬로 정리해줘」라고 시킵니다. Anthropic도 에이전트가 스스로 스킬을 다듬는 방향을 밝혔습니다.
단계 4
스킬 라우팅 계층 두기
cursor-skill-list처럼 「어떤 요청에 어떤 스킬」 분기표를 두면, 포괄적 지시도 올바른 절차로 연결됩니다.
단계 5
연관 스킬 묶기
칼럼 작성은 column-posting → im-not-ai → (선택) site-media-upload처럼, 큰 작업은 작은 스킬 조합으로 설계합니다.
Anthropic도 에이전트가 스스로 스킬을 만들고 다듬는 방향을 밝혔습니다. 잘 된 작업이 끝나면 「이걸 스킬로 정리해줘」라고 시키는 습관이 가장 빠른 학습입니다.
Part 4 · 실전
CLI와 MCP — 무엇을 쓸까
두 용어는 겹치지 않습니다. MCP는 「AI가 외부 세계에 어떻게 접속할지」에 대한 표준 규격이고, CLI는 「터미널에서 명령을 직접 친다」는 실행 방식입니다. 에이전트는 MCP 서버를 통해 도구를 쓸 수도 있고, MCP 없이 bash에서 curl만 쳐서 같은 일을 할 수도 있습니다.
MCP 서버가 노출하는 3가지
| 이름 | 역할 | 비유 |
|---|---|---|
| Tools | AI가 실행할 수 있는 함수·동작 (파일 쓰기, API 호출, DB 쿼리 등) | POST — 무언가를 바꾸거나 실행 |
| Resources | AI가 읽어 들일 데이터 (문서, DB 행, 설정 파일 등) | GET — 정보를 컨텍스트로 가져옴 |
| Prompts | 자주 쓰는 워크플로를 매개변수 있는 템플릿으로 제공 | 양식이 채워진 업무 요청서 |
MCP는 JSON-RPC 2.0으로 메시지를 주고받습니다. 로컬에서는 stdio(프로세스 파이프), 원격·팀 공유에는 HTTP 기반 전송을 씁니다. 반면 CLI는 PowerShell에서 curl.exe, npm run, npx wrangler처럼 이미 익숙한 명령을 그대로 씁니다. 이 사이트의 위키·칼럼·미디어 업로드는 스킬이 절차를 정하고, 에이전트가 CLI로 API를 호출하는 패턴입니다.
| 구분 | MCP | CLI |
|---|---|---|
| 한 줄 정의 | MCP — AI↔외부 도구 연결용 표준 규격(중간 어댑터) | CLI — 터미널 명령으로 OS·API·스크립트 직접 실행 |
| 누가 무엇을 하나 | MCP 서버가 Tools/Resources 노출 → AI 클라이언트가 호출 | 에이전트가 bash/PowerShell에서 curl·git·npm 등 실행 |
| 컨텍스트 비용 | 도구 스키마·설명이 시스템 프롬프트에 많이 실림 | 당장 쓸 명령 한 줄만 출력·실행하는 경우가 많음 |
| 설치·운영 | 서버 프로세스·인증·호스트 앱 연동 설정 필요 | 셸·curl·Node만 있으면 바로 가능 (스킬로 절차만 정의) |
| 팀·보안 | 권한·감사·공유 MCP 서버에 유리 | 개인 PC·단일 저장소 작업에 가볍고 빠름 |
| 이 저장소 예 | 외부 SaaS 연동 시 MCP 검토 가능 | POST /api/admin/media, wrangler, keopuba 스크립트 + 스킬 |
균형 잡힌 선택
혼자 + 단일 프로젝트 → CLI + 스킬이 가볍습니다. 팀 + 여러 SaaS + 권한 관리 → MCP 서버를 한 번 만들어 두고 Claude·Cursor·ChatGPT 등이 같이 쓰게 하는 편이 낫습니다. 「MCP를 안 쓴다」는 말은 보통 「중간 규격 없이 터미널로 직접 한다」는 뜻이지, 외부 연동을 포기한다는 뜻은 아닙니다.
Part 4 · 실전
바이브 코딩 툴과 스킬
아래 툴들 위에 스킬을 얹습니다. 툴이 바뀌어도 「목표 + 스킬 문서」 구조는 유지됩니다.
- Cursor — IDE 통합, Skills·Rules, 멀티파일 편집
- Claude Code — 터미널 에이전트, SKILL.md 기반 워크플로
- Codex — OpenAI 코딩 에이전트
- Antigravity, Kilo, Trae, OpenCode 등 — 동일하게 스킬·로직을 얹어 쓰는 바이브 코딩 툴
관련 칼럼: AI와 바이브 코딩 활용법, 바이브 코딩 A to Z
Part 4 · 실전
스킬·CLI 자동화 — 보안을 잊지 말 것
스킬과 CLI를 권하는 만큼, 에이전트가 손댈 수 있는 범위를 스스로 제한해야 합니다. 편의와 보안은 트레이드오프입니다.
- 에이전트가 터미널·파일·API를 쓰게 하면 편하지만, 스킬·MCP·외부 스크립트는 신뢰할 수 없는 출처일 경우 프롬프트 인젝션·데이터 유출 위험이 있습니다. Anthropic 공식 가이드도 설치 전 스킬 내용을 검토하라고 강조합니다.
- 스킬 본문에 「git push --force」「.env 읽기」 같은 위험 명령이 들어가면 AI가 그대로 실행할 수 있습니다. 금지 경로·금지 명령은 SKILL.md와 Rules(.mdc)에 명시해야 합니다.
- CLI 자동화는 편의와 보안이 트레이드오프입니다. 최소 권한(읽기 전용 토큰, 스테이징만 배포)과 사람 승인 단계를 스킬 DoD에 넣는 편이 안전합니다.
더 깊은 체크리스트
SSRF·CSRF·관리자 API·same-origin 등은 별도 칼럼 바이브 코딩과 보안에서 다룹니다. 스킬을 늘릴수록 그쪽도 함께 보세요.
Part 4 · 실전
프로그램이 맞는 경우
- 남에게 팔거나 SaaS로 제공할 때 — 결과물 일정성·UI·버전 관리가 필요합니다.
- 강의·모객용 데모 — 「이 버튼 누르면 된다」는 완성품이 설득력이 있습니다.
- 규제·감사·회계·정산 — 동일 입력에 동일 출력(결정성·재현성)이 법적·업무적으로 요구될 때. 스킬만으로는 실행마다 결과가 달라질 수 있어 프로그램·스크립트가 맞습니다.
- 나 혼자 쓰는 반복 작업·콘텐츠 제작·사이트 운영 — 유연함이 더 중요하면 스킬·로직이 유리합니다. 다만 그 안에서도 검증·배포 같은 단계는 scripts/로 고정하는 편이 안전합니다.
Part 5 · 마무리
핵심 요약
앞에서 다룬 내용을 짧게 정리합니다.
- 프로그램 = How를 코드·UI에 고정 → 수정할 때마다 사람이 코드를 고침.
- 스킬·로직 = What/Why·DoD만 주고 AI가 How(파일·CLI·조합)를 그때그때 선택.
- Agent Skills = SKILL.md + 점진적 공개 + (필요 시) scripts·references.
- 실전 사례: 숏폼·칼럼·커푸배·위키 이미지는 스킬 체인이 프로그램보다 수정 부담이 적은 경우가 많음.
- 설계: description(트리거)·DoD·금지·연관 스킬이 핵심. 500줄 넘으면 reference로 분리.
- 메타 스킬: Claude skill-creator, Cursor create-skill, 「방금 한 일을 스킬로 정리해줘」.
- 약점: 스킬+AI는 비결정적일 수 있음 → 정확한 단계는 scripts/로, 외부 스킬은 설치 전 검토.
- CLI는 MCP보다 가볍고 직접적 — 혼자 쓰는 작업에 특히 유리. 보안·권한은 스킬·Rules로 제한.
- 「전용 프로그램으로 결과 뽑기」는 엊그제까지만 흔했던 옛 방식. 지금은 스킬·로직 시대.
「프로그램을 만들지 마세요. 스킬과 로직을 설계하세요.」
여기서 말하는 옛 방식은 말 그대로 「지난달」을 뜻하는 게 아닙니다. 대본에 맞춰 이미지를 박아 넣는 전용 프로그램을 짜 두고, 길이·옵션·UI가 바뀔 때마다 코드를 다시 고치던 흐름을 뜻합니다. 그건 엊그제까지만 해도 흔했지만, AI 에이전트가 터미널·파일·스킬을 쓰는 지금은 결과를 뽑아 내는 완성 프로그램보다 스킬(SKILL.md)과 로직으로 맡기는 편이 훨씬 가볍습니다.
Part 5 · 마무리
핵심 용어 사전 — 바이브 코딩·스킬·MCP·CLI
본문을 읽은 뒤 헷갈리는 용어만 골라 보면 됩니다. 카드는 2열로 배치했습니다. 각 항목은 한 줄 정의 → 상세 → 예시 순입니다.
바이브 코딩
Vibe coding자연어로 의도를 말하고 AI가 코드·명령을 대신 짜·실행하는 개발 방식.
예전처럼 모든 분기를 사람이 코드로 박아두지 않고, 「이 기능 추가해줘」「배포해줘」처럼 목표를 말하면 에이전트가 파일 편집·터미널·API 호출을 조합합니다. Cursor, Codex, Claude Code 등이 대표 툴입니다. 바이브 코딩만으로 끝나는 게 아니라, 반복 작업은 스킬(SKILL.md)로 절차를 고정해 두면 매번 같은 실수를 줄일 수 있습니다.
예: 「칼럼 하나 작성해줘」→ column-posting 스킬 로드 → TSX 작성 → Router 등록
스킬
Skill / Agent SkillAI에게 「이런 일은 이렇게 해라」고 적어 둔 폴더+문서 묶음.
최소 구성은 SKILL.md 한 파일입니다. YAML 머리말에 name·description, 본문에 절차·금지 사항·완료 기준(DoD)을 적습니다. Anthropic이 2025년 Agent Skills로 공식화했고, 2025년 12월 agentskills.io 개방형 표준으로 확장됐습니다. Cursor의 .cursor/skills/도 같은 패턴입니다. 직원 온보딩 매뉴얼처럼, 매번 구두로 설명하지 않아도 에이전트가 읽고 따릅니다.
예: column-posting, wiki-posting, site-media-upload
로직
Logic (workflow)「무엇을·왜·언제」에 대한 판단 기준과 단계 순서. 코드 전체가 아님.
이 글에서 로직은 if-else 소스코드를 뜻하지 않습니다. 「자료 있으면 1차 소스로 쓰고 빈 곳만 조사」「이미지는 god-tibo만」「완료 전 FAQ 6개」처럼 의사결정 규칙입니다. 스킬 문서가 로직의 정본이고, AI가 그때그때 How(어떤 파일을 열지, 어떤 명령을 칠지)를 채웁니다.
예: cursor-skill-list §1 분기표 = 「칼럼 요청이면 wiki 말고 column-posting」 로직
MCP
Model Context ProtocolAI 앱과 외부 데이터·도구를 연결하는 공개 표준 프로토콜.
Anthropic이 2024년 11월 공개했습니다. AI 쪽을 MCP 호스트(클라이언트), 데이터·도구 쪽을 MCP 서버라고 부릅니다. JSON-RPC 2.0 메시지로 통신하며, 서버는 Tools(실행)·Resources(읽기)·Prompts(템플릿)를 노출합니다. USB-C 비유처럼 「한 규격으로 여러 AI·여러 서비스 연결」이 목표입니다. 2025년 12월 Linux Foundation 산하 Agentic AI Foundation으로 기부되어 벤더 중립 표준이 됐습니다.
예: GitHub·Slack·DB용 MCP 서버를 만들면 Claude Desktop·Cursor 등에서 재사용
CLI
Command Line Interface터미널에 치는 텍스트 명령으로 컴퓨터·서버·API를 조작하는 방식.
bash, PowerShell, curl, git, npm, npx wrangler 등이 CLI입니다. 바이브 코딩 에이전트는 터미널 도구를 쓸 수 있어, 「파일 읽기 → 스크립트 실행 → curl로 API 호출」을 사람 대신 수행합니다. MCP 없이도 동작합니다. 다만 명령 실수·권한 범위는 사람이 스킬로 제한해야 합니다(금지 경로, git push --force 금지 등).
예: curl -X POST /api/admin/media, npm run deploy:upload
컨텍스트 창
Context windowAI가 한 번에 「기억」하고 추론에 쓸 수 있는 토큰(글자 조각) 상한.
스킬 50개 본문을 전부 넣으면 창이 차서 둔해지고 비용도 커집니다. 그래서 Agent Skills는 name·description만 먼저 올리고(약 100토큰 수준), 필요할 때 SKILL.md 본문, 더 필요할 때 reference·스크립트를 여는 점진적 공개를 씁니다. 스킬 설계 = 컨텍스트 예산을 아끼는 설계이기도 합니다.
예: SKILL.md 500줄 넘으면 reference-*.md로 쪼개기 (agentskills.io 권장)
점진적 공개
Progressive Disclosure필요할 때만 단계적으로 정보를 펼치는 UI·에이전트 설계 원칙.
Agent Skills 표준의 3단계: (1) Discovery — name·description만, (2) Activation — SKILL.md 전체, (3) Execution — scripts·references·assets. 책의 목차→본문→부록과 같습니다. 에이전트가 파일시스템·셸을 쓸 수 있으면 스킬에 담을 수 있는 정보량은 사실상 무한에 가깝습니다.
예: wiki-posting → reference-prompt.txt는 3단계에서만 열림
What / Why / How
목표·이유·방법프로그램은 How를 고정, 스킬은 What·Why만 주고 How는 AI가 선택.
What: 무엇을 만들지(「칼럼 작성」「45초 숏폼」). Why: 왜·누구를 위한지(독자 이해, SEO). How: 어떤 파일·명령·순서 — 스킬은 여기를 절차·예시로 안내하되, 상황마다 AI가 채웁니다. 사용자는 What 위주로 말하고, 스킬이 Why·품질 기준을, AI가 How를 수행합니다.
예: What:「보안 칼럼 보강」 / 스킬: FAQ 6개·OWASP 인용 / How: AI가 섹션 추가
Rules
Cursor Rules (.mdc)에디터·에이전트가 항상 지킬 프로젝트 규칙. 스킬과 역할이 다름.
Rules는 「PowerShell에서 && 금지」「docs 커밋 금지」처럼 전역·상시 적용 규칙입니다. Skills는 「칼럼 작성 요청이 왔을 때만」 읽는 작업 매뉴얼입니다. Rules = 직장 내규, Skills = 업무별 SOP(표준 작업 절차). 둘 다 쓰되, 반복 워크플로는 스킬로, 저장소 전체 금지·스타일은 Rules로 나누는 편이 낫습니다.
예: .cursor/rules/gitignore-local-only.mdc vs column-posting/SKILL.md
에이전트
AI Agent도구(파일·터미널·브라우저)를 쓰며 여러 단계를 스스로 이어가는 AI.
한 번의 채팅 응답으로 끝나지 않고, 읽기→판단→실행→검증을 반복합니다. 스킬은 에이전트의 「업무 매뉴얼」, MCP는 「표준화된 외부 플러그」, CLI는 「OS·서버에 직접 손대는 손」에 가깝습니다. 바이브 코딩 툴의 Agent 모드가 이에 해당합니다.
예: 「칼럼 써줘」→ 조사 → TSX 작성 → Router 4곳 등록까지 한 세션
메타 스킬
Meta skill「스킬을 만드는 법」을 가르치거나 스킬 초안을 생성하는 스킬.
Claude의 skill-creator, Cursor의 create-skill이 대표입니다. 워크플로 설명만으로 SKILL.md·frontmatter·트리거 문구를 제안하고, skills-ref validate로 구조를 검증할 수 있습니다. 잘 끝난 작업을 「스킬로 정리해줘」라고 역설계하는 것도 같은 계열입니다.
예: 「칼럼 포스팅 절차를 스킬로 만들어줘」→ skill-creator / create-skill
MCP를 한 번 더 짧게
MCP = AI용 USB-C 비유: GitHub·DB·슬랙마다 AI 앱별 커넥터를 짜던 N×M 문제를, 서버 한 번 만들고 여러 클라이언트가 붙는 방식으로 줄입니다. 혼자 쓰는 작업은 curl·스크립트(CLI)만으로도 충분한 경우가 많습니다.
Part 5 · 마무리
FAQ
스킬을 쓰라는 게 코딩을 안 하라는 뜻인가요?
아닙니다. 스킬은 「어떻게 할지」를 사람이 코드에 박아두지 말고, AI가 목표를 보고 절차·코드·CLI를 선택하게 하라는 뜻입니다. 필요하면 AI가 그 자리에서 코드를 짜고, 스킬 안의 스크립트를 실행하기도 합니다.
그럼 아예 프로그램을 만들면 안 되나요?
판매·모객·다수 사용자용 제품이라면 프로그램이 맞습니다. 다만 나 혼자 쓰는 이미지 배치, 영상 편집, TTS, 칼럼 포스팅 같은 작업 흐름을 GUI 프로그램으로 굳히면, 수정 비용이 작업 자체보다 커지는 경우가 많습니다.
Agent Skills와 Cursor Skills는 같은 건가요?
개념은 같습니다. SKILL.md에 지침·절차·참고 문서를 담고, 에이전트가 작업 시 로드합니다. Anthropic이 공개한 Agent Skills 표준은 여러 툴이 공유할 수 있도록 설계됐고, Cursor·Claude Code 등에서 같은 패턴을 씁니다.
점진적 공개(Progressive Disclosure)가 왜 중요한가요?
AI 컨텍스트 창은 한정돼 있습니다. 모든 스킬 본문을 한꺼번에 넣으면 둔해지고 헷갈립니다. 이름·설명만 먼저 올리고, 필요할 때만 본문·reference·스크립트를 열면 스킬 수와 정보량을 크게 늘릴 수 있습니다.
MCP는 이제 안 쓰나요?
혼자 쓰는 빠른 작업·사이트 관리에는 CLI(curl, npm 스크립트, wrangler 등)가 더 가볍고 직접적입니다. 팀 공유·권한·감사가 중요한 환경에서는 MCP가 여전히 강점이 있습니다. 둘 중 하나가 정답이 아니라 용도로 고릅니다.
영상처럼 이미지 자동 배치를 프로그램으로 만들면 안 되나요?
강의 판매·시청자 모객용 데모라면 괜찮습니다. 본인 작업용이라면 대본에 맞는 이미지 배치·길이 변경·후킹 변형을 스킬(예: video-longform-to-shortform, column-posting)과 AI 지시로 처리하는 편이 수정 부담이 적습니다.
스킬은 어디서부터 만들면 되나요?
실제로 자주 하는 작업 하나를 AI에게 시켜보고, 실패·헷갈리는 지점을 메모합니다. 그다음 .cursor/skills/아래에 SKILL.md를 만들고 name·description·트리거 키워드·완료 기준(DoD)·연관 스킬 링크를 적습니다. 이 저장소는 cursor-skill-list가 라우팅 인덱스 역할을 합니다.
바이브 코딩을 조금만 해봤는데, 이 글이 도움이 될까요?
Cursor나 Codex로 기능 하나 만든 경험이 있으면 「코드 고치느라 시간 쓰는 것」과 「말 한마디로 끝나는 것」의 차이를 체감하기 쉽습니다. 프로그램 대신 스킬을 쌓을수록 같은 유형의 작업이 빨라지고, 수정은 자연어로 끝납니다.
MCP와 스킬은 같은 건가요?
아닙니다. MCP는 AI가 외부 도구·데이터에 접속하는 연결 규격(프로토콜)이고, 스킬은 그 안에서 「어떤 순서로·어떤 기준으로 일할지」 적어 둔 매뉴얼입니다. MCP 서버로 GitHub API를 열어두고, 스킬로 「PR 만들 때 이 체크리스트 따르기」를 적는 식으로 함께 씁니다.
CLI만 쓰면 MCP는 완전히 필요 없나요?
1인·단일 저장소 작업만 한다면 CLI+스킬만으로 충분한 경우가 많습니다. 여러 SaaS를 팀이 공유하거나, 권한·감사 로그가 필요하면 MCP 서버 한 번 만들어 두고 여러 AI 클라이언트가 붙는 편이 낫습니다. 「MCP 안 쓴다」는 뜻은 「연결 표준 없이 curl·스크립트로 직접 한다」에 가깝지, 외부 연동 자체를 안 한다는 뜻은 아닙니다.
SKILL.md와 .cursor/rules 차이는?
Rules(.mdc)는 저장소 전체에 항상 걸리는 규칙(커밋 금지 경로, 코딩 스타일)입니다. SKILL.md는 특정 작업 요청이 왔을 때만 읽는 절차서입니다. 칼럼 작성 로직은 column-posting 스킬, Git 금지 경로는 gitignore-local-only 규칙처럼 나눕니다.
스킬을 만드는 전용 스킬이 있나요?
있습니다. Claude 쪽은 skill-creator(플러그인·Claude Code)가 설명만으로 SKILL.md 초안·트리거 문구·구조를 제안합니다. Cursor에는 create-skill 스킬이 있고, 대화로 「방금 한 일을 스킬로 정리해줘」라고 해도 됩니다. 워크플로를 따라가면 보통 30분 안팎에 첫 스킬 초안을 만들 수 있다는 체감이 커뮤니티 후기에 많습니다(처음부터 손으로 쓰면 더 걸릴 수 있음).
SKILL.md description은 왜 그렇게 중요한가요?
에이전트는 처음에 name·description만 보고 「지금 이 스킬을 열까」를 판단합니다. description에 트리거 키워드(칼럼, 위키, 커푸배 등)와 사용 시점을 한 문단에 넣지 않으면, 아무리 본문이 좋아도 스킬이 로드되지 않습니다. Claude Code 문서는 description+when_to_use 합쳐 약 1,536자까지 목록에 실리고, 전체 스킬 description 합산 약 15k자 예산을 넘으면 일부 스킬이 목록에서 빠질 수 있다고 안내합니다.
스킬+AI는 매번 똑같이 동작하나요?
아닙니다. 같은 지시를 줘도 AI가 스킬을 해석하는 순서·표현은 실행마다 달라질 수 있습니다. 그래서 회계·규제처럼 재현성이 중요한 영역은 프로그램이 유리하고, 스킬을 쓸 때도 lint·검증 스크립트·고정 CLI 단계를 scripts/에 두어 결정적인 부분만 코드로 박습니다.
외부 스킬·CLI 자동화는 안전한가요?
편의만큼 위험도 커집니다. 출처를 모르는 스킬은 프롬프트 인젝션·데이터 유출 가능성이 있어 Anthropic도 설치 전 검토를 권합니다. 터미널 권한·비밀 경로·force push 금지는 SKILL.md와 Rules에 명시하고, 자세한 체크리스트는 관련 칼럼 「바이브 코딩과 보안」을 참고하세요.
스킬 설계에서 가장 먼저 정할 것은?
「이 스킬이 끝나는 조건(DoD)」과 「언제 자동으로 켜질지(description)」입니다. 그다음 단계 순서, 금지 사항, 연관 스킬 링크 순입니다. How(어떤 파일을 열지)는 AI에게 맡기고, What/Why와 품질 기준만 문서에 남깁니다.