▲

Claude Skills는 굉장하다, MCP보다 더 큰 혁신일지도

 (simonwillison.net)
26P by GN⁺ 2일전 | ★ favorite | 댓글 12개
  • Anthropic이 발표한 Claude Skills는 모델이 특정 작업을 수행할 때 필요한 지침, 스크립트, 리소스를 폴더 형태로 제공하는 새로운 패턴으로, 작업별 전문성을 동적으로 로드하는 방식
  • Skills는 Markdown 파일과 선택적 스크립트로 구성되며, 세션 시작 시 각 스킬의 메타데이터만 수십 개 토큰으로 로드한 뒤 실제 필요할 때만 전체 내용을 불러와 토큰 효율성이 매우 높음
  • Claude Code를 통해 Skills는 단순한 코딩 도구를 넘어 범용 자동화 에이전트로 확장되며, 파일시스템과 명령 실행 환경만 있으면 다양한 작업 자동화가 가능
  • MCP와 달리 Skills는 프로토콜이 아닌 Markdown과 YAML 기반의 단순한 구조로, 다른 모델이나 도구에서도 즉시 활용 가능하며 공유와 확산이 용이
  • 이러한 단순함과 효율성 덕분에 Skills는 MCP보다 훨씬 빠른 속도로 생태계가 확장될 것으로 예상되며, 데이터 저널리즘부터 브랜드 가이드라인까지 다양한 분야에서 전문화된 에이전트 구축이 가능 (MCP의 토큰 소모 문제와 복잡한 사양을 피할 수 있음)

Skills의 개념과 구조

  • Anthropic이 2025년 10월 16일 Claude Skills 를 공식 발표
    • 모델이 특정 작업(예: Excel 작업, 조직의 브랜드 가이드라인 준수)을 수행할 때 필요한 지침, 스크립트, 리소스를 담은 폴더 단위의 능력 확장 시스템
    • Claude는 작업과 관련이 있을 때만 해당 스킬에 접근하여 전문화된 작업 수행 능력을 향상
  • anthropic/skills GitHub 저장소에서 공식 스킬 예제 제공
  • Skills는 개념적으로 극도로 단순
    • 핵심은 모델에게 작업 수행 방법을 알려주는 Markdown 파일
    • 선택적으로 추가 문서와 미리 작성된 스크립트를 포함하여 작업 완수를 지원
  • 9월 발표된 Claude의 문서 생성 기능이 실제로는 Skills로 완전히 구현되었음
    • .pdf, .docx, .xlsx, .pptx 파일 처리 스킬이 공개 저장소에서 확인 가능

토큰 효율성: Skills의 핵심 장점

  • 세션 시작 시 Claude는 모든 사용 가능한 스킬 파일을 스캔하고 각 스킬의 frontmatter YAML에서 짧은 설명만 읽음
  • 각 스킬이 차지하는 초기 토큰은 수십 개에 불과하여 극도로 효율적
  • 사용자가 스킬이 도움될 수 있는 작업을 요청할 때만 전체 세부 내용이 로드됨
  • 이는 단순히 디스크에 파일을 저장하는 것을 넘어 기능으로 만드는 핵심 차별점

Slack GIF 생성 스킬 실습 사례

  • slack-gif-creator 스킬 메타데이터 설명
    • Slack에 최적화된 애니메이션 GIF 생성 툴킷
    • 크기 제약 검증기와 조합 가능한 애니메이션 기본 요소 포함
    • "X가 Y를 하는 Slack용 GIF를 만들어줘" 같은 요청에 적용
  • 실제 테스트 과정
    • Claude 모바일 웹앱에서 Sonnet 4.5 모델로 slack-gif-creator 스킬 활성화
    • "Make me a gif for slack about how Skills are way cooler than MCPs" 프롬프트 입력
    • Claude가 자동으로 GIF 생성 (품질은 개선 필요하지만 스킬의 반복 개선이 용이함)
  • 생성된 Python 스크립트의 주목할 점
    • 스킬 디렉토리를 Python 경로에 추가: sys.path.insert(0, '/mnt/skills/examples/slack-gif-creator')
    • 스킬의 core/ 디렉토리에 있는 GIFBuilder 클래스 활용
    • 파일을 /mnt/user-data/outputs/에 저장
    • Slack 크기 제한(2MB) 검증 함수 check_slack_size() 사용으로 규격 준수 확인
    • 크기가 초과되면 모델이 자동으로 더 작은 파일을 재생성 시도 가능

