이 영상은 2025년 10월에 등장한 Skills(스킬) 이 이제는 "개인용 프롬프트 모음"이 아니라, 조직 전체의 AI 인프라로 바뀌었다는 흐름을 정리합니다. 핵심은 스킬을 사람이 읽기 좋은 문서가 아니라 에이전트가 호출하기 좋은 계약(Contract) 으로 설계해야 한다는 점이에요. 그리고 Anthropic·OpenAI·Microsoft가 사실상 같은 방향(공통 표준/파일 기반)으로 합류하면서, 스킬을 잘 쌓는 팀이 시간이 갈수록 더 크게 앞서게 된다고 결론 냅니다.

1. 10월에 스킬이 나왔지만, '지금' 게임은 이미 달라졌다

영상은 "Anthropic이 10월에 스킬을 출시한 뒤, LLM/에이전트 세계가 너무 빨리 변했는데 우리는 아직 그 변화에 맞춰 사고방식을 업데이트하지 못했다"는 문제의식으로 시작합니다. 대부분 에이전트를 말할 때 특정 툴(영상에서는 'OpenAI/Claude 쪽 에이전트 흐름')만 떠올리지만, 정작 더 근본적인 변화는 스킬이 '지속적이고 예측 가능한 성과'를 만드는 바닥(substrate) 이 되고 있다는 점이라고 강조해요.

"우리가 놓치고 있는 건, 스킬이 비즈니스가 필요로 하는 '정확하고, 지속되고, 예측 가능한 결과'를 만드는 기반이 되고 있다는 거예요."

그래서 이 영상은 '에이전트가 읽고 호출할 수 있는 스킬(agent-readable skills)' 로 관점을 바꾸는 업데이트 강의처럼 진행됩니다. 그리고 발표도 하나 곁들여요. 본인 스킬만 올리는 게 아니라, 커뮤니티가 함께 올리고 배울 수 있는 스킬 저장소(repo) 를 만들겠다고 합니다.

"이건 '스킬을 제대로 만드는 법'을 같이 배우는 장소가 될 거예요. 커뮤니티가 스킬을 던져 넣고, 다 같이 의미 있는 일을 더 잘하게 만드는 거죠."

2. 스킬 생태계를 바꾼 4가지 큰 트렌드

2.1 개인 설정 파일 → 조직 인프라로 급변

가장 큰 변화 1번은 스킬의 지위 상승입니다. 예전엔 개인이 자기 편의를 위해 만들던 것이, 이제는 팀/엔터프라이즈가 전사 배포·버전 관리하는 "업로드 1번으로 깔리는 인프라"가 됐다고 해요. 스킬이 사이드바에 뜨고, Excel/PowerPoint/Claude/Copilot 같은 업무 도구에서 호출되는 형태로 흡수되고 있다는 거죠.

"6개월 전엔 개인 설정이었는데, 지금은 조직 인프라예요. 전사 배포되고, 버전 관리되고, 엑셀·파워포인트·Claude·Copilot에서 다 불려요."

여기서 강조되는 키워드는 공통 인프라 레이어, 그리고 사람도 읽고 에이전트도 읽는 문서입니다. 즉, 스킬은 "누가 머릿속에 노하우를 들고 있느냐"가 아니라 "조직이 어떻게 노하우를 파일로 운영하느냐"의 문제로 바뀌었다는 말이에요.

2.2 스킬을 '호출하는 주체'가 사람에서 에이전트로 넘어감

두 번째 변화는 생각보다 결정적입니다. 10월엔 사람이 대화 중에 스킬을 몇 번 쓰는 정도였는데, 지금은 에이전트가 한 번 실행(run)하면서 수백 번 스킬을 호출할 수 있죠. 그래서 "사람 기준으로 그럴듯한 스킬"과 "에이전트가 안정적으로 굴릴 수 있는 스킬"의 요구사항이 달라집니다.

"이제 스킬의 대부분은 사람이 아니라 에이전트가 호출해요. 사람은 대화 중 몇 번이지만, 에이전트는 한 번에 수백 번을 불러요. 그러니 스킬을 agent-first로 생각해야죠."

