프롬프트 엔지니어링의 다음 단계: Claude ‘Skill’ 시스템 파헤치기

노션에 정리해둔 프롬프트 뭉치들을 볼 때마다 한숨부터 나왔다.

매번 같은 프롬프트를 복붙하는 게 슬슬 지겹고 비효율적이라 느꼈다면, Anthropic이 제시한 ‘Skill’이라는 개념에 주목할 필요가 있다. 정확히 그 가려운 곳을 긁어주는 해결책이다.

복붙의 한계

솔직히 말하면, 나도 한때 노션에 “잘 먹히는 프롬프트 모음집”을 신줏단지 모시듯 정리해뒀다(지금 생각하면 참 눈물겹다). 코드 리뷰 시킬 때 쓰는 프롬프트, 블로그 글 다듬을 때 쓰는 프롬프트, PR 설명 작성 시킬 때 쓰는 프롬프트… 이런 걸 모아두고 매번 창을 오가며 복사해서 붙여넣곤 했다.

혼자 쓸 때는 그럭저럭 버틸 만하다. 그런데 팀 단위로 넘어가면 사방에서 문제가 터진다. 똑같은 “코드 리뷰” 업무인데 A는 보안 관점에서만 까다롭게 보고, B는 린트 컨벤션만 대충 훑고, C는 아예 생뚱맞은 포맷으로 결과를 뽑아온다. 프롬프트가 사람마다 제각각이니 결과물 품질도 롤러코스터를 탄다.

Anthropic이 발표한 “A complete guide to building skills for Claude”라는 가이드가 딱 이 골치 아픈 문제를 정면으로 다룬다. 읽어보니 꽤 무릎을 치게 만드는 접근이라 각 잡고 정리해봤다.

스킬(Skill)이란?

가이드에서 정의하는 스킬은 우리가 흔히 말하는 단순 “프롬프트”와는 아예 결이 다르다. 쉽게 비유하자면 이런 차이다:

• 프롬프트: “이 코드 리뷰해줘.” (일회성 요청, 매번 일일이 넣어줘야 함)
• 스킬: “우리 팀 보안 가이드라인과 변수 명명 규칙에 따라 코드를 점검하고, 발견된 이슈는 심각도(Critical/Major/Minor)에 따라 분류해서 리포트해.” (언제든 재사용 가능한 절차 매뉴얼)

결국 스킬은 Claude에게 ‘특정 업무를 수행하는 공식 매뉴얼’을 통째로 쥐여주는 것이다. 신입 사원 들어왔을 때 업무 인수인계서 넘겨주듯이, AI한테도 “이 상황에선 군말 말고 이 절차대로 해”라는 가이드를 박아두는 셈이다.

누가 실행하든 동일한 절차를 밟으니, 결과물의 품질이 들쑥날쑥할 틈이 없다. iOS 개발에 비유하자면 줄줄이 긴 코딩 컨벤션 위키 문서를 SwiftLint 규칙 파일(.swiftlint.yml)로 박제해 버리는 것과 똑같은 맥락이다.

MCP와 뭐가 다른 건데?

여기서 가장 헷갈리기 쉬운 게 MCP(Model Context Protocol)와의 관계다. 나도 처음엔 “이거 결국 MCP랑 비슷한 거 아닌가??” 싶었는데, 둘의 역할은 완전히 갈린다.

• MCP: 연결(파이프라인)을 담당한다. 데이터베이스, GitHub, Google Drive 같은 외부 도구와 데이터를 Claude에게 날라다 주는 손발. “여기서 데이터 긁어와”에 해당한다.
• Skill: 절차(두뇌)를 담당한다. 가져온 데이터를 어떻게 요리하고, 분석하고, 어떤 형식으로 보고할지 정하는 룰. “가져온 걸로 이렇게 처리해”에 해당한다.

실제 업무 시나리오로 보면 단번에 감이 온다.

1. MCP가 사내 DB에서 ‘지난달 매출 데이터’를 긁어온다.
2. Skill이 이 데이터를 받아 ‘재무팀 주간 보고서 양식’에 맞춰 요약하고, 전월 대비 변동이 10% 이상인 항목은 별도로 플래그를 딱 달아준다.

MCP 없이도 스킬은 단독으로 쓸 수 있고(독립형), MCP와 결합하면 그야말로 날개를 단다(강화형). 둘은 밥그릇 싸움하는 사이가 아니라, 레고 블록처럼 찰떡으로 맞물리는 관계다.

