스포카(Spoqa)의 크리에이터팀은 2016년 2월부터 리모트 시스템을 도입하기 시작했습니다. 1분 1초가 바쁜 스타트업 환경에서 리모트를 어떻게 도입했는지, 잘 되고 있는지 궁금해하시는 분이 많아 우리의 도입 과정을 공개합니다.

도입 동기

동기는 간단했습니다. 회사 사무실이 때로는 최고의 근무환경이 아니었기 때문입니다. 이유는 여러 가지였는데, 몇 가지 예시를 들어보겠습니다.

 

1. 직원 A: 주변 직원들의 지나친 인터럽트로 모두가 퇴근한 시간에 하루의 일을 시작할 수 있었습니다.
2. 직원 B: 다른 직원보다 더위를 더 잘 탔는데 무더운 날씨엔 일을 못 할 정도로 사무실 기온을 힘들어했습니다.
3. 직원 C: 집이 너무 멀지만 사정상 회사 가까이 이사 올 수 없어 매일 4시간씩 이동하며 일해야 했습니다.

 

따라서 우리의 리모트 도입은 기본적으로 모두가 집중해 근무할 수 있도록 장려하기 위해 시작되었습니다. 일부 기업이 복지로서 리모트를 도입하는 것과 반대되는 방향입니다. 집중 근무로 목표를 고정한 이유는 세부 규칙을 도입하는 데 있어 의견이 상충할 여지를 최소화하기 위해서였습니다.

메타 규칙

제가 여러 회사의 리모트 시스템과 과정, 베이스캠프(Basecamp)의 제이슨 프라이드(Jason Fried)와 DHH가 작성한 「리모트(Remote)」를 검토하며 알게 된 것은 팀에 따라 최적의 리모트 시스템은 다르다는 것이었습니다. 팀이 직면한 업무 유형, 팀의 수준, 취향, 성향 등 여러 요소와 관련되어 있기 때문인데요.

 

팀에 가장 이상적인 규칙을 만들기 위한 메타 규칙을 정하기로 했습니다. 리모트를 준비하며 가장 중요한 메타 규칙을 아래 4개로 선별했습니다.

 

1. 리모트 시스템을 악용할 여지가 있는 팀원은 없어야 한다.
2. 업무 시스템은 측정 가능해야 한다.
3. 주요 커뮤니케이션 채널은 어디서든 접근 가능한 방법이어야 한다.
4. 규칙은 1주에서 2주마다 점진적으로 실험하고 개선한다.

 

아래부터 각 메타 규칙을 자세히 설명하겠습니다.

 

1. 리모트 시스템을 악용할 여지가 있는 팀원은 없어야 한다.

 

가장 중요한 시작점입니다. 보통 리모트 시스템을 도입하려고 하면 이걸 누군가 악용하지는 않을까 걱정하게 됩니다. 우리는 기본적으로 신뢰할 수 없는 팀원은 내보내야 하며, 나머지는 측정으로 보완할 수 있다고 합의했습니다.

 

다행히 리모트 시스템을 도입하는 시점에서 이런 걱정거리가 있는 팀원은 없었지만, 만약 걱정되는 사람이 있다면 늦기 전에 어서 내보내시기 바랍니다. 리모트 시스템을 도입하지 않더라도 눈에 보이지 않을 때 일을 안 할 것 같은 사람과 같이 있는 것은 모두에게 시간 낭비입니다.

2. 업무 시스템은 측정 가능해야 한다.

 

아무리 신뢰로 똘똘 뭉친다 하더라도 무의식적 악용과 역량의 문제는 피할 수 없습니다. 우리는 이런 여지를 측정으로 보완합니다. 측정 가능하다면 어디서 일하든 업무 역량을 평가할 수 있습니다. 반대로 측정 불가능하다면 눈앞에서 일을 하고 있어도 업무 역량을 평가할 수 없습니다.

 

업무 역량을 평가하기 위해 우리는 깃허브 이슈즈(Github Issues)를 이전보다 더 적극적으로 활용하기로 했고 아래와 같이 쓰기로 했습니다. 각 회사에서 이미 쓰고 있는 이슈 트래킹 시스템이 있다면 아래를 참고해서 맞춰 적용하시면 됩니다.

 

1. 비 개발 업무를 포함해서 모든 업무는 이슈로 남기고 기록한다.
2. 매일 업무 진행 상황을 이슈에 남긴다.
3. 이슈에 기록이 없으면 일을 안 한 것으로 간주한다.
4. 먼저 월간 마일스톤에 이번 달 해야 하는 일들을 모두 집어넣는다.
5. 매주 월간 마일스톤에서 주간 마일스톤으로 이슈를 옮겨와서 작업한다.
6. 주간 마일스톤 내 이슈는 반드시 1명의 담당자가 있어야 한다.
7. 담당자로 지정된 업무는 반드시 해야 한다. 한 이슈의 담당자는 아주 자주 바뀌게 된다.
8. 핵심 측정지표는 마일스톤 내 달성률(처리한 이슈 / 처리하기로 한 이슈)이다.

 

