지금 일하는 곳에서 약 3개월 전에 슬랙을 도입하였다. 처음에 몇주 정도 무료로 써보고, integration 의존성이 높아지고 과거 대화 검색이 필요해지면서 결국 유료로 전향.

이전에 사용하던것은 Skype. 전반적으로는 문제가 없었으나, 다소 신경쓰이는 문제들이 있었는데:

1. 모바일 클라이언트가 배터리를 너무 많이 먹는다.
2. 데스크탑에서는 P2P 네트워크의 bridge node로 기본으로 사용하기 때문에, 테더링할때 안끄면 후회할 일이 발생한다.
3. 상대가 오프라인일때 메시지를 보내고 내가 오프라인이 되면, 상대방이 이후 먼저 온라인이 되더라도 내가 온라인이 될때까지 메시지 전달이 되지 않는다. (단, 그룹 대화방의 경우는 그 메시지를 수신한 사람이 한명이라도 있고 온라인일 경우에는 전달이 된다.)
4. 파일 보낸건 그때 바로 안받으면 못받는다고 보면 된다.
5. 파일 전송 속도의 편차가 심하고, 공공 네트워크 같은 곳 (예를 들면, 스타벅스 Wifi) 에서 승인 handshake시 간혈적으로 말썽이 난다.
6. 대화록이 로컬에 저장되기 때문에 (보안 측면에서는 이 부분이 나쁘다고 할 수 없으나, 대화록 백업을 정상적인 방법으로는 못하고 export도 안된다) PC가 바뀔 경우 과거 대화 검색이 불가능하다.
7. 그 외 사소한것으로는 간혈적인 이중 푸시 노티 문제, 로그아웃 후 마지막 로그인했던 아이디의 푸시가 오는 문제. (...이건 사소하지는 않다. iOS에서 발생하는 문제이며, Android는 해당이 없는 듯 하다.)

이러한 문제 등으로 IRC (via IRCCloud), Campfire 등을 시도하였는데 여러가지로 반응이 좋지 않아 (사용률이 대단히 저조했다) 결국에는 서비스를 중단하고 (자체 IRC 서버를 운영했었다) 다시 Skype를 복귀를 했다가, 최근에 많이들 사용하는 Slack을 시도해보기로 하였다.

다른 후보들도 있었다.

• IRC / IRCCloud: 도입 실패 이력이 있어 스킵.
• Campfire: 도입 실패 이력이 있어 스킵.
• Hipchat: 지금 다니는 대학원에서 사용중. UXê°€ 일단 상당히 별로고, Atlassian ID 또는 Bitbucket IDê°€ 이미 있을 경우 골아픈 인증시스템 버그 때문에 고생한 적이 있어 일단 배제해버렸다. 장점은 (유료 플랜에 한하여) 영상 통화나 화면 공유가 되는데, 이게 얼마나 잘되는지는 시도해보지 ì•Šì•„ 모르겠다. (JIRA cloud 성능을 생각하면, 서버 중개식으로 Atlassian 서버를 경유한다면 서비스 품질에 대해서 조금 걱정이 되기는 한다.)
• 잔디: 파일 공유가 메인 기능이고, Integration이 구글 위주라 패스.
• Zulip: 무료로 사용이 가능하고, 이런 저런 측면에서 꽤 강력한 후보였으나 공교롭게도 도입 검토 시점에는 모바일 클라이언트가 제대로 빌드가 안되었다.

우선, 도입시도시에는 예외없이 전원 전향하고 Skype를 버리는 형태로 했는데, 전환은 꽤 매끄럽게 되었고, 사용률도 매우 높았다. (역시 UI가 이쁘고 봐야한다.) 지금 도입 만족도가 높고, 상당량의 커뮤니케이션이 그 안에서 발생한다. 대외 커뮤니케이션이나 기록이 확실히 남아야하는 경우에는 아직도 메일을 사용하고, 그 외 상당량 커뮤니케이션은 기록 없이 구두로 발생한다. 후자는 원격 근무자 밖에 없는 회사를 차리지 않는 이상은, 한국 사람 특성상 없어지기는 어려울 듯.

