에이전트를 만들지 마세요. 스킬을 만드세요.

지난달 팀 회의에서 한 동료가 이런 말을 했다.

"요즘 Claude 쓰면서 느낀 건데, 프롬프트가 점점 소설처럼 길어지고 있어. 15페이지짜리 시스템 프롬프트 유지보수하는 게 더 힘들다."

나도 공감했다. 스타일 가이드, 컴포넌트 규칙, API 사용법, 배포 절차. 매 세션 시작마다 이 모든 걸 컨텍스트에 쑤셔 넣고 있었다. 그러다 보니 모델이 10,000토큰 전에 적힌 규칙을 잊어버리기 일쑤였고, 내가 분명히 적어둔 bg-primary 토큰 대신 bg-blue-500을 뱉어내는 걸 보고 있어야 했다.

이때 Anthropic의 Barry Zhang과 Mahesh Murag가 던진 한 줄이 머릿속에 맴돌았다.

"Stop building agents. Start building skills."

에이전트를 새로 만들지 말고, 기존 에이전트에 스킬을 장착하라. 단순해 보이는 이 문장 뒤에는, 2026년 AI 소프트웨어를 만드는 방식의 조용한 재구성이 숨어 있다.

문제는 거대한 프롬프트에 있었다

스킬이라는 개념이 없을 때, 우리가 하던 방식은 이랬다. 모든 걸 하나의 프롬프트에 집어넣는 것. 스타일 가이드, 툴 정의, 컴포넌트 컨벤션, 워크플로우 절차, 도메인 지식. 전부 컨텍스트에 상주하고, 전부 매번 로딩된다.

이건 예측 가능한 방식으로 망가진다. 모델은 컨텍스트 한계에 부딪히고, 그 한계에 닿기도 전에 성능이 저하된다. 10,000토큰 앞에 적힌 규칙을 잊어버린다. 디자인 시스템에서 벗어난다. 내가 명시적으로 적어둔 컴포넌트 props를 환각해서 만들어낸다. 15페이지짜리 시스템 프롬프트로 전체 프론트엔드 스택을 커버하려는 팀에게 물어보라. 그들은 이게 얼마나 고통스러운지 안다.

스킬은 이 구조를 뒤집는다. 에이전트는 자신이 할 수 있는 일들에 대한 슬림한 인덱스만 유지한다. 그리고 작업이 필요할 때만 해당 능력을 로드한다. 작고, 테스트되고, 재사용 가능한 플레이북. 온디맨드. 한꺼번에 모든 것이 되려는 거대한 프롬프트가 아니다.

스킬이란 결국 하나의 폴더다

Barry가 Anthropic 세션에서 말한 대로, 이건 의도적으로 단순하게 설계됐다. "컴퓨터만 있다면 누구나, 사람이든 에이전트든 만들고 사용할 수 있는 것을 원했다."

Claude Code와 Google Antigravity 모두 같은 방식으로 스킬을 정의한다. Antigravity 문서는 이렇게 말한다. 스킬은 에이전트 능력을 확장하는 오픈 표준이다. 스킬은 SKILL.md 파일을 포함하는 폴더이며, 에이전트가 특정 작업을 할 때 따를 수 있는 지침을 담는다.

그 폴더 안에는 세 가지 콘텐츠가 들어간다.

SKILL.md가 핵심이다. YAML 프론트매터를 가진 마크다운 파일로, 이 스킬이 무엇을 하는지, 언제 사용하는지, 어떻게 사용하는지를 알려준다.

Scripts는 결정론적 작업을 처리한다. JS, Python, 쉘. 매번 같은 결과를 내야 할 때, 모델이 매 세션 처음부터 코드를 다시 짜는 대신 테스트된 스크립트를 실행한다.

Resources는 정적 참조 파일이다. 템플릿, 디자인 토큰, 스키마. 추상적인 지침을 구체적인 사례에 연결해준다.

스킬이 그냥 폴더이기 때문에, Git도 되고 Google Drive도 되고, zip으로 메일로내도 된다. 새로운 인프라가 필요 없다.

이건 그냥 정리된 프롬프트 모음이 아니다

스킬을 단순한 텍스트 파일 정리와 구분하는 건 로딩 메커니즘이다.

