슬랙이라는 메신저의 설계 철학

가장 최근에는 슬랙을 프로젝트 전체의 업무용 메시징 시스템으로 활용하고 있습니다. 그 전에는 마이크로소프트 팀즈를 사용했는데 저는 이 소프트웨어와 서비스를 극도로 싫어했습니다. 어느 정도로 싫어했느냐 하면 그들도 기껏해야 돈 받고 일하며 생계를 꾸려 가는 비슷한 사람들이라는 사실을 모르지 않으면서도 팀즈 만든 놈들은 지옥에나 가라고 말했을 정도입니다. 그들은 지구에 산소가 고갈되는 미래까지 지옥에서 끝없이 고통 받아야 마땅합니다. 인터넷에 자주 나타나는 힙한 회사들은 더 이상 윈도우 기반 운영체제를 제공하지 않고서도 개발할 수 있는 것 같지만 적어도 제가 경험해 온 게임 소프트웨어 개발 업계에서는 아직까지 윈도우 이외의 운영체제를 각자가 사용할 메인 워크스테이션으로 제공한 적이 없습니다. 어느 회사의 어느 프로젝트에 출근하더라도 항상 처음 받은 기계에는 윈도우 운영체제와 마이크로소프트 오피스가 기본 제공되었는데 먼 과거에는 종종 팀마다 윈도우 운영체제를 설치하는데 사용할 미디어를 가지고 있기도 했지만 어지간하면 회사에 수직계열화 되어 있거나 계약직으로 고용된 IT 부서에서 바로 로그인 해서 사용할 수 있는 상태로 만든 다음 책상 위에 올려 놓아 주곤 합니다. 윈도우 11은 첫 출시 때 그들이 과거 인터넷 익스플로러나 엣지 브라우저를 그렇게 했던 것과 같이 팀즈 앱을 운영체제에 기본 탑재했습니다. 마이크로소프트 팀즈는 이 분야에 아주 늦게 진입한 경쟁자이지만 윈도우 운영체제와 함께라면 의미 있는 자리를 차지할 수는 있겠다고 생각했습니다.

윈도우 11이 출시될 무렵 저는 매터모스트라는 슬랙 얼터너티브를 사용하는 프로젝트에 소속되어 있었습니다. 사실 처음 프로젝트를 시작할 때 업무용 메시징 시스템으로 당연히 슬랙을 사용하는 것이 좋겠다고 의견을 모았지만 당시 우리들의 사정 상 회사에 함부로 고가의 소프트웨어를 구입해 달라고 요청하기에는 좀 애매한 상황이었습니다. 회사는 직원들이 한 달 단위로 최대 52시간으로 제한된 초과근무시간을 거의 채우기를 요구했는데 물론 여기에 제대로 보상을 해 주었습니다. 모르긴 몰라도 회사는 이 초과근무 시간 전체를 채우기 위해 상당한 비용을 투입하고 있었을 것 같습니다. 특히 이렇게 초과근무를 만성적으로 유지하면 어지간히 건강을 유지하던 사람들도 점점 더 아침에 일어나기 힘들어지기 때문에 회사에서 허용하는 가장 늦은 시간에 출근하게 되는데 그러면 퇴근 시간은 거의 대부분 회사에서 택시 비용을 제공하는 시간 이후가 되기 십상입니다. 그러면 회사는 초과근무 수당을 지불해야 하고 그 시간 중 상당 부분은 야간 근무로 계산되어 더 높은 수당이 책정되며 거기에 택시비까지 지불해야만 합니다. 밤 11시가 넘은 시간에 회사 앞은 회사까지 올라오는 언덕 저 아래에서부터 언덕 위까지 늘어선 택시들로 불야성을 이루었는데 우리들은 회사 앞까지 이어지는 오르막길을 ‘판교 택시 언덕’이라고 부르곤 했습니다. 그런데 알고 보니 이 시간대에 이 언덕에 차를 세우고 대기하던 기사님들 일부도 이곳을 같은 이름으로 부르고 있다는 사실을 알게 되어 상당히 재미있는 현상이라고 생각했습니다. 누군가 그 이름을 말했을지 아니면 기사님들 사이에 자연스레 만들어진 이름일지 굉장히 궁금합니다.

