[노션으로 애자일 조직 만들기] 내가 경험한 협업 문화(1)

언택트 시대다. 이제 각 조직은 마주하지 않고 일해야 한다. 속도는 물론 결과도 내야 하는데 마주할 수 없다니, 그야말로 새로운 업무 시대다. <노션으로 애자일 조직 만들기> 시리즈에서는 내가 CODEF 데이터랩 개발자로 일하며 도입한 애자일 조직에 관해 소개한다.
[편집자주]

비대면, 언택트, 재택근무, 원격 근무. 새로운 업무 시대가 왔다. 미리 준비한 곳이 있는가 하면 이제서야 도입하느라 허둥지둥인 곳도 있다. 여태 뭐 했냐며 당장 적용할 수 있게 돈을 쏟아붓는 곳도 있다. 하지만 이 분야를 경험해본 사람이라면 알 것이다. 이건 돈으로 되는 문제가 아니라는 것을.

내가 협업 분야에 관심을 둔 것은 2014년쯤이었던 걸로 기억한다. 당시 애자일을 키워드로 내게 여러 콘텐츠가 보였고, 사내에 우리도 애자일 조직을 도입하자며 제안했다. 당시 나는 개발자 수백 명이 있는 SI 회사 대리로 3년 차 개발자였다.

“애자일? 그래, 그래서 그거 하면 몇 맨먼스 아낄 수 있나?”

당시 나는 이 조직에 이런 류 아이디어는 먹히지 않는다고 판단했다. 솔직히 크게 실망했다. 뭐든 맨먼스 위주로 생각하는 이 바닥 문화가 마음에 들지 않았다.

하지만 연차가 쌓이고, 여러 경험을 한 지금은 당시 리더가 했던 그 말을 이해한다. 그는 맨먼스로 평가받았고, 맨먼스가 전부였다. 그런 그에게 단순히 이게 좋다고 하니, 적용하자 말했던 내가 잘못된 것이다.

시간이 흘러 나는 프리랜서 개발자와 스타트업 대표를 거쳐, IT 기자가 됐다. 나는 소프트웨어 전문지 <마이크로소프트웨어>를 만들었는데, 우리 팀은 철저히 원격 근무였다. 2, 3명이 최대한 많은 영역을 커버하기 위해 물리적으로 떨어져 있었고, 덕분에 여러 업무 방법을 경험했다.

협업 도구는 우리가 경험한 업무 방법을 돕는 역할이었다. 나는 지라, 컨플루언스, 레드마인, 트렐로, 아사나, 젠키트, 구글 드라이브, 행아웃, 스카이프, 페이스북 메신저 등 사용자가 좀 있다는 서비스는 죄다 써봤다.

그렇게 여러 경험을 하고서 드디어 내가 원했던 업무 방식을 조직에 적용했다. CODEF 데이터랩은 노션을 활용한 애자일 조직을 운영하며, 이 과정에서 내가 많은 부분 경험을 나눴다.

이 글에서는 내가 경험했던 업무 방식에 관해 소개한다.

은행 SI 개발자, 인터넷은 안 된다.

나는 6년 동안 SI 개발자로 일했다. 은행에서 안드로이드 앱을 만들었는데, 그동안 내가 만든 안드로이드 앱만 십수 개다. 시간이 꽤 흘러 지금은 서비스를 종료한 곳도 많으니 편히 이야기하자면, ▲우리은행 ▲기업은행 ▲신협 ▲대구은행 등이 내 손을 거친 은행이다.

은행은 인터넷이 되지 않는다. 구글링 없이 개발하는 개발자는 극히 드물다. 딱히 구글링하지 않는 게 뛰어난 능력을 의미하지도 않는다. 그렇다면 은행에서 일하는 개발자는 어떻게 구글링을 할까?

은행원들에게는 인터넷 피씨가 별도 제공된다. 인터넷은 그 피씨에서만 한다. 자료를 받아야 하면, 보안팀에 요청해 검수를 받고 들여오는 방식이다.

SI 개발자는 그런 거 없다. 꼭 필요한 자료는 은행원에게 요청하고, 은행원이 보안팀에 요청해 받는 방식이다. 그렇지 않고는 자료는 넣을 수 없다. 때문에 스마트폰으로 찾아서 보고 타이핑하고… 그런 식이다.

지금은 어떨지 모르겠다만, 내가 일하던 때는 대부분 그랬다.

