Slackbot MCP 연결: 한국 팀이 앱 권한과 실행 책임을 설계하는 법

Slack은 2026년 6월 17일 Slackbot의 모델 컨텍스트 프로토콜(Model Context Protocol, MCP) 클라이언트를 일반 제공한다고 발표했다. Slackbot에서 20개가 넘는 파트너 앱을 연결해 정보를 찾고 앱의 작업을 실행하며, 결과를 채널에 공유할 수 있다는 내용이다.Slack 공식 발표 한국 조직이 주목할 변화는 “챗봇이 더 똑똑해졌다”가 아니다. 대화창이 외부 시스템의 실행 창이 되면서 앱 설치 승인, 사용자 계정 권한, 실행 후 검수 책임을 하나의 운영 정책으로 묶어야 한다는 점이다.

확인된 사실: Slackbot MCP 클라이언트는 2026년 6월 17일 일반 제공됐습니다. 연결 직후 Slackbot은 MCP 서버의 모든 내장 도구에 접근하지만, 구성원은 앱 설정에서 읽기·쓰기 도구를 Always allow, Needs approval, Blocked로 조정하고, Custom을 선택해 개별 도구별 설정을 맞춤화할 수 있습니다. Enterprise Grid·Enterprise+ 관리자는 MCP 서버 접근 대상을 사용자·그룹 단위로 관리할 수 있습니다.

>

POEMORA 해석: 관리자 통제와 사용자별 도구 설정을 함께 적용해 읽기 중심 업무부터 검증해야 합니다. 사용자 권한을 따른다는 설명도 잘못된 기존 권한을 자동으로 고쳐주지는 않습니다.

발표가 바꾼 것은 검색보다 실행의 경계다

기존 Slack 연동은 알림이나 링크 이동에 머무는 경우가 많았다. MCP 앱을 연결하면 Slackbot이 개발자가 구성한 도구를 통해 외부 서비스의 정보를 가져오고 작업을 수행할 수 있다. 공식 발표에는 Amplitude, Atlassian, Box, Canva, Docusign, Linear, Miro, Webflow, Zoom 등이 파트너 생태계로 제시됐다.Slack 공식 발표

조직 관점에서는 세 경계가 달라진다.

• 데이터 경계: Slack 대화뿐 아니라 연결된 앱의 데이터가 응답 맥락에 들어온다.
• 행동 경계: 답변 생성에서 레코드 작성·수정 같은 외부 작업으로 확장된다.
• 협업 경계: 개인 대화에서 만든 결과를 채널에 공유할 수 있어, 잘못된 결과도 더 빠르게 확산될 수 있다.

그러므로 “MCP 지원 앱인가”보다 “어떤 도구를 누구에게 열고, 실행을 어떻게 취소하며, 누가 결과를 승인하는가”를 먼저 묻는 것이 맞다.

앱 승인과 사용자 권한은 서로 다른 통제다

Slack 도움말에 따르면 앱 승인이 켜져 있으면 관리자 또는 권한 있는 구성원만 MCP 서버가 포함된 앱을 설치할 수 있습니다. 구성원은 각자 외부 계정을 연결하며, 기본적으로 Slackbot은 해당 MCP 서버의 모든 내장 도구에 접근합니다.Slack MCP 연결 도움말 다만 구성원은 Slackbot의 앱 설정에서 Read-only·Write 범주를 Always allow, Needs approval, Blocked로 조정하고, Custom에서 개별 도구별 설정을 맞춤화할 수 있습니다.Slackbot 앱 사용 도움말 Enterprise Grid·Enterprise+의 Org Owner와 Org Admin은 설치된 MCP 서버의 접근 대상을 모든 사용자, 특정 사용자·그룹, 또는 차단으로 관리할 수 있습니다. 이 관리자 기능은 Pro·Business+·Enterprise Select에는 제공되지 않습니다.

여기서 앱 승인, MCP 서버 접근, 구성원의 도구 설정, 외부 계정 권한을 혼동하면 안 됩니다. 앱 승인은 통합 설치를 허용하는 절차이고, Enterprise Grid·Enterprise+의 서버 접근 설정은 누가 그 서버를 쓸지 정합니다. 구성원별 도구 설정은 각 작업의 자동 실행·확인·차단을 조절하며, 외부 계정 권한은 실제 시스템에서 가능한 행동 범위를 결정합니다. 어느 한 층만 안전해도 전체 흐름이 안전한 것은 아닙니다.

첫 파일럿에서는 관리자가 가능한 플랜이라면 MCP 서버 접근을 제한된 사용자·그룹에만 열고, 참여자는 앱 설정에서 쓰기 도구를 Blocked 또는 Needs approval로 바꿉니다. 공급자 계정 권한도 최소화한 뒤 검색·요약 같은 읽기 중심 작업부터 검증합니다. 고객 레코드 수정, 계약 발송, 비용 승인, 운영 배포는 도구 제한, 별도 승인, 로그 검토와 복구 절차가 확인된 뒤에만 허용합니다.

보안 설명을 도입 면제표로 쓰면 안 된다

