서론

이 글은 12월 14일에 열린 스프린트 서울에 참가하고 나서 작성한 후기입니다

먼저 이 행사는 Facebook OSS 개발자 포럼 페이지에 올라온 홍보 글을 통해서 알게 되었습니다. (페이스북에 있는 다양한 개발자 그룹(생활코딩, 프론트엔드개발그룹, GDG Korea WebTech 등등...)에 들어가시면 재밌는 개발행사를 많이 알 수 있답니다 🙂)

평소에 오픈소스 기여에 관심이 있었던 저에게 정말 흥미가 가는 행사였습니다.😀 혼자서 오픈소스를 조금씩 해봤을 때, 이런저런 이유로 어려움을 많이 겪고 자주 그만두게 되었죠. 이런 행사를 통해서 오픈소스의 문턱을 넘어서고 싶어서 신청하게 되었습니다!

---

시작 🏁

아침 10시부터 시작하는 행사였기 때문에 선릉에서 멀리 살고 있던 저는 토요일 아침부터 일찍 일어나서 준비를 마치고 행사 장소(스파크플러스 선릉점 3층 aka 지그재그)에 딱 맞춰 도착했습니다.
ps. 지그재그 인사 담당자님께서 회사 내부 구경을 시켜주셨습니다.

다른 참가자분들과 스프린트 리더분들을 기다리면서 약 30분 정도 소모되었고, 각 프로젝트별 리더분들께서 프로젝트 소개를 마친 후에 참가자분들께서 각자 재밌어 보이는 프로젝트에 참여하면서 행사가 시작되었습니다.
ps. RustPython 프로젝트의 리더분께서 개인 사정으로 좀 늦으시게 되어서 프로젝트 소개를 제대로 하지 못하셔서 도착하시고 나서 혼자서 프로젝트를 시작하셨다고...😂

진짜 시작 🏃🏻‍♂️

Mocha 프로젝트에 관해서 간단하게 소개를 해보겠습니다.

브라우저와 Node.js에서 동작하는 전통적인 자바스크립트 테스트 프레임워크

Mocha 프로젝트에 저 포함 6명의 참가자가 참여하게 되었고, 무려 Mocha, Node.js 오거나이저이신 변정훈 님이 리더로 프로젝트 리딩을 해주셨습니다. 6명의 참가자가 한 번에 우르르 몰리자 정훈 님께서 Mocha 프로젝트에 이렇게 많은 사람이 몰린 적이 없는데..라고 말씀하시면서 당황해하시던 모습이 기억에 남네요.🙂

이렇게 Mocha 프로젝트 참가자들과 리더가 모두 모이자, 정훈 님께서 간단하게 프로젝트 소개와 자기소개를 하시고, 참가자들도 각자 자기소개를 하면서 행사를 시작했습니다.

저는 지난 공개 SW 컨트리뷰톤에 참가하면서 Mocha 프로젝트를 자세히 알게 되었습니다. 비록 다른 프로젝트에 참가했지만, 최종 평가회에서 Mocha 프로젝트의 발표에서 보여준 모습은 저에게 인상적이었습니다. (제가 진행했던 프로젝트는 참가자들이 함께 처음부터 개발하는 프로젝트였지만, Mocha 프로젝트는 이전부터 많은 개발자가 함께 만들어가던 프로젝트였습니다) 제가 생각했던 오픈소스 기여는 전자보다 후자에 가까웠기 때문에 컨트리뷰톤이 끝나고 Mocha같은 프로젝트에 오픈소스 기여를 해봐야지라고 생각하기도 했고, 실제로 풀리퀘를 보내기도 해봤습니다. (오거나이저에 의해 거부된 건 안 비밀...🤣)

너무나 타당한 이유를 들어주신 오거나이저 님에게 👍을 달고 닫힌 첫 풀리퀘

이렇게 Mocha에 대해서 약간의(매우 약간의...) 지식이 있었던 저는 지식이 아예 없었던 다른 참가자들에 비해서 쉽게 저의 이슈를 찾을 수 있었습니다. 이슈는 Mocha 프로젝트의 issue 페이지에 들어가 보면

위처럼 많고 많은~ 이슈들을 찾을 수 있습니다. 여기서 라벨이 good-first-issue인 이슈들을 선택하면