2.3 스킬은 개발자 전용이 아니다 (그리고 대기업도 그걸 안다)

세 번째는 스킬이 터미널에서 코드 실행하는 개발자 장난감이 아니라는 점이에요. 업무 전반, 심지어 개인 생활에도 적용되는 "업무 방법론을 담는 그릇"이 되고 있고, 대기업들도 그 흐름에 동의한다는 식으로 말합니다.

"스킬은 터미널에만 사는 게 아니에요. 비즈니스 전반, 개인 생활까지 쓰는 거예요."

또한 Anthropic과 Microsoft의 협업(스킬을 Copilot 쪽으로), OpenAI 릴리즈에서도 스킬이 등장하는 흐름을 언급하며, 스킬이 사실상 '오픈 표준(open standard)' 쪽으로 굳어지고 있다고 봅니다.

"스킬은 이제 오픈 표준이 됐고, 앞으로 AI가 작동하는 방식의 공통 인프라 차량(vehicle)이 될 거예요."

2.4 '알파(우위)'는 닫아두는 게 아니라, 공유하며 발견된다

네 번째는 문화/전략 이야기입니다. 예전엔 알파(우위)는 비공개로 숨기는 게 상식이었지만, 에이전트·스킬 세계에서는 베스트 프랙티스가 '이미 알려진 것'이 아니라 '발견되는 것' 이라서, 커뮤니티가 함께 실험할수록 발전 속도가 빨라진다고 해요.

"우리는 스킬을 야구카드처럼 교환하고 있어요. 인터넷 전체가 같이 배우는 중이죠."

그리고 LLM 시대는 설명서가 이미 완성되어 배포되는 게 아니라, 사람들이 시행착오로 "설명서를 함께 발견"해 간다는 비유도 나옵니다.

"90년대엔 설명서가 '알려진 것'이었죠. 하지만 LLM은 우리가 설명서를 함께 발견하는 거예요."

3. 스킬이 정확히 뭐고, 사람들이 실제로 어떻게 쓰고 있나

발표자는 스킬을 아주 단순한 형태로 정의합니다. 스킬은 폴더 안에 텍스트 파일 하나가 있는 정도의 '원시적 구조'지만, 그 안에 맥락과 방법론을 담을 수 있어 강력하다는 거예요.

"스킬은 폴더 하나와 그 안의 텍스트 파일 하나예요. 필수 파일은 skill.markdown 하나뿐이죠."

구성은 크게 두 덩어리입니다.

• 상단: 메타데이터(metadata)
• 하단: 방법론/지침(methodology & instructions)

그리고 이게 결국 "평범한 언어로 쓰인 지시문"을 통해 LLM에게 예측 가능한 방식으로 입력→출력을 만들게 하는 장치라고 설명합니다.

3.1 가장 흔한 운영 패턴: '스페셜리스트 스택(specialist stack)'

Claude 생산 현장에서 가장 흔한 패턴으로 스페셜리스트 스택을 소개합니다. 예를 들어 개발 프로젝트 폴더에 스킬 묶음을 넣어두면:

• 애매한 지시 → PRD로 바꿔주는 스킬
• PRD → GitHub 이슈로 쪼개주는 스킬
• 테스트 작성 스킬 등…

이렇게 역할별로 "전문가 스킬"이 층층이 쌓이면서, 에이전트가 그 파일들을 호출해 일을 진행합니다.

"에이전트가 '전문가의 지시'를 매번 따로 받을 필요가 없어요. 전문성은 파일 안에 있거든요."

여기서 발표자는 스킬이 프롬프트의 고통(뉘앙스 조정, 반복 입력) 을 줄여 준다고 말합니다. 즉, 엄격한 프롬프트 테크닉에 덜 의존하게 된다는 거죠.

3.2 개발이 아니어도 된다: 부동산 운영에 스킬 5만 라인