회사는 이런 곳에 큰 돈을 쓰는데 익숙한 것 같았지만 우리들이 사용할 소프트웨어를 구입하는데는 그리 익숙하지 않은 것처럼 보였습니다. 가령 우리들이 사용할 위키 모양의 정보시스템은 최신 버전으로부터 여러 버전 뒤쳐진 옛날 버전이었는데 물론 그 버전으로도 일상적인 기능을 활용하는데는 무리가 없었지만 컨플루언스 위키의 단점에 설명한 대로 정보시스템 소프트웨어의 현대적인 최신 버전과 회사에서 구동하는 버전 사이에 차이가 점점 커지며 사용성이 현대에 프로젝트 구성원들 각자가 일상적으로 사용하는 소프트웨어 사용 경험에 한참 뒤쳐진 모습일 수밖에 없습니다. 하지만 회사는 이런 상황으로부터 기인할 수 있는 생산성 저하를 딱히 심각하게 여기지는 않는 것 같아 보입니다. 또 회사에서는 게임 소프트웨어 개발 업계에서 널리 사용하는 고가의 형상관리 소프트웨어를 사용했습니다. 인터넷에 올라오는 여러 글을 살펴보면 이 세계에는 형상관리도구로 오직 깃(Git)만이 사용되는 것처럼 보입니다. 심지어 어떤 커뮤니티에 올라온 글은 ‘어떤 유명한 대기업에서는 깃을 사용하지 않고 아무도 안 쓰는 듣보 형상관리도구를 사용한다’고 말하고 있었는데 실상 깃은 이 고가의 형상관리 소프트웨어가 처음 시장에 나타난 다음 10년이 지난 다음에야 나타났습니다. 깃이 시장에 처음 나타났을 때 이 도구의 특징은 네트워크 없이 분산환경에서 동작하며 무료로 사용할 수 있다는 점 정도였습니다. 하지만 우리들은 깃으로 빌드 규모를 지탱할 수 없다는 점을 잘 알고 있었기에 선택의 여지가 없습니다.

하지만 이 고가의 형상관리도구는 앞서 계속해서 고가라는 점을 강조한 대로 사용자 당 매월 상당한 비용을 지불해야 했기에 단일 소프트웨어에 지출하는 것 치고는 굉장히 비용이 높았을 겁니다. 회사는 꼼수를 썼는데 소프트웨어 제작사가 계정 단위로 과금한다는 점을 응용해 최소 팀 단위로 같은 계정을 사용하게 한 다음 각 사용자가 서로 다른 워크스페이스 이름을 사용해 서로를 구분하는 방식으로 계정 수를 줄여 비용을 절약합니다. 그래서 이 도구로 작업 내역을 살펴보면 팀 계정들이 하루에도 수없이 많은 파일을 올려 대고 있었는데 언뜻 보면 한 사람이 이렇게 많은 파일을 이렇게 여러 차례 작업해서 올리고 있다고 착각할 수 있지만 계정 칼럼을 숨기고 워크스페이스 이름 칼럼을 추가하면 계정은 같지만 서로 다른 워크스페이스로부터 작업 되어 파일이 올라왔다는 사실을 알 수 있었습니다. 그래서 프로젝트 전체에 걸친 꽤 많은 인원이 이 형상관리도구를 사용하면서도 예상하기에 회사는 그리 큰 비용을 지출하지 않고 있었을 가능성이 높습니다. 이 사실을 형상관리도구 제작사가 눈치 챈 것인지 개인적으로 같은 도구를 무료 범위로 사용하고 있는데 이제는 계정 당 과금 뿐 아니라 워크스페이스 수에도 제한을 두고 있습니다. 그래서 더 적은 수의 계정을 사용하더라도 각 계정이 생성할 수 있는 워크스페이스 수에 제한이 있어 이전에 경험한 것처럼 단 몇 개의 유료 계정만을 사용해 프로젝트 전체를 지탱하는 방식으로는 사용할 수 없게 됐습니다. 하지만 과금은 서버 단위로 일어나기에 회사에서 서버를 최신 버전으로 업데이트 하지 않는 한 이전에 정립된 과금 규칙에 따라 계속해서 사용할 수 있습니다.

