DM이 하나뿐인 안전한 의사소통 창구일 때 이를 막을 수 없다

지금에 와서 생각해보면 대체 어떻게 그런 식으로 일했는지 상상하기 어렵습니다. 분명 저 자신이 그런 방식으로 일해본 적이 있고 또 그런 방식으로 일을 진행 시켜 개발을 수행하고 또 프로젝트를 런칭한 경험이 있는데도 말입니다. 현대에 슬랙이나 팀즈 같은 본격적인 메시징 소프트웨어가 없던 시대에는 개인용 메신저나 메일을 사용해 다른 사람들과 이야기하며 일을 진행했습니다. 첫 회사에서는 아예 버전 관리 소프트웨어를 사용하지 않고 각자가 수정한 최신 파일을 네트워크 상에 있는 공유디렉토리에 올리고 있었습니다. 문서는 마이크로소프트 워드로 작성했고 그 시대나 지금이나 데이터는 엑셀을 사용했습니다. 사실 이 상태만 놓고 보면 크게 이상하지는 않았습니다. 매일 자정에 백업 소프트웨어가 공유디렉토리 전체를 백업했지만 뭔가 심각한 문제가 생겨 그 백업의 도움을 받을 일은 없었고 누군가 데이터를 잘못 수정해 문제를 일으키면 오동작이나 메러 메시지를 확인한 다음 문제를 수정해 나갔습니다. 문서를 작성하고 나면 이 문서를 읽어야 할 것 같은 사람들을 수신자에 잔뜩 집어넣고 메일을 보냈는데 윈도우에서 \문자로 시작하는 공유디렉토리 경로를 바로 클릭할 수 있도록 링크를 만드는데 좀 제한이 있어 메일을 받은 사람들이 문서를 읽지 않는 문제가 자주 일어났으므로 공유디렉토리에 있던 파일을 메일에 첨부했습니다. 그렇게 일했습니다.

한동안 다른 사용자들과의 연결 관계를 클라이언트에만 저장했던 정신 나간 인스턴트 메신저가 세계를 지배했지만 어느 순간 똑같은 동작을 서버에 기반해 동작하는 좀 더 현대적인 인스턴트 메신저가 나타났습니다. 이런 소프트웨어를 개인적으로도 사용했지만 회사에서도 이를 사용하기 시작했습니다. 그래서 메신저에 있는 사람들 목록에 닉네임을 쓰고 있으면 이 사람은 아마도 회사에서 이 메신저를 사용하고 있지 않을 가능성이 높았고 자기 이름을 쓰고 있는 사람은 이 메신저를 개인용 뿐 아니라 업무용으로 사용하고 있을 가능성이 높았습니다. 저 역시 그랬습니다. 지금은 사라진 마이크로소프트에서 만든 메신저에 이름과 소속 부서를 표시한 채 회사로부터 오는 메시지에도 응답하고 개인적으로 오는 메시지에도 응답했습니다. 메일에 비해 접근성이 압도적으로 뛰어났기에 메신저는 순식간에 개발을 수행하는데 중요한 위치를 차지했습니다. 서로 같은 층에서 일하고는 있었지만 아주 멀리 떨어져 있을 때 서로 자리에 있는지조차 알기 쉽지 않을 때가 있습니다. 그럴 때 괜히 자리에 찾아갔다가 자리를 비운 상태이면 몇 분을 낭비하고 그냥 돌아와야만 했습니다. 하지만 메신저로 미리 자리에 있느냐고 물어보면 아주 빨리 약속을 잡을 수도 있었고 또 아주 간단한 요청을 메일을 통해 보내느라 받는 사람을 넣고 인사말을 쓰고 본문을 쓰는 귀찮은 짓을 할 필요도 없었습니다. 그냥 원하는 사람 이름을 더블클릭해서 창을 하나 열고 거기 그냥 메시지를 타이핑 하면 됐습니다. 여전히 인사말로 시작하는 사람들도 있었지만 감사하게도 즉시 용건부터 시작하는 사람들도 있어 일이 편했습니다.