재미있는 사례로, X에서 활동하는 부동산 GP(텍사스 페인트브러시)를 언급합니다. 이 사람은 운영 전반을 스킬로 쌓아 50개 저장소에 5만 라인이나 만들었고, 임대 명부 표준화, 시세 비교(comps), 현금흐름 처리, 팀 핸드오프 프로토콜까지 담았다고 해요.

"에이전트가 그 스킬들을 호출해 예측 가능하게 운영을 돌릴 수 있고, 놀라운 건 그걸 '써놓는 것' 자체가 사람 onboarding에도 큰 도움이 된다는 거죠."

핵심은 방법론이 사람 머리에만 있지 않고, 리포지토리에 남는다는 점이에요. 즉 스킬은 자동화 도구이면서 동시에 조직 문서화 장치가 됩니다.

3.3 더 고도화: 오케스트레이터 스킬과 서브에이전트 분기

또 다른 발전형으로 오케스트레이터(orchestrator) 스킬을 소개합니다. 들어오는 요청을 분석해서 연구/코딩/UI/문서 등으로 업무를 쪼개고, 각각을 서브에이전트에게 맡기도록 "분기"를 만들어 주는 스킬이죠.

"하나의 상위 요청이 들어오면, 오케스트레이터 스킬이 그걸 서브에이전트들에게 안정적으로 '팬아웃'시켜요."

그리고 스킬이 표준화되면 생태계 전체가 같은 방식으로 굴러서, Excel이든 PowerPoint든 Copilot이든 Claude든 어디서나 같은 자산을 재사용할 가치가 커진다고 연결합니다.

4. 왜 '프롬프트'가 아니라 '스킬'이 복리로 쌓이나

발표자의 메시지는 단순합니다. 프롬프트는 좋지만, 대화가 끝나면 증발하기 쉽고(다시 복붙해야 하고), 반면 스킬은 파일로 남아 개선·버전업·공유되며 복리(compound) 로 성장한다는 거예요.

"프롬프트는 대화가 끝나면 사라져요. 다시 붙여넣어야 하죠. 하지만 스킬은 남습니다. 스킬이야말로 지속되는 것이에요."

특히 6개월 동안 스킬을 써온 사람들은 "출력 마음에 안 들면 스킬 파일을 업데이트"하면서 점점 더 정교해지고, 그 자산이 계속 누적됩니다.

"스킬을 만들던 사람들은 계속 다듬어서 복리로 쌓았고, 프롬프트만 하던 사람들은 같은 걸 계속 복붙하고 있어요."

프롬프트는 레고의 기본 블록(쓸모는 있으나 기본재)이고, 원하는 '성(캐슬)'을 지으려면 재사용 가능한 특수 블록이 필요한데 그게 스킬이라는 비유도 나옵니다. 🧱

5. "작동하는 스킬" 만드는 법: 사람들이 가장 많이 망하는 지점들

여기서부터는 실전 가이드가 꽤 촘촘하게 나옵니다. 특히 description(설명) 필드를 아주 강하게 강조해요.

5.1 "스킬이 죽는 곳은 description이다"

발표자는 단언합니다.

"가장 중요한 건 이거예요. 대부분의 스킬은 description에서 죽어요."

나쁜 description의 특징은 너무 추상적이고 두루뭉술한 것입니다. 예: "경쟁 분석을 도와줍니다" 같은 문장은 트리거가 애매해져서, 제대로 호출되지 않거나 엉뚱하게 호출됩니다.

좋은 description은 다음을 포함해야 한다고 설명합니다.

• 생성하는 산출물 타입(문서/아티팩트 종류)
• 사용자가 실제로 말할 법한 트리거 문구
• 출력 형태가 어떻게 생겨야 하는지

"좋은 설명은 '무엇을 만든다'가 분명하고, '어떤 말에 반응해야 하는지'가 들어가고, '출력이 어떻게 생겨야 하는지'가 적혀 있어요."

또 Anthropic 가이드로 "대체로 스킬은 과하게 트리거되기보다 덜 트리거되는 경향이 있으니, 스킬이 좀 더 '적극적으로' 발동되게 써라"는 조언을 전합니다.

