리모트 도입기

스포카 개발팀에서 지난 반년간 리모트를 도입하고 경험한 것을 공유합니다.

Transcript

1. 리모트 도입기 스포카 개발팀 홍민희
2. 발표자 소개 • 주식회사 스포카 개발팀에서 도도 포인트 개발중 • 파이썬 프로그래머 • 자유 소프트웨어/오픈 소스 지지자 • 오픈 웹과 모질라 지지자
3. 스포카 소개 • 혹시 회사 이름이 스마트폰 포인트 카드를 세 글자 로 줄인 게 아닐까 하는 심증이 있습니다 • 카페 등에서 카운터에 QR 코드가 찍혀있고 스마트 폰 앱으로 그걸 찍으면 적립되는 서비스로 시작 • 잘 안됐다고 합니다
4. 도도 포인트 소개 • 카운터 앞에서 핸드폰 꺼내서 앱 켜는 게 너무 불편해서 적립율이 낮았다고 합니다 • 그래서 카운터 앞에 iPad를 두고 적립 고객이 전화번호 만 입력하게 하자는 아이디어로 도도 포인트 시험 적용 • CEO 아이디어였는데 CTO가 그딴게 될리가 없다고 생 각했다고 합니다
5. 도도 포인트 소개 • CTO가 CEO의 생각이 틀렸다는 것을 일부러 보여 주려고 대충 짠 코드로 퀵&더티 프로토타입 구현 • 근데 하루만에 적립율이 이전에 비해 13배나 증가 해서 CTO의 기대는 빗나갔습니다 • 그래서 저는 그 퀵&더티 코드 베이스 기반에서 일 하고 있습니다
7. 도도 포인트 소개 • 약 1,400개 매장 • 약 239만 적립 고객 • 일 평균 15,000건 적립
8. 도입 배경 • 빠른 성장 배경: 세일즈팀, 고객 지원팀, 제품 개발 팀의 삼위일체 • 없는 허상의 문제를 푸는 경우가 없음 • 개선점은 모두 고객과 긴밀하게 소통하며 얻음
9. 도입 배경 • 빠른 피드백, 짧은 반복? • 전반적으로 좋지만, 개발팀의 인터럽트가 점점 잦 게 되고… • 어떨 때는 애드혹한 요청을 처리하느라 하루 종일 아무런 개발을 못하게 되는 경우도
10. 도입 배경 • 모든 피드백이 같은 중요도를 가지는 것은 아님 • 고객 지원팀에서 급하게 봐 달라고 하면 결국 매장의 공유 기 문제인 경우가 태반 • 개발자가 가맹 매장 컴퓨터/인터넷 수리 기사가 되기도 • 고객 지원팀은 매장 주인이 화를 내면 마음이 급해지므로 개발팀 인터럽트를 무릅쓰고 쉽게 지원 요청함
11. 동기 • 최초 동기: 과도한 인터럽트, 어떻게 줄일까? • 고객 지원팀은 사무실에 있는 개발팀 아무나, 혹은 특별히 잘 받아주는 사람한테 찾아감 • 일단 사무실에서 도망가자! • 다른 팀에는 집중근무제라고 설명
12. REMOTE 37signals
13. 동기 • 마침 개발팀에서 37signals에서 쓴 REMOTE를 읽은 사람이 CTO 비롯해서 몇 있었음 • 사무실에서 집으로 도망치자! • 이렇게 원격 근무를 처음 시도해봄
14. 메타 규칙 • 가장 약한 리모트에서부터 점차적으로 강한 리모트 로 바꿔보자 • 별로면 언제든 되돌리자↩️ • 한번에 하나씩만 바꾸자
15. 첫 리모트: 가장 약한 리모트 • 일주일에 두 반나절 (약 4시간) 원격 근무 • 일단 사무실에 출근은 한다 • 점심 먹고, 인터럽트가 잦은 오후 시간만 리모트 • 합쳐서 연속으로 하루 종일 할 수는 없음
16. 첫 리모트: 가장 약한 리모트 • 어느 요일에 할지는 각자 선택 • 그러나 월요일에 사전 계획하여 팀에 공유 • 동시에 너무 많은 사람이 사무실이 비우지 않도록 하루에 세 사람까지만 리모트 가능
17. 대화는 어떻게? • 개발팀은 어떠한 채팅 서비스도 사용하지 않았음 • 오직 이메일만 사용해옴✉️ • 세일즈팀은 카카오톡으로 카톡방 운영 • 전사적으로 야머를 도입했지만 잘 쓰이지 않음☁️
19. Slack: 비동기 대화 • IRC 비슷한 기업용 채팅 서비스 • 비슷한 다른 서비스도 많음: HipChat, Campfire • 카톡과 달리 모든 사람에게 알림이 가지 않음 • 누가 날 언급하면(부르면) 알림이 옴
21. 첫 리모트의 위험 요소 • 자칫 잘못하면 리모트하는 사람들이 소외됨 • 기껏 만든 소통 채널(Slack)도 아무도 안 쓰는 공 간이 될 수도… 이전의 실패 사례(야머)도 존재 • 말로는 리모트를 해도 된다고 하면서도 은근히 서 로 눈치를 주면 어쩌나?
22. 부트스트랩: 의무 리모트 • 일주일에 두 반나절은, 의무적으로 사무실에서 나가야함 • 꼭 집에서 할 필요 없고, 근처 카페를 가도 괜찮음☕️ • CTO 포함 개발팀 전체의 의무 • 리모트 첫 주부터 Slack 채팅방 활성화 • 아무도 눈치 안봄
23. 첫째 주 회고 • 리모트할 때는 확실히 인터럽트가 줄었다 • 정말 중요하면 슬랙이나 전화가 오게 되었음 • 정말 중요한 요청이 아닌 것은 이메일로 오게 됨✉️ • 하지만 이왕 집에서 일할 거 출퇴근 스트레스 피할 수 있으면 좋을텐데…
24. 둘째 주 규칙 • 두 반나절을 합쳐서, 하루 종일 리모트하는 것도 허 용하기 시작 • 집이 먼 사람들은 아예 하루를 써서 출퇴근 스트레 스를 피하기도 • 사무실 근처에서 사는 사람들은 여전히 출근 후 오 후만 리모트하는 것을 선호하기도
25. 둘째 주 회고 • 두 반나절만으로는 부족하다! 감질난다! • 회의 같이 동시에 해야 하는 일이 아니면 굳이 리모 트하는 사람도 출퇴근 시간에 맞춰서 일해야 하나? • 일단 세 반나절로 늘리기로 결정 • 출퇴근 시간은 아직은 맞추기로
26. 다시 보는 메타 규칙 • 가장 약한 리모트에서부터 점차적으로 강한 리모트 로 바꿔보자 • 별로면 언제든 되돌리자↩️ • 한번에 하나씩만 바꾸자
27. 이후 변화들… • 공유 시간을 10시­–19시에서 11시­–17시로 축소 • 동시에 리모트 가능한 인원 제한 없앰 • 이틀로 짝을 맞추 수 있게 세 반나절에서 네 반나절로 확대 • 월요일에만 리모트 계획을 잡고 팀에 공지해야 했던 것을, 리모트 전날만 공지하면 되도록 완화
28. 이후 변화들… • 아직 리모트가 부족하다는 의견을 수렴하여, 다섯반나절로 확대 • 해보고 나니 다섯 반나절까지 필요 없더라는 의견을 수렴하여 다시 네 반나절로 축소 • 아예 리모트 계획을 전날이 아니라, 당일 오전에만 말하면 되도 록 수정 • 그런데 아무도 늦잠 외의 이유로 오전에 갑작스럽게 계획을 잡 는 경우가 없어서, 도로 하루 전에 계획을 잡는 것으로 돌아감
29. 다시 보는 메타 규칙 • 가장 약한 리모트에서부터 점차적으로 강한 리모트 로 바꿔보자 • 별로면 언제든 되돌리자↩️ • 한번에 하나씩만 바꾸자
30. 현재 규칙 • 일주일에 네 반나절 리모트 • 리모트 계획은 전날까지 정하고 팀에 공지 • 공유 시간은 13시­–17시 • 두 조로 나눠서 하루 중 아무 때나 행아웃 회의 • 월요일은 리모트 안하고 주간 회의 (리모트 제도 회의)
31. 교훈: 파라메터 러닝 • 리모트 규칙은 조직과 업무의 특성에 따라 최적해가 다를 수밖에 없음 • 따라서, 리모트 규칙이 아니라 메타 규칙을 따르자 • 규칙을 생성해내는 규칙 • 스포카에서도 개발팀과 디자인팀의 리모트 파라메터 가 많이 다름
32. 리모트의 활용 예 • 출퇴근 거리가 먼 사람은 일주일에 두 번은 출근을 아예 안함 • 아침잠이 많은 사람은 13시부터 근무 시작 • 일본에서 리모트한 사람도 둘이나 있음G • 리모트를 화요일과 목요일에 하면, 출근하는 월수금 모 두 금요일 같은 기분을 느낄 수 있음
33. 리모트의 부작용 • 출퇴근 같은 분명한 맺음이 보이지 않아서 초과 근무하 기 쉬움 • 이는 37signals의 REMOTE 책에서도 언급 • 제도적으로 초과 근무를 금지시키고, 스스로도 시간이 지나면 일을 중단하는 노력을 의식적으로 해야 함 • 스포카도 아직 완전히 해결하지 못한 문제
34. 기우였던 걱정 • 혹시 업무 생산성이 크게 떨어지는 것은 아닐까? • 리모트를 하면 마치 쉬는 날처럼 여겨지지 않을까? • 실제로 만나서 얘기하지 못하니 커뮤니케이션에 문 제가 있지 않을까? • 혹시 개발팀이 다 히키코모리가 되면 어떡하지?
35. 생산성 저하? • 물론, 분명 어떤 파라메터 (리모트 규칙) 조합에서 는 생산성이 저하됨 • 반대로, 파라메터 설정을 잘 하면 생산성이 올라가 기도 함 • 결국 메타 규칙을 잘 따르면 극복 가능한 문제
36. —―William Thomson, 1st Baron Kelvin “If you cannot measure it, you cannot improve it.”
37. 어려운 문제: 측정 • 생산성 측정을 하고 있지 않다면, 실상 생산성이 올 라갔는지 떨어졌는지도 알 수 없다 • 측정의 정밀도와 간편함 사이의 균형도 중요 • 물론, 생산성은 정량적으로 측정하기 힘든 분야니 꾸준히 정밀도를 올리려고 노력해야
38. 생산성 측정 • 생산성을 측정하면 “사무실에서 일하는 것”이 중요 하지 않게 됨 • 되려 실제 생산성이 중요하므로 각자 능률이 가장 잘 나오는 장소를 선택하게 됨 • 물론, 특정 측정 방식에 overfitting되지 않도록 꾸 준히 측정 방식도 개선해야
39. 리모트=쉬는 날? • 메타 규칙에 의해, 그렇게 느껴진다면 되돌렸을 것 • 실제로는 그런 이유로 되돌렸던 적도 없었지만… • 글쎄요, 왜 그렇게 안 느껴질까요?
40. 리모트=쉬는 날? • 정확히는 모르겠지만 제 가설은… • 슬랙이 휴일에도 쓸 정도로 카카오톡 정도의 존재감 이 됐음 • 슬랙이 조용하면 쉬는 날 기분이 남 • 하지만 슬랙이 활발하기 때문에 쉬는 날이라는 생각 이 전혀 들지 않음
41. 커뮤니케이션 문제? • 실제로는 채팅으로도 아무 문제 없는 것들이 대부 분 • 말이 필요한 일부 케이스는 행아웃으로 해결 • 정말 만나야 하는 것들은 월요일에 모아서 회의
42. 리모트의 부수 효과 • 부서간 커뮤니케이션 증가 • 의외로 잡담 채널이 활발 • 부서와 상관 없는 돌발/번개 저녁 모임이 잦아짐
43. 잡담 채널 • #random —― 아무나, 아무 얘기나 • #sig-foodporn —― 맛집 후기 및 공유 • #game —― 비디오 게임 • #sig-yeswecan —― 영어로만 대화하는 채널O • #sig-health-beauty —― 다이어트 및 미용 채널
44. 잡담 채널 • #sig-finance —― 재태크, 주식 투자 • #sig-dankbeats —― 음악 • #sig-jireumshin —― 지름신, 신기한 물건 공유 • #sig-bicycle —― 자전거, 자출 모임
45. Slack: 유비쿼터스 사무실 • 웹, 데스크탑 앱, 모바일 앱 지원 • 멘션한 메세지를 웹/데스크탑 앱에서 금방 확인 안하면 모바일 앱으로 알림이 감 • 모바일 앱에서도 확인을 못하면 1분 뒤에 메일로 모아서 알려줌✉️ • 당연히 내가 안 보고 있었을 때의 모든 대화가 로그됨
48. Slack • 모든 로그가 검색 가능 • 이미지, 파일 첨부 가능 • Google Drive의 스프레드 시트, 문서 공유 가능 • Dropbox, GitHub 등 외부 서비스 연동 • API로 쉽게 봇 제작 가능⛄️
49. Slack • 도도 관리자 페이지와 통합 • 담당 세일즈한테 매장 정보 노티 • 세일즈팀에서 카톡방 대신 써야할 동기 부여 • 개발팀은 배포 시스템도 연동
51. GitHub Issues • GitHub은 회사 초기부터 계속 써왔음 • 풀 리퀘스트 중심의 업무 • 그러나 첫 리모트 당시에는 이슈 트래커는 쓰지 않 고 있었음 • (과거 트렐로를 사용하다가 잘 쓰이지 않게 됨)
52. GitHub Issues • 개발팀 외에도 디자인팀도 이슈 트래커 함께 사용 • 지금은 개발팀에서 만드는 이슈보다 디자인팀에서 만드는 이슈가 훨씬 많고, 더 적극적으로 활용함 • 레이블 이름과 채팅 채널 이름을 맞춰서, 해당하는 채널에 이슈 진행을 중계하는 봇을 만듬
60. 기타 유용한 도구 • VPN을 써서 집에서도 사무실 환경에 접근 • 구글 캘린더를 써서 각자 리모트 계획과 미팅 일정 을 공유 • 행아웃을 써서 화상으로 미팅 (핸드폰으로도 가능)
62. 감사합니다 • 궁금한 것들이 있으면 물어보세요 • hongminhee@spoqa.com • twitter.com/hongminhee • hongminhee.org
63. bit.ly/spoqa-remote