에이전트는 모든 스킬을 프롬프트에 주입하지 않는다. 세션 시작 시, 스킬 이름과 한 줄 설명만으로 구성된 작은 인덱스를 로드한다. 각각 약 100토큰. 수백 개의 스킬을 설치해도 컨텍스트 비용은 미미하다.

모델이 어떤 스킬이 관련 있다고 판단하면 툴 콜을 발생시킨다. 런타임이 해당 스킬의 전체 SKILL.md를 컨텍스트에 로드한다. 스크립트와 참조 파일은 지침이 명시적으로 요구할 때만 로드된다. 나머지는 파일시스템에 그대로 있고, 토큰을 소모하지 않는다.

임베딩도 없고, 분류기도 없다. 언어 모델 자체가 평범한 추론을 통해 어떤 스킬을 쓸지 결정한다. 이건 곧 스킬 설명이 진짜 무게를 가진다는 뜻이다. 모호한 설명은 빗나가고, 정확한 설명은 믿을 수 있게 작동한다.

Skills와 MCP: 경쟁이 아니라 공존이다

MCP는 연결성을 담당한다. 외부 데이터, API, 서비스로의 파이프. 스킬은 전문성을 담당한다. 그 연결들을 잘 사용하는 절차적 지식. 스킬은 여러 MCP 툴을 순차적으로 오케스트레이션할 수도 있고, 스킬 안의 스크립트로 데이터를 처리한 뒤 프로젝트 컨벤션에 맞게 출력을 포맷팅할 수도 있다.

둘 중 하나를 고르는 건 말이 안 된다. 함께 작동한다.

왜 "에이전트 만들기를 멈춰야" 하는가

Barry와 Mahesh는 여기에 앉아서 생각해볼 만한 컴퓨팅 비유를 던진다. 모델은 프로세서다. 에이전트 런타임은 운영체제다. 스킬은 애플리케이션이다. 수백만 명의 개발자가 애플리케이션을 만든다. 그게 진짜 가치가 복합되는 곳이다.

각 도메인마다 새로운 에이전트가 필요한 게 아니다. 각 작업에 맞는 스킬이 필요한 것이다. 에이전트는 그대로다. 변하는 건 로드되는 전문성뿐이다.

좋은 설명을 쓰는 법

설명이 트리거이다. 모델은 이 설명을 보고 요청과 매칭시킨다. 평범한 추론으로.

능동적 동사를 써라. "Enforces project design system"은 작동한다. "A skill about design"은 안 된다.

트리거를 구체적으로 써라. "Use when creating React components, pages, layouts, forms"는 여러 매칭 표면을 제공한다.

100단어 이내로 유지하라. 설명은 매 세션 모든 스킬에 걸쳐 로드된다.

테스트하라. 새 세션을 열고 "build me a settings page with a form"이라고 해보라. 스킬이 이름을 언급하지 않아도 활성화되는지 지켜본다. 안 되면 설명을 다듬는다.

그래서 이제 뭘 하면 되나

에이전트를 버리라는 게 아니다. 에이전트는 이미 충분히 똑똑하다. 부족한 건 전문성이다. 그리고 전문성은 폴더 하나에 담긴다.

오늘 당장 할 수 있는 일은 간단하다. 네가 매번 프롬프트에 복사붙여넣기 하고 있는 그 규칙들 — 컴포넌트 컨벤션, 코드 리뷰 체크리스트, API 호출 패턴 — 을 꺼내서 하나의 폴더로 만드는 것. SKILL.md에 언제 쓰는지를 명확히 쓰고, 필요한 스크립트와 참조 파일을 옆에 두어라.

핵심은 이거다

요즘 먹히는 패턴은 단순하다. 범용 에이전트 하나, 스킬 라이브러리, 그리고 외부 세계를 잇는 MCP.

“에이전트를 그만 만들어라”라는 말은, 도메인마다 같은 껍데기를 반복해서 만들지 말라는 뜻이다. 문제는 런타임이 아니라 전문성이었다.

전문성은 한 번 패키징한다. 필요할 때만 로드한다. 나머지는 공통 런타임이 처리한다.

스킬을 만들기 위해 인프라 엔지니어일 필요는 없다. 일이 어떻게 돌아가야 하는지만 알면 된다.

이 글은 Anthropic의 Barry Zhang과 Mahesh Murag가 제시한 Agent Skills 개념을 바탕으로, 실제 프로덕션 적용 관점에서 재구성한 내용입니다.