잘 나가는 애들 다들 쓴다니까 사람들이 반응이 좋았던것일지도 모른다는 생각이 조심스럽게 들기는 했다. 심지어 최근에 구글 안에서도 슬랙을 사용하는 팀이 있다 한다.

일단 슬랙의 가장 큰 장점은 Bot을 직접 짜거나 하지 않더라도 바로 사용할 수 있는 integration이 많다는 것이다. 현재 사용중인 App은 10개, 그 안에 integration은 정확히 모르겠으나, 꽤 많다. 자체적으로 Bot을 돌리고 있는것들도 있다. 최근에는 한잔씩 내릴 수 있는 기계를 사서 안쓰이지만, 이전에 아침에 커피 당번도 Slack Bot으로 정했었다. (사실은 불과 3주전까지의 이야기이다. 사실 커피는 핑계였고, 신입 직원에게 load balancer에서 사용할 queueing 알고리즘을 고민시키기 위함이었다.)

현재 업무 지원 용도로는 다음 기능들을 사용하고 있다.

• 서비스 장애/오류/관리자 손길이 필요한 상황 ë³´ê³ 
• 스토리지 장비 오류 ë³´ê³ 
• Teamcity Continuous Integration
• JIRA
• Trello (지금은 대부분 JIRAë¡œ 넘어갔다.)
• Google Calendarë¡œ 일정/휴가 관리 및 reminder

일단은 작은 회사인 만큼 한 사람이 한가지 일만 하지는 않는다. 슬랙 덕분에 내부에서 일어나는것 상당량을 모두가 관련 채널에 들어가 있으면 알 수 있다는건 공개성 측면에서 긍정적인 효과를 볼 수 있었다. 커지면 어떨지는 겪어봐야 알 듯.

simple-slack-api 라는것을 이용하여 기본적인 골격은 정말 금방 만들 수 있었다. 이전에 TCL로 Eggdrop 삽질 하던 시절 생각하면 세상 참 좋아진 것 같다. (예제는 Kotlin이나, 실제 운영중인 bot은 그냥 Java이다.)

package com.oddconcepts.coffeebot
import com.ullink.slack.simpleslackapi.impl.SlackSessionFactory

fun main(args: Array<String>) {
    val session = SlackSessionFactory.createWebSocketSlackSession(kKey);
    session.connect();
    session.addMessagePostedListener({ posted, session ->
        if (posted.sender.userName == kUserName)
            session.sendMessage(posted.channel, "Testing", null);
    });
}

지금까지 장점을 좀 정리하자면:

1. Integration이 기본 지원되는게 많아 그냥 폼 몇개 채우는거만으로 서비스 연계가 가능하다.
2. 시스템이 통보를 해줘야하는데 담당자 한명만 이 내용을 알고 있는 환경을 전원 공유 환경으로 오픈된 업무 문화를 만들 수 있다. (이건 조직 규모에 따라 적절하게 사용하기 나름이지만.)
3. Bot 개발이 편하다.
4. UI가 다른 엔터프라이즈 메시징 서비스에 비해서는 다가가기 쉽다.
5. 중개 서버가 있어 대화창에서 파일 공유가 매우 안정적으로 된다.

정도가 될 것 같다.

장점을 이야기했으니, 이제는 단점. 모든게 완벽할 수는 없으니 이 부분에 대해서는 확실히 짚고 넘어갈 필요가 있다.

우선, 가장 큰 문제. 데스크탑 클라이언트의 전반적인 퍼포먼스 문제왜 배터리 소모량 문제는 근시일 내에 해결되지 않으면 서비스의 실패 요인이 될 수 있을 정도로 심각하다. 만약에 전부 네이티브로 해결을 보고 기능상 동일한 수준을 제공하는 서비스가 나온다면 시장을 꽤 뺏어갈 수 있지 않을까 싶을 정도. 카페 근무시에는 아예 클라이언트를 꺼두고 모바일 푸시만 보면서 일할 정도로 배터리 수명에 지장을 준다.

브라우저 기반이라서는 사실 Slack의 사정이고, 이 부분은 절실하게 개선이 필요하다.