이런 상황을 파악한 우리들은 우리 스스로 회사에 새로운 소프트웨어를 구입해 달라고 요청하기 상당히 까다로운 입장이라는 사실을 인지합니다. 특히 어도비 제품군처럼 개발에 필수불가결하다는 사실을 누구라도 쉽게 인지할 수 있는 경우를 제외하고는 프로젝트 구성원들 전체에 걸쳐 광범위하게 사용되는 소프트웨어를 사용하겠다고 함부로 말할 수가 없었습니다. 가령 저는 아주 오래 전부터 인터페이스를 빠르게 설계하는데 발사믹 와이어프레임이라는 제품을 사용해 왔습니다. 사실 그 전에는 마이크로소프트 비지오를 사용했는데 그 시대에는 비슷한 소프트웨어가 비지오 같은 고가의 소프트웨어밖에 없었지만 어느 순간 비슷한 역할을 하는 훨씬 저렴한 소프트웨어가 잔뜩 나타났고 이제 비지오는 개인적인 용도로 8년 전에 구입한 다음 다시는 구입하지 않고 있고 또 회사에도 요구하지 않게 됩니다. 그런데 발사믹 와이어프레임은 어도비 제품군처럼 유명하지도 않았고 또 비슷한 역할을 하는 무료 소프트웨어가 널려 있는 것처럼 보였기 때문에 회사를 설득하기는 쉽지 않았습니다. 결국 제 능력을 최대한 발휘해 기안을 올리며 설명에 정말 눈물 없이는 볼 수 없는 간절한 설명을 남겼고 이 설명은 만약 이 기안을 읽는 당신이 이 가격이 높지도 않은 소프트웨어 구매 요청을 거절해 저에게 생산성 감소를 일으킨다면 당신은 정말 세상에 다시 없을 인간 쓰레기이며 회사의 역적이라는 말을 정중하게 서술한 것이었습니다. 이 글을 작성하는데 시급으로 계산할 때 상당한 비용을 소모한 다음에야 소프트웨어를 얻을 수 있었는데 회사는 아마 이런 낭비를 인지하지도 못했을 겁니다.

그래서 우리는 회사에 슬랙을 사 달라는 요청을 시도하기도 전에 포기합니다. 사실 이렇게 쉽게 포기할 수 있었던 이유 중에는 매터모스트라는 그럭저럭 잘 동작하는 것으로 알려진 얼터너티브가 있다는 사실을 알고 있었기 때문입니다. 그래서 최소한 완전 클래식하게 오직 이메일만 가지고 개발하는 최악의 상황을 모면할 수 있었습니다. 매터모스트는 나름 슬랙 얼터너티브 답게 슬랙의 기능을 거의 그대로 복제한 것처럼 보였는데 무료로 사용할 수 있는 대신 우리가 이 소프트웨어를 직접 호스팅 해야 했고 당시 우리는 보안 상 폐쇄망에서 개발을 수행했기 때문에 매터모스트를 호스팅하는 서버 역시 폐쇄망에 위치해야 했고 덕분에 이 소프트웨어가 슬랙과 비슷하게 여러 외부 API에 근거해 동작하는 자동화 기능에는 접근할 수 없었습니다. 이런 명백한 한계에도 불구하고 최소한 이메일 대신 팀 별로 마음 놓고 이야기할 수 있는 비공개 채널과 여러 개발 주제에 따라 이야기할 수 있는 여러 공개 채널을 운용할 수 있게 됐고 이들이 현대 슬랙처럼 온갖 기능을 자동화 해 주지는 못하지만 최소한 특정 글의 주소를 복사해 이곳 저곳에 붙여 넣어 언제든 바로 그 대화로 이동할 수 있게 됐고 또 이메일 앞부분과 뒷부분에 쓸 적당한 인사말을 생각하느라 시간을 낭비할 필요도 없어집니다. 다만 이 당시의 매터모스트는 명령어 기반의 자동화를 구축하기 위해 별도의 API나 코드를 삽입할 수 있는 대신 정규표현식을 사용해 명령어를 인식해야 했기 때문에 이런 요구사항에 기민하게 대처할 수는 없었고 다른 회사들이 슬랙에서 편안한 기능을 아무렇지도 않게 사용하는 것을 우리가 매터모스트 기반으로 흉내 내기 위해서는 온갖 아슬아슬한 묘기를 부려야만 했습니다.

