로그인|회원가입|고객센터
Top
검색버튼 메뉴버튼

리모트 워크 기업 ‘오토매틱’ 사례

8시간 자리만 지키면 무슨 소용?
리모트 워크 핵심은 효율적 업무 진행

김태곤 | 268호 (2019년 3월 Issue 1)
Article at a Glance
웹사이트 제작 도구인 워드프레스로 잘 알려진 미국 IT 기업 오토매틱은 원격 근무가 성공적으로 안착한 대표적인 회사다. 이 회사가 가장 중요하게 생각하는 것은 소통이다. 오토매틱은 대표를 포함해 모든 직원이 직급에 상관없이 자유롭게 의견을 교환할 수 있는 분위기를 조성하고, 누구나 명확하게 업무와 관련한 의견을 전달할 수 있도록 구체적인 가이드라인을 제시한다. 또한 재무적 정보를 포함한 회사 정책 및 상황을 투명하게 공개해 직원들이 회사를 잘 이해하도록 도왔다. 효율적인 업무를 위한 원칙도 분명히 세웠다. 직원들에게 작은 단위로 업무를 배분하고 이에 대한 맞춤형 피드백을 정기적으로 줌으로써 업무에 대한 몰입도와 성취욕을 높였다. 오토매틱의 일원이 되는 데 적합한 성격과 역량을 갖춘 인재를 뽑을 수 있는 까다로운 채용 시스템도 중요한 역할을 했다.



“대기가 희뿌연 먼지에 갇혔습니다. 오늘 외출하실 때는 마스크를 착용하시는 것이 좋겠습니다. 현재 수도권 곳곳에는 초미세먼지 주의보가 발령 중입니다.”

2019년 1월의 어느 날 아침, 뉴스에서는 기상 해설자가 연신 주의를 당부했다. 커피를 내리며 창밖을 보니 아니나 다를까 희뿌연 하늘에서는 푸른빛을 흔적도 찾기 어려웠다. 어제 마무리하지 못한 일이 생각나서 컵을 들고 사무실로 출근했다. 조금 더 정확하게 표현하자면 업무를 할 때 쓰는 작은 방으로 걸어갔다. 그렇게 출근에 걸린 시간은 1분 남짓. 몇십 년 만이라는 지난여름의 폭염도, 십수 년 이래 최악이라는 미세먼지도 내게는 다른 세상 얘기다.

리모트 워크(remote work) 덕분이다. 리모트 워크, 즉 원격 근무는 사무실이 아닌 다른 곳에서 자유롭게 일하는 것을 의미한다. 비슷한 용어로 집에서 근무한다는 의미의 재택근무가 있지만 리모트 워크는 집이 아닌 다른 곳, 예를 들면, 카페나 코워킹 스페이스 혹은 여행을 하면서 근무할 수 있다는 의미도 내포하고 있기 때문에 재택근무와는 구분해서 사용된다.

나는 2011년부터 리모트 워크를 본격적으로 시작했다. 녹색 검색창으로 유명한 회사에 재직 중에 뉴욕 기반의 팬시(Fancy.com)라는 스타트업에서 제안을 받고 이직해 4년간 리모트 워크 환경에서 일했다. 그전에 프리랜서로서 재택근무를 해본 적은 있지만 회사에 소속된 정직원으로서 풀타임(full-time) 리모트 워크를 해본 것은 그때가 처음이었다. 다행히 이 새로운 업무 환경이 내게 잘 맞아서 아예 모든 직원이 리모트 워크를 하는 오토매틱(Automattic)이라는 기업으로 2016년 6월 중순쯤 이직했다. 팬시는 전 직원이 50명이 채 안 되는 작은 기업이었던 데다가 주로 엔지니어들만 리모트 워크를 했던 반면, 오토매틱은 직군에 상관없이 모든 직원이 리모트 워크를 하고 있으며 직원 수도 853명(2019년 1월 현재)으로 규모가 훨씬 크다. 그 덕분에 리모트 워크라는 근무 형태를 조금 더 다양한 측면에서 살펴볼 수 있었다.

오토매틱이라는 이름은 들어본 적 없더라도 워드프레스(WordPress)라는 오픈소스 응용프로그램의 이름은 들어봤을 수 있다. 워드프레스는 전 세계 웹사이트의 약 33%(2019년 1월 기준, w3techs.com 통계)가 사용하고 있는 웹사이트 제작 도구인데 플러그인이나 테마를 추가하거나 교체하는 방식으로 다양한 목적에 활용하기 좋다는 게 큰 장점으로 꼽힌다. 한국에서는 서울시의 웹사이트를 워드프레스로 만든 게 알려지면서 덩달아 유명해졌다. 1 오토매틱은 워드프레스를 만든 맷 뮬렌웨그(Matt Mulenweg)가 2005년 설립한 기업으로 워드프레스 프로젝트를 지원하는 한편 이를 이용한 블로그 호스팅을 주요 사업 모델로 삼고 있다. 오토매틱은 직원이 20명이던 설립 당시부터 리모트 워크를 해왔고 기업 운영 체계의 실험과 개선을 거듭해 직원 수가 40배 이상 늘어난 지금도 전 직원이 리모트 워크 형태로만 일한다. 이렇게 큰 회사가 어떻게 리모트 워크를 할 수 있었을까?




처음엔 그게 유일한 방식인 줄 알았다
오토매틱은 워드프레스라는 오픈소스 프로젝트에 근간을 두고 있다. 2005년 당시 워드프레스는 이미 어느 정도 이름이 알려진 프로젝트였고, 전 세계에서 여러 소프트웨어 개발자가 참여하고 있었다. 여느 오픈소스 프로젝트와 마찬가지로 사무실 없이, 참여자 모두 출근하지 않고 일하는 일종의 리모트 워크 방식으로 진행됐다. 그래서 창업자인 뮬렌웨그는 자연스럽게 전 직원이 리모트 워크로 일하는 회사를 세우기로 한다. 사실 좀 더 정확히 말하면 그는 그 방법밖에 없다고 생각했다.