인스턴트 메신저가 일하는 사람들에게 얼마나 깊이 자리잡았나 하면 한 회사에서 정리해고를 시작하기 전 맨 먼저 한 행동은 메신저를 차단하는 것이었습니다. 어느 날 아침 출근해보니 메신저가 영원히 로그인 되지 않고 있었습니다. 처음에는 일시적인 문제라고 생각했고 또 저 한 사람에게만 일어난 문제라고 여겼습니다만, 사람들이 하나 둘 출근하면서 모든 사람들이 똑같은 문제를 겪고 있다는 사실을 알게 되었습니다. 우리들은 회사에 있는 다른 부서 사람들과도 메신저를 통해 정보를 주고 받고 있었지만 서로 직접 연락할 연락처를 가지고 있지는 않았습니다. 그래서 우리들은 순식간에 회사의 다른 부서와 정보를 주고 받을 수 없게 되었고 회사는 무사히 정리해고를 수행했습니다. 그런데 해고가 어느 정도 마무리된 다음에도 여전히 메신저를 사용할 수 없었는데 이는 의도적인 것인지 아니면 일단 계획 대로 차단했지만 이후 이 사실이 회사에서 잊혀져 차단을 해제하는 일을 빠뜨린 것인지는 알 수 없었습니다. 한동안 메일을 사용해 일하려고 했지만 이미 메신저가 얼마나 편리한지 알게 된 사람들은 메일로만 일하는 상태가 얼마나 비효율적인지 알고 있었습니다. 저 자신도 너무나 불편했기 때문에 회사 밖에 프록시 서버를 만들고 메신저 설정을 프록시 서버를 가리키도록 해 회사의 차단에도 불구하고 메신저를 사용할 수 있도록 만들었습니다. 아마 현대라면 AWS 같은 서비스가 있으니 훨씬 편안하게 같은 행동을 할 수 있겠지만 그 시대에 회사 바깥의 고정된 장소에 프록시 서버를 만들기는 쉽지 않았습니다.

한편 인스턴트 메신저가 여러 사람들에게 본격적으로 퍼져 자리 잡기 이전에 우리들은 이미 IRC라는 프로그램, 프로토콜을 통해 다른 여러 사람들과 모여 이야기하는 환경에 익숙해져 있었습니다. 다른 사람과 일대일로 대화하는 인스턴트 메신저는 훨씬 나중에 나타났는데 이미 그 이전 부터 여러 사람들이 같은 채팅방에 모여 이야기할 때 정보가 사람들에게 아주 빨리 퍼지고 여러 사람들로부터 피드백을 순식간에 받을 수 있다는 사실 역시 알고 있었습니다. 온라인 게임에도 채팅 기능이 있었지만 대체로 이 기능들은 여러 모로 불완전했습니다. 인터페이스는 한 박자씩 느리게 움직였고 많은 텍스트를 입력할 수도 없었으며 복사, 붙여넣기에 제약이 있을 때도 있었습니다. 그래서 게임에 내장된 바보같은 채팅 기능을 사용하는 대신 함께 플레이 하는 사람들이 IRC에 채널을 만들어 대화했고 이전에 비해 엄청나게 편안하게 게임을 플레이하며 서로 이야기를 주고 받을 수 있었습니다. 사실 이메일을 사용해 일하다가 인스턴트 메신저를 사용하기 시작할 때 느꼈던 편리함과 이로 인한 가능성을 이미 IRC를 사용해 함께 게임하는 사람들과 이야기하며 어느 정도 알고 있었다고 볼 수도 있었을 것 같습니다.

