메타데이터
- 채널: Tech Bridge
- 원본 제목: [한영자막] 모델만 바꿨는데, 왜 스킬이 안 먹혔을까?
- URL: https://www.youtube.com/watch?v=IUeXLIuToyU
- 영상 길이: 17:10
- 원본 업로드일: 2026-08-05
- 처리일자: 2026-08-05
- 발표자: 요기(Yogi) — FactSet 수석(Staff) AI 엔지니어, 금융 데이터/리서치 기업 소속
- 주제: 에이전트형 제품에서의 "스킬(Skill)" 설계·발견·거버넌스
1. 핵심 요약 (What / Why / So What)
이 발표는 에이전트 기반 제품(Agentic Product) 을 만들 때, 기능을 "화면·버튼·API"가 아니라 "스킬(Skill)"이라는 단위로 노출하는 것이 왜 새로운 표준이 되고 있는지, 그리고 그 스킬을 실제 하네스(harness)에 어떻게 붙이고 기업 규모로 운영하는지를 다룬다.
- What: 발표자는 작년(2025) 같은 학회에서 "청사진(Blueprint)" — 에이전트에게 미리 정해진 단계/레시피를 전달하는 방식 — 을 발표했었다. 하지만 Anthropic이 2025년 10월 "스킬(Skill)"을 출시하면서, 청사진은 "순진한 형태의 기술"이었음이 드러났고, 팀은 청사진에서 완전히 벗어나 스킬 중심 설계로 전환했다.
- Why: 기존 제품은 화면·버튼·양식·대시보드라는 "표면(surface)"을 사용자가 직접 탐색하는 구조였다. 그러나 에이전트가 제품의 주요 인터페이스가 되는 시대에는, 기능이 어디에 위치해야 하는지가 근본적으로 바뀐다. 발표자는 이를 "프롬프트는 에이전트가 누구인지 정의하고, 도구는 무엇에 연결할지 정의하며, 스킬은 실제로 어떤 일이 어떻게 이루어지는지를 정의한다"는 프레임으로 설명한다. 즉 스킬은 에이전트 동작을 결정하는 비즈니스 로직을 담기에 가장 적합한 장소다.
- So What: 스킬이 새로운 "기능(feature)"이 되면, 제품에 대한 이해도가 높은 비엔지니어도 스킬을 작성해 역량을 확장할 수 있게 된다. 이는 엔지니어의 역할 자체를 바꾼다 — "제품 기능을 직접 출시하는 역할"에서 "제품 구성 요소와 하네스(배선)를 출시하는 역할"로 이동한다. 발표 제목의 질문("모델만 바꿨는데 왜 스킬이 안 먹혔을까")에 대한 답은, 스킬을 단순 문서가 아니라 모델별로 버전 관리되는 계약(contract) 으로 다뤄야 하며, 모델을 업그레이드할 때마다 반드시 평가(eval)를 재실행해야 한다는 것이다.
2. 핵심 발언 및 근거 (원문 인용 기반)
2-1. 청사진(Blueprint) → 스킬로의 전환
"작년 이 학회에서 제가 발표했던 내용이 바로 설계도(청사진)에 관한 것이었습니다. 청사진이란 실제로 에이전트에게 전달할 수 있는 간단한 일련의 단계 또는 레시피로, 에이전트가 매번 경로를 스스로 찾아낼 필요가 없도록 해줍니다." "돌이켜보면, 그것은 아주 순진한 형태의 기술에 불과했던 것 같습니다. Anthropic은 작년 10월에 스킬을 출시했고, 심지어 에이전트를 만들지 말라고 경고하기도 했습니다."
근거: Anthropic이 스킬 기능을 오픈소스로 공개했기 때문에, 팀이 자체적으로 유사한 체계를 유지·개발할 필요가 없어졌고, 그 결과 청사진 방식을 버리고 스킬 방식을 전면 채택했다.
2-2. "누가, 무엇을, 어떻게" 프레임
"프롬프트는 상담원(에이전트)이 누구인지 정의합니다. 도구는 연결할 수 있는 대상을 정의합니다. 그리고 기술(스킬)은 실제로 어떤 일이 어떻게 이루어지는지를 알려줍니다. 그리고 이곳은 에이전트의 동작을 결정하는 비즈니스 로직을 보관하기에 아주 좋은 장소입니다."
2-3. 스킬의 정의
"사전적으로 '기술'이란 어떤 일을 잘 해낼 수 있는 능력을 의미합니다. 즉, 모델은 해당 기능 없이도 작동할 수 있지만, 기능이 있을 때 더 나은 성능을 발휘한다는 의미입니다. 에이전트 스킬에 대한 더 나은 정의는 AI 에이전트에게 특정 작업을 잘 수행하는 방법을 가르치는 표준화된 방식입니다."
- 간단한 스킬: 마크다운 수준의 지침만 포함
- 복잡한 스킬: 여러 파일 및 실행 가능한 스크립트에 대한 참조 포함
skill.md파일 구조: 서두의 이름(name)과 설명(description) = 검색/발견용 핵심 메타데이터, 본문 = 비즈니스 로직과 지침, 그 외 파일·스크립트 참조
2-4. 설명(description)은 "라우팅 신호"다
"설명이 실제로는 라우팅 신호라는 것입니다. 예를 들어 HTML 보고서 작성과 PDF 보고서 작성이라는 두 가지 다른 기술이 있을 때, 사용자가 'PDF' 보고서를 요청할 때만 해당 스킬을 쓰도록 설명에 'PDF'라는 트리거 단어를 넣습니다. 그 단어가 에이전트가 어떤 스킬을 선택해야 할지 알 수 있도록 도와주는 트리거 단어인 겁니다. 설명은 스킬 자체에 대한 내용이 아니라 사용자 요청에 맞춰 작성하는 것이 매우 중요합니다."
중요 시사점: description을 "이 스킬은 무엇을 하는가"로 쓰지 말고 "사용자가 이렇게 말하면 이 스킬을 써야 한다"는 관점으로 작성해야 발동 누락(스킬이 "녹슬어서" 안 먹히는 문제)을 막을 수 있다.
2-5. 스킬은 데이터 모델이 아니라 "사용자 의도"로 조직해야 한다
"제가 스킬 라이브러리를 만들기 시작했을 때는 사용 사례가 매우 제한적이었습니다. 추정 분석 능력이나 기본 사항을 추가해야 하는데, 실제 사용 사례들이 데이터 모델을 제대로 반영하지 못하고 있었습니다. 그것들은 정말 실제 사용 사례에 관한 것이었고, 저는 여러 번 리팩토링을 해야 했습니다."
구체적 사례: "추정 분석(Estimate Analysis) 능력" → 실제로는 "수익 준비(Earnings Prep) 능력"으로 재구성. "뉴스 및 분석가 평가 능력" → "장전 브리핑(Pre-market Briefing) 능력"으로 재구성. 즉 스킬 이름/경계는 내부 데이터 모델이 아니라 사용자가 실제로 요청하는 시나리오 단위로 잡아야 한다.
2-6. 모델을 바꾸면 스킬이 깨지는 이유 (영상 제목의 핵심 답변)
"저희는 스택을 새로운 모델로 업데이트했는데, 스킬을 제대로 따르지 않아서 오류가 발생하기 시작했습니다. 아무것도 바뀌지 않았습니다. 스킬 코드의 단 한 줄도 수정하지 않았는데도 실패했습니다. 그리고 우리가 그 이면을 파헤쳐 보니, 이 새로운 모델은 기술의 기초(basics)에 매우 집중하고 있다는 것이었습니다." "평가를 실시하는 것이 매우 중요하며, 평가 없이 기술을 습득하는 것은 그저 희망사항일 뿐입니다. 스킬은 문서가 아닙니다. 많은 사람들이 스킬을 문서처럼 생각하지만, 스킬은 모델에 맞춰 버전 관리되는 계약과 같습니다. 그러므로 모델을 업그레이드할 때마다 평가를 다시 실행해야 합니다."
핵심 근거: 스킬은 특정 모델의 instruction-following 특성(모델이 무엇을 "기초"로 우선시하는지, 지침을 어떻게 해석하는지)에 암묵적으로 의존한다. 모델 세대가 바뀌면 동일한 스킬 문서라도 해석·실행 방식이 달라질 수 있으므로, 스킬 코드가 그대로여도 결과가 깨질 수 있다. 따라서 스킬은 "정적 문서"가 아니라 "모델 버전에 종속된 계약(versioned contract)"으로 취급해야 하며, 모델 교체 시 반드시 회귀 평가(eval)를 다시 돌려야 한다.
2-7. 규모에 따른 라우팅 메커니즘의 변화
"몇 가지 기술을 가지고 있을 때 시스템 프롬프트에 입력하는 게 정말 효과적이에요. 하지만 스킬 스택을 늘려가기 시작하면 이 방식은 무너집니다. 보유 스킬이 10개 이상이라면, 시스템 프롬프트에 추가할 스킬을 어떻게 추려낼지 생각해 보는 게 좋을 거예요. ... 진짜 문제는 수백 가지 기술을 갖게 될 때 시작됩니다." "그리고 라우팅 메커니즘은 규모가 커짐에 따라 조정되는 것이 아니라, 메커니즘 자체가 변경됩니다."
2-8. 거버넌스의 5요소
"스킬 라이브러리 관리에는 대략 다섯 가지 측면이 있다고 볼 수 있습니다. 그리고 이러한 요소에는 입장(Admission), 소유권(Ownership), 경계(Boundaries), 생명주기(Lifecycle) 및 핵심 요소(Core)가 포함됩니다. ... 하지만 거버넌스라고 하면 꼭 관료주의적인 병목 현상을 떠올릴 필요는 없습니다. 어떻게 구현하느냐에 따라 완전히 달라집니다. 좋은 소식은 우리가 코드에서 많은 좋은 관행들을 빌려와 기술에 적용할 수 있다는 것입니다. 그리고 이러한 코딩 방식은 수십 년 동안 효과가 있었습니다."
3. 사례 / 예시
3-1. 최소 하네스 구성 요소
스킬 지원을 하네스에 추가하기 위한 최소 요구사항 3가지:
- 스킬 레지스트리 (이름, 설명, 습득 경로의 모음)
- 시스템 프롬프트 (레지스트리 정보를 명령어로 연결해 삽입)
- 기본 파일 읽기 도구
- 스크립트 실행이 필요하면 추가로 bash 셸 또는 코드 실행 샌드박스 환경 필요
3-2. 3가지 예시 스킬 (금융 도메인)
- 기업 조사(Company Research) 스킬: 기업에 대한 기본 웹 검색 수행 + 결과 기반 가격 책정
- 보고서 HTML 생성 스킬: 마크다운 → HTML 변환
- 보고서 PDF 생성 스킬: 마크다운 파일 → PDF 변환
3-3. 에이전트 루프 동작 방식
- 시스템 프롬프트에는 스킬의 이름·설명·경로만 포함되고 스킬 본문은 포함되지 않음 → 이것이 Anthropic이 말하는 "점진적 정보 공개(progressive disclosure)"
- 에이전트는 필요한 스킬만 선택해 "읽고" 그 지시를 따름
- 루프 구조: 메시지 배열 추적 → 모델 호출(메시지+도구 사용) → 매 턴마다 도구 호출 여부 판단 → 도구 호출 시 메시지에 추가 → 도구 호출이 없으면 종료 및 결과 출력
3-4. 예시 시나리오: "NVIDIA에 대한 보고서를 발행해달라"
- 사용 가능한 스킬 파악 (활성화 단계)
- 기업 조사 스킬 호출 → 웹 검색 수행
- 보고서 작성(HTML) 스킬 사용 → HTML 형식 보고서 생성
- 만약 사용자가 "PDF"라는 단어를 썼다면 PDF 생성 스킬이 대신 트리거됨 (설명에 박힌 트리거 단어 때문)
3-5. 스킬 재구성 사례 (사용자 의도 중심)
| 기존 (데이터 모델 중심) | 재구성 후 (사용자 의도 중심) |
|---|---|
| 추정 분석(Estimate Analysis) 능력 | 수익 준비(Earnings Prep) 능력 |
| 뉴스 및 분석가 평가 능력 | 장전 브리핑(Pre-market Briefing) 능력 |
3-6. 스킬 라이브러리 거버넌스 5요소 상세
- 입장(Admission): 해당 스킬이 새로 존재해야 하는지, 기존 스킬에 통합돼야 하는지 판단. 팀은 "사람이 개입하는 자동화된 등록 시스템"을 구축 — PR(홍보 자료/코드 리뷰) 검토 프로세스와 유사한 아날로그.
- 소유권(Ownership): 애플리케이션 팀이 기능을 유지 관리하듯, 각 스킬도 코드 오너처럼 지정된 소유자/유지관리자가 필요.
- 경계(Boundaries): 스킬이 많아지면 스킬 목록 자동 생성 도구와 각 도구에 대한 접근 제어(access control) 설정이 중요.
- 생명주기(Lifecycle): 스킬의 시맨틱 버저닝(semantic versioning) 유지. 스킬을 삭제할 때는 항상 사용 중단(deprecation) 경고를 먼저 표시하고 변경 로그(changelog)에 반영.
- 핵심 요소(Core): 좋은 제품에서 기능들이 유기적으로 연결되듯, 역량이 실제로 활용되도록 정기적인 감사(audit)와 검증을 실시.
4. 구조화된 시사점 / 액션 아이템
스킬 설계 원칙
- description은 스킬 설명이 아니라 라우팅 신호로 작성하라. "이 스킬이 무엇을 하는가"가 아니라 "사용자가 어떤 말을 할 때 이 스킬을 골라야 하는가" 관점으로 트리거 단어를 명시적으로 박아 넣을 것.
- 스킬 경계는 내부 데이터 모델이 아니라 실제 사용자 시나리오 단위로 잡아라. 초기 스킬 라이브러리는 사용 사례가 좁으므로 리팩토링을 여러 번 거치는 것이 정상.
- 비기술 사용자의 인지 부하를 낮추기 위해 스킬 목록/설명을 관리할 것 — 스킬이 너무 많으면 사람도, 에이전트도 헷갈린다.
모델 업그레이드 대응 (영상의 핵심 답)
- 스킬을 문서가 아니라 "모델별 버전 계약"으로 취급하라.
- 모델을 교체/업그레이드할 때마다 스킬별 평가(eval) 스위트를 반드시 재실행할 것 — 코드를 한 줄도 안 바꿔도 새 모델의 instruction-following 특성 차이로 스킬이 깨질 수 있음.
- 평가 없는 스킬 배포는 "희망사항(wishful thinking)"에 불과하다는 인식 전환이 필요.
규모별 라우팅 전략
- 스킬 10개 미만: 시스템 프롬프트에 전체 스킬 이름/설명 목록을 그대로 넣는 방식으로 충분.
- 스킬 10개 이상: 임베딩 기반 유사도 검색, 또는 작은 모델을 활용한 사전 필터링으로 시스템 프롬프트에 넣을 스킬을 추려내는 단계 필요.
- 스킬 수백 개 이상: 단순 필터링을 넘어 스킬 계층 구조(hierarchy), 메타데이터 필터, 정식 거버넌스 체계가 필수. 이 지점에서는 "조정"이 아니라 라우팅 메커니즘 자체를 교체해야 한다.
조직 차원의 시사점
- 스킬이 새로운 "기능 단위"가 되면서, 엔지니어의 역할이 "기능을 직접 만드는 사람"에서 "기능을 만들 수 있는 하네스/구성을 제공하는 사람"으로 이동한다.
- 제품 이해도가 높은 비엔지니어(도메인 전문가)도 스킬 작성으로 제품 역량을 직접 확장할 수 있게 되므로, 이를 지원하는 등록·리뷰·소유권 프로세스를 코드 리뷰 관행에서 빌려와 구축할 것.
- 코드베이스에 이미 검증된 관행(코드 오너, PR 리뷰, 시맨틱 버저닝, 사용 중단 경고, 변경 로그, 접근 제어)을 스킬 라이브러리에도 그대로 이식하면 거버넌스를 관료적 병목 없이 운영할 수 있다.
실무 체크리스트
- [ ] 스킬 description에 사용자 트리거 단어(예: "PDF")가 명시적으로 들어가 있는가?
- [ ] 각 스킬에 대한 평가(eval) 케이스가 존재하는가, 모델 교체 시 자동 재실행되는가?
- [ ] 스킬 소유자가 코드 오너처럼 명시적으로 지정되어 있는가?
- [ ] 스킬 폐기 시 사용 중단 경고 + 변경 로그 프로세스가 있는가?
- [ ] 스킬 수가 10개를 넘어갈 때 임베딩/필터링 기반 선별 라우팅으로 전환할 계획이 있는가?