Skills의 환경 의존성

  • Skills 메커니즘은 모델이 다음에 접근할 수 있어야 완전히 작동
    • 파일시스템
    • 파일시스템 탐색 도구
    • 환경에서 명령 실행 능력
  • 이는 LLM 툴링의 일반적인 패턴
    • ChatGPT Code Interpreter가 2023년 초 최초의 대규모 사례
    • 이후 Cursor, Claude Code, Codex CLI, Gemini CLI 같은 코딩 에이전트 도구로 로컬 머신까지 확장
  • 이 요구사항은 MCP, ChatGPT Plugins 등 이전의 LLM 능력 확장 시도와의 가장 큰 차이점
  • 중요한 의존성이지만 잠금 해제되는 새로운 능력의 규모가 놀라울 정도로 큼
  • 안전성 문제는 여전히 중요
    • 안전한 코딩 환경 제공 필요
    • 프롬프트 인젝션 같은 공격을 허용 가능한 수준의 피해로 제한할 수 있도록 샌드박스 환경 구축 방법 필요

Claude Code: 범용 에이전트로의 진화

  • 2025년 1월 저자는 "에이전트"가 실패할 것이라 예측했으나 완전히 빗나감
    • 2025년은 실제로 "에이전트"의 해가 되었음 (다양한 정의가 존재하지만 "tools in a loop"로 정의)
  • Claude Code는 이름이 잘못 붙여짐
    • 순수한 코딩 도구가 아니라 범용 컴퓨터 자동화 도구
    • 컴퓨터에 명령을 입력해서 달성할 수 있는 모든 작업을 자동화 가능
    • 범용 에이전트(general agent) 로 설명하는 것이 가장 적절
  • Skills는 이 가능성을 훨씬 더 명확하고 명시적으로 만듦
  • 응용 가능성이 현기증 날 정도로 광범위
    • 데이터 저널리즘 예시: 다음 작업을 다루는 스킬 폴더 구성 가능
      • 미국 인구조사 데이터 출처 및 구조 이해
      • 다양한 형식의 데이터를 Python 라이브러리로 SQLite/DuckDB에 로드
      • S3의 Parquet 파일이나 Datasette Cloud 테이블로 데이터 온라인 게시
      • 새로운 데이터셋에서 흥미로운 스토리를 찾는 방법(경험 많은 데이터 리포터의 지침)
      • D3를 사용한 깔끔하고 가독성 높은 데이터 시각화 구축
    • 결과: Markdown 파일과 몇 개의 Python 스크립트 예제만으로 미국 인구조사 데이터에서 스토리를 발견하고 게시하는 "데이터 저널리즘 에이전트" 구축 완료

Skills vs MCP 비교

  • Model Context Protocol(MCP) 는 2024년 11월 출시 이후 엄청난 관심 획득
    • 모든 기업이 "AI 전략"이 필요했고, MCP 구현 발표가 그 요구를 충족하는 쉬운 방법이었음
  • MCP의 한계가 점차 드러남
    • 가장 중요한 문제는 토큰 사용량
    • GitHub의 공식 MCP는 그 자체만으로 수만 개의 컨텍스트 토큰 소비
    • 몇 개 더 추가하면 LLM이 실제 유용한 작업을 할 공간이 거의 남지 않음
  • 코딩 에이전트를 진지하게 다루기 시작한 이후 저자의 MCP 관심도 감소
    • MCP로 달성할 수 있는 거의 모든 것을 CLI 도구로 대체 가능
    • LLM은 cli-tool --help 호출 방법을 알고 있어 사용법 설명에 많은 토큰을 소비할 필요 없음
    • 모델이 필요할 때 스스로 파악 가능
  • Skills는 정확히 같은 장점 보유, 더 나아가 새 CLI 도구 구현조차 불필요
    • 작업 수행 방법을 설명하는 Markdown 파일만 드롭
    • 안정성이나 효율성 향상에 도움이 되는 경우에만 추가 스크립트 포함

