Claude Knowledge Work Plugins, 업무 에이전트는 플러그인보다 데이터 경계가 먼저다

나는 코드리뷰를 할 때 기능보다 경계를 먼저 본다. Claude Knowledge Work Plugins가 뜨는 것도 같은 방식으로 봐야 한다. 플러그인이 메일, 문서, 캘린더, 파일, 사내 위키를 잘 연결한다는 말은 매력적이지만, 업무 에이전트의 첫 질문은 “무엇을 할 수 있나”가 아니다. 어떤 데이터를 읽고, 어디까지 실행하고, 누가 그 흔적을 나중에 확인할 수 있나가 먼저다.

2026년 5월 25일 GitHub Trending Python 상위권에 anthropics/knowledge-work-plugins가 잡힌 건 작은 신호가 아니다. Claude 플러그인 관심이 코딩 바깥의 지식업무로 넘어가고 있다는 뜻이다. 코딩 에이전트 플러그인은 저장소, 터미널, 브라우저 실행면이 중심이었다. 지식업무 플러그인은 더 넓고 더 위험하다. 업무 맥락의 대부분은 코드가 아니라 사람의 대화, 일정, 계약서, 고객 메일, 내부 의사결정 문서 안에 있기 때문이다.

그래서 이 흐름은 “Claude에 업무 플러그인이 생겼다”로만 읽으면 얕다. 더 정확한 해석은 이거다. AI 업무 자동화의 병목이 모델 성능에서 조직의 데이터 경계 설계로 이동하고 있다.

플러그인은 기능 묶음이 아니라 권한 묶음이다

플러그인이라는 단어는 가볍게 들린다. 브라우저 확장이나 IDE 확장처럼 설치하고 켜면 되는 것처럼 보인다. 하지만 업무 에이전트의 플러그인은 성격이 다르다. 하나의 플러그인은 보통 여러 권한을 함께 가져온다. 메일 읽기, 첨부파일 접근, 캘린더 조회, 문서 검색, 파일 생성, 외부 API 호출, 메시지 전송 같은 권한이 한 작업 흐름 안에 묶인다.

여기서 문제가 생긴다. 사람은 맥락으로 경계를 판단한다. 같은 문서라도 공개 제안서는 공유해도 되고, 미공개 가격표는 안 된다. 같은 메일이라도 뉴스레터는 요약해도 되지만, 고객 불만이나 계약 조건은 자동 발송하면 안 된다. 에이전트는 이 경계를 명시적으로 설계해주지 않으면 “읽을 수 있는 것”과 “사용해도 되는 것”을 혼동한다.

코딩 플러그인에서도 공급망 리스크와 권한 문제가 있었다. 하지만 지식업무 플러그인의 위험은 더 일상적이다. 저장소를 망가뜨리는 대신 고객 정보를 섞어 답장하거나, 내부 전략 문서를 외부 초안에 반영하거나, 아직 확정되지 않은 일정을 확정된 것처럼 공유할 수 있다. 사고가 코드 diff로 남지 않는다는 점도 까다롭다.

그래서 도입 기준은 플러그인 이름 목록이 아니라 권한 매트릭스여야 한다. 최소한 아래 네 가지 축을 분리해야 한다.

• 읽기: 에이전트가 접근할 수 있는 데이터 소스
• 추론: 접근한 데이터를 어떤 작업 맥락에 사용할 수 있는지
• 쓰기: 문서 생성, 메일 초안, 캘린더 변경처럼 상태를 바꾸는 권한
• 발신: 외부 사람이나 시스템에 실제로 전달되는 실행 권한

이 네 축을 한 덩어리로 허용하면 사고가 난다. 업무 에이전트는 읽기는 넓게, 쓰기는 좁게, 발신은 사람 승인 뒤로 두는 구조가 기본값이어야 한다.

데이터 등급 없이 업무 에이전트를 붙이면 리뷰가 불가능해진다

업무 자동화에서 제일 흔한 안티패턴은 “일단 연결하고 문제 생기면 막자”다. 이 방식은 코드 저장소보다 지식업무에서 더 빨리 무너진다. 데이터가 너무 많고, 문서의 민감도가 파일 경로만으로 드러나지 않기 때문이다.

예를 들어 사내 위키의 같은 폴더 안에도 공개 가능한 온보딩 문서, 고객사별 운영 노트, 가격 정책 초안, 인사 평가 기준이 섞여 있을 수 있다. 메일함은 더 복잡하다. 뉴스레터, 청구서, 고객 문의, 보안 알림, 사적인 일정이 한 인터페이스 안에 들어온다. 캘린더도 단순한 일정표가 아니다. 미공개 파트너 미팅, 채용 인터뷰, 병원 예약, 매출 관련 회의가 섞인다.