“처음 시작할 때 우리는 전부 오픈소스 개발자였습니다. 그래서 리모트 워크가 회사를 만들 수 있는 유일한 방법처럼 보였습니다.”
- 맷 뮬렌웨그, 비즈니스인사이더


창업 당시 직원의 출신지만 봐도 영국, 텍사스, 샌프란시스코 등 다양했으니 리모트 워크 외엔 다른 방도가 없었을 것이다. 그 덕분에 오토매틱은 인재 채용에 있어 공간의 제약을 받지 않는 기업이 될 수 있었다. 구글, 애플, 페이스북 등 유명 테크 기업의 본사가 몰려 있는 실리콘밸리에서는 ‘인재 채용 전쟁’이라고 부를 정도로 능력 있는 인재를 모시려는 기업의 구애 작전이 치열하다. 직원의 몸값도 나날이 높아지고, 임대료와 같은 생활비도 덩달아 살인적으로 높아지며 이를 보상하기 위해 다시 연봉을 올리는 악순환이 계속되고 있다. 작년 4월 월스트리트저널에서 발표한 바에 따르면 평균 연봉이 가장 높은 곳은 페이스북으로 중위 소득이 24만 달러(약 2억6000만 원)에 달한다.

반면 리모트 워크 기업이라면 공간의 제약을 벗어나서 미국은 물론 전 세계에서 유능한 인재를 채용할 수 있다. 최근 TED를 통해 공개한 영상 ‘원격 근무가 비즈니스에 더 좋은 이유(Why working from home is better for business)’에서 뮬렌웨그는 이를 낚시에 비유했다. 수많은 낚시꾼이 있는 좁은 호수보다는 넓은 바다에서 낚시하는 편이 훨씬 더 많고 다양한 물고기를 낚을 수 있다. 실제로 오토매틱은 굉장히 다양한 국가에서 직원을 채용하고 있다. 2019년 1월 현재 800여 명의 직원이 속한 국가는 총 68개국이고 사용할 수 있는 언어는 84개에 이른다.

비단 실리콘밸리가 아니라도 인재를 구하는 데 어려움을 겪는 것은 어디나 마찬가지다. 이에 관해 전 직장에서 들었던 일화가 있다. 당시 회사 대표가 뉴욕에서 동종 업계에 있는 이들과 종종 모임을 가졌는데 하나같이 직원 채용이 어렵다고 하소연을 하더란다. 비용도 비용이지만 능력 있는 인재를 찾기도 어렵다는 것이었다. 그때 내가 다니던 회사는 이미 개발자 대부분을 한국에서 고용하고 있었다. 대부분 원격근무 형태로 일했다. 대표는 그들의 하소연을 들으며 ‘한국에서 찾으면 해결될 텐데!’라고 속으로 생각하고 혼자 뿌듯해하며 혹여 경쟁자를 늘릴까 봐 알려주지 않았다고 한다.

넓은 인재풀 확보 외의 장점도 있다. 뉴욕 역시 실리콘밸리 못지않게 물가가 높기로 유명한 도시이기 때문에 직장인의 연봉 수준이 높게 책정돼 있다. 따라서 한국에서 직원을 채용하면 뉴욕에 비해 적은 연봉으로 우수한 인재를 채용할 수 있어 경제적인 면에서도 이득이 된다. 그리 크지 않은 스타트업이라 비용에 민감한 당시 회사의 대표에게 굉장한 매력으로 다가왔음은 물론이다.


규모가 커져도 수평 조직은 유지될 수 있다
먼저 수평 조직이 무엇인지 짚고 넘어가 보자. 수평 조직을 얘기할 때 팀보다 상위 계층이 없어야 한다거나 관리자가 없어야 한다고 생각하는 경향이 있다. 하지만 수평 조직은 조직의 구성 형태가 아닌 의사결정 방식을 일컫는 말로 봐야 한다. 1999년 존 허즈번드(Jon Husband)가 주창한 ‘Wirerachy’라는 개념은 수평 조직의 특성을 잘 나타내준다. Wirearchy란 상호 연결된 구성원들과 기술에 의해 가능해진 정보, 신뢰, 결과 중심주의에 기반한 권력과 권한의 동적인 양방향 흐름을 의미한다. 특정 계층만 권한을 독점하고 있다면 수평 조직이라고 볼 수 없다.

수평 조직을 지향한다면서 ‘OO님’이나 영어 이름으로 호칭을 통일하고 복장을 자율화해서 반바지를 입고 다닌다 한들 의사결정 구조가 변하지 않으면 아무 소용없다. 얼마 전 읽은 글에서 호칭을 모두 ‘OO님’으로 통일한 국내 모기업의 회의에 협력 업체로 들어갔는데 임원진이 실무진에게 “OO님이 이렇게 해주시면 되겠네”라며 호칭 외에는 이전과 전혀 달라진 게 전혀 없어서 웃음이 났다는 내용을 본 적이 있다. 이는 본질은 외면한 채 수평 조직의 외형만 따라 한 ‘수평조직룩(- look)’이나 다름없다.

2010년 무렵 오토매틱의 직원 수는 2005년 창업 이래 50여 명까지 늘어났지만 여전히 모든 직원이 창립자인 뮬렌웨그에게 직접 보고하는 형태로 운영되고 있었다. 당시 CEO는 야후 출신의 토니 슈나이더였는데 업무가 감당하기 어려울 정도로 복잡해지자 그제야 50명의 직원을 10개 팀으로 나누기로 했다. 그리고 이것만으로는 부족했는지 실험적으로 외부에서 팀장을 한 명 더 영입하기로 한다. 그가 바로 오토매틱의 문화에 대한 책 『바지 벗고 일하면 안 되나요?(제이펍)』를 지은 스콧 버쿤이었다. 그는 입사 전부터 조직문화와 경영 관리에 관한 책을 저술하고 강연을 하던 사람이다. 뮬렌웨그가 그에게 경영 관련 컨설팅을 받았는데 나중에는 아예 영입하게 된 것이다. 이로써 창립 5년 만에 처음으로 위계라는 것이 생겼다.