이런 아쉬운 점을 제외하면 매터모스트는 이메일보다 훨씬 잘 동작했습니다. 특히 규모가 큰 사양을 개발할 때 이 주제에 해당하는 이야기를 하는 별도의 공개 채널을 운용할 수 있는 점이 가장 긴요했습니다. 규모가 큰 기능에는 프로젝트 구성원 전반에 걸친 다양한 사람들이 필요합니다. 이들 중 일부는 여러 기능에 걸쳐 겹치고 또 겹칠 수밖에 없지만 나머지는 기능의 규모에도 불구하고 여러 기능에 걸쳐 겹치지 않는 경우도 있었는데 이들이 자신이 관여하지 않는 채널에서 일어나는 모든 대화를 읽으며 시간과 정신력을 낭비할 필요는 별로 없었습니다. 하지만 좀 더 호기심이 많은 사람들은 자신이 직접 관여하지 않는 주제라도 채널이 공개되어 있기에 채널에 조용히 참여해 거기서 지나가는 말들을 조용히 살펴보다가 뭔가 자신이 기여할 수 있는 주제가 나타나면 슥 나타나 도움을 주기도 합니다. 이런 동작인 개인의 역량에 전적으로 의존하지만 만약 시스템이 이런 행동 자체를 허용하지 않는다면 개인이 역량을 펼칠 기회 자체가 오지 않을 겁니다. 만약 우리들이 이메일을 통해 의사소통 했다면 개인이 아무리 다른 파이프라인의 개발 상황을 알고 싶다 하더라도 이 의도를 편안하게 달성할 기회를 얻을 방법은 없거나 거의 없습니다.

어느 날 당시 프로젝트에 새 보스가 취임하면서 그 분이 이전 프로젝트에서 회사 차원으로 사용하던 그 동안 단 한번도 고려한 적 없는 회사의 업무용 메신저 소프트웨어를 회사에 제안해 프로젝트 전체가 새로운 업무용 메시징 시스템을 사용하게 됩니다. 이미 그 메신저 소프트웨어를 제작하는 회사에서는 일반 사용자들을 위한 메시징 소프트웨어를 서비스하고 있었기에 상대적으로 작은 사용자 규모에서 핵심 기능을 제공하는데는 아무런 문제가 없으리라 예상했고 예상은 거의 틀리지 않았습니다. 하지만 이 업무용 메시징 소프트웨어는 일반 사용자들을 대상으로 한 소프트웨어 인터페이스를 거의 그대로 가져와 사용 범위를 업무용으로 설정하고 이에 맞춰 소프트웨어의 일부를 튜닝한 제품처럼 보입니다. 이 메신저의 여러 가지 특징은 저를 당혹스럽게 만들었는데 가장 먼저 맞닥뜨린 특징은 이전에 사용하던 슬랙이나 매터모스트가 각자의 대화를 과거 IRC와 같이 왼쪽부터 오른쪽으로 읽어 나가면 되는 줄글의 나열로 표현하는 대신 모바일 기계에서 주로 사용되는 왼쪽에 다른 사람이 한 말이 풍선 모양으로 나타나고 오른쪽에 내가 한 말이 풍선 모양으로 나타나는 인터페이스를 사용하고 있었습니다. 일반 사용자들을 위한 메시징 앱에는 이런 모양이 더 친숙하게 느껴질 수도 있었지만 일단 이 좁은 화면 폭을 고려한 왼쪽과 오른쪽으로 각각 정렬된 말풍선을 보는 순간 이 앱이 과연 업무 환경에서 동작할 것을 얼마나 고려해서 개발되었을지 강한 의심을 가지게 만들었습니다. 다음으로 당혹스러웠던 점은 그 말풍선 안에 사용 가능한 텍스트 포멧이 극도로 제한적이라는 것입니다. 텍스트 자체에 굵게, 밑줄, 취소선 따위의 기초적인 포멧을 쓸 수는 있었지만 하다못해 블릿포인트조차 지원하지 않았습니다.