마일스톤(milestone) 담당자 선정은 팀에서 지정된 오거나이저와의 협의로 정합니다. 우리 회사의 오거나이저는 일반적인 회사의 매니저와 비슷하지만 관리 의무는 낮고 실무를 함께 한다는 점에서 차이가 있습니다. 오거나이저의 목표는 팀원이 꼭 필요한 업무를 일정 내로 달성할 수 있도록 돕는 것입니다. 주어진 업무의 관리 의무는 기본적으로 팀원 개개인이 책임집니다.

3. 주요 커뮤니케이션 채널은 어디서든 접근 가능한 방법이어야 한다.

 

기존의 커뮤니케이션 채널은 사무실에서의 대화가 주류 채널이지만 리모트를 성공적으로 도입하려면 커뮤니케이션에서 장소 간의 차별이 없어야 합니다. 외부에서 일하는 순간부터 커뮤니케이션 채널에서 소외되면 업무 역량에서 불리한 위치에 있을 수밖에 없으며 이는 시스템적으로 직원들에게 리모트를 하지 않도록 권장하는 꼴이 됩니다.

 

우리는 주요 커뮤니케이션 채널로 슬랙(Slack)을 쓰기로 했습니다. 슬랙을 선택한 이유는 다음과 같습니다.

 

1. 깃허브, 센트리(Sentry), 서클CI(CircleCI), 행아웃(Hangout) 등 여러 외부 서비스 연동을 지원합니다.
2. 도구의 진입 장벽이 낮아 비 개발자도 쉽게 접근 가능합니다.
3. 윈도우, 맥, iOS, 안드로이드 등 여러 플랫폼을 지원합니다.
4. 연동 API가 잘 되어있어 우리 서비스 운영 시스템과의 연동이 쉬웠습니다.

 

슬랙 사용에 관심 있다면 우리를 통해 가입해서 100달러 크레딧을 무상으로 받으실 수 있습니다. 10개 이상의 서비스를 연동해 쓸 때는 크레딧이 필요하므로 꽤 유용할 것이라 생각합니다.

4. 규칙은 1주에서 2주마다 변경한다.

 

리모트를 전혀 안 하는 것은 9 to 6로 주당 월~금까지 40시간 모두 사무실에서 근무하는 것입니다. 반대로 완전한 리모트는 아무데서나, 언제나 40시간만 일하면 되는 것입니다. 우리는 최적의 중간점을 찾기 위해 아래와 같은 과정을 거칩니다.

 

1. 리모트의 속성을 정의한다.
2. 매주 하나씩 점진적으로 리모트의 속성을 추가/수정/삭제한다.
3. 1-2주 체험 후 장단점을 회고한다. 달성률을 측정해서 문제가 없었는지 검토한다.
4. 2번과 3번을 반복한다

 

이런 과정을 거치는 이유는 단 하나의 사소한 문제로 전체 리모트 시스템을 폐쇄하고 싶지 않기 때문입니다. 분명 어떤 속성은 팀에게 맞지 않고 부작용이 있는데, 사전에 설계한 여러 속성이 한꺼번에 적용되었다면 어느 것이 문제인지 알기 어렵습니다.

 

하나씩 적용하면 부작용이 발생했을 때 곧바로 어떤 이유 때문인지 쉽게 파악할 수 있으니 해당 이슈만 철회하면 됩니다. 서비스 배포 시스템에서 작게 더 자주 업데이트하는 것이 서비스 안정성을 향상시키는 것과 같은 원리입니다.

 

리모트 시스템을 검토하며 아래와 같이 리모트의 속성을 정리하고 하나씩 적용하기 시작했습니다. 여러 가지가 있지만 대표적인 것을 추려 언급하면 다음과 같습니다.

 

1. 주간 최대 리모트 시간: 주간 최대로 리모트 근무를 할 수 있는 시간입니다.
2. 하루 최대 리모트 시간: 하루 중 최대로 리모트 근무를 할 수 있는 시간입니다.
3. 최소 리모트 단위 시간: 리모트 시간 배분 시 최소로 설정할 수 있는 단위 시간입니다.
4. 공유 시간: 팀원 간 함께 근무를 해야 하는 시간 범위입니다.
5. 리모트 장소: 리모트가 가능한 장소의 범위입니다.

 

그리고 속성별 규칙은 이처럼 변화했습니다. 이 변화는 팀마다 차이가 날 수 있으므로 어디까지나 참고용으로만 여기시기 바랍니다.

 

