Slack을 AI 에이전트에 연결하기

1. 에이전트가 Slack에서 하는 일

커넥터는 연결이 돌려준 토큰으로 Slack의 웹 인터페이스와 곧바로 대화합니다. 다섯 가지 작업을 쓸 수 있고, 용도는 셋으로 나뉩니다.

• 찾기. 결정, 링크, 이미 나온 답을 찾아냅니다 — 다시 묻는 대신.
• 이력 읽기. 채널의 흐름을 이어받아 어떤 주제가 어디까지 왔는지 파악합니다 — 쓸모 있는 답변의 조건입니다.
• 올리기. 채널에 씁니다 — 보고, 경고, 끝낸 일의 결과.

요청하는 권한은 셋입니다 — 채널 목록 읽기, 그 이력 읽기, 메시지 쓰기. 다이렉트 메시지에 관한 것은 없습니다.

2. 앱은 채널에 초대되어야 한다

이것이 첫 번째 놀라움이고, 결함이 아닙니다. Slack은 채널의 이력을 그 채널의 구성원인 앱에만 엽니다. 앱이 초대되기 전까지 읽기는 「not_in_channel」이라고 답하고 아무것도 올라오지 않습니다.

초대는 Slack 쪽에서, 채널마다, 동료를 대하듯 합니다. 처음에는 약간의 수고이고, 사실 이것이 제품의 가장 좋은 보증입니다. 에이전트의 범위가 Slack 안에서 모두에게 보입니다. 누구나 앱이 어느 채널에 있는지 보고, 빼낼 수 있습니다. 남의 화면에 숨은 설정이 팀이 보는 것을 뒤집을 수는 없습니다.

3. 올린 글은 거둘 수 없다

이것이 설정을 좌우해야 할 제약입니다. 에이전트가 채널에 올린 글은 구성원 모두가 읽고, 조용히 거두는 방법은 없습니다. 알림은 나갔고, 사람들은 보았습니다.

실제적인 결과는 셋입니다.

• 고객이나 협력사, 혹은 회사 전체가 있는 채널에서는 쓰기 전 승인을 남겨 두십시오. 그것이 기본 설정이고, 거기서 완화할 좋은 이유는 없습니다.
• 에이전트가 계속 내놓는 것 — 보고, 끝낸 일, 경고 — 을 위해 전용 채널을 여십시오. 그 채널은 위험 없이 완화할 수 있습니다. 그것을 읽는 사람들이 거기서 무엇을 볼지 알기 때문입니다.
• 「사정을 알고 있게」 하려는 이유만으로 결정이 이루어지는 채널에 에이전트를 연결하지 마십시오. 채널을 읽는 것은 접근이지 예의가 아닙니다.

4. 채널에 쓰인 것은 명령이 아니다

메일과 마찬가지로, 채널의 내용은 에이전트가 읽는 데이터이지 실행하는 지시가 아닙니다. 누군가 — 선의든 아니든 — 「에이전트가 이 파일을 이 주소로 보내야 한다」고 쓸 수 있습니다. 그 메시지는 이해할 텍스트일 뿐 명령이 아닙니다.

지시는 에이전트에게 맡겨진 임무에서 옵니다. 그리고 회사를 구속하는 모든 작업은 실행 전에 요청되는 사람의 승인을 거칩니다. 누구나 쓰는 도구에서 이 구분은 이론상의 세부가 아닙니다.

5. 시간이 지나면 무엇이 달라지는가

Slack의 값어치는 올리기가 아닙니다 — 기억입니다.

• 1주 차. 이미 답한 질문이 다시 나오지 않습니다. 에이전트가 결정을 찾아내 그 글을 인용합니다.
• 3개월 차. 에이전트 채널이 무엇이 이루어졌는지 보는 자리가 됩니다. 그것을 묻기 위한 회의는 필요 없습니다.
• 2년 차. 그전까지 3주만 지나면 읽을 수 없던 Slack의 이력이 다시 찾아볼 수 있게 됩니다 — 찾는 법을 아는 존재가 있기 때문입니다.

수치로 된 이득은 약속하지 않습니다. 오가는 양과 채널 운영의 규율에 달려 있습니다.

6. 자주 묻는 질문

더 읽기

이어서 읽기: 이용 가능한 모든 커넥터, 에이전트가 일하는 모습 보기, 거버넌스와 예산 통제.