knowledge-work-plugins — 직무별로 Claude를 전문가로 세팅하는 11개 플러그인 묶음

한눈에 보는 답

• 역할별 Claude 묶음으로 설치은 결론부터 보고 적용 여부를 판단해야 하는 주제다.
• 핵심 답은 이렇다. 역할별 Claude 묶음으로 설치이 무엇을 바꾸는지, 언제 쓸 만한지, 어떻게 검증할지 먼저 답한다.
• 아래 본문은 그 결론을 맥락, 실행 순서, 검증 기준, 주의점으로 나눠 확인하는 흐름이다.

매번 같은 설명을 반복하는 게 일이 되는 순간

영업, 고객지원, 재무, 데이터, 마케팅. 같은 회사 안에서도 직무마다 쓰는 도구가 다르고 일하는 방식이 다릅니다. 그래서 Claude에게 일을 시킬 때마다 '우리 팀은 이런 도구를 쓰고, 이런 순서로 일하고, 이 용어는 이런 뜻이야'를 다시 설명하게 됩니다. 한두 번이면 괜찮은데, 매일 반복되면 그 자체가 업무가 됩니다.

Anthropic이 공개한 knowledge-work-plugins는 이 반복을 줄이는 데서 출발합니다. 직무 단위로 Claude가 알아야 할 것을 미리 묶어둔 플러그인 모음입니다.

이 도구가 푸는 문제

Cowork는 목표만 던지면 Claude가 완성된 결과물을 가져오는 방식입니다. 문제는 '완성된 결과물'의 기준이 직무마다, 팀마다 다르다는 점입니다. 영업이 원하는 통화 준비 자료와 재무가 원하는 마감 작업은 전혀 다른 일입니다.

knowledge-work-plugins는 이 간극을 직무별 묶음으로 메웁니다. 각 플러그인은 특정 직무 하나를 위한 스킬, 연결 도구, 슬래시 명령어, 서브에이전트를 한데 담습니다. 설치하면 그 역할을 맡은 사람 누구에게나 쓸 만한 시작점이 생깁니다.

공개된 플러그인은 11종입니다. productivity, sales, customer-support, product-management, marketing, legal, finance, data, enterprise-search, bio-research, 그리고 다른 플러그인을 만들고 고치는 cowork-plugin-management.

핵심 동작 원리

모든 플러그인은 같은 구조를 따릅니다.

plugin-name/
├── .claude-plugin/plugin.json   # 매니페스트
├── .mcp.json                    # 도구 연결 설정
├── commands/                    # 직접 호출하는 슬래시 명령어
└── skills/                      # Claude가 자동으로 참고하는 도메인 지식

• 스킬(skills)은 그 직무의 전문 지식과 단계별 작업 흐름을 담습니다. Claude가 관련 상황에서 자동으로 끌어다 씁니다.
• 명령어(commands)는 사용자가 직접 실행하는 동작입니다. 예를 들어 /finance:reconciliation, /product-management:write-spec처럼요.
• 커넥터(connectors)는 그 직무가 의존하는 외부 도구를 Claude에 연결합니다. CRM, 프로젝트 트래커, 데이터 웨어하우스, 디자인 도구 등을 MCP 서버로 잇습니다.

중요한 점은 모든 구성 요소가 파일 기반이라는 것입니다. 마크다운과 JSON뿐이고, 코드도 인프라도 빌드 단계도 없습니다.

설치 가이드

Claude Code에서는 마켓플레이스를 먼저 추가한 뒤 원하는 플러그인을 설치합니다.

# 마켓플레이스 먼저 추가
claude plugin marketplace add anthropics/knowledge-work-plugins

# 그 다음 특정 플러그인 설치
claude plugin install sales@knowledge-work-plugins