직원 수가 800명이 넘는 지금은 팀은 물론 팀을 총괄하는 부서도 생겼고 필요에 따라 팀 내부에 하부 팀을 두기도 하는 식으로 체계는 훨씬 더 복잡해지고 각 팀이 하는 일은 점점 전문화됐다. 당연히 팀과 부서마다 관리자도 존재한다. 하지만 커뮤니케이션 문화 자체는 크게 변하지 않았다. 언제든 누구와도 자유롭게 커뮤니케이션할 수 있다. 그 대상이 뮬렌웨그라고 해서 예외는 아니다. 뮬렌웨그 역시 주기적으로 업데이트되는 보고 외에 질문이 있을 때는 해당 팀의 채팅방이나 블로그에 글을 쓰거나 댓글을 남기고, 이를 본 사람이 알아서 답변을 남긴다. 같은 규모의 한국 회사에서는 아마 찾아보기 어려운 풍경일 것이다. 지난해 오토매틱의 데이터팀에서 시각화한 커뮤니케이션 집적도 그래프 2 에 따르면 대체로 그룹별 커뮤니케이션이 활발하지만 그 중심에는 뮬렌웨그가 있음을 알 수 있다. (그림 1)





커뮤니케이션은 산소다
버퍼(Buffer)라는 또 다른 리모트 워크 기업은 자사 블로그를 통해 리모트 워크에 다섯 단계가 있다고 주장했다. 3


● 1단계: 사무실에서 일하는 시기. 리모트 워크를 시작하기 전 단계다.
● 2단계: 주로 사무실에서 일하지만 재택근무도 가능한 단계. 국내 여러 스타트업이 도입한 리모트 워크의 초기 형태다.
● 3단계: 모두가 리모트 워크를 하지만 단일 시간대에서만 일하는 단계.
● 4단계: 전 세계에 분산된 여러 팀이 여러 시간대에서 일하는 단계. 팀 단위로 시간대가 다르고 같은 팀끼리는 같은 시간대에 일하는 형태다.
● 5단계: 구성원들이 어디서든 언제라도 완전히 자유롭게 일할 수 있는 단계.


오토매틱의 근무 형태는 완전한 리모트 워크인 5단계에 해당한다. 언제 일해도 상관없다는 의미는 바꿔 말하면 나와 업무 시간이 같은 사람이 없을 수 있다는 의미가 된다. 같은 도시에 살아도 업무 시간은 다를 수 있다. 그래서 완전한 리모트 워크 환경에서 커뮤니케이션은 기본적으로 질문이나 요청에 대한 즉각적인 응답을 기대할 수 없는, 이른바 비동기(asynchronous) 커뮤니케이션이다. 이러한 응답 지연은 리모트 워크를 처음 시작한 사람들이 겪는 최초의 장벽이기도 하다.

예전에 어떤 모임에서 ‘안녕하세요’로 시작하는 메신저 대화가 짜증 난다는 말을 들었다. 이유인즉 이랬다. ‘안녕하세요’만 오는 경우 본인도 ‘안녕하세요’밖에 보낼 말이 없고 그러면 상대는 ‘요청할 사항이 있는데 시간 괜찮으세요’ 말만 하고 괜찮다고 말하면 그제서야 비로소 용건이 나온다는 것이었다. 한창 집중해서 일하는 중이었는데 메신저로 이야기를 하느라 흐름이 끊겨버렸다. 진짜 필요한 대화를 하기까지 약간의 시간이 있었음에도 불구하고 본인 업무를 다시 시작하기엔 모호해서 결국 시간을 허비하게 됐다. 차라리 처음부터 용건을 말했더라면 처리한 후 업무를 다시 시작할 수 있었을 거라고도 덧붙였는데, 오토매틱에서 이뤄지는 커뮤니케이션은 대체로 그와 같다. 간단한 인사말과 함께 바로 용건을 메시지 창에 남겨두는 게 일반적이다.

그런데 사무실 근무자들은 메신저가 어디까지나 보조적인 도구에 불과하기 때문인지 대체로 이런 비동기 커뮤니케이션에 익숙하지 않은 것처럼 보인다. 같은 사무실에서 일하는 중 급한 문제가 있다면 담당자에게 전화를 걸거나 자리로 찾아가면 된다. 리모트 워크에서는 그게 불가능하다. 미국에 살고 있는 내 동료들과 나처럼 아예 일하는 시간대가 정반대로 어긋날 수도 있고, 시간대가 같다고 한들 내가 자리를 비웠을지 여부를 알 수 없다. 문제가 생겨도 나에게 메시지를 보내는 게 고작일 것이다. 내가 언제 볼지 알 수 없는 상태로 말이다. 만약 내가 어제 작업한 코드에서 큰 문제가 발생했는데 하필 내가 자리에 없다면 어떻게 되는 걸까? 수습할 수 없는 문제를 만들어놓고 자리를 비운 나를 해고하는 것으로 이야기가 끝날까?

여기서 ‘커뮤니케이션은 산소다(communi cation is oxygen)’라는 사내 격언의 한 구절이 등장한다. 저 격언과 함께 커뮤니케이션의 중요성을 너무 강조해서 입사 초기에는 중요한 건 알겠지만 조금은 유난 떠는 거 아닌가 싶을 정도였다. 사내 공식 매뉴얼에서 뉘앙스 조절, 피드백 주기/받기, 글 쓰는 방법 등 커뮤니케이션과 연관된 여러 주제를 찾을 수 있으며 관련 사내 강의도 자주 열린다. 지난 몇 년간의 관찰 및 경험과 내가 직접 받은 피드백을 통해 리모트 워크에서 꼭 필요한 커뮤니케이션의 요소를 다음과 같이 3가지로 정리해봤다.