한결 초보자들이 기여를 시작하기 좋은 이슈들이 남게 됩니다.(하지만, 이슈들이 이렇게 오랜 기간동안 남아있는 데에는 다 이유가 있다는..😅)
아무튼, 이렇게 오거나이저들이 골라준 이슈들 중에서 맘에 드는 이슈를 골라서 어떤 이슈인지 확인해보면서 해결할 수 있을 것 같은 이슈를 고르고, Mocha 레포지토리를 포크하고, 해당 이슈를 해결하는 브랜치라고 명시하기 위해서 issue/${이슈 번호} 이런 형식으로 브랜치를 새로 만들어줍니다! 포크와 브랜치에 관한 자세한 사항은 이 글을 참고해보세요! 제가 선택한 이슈는 문서화에 관한 이슈였습니다.

이렇게 해결하고자 하는 이슈를 찾고나서 열심히 세팅하고 이것저것 하다 보니까 지그재그에서 미리 주문해주신 맛있는 🍕가 도착했습니다.

🍕 타임

일찍 일어나느라 아침도 안먹고 와서 배가 고팠던 터라 피자가 무척이나 맛있었습니다. (후원해주신 지그재그에게 감사를...) 피자를 먹으면서 다른 참가자분들과 리더분들과 함께 얘기를 다양한 얘기를 나눴습니다. 얘기를 나누다 보니 아까 개인 사정으로 늦게 도착하신 RustPython 리더분이신 정윤원님과도 함께 대화하게 되었습니다. 여기서 화려한 언변에 대화가 끝나갈 즈음에 저는 Rust에 빠지게 되었습니다.😆 그러고 나서 빨리 Mocha 이슈를 해결하고 바로 RustPython 프로젝트에 참가하겠다고 말씀드리고 저는 이슈를 해결하러 달려갔습니다.🏃🏻‍♂️ (참고로 스프린트 서울은 참가 신청을 받을 때, 어떤 프로젝트에 참가하고 싶은지 입력하지만, 실제 행사에서는 꼭 신청한 프로젝트만 할 수 있는 것이 아니라 자신이 하고 싶은 프로젝트로 옮겨 가면서 행사에 참여할 수 있습니다.)

이슈 해결하기 🤯

제가 어떤 방식으로 이슈를 해결했는지 말씀드리기 앞서, 제가 어떤 이슈를 해결했는지 말씀드리도록 하겠습니다. 사실, 제가 해결한 이슈는 앞서 말씀드렸다시피 로직에 관련된 이슈가 아니라, 문서화에 관련된 이슈였습니다. 테스트 프레임워크인 Mocha에는 테스트를 진행할 때, 진행되고 있는 테스트의 현황을 알려주는 Reporter라는 기능이 있습니다. Mocha를 cli로 실행시킬 때, 어떤 Reporter를 실행시킬 것인지 선택할 수 있습니다. 이렇게 Reporter를 선택할 때, 하나의 Reporter를 선택할 수 있는 두 가지 이름이 있습니다.

// Spec Reporter: Spec, spec
// TAP Reporter: TAP, tap
// XUnit Reporter: XUnit, xunit
...etc

이렇게 두 가지 선택지가 있는 반면에, 문서에서는 Reporter에 대한 설명이 매우 부족하고, 어떤 이름으로 사용 가능한지, 무엇이 cli에서 사용하는 이름이고, 무엇이 Reporter를 지칭하는 명칭인지 헷갈리게 작성이 되었습니다.

그래서 저는 이슈 작성자의 의견을 반영해서

이런 형태처럼 Reporter 문서에서 유저들이 Reporter를 사용할 수 있는 이름을 명확하게 이해할 수 있게 만들고자 했습니다.

하지만, 제가 이전에 보냈던 풀리퀘도 어떻게 클론받은 문서를 로컬 환경에서 렌더링하는지도 모르는 상태에서 대충 마크다운만 수정하면서 \"의미만 맞으면 되겠지"라고 생각하면서 보냈었는데(문서를 로컬로 실행시키는 법을 몰라서 변경된 문서의 렌더링 결과를 미리 보지 못했다😅), 이번 기회에 Mocha 오거나이저👨🏻‍💻이신 변정훈님의 도움을 받아서 로컬에서 제가 수정한 문서가 어떻게 렌더링되는지 확인하고 풀리퀘를 보내는 작업까지 해보려고 했습니다.

