공개SW 컨트리뷰톤 회고

공개SW 컨트리뷰톤을 시작한 지 3주가 지났다.
그 동안 컨트리뷰톤을 진행하며 배운점과 느낀점을 정리해보았다.

지원 동기

올해 6월에 진행된 '2019 오픈소스 개발자 이야기' 행사에 참석한 후 '공개SW 컨트리뷰톤'에 대해 알게되었다. 오픈 소스에 기여하고 싶은 마음을 갖고 있었는데 '공개SW 컨트리뷰톤'이 오픈 소스 기여를 시작하기 좋은 기회라고 생각해서 지원했다. 위의 사진에서 볼 수 있듯이 여러가지 주제가 있었다. 현재 자바스크립트를 공부하고 있기 때문에 관심있는 주제는 크게 세 가지로 추려졌다.

  1. Mocha
  2. React Native Basic Tutorial
  3. 자바스크립트 튜토리얼 한글화

나는 위 세가지 중에서 React Native Basic Tutorial 이라는 주제를 1지망으로 신청했다. 일단 Mocha의 경우 이미 너무 유명한 오픈 소스이기 때문에 내가 기여할 수 있는 부분이 많지 않을 것 같았다. 자바스크립트 튜토리얼 한글화의 경우 개발이 아닌 번역이기 때문에 좀 아쉬웠다. React Native Basic Tutorial을 선택한 이유는 다음과 같다.

  • 최근 React 공부를 시작했다.
  • Turorial을 만들면서 기본 개념을 많이 배울 수 있을 것 같다.
  • 내가 기여할 수 있는 부분이 다른 주제에 비해 많을 것 같다.

React Native는 React와 유사한 부분이 많기 때문에 이왕 React 공부를 시작한 만큼 같이 공부하면 시너지 효과가 날 것 같았다. 또한 경험상 혼자 공부하는 것보다 배운 것을 발표하거나 누군가에게 설명할 때 공부 효율이 훨씬 더 높았다. 무엇보다 React Native는 아직 Tutorial이 많지 않기 때문에 내가 기여할 수 있는 부분이 많다고 생각했다. 이와 같은 이유로 1지망React Native Basic Tutorial, 2지망자바스크립트 튜토리얼 한글화로 지원했다.
감사하게도 1지망으로 신청한 React Native Basic Tutorial 팀에 합격했고 발대식에 가게되었다.

발대식

발대식에서는 공개SW 컨트리뷰톤의 취지와 진행 과정, 지난 기수 분들의 경험담을 들을 수 있었다. 발대식에서 기억에 남는 말은 다음 두가지 였다.

  • 오픈소스 PR은 Merge 보다 Merge 되기 까지의 Review, feedback 과정이 훨씬 더 중요하다.
  • 오픈소스에 기여하면서 가장 우선시 되는 목표가 재미였으면 좋겠다.

내가 컨트리뷰톤에 참가하는 이유는 상을 받기 위해서도 아니고 대단한 기여를 하기 위함도 아니었다.

결과보다 과정에 더 큰 의미를 두고 그 과정에서 재미를 느끼는 것

이것이 이번 컨트리뷰톤의 궁극적인 목표가 되었다.

팀 모임

다른 팀은 어떤지 모르겠지만 우리팀은 경쟁률이 4:1 정도 였다고 한다. 아직 많이 부족하고 오픈 소스 기여 경험이 없는 내가 뽑힌 것에 대해 다시 한 번 감사하게 되었고 더 열심히 하기로 마음 먹었다.

우리 팀의 궁극적인 목표는 다음 두 가지다.

  • 리엑트 네이티브 튜토리얼 페이지 만들기
    • 제대로 된 튜토리얼 페이지가 없다. — 심지어 영어로도
  • 독립적인 기능의 앱을 만드는 튜토리얼
    • sample app을 만들며 익히는 게 목적

슬랙을 통해 상시로 소통하며 오프라인 모임은 2주에 한 번 강남에서 하기로 했다. 팀원은 총 13명이었는데 3-4명이 한 팀이 되어 진행한다고 했다. 팀은 팀원들이 각각 하고 싶은 튜토리얼 순위별로 3개씩 제출한 것을 기반으로 배정되었다. 팀은 Basic Tutorial, Debugging, Router, State Management 등 4개의 팀으로 나뉘었다. 나는 React Native 기본 개념을 다루는 Basic Tutorial 팀에 배정되었다.

팀원은 나까지 총 세명이었는데 한 분은 직장인, 다른 한 분은 대학생이었다. 팀장을 선출해야 하는데 다들 일과 취업준비로 바쁘셔서 선뜻 나서지 않으셨다. 나는 다른 분들에 비해 상대적으로 덜 바쁜 상태였고 이번 오픈소스 프로젝트를 열심히 잘 해보고 싶었던 마음이 컸기에 팀장을 맡기로 했다. 작은 팀이지만 함께 소통하고 개발하며 팀을 운영하는 경험이 나중에도 큰 도움이 될 것 같았다.

팀 프로젝트 시작

하지만 학교 조별과제가 그러하듯 팀플이 순조롭게 흘러가진 않았다. 매일 슬랙에서 온라인으로 팀별 회의를 진행하는데 시간을 맞추는 것부터 힘들었다. 약속 시간보다 늦게오거나 연락도 없이 참석하지 않는 경우도 생기기 시작했다. 그러다 보니 회의 시간이 길어졌고 진행 속도도 더뎠다.

