Outsider's Dev Story

Stay Hungry. Stay Foolish. Don't Be Satisfied.

컨트리뷰톤 2019 참가 후기

지난여름에 컨트리뷰톤에 참가해보지 않겠냐는 연락을 받았다. 공개SW 개발자센터의 오픈프론티어에 작년부터 참가하고 있기 때문에 컨트리뷰톤에 대해서 들어본 적은 있었지만 사실 자세히 알지는 못했다.

공개SW컨트리뷰톤 공고

컨트리뷰톤을 간단히 설명하면 컨트리뷰팅 + 해커톤이 합쳐진 말로 일정 기간 오픈소스 기여를 돕는 행사로 참가 프로젝트를 선정해서 해당 프로젝트의 기여를 도와줄 멘토들이 있고 이 프로젝트들을 기준으로 참가자를 모집해서 기여할 수 있게 지원하는 행사다.

작년부터 Mocha에 기여하고 있어서 참가 요청을 받은 것인데 해보던 행사도 아니고 행사 기간이 길어서 처음에는 회의적이었다. 그러다가 이미 컨트리뷰톤에 여러 번 참가하신 정윤원 님이 꼬셔서 참가하게 되었다.

컨트리뷰톤 참가자 선정

컨트리뷰톤은 2016년부터 진행된 행사로 올해는 Backend.AI, pandas, Armeria, 구름입력기등 총 20개의 프로젝트가 선정되었다. 온라인 및 각 대학교 등에서 홍보가 되는 것 같은데 정부 사업이라서 그런지 보통 개발 커뮤니티에서는 연결되기 어려운 대학교에 공고가 나가고 이를 통해 학생들도 정보를 많이 접하는 것 같았다.

처음에 작성했던 프로젝트 소개와 진행방식에 대한 소개자료를 보고 참가자들이 프로젝트를 골라서 선정하고 그중에서 참가자를 고르면 된다. 보통 10명 안팎 정도를 얘기하던데 mocha 프로젝트에는 12명을 선정하려고 생각했다가 신청자가 56명인가 되어서 그중에서 고르고 고르다가 다 못 고르고 14명은 선정했다. 나한테 왜 떨어졌는지 물으신 분도 계셨는데 경력이나 자기소개 등이 있는데 사실 변별력이 별로 없어서 선정하기가 어려웠다. 물론 이력서 약식의 긴 문서가 있었어도 다 보기는 힘들었을 거다. 처음 참가하는 행사라 감이 없어서 어떻게 해야 할지 모른 채로 신청자가 적은 내용을 다 읽어보았다.

컨트리뷰톤의 목표를 생각해봤을 때 오픈소스에 기여해 볼 기회가 없었던 사람들에게 오픈소스를 알려주고 오픈소스에 기여해 보면서 장기적으로 컨트리뷰터가 되게 만드는 것이라고 생각했다.

그래서 오픈소스에 관심은 있으나 어디서부터 시작할지를 모르고 주변에서 도움을 받기 어려운 사람들을 위주로 뽑았는데 신청 서류에 분별력이 높지는 않았기 때문에 꽤 많은 부분은 그냥 직관이긴 하다. 그리고 성비를 반반을 맞추었다. 이런 부분은 이쪽 업계의 성비가 과도하게 한쪽으로 치우쳐져 있다고 생각하기에 의도적으로 한 것이고 이런 생각도 역차별일까 걱정을 좀 했지만, 주변에 조언을 구했을 때 괜찮을 거라고 판단해서 그대로 진행했다.

처음 프로젝트 진행 계획서를 올릴 때 온라인 위주로만 진행하겠다고 계획서를 올렸기 때문에(그 이상 시간을 쓰기 어려울 거로 생각하기도 했고 온라인으로 충분하다고 생각했다.) 지방에서 지원하신 분들도 꽤 계셨고 온라인으로 할 계획이었기 때문에 실제로 그런 분들도 뽑았다.

컨트리뷰톤에서의 초기 목표

올해 JSConf Korea에서도 Mocha로 발표하고 SprintSeoul에도 참가하고 있는데 이런 활동을 계속하는 이유는 내가 Mocha를 계속 하기 위함이다. 올해 전체적으로 슬럼프기도 하지만 계속 내가 Mocha에 참여하도록 만드는 장치들이기도 하다.