Skills 생태계의 폭발적 성장 전망

  • Skills의 가장 흥미로운 점 중 하나는 공유의 용이성
    • 많은 스킬이 단일 파일로 구현될 것으로 예상
    • 더 정교한 스킬은 몇 개 파일이 있는 폴더 형태
  • Anthropic 제공 자료
  • 저자도 Datasette 플러그인 빌드 방법 같은 스킬 아이디어 구상 중
  • 다른 모델에서도 사용 가능: Skills 설계의 또 다른 장점
    • 스킬 폴더를 Codex CLI나 Gemini CLI에 연결하고 "pdf/SKILL.md를 읽고 이 프로젝트를 설명하는 PDF를 만들어줘"라고 하면 작동
    • 해당 도구와 모델이 스킬 시스템에 대한 내장 지식이 없어도 가능
  • 예상: 올해의 MCP 러시를 초라하게 만들 정도로 Skills의 캄브리아기 폭발 발생

단순함이 핵심 강점

  • 일부에서는 Skills가 너무 단순해서 기능이라 하기 어렵다는 반발 존재
    • 많은 사람들이 Markdown 파일에 추가 지침을 넣고 코딩 에이전트에게 읽게 하는 트릭을 이미 실험
    • AGENTS.md는 잘 확립된 패턴이며, "PDF 생성 전에 PDF.md를 읽으라"는 지침 포함 가능
  • Skills 설계의 핵심 단순함이 바로 저자가 흥분하는 이유
  • MCP는 전체 프로토콜 사양
    • 호스트, 클라이언트, 서버, 리소스, 프롬프트, 도구, 샘플링, 루트, 엘리시테이션
    • 세 가지 전송 방식(stdio, streamable HTTP, 원래는 SSE) 포함
  • Skills는 Markdown + 약간의 YAML 메타데이터 + 선택적 실행 스크립트
    • LLM의 정신에 훨씬 가까움: 텍스트를 던지고 모델이 알아서 처리하게 함
  • Skills는 어려운 부분을 LLM 하네스와 관련 컴퓨터 환경에 아웃소싱
    • 지난 몇 년간 LLM의 도구 실행 능력에 대해 배운 모든 것을 고려할 때 매우 현명한 전략
▲
shakespeares 18시간전  [-]

코딩에 있어서 claude Code 사용할 때도 접목이 되는 부분일까 싶기도 하네요.
현재도 Claude.md에 가이드를 넣어놓고 세부가이드는 각각 나눠서 진행하고 있는데요.

답변달기
▲
labeldock 1일전  [-]

적은 토큰으로 많은 작업을 수행하려면 프롬프트 최적화보단 멀티 에이전트와 요약을 활용하는 방식으로 간단하게 해결할 수 있을것 같은데요. 문제점은 동감하는데 해결방식은 한계가 있게 느껴지네요

답변달기
▲
savvykang 2일전  [-]

Skills도 토큰을 사용하지 않나요? 만약 그렇다면 토큰 사용량 문제가 또 발생할 것 같은데 그때는 어떻게 대응할지 잘 모르겠네요

답변달기
▲
dnjstmxhs 1일전  [-]

컨텍스트에 SKILLS.md 전부가 아니라 상단에 아래같이 이름과 설명 부분만 일단 항상 들어가는걸로 보이더라고요.

name: skill-creator
description: Guide for creating effective skills. This skill should be used when users want to create a new skill (or update an existing skill) that extends Claude's capabilities with specialized knowledge, workflows, or tool integrations.
license: Complete terms in LICENSE.txt

답변달기
▲
ds2ilz 2일전  [-]

클로드 코드로 일하다 보면 지침이나 규정을 계속 컨텍스트로 먹이게 되는데 결국 토큰 사용량과 컨텍스트 사이에서 고민을 하게 되더군요. 그러다 생각한게 폴더를 만들어서 상세 내용은 거기에 기능별 md로 자세하게 써넣고 claude.md 에는 뭐 하려면 뭐 봐 하는 포인터만 잔뜩 넣는 방식이었는데 꽤 싸게 잘 작동했습니다. skills 가 결국 이런거 모아놓은걸테니 꽤 쓸만하겠네요

답변달기
▲
laeyoung 16시간전  [-]

그리고 발표한대로 skills marketplace도 나오면, 필요한 skill들만 받아다가 필요할때 enable 시켜놓고 나름 괜찮을거 같더라고요

답변달기
▲
shakespeares 18시간전  [-]

오 핵심 설명 감사합니다.