이 메시징 소프트웨어의 클라이맥스는 새 채널을 생성할 때 기본값이 비공개 채널로 설정된다는 점입니다. 이는 슬랙과 반대로 동작하는데 슬랙이 채널을 생성할 때 무지성으로 다음, 다음 버튼을 클릭하다 보면 공개 채널을 생성하게 되는 것과 완전히 다릅니다. 물론 선택에 따라 채널을 공개로도 비공개로도 생성할 수 있지만 이는 프로젝트가 정보를 다루는데 아주 근본적인 차이를 만들어냅니다. 앞서 매터모스트에서 여러 파이프라인에 걸쳐 서로 다른 채널에서 의사소통 하고 있지만 호기심이 있는 개인이 각 채널에 참여해 대화를 살펴보다가 자신이 개입할 시점을 찾을 수 있다는 이야기를 했는데 채널들이 기본적으로 비공개로 만들어지면 이런 가능성은 완전히 제거되며 과거 이메일을 사용한 의사소통과 별 다를 것이 없게 됩니다. 각 파이프라인 별 채널 뿐 아니라 온갖 목적으로 채널이 만들어지지만 이들 모두의 기본값이 비공개이기에 프로젝트 내에 정보가 메시징 소프트웨어를 통해 흐르기는 하지만 극도로 제한된 인원들에게 선택적으로 정보가 흐르며 정보가 더 넓은 범위의 사람들에게 자연스럽고 우연하게 전달되어 시너지를 일으킬 가능성을 완전히 차단합니다. 이런 상태가 계속되고 또 당연해지면 어떤 정보에 접근할 수 있는지에 따라 정보를 알고 있다는 사실 자체가 일종의 권력 모양으로 행사될 수 있습니다. 물론 이런 정보의 흐름을 통제하는 방법으로 자신의 존재 이유와 이에 따르는 권력을 유지하는데 관심이 있는 분들이라면 이런 특징이 너무나 반갑고 또 자연스러울 수 있지만 개인적으로 이런 특징은 프로젝트의 성공을 위하지는 않습니다.

앞서 팀즈 만든 놈들은 지옥에나 가라에 설명했지만 팀즈 이야기를 잠깐 하고 넘어가자면 팀즈는 아예 차원이 다른 문제점을 가지고 있습니다. 팀즈는 기존 여러 업무용 메신저들이 ‘채널’이라고 부르는 기능에 채팅 대신 일종의 ‘게시판’ 기능을 붙이고 실제 채팅은 별도의 ‘채팅’ 기능으로 정의했습니다. 이런 특징 때문에 기존 다른 업무용 메신저를 사용하던 습관에 따라 사람들은 ‘채널’을 생성했는데 채널은 그들이 상상한 채팅 기능이 아니라 게시판 기능이었기 때문에 사람들에게 큰 혼란을 일으킵니다. 이전에는 주제에 맞는 채널을 선택하고 할 말을 타이핑하고 바로 전송할 수 있었지만 채널에 뭔가를 이야기하려면 채널을 선택한 다음 새 글 버튼을 클릭하고 제목을 쓰고 내용을 쓴 다음 전송 버튼을 클릭해야만 말할 수 있었습니다. 자연스럽게 사람들은 채널에 뭔가를 말하기를 기피하기 시작했는데 이는 이메일을 통해 의사소통 할 때 쉽게 나타나던 현상과 전혀 다르지 않습니다. 이메일을 쓰느니 그냥 직접 말로 전달해버리는 쪽이 훨씬 편했고 이는 기록에 남지 않아 온갖 문제를 일으켰지만 사람들은 언제나 편안한 방식으로 행동하기 마련이며 이 행동 자체를 문제 삼으면 팀에 남길 사람이 아무도 없을 겁니다. 물론 채널 기능을 완전히 무시하고 채팅 기능만 사용하면 슬랙과 비슷하게 사용할 수 없지 않았지만 사람들은 채널이라는 이름의 게시판이 존재하는 이상 이를 사용하려고 시도했고 규모가 작은 문서들이 팀즈의 채널 기능으로 숨어 버리면서 우리들이 이전까지 사용해 온 정보시스템의 검색에 더 이상 나타나지 않는 상황이 벌어졌고 이 특징이야말로 제가 마이크로소프트 팀즈에 저주를 퍼부으며 욕하는 가장 큰 이유입니다.

