Published on

Claude Cowork 플러그인: 에이전트를 팀 운영 레이어로 바꾸는 Anthropic의 새 승부수

Authors

Claude Cowork · Plugins · Agent Skills · MCP

Anthropic의 최근 움직임에서 중요한 건 “Claude가 또 똑똑해졌다”가 아니다. 더 정확한 변화는 Claude를 개인용 채팅창에서 팀 단위 업무 운영 레이어로 끌어올리려는 시도다. Claude Cowork는 사용자가 목표와 주기를 주면 결과물을 만들어 돌아오는 위임형 작업 표면이고, 플러그인은 그 표면에 역할·도구·절차를 꽂아 넣는 패키징 방식이다.

Claude Cowork 플러그인 커버

이번 글의 관전 포인트는 간단하다. Anthropic이 공개한 Knowledge Work Plugins, Claude Code Plugins Directory, Agent Skills, 그리고 Claude Cowork 제품 페이지를 같이 보면, 에이전트 시장의 경쟁축이 “모델 호출”에서 업무 패키지 배포와 운영 거버넌스로 이동하고 있다.

기준 시점: 이 글은 2026-05-27에 확인한 Anthropic 공식 제품 페이지, Claude Code 문서, GitHub 저장소 README/API 메타데이터를 바탕으로 썼다. Claude Cowork와 플러그인 디렉터리는 빠르게 바뀔 수 있으니 실제 도입 전 최신 문서를 다시 확인해야 한다.

왜 지금 이 주제가 중요한가

Claude Cowork 제품 페이지는 Cowork를 “Hand off a task, get a polished deliverable”이라고 설명한다. 사용자가 세부 단계마다 지시하는 채팅이 아니라, 목표와 주기를 설명하면 Claude가 파일 정리, 보고서 작성, 스프레드시트 생성, 메모 분석 같은 작업을 실행하고 결과물을 돌려주는 방향이다.

여기까지만 보면 “컴퓨터를 조작하는 에이전트” 이야기처럼 들린다. 하지만 더 중요한 층은 플러그인이다. Cowork 페이지는 플러그인을 “팀의 도구, 지식, 워크플로를 한 번에 설치 가능한 묶음”으로 설명하고, 구성요소를 Skills, Connectors, Sub-agents로 나눈다. 즉 Anthropic은 Cowork를 단순 실행면으로, 플러그인을 그 실행면에 꽂는 조직 지식·도구 패키지로 보고 있다.

이 구도가 중요한 이유는 세 가지다.

  • 에이전트의 품질 병목이 프롬프트 한 줄이 아니라 업무 절차의 패키징으로 이동한다.
  • 팀 단위 도입에서는 모델보다 권한, 커넥터, 승인, 감사 가능성이 더 중요해진다.
  • 플러그인 디렉터리와 마켓플레이스가 커지면, 에이전트 생태계는 앱스토어보다 운영 플레이북 저장소에 가까워진다.

Knowledge Work Plugins는 “업무별 에이전트 번들”이다

Anthropic의 anthropics/knowledge-work-plugins 저장소 README는 플러그인을 아주 실용적으로 정의한다. 플러그인은 Claude를 특정 역할, 팀, 회사에 맞는 전문가로 바꾸며, Cowork용으로 만들어졌지만 Claude Code와도 호환된다. 저장소는 productivity, sales, customer-support, product-management, marketing, legal, finance, data, enterprise-search, bio-research, cowork-plugin-management 같은 11개 플러그인을 공개한다.

여기서 중요한 건 플러그인이 “프롬프트 모음”이 아니라는 점이다. README는 각 플러그인이 특정 직무를 위한 skills, connectors, slash commands, sub-agents를 묶는다고 설명한다. 예를 들어 finance 플러그인은 Snowflake, Databricks, BigQuery, Slack, Microsoft 365 같은 커넥터를 전제로 하고, legal 플러그인은 계약 검토, NDA triage, compliance, risk assessment 같은 반복 업무를 겨냥한다.

Claude 플러그인 구조

저장소의 기본 구조도 꽤 명확하다.

plugin-name/
├── .claude-plugin/plugin.json
├── .mcp.json
├── commands/
└── skills/

이 구조는 개발자에게 익숙한 형태다. plugin.json은 패키지의 정체성과 버전을 담고, commands/는 명시적으로 호출하는 슬래시 커맨드를 담고, skills/는 Claude가 관련 상황에서 자동으로 읽어야 할 절차 지식을 담는다. .mcp.json은 외부 도구와 데이터에 접근하는 커넥터 설정이다.

