본문 바로가기
스타트업/개발팀

개발자들은 왜 Slack 을 쓸까?

by 반포한강공원 2020. 10. 4.

 

슬랙 CEO, 스튜어트 버터필드

 

"카카오톡 쓰면 안되나요?"
"디스코드 쓰면 안되나요?"

정답은 이렇다. 

"안돼요 !!!"

좀 이상하다.
개발자들은 왜 꼭 Slack 을 써야 할까?

채팅이라면 카카오톡이 더 편하다.
초대하기가 더 쉽기 때문.

게이머들한텐 "디스코드"가 더 인기다.

음성채팅도 되고 모양도 슬랙이랑 똑같이 생겼으니까.

 
그런데 왜 꼭 "Slack"을 쓰라고 할까?

이유가 있다.

딱 이 시나리오 때문에 그렇다.

스타트업에서

웹 개발자, 단말개발자, 백엔드개발자
3명이 모여서 서비스를 만든다.

런칭을 하고 나니 모니터링을 해야 한다.

접속자 통계도 확인해야 한다.

시스템이 다운되면 모두에게 "비상알람"이 가도록 해야 한다.

음, "관리자 페이지"를 만들어야겠군.

그런데 업무량이 만만치 않다. 

서버도 분리해야 하고, DB도 분리해야 한다.
로그인 기능도 만들어야 한다.
로그인 만들려면 탈퇴나 권한관리도 만들어야 한다.

한번 보낸 알람은 재전송이 안되게 해야 한다.

에고 이제 갓 오픈했는데
이런 거 만들려니 부담된다.

기능도 많고 페이지 수도 많다.


배보다 배꼽이 더 크다고,

"관리자 페이지" 만드는게

핵심서비스 만드는 것보다 힘들다.

옛날에는

그냥 안만들었다.
한 명이 "백도어"로 들어가 꾸준히 확인했다.

물론 그걸론 업무 생산성이 안났다.

"무슨 에러 떴어?"
"몰라, 에러 메시지가 잔뜩인데 메일로 보낼께~"
메일 받아봤자 어차피 모른다.

서버접속을 해야 확인할 수 있다.

회사로 출동하는데만 30분이 넘게 걸렸다.

 

아직 서비스가 어릴 땐 그런 게 가능하다.

하지만 서비스가 조금 더 자라면 힘들어진다.

 

개발팀도 많아진다.

3명에서 7명이 된다.

파트도 두개로 나뉜다.

하지만 관리자 페이지 만들기엔 여전히 손이 모자란다.

핵심기능 만드는데 시간이 더 필요하다.

 

관리자 페이지는 여전히 뒷전.

하지만 이게 없어서 여전히 장애대응이 느리다.
아 미치겠다.

슬랙을 만들어버리다.

그래서 누가 아예 만들어버렸다.

"통합 관리자툴"을 !!!

 

서버에서 특정 알람이나 로그메시지를 쉽게 보낼 수 있게 했다.

로그를 보고 개발팀끼리 바로 이야기 나눌 수 있게 "채팅방"도 넣었다.

 

새벽이라도 스마트폰만 들면 알 수 있게 "앱"으로 만들었다.

특정 사안별로 대응할 수 있게 "Channel" 기능도 만들었다.

유레카~

그래서 "슬랙"은 채팅앱이 아니라

"팀 커뮤니케이션 툴"로 분류한다.

 

누가 만들었을까?

Tiny Speck 이라는 회사가 만들었다.

게임 회사다.

 

Stewart Butterfield 라는 공동창업자가 발표했다.

CTO 는 아니다. 관리자다.

Glitch 라는 게임을 만들다가 만들었다고 한다.

 

Glitch 는 망했다.

Slack 은 살아남았다.

실리콘밸리 스타트업들이 빠르게 "Slack"을 사용하기 시작했다.

 

서비스가 크는 꽤 오랫동안,

관리자 페이지를 만들지 않아도 된다.

 

이거 생각보다 유용하다.

새벽에 장애알림을 받아야 하는데,

굳이 SMS를 보내지 않아도 되니 비용걱정도 없다.

 