최근 그런 저주스러운 마이크로소프트 팀즈를 뒤로 하고 슬랙을 사용하기 시작하면서 몇몇 답답한 문제가 꽤 완화되었습니다. 일단 이전에 비해 자동화가 압도적으로 편해졌습니다. 가령 마이크로소프트 팀즈에 어떤 자동화 기능을 만들기 위해서는 관리자가 마이크로소프트 애저 콘솔에 권한을 부여해야만 합니다. 하지만 일선 프로젝트나 일선 팀 입장에서는 도대체 그 관리자가 누구인지조차 알 수 없어 사실상 자동화를 편안하게 구축할 수가 없습니다. 하지만 슬랙은 워크스페이스에 참여한 각 개인들이 자신에게 부여된 권한 안에서 자유롭게 자동화를 구축할 수 있습니다. 이 과정에 누군가의 승인이 필요하지 않은데 이럴 수 있는 이유는 참여자 자기 자신에게 부여된 권한 범위 안에서만 동작하기 때문입니다. 사실 가장 큰 장점은 무지성으로 새 채널을 생성하면 기본적으로 채널이 공개로 설정되어 이전에 비해 공개 채널이 늘어났다는 점입니다. 저 자신도 여러 공개된 채널에 걸쳐 진행되는 여러 파이프라인에서 일어나는 일을 궁금해하는 사람 중 하나로 평소에는 제가 접근할 수 있는 프로젝트 위키에 올라오는 모든 페이지를 읽어 남들이 잘 모르는 정보를 알고 있다가 적당한 때 활용하는 것을 좋아합니다. 마찬가지로 슬랙에서도 제가 접근할 수 있는 여러 공개 채널에 걸쳐 조용히 상주하고 있다가 정보를 획득해 적당한 시점에 활용하거나 제가 개입해 상황을 개선할 수 있을 기회를 잡을 수도 있게 되었습니다.

하지만 불행하게도 모든 사용자들이 슬랙을 사용하면서 슬랙의 이런 특징을 잘 이해한 것은 아닌 것 같습니다. 이 글을 쓰는 오늘을 기준으로 10년 전 영상이라고 표시되는 "So Yeah, We Tried Slack …"이라는 영상은 슬랙이 처음 서비스를 시작할 즈음 만들어졌습니다. 슬랙이라는 업무용 메시징 소프트웨어를 통해 팀 전체가 메시지와 파일을 빠르게 주고 받아 정보를 공유하고 이에 따라 업무 생산성을 향상 시킬 수 있다는 내용으로 구성되어 있습니다. 10년이 지난 지금도 이 영상의 핵심은 변하지 않았다고 생각합니다. 업무용 메시징 소프트웨어를 사용하는 이유는 프로젝트 구성원 전체에 걸쳐 필요한 사람에게 더 빠르고 효율적으로 정보를 전달하는 것입니다. 물론 이 과정에서 원하지 않는 사람들에게 과도한 정보가 제공되어 오히려 노이즈로 작용하거나 정보가 전달되어서는 안되는 사람들에게 전달되어 도리어 문제가 일어날 가능성도 없지 않습니다. 하지만 이런 위험에도 불구하고 근본적으로 프로젝트 구성원 전체에 걸쳐 최대한 많은 정보가 자연스럽게 전달되는 상태를 유지할 때 앞서 여러 차례 설명한 우연한 기여의 기회가 나타나고 이런 기회들이 그냥 사라지지 않고 사람들의 참여를 이끌어낼 때 프로젝트가 성공할 가능성이 조금씩 증가한다고 생각합니다. 하지만 이런 근본적인 철학을 인지하지 않고 그저 또 다른 메시징 소프트웨어를 도입했다는 관점으로 슬랙을 바라보면 크게 두 가지 실수를 할 수 있습니다.