기술적 구조: 폴더 하나가 스킬 하나

스킬의 물리적 형태는 생각보다 훨씬 심플하다. 디렉터리 폴더 하나로 똑 떨어지게 관리되고, Git으로 버전 관리하기도 딱 좋다.

my-skill/
├── SKILL.md          # 스킬의 핵심 로직과 정의
├── templates/        # 보고서 양식, 이메일 초안 등
├── resources/        # 참고할 사내 규정, 가이드라인
└── examples/         # Few-shot learning용 예시

핵심은 단연 SKILL.md 파일이다. 여기에 스킬의 발동 조건, 세부 실행 절차, 최종 출력 포맷 등을 정의해 둔다.

재미있는 건 SKILL.md의 description 메타데이터다. 이건 사람이 읽으라고 달아둔 주석이 아니라, Claude가 프롬프트를 보고 “아, 지금 이 스킬을 서랍에서 꺼내 써야겠네”라고 스스로 판단하는 방아쇠(트리거) 역할을 한다. description을 얼마나 찰떡같이 쓰느냐에 따라 스킬이 제때 발동되기도 하고, 영영 서랍 속에서 잠만 자기도 한다.

또 하나 감탄한 부분은 ‘점진적 공개(Progressive Disclosure)’ 패턴이다. 스킬의 방대한 내용을 한꺼번에 메모리에 다 퍼붓는 게 아니라, 상황에 맞춰 필요한 단계만 야금야금 불러온다. 토큰 낭비를 틀어막기 위한 설계인데, 이런 디테일을 보면 Anthropic이 실제 프로덕션 환경에서 토큰 비용 때문에 얼마나 머리를 싸맸는지 눈에 선하다.

활용 패턴 두 가지

패턴 A: 독립형 스킬

외부 도구 연동 없이, Claude 자체의 기본 지능에 특정 도메인 전문성을 딱 입히는 방식이다.

내가 당장 써먹을 만한 예시만 떠올려봐도 꽤 쏠쏠하다:

• iOS 앱의 접근성(Accessibility) 체크리스트를 기반으로 코드를 깐깐하게 리뷰하는 스킬
• 우리 팀 코드 스타일에 맞춰 Swift 코드를 점검하고 다듬어주는 스킬
• 빡빡한 앱 스토어 심사 가이드라인에 걸리지 않게 릴리즈 노트를 작성하는 스킬

패턴 B: MCP 강화 워크플로우

외부 데이터 및 도구와 결합해서 번거롭고 복잡한 실무를 끝장내는 방식이다.

• Jira(MCP)에서 이번 스프린트 티켓을 조회 → 우선순위 재산정(Skill) → Slack(MCP)으로 팀 채널에 깔끔하게 공유
• GitHub(MCP)에서 PR 목록 긁어오기 → 각 PR 변경 사항을 보안 관점에서 분석(Skill) → 위험도가 높은 건 리뷰어에게 멘션 알림

이 패턴을 보면서 느낀 점은 명확하다. 결국 AI 활용의 판도가 ‘질문 잘 던지는 요령’에서 ‘워크플로우를 얼마나 단단하게 설계하느냐’의 영역으로 완전히 넘어가고 있다는 사실이다.

개인적인 생각

솔직히 아직 개인 사이드 프로젝트 수준에서는 스킬을 폴더까지 파가며 거창하게 구축할 유인이 크진 않다. 나 혼자 쓰는데 폴더 구조 잡고 메타데이터 관리하는 건 좀 투머치다(귀차니즘이 승리한다).

하지만 팀 단위로 넘어가면 이야기가 180도 달라진다. “AI 혼자 기가 막히게 잘 쓰는 팀원”의 암묵지와 노하우를 스킬 파일로 패키징해서 팀원 전체에 뿌릴 수 있다는 건 엄청난 무기다. 신규 입사한 주니어 개발자한테 “일단 이 스킬 폴더 깔고 써봐”라고 건넬 수만 있다면, 팀 내 AI 활용 격차는 순식간에 메워질 테니까.

이제 AI 활용은 “누가 프롬프트를 예술적으로 깎느냐”는 개인기 싸움에서, “누가 조직에 맞는 AI 파이프라인을 엔지니어링하느냐”의 시스템 싸움으로 바뀌었다.

반복해서 붙여넣고 있는 프롬프트가 있다면, 오늘 당장 창 끄고 SKILL.md 파일 하나 만들어 보는 걸 추천한다.