한 회사에서는 보안을 위해 네트워크를 논리적으로 분리해 인터넷에 접근할 수 있는 외부망과 인터넷과 분리되어 있는 내부망을 운용했고 핵심 개발은 내부망에서만 수행할 수 있었습니다. 외부망에서는 인터넷, 회사 인트라넷, 메일, 인스턴트 메신저 따위를 사용할 수 있었습니다. 하지만 프로젝트에 관련된 그 어떤 에셋에도 접근할 수 없었습니다. 반면 내부망은 인터넷으로부터 분리되어 있었지만 컨플루언스 위키, 퍼포스 따위에 접근할 수 있었지만 인스턴트 메신저 같은 것은 꿈도 꿀 수 없었습니다. 인스턴트 메신저 실행파일을 외부망으로부터 반입해 설치한다 하더라도 인터넷에 접근할 수 없는 이상 사용은 불가능했습니다. 회사 역시 내부망의 의사소통이 필요하다는 사실을 아예 무시하지는 않았습니다. 회사는 내부망에 내부망 전용 이메일 주소를 부여하고 이메일을 통해 의사소통 하게 했는데 이미 다른 회사의 이전 프로젝트에서 인스턴트 메신저를 사용해 일하는 편리함에 익숙해져 있다가 다시 몇 년을 회귀해 이메일만 사용하는 개발 환경에 익숙해지기는 쉽지 않았습니다. 하지만 사용 가능한 방법은 이메일 밖에 없었고 이전에 비해 압도적으로 모든 것이 느리게 진행되는 환경에 다른 사람들과 똑같이 익숙해져야만 했습니다. 만약 제가 어떤 데이터를 변경할 작정인데 이 변경이 여러 사람들의 테스트 시나리오와 업무에 영향을 끼칠 거라고 예상된다고 해봅시다. 저는 데이터를 수정하고 퍼포스에 서브밋 하기 전 이 작업에 의해 영향을 받을 것으로 추정되는 사람들을 수신자로 하는 이메일을 작성해 보내야만 합니다. 만약 제가 예상한 수신자보다 더 많은 사람들이 이 변경으로부터 영향을 받는다 하더라도 그 사람들은 이 정보를 바로 획득할 수 없었습니다. 물론 이런 문제를 완화하기 위해 파트, 팀, 실, 프로젝트 전체를 가리키는 그룹 주소가 있었습니다. 수신자를 충분히 넓게 지정하지 않아 여러 가지 문제를 겪은 다음 사람들은 아무렇지도 않게 간단한 메일에도 수신자가 백 명이 넘는 그룹 주소를 항상 넣기 시작했고 하루에 수 백 통의 메일을 받았지만 그 중 실제로 의미 있는 메일은 한 자리 수에 불과했습니다.

내부망에서 오직 메일을 통해 일하기 너무 불편했던 나머지 한 가지 방법을 시도해 보았습니다. 외부망에서 IRC 서버 소프트웨어와 클라이언트를 반입한 다음 내부망의 아무 컴퓨터에나 IRC 서버를 만들고 이 서버를 가리키도록 설정한 클라이언트를 사용해 채팅을 시도하는 것입니다. 설정이 아주 쉽지는 않아 여러 사람에게 배포하는데 시간이 걸리기는 했지만 이윽고 여러 사람들이 한 채팅방에 모여 이야기하기 시작했습니다. 이들은 평소 메일을 통해 업무적인 대화만을 해야만 하는데 갑갑함을 느끼고 있었던 것 같아 보입니다. 이들은 서로 편안하게 실시간으로 대화하게 되자마자 바로 오늘 점심에 뭘 먹을 지 이야기하기 시작했고 이런 이야기와 업무 대화가 마구 섞여 지나갔습니다. 채팅은 아주 빠르게 스크롤 되었지만 정확한 사람을 멘션하면 그 사람에게 알림이 가도록 할 수 있었기에 메일을 통해 메시지를 주고 받을 때보다 훨씬 빠르게 일이 진행되었습니다. 사람들이 업무에 직접적으로 연관되지는 않았지만 개인적인 관심사나 오늘 겪은 일 따위를 이야기하며 사람들이 채팅에 관심을 가지게 된 것은 덤입니다. 하지만 이 체계는 고작 며칠도 유지되지 못했습니다. 회사 보안 부서는 내부망에서 어떤 컴퓨터 한 대에 여러 컴퓨터가 요청을 보내고 받는 모습을 수상하게 생각했고 이게 무슨 일인지 파악하기 시작했습니다. 그리고 IRC 서버와 소프트웨어를 통해 인가 받지 않은 방식으로 파일을 주고 받을 수 있다는 이유를 들어 IRC 트래픽을 차단했고 우리는 단 며칠 만에 다시 회사가 내부망에서 인가한 파일 전송이 가능한 방법 중 하나인 메일로 돌아와야만 했습니다. 업무 진행 속도는 다시 느려졌고 더 빨리 일할 수 있었지만 회사가 속도를 제한하고 있었으므로 어쩔 수 없이 받아들일 수밖에 없었습니다.

