티엠티티
반셀프 바이블세상의 모든 자재티엠티티 팀

스타트업, 우리는 더 좋은 협업 툴이 필요해!

혹시 협업하는 과정이 매끄럽지 않다거나, 대화는 하지만 소통이 잘 이루어지지 않는다고 느껴본 적이 있나요? 일하다 보니 몇몇하고만 대화만 이루어져서 전체 프로젝트 구성원들이 같은 내용을 공유하지 못해 차질이 생기진 않았나요?

silos
곡식을 담는 원통형 창고를 일컫는 사일로. ‘부서별 이기주의’로 많이 알려져 있지만 실제로는 필요한 정보가 교류되지 않아 소통에 많은 시간적, 정신적 비용이 발생하는 현상을 일컫습니다. 슬랙으로 실시간 대화를 하더라도 사일로가 발생할 수 있습니다. 참고 자료: How The “Silo Effect” Is Hurting Cross Team Collaboration

이 글은 이런 사람들이 보면 좋습니다:

  • 위 질문을 읽으며 격하게 끄덕였다면 🤔
  • 협업하기 위해 새로운 툴을 찾고 있는 프로덕트 매니저

시작하기에 앞서 이 글에 언급된 협업 툴, 도구들은 저희가 서비스를 출시하면서 느꼈던 의견에서 비롯되어 다소 주관적입니다. 제품 리뷰라기보다는 경험담과 몇 가지 깨달은 점을 기술한 회고에 가깝습니다. 따라서 ‘아, 이 협업 툴이 이렇게 느껴질 수도 있겠구나’ 정도로만 생각해주세요.

왜 더 좋은 협업 툴이 필요해?

도구는 인간을 인간답게 만들었으니까요. 인류가 도구를 잘 써서 발전했고, 그게 타 영장류와 우리가 다른 이유라고 어디서 들은 바가 있거든요. 좋은 툴을 사용해서 더 나은 내가 되고자 하는 욕망은, 스티브 잡스가 맥북을 바라보는 시선이기도 합니다.

약 1분 남짓한 짧은 영상에서 잡스는 종의 운동능력이 얼마나 효율적인지에 관한 연구를 언급합니다. 콘도르[1]가 1㎞를 이동하는데 드는 노력이 가장 적은 데 반해 인간은 테스트 객체 중 하위권이었습니다. 그런데 ‘자전거를 탄 인간’은 이 독수리를 완전히 앞질러버렸다며, 컴퓨터는 우리의 사고 능률을 여느 종보다도 높여주는 자전거와 같은 도구라고 일컫습니다.

What a computer is to me is it's the most remarkable tool that we have ever come up with. It's the equivalent of a bicycle for our minds. — Steve Jobs

요리할 때는 조리 도구, 캠핑할 때는 야영 장비, 운동할 때는 운동 기구 – 유년기를 보내며 우리는 본능적으로 알고 있습니다. 도구를 잘 쓰면 적은 노력으로 많은 걸 해낼 수 있다는 사실을요. 그래서 일을 시작하기 전에 좋은 협업을 가능케 할 툴을 모색합니다. 스타트업에서 좋은 업무 문화를 만들어야 한다는 이야기도 들었으니 굉장히 중요한 퀘스트를 부여받은 느낌도 들죠.

선택의 딜레마