Slack은 네이티브 AI 기능이 사용자가 원래 접근할 수 있는 Slack 데이터만 사용하고, 고객 데이터를 대규모 언어 모델 학습에 사용하지 않으며, 서드파티 모델을 Slack이 통제하는 인프라에서 호스팅한다고 설명한다.Slack AI 보안 도움말 또한 비공개 채널이나 참여하지 않은 다이렉트 메시지를 AI가 새로 보여주지는 않는다고 밝힌다.

그러나 이 설명의 범위를 정확히 읽어야 한다. MCP 앱은 외부 서비스와 연결되므로 설치 화면에 표시되는 도구와 권한, 외부 공급자의 보안·개인정보 정책까지 별도로 검토해야 한다. “Slack AI가 학습하지 않는다”는 사실이 연결 앱의 모든 데이터 처리 조건을 대신 설명하지 않는다.

한국 조직의 최소 검토 문서는 다음 다섯 항목이면 충분하다.

1. 연결 앱과 공급자, 데이터 처리 위치
2. 요청 시 전달되는 데이터 종류
3. 사용 가능한 읽기·쓰기·삭제 도구
4. 사용자·그룹 배정 기준과 퇴사자 회수 절차
5. 사고 시 앱 비활성화, 토큰 폐기, 변경 복구 담당자

개인정보, 인사, 재무 데이터가 포함되면 법무·보안 검토를 선행하고 파일럿 데이터는 가명 또는 비민감 샘플로 제한한다.

사용 교육은 요청 작성보다 실행 전 정지에 초점을 둔다

MCP 교육의 실패는 사용자가 프롬프트를 못 쓰는 것이 아니라, AI가 제안한 행동을 너무 빨리 승인하는 것이다. 45분 교육을 세 단계로 구성할 수 있다.

첫째, 범위를 읽는다. 앱 연결 화면에서 Slackbot이 쓸 수 있는 도구를 확인하고 읽기와 쓰기를 구분한다.

둘째, 실행 전에 말로 확인한다. 대상 시스템, 레코드, 변경 값, 공유 채널을 Slackbot에게 다시 나열하게 한다. 이름이 비슷한 고객사나 프로젝트가 있으면 고유 식별자를 원문에서 확인한다.

셋째, 결과를 외부 시스템에서 확인한다. “완료했습니다”라는 응답이 아니라 실제 앱의 변경 기록을 읽는다. 오류가 있으면 채널에 공유하기 전 되돌린다.

교육 통과 기준은 정답률만으로 두지 않는다. 민감 작업을 거부하는지, 모호한 대상을 질문으로 되돌리는지, 실행 후 원장을 확인하는지를 관찰한다.

성과 측정은 탭 이동 횟수보다 재작업까지 포함한다

MCP 도입의 표면 지표는 Slack 안에서 완료한 작업 수다. 그러나 실행 오류가 늘면 절약한 클릭보다 복구 비용이 커진다. 다음 지표를 함께 본다.

• 업무 요청부터 외부 시스템 반영까지의 중앙값 시간
• 한 건당 수동 입력 단계 수
• 실행 후 수정·취소 비율
• 잘못된 대상이나 값으로 실행된 건수
• 결과 공유 뒤 추가 확인 질문 수
• 승인되지 않은 앱·도구 사용 시도 수

파일럿은 한 팀, 한 앱, 두 업무로 제한한다. 예를 들어 프로젝트 팀이 Linear 이슈를 조회하고 초안을 만드는 업무부터 시작하되 최종 등록은 사람이 확인한다. 2주 뒤 오류가 낮고 리드타임이 줄면 등록까지 확장한다. 여러 앱을 동시에 연결하면 어느 통합이 효과나 오류를 만들었는지 알 수 없다.

4단계 도입 판단

1. 후보 선정: 빈도가 높고 규칙이 명확하며 취소 가능한 업무를 고른다. 월 1회 예외 업무는 교육비가 더 클 수 있다.

2. 권한 설계: 앱 승인자, 플랜별 MCP 서버 접근 대상, 구성원의 도구별 허용·승인·차단 설정, 외부 계정 역할, 공유 채널을 표로 남깁니다. 기본값은 최소 권한과 제한된 그룹입니다.

3. 통제된 실험: 관리자와 참여자의 설정에서 쓰기 도구가 차단되거나 매번 승인을 요구하는지 확인한 뒤, 샘플 데이터와 읽기 작업으로 시작해 실행 전 확인과 실행 후 원장 검증을 의무화합니다.

4. 확장 또는 중단: 시간 감소와 오류·재작업 감소가 함께 확인될 때만 다음 앱이나 쓰기 도구를 연다. 보안 검토가 끝나지 않았거나 취소 경로가 없으면 연결 수를 늘리지 않는다.

협업 앱 연결과 승인 흐름을 기존 업무 자동화에 맞춰 설계하려면 POEMORA 자동화 서비스에서 시스템별 권한과 실패 복구 단계를 함께 정리할 수 있다. MCP의 생산성은 대화 한 번으로 일을 끝내는 데 있지 않다. 조직이 허용한 범위 안에서, 검증 가능한 기록을 남기며, 재작업 없이 일을 끝내는 데 있다.