이런 환경은 원격 근무도 안 되고, 협업 도구도 의미가 없다. 애초에 다 붙어서 개발하고, 테스트하는데 무슨 의미가 있을까?

2014년쯤 신협 프로젝트를 하러 대전에 내려갔는데, 그때 일기장에 ‘다음 회사는 서울에서 출퇴근 할 수 있고, 인터넷이 되는 환경에서 일하고 싶다’고 적어두기도 했다. 참 소박한 꿈이었다.

도밍고컴퍼니, 구글과 트렐로를 적용하다.

그렇게 SI 환경을 벗어나기 위해 사이드 프로젝트를 하곤 했다. 주로 주말을 활용했고, 이 과정에서 다른 회사 직원들과 협업할 기회가 있었다.

그렇게 SI 환경과 사이드 프로젝트로 경험하며 나는 내 프로젝트를 꿈꿨다. 첫 회사를 4년 채운 2016년, 큰 꿈을 안고 창업했다. <도밍고컴퍼니>다.

<도밍고컴퍼니>는 뉴스 큐레이션 서비스 <도밍고뉴스>를 만드는 미디어 스타트업이었다. 이때 멤버들과는 구글과 트렐로로 협업했다. 당시에 내가 가장 좋아했던 도구다.

SI 환경이 답답하긴 했어도, 능력 있는 선배들이 많았다. 그들이 설계했던 자료나 협업 방식은 내 머릿속에 가득 채워서 나왔다. 그리고 그 경험을 <도밍고컴퍼니>에 녹였다.

<도밍고컴퍼니>는 최대 3명이 있었고, 트렐로로 업무를 트래킹하고, 구글 드라이브에 아카이빙 했다. 최근 API를 설계하며 당시 자료를 열어볼 일이 있었는데, 그 시절에 아등바등 나름 노력했었던 것을 확인했다.

리더로서 비즈니스를 진행해본 경험은 내게 큰 자산이 됐다. 업무 환경 자체를 만들어야 하는 막막함도 큰 경험이 됐다. 수익을 내거나 상용 서비스를 만드는 단계까지 가진 못했다. 하지만, 그 단계에 도달하기 위해 어떤 것이 필요하고, 어떤 것이 부족한지 확인할 수 있었다.

무엇이 부족한지 몰라 헤매던 내게, 부족하고 필요한 것을 확인했으니 이는 굉장한 도약이었다.

마이크로소프트웨어, 원격 근무의 끝. 출근은 없다.

미디어 스타트업으로 여기저기 소문을 낸 탓에 종종 제의가 왔다. 그중 하나가 <마이크로소프트웨어>였다. <마이크로소프트웨어>는 소프트웨어 전문지로 명성있는 개발 잡지다.

내 개발 경험과 미디어에 관심을 두는 성향을 믿고 IT기자를 제안했다. 그렇게 기자가 돼 참 많은 경험을 했다.

우선 출근이 필요 없는 조직이었다. <마이크로소프트웨어>는 조선 미디어 그룹 내 있었고, IT조선 회사에 속한 팀이었다. 레거시 미디어에 속했지만, 독립적으로 운영됐다.

아침에 카페로 출근해 뉴스 큐레이션을 하고, 알아서 개발자와 연락해 만나는 일이었다. 그렇게 만난 개발자가 잡지에 글을 쓸 수 있도록 가이드 하고, 글을 받으면 교열&편집해 종이 잡지로 출판하는 일이었다.

종종 <마이크로소프트웨어>와 내 존재를 알리기 위해 취재 후 기사를 쓰기도 했고, 회사인 IT조선 요청으로 잡지 내용을 요약해 기사화 하거나, 소프트웨어분야 보도자료를 내기도 했다.

IT조선은 구글 지스위트를 사용한다. 이메일이며, 기사를 모두 구글 독스에 써서 출고한다. 구글 독스에 별도 플러그인을 만들어 사용했다.

잡지 기고자들은 MS워드, 애플 페이지, 한글 등 자유운 형식에 원고를 써서 보냈고, 우리 팀은 구글 독스에 옮겨 교열을 봤다. 그렇게 정리된 글을 디자인 회사에서 인디자인으로 옮겨 출판했다.

이 업무 과정에서 내가 협업해야 할 대상은, <마이크로소프트웨어> 팀, IT조선 편집본부, 디자인 회사 그리고 잡지 필자들이었다.