그런데 이 툴들에 대해 찾다 보면 어떤 걸 골라야 할지 모르는 아주 고약한 구렁텅이에 빠집니다. 만약 새로운 협업 툴로 이전하려고 할 때는 부담감이 더 커지죠. 선택 장애가 있다면 종종 답답함과 좌절감까지 느끼게 되는데, 경험상 아래의 이유가 복합적으로 작용했었습니다:

  • 대부분 해외 서비스다. 몇몇 분야에서 잘하는 국내 플레이어들이 있지만 대체로 비슷한 해외 서비스를 번역해서 내놓은, 로컬라이징(localization) 정도로 느껴집니다. 팀원들의 업무가 전문적일수록 영어로 된 서비스밖에 선택지가 없는 경우가 많아서 (e.g. 개발 → 깃허브, 디자인 → 스케치) 영어가 질색이더라도 어느 정도는 더불어 살아가는 방법을 터득합니다. 그러다 보면 협업 툴을 비교할 때 한글이어서 해당 서비스를 선택하는 이유가 없어지죠. 실제 주변 팀들의 이야기입니다. 그렇다고 더 좋은 기능을 제공하느냐 하면, 국내 SaaS 시장이 불모지에 가까워서 치열한 경쟁을 통한 업계 발전을 기대하기 어렵습니다. 그럼 더이상 언어가 메리트가 아닌 팀들에게는 해외 서비스를 사용하지 않을 이유가 없어집니다. 그렇다고 해도 모국어가 아니라 느껴지는 불편함이 없을 수는 없죠.

Speak english

  • 스타트업에 꼭 필요한 협업 툴이라는 제목 등으로 소개되는 게시글은 깊게 들어가지 않는다. 단, 협업 툴에 대한 검색을 막 시작하는 처지에서는 유용합니다. 예컨대 어떤 서비스들이 있고 어떤 키워드로 추가 리서치해야 할지 지형을 파악하기에는 더할 나위 없죠. 하지만 해당 툴을 처음 접할 때는 같은 분야의 서비스인데도 함께 나열되어 있어서 ‘두 개 다 써야 하나?’ 혼동이 오기도 합니다.

  • X 서비스를 이렇게 활용하면 Y 서비스가 굳이 필요 없겠는데? 대표적인 예가 트렐로, 아사나 류의 리스트 기반 서비스입니다. 특정 사용 방법에 제한이 없어 단순한 할 일 관리 이상으로 레퍼런스만 따로 모아놓거나, 공지사항, 미팅노트로 쓰는 등 다양하게 활용할 수 있습니다. 대부분의 협업 툴들이 이런 유연함을 강점으로 내세웁니다. 그런데 말이죠. 아래 각 협업 툴을 설명하면서 자세히 언급하겠지만, 저처럼 정리정돈을 못 하는 사람들에게는 이런 유연함은 독으로 돌아옵니다. 협업 툴을 선택할 당시에는 ‘그럼 왜 사람들이 Y 서비스와 함께 쓰지? 왜 Y 서비스에 이렇게까지 열광하지?’ 이런 고민의 굴레에 빠지게 됩니다.

  • 선택지가 너무 많은데 비해 기능이 대동소이하다. 만약 여러분이 Product Hunt, Stackshare, Siftery 같은 서비스도 참고해서 찾아본다면? 세상에나 이렇게 많은 서비스가 있다는 사실에 경악을 금치 못하죠. 찾아보면 막 별의별 게 다 나옵니다. 또한, 각 서비스의 랜딩 페이지를 읽다 보면 경쟁사들이 서로 비슷한 기능을 제공하고 있어서 뭐가 더 좋은지 글만으로는 알기 어렵습니다. X 니즈를 가진 유저만을 대상으로 하던 서비스가, 커지면서 Y 니즈를 가진 유저도 끌어들이기 위해 타 영역의 기능을 모방하기 때문입니다.