5.2 치명적인 gotcha: description은 반드시 한 줄이어야 한다

실전에서 많이 깨지는 기술적 함정도 알려줍니다.

"스킬 description은 무조건 한 줄이어야 해요. 포매터가 줄바꿈을 넣으면 Claude가 두 번째 줄을 제대로 안 읽습니다."

즉, 멀쩡한 내용이어도 자동 포맷팅/줄바꿈 때문에 스킬이 오작동할 수 있다는 얘기라, 팀에서 공유할 때 특히 위험합니다.

5.3 methodology(본문)는 '절차'가 아니라 '추론'을 넣어야 한다

스킬 본문에서 필요한 요소를 "다섯 가지"로 정리하는데, 요지는 이렇습니다.

1. 단계(step)만 쓰지 말고, 판단 기준/원칙 같은 'reasoning(추론)'을 써라
   절차만 있으면 예외 상황에서 깨지는 "취약한 스킬"이 됩니다.

"절차만 있는 스킬은 너무 취약해요. 추론이 있어야 일반화합니다."

2. 출력 포맷을 구체적으로 명시하라
   "요약해줘"처럼 두루뭉술하면 나중에 후회한다는 톤입니다.

"마크다운인지, 엑셀인지, PDF인지, 섹션이 뭔지—구체적으로 안 쓰면 후회해요."

3. 엣지 케이스를 명시하라
   사람이 상식으로 처리하는 걸 LLM이 알아서 해줄 거라 믿지 말라고 못 박습니다.

"사람은 상식으로 처리하죠. 하지만 Claude는 그러지 않아요. 엣지 케이스는 꼭 써야 해요."

4. 좋은 예시(example)를 넣어 패턴 매칭하게 하라
   스킬 폴더에 파일을 여러 개 둘 수 있으니 예시를 함께 제공하라고 합니다.

5. 그런데도 스킬은 '짧고 날렵(lean)'해야 한다
   길게 쓰면 지시가 경쟁하고 컨텍스트만 부풀어서 성능이 떨어질 수 있다고 경고해요. 경험칙으로 핵심 파일은 대개 100~150줄을 넘기지 말라고도 합니다.

"짧지만 안정적으로 발동하는 스킬이, 길고 지시가 충돌하는 스킬을 이깁니다."
"대부분의 경우 핵심 스킬 파일은 100~150줄 이상 쓰지 마세요."

그리고 시간 배분 조언이 아주 인상적입니다.

"80%는 description에, 나머지 20%를 추론/명확한 지침에 쓰세요."

6. 에이전트-퍼스트 설계: 이제 스킬은 '라우팅'과 '계약'이다

여기부터가 영상의 제목(표준화가 모든 걸 바꾼다)과 가장 맞닿는 핵심 파트예요. 사람이 쓰다 실패하면 즉시 수정하지만, 에이전트는 자동으로 밀어붙이다가 크게 사고가 날 수 있으니, 설계 철학 자체를 바꿔야 한다는 겁니다.

6.1 실패 양상이 달라졌다 → 정량 테스트가 필요하다

사람이 쓸 땐 드리프트가 보이면 바로 잡지만, 에이전트는 복구 루프 없이 실패할 수 있고 비용이 커질 수 있다고 합니다. 그래서 스킬도 테스트 스위트(test suite) 를 갖추고, 버전 바꾸고, 성능을 정량화해야 한다고 주장해요.

"에이전트가 틀리면 회복 루프가 없을 수도 있어요. 그래서 스킬 성능을 정량적으로 테스트해야 합니다."

또 "스킬 문구가 모델의 잠재 공간(latent space)을 건드리기 때문에, 작은 표현 차이가 결과를 크게 바꿀 수 있다"는 점을 들어, 문구를 바꿀 때마다 여러 버전을 실험하라고 합니다.

"표현을 조금만 바꿔도 결과가 크게 달라질 수 있어요. 그러니 바구니 테스트를 돌리고, 버전 올리고, 다시 측정하세요."

6.2 description은 라벨이 아니라 라우팅 신호(routing signal)