필드에서 뛰는 기자가 되고자 했고, 최대한 많은 개발자를 만나고자 했다. 하루 미팅을 최대 8번까지 해봤는데, 다음날 감기에 걸려 일주일을 앓고 나서는 적절히 체력을 관리하며 필자를 확보하는 노하우를 만들기 시작했다.

이렇게 여러 조직과 소통하고, 동시에 개발자 수십 명과 소통하는 과정은 정보를 어떻게 기록하고, 어떻게 공유해야 하는지 고민해야 했다. 정보의 누락과 중복을 피하기 위해 지속해서 소통해야 했고, 때로는 효율을 따지기 보다 결과를 우선해야 함을 배웠다.

아무튼, <마이크로소프트웨어>는 원격 근무로도 충분히 일을 할 수 있다는 것을 배웠던 곳이다.

STEW, 경험한 것은 모두 여기로.

내 커리어는 2011년 11월 시작됐다. 하지만 이보다 이른 2011년 4월부터 지속해온 조직이 있다. <커뮤니티 STEW>다.

<커뮤니티 STEW>는 한국장학재단 멘토링으로 시작했는데, 당시 창업 멘토링으로 창업에 관심 있는 친구들이 모였다. 이들과 1년 뒤 헤어지고 싶지 않아 새로운 조직을 만들었고, 그게 <커뮤니티 STEW>다.

지금은 독서소모임, 경영소모임, 투자소모임, 코딩소모임, 미디어소모임 등 5개 소모임을 만들어 함께 공부하고 있다.

앞서 SI 개발자, 창업, 기자 등에서 배운 모든 경험치를 <커뮤니티 STEW>에 모두 쏟아 넣고 있다. 좋다고 생각되는 모든 것은 <커뮤니티 STEW>에 적용하고, 내가 잘 소화할 수 있는지 테스트한다.

때문에 각 방법론과 도구를 왜 쉽게 도입할 수 없는지 너무도 잘 이해하고 있다. <커뮤니티 STEW>는 내가 많은 경험을 했음에도 모두 다 실패했기 때문이다. <커뮤니티 STEW>에서 사용하는 건 딱 하나, 카카오톡 뿐이다.

어떤 도구를 도입할 때 어떤 시행착오가 있는지 <커뮤니티 STEW>에서 배울 수 있었다. <커뮤니티 STEW>에는 IT에 익숙지 않은 멤버가 월등히 많은데, 이들에게 서비스를 설명하기란 SI 개발자 시절 맨먼스만 생각하던 리더에게 설명하는 것보다 어려웠다.

이럴 땐 카카오톡이 짱이다.

<커뮤니티 STEW>에서 했던 시행착오는 언젠가 해야 했을 것이고, 덕분에 필드에서 할 경험을 실패가 용인되는 곳에서 경험할 수 있었다.

CODEF, 검증된 방법으로 시행착오를 줄이다.

개발자, 창업, 기자, 커뮤니티 리더까지. 꽤 다양한 경험을 하며 나는 조직 내 캐릭터에 따라 도입해야 하는 방법론과 도구가 철저히 달라져야 한다는 것을 배웠다.

또한, 한 번 도입한 방법론은 정말로 바꾸기가 쉽지 않기 때문에 신중히 공론화해야 한다는 것도 배웠다. 생각보다 이런 것에 스트레스를 크게 받는 사람이 많았다.

때문에 CODEF에서는 철저히 계획적으로 접근했고, 무려 1년에 걸친 과정을 통해 11명이 속한 부서에 노션과 애자일 방법론을 도입했다. 뒤에서 설명하겠지만, 이게 무슨 노션이고, 애자일 방법론이냐. 고작 이 정도 기능을 사용하면서 도입했다고 하는 것이냐는 식의 황당함을 말할 수도 있다.

기능과 방법론의 함정에 빠지면 안 된다. 중요한 건 최소한의 노력으로 지금보다 분명히 나아지는 것이 중요하다. 협업과 도구 따위가 비즈니스 본질을 방해해서는 안 되기 때문이다.

마무리

나는 8년이 넘는 커리어 동안 SI 개발자, 프리랜서 개발자, 창업자, 커뮤니티 리더, IT 기자, 서비스 개발자 등을 경험했다. 이 과정에서 많은 것을 경험했고, 최소 개선으로 최대 효율을 내는 것을 추구했다.

다음 글에서는 그동안 내가 사용했던 협업 무료 도구에 관해 설명하겠다.