다음 회사에서는 인터넷에 직접 연결된 기계로 개발한 덕분에 이전에 비해 훨씬 편안하게 일할 수 있었습니다. 같은 컴퓨터로 검색하고 검색 결과를 복사해 바로 문서나 코드에 붙여 넣을 수도 있었습니다. 이전에는 인터넷에 접근할 수 있는 외부망 컴퓨터에서 코드를 가져오려면 이를 텍스트 파일로 저장한 다음 회사가 인가한 전송 방식에 따라 전송하고 이 전송 요청이 승인된 다음 내부망 기계로부터 이를 가져오거나 이 과정이 귀찮으면 한 쪽 모니터에 띄워 놓고 다른 쪽 모니터를 보며 직접 타이핑 하기도 했습니다. 보안이 중요하다는 사실을 인정하지만 이런 수준의 비효율을 감수할 일인가 싶었습니다. 그런 세계에서 살다가 검색 결과를 바로 복사해 프로젝트에 붙여 넣을 수 있기만 해도 갑자기 새로운 세상이 열리고 효율이 급격하게 향상되는 느낌이 들었습니다. 느낌이 아니라 실제로 그랬습니다. 그 팀에서는 자체적으로 개발한 IRC와 비슷한 채팅 프로그램을 사용했는데 이 프로그램 역시 주제 별로 여러 채널을 만들고 각 주제에 관심이 있거나 각 주제의 정보를 계속해서 따라 잡아야 하는 사람들이 한 채팅방에 잔뜩 모여 대화에 참여할 수 있었습니다. 다만 이 프로그램을 처음 개발했던 사람들과 그들의 부서가 이미 사라진 다음이어서 프로그램은 유지보수 되지 않은 채 아슬아슬하게 동작하고 있었습니다. 지금 돌아보면 모르긴 몰라도 보안 문제를 수없이 가지고 있었을 겁니다. 심지어 그런 프로그램이 장기간 유지보수 되지 않은 채 인터넷에 연결된 기계에서 동작하고 있었으니 편리하기는 했지만 보안 상 안전하지는 않았을 겁니다. 그러다가 그 프로젝트가 드랍 되면서 다른 채팅 프로그램을 알아보기 시작했는데 그 때 처음으로 슬랙을 도입했습니다. 드디어 서비스 수준에서 여러 가지 방법으로 자동화를 제공하는 현대적인 채팅 프로그램을 업무에 사용할 수 있게 된 겁니다. 당장 적극적으로 여러 가지 자동화 기능을 만들었고 슬랙은 순식간에 메일을 대체했을 뿐 아니라 여러 사람의 회사에서 일상을 편안하게 바꿔 주었습니다. 물론 회사는 그 댓가로 상당한 비용을 지출해야만 했지만요.

메일과 비교해 슬랙이 가지는 아주 근본적인 차이는 슬랙이라는 메신저의 설계 철학에서 언급한 적 있는 동시에 메시지가 도달해야 하는 다수에게 한 번에 메시지를 보낼 수 있다는 점입니다. 메일을 사용한다면 이 메시지를 전달 받아야 할 사람을 메일을 보낼 사람이 임의로 선택해야 했습니다. 너무 적은 사람들에게 보내면 충분히 많은 사람들에게 정보가 전달되지 않을 수 있었지만 반대로 너무 많은 사람들에게 보내면 여러 사람들이 메일이 도착한 즉시 삭제해 버리는 습관을 만드는데 일조할 가능성이 높았습니다. 하지만 슬랙을 사용하기 시작하면서 주제 별 채널이 생겼고 이 채널에 상주하며 채팅을 따라잡을지 그렇지 않을지를 결정하는 것은 개개인의 선택이 되었습니다. 또 어떤 주제에 관여하기 시작할 때 채널에 입장해 메시지를 받으며 일하다가 이 주제에 더 이상 관여하지 않게 되면 정보량을 조절하기 위해 채널에서 나가는 선택을 할 수도 있었습니다. 특히 여러 주제에 일시적으로 관여하는 사람들이 상시 너무 많은 채널로부터 메시지를 받아 오히려 업무에 방해를 받는 상황을 스스로 통제할 수 있었습니다. 이렇게 채널을 통한 선택적 메시지 수신을 통한 정보량 조절은 메시지를 작성하는 사람에게는 이 메시지가 전달되어야 하는 사람들을 임의로 선택할 필요가 없게 만들었고 메시지를 받는 사람 역시 메시지 수신 여부를 채널 단위로 선택할 수 있었기에 서로 이전에 비해 훨씬 적은 고민 만으로 여러 사람들에게 편안하게 메시지를 보낼 수 있게 되었습니다. 한동안 메일은 좀 더 중요한 공지사항 따위를 전달하는 용도로 사용되었지만 어느 순간 개발팀 내에서는 더 이상 메일을 사용하지 않게 되었습니다.