Mocha 로고

컨트리뷰톤에 Mocha로 참여했지만, Mocha는 하나의 수단일 뿐이고 오픈소스를 이해하고 재미를 알아가기를 바랬다. Mocha에 기여를 하는 것도 큰일이지만 오픈소스에 Mocha가 있는 것은 아니기에 Mocha에 기여하는 것이 끝이 아니라 오픈소스 생태계를 이해하고 행사 이후에도 다양하게 오픈소스 생태계 내에서 기여를 할 수 있기를 바랐다.

이 목표는 여전히 맞는다고 생각하지만 큰 목표에 비해서 내가 준비가 안 되어 있었고 너무 쉽게 생각했기 때문에 행사가 끝난 시점에서 보면 절반 정도만 성공했다고 생각한다. 최대한 이런 부분을 전달하려고는 했지만 얼마나 전달되었는지는 자기 잘 모르겠다.

위의 목표에 따라 첫 주에는 성당과 시장을 읽게 하고 오픈소스에 대해서 설명하려고 했다. 막상 시작하니 6주가 짧아서 이는 제외하고 진행하기는 했지만, 그냥 책과 설명으로 의도가 전달되었을까 하면 자신은 없다.(주변에서도 너무 거창한 계획이었다고 혼나기도 했다.) 이 부분을 설명하지 못하고 넘어간 게 영 신경 쓰여서 행사 후에는 오픈 소스로 미래를 연마하라라는 책을 선물로 주고 설명을 대체했다.(내가 말하는 것보다 잘 정리된 것 같아서..)

온라인 과정 진행

매주 화요일 10시에 모여서 화상으로 모임을 진행했다. 처음에는 Mocha의 사용법, 프로젝트의 구조, 로컬에서 개발환경, 테스트 실행 방법 등을 설명했고 Mocha의 경우 Pull Request를 올리면 Linting, 유닛테스트, Windows 테스트, CLA, 커버리지 등 다양한 서비스와 연동되어 있었기 때문에 어떤 역할을 하는지 설명하고 질문을 받았다. 처음에는 1시간씩 하려고 했지만 실제로는 거의 2시간씩 했던 것 같다.

첫 주가 지나면서부터 내가 너무 쉽게 생각했다는 느낌이 있었다.

일단 나는 이런 도구들을 써온 지가 오래되었고 이제 시작하는 분들한테 이렇게 설명한 적이 거의 없었기 때문에 사람들이 뭘 어려워하고 뭐가 힘든지를 전혀 모르고 있었던 것 같다. 이전에 오픈소스 발표를 할 때도 사실 Git이나 GitHub를 이해하는 게 진입장벽이라고 생각하기에 오타를 고치거나 하는 것도 처음에는 좋다같은 얘기를 종종 했었는데 실제로 가까이서 보니 진입장벽은 그보다 훨씬 더 높았다.

Open Source Initiative 로고

결국 오픈소스의 프로세스들은 협업을 위한 과정들인데 학생분들이나 아직 협업의 경험이 많지 않은 분들이 이런 프로세스의 필요성을 이해하는 데 많은 어려움이 있었다. 열심히 설명하면 뭔지 정도는 이해하시지만 그 경험은 부족하기에 왜 필요한지까지는 쉽게 전달하기 어려웠고 나도 설명해 본 적이 없어서 난항을 겪었다.

예를 들어 TravisCI가 있어서 질문을 받으면 "그건 CI에요"하면 내 입장에서는 설명이 끝났었는데 거기서 전달이 안 되니까 CI가 무엇인지 왜 필요한지를 설명하면서 계속 긴 이야기로 넘어가게 되다 보니 들으면서 쉽게 이해하기 어려웠을 것 같다.

그리고 요즘 JavaScript쪽이 더 그렇긴 하지만 mocha도 오래된 프로젝트라 협업과 관리를 돕는 많은 장치가 있고 그런 부분을 설명하다 보니 ESlint, husky, Karma, Travis, AppVeyor, Netlify, Coveralls, Istanbul, Prettier, Sauce Labs 등 수많은 서비스와 도구들을 설명해야 해서 참가하신 분들이 용어에서 이미 압도된 느낌이 강했다. 사실 오픈소스를 한다고 저런 서비스나 도구를 꼭 이해해야 하는 건 아니라서 컨트리뷰톤의 의도와 Mocha처럼 오래된 프로젝트는 좀 안 어울리지 않나 하는 생각도 했다.

