협업 도구 시대다. 유한한 자원인 시간을 극복하려는 다양한 아이디어가 현실화 됐다. 우리는 협업 도구를 잘 활용해야 하고 때문에 잘 알아야 한다. 그런데 협업 도구는 우리를 얼마나 도울 수 있을까? 

아는 만큼 활용할 수 있는 협업 도구. <오세용의 협업 도구 이야기> 시리즈에서 다양한 협업 도구 이야기를 전달한다.

이 글은 한국 먼데이닷컴 블로그에 기고한 글입니다.
[오세용의 협업 도구 이야기 #7] 오픈소스 협업 도구를 쓴다면?

소프트웨어 역사를 논하며 ‘오픈소스’를 빼놓을 수 없다. 세계에서 가장 유명한 오픈소스인 리눅스(Linux)를 비롯해 리눅스 커널 기반으로 만들어진 안드로이드(Android)는 물론 많은 투자자와 울고 웃었던 비트코인 역시 오픈소스다. 

최근 내가 개발자로서 관심을 가졌던 오픈소스는 크로스 플랫폼 GUI 프레임워크인 플러터(Flutter)다. 플러터는 구글이 출시한 오픈소스로 다트(Dart)라는 언어로 한 번 개발하면 ▲안드로이드 ▲iOS 등 모바일은 물론 ▲데스크톱 ▲웹 등 다양한 애플리케이션으로 만들 수 있다. 이처럼 여러분은 알게 모르게 플러터를 비롯해 많은 오픈소스를 사용하고 있다.

오픈소스가 완벽한 주류로 올라서기까지 많은 역사가 있었다. 그리고 이 역사에 강력한 영향력을 끼친 기업인이 있는데 바로 MS의 CEO 사티아 나델라다. 사티아 나델라는 그동안 오픈소스를 배척했던 MS의 정책과 반대 행보를 걸었다. 그 정점은 오픈소스의 본진이라 할 수 있는 세계 최대 오픈소스 저장소 깃허브(GitHub)를 MS가 인수한 것이다. 

<그림1> 마이크로소프트 주가

여러 이유가 있겠지만 2018년 MS는 75억 달러(약 8조 원)에 깃허브를 인수하며 지속 성장했다. 주가를 보면 2018년 인수 후 주가가 3배를 훌쩍 넘은 것을 확인할 수 있다. MS의 오픈소스 전쟁 참전으로 더 이상 오픈소스는 비주류가 아니다. 

그렇다면 협업 도구는 어떨까? 이번 칼럼에서는 오픈소스 협업 도구에 관해 풀어볼까 한다.

시작은 오픈소스였다

불과 10년 전만 해도 협업을 위한 소프트웨어 시장이 이 정도 규모는 아니었다. 역사가 있는 글로벌 협업 도구 중 하나인 먼데이닷컴도 2012년 2월 창업했으니 그 뒤로 우후죽순 생겨났다. 때문에 협업 도구 시장이 고작 10년이 됐다고 생각하기 쉽다.

하지만 그전에도 협업 도구는 있었다. 내가 커리어를 시작한 2011년에도 협업 도구는 존재했다. 여전히 건재한 아틀라시안의 지라(Jira)는 무려 2002년 출시돼 현재까지 이어오고 있다. 10년 전에도 지라를 사용했던 경험을 떠올리면 정말 너무도 많이 발전했다.

지라는 상용 서비스지만 자체 서버에 설치하면 소규모 팀은 무료로 사용할 수 있었다. 아틀라시안의 위키 서비스인 컨플루언스(Confluence)도 소규모 팀은 무료였다. 이 서비스는 DB 테이블에도 직접 접근할 수 있어 CMS(Content Management System)로도 훌륭했다.

지라와 컨플루언스를 유용하게 활용했지만 내가 처음 만난 오픈소스 협업 도구는 버그 트래커 맨티스였다.

■ 버그 트래커 맨티스

신입 개발자로 커리어를 시작했던 2011년, 내게 주어진 몇몇 업무 중 버그 트래커 맨티스(Mantis)를 관리하는 게 있었다. 맨티스는 프로젝트 마지막 QA(품질관리) 단계에서 소프트웨어 버그를 찾아 보고하고 개발자가 이를 해결하는 과정을 기록하는 도구였다. 현재 먼데이닷컴 등이 비하면 UI도 투박하고 불편한 기능이 한, 두 가지가 아니었다. 딱히 맨티스를 직접 수정하는 등의 일은 없었기에 신입사원인 내가 맡아서 관리했다.

<그림2> 맨티스

특별히 관리할 일도 없었다. 사실 뭔가 수정하라고 해도 할 줄도 몰랐다. 맨티스는 PHP라는 언어로 돼 있는데 나는 PHP를 잘 몰랐다. 그러던 중 사건이 터졌다.

맨티스 서버가 죽었다. 분명히 지난주만 해도 문제가 없었는데 월요일에 출근했더니만 접속이 되지 않았다. PHP 언어는 모르고, 그렇다고 서버 로그를 분석할 줄도 모르겠고. 팀장님은 빨리 고치라며 압박하니 어떻게든 서버를 띄워야 했다. 그러던 중 아이디어가 번쩍했다!

당시 맨티스는 윈도 서버에서 구동되고 있었다. 그리고 윈도는 서버를 며칠 전으로 돌리는 기능이 있었다. 분명 지난주에는 정상 작동했었기에 나는 속으로 ‘유레카’를 외쳤다. 일주일 뒤로 돌아간 맨티스 서버는 정상 작동했고 나는 의기양양하게 팀장님에게 보고했다.

그런데 문제가 생겼다. 맨티스 서버는 맨티스만 구동되는 게 아니었다. 당시 팀의 모든 소스를 관리하는 SVN 서버도 겸하고 있었다. 일주일 뒤로 돌아간 것은 맨티스뿐만 아니라 SVN 소스도 함께였다. 그렇다. 나는 우리 팀의 일주일 업무를 날려버린 것이다.

당시 내가 할 수 있는 것은 솔직하게 보고하는 것뿐이었다. 그때부터였을까? 협업 도구는 결코 가벼이 다뤄져서는 안 된다는 강박이 내게 생긴 시점이다.

■ 프로젝트 관리 레드마인

레드마인(redmine)은 2006년 시작된 오픈소스다. 나는 맨티스보다 많이 사용하진 않았지만 업계에서 맨티스만큼 많이 들었던 협업 도구다. 맨티스보다는 좀 더 프로젝트 관리 기능을 제공하는 것으로 알고 있다. 개인적으로는 맨티스보다 UI가 더 나은 것 같다.

<그림3> 레드마인

당시에도 지라는 상용 소프트웨어였고 금융권 프로젝트에서는 대부분 지라가 사용됐다. 하지만 개발자를 보유한 중소기업은 상용 소프트웨어보다는 무료 소프트웨어를 희망했다. 현재보다 개발자 인건비가 훨씬 싸기도 했고 소프트웨어에 돈을 쓰는 게 지금보다 더 깐깐했던 시기이기도 했다. 소프트웨어를 만드는 개발자들도 그랬으니, 소비자는 얼마나 더 심했을까.

코딩 유튜브로 유명한 ‘생활코딩‘에도 2012년에 레드마인을 소개하는 영상이 있다. 지금은 실무에서 레드마인을 사용한다는 이야기를 듣지 못하지만 당시에는 프로젝트 경험이 있는 개발자라면 대부분 아는 꽤 인지도 있는 오픈소스 소프트웨어였다.

그리고 여전히 많은 오픈소스 협업 도구가 알게 모르게 진행되고 있다.

굵직한 오픈소스 협업 도구

종종 사내 협업 시스템을 만들고 싶다는 상담을 요청 받곤한다. 대부분 소규모 팀이고 당장 비용을 지출하기는 어렵다며 걱정을 털어놓는다. 나는 개발팀이 4명일 때부터 10명 신사업 팀. 30명 전사 그리고 100명까지 회사와 함께 성장하며 협업 시스템을 만든 경험이 있다. 그리고 지금 5명 스타트업을 창업하며 다시 협업 시스템에 관해 배우고 있다.

때문에 확신을 갖고 말할 수 있다. 소규모 팀을 때 가장 먼저 세워야 할 협업 정책은 단연 ‘채팅’이다.

협업 도구 칼럼니스트이자 협업 도서 저자로서 스타트업 협업 시스템을 제대로 만들고 싶은 욕심이 있었다. 왜 없었겠나 내가 가장 잘하는 것 중 하나인데. 하지만 사업을 이어가며 협업 시스템을 잘 만든다는 게 무엇 때문에 중요한지 생각해 보게 됐다. 협업 시스템을 잘 만드는 것 자체는 전혀 중요하지 않다. 그게 사업에 도움이 된다면 고마울 뿐. 협업 시스템 자체가 주요 사업이 아닌 이상 협업 시스템 자체는 중요하지 않다.

소규모 팀일수록 도구를 최소화해야 한다. 그리고 결코 대체할 수 없는 도구가 바로 채팅 앱이다. 간혹 채팅 앱을 사용하지 않는다는 리더를 만나는데 이는 리더를 빼놓은 단톡방이 있는 것이다. 채팅 앱은 대체할 수 없다.

때문에 나는 채팅 앱만큼은 다시 변경할 필요가 없도록 끝판왕인 ‘슬랙’을 쓰라고 권유한다. 하지만 슬랙도 인당 월 1만 원 정도로 10명만 돼도 월 10만 원이 필요하다. 협업 도구 고민을 털어놓는 사람은 대부분 ‘금액’에 관련된 고민이다. 애초에 돈이 부담되지 않는다면 고민도 하지 않을 것이다. 때문에 슬랙이 부담된다는 이들에게는 매터모스트를 추천한다.

■ 오픈소스 채팅 앱 매터모스트

매터모스트(Mattermost)는 설치형 슬랙이다. 서버에 설치해 운영할 수 있는 엔지니어가 있는 팀이라면 꽤 긴 시간동안 매터모스트로 운영할 수 있다. 10명 신사업 팀에서 1년여 매터모스트로 문제 없이 채팅 앱을 사용했던 기억이 있다.

<그림4> 매터모스트

최근에는 UI도 꽤 많이 발전해서 슬랙과 큰 차이가 없다. 노션 등을 활용해 채팅 앱 없이 조직을 운영할 수 있다는 이야기도 듣곤 하는데 이는 설계된 상황에서는 가능할 수도 있다. 하지만 조직이라는 게 늘 설계된 상황만 발생하는 건 아니다. 예외 케이스는 늘 시급성을 요하고 이때는 채팅 앱을 대체할 수 있는 건 마땅치 않다.

나는 노션으로 협업 시스템을 구축하고 슬랙으로 채팅 시스템을 구축했는데도 카카오톡 단톡방을 만들어야만 했다. 너무 싫었지만 코로나로 인한 긴급 상황을 전파하기 위해서는 피할 수 없었다. 전사 모든 인원에게 전화를 돌리는 것보다 단톡방 공지를 하는 게 훨씬 빠르고 정확했기 때문이다.

■ 작업 관리 OS APITable

협업 도구를 리서치하던 중 꽤 특별해 보이는 오픈소스를 발견했다. APITable(API 테이블)이다. API 테이블은 1만 개에 달하는 깃허브 스타를 받았다. 

▲테이블뷰 ▲그리드뷰 ▲칸반보드 ▲캘린더 ▲갤러리 등 범용적으로 사용되는 대부분의 뷰 형태를 제공한다. 각 항목별 권한을 부여할 수도 있고 각 데이터를 API 형태로 제공할 수도 있다. 자동화와 대시보드 기능도 제공하는데 이 모든 게 자체 호스팅으로 제공하면 무료로 사용할 수 있다.

<그림5> APITable

오픈소스로 제공되는만큼 원하는 기능을 커스터마이징할 수도 있다. 10년 전 사용하던 맨티스와 레드마인과 비교하면 오픈소스로 이 정도 퀄리티의 제품을 만드는 게 새삼 놀랍다. 물론 클라우드 방식으로 사용할 경우 다른 서비스들처럼 월 구독 모델로 비용을 받는다. 하지만 1만 개에 달하는 깃허브 스타가 증명하듯 API테이블은 오픈소스로서 굉장한 지지를 받는 프로젝트다.

그런데 이 정도 소프트웨어가 오픈소스라면 우리는 이제 협업 도구를 유료로 사용할 필요가 없을까? 글쎄. 나는 오히려 API 테이블이 우리가 협업 도구를 유료로 사용해야 하는 이유라고 본다.

상용 협업 도구를 써야 하는 이유

아는 만큼 보이는 법이다. 첫 창업 당시 나는 ‘경영지원팀’의 역할에 관해 뼈저리게 이해했다. 첫 회사를 4년 동안 다니면서도 경영지원팀이 정확히 무슨 일을 하는지 몰랐다. 첫 창업 후 ▲1인 사무실을 구할 때 ▲프리랜서 세금 신고 할 때 등 내가 해야 하는데 도대체 어떻게 해야 할지 모르겠던 그 심정을 잊을 수 없다.

최근 두 번째 창업을 하면서는 전보다 꽤 준비가 됐다고 생각했다. 그런데 준비는커녕 전보다 더 허둥지둥했던 것 같다. 나는 소프트웨어 제품 개발은 동료들에게 맡긴 채 나머지 업무를 커버했는데 이는 결코 내가 나머지 업무를 잘해서가 아니다. 소프트웨어 개발을 위해서는 제품 기획과 코딩 외 ▲인프라 ▲디자인 ▲마케팅 등 다양한 업무가 있다. 그리고 나는 인프라를 무척 가볍게 생각했나보다.

제품을 서비스하기 위해서는 꽤 많은 인프라 작업이 필요하다. IDC에 서버를 둘지 아니면 클라우드 서버를 둘지. DB는 무엇을 선택할지. 클라우드로 갈 경우 어떤 회사 호스팅을 이용할지. 인프라 아키텍처를 어떻게 구상할지. 트래픽은 어느 정도로 예상해야 할지 등. 현재도 모르겠는데 미래에도 적절한 무언가를 선택하려니 압박감이 너무도 무거웠다.

클라우드 서비스를 사용한다는 건 이 모든 고민을 하지 않아도 되는 것이다.

API 테이블이 설령 먼데이닷컴과 비슷한 기능을 무료로 제공한다고 해도 직접 호스팅해서 사용하는 건 전혀 다른 일이다. 규모가 커질수록 API 테이블 호스팅만을 담당하는 직원이 필요해질 것이고 그 비용을 생각해 보면 먼데이닷컴을 SaaS(Software as a Service) 형태 클라우드 서비스로 사용하는 게 훨씬 저렴하게 느껴질 것이다.

물론 문제가 발생하지 않는다면 API 테이블을 무료로 사용하는 게 이득이라 생각될 수 있겠다. 하지만 문제가 발생하면 어떻게 할지 대응 방안을 꾸려둬야 하고 이 역시 비용이다.

조직은 핵심 비즈니스에 집중해야 한다. 대부분의 비즈니스는 ‘협업 도구’ 그 자체가 아니다. 협업 도구는 핵심 비즈니스를 위해 활용하는 말 그대로 ‘도구’다. 핵심 비즈니스가 아닌 ‘도구’를 위해 시간을 할애한다면 굉장한 기회비용을 날리고 있는 셈이다.

또한, 버그 트래커 맨티스를 관리했던 엔지니어로서 이야기하자면, 핵심 비즈니스가 아닌 보조 도구를 관리하는 업무를 맡는 게 즐거운 엔지니어는 그리 많지 않다. 

결국 상용 협업 도구 시장은 지속 성장하지 않을까?

마무리

존중받고 싶은 욕구는 인간의 욕망 중 하나다. 조직에서 보다 주요한 역할을 맡으려는 건 이 욕망의 연장선이다.

비즈니스도 마찬가지다. 결국 비즈니스 본질에 얼마나 집중하며 시간을 할애하는지가 비즈니스의 성패를 가른다. 그리고 구성원이 본질에 집중하기 위해서는 부차적인 업무. 즉, 협업 도구 따위를 다루는 등의 업무는 비용을 지불하며 SaaS를 활용하는 것이 때로는 현명할 것이다.

이 글을 읽는 모두의 비즈니스가 성공하기 위해 협업 도구를 보다 현명하게 사용하길 바란다.

참고자료