프로덕트 헌트
새로운 툴을 찾는 성지, 프로덕트 헌트

  • 여러 툴을 접한 경험이 없다. 스타트업의 특성상 구성원들이 여러 툴을 접한 경험이 없을 때가 많습니다. 그러면 새로운 툴을 도입하는 과정에서 비교 대상이 없어서 아무리 리뷰 글을 읽어봐도 뜬구름 잡는 소리같이 느껴지기 마련입니다. 이때는 직접 사용해봐야 머리가 아닌 마음으로 이해하게 되는데 몸뚱이가 하나로 부족한 스타트업에서 이런 데에 투자하는 시간이 사치처럼 느껴지기도 하고요.

  • 나만 쓰는 게 아니라 팀원들까지 함께해야 하니까 막 지르기가 힘들다. 개인용일 때는 그냥 설치해보고 별로면 그만두면 되지만, 함께 사용하는 도구를 결정해야 하는 만큼 신중해지는 면모를 보이게 됩니다. 한 번 적용하고 나서 뭐가 마음에 들지 않는다면? 새로 이전해야 하는데 그에 드는 시간과 노력의 기회비용이 만만찮기 때문입니다.

  • 이미 특정 협업 툴을 사용하고 있는 팀이 이전하는데는 많은 시간과 노력이 든다. 이전하고 싶은 욕구가 굴뚝같이 샘솟지만, 모두가 문제라는 걸 알아도 나름대로 적응해버렸기에 썩 내키지 않거나 심드렁할 수 있습니다. 이전하는 만큼 더 알맞은 툴을 찾으려고 고민하지만, 일상에 바빠지면 옮기려던 계획은 물거품이 되어버리고 다시금 선택이 어려워지며 제자리걸음 하기를 반복합니다.

그럼 어떻게 선택하나요? 너무 당연하게 들리겠지만, 직접 써봐야지요. 파일럿 테스트[2]를 통해서요. 그런데요. 왜 지금 상황에 만족하지 못하는지는 알고 있나요? 왜 특정 협업 툴이 필요한지 직접 종이에 작성해본 적이 있나요?

Give me six hours to chop down a tree and I will spend the first four sharpening the axe.
— Abraham Lincoln

링컨은 나무를 자르는 데 여섯 시간이 주어진다면 그중 네 시간을 도끼날을 벼리는 데 쓰겠다고 했습니다. 마찬가지로 좋은 협업 툴을 찾으려면 다짜고짜 검색하는 게 아니라 왜 지금 상황에 만족하지 못하는지를 돌이켜봐야 합니다. 으, 너무 당연한 말을 해서 뭐라 할 말이 없다고요?

sheldon-oh-please-gif

하지만 막상 찾으라고 하면 다들 그 당연한 과정을 거치지 않습니다. 뭐가 있나 일단 검색부터 해요. 부디 저희 팀이 빠졌던 실수를 반복하지 않기를 바래요. 특정 협업 툴에 만족하지 못하는 이유를 – 저희의 경험을 통해 – 넓은 맥락에서 관찰할 수 있다면 결정하는 데 도움이 되지 않을까 합니다.

특정 협업 툴에 만족하지 못하는 이유

저희 팀에서는 크게 네 가지의 이슈가 있었습니다:

  1. 해당 협업 툴이 우리 팀의 현재 상황, 현재 업무 방식과는 맞지 않았다.
  2. 협업 툴이 문제가 아니라 나 자신이 정리정돈을 못 하는 엉망진창인 사람이다.
  3. 다양하게 활용할 수 있는 데 반해 해당 서비스의 UI가 그에 미치지 못한다.
  4. 여러 협업 툴을 동시에 사용하다 보니 인지 부하가 생겨, 되려 생산성이 하락했다.

협업 툴이 없어서 생기는 현재의 불편함 or 지금의 협업 툴에서 만족하지 못했던 이유 = 새로운 협업 툴을 찾는 계기가 아닐까요? 그러므로 장점이나 기능에 대한 소개보다는 사용하면서 느꼈던 불편함 위주로 풀어보겠습니다.

Slack

아, 슬랙. 스타트업에게는 거의 필수라고 불리는 이 협업 툴을 더는 쓰지 않습니다. 처음 팀을 꾸릴 때 슬랙은 선택사항이 아니었습니다. 이유는 간단했죠: 다들 그렇게 하니까. 일정 시간 동안은 재밌었습니다. 각종 명령어와 여러 봇들과 노는 기분 다들 아시죠? 🤖 파일을 공유하고 자유롭게 소통하기도 쉬웠습니다.

