모델만 바꿨는데 왜 스킬이 안 먹혔을까 — FactSet 수석 AI 엔지니어가 말하는 '스킬 중심 에이전틱 제품' 설계법

출처: TechBridge-KR — [한영자막] 모델만 바꿨는데, 왜 스킬이 안 먹혔을까? · 러닝타임 17분

"에이전트가 제품의 주된 인터페이스가 된다면, 기능은 대체 어디에 살고 있을까요?" — 요기(Yogi), FactSet Principal AI Engineer

이 영상은 금융 데이터·리서치 기업 FactSet의 수석 AI 엔지니어 요기(Yogi)가 AI Engineer World's Fair 무대에서 발표한 "스킬 중심 에이전틱 제품 만들기" 세션을 정리한 것이다. 그는 작년 같은 컨퍼런스에서 '블루프린트(Blueprint)'라는 자체 개념을 발표했었는데, 앤트로픽이 지난해 10월 스킬(Skills)을 정식 출시한 뒤 자체 표준을 유지할 이유가 없다고 판단해 전면적으로 스킬 체계로 전환했다고 밝히며 발표를 시작한다. 이 영상이 특히 유용한 이유는, 스킬을 코딩 에이전트(Claude Code, Codex 등)의 맥락에서만 다루는 대부분의 온라인 담론과 달리, 자체 에이전틱 제품(harness)에 스킬 지원을 어떻게 넣고, 이를 엔터프라이즈 규모로 어떻게 관리하는지에 초점을 맞추고 있기 때문이다. 실제로 수백 개의 스킬을 운영하며 겪은 실패 사례(모델을 업그레이드했더니 아무것도 손대지 않은 스킬이 갑자기 작동하지 않은 사건)와 그로부터 얻은 교훈이 발표의 핵심을 이룬다.

1. 발표자 소개와 배경: 블루프린트에서 스킬로 (00:00~00:39)

요기는 자신을 FactSet의 수석 AI 엔지니어로 소개하며, 회사가 금융 데이터·리서치를 다룬다고 짧게 언급한다. 이어 그는 청중이 사진을 찍느라 발표에 집중하지 못하지 않도록 슬라이드를 별도로 공유하겠다고 안내하고, 자신의 X(트위터) 핸들을 알려주며 발표를 시작한다.

2. 왜 지금 '에이전틱 제품' 관점의 스킬인가 (00:39~02:20)

요기는 작년 같은 컨퍼런스에서 '블루프린트'라는 개념을 발표했다고 밝힌다. 블루프린트란 에이전트에게 매번 경로를 새로 탐색시키지 않도록 넘겨주는 단순한 단계·레시피 모음이었다. 돌이켜보면 이는 아주 초기 형태의 '스킬'이었다는 것이 그의 진단이다. 그런데 앤트로픽이 작년 10월 스킬을 정식으로 오픈소스화하면서 상황이 바뀌었다. "자체 표준을 계속 유지할 이유가 없었다"는 것이 그의 표현이다. 그는 이 전환을 계기로 팀이 블루프린트를 완전히 버리고 스킬 체계를 전면 채택했다고 밝히며, 청중에게 스킬을 직접 만들어본 적이 있는지, 그리고 Claude Code나 Codex 같은 코딩 도구의 맥락을 넘어 자체 하네스(harness)에 스킬을 통합해본 적이 있는지를 손을 들어 확인한다.

이 질문을 던진 이유는 명확하다 — 온라인의 스킬 관련 논의가 대부분 코딩 에이전트의 맥락에 갇혀 있다는 문제의식 때문이다. 요기는 슬라이드로 이 발표의 범위를 명확히 긋는다. 다루지 않는 것은 코딩 하네스, 코딩 에이전트를 위한 스킬, 스킬 작성법이고, 다루는 것은 에이전틱 제품 맥락에서의 스킬, 자체 하네스에 스킬 지원을 추가하는 법, 그리고 엔터프라이즈 규모로 스킬을 확장하는 법이다.

3. 전통적 UI 제품 vs 에이전트가 인터페이스인 제품 (02:20~02:44)

전통적인 제품은 화면, 버튼, 폼, 대시보드로 구성된 표면(surface)이었고 사용자는 이 UI를 직접 탐색했다. 그러나 최근 제품들은 점점 에이전트가 전면에 나서는 인터페이스로 바뀌고 있다. 사용자는 에이전트에게 직접 말을 걸거나, 뒤에서 에이전트가 주된 의사결정자 역할을 하며 사용자의 제품 탐색을 돕는다.

