안녕하세요! FE플랫폼팀에서 사내 NPM, 스타일 가이드, 그리고 최근에는 웹 성능과 관련된 업무를 담당하고 있는 joah입니다. 최근 카카오 사내 기술 세미나 ‘Techtalk’에서 발표했던 오픈소스 활동 소개와 오픈소스 활동을 통해 개발자로서 성장했던 이야기를 공유하고자 합니다.

오픈소스 활동

저는 다양한 오픈소스 활동을 하고 있습니다. 아래 이미지는 Github 커밋 기록인데요, 카카오에 입사한 2019년을 시작으로 지금까지 꾸준히 활동하고 있습니다. 현재는 Rome과 ESLint라는 프로젝트에서 코어 컨트리뷰터와 커미터로, Microsoft Typescript 웹사이트 한국어 번역 프로젝트에 리뷰어로 활동하고 있습니다.

Rome

https://github.com/rome/tools

Rome은 TS, JS, HTML, CSS를 위한 린터, 번들러, 트랜스 파일러입니다. 현재 프론트엔드 개발 환경을 구축하기 위해선 웹팩, ESLint, Prettier, Babel 과 같이 다양한 도구를 사용해야 하는데 이를 하나로 통합하려는 프로젝트입니다. 아직 정식 버전이 릴리즈 되지 않았는데, 조금씩 기능이 완성이 되어가고 있습니다. 저는 Rome 내에서 주로 TypeScript랑 CSS 파서 쪽을 컨트리뷰션하고 있습니다.

ESLint

https://github.com/eslint/eslint

ESLint는 아마 많은 분들이 사용하실 것 같아요. JavaScript 코드에 스타일이나 문제점 등을 찾아서 알려주고, 자동으로 고칠 수 있는 경우에는 직접 수정까지 해주는 프로그램입니다. 주간 다운로드 수가 1000만이 넘어갈 정도로 많이 사용되고 있는 프로젝트이고요, 파트에서 담당하고 있는 카카오 자바스크립트 스타일 가이드도 ESLint를 사용하고 있습니다.

TypeScript Website Localizations

https://github.com/microsoft/TypeScript-Website-Localizations

TypeScript Website Localizations라는 프로젝트입니다. 타입스크립트 웹 사이트에 다국어 지원을 위한 번역 프로젝트로, 현재는 참여율이 조금 저조한 상태이지만 혹시 타입스크립트에 관심이 있다면 기여를 통해 도와주시면 감사하겠습니다. : )

오픈소스 참여기

신입 개발자의 고민

입사 후 신입 개발자로서 성장에 대한 고민들이 있었습니다. 성장을 하고 싶은데 어떻게 해야 할지 아마 대부분의 신입 개발자라면 한 번쯤 고민해 보았을 것 같은데요, 업무를 맡아 코드를 짰고, 동작은 하는데 코드를 이렇게 짜도 괜찮나…?라는 걱정도 있었습니다. 또 코드 리뷰를 자세히 받아보고 싶은데 업무 일정도 정해져 있다 보니 다소 부담스럽기도 했습니다.

그래서 다양한 방법으로 성장을 위한 노력을 했습니다. 토이 프로젝트, 개발 서적, 온라인 강의, 그룹 스터디 와 같이 일반적으로 알려져 있는 방법들을 많이 활용했습니다. 그런데 대부분 새로운 지식을 얻는 데는 효과적이었지만, 코드 리뷰를 받고 싶다거나 코드를 이렇게 짜도 되는지? 와 같이 근본적으로 가지고 있던 질문에 대한 답은 얻지는 못했습니다.

오픈소스에 참여해보자

성장 방법에 대한 다양한 고민 끝에 오픈소스에 참여해보면 어떨까라는 생각을 했었습니다. 그 당시의 생각은 유명한 오픈소스는 긴 시간 동안 개발/ 리팩터링 된 코드들이 많이 있어 배울 점이 많을 것 같았고, Pull Request를 날리고 리뷰를 받는 프로세스로 꼼꼼한 코드 리뷰를 받아보고 싶었습니다.

