Claude Code 스킬·워크플로우·에이전트 차이: 3가지 구분법과 실전 가이드

스킬, 워크플로우, 에이전트. AI를 조금만 사용하다 보면 계속 마주치는 단어예요. 문제는 설명을 읽어도 셋이 비슷하게 느껴진다는 것입니다.

스킬도 일을 시키는 방법 같고, 워크플로우도 일을 시키는 방법 같고, 에이전트도 결국 AI가 일하게 만드는 방법처럼 보이니까요.

하지만 용어를 전부 외울 필요는 없어요. 지금 내 앞에 있는 일을 보면서 질문 하나만 하면 됩니다.

이 일의 단계를 내가 미리 적을 수 있나요?

단계를 적을 수 있다면 스킬이나 워크플로우부터 검토하세요. 결과를 보면서 다음 행동을 계속 판단해야 한다면 에이전트가 더 잘 맞습니다.

이 질문은 빠르게 고르는 실무용 기준이지 세 개념을 가르는 절대적인 기술 규칙은 아닙니다. 스킬 안에도 여러 단계나 에이전트 실행을 넣을 수 있고, 에이전트도 정해진 절차를 따를 수 있어요. 핵심은 AI에게 재사용할 방법을 줄지, 고정된 순서를 실행시킬지, 상황에 따른 판단을 맡길지입니다.

이 글에서는 세 개념의 차이만 설명하지 않습니다. 실제로 어떤 파일을 만들면 되는지, 어떤 내용을 넣어야 하는지, 내 업무를 셋 중 하나로 진단하는 프롬프트까지 모두 정리해볼게요.

바쁜 사람을 위한 한눈에 보기

가장 중요한 차이는 AI에게 방법을 줄 것인지, 판단을 맡길 것인지입니다.

주방으로 이해하면 3초면 됩니다

머릿속에 주방 하나를 떠올려보세요.

• 스킬은 레시피 카드입니다. 김치찌개 하나를 어떤 재료와 순서로 만드는지 적혀 있어요.
• 워크플로우는 조리 라인입니다. 주문 접수, 조리, 검수, 포장이 항상 같은 순서로 진행돼요.
• 에이전트는 셰프입니다. “냉장고에 있는 재료로 저녁을 차려줘”라고 하면 재료를 확인하고 메뉴와 조리 순서를 직접 결정해요.

여기서 한 가지 주의할 점이 있습니다. 이 셋은 서로 완전히 분리된 도구가 아니에요. 셰프가 레시피 카드를 사용할 수 있듯이 에이전트도 스킬을 사용할 수 있습니다. 하나의 워크플로우가 여러 스킬을 순서대로 실행할 수도 있고요.

실제 업무에서는 셋을 조합하는 경우가 많지만, 처음부터 복잡하게 만들 필요는 없습니다. 가장 작은 스킬 하나로 시작하고, 정말 필요할 때 워크플로우와 에이전트로 확장하는 편이 좋습니다.

1. 스킬: 같은 설명을 반복하고 있다면

스킬은 특정 업무를 어떻게 처리해야 하는지 적어둔 재사용 가능한 지시문입니다.

예를 들어 블로그 글을 부탁할 때마다 아래 내용을 반복해서 말하고 있다고 해볼게요.

• 쉬운 단어를 사용할 것
• 첫 문단에서 독자의 문제를 짚을 것
• 소제목마다 실제 예시를 넣을 것
• 과장된 표현을 사용하지 않을 것
• 마지막에 실행할 수 있는 프롬프트를 제공할 것

이 기준은 작업할 때마다 달라지는 판단이 아니라 항상 유지하고 싶은 나만의 방식입니다. 이런 내용을 스킬로 저장해두면 매번 다시 입력하지 않아도 됩니다.

Claude Code의 프로젝트 스킬은 다음과 같은 폴더 구조로 만듭니다.

.claude/
└── skills/
    └── blog-writer/
        └── SKILL.md

직접 호출할 때 사용하는 /blog-writer라는 이름은 기본적으로 폴더명에서 나옵니다. SKILL.md의 name 항목은 표시 이름을 따로 지정할 때 사용할 수 있어요. 참고 자료, 템플릿, 스크립트 등을 같은 폴더에 함께 넣을 수 있기 때문에 스킬은 폴더 단위로 구성됩니다.

바로 써보는 블로그 작성 스킬

아래 내용을 .claude/skills/blog-writer/SKILL.md에 저장해보세요.

---
name: blog-writer
description: 쉬운 설명과 실용적인 예시가 포함된 블로그 글을 작성할 때 사용합니다.
---

# 블로그 글 작성

사용자가 주제와 독자를 알려주면 다음 기준으로 글을 작성합니다.