생각해보면 각자 마다 프로젝트에 임하는 마음이 달랐던 것 같다. 나의 경우 첫 오픈소스 프로젝트이기도 하고 관심있는 주제였기 때문에 하루의 대부분의 시간을 프로젝트에 투자했다. 또한 팀장이 되었기 때문에 팀을 잘 이끌고 싶다는 욕심도 있었다. 하지만 다른 팀원분들의 경우 이미 하고 있는 일이 있고 이 프로젝트는 자투리 시간을 이용하는 서브 프로젝트였다.

하지만 이렇게 계속 진행되다가는 프로젝트가 원활하게 진행되지 않을 것 같았다. 그렇게 일주일 간 고심하다 팀원들에게 조심스레 No Show 벌금을 제안했다. '연락도 없이 회의 참석을 하지않는 경우에 한 해 벌금을 걷는 것으로..' 아무리 부담없이 하는 프로젝트여도 최소한의 규칙은 있어야 끝까지 잘 마무리 될 수 있을 것 같았다. 감사하게도 팀원들도 동의를 해주었다.

No Show 벌금이 생긴 이후 부터는 신기하게도 늦는 사람이 없었다. 많은 벌금은 아니었지만 (1회당 2,000원) 벌금이 있고 없고의 차이는 굉장히 컸다. 덕분에 회의 시간도 전보다 훨씬 짧아졌고 진행 속도도 빨라졌다.

React Native TodoList 만들기

우리팀에게 주어진 임무 React Native의 기본 기능을 이용한 튜토리얼을 만드는 것이었다. 기본 기능은 공식 홈페이지에 이미 잘 설명되어 있었다. 하지만 해당 기능만 간단하게 소개되어 있어 실무에서 어떻게 사용하는지는 알기 어려웠다. 따라서 우리팀은 기본 기능을 모두 사용하여 하나의 앱을 만들어 보는 튜토리얼을 제작하기로 했다. 기본 기능만 사용할 것이기에 간단한 TodoList를 만드는 것으로 합의했다.

각자 일주일 동안 React Native로 TodoList를 만들어 보고 코드 리뷰를 통해 그 중 가장 괜찮은 코드를 메인으로 쓰기로 했다. 일주일 간 React와 React Native 책과 강의를 통해 기본 개념을 익히고 TodoList를 만들었다. React Native는 React와 비슷한 부분이 많아 React 책을 많이 참고했다. 특히 최근에 나온 벨로퍼트 님의 리액트를 다루는 기술 책이 설명이 매우 잘 되어 있어서 큰 도움을 받았다.

React Native로 만든 TodoList

todolist.png

일주일 뒤 각자 만든 TodoList를 서로 리뷰해주는 시간을 가졌다. 한 분은 React와 React Native가 모두 처음인 분이셔서 React로만 TodoList를 만들어 오셨고 다른 팀원은 기능을 모두 구현해오셨다. 회의 끝에 내가 만든 코드를 기반으로 진행하기로 했다. 내가 코드를 잘 짜서 그런 건 아니었다.

원래는 기본 기능을 사용하여 TodoList 하나만 만드는 걸로 계획을 했는데 그러기에는 6주라는 시간이 생각보다 길었다. 따라서 추가 기능도 다루기로 했다. 나도 React Native는 처음이라 추가 기능을 다시 공부해서 개발하는 건 조금 부담스러웠다. 팀원 중 현직 개발자 분이 계셨는데 React와 React Native를 실무에서 사용해본 경험이 있으셨다. 그래서 추가 기능 개발은 그 팀원이 맡아주시기로 했다.

  1. 공식 홈페이지에 있는 기본 기능을 모두 사용하여 TodoList 만들기
  2. 추가 기능: 외부 디버거, 핫 로딩, 애니메이션, 컴포넌트 분리 등

내가 1번을 맡고 팀원 두 분이 2번을 맡아서 진행하기로 했다. 2주차가 되던 날 오프라인 모임을 진행했고 팀원분들에게 코드 리뷰를 한 번 더 받아 코드를 개선했다. 팀원 중 현직 개발자 분이 계셨기에 코드 개선에 많은 도움이 되었다. 그렇게 각자 맡은 역할에 따라 작업을 진행하고 있다.

Git 을 이용한 협업

Git을 통해 여러명이서 협업한 경험은 없었는데 이번 기회를 통해 많이 배우고 있다. 우리팀의 Git flow의 예시는 다음과 같다.

upstream: react-native-tutorial
origin: upstream을 fork한 본인의 repository

1. Issue를 생성하고 assign 한다.

upstream에 issue 생성

- Title: [Basic] Make props tutorial
- Body: Make props tutorial with example project

issue number: 5라고 가정

2. assign 된 인원이 해당 브랜치 생성

  • 각 팀별 브랜치에서 시작 -- 우리팀의 경우 tutorial/basic 브랜치에 checkout
    git checkout tutorial/basic

  • tutorial/basic 브랜치에서 git pull 을 통해 최신사항 반영

    git pull upstream/tutorial/basic

  • tutorial/basic 브랜치에서 작업 브랜치 생성

    git checkout -b 5-props-tutorial --track upstream/tutorial/basic

3. 소스 코드 수정

  • 변경사항 커밋

    git commit -m 'Add a props tutorial in basic-tutorial #5'

  • Push 전에는 rebase를 통해 혹시나 최신 변경사항이 있을경우 반영

    git pull --rebase upstream basic-tutorial

  • 본인 Fork 레파지토리인 Origin에 Push

    git push origin

  • 본인 origin Github에서 5-props-tutorial브랜치를upstream/basic-tutorial에 PR 요청

이제 프로젝트 기간의 반이 지났다. 오픈소스 프로젝트를 통해 React Native, Git flow, 협업 경험 등 많은 것을 배우고 있다. 앞으로 남은 기간도 열심히 참여하여 더 성장하고 싶다 :)