하지만 모든 사람들이 이런 방식으로 메시지를 주고 받는 것을 편안하게 생각하지는 않았습니다. 메일을 사용할 때는 수신자를 직접 선택할 수 있었기에 훨씬 적은 사람들을 대상으로만 메시지를 보낼 수 있었습니다. 또 인스턴트 메신저를 사용할 때는 상대방 한 명을 지정해 그 사람에게만 메시지를 보낼 수 있었습니다. 이런 정보 전달 방식은 프로젝트 전체적인 관점에서는 그리 효율적이지 않다고 생각할 수 있지만 메시지를 주고 받는 개개인 관점에서는 약간은 사적인 요청을 할 수 있게 만들었습니다. 가령 제가 작업하다가 어떤 문제에 부딪쳤고 제 스스로 문제를 해결할 수 없다고 판단했다 칩시다. 저는 인스턴트 메신저를 통해 저를 도와줄 수 있을 것 같은 누군가에게 제 약점을 드러내고 제 문제를 해결하는데 도움을 달라고 요청할 수 있습니다. 이 대화는 저와 그 상대 사이에만 오가기 때문에 이 과정은 심리적으로 안전하게 진행할 수 있습니다. 하지만 같은 상황에서 여러 사람들이 모여 있는 슬랙 채널에 이 문제를 말하면 여러 사람들의 도움을 조금씩 받아 문제를 더 빨리 해결할 수 있을지도 모르지만 동시에 제 약점이 모든 사람들에게 노출되는 결과로 이어지기도 합니다. 때문에 슬랙을 도입하고 여러 대화가 채널을 통해 많은 사람들에게 실시간으로 전달되기 시작한 다음에도 이전 인스턴트 메신저의 사용 습관과 똑같은 DM을 통한 메시지 교환이 여전히 일어났습니다. 이 개인적인 대화를 통해 분명 여러 가지 문제가 해결되었겠지만 다른 사람들은 업무 진행상황을 전달 받을 수 없었기에 메일을 사용할 때와 비슷하게 누군가는 진행상황을 알고 이에 대응하며 일하지만 누군가는 이 진행을 전혀 전달 받지 못해 문제를 겪었습니다. 이 주제는 전 세계적으로 비슷한 상황을 겪은 여러 팀에 속한 수많은 사람들의 고민거리였고 프로젝트 차원에서 DM 사용을 지양하는 정책을 수립해 실행하고 교육하고 또 가이드 하는 식으로 정리되어 가고 있었습니다.

