1. 개요
사내 문서 아카이빙과 효율적인 프로젝트 관리를 위한 사내 Slack 도입과 더불어 챗봇 시스템을 통해 자동화 및 AI 연계성에 대해 정리해보려 합니다.
현재 회사 내 메신저는
dooray를 사용하고 있었습니다. 하지만 대부분의 임직원들은 해당 메신저의 기능을 100% 활용하지 못하고 있다. dooray 내에서도 프로젝트 관리와 드라이브, 위키 등 다양한 툴들이 있지만, 웹 기반으로 구동되는 부분과 잦은 오류, 투박한 디자인으로 인해 사용성은 떨어지는 듯 하다.1.1 빛 좋은 개살구인 두레이
문제의 원인을 생각해보니 다음과 같았다.
- 투박한 디자인 + 웹 기반 관리(App은 있지만 한계가 있다.)
- 자유도가 낮은 챗봇: 웹훅 수준으로만 가능. (slack의 integration 급은 아님)
- 커스터마이징 하기 어려움.
- UX 적으로 불편함. (뭐가 뭔지 잘 모름)
이 외에도 여러가지 이유가 있겠지만, 나 또한 사용하기에 자유도가 떨어지고, 복잡하게 느껴졌다.
1.2 대안책을 찾아보자.
우선 사내 메신저의 취지를 알아보자.
사내 메신저는 사실 dooray 채팅 기능만으로 충분하다. 하지만, 이미 카카오톡과 유사한 서비스이기에 하나의 채팅방에서 모든 업무와 대화가 시작되는 형태이다. 이는 “채팅형으로 진행”되는 구조이기에 휘발성이 강하여 이전에 메시지를 하나 씩 뒤져 봐야하는 구조이다. b
그렇다면 단순 “메신저”로써의 역할을 넘어선,
협업툴 로써의 새로운 대안을 찾게되었다. 이전 회사에서 잘 사용했었던 Slack 이다. 사실 여러가지 협업툴을 통해서 회사 문서와 기획, 마케팅, 개발 등 다양한 부분에 필요한 솔루션을 통합해주는 것으로 떠올리기 쉬운 협업툴이다.내가 가장 좋아하는 말은 “반복되는 행위에 대해, 자동화시켜 본질에 집중”할 수 있게 하는 취지에 맞는 툴이 바로
Slack 이다. 다양한 App 들과 통합하고 프로세스를 만들어 자동으로 배포하고 테스트할 수 있게 하는 것이다. 또한 Slack API를 통해 챗봇으로 다양한 업무를 보조하고 생산성을 월등히 높일 수 있기 때문이다.2. 사내 Slack을 도입하기 위한 여정
Slack 과 Dooray가 공존하다.
Dooray 를 버리기엔 이미 이메일, 근태 관리, 결제관리 등 복잡한 여정이 함께 한다. 따라서 일반적인 메신저에 특화된 Dooray와 별도로
Slack 을 통해 업무 상 커뮤니케이션이 필수적인 부분 한정으로 Slack 을 선택하였다.특히,
Slack 채널에 집중해서 보다 업무 상 구분이 되어야하는 채널에 포커스를 두었다.2.1 채널 네이밍 선정
채널이 우후죽순 생겨나면 어디가 어디인지 찾기가 힘들다. 현재 내가 들어간 채널만해도 수십여개가 된다. 이렇기 때문에 채널 네이밍이 중요해진다. 여러가지 레퍼런스를 참조하던 중 가장 우리에게 잘 맞을 것 같은 레퍼런스를 참조해 다음과 같이 네이밍을 선정했다.
접두사 | 설명 |
#0- | 전체 공지 및 정보 교환 채널 |
#1- | 각 부서별 공지사항, 이야기, 정보 교환용 채널 |
#2- | 부서 별 진행하는 프로젝트 채널 |
예를 들어 SW개발팀에서 진행하는
AA프로젝트 라고 하면, 채널명은 #2-AA프로젝트 가 되는 것이다. 이렇게 앞의 접두사가 구분값이 되며 내가 원하는 채널을 찾기 위한 하나의 태그로 보면 된다. 2.2 Slack 봇 도입하기
이미 잘 만들어진
Slack 봇이 있기 때문에, 크게 만들지는 않았다. 현재 추가된 Bot은 Figma, Github, Google Drive, Youtrack, Outline 이다.- Figma : 피그마 대지에 코멘트를 달면 실시간으로 알림이 온다.
- Github: PR 시 알림이 온다.
- Google Drive: 구글 드라이브 파일 관리
- Youtrack: jira 와 동일한 에자일/칸반보드 형태의 소프트웨어(이슈 트래킹)
- Outline: 사내 위키 백과
추가로 만든 봇은 다음과 같다.
- rbot: GPT4와 연계해서 데이터를 받아오게 하였다.
- 정량 서류 만료일 체크
- 지난 프로젝트 아카이빙 검색 - outline 연계
- aws-bot: AWS EC2 인스턴스 상태 조회 서비스
- stop/running 인스턴스 조회
- CPU 사용량 조회 → 차트 표시
rbot은 내가 직접 만들었고, aws-bot 은 팀원이 만들었다. 여기서 aws-bot 을 시작하기 위해 전반적인 가이드와 함께 AWS Lambda에 대해서 알려주었고, 해당 인프라 관리에 대한 가이드도 지원하였다.
2.3.1 rbot 만들기
전반적인 구조는 다음과 같다. 우선 기능에 대해서 정리하면,
🕵️ 정량 서류 알림 - alarm.gs
코드
🕵️ 특정 폴더 내 파일 변경 알림 캐치 - event_catch.gs
코드
위 2개 코드는 구글 스크립트 기반으로 작성했다.
특정 파일이 만료되어가면 스프레드시트에 로그를 남기도록 하였다. 그리고 해당 파일이 업데이트 되면 새롭게 알림을 주도록 하였다.
매일 일정 시간에 스케쥴링 작업을 해서 만료일 / 최신화 검사를 진행하였다.
2.3.2 rbot 으로 GPT4 붙이기
Slack 은 expeire 시간이 3초이다.
Slack 특성 상 API 에 해단 대기시간은 3초 이내로 떨어져야한다. 하지만 GPT4를 붙이기 위해선 3초 이상의 시간이 필요했다. 따라서 내가 생각한 로직은 다음과 같다.AWS Lambda 비동기 콜
원래는 AWS Lambda 에서 Step Function으로 처리하려했다. 하지만 변수를 전달하고 다시 콜백함수로 호출하는 과정이 여간 귀찮은 과정으로 여겨졌다. 왜냐하면
Slack 에서는 여러가지 커맨드 명령어를 입력해야했다. 이때마다 처리하는 과정이 매우 복잡하게 여겨졌다.따라서 하나의 메인
커멘드 명령어 수신 함수를 기반으로 해당 명령어에 해당하는 로직을 구현하는 Processor 함수를 비동기로 호출하기로하였다.기존 코드를 조금 수정하면 위와 같다. 해당
\combo 명령어가 들어오면 비동기적으로 다른 Lambda 함수를 호출하는 방식이다. 기본적으로 AWS Lambda 는 비동기 호출이 가능하기 때문이다.커멘드 명령어가 입력되면, 바로 메시지를 전달한 뒤, 해당 메시지 원본을 교체하는 방식을 차용하였다. 어짜피 커멘드 명령어는 본인밖에 보이지 않기 때문에 큰 무리가 없이 구현할 수 있었다.
그리고 API Gateway를 통해 외부와 통신을 하게 하였다. 앞 단에서 Slack Bot Token 유효성 검사를 통해 validate를 하였고, API Gateway에서 권한 부분 에서도 처리하였다.