이 지점에서 요기는 핵심 질문을 던진다 — "에이전트가 제품의 주 인터페이스가 된다면, 기능은 대체 어디에 살고 있는가?"

4. Who–What–How 프레임: 프롬프트, 툴, 스킬의 역할 분담 (02:44~03:46)

요기는 이 질문에 대한 답으로 "누가(Who)–무엇을(What)–어떻게(How)"라는 3분할 프레임을 제시한다.

• 프롬프트(Prompt) — 에이전트가 '누구'인지를 정의한다.
• 툴(Tools) — 에이전트가 '무엇'에 연결될 수 있는지를 정의한다.
• 스킬(Skills) — 하나의 작업이 '어떻게' 수행되는지를 알려준다.

즉 스킬이야말로 에이전트의 행동을 좌우하는 비즈니스 로직을 담아두기에 가장 적합한 자리라는 것이 그의 주장이다.

5. 스킬은 새로운 기능이다 — 엔지니어 역할의 이동 (03:46~04:44)

요기는 "스킬이 새로운 기능"이라는 명제를 FactSet의 실제 사례로 설명한다. 금융업에서 매우 중요한 워크플로우인 주식 리서치(equity research)와 자산관리(wealth management)는 예전에는 각각 버튼, 드롭다운, 화면으로 구현되던 것들이었다. 그런데 지금은 이것들이 그저 스킬 하나로 대체됐다는 것이다.

6. 스킬이란 정확히 무엇인가 (04:44~05:33)

스킬(skill)의 사전적 의미는 "어떤 것을 잘 해내는 능력"이다. 이는 모델이 그 스킬 없이도 살아남을 수는 있지만, 스킬이 있으면 확실히 더 잘 해낸다는 것을 의미한다. 요기는 여기서 더 정교한 정의를 제시한다 — "에이전트 스킬이란 AI 에이전트에게 특정 작업을 잘 수행하는 방법을 가르치는 표준화된 방식"이다. 단순한 스킬은 마크다운 파일 하나로 구성될 수 있지만, 복잡한 스킬은 여러 참조 파일과 실행 스크립트를 포함할 수 있다.

SKILL.md는 스킬의 심장이다. 프론트매터(front matter)에 담긴 이름(name)과 설명(description)이 에이전트가 이 스킬을 발견하는 핵심 정보이며, 실제 비즈니스 로직과 지시사항은 스킬 본문에 담기고 여기에 다른 파일·스크립트 참조가 포함될 수 있다.

7. 하네스에 스킬 지원을 넣는 최소 구성 (05:33~06:24)

자체 하네스에 스킬 지원을 넣는 데 필요한 최소 요건은 딱 세 가지뿐이라고 요기는 강조한다.

• 스킬 레지스트리 — 스킬들의 목록
• 시스템 프롬프트 — 스킬을 노출하는 자리
• 기본적인 파일 읽기 툴 — 스킬 본문을 읽어들이는 수단

여기에 만약 스크립트를 실행해야 한다면 bash나 코드 실행 샌드박스 환경이 추가로 필요하지만, 그것 없이도 스킬 지원의 '바닥'은 이 세 가지로 충분하다는 것이 핵심이다.

8. 스킬 레지스트리 설계와 3가지 예시 (06:24~07:04)

스킬 레지스트리는 이름·설명·경로를 가진 스킬들의 단순한 모음이다. 요기는 이를 세 가지 예시 스킬로 설명한다.

• company-research — 특정 회사에 대한 기본적인 웹 검색을 수행해 마크다운 리서치 브리프를 생성한다.
• report-html — 마크다운을 콘텐츠와 구조를 유지한 채 완결된 HTML 리포트로 변환한다.
• report-pdf — 마크다운의 데이터를 채우고 병합해 PDF 파일로 추출한다.

9. 에이전트는 어떻게 스킬을 발견하는가 — Progressive Disclosure (07:04~08:56)