● 주기성: 너무 잦을 필요는 없지만 충분한 빈도(작업당 최소 1일 1회)로 커뮤니케이션해야 한다. 실제로 일을 하는지, 안 하는지 알 수 없는 근무 형태이므로 시간이 오래 걸리는 작업이라면 ‘거래처로부터 응답을 기다리고 있음’과 같이 해당 작업이 진행되지 못하고 있는 이유를 알려줘야 한다.
● 응답성: 누군가 내가 진행 중인 작업에 관해 물었거나 혹은 다른 이유로 문서나 채팅 등에서 나를 언급했다면 설령 ‘잘 모르겠다’는 말이라도 응답을 해주는 것이 좋다. 업무일 기준 24시간 이내의 응답이 권장된다.
● 투명성: 회사 내에서 일어나는 모든 커뮤니케이션은 공개가 원칙이다. 잡담, 면담 또는 사적인 부탁을 비공개 채널로 요청하는 경우는 있지만 비공개 채널에서 회사와 관련 있는 의견이나 결론 등이 도출됐다면 내용을 정리해 공개한다.


앞서 든 사례를 다시 살펴보자. 내가 작성한 코드에 문제가 생기면 다음과 같이 일이 진행된다.


● 보고: 누군가 공개적으로 해당 문제를 언급한다. 주로 각 부서나 프로젝트 채팅방에 와서 보고하는데 해당 부서가 확실하지 않은 경우에는 회사 전체 구성원이 참여하는 채팅방에서 물어보고 부서를 특정하기도 한다.
● 확인: 가능한 사람이 누구라도 문제를 재차 확인해보고 자신에게도 발생하는 문제라고 판단되면 보고를 덧붙인다. 때로는 문제가 생긴 원인까지 찾아서 추가 정보를 제공하기도 한다.
● 수정: 문제를 빨리 수정하는 게 어렵다면 일단 문제가 된 부분만 문제 발생 전으로 되돌린다.
● 피드백: 최초 보고자와 업무 관련자를 참조해 보고된 문제가 어떤 식으로 처리됐는지 알려준다.
앞서 커뮤니케이션에서 중요한 요소 중 하나로 든 ‘투명성’은 두 번째 단계 ‘확인’ 과정에서 큰 힘을 발휘한다. 모든 정보가 공개돼 있기 때문에 적절한 검색 방법을 활용하면 대체로 원하는 정보에 접근할 수 있다. 해당 문제는 왜 생겼는지, 업무에는 누가 관련됐는지 등 때로는 문제를 해결할 방법도 찾을 수 있다. 적어도 회사 내부에서라면 담당자만 알고 있는 정보는 없다. 그 덕분에 누구라도 나를 대신해 문제를 수습하거나 질문에 답변해주는 게 가능하다. 그뿐만 아니라 단순한 질문은 아예 해당 부서에 묻기 전 검색을 통해 해결하는 게 일반적이다. 휴가 중에 업무 자료를 내놓으라고 닦달하는 전화를 받는 안타까운 상황은 애초에 존재하지 않는다.


적절한 도구가 커뮤니케이션 비용을 낮춘다
조직이 커지면 커뮤니케이션 비용이 증가한다. 업무가 세분될수록 담당 부서를 찾는 것도 어려워진다. 오토매틱에서는 이런 문제를 해결하기 위해 다양한 기술을 적극적으로 활용한다. 블로그 소프트웨어가 주력 상품인 회사답게 커뮤니케이션의 중심은 블로그가 차지하고 있지만 예전에 직원들은 내부 블로그보다 트위터를 훨씬 더 열심히 사용하고 있었다고 한다. 그래서 트위터와 비슷한 사용자 인터페이스를 갖추고 조금 더 가볍고 빠른 커뮤니케이션이 가능한 P2라는 워드프레스 테마를 제작해서 사용하기 시작했다. 뮬렌웨그는 자신의 블로그를 통해 2009년 P2를 도입한 후 60일 만에 1100건의 게시물이 작성됐다고 전했다. 전체 게시물의 23.4% 정도였다.

내부 블로그는 팀별, 지역별, 프로젝트별, 관심사별 등 다양한 목적으로 만들어진다. 외부 홍보 프로젝트를 위한 블로그, 마케터를 위한 블로그, 유럽인을 위한 블로그, 고양이를 키우는 사람을 위한 블로그 등 전체 블로그의 개수는 500여 개에 달한다. 게시물은 관련 문서 링크를 전부 포함하고 있어 처음 보는 사람이라도 해당 내용을 쉽게 파악할 수 있다. 관련이 있을 법한 실무자나 팀도 모두 참조한다. 참조된 사람에게는 게시물이 업데이트되거나 댓글이 작성될 때마다 알람이 간다. 토론이 필요한 내용은 댓글로 토론이 이뤄지고, 어느 정도 합의점에 이르면 위키피디아 같은 형태의 사내 매뉴얼인 필드 가이드(Field Guide)로 옮겨 적어 공식 매뉴얼로 만든다. 필드 가이드는 직원 누구라도 작성하고 수정할 수 있다. 적절한 검색어만 입력하면 클릭 한 번으로 원하는 자료를 찾을 수 있도록 내부 블로그 검색 엔진도 운영하고 있다.

매출, 페이지뷰, 가입자 수, 쿠폰 사용 횟수와 같은 민감한 통계 자료도 모든 구성원에게 공개돼 있으므로 원한다면 클릭 몇 번으로 실시간 데이터를 확인할 수 있다. 굳이 다른 부서에 요청할 일이 없다. 설령 만들어진 자료가 없더라도 이미 공개된 빅데이터를 조회할 수 있는 도구를 사용해 자신이 원하는 데이터만 추출할 수도 있다. 비슷한 자료를 조회하는 일이 반복되면 전용 도구가 만들어지곤 한다.

정보가 모두 공개돼 있으니 정보의 독점에서 오는 권력도 없고, 부서끼리의 알력 다툼도 없다. 우리 부서가 아는 데이터와 다른 부서가 아는 데이터에 차이가 없기 때문이다. 아마 대부분의 오토매틱 직원은 정보의 불균형을 발견했을 때 블로그 글을 작성해야겠다는 생각을 할 것이다. 적어도 나는 현재까지 그런 순간을 경험조차 하지 못했지만 말이다.




