Slack 연동 — 협업 도구는 AI가 일하는 "광장"이 되어야 한다

신진형 · 에스엘파워 · 2026.06.17

메신저를 그냥 직원들 잡담 공간으로 두면 아깝습니다. 우리가 Slack을 택한 진짜 이유는 채팅이 아니라, AI 에이전트가 사람과 같은 채널에서 일하고, 보고하고, 승인을 받을 수 있는 “업무의 광장”으로 쓰기 위해서였습니다. 이 글은 협업 도구를 고를 때 1순위 기준을 “채팅 품질”이 아니라 “연동성”에 둔 이유와, 그것이 우리가 설계한 동사 → 도구 → 채널 구조와 어떻게 맞물리는지에 대한 기록입니다.

1. 협업 도구를 “메신저”로만 보지 않기

대부분의 회사에서 메신저는 대화 도구입니다. 사람이 사람에게 말을 거는 곳. 하지만 AI 네이티브를 지향하는 우리에게 협업 도구는 다른 의미였습니다. 에이전트가 어떤 사건을 감지하고, 판단하고, “이거 승인해 주세요”라고 사람에게 말을 거는 접점이 필요했습니다.

그 접점으로 가장 자연스러운 곳은 어디일까요? 새로 만든 복잡한 결재 화면이 아니라, 이미 사람들이 하루 종일 모여 있는 메신저였습니다. 사람이 굳이 시스템을 찾아가는 게 아니라, 시스템이 사람이 있는 곳으로 찾아오는 것입니다.

이 차이가 왜 결정적인지는 “마찰”이라는 단어로 설명됩니다. 사람에게 새 화면을 하나 더 열게 하는 것, 새 앱을 깔게 하는 것, 새 로그인을 외우게 하는 것 — 이런 작은 마찰이 쌓이면 아무리 좋은 기능도 안 쓰게 됩니다. 반대로 “이미 켜져 있는 메신저에 알림이 뜨고, 거기서 바로 답한다”면 마찰이 거의 0입니다. AI가 사람을 돕겠다면서 사람에게 새 수고를 강요하면 본말이 전도됩니다. 그래서 우리는 에이전트의 출구를 “새 화면”이 아니라 “이미 있는 채널”로 두기로 했습니다.

2. 왜 하필 Slack이었나 — 기준은 “연동성”

우리는 메신저를 여러 번 갈아탔습니다. 외주 도구에서 시작해 사내 자체 호스팅까지 시도했고, 최종적으로 협업 도구로는 Slack을 택했습니다(그 여정은 메신저 여정 글에 따로 적었습니다).

Slack을 고른 핵심 기준은 단순한 채팅 품질이 아니라 연동성이었습니다 — 외부 시스템과 봇·웹훅·앱으로 얼마나 깊게 엮을 수 있는가. AI 에이전트를 채널에 자연스럽게 들여보내려면 이 확장성이 결정적이었습니다.

흔한 선택 기준	우리가 둔 기준
채팅이 잘 되나	봇·웹훅·앱 연동이 깊은가
이모지·스레드가 예쁜가	에이전트가 채널에서 행동할 수 있나
가격이 싼가	승인 같은 상호작용을 채널 안에서 처리할 수 있나

3. 동사 → 도구 → 채널: 우리 설계의 마지막 퍼즐

이 결정을 이해하려면 우리 ERP 설계의 출발점을 알아야 합니다. 우리는 화면(명사)이 아니라 **동사(verb)**에서 시작합니다.

설계 순서: 동사 → 도구 → 채널. 협업 도구 연동은 이 그림의 마지막 퍼즐입니다 — 에이전트가 도구를 실행한 결과를 사람에게 보고하고 승인받는 창구가 메신저 채널이 됩니다.

이 그림에서 보듯, 협업 도구는 곁다리 기능이 아니라 설계의 출구입니다. 에이전트가 “재고가 부족합니다, 발주할까요?”를 어디에 묻는가 — 그 자리가 메신저 채널입니다. 그래서 “그 채널에서 봇이 말하고, 버튼을 누를 수 있는가”가 도구 선택의 1순위 기준이 됐습니다.

한 장면으로 그려 보면 이렇습니다. 재고를 확인하는 동사가 도구로 등록돼 있고, 에이전트가 그 도구를 주기적으로 실행합니다. 어느 날 특정 자재가 안전 재고 아래로 떨어지면, 에이전트는 그 사실을 감지해 채널에 한 줄을 띄웁니다 — ”○○ 자재가 안전 재고 미만입니다. 지난 발주 이력 기준으로 발주서를 준비할까요?” 담당자는 채널에서 그 제안을 보고, 맞으면 승인합니다. 그 순간 에이전트는 다음 동사(발주서 작성)를 실행합니다. 사람은 어떤 화면도 새로 열지 않았고, 단지 채널에서 판단만 했습니다. 이것이 동사 → 도구 → 채널이 한 줄로 꿰어졌을 때의 모습입니다.

지금 우리가 구현한 단계는 이 그림의 앞부분 — 코어 업무 동사들을 에이전트가 호출할 수 있는 도구로 등록하고, 알림이 채널로 흐르게 하는 배관까지입니다. “채널에서 버튼 하나로 승인”이라는 마지막 한 칸은 이 배관 위에 얹을 다음 작업으로 남아 있습니다. 중요한 건 순서입니다 — 동사와 도구라는 토대를 먼저 깔았기 때문에, 채널 상호작용은 그 위에 자연스럽게 얹힙니다. 만약 화면부터 만들고 동사를 나중에 붙이려 했다면, 이 구조 자체가 성립하지 않았을 것입니다.

4. 사람은 승인하고, 에이전트는 일한다

이 방향이 의미 있는 이유는 우리의 일관된 철학과 맞닿기 때문입니다. 에이전트가 자율적으로 일하되, 중요한 결정은 사람이 내립니다(HITL).

그 “사람의 결정”이 일어나는 자리가 별도의 복잡한 결재 화면이 아니라, 이미 손에 익은 메신저 채널이라면 — 마찰이 극적으로 줄어듭니다. “승인할까요?”에 엄지손가락 하나로 답하는 미래를 향한 첫걸음입니다. 전자결재의 “사건 → 판단 → 사람 승인” 골격이, 이번엔 메신저 채널 위에서 한 번 더 구현되는 셈입니다.

5. 그래서, 협업 도구를 고를 때 무엇을 보나

우리 경험을 체크리스트로 정리하면 이렇습니다. AI 네이티브를 지향하는 조직이라면, 아래 오른쪽 항목들이 왼쪽보다 무겁게 다뤄져야 합니다.

질문	왜 중요한가
봇이 채널에서 말하고 들을 수 있나	에이전트가 사람에게 보고하는 입
외부 사건을 채널로 밀어 넣을 수 있나(웹훅)	업무 사건을 채널로 흘리는 통로
메시지에 버튼·상호작용을 붙일 수 있나	”승인할까요?”를 채널에서 처리
사람들이 이미 매일 켜 두는가	마찰 0 — 새 습관을 강요하지 않음

이 표의 모든 항목은 “채팅이 잘 되나”와는 거의 무관합니다. 전부 **“에이전트가 이 안에서 일할 수 있나”**를 묻습니다. 도구를 고르는 렌즈가 바뀌면, 같은 후보군을 봐도 결론이 달라집니다.

이 글은 SL.AIMS를 만들며 겪은 현장 회고 중 하나입니다. 전체 그림은 〈사례연구: SL.AIMS〉에 있습니다.