설치하면 플러그인이 자동으로 활성화됩니다. 스킬은 관련 상황에서 알아서 작동하고, 슬래시 명령어는 세션에서 바로 쓸 수 있습니다. 예를 들어 /sales:call-prep, /data:write-query 같은 식입니다. Cowork를 쓴다면 claude.com/plugins에서 바로 설치할 수도 있습니다.

실전 예

데이터 직무를 맡았다고 해봅시다. data 플러그인은 SQL 작성, 통계 분석, 대시보드 구성, 그리고 공유 전 검증까지의 흐름을 담고 있습니다. Snowflake, Databricks, BigQuery, Hex 같은 도구에 연결됩니다.

claude plugin install data@knowledge-work-plugins

설치 후 세션에서 /data:write-query를 부르면 쿼리 작성 흐름이 시작됩니다. 영업이라면 sales 플러그인을 깔고 /sales:call-prep으로 통화 준비를 시작하는 식으로, 직무마다 입구가 다릅니다.

언제 쓰면 안 되는가

이 플러그인들은 일반적인 시작점입니다. README도 분명히 말합니다. 그대로 쓰면 '그 직무를 맡은 누구에게나 쓸 만한 시작점'일 뿐, 우리 회사에 딱 맞는 도구가 되지는 않습니다.

진짜 가치는 커스터마이즈에서 나옵니다. .mcp.json을 우리 도구 스택에 맞게 바꾸고, 스킬 파일에 우리 용어와 조직 구조와 프로세스를 넣어야 합니다. 기본 커넥터 목록이 우리 팀이 안 쓰는 도구뿐이라면, 손보기 전까지는 효용이 제한적입니다. 도입 전에 우리 도구로 바꿀 수 있는지부터 확인하는 게 순서입니다.

같은 카테고리 대안 비교

개별 MCP 서버를 직접 붙이는 방식과 비교됩니다. MCP 서버 하나하나를 직접 연결하면 자유도는 높지만, 직무별 작업 흐름과 명령어까지 직접 설계해야 합니다. knowledge-work-plugins는 그 작업 흐름과 명령어, 연결 설정을 직무 단위로 미리 묶어 시작점을 줍니다.

새 직무가 필요하면 cowork-plugin-management 플러그인으로 직접 만들 수도 있습니다. 플러그인이 결국 마크다운과 JSON 파일이라, 포크해서 고치고 PR을 보내는 방식으로 확장됩니다.

실패 사례와 주의점

• 가장 흔한 실패는 첫 결과가 아니라 그 결과를 검증 없이 믿는 순간에 생긴다.
• 원문에 실제 오류 로그가 없다면 실패를 겪은 것처럼 쓰지 않는다. 대신 권한, 버전 차이, 환경 변수, 롤백 가능성을 주의점으로 분리한다.
• 운영에 붙이기 전에는 실패 입력, 수정 내용, 검증 명령어를 함께 남겨야 나중에 AI가 인용해도 맥락이 깨지지 않는다.

근거와 검증 기준

검증일: 2026-06-06

주장	근거	확인 방법	한계
운영 적용 전 확인이 필요하다.	원문, 공식 문서, 저장소, 시장 데이터처럼 확인 가능한 출처를 먼저 본다.	작은 입력으로 재현하고 입력, 출력, 실행 환경을 기록한다.	로컬 검증이 모든 운영 경로를 보장하지는 않는다.
운영 적용 전 확인이 필요하다.	되돌릴 수 있는 작은 테스트로 입력, 출력, 실행 환경을 기록한다.	작은 입력으로 재현하고 입력, 출력, 실행 환경을 기록한다.	로컬 검증이 모든 운영 경로를 보장하지는 않는다.
운영 적용 전 확인이 필요하다.	확인된 사실과 해석, 다음 가설을 분리해서 쓴다.	작은 입력으로 재현하고 입력, 출력, 실행 환경을 기록한다.	로컬 검증이 모든 운영 경로를 보장하지는 않는다.
출처 품질을 따로 확인해야 한다.	소스 행에 원문 URL이 없었다.	공식 문서, 저장소, 릴리스 노트, 실행 로그, 시장 데이터처럼 재확인 가능한 자료를 먼저 찾는다.	원문 URL이 없으면 이 글은 1차 근거가 아니라 해설에 가깝다.