평가와 관리는 어떻게 이뤄질까
리모트 워크 환경에 관해 얘기할 때마다 오토매틱은 직원들을 어떻게 평가하고 관리하느냐는 질문을 듣는다. 앞서 언급한 책 『바지 벗고 일하면 안 되나요?』에는 스콧 버쿤이 오토매틱에 입사한 후 팀원들과 첫 면담을 하는 장면이 등장한다.



자리를 뜨기 전에 나는 팀원들과 한자리에서 만나면 물어보고 싶었던 질문 두 가지를 했다.

“오토매틱에서는 여러분의 업무 성과를 어떻게 판단하나요?” 그들은 동시에 어깨를 으쓱했고 그 모습에 나는 웃음을 터트렸다. (중략) 그들은 아무도 그 문제를 신경 쓰지 않았다. 회사에서 그 문제를 강조한 적이 없었기 때문이다.



오토매틱의 사내 매뉴얼은 팀장의 역할을 팀 구성원이 더 나은 성과를 내도록 돕는 조력자로 규정한다. 실무자의 의견에 권위가 부여되는 업무 중심 문화에서 팀장이란 전통적인 개념의 상사나 관리자가 아닌 “관리를 주 업무로 하는 동료”다. 오토매틱에서 팀장이 되는 것은 새로운 역할이 주어진 것일 뿐 승진이 아니다.

그렇다고 오토매틱에 관리나 평가가 아예 없다는 의미는 아니다. 국내 기업에 근무할 때 하던 식으로 팀장이나 동료에게 점수를 매기는 정량적 평가는 하지 않지만 6개월에 한 번씩 동료나 팀장에 대해 피드백을 보내는 방식으로 평가한다. 스스로에 대해 평가할 수 있는 셀프 피드백도 6개월에 한 번씩 요청받는다. 물론 팀장도 팀원에 대한 피드백을 보낸다. 나는 이 과정에서 내가 겪었던 한국 기업 문화와 크게 다른 두 가지 점을 발견했다.

첫 번째, 피드백이 의무가 아닌 선택이라는 점이다. 예를 들어, 셀프 피드백에는 딱 두 가지 문항이 존재하는데 지난 6개월간 가장 잘한 일 하나를 기술하라는 것과 그 일이 회사가 추구하는 목적에 어떻게 도움이 됐는가 하는 것이었다. 셀프 피드백을 쓰려고 하다가 막상 6개월간 했던 일 중 하나만 꼽을 정도로 거창한 일이 생각나질 않아 보내지 않은 적이 있다. 하지만 이와 관련해 인사팀이나 팀장으로부터 어떠한 독촉도 받지 않았다. 두 번째, 팀장이 인사팀에 보내는 것까지 포함한 모든 피드백은 당사자에게 원본 그대로 공유하는 게 원칙이라는 점이다. 회사에서 사용하는 정확한 용어로 말하면 ‘강력 권장(strongly recommended)’이다. 어떻게 하면 더 나은 구성원이 될 수 있을지 꼼꼼하고 세심하게 적은 동료들의 의견은 나의 성장에 많은 도움이 됐다. 오로지 업무 성과만으로 객관적인 평가가 이뤄지는 것도 리모트 워크 환경이 지니는 장점이다.

업무는 가능한 작은 단위로 나눠 관리한다. 그렇게 하는 게 일의 추이를 추적하기 쉽고 작업하는 입장에서도 언제 끝날지 모르는 막대한 규모의 업무를 다루는 것보다 작은 일 여러 개를 처리하는 방식이 더욱 소화하기 편하다. 업무 관리 도구에서 ‘진행 중’ 상태의 일을 ‘완료’ 상태로 변경할 때 성취감도 느낄 수 있어 업무를 지속하는 동력이 되기도 한다. 앞서 언급했듯이 단 한 문장이라도 추이를 매일 기록하는 것이 원칙이기 때문에 훑어보는 정도로도 잘 진행되는 업무와 그렇지 않은 업무를 금방 파악할 수 있다. 대체로 하루 이틀 정도면 완료할 수 있는 크기로 작업을 설정하므로 며칠이 지나도 진척이 없는 일은 관리자들에게 적신호나 다름없다. 담당자에게 해당 업무에 자신이 알지 못하는 문제가 없는지, 무엇을 도와줘야 할지 적극적으로 의견을 묻는다. 이런 일을 몇 번 겪고 나면 실무자 입장에서는 언제쯤 관리자들이 개입하게 될지 감이 생기고 그런 일이 생기기 전에 미리 도움을 요청하기도 한다. 내가 도움을 요청했을 때 지금까지 모든 관리자가 ‘미리 말해줘서 고맙다’라고 말한 점도 인상에 깊게 남았다.

지속적인 동기부여도 주요 관리 대상이다. 앞서 언급한 업무 몰입도 조사에도 동기부여와 관련한 몇 가지 항목이 있고 1∼2주마다 주기적으로 하는 1대1 면담에서도 수시로 관련 질문을 받곤 한다. 관리자들은 혹여라도 실무자들의 업무 의욕에 영향을 미치는 일이 없는지 늘 촉각을 세우고 있는 듯 보였다. 얼마 전 2주 정도 작업했던 기능이 다른 팀에서 우려를 표하는 바람에 출시되지 못할 상황이 생겼다. 애정을 가지고 노력했던 일이니만큼 해당 기능이 완전히 사라지는 건 썩 유쾌하지 않다는 의견을 팀장에게 전달했다. 사실 그 직후 원만한 합의를 통해 출시는 하되 일반 사용자들에게는 노출하지 않는 것으로 마무리했기 때문에 내가 속상해 할 원인은 이미 제거됐음에도 불구하고 팀장은 해당 기능이 어째서 비활성화돼야 했는지, 내 기분은 어떤지 그 후 한 달간 열심히 설명하고 확인하려 했던 기억이 있다. 내가 어째서 기분이 좋지 않았는지, 그리고 지금은 왜 기분이 나아졌는지 더 길게 설명하지 않았더라면 아마 팀장의 걱정은 계속됐으리라.


