Claude를 쓰는 사람은 많아졌지만, '제대로' 쓰는 사람은 여전히 적다. Anthropic이 2025년 10월 Agent Skills를 공개한 뒤, 개발자 커뮤니티 반응은 두 갈래였다. "또 하나의 추상화 레이어 아니야?"라는 회의론, 그리고 실제로 주말 내내 써본 뒤 "이게 에이전트가 진짜 쓸모 있어지는 방식이구나"로 돌아선 실용론. 나는 후자 쪽이다. 여기에 출력 형식 설계라는 두 번째 축을 얹으면, Claude를 단순한 자동완성 도구가 아니라 실무 워크플로우의 핵심 레이어로 다룰 수 있는 그림이 완성된다.
Skills의 핵심은 '점진적 공개'다
dev.to에 올라온 100개 Skills 실사용 리포트가 던지는 가장 중요한 개념은 progressive disclosure, 즉 점진적 공개다. Skill은 구조적으로 단순하다. SKILL.md 하나와 선택적 스크립트, 참조 문서로 이뤄진 디렉터리다. 하지만 작동 방식이 다르다. Claude는 시작 시점에 설치된 모든 Skill의 name과 description만 로드한다. 태스크와 매칭되는 순간 본문을 읽고, 본문이 추가 파일을 참조할 때만 그 파일을 가져온다. 스크립트는 실행되지만 스크립트 본문 자체는 토큰을 소모하지 않는다.
이 구조가 중요한 이유는 명확하다. 200페이지짜리 플레이북을 에이전트에게 통째로 주입하지 않아도 된다. 필요한 순간에 필요한 만큼만 열린다. 거대한 시스템 프롬프트가 확장성의 한계에 부딪히는 지점에서 Skills는 오히려 가벼워진다.
좋은 Skill과 '그럴듯한 프롬프트'를 가르는 기준
100개를 테스트한 결과 70%가 탈락했다. 탈락 기준을 뒤집으면 좋은 Skill의 조건이 나온다.
- 트리거 정밀도: 클로드가 '지금 이 Skill이 필요한 상황인가'를 정확히 인식하는가.
description필드가 핵심이다. 모호한 설명은 Skill을 무용지물로 만든다. - 결정론적 코드 위임: 모델에게 "조심해서 처리해"라고 부탁하는 대신, 스크립트가 그 작업을 직접 실행한다. PDF Skill이 대표적이다. 파이썬 파서가 구조화된 필드 메타데이터를 반환하니 환각이 끼어들 틈이 없다.
- 토큰 경제:
SKILL.md본문은 최대한 가볍게, 세부 내용은 번들 파일로 위임한다. - 재사용성: 단일 워크플로우에만 쓰이는 일회성 트릭은 Skill이 아니라 프롬프트로 처리하면 된다.
추천 목록에서 눈에 띄는 건 skill-creator다. Skill을 만드는 Skill. 프론트매터 계약을 강제하고, 대부분의 사람이 틀리는 description 문구를 제안하며, 번들 파일 구조를 스캐폴딩해준다. 처음 하나를 깔아야 한다면 이걸 먼저 설치하는 게 맞다.
Claude Code가 Skills의 진짜 무대인 이유
Skills 생태계를 논할 때 Claude Code를 빼면 대화가 반쪽이 된다. 터미널 전용 실험체로 시작한 Claude Code는 이제 터미널·IDE 플러그인·데스크톱 앱·웹·iOS·Slack을 아우르는 멀티 서피스 환경이다. Notion 공동창업자 Simon Last의 말이 인상적이다. "내 일의 상당 부분은 Claude Code 인스턴스를 최대한 많이 바쁘게 유지하는 것이다." Ramp는 Metaflow 전환에서 ML 모델 당 1~2일을 절감했고, Intercom·Spotify·Shopify·Figma·Asana가 공개적으로 도입을 밝혔다.
특히 주목할 신기능은 Routines다. 한 번 설정해두면 스케줄·API·이벤트 트리거로 자동 실행된다. 야간 의존성 업그레이드, 새 GitHub 이슈 자동 트리아지, 머지 시 체인지로그 생성이 일회성 설정으로 끝난다. Skills + Routines 조합은 2026년 가장 주목할 워크플로우 패턴이다.
두 번째 세금: 출력 형식이 토큰 비용을 결정한다
Skills로 워크플로우를 설계했다면, 다음 질문은 "무엇을 출력하게 할 것인가"다. dev.to의 Format Tax 분석이 이 지점을 날카롭게 짚는다. 동일한 100단어 콘텐츠를 일곱 가지 형식으로 출력했을 때 토큰 청구액은 형식마다 극적으로 달랐다.
핵심 통찰은 이것이다. 토큰 비용은 프롬프트가 아니라 출력 형식에서 결정된다. 대부분의 개발자가 프롬프트 길이를 줄이는 데 집중하지만, 진짜 비용은 응답의 구조에 숨어 있다.
- SVG: 좌표, 사각형, 경로, 색상 지정이 모두 텍스트로 작성된다. 독자는 결과물만 보지만 토큰 청구서는 모든 드로잉 지시를 기억한다.
- React 컴포넌트: import, JSX 래퍼, 스타일링 로직, 이벤트 핸들러, 중첩 컨테이너—이 스캐폴딩 중 독자에게 닿는 건 없다.
- Mermaid: Claude 인터페이스 안에선 가볍고 우아하다. WordPress 퍼블리싱 파이프라인에서는 스크린샷→크롭→업로드→이미지 압축→alt 텍스트 작업으로 바뀐다.
"형식이 가장 세련되어 보일 때가 깨지기 가장 직전"이라는 문장이 이 글에서 가장 기억에 남는다.
편집 비용이라는 보이지 않는 세금
Format Tax에는 생성 비용 외에 편집 비용이라는 두 번째 축이 있다. 3,000단어 문서에서 한 단락만 수정하려고 전체를 다시 붙여넣는 행위가 대표적이다. 수정 규모가 아니라 문서 크기가 비용을 결정한다. 100페이지 보고서를 복사해서 3페이지 오타를 고치는 것과 같다.
가장 싼 편집 워크플로우는 가장 단순한 것이다. 수정할 섹션만 요청하고, 결과를 직접 문서에 붙여넣는다. 대부분의 사람은 반대로 한다. 전체를 다시 보내고, 워크플로우가 편하다고 느끼며, 청구서가 조용히 쌓이는 걸 모른다.
실무 적용: 형식 선택의 결정 트리
두 소스를 엮으면 실무 결정 트리가 나온다.
- 최종 목적지를 먼저 확인하라. 출력이 어디로 가는가? WordPress인가, GitHub인가, 코드베이스인가? 목적지가 지원하지 않는 형식은 시작부터 탈락이다.
- 구조는 필요한 만큼만 추가하라. Mermaid나 SVG가 필요한 경우는 생각보다 훨씬 좁다. 정보가 플레인 텍스트로 전달 가능하다면, 플레인 텍스트가 항상 이긴다.
- Skill의 description 필드에 출력 형식 힌트를 심어라. Skills 생태계와 Format Tax 최적화는 실은 같은 레이어에서 작동한다. Skill이 태스크를 감지하는 순간, 어떤 형식으로 응답할지도 함께 지정되어야 한다.
- 편집 루프를 설계하라. 전체 문서를 재전송하지 않아도 되는 워크플로우를 처음부터 만들어라.
전망: Skills + 형식 설계가 프론트엔드 AI 워크플로우의 다음 레이어다
"AI 도구를 쓴다"는 말이 이제는 너무 뭉뚱그려진 표현이 됐다. 어떤 Skills를 설치하고, 각 Skill의 트리거와 출력 형식을 어떻게 정의하느냐가 실제 생산성의 차이를 만든다. Claude Code가 Routines로 이벤트 기반 자동화를 완성하고, Skills가 패키지 포맷으로 생태계를 형성하는 지금, 프론트엔드 개발자에게 필요한 역량은 프롬프트를 잘 쓰는 것에서 AI 워크플로우를 설계하는 것으로 이동하고 있다.
좋은 Skill 하나가 팀 전체의 반복 작업을 없애고, 출력 형식 하나를 바꾸는 것이 월간 토큰 비용을 의미 있게 줄인다. 이 두 가지를 동시에 설계할 수 있는 개발자가 AI-Native 워크플로우에서 실질적인 레버리지를 갖는다.