준비 과정

제가 프로젝트를 준비한 과정은 다음과 같습니다.
1. 기여 가이드를 보면서 기여 절차 숙지하기
2. Mocha 레포지토리 문서 개발 부분 README를 읽으면서 문서 개발 관련 정보 숙지하기
1. gm모듈의 의존성 프로그램인 GraphicsMagick 혹은 ImageMagick 둘 중 선호하는 프로그램을 설치하기
3. 포크한 Mocha 레포지토리를 클론받고, npm 모듈 설치하기

그런데 이렇게 필요 모듈들을 모두 설치했음에도 불구하고 자꾸 알 수 없는 오류가 발생했습니다. 그래서 저의 영웅 변정훈님께 여쭤봤습니다. 정훈님께서 Node.js 버전을 여쭤보시더니 12라는 저의 대답을 듣고는 Node.js v12에 대한 모듈 호환 이슈가 있다고 말씀해주시고는 Node.js v10을 설치하고 npm start docs 명령어를 실행시키니까 딱 문서가 렌더링되는 모습을 보고 너무 감격이었다는...(글로 설명하니 많이 생략되고 압축되었지만, 정말 여러 에러들을 만났습니다 😢)

이렇게 모든 준비를 끝마치고 드디어 먼저 설명한 문서의 문제를 다음과 같이 해결해봤습니다.

BEFORE

AFTER

변경사항은 다음과 같습니다.

• cli에서 사용가능한 이름들은 설명과 분리해서 명시
• Reporter 본문에서 지칭하는 Reporter들의 이름은 대문자 이름으로 통일

사실 엄청난 변경은 아니지만, Mocha 사용자들이 더 명확하게 Reporter의 사용법을 알 수 있게 될 것을 생각하니 뿌듯합니다.😉 그리고 저처럼 Mocha를 잘 알지 못하는 초보자들이 좀 더 쉽게 알 수 있게 되지 않을까 생각이 됩니다.

---

RustPython 🐍

Mocha 문서 이슈를 해결하고 나서 앞서 피자 타임 때 얘기했던 정윤원 님과 약속했던 대로 바로 RustPython팀에 참여하러 달려갔습니다. 점심시간까지만 하더라도 한 명(리더 님...)밖에 없었던 RustPython방이 어느 새 다섯 명의 인원으로 꽉차게 되었습니다. 이렇게 RustPython팀에 참여하게 되고, 정윤원 님의 도움으로 RustPython 기여를 시작하게 되었습니다.

Rust? Python?

저는 프로젝트의 시작부터 끝까지 많은 어려움들을 겪었습니다.(언어적 이해 부족, 프로젝트 이해 부족) Rust나 Python에 대한 지식이 많이 부족했습니다. Python은 고등학교 재학 시절에 조금밖에 해보지 않았고, Rust는 많이 들어보지도 않은 생소한 언어였습니다. 그래서 프로젝트 세팅부터 이슈 선정, 이슈 해결까지 모든 부분에서 정윤원 님의 도움을 받으면서 프로젝트 진행을 했습니다.

삽질 ⚒️

RustPython 프로젝트를 진행하면서 정말 많은 어려움들을 겪었지만, 그 중에서 기억나는 2 가지 이슈들을 추려서 설명해보겠습니다.

1. Python 버전 문제 - Python2 → Python3으로 변경
2. RustPython test MAC OS 버그

먼저, 첫 번째 이슈는 Python3을 설치하면서 간단하게 해결되었습니다. 두 번째 이슈는 프로젝트 세팅이 잘 되었는지 확인하기 위해서 준비가 끝나고 전체 테스트를 돌렸더니 에러가 발생해서 에러 원인을 찾다가 알아낸 테스트 버그였습니다. 리더 님과 이 문제를 어떻게 해결해야할지 원인을 찾다가 테스트 코드에서 Unix OS와 Windows OS를 제대로 구분하지 못하는 이슈때문에 발생한다는 것을 깨닫고, 이 이슈를 제 첫 RustPython 풀리퀘로 보내기로 했습니다.

이슈 부수기💥

Python에서 sys.platform

System	platform value
AIX	'aix'
Linux	'linux'
Windows	'win32'
Windows/Cygwin	'cygwin'
macOS	'darwin'