또한 내가 하고 싶을 때, 여유 있는 시간에 참여할 수 있을 것 같다고 생각했습니다. 하지만 어떤 프로젝트를 참여해야 할지 다소 막막했었는데요, React나 Typescript 등의 프로젝트에 기여해 보고 싶었는데 막상 들어가서 시작하려니까 너무 막연한 상태였습니다.

오픈소스 접근 방식

처음에는 전체 소스코드를 분석해서 원리와 동작을 먼저 파악하고 기여를 해야겠다고 생각했지만 봐야 할 코드가 끝이 없었습니다. 그러던 중에 ESLint 프로젝트에서 해결하기 쉬워 보이는 이슈를 찾게 되었고, 이슈 내용 중 어떤 함수에 정규식에 오류가 있는 것 같다는 힌트까지 써져있었습니다.

쉬워 보이는 이슈

바로 수정하는 PR 을 만들어서 날렸고 코드 리뷰를 거친 후에 머지가 되었는데요, 테스트 코드를 제외하고는 정규식 s 플래그 한자만 추가한 PR이었습니다. 예상했던 대로 난이도가 좀 낮은 이슈였지만 오픈소스에 기여했다는 뿌듯함과 자신감을 얻게 되었습니다. 그리고 저 함수가 어떤 일을 하게 되는지 알게 되니 저 함수를 사용하는 코드들도 조금씩 이해가 되었습니다.

ESLint 첫 PR Merge ?

전체 소스 코드를 분석해서 이해한 뒤에 접근하기보다는 이슈 해결을 목표로, 이슈 해결에 필요한 부분만 분석하는 방식으로 접근하니 오픈소스 참여가 더 즐거워졌습니다.

이후 ESLint 프로젝트에 해결할 이슈를 찾고 PR 을 날리는 과정을 반복하게 됩니다. 초반에는 간단한 버그 수정 위주로 시작했는데요, 하다 보니 점점 이해되는 코드가 많아지고 프로젝트에 대한 전반적인 이해도가 올라가게 되어서 버그 수정뿐만 아니라 기능을 추가하는 PR 을 날려보기도 했습니다.

이슈 해결 반복

프로젝트에 대한 이해도가 올라가니 코드 수정 이외에 활동도 할 수 있었습니다. 사용자들이 남긴 이슈에 대해서 가끔 메인테이너 대신 답변을 달기 시작했는데요, 사실 이는 의도적으로 오픈소스 커뮤니티에서 인정을 받고 커뮤니티에 기여하기 위한 행동이었습니다.

메인테이너인 대신 답변 달기

실제로 오픈소스 커뮤니티에서는 코드 기여뿐만 아니라 이슈에 대한 토론, 답변과 같은 활동에도 높은 가치를 주고 있었습니다. 3~4개월 정도 활발하게 활동을 하고 나니 커미터로 추천한다는 제안을 받았고, 그 후로 저는 커미터로서 프로젝트에 참여하게 되었습니다.

오픈소스에서 얻을 수 있는 경험

Code Review

코드 리뷰는 개발자가 직접 해주는 것이라 오픈소스만의 특징이라기보다는 리뷰어에 따라 차이가 있다고 생각합니다. 하지만 제가 오픈소스 활동을 통해 경험한 바로는 오픈소스에서 코드 리뷰를 조금 더 꼼꼼하게 받는다고 느꼈습니다. 실제로 변수, 함수 네이밍부터 부족한 테스트 케이스에 대한 리뷰와 주석에 대한 내용까지 꼼꼼하게 리뷰를 받기도 하였습니다.

