Claude Skills는 왜 Agent에게 필요한가

Claude Skills는 Claude에게 특정 작업 방식을 가르치기 위한 패키지 구조다. Anthropic은 이를 Skills라는 이름으로 소개했고, Claude Code 문서에서는 Skill을 SKILL.md 파일과 필요한 스크립트, 참고 자료, 리소스를 담는 디렉터리로 설명한다. 핵심은 단순하다. 모든 지식을 프롬프트 한 번에 밀어 넣지 않고, 필요한 순간에 필요한 절차와 자료만 모델에게 노출한다.

내가 이 기능을 중요하게 보는 이유는 Skills가 단순한 프롬프트 템플릿이 아니기 때문이다. Skills는 LLM Agent가 커지면서 반복적으로 부딪힌 문제, 즉 컨텍스트 과부하와 도구 사용의 불안정성을 줄이려는 설계에 가깝다. Agent가 잘 작동하려면 모델이 작업 목표를 이해하고, 적절한 도구를 고르고, 중간 결과를 해석하고, 다음 행동을 결정해야 한다. 이 과정에서 매번 모든 설명을 한꺼번에 제공하면 오히려 성능이 흔들릴 수 있다.

Progressive Disclosure 개념을 설명하는 인터페이스 예시

Progressive Disclosure는 필요한 정보만 단계적으로 드러내는 설계 원칙이다. 출처: Gapsy Studio

Skills를 한 문장으로 정리하면

Claude Skills는 특정 작업을 수행하는 방법을 Claude가 필요할 때 읽어 들일 수 있게 만든 작업 지식 패키지다.

예를 들어 회사 내부 보고서를 만드는 Skill이 있다면, 그 안에는 보고서 형식, 금지 표현, 데이터 처리 스크립트, 예시 파일, 체크리스트가 들어갈 수 있다. Claude는 사용자의 요청이 이 Skill과 관련 있다고 판단하면 먼저 간단한 설명을 보고, 더 필요한 경우 세부 파일이나 스크립트를 읽어 작업을 진행한다.

이 구조는 사람이 업무를 배울 때와 비슷하다. 모든 사내 규칙을 머릿속에 한꺼번에 넣고 시작하지 않는다. 먼저 어떤 업무인지 파악하고, 필요한 문서와 예시를 찾아보고, 필요한 도구를 실행하면서 결과를 만든다. Skills는 이 흐름을 LLM Agent 쪽으로 옮긴 설계다.

Progressive Disclosure라는 배경

Skills를 이해하려면 Progressive Disclosure를 먼저 봐야 한다. Progressive Disclosure는 사용자가 처음부터 모든 정보를 보지 않게 하고, 필요한 시점에 더 자세한 정보를 단계적으로 보여주는 설계 원칙이다. Nielsen Norman Group은 progressive disclosure를 고급 기능이나 드문 정보를 뒤로 미뤄 초기 복잡도를 낮추는 상호작용 설계로 설명한다.

이 원칙은 UI에서 자주 쓰인다. 처음 화면에는 핵심 버튼만 보여주고, 고급 설정은 접힌 영역이나 별도 메뉴에 둔다. 사용자는 기본 작업을 빠르게 시작하고, 더 복잡한 작업이 필요할 때만 추가 정보를 연다.

LLM Agent에서도 같은 문제가 생긴다. 모델에게 너무 많은 지침, 도구 설명, 예외 규칙, 예시를 한꺼번에 넣으면 컨텍스트가 길어진다. 컨텍스트가 길어질수록 모델은 중요한 조건을 놓치거나, 현재 작업과 무관한 지침에 영향을 받을 수 있다. 따라서 Agent 설계에서는 필요한 정보를 필요한 순간에 제공하는 방식이 중요해진다.

Skills는 이 관점에서 Progressive Disclosure를 Agent 메모리와 도구 사용 영역에 적용한 형태로 볼 수 있다. Skill의 최상위 설명은 짧고, 세부 절차와 자료는 필요할 때만 펼쳐진다. 모델은 먼저 어떤 Skill이 관련 있는지 판단하고, 그다음 필요한 파일을 읽거나 스크립트를 실행한다.

왜 프롬프트 하나로는 부족했는가

초기의 LLM 활용은 대부분 프롬프트 중심이었다. 사용자가 긴 지시문을 작성하고, 모델은 그 지시문 안에서 답을 만들었다. 간단한 작업에는 이 방식이 충분하다. 하지만 Agent가 실제 업무를 맡기 시작하면 프롬프트 하나만으로는 한계가 드러난다.