(위에서 Safari가 가장 많이 차지하고 있는 이유는 이 글을 사파리에서 작성하고 있기 때문이다. 슬랙은 사용하지도 않았다.)

그리고 구글을 제외한 대부분 외국 서비스에 공통되는 문제이나, 한글 검색이 상당히 문제가 있고 아울러 영어 검색도 딱히 좋지는 않다. 과거 대화록 검색에서 결국 원하던것을 찾지 못하여 스크롤로 찾은 적이 제법 있었으니, 검색은 사실상 포기하는게 나을수도 있다. (이건 Confluence나 JIRA 같은 경우에도 해당되는 문제이다)

Snippet (Command+엔터로 긴 글 붙여넣기) 처리가 상당히 느리다. 만약에 빌드 로그 같은걸 붙여넣을 경우 그걸 불러올때 클라이언트가 멈추는 수준으로 느려졌다가 간신히 표시된다는 느낌을 받았는데, 매번 다운로드를 받아서 봐야하는 불편함이 있다.

IFTTT인테그레이션에 의존한다면 그냥 잊고 사는게 편하다. 처음에 두번 정도 동작하고 그 뒤로는 동작하는 것을 본 적이 없다. 이게 업무상 중요한 기능이 아닌지라 (텀블러 연동) IFTTT의 문제인지 Slack의 문제인지는 확인해보지 않았으나, 엔드유저 입장에서 봤을때는 그 문제가 어디 있는지는 사실 관심이 없다. 된다 안된다에만 관심이 있는데, 경험상으로는 안된다.

비싸다. 우리 같은 경우 사람 수가 적어 크게 부담되는 금액은 아니지만, 메신저 주제에 Google Apps for Work보다 높은 금액을 지불해야하는건 사실 가격대 성능비가 좋다고 할 수는 없다. 100명 있는 조직이라고 하면, 1년에 메신저 사용료가 1000만원이라는 이야기다. 아주 큰 돈은 아니지만, 다른 무료 대안이 있는걸 감안했을때는 분명히 부담되는 비용.

단축키가 희한하고 (OS 표준하고는 좀 안맞는다) 커스터마이징이 안된다. 나의 경우, Command + Alt + 방향키와 Command + Shift + []를 사용하는 툴 대부분에서 굉장히 많이 사용한다. 문제는, 이게 동작하는 방식이 슬랙에서는 굉장히 이상한데 (특히 Command + Alt + 방향키) 원하는 기능의 단축키는 Alt + 위/아래 이다.

다조직을 사용하는 경우, 인증 시스템이 상당히 야리꾸리하다. 어차피 같은 백엔드일텐데, 같은 메일 주소, 허나 다른 비밀번호로 다른 조직 2개에 가입이 가능하다. 유저 매핑상 조직 가입 여부만 기록해두면 될 것 같은데 굳이 이런 형태로 구현한 이유에 대해서는 조금 이해가 안되는 점은 있다.

그리고 마지막으로, 개인적인 취향의 문제이지만 테마 기능이 상당히 미흡하다. 사이드바 색깔은 변경할 수 있으나, 눈이 아파서 어두운 배경을 선호하는 사람한테는 쥐약이다. 이걸 해결하는 방법은 Greasemonkey 스크립트 같은걸 이용하는 것인데, 이것 마저도 커스텀 MacGap 기반인 맥 버전에서는 사용할 수 없다. 사실 사이드바만 색상 변경 가능한건 무슨 의미인가 싶기도 하다.

사용할지 말지는 어디까지나 팀의 성향과 커뮤니케이션 스타일, 그리고 특히 타 서비스와 연동의 필요성에 따라 달려있는것 같다. 완벽하지는 않지만, 성향이 맞다면 써볼 만한 툴.

쓸데없는 사실: Slack 백엔드 스택의 상당량은 PHP(?!)임. 쓸데없는 사실2: 구글 인증 Slack 조직에 가입했다가 해당 구글 계정에 대한 권한을 상실하면 클라이언트에서 로그아웃이 영원히 불가능한 버그가 있다.