1. 첫 문단에서 독자가 겪는 문제를 구체적으로 보여줍니다.
2. 어려운 용어는 일상적인 비유로 먼저 설명합니다.
3. 각 소제목에는 실제 상황이나 예시를 하나 이상 넣습니다.
4. 독자가 그대로 복사할 수 있는 프롬프트나 템플릿을 제공합니다.
5. 확인되지 않은 통계나 과장된 표현은 사용하지 않습니다.
6. 마지막에는 오늘 바로 할 수 있는 행동 하나를 제안합니다.

작성 전에 다음 입력값이 있는지 확인합니다.

- 글의 주제
- 주요 독자
- 글의 목적
- 원하는 분량
- 반드시 포함할 내용

정보가 부족하면 가장 중요한 질문부터 하나씩 확인합니다.

저장한 뒤에는 이렇게 요청할 수 있습니다.

/blog-writer

주제: 생성형 AI로 고객 문의 답변 시간을 줄이는 방법
독자: 혼자 쇼핑몰을 운영하는 초보 사업자
목적: 바로 적용할 수 있는 방법 알려주기
분량: 2,000자 안팎
반드시 포함할 내용: 답변 템플릿 예시와 주의점

스킬은 사용자가 /blog-writer처럼 직접 부를 수도 있고, description과 관련된 요청이 들어왔을 때 Claude가 선택해서 사용할 수도 있습니다. Claude는 평소 스킬의 설명을 보고 사용할지 판단하며, 전체 지시문은 스킬이 호출될 때 대화 맥락에 들어옵니다. 자동 실행되면 곤란한 배포나 발송 작업은 disable-model-invocation: true를 추가해 사용자가 직접 호출할 때만 실행되도록 설정할 수 있습니다.

2. 워크플로우: 순서가 항상 같다면

워크플로우는 Claude Code의 고유한 파일 종류라기보다 업무를 정해진 순서로 실행하는 설계 방식에 가깝습니다.

예를 들어 영상 하나를 여러 콘텐츠로 바꾸는 업무를 생각해볼게요.

1. 영상의 핵심 내용을 요약합니다.
2. 블로그 글 초안을 작성합니다.
3. 인스타그램 캐러셀을 만듭니다.
4. 이메일 뉴스레터를 작성합니다.
5. 사용자가 검토한 뒤 최종본을 저장합니다.

입력하는 영상은 달라져도 순서와 결과물은 같습니다. Claude가 다음 단계를 새로 고민할 필요가 없어요. 이런 일이 워크플로우에 적합합니다.

Claude Code에 반드시 사용해야 하는 WORKFLOW.md 표준 형식은 없습니다. 가장 간단한 방법은 워크플로우의 단계와 승인 지점을 스킬 안에 적는 것입니다. 더 엄격한 자동 실행이 필요하다면 셸 스크립트, 훅, CI 같은 도구로 구현할 수도 있어요. 즉 워크플로우는 파일의 이름이 아니라 단계가 연결되는 방식입니다.

바로 써보는 콘텐츠 재활용 워크플로우

---
name: content-repurpose
description: 영상이나 원문 하나를 블로그, 인스타그램, 이메일 콘텐츠로 바꿀 때 사용합니다.
disable-model-invocation: true
---

# 콘텐츠 재활용 워크플로우

입력받은 원문을 다음 순서로 처리합니다.

## 1단계: 원문 분석

- 핵심 주장 3개를 추출합니다.
- 주요 독자와 독자가 얻을 이익을 정리합니다.
- 빠진 정보나 확인이 필요한 주장을 표시합니다.

분석 결과를 보여주고 사용자의 승인을 기다립니다.

## 2단계: 블로그 글

- 문제 제기, 핵심 설명, 사례, 실행 방법 순서로 작성합니다.
- 독자가 복사할 수 있는 프롬프트를 포함합니다.

## 3단계: 인스타그램 캐러셀

- 커버와 CTA를 포함해 최대 9장으로 구성합니다.
- 한 장에는 하나의 메시지만 담습니다.

## 4단계: 이메일

- 블로그 글의 핵심을 500자 이내로 요약합니다.
- 전체 글로 이동하는 CTA를 한 번만 넣습니다.

## 5단계: 최종 검토

- 세 결과물의 핵심 메시지가 일치하는지 확인합니다.
- 사용자의 승인 전에는 게시하거나 발송하지 않습니다.

이 예시에서 중요한 부분은 각 단계보다 승인 지점입니다. 초안 작성처럼 되돌리기 쉬운 작업은 자동으로 진행해도 괜찮지만, 게시·발송·삭제처럼 외부에 영향을 주는 작업은 반드시 사람의 확인을 거치도록 만드는 것이 안전합니다.

3. 에이전트: 다음 행동을 미리 정할 수 없다면