즉 플러그인은 “Claude에게 이런 식으로 답해줘”가 아니라 “우리 조직의 이 업무는 이런 도구와 이런 절차와 이런 커맨드로 수행돼야 한다”를 파일 시스템으로 배포하는 방식이다. 이게 Anthropic이 밀고 있는 실질적인 제품 포인트다.

Claude Code 플러그인은 팀 배포와 버전 관리를 위한 포장 단위다

Claude Code 문서의 플러그인 페이지는 standalone .claude/ 설정과 plugin 방식을 분리한다. 단일 프로젝트, 개인 실험, 짧은 커맨드에는 standalone 설정이 맞지만, 팀·커뮤니티 공유, 버전 릴리스, 여러 프로젝트 재사용, 마켓플레이스 배포에는 플러그인이 맞다는 설명이다.

이건 한국 개발팀에게 꽤 현실적인 신호다. 지금 많은 팀이 Cursor, Claude Code, Codex CLI, 내부 RAG, MCP 서버를 각자 붙여 쓰고 있다. 그런데 이 상태에서는 좋은 사용법이 개인의 dotfiles나 노션 문서에 흩어진다. 플러그인 방식은 그 흩어진 운영 지식을 Git 저장소와 릴리스 단위로 묶는다.

Claude Code의 공식 플러그인 디렉터리(anthropics/claude-plugins-official)도 같은 방향을 보여준다. README는 플러그인 구조에 .claude-plugin/plugin.json, .mcp.json, commands/, agents/, skills/, README.md를 명시하고, /plugins는 Anthropic 내부 플러그인, /external_plugins는 파트너와 커뮤니티 플러그인을 담는다고 설명한다.

여기서 눈여겨볼 대목은 경고 문구다. 디렉터리는 플러그인을 설치하기 전에 신뢰 여부를 확인하라고 말한다. Anthropic은 플러그인 안에 어떤 MCP 서버, 파일, 소프트웨어가 포함될 수 있는지 직접 통제하지 않으며, 의도대로 동작하거나 바뀌지 않는다고 보장할 수 없다는 식의 경고를 붙인다.

이 경고는 단순 면책이 아니다. 에이전트 플러그인의 본질을 보여준다. 플러그인은 모델 프롬프트보다 훨씬 강력하다. 커넥터, 파일 접근, 명령, 서브에이전트를 묶을 수 있기 때문이다. 그래서 플러그인 생태계는 생산성 도구이면서 동시에 공급망 보안 문제가 된다.

Skills는 컨텍스트를 아끼는 조직 지식 포맷이다

Anthropic의 Skills 설명에서 가장 중요한 개념은 progressive disclosure다. Skills는 폴더 형태의 지침, 스크립트, 리소스이고, Claude는 모든 내용을 한 번에 컨텍스트에 넣지 않는다. 먼저 각 Skill의 name과 description 정도를 보고, 관련성이 있다고 판단할 때만 전체 SKILL.md를 읽는다.

이 설계는 작아 보이지만 실무적으로 크다. LLM 기반 업무 자동화에서 조직 지식을 전부 시스템 프롬프트에 때려 넣는 방식은 오래 못 간다. 컨텍스트가 낭비되고, 충돌이 생기고, 업데이트가 어렵다. 반대로 Skill은 “필요할 때 읽는 업무 매뉴얼”에 가깝다.

Anthropic의 engineering 글은 Skill을 신규 입사자 온보딩 가이드에 비유한다. 이 비유가 정확하다. 좋은 Skill은 모델에게 모든 배경지식을 암기시키는 게 아니라, 특정 업무를 할 때 참고해야 할 절차와 파일, 스크립트, 리소스를 묶는다. 그래서 팀 입장에서는 “우리 회사의 견적서 작성법”, “우리 브랜드 톤으로 세일즈 메일 쓰는 법”, “우리 데이터웨어하우스에서 지표 검증하는 법” 같은 절차를 파일로 버전 관리할 수 있다.

이 관점에서 보면 Knowledge Work Plugins의 진짜 가치는 샘플 플러그인 자체보다 기업이 자기 업무를 어떻게 에이전트용 운영 자산으로 바꿔야 하는지 보여주는 레퍼런스에 있다.

Cowork는 채팅 UI가 아니라 위임형 작업 큐다

Claude Cowork 페이지는 몇 가지 사용 예시를 반복해서 보여준다. 매주 금요일 분석 대시보드에서 지표를 가져와 주간 리포트 템플릿에 넣기, 다운로드 폴더를 스캔해 정리 계획을 제안하기, 영수증·인보이스·스크린샷을 스프레드시트로 만들기, 회의 노트와 문서를 바탕으로 제품 업데이트 보고서를 초안 작성하기 같은 사례다.

채팅에서 위임형 작업으로

