이번 글에서 소개하려는 왓챠의 Fridave라는 문화는 CS팀과의 협업을 발판 삼아 회사가 안고 있는 비효율의 숙달화에 대한 문제를 해결하려는 시도이다
지속 가능함이란 | Photo by Chris Barbalis on Unsplash
요즘 회사 안팎에서 고민하는 것은 개인이 가진 한계에 대한 것이다. 다양한 환경에서 직면하는 문제를 해결하기 위해 개인은 재능이나 노력, 작은 도움으로 작은 사례를 만들어낸다. 대부분의 개인과 사례는 칭찬과 존경을 수반하지만, 애초 해결하려 했던 문제를 해결하기 위한 변화를 이끌어 내기에 개인은 작고 너무나 단편적이어서
와 나 존나 멋있었어. 하얗게 불태웠다.
로 끝난다. 결국 개인은 개인으로, 사례는 사례에 그쳐 흩어지는 것을 수없이 봐왔고 스스로도 경험했다. 변화는 다양한 사례가 모여 천천히 만들어 지는 것이라 생각하지만 사례들이 절로 변화로 이어지는 것은 아닐 것이다. 공감대만으로 참여가 뒤따라 변화의 힘이 갖춰지겠지만 대개의 경우 공감대를 참여로 이끌어 낼 수 있는 적절한 문화나 시스템이 필요하다. 문제마다 어떤 모습의 문화 혹은 시스템이 필요할 지는 매번 다르겠지만. 이번 글에서 소개하려는 왓챠의 Fridave라는 문화는 CS팀과의 협업을 발판삼아 회사가 안고 있는 비효율의 숙달화에 대한 문제를 해결하면서도 단지 개인과 사례로 그치지 않기 위한 시도이다.
고마워요 데인 😉
CS팀과의 작업을 한 뒤로 가장 많이 들었던 말은 ‘고마워요 데인’ 이었다(왓챠블로그 게으른 개발자와 부지런한 CS팀이 만났을 때 참조). 회사 내에서 업무로서 수행하는 일에 대해 고맙다는 표현은 지양하려고 하는데 네 팀의 일도 내 팀의 일도 결국 회사의 일이기 때문이다. 회사 안에서 타팀이 하는 일에 나를, 회사를 위하지 않는 일은 없다. 그래서 왜 고맙다는 표현을 자주 듣게 되었나를 생각해보면 아래 두가지 이유가 아닐까 싶다.
CS팀은 내가 했던 일이 업무 외의 일이라고 생각하기 때문에
실제로 이 일들은 대부분 업무 외의 시간에 이루어졌기 때문에
결국 이 두가지 이유를 해결하여 - 비효율적인 업무를 개선하는 것이 하나의 업무가 되고 업무 내 시간에 이루어지는 것 - CS팀과의 협업으로 이룬 것들을 단지 ‘와 나 존나 멋있었어, 하얗게 불태웠다’로 끝내지 않고 더이상 비개발 팀원들로부터 ‘고마워요 개발팀’이라는 표현이 생각나지 않게 하려면 어떻게 할까가 고민이었다.
Hacktoberfest 메인 로고 👕
Hacktoberfest
그런 고민 와중에 우리의 눈길을 끈 것은 11월 한달 간 진행되고 있던 Hacktoberfest였다. 간단히 소개하면 전 세계 오픈소스 프로젝트와 기여자들을 위한 행사로 개발자들은 11월 한달간 오픈소스 프로젝트 이슈 트래커에 등록된 이슈를 해결하면 된다. 이 후 Merge까지 된 Pull Request가 4개 이상이면 주최측 - Digital Ocean - 으로부터 티셔츠를 받을 수 있다.
규모 768명이 참여한 2014년 첫 이벤트(출처: 공식블로그) 이후 2019년 482,182개의 Pull Request가 열렸고 61,956개의 이슈가 해결되었으며 총 154,466개의 프로젝트(레포지토리수)가 참여했다(출처: 공식블로그). 5년새 실로 엄청난 규모를 가진 오픈소스 행사가 되었다.
그래 이거면 돼 👕 - 출처: 공식블로그
방식 우리가 주목한 것은 프로젝트 관리자와 기여하는 개발자의 관계, 그리고 그들이 오픈소스 참여를 이끌어내는 시스템이다. 이미 오픈소스는 전세계에서 상업적, 비상업적으로 엄청난 성공을 거두고 있고 개발자들 사이에서도 인기있는 활동이 되고 오픈소스 기여가 여러가지로 큰 의미를 지니게 되었다. 다만 그러한 공감대를 어떻게 실제 참여로 이끌어내냐는 것인데 이것을 Digital Ocean은 11월 한달이라는 한정된 기간을 지정하고 엄청난 보상(티셔츠 😊👕)을 걸어서 너무나 쉽게 해결해버렸다.
프로젝트 관리자들은 미리 행사 기간동안 처음 프로젝트를 접하는 개발자들을 위한 이슈들을 골라 good first issue라는 라벨을 달아놓는다. 코드뿐만 아니라 번역, 문서화까지 다양하다. 이렇게 진입장벽을 매우 낮춰놓으니 평소에 회사일 등으로 마음만 먹고 기여는 미루기만 하던 개발자들도 “오 그럼 이 기회에 한번 해볼까?”로 이어지는 것이다.
rust-clippy 프로젝트에 올라온 good first issue 목록
우리가 적용 가능한 모델일까?
프로젝트 관리자와 기여하는 개발자의 관계를 비효율을 겪고 있는 비개발팀과 개발팀의 관계로 비유해보면 어떨까? 평소 비개발팀이 비효율이라는 것을 알면서도 어쩔 수 없지 하면서 넘기던 일들, 때로는 비효율이라는 것을 미처 눈치채지 못하고 숙달되어 가던 일들을 CS팀과의 사례처럼 먼저 가서 묻기 전에 good first issue 이슈들처럼으로 문서로 정리해놓는다면 어떨까? 개발팀이 업무 시간 동안 공식적으로 이렇게 정리된 이슈들에 관심을 갖고 해결을 할 시간을 가질 수 있다면?
Fridave 첫 제안
세가지 고민
1. 언제 & 얼마나 할 수 있을까 우리는 CTO 테디와 대화를 나눈 뒤 충분히 시도해볼만한 가치가 있는 것이라고 판단했고 오히려 우리가 제안한 월 1회보다 더 자주 하면 어떻겠냐는 역제안도 받았다. 그렇게 최소 월 1회, 다른 일정을 고려해 여유가 된다면 2회 이상을 목표로 삼았다.
위 글처럼 개발팀이 금요일을 평소와는 다른 방식으로, 특히 업무의 20%를 활용하는 날로 활용하는 것은 꽤나 지지를 받고 있다. 주말을 앞두고 생산력이 떨어지는 시간을 다른 방식으로 활용하는 의미도 있고 혹여나 배포 후 문제가 생겼을 때 … 아 아니다 😅 아… 아무튼 금요일에 하기로 했다.
2. 비개발팀의 이슈 발굴 한가지 우려는 문자 그대로 비효율의 숙달화다. 숙달된 비효율은 쉽게 발견하기 힘들다. 특히 직접 기능을 구현하는 개발자가 아닌 구현된 기능을 활용하는 비개발팀 입장에서는 더 나은 방법을 떠올리는 것이 어려울 수도 있다.
미리 비개발팀과 정리해놓은 이슈 목록
이것은 파일럿을 먼저 진행해보기로 한 이유 중 하나다. 혹여나 “자 해결해볼까!?”하고 모였는데 막상 이슈가 별로 없거나 있더라도 정리가 잘 안되어 있다면 김이 샐 것이 분명했다. 파일럿을 앞두고 우리는 이슈가 특히 많이 나올 것 같은 비개발팀과 어떤 이슈들이 미리 정리가 되면 좋을지 미리 가벼운 대화를 나눴고 대화를 바탕으로 문서화를 진행했다. 이 대화를 통해서 ‘아 이미 엄청나게 비효율적으로 일하고 있다는 것을 잘 알고있고 엄청 빡*가면서 일하고 있구나’를 깨달았던건 비밀로 하자 🤗
3. 20%가 단지 업무가 되지 않도록 위에서 언급한 ‘비효율적인 업무를 개선하는 것이 하나의 업무가 되고, 업무 내 시간에 이루어지는 것’이 목표라고 했는데 세번째 고민은 이와 반대로 들릴 수 있다.
우리는 Fridave에 참여하는 개발자가 단지 다른 종류의 주어진 일을 하는 느낌을 갖지 않기를 바랐다. 오픈소스 & Hacktoberfest에 참여하는 개발자들이 느끼는 그런 종류의 재미를 느낄 수 있기를 바랐다( 👕 말고). 그래야만 개발팀에게는 20%의 문화로 정착할 수 있고 지속 가능할 것이라 생각했다. 개발팀에게는 어쩌면 비효율의 숙달화를 해결한다는 명목으로 재밌는 기술적인 시도를 해볼 수 있는 시간이 될 수 있지 않을까?
평소에 써보지 못하는 언어/플랫폼을 사용해볼 수 있는 계기
더불어 파일럿동안 비효율의 숙달화의 주제를 벗어나 온전히 20%를 취지를 살려보려는 시도도 있었다. 모바일팀은 이 시간을 활용해 TDD를 시도하기 위한 준비를 하였고, 디자인팀은 개발팀과 별도로 디자인팀만의 20% 시간으로 정하여 평소에 하고싶었지만 우선순위에 밀려서 못하던 브랜드 서체 점검 등의 작업들을 진행하였다. 👏🏻
파일럿 결과
일하는 사람 억지로 불러모아서 찍은 설정샷은 아니지만
참여 개발자: 8명
완전히 해결된 이슈: 2개
일부만 해결된 이슈: 2개
해결이 진행중인 이슈: 3개
비개발팀과 개발팀의 소통은 잘 이루어질 지, 중간에 있을 전체회의로 인해 시간이 부족하거나 흐름이 깨지지는 않을 지 등등의 걱정에도 불구하고 (물론 몇 작업은 주말까지 이어지긴 했지만 😋) 기대 이상의 결과가 나왔다. 특히 영상팀 스티븐이 올린 이슈( DCP - Digital Cinema Package - 를 만들기 전 단계에 가장 영상팀을 괴롭히는 작업인 영상에 자막을 새기는 작업)를 해결한 결과물은 오픈소스화🍻도 고려하는 중이다.
20% 문화의 좋은 출발이 되기를
CS팀과의 협업을 계기로 비개발팀이 가진 비효율의 숙달화를 해결하기 위한 첫 시도였지만 파일럿 치고는 꽤나 괜찮은 결과나 나왔다. 파일럿을 2회로 나누어 진행해야할 것 같다는 걱정이 있었지만 이것으로 충분하다고 결론을 내고 2020년에 본격적으로 데이브를 튀겨보기로 했다(맨 하단 이름의 유래 참고).
Fridave가 하나의 문화로 자리잡을 수도 혹은 머지않아 실패로 끝나 사라질 수도 있을 것이다. 다만 이 시도가 비개발팀에게는 평소 일하는 방식에 대해 지속적으로 의문을 갖고 더 나은 방식이 없을까를 고민하는 계기가 되고, 개발팀에게는 동료의 업무 방식을 개선해준다는 명목으로 20%의 문화를 다양한 형태로 즐길 수 있는 계기가 되면 충분히 의미있지 않을까 🙏🏽
데이브튀김
p.s. 이름의 유래: Fridave는 Hacktoberfest에 영감을 받아서 이전 협업을 진행했던 CS팀 데이브(Dave)와 함께 고민을 시작했다. October 대신 Friday를 넣어볼까?로 이름짓기를 시작해서 그렇다면 develop… dev… 뎁으… 데이브?????? 이렇게 데이브튀김이 되었다. 그래서 이날은 하루 종일 감자튀김을 라운지에 두고 나눠먹는 전통(?)이 생겼다.
이런 시도를 적극적으로 함께하는 왓챠 멋진 곳이에요. 지원은 이곳에서 👉🏼 https://team.watcha.com/joinus/ 👈🏼
가입하기
