오픈소스 멘토링 3기 참가 후기

오다혜·2024년 3월 17일
2

멘토링 지원, 선발 그리고 왕 부담

개발 공부를 시작하고는 4년 반, (돈을 받고) 일을 시작한 지 2년 반, '프론트엔드 개발자'가 된 지는 1년 반이 되었다. 그동안 오픈소스 컨트리뷰터가 되고 싶은 마음이 막연하게 있었지만 두려움 때문에 시작을 못하고 있었다. 오픈소스는 실력이 뛰어난 개발자만 하는 거라는 생각을 핑곗거리 삼아 합리화했달까. 사실 문서 번역이라도 했어도 됐을텐데 혼자서는 게으름 이슈..로 사실상 아무 것도 하지 못했다.

혼자서는 도저히 안 되겠어서 오픈소스 오픈 카톡방에 들어갔다. 2기까지 멘토링이 진행되었고 올해(2024년) 초에 3기 멘토링을 모집하신다는 정보를 입수하고 존버(?) 하다가 모집글이 올라온 걸 알게 되고 바로 지원서를 작성했다.

정말 참가하고 싶었는데 뽑히게 되어서 기쁜 마음도 잠시, 50명 넘는 지원자들 중에 뽑히게 된 만큼 잘해야 된다는 생각에 부담이 밀려왔다. 심지어 같이 뽑힌 팀원분들 중에 이미 오픈소스에 기여해보신 분이 절반 이상이셨다. (나는 MDN 번역도 안 해본 의지박약 감자인데...)

이런 나도 멘토링 기간 안에 PR을 만들었다! 멘토링 경험이 너무 좋았어서 모두에게 이 경험을 공유하고자 이 글을 작성하게 되었다.

멘토링 진행

약 일주일 안에 이슈 선정부터 PR 생성과 회고까지 진행되는 속성 과정이었다.

  • 수(3/5) ~ 목(3/6): 이슈 선정
  • 목(3/6)
    - 21:00 ~ 22:30: 각자 선정한 이슈 피드백 및 해결 방법 고민/공유
  • 토(3/8)
    - 20:00 ~ 22:00: PR 생성
    - 22:00 ~ 23:00: 회고

이슈 선정

오픈소스 첫 기여 가이드에도 나와있다시피 이슈 선정이 무엇보다 중요했다. 길어봤다 이틀 안에 해결해야 하기 때문에 쉽고, 문제 해결 방법이 명확해야 했다.

적절한 이슈(쉬운 이슈)란 아래의 조건을 만족하는 이슈다.
1. 정확히 어떤 현상이 왜 이상하고, 어떤 코드가 의심되는지 명시되어 있음
2. 재현할 수 있는 테스트 코드와 결과가 있음
3. 제안하는 수정 방안이 있음

스타일링 쪽에 관심이 있어서 처음에는 tailwindcss, chakra ui 쪽 에서 이슈를 선정하고자 했는데 막상 이슈들을 보니까 라벨링이 잘 되어 있지 않아서 파악하기가 어려웠다. 1시간 정도 보다가 진입 장벽이 높아서 깔끔하게 포기하고 다른 오픈소스를 탐색했다.

내가 고른 이슈는 Rollup 에서 Error 객체를 콘솔에 찍는 방법을 개선하는 이슈였다. Error 내에 cause 가 있으면 모든 cause 를 다 콘솔에 찍어달라는 요청이었다.
https://github.com/rollup/rollup/issues/5166



테스트코드는 없었지만 1번과 3번을 만족하는 이슈였다. 특별히 메인테이너가 어느 부분을 개선해야 하는지 정확히 코드 위치를 집어주어서 어려움 없이 개선할 수 있을 거 같다고 생각했다.

해결 과정

쉬운 이슈임에도 불구하고 내가 생각했던 것보다 PR 을 날리는 건 더 어려웠다.

문제 1. 세팅

개선하려면 일단 프로젝트를 돌려야 하는데 rollup 이 내부에서 rust 를 사용하고 있었다. CONTRIBUTING.md에서 시키는대로 세팅을 했지만 빌드가 터지는 문제가 발생했다. 내가 개선해야 하는 부분은 다행히도 로컬에서 테스트할 수는 있어서 빌드는 일단 넘어가기로 했다. 멘토님께서 말씀하시길, 정석은 아니지만 다른 프로젝트들도 세팅이 잘 안 되는 경우에는 PR 을 일단 날리고 github action 에서 돌아가는 테스트로 확인하기도 한다고 하셨다.

문제 2. 테스트

쉬운 이슈의 조건 중 2개는 만족하는 이슈였지만 Rollup 내부에서 내가 개선해야 하는 함수에 대한 단위테스트가 존재하지 않았다. 테스트 케이스를 추가하는 게 아니고 처음부터 만들어야 하다보니 막막했다. 더군다나 단위 테스트 코드를 짜본 적도 없었다. 결론적으로는 일단 개선 PR 을 날리고 메인테이너의 의견을 받아보기로 했다. 고민이 될 때는 일단 작업을 한 뒤에 메인테이너의 의견을 받는 식으로 진행하는 편이 좋다고 하셨다.

문제 3. javascript Error

그냥 출력 로직만 살짝 수정하면 되는 줄 알았는데 javascript ECMA 2022 에서 업데이트된 Error 객체에 대해 잘 알아야 해결할 수 있었다.

// ES5

interface Error {
	
	name: string;
	
	message: string;
	
	stack?: string;

}

// ES2022
interface Error {

	cause?: unknown;

}

이슈 수정하면서 Node 에서는 에러를 어떻게 출력하고 있는지, 새로운 Error 객체가 어떻게 정의되었는지 잘 알게 되었다.