매주 1회 전체 회의를 하면서 진행 사항 확인 및 전체적으로 설명하면서 진행했다. 14분한테 이슈를 일일이 찾아드리기도 쉽지 않은 일이었지만 자신이 할만한 이슈를 찾고 내용을 파악하는 것도 오픈소스에 기여하는 과정 중 하나라고 생각했기 때문에 이슈도 직접 찾아보게 요청을 했다.

전체 회의외에 이슈에서 막히는 부분은 나랑 따로 화상회의를 잡아서 해당 부분을 설명해주고 같이 방향을 논의하면서 진행할 생각이었지만... 아무도 별도의 화상회의를 요청하지 않았다.

오프라인 스프린트로 변경

사실 이때까지는 내가 컨트리뷰톤에 크게 몰입하고 있지도 못했지만 크게 잘못되었다고 느낀 건 중간보고서를 제출하는 3주 차가 지났을 때였다. 이슈를 찾을 때 Mocha 프로젝트 자체 외에도 생태계 자체를 강조해야 한다고 생각했기에 mocha org 밑의 다른 프로젝트에 해도 상관없다고 하기는 했지만, 이슈를 직접 찾으라고 했더니 대부분이 적합한 이슈를 찾지 못하고(이전 문맥을 몰라서 이슈의 내용을 잘 모르거나 이슈가 할만한지를 판단하기 어렵거나 등) mocha와 관련된 다양한 프로젝트 설정을 모아두는 mocha-examples의 이슈를 처리하겠다고 중간보고서에 올라왔다.

3주가 지났는데 방향을 전혀 못 잡고 있다는 걸 깨달은 순간 "망했다"라는 생각이 들었고 더 적극적인 지원을 해야겠다고 생각을 바꾸었다. 실제로 난 저렇게만 안내를 하면 진행이 될 거라고 생각을 하고 있었다. 지방에 계신 분들한테는 죄송했지만 모일 수 있는 사람들이라도 모여서 더 적극적으로 지원을 하고 나면 원격으로 지원해드리는 분들도 부담을 덜 수 있을 것 같았다.

mocha 오프라인 스프린트

마침 10월 초에는 공휴일이 꽤 있었기 때문에 약속 시간을 따로 잡지 않고 오후 1시부터 7시 정도까지 내가 정한 카페에 계속 있고 참가자분들이 시간이 될 때 잠깐이라도 들려서 같이 이슈를 해결할 수 있도록 했다. 그렇게 행사가 끝날때까지 5번의 스프린트를 했고 정확한 모임 시간을 잡은 것은 아니라서 꽤 많은 분이 참여했다.

그리고 직접 이슈를 찾아보라고 한 부분도 할만한 이슈를 찾아서 어떤 내용이고 어느 부분을 보면 되고 난이도는 어느 정도인지를 정리해서 틈틈이 Slack에 올리기 시작했고 참가자들도 거기서 이슈를 하나씩 가져가기 시작했다.

오프라인 스프린트에서는 5명 정도씩 나오셨는데 이정도 인원이면 나는 다른 일은 거의 못 하고 질문받고 설명해주고 어디가 문제인지 같이 찾아보다 보면 하루가 다 가곤 했다. 저번 PyCon Sprint에서도 느꼈는데 혼자서 도와드릴 수 있는 인원은 5명 정도가 한계인 것 같다.

가까이서 보니 어떤 부분에서 어려워하는지 빠르게 느낄 수 있었고 바로 설명해 드리면서 진행이 빨라지게 되었다. 그전에 1:1 온라인 미팅을 왜 요청 안 하셨는지도 좀 이해하게 되었는데 내가 생각했던 건 혼자 보시다가 궁금한 내용을 정리해 오면 나랑 얘기하면서 그 부분에 대해 답변을 하고 이후 다시 작업해보고 하는 것이었는데 실제로 오프라인에 모이고 보니 10분마다 막히거나 궁금한 부분이 생기고 하다 보니 따로 온라인 미팅을 잡아서 하기가 어려운 상태였다.