먼저 비공개 채널 생성을 통한 정보 전달에 제한을 만드는 것입니다. 어떤 사람들은 공개 채널에서 이야기하기를 아주 꺼리기도 합니다. 이전 DM과 심리적 안정감에 관련된 이야기를 했는데 DM을 통해 업무를 처리하면 이 정보가 널리 전파되지 않아 별도로 기록을 남기지 않을 때 문제를 일으킬 수 있습니다. 하지만 업무용 메시징 소프트웨어를 사용하는 근본적인 이유 중 하나는 이런 자잘한 메시징에 별도로 기록을 남기지 않기 위한 것도 있기에 DM으로 업무를 처리하는 것은 썩 올바른 접근은 아닙니다. 하지만 사람에 따라서는 공개된 채널에서 말하기를 꺼리기도 하는데 주로 자신이 틀린 말을 할 때 자신에게 돌아올 비난이나 책임 추궁을 두려워하는데서 나타나는 행동이라고 예상합니다. 이는 근본적으로 프로젝트 전체에 걸쳐 구성원들에게 안전한 환경을 만들 때 근본적으로 해결할 수 있습니다. 하지만 이는 이상적인 접근일 뿐 실제 상황에서 오랜 시간을 들여 이런 환경을 구축하기는 대단히 어려울 겁니다. 그래서 DM을 사용해선 안된다거나 DM을 통해 진행한 업무에는 반드시 별도 기록을 만들어야 하는 규칙을 만들어 대응하곤 하는데 이 정도가 적당한 타협점이라는 사실을 알지만 이런 정책이 잘 동작하지 않는다는 사실 역시 부정할 수 없습니다. 이런 상황에서 이전에 다른 업무용 메시징 소프트웨어를 사용하던 습관에 별다른 고민 없이 비공개 채널을 남발하면 사람들이 DM을 통해 업무를 진행하는 상황을 그냥 방치하는 것과 비슷한 효과를 가져옵니다. 프로젝트 워크스페이스에 온갖 다양한 파이프라인과 채널이 존재하지만 이들 모두가 비공개 채널로 숨겨지면 프로젝트 워크스페이스는 겉보기에 적막하고 활기 없는 곳으로 보이게 됩니다. 이는 마치 실컷 MMO 게임을 개발해 놓고 주요 컨텐츠를 모두 인스턴스 던전 안으로 분리해 플레이어는 많지만 이들 중 누구도 필드에 나타나지 않는 망한 모습으로 나타나는 것과 비슷합니다. 누가 그런 게임을 하고 싶어할까요? 누가 그런 프로젝트에 참여하고 싶어할까요?

또 다른 실수는 메시징 소프트웨어라는 슬랙의 본래 역할을 뛰어넘어 슬랙에 명시적으로 정보를 적재하려고 하는 행동입니다. 슬랙을 도입하는 조직 대부분이 이미 완전히 잘 동작하는 정보시스템을 갖추고 있을 겁니다. 만약 그렇지 않다면 그 프로젝트는 성공할 수 없으니 빨리 도망치는 편이 자신의 인생과 건강에 이롭다고 확실히 말할 수 있습니다. 슬랙은 처음부터 메시징 소프트웨어로 시작했기에 사용자들이 서로 메시지를 주고 받는 기능에 집중한 상태로 오랜 세월 동안 개발되어 왔습니다. 채널, 허들, 캔버스 모두 사용자들이 메시지를 주고 받는데 사용하는 기능이며 슬랙은 이 과정에서 오직 메시지를 전송하고 묵시적으로 이 기록을 유지하는 역할을 하면 우리가 이 서비스에 요구하는 역할을 충분히 수행하는 것입니다. 그런데 슬랙이 제공하는 캔버스 같은 기능을 오인하면 이를 마이크로소프트 팀즈가 그랬던 것처럼 채널이라는 이름의 게시판 기능과 같이 명시적인 정보 적재 기능으로 착각할 수 있습니다. 물론 그렇게도 사용할 여지가 없지 않으며 앞서 도망치라고 말한 슬랙 이외에 다른 정보시스템이 없는 프로젝트라면 그런 선택을 할 수도 있다고 생각합니다. 하지만 멀쩡히 동작하는 정보시스템이 존재하는 이상 슬랙은 오직 일시적인 정보 전달의 역할을 맡고 이 과정에서 묵시적으로 기록을 남기는 역할에 절대적으로 머물러야 합니다. 프로젝트 구성원들이 명시적으로 정보를 적재해 신뢰할 수 있는 곳으로 유지해야 하는 것은 슬랙이 아니라 그 이전부터 사용해 왔을 정보시스템입니다. 이런 특징을 생각하지 않은 채 슬랙이 모든 대화마다 퍼머링크를 부여하고 허들이나 캔버스에도 같은 기능을 제공하는 모습을 보고 이를 마이크로소프트 팀즈에 있던 저주받아 마땅한 채널 기능과 착각해 명시적인 정보 적재 기능으로 착각하는 순간 이전 마이크로소프트 팀즈를 사용할 때와 마찬가지로 우리들의 핵심 정보시스템으로부터 주요 정보를 제거하는 이상한 결과를 맞게 됩니다.