그런데 딱 거기까지입니다. 흘러가 버리는 채팅 UI가 가지는 한계점에 저희는 금새 지쳤습니다. 대화할 당시에 다른 일을 하고 있다면 중요한 내용을 놓치기 일쑤고 알람은 수시로 울려댑니다. 파일 업로드하면 찾기 힘들어서 헤매고요. 이런 단점을 개선할 수 있는 여러 방법이 있습니다. 예컨대 메시지를 핀하거나, 알람을 설정하거나, 구성원들 사이에 슬랙을 사용하는 규칙을 정해놓을 수 있겠죠. 그래도 본질적인 해결책이 아닌 단점을 완화시키는 데에 그칩니다. 저희 팀만 느끼는 느끼는 게 아닙니다. 미디엄에서는 왜 슬랙과 헤어지는지를 편지 형식으로 쓴 글그룹 채팅의 단점 17가지를 작성한 글이 각각 5,500과 4,700 박수를 받으며 크게 호응했습니다.

1_70nC7ktnNMg9Ygf7hHogRQ
혹시 여러분도 채팅만 하다가 지치진 않나요? 사진 출처는 베이스캠프 블로그

제가 느꼈던 가장 커다란 이슈는, ‘할 일을 중심으로 한 협업 문화’를 만들기가 힘들다는 점이었습니다. 실시간 채팅은 정말로 “아젠다 없이 하루 종일 하는 회의”입니다. 업무 관련 대화를 하지만, 주제가 휙휙 바뀌기 마련이죠. 이를 개선하기 위해 슬랙이 스레드라는 기능을 추가했지만, 조악하다며 엄청 까였습니다. 점점 복잡해지는 슬랙 😨 – 슬랙은 협업(collaboration) 툴이 아니라 유연한 소통(communication)을 위한 도구였던 거죠. 원격 근무 위주거나 구성원이 굉장히 많아져서 서로 친해질 기회가 적을 때 슬랙은 그 쓰임새를 다할 수 있을 듯합니다. 저희는 아직 그렇지 못해서, 패스.

Trello

슬랙과 함께 칸반 시스템으로 할 일을 정리했었습니다. 처음에는 화이트보드에 스티키 노트를 붙였는데 모든 게 다 어설퍼서 슬픈 상황. 수기로 업데이트하는 게 어렵고 사무실 밖에서는 확인하기 어려워 트렐로로 옮겼습니다. 처음 트렐로를 팀에 소개했을 때 모두가 좋아라 찬양했었죠. 직관적인 인터페이스, 카드게임같이 카드를 드래그하는 시스템.

여기서 슬랙과의 마찰이 발생했습니다. 소통은 슬랙으로 하고, 할 일은 트렐로로 관리하면서 서비스를 왔다갔다하다보니 인지 부하가 생겨 (context switching) 되려 생산성이 떨어졌습니다. 카드에 코멘트를 달아 소통하자니 슬랙이 이미 소통의 중심으로 자리잡은 터라 애매해졌습니다.

trello_slack
트렐로와 슬랙의 만남. 좋아 보이지만 여러 서비스가 연동되는 과정에서 필연적으로 인지 부하가 생깁니다. 사진 출처는 트렐로 블로그

또한, 한 팀원의 피드백에 따르면 트렐로를 프로젝트별로 정리하다 보면, 한눈에 들어오는 느낌이 없고 끝도 없이 이어지는 피아노 위에 서 있는 기분이었다고 합니다. 팀의 모든 보드를 보여주는 페이지나, 내게 할당된 할 일만 보는 페이지가 단순한 링크 연결에 그쳐서 모든 프로젝트와 팀 전체를 아우르는 메인 허브의 기능을 하지 못했습니다. 왜 트렐로가 1조 가치의 비즈니스를 만들지 못했나에서도 비슷한 맥락을 짚고 있습니다. 물론 이는 정리정돈을 잘 하는 팀이었다면 가능했을 테지만, 저희로서는 힘에 부쳤습니다.