첫 번째 한계는 컨텍스트 비용이다. 모든 업무 규칙과 예시를 매번 프롬프트에 넣으면 입력 토큰이 커진다. 비용만의 문제가 아니다. 모델이 현재 작업에 필요한 핵심 정보를 찾는 부담도 커진다.

두 번째 한계는 재사용성이다. 같은 업무 지식을 여러 프롬프트에 복사하면 버전 관리가 어려워진다. 규칙이 바뀌었을 때 모든 프롬프트를 고쳐야 한다. Skills는 업무 지식을 파일 단위로 묶어 재사용할 수 있게 만든다.

세 번째 한계는 실행 능력이다. 실제 업무에는 계산, 파일 변환, 데이터 정제, API 호출 같은 절차가 섞인다. 자연어 설명만으로는 일관된 결과를 내기 어렵다. Skill 안에 스크립트를 포함하면 모델은 설명을 읽는 데서 끝나지 않고, 필요한 실행 절차를 함께 사용할 수 있다.

Tool Use에서 Skills까지의 흐름

Skills는 갑자기 등장한 독립 기능이라기보다, LLM을 Agent로 만들기 위한 흐름 위에 있다. 이 흐름을 간단히 정리하면 프롬프트, Tool Use, MCP, Skills로 이어진다.

Anthropic은 Claude가 외부 도구를 호출할 수 있는 tool use를 제공한다. Tool Use는 모델이 답변만 생성하는 것이 아니라, 정의된 도구를 선택하고 입력값을 만들어 호출하는 방식이다. 예를 들어 날씨 API, 데이터베이스 조회, 코드 실행기 같은 도구를 모델이 사용할 수 있다.

Tool Use는 Agent의 행동 범위를 넓혔다. 하지만 도구가 많아질수록 또 다른 문제가 생긴다. 모델은 어떤 도구를 언제 써야 하는지 알아야 하고, 도구 호출 전후의 절차도 이해해야 한다. 도구 설명을 모두 컨텍스트에 넣으면 다시 컨텍스트 과부하가 생긴다.

이후 Anthropic은 외부 시스템과 AI 애플리케이션을 연결하기 위한 Model Context Protocol을 공개했다. MCP는 모델이 데이터 소스와 도구에 접근하는 방식을 표준화하려는 시도다. MCP가 연결의 표준화에 가깝다면, Skills는 특정 작업을 수행하는 방법의 패키징에 가깝다.

정리하면 Tool Use는 모델이 도구를 쓸 수 있게 만들었고, MCP는 도구와 데이터 연결 방식을 정리했으며, Skills는 그 도구와 자료를 어떤 절차로 써야 하는지 작업 단위로 묶는다.

Skills의 구조

Claude Code의 Skills 문서는 Skill을 디렉터리 구조로 설명한다. 하나의 Skill은 보통 SKILL.md를 중심으로 구성된다. 이 파일에는 Skill의 이름, 설명, 사용 조건, 작업 절차가 들어간다. 필요한 경우 같은 디렉터리에 스크립트, 템플릿, 참고 문서, 예시 파일을 함께 둔다.

중요한 점은 SKILL.md가 단순한 긴 설명서가 아니라는 것이다. Skill 설명은 모델이 이 Skill을 언제 써야 하는지 판단할 수 있게 충분히 명확해야 한다. 동시에 모든 세부 정보를 처음부터 담아 컨텍스트를 낭비하지 않아야 한다.

Skill은 보통 다음과 같은 정보를 담는다.

어떤 상황에서 이 Skill을 사용해야 하는지
작업을 어떤 순서로 진행해야 하는지
필요한 입력과 출력 형식은 무엇인지
사용할 수 있는 스크립트나 파일은 무엇인지
결과를 검증할 때 확인할 조건은 무엇인지

이 구조는 Agent에게 업무 매뉴얼을 주는 것과 비슷하다. 다만 매뉴얼 전체를 처음부터 펼쳐 놓는 대신, 목차와 핵심 설명을 먼저 주고 필요한 세부 항목만 읽게 만든다.

여러 번의 Tool Call이 왜 중요해졌는가

Agent가 복잡한 일을 처리할 때는 한 번의 도구 호출로 끝나지 않는 경우가 많다. 예를 들어 PDF 보고서를 생성하는 작업을 생각할 수 있다. Agent는 먼저 사용자의 요구사항을 해석하고, 원본 데이터를 읽고, 통계를 계산하고, 차트를 만들고, 문서를 조립하고, 마지막으로 결과 파일을 검증해야 한다.