스킬 레지스트리가 준비되면, 이름·설명·경로를 이어붙여 시스템 프롬프트에 넣는다. 여기서 중요한 점은 스킬 본문(body)이 아니라 이름·설명·경로만을 시스템 프롬프트에 넣는다는 것이다. 이것이 바로 '점진적 공개(progressive disclosure)'라고 불리는 방식이다. 에이전트는 스킬 목록을 훑어본 뒤, 실제로 필요한 스킬만 골라 읽고 그 지시사항을 따른다. 그다음 필요한 것이 에이전틱 루프(agentic loop)인데, 이는 시스템 프롬프트를 실행하고 모든 메시지를 배열에 기록하며, 매 턴마다 모델을 호출해 툴 호출이 필요한지 판단하고, 툴 호출이 없으면 최종 출력을 내보내는 구조다. 예를 들어 "엔비디아 리포트를 발행해줘"라는 요청이 들어오면, 에이전트는 company-research 스킬을 호출해 웹 검색을 수행하고, 이어 report-html 스킬(report-pdf가 아니라)을 사용해 HTML 리포트를 만들어낸다.

10. 교훈 1: description은 라우팅 시그널이다 (08:56~10:33)

앞서 예시에서 report-html과 report-pdf라는 두 개의 유사한 스킬이 있었지만, 실제 시연에서는 HTML만 선택됐다. 그 이유는 report-pdf의 설명(description)에 "사용자가 PDF 리포트를 요청할 때만 이 스킬을 사용하라"는 문구가 명시돼 있었기 때문이다. 'PDF'라는 단어 자체가 에이전트에게 어떤 스킬을 골라야 할지 알려주는 트리거 워드였다는 것이다. 이 때문에 description은 '라우팅 시그널'이라 불린다. 요기는 이 슬라이드에서 세 가지 원칙을 제시한다 — ① 스킬 자체를 설명하기보다 그 스킬을 트리거해야 할 요청 문구를 설명할 것, ② 여러 스킬의 설명을 서로 겹치지 않게 뚜렷이 구분할 것, ③ 에이전트의 행동이 바뀔 때마다 설명도 함께 갱신할 것. 설명이 방치돼 오래되면(stale) 트리거가 되지 않는 원인이 되므로 지속적인 관리가 필요하다는 것이다. 아울러 에이전틱 제품 맥락에서는 비개발자 사용자에게 스킬 목록을 일일이 기억하게 하는 인지 부담을 주지 않기 위해, 대부분의 스킬이 사용자에게 직접 노출되지 않고 내부적으로만 작동하는 경우가 많다는 점도 짚는다.

11. 교훈 2: 데이터 모델이 아닌 유저 의도로 스킬을 나눠라 (10:33~11:32)

요기가 스킬 라이브러리를 처음 구축할 때는 좁은 유스케이스만 상정했다 — 예를 들어 'estimation analysis(추정치 분석)' 스킬이나 'fundamentals(기본 재무지표)' 스킬 같은 식이다. 그런데 실제 사용자들이 던지는 요청은 이런 데이터 모델 구조를 반영하지 않았다. 실제 유스케이스는 훨씬 더 실질적인 목적 중심이었고, 그는 이를 반영해 스킬 라이브러리를 여러 차례 리팩터링해야 했다. 그는 이것이 문제가 아니라 자연스러운 과정이라고 말한다 — 처음에는 좁은 유스케이스로 단순하게 시작하고, 더 많은 유스케이스를 발견할수록 스킬 라이브러리를 리팩터링해 나가는 것이 맞다는 것이다. 실무적으로는 이렇게 적용된다:

• ❌ news / analyst-ratings / social-sentiment 스킬 → ✅ pre-market-briefing(개장 전 브리핑) 스킬
• ❌ fundamentals / estimates / earnings-transcript 스킬 → ✅ earnings-preparation(실적 발표 준비) 스킬
• ❌ price-history / ownership / filings 스킬 → ✅ competitive-positioning(경쟁 포지셔닝) 스킬

12. 교훈 3: 모델을 바꿨더니 스킬이 실패한 사건 — Eval의 필요성 (11:32~12:32)

이 발표에서 가장 인상적인 실전 사례가 여기서 등장한다. FactSet 팀이 스택을 새로운 모델로 업데이트하자, 에이전트가 스킬을 지키지 않으면서 갑자기 실패하기 시작했다. 스킬 파일에는 단 한 줄도 손대지 않았는데도 실패한 것이다. 원인을 깊이 파고든 결과, 새 모델이 스킬의 '시작 부분'에만 지나치게 집중하는 경향이 있었고, 정작 매우 중요한 지시사항은 스킬의 '끝부분'에 배치돼 있었다는 것이 밝혀졌다.

