Slack MCP 에이전트, 읽기만 할지 보낼지 어떻게 나누나

Slack MCP 에이전트를 채널 요약·멘션 대응에 쓰기 전에, 읽기(검색·히스토리)와 쓰기(메시지 전송)를 같은 권한으로 묶지 않는 것이 안전합니다. Slack의 공식 MCP는 검색·채널/스레드 읽기·메시지 전송·초안(draft)·리액션 등을 한 서버에서 제공합니다. 그래서 “연결만 하면 바로 보내도 된다”가 기본값이 되기 쉽습니다.

이 글은 읽기 전용으로 시작하는 방법 · 송신 확인 UX · 채널 invite가 왜 필요한지만 다룹니다. 요금·플랜·실제 토큰 값·클릭 경로를 발명한 Slack UI 스크린 투어는 없습니다. 근거는 Slack MCP server overview, conversations.history, groups:history입니다.

읽기 전용으로 시작하려면?

한 줄 답: 처음에는 히스토리·검색·멤버 조회에 해당하는 읽기 스코프·도구만 켜고, chat:write(및 동등한 송신·채널 생성 도구)는 나중 단계로 미룹니다. 에이전트 규칙에도 “요약·초안까지, 전송 도구는 사용자 확인 전 금지”를 적습니다.

공식 문서의 OAuth 스코프 표가 권한 경계를 명확히 나눕니다.

하려는 일대표 스코프(문서 기준)비고
채널/스레드 읽기channels:history, groups:history, mpim:history, im:history읽기
메시지·채널 검색search:read.public 등 search:read.*읽기
채널 목록·멤버channels:read, groups:read, …읽기
메시지 전송chat:write쓰기
채널/대화 생성channels:write / groups:write 등쓰기
리액션reactions:write쓰기

실무에서 “읽기만”을 만드는 패턴은 세 겹입니다.

  1. 스코프 최소 집합 — 워크스페이스/앱 설치 단계에서 송신·생성 스코프를 빼거나, 별도 읽기 전용 앱/연동을 먼저 승인합니다. 관리자 승인이 있는 공식 MCP라면, 클라이언트·앱을 읽기 용도로만 승인하는 쪽이 문서의 “admins approve and manage” 모델과 맞습니다.
  2. 도구 허용 목록 — MCP 클라이언트(에이전트) 쪽에서 send/create/reaction 도구를 비활성·거부합니다. 커뮤니티 서버 중에는 포스팅 도구를 기본 비활성하거나 READ_ONLY 플래그를 두는 구현이 있습니다. 공식 서버를 쓸 때도 클라이언트의 tool allow/deny로 같은 효과를 냅니다.
  3. 에이전트 규칙 문구 — “Slack에서 읽기·검색·요약·초안만 한다. chat:write에 해당하는 전송 도구는 사용자가 명시한 뒤에만.” 규칙에는 정책만 두고, 토큰 문자열은 넣지 않습니다.
# Slack MCP — phase 1 (read-only)
- Allowed: search, read channel/thread history, list channels/members, draft text in chat (do not post).
- Forbidden until explicit user OK: send message, create channel, add reaction, upload+share that posts.
- Never paste Slack tokens into rules, commits, or chat.

채널 요약·결정 찾기·멘션 맥락 모으기는 이 단계만으로도 충분히 가치가 있습니다. “보내기”는 팀이 초안 품질과 확인 UX를 본 다음에 켭니다.

송신 확인 UX는?

한 줄 답: 쓰기를 켠 뒤에도 에이전트가 바로 chat:write 도구를 호출하지 않게 합니다. 초안 → 사람이 확인 → 전송 순서를 규칙과 도구 게이트로 고정합니다.

공식 MCP는 Send messages와 별도로 Draft messages(클라이언트 안에서 초안·포맷·미리보기)를 제공합니다. 이 구분을 UX의 축으로 쓰면 됩니다.