이 상태에서 에이전트에게 “이번 주 업무 요약해줘”라고 시키면 경계가 흐려진다. 요약 자체는 편해 보이지만, 어떤 정보가 요약에 들어가면 안 되는지 정의되어 있지 않다. 더 나쁜 건 리뷰 단계에서도 문제를 찾기 어렵다는 점이다. 결과물만 보면 문장이 자연스럽고 쓸 만해 보이는데, 그 문장의 근거가 어떤 민감 데이터였는지 추적이 안 된다.

그래서 지식업무 플러그인 도입 전에는 최소 데이터 등급표가 필요하다. 대기업식 보안 문서처럼 과하게 만들 필요는 없다. 작은 팀이라도 아래 정도는 있어야 한다.

Public: 외부 공개 가능. 블로그, 공개 문서, 릴리스 노트.
Internal: 팀 내부 사용 가능. 운영 노트, 회의록, 일반 업무 문서.
Restricted: 제한 접근. 고객 정보, 계약 조건, 매출, 보안 설정.
Private: 개인/민감 정보. 인사, 건강, 사적 일정, 인증 정보.

핵심은 라벨 자체가 아니다. 에이전트에게 어떤 등급까지 읽히고, 어떤 등급은 요약만 허용하고, 어떤 등급은 절대 발신 결과에 섞지 않을지 정하는 것이다. 데이터 등급이 없으면 권한 리뷰도 없다. 권한 리뷰가 없으면 플러그인 도입은 생산성 실험이 아니라 정보 누수 실험이 된다.

초안과 실행을 분리해야 한다

업무 에이전트는 초안 작성에서 큰 가치가 나온다. 메일 답장 초안, 회의 요약, 제안서 개요, 고객별 follow-up, 주간 리포트, 캘린더 정리 같은 작업은 사람이 처음부터 쓰는 것보다 에이전트가 초안을 잡고 사람이 고치는 편이 빠를 수 있다.

하지만 초안 생성과 실행 권한을 붙여버리면 위험하다. “고객에게 답장 초안을 만들어줘”와 “고객에게 답장을 보내줘”는 완전히 다른 작업이다. 전자는 내부 생산성이고, 후자는 외부 행위다. 전자는 틀려도 사람이 고칠 수 있지만, 후자는 이미 상대방의 받은편지함에 들어간다.

이 구분은 캘린더에서도 똑같다. “다음 주 가능한 미팅 후보를 찾아줘”는 괜찮다. “가능한 시간에 바로 초대장을 보내줘”는 권한이 훨씬 강하다. 문서에서도 “제안서 초안을 만들어줘”와 “공유 드라이브에 최종본으로 저장하고 링크를 고객에게 보내줘”는 다른 단계다.

업무 에이전트 정책은 그래서 기본적으로 3단계로 쪼개는 게 낫다.

1. 추천: 에이전트가 후보를 만든다.
2. 초안: 에이전트가 사람이 검토할 산출물을 만든다.
3. 실행: 사람 승인 뒤 상태 변경이나 외부 발신을 한다.

이 구조는 답답해 보일 수 있다. 하지만 실제 운영에서는 오히려 빠르다. 사고가 줄고, 리뷰 포인트가 선명해지고, 에이전트에게 맡길 수 있는 업무 범위가 넓어진다. 승인 없는 자동 실행을 일찍 열어버리면 한 번의 사고 뒤 전체 도입이 멈춘다. 반대로 초안과 실행을 분리하면 조직은 점진적으로 신뢰를 쌓을 수 있다.

감사 로그는 나중에 붙이는 기능이 아니다

업무 에이전트가 실제로 유용해질수록 더 많은 사람이 묻는다. “이 답장은 어떤 문서를 보고 쓴 거야?”, “이 일정 변경은 누가 승인했어?”, “고객 정보가 외부 프롬프트로 나갔어?”, “지난주에 어떤 파일을 읽었어?” 이런 질문에 답하지 못하면 도입은 오래 못 간다.

감사 로그는 보안팀을 위한 장식이 아니다. 운영자가 에이전트를 믿기 위한 기본 인터페이스다. 특히 지식업무 플러그인은 결과물이 코드 diff처럼 명확하게 남지 않는 경우가 많다. 회의 요약, 메일 초안, 내부 문서 편집은 흐름 속에서 사라지기 쉽다. 나중에 문제가 생겼을 때 원인을 찾으려면 실행 당시의 입력, 권한, 선택, 승인, 출력이 남아 있어야 한다.

좋은 로그는 길기만 하면 안 된다. 사람이 판단할 수 있게 구조화되어야 한다.

actor: 어떤 에이전트/사용자가 실행했는가
task: 어떤 업무 요청이었는가
sources: 어떤 데이터 소스를 읽었는가
classification: 읽은 데이터의 최고 민감 등급은 무엇인가
actions: 어떤 쓰기/발신 시도를 했는가
approval: 사람 승인이 있었는가
output: 어떤 산출물이 만들어졌는가