저 자신은 멍청하면서도 뻔뻔하기에 저 자신이 뭘 모른다면 그 문제를 최대한 빨리 해결해야 한다고 생각했습니다. 그래서 어떤 문제를 겪거나 일하는 도중 어떤 정보를 모른다면 편안하게, 그리고 뻔뻔하게 여러 사람들이 모인 채널에 대고 그냥 제가 모르는 것을 물어봤습니다. 또 제가 문서를 업데이트 하면 이 사실을 여러 사람들이 모인 채널에 말하고 링크를 걸고 수정 요약을 함께 붙여 넣었습니다. 이 과정에서 저는 제가 모르는 정보를 다른 사람들의 도움을 받아 바로 알 수 있었고 또 제가 문서를 작성할 때, 데이터를 수정할 때 저지른 실수를 순식간에 수정할 수 있었습니다. 만약 제가 채널에 직접 말하지 않았다면 제 실수는 나중에 다른 사람들이 문제를 겪은 다음에야 문제가 일어났다는 사실을 깨달을 수 있었을지도 모릅니다. 하지만 쪽팔림은 잠깐일 뿐 이로 인한 장점이 더 크다고 생각했습니다. 그래서 제 스스로 멍청한 소리를 할 가능성이 높음을 알았지만 뻔뻔하게도 그냥 채널에 제 상황을 말했습니다. 하지만 모든 사람들이 저와 같은 판단을 하지는 않았고 또 이를 강요할 수도 없었습니다. 사실 한동안 저는 DM 사용을 지양하는 캠페인이 진행되는 동안 DM으로 말을 걸어오는 분들과 이야기를 시작한 다음 이 이야기를 이어서 어느 채널에서 하자며 채널 링크를 보내 이야기를 채널에서 이어 하도록 가이드 하곤 했습니다. 한동안 이런 행동이 프로젝트 전체적으로 이익을 가져올 거라고 생각했고 이 생각이 아주 틀리지는 않았다고 생각합니다. 하지만 시간이 지나며 DM과 심리적 안정감에 대해 생각하기 시작했고 DM으로 말을 걸어 오는 분들을 무작정 채널로 끌어내는 행동이 자칫 폭력적일 수 있다는 사실을 깨달았습니다. 이 다음부터 DM으로 말을 걸어온 분을 굳이 채널로 끌어내지 않았습니다. 다만 이야기를 마친 다음 제가 회의록을 작성해 공유하는 수준에서 타협했습니다. 그동안의 제 행동이 자칫 폭력적일 수 있고 이 행동에 의해 더더욱 심리적으로 위축되는 구성원이 생길지도 모르는 위험한 행동을 계속해서는 안된다고 생각했습니다.

여전히 장기적으로는 DM 사용을 지양해야 한다고 생각합니다. 다만 프로젝트에 참여한 여러 사람들의 성향이 다르고 각자가 처한 입장과 이에 근거한 심리적 안정감은 모두가 다를 수밖에 없습니다. 이들을 DM으로부터 벗어나게 만들어 채널에서 이야기하도록 하려면 DM을 사용해서는 안된다는 캠페인도 필요하지만 동시에 프로젝트 전체에 걸친 심리적 안정감을 구축하는 것이 더 중요하고 또 더 유효하다고 생각합니다. 이들이 결코 채널에 말하는 것이 더 효율적이고 또 더 빨리 문제를 해결하는 방법이라는 사실을 몰라서 DM을 통해 말하는 것이 아닙니다. 누군가에게는 채널에서 말하는 행동이 안전하다고 느껴지겠지만 또 다른 누군가에게는 그렇지 않을 수 있습니다. 내 작은 실수가 순식간에 수 십 명에게 까발려지는 상황을 견디기 어려워하는 사람들도 분명히 있을 수 있습니다. 그래서 DM 사용을 지양하는 캠페인, 금지하는 정책은 겉보기에는 뭔가 의미 있는 행동을 하고 있는 것처럼 보이겠지만 DM을 사용하기로 마음 먹은 사람들에게 안전한 느낌을 결코 주지 않습니다. 결과적으로 DM 사용은 줄어들지 않고 이로 인해 발생하는 문제는 여전히 일어납니다. 이쯤 되면 사실 DM을 사용하지 말라는 캠페인이나 정책은 그 원인에 접근하지 않기에 사실상 효과가 없다고 생각하게 되었습니다.