이 과정은 여러 단계의 Tool Call로 구성된다.

파일 목록 조회
원본 데이터 읽기
데이터 정제 스크립트 실행
차트 생성
문서 템플릿 적용
결과 파일 저장
산출물 검증

도구 호출이 많아질수록 Agent는 현재 단계가 전체 절차에서 어디에 해당하는지 알아야 한다. 단순히 도구 목록만 주면 부족하다. 작업의 순서, 중간 결과의 의미, 실패했을 때의 대처 방식이 필요하다.

Skills는 이런 다단계 작업의 절차를 담는 데 적합하다. Skill은 도구 자체가 아니라, 도구들을 엮어 하나의 업무를 완성하는 방법을 설명한다. 이 점에서 Skills는 Tool Call을 대체하지 않는다. 오히려 Tool Call이 많아질수록 필요한 상위 레이어에 가깝다.

AI Agent가 여러 도구와 단계를 거쳐 작업을 수행하는 워크플로우 다이어그램

Agent 작업은 여러 단계의 도구 호출과 검증으로 구성된다. 출처: Softude

Skills와 RAG는 어떻게 다른가

Skills를 RAG와 혼동하기 쉽다. 둘 다 필요한 정보를 외부에서 가져온다는 점은 비슷하다. 하지만 목적이 다르다.

RAG는 보통 질문에 답하기 위해 관련 문서를 검색해 컨텍스트에 넣는 방식이다. 핵심은 지식 검색이다. 사용자가 특정 규정, 제품 정보, 문서 내용을 물으면 관련 문단을 찾아 모델에게 제공한다.

Skills는 작업 수행 방법을 담는다. 핵심은 절차와 실행이다. 어떤 파일을 읽어야 하는지, 어떤 스크립트를 실행해야 하는지, 어떤 형식으로 결과를 만들어야 하는지를 정의한다.

간단히 말하면 RAG는 “무엇을 알아야 하는가”에 가깝고, Skills는 “어떻게 해야 하는가”에 가깝다. 실제 시스템에서는 둘을 함께 쓸 수 있다. Skill이 작업 절차를 제공하고, 그 과정에서 RAG가 필요한 근거 문서를 찾아주는 식이다.

Skills와 시스템 프롬프트의 차이

시스템 프롬프트는 모델의 전반적인 행동 원칙을 정하는 데 적합하다. 예를 들어 보안 규칙, 답변 톤, 금지 행동, 전체 애플리케이션의 역할을 담을 수 있다. 하지만 모든 업무별 절차를 시스템 프롬프트에 넣으면 시스템 프롬프트가 비대해진다.

Skills는 업무별 지식을 분리한다. 보고서 작성 Skill, 데이터 정제 Skill, 고객 응대 Skill, 코드 리뷰 Skill을 각각 따로 둘 수 있다. 모델은 사용자의 요청에 맞는 Skill만 선택한다.

이 차이는 운영에서 중요하다. 시스템 프롬프트는 자주 바꾸기 어렵고 영향 범위가 넓다. Skill은 특정 작업 단위로 관리할 수 있어 수정과 실험이 쉽다. 조직 안에서 업무별 담당자가 Skill을 관리하는 방식도 가능하다.

연구자들의 고민이 드러나는 지점

Anthropic이 Building effective agents에서 강조한 방향은 복잡한 프레임워크보다 단순하고 조합 가능한 패턴을 선호하는 쪽에 가깝다. 해당 글은 워크플로우와 Agent를 구분하고, 모델이 도구를 사용하면서 피드백을 받아 반복하는 패턴을 설명한다.

Skills는 이 고민과 맞닿아 있다. Agent를 잘 만들기 위해 모든 것을 거대한 프롬프트나 복잡한 오케스트레이터에 넣는 대신, 작업 지식을 작은 단위로 나누고 필요할 때 불러오는 방식이다. 이는 Agent 시스템을 더 관찰 가능하고, 더 수정 가능하며, 더 재사용 가능하게 만든다.

여기서 중요한 철학은 모델을 전지전능한 하나의 함수처럼 다루지 않는다는 점이다. 모델은 판단과 생성에 강하지만, 모든 절차와 자료를 항상 머릿속에 들고 있을 필요는 없다. 필요한 지식은 외부에 정리해 두고, 모델은 상황에 따라 그것을 읽고 실행한다.

초보자를 위한 예시

블로그 글을 자동으로 다듬는 Skill을 만든다고 가정한다. 이 Skill은 다음과 같은 구조를 가질 수 있다.