이렇게 아쉬운 점을 말하기는 하지만 유연하게 사용할 수 있는 좋은 서비스임은 의심의 여지가 없습니다. 거기다 핵심 기능을 무료로 쓸 수 있으니 지나친 불평일지도 모르죠. 지금은 메인 협업 툴로서 쓰고 있지는 않고 특정 프로젝트를 보조하는 수단으로만 쓰고 있습니다.

Google Docs / Dropbox Paper

구글 닥스와 드롭박스 페이퍼는 서로 차이점이 있습니다만 큰 맥락에서는 함께 이야기해도 좋을 듯합니다. 아무래도 후발주자인 페이퍼가 저희에게는 여러모로 매력적이게 다가왔습니다. 구체적으로는 1) 타 서비스와의 임베드, 2) 깔끔한 디자인과 아기자기한 이모티콘, 3) 이미지 레이아웃 기능 4) 할 일 기능이 있습니다. 그중 제가 눈여겨봤던 부분은 타 서비스와의 임베드와 할 일이었습니다. 프로젝트마다 문서를 하나 만들고, 거기에 할 일을 모두 나열해서 작업이 이루어지는 거죠.

실제 할 일과, 그 일을 하는데 필요한 정보가 한데 담겨 있다? 기존의 할 일 시스템에서는 아무리 잘 하더라도 어느 정도 갭이 느껴지기 마련입니다. 그런데 페이퍼에서는 문서 안에 할 일이 모두 담겨있고 문서 안에 그 할 일을 하는데 필요한 프로젝트 내용을 모두 담을 수 있죠. 그 과정에서 문서화가 자연스레 이뤄지고, 타 서비스를 임베드할 수도 있으니 ‘하나의 문서가 프로젝트의 허브로서 작동할 수 있지 않을까?’ 하는 상상도 했었습니다.

그런데 결국 팀의 메인 협업 툴로 쓰기에는 아쉬움이 많이 남았습니다. 가장 걸리는 부분은 폴더 단위 구조. 문서가 늘어날수록 정리하기 어려워지리라는 게 팍 와닿았습니다. 최소한 트리 뷰(tree view) 정도는 제공해야 하지 않을까. 실제로 포럼에서도 이 요청을 굉장히 많이 하는데 아직 중요하다고 판단하지 않았는지, 감감무소식이네요.

이에 대한 대안으로 Notion.so를 써보기도 했는데요. 세 서비스 모두 실시간 수정, 문서 작업에는 더할 나위 없는 좋은 서비스들이지만 메인 허브로서는 역시나 부족함을 느꼈습니다. 소통하기 어려운 느낌이 든다고 해야 할까요? 그렇다고 슬랙과 함께 쓰자니 위에 언급한 이유로 더 복잡해지죠. (이쯤 되면 불만 제로에 출현해야 하는 게 아닌가 싶습니다 😈)

Asana

슬랙을 포기할 때 가졌던 생각이 “대화 중심이 아닌, 할 일 중심으로 하는 협업 문화를 만들자!”라는 생각이 있었습니다. 마침 회사에 휴식기를 가질 시기여서 이참에 새로 시작하는 기분으로 트렐로 대신 아사나를 써보면 어떨까 싶었죠. 트렐로에 부족한 검색과 리포트 기능이 좋아서 끌리기도 했고요.

그런데 정말 예상치 못하게도, 파일 업로드가 문제였습니다. 각 태스크에 파일을 올리면 화면에 뜨는데도 시간이 걸리고, PDF가 종종 열리지 않아 불안정하다고 느꼈습니다. 그래도 서비스를 시작한 지 오래되었다고 알고 있었는데, 사용자로서 기초적인 기능에 아쉬움이 느껴지다니.

