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

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

이 글은 한국 먼데이닷컴 블로그에 기고한 글입니다.
[오세용의 협업 도구 이야기 #3] 프로젝트에서 협업 도구는 왜 필요한가

나는 지난 10년 동안 소프트웨어 개발자로 일했다. 주로 핀테크 시장 애플리케이션 개발자로 일했는데 수백 명이 투입되는 이른바 ‘차세대 프로젝트’에서 애플리케이션 개발자는 그저 수많은 개발자 중 하나인 개발자A가 될 수밖에 없다. 수백 명을 관리하다 보니 관리자들은 때론 개발자로 하여금 ‘부품’과 같은 느낌을 받게 했다. 지금은 관리자들의 마음을 이해할 수 있지만 그때는 그게 너무 싫었다.

하지만 WBS 역시 IT 역사와 함께 필요에 의해 만들어진 도구다. 여전히 WBS는 유용히 사용되고 단점을 감안하고도 WBS가 사용되는 게 이득인 상황도 있다. 어쨌든 장점이 명확한 도구다. 하지만 협업 도구 시대에는 꼭 WBS를 고집할 필요는 없어졌다. 많은 협업 도구가 WBS의 단점을 보완했기 때문이다.

이 칼럼에서는 프로젝트 관리를 위한 협업 도구에 관해 알아본다.

프로젝트는 어떻게 관리하나

어느 날 PM(프로젝트 매니저)의 모니터에 엑셀 파일이 떠 있는 걸 봤다. WBS(Work Breakdown Structure)라는 양식의 프로젝트를 관리하는 일종의 도구였다. 수백 라인에 달하는 그 시트에서 개발자A인 나는 그저 ‘한 줄’에 불과했다. 그때부터 나는 WBS를 혐오하기 시작했다.

시간이 흘러 5명 개발팀의 팀장이 된 나는 상용 서비스를 개발, 운영하기 위해 개발자를 적절히 관리해야 했다. 누군가는 좋은 개발자를 모았다면 관리라는 게 필요 없다고 할지 모르겠다. 나 역시 그런 환경을 꿈꿨던 적이 있다. 소위 스타트업이라면 모두가 주도적인 구성원으로 조직돼 관리가 아닌 비전 공유 따위로 모두가 한 방향으로 나아갈 수 있다는 희망 말이다. 

그런데 개발 팀장이 되니 그건 말 그대로 희망일 뿐인가 싶었다. 5명이 특별한 관리 없이 비전 따위로 한 방향을 바라보는 건 정말 쉽지 않았다. 결국 나는 그토록 혐오했던 WBS를 만들기 시작했다.

◆ 프로젝트는 ‘관리’ 돼야만 할까

일단 일이 돼야 했기에 WBS를 만들어 일정을 관리했지만 WBS를 혐오했던 나는 이 방식의 단점을 너무도 잘 알고 있었다. 가장 큰 위험 요소를 하나 말하자면 WBS는 프로젝트 초기에 만들어 일정을 관리한다. 만약 10개 기능을 10일 동안 개발한다고 하면 하루에 1개씩 개발하면 되겠다. 그런데 프로젝트 초기에 구상한 기능 10개는 개발을 진행하며 11개, 12개로 하나씩 추가가 된다. 기능은 추가되는데 일정은 그대로다. 따라서 개발자는 하루에 1개가 아닌 2개, 3개를 개발해야 하는 상황에 놓인다.

문제는 개발을 WBS를 만든 관리자가 하지 않는다는 것이다. 관리자가 같이 개발을 하더라도 모든 개발에 참여할 수는 없다. 모든 개발에 참여한다면 애초에 WBS 자체가 필요 없다. 즉, 개발자는 WBS의 일정을 지키기 위해 새로이 발견되는 기능을 보고하지 않는다. 보고하면 그저 자신의 일만 늘어날 뿐이다. 그렇게 10일 동안 하루에 1개씩 개발을 마치고 10일 뒤 관리자는 새롭게 개발돼야 하는 기능을 발견한다. 이미 그때는 늦었다.

만약 WBS가 추가 기능이 생기지 않을 정도로 완벽히 만들어졌다면 어떨까? 관리자가 정말 뛰어난 개발자여서 예측 가능한 모든 기능을 WBS에 넣고 필요한 일정을 완벽히 맞출 수 있다면 어떨까? 그래서 개발자들은 잘 짜여진 WBS 위에서 정확한 일자대로 기능을 구현한다면 어떨까? 아쉽지만 이는 정말 쉽지 않다.

시간이 흘러 나는 개발 팀장에서 개발 부서장이 됐다. 어느새 10명이 된 개발 부서는 1개 사업의 기술 영역을 담당했고 여러 가지 서비스를 필요로 했다. 모든 개발자의 기술력이 비슷하거나 도메인 지식이 비슷하다면 조직 어디든 배치할 수 있을지 모른다. 하지만 조직은 균형이 필요하다. 기술력은 물론 경험과 캐릭터 등 모든 게 서로 다르기 때문에 오늘은 A팀, 내일은 B팀 따위로 임의 배치할 수 없다. 사람인지라 상황에 따라 개인사가 생기기도 한다. 결국 개발 부서를 온전히 계획대로 물 흐르듯 운영하는 건 정말 쉽지 않았다.

나는 철저히 계획형 인간으로 계획대로 되는 걸 선호한다. 하지만 계획은 늘 망가지기 마련이다. 수차례 망가지는 계획을 보며 때로는 구성원이 밉기도 했다. 계획대로만 하면 분명히 좋은 결과가 있을 텐데 왜 계획대로 해주지 않을까.

그렇게 어느 개발 부서장은 프로젝트 관리에 더해 조직도 ‘관리’하기 시작했다.

◆ 조직은 ‘관리’ 돼야만 할까

계획형 인간으로서 부서의 계획을 수차례 수정했다. 당시 A안부터 B안, C안을 넘어 G안까지 만들었던 기억이 있다. 상황이 매 순간 바뀌는데 나는 이 모든 상황을 트래킹해 적절한 판단을 하고 싶었다. 그게 관리자의 역할이라 생각했다. 

적절한 판단을 위해선 정보가 필요하다. 이를 위해 타 부서장과 경영진은 물론 부서원과 정기 미팅을 가졌다. 내가 생각하는 부서의 비전을 공유하고 개개인의 성장과 함께 부서를 최고로 만들고 싶었다. 그렇게 정보를 수집하고 동기부여 하는 일 자체도 꽤 많은 리소스를 필요로 했고 덕분에 주말에도 카페에 앉아 구성원의 성장 방향성을 위한 내용을 정리하기도 했다.

그러던 중 팀장에게 부서원들이 나와 미팅을 꺼려한다는 이야기를 들었다. 부서장과 미팅이 마치 입사 면접처럼 딱딱하다는 말도 들었다. 나는 그동안의 모든 노력을 부정당하는 느낌이었다. 머릿속이 하얘졌다. 그러다 정신을 차렸더니 WBS로 개발자를 엑셀 시트 한 줄로 관리하던 PM과 내가 다를 게 뭔가 싶었다. 결국 나 역시 부서원을 부품으로 생각했던건가 싶었다.

실수였다. 서툴렀기에 올바르지 못한 방법을 사용한 것이다. 나는 모든 상황을 트래킹하고 모든 상황을 ‘관리’ 해야 한다는 강박을 내려놨다. 모든 상황을 스스로 ‘판단’해야 한다는 잘못된 생각도 버렸다.

그런데 프로젝트도 조직도 ‘관리’가 아니라면 리더는 어떤 역할을 해야 할까? 내가 찾은 방법은 너무도 식상한 말. ‘협업’이었다.

◆ 관리 vs 협업

꽤 오래 운영한 독서모임이 있다. 독서모임을 운영하다 보면 특별히 의견을 많이 내는 친구들이 있다. 반면 다소 소극적인 친구도 있다. 어느 날 나를 제외하곤 소극적인 친구들만 모였고 나는 모임 분위기를 띄워야 한다는 압박에 평소보다 2~3배 더 말을 했다. 그랬더니 한 친구가 이렇게 말했다.

“우리도 다 책 읽고 말하고 싶어서 모인 거에요. 모든 의견에 그렇게 다 의견을 내면 우리는 언제 말을 해요.”

순간 쥐구멍에 숨고 싶었다. 내가 말이 많은 건 사실이지만 그날은 정말 모임 분위기를 띄우려고 그랬던 거다. 그런데 상대가 소극적이라 생각했던 건 순전히 내 생각이었다. 결국 그 뒤로는 내 차례에도 말을 아꼈던 기억이 있다.

관리가 아닌 협업이란 게 말 장난으로 느껴질지 모르겠다. 앞서 말하던 관리가 아닌 ‘비전 공유’ 따위를 말하려는 건 아니다. 말 그대로 협업. 함께 일 하자는 거다. 우리 모두는 일을 하러 모였다. 관리자라고 해서 리더라고 해서 혼자서만 생각하고 판단한다면 구성원의 지지를 받지 못한다. 아닌척 해도 겉으로 표현하지 않아도 사실은 어떤 의견이 있을 수 있다. 리더는 그 의견을 나눌 수 있는 장을 열어야지 스스로 판단하고 결정하는 건 현 시대에 적절하지 않다.

나는 평소에도 정보를 공유하는 편이었지만 관리를 덜하기로 마음 먹고나서는 좀 더 공유하기 시작했다. 이 일을 우리가 왜 하게 됐는지, 누가 요청했으며 어떤 과정을 거쳐 진행됐는지. 그리고 이 일을 언제까지 마무리 한 뒤에는 누구에게 어떻게 전달되는지. 그래서 업무가 어떻게 마무리 되는지.

협업을 택했다고 한들 관리자로서 역할을 놓는다는 건 아니다. 부서장으로서 해야 할 인사평가 등 역할은 분명히 다했다. 관리와 협업은 어쩌면 한 끗 차이일지 모른다. 더욱이 이건 정답이 없다. 왕도도 없다. 분명한 건 현 시대에 협업이라 함은 구성원이 ‘함께 일하고 있다’고 느끼는지 여부에 따라 결정된다고 본다. 그리고 이 과정에서 협업 도구는 중요한 역할을 담당한다. 바로, 정보 공유다.

정보 공유는 협업 도구로

학부 시절 한 프로그래밍 수업에서 교수님이 메모장을 켜라고 했다. 그리고 일주일 동안 메모장을 만들라고 했다. 우리는 모두 콧방귀를 꼈다. 메모장이 뭔 기능이 있다고?

놀랍게도 메모장에는 기능이 수십 개 있다. 단순히 복사, 붙여넣기를 제외하더라도 ▲시간 ▲바꾸기 심지어 ▲Bing으로 검색 등 생각보다 많은 기능이 메모장에 녹아있다. 그리고 이는 모두 누군가가 만든 기능이다.

협업 도구는 수백, 수천 가지 기능을 자랑한다. 협업 도구가 자랑하는 ▲자동화 ▲마켓플레이스 등 굵직한 기능을 제외해도 화면에 보이는 모든 기능을 누군가가 만들었다는걸 생각하면 개발자로서 그 업무량에 눈앞이 아찔해진다.

때문에 협업 도구를 사용할 때는 기능에 압도될 필요 없다. 애초에 이 기능 자체를 모두 사용하는 사람은 없다. 협업 도구는 서비스를 기획하며 수많은 사용자 유형을 염두에 두고 만든다. 그리고 어떤 개인이 이 모든 사용자 유형에 포함되지 않는다.

하지만 협업 도구를 사용할 때 모든 사용자가 염두에 둬야 할 유형이 있다. 바로 정보 공유다. 각 협업 도구를 사용해 정보를 공유하는 효율적인 방법을 소개한다.

◆ 프로젝트 관리 도구를 써라

먼저 프로젝트 관리 도구다. 앞서 현 시대 협업에서 구성원이 ‘함께 일하고 있다’고 느끼는 게 중요하다고 했다. 이를 위해 누가 업무를 요청했고, 언제까지 하고, 어떻게 전달되는지 등 다양한 요소를 공유해야 한다고 했다. 

하지만 이를 관리자가 하나하나 공유하기란 쉽지 않다. 시간도 많이 필요할뿐더러 관리자도 사람인지라 공유하고 싶어도 잊는 경우가 많다. 이를 위해 먼데이닷컴 등 프로젝트 관리 도구를 쓰는 걸 추천한다.

지난 칼럼([오세용의 협업 도구 이야기 #2] 협업 도구 도입의 필요 조건)에서 먼데이닷컴을 활용해 재직증명서를 발급하는 요청 시트를 만들었다. <그림3>은 요청 시트의 ‘활동 로그’다.

먼데이닷컴 활동 로그를 보면 각 업무 카드에 어떤 활동이 있었는지를 확인할 수 있다. ▲어느 그룹에서 어느 그룹으로 옮겨졌는지 ▲누가 만들었는지 ▲어떤 속성 값이 추가됐는지 등 관리자는 모든 업무를 기억할 필요가 없다. 또한 이 정보를 공유하는 과정은 관리자가 시간을 할애할 필요가 없다. 구성원이 ‘활동 로그’를 보는 것만으로 충분한 정보 공유가 된다.

다만, 관리자는 프로젝트 관리 도구를 통해 업무가 이뤄지도록 업무 환경을 만들기만 하면 된다.

지난 칼럼에서는 간단한 샘플 보드를 소개했다. 실제 프로젝트 관리에 먼데이닷컴을 활용하다 보면 아래 <그림4>처럼 다양한 항목을 활용하게 된다.

디자인 작업 현황에 따라 각 ▲디자인 ▲1차컨펌 ▲개발/퍼블리싱 ▲2차컨펌 ▲오픈 등에 ▲진행전 ▲진행중 ▲지연 ▲완료 등을 표시할 수 있다. 또한 각 상황을 퍼센테이지로 계산해 진행상황을 표시할 수도 있다.

앞서 설명했듯이 먼데이 닷컴과 같은 도구로 프로젝트를 관리하게 되면 관리자는 모든 업무를 기억할 필요가 없다. 구성원이 업데이트하는 보드를 확인하는 것만으로 충분한 정보 공유가 된다.

웹디자인 프로제트 관리는 테이블형태 외 간트차트 등으로도 확인할 수 있다. 간트차트는 시간 흐름에 따라 각 작업을 배치해 관리자가 전체 업무 흐름을 파악하기 좋다. 

하지만 관리자라고 해서 프로젝트 관리만 하지는 않는다. 다른 업무로도 바쁜데 매번 프로젝트 관리를 위해 협업 도구만 쳐다보고 있을 순 없다. 이럴땐 보드 자동화 기능을 활용해 알림을 받아볼 수 있다.

<그림6>은 먼데이닷컴 보드 자동화 기능 화면이다. 각 항목을 보면 디자인 항목이 ‘완료’로 변경될 경우 업무를 ‘진행 완료’ 영역으로 옮기는 등 어떤 시점에 조건을 만족할 경우 어떤 액션이 이뤄지도록 구성돼 있다. 이 자동화 기능은 각 관리자가 원하는대로 조합할 수 있다.

◆ 사내 위키를 써라

온라인에서 협업을 통해 정보의 내용과 구조를 수정할 수 있는 웹사이트를 위키(Wiki)라고 한다. 그리고 사내에서 정보를 공유하는 도구를 사내 위키라 부른다.

내가 창업한 스타트업 유자랩스는 사내 위키 사용을 적극 권장한다. 아무리 내가 한 작업도 몇 주만 지나면 잊히기 마련이다. 결국 다시 기억을 떠올리는데 아까운 시간이 할애된다. 사내 위키를 만들어 각 작업을 간략히 기록해 두면 빠르게 기억을 떠올릴 수 있다.

관리자는 사내 위키를 작성하는 구성원을 적극 독려해야 한다. 위키 작성을 강제하는 스타트업도 있지만 경험상 모든 조직에 긍정적인 효과가 있지는 않았다. 당장은 업무 속도에 영향을 주는 것처럼 보일지 몰라도 위키가 축적되면 무서운 효과를 발휘하는 걸 경험한 바 있다.

◆ 슬랙 대화는 공개 채널을 써라

많은 스타트업이 슬랙(Slack)을 사용한다. 슬랙은 API를 활용해 각종 봇을 만들 수 있는 장점으로 널리 보급됐지만 꼭 봇을 활용하지 않더라도 채널을 잘 활용하면 큰 효과를 볼 수 있다.

유자랩스는 각 업무 유형에 따라 채널을 나눠 관리하고 있다. <그림5>는 슬랙이 아닌 디스코드다. 디스코드, 매터모스트 등은 슬랙처럼 채널 형식으로 대화할 수 있으며 무료다. 디스코드는 푸시가 다소 느리게 온다는 단점이 있지만 초기 스타트업에게 비용을 아낄 수 있다면 이 정도 단점은 눈감아줄만 하다.

앞서 소개한 3가지 유형 중 공개 채널 대화가 가장 중요하며 구성원의 행동을 바꾸는 것도 가장 어려웠다. 왜 그리 다들 부끄러움이 많은지 비공개 채널이나 개인 메시지(DM)로 업무를 처리하곤 했다. 하지만 공개 채널에서 업무 대화를 하도록 유도하는 건 관리자의 중요한 역할 중 하나다.

마무리

관리자는 외로운 포지션이다. 분명 모두를 위한 선택을 하는 자리인데 그 선택에서 스스로를 제외할 때가 있다. 차라리 그게 마음이 편하기 때문이다. 하지만 마음 한편에는 서운함이 쌓이고 어느 순간 폭발할지도 모른다. 때문에 모두를 위한 선택에서 스스로를 제외하지 않길 바란다.

결국 함께 해야 한다. 관리자라고 해서 조금 더 희생하려는 순간 오히려 누구도 원치 않는 방향으로 조직을 이끌지도 모른다. 적어도 나는 스스로를 희생할 때보다 함께하려 했을 때 일도 삶도 더 나아졌다.

또한 함께하는 과정에서는 도구를 적극 활용하자. 지금은 협업 도구 시대이기 때문이다.

이 글은 한국 먼데이닷컴 블로그에 기고한 글입니다.
[오세용의 협업 도구 이야기 #3] 프로젝트에서 협업 도구는 왜 필요한가