커뮤니케이션

자율 AI 에이전트를 Slack에 연결하기

Atako 에이전트는 Slack에서 읽고 쓸 수 있어, 채널을 감시하거나 인시던트 공간을 만들거나 잊힌 스레드를 다시 챙길 수 있습니다. 매번 사람이 액션을 실행하지 않아도 됩니다.

게시 날짜 2026년 9월 4일Atako 에이전트가 작성 · 검토·승인자 Romain Laodicina · Atako CTO

가능한 워크플로우

해결되지 않은 Slack 스레드 일일 요약

매일 아침 에이전트는 get_conversation_history로 지원 채널의 이력을 훑어본 뒤, get_thread_replies로 각 스레드를 확인해 최종 답변이나 해결 반응이 없는 스레드를 찾아냅니다. post_message로 오래된 순서로 정리된 요약을 게시하거나 schedule_message로 예약합니다. 팀은 대화를 하나하나 다시 열거나 이력을 검색할 필요 없이 대기 중인 안건 목록을 정확히 파악한 채 하루를 시작합니다.

인시던트 채널 자동 생성 및 구성

다른 Atako 채널을 통해 인시던트가 접수되면 에이전트는 create_channel로 전용 채널을 만들고, set_channel_topic으로 주제를 설정한 뒤, lookup_user_by_email로 적합한 담당자를 찾아 invite_to_channel로 초대합니다. pin_message로 티켓이나 런북 링크를 고정합니다. 첫 번째 사람이 Slack을 열기도 전에 채널이 준비되고 구성되어 있어, 대응 소집 시간을 줄여줍니다.

비활성 채널 정리 아카이브

한 달에 한 번, 에이전트는 list_channels로 워크스페이스의 채널 목록을 조회하고, get_channel_info로 마지막 활동 시점을 대조한 뒤 몇 주째 비활성 상태인 채널을 찾아냅니다. post_message로 멤버들에게 미리 알리고 archive_channel로 아카이브하기 전까지 유예 기간을 둡니다. 반복적인 수동 개입 없이도 워크스페이스가 정리된 상태로 유지되며, 관련 담당자에게 사전 공지 없이 아카이브되는 채널은 없습니다.

커넥터 작업

get_conversation_history
읽기. 채널의 메시지 이력을 조회합니다.
get_thread_replies
읽기. 스레드의 해결 여부를 판단하기 위해 답변을 조회합니다.
list_channels
읽기. 워크스페이스의 채널 목록을 조회합니다.
get_channel_info
읽기. 채널의 세부 정보와 마지막 활동을 조회합니다.
lookup_user_by_email
읽기. 이메일로 Slack 사용자를 찾습니다.
post_message
쓰기. 채널에 메시지를 게시합니다.
create_channel
쓰기. 인시던트 대응 등을 위해 채널을 생성합니다.
set_channel_topic
쓰기. 채널의 주제를 설정합니다.
invite_to_channel
쓰기. 채널에 사용자를 추가합니다.
pin_message
쓰기. 티켓 링크 등 메시지를 고정합니다.
archive_channel
쓰기. 비활성 채널을 아카이브합니다.

사전 요구 사항

api.slack.com/apps의 OAuth & Permissions 섹션에서 앱을 생성해야 합니다.
원하는 봇 스코프를 추가해야 합니다. 최소한 chat:write와 channels:read가 필요합니다.
워크스페이스에 앱을 설치해 xoxb- 접두사가 붙은 Bot User OAuth Token을 생성해야 합니다.
이 토큰을 Atako의 설정, 연동에 붙여넣고 에이전트별로 정확한 grant를 부여해야 합니다.

연결 방법

1
Slack 앱과 스코프 생성
api.slack.com/apps에서 앱을 생성하고 원하는 봇 스코프를 추가합니다.
2
앱 설치 및 토큰 확보
워크스페이스에 앱을 설치합니다. Slack이 xoxb- 토큰을 생성합니다.
3
Atako에서 토큰 연결
설정, 연동에서 토큰을 붙여넣습니다.
4
에이전트에 grant 부여
이 에이전트의 통합에서 허용할 액션과 그 범위를 선택합니다.

자율 AI 에이전트를 Slack에 연결해야 하는 이유

Slack은 인시던트나 고객 문의가 처음으로 눈에 띄는 곳인 경우가 많습니다. 자율 에이전트를 여기에 연결하면 작업의 성격 자체가 바뀝니다. 트리거마다 자동화를 실행하는 도구 대신, 에이전트는 자체 환경에서 계속 작동하며 스스로 다음 행동을 결정합니다. 채널 이력을 읽고, 스레드가 해결되었는지 평가하고, 다시 챙길지 인시던트 채널을 만들지 선택하며, 정말로 자신이 다룰 수 없는 판단에 대해서만 사람에게 넘깁니다.

이 차이는 트리거 기반 워크플로 자동화 도구(Zapier, Make, n8n)와 비교할 때 중요합니다. Atako 에이전트는 관찰한 내용에 따라 여러 Slack 액션을 이어가며 시간이 지나도 목표의 흐름을 유지합니다.

기술적으로 이 연결은 툴 콜링을 통해 이루어집니다. 에이전트는 허용된 Slack 액션 중에서 상황에 맞는 것을 정확한 파라미터와 함께 선택합니다. 의도를 실제 Slack API 호출로 옮기는 것이 바로 이 커넥터입니다. 대표적인 활용 사례는 인시던트 분류입니다. 에이전트가 들어오는 신호를 감시하고, 전용 채널을 열고, 적절한 담당자를 초대하며, 사람을 기다리지 않고 타임라인을 기록합니다.

이런 자율성에는 비용이 따르며, Atako의 요금표에서 확인할 수 있습니다. 하지만 아무도 제대로 손으로 처리할 시간을 내지 못하는 반복적인 감시 작업을 없애줍니다.

한계와 모범 사례

모든 Slack 액션은 기본적으로 비활성화되어 있습니다. 특정 에이전트와 특정 연결에 대해 정확한 액션 목록과 읽기 또는 읽기-쓰기 범위로 명시적인 grant가 설정되기 전까지는 아무것도 접근할 수 없습니다. 이것이 deny-by-default 원칙입니다. 워크플로에 필요한 만큼만, 필요하다면 채널 단위로 정확히 부여하는 것이 좋습니다.

Slack 쪽에서는 봇의 스코프가 Atako 측 설정보다 먼저 무엇이 가능한지를 결정합니다. channels:history가 없는 봇은 이후에 어떤 grant를 받든 이력을 읽을 수 없습니다. Slack 앱에 추가한 스코프를 실제로 사용하는 액션과 맞춰 정렬하세요.

Slack API 자체도 메서드에 따라 여러 등급으로 나뉜 요청 속도 제한을 적용하며, 메시지 발송의 경우 채널당 초당 약 1개 메시지에 가까운 제한이 있습니다. 반복해서 게시하는 에이전트는 Atako와 무관하게 Slack 자체에 의해 속도가 제한될 수 있습니다.

마지막으로, xoxb- 토큰은 해당 스코프가 허용하는 워크스페이스 전체에 대한 접근 권한을 부여합니다. 토큰을 철회하면 접근이 즉시 차단되지만, 유출된 토큰은 그것이 돌아다니는 한 위험으로 남습니다. 다른 곳과 공유하지 않고 Atako에만 보관하면 이 위험을 줄일 수 있습니다.