에이전트는 체크리스트를 그대로 실행하는 도구가 아닙니다. 목표와 사용할 수 있는 도구를 받은 뒤, 상황을 살펴보며 필요한 단계를 스스로 결정합니다.

예를 들어 “이번 주 광고비가 새는 곳을 찾아줘”라는 요청은 처음부터 정확한 단계를 적기 어렵습니다.

어떤 캠페인에 문제가 있는지, 소재가 문제인지 타기팅이 문제인지, 이전 주와 무엇이 달라졌는지에 따라 살펴볼 경로가 계속 달라지기 때문입니다. 이런 일은 정해진 워크플로우보다 광고 분석 에이전트에 더 잘 맞습니다.

Claude Code의 프로젝트 서브에이전트는 다음 위치에 마크다운 파일로 만들 수 있습니다.

.claude/
└── agents/
    └── content-researcher.md

바로 써보는 콘텐츠 리서치 에이전트

---
name: content-researcher
description: 블로그 글에 필요한 최신 자료와 근거를 조사할 때 사용합니다.
tools: WebSearch, WebFetch, Read, Grep
model: sonnet
---

당신은 콘텐츠 리서처입니다.

목표는 작성자가 신뢰할 수 있는 근거를 바탕으로 글을 쓸 수 있도록
핵심 사실, 사례, 반론과 출처를 정리하는 것입니다.

항상 다음 원칙을 지킵니다.

1. 공식 문서와 1차 출처를 우선합니다.
2. 게시일과 실제 사건이 발생한 날짜를 구분합니다.
3. 확인되지 않은 주장은 사실처럼 표현하지 않습니다.
4. 자료가 서로 충돌하면 양쪽 근거를 함께 보여줍니다.
5. 조사 결과에 따라 다음 검색 경로를 스스로 결정합니다.

최종 결과에는 다음 내용을 포함합니다.

- 핵심 발견
- 글에 사용할 수 있는 구체적인 사례
- 주의해서 표현해야 하는 주장
- 각 항목의 출처 링크
- 추가 확인이 필요한 내용

일반적인 서브에이전트는 메인 대화와 분리된 맥락에서 위임받은 작업을 처리하고 결과를 돌려줍니다. 다만 context: fork로 실행하는 스킬처럼 부모 대화의 맥락을 이어받는 방식도 있으므로 모든 에이전트가 항상 완전히 같은 방식으로 격리되는 것은 아닙니다. 긴 조사 내용이나 로그가 메인 대화를 가득 채우지 않게 하거나, 독립된 전문 작업을 맡길 때 유용합니다.

다만 에이전트가 항상 더 좋은 선택은 아닙니다. 독립된 맥락에서 탐색하고 도구를 여러 번 사용하면 단순한 스킬보다 토큰, 시간, 비용이 더 들 수 있어요. 이미 순서를 알고 있는 업무라면 에이전트보다 워크플로우가 더 단순하고 결과를 예측하기 쉽습니다.

같은 업무를 세 가지로 만들면 어떻게 다를까요?

“매주 경쟁사 콘텐츠를 분석한다”는 업무로 비교해보겠습니다.

스킬로 만들 때

분석할 때 항상 적용할 기준을 저장합니다.

각 콘텐츠를 주제, 첫 문장, 핵심 주장, CTA, 반응으로 나누어 분석하고
마지막에 우리 콘텐츠에 적용할 아이디어 3개를 제안해줘.

사용자가 분석할 콘텐츠를 직접 주고, Claude는 저장된 기준에 맞춰 분석합니다.

워크플로우로 만들 때

매주 같은 순서로 진행합니다.

경쟁사 게시물 수집 → 항목별 분류 → 지난주와 비교 → 보고서 작성 → 담당자 승인

분석 대상과 출력 형식이 정해져 있고, 과정이 매번 거의 같습니다.

에이전트로 만들 때

목표만 주고 조사 경로는 맡깁니다.

이번 주 경쟁사 콘텐츠에서 갑자기 반응이 높아진 주제를 찾아서
원인을 분석하고 우리가 실험할 아이디어를 제안해줘.

에이전트는 어떤 경쟁사를 먼저 볼지, 무엇을 비교할지, 추가 조사가 필요한지를 결과에 따라 결정합니다.

무엇을 만들어야 할지 결정하는 세 가지 질문

업무 하나를 떠올리고 아래 순서대로 물어보세요.

1. 같은 기준을 계속 반복하나요?

그렇다면 스킬부터 만드세요. 브랜드 문체, 검수 기준, 보고서 형식, 고객 답변 원칙처럼 반복해서 설명하는 내용이 좋은 출발점입니다.

2. 시작부터 결과물까지의 순서가 정해져 있나요?

그렇다면 워크플로우로 작성하세요. 각 단계의 입력값과 결과물, 사람이 승인해야 하는 지점을 함께 적으면 됩니다.