“우리는 결과로 업무를 평가합니다. 얼마나 일했는지는 신경 쓰지 않아요.”
- 맷 뮬렌웨그, 하버드비즈니스리뷰 2014년 4월 호


뮬렌웨그가 말한 바와 같이 오토매틱에는 결과 위주의 평가 문화가 정착돼 있다. 단순히 코드 몇 줄 작성, 매출 몇 % 성장 같은 정량적인 성과 평가를 말하는 게 아니다. 오토매틱은 끊임없이 새로운 시도를 하고 있기 때문에 그 과정에서 실패도 많이 경험하고 가끔은 그런 문제가 일반 사용자에게 노출되기도 한다. 그렇지만 실패를 통해 배우고 똑같은 실수를 반복하지 않도록 노력하는 것 또한 문화로 정착돼 있어서 실패도 하나의 성과로 받아들인다. 애초에 회사의 근간이 된 워드프레스는 다른 블로그 소프트웨어의 실패에서 탄생했다. 당시 뮬렌웨그가 잘 사용하고 있던 블로그 소프트웨어 프로젝트가 중단돼 버린 까닭에 새로운 블로그 소프트웨어를 만들기로 한 게 워드프레스의 시발점이었기 때문이다.

얼마 전에 내가 만들었던 기능이 문제를 일으켜서 특정 경로로 접속한 신규 회원이 가입을 할 수 없는 오류가 생겼다. 업무 프로토콜에 따라 동료들의 검토와 승인을 받은 코드였음에도 문제가 일어난 것이다. 내가 잠든 사이에 일어난 일이라 그 시각에 근무하고 있던 팀원이 내가 만들었던 기능을 원래대로 되돌려뒀다. 아침에 일어나 문제를 확인하고 빠르게 해결했지만 처음 보고를 받았을 때는 꽤 놀랐던 기억이 있다.

중요한 건 그다음이다. 팀장은 내게 비공개 채널로 말을 걸어 어째서 이런 문제가 생겼는지 정확히 알고 싶어 했고, 앞으로 이런 문제를 예방하려면 어떻게 해야 할지 의견을 물어왔다. 혹시 내가 이 과정을 비판으로 받아들일까 봐 몇 번씩 대화의 정확한 목적이 문제의 확인과 예방임을 강조했다. 어느 정도 의견이 정리되자 팀장은 내게 앞서 나누었던 얘기를 회고 문서로 만들어서 다른 구성원들에게 공유해 줄 수 있겠냐고 요청했다. 쓰기 어려우면 본인이 하겠다는 말도 덧붙였지만 아무래도 해당 업무는 내가 잘 알기에 자발적으로 문제가 시작된 원인, 경과, 예방을 위해 했던 조치까지 담아 문서로 만들어 공유했다. 문서를 쓰는 중에 문득 지금 내가 작성하고 있는 것은 ‘시말서’의 사전적 의미와 정확하게 일치한다는 것을 깨달았다. 다행히 국내 회사에 근무할 때는 한 번도 써본 적이 없지만 시말서라고 하면 징계의 일종으로 생각했지 이런 미래 지향적인 문서일 거라는 생각은 전혀 해보지 못했다. 다른 이들이 공개한 문서와 마찬가지로 내 회고 문서에도 ‘이렇게 자세히 공유해줘서 고맙다’라는 댓글이 이어졌다. 내가 예방책으로 마련한 자동화 도구를 통한 검사는 동료들이 비슷한 문제를 반복하지 않도록 도와줬다. 기능을 출시하기 전에 에러 메시지를 보고 고친 덕분이었다.


채용은 오디션이다
창립자인 뮬렌웨그는 하버드비즈니스리뷰와 가졌던 인터뷰에서 다소 길고 복잡한 오토매틱의 채용 절차를 ‘오디션’에 비유했다. 단순히 이력서나 짧은 면접만으로 채용 여부를 결정하지 않고 시간과 비용이 들더라도 실제 업무와 비슷한 환경을 제공하고 능력을 발휘할 기회를 주기 때문이다. 대부분의 직원은 짧게는 몇 주부터 길게는 9개월까지 걸려서 입사한다.

오토매틱의 채용 절차는 다소 길고 복잡하다. 소프트웨어 개발자의 경우, 채용 절차는 서류 전형, 면접, 코드 인터뷰, 트라이얼, 연봉 협상이라는 단계를 거치는데 모든 과정이 온라인으로만 진행되고 화상은커녕 심지어 전화 통화조차 하지 않고 이뤄진다. 전 세계 다양한 문화권에서 지원하기 때문에 이름만으로는 성별조차 알기 어려운 경우도 있다. 완벽한 블라인드 채용인 셈이다.





회사 채용 공고에 나와 있는 e메일로 이력서를 보내면 몇 주 안에 합격 여부를 알려준다. 면접을 온라인으로 한다는 점만 제외하면 우리가 흔히 아는 면접과 크게 다르지 않다. 면접관 역할을 하는 오토매틱 직원이 나에게 질문을 하고 내가 답을 하면 된다. 조금 특수한 점이라면 리모트 워크를 하는 회사이기 때문에 리모트 워크에 관련된 질문이 몇 가지 섞여 있다는 것이다. 예를 들면, 리모트 워크 경험은 있는가, 1년에 한두 달 정도는 여행을 다녀야 할 텐데 괜찮은가 등이 있었다.

이 과정이 지나고 나면 코드 인터뷰를 한다. 소프트웨어 개발자 이외의 직군에서는 다른 과정으로 대체되거나 아예 없을 수도 있다. 진짜 중요한 건 그다음인 트라이얼(trial)이다. 코드 인터뷰가 최소한의 기술적인 업무 소양을 갖췄는지 보는 거라면 트라이얼 과정은 정말로 우리 회사에서 일을 잘할 수 있는 인재인지 보는 과정이다. 가장 길게 진행되기도 하고 실제로 회사에서 진행하고 있거나 진행할 일을 구직자에게 의뢰하는 방식으로 이뤄지기 때문에 오토매틱은 구직자가 트라이얼 과정에 할애한 시간을 시급으로 지급한다. 시급은 시간당 25달러가 책정되는데 나중에 받을 연봉과는 상관없이 일괄적으로, 합격 여부와 상관없이 지급된다.