단계에이전트가 하는 일사람이 하는 일
1. 수집검색·히스토리로 근거 모음범위(채널·기간)만 지정
2. 초안채팅/초안 도구로 문장 작성톤·수신처·멘션 검토
3. 확인“이 초안을 보낼까요?”만 물음명시적 승인(채널·본문 확정)
4. 전송그때만 send 도구 호출전송 결과·스레드 위치 확인

확인 UX를 지키는 최소 규칙 예시입니다.

  • 기본 거부: send 계열 도구는 allowlist에 없거나, 매 호출마다 사용자 승인 게이트를 탑니다.
  • 수신처 재진술: 전송 직전에 채널/스레드 식별자와 본문 요약을 다시 보여 준 뒤 승인받습니다. “알아서 보내” 한 줄만으로는 부족합니다.
  • 멘션·공지 채널은 더 엄격: #general·고객 접점·온콜 채널은 초안 단계에서도 별도 확인을 요구합니다.
  • 실패 시 재전송 금지: rate limit·권한 오류 후 자동 재시도로 중복 게시하지 않습니다. 공식 문서도 MCP 도구가 Web API와 같은 rate limit을 받는다고 명시합니다.

초안은 에이전트 채팅 안에만 두고, Slack에 올리기 전에는 도구 호출이 일어나지 않아야 합니다. “요약한 내용을 채널에 공유해 줘”처럼 모호한 지시가 오면, 먼저 초안을 보여 주고 승인을 받는 쪽으로 규칙을 고정합니다.

채널 invite는 왜 필요한가?

한 줄 답: 스코프만으로는 부족합니다. 히스토리·멤버십 기반 도구는 해당 대화의 멤버일 때 의미가 있습니다. 비공개 채널은 특히 초대(invite) 없이는 읽기·쓰기가 막히는 경우가 일반적입니다.

공식 MCP의 “List user channels”는 내가 멤버인 채널을 나열합니다. conversations.history 계열도 토큰 종류·스코프와 함께 멤버십에 의존합니다. 비공개 채널용 groups:history 설명은 “앱이 추가된 비공개 채널의 메시지”를 본다고 적습니다. 멤버가 아니면 not_in_channel 같은 거부로 끝납니다.

그래서 운영 체크리스트는 스코프와 invite를 나란히 둡니다.

  1. 읽을 채널 목록을 먼저 정한다 — 요약 대상 채널만. 전사 검색이 필요하면 search:read.*와 별도 정책.
  2. 앱/봇(또는 OAuth 사용자)을 그 채널에 초대한다 — 비공개는 멤버가 /invite 등으로 초대하는 흐름이 일반적입니다. 공개 채널도 멤버십이 없으면 읽기가 막히는 구성이 많습니다.
  3. 연결 후 “멤버인 채널 목록”으로 검증한다 — MCP의 list-channels 계열로 대상이 보이는지 확인합니다. 안 보이면 스코프보다 invite를 먼저 의심합니다.
  4. 송신은 멤버십 + chat:write + 확인 UX — 읽기도 못 하는 채널에 보내기를 켜 두지 않습니다.

에이전트에게 “모든 채널을 읽어라”고 시키기 전에, 초대된 채널 = 허용 경계로 생각하면 권한이 단순해집니다. 새 프로젝트 채널이 생길 때마다 invite를 워크플로에 넣는 편이, 나중에 “왜 요약이 비었지?”를 줄입니다.

마무리

Slack MCP는 읽기와 쓰기가 한 서버에 공존합니다. 처음에는 히스토리·검색·초안만 허용하고, chat:write는 확인 UX와 함께 켭니다. 스코프와 별개로 채널 invite(멤버십) 가 읽기·쓰기 가능 범위를 결정합니다. 토큰 값은 rules·채팅·커밋에 넣지 않습니다. 요금·플랜·클릭 경로 투어는 이 글 범위 밖입니다.

출처