에이전트가 목표를 달성하기 위해 워크플로우를 탐색할 때, description이 "이 스킬이 언제 쓰이는지"를 알려주는 길 안내 표지판이 된다는 겁니다.

"description은 라벨이 아니에요. 라우팅 신호예요. 에이전트가 워크플로우에서 어디로 가야 하는지 알려줘야죠."

6.3 에이전트는 '계약(Contract)'이 있어야 움직인다

출력을 API 계약(SLA/필드/제약) 처럼 선언적으로 명시하라고 말합니다. 에이전트는 "이 스킬을 쓰면 무엇을 얻고 무엇을 못 얻는지"가 분명해야 올바른 선택을 한다는 거예요.

"에이전트는 계약을 필요로 해요. '이 스킬로 무엇을 얻는지, 무엇을 못 얻는지'를 선언적으로 써주세요."

6.4 합성 가능성(Composability): 다음 단계로 넘길 수 있어야 한다

스킬을 "문제 하나를 끝내는 도구"로만 보지 말고, 다음 에이전트/다음 프로세스에 핸드오프 가능한 산출물을 만들어야 한다고 강조합니다.

"한 번의 출력으로 끝내려 하지 말고, 다음 단계에 넘기기 좋은 출력을 만들어야 해요. 아니면 핸드오프에서 깨집니다."

6.5 하드와이어는 스킬이 아니라 스크립트로

마지막 원칙은 현실적인 경계선입니다. 스킬은 자연어라 어느 정도 흔들릴 수 있으니, 정말 결정론적으로 고정해야 하는 행동은 스크립트로 하라고 권합니다.

"정말 하드와이어하고 싶다면 스킬 말고 스크립트를 쓰세요. 그게 AI를 못해서가 아니라, AI의 한계를 아는 거예요."

7. 팀/조직에서 스킬을 운영하는 3단 구조(Three-tier architecture)

에이전트+사람이 섞인 팀에서, 스킬은 "즉시 실행 가능한 컨텍스트" 역할을 합니다. 다만 모든 컨텍스트를 스킬로 만들 필요는 없고, 일을 '처리하고 넘기는' 프로세스에 특히 유용하다고 설명해요. 그리고 잘하는 팀은 스킬을 3계층으로 나눈다고 제안합니다.

7.1 Tier 1: 표준 스킬(Standard skills)

전사 공통으로 동일하게 쓰는 것들입니다. 예: 브랜드 보이스, 포맷 규칙, 승인된 템플릿 등.

"브랜드 보이스 스킬을 만들어서 전사에 깔면, 다 같이 쓰는 거죠. 안 하고 있으면 해보세요."

7.2 Tier 2: 방법론 스킬(Methodology skills)

팀/조직의 "고부가가치 작업을 잘하는 방식"을 담습니다. 특히 시니어들의 암묵지를 신입이 몇 달 걸려 배우는 내용을 스킬로 빼내는 게 핵심이라고 말해요.

"신입이 몇 달 걸려 배울 걸, 스킬로 바로 전달할 수 있다면 그게 Tier 2예요."

그리고 이 Tier 2가 진짜 알파(우위)가 숨어 있는 곳인데, 문제는 이게 보통 관리자(enterprise admin)가 아니라 실무 시니어의 머리 속에 있어서 끄집어내 공유 가능한 형태로 만들어야 한다고 합니다.

7.3 Tier 3: 개인 워크플로우 스킬(Personal workflow skills)

개인 생산성용 "내 책상 아래" 스킬입니다. 다만 여기서도 경고가 있어요. 노하우를 노트북/다운로드 폴더에만 두지 말라는 겁니다. 휴가/병가/퇴사 등으로 본인이 비면 팀이 곤란해질 수 있으니까요.

"노트북에만 두지 마세요. 당신이 없을 때 누군가 그 스킬이 필요해질 수 있어요."

결국 스킬은 전문성(Expertise)을 인코딩하는 파일이며, 접근 범위를 어떻게 설계할지(개인/팀/전사)를 의식적으로 결정해야 한다고 정리합니다.