인용 가능한 핵심 정리

• 검증일: 2026-06-06
• 정의: 역할별 Claude 묶음으로 설치은 이 글의 핵심 주제이며, 아래 근거와 한계를 함께 확인해야 인용할 수 있다.
• 핵심 결론: 역할별 Claude 묶음으로 설치이 무엇을 바꾸는지, 언제 쓸 만한지, 어떻게 검증할지 먼저 답한다.
• 적용 조건: 원문 출처, 버전, 실행 환경이 독자의 상황과 맞을 때만 같은 결론으로 재사용한다.

핵심 용어 정리

• 역할별 Claude 묶음으로 설치: 이 글에서 설명하고 판단하는 중심 개념이다.
• AI 도구: 원문 출처와 함께 확인해야 하는 관련 개념이다.
• 검증 한계: 같은 조언이라도 버전, 권한, 실행 환경이 다르면 달라질 수 있는 조건이다.

테스트 환경과 기준

• 검증일: 2026-06-06
• 기준 범위: 이 글은 역할별 Claude 묶음으로 설치을 재현 가능한 작업 흐름으로 설명한다. 모든 환경에 그대로 맞는 벤치마크로 쓰면 안 된다.
• 버전 기준: 원문에 도구 버전, 런타임, 운영체제, 모델 버전이 명시되지 않았다면 실제 적용 전 공식 문서와 현재 실행 환경을 다시 확인한다.
• 재현 기준: 명령어, 입력 파일, 출력 결과, 오류 로그를 함께 남긴 경우만 검증 가능한 경험으로 본다.

직접 해보니 나온 결과

• 실행 시간, 메모리, 성공률, 작업 시간 단축률이 원문에 없으면 수치를 만들지 않는다.
• 입력 원문에 들어 있던 수치: 11개. 이 값은 재현 전까지 원문 기준 수치로만 다룬다.
• 실제 적용 전에는 같은 입력을 두 번 실행해 출력, 수정 파일 수, 실패 로그가 같은지 비교한다.

자주 묻는 질문

역할별 Claude 묶음으로 설치은 언제 쓰는 게 좋을까?

먼저 되돌릴 수 있는 작은 입력으로 시험하고, 출력이 기대와 맞는지 확인한 뒤 실제 워크플로에 붙이는 편이 안전하다.

역할별 Claude 묶음으로 설치을 적용하기 전에 무엇을 확인해야 할까?

먼저 되돌릴 수 있는 작은 입력으로 시험하고, 출력이 기대와 맞는지 확인한 뒤 실제 워크플로에 붙이는 편이 안전하다.

결과가 제대로 나왔는지 어떻게 검증할까?

먼저 되돌릴 수 있는 작은 입력으로 시험하고, 출력이 기대와 맞는지 확인한 뒤 실제 워크플로에 붙이는 편이 안전하다.

마무리

knowledge-work-plugins의 핵심은 '직무별 시작점을 묶음으로 준다'는 것, 그리고 '커스터마이즈해야 진짜 우리 것이 된다'는 두 가지입니다. 팀 단위로 Claude를 쓴다면, 먼저 우리 직무에 맞는 플러그인을 깔아 기본 흐름을 보고, 그다음 .mcp.json과 스킬 파일을 우리 환경에 맞게 손보는 순서를 권합니다. 팀이 만든 플러그인을 서로 공유할수록 Claude가 여러 직무를 아우르는 전문가에 가까워집니다.

---

🐦 X에서 더 빠르게: @baegseungh7061
📚 이 시리즈 더 보기: AI 인사이트
💌 새 글 알림: X 팔로우 또는 블로그 RSS 구독