실제로 오프라인 스프린트를 진행하고 작업도 진행되고 난 다음에는 온라인으로 따로 추가 설명이 가능한 상태가 되었다.

컨트리뷰톤 결과

그렇게 열심히 6주를 하고 14분 중 10분만 남게 되었다.

  • mocha 외의 프로젝트도 포함해서 총 22개의 PR을 올렸고
  • 마침 6.2.2 릴리스가 있어서 2분은 컨트리뷰터로도 등록되었고
  • mocha에 5개의 PR이 머지되었고
  • mocha-examples에 3개의 PR이 머지되었고
  • 다수의 이슈를 올리고 댓글에서 논의가 진행되었다.

이 글에서도 기록 차원에서도 정량적으로 정리를 했지만 오픈소스 기여 과정이란 것이 Merge된 풀리퀘스트 뿐 아니라 올렸다가 닫히거나 리뷰를 받으면서 계속 다듬어 가는 과정, 이슈 등에서 논의하는 과정도 다 포함된다고 생각하기 때문에 그런 부분을 최대한 경험하게 하려고 노력을 했다. Pull Request가 올라가고 머지되면 좋긴 하지만 그렇게 돌아가는 기여라는 게 거의 없고 대부분은 험난한 리뷰와 논의 과정을 거쳐야 하므로 Merge 자체에 너무 집착하지 않고 과정에 더 집중할 수 있기를 바랬다.

컨트리뷰톤 결과 발표

처음 시작할 때도 과정에 집중할 거고 수상에는 관심 없다고 강조하긴 했는데 최종 결과에서 장려상을 받았다. 상은 내가 받는 건 아니고 당연히 참가하신 분들이 받는 건데 결과도 좋게 나와서 다행이다.

배운 것들

결론부터 말하면 참여하길 잘했다 싶을 정도로 만족하고 있다. 고인물들 사이에서만 놀다 보니 몰랐던(정확히는 알았지만 까먹은) 부분들을 많이 곱씹어볼 수 있었다. 이런저런 활동을 하고 다니면서도 학생분들이나 이제 개발을 시작하는 분들은 단방향으로 내가 전달하는 발표나 강의 등이었기 때문에 앞에서 말한 대로 사람들이 뭘 어려워하는지 전혀 감을 잡지 못했던 것 같다.

너무 당연하게 사용하는 수많은 용어와 개념들로 설명 아닌 설명을 하면서 "어? 여기서 막힌다고?", "그럼 어디부터 설명해야 하는 거지?"같은 생각을 많이 하면서 느낀 점이 많다.

그리고 열정적으로 눈 반짝이면서 질문하는 모습을 보니까 그 에너지가 전달된 듯 나도 재밌어져서 집중할 수 있게 된 것 같다. (혼자 생각이지만) 뒤로 갈수록 설명하는 것도 좀 더 쉬워진 느낌이기도 하고...

보통 내가 하던 활동과는 다른 형태의 활동이라서 더 재밌었던 것 같다.(물론 6주가 넘어가면 너무 힘들 것 같긴 하다.) 6주간 꽤 자주 연락하면서 지내고 같이 코딩하다 보니 앞으로 또 어디서든 뵈면 상당히 반가울 것 같다. 같은 업계니 또 어디서 만날지 모를 일이고.. ㅎㅎㅎ

2019/12/04 01:49 2019/12/04 01:49

기술 뉴스 #139 : 19-12-02