어떤 프로젝트에 참여할 때는 도리여 DM 사용을 장려하고 저 자신도 DM을 적극적으로 활용하게 된 적이 있습니다. 관리자들은 슬랙의 각 채널을 그들이 설정한 규칙에 따라 생성한 다음 철저한 규칙에 따라 운용했습니다. 어떤 말을 하려면 정해진 규칙에 따라 정확한 채널의 정확한 스레드에 이어서 말해야만 했습니다. 또한 어떤 채널에 말할 때는 미래의 검색을 위해 말에 키워드를 대괄호에 감싸 함께 말해야만 했습니다. 관리자 관점에서 이런 정책은 사람들의 대화가 유실되지 않고 효과적으로 연결되게 만들 뿐 아니라 관리자들 스스로가 수많은 채널에 흘러가는 정보를 훨씬 더 효율적으로 파악할 수 있는 방법이라고 생각했을 겁니다. 모든 사람들이 이 규칙을 철저히 지키기만 한다면요. 예상하셨겠지만 이 규칙은 적어도 겉으로 보기에는 잘 동작하는 것처럼 보였습니다. 하지만 그렇게 겉으로는 잘 드러나지 않는 현상이 일어났는데 바로 슬랙 전체에 걸쳐 사람들이 하는 말이 급격하게 감소했다는 점입니다. 처음에는 제가 참여한 채널에만 사람들이 아무 말도 하지 않는다고 생각했습니다. 하지만 여러 공개 채널들을 여러 차례에 걸쳐 살펴본 다음 말 한 마디를 하기 위해 복잡한 규칙을 정확히 지켜야만 하는 상황 속에 사람들은 그냥 아무 말도 하지 않는 것으로 규칙을 어길 때 받는 블레임을 피하기 시작했다는 사실을 깨달았습니다. 실은 그렇게 여러 채널을 둘러보기 이전에 저 자신이 그렇게 행동하고 있었습니다. 이전에 다른 프로젝트에서는 회의록을 작성하면 항상 이 회의록을 봐야 할 것 같은 사람들이 모인 슬랙 채널에 회의록과 요약을 공유하곤 했지만 이제 이 메시지를 어느 채널의 어느 스레드에 말해야 할 지 판단해야만 했고 그런데 시간을 쓰느니 어차피 회의록은 작성했고 컨플루언스를 열심히 살펴보는 누군가는 알아서 읽겠거니 하고 아무 조치도 취하지 않았습니다. 당연하지만 회의록은 그 누구에게도 읽히지 않을 때가 대부분이었습니다. 저는 아무도 읽지 않는 문서를 작성하는데 시간을 낭비하게 되었습니다.

그리고 사람들은 이전보다 훨씬 더 많이 DM으로 말하기 시작했습니다. DM으로 말하는데는 아무런 제한이 없습니다. 정확한 키워드들을 대괄호에 묶어 말할 필요도 없고 정확한 위치에 말할 필요도 없습니다. 그냥 말하고 싶은 사람을 골라 말을 시작하면 됩니다. 놀랍게도 현대의 검색 기술은 극격하게 발전해 굳이 대화에 미래에 검색을 위해 키워드를 나열하지 않아도 상관없었습니다. 오히려 잘못된 키워드 나열이 검색에 노이즈를 일으킬 때가 더 많았습니다. 만약 과거의 저였다면 DM으로 이야기하기 전에 이 이야기를 특정 채널에서 이어 하자ㄷ고 가이드하고 채널로 옮겨 이야기를 계속했을 겁니다. 하지만 저 역시 더 이상 그러지 않았습니다. DM 밖에 이야기하려면 생각해야 할 것이 너무 많았습니다. 아주 정교한 규칙에 따라 정확한 채널에 말하지 않으면 관리자에 의해 메시지는 삭제되었고 그 밑에 달린 스레드만 덩그러니 남았습니다. 올바른 키워드를 포함하지 않은 메시지에는 키워드를 포함해야 한다는 가이드 메시지가 항상 따라 붙었고 그런 꼴을 겪고 싶지 않았습니다. 그래서 저 자신도 적극적으로 DM을 사용하기 시작했습니다. DM은 관리자들이 볼 수가 없었고 또 관리자들이 강제로 DM을 금지할 수도 없었습니다. 모든 공개 채널에 걸쳐 대화는 급격히 감소하다 못해 거의 정지하다시피 했습니다. 한 주 내내 여러 업무 채널에 걸쳐 아무 이야기도 하지 않았습니다. 그렇다고 개발이 멈춘 것은 아닙니다. 마치 이전에 인터넷이 안 되는 내부망에서 오직 내부망 전용 메일을 통해 일하던 것과 비슷합니다. 모두가 각자 어떻게든 자신이 편안하고 또 안전하다고 여기는 범위 안에서 저마다의 방법으로 메시지를 주고 받고 있습니다. 공개 채널에 말하는 행동은 편안하지도 않고 또 심리적으로 안전하지도 않습니다. 저 자신도 그 상황에 동의했기에 저 역시 공개 채널에는 아무 말도 하지 않고 DM으로 숨어들었습니다. 대화는 훨씬 편안해졌습니다. 비록 같은 말을 여러 사람에게 반복해야만 했고 문서는 잘 전달되지 않곤 했지만 이 상황을 만든 관리자들의 책임이라고 생각하기로 했습니다.