소통에서도 딱 아사나만 쓰기에는 아쉬웠는데, 이게 슬랙을 쓰던 버릇이 있어서 그랬을까요? 각자에게 할 일이 명확하다면, 그 할 일의 코멘트로 대화만으로 충분하지 않을까 싶었는데 의외로 애매한 케이스들이 있었습니다. 또한 저희는 업무에 대한 작업물이나 기록, 공지사항을 아사나에 모아뒀는데요. UI 자체가 할 일을 작성하는 쓰임새로 디자인되었다 보니 섞여 있으면 번잡스러워지고, 따로 떨어뜨려 놓아도 이런 노트들이 주목받지 못하는 인상을 받았습니다. 결국, 아사나 하나만 쓰기에도 부족하다는 느낌을 받고 탈락.

몇 가지 깨달은 점

아 정말, 여기까지 작성하고 나니 불평분자가 따로 없네요. 하지만 절대 언급된 서비스들을 폄하하려는 의도는 없습니다. 저희의 상황에는 맞지 않았을 뿐. 이런 유목민 같은 이동을 통해 저희가 느꼈던 점은:

  • 협업 툴은 잘못이 없다. 저희가 슬랙을 포기했던 이유는 애초에 슬랙을 잘못 인식하고 있어서였습니다. 슬랙든 소통(communication)을 위한 도구인데, 저희는 이를 협업(collaboration)하는 용도로 사용하려고 했지요. 아사나도 마찬가지로 단지 할 일 관리(to-do management) 서비스일 뿐인데, 이걸로 소통까지 해결하고 단 하나의 메인 허브로 사용하려고 했던 거죠.
  • 다만 UI는 중요하지 않아 보여도 중요하다. 서비스를 개발하는 사람들은, UI가 데코레이션에 불과하고 기능이 더 중요하다고들 생각합니다. 그런데 슬랙은 이미 있던 IRC의 모습을 이메일을 사용하는 유저들의 니즈에 접목했고, 트렐로는 할 일을 나열하는 방식을 칸반 형식으로 구현했던 거죠. 좋은 점만 있는가 하면, 슬랙의 채팅 UI는 일하는 방식을 바꿔버릴 만큼 강력하지만 그만큼 피로도를 누적시키기도 하고요. 따라서 내가 어떤 니즈가 있고, 이를 어떤 UI를 가진 협업 툴로 해결할 수 있을지를 살펴보는 과정이 필요합니다.
  • 도구를 어떻게 사용할지를 결정하는 건 우리의 몫이다. 좋은 도구를 가지고 있어도 이를 어떻게 쓰는지를 모르거나, 제대로 사용하지 못하면 없는 거만 못하죠. 그러기 위해서는 느슨하더라도 팀 내부에서 일을 진행하는데 일련의 체계가 잡혀있어야 한다고 느꼈습니다. 그 체계가 있어야 사용하는 협업 툴이 빛날 수 있을 테니까요.

그래서 저희는 결국 위 서비스들이 아닌, 다른 협업 툴을 사용하게 되었습니다. 이는 다른 이야기를 통해 소개할 기회가 있을 듯합니다. 이 게시글 이미지에 쓰인 로고 중 하나라는 게 힌트이며 지금까지는 아주 만족스럽습니다. 🤣

아문센은 기본적으로 초기 설정을 의심하라는 매니페스토를 가지고 있습니다 – 늘 불편한 점을 발견하고 이를 개선하자는. 따라서 이렇게 새로운 도구를 철새 이동하듯 옮겨 다닐 수 있었던 게 아닐까 해요. 열린 마음으로 받아주는 팀원들이 있어 행복합니다. ❤️ 여러분 팀은 어떤 서비스를 쓰고 있나요? 사용하면서 어떤 불편함을 품고 있나요?

혹시 협업 툴을 선택하는데 어려움을 겪고 있거나 궁금한 점이 있나요? 제게 이메일로 알려주세요.


  1. 주로 남미에 서식하는 대형 독수리 ↩︎

  2. 소규모로 협업 툴을 사용하면서 프로젝트를 진행해보는 과정 ↩︎

인기있는 글