37
회사마다 Slack 봇의 모양은 다릅니다.
어떤 봇은 Jira 이슈를 만들고, 어떤 봇은 회의에 늦은 사람을 부르고, 어떤 봇은 의심 거래의 판단 근거를 전달합니다. 기능만 보면 서로 관련이 없어 보이죠.
그런데 각 회사의 공식 기술 블로그를 따라가 보니 공통점이 있었습니다.
정보가 생긴 시스템보다, 사람이 다음 행동을 하는 곳에 봇을 두고 있었습니다.
1. 토스는 Jira를 없애지 않고 ‘이슈를 옮기는 순간’을 없앴습니다
Slack에서 버그나 요청이 제보되면 담당자는 브라우저를 열고 Jira에 접속한 뒤 같은 내용을 다시 입력해야 합니다.
토스의 이슈봇은 Jira를 대체하지 않았습니다. 대신 Slack 대화가 이슈로 바뀌는 구간을 짧게 만들었습니다. Slack 안에서 이슈를 만들고, 수정하고, 완료할 수 있도록 한 것입니다.
토스 이슈봇 활용 화면. 출처: 토스 기술 블로그, 「슬랙봇 디자인 101」
토스가 공개한 계산에 따르면 이슈 생성에서 45초, 업데이트에서 15초가 줄었습니다. 2021년 한 해에 절약한 시간은 1,076시간이었습니다.
한 번의 작업에서 줄인 시간은 짧습니다.
하지만 매일 여러 사람이 반복하는 이동과 재입력은 팀 전체의 시간으로 계산하면 커집니다.
토스 글에서 특히 눈에 들어온 표현은
Slack 봇이 해야 할 일을 ‘업무 대화의 맥락’에 위치시킨다는 설명이었습니다.
봇의 장점이 기능 수가 아니라
대화하던 사람이 다른 화면으로 이탈하지 않아도 된다는 것에 있다는 이야기입니다.
2. 카카오페이는 회의 연락의 작은 어색함을 없앴습니다
회의가 시작됐는데 참석자가 오지 않으면 어떻게 할까요?
이름을 확인하고, Slack에서 검색하고, DM을 연 뒤 “회의 오고 계신가요?”라고 메시지를 보냅니다.
카카오페이 기술 블로그는 이를 네 단계의 과정으로 설명합니다.
개발자 5명이 사내 Slack 봇 콘테스트에서 만든 ‘죠르디 회의봇’은
참석자 이름을 한 번 누르면 봇이 대신 알림을 보내도록 만들었습니다.
카카오페이 죠르디 회의봇의 회의 시작 알림. 출처: 카카오페이 기술 블로그
이 사례가 재미있는 이유는 거대한 생산성 문제가 아니라,
회의 때마다 누군가 감당하던 작고 반복적인 수고를 골랐기 때문입니다.
죠르디는 아침 일정 브리핑, 회의 시작 알림, 회의실 위치와 회의록 공유까지 기능을 넓혔습니다.
정식 출시 시점에는 전사 구성원의 25%가 사용했고, 이후 사내 사용자의 80%까지 확보했다고 합니다.
기능을 한꺼번에 늘려서가 아니라, 실제로 자주 겪는 장면에서 시작해 사용자를 넓힌 과정도 함께 볼 만합니다.
3. 당근페이는 AI의 판단 결과를 Slack으로 가져왔습니다
당근페이는 이상거래탐지시스템(FDS)에 LLM을 적용한 과정을 공식 기술 블로그에 공개했습니다.
의심 거래 한 건을 검토하려면 거래 내역과 중고거래 게시글 등 여러 정보를 확인해야 했고,
한 건에 5분에서 20분까지 걸렸다고 합니다. 담당자가 교대되면 판단에도 차이가 생길 수 있었습니다.
당근페이는 룰 엔진의 결과와 추가 데이터를 LLM이 함께 평가하도록 했습니다.
그리고 모델이 만든 판단 결과와 근거를 모니터링팀의 Slack 알림으로 전달했습니다.
당근페이 AI 기반 FDS 사례. 출처: 당근 기술 블로그
여기서 Slack은 단순한 알림창이 아닙니다.
시스템이 분석한 정보를 실제로 검토하고 대응할 사람에게 가져가는 마지막 구간입니다.
AI가 판단을 끝내는 것이 아니라,
사람이 더 빠르고 일관되게 판단할 수 있도록 필요한 맥락을 전달하는 방식에 가깝습니다.
4. GitHub는 채팅창을 운영 명령의 입구로 바꿨습니다
Slack이 지금처럼 널리 쓰이기 전부터 GitHub는 사내 채팅에서 반복 업무를 처리하는 Hubot을 만들었습니다. 팀원은 채팅창에서 Hubot을 불러 배포하거나 운영 정보를 확인하고, 정해진 작업을 실행할 수 있었습니다.
GitHub의 자동화 봇 Hubot. 출처: GitHub Blog, 「Hubot」
Hubot이 보여준 핵심은 채팅 도구가 업무 시스템 전체를 대신한다는 데 있지 않습니다. 사람이 이미 모여 대화하는 곳에 자주 쓰는 명령과 결과를 가져오면, 별도의 화면을 오가는 횟수를 줄일 수 있다는 점입니다.
토스가 대화를 Jira 이슈로 연결하고, 당근페이가 분석 결과를 담당자에게 전달했다면, GitHub는 채팅에서 운영 작업을 시작하도록 했습니다. 해결한 문제는 달라도 ‘사람이 다음 행동을 하는 자리에서 봇이 일을 이어준다’는 원리는 같습니다.
Slack 봇의 역할은 ‘다 하는 것’보다 ‘사이를 잇는 것’에 가깝습니다
네 회사는 서로 다른 문제를 풀었습니다.
- 토스는 대화를 이슈로 옮기는 구간을 줄였습니다.
- 카카오페이는 회의 참석자에게 연락하는 단계를 줄였습니다.
- 당근페이는 시스템의 분석 결과를 담당자의 판단으로 연결했습니다.
- GitHub는 채팅에서 반복적인 운영 작업을 시작하게 했습니다.
이 사례들을 보고 나니 Slack 봇의 역할을 조금 다르게 보게 됩니다.
모든 업무를 Slack 안에 넣는 것이 아닙니다. Jira, 캘린더, FDS처럼 각자의 목적에 맞는 시스템은 그대로 둡니다. 대신 정보가 생긴 곳과 사람이 행동하는 곳 사이의 간격을 줄입니다.
CROS AIR도 이 간격에서 출발했습니다.
팀의 업무는 Slack 대화와 Thread에서 생기지만, 할 일과 담당자, 진행 상태는 대화 사이에 흩어집니다. CROS AIR는 새로운 업무 방식을 하나 더 요구하기보다, 이미 오간 대화에서 실행할 내용을 정리하고 원래 맥락과 연결하는 데 집중하고 있습니다.
좋은 Slack 봇을 판단하는 질문은 “무엇까지 할 수 있나?”보다 “사람이 매일 반복하던 어느 구간을 줄였나?”에 더 가까울지도 모릅니다.
참고 자료
0
0