이 사례들은 화려한 데모라기보다 운영 모델을 말한다. Cowork는 사용자가 다음 토큰을 계속 유도하는 채팅창이 아니라, 작업을 맡기고 결과로 돌아오는 큐에 가깝다. 제품 페이지도 “Describe the outcome and cadence”, “Claude works through each step”, “You choose which folders and connectors Claude can access”, “Before Claude acts, it shows you the plan and waits for your approval” 같은 문장으로 제어 모델을 설명한다.

여기서 플러그인이 붙으면 그림이 완성된다.

  • Cowork는 작업 실행면이다.
  • Skills는 절차 지식이다.
  • Commands는 명시적 액션이다.
  • Sub-agents는 역할별 실행자다.
  • Connectors/MCP는 외부 시스템 접근이다.
  • 플러그인은 이들을 팀·직무 단위로 묶는 배포 포맷이다.

결국 Anthropic이 그리고 있는 미래는 “모든 사람이 더 긴 프롬프트를 잘 쓰는 세상”이 아니다. 오히려 좋은 플러그인과 좋은 Skill을 가진 조직이 반복 업무를 더 안정적으로 위임하는 세상에 가깝다.

개발자와 빌더에게 주는 실무 해석

이 변화는 AI 제품을 만드는 팀에게 꽤 직접적인 힌트를 준다. 앞으로 에이전트 제품의 차별화는 모델 선택만으로는 부족하다. 다음 네 가지가 제품의 품질을 가른다.

1) 업무 단위를 플러그인으로 자를 수 있는가

좋은 에이전트 제품은 “무엇이든 해준다”보다 “이 업무는 이렇게 한다”를 잘 포장해야 한다. sales, legal, finance, data처럼 직무 경계가 있는 플러그인은 사용자의 기대치를 좁히고 평가 기준을 명확하게 만든다.

2) 도구 접근과 절차 지식을 분리할 수 있는가

MCP 커넥터는 도구 접근을 제공하고, Skill은 절차 지식을 제공한다. 둘을 섞으면 유지보수가 어려워진다. 좋은 설계는 “어떤 API에 접근할 수 있는가”와 “그 API를 어떤 업무 규칙으로 사용할 것인가”를 분리한다.

3) 승인과 감사 흐름을 제품 기본값으로 둘 수 있는가

Cowork 페이지는 사용자가 접근 가능한 폴더와 커넥터를 선택하고, 중요한 행동 전에 계획을 보여주고 승인받는 흐름을 강조한다. 팀 환경에서는 이게 선택 기능이 아니라 기본 기능이어야 한다. 특히 법무, 재무, 고객지원처럼 외부 영향이 큰 업무에서는 더 그렇다.

4) 플러그인을 공급망으로 볼 준비가 되어 있는가

플러그인은 커맨드, MCP 서버, 파일, 서브에이전트를 포함할 수 있다. 따라서 플러그인 마켓플레이스는 생산성 생태계이면서 보안 생태계다. 설치 전 검토, 버전 고정, 내부 허용 목록, 권한 제한, 로그 추적이 필요하다.

플러그인 거버넌스

SEO 관점에서 보면 “Claude 플러그인”은 아직 덜 붐빈 키워드다

한국어 검색 관점에서도 이 주제는 흥미롭다. “Claude Code”, “MCP”, “AI 에이전트”는 이미 넓은 키워드가 됐지만, “Claude 플러그인”, “Claude Cowork”, “Agent Skills”, “MCP 커넥터”, “에이전트 플러그인 보안”은 아직 실무 해석이 부족한 영역이다.

특히 한국 개발자와 테크 운영자에게 필요한 글은 “설치법”만이 아니다. 더 중요한 질문은 이렇다.

  • 우리 팀의 반복 업무를 Skill로 만들 수 있는가?
  • MCP 서버를 붙이면 어떤 권한 경계가 필요한가?
  • 플러그인을 내부 마켓플레이스로 배포할 때 누가 리뷰할 것인가?
  • Claude Code용 플러그인과 Cowork용 플러그인은 어디까지 겹치는가?
  • 에이전트가 결과물을 만들 때 승인·검수·감사 로그는 어떻게 남길 것인가?

이 질문에 답하는 팀이 단순 도입팀보다 훨씬 빨리 생산성을 얻을 가능성이 높다.

한 줄 결론

Claude Cowork와 플러그인 생태계의 핵심은 “더 좋은 챗봇”이 아니다. Anthropic은 스킬, 커맨드, 서브에이전트, MCP 커넥터를 파일 기반 패키지로 묶어 에이전트를 팀 단위 운영 레이어로 배포하는 방식을 밀고 있다. 개발자와 빌더가 봐야 할 포인트도 모델 성능보다 이 패키징과 거버넌스다.

참고한 주요 출처

Discuss on Twitter • View on GitHub