답변달기
▲
killdong 2일전  [-]

주저리주저리 개소리 할필요 없고, 핵심은 컨텍스트 핸들링을 어떻게 하면 효율적으로 하는가의 문제가 전부인듯.

답변달기
▲
dnjstmxhs 1일전  [-]

컨텍스트 핸들링이랑 클로드 스킬이랑 어떤 연관이 있으려나요? 전 이미 이전에 있었던 클로드 코드 커스텀 커맨드랑 뭐가 다른거지? 라는 생각이 들었는데 문서를 읽다보니 가장 큰 차이점은 아무래도 하나의 스킬 안에 파이썬이나 자바스크립트 같은 스크립트 코드를 포함시켜 실행시킬수 있다는 점이 큰 차이점으로 느껴지더라고요

답변달기
▲
killdong 2일전  [-]

Hacker News에 대해 개소리라 말한건 아니니 오해 없길 바래요.

답변달기
▲
GN⁺ 2일전  [-]
Hacker News 의견

  • 저에게 Claude Skills는 RAG를 사용자 경험 측면에서 쓸데없이 어렵게 만든다는 증거로 보임. 기술적으로 복잡한 게 아니라 UX가 문제임. 이 부분만 잘 해결하면, Claude Skills 자체가 불필요해질 것 같음. Claude Skills가 MCP보다 나은 점은 만들기 쉽다는 것임. 그냥 글쓰기로 만들 수 있으니 누구나 쓸 수 있음. 하지만 환경에 크게 의존함. 예로, 동작에 필요한 특정 도구가 필요할 때 이를 자동화하려면 샌드박스 세팅은 어떻게 함? 심지어, 제대로 된 버전이 맞는지도 확신하기 어려움

  • 우리 회사 내부적으로 비슷한 걸 시도하고 있음. 우리 monorepo의 컨텍스트 파일이 너무 커져서, 작업별로 점진적으로 로드되는 fragment 트리를 구축했음. 이런 컨텍스트 문서들이 기존 개발자 문서와 굉장히 비슷해 보이지만, 실제로는 훨씬 쓸모 있고 작업 지향적임. 예전엔 왜 이런 문서를 만들지 못했는지 궁금해짐.

    1. 피드백 루프가 너무 길었음. 문서를 써도 그게 효과적인지 평생 모를 수 있고, 알게 되는 건 몇 년 뒤일 수도 있음. 변경해도 A/B 테스트 같은 건 불가능했음. 이젠 간단히 컨텍스트 마크다운을 써보고 Claude에게 시켜서 바로바로 개선 가능함
    2. 도구들이 문서 작성 자체도 쉽게 해 줌. 좋은 문서를 만드는 건 과거에는 항상 어려웠고, 예시나 링크, 유용한 부가 정보를 넣으려면 시간이 엄청 들었는데, 이젠 도구 덕에 비용이 줄어듦
    3. 개발자 중에는 이기적인 사람도 많음. 남을 위해 쓰는 문서는 의욕이 잘 안 생기는데, AI를 더 잘 부릴 수 있게 해주는 문서라면 스스로 동기부여가 생김 혹시 다른 이론들이 있는지 궁금함

    • 이건 사실상 principal agent 문제에 marshmallow test 성격이 섞인 것임. 개발자가 AI가 아니라 타인을 위해 문서를 쓴다면, 그 사람이 누군지, 무엇이 필요한지, 심지어 그걸 볼지조차 알 수 없음. 물론 나중에 자기한테도 도움이 될 수 있지만, 그걸 이해하거나 시간, 규율을 갖추기 어려움. 하지만 AI가 문서를 활용해서 나를 직접 도와주는 상황이라면, 필요한 정보를 기록할 엄청난 즉각적인 동기가 생김. 또한 피드백 루프도 짧아짐. 참고로, LLM 특성상 코드 주석이 잘 지워지기 때문에 요즘은 문서를 더 많이 남기고 주석은 확 줄었음

    • 신규 개발자는 문서가 엉망이어도 멍청해 보인다는 이유로 불평을 잘 안 함. 작성자는 이미 자기 머릿속에 모델이 있어서 문제를 잘 못 느끼고, 문서를 잘 쓰는 건 자기 일자리를 위험하게 만드는 행위였음. 하지만 멍청한 로봇에게 엉망인 문서를 건네면, 그게 잘 안 돼도 스스로를 탓해야 함. 결국 #2 + #3이라고 생각함. 큰 변화라면 '교체 가능성'이 부정적에서 긍정적으로 변한 거임 (자기 자리를 값싼 에이전트에게 빼앗기기 전에 스스로 에이전트로 대체함)

    • 기술 부채가 존재하는 이유와 비슷함: 비즈니스 압박, 잘못된 설계, 리소스 부족. 코드를 바꿀 때마다 좋은 문서를 계속 유지하기가 과거에는 정말 비용이 많이 들었음

  • 폴더 안에 여러 skills가 있다고 상상해보라고 했을 때, 미국 센서스 데이터 위치나 구조 해석 방법 같은 태스크를 커버하는 상황이 떠오름. 이 얘기를 듣자마자 Wolfram Alpha를 처음 썼을 때가 생각남. 일반 검색엔진과는 다르게 진짜 구조화된 도구로 문제를 푸는 것에 압도당했었음. 지금 다시 써봤는데도 여전히 대단함: Wolfram Alpha로 미국 인구 쿼리하기. 내 머릿속의 Skills 모델은 Wolfram Alpha에 커스텀 확장을 추가한 것과 비슷함

    • 당신이 올린 링크를 클릭해보니 Wolfram Alpha에서 쿼리가 what%27s the total population of the United States%3F로 열림. 결과값이 재미있는데, 6.1% mod 3 °F (2015-2019 American Community Survey 5-year estimates)라고 나옴. 이게 어떻게 계산된 건지 궁금함

    • 솔직히 옛날 Wolfram Alpha는 정말 미친 성과였음. 어떻게 그 당시 AI 없이 복잡한 수학 문제까지 다루는 시스템을 구현했는지 지금도 신기함

  • Skills와 기존의 도구의 차이가 좀 헷갈림. 많은 skills가 그냥 도구라고 볼 수도 있고, 혹은 여러 도구 묶음에 설명을 더한 느낌임. 그런데 도구 정의와 skill 정의가 서로 다른 위치에 있지 않나? 둘 사이의 dependency를 어떻게 표현해야 하는지 궁금함. skills가 "커맨드라인 사용 가능, python, tool A, tool B가 필요하다"라고 명시하면 skill 로드 시 이런 도구들이 함께 활성화된다는 의미인가?

  • 실제로 주목할 점은 모든 이들이 MCP에 과몰입하고 경로 의존적으로 행동했다는 점임. 진짜 흥미로운 건 사실 단순히 "tool call" 그 자체임. tool call이 정말 유용하고 신기함. MCP는 단지 그걸 위한 여러 수단 중 하나일 뿐임. 게다가 그리 뛰어난 방식도 아님

    • MCP가 엄청나게 퍼진 건 타이밍이 전부라고 생각함. MCP 이전에도 도구 호출은 존재했지만, 모델이 그걸 잘 못했음. MCP 등장 시기가 정확히 모델들이 도구 호출을 잘하기 시작한 때와 맞물림. 그래서 결국 LLM이 다른 시스템과 상호작용 용도로 도구를 호출할 수 있다는 사실을 사람들이 알게 된 게 MCP 열풍의 본질임

    • MCP 서버는 사실상 tool call을 등록하는 레지스트리임. 그럼 일반 tool call보다 뭐가 나쁨?

    • MCP가 의미 있는 건 LLM에게 oauth 개념을 알려준다는 점임. 그래서 서버 기반 도구 호출이 가능해진 것임. 예전엔 쓸 cli마다 별도로 설치하고 그 안에서 인증을 따로 처리해야 했음. tool calling이 LLM의 가장 큰 장점임은 맞지만, "도구 인증에 신경 써야 한다"는 메시지가 드러난 것도 꽤 큰 가치라고 생각함

    • 참고로, MCP도 Anthropic이 혁신했던 기능임을 알려줌

    • Skills를 빼고라도, MCP보다 더 나은 방식이 있다면 어떤 게 있는지 궁금함

  • MCP의 영향력은 터미널을 넘어서 훨씬 넓음. ChatGPT, Claude Web, n8n, LibreChat에서도 쓸 수 있고, 인증, 리소스, 심지어 UI(apps-sdk 등)까지 고민되어 있음. 코딩 워크플로우나 CLI 기반 에이전트(Claude Code 등) 위주라면 CLI 도구도 엄청난 가치가 있지만, CRM, 영업, 지원, 운영, 재무 같은 영역에서는 MCP 기반 도구가 더 적합한 형태임. Skills와 MCP는 경쟁 관계가 아니라 상호 보완적인 목적임. 특히 Skills의 파이썬 코드가 interpreter로 직접 MCP를 호출할 수 있을 때가 진정한 도약임(우리도 해봤고 아주 잘 됨)

    • MCP가 터미널 기반 도구에 비해 큰 장점 중 하나는 완전 분리된 리눅스 환경 같은 샌드박스 없이도 동작할 수 있다는 점임. 그리고 훨씬 단순한 모델로도 쓸 수 있음. 노트북이나 심지어 폰에서 돌아가는 모델도 MCP 두세 개는 충분히 다룰 수 있음. 솔직히 이런 모델에게 파일도 읽고 curl까지 신뢰성 있게 하라고 시키긴 무리임

    • LLM을 외부 소프트웨어나 물리적 세계와 통합하는 게 요즘 정말 멋진 느낌임. 이 모든 게 자연어로 가능함. 심지어 LLM이 MCP 서버 코드를 만들어낼 수 있어서, 완전히 새로운 기능을 손쉽게 생성 가능함

  • 솔직히 MCP가 과대평가됐고 한계도 명확하다고 생각함. 현재 MCP 서버의 95%는 쓸모없고, 그냥 단순한 tool call로 충분히 대체 가능함

    • 당연한 말이지만, 잘 만든 MCP 서버는 정말 좋음. 반면 엉망인 MCP 서버는 오히려 더 심각한 문제를 만듦. 보통 모든 제품팀이 "MCP가 핫하다"는 이유만으로 반드시 MCP 서버를 만들어야 한다는 압박을 받음. 고객들도 AI 활용에 대한 목표가 무조건 있기 때문에 이런 걸 요구함. 하지만 실제로 뭘 원하는지 모르고 그냥 "AI 들어갔다"라고만 하면 됨. 그래서 제품팀도 AI 도입이 뚜렷한 효과는 없지만, MCP 덕분에 빠르게 "우리 AI 제품임"이라고 홍보할 수 있음. AI 본질과는 크게 관련 없는 현상임

    • MCP는 서버 제공자를 신뢰해야만 쓸 수 있음. 사실상 서버의 정직성에 의존함. 실제로 Uber 같은 회사는 갖은 prompt engineering으로 LLM이 자기 서비스를 최고의 옵션이라 생각하게 끊임없이 유도할 것임. 결국 MCP publisher와 consumer 사이에는 인센티브가 완전히 어긋남

    • 결국 tool call이 핵심임에는 동의함. 하지만 MCP가 CLI 대비 적어도 두 가지 이점이 있음. 하나는 tool call LLM이 구조화된 출력을 요구하면서 복잡한 상호작용을 구현할 때 MCP가 CLI보다 쉽다는 것임. 또 하나는 tool call 사이에 state를 MCP 서버에서는 자연스럽게 유지할 수 있음. 처음엔 나도 hype에 쉽게 넘어간 게 아닌가 했지만, 최근 MCP 배워보려고 만든 작은 데모(https://github.com/cournape/text2synth)가 CLI로 만드는 것보다 쉬웠고, 이런 예가 MCP의 신기한 활용 가능성을 잘 보여준다고 생각함

    • MCP 서버는 해커들에게 굉장히 인기가 많은 느낌임. 부실하게 설정되고 대충 배포된 인스턴스가 너무 많음. 기업들이 기존의 모든 배포 방어선을 삭제해버린 상태임

    • 우리 프론트엔드 팀은 figma MCP에서 엄청난 가치를 뽑아냄. 3주 걸릴 일을 하루 만에 끝낼 수 있었음

  • 나도 markdown 파일 몇 개로 skills와 맞먹는 걸 만들었음. 세션마다 한 번 정도 에이전트에게 skill을 리마인드해주는 정도면 충분함. Claude가 이걸 한다고 해서 뭐가 특별한지 잘 모르겠음

    • 일종의 패턴에 이름 붙이기가 중요한 부분임. 이미 많은 이들이 자연스럽게 발견해서 쓰던 유용한 패턴인데, 이름이 생기니 더 수준 높은 논의가 가능해짐. Anthropic은 특히 이 패턴이 코딩 에이전트의 고질적 문제였던 'context 오염' 해결에 도움이 된다는 것도 포착함. 예전 AGENTS.md나 MCP는 문맥에 너무 많은 정보가 들어가서 비실용적이었는데, skills 패턴이 훨씬 더 효율적임

    • 이미 해결된 문제를 공식적으로 구조화하고 자동화를 조금 더한 느낌임. 이전에 써보던 MCP들 중엔 그냥 fancy한 문서 검색 기능이었던 게 많은데, 이런 식의 skills가 그걸 대체해줄 것으로 기대함

    • 나도 같은 궁금증이 있음. Aider나 CC로 이걸 1년 넘게 써왔음

  • 이거 조금 부정적일 수 있는데, 비슷하게 느끼는 사람이 있는지 보고 싶음. 이런 서비스를 평균적인 사용자가 직접 세팅하라고 하면, 그들은 '미쳤냐'고 생각하는 게 맞음. 대부분은 그냥 로그인하고, 무언가를 요청하면 시스템이 나머지를 알아서 처리해주길 바람. MCP, Apps, Skills, Gems 등은 다 문제를 잘못 잡고 있음. 이건 유튜브에서 6개월마다 "새로운 프로그래밍 언어나 프레임워크가 최고다" 하면서 todo 앱 만들었다가 똑같은 영상 최대 6번 거듭하는 채널과 비슷함. 정말 반복적인 표면적 개선만 있고, 근본적인 문제는 안 풀리고 있음. 기술 장르 어딘가에서 뭔가 잘못됐고, 돈이 몰입되면 이런 발표만 쏟아지고, 다음 릴리즈만 내고 진급, 이직하며 본질적 가치는 안 남는 것 같음

    • 근본 문제가 해결되지 않는다는 주장에 대해 말하자면, 요즘은 솔루션이 아예 새로운 문제까지 패키지로 챙겨옴. 박스를 열면 문제와 솔루션이 동시에 튀어나와서 서로 좇고 도망감. 그리고 자신이 기술적으로 더 발전한 인간이 된 것 같다고 느낌

    • MCP, Apps, Skills, Gems 등 전부 잘못된 문제를 고민한다는 말에 대해, 내 부정적 시각으로는 우리가 AI를 위해 더 많은 문서와 API를 만들고 있는데, 사실 인력을 위한 문서로 만들었어도 결과는 비슷했을 것임. 내 시간의 절반은 문서 없는 복잡 시스템 디버깅에 끌려 다녔음

    • "근본 문제"가 뭐며, 2023년 ChatGPT 대중화 이전에는 이런 "근본 문제"를 해결하는 주기가 어느 정도였는지 궁금함

    • "todo 앱을 같은 내용으로 6번 만든 뒤 잊어버린다"는 말을 예로 들면, 이게 무슨 문제인지 잘 모르겠음. 기술은 원래 점진적, 반복적으로 나아감. 누군가는 내일 또 최고의 프론트엔드 프레임워크라는 영상을 올릴 것이고, 예전엔 Nextjs, 그 전엔 React, Angular, JQuery, PHP, HTML로 똑같이 했었음. 만약 AI에 총알이 몰리지 않았다면 아직도 GPT-3, Claude 2에서 멈췄을 것임. 도구 측면에서 허접한게 나올 때도 있지만(나는 Skills는 꽤 좋다고 생각함), 이런 걸 보고 업계 전체가 썩었다고 할 순 없다고 봄

    • 뭐, 아직 모든 게 시작 단계고 제대로 뭐가 통하는지 아무도 모름. 표면적인 시도 같지만 사실상 최첨단임

  • 이건 완전히 다른 개념임. MCP는 외부 서비스 연결, oauth 같은 인증 처리까지 포함됨. Skills는 사실상 cli 도구 + 프롬프트 조합임. 활용 영역이 다르니 쉽게 비교 불가임. 참고로, MCP 등장 이전에 우리도 Skillset이란 시스템을 만들어 썼는데, 지금 보니 MCP와 Skills의 장점이 섞인 최고의 하이브리드였다고 생각함

답변달기
▲
github88 2일전  [-]

호들갑은 진짜

답변달기