스타트업의 이상과 현실 (3)
오픈 커뮤니케이션의 흑과 백
슬랙(Slack; IT업계에서 주로 사용하는 메신저)을 처음 써본 것은 아니었지만 외부 업체랑 일할 때만 썼기 때문에 적응하는 데까지 시간이 좀 걸렸다. 그동안은 회사의 자체 메신저만을 쓰거나 끽해야 MSN 혹은 네이트온(아아, 옛날 사람) 정도만 사용했던지라 오픈형 커뮤니케이션에 특화된 슬랙이 낯설었다.
그렇지만 요즘은 슬랙이 대세로 보인다. 스타트업은 물론이고, 많은 IT 회사들이 앞다투어 슬랙으로 메신저를 변경하는 이유는 무엇일까?
정답은 오픈 커뮤니케이션에 있다.
내가 다녔던 스타트업에서도 '오픈 커뮤니케이션'을 강조하며, 슬랙 채널을 업무의 적극적인 소통 창구로 활용하기를 강조했다. 1:1 대화 채널인 DM(Direct message)으로 소통하는 것이 아니라, 개인과 개인의 대화여도 모두 공개된 채널에 남기라는 것이다. 물론 여기서 공개가 어려운 민감한 내용은 예외이다.
실제로 슬랙은 많은 장점을 가지고 있다.
사용법이 간단하고, 프로그램이 가볍다.
궁금한 내용을 각자 알아서 검색해서 확인할 수 있다. 즉, 일종의 업무 문서 기능을 일부 대체한다.
구글밋과 유사한 수준의 화상회의를 진행할 수 있다.
첨부파일을 공유하기 쉽다.
서드파티(3rd party; 다른 회사 제품에 이용되는 하드웨어나 소프트웨어) 제품과 연동의 폭이 넓다.
분명 슬랙은 각광받을만 하다. 나 역시 슬랙을 쓴 지 2주도 되지 않아서 무릎을 탁! 쳤으니까. 그래, 사실 슬랙은 잘못이 없다. 다만 실제로 업무를 진행해 보니, 모든 이슈를 슬랙, 아니 텍스트로 전달하는 것이 모두에게 꽤 부담이 되는 일이었음을 느끼게 되었다. 정확히는 이러한 오픈 커뮤니케이션의 어려움이라고나 할까.
피드백 과잉
슬랙의 오픈 채널은 초대받지 않아도 별도의 승인 절차 없이 스스로 입장할 수 있다. 그래서인지 회사의 모든 구성원들이 각 팀의 채널에 모두 속해 있었다. 피드백 문제는 여기서 출발한다. 말 그대로 모두가 피드백을 주는 상황이 된 것이다. 이런 문제는 주로 디자인 이슈에 국한된다는 점 또한 문제였다. 어떤 기획 의도에 따라 디자인된 것인지 맥락을 파악하지 못한 상태에서 '이 버튼 위치를 오른쪽으로 빼는 게 낫지 않겠어요?'라는 천진난만한 피드백이 여러 팀원에게서 오는 것이다.
오픈 커뮤니케이션에서는 피드백이 왔을 때 '먹금' 할 수 없다. 누군가의 피드백을 수용하건 수용하지 않건, 그 이유에 대해 피드백을 받은 사람이 설명해야 하는 것이 암묵적인 룰이다. 이건 스타트업에서의 커뮤니케이션에 가장 본질적인 특성이기도 하다. 그렇기 때문에 담당자 입장에서 <당연한 것>을 매번 설명해야 하는 번거로움이 생겼다. 피드백에 대한 피드백을 실시간으로 주어야 한다는 압박감을 느끼는 팀원들도 적지 않았다. 메일로 소통했으면 비교적 적었을 문제들인 게 사실이다.
이 문제를 해결하려면...
피드백을 주는 입장에선,
내가 의견을 냄으로써 노이즈가 발생하지 않을지 한번 생각해 보는 것이 좋다. 내 의견이 정말 필요한 의견인지, '그냥 느낌적인 느낌'은 아닌지, 명확한 이유를 덧붙여 설득해야 한다.
최종 결정 권한은 담당자 및 해당 팀에 있다는 것을 염두에 고, 내 의견이 반영되지 않아도 상처받지 않을 단단한 마음이 필요하다.
피드백을 받는 입장에선,
피드백을 주는 사람의 이해도가 부족하다고 느낄 경우는 기존의 논의사항을 리마인드 해주는 편이 좋다. 하나하나 설명하기보다는 슬랙의 링크 및 태그 기능을 활용해 보자.
열린 마음으로 피드백을 수용하되, 아주 크리티컬한 이슈가 아니라면 이미 결정 난 사항에 대해 굳이 뒤집어서 다시 논의를 시작할 필요는 없다. 이 부분을 이야기하기 어렵다면 선임 혹은 의사 결정권자에게 SOS하여 논의를 마무리 짓는 편이 효율적이다.
넘치는 정보
이 문제 역시 채널의 허들이 없다는 점에서 비롯된다. 슬랙을 써봤다면 알 것이다. 30분만 다른 일에 집중하고 돌아와도 모든 채널이 볼드 처리되어 있다. 그 사이 읽어야 할 메시지가 가득 쌓였단 뜻이다.
이 문제를 해결하려면...
중요한 메시지는 놓치지 않을 수 있도록 알림 기능을 적극 활용할 필요가 있다. 특히 DM, 내가 속한 프로젝트 그룹이나 팀의 채널 등은 슬랙의 상단으로 옮겨 항상 볼 수 있도록 하자.
의사결정 중인 시점이 아니라면 실시간으로 확인해야 하는 메시지를 제외하고는 시간을 정해 확인하는 편이 낫다. 가령 오전에는 업무 준비를 하며 30분가량 슬랙을 확인한 뒤, 이후로는 개인 업무를 진행하고, 점심시간 뒤 집중이 덜 되는 타이밍을 활용해 다시 다른 채널의 슬랙을 확인하는 등 본인만의 업무 사이클에 맞게 '슬랙 확인하는 시간'을 마련하는 것이다.
당신이 리더라면, 데일리 스크럼을 적극 활용하여 팀원들에게 중요한 공지를 전달하는 것도 방법이다. 회사 전체나 다른 팀에서 오가는 중요한 이슈들에 대해 간결한 형태로 공지하는 것이다. 이것을 잘 활용하면 팀원들이 불필요하게 슬랙에 얽매인 문제를 해결할 수 있고, 스스로도 이슈를 파악하기에 용이하다. 나의 경우 이렇게 공지한 내용을 매일 팀 채널에 짧게 올리곤 했는데, 팀원들이 매우 만족했던 경험이 있다.
업무 중복
이미 지라나 컨플루언서처럼 이슈 트래킹 툴을 사용할 경우 슬랙에 모든 이슈를 남기는 것은 담당자 입장에서 일을 두 번 하는 것이 된다. 하지만 슬랙은 어디까지나 메신저이기 때문에 내용이 휘발되는 경우가 많다. 반대로 이슈 트래킹 툴은 다소 폐쇄적이기 때문에, 오픈 커뮤니케이션을 위해서 슬랙에 중복으로 공유해야 할 일은 분명 발생한다. 결국 두 가지를 모두 적절히 활용할 수밖에 없다.
이 문제를 해결하려면...
슬랙과 이슈 트래킹 툴의 활용 범위를 명확히 정리하고 공지한다. 가령 전체적인 업무 방향성 논의, 아이디어 교환 등의 업무를 슬랙에서 하기로 했다면 슬랙에 하나의 스레드(Thread; 타래. 한 말풍선에 계속해서 댓글을 달 수 있는 기능)를 만들어 논의하고, 정제된 내용을 이슈 트래킹 툴의 티켓(Ticket; 업무 일감을 의미)으로 발행하도록 약속하면 순차적으로 두 가지 툴을 이용할 수 있다.
슬랙과 이슈 트래킹 툴을 연동하여 티켓이 발행될 때마다 알림이 오도록 하고, 해당 팀원들은 본인이 맡은 업무에 대한 알림을 받을 경우 모두 확인하도록 한다.
가급적 슬랙과 이슈 트래킹 툴 양방향으로 공유 가능하도록 한다. 티켓을 발행한 뒤 슬랙 댓글에는 해당 티켓의 번호를 공유하고, 티켓의 본문에는 논의의 배경이 된 슬랙의 링크를 기재하는 식이다. 이러면 어느 한쪽만 보더라도 이동이 가능하여 전체적인 업무 맥락을 파악할 때 도움이 된다.
속된 말로 꺼림칙한 이야기는 일부러 만나서 회의를 하고, 급한 요청사항은 전화로 부탁하고, 공식적인 일은 각 잡은 메일로 보냈던 지난 직장 생활과 비교하면 슬랙을 이용한 오픈 커뮤니케이션은 다소 단조로운 날 것의 느낌이었다.
모든 것을 '오픈'하다 보니 종종 댓글 싸움(?)이 일어나기도 하고, 솔직한 피드백을 빙자한 저격을 목격한 적도 있다. 반대로 오픈 커뮤니케이션이라고 하지만 민감한 정보까지 100% 모두에게 오픈할 수 없는 점을 지적해 모순적이라고 심통 난 팀원도 있었다. 공개 채널에 어떤 글이 올라오면 달리기 경주하듯 경쟁적으로 이모티콘과 댓글을 달며 '이렇게 빛의 속도로 반응하는 나 어떤데'를 뽐내는 분위기도 있었다. 그러다 보니 의미 있는 토론보다는 보여주기식 여론 조성으로 느낀 적도 솔직히 많다.
그렇지만 이런 점을 감수하고라도 스타트업에서 오픈 커뮤니케이션은 여전히 중요한 업무 방식이다. 돌이켜보면 오너가 아닌 모든 팀원이 오너십을 갖고 일할 수 있게 만드는 동기는, 결국 이러한 투명성에서 시작된다고 보기 때문이다. 모든 팀원이 비슷한 수준으로 회사의 목표와 업무 방향성을 이해하고 우리가 해야 할 과제를 받아들일 수 있는 방식이 오픈 커뮤니케이션의 본질 아닐까? 결국 어떤 툴의 기능을 잘 이용하느냐는 문제보다, 우리가 왜 오픈 커뮤니케이션을 해야 하는지 상기하고 고민하는 것이 가장 중요하다.