면접관은 트라이얼 과정을 계속 지켜보면서 적절한 시기에 피드백도 주고, 필요하다고 판단하면 트라이얼 과정을 조기 종료시키기도 한다. 오토매틱은 인터넷 기업답게 기술 직군의 수가 많다. 그 때문인지 엔지니어 채용은 다른 채용 과정과 조금 다른 면이 있으며 엔지니어 채용만 전담하는 부서도 따로 있다. 다른 직군과 달리 엔지니어 채용 과정의 면접관은 해당 실무 종사자가 아닌 전담 부서에서 맡는다. 단, 최근에는 입사 지원자가 많아서 해당 부서 인력만으로는 무리가 있는지 사내 공고를 통해 서류 전형 판단에 도움을 줄 자원봉사자를 구하기도 했다.

실제 업무를 하는 과정이니만큼 제품에 변화를 줄 때는 반드시 이유가 있어야 하고, 미심쩍은 부분이 있으면 반드시 누군가 댓글로 질문을 한다. 이 변화의 의도는 무엇인가, 다른 방식으로 해볼 수는 없는가, 해당 업무에 대한 회사의 표준 프로토콜은 이렇다 등 다양한 의견 교환이 댓글을 통해 이뤄진다. 앞서 말했듯이 오토매틱은 커뮤니케이션의 중요성을 끊임없이 강조한다. 이미 코딩 테스트를 통과한 뒤에 진행하는 과정이므로 트라이얼은 동료들과의 커뮤니케이션이나 협업을 더 중요하게 평가하는 단계라고 봐도 무방할 것이다. 내가 채용 과정에서 담당자로부터 받았던 피드백도 모두 커뮤니케이션에 관한 것이었다. 한 번은 당장 답하기 어려운 문제에 봉착해 해결책을 찾기 위해 며칠간 고민했던 적이 있다. 면접 담당자로부터 ‘직장이 따로 있는 상태에서 참여하느라 답이 늦는 것은 이해한다. 하지만 늦게 되면 언제까지 답을 줄 수 있을지라도 댓글로 남겨달라’는 피드백을 받고 아차 싶어서 그 후부터는 어떤 식으로든 코멘트를 남기려 노력했던 기억이 있다.

트라이얼 과정까지 통과하고 나면 CEO인 뮬렌웨그와 채팅을 통해 간단한 인터뷰를 하고 연봉을 협상하는 최종 관문이 기다린다. 내부적으로는 맷 챗(Matt Chat)이라 불렀던 이 과정에서 나는 비록 온라인이고 텍스트로 나누는 대화지만 세계적으로 유명한 CEO와 대화를 나눈다는 점 때문에 들떴던 기억이 있다. 뮬렌웨그는 많은 직원에게 최근 읽는 책을 묻곤 했는데 나중에 직원들끼리 서로 맷 챗에서 말한 책을 공유하기도 했다. 아쉽게도 현재는 회사 규모가 커지면서 인사팀과의 채팅으로 바뀌어서 사라진 단계다.


리모트 워크에서 발생하는 문제는 어떻게 다루나
이처럼 리모트 워크가 잘 맞는 사람에게 굉장히 즐겁게 일할 수 있는 환경을 제공하는 게 사실이지만 그렇다고 해서 모두에게 잘 맞는 방식이라고 생각하지는 않는다. 이 방식이 맞지 않는 사람도 분명히 있다. 리모트 워크가 가지고 있는 태생적인 문제도 있고 주변 환경이 문제일 수도 있다. 처음 입사했을 때 팀장이나 동료들이 가장 많이 묻는 말이 바로 ‘리모트 워크 환경에서 일하는 건 어떤가’였다. 입사 시점에서 이미 4년 넘게 리모트를 경험한 내겐 불필요한 질문처럼 느껴졌지만 알고 보니 오토매틱에서 직원들이 가장 많이 퇴사하는 시기가 바로 입사 후 3개월 이내라고 한다. 리모트 워크나 디지털 노마드 생활에 환상을 가지고 있던 이들이 막상 체험해보고 나니 자신의 생각과는 다른 현실을 깨닫고 관두는 것일 터다. 내가 직간접적으로 겪은 리모트 워크의 문제점은 다음과 같다.

첫째, 시간 관리가 어렵다. 돌이켜보면 리모트 워크를 막 시작한 처음 몇 개월간은 적정한 업무량을 찾는 게 가장 시급한 문제였다. 정해진 시간이 없다 보니 어떤 날은 일을 너무 많이 하기도 하고 또 어떤 날은 너무 적게 하기도 했다. 컨디션이 들쑥날쑥해져서 업무도 원활하지 않는 것 같은 느낌이었다. 다른 문제와 달리 이 문제만큼은 스스로 해결하는 수밖에 없다. 내가 했던 것처럼 익숙해지기 전까지는 출퇴근 시간을 스스로 정해두거나 포모도로 기법(Pomodoro technique) 4 과 같은 시간 관리 방법론을 도입해보는 것도 방법이 될 수 있다.

둘째, 외롭다. 아닌 게 아니라 꽤 큰 문제다. 지금도 그렇지만 처음 오토매틱에 입사했을 때는 회사에 한국인이 나뿐이었고 다른 팀원들은 모두 미국과 캐나다에 살고 있었다. 내가 적응할 때까지 보조를 맞춰주기 위해 동료 한 명이 자신의 평상시 업무 시간보다 조금 늦게까지 일을 했다. 그 후 팀을 옮겼을 때 비슷한 처지에 있던 호주 동료가 굉장히 기뻐했던 기억이 있다. 안타깝게도 나는 오후 늦게 일하는 것을 좋아해서 그 동료와 많은 얘기를 나누지 못했고 그 동료는 1년이 지났을 때쯤 퇴사했다. 새 직장은 출퇴근하는 곳이라고 했다. 리모트 워크를 도입한 유럽 회사에서 유일한 한국인으로 근무하는 사교적인 성격의 한 지인은 처음 리모트 워크를 시작할 무렵에는 사람들과 직접 대면하지 않는 점이 꽤 스트레스라고 하소연하기도 했었다. 몇 달 후 다시 만났을 때는 자유로운 시간에 그림도 배우고 운동도 다니며 굉장히 즐겁게 일하긴 했지만 말이다.

