스타트업 협업 일기 - Slack 자동화
Slack 기능. 어디까지 써봤어?
넘치는 협업 툴
나는 현재 약 40명 정도의 직원이 있는 스타트업에서 PO로 일을 하고 있다.
스타트업에서 제품을 관리하기 위해서는 정말 다양한 툴들을 사용한다.
효율화를 위해 새로운 툴을 도입하기도 하고,
또 환경이나 비용의 문제로 툴을 정리하기도 한다.
그럼에도 거의 모든 IT 스타트업에서 활용하는 툴이 뭐가 있을까?라고
하나 꼽아보자면, 나는 Slack이라고 생각한다.
사실 Slack은 이미 너무나 유명해서 모르는 사람이 없는 제품일 것이다.
그러나 최근 Slack에 대한 나의 생각이 많이 달라지고 있기 때문에,
최근 내가 느꼈던 감정과 새롭게 활용하고 있는 기능에 대해 간략하게 소개해보려고 한다.
Slack의 첫인상
내가 이 Slack을 처음 썼던 2017년도에도 여러 기능이 있기는 했지만,
사실 나는 이 Slack의 강력한 점을 크게 느끼지 못했다.
왜냐하면 그 당시에 나는 에이전시에 근무하고 있었는데,
정말 거의 메신저로써의 역할로만 이 Slack을 사용하고 있었고
DM 외에 특정한 카테고리를 기준으로 하는 채널을 만들 수 있다는 점 외에
특별한 점이 체감되는 부분이 없었기 때문이다.
그랬던 첫인상은 거의 7년이라는 시간 동안 크게 달라지지 않았고,
그냥 남들 다 쓰는 일종의 글로벌 스탠다드이니깐... 이라는 생각으로 Slack을 사용하고 있었다.
지금 생각하면 그저 원시인이었던 나Slack의 강점
Slack의 진가를 알게 되기 시작한 것도 마이프차에 이직하면서부터였다.
여기서 강력한 점을 느낀 건 바로 여러 분야에서 개발을 통한 연동이 되었기 때문인데,
우리 제품에서 일어난 여러 액션들을 실시간으로 알림을 받을 수 있었고,
GA 및 스프레드 시트와 연결하여 지표들도 계속해서 알림 받을 수 있었기에
내가 전에 알던 것과는 인상이 확연히 달라졌다.
그러나 그것도 벌써 2년이나 되어가면서,
또 워낙에 많은 사람들이 그렇게 이용해오고 있으면서,
이제는 확장성 외에 또 다른 Slack의 강점이 있나? 생각하고 있던 참에...
팀원으로부터 어떤 요청을 받게 되어 Slack에서 안 써본 기능을 활용하는 기회가 생겼다.
체계의 문제? 사람의 문제?
어떤 스타트업이나 제품에서 발견된 Bug를 제보하는 채널이 있을 것이다.
우리는 Slack의 #bug-report라는 채널에 정해진 양식으로 제보를 받고 있었는데,
이 채널에 가장 많은 제보를 하는 고객경험팀과 세일즈팀원들이 불편한 점이 있던 점을 말해주었다.
물론 기존에도 이런 불편한 점들을 해결하기 위해 제품팀에서 여러 방안을 세우고, 공유했었지만,
사람이 하는 일이다 보니 제대로 지켜질 수 없었던 부분이 있었다.
이슈 리포팅 버전 final_final_최종그래서 이번 기회에 제대로 불편한 점들을 듣기 위해
어떤 것들이 진짜 문제점인지 간단히 내부 인터뷰를 진행해 본 결과
문제점은 크게 다음과 같았다.
1. 애매한 이슈에 대한 유관 부서의 등록 부담
이전에 이 채널에는 버그를 비롯한 버그처럼 보이는 질문 사항들도 많이 올라왔었는데, 이 부분이 제품팀에서 관리가 너무 힘들어 확실한 버그만 제보하게끔 정의했다.
그랬더니, 실제로 버그를 발견하더라도 애매한 것들은 이 bug-report 채널이 아닌 다른 채널에 등록하여 질문을 하였고, 결과론적으론 제품팀에서 확인해야 하는 채널만 늘어나게 되었다.
2. 버그 리포트 입력 정보 누락
기본적으론 사전에 정의한 버그 리포트 템플릿으로 버그를 등록하지만, 가끔 바쁘거나 모든 타이핑을 입력하기 어려운 경우 항목들이 누락되어 제보가 되어서, 제품팀에서 다시 내용을 파악하는데 시간이 오래 걸렸다.
3. 담당자 배정 이슈
버그를 제보할 때, 확인을 요청할 담당자가 명확하게 배정되지 않아 확인이 지연되거나,
누가 확인해야 하는지 애매한 이슈들의 책임 소재가 불분명한 경우들이 있었다.
4. 제보된 이슈에 대한 트래킹이 제대로 되지 않았다.
어떤 건들은 해결 후 스레드로 제보한 팀원에게 해결 안내를 하였으나, 어떤 건은 잠수함 패치가 되기도 했다.
또 QA 엔지니어가 제보된 이슈를 따로 관리하고 있었으나, 일일이 노션 보드에 다시금 이슈를 옮겨두는 작업들은 일을 위한 일이 되었다.
어떻게 해결을 해볼까?
위의 문제 해결을 위해 어떤 방법을 사용해야 할까... 고민이 되었다.
참고로 우리 회사는 Slack과 Notion만 이용해서 모든 업무를 처리하는데,
비 제품팀 인원이 많기 때문에 Jira 같은 툴을 사용하는 방법도 적절하지 않았다.
그러던 중에 고객 경험팀의 팀원이 Slack에서도 사전에 정의한 폼으로
정보를 입력받을 수 있는 기능이 있다고 알려주어 서칭을 해보게 되었다.
그래서 존재를 인식한 게 바로 워크플로 기능이었다.
Slack에서 진짜 거의 열어볼 일 없던 더 보기를 누르면... 어느샌가 이런 다양한 기능들이 숨어있다.
나는 작년 정도에 업데이트되었던 캔버스 정도 기능만 사용하고 있었는데,
처음으로 이 기능의 존재를 인식하고 홀리듯이 빠져가기 시작했다.
워크플로가 뭐지?
자동화 중에서도 '워크플로' 기능은 여러 트리거에 따른 액션을 지정할 수 있는 기능으로,
많이들 사용하는 Zapier를 연상하면 이해하기 쉽다.
이벤트는 일정이나 이모티콘 반응할 때, 사용자 채널에 참여할 때뿐만 아니라 특정 클릭으로 시작할 수도 있는데, 이렇게 구성하게 되면 채팅 창에서 /워크플로명을 입력하여 여타 다른 앱처럼 바로 호출을 할 수도 있다.
이벤트 또한 굉장히 다양한 이벤트를 지원하는데, 단순히 슬랙 채널에 메시지를 보내는 것부터
Slack 최고의 강점인 다양한 서비스들과의 연동도 지원을 한다.
내가 워크플로로 설정한 기능을 간단히 한번 살펴보면 다음과 같다.
나는 트리거로 '특정 버튼을 클릭하면' 워크플로가 시작되도록 구현하였고,
정보 수집 기능을 통해서 폼 형태로 필요한 정보를 입력받도록 하였다.
이렇게 되면 지정된 콘텐츠를 입력해야 하기에, 누락된 내용들이 없게끔 만들 수 있었다.
또 우선순위 쪽에 버그 리포트가 아닌, 질문에 대한 옵션도 구성하여
질문을 하는 사람이나, 확인하는 사람의 부담을 줄이도록 구현을 하였다.
쨔잔~ 워크플로 제보 시, #Bug-report 채널에 자동 알림이 온다.단순 입력받은 항목뿐만 아니라, 보낸 사람이나 기본 담당자인 QA 엔지니어 어싸인까지 자동화할 수 있다!
이런 환경을 구축한 것 만으로 버그 리포트와 관련된 일차적인 목표는 달성했다고 볼 수 있다.
그런데...
이 정도로 끝나면 아쉽잖아?
'리스트' 기능이라고 들어봤나?
자동화처럼 알게 모르게 나의 Slack 메뉴에 추가되어 있던, '리스트'라는 기능이 있다.
이 기능은 슬랙에서 일종의 Notion에서 만들 수 있는 수준의 간략한 데이터베이스를 만들 수 있는 기능이다.
우리가 흔히 많이 본, 그 정도의 기능이기에, 이 기능 단독으로는 굳이 다른 툴을 놔두고
이 기능을 활용해야 할 동기를 느끼지 못했었... 는데...
이게 워크플로, 자동화와 만나게 되니 말이 완전히 달라졌다.
'목록에 항목 추가'위에서 구성한 워크플로를 다시 한번 들여다보자.
- 버튼을 클릭하면,
- 폼을 통해서 정보를 수집하고,
- 정보가 수집 완료되면, 채널에 메시지를 보낸다.
그런데 맨 마지막에 '목록에 항목 추가'라는 내용이 있는 것을 볼 수 있다.
이게 바로 채널에 전송된 메시지에 동작할 수 있는 버튼을 추가하고,
해당 버튼을 클릭했을 때 동작까지 이어질 수 있도록 구현한 플로우이다.
즉, 위 버그 리포트에서 버튼 한번 클릭하는 것만으로 해당 데이터가 바로 리스트에 적재되는 것이었다.
이것만으로 우리 팀 QA 엔지니어의 단순 반복 업무를 극단적으로 단축할 수 있고,
버그 리포트를 제보한 팀원은 다른 툴을 실행하지 않더라도 Slack 안에서 본인의 이슈 진행 상황을 확인할 수 있었다.
이 기능을 참 디테일하게 잘 만들었다고 느꼈던 점은,
우리가 흔히 사용하는 표/상태별 보드의 사용성을 유지하면서도
기존 Slack의 강점인 스레드 체계를 그대로 유지했다는 점이다.
때문에 리스트에 등록된 각 일감은 물론, 스레드에 등록된 코멘트들마다 URL을 가지고 있어
공유하기도 용이하고, 또 반대로 일감이 다른 스레드에 공유되면, 바로 관련 스레드에서 찾아들어갈 수 있는
탑-다운 / 바텀-업 모두 지원하는 점이 인상적이었다.
이 정도만 해도 완전 초기 스타트업에서 필요한 프로덕트 관리 기능은 모두 지원하는 거 아닐까?
여기서 끝이 아니다! 마지막까지 자동화해 보기
이렇게 열심히 프로세스를 구축해서, Slack 채널에 올리고,
데모데이를 통해 전사적으로 공유를 하니 유관부서에서 많은 긍정적인 반응이 있었다.
그런데 바로 다음의 순간. 우리 대표님께서 하나의 요구사항을 추가하셨다.
"이슈 확인하고 수정되면... 수정되었다는 알림을 받을 수는 없나?"
음... 이거까지 될까...? 자신은 없지만 확인해 보겠다는 말과 함께 나는 다시금 워크플로의 세계로 빠져들었다.
그래도 앞선 환경을 세팅하는 과정에서 꽤나 이 기능에 익숙해져서, 금방 방법을 찾을 수 있었다.
새로운 워크플로를 구성하여 리포트에서 상태가 '해결'로 바뀌게 되면,
자동으로 해당 일감 이슈 해결 메시지와 제보를 했던 팀원을 어싸인하는 형태로 구성하니 쉽게 해결할 수 있었다.
다만, 위와 같은 플로우를 만들기 위해서는 '제보한 사람' 정보가 있어야 하는데,
최초에는 이 보낸 사람 항목을 만들지 않아서 워크플로를 일일이 처음부터 수정해야 했다는 점.
또, B2C 플랫폼과 B2B SaaS, 그리고 기타 이슈를 따로 받기 위해 워크플로를 세 종류로 나눠놓았는데,
수정사항이 발생하니 모두 따로 수정해줘야 했다는 점이 굉~~ 장히 불편하기 그지없었다.
역시 처음 구조 세팅할 때 신중하게 세팅하는 게 최고다.
이 버그 리포트 체계는 6월 말에 세팅하여, 이제 한 달 정도 지나가는 참이다.
처음에 적응을 우려했으나, 다른 팀원들도 모두 잘 사용하고 있고,
확실히 이전보다 이슈 처리 진행 상황이나 과정들이 잘 드러나있어 소통하기에도 용이한 것 같다.
더 보완사항이 남아 있을 수는 있겠으나,
불편사항을 말해주었던 유관부서나, 이슈를 관리하는 QA 엔지니어도 체계에 만족하고 있기에
일단은 현재 시점에서는 성공적으로 체계를 만들어낸 것 같아 뿌듯하다.
혹여 초기 스타트업이나 극도로 적은 인원인데 여러 툴을 사용하는 것이 비용적으로 부담스럽거나
Slack, Notion 등 정보가 이리저리 분산되는 것을 우려하거나,
초기 제품 관리가 필요한데 고도화된 체계를 잡기는 어려울 것 같은 사람들이 있다면,
이 Slack의 자동화, 워크플로, 리스트 기능들을 적극적으로 이용해 보면
쉽고 간단하지만 좋은 효율을 내는 체계를 만들어낼 수 있을 것이라고 생각한다.
나도 이 Slack 자동화 세팅을 하면서 다른 사람들의 안내 글들을 많이 참고하였는데,
단순히 사용법 및 세팅 방법을 안내하기보다는 문제 인식의 순간부터
해결 과정까지 공유해 보면 누군가에게는 도움이 되지 않을까 싶어 오랜만에 이렇게 글을 써봤다.
요즘 특히 이런 자동화, 효율화에 관심이 많이 가는데,
다음엔 또 다른 툴을 활용해서 가치를 만들어내는 법을 소개해보겠다.