13. 스킬이 10개, 100개를 넘어갈 때의 확장 전략 (12:32~13:30)

스킬 개수가 적을 때는 이름·설명을 전부 시스템 프롬프트에 욱여넣는 방식으로도 잘 작동한다. 그러나 스킬 스택이 커지기 시작하면 이 방식은 무너진다. 요기는 대략 10개를 넘는 시점부터 시스템 프롬프트에 넣을 스킬을 어떻게 걸러낼지 고민해야 한다고 조언한다. 방법으로는 임베딩을 활용한 유사도 검색으로 스킬을 추려내거나, 별도의 작은 모델을 두어 관련 스킬만 골라 시스템 프롬프트에 추가하는 방식이 있다. 스킬이 수백 개 규모로 늘어나면 진짜 어려움이 시작되는데, 이때는 스킬의 계층 구조(hierarchy)와 메타데이터 필터, 그리고 라이브러리를 검색 가능하고 일관되게 유지할 거버넌스가 반드시 필요해진다.

14. 엔터프라이즈 스킬 라이브러리 거버넌스 5원칙 (13:30~16:20)

요기는 스킬 라이브러리 거버넌스를 다섯 가지 측면으로 정리한다. "엔터프라이즈스럽게" 들리지만, 각각은 매우 근본적인 질문에 답한다. 그는 거버넌스가 반드시 관료적 병목이 될 필요는 없으며, 자동화 수준과 적절한 사람의 개입(human-in-the-loop)을 어떻게 배치하느냐에 달려 있다고 강조한다. 그리고 이 실천법들은 소프트웨어 코드 관리에서 수십 년간 검증된 것들을 그대로 빌려올 수 있다고 말한다.

요기는 스킬이 많아질수록 자동 목록화(auto-listing) 툴을 마련하고, 툴 자체에도 접근 통제를 걸어 스킬 간 경계를 명확히 지켜야 한다고 마무리한다.

15. 마무리 요약 (16:20~17:10)

요기는 발표를 네 가지 핵심 메시지로 마무리한다. 첫째, 스킬은 에이전틱 제품 안의 기능(feature)이다. 둘째, 우리의 역할은 기능을 출시하는 것에서 하네스를 출시하는 것으로 이동하고 있다. 셋째, 규모가 커질수록 라우팅 메커니즘은 미세조정만으로 해결되지 않으며, 메커니즘 자체가 바뀌어야 한다. 넷째, 엔터프라이즈 규모에서는 스킬 라이브러리 거버넌스가 타협 불가능한 요소다.

한줄 요약 & 체크리스트

한줄 요약: 에이전트가 제품의 인터페이스가 되는 시대에는 스킬이 곧 기능이며, 엔지니어의 일은 기능을 만드는 것에서 스킬이 안전하고 일관되게 작동할 하네스와 거버넌스 체계를 만드는 것으로 바뀌고 있다.

• ☑ 스킬을 코딩 에이전트 전용 개념으로만 보지 말고, 자체 제품/서비스의 '기능'을 대체할 단위로 재검토한다.
• ☑ 하네스에 스킬 지원을 넣을 때 최소 3요소(레지스트리, 시스템 프롬프트, 파일 읽기 툴)만으로 시작할 수 있다는 점을 기억한다.
• ☑ 스킬의 description을 작성할 때 스킬 자체 설명이 아니라 실제 사용자가 쓸 법한 요청 문구(트리거 워드)에 맞춰 작성한다.
• ☑ 스킬을 데이터 모델(예: '추정치', '기본지표') 기준이 아니라 실제 사용자 의도(예: '실적 발표 준비', '개장 전 브리핑') 기준으로 설계한다.
• ☑ 모델을 업그레이드하기 전후로 반드시 평가(eval)를 재실행한다 — 스킬은 문서가 아니라 특정 모델에 종속된 계약이다.
• ☑ 스킬이 10개를 넘기면 임베딩 검색이나 소형 라우팅 모델로 시스템 프롬프트에 넣을 스킬을 선별하는 방안을 검토한다.
• ☑ 스킬이 늘어날수록 Admission·Ownership·Boundaries·Lifecycle·Coherence 다섯 가지 거버넌스 축을 코드 리뷰·CODEOWNERS·버전관리에 빗대어 설계한다.

본 리포트는 유튜브 원본 영상을 요약·정리한 것이며, 이미지 캡처는 학습·비평 목적입니다. 원본 채널: TechBridge-KR