오토매틱에서는 근무자가 외로움을 느끼지 않도록 비슷한 시간대에 근무하는 동료들끼리 연결해주는 멘토 제도도 운영하고 있고, 지역별 채팅방을 운영하기도 한다. 원한다면 코워킹 스페이스나 카페처럼 조금 덜 외로운 공간에서 일할 수 있도록 앞서 말한 제도를 통해 일정 비용을 지원하며, 직접 동료들과 만날 수 있도록 1년에 2∼3회 정도 팀원끼리 한 장소에 모여 함께 일하면서 지내는 팀 미트업(team meetup)이나 회사 전 직원이 모이는 그랜드 미트업(grand meetup)도 진행한다.

셋째, 가족의 협조도 중요하다. 안방에서 작은방으로 출근하기 때문에 가족들이 일하는 것으로 봐주지 않는다고 한숨 쉬는 사례를 종종 봤다. 전 직장에서 함께 근무하던 동료는 부모님이 일하는 중에 자꾸 쓰레기를 버리고 오란다며 하소연했고, 또 다른 동료는 한창 호기심 많을 나이의 자녀를 피해 개인 사무실을 얻기도 했다. 인터뷰 중에 아이가 해맑게 들이닥쳤던 BBC뉴스의 영상을 기억하는가. 오토매틱에서도 팀 화상 회의를 하다가 비슷한 일을 겪은 적이 있다. 그 순간 회의 중이던 모든 사람이 삼촌, 이모 미소를 지었지만 말이다.

리모트 워크를 하는 사람들을 대상으로 조사한 한 설문 조사에서 업무 장소에 대한 질문에 78%가 ‘주로 집에서 일한다’라고 답했다. 5

공간을 공유하는 가족의 협조가 중요하다는 의미다. 『소프트 스킬』의 저자 존 손메즈(John Sonmez)는 자신의 가족들은 자기가 설령 집에서 일하고 있더라도 방해하지 않도록 급한 일이 아닌 용무는 e메일을 보내거나 본인이 휴식을 취할 때까지 기다렸다가 말한다고 밝혔다. 집중을 깨뜨리지 않도록 가족 구성원들과도 리모트 워크가 업무의 한 형태라는 공감대를 형성하는 게 중요하다.


완벽하진 않지만 시도해 볼 가치는 있다
최근 한 언론 보도에서 20·30세대를 중심으로 퍼져나가는 ‘언택트(untact) 문화’에 관해 읽은 적이 있다. 언택트는 접촉을 뜻하는 콘택트에 부정 의미의 접두사 ‘Un-’을 붙여 만든 신조어로 사람과 접촉을 최소화하고 비대면 형태로 정보와 서비스를 받는 것을 의미한다. 해당 기사는 또한 이 문화가 젊은 세대에서 두드러진 이유로 ‘관계로 인한 감정소비를 줄이기 위해’서라고 분석했다. 마찬가지로, 직장 생활을 하다 보면 사회적 관계에서 오는 불필요한 스트레스가 많다. 한 설문 조사에서 직장인 중 절반 이상이 가장 큰 스트레스 요인으로 ‘상사/동료와의 대인관계’를 꼽았을 정도다. 리모트 워크 환경에서는 관계로 인한 스트레스가 굉장히 줄어든다. 오히려 사람이 그리워지기도 한다.

리모트 워크가 직장 생활에서 오는 모든 문제를 해결할 만병통치약이라고 말하려는 건 아니다. 10년 넘게 지속해오는 오토매틱에도 리모트 워크 업무 환경은 여전히 진화 중인 실험이다. 하지만 분명 시도해 볼 가치는 있다고 생각한다. 앞서 언급한 리모트 워크 경험자 대상 설문 조사에서 응답자의 90%가 앞으로도 리모트 워크를 계속하고 싶다고 말했고, 94%의 응답자는 다른 이에게도 권하겠다고 답할 정도로 리모트 워크는 만족도가 높은 업무 환경이다. 지속하기 어려울 것이라는 항간의 의구심이 담긴 눈초리와는 다르게 오토매틱은 꾸준히 실적을 내고 있으며 내가 근무한 지난 2년 반 동안만도 300명 가까이 직원이 늘어나며 빠르게 성장하고 있다. 이제 800명이 훌쩍 넘는 인원은 리모트 워크가 작은 기업에서만 가능할 것이라는 오해를 불식하기에도 충분하다. 미국 경제 전문지 포천에 따르면 오토매틱의 기업 가치는 이미 2014년에 10억 달러(한화 약 1조1000억 원)를 기록했다. 6

8년째 리모트 워크를 하면서 느끼는 점은 이 근무 형태가 다른 방해 요소를 배제하고 오로지 효율적으로 업무를 진행하는 데 초점이 맞춰져 있다는 것이다. 기업에서 필요한 직원은 8시간 자리를 지키고 앉아 있을 사람인가, 아니면 효율적으로 성과를 낼 수 있는 인재인가. 후자라고 답했다면 리모트 워크가 좋은 선택지일 수도 있다.


필자소개 김태곤 오토매틱 프로그래머 taegon.kim@automattic.com
필자는 서울시립대에서 전자전기컴퓨터공학을 전공한 후 SK컴즈, 네이버, 팬시(Fancy)를 거쳐 현재는 오토매틱(Automattic)에서 자바스크립트 개발자로 근무하고 있다. 국내 1세대 프런트엔드 개발자로서 여러 콘퍼런스에서 발표하고 다수의 번역서를 출간했으며 웹 기술을 다루는 블로그(https://taegon.kim)를 운영하고 있다.
인기기사