저 또한 커미터가 된 후 리뷰어에 입장에서 리뷰를 할 때는 좀 더 꼼꼼한 코드 리뷰를 하게 되었습니다. 회사에서는 동료가 작성한 PR이 머지가 된 후에 문제가 발생하면 동료한테 알려주고 수정해 달라고 요청할 수가 있는데요, 오픈소스에서는 컨트리뷰터의 PR을 머지한 후에 컨트리뷰터에게 수정 요청을 할 수가 없는 형태이기 때문에 머지 전에 문제가 발생하지 않고, 발생하더라도 내가 직접 수정할 수 있을 정도로 꼼꼼하게 코드 리뷰를 하게 된다고 생각해서 저도 리뷰를 하면서 꼼꼼하게 코드 리뷰를 하는 훈련이 되었습니다.

마지막으로 오픈소스 멤버 중에 Facebook이나 Google 엔지니어들도 있는데요, 글로벌기업의 엔지니어에게 코드 리뷰를 받을 수 있는 경험도 조금 색다른 경험이지 않나 싶습니다. ?

Deep Dive

다음으로 딥 다이브, 조금 더 특정 분야를 깊게 파보는 경험을 할 수 있었습니다.

프로젝트마다 다르겠지만 오픈소스는 상업 서비스보다는 어떤 문제를 해결하거나 어떤 특정 기술을 구현한 경우가 많은데요, 이런 프로젝트에 기여를 하다 보면 회사에서는 경험하기 힘든 분야에 대해 깊은 지식과 리서치를 하는 경험을 하게 되었습니다.

예를 들어 ESLint 프로젝트의 경우 ECMAScript spec 을 지원하기 때문에 스펙 문서를 직접 살펴보는 작업이 필요했고, Rome 프로젝트에서는 CSS 파서를 구현하기 위해서 CSS 스펙 문서를 보면서 토크나이징이 어떻게 이루어지는지, 어떤 문법이 올바른 문법인지 등을 찾아보는 경험을 할 수 있었습니다.

Test

다음으로는 테스트입니다. 잘 유지되고 있는 오픈소스에서는 잘 구성된 테스트 환경에서 코딩하는 경험을 할 수 있습니다. 코드 수정에 테스트 케이스가 없으면 대부분 리뷰가 달리게 되고, 적어도 모든 분기문을 테스트하는 테스트 케이스를 요청받기 때문에 꼼꼼한 테스트 케이스 작성을 경험하게 됩니다.

그리고 그 환경에서 작업을 하다 보면 스스로가 작은 기능 수정에도 얼마나 많은 실수를 하는지 깨닫게 되는데요, 기능 추가 작업으로 기존에 테스트 케이스를 실패하는 경우가 많이 있는데 만약 테스트 케이스가 없었다면 그냥 머지가 될 수도 있고 나중에 문제를 만들 수도 있겠죠! 이런 경험을 통해 테스트 케이스의 중요성도 느낄 수 있었습니다.

마치며

먼저 저에게 가장 오픈소스에 큰 진입장벽이 되었던 것은 영어였습니다. 영어가 부족하다 보니 처음에 오픈소스에 접근하기 꺼렸던 것도 사실입니다. 하지만 열심히 번역기도 돌려보고 부딪혀보니 문법은 조금 틀려도 커뮤니케이션에 큰 문제는 없더라고요! 다만 이슈 해결 이외에 조금 기술적으로 깊은 대화가 있을 때는 아직도 어려워서 참여를 잘 못하고 있는데요, 열심히 공부해서 극복해야 할 미션이라고 생각합니다.

오픈소스를 통해 다양한 성장의 경험을 할 수 있다는 걸 이 글을 통해 전해드리고 싶었고, 혹시 저의 경험에 공감하시고 관심이 있으신 분들은 오픈소스에 참여하는 기회가 많이 있었으면 좋겠습니다. 감사합니다.

FE개발자의 성장 스토리 10 : 주니어 FE 개발자 오픈소스 성장기