사실 이 상태를 만든 정책에 저항하지 않은 것은 아니었습니다. 정책이 실행되기 전 정책이 텍스트로 공유되었을 때 정책이 실행되는 모습을 상상하기 시작한지 1초 만에 이 정책은 반드시 실패하거나 개발 효율을 급격하게 떨어뜨릴 거라고 예상했습니다. 그리고 어떻게든 정책의 시행을 막으려고 해봤습니다. 조직도 상 제 위에 있는 여러 관리자들에게 경고했습니다. 또 정책이 시행되어 공개 채널에 대화가 뚝 끊어진 다음에는 그럼에도 불구하고 가끔은 의도적으로 규칙을 어기며 사람들에게 정보를 전달했습니다. 하지만 이런 행동은 강력한 블레임 대상이 될 뿐이었습니다. 당장 아무도 공개 채널에 말하지 않는 상황 속에서도 이를 문제라고 생각하는 관리자는 거의 없거나 없었고 여러 차례의 면담과 술자리를 거친 끝에 어느 술자리에서 “우진님은 무슨 치외법권이에요?” 라는 말을 듣고 명백히 잘못된 정책에 저항할 동력을 완전히 잃어버렸습니다. 그 날로 저는 그저 공개 채널에 말하지 않고 DM으로만 일하는 다른 모든 사람들 사이로 조용히 사라지기로 결정했습니다. 그 후 저는 더이상 불행을 겪지 않았습니다. 복잡한 규칙을 지키며 정확한 장소에 정확한 방법으로 말하는 대신 다른 사람들과 똑같이 편안한 방법으로 편안하게 이야기하는 것이 훨씬 더 편했고 훨씬 더 효율적이었을 뿐 아니라 실제 개발을 진행시키는 거의 유일한 방법이었기 때문입니다.

이제 시간이 지나 그 프로젝트가 어떻게 되었을지 모르겠습니다. 모르긴 몰라도 과거 인터넷에 접근할 수 없는 내부망에서 오직 내부망 전용 메일 만을 사용해 의사소통 하게 만든 그 회사의 프로젝트들, 그리고 그 회사와 비슷한 운명을 맞이하게 되지 않을지 조심스럽게 상상해 봅니다. 다른 한편으로는 그 프로젝트에서 DM 사용을 지양하는 캠페인을 하고 여러 부서의 회의록에 걸쳐 DM 사용을 사실상 금지한다는 메시지가 매번 반복됨에도 왜 DM 사용이 결코 줄어들지 않는지 근본적인 원인을 깨닫지 못하는 한 DM 사용을 막을 방법은 없으며 제목의 주장과 같이 ‘DM이 하나뿐인 안전한 의사소통 창구일 때 이를 막을 수 없다’고 생각합니다. 그리고 만약 어떤 방법으로든 이런 상황에서, 그러니까 심리적으로 안정감을 주지 못하는 상황, 복잡한 규칙, 규칙에 벗어날 때 가해지는 직간접적인 처벌이 공존하는 한 DM으로 숨어드는 사람들을 막을 수도 없고 또 이들을 비난할 수도 없으며 DM 사용을 금지한다면 이제 그 프로젝트의 진행은 완전히 멈출 겁니다. 그러니까 DM이 성행하는 상황은 DM 사용을 금지한다고 개선되지 않습니다. 보다 근본적이고 직접적인 문제를 해결해야 하며 그렇지 않은 채 DM 사용만 금지하면 그나마 개발을 진행 시키던 마지막 보루인 DM을 사용할 수 없게 되면서 개발은 멈출 겁니다. 아마 그 프로젝트 또한 비슷한 운명을 맞게 될 거라고 예상합니다.