1. 주간 최대 리모트 시간: 4시간으로 시작해서 4시간씩 늘려나갔고, 16시간까지 확대했습니다. 16시간이 되면서 팀원들이 이 이상의 리모트 시간은 불필요하다고 여겨 현재 유지 중입니다.
2. 하루 최대 리모트 시간: 4시간으로 시작했고, 곧 8시간으로 변경해 하루 전체를 리모트 가능하게 했습니다. 사무실과 먼 곳에 사시는 분들은 주로 하루 전체를 사용했고, 가까운 곳에 근무하시는 분들은 4시간씩 여러 번 리모트하는 것을 선호하고 있습니다.
3. 최소 리모트 단위 시간: 4시간으로 시작했고, 이후 자유로 해제해보았으나 서로의 협업 시간을 매주 확인하는 것이 번거롭다는 의견에 따라 다시 4시간으로 제한되었습니다.
4. 공유 시간: 10-19시로 시작했으며, 한 시간씩 줄여나가 13-17시로 변경되었습니다. 이 과정에서 공유 시간 내 접속 여부를 확인하기 위해 행아웃을 쓰기로 했으며 현재까지 잘 이용 중입니다.

좋은 점

리모트 도입 과정과 결과에 경영진과 실무진 모두 만족하며, 도입하기 전에 어떻게 일을 했는지 의아할 정도로 현재 시스템이 잘 안착한 상태입니다. 리모트를 도입하면서 느끼게 된 좋은 점을 정리하면 아래와 같습니다.

 

1. 사무실 자체의 문제로 업무 달성률이 하락하는 문제가 많이 사라졌습니다.
2. 도입 과정에서 업무 성과 측정 및 평가 시스템이 굉장히 정교해져서 각 팀원의 업무 현황 및 문제점 분석이 쉬워졌습니다.
3. 어디서든 업무 현황을 자세히 볼 수 있게 되어, 보고를 위한 불필요한 과정이 많이 생략되었습니다.

부작용

아래는 리모트 시스템을 도입하면서 생긴 부작용입니다. 대응책도 함께 말씀드리자면 아래와 같습니다.

 

1. 초기에 리모트 업무에 대한 미숙으로 달성률 하락이 종종 발생했습니다. 가령 구동 테스트를 해야 할 테스트 디바이스를 깜빡하고 다른 장소에 두고 와 테스트를 제대로 진행하지 못하는 실수를 하는 거죠. 숙달될 때까지 시간이 조금 필요합니다.
2. 리모트 시스템에서는 모두의 업무 현황이 실시간으로 공유되므로, 장소와 시간에 무관하게 업무 환경에 노출되어 업무 스트레스가 증가할 수 있습니다. 공유 시간 외 커뮤니케이션을 약속해 개선할 수 있습니다.
3. 이슈와 실제 업무의 싱크가 어긋날 때가 많습니다. 역시 업무 미숙에 따른 실수로 이를 끝까지 개선하겠다는 리더의 의지가 중요합니다. 싱크가 너무 안 맞는다면 업무를 평가할 수 없으므로 리모트를 중단하는 것이 낫습니다.

마치며

리모트 시스템을 도입하면서 배운 점은 리모트 근무가 가능한지 테스트해보는 것 자체가 팀의 업무 수준을 평가하는 아주 좋은 지표가 된다는 것입니다. 실제로 리모트를 반대하는 팀의 주장을 잘 생각해보면 리모트의 문제가 아니라 해당 회사의 업무 평가 시스템과 조직 문화가 진짜 문제임을 잘 알 수 있습니다. 측정과 평가를 제대로 할 수 있고, 서로 기본적인 신뢰만 있다면 근무자가 어디서 언제 일하는지는 중요하지 않습니다.

 

물론 구조적인 문제로 못하는 회사들도 있습니다. 야후는 직원들이 야후 외 프로젝트, 혹은 창업 준비를 위해 리모트를 악용하는 경우를 많이 발견했다고 하는데 이 또한 충분히 공감 가는 내용입니다. 이상적으로는 직원들 모두가 회사의 비전에 깊게 공감하면 이런 문제로 골치가 아플 일이 없지만 이미 충분한 성장을 한 회사나 공룡 회사라면 우리보다 더 복잡한 문제가 많을 테니까요.

 

여담으로 이 글에서 언급한 「리모트」는 전체적인 논리 전개에 있어 개인적으로 좋아하는 내용은 아닙니다. 리모트 시스템을 칭찬하기 위해 서로 상충할만한 여러 장점을 한꺼번에 호소하는 경향이 있기 때문입니다. 다만 리모트를 도입하겠다고 결심하셨다면, 그들의 도입 비결이나 일부 논리 전개는 초기 도입 준비 시 참고할만합니다.

필자 김재석 (블로그, 페이스북)

주식회사 스포카(Spoqa) 최고기술경영자. 서비스 개발을 총괄하고 있다. 새로운 아이디어와 사용자 경험, 여러 민첩한 개발 방법론에 관심이 많다.