오픈소스 기부

이번 멘토링에서는 오픈소스에 기부를 하는 룰이 추가되었다.
원하는 오픈소스에 기부하면 애정도가 상승하면서 오픈소스에 대한 관심도도 높아질 수 있을 것이라는 기대로 처음 도입된 룰이라고 하셨다. 원하는 오픈소스 혹은 컨트리뷰터에게 자유롭게 50$ 를 기부하면 된다.

나는 vite 에 50$ 를 기부했다! (이제 나도 vite 주인이야~) 응원하는 기업의 주식을 사서 투자하는 것과 비슷한 느낌이 아닐까? 돈이 들어가서 그런지 마음 속에 오픈소스가 한층 더 커지고 의지도 활활🔥 불타게 되었다. github 에서 confetti 애니메이션도 보여줘서 2배로 뿌듯했다..

PR, 그리고 리뷰

일단 멘토링 시간 내에 PR 을 올리고 리뷰를 기다렸다! Rollup 메인테이너 분이 굉장히 부지런하신지 며칠 만에 바로 리뷰를 달아주셨다.

테스트를 안 짜고 올렸더니.. 테스트에 대한 설명도 친절히 남겨주셨고, 개선 방향을 좀 더 상세히 남겨주셨다. 나같으면 내가 그냥 바꾸고 말텐데 방법까지 알려주다니 정말 친절한 메인테이너라고 생각했다. 무료로 메인테이너에게 강의를 받는 느낌이었다! 아직 개선 커밋은 안 올렸지만(바빠서..?) 이번주 중으로 개선한 다음에 리뷰를 요청해보려고 한다 :D

느낀점

물고기를 잡아주는 게 아니라 물고기를 잡는 법을 배울 수 있었던 멘토링 시간이었다. 오픈소스 기여 방법도 배웠지만 인생에서 성장하는 방법 자체를 배울 수 있었다.

쉬운 것부터, 걸음마부터

오픈소스 <첫 기여> 는 무조건 <쉬운 이슈 선정>이 중요하다는 것.
무엇을 도전함에 있어서도 <첫 시작>은 무조건 <쉬운 도전>이 중요하다는 것.

최근에 개발자 직군이 나에게 맞는지 진로 고민도 진지하게 하고 있었고, 나의 목표 대비 더딘 성장에 좌절도 많이 했었다. (정말 진지하게 클라이머나 복서가 되고 싶기도 했다^^) 근데 내가 처음부터 대단한 걸 하려고 해서 그랬구나 하는 깨달음을 얻었고, 큰 성취가 아니라 작은 노력들을 쌓아서 꾸준히 노력해야겠다고 생각했다. 지름길은 어디에도 없다!

PR은 작은 단위로

Rollup 내에 에러에 대한 타입이 생각보다 제대로 잡혀있지 않았고 이 또한 개선하고 싶은 부분이었다. 근데 멘토님께 공유드리니 해당 부분은 내가 만들 PR 이 머지된 이후에 다시 개선사항으로 만들자고 조언해주셨다. 조언을 듣고 PR을 날린 후에 메인테이너의 리뷰를 받으니까 더 확실한 방향을 알 수 있어서 좋았다.
사내에서 개선 PR을 날릴 때에도 지금까지는 눈에 보이는 것을 모두 바꾸느라 내 PR 단위도 너무 커지고, 작업 시간도 너무 길어졌다. 개선하는 사람도, 리뷰하는 사람도 힘든 PR을 만들고 있었는데 잘못된 습관이었다는 것을 깨달았고 앞으로는 사내의 PR 도 더 작게 쪼개야겠다고 생각했다.

오픈소스에 도전하자.

멘토님이 한국은 시장이 작으니 오픈소스를 통해서 영향력을 더 넓혔으면 좋겠다고 하셨다. 하다보니 큰 오픈소스에 기여도 하고 꾸준히 하다보니 커리어가 되셨다고. 꾸준히 하다보면 정말 도움이 많이 될 거 같다. 개발 실력도 많이 늘고 영어 실력도 늘고. 가벼운 마음으로 시간 날 때마다 쉬운 이슈들에 도전해보고자 한다.

나같은 주니어 개발자에게 정말 추천하고 싶은 공부 방법이다.

  1. 빠르게 실전에 부딪혀볼 수 있다.
    토이 프로젝트는 기획,설계,세팅 등 생각보다 기술 습득을 위해 해야 할 부가적인 일이 많다는 단점이 있는데 이미 만들어진 프로젝트를 개선하는 것이라서 공부를 더 효율적으로 할 수 있다.
  2. 오픈소스 내부 구조를 파악할 수 있다.
    내부 구현이 어떻게 되어 있는지 까보고 싶은 마음은 있지만 솔직히 어디서부터 어떻게 봐야 할 지 막막했던 경험이 다들 있을 거라고 생각한다. 근데 이슈를 해결하고자 하면 해당 이슈와 관련 있는 코드를 보게 되고 결국에는 전체 프로젝트를 파악할 수 있게 되는 것을 느꼈다.
  3. 많은 사람들에게 임팩트를 줄 수 있다.
    개발자들은 내가 짠 코드가 내 자식 같이 느껴질 때가 많다. 근데 내 코드가 개발자들이 사용하는 오픈소스의 일부가 되었다면.. 이 얼마나 예쁜 자식이겠는가! 👶

공부는 하고 싶은데 뭘 해야 할 지 모르겠다면, 빠르게 성장하고 싶다면 오픈소스를 하자!!

비고

profile
프론트엔드에 백엔드 한 스푼 🥄

0개의 댓글