8. 왜 또 스킬 저장소를 만드나: '도메인 특화 스킬'의 빈칸

영상 후반부는 커뮤니티 저장소 발표로 이어집니다. 이미 마켓플레이스나 깃허브 모음이 많은데도 왜 또 만드냐는 질문에, "기술자용 스타터팩은 많은데, 실제 문제를 푸는 도메인 특화 스킬이 부족하다"고 답합니다.

"우리가 부족한 건 '진짜 문제를 푸는 도메인 스킬'이에요. 임대 명부 분석 같은 건 아무 깃허브에나 굴러다니지 않죠."

그래서 커뮤니티가 각자 업에서 쓰는 "야구카드"를 교환하듯 공유하자고 하고, 이 저장소는 Open Brain 깃허브 리포지토리의 한 섹션으로 들어가 쉽게 통합될 거라고 설명합니다.

또 2025년 10월에 Simon Willison이 "스킬이 MCP보다 더 큰 딜이 될 수 있다"고 했던 말을 인용하며, 지금은 아직 우리가 그만큼 유창하게 만들지 못하지만, 그 방향으로 가려면 스킬 제작 숙련도가 더 올라가야 한다고 말합니다.

"스킬이 MCP보다 더 큰 일이 될 수도 있어요. 문제는 지금 우리가 그걸 만들 만큼 충분히 유창하지 않다는 거죠."

저장소의 운영 방식도 구체화합니다. 워크플로우 타입으로 정리하고, 각 스킬에 에이전트 가독성/호출 가능성 기준('agent readability bar') 을 일관되게 적용해 "검증된(practitioner library)" 형태로 만들겠다고 해요.

"경쟁 분석, 재무 모델 리뷰, 딜 메모 작성, 리서치/미팅 요약 같은 아주 구체적인 스킬을 다룰 거예요."

9. 이번 주에 바로 써먹는 실행 팁: 어디서 시작할까?

마지막은 단계별 권장 루트로 마무리됩니다.

1. 초보라면: 반복 업무 1개를 골라 스킬로 바꾸기
   일주일에 1~3번 반복하는 일을 떠올리고, 지금까지의 대화/좋았던 결과/아쉬웠던 점을 AI에 넣어서 skill.markdown 초안을 만들라고 합니다.

"일주일에 한두 번 반복하는 걸 골라서 '이걸 스킬로 바꿀 수 있을까?'를 물어보세요."

2. 이미 만드는 중이라면: 핸드오프·출력 계약·워크플로우 연결을 더 고민하기
   특히 "계약처럼 출력 정의하기", "다음 단계로 넘길 수 있게 만들기"를 더 진지하게 보라고 합니다.

3. 팀/엔터프라이즈라면: 3티어로 배포/공유 전략 세우기
   브랜드 표준인지, 팀의 장인 방법론인지, 개인 워크플로우인지에 따라 배포/관리 방식이 달라진다는 거죠.

그리고 마지막으로 다시 한 번 "스킬이 복리로 쌓인다"는 메시지로 돌아옵니다. 스킬은 성공적인 워크플로우 실행 기록을 남기는 방식이고, 그게 미래의 더 똑똑한 에이전트와 미래의 팀에게 그대로 레버리지가 된다고요.

"스킬은 복리로 쌓여요. 미래의 더 똑똑한 에이전트도, 미래의 팀도 그걸로 실행할 수 있게 됩니다."
"프롬프트는 복붙 지옥이지만, 스킬은 지속됩니다."

마무리

이 영상의 결론은 명확합니다. 스킬은 단순한 프롬프트 포장재가 아니라, 에이전트가 호출하는 조직의 실행 인프라가 되었고, 그래서 이제는 트리거(description)·계약(출력)·합성(핸드오프)·테스트(정량 검증) 중심으로 설계해야 합니다. 그리고 표준화가 진행되는 지금, 스킬을 잘 "버전 관리하며 쌓는 팀"이 시간이 지날수록 더 크게 앞서게 된다는 게 핵심 메시지예요.