blog-editor/
  SKILL.md
  style-guide.md
  banned-words.md
  examples/
    good-post.md
    bad-post.md
  scripts/
    check-links.py

SKILL.md에는 이 Skill을 언제 써야 하는지와 전체 절차를 적는다. style-guide.md에는 문체 규칙을 둔다. banned-words.md에는 피해야 할 표현을 둔다. check-links.py는 글 안의 링크가 살아 있는지 검사한다.

사용자가 “이 글을 내 블로그 톤으로 다듬어 줘”라고 요청하면 Claude는 이 Skill이 관련 있다고 판단한다. 먼저 SKILL.md를 읽고, 필요하면 스타일 가이드와 예시를 참고한다. 마지막에는 링크 검사 스크립트를 실행해 결과를 검증할 수 있다.

이 예시에서 중요한 것은 Skill이 답변 문구 몇 줄을 저장한 것이 아니라는 점이다. Skill은 작업의 판단 기준, 절차, 참고 자료, 검증 방법을 함께 담는다.

Skills를 잘 만들기 위한 원칙

Skills를 만들 때 가장 중요한 원칙은 작게 나누는 것이다. 하나의 Skill이 너무 많은 업무를 담당하면 다시 거대한 프롬프트와 비슷해진다. Skill은 모델이 “이 작업에는 이 Skill이 맞다”고 판단할 수 있을 정도로 명확해야 한다.

두 번째 원칙은 설명과 자료를 분리하는 것이다. SKILL.md에는 사용 조건과 핵심 절차를 간결하게 둔다. 긴 예시, 대형 문서, 스크립트는 별도 파일로 둔다. 이렇게 해야 Progressive Disclosure의 장점이 살아난다.

세 번째 원칙은 검증 단계를 포함하는 것이다. Agent는 실행 과정에서 실수할 수 있다. 따라서 결과를 만든 뒤 무엇을 확인해야 하는지 Skill 안에 적어 두는 편이 좋다. 파일 생성 여부, 출력 형식, 누락된 필드, 링크 유효성 같은 검증 조건이 여기에 해당한다.

네 번째 원칙은 도구 호출을 절차 속에 배치하는 것이다. “필요하면 도구를 사용하라”보다 “먼저 입력 파일을 확인하고, 그다음 정제 스크립트를 실행하고, 실패하면 오류 로그를 읽어라”가 더 안정적이다. Agent는 자유도가 너무 높을 때보다 적절한 절차가 있을 때 더 예측 가능하게 움직인다.

Skills가 해결하려는 문제

Skills가 해결하려는 문제는 기능 추가라기보다 운영 문제다. Agent를 실제 업무에 넣으면 다음 문제가 반복된다.

프롬프트가 계속 길어진다.
업무 지식이 여러 곳에 복사된다.
도구가 많아질수록 선택이 불안정해진다.
중간 실패를 복구하는 절차가 약하다.
결과 검증이 사람에게만 의존한다.

Skills는 이 문제를 작업 단위 패키징으로 줄인다. 업무 지식을 한곳에 모으고, 필요한 순간에만 노출하며, 도구 사용 절차와 검증 기준을 함께 제공한다. 그래서 Skills는 단순한 편의 기능보다 Agent 운영을 위한 설계 패턴에 가깝다.

정리

Claude Skills의 핵심은 점진적 공개다. 모든 정보를 한 번에 모델에게 주는 대신, Skill 설명을 통해 관련성을 판단하고, 필요한 세부 자료와 스크립트를 단계적으로 읽게 만든다.

이 철학은 UI 설계의 Progressive Disclosure와 닮아 있다. 초기에 보여줄 것은 줄이고, 필요한 순간에 복잡도를 펼친다. LLM Agent에서는 이 방식이 컨텍스트 관리, 도구 선택, 다단계 작업 수행에 직접적인 의미를 가진다.

Tool Use가 모델에게 행동 능력을 줬다면, Skills는 그 행동을 업무 단위로 조직하는 방법을 제공한다. MCP가 외부 시스템과의 연결 방식을 정리했다면, Skills는 연결된 도구와 자료를 어떻게 써서 결과를 만들지 정리한다.

결국 Skills는 Agent를 더 크게 만드는 기능이 아니라, Agent가 커져도 다룰 수 있게 만드는 구조다. 이 점이 Claude Skills를 단순한 프롬프트 묶음이 아니라 Agent 설계의 중요한 진화로 보게 만드는 지점이다.

Claude Skills는 왜 Agent에게 필요한가