3. 결과를 보고 다음 행동을 바꿔야 하나요?

그렇다면 에이전트를 고려하세요. 조사, 디버깅, 성과 분석처럼 처음부터 경로를 확정하기 어려운 업무가 여기에 해당합니다.

둘 이상이 필요할 수도 있습니다. 예를 들어 콘텐츠 전략 에이전트가 자료를 조사하고, 브랜드 문체 스킬을 사용해 초안을 만든 뒤, 콘텐츠 배포 워크플로우가 채널별 결과물을 만드는 식입니다.

하지만 처음부터 세 가지를 모두 만들지는 마세요. 가장 자주 반복하는 설명 하나를 스킬로 바꾸는 것부터 시작하면 됩니다.

내 업무를 대신 진단해주는 프롬프트

아직도 무엇을 만들어야 할지 헷갈린다면 아래 프롬프트를 그대로 복사해 사용해보세요. 대괄호 안만 내 상황에 맞게 바꾸면 됩니다.

내가 반복하거나 번거롭게 처리하는 업무를 AI 시스템으로 만들고 싶어.
이 업무를 스킬, 워크플로우, 에이전트 중 무엇으로 만들어야 할지 진단해줘.

내가 하는 업무:
[예: 고객 문의 메일에 답장하기]

나의 역할:
[예: 1인 쇼핑몰 운영자]

이 일이 잘됐다고 판단하는 기준:
[예: 고객이 한 번에 이해하고 추가 문의가 줄어드는 것]

현재 사용하는 도구:
[예: Gmail, Notion, Claude Code]

다음 순서로 진행해줘.

1. 바로 결론을 내리지 말고, 판단에 필요한 질문을 가장 중요한 것부터 하나씩 물어봐줘.
2. 정보가 충분하면 스킬, 워크플로우, 에이전트 중 가장 적합한 것을 골라줘.
3. 왜 그 방식이 맞는지 쉬운 말로 설명해줘.
4. 둘 이상이 필요하다면 가장 단순한 것부터 시작하는 순서를 알려줘.
5. 스킬이라면 완성된 SKILL.md를 작성해줘.
6. 워크플로우라면 단계, 입력값, 결과물, 승인 지점을 작성하고 SKILL.md에 담아줘.
7. 에이전트라면 역할, 목표, 원칙, 필요한 도구가 포함된 에이전트 파일을 작성해줘.
8. 게시, 발송, 삭제처럼 되돌리기 어려운 행동은 사용자 승인 전까지 실행하지 않도록 설정해줘.
9. 오늘 실제 업무로 시험할 수 있는 가장 작은 첫 단계도 알려줘.

잘못 고르기 쉬운 세 가지 경우

반복 업무라고 무조건 에이전트를 만드는 경우

에이전트라는 단어가 더 강력하게 들리지만, 정해진 형식으로 보고서를 만드는 일에는 불필요할 수 있습니다. 판단이 필요하지 않다면 스킬이나 워크플로우가 더 빠르고 결과도 일정합니다.

스킬 하나에 모든 업무를 넣는 경우

글쓰기, 이미지 제작, 게시, 성과 분석을 하나의 거대한 스킬에 모두 넣으면 수정하기 어려워집니다. 각각의 목적이 다르다면 작은 스킬로 나누고 워크플로우에서 순서대로 연결하는 편이 좋습니다.

자동화와 자동 실행을 혼동하는 경우

단계가 자동으로 이어지는 것과 외부에 자동으로 게시되는 것은 다른 문제입니다. 초안 작성은 자동화하더라도 발송과 게시 전에는 승인 단계를 두세요. 특히 고객 연락, 결제, 파일 삭제가 포함된 작업은 더 보수적으로 설계하는 것이 좋습니다.

자주 묻는 질문

오늘은 스킬 하나만 만들어보세요

스킬, 워크플로우, 에이전트를 전부 이해한 뒤 시작할 필요는 없습니다.

오늘 내가 AI에게 두 번 이상 반복해서 설명한 내용을 하나 찾아보세요. 자주 사용하는 문체일 수도 있고, 회의록을 정리하는 순서일 수도 있고, 상품 소개를 검수하는 기준일 수도 있습니다.

그 내용을 먼저 SKILL.md에 담아보세요. 사용하다 보니 여러 단계가 항상 같은 순서로 이어진다면 워크플로우로 확장하고, 결과에 따라 다음 행동을 계속 바꿔야 한다면 그때 에이전트를 만들면 됩니다.

정리하면 기준은 하나입니다.

복잡한 시스템보다 실제로 한 번 사용한 작은 스킬이 훨씬 가치 있습니다. 오늘 반복한 설명 하나부터 저장해보세요.

함께 읽으면 좋은 글