웹개발 관련

  • 만화로 보는 DNS over HTTPS : 모질라의 A cartoon intro to DNS over HTTPS의 한국어 번역본이다. HTTPS를 이용하더라도 DNS를 조회할 때는 어떤 사이트에 접속하려는지 볼 수 있게 되는데 Trusted Recursive Resolver(TRR)와 DNS over HTTPS(DoH)로 이를 어떻게 보호하고 어떤 부분은 감출 수 없는지를 설명하는 글이다.(한국어)
  • SPA에서의 접근성에 대해 배운 것들 : SPA을 만들면서 접근성에 대해 배운 것을 정리한 글이다. 보통 <button>, <input> 대신 <div>, <span>을 많이 사용하는데 이렇게 되면 포커스나 스크롤 위치를 수동으로 다루어 주어야 하므로 접근성 관련해서 버그가 더 많이 나올 수밖에 없다. 그리고 접근성을 강화해서 aria 태그를 이용하면 테스트도 더 쉽게 작성할 수 있다고 얘기하고 있다.(한국어)
  • Build a PWA Using Only Vanilla JavaScript : 바닐라 자바스크립트 즉, 다른 프레임워크를 사용하지 않고 JavaScript로 PWA를 구현하는 과정을 설명하고 있다. Manifest, Service Worker 등 PWA에 필요한 기능을 설명하고 이 구현과정을 설명하면서 예제 소스도 함께 제공하고 있다.(영어)
  • Redux Style Guide : Redux 공식 사이트에 올라온 Redux 코드를 작성할 때의 추천 패턴과 베스트 프랙티스를 모아놓은 스타일 가이드다.(영어)
  • Time Traveling State Debugger — Reactime — Now Supporting Concurrent Mode, Routers, and more : Redux DevTools에 영향을 받아 만든 크롬 개발도구인 Reactime 3.0에 Time Traveling 디버깅 기능이 추가되어 React 앱에서 사용자 액션에 따른 상태 변화를 다시 재현하면서 디버깅할 수 있다.(영어)
  • JavaScript ‪Module Cheatsheet : ECMAScript Modules에서 importexport를 어떻게 사용하는지 이름 있는 경우 default를 쓰는 경우 등 다양한 사례별로 정리한 글이다.(한국어)

그 밖의 개발 관련

  • Announcing core Node.js support for ECMAScript modules : Node.js 13.2.0 버전부터 import, export 문법으로 사용하는 ECMAScript 모듈을 지원한다. 이전 버전까지는 --experimental-module 플래그를 사용해야 했다. 모듈은 .mjs 확장자를 사용하거나 해당 파일의 가장 가까운 위치에 있는 package.json에서 typemodule로 지정되어 있어야 한다. 기본의 CommonJS는 cjs 확장자를 사용하거나 type이 없거나 commonjs로 지정되어 있어야 한다.(영어)
  • Better Android Testing at Airbnb — Part 1: Philosophy and Mocking, Part 2: Screenshot Testing : Airbnb에서 Android 테스트 자동화를 한 과정을 설명한 7편의 시리즈 글 중 첫 두 편의 글이다. Espresso를 쓰다가 Jetpack의 ViewModel을 도입해서 MvRX 라이브러리를 오픈소스로 공개하고 사용해 온 뒤 더 테스트를 잘할 수 있도록 모킹 시스템을 도입해서 MvRX 라이브러리에 통합시키고 이후 스크린샷 비교를 위해 Happo 서비스를 도입했다고 한다.(엉여)
  • Meet Doctor, a new React Native command : React Native 개발 환경의 오류를 검사할 수 있는 doctor 명령어가 추가되었다.(영어)

인프라 관련

볼만한 링크

  • 스프링러너, 벌써 일 년 : 스프링을 배울 수 있는 워크숍을 1년 동안 운영하고 회고하는 글이다. 스프링러너 워크숍에서는 스프링의 사용법과 응용법을 가르치는 것을 목표로 하고 있고 이 과정을 통해서 스프링에 대해서 배울 수 있지만 16시간 동안 많은 내용을 가르치기 때문에 참가자들이 컨디션 조절을 잘해야 한다는 어려움이 있다.(한국어)

IT 업계 뉴스

프로젝트

  • Browser Default Styles : HTML 요소의 브라우저별 기본 스타일을 비교할 수 있는 사이트.
  • Lighthouse CI : Lighthouse를 CI에서 돌릴 수 있게 하는 CLI.
  • whocanuse : 색상 대비로 인한 접근성을 검사해 주는 사이트로 배경색과 텍스트의 색을 입력하고 접근성에 대한 결과를 볼 수 있다.
  • WebGLStudio.js : 웹 기잔의 3D 그래픽 에디터.
  • Gridsome : Vue.js를 이용한 정적 웹사이트 생성 도구.
  • Fitty : 부모 컨테이너 사이즈에 텍스트를 맞추는 JavaScript 라이브러리.
  • Clusterlint : Kubernetes 클러스터가 베스트 프렉티스를 따르고 있는지 검사해주는 도구로 Digitalocean에서 만들었다.

버전 업데이트

2019/12/02 04:19 2019/12/02 04:19