본문으로 건너뛰기 
나는 왜 남의 SKILL.md를 들여다보기 시작했나
— 잘 만들어진 스킬에는 만든 사람의 ‘일하는 철학’이 담겨 있다
"에이전트에게 스킬을 만들어주는 건, 새로 온 사람에게 온보딩 가이드를 만들어주는 것과 같습니다."
— Anthropic
🧩 내 스킬을 다시 열어보니, 내 고집이 적혀 있었다
저는 반복되는 일을 스킬로 만들어 씁니다.
스킬이라고 하면 거창하게 들리지만, 사실은 설명서 한 장에 가깝습니다. AI에게 "이런 일이 들어오면 이런 순서로, 이런 원칙을 지켜서 처리해"라고 미리 적어두는 마크다운 파일이죠. 보통 파일 이름을 SKILL.md로 붙여서 그렇게 부릅니다. 제가 늘 말로 하던 지시를 한 번만 적어두면, 다음부터는 AI가 그 파일을 읽고 그 방식대로 움직입니다.
할 일 관리용 스킬이 하나 있습니다. Akiflow에 할 일을 넣고 일정까지 잡아주는 건데, 여기에 제가 아예 규칙으로 적어둔 문장이 하나 있어요. 백로그를 만들지 말 것. 날짜 없는 할 일은 쌓이기만 하다가 결국 죄책감이 되니까, 무조건 가까운 날짜에 붙이라고 적어뒀습니다.
"지금 뭐 해야 돼?"라고 물으면 답해주는 비서 스킬도 있습니다. 캘린더와 노트, 슬랙, 할 일을 전부 가로질러 읽은 뒤에 딱 하나만 짚어줍니다. 우선순위 목록은 주지 말라고 적어뒀어요. 목록이 여러 개 나오면 저는 또 고르느라 시간을 쓰게 되거든요.
업무 자동화를 도와주는 코치 스킬도 만들었습니다. 첫 줄이 이렇습니다. 코치가 대신 골라주지 않는다. 무엇을 자동화할지는 본인이 고르게 하고, 코치는 질문만 던지게 해뒀습니다.
이걸 만들 때 거창한 생각이 있었던 건 아닙니다. 매번 똑같은 설명을 다시 하는 게 귀찮았거든요. 매일 아침 브리핑이나 하루 기록처럼 루틴에 붙어 있는 것들도 그렇게 하나둘 만들어졌습니다.
효과는 분명했습니다. 한 번 잘 만들어두면 그다음부터는 제가 아무 말 안 해도 같은 형식으로, 같은 길이로, 같은 순서로 나옵니다. 시간이 줄어드는 것도 좋았지만, 결과물이 매번 비슷한 수준으로 나오는 것이 더 좋았습니다.
생산성 분야에서는 이런 걸 이미 SOP(Standard Operating Procedure), 즉 표준 운영 절차라고 부릅니다. 잘하는 사람의 방식을 문서로 만들어두고, 다른 사람도 그 수준에서 시작하게 하는 거죠. 스킬은 그 SOP를 AI가 읽을 수 있는 형태로 옮겨둔 것뿐입니다.
여기까지는 그저 일을 좀 더 편하게 하려던 시도였습니다.
그런데 얼마 전 이 파일들을 다시 열어보다가 이상한 기분이 들었어요. 그 안에 적혀 있는 게 절차만은 아니더라고요.
백로그를 만들지 마라. 하나만 짚어줘라. 대신 골라주지 마라.
돌이켜보니 전부 제가 일할 때 붙들고 있는 고집이었습니다. 저는 업무 순서를 적어둔다고 생각했는데, 실제로 적어둔 건 제 믿음이었던 거예요. 그것도 제가 모르는 사이에 말이죠.
절차를 적어둔 줄 알았는데, 적혀 있던 건 제 고집이었습니다.
Nano Banana 2 생성 이미지
그러면 남의 스킬에는 뭐가 적혀 있을까. 갑자기 그게 궁금해졌습니다.
남의 스킬을 열어보니, 거기에도 사고의 흐름이 있었다
해외 개발자들도 자기 스킬을 하나둘 공개하기 시작했습니다. 궁금해서 하나씩 열어봤어요. 그 사람들이 어떤 순서로 일하는지 슬쩍 들여다보고 싶었거든요.
역시 절차만 있는 건 아니었습니다.
"이 단계에서는 개요를 짜지 마라." 왜 굳이 이 금지 문장을 넣었을까요? "이 규칙은 세션 내내 유효하고, 주제가 바뀌어도 사라지지 않는다." 왜 이걸 이렇게까지 못 박아뒀을까요? "이건 완성품이 아니니 고쳐 쓰세요." 왜 만든 사람이 스스로 이런 말을 남겼을까요?
금지 문장에는 반드시 이유가 붙어 있습니다. 무엇을 하라고 적는 건 누구나 할 수 있지만, 무엇을 하지 말라고 적으려면 그걸 한 번 해보고 결과가 좋지 않았던 경험이 있어야 하기 때문입니다. 하라는 말은 이상이고, 하지 말라는 말은 이력이에요. 그래서 금지 문장을 하나씩 따라가다 보면 그 사람이 어디서 걸려 넘어졌는지, 그 뒤로 무엇을 진실로 믿게 됐는지가 보입니다.
이게 제가 남의 스킬을 들여다보게 된 이유입니다. 업무 순서만 배우는 게 아니라 일하는 철학, 그러니까 이 사람이 무엇을 중요하게 여기고 무엇은 절대 하지 않으려 하는지를 읽게 되거든요.
도구를 고를 때도 마찬가지입니다. 남들이 많이 쓴다고 무작정 따라 쓰는 게 아니라, 그걸 만든 사람이 무엇을 믿는지 먼저 봐야 합니다. 내 철학과 맞닿아 있는 도구만 나를 한 단계 끌어올려줍니다. 안 맞으면 좋은 도구도 결국 짐이 될 뿐이죠.
오늘은 제가 들여다본 것 중에서 철학이 특히 선명했던 세 개의 스킬을 가져왔습니다.
첫 번째 — Anthropic: "신입에게 주는 온보딩 문서"
2026년 1월 30일, Anthropic은 Claude Cowork에 플러그인 기능을 붙이면서 자기들이 쓰던 11개를 통째로 오픈소스로 공개했습니다. 세일즈, 마케팅, 법무, 재무, 데이터 분석, 고객지원, 생산성까지 직무별로 하나씩이었어요.
깃허브 저장소에 적힌 문장은 이렇습니다.
"우리 자신의 업무에서 만들어지고 영감받은 11개를 공개합니다."
직접 사내에서 쓰던 걸 바깥에 공유한 것입니다. AI를 가장 적극적으로 쓰는 회사가 자기들 내부에서 어떻게 일하는지 열어 보인 셈이죠.
여기 담긴 철학 세 가지
하나, 모델이 아니라 맥락이 유능함을 만든다.
Anthropic 쪽 표현이 정확합니다. 스킬은 에이전트가 "자기가 놓인 특정 맥락에서" 일을 잘하도록 가르치는 방법이라고 했어요. 더 똑똑한 AI를 기다리는 게 아니라, 지금 있는 AI에게 우리 맥락을 알려주자는 관점입니다. 앞의 인용문, 그러니까 신입에게 온보딩 문서를 만들어주는 것과 같다는 비유도 여기서 나왔고요.
둘, 지식 노동은 코드 없이도 파일로 표현할 수 있다.
플러그인은 전부 마크다운과 JSON으로 되어 있습니다. 별도의 코드가 없어요. 그래서 개발자가 아니어도 열어서 읽고, 고치고, 공유할 수 있습니다. 겉으로는 단순한 기술 선택처럼 보이지만 실제로는 다릅니다. 오히려 "업무 방식은 개발자만 다룰 수 있는 게 아니다"라는 선언에 가깝죠.
생산성 플러그인이 이 철학을 가장 잘 보여줍니다. 할 일 관리 앱을 하나 더 만든 게 아니에요. 대신 TASKS.md라는 마크다운 파일 하나를 Claude가 읽고 쓰게 합니다. 그러면서 내 사람들, 내 프로젝트, 내가 쓰는 용어를 학습해서 챗봇이 아니라 동료처럼 일하게 만드는 게 목표라고 적혀 있습니다.
셋, 완성품을 주지 않는다.
이 지점이 가장 흥미롭습니다. Anthropic 스스로 나머지 10개는 그대로 쓰지 말고, 출발점으로 삼아 자기 회사의 도구와 용어, 절차에 맞게 고쳐 쓰라고 권합니다.
실제로 그 11개를 자기 업무에 붙여 테스트해본 한 뉴스레터 운영자의 결론도 같았어요.
"완성품이 아니라 출발점입니다."
그러면서 이런 말도 덧붙였습니다. 단독 스킬과의 진짜 차이는 슬래시 명령(slash command)이라고요. 스킬은 Claude가 생각하는 방식을 바꾸고, 슬래시 명령은 하나의 완결된 작업을 통으로 실행합니다.
같은 리뷰어가 짚은 단점도 옮겨둘게요. 플러그인 세션은 사용량을 훨씬 빨리 씁니다. 복잡한 세션 하나가 일반 메시지 100개 이상에 맞먹을 수 있으니, 토큰을 아껴야 한다면 더더욱 내 상황에 맞게 손봐야 합니다.