굳이 멋진 그래프 화면이 필요없다면,

CEO도 슬랙을 본다.

간략한 통계 숫자를 더 좋아하는 경우가 많다.

 

세계 1위 협업툴이 되었다.

부럽다.

 

Butterfield가 잘했다.

참 잘했다.

 

사실 나도 비슷하게 만들어 놓은게 있었다.

은행 프로젝트 할 때 이 과장님이 비슷한 걸 만들었었다.

이통사 프로젝트 할 때 김 차장이 비슷한 걸 만들었었다.

 

Butterfield는 완성도를 높여 발표했고,

내껀, 우리껀 그냥 몰래 썼다.

음... SI 현장이니까...

이야기하자면 길다. 잊자.

 

더 이상 설명하지 않다.

하루에 몇명 접속했는지,

어제 대비 얼마나 더 상승했는지,

접속시간은 얼마나 늘었는지,

굳이 "웹 사이트"로 볼 필요가 없다.

그냥 "슬랙앱"을 열어서 통계 Channel 을 열어보면 된다.

 

오히려 노트북을 열고 웹 로그인하고

복잡한 메뉴를 클릭해서

그 페이지를 찾아가는 것보다 훨씬 쉽다.

훨씬 빠르다.

 

투자가를 초청하기도 쉽다.

특정채널에 초대해 놓고,

필요한 정보를 보여준다.

 

굳이 한달짜리 ppt 를 만들지 않아도 된다.

"그냥 우리꺼 보세요."

채널에 초대하는 것만으로

충분히 흥미를 끌 수 있다.

 

이런 작업에는 Slack 이 단연 탑이다.

Slack 은 이렇게 협업해야 비로소 쓸모있는 툴이다.

 

뭐부터 시작해야 하나?

뭔가 Slack 이랑 연동할 서버나 서비스가 있어야 한다.

그러니 서비스를 먼저 하나 만들자.

24시간 가동되는 서비스라면 더 좋다.

 

트렐로나 Jira 와도 연계된다.

연동가능한 서비스가 1,500개나 된다.

아따 많다.

아무거나 연계해서 써보자.

서버 모니터링할 때만큼 짜릿하진 않을거다.

 

즉, 그냥 단순히 채팅방으로 사용한다면

"카카오톡 오픈채팅방"으로 충분하다.

 

이미지 캡쳐해서 공유할거라면

다른 메신저 앱으로도 충분하다.

 

하지만 Slack 을 그렇게 사용한다면 

아직 서비스 개발을 시작하지 않은거다.

 

아니면 협업을 하고 있지 않던지,

Slack 사용법을 모르고 있는거다.

 

뭐 그렇게 해도 회사는 돌아간다.

돌아간다면 그냥 그렇게 살아도 된다.

 

아니면 이미 "관리자 페이지" 기능이 충분해서

Slack 이 필요없을 수도 있다.

 

"관리자 페이지" 기능이 충분하다면,

이미 돈을 벌고 있는 대형 서비스일 가능성이 크다.

그렇다면 그냥 계속 "관리자 페이지"를 쓰자.

그래도 된다.

 

느낌적 느낌상 Slack 은 1인 ~ 50명 규모의 개발팀이

누적가입자 1,000만명까지는 괜찮지 않나 싶다.

 

요약

초보자들에게 Slack 을 써보라고 하는 이유는 이렇다.

 

쓰다보면 불편한게 생기고,

불편하면 무슨 기능이 있는지 찾게 되고,

찾고나면 써볼 수도 있게 되고,

쓰다보면 혹시 일을 잘할 수 있게 되고,

잘하다 보면 생산성이 높아지지 않을까?

 

이런 바람 때문이다.

그런데 그냥 채팅앱처럼 쓰고 있으면 "기획 의도" 실패다.

 

협업을 안하고 있거나

다른 툴에서 해결하고 있는거다.

 

도구에 매몰되지 말고

뭔가 멋있는 걸 만들어보자.

 

칼을 열심히 갈고 있지만 말고,

뭔가 맛있는 요리를 만들어보자.

 

끝.

 

반응형

댓글