업무용이든 개인용이든 메시징 소프트웨어는 그 이름 그대로 일시적인 메시지를 전달하는 역할을 합니다. 메시지 전달에 의한 결과로 사람들은 어떤 행동을 하거나 행동에 영향을 끼칠텐데 이 시점에 메시징 소프트웨어의 역할은 끝납니다. 다만 정보기술이 발전하며 메시징 소프트웨어가 오래된 메시지를 충분히 많이 저장함에 따라 이전 시대에는 그냥 사라졌던 여러 기록이 미래에 검색을 통해 재발견되어 재활용될 여지가 생깁니다. 슬랙은 전통적인 IRC를 현대적으로 재해석하면서도 IRC의 여러 특징을 가져와 좀 더 개방적인 메시징 환경을 제안했고 이는 프로젝트의 성공 가능성을 올리는 여러 역할을 할 가능성이 있습니다. 이런 특징에 대한 이해 없이 그저 익숙한 잘못된 업무 습관을 그대로 반영하려 한다면 앞서 설명한 개인용 메시징 소프트웨어를 거의 그대로 업무용으로 전환한 어처구니 없는 메시징 소프트웨어에 아무런 문제의식을 못 느끼거나 마이크로소프트 팀즈가 채널 기능을 통해 그 스스로가 정보를 모두로부터 제거해 버리는 행동을 하고 있음에도 문제의식을 못 느끼고 또 슬랙을 사용하면서도 비공개 채널을 남발하고 일시적인 메시지 전달 보조 수단은 캔버스를 명시적인 정보 적재 수단으로 착각할 수 있습니다. 안타깝지만 업무용 메시징 소프트웨어를 선택하는 사람들조차도 이런 차이나 필요성을 인지하지 못한 채 소프트웨어를 선택하고 또 올바르지 않은 방법으로 운용하는 것 같아 보입니다.

슬랙이라는 업무용 메시징 소프트웨어의 설계 철학은 더 오래된 IRC로부터 시작된 공개 채널을 통한 정보 전파, 여러 채널에 상주하는 호기심이 있는 개인이 자신이 참여할 기회를 더 많이 얻는 것, 약간의 위험에도 불구하고 대외비 수준의 비밀은 프로젝트 수준에 자연스럽게 전파되어 이 정보를 모르고 있을 때 일어날 수 있는 비효율을 최소화하는 것에 있습니다. 이 과정에서 일어난 모든 기록은 묵시적으로 유지되어 미래에 검색을 통해 재발견 되어 재활용 될 수 있지만 이런 활용은 부가적인 것으로 업무용 메시징 소프트웨어의 기본적인 사용 시나리오라고 말하기는 어렵습니다. 특히 마이크로소프트 팀즈가 채널 기능으로 수많은 사람들을 헛갈리게 만들어 저주 받아 마땅한 생산성의 저하를 겪게 만드는 모습을 보고도 아무런 문제의식을 가지지 못한다면 일시적인 의사소통을 돕기 위한 캔버스 같은 기능을 보고 명시적인 정보 적재 기능이라고 착각할 여지가 없지는 않습니다. 하지만 기왕 비싼 돈 내고 슬랙을 사용한다면 이 도구의 근본적인 철학을 생각해보고 지불한 돈에 비해 더 큰 효용을 얻을 수 있도록 노력해야 합니다.