Slack MCP가 연결하는 것#
Slack은 공식 MCP 서버를 제공합니다. 검색은 대화 내용을 외부 클라이언트에 노출할 수 있고, 메시지 전송은 다른 사람에게 실제로 전달되는 별도의 작업입니다.
| 작업 | 공식 서버의 사용자 토큰 권한 예시 | 영향 |
|---|---|---|
| 공개 대화 검색 | search:read.public | 검색 결과를 읽습니다. 비공개 대화에는 별도 범위가 필요합니다. |
| 채널 기록 읽기 | 공개 채널은 channels:history | 채널 기록을 읽습니다. 대화 유형에 따라 필요한 권한이 다릅니다. |
| 메시지 전송 | chat:write | 메시지가 실제 대화에 게시됩니다. |
출처: Slack MCP 서버의 권한 목록, 2026-11-01 확인. 이는 공식 문서의 범위 예시이며 특정 앱에 부여된 권한의 증거는 아닙니다.
- 워크스페이스 관리자와 허용된 대화, 보존·감사 정책 및 필요한 권한을 정합니다.
- Slack 공식 서버의 앱 등록과 OAuth 요건을 확인합니다. Mirr Code와의 호환성은 별도 검증이 필요합니다.
- 읽기부터 제한적으로 확인하고, 실제 메시지 전송은 내용과 수신 대상을 사람이 검토한 뒤 승인합니다.
추가 검증 필요: 실제 Slack 앱에 부여된 scope와 인증·Mirr 연결, 설치·설정 기록, 쓰기 작업의 사람 승인, 실행 기록과 민감정보를 가린 스레드 요약 등 도구 출력, rate limit 오류는 아직 확보하거나 확인하지 못했습니다.
준비물과 권한#
공식 서버는 등록된 Slack 앱과 기밀 OAuth를 요구하며, Slack 문서는 디렉터리 게시 앱 또는 내부 앱만 MCP를 사용할 수 있다고 설명합니다. 필요한 사용자 권한과 관리자 승인 여부를 확인하세요. 실제 앱에 부여된 범위는 아직 확인하지 못했습니다.
설치와 연결#
Mirr Code 설치 문서와 외부 도구 연결 안내를 참고하세요. Slack 공식 서버는 Streamable HTTP와 등록된 앱을 요구하므로, 주소만 추가하면 연결된다고 가정하지 마세요. Mirr에서의 인증과 연결은 아직 확인되지 않았습니다.
공식 엔드포인트는 https://mcp.slack.com/mcp입니다. Slack은 SSE와 동적 클라이언트 등록을 지원하지 않으며, 클라이언트의 고정 앱 ID와 기밀 OAuth를 요구합니다. Mirr의 인증 지원을 확인하기 전에는 동작하는 설치 절차로 안내할 수 없습니다. 공식 서버·권한에 대한 문서 설명과 실제 앱의 승인·설치 기록을 구분하세요.
Slack MCP 설정에서 주소 등록·OAuth 지원·도구 확인은 별도 단계입니다. 공식 서버가 있으므로 커뮤니티 패키지를 임의로 설치할 필요는 없지만, Mirr에서 사용할 클라이언트 앱과 인증 경로가 준비됐다는 뜻은 아닙니다. 다음은 설치 성공 절차가 아닌 사전 확인 목록입니다.
- 워크스페이스 관리자와 사용할 공식 서버·앱을 확인하고, Slack이 허용하는 내부 앱 또는 마켓플레이스 앱 조건과 앱 승인 정책을 검토합니다. 필요한 대화 유형과 조회·전송 scope를 위 표에 맞춰 최소화합니다.
- 클라이언트 담당자에게 고정 앱 ID,
client_id·client_secret을 사용하는 기밀 OAuth와 Slack 사용자 토큰 흐름을 지원하는지 확인합니다. 비밀값을 대화·프로젝트 파일·진단 로그에 넣거나 일반 OAuth 안내만으로 지원된다고 판단하지 마세요. - Mirr의 HTTP 주소 등록·로그인 안내와 Slack의 Streamable HTTP·인증 요구를 대조합니다. Mirr 문서는 이 Slack 앱 등록·기밀 OAuth 조합을 확인해 주지 않습니다. 주소만 추가하는 명령을 완성된 Slack 설치법으로 제시하지 않는 이유입니다.
- 호환성이 확인된 승인 환경에서만 앱 권한 화면·인증·설정 기록을 보관하고, 읽기 도구의 실제 범위부터 확인하도록 계획합니다. 메시지 전송은 별도 쓰기 승인·대상·내용 검토 뒤의 단계로 둡니다.
근거: Slack 공식 서버의 앱·전송·인증 요구(2026-11-02 문서 확인). 실제 앱의 승인된 scope, Mirr 인증 호환성과 설치·도구 출력은 아직 확인하지 못했습니다. 따라서 이 사전 확인 목록은 설치 사례가 아닙니다.
실제 작업 예제#
예를 들어 허용된 채널에서 결정을 검색해 요약한 후, 공유할 메시지는 별도로 검토할 수 있습니다. 실행 기록과 테스트 출력은 아직 확보하지 못했습니다.
보안과 제한#
읽은 대화가 클라이언트와 모델에 전달될 수 있으므로 민감정보, 보존 기간과 감사 정책을 먼저 확인하세요. 메시지 전송이나 채널 생성은 조회와 달리 외부 상태를 바꿉니다. Slack 공식 서버 보안 안내도 확인하세요.
문제 해결과 자주 묻는 질문#
이 절의 점검표는 Slack 공식 MCP 안내와 HTTP API 제한 안내(2026-11-02 확인)를 근거로 한 것입니다. 실제 오류 재현 기록이 아닙니다.
| 증상 | 확인할 것 | 다음 행동 |
|---|---|---|
| 인증을 끝낼 수 없음 | 등록된 앱, 내부·마켓플레이스 앱 조건, 기밀 OAuth와 클라이언트 지원 | 관리자와 호환성을 확인하고 토큰을 로그에 붙이지 않기 |
| 검색·읽기가 거부됨 | 실제 사용자 토큰 scope와 대상 대화 유형, 계정 접근 권한 | 필요한 범위만 다시 검토하고 조직 승인 없이 확대하지 않기 |
| 검색 결과가 없음 | 워크스페이스·대화·기간·검색 조건 | 권한 부족이라고 단정하지 말고 승인된 화면의 원문과 대조 |
| 메시지 전송 실패 | 쓰기 scope, 수신 대상과 실제 게시 여부 | 사람이 승인한 대상·내용인지 확인하고 중복 전송 방지 |
| HTTP 429 또는 제한 오류 | 도구별 제한과 Retry-After 안내 | 안내된 시간을 기다리고 호출량 줄이기 |
| IP 허용 목록 관련 거부 | 앱에 설정한 허용 IP와 클라이언트의 실제 출발 IP | 관리자가 정책을 검토하며 제한을 임의로 해제하지 않기 |
MCP 활동 감사 가능 범위와 보존 기간은 워크스페이스의 정책·계약과 실제 로그에서 따로 확인하세요. Slack의 보존 설정이 외부 클라이언트와 모델의 보존 조건까지 보장하는 것은 아닙니다. 실제 앱 권한과 Mirr 연결 검증 결과가 아직 없으며, 이 글은 연결 성공 절차가 아닌 문서 기반 현황과 점검 기준을 제공합니다.
공식 서버와 Slack 안의 MCP 클라이언트를 구분하기#
Slack 문서에는 Slack 데이터를 외부 AI 도구에 제공하는 MCP 서버와 Slack 쪽에서 외부 MCP를 연결하는 클라이언트에 관한 안내가 함께 있습니다. 이 글의 대상은 전자입니다. 다른 방향의 OAuth 설정과 scope를 섞어 적용하면 잘못된 안내가 됩니다. 서버 주소, 등록 앱과 사용자 토큰 요구를 공식 Slack MCP 서버 문서에서 확인하세요. 공식 서버가 있다는 사실은 Mirr가 그 인증 조합을 지원한다는 증거가 아닙니다.
현재 공식 안내는 고정 앱 ID를 가진 등록 앱과 기밀 OAuth를 요구하고 Streamable HTTP를 사용한다고 설명합니다. SSE와 동적 클라이언트 등록은 지원하지 않는다는 제한도 있습니다. PKCE 관련 추가 안내가 보이더라도 이것만으로 특정 데스크톱 클라이언트의 전체 인증 흐름이 검증되는 것은 아닙니다. Mirr의 실제 앱 등록·비밀 저장·사용자 토큰 경로는 담당자가 별도로 확인해야 합니다. 이 글에는 작동한다고 보장하는 설치 명령을 추가하지 않습니다.
대화 유형별 권한을 업무 목적에 맞추기#
공개 채널 검색, 비공개 대화 검색과 DM 검색은 같은 범위가 아닙니다. 필요한 대화 유형과 기간을 먼저 정하고 해당 작업의 공식 scope를 대조하세요. 공개 대화만 필요하다면 비공개·DM 권한을 편의상 추가하지 않습니다. scope가 있어도 실제 사용자가 접근할 수 있는 대화 범위와 조직 정책을 함께 확인해야 합니다. 특정 앱의 실제 부여 권한은 승인 화면과 연결 결과에서 확인해야 하며 이 절의 표는 그 증거가 아닙니다.
| 업무 목적 | 공식 권한 설명에서 볼 항목 | 검토할 추가 경계 |
|---|---|---|
| 공개 채널 결정 찾기 | search:read.public | 대상 채널·기간·반환 정보 |
| 비공개 대화 검색 | 대화 유형에 맞는 검색 scope | 참여자 기대·조직 승인·민감정보 |
| 스레드 내용 읽기 | 채널 유형에 맞는 history scope | 링크된 파일과 다른 대화의 추가 접근 |
| 요약 메시지 게시 | chat:write | 수신 채널·멘션·정확한 본문 승인 |
| 파일 읽기·공유 | 해당 파일 도구의 별도 scope | 원문 데이터·공유 대상·외부 사본 |
| 연결 종료 | 앱·토큰의 실제 철회 경로 | 클라이언트 문맥과 로그의 보존 |
권한을 고를 때는 “검색만 한다”는 목적을 도구와 토큰 설정에 반영할 수 있는지 검토합니다. 모델에 읽기만 요청하는 문구는 권한 제한이 아닙니다. 여러 서비스를 함께 연결하면 Slack 대화가 다른 서비스의 PR·이슈·문서로 옮겨갈 수 있습니다. 각각의 전송 대상을 별도로 승인해야 합니다. 한 서비스에서 읽을 권한이 있다고 다른 서비스에 공개할 권한까지 생기지는 않습니다.
스레드 요약을 만들 때 맥락 보존하기#
검색 결과 한 줄을 최종 결정으로 요약하지 마세요. 앞뒤 대화, 답글과 후속 정정에서 의미가 달라질 수 있습니다. 승인된 범위에서 원래 스레드를 확인하고 누가 어떤 결정을 했는지, 제안과 미결정이 무엇인지 구분합니다. 가상의 일정 논의라면 확정 날짜, 후보 날짜와 확인이 필요한 담당자를 나눠 적을 수 있습니다. 실제 대화를 조회하지 않았다면 이런 형식을 실제 팀의 결정 기록처럼 제시하면 안 됩니다.
요약에는 근거 링크와 조사 범위가 유용하지만 링크 자체가 비공개 채널과 사용자 정보를 드러낼 수 있습니다. 공개용 결과에서는 필요한 범위만 남기세요. 발언자의 추측을 사실로 바꾸거나 반대 의견과 조건을 빼지 않는 것도 중요합니다. 숫자와 날짜는 원문과 대조하고 상대 날짜는 기준 시점이 명확한 경우에만 풀어 씁니다. 근거를 못 찾았으면 “없다”보다 “조회한 범위에서 확인하지 못했다”가 정확할 수 있습니다.
자동 요약이 개인 평가나 민감한 의사결정에 쓰이면 추가 검토가 필요합니다. 비식별 처리했더라도 상황으로 사람을 알아볼 수 있습니다. 목적에 필요하지 않은 DM이나 파일을 가져오지 않는 편이 좋습니다. Slack의 원문 보존 정책은 외부 모델의 보존 정책과 다르므로 승인 전에 둘을 확인해야 합니다. 요약을 만든 뒤 원문을 삭제하거나 보존 설정을 바꾸는 행동은 별도 권한이며 이 글의 범위가 아닙니다.
메시지 초안과 전송을 나누기#
먼저 보낼 채널과 스레드, 본문과 멘션을 초안으로 제시합니다. 사람이 확인하기 전에는 전송하지 마세요. 같은 이름의 채널이 다른 워크스페이스에 있을 수 있으므로 정확한 대상 식별자를 대조해야 합니다. 공개 채널과 비공개 채널의 독자도 다릅니다. 멘션은 사람에게 알림을 보내므로 단순 문구 편집 이상의 영향이 있습니다. 링크 미리보기와 첨부 파일이 의도치 않은 정보를 보여 주는지도 검토하세요.
승인한 초안이 이후 수정됐다면 다시 검토가 필요할 수 있습니다. 가령 “검사 중”이라는 가상의 초안을 “출시 완료”로 바꾸면 단순한 문체 수정이 아닙니다. 상태와 독자가 취할 행동이 달라지기 때문입니다. 새 멘션이나 첨부 파일을 넣는 것도 전달 대상과 정보 범위를 바꿀 수 있습니다. 실제 전송 후에는 메시지 식별자와 원문을 대조하세요. 이 글에서는 실제 메시지를 전송하지 않았습니다.
호출 제한과 전송 시간 초과를 구분하기#
공식 서버는 도구·작업 종류에 따라 제한을 적용하며 Web API와 같은 제한 체계를 공유한다고 설명합니다. 모든 도구에 하나의 고정 호출량이 있다고 가정하지 마세요. HTTP 429와 Retry-After를 받았다면 안내된 대기와 호출량 조정을 검토합니다. 검색 범위를 좁히고 필요한 필드만 읽는 방식도 고려할 수 있습니다. 제한을 피하려고 여러 계정이나 앱으로 요청을 분산하는 대응은 이 글에서 권하지 않습니다.
전송 요청의 시간 초과는 제한 오류와 다를 수 있습니다. 이미 메시지가 저장됐는지 서비스에서 확인하고 재시도 여부를 결정하세요. 로그에는 토큰과 원문 대화를 모두 남기지 않아도 됩니다. 오류 종류, 도구 이름과 가린 대상 정보, 반영 상태를 조사할 수 있는 식별자를 보관합니다. 실제 제한 오류를 재현하지 않았다면 공식 문서의 예시를 자신의 실행 화면처럼 표시하지 마세요. 이 문서에는 실제 rate limit 오류를 관찰한 기록이 없습니다.
관리자 승인·감사·보존을 확인하는 질문#
관리자에게는 사용할 앱과 대화 유형, 필요한 읽기·전송 권한, 외부 처리 목적을 함께 설명하세요. 앱 승인 정책과 허용 IP가 있다면 실제 클라이언트의 요청 경로가 맞는지도 검토해야 합니다. 접속이 거부된다고 IP 제한을 임의로 해제하지 않습니다. 공식 문서가 감사 로그를 안내하더라도 실제 워크스페이스에서 어떤 항목과 기간을 볼 수 있는지는 계약과 설정에서 확인해야 합니다. 모든 행위가 항상 기록된다고 보장하지 마세요.
보존 질문은 Slack 원문, 클라이언트의 대화 기록, 모델 제공자와 공유 산출물로 나눕니다. 원문 삭제가 다른 사본의 삭제를 뜻하지 않습니다. 작업이 끝나면 필요 없는 앱 승인과 토큰을 서비스에서 철회하고, 외부로 전달된 자료의 처리 조건도 확인합니다. 이미 게시한 메시지의 수정·삭제는 별도 작업입니다. /rewind나 브라우저 종료로 Slack의 상태가 자동으로 복구되지는 않습니다.
공개 조건을 확인하는 데 필요한 자료#
먼저 Mirr 담당자가 고정 앱 ID와 기밀 OAuth, 필요한 전송과 비밀 저장 경로를 실제 버전에서 검증해야 합니다. 그다음 관리자가 승인한 앱 scope와 비식별 테스트 대화 범위를 확인합니다. 설치·인증 기록, 실제 도구 목록과 가린 스레드 요약, 사람이 승인한 전송 단계와 실제 결과를 같은 과제로 묶어야 합니다. 읽기만 검증했다면 전송은 계속 미실행입니다. 개인 업무 대화를 무단으로 사용해 증거를 채우지 않습니다.
현재는 이 입력이 없으므로 이 글을 Mirr의 Slack 설치 성공 사례로 사용할 수 없습니다. 공식 서버의 현황과 점검 기준을 제공하는 범위입니다. 실제 설정을 검토할 때도 scope 화면은 승인된 권한을, 가린 스레드 출력은 수행한 조회를 설명합니다. 둘이 같은 앱·계정 범위에 대한 자료인지 확인해야 합니다. 다른 클라이언트의 화면이나 일반 웹페이지 캡처를 Mirr 인증·세션의 증거로 바꾸어 해석하지 마세요.
검색 결과가 없을 때 권한부터 넓히지 않기#
검색 결과가 없으면 먼저 워크스페이스와 대화, 기간과 검색 조건을 확인하세요. 대상 대화가 실제로 존재하는지와 연결한 사용자가 원문에 접근할 수 있는지도 봅니다. 검색 범위가 좁아서 못 찾은 것과 접근이 거부된 것은 다릅니다. 오류 없이 빈 결과를 받았다는 사실만으로 권한 차단을 검증했다고 보고하지 않습니다. 필요한 경우 관리자가 승인한 비식별 테스트 대화에서 기대 결과를 정해 확인해야 합니다. 실제 업무의 비공개 대화를 권한 시험용으로 무단 조회하지 마세요.
찾은 결과가 있다면 원문과 후속 정정을 확인한 뒤 요약합니다. 비슷한 이름의 프로젝트나 사용자가 언급됐다고 같은 의사결정으로 묶으면 안 됩니다. 결론의 범위와 적용 시점이 다른 대화를 합치지 않도록 주의하세요. 스레드에 파일이나 다른 채널 링크가 있어도 추가 조회가 승인 범위를 넘는지 확인합니다. 필요한 근거를 못 읽었다면 그 한계를 표시하고 추측을 결정으로 바꾸지 않습니다. 메시지 수와 요약 길이가 정확성을 대신하지 않습니다.
읽기 검증과 메시지 전송 검증의 다른 증거#
가상의 조회 과제에서 공개 채널의 결정만 읽었다면 그 결과가 맞아도 DM 접근이나 메시지 전송을 확인한 것은 아닙니다. 읽기 기록에는 승인된 범위와 검색 조건, 가린 결과를 남깁니다. 별도 전송을 승인받았다면 수신 대상과 승인한 본문, 실제 게시 식별자와 중복 여부를 연결해야 합니다. 전송하지 않았다면 미실행으로 두세요. 실제 앱 권한과 Mirr 인증 호환성의 확인도 이 문서에서는 아직 남아 있습니다.
자료를 공유할 때는 대화 원문과 사용자 이름, 계정 지표를 그대로 공개하지 않습니다. 비밀값이 없는지 직접 확인하고 공개할 수 있는 사실만 추립니다. 보안 제한을 이유로 필요한 증거가 공개되지 못한다면 확인 가능한 범위를 좁혀 설명하세요. 없던 성공 로그를 만드는 대신 어떤 담당자 입력과 승인 환경이 필요한지 남기는 것이 정확한 인계입니다.
검색 결과의 시각과 요약 기준 시점도 구분하세요. 과거 대화의 제안을 현재 유효한 결정으로 옮기기 전에 후속 정정 여부를 확인해야 합니다.
요청 제한을 도구 단위로 계산하기#
Slack 문서는 Slack MCP 서버도 모든 Slack Web API 메서드와 같이 요청 제한(rate limit)의 적용을 받는다고 설명합니다. 제한은 도구 또는 작업 유형별로 정해지며, MCP 도구로 호출하든 Slack Web API를 직접 호출하든 같은 제한이 적용된다고 합니다(Slack MCP 서버 안내).
제한에 걸린 응답은 실패로 기록하고, 이전 결과를 새 결과로 게시하지 마세요. 이 글은 실제 호출량을 측정하지 않았습니다.
MCP 도구 호출과 Slack Web API 직접 호출은 같은 제한을 공유하므로, 두 경로의 호출 횟수를 합산해 계산하세요.
다음에 연결할 것#
다른 업무 도구를 연결할 때도 서비스별 권한과 읽기·쓰기 범위를 따로 검토하세요.
편집 메모 (2026-11-02): 공식 엔드포인트·인증 제약과 오류별 점검표를 추가했습니다. 실제 설치·scope 승인, Mirr 연결, 사람의 쓰기 승인, 가린 스레드 요약과 rate limit 오류 증거는 아직 없습니다.