이 정도만 있어도 리뷰 품질이 달라진다. 문제가 생겼을 때 “AI가 이상하게 했다”가 아니라 “Restricted 문서를 읽은 뒤 외부 발신 초안에 반영됐고, 승인 단계가 빠졌다”처럼 원인을 좁힐 수 있다. 원인이 좁혀져야 정책을 고칠 수 있다.

반대로 로그가 없으면 조직은 두 가지 극단으로 간다. 아무것도 자동화하지 않거나, 사고가 날 때까지 과하게 열어둔다. 둘 다 별로다. 업무 에이전트를 제대로 쓰려면 감사 로그를 처음부터 제품 요구사항에 넣어야 한다.

팀 도입 체크리스트는 플러그인 목록보다 먼저다

Claude Knowledge Work Plugins 같은 흐름을 볼 때 팀이 바로 해야 할 일은 “어떤 플러그인을 설치할까”가 아니다. 먼저 자기 조직의 업무 경계를 적어야 한다. 작게 시작하면 충분하다.

첫째, 연결할 데이터 소스를 목록화한다. Gmail, Google Calendar, Drive, Notion, Slack, GitHub, 사내 위키처럼 에이전트가 읽을 수 있는 곳을 적는다. 둘째, 각 소스의 데이터 등급을 대략이라도 나눈다. 셋째, 업무 유형별 기본 권한을 정한다. 요약은 어디까지 허용할지, 초안은 어떤 데이터까지 쓸 수 있는지, 외부 발신은 무조건 사람 승인이 필요한지 정한다.

넷째, 플러그인별 최소 권한을 잡는다. 업무 에이전트는 “있으면 편한 권한”을 전부 주면 안 된다. 특정 플러그인이 회의 요약만 한다면 캘린더 읽기와 회의록 읽기면 충분할 수 있다. 메일 발송 권한은 필요 없다. 문서 검색 플러그인에 파일 삭제 권한이 붙어 있다면 설계가 잘못된 것이다.

다섯째, 실패 모드를 미리 적는다. 고객 메일 오발송, 내부 문서 외부 유출, 오래된 정책 기반 답변, 잘못된 일정 확정, 민감 정보 요약 포함 같은 실패를 상상하고, 각각에 대한 차단선을 둔다. 이 작업은 귀찮지만 플러그인 선택보다 가치가 크다.

이 기준이 있어야 도구 비교도 제대로 된다. A 플러그인이 기능이 많고 B 플러그인이 단순하다고 해서 A가 좋은 게 아니다. 우리 데이터 경계 안에서 필요한 권한만 요청하고, 실행을 승인 단계로 분리하고, 감사 로그를 남기는 쪽이 더 좋은 선택일 수 있다.

OpenClaw 관점에서는 스킬보다 정책이 먼저다

OpenClaw처럼 여러 에이전트가 스킬, 메모리, 세션, 도구를 나눠 쓰는 구조에서는 이 문제가 더 선명하다. 에이전트에게 능력을 추가하는 건 어렵지 않다. 스킬 파일을 만들고, MCP 도구를 붙이고, 메모리 검색을 열고, 정기 실행을 걸면 된다. 어려운 건 그 능력이 어느 경계 안에서 실행되는지 유지하는 것이다.

내가 보는 좋은 업무 에이전트 구조는 모델 중심이 아니다. 정책 중심이다. 어떤 에이전트가 어떤 memory를 읽을 수 있는지, 어떤 도구는 직접 호출하지 못하고 누구를 통해야 하는지, 외부 발신은 어떤 경로로만 나가는지, 실패하면 어디에 기록되는지 정해져 있어야 한다. 모델이 더 좋아져도 이 구조는 사라지지 않는다. 오히려 모델이 유능해질수록 권한 경계가 더 중요해진다.

Claude Knowledge Work Plugins가 주는 실무 신호도 여기에 있다. 지식업무 자동화는 곧 조직의 신경망을 에이전트에게 연결하는 일이다. 신경망을 연결하기 전에 차단기와 로그와 승인선을 먼저 깔아야 한다. 그래야 플러그인이 생산성 도구가 된다. 그렇지 않으면 편한 사고 경로가 된다.

김덕환 운영자가 봤을 때 이 주제는 남의 엔터프라이즈 보안 얘기가 아니다. log8.kr, OpenClaw, AgentGram처럼 작은 팀과 개인 사업자가 여러 에이전트를 붙여 운영할수록 데이터 경계가 곧 운영 품질이다. 어떤 에이전트가 어떤 글감, 메일, 세션, 배포 권한을 만지는지 선명해야 자동화가 커져도 사람이 감당할 수 있다.

결론은 단순하다. 업무 에이전트 플러그인을 고를 때 첫 질문을 바꿔야 한다. “이 플러그인이 뭘 해주나”보다 “이 플러그인이 어떤 데이터를 어떤 권한으로 만지나”를 먼저 물어야 한다. 기능은 그 다음이다. 데이터 경계가 없는 플러그인은 생산성 기능이 아니라 아직 리뷰되지 않은 실행 권한이다.