The Complete Guide to Building Skills for Claude 를 읽고

Chapter 1: Fundamentals

MCP와 Skills가 어떻게 다른지에 대해 알게 됐다. 처음 MCP가 나오고, 그 후에 Skills가 나왔을 때 나는 이게 그냥 토큰 수를 아끼기 위한 아이디어라고만 생각했는데 MCP에게 저수준의 통합을 맡기고, skill로 이 통합을 기반으로 한 워크플로우를 정의하고 하는 것이 아하.

내가 초기에 가졌던 오해는 Standalone skills들만 생각하고 MCP를 대체한다고 오해했다는 것을 알게 됐다.

Chapter 2: Planning and design

사실 스킬 skill 생성해주는 스킬로 만들고 한번 만들고나면 검증을 잘 안 하고 그때그때 고쳤었는데, 글을 쓰다보니 이런 거 녹 닦아주고 실제 수정을 LLM에게 넘겨야하나 생각도 드네요.

Chapter 3: Testing and iteration

skill creator 스킬로 스킬을 만들고, 쓰면서 자꾸 크리에이터한테 피드백을 먹여 개선시키고... 뭔가 LLM 스럽다.
skill이야 뭐 어차피 지금은 자동화된 프로세스에서 실행시키는 게 아니고 우리가 필요할 때 직접 실행시키고 있어서 회사에서는 별 신경을 쓰지 않았다. 근데 이런 부분들 나중에 자동화 하려면 스킬들 제때제때 잘 쓸 수 있게 테스트도 만들어두고, 그전에 우리의 프로세스들을 스킬들로 좀 만들어둘 필요가 있을 것 같다.

Chapter 4: Distribution and sharing

스킬을 API형태로 노출시킬 수 있다는 건 몰랐다. 흥미롭군.

Chapter 5: Patterns and troubleshooting

개인적으로 만들어둔 아키텍처 관련된 스킬이 있는데 20개~50개 사이를 유지하래서 확인해보니 다행히 12개가 전부였다. 휴.
새로이 알게된 건

1. iterative하게 개선하는 걸 스킬로 만들 수 있구나 (Pattern 3)
2. 모호하고 확률적인 검증을 어떻게 피할 수 있을까
   • 항상 궁금했다. 왜냐면 md파일에 대충 넣는다고 되는 게 아니고 좀 더 강하게/시스템적으로 검증이 보장되어야할 거 같은 느낌을 항상 받았음. (pre-commit 훅처럼)
   • 근데 결국 ## IMPORTANT 이런 거 넣고, 검증을 해주는 코드를 넣고, workflow 에서 검증하라고 쓰고,,, 이렇게 다중으로 설정하는 게 최선인가보다.
   • 혹은 검증 증거물 파일을 남기고, 증거물 파일을 기반으로 다음 작업을 하게하고... 이것도 그냥 지가 증거물파일 만들 수도 있을 거 같은데.. 잘 모르겠다 ㅜㅜ

Chapter 6: Resources and references

• Quick Checklist 유용해보인다.

---

Memo

주요 유즈케이스

• 문서화 & 애셋 생성 (예: front-end design skill)
• Workflow automation (예: skill-creator skill)
• MCP 강화 (예: sentry-code-review skill)
  • 내가 회사에서 만드려고 했던 건데 이미 있는 거 같다.
  • sentry mcp로 에러데이터 가져오고, 코드 파악해서 수정해주고 제시하는 거

    스킬 평가

정량적

1. 테스트 쿼리 10-20개 돌려서 호출 잘 되나 확인(90% 이상)
2. 같은 작업을 스킬로 했을 때와 아닐 때 토크 사용량과 tool calls 비교하기
3. 테스트 과정에서 MCP error log가 있지는 않은지 확인

정성적

1. 추가적인 프롬프트가 필요하진 않았는지
2. 사용자의 수정이 필요하진 않았는지 (3~5번 했을 때 결과물의 품질과 일관성 검증)
3. 새로운 사용자가 최소한의 안내만으로 첫 시도에 해당 작업을 성공적으로 마칠 수 있는지