이 이슈는 다음 코드에서 문제가 발생하게 되었습니다.

if "win" not in sys.platform:
  #something

위 코드로 windows라고 판별하게 된다면 Mac에서의 값인 darwin과 Windows에서의 값인 win32와 cygwin을 구별하지 못하게 됩니다.
ps. 포스트를 작성하면서 Windows내에서 win32와 cygwin 두 가지 경우를 커버하기 위해서 저렇게 사용했다는 걸 알게 됐네요...

저렇게 사용한 코드들을 다음 코드처럼 변경하게 되었습니다.

is_win = sys.platform.startswith("win")
if is_win:
  #something

ps. 이제 와서 돌아보니 고친 코드조차 제대로 역할을 수행하지 못하는 코드였네요.. 풀리퀘를 빨리 수정해야겠네요.😣

이렇게 에러를 고치고 나니 거의 6시가 되어 행사가 다 끝나가는 시간이어서 더 많은 이슈해결은 기대하기 어려울 것 같아 마무리 지었습니다.

후기 👨🏻‍💻

이 행사를 통해서 정말 많은 것들을 알게 되었지만, 가장 인상 깊었던 3 가지가 있습니다.

1. dependency의 위험성
2. git의 중요성
3. 오픈소스 기여의 중요성

dependency의 위험성

이번에 기여한 두 프로젝트에서 공통적으로 경험한 이슈가 있습니다. 바로 플랫폼과 dependency 모듈의 버전 호환 문제였습니다. Mocha의 Node.js 버전 호환성, RustPython의 Python 버전 호환성 문제, 두 문제의 성격은 다르긴 하지만 모두 dependency의 위험성을 알려주는 중요한 경험이라고 생각합니다.

ps. nvm을 사용하시면 Mocha의 Node.js 버전 호환성 이슈를 쉽게 해결하실 수 있습니다.🙂

git의 중요성

이번 행사에서 또 정말 중요하다고 느낀 점이 git 사용 방법을 정확히 익히자는 것이었습니다. 기존에 제가 git을 사용하는 환경은 단순히 remote와 origin이 같은 환경이었고, 커밋을 잘못하더라도, 크게 문제가 되지 않는 프로젝트였습니다. 하지만 오픈소스 프로젝트에서 git은 그보다 훨씬 중요한 의미였습니다. commit 메세지부터 풀리퀘 내용, git username 등등 정말 git을 "잘" 알고 사용해야겠다는 생각이 들었습니다.

사실, Mocha에 풀리퀘를 보낼 때, 노트북을 사용한지 얼마 되지 않아서 로컬에서 username과 email이 등록되지 않은 상태로 커밋을 하고 보내서 다음과 같은 메세지와 함께 풀리퀘가 거부가 되었습니다.

결국 푸쉬된 커밋을 취소하고 username과 email을 등록하고 다시 커밋하고 푸쉬하는 복잡한 작업을 하는 과정에서 또 많은 어려움을 만났습니다.🤯 결국 정윤원님의 도움을 받아서 해결했지만, git의 중요성을 다시 한 번 느끼게 되었습니다.

오픈소스 기여의 중요성

이번 스프린트에서 코드적인 부분에서 엄청난 기여를 하진 않았습니다. 하지만 오픈소스 기여의 첫 발자국을 내디뎠다는 점에서 저에게 좋은 경험이 되었습니다.

오픈소스 기여가 아니었다면 주니어 개발자로서 하지 못했을 경험을 했습니다. 정말 다양한 에러와 이슈들을 만나고, 잘 알지 못하는 분야의 지식을 습득하는 것은 정말 힘들지만 값진 경험이었습니다. 정말 개발자들이 왜 오픈소스 기여를 장려하는지 알게 되었습니다.

마무리

이 글을 읽는 분들도 오늘부터 재밌어 보이는 오픈소스 프로젝트 하나를 골라서 기여를 시작해보시는 걸 추천해 드립니다. 확실히 개발을 시작하신 지 얼마 되지 않은 분들에게는 높은 허들이라고 생각합니다. 하지만 스프린트 서울 같은 오픈소스 행사들에 참가하셔서 리더분들의 도움을 받으시면서 오픈소스 기여를 시작하신다면 엄청나게 성장한 자신을 만날 수 있을 거라 확신합니다.

긴 글 읽어주셔서 감사합니다.😊