오픈소스 기여하기 회고 3

이번 포스팅을 마지막으로 오픈소스 기여하기 시리즈는 끝입니다. 마지막인만큼 오픈소스 컨트리뷰터로서 활동하는 것에 대한 느낀점을 쭈욱 나열하는 형식으로 적어보려고 합니다.

 

오픈소스를 왜 시작했어요 ?

"유명한 오픈소스에 내 코드를 남겨보자" 

시작하자고 마음을 먹은 이유자체는 정말 순수했습니다. 물론 앞선 포스팅에서 다양한 이유들도 적어두긴 했습니다만, 위와 같은 이유가 제일 컸습니다. 자랑하거나 유명해지고 싶었다고 할까요?

 

쉽지 않은 길이라는 것을 미리 알고는 있었지만, 때로는 이런 무모하고 단순한 이유들이 가장 큰 원동력이 되기도 합니다. 어렵거나 큰일을 이루어 내기 위해서는 해내야하는 수많은 일들이 있는데 이런 순수한 감정들은 정말 큰 도움이 됩니다.

 

패치할만한 버그를 찾는 과정은 고달프다

오픈소스를 사용하다 버그를 발견해서 패치할 수 있다면 그것은 정말 금상첨화와도 같을 것입니다. 하지만, 대부분의 경우는 이미 누군가는 시도를 하고 있거나 잘못된 사용법으로 인해 발생하는 것입니다. 물론, 번역이나 문서화 혹은 아이디어 제시 같은 것도 모두 오픈소스에 기여하는 행동입니다.

 

그런데 저는.. 버그를 패치하는 기여를 하고 싶었습니다. 유명 오픈소스들이 잘 관리되고 성장한 이유 그리고 코드베이스의 퀄리티 이 두가지를 경험해보고 싶었기 때문입니다.

 

그래서 사용하는 오픈소스들의 버그/이슈 티켓들을 컴퓨터에 앉으면 정말 시도때도 없이 확인했습니다. 여기서 생각보다 많은 감정소모를 했습니다. 뭔가 점점 조급해지는 마음도 들었구요.

그래도 소프트웨어의 버그는 늘 존재하기에 패치할만한 것들은 많이 있습니다 :)

Django Bug Tracker

Django

 

패치를 시작하다

디버깅 & 디버깅 & 디버깅

네.. 패치를 하기 위해서 무한 디버깅을 했습니다. 

특히나, 버그가 발생하는 플로우의 코드들을 따라 읽어가면서 전체적인 흐름을 파악하는 것이 굉장히 어려웠습니다. 워낙에 많은 양의 코드가 있고 모두 처음보는 코드들이니까요. 그 역할을 제대로 이해하기란 여간 쉬운게 아닙니다.

 

그래도 반복학습엔 장사없다고 계속해서 보다보니 그림이 그려지고, 그 시점에서 손으로 글을 써가며 정리도 해보니 익숙해졌습니다. 그러다 어느 순간 특정한 곳에서 발생하는 문제일 것이라는 가정을 세우게 됩니다. 그리고 해결방법을 계속해서 생각해냅니다. 물론 중간중간 어떤 패치들과 변경사항이 있었는지도 꼼꼼하게 체크해야 합니다. (때로는 어떤 패치로 인해 버그가 발생했을 수도 있고, 맥락을 이해하는데 큰 도움이 됩니다.)

 

그런데 저의 경우는 문제를 찾고나면 생각보다 쉽게?? 해결책이 떠올라서 버그를 픽스하는 것 자체에는 큰 시간이 들지 않았습니다. 하지만 마음 한구석에는 이게 진짜 이 문제가 맞나? 올바른 방향의 패치가 맞나 ? 라는 생각이 자리잡고 있었습니다.

 

PR 오픈

하지만 무한정 시간을 쏟을 수도 없을 뿐더러 더 깊게 파본다 한들 얻는 것은 없을것 같다고 생각했습니다. 그래서 리뷰를 위해 PR을 오픈하고 작성한 패치와 테스트에 대해서 설명을 적어두고 기다리는 시간을 가집니다.

 

리뷰는 언제쯤..

항상 현업에서는 매우 빠른 주기를 가지고 리뷰/피드백을 거쳐왔던터라 빠른 사이클에 익숙해져 있었습니다. 이 부분이 오픈소스를 하면서 가장 잘못했던 부분이었다고 생각합니다.

 

첫 PR에는 차마 1일을 기다리지 못하고 메인테이너를 언급하여 리뷰를 요청했습니다. 물론, 다른 PR들에 리뷰가 계속해서 달리는 것도 보았고 활동을 하는 것처럼 보였기 때문입니다..ㅎㅎ 그런데 여기서 메인테이너분이 기다림이 필요하다는 코멘트와 함께 관련된 내용이 담긴 장고 문서를 보내주셨는데 여기서 아차 싶었습니다.

 

간략하게 얘기하자면 해당 문서에는 모두 Volunteer이고 중요도와 개개인의 일정에 따라서 리뷰가 늦어질 수 있다. 하지만 절대 무시하는 것은 아니다. 라는 점을 강조하고 있었습니다. 딱 저의 상황에 맞는 내용이었죠.

Contributing code FAQ

FAQ: Contributing code | Django documentation | Django

 

그래도 2~3주 정도면 리뷰가 달릴 것이라는 희망아닌 희망을 갖고 있었습니다. 그리고 리뷰를 간절하게 받아보고 싶었던 마음 때문에 깃허브로부터 알림이 온 메일은 없는지 진짜 하루에도 수십번씩을 2주정도는 들락날락 했습니다. 저는 이 기다림이 감정소모가 가장 크고 힘들었던 것 같습니다. 

 

개인적인 추천이지만 이 때에는 패치거리를 더 찾아보시거나 다른 일을 하면서 잊으면서 지내는 것이 속편합니다. 저도 다른 패치를 찾아보다가 시도한 패치의 PR이 오히려 먼저 Merged 되었습니다.

 

Django Contributor 등극

리뷰가 달린 코멘트를 반영하고 나서도 수시로 메일함을 들락거렸습니다. 그러다 어느날 자다깬 새벽이었습니다. 뭔가 갑자기 메일함을 열어보고 싶더군요. 

 

엥? Main ~~~ 하면서 깃허브로부터 약 몇통의 메일을 온 것을 확인했습니다. 처음에는 비몽사몽이었기에 뭐지??? 싶었는데 자세히 들여다보니 Main에 제 PR이 Merged 되었다는 것이었습니다!!

 

와.. 간절히 바랬던 것이라 그런지 이 순간부터 약 하루정도는 진짜 웃음만 났던것 같습니다. 말로 할수 없는 뿌듯함도 있었고 그동안 기다렸던 초조함도 싹 가셨습니다.

 

https://github.com/django/django/pull/16120

Fixed #34052 -- Made migrate --check don't emit signals and output when up to date. by na86421 · Pull Request #16120 · django/

 

재밌는데 성장까지 ?

제가 오픈했던 PR들에 적힌 코멘트에서 발견한 공통적인 것은, 내용이 길지는 않았지만 굉장히 많은 것들이 함축되어 있었습니다. 오픈소스 컨트리뷰터로서 실력적인 측면에서 가장 큰 성장을 이룰 수 있는 부분이 리뷰과정인 것 같습니다.

 

특히나 저는 잘 알고 있다고 자부하고 있던 테스트에 대해서 모자란 부분이 많구나 라는 것을 느꼈습니다. 또한, 패치한 코드 보다도 테스트를 더 중요시 하는 것처럼 보였습니다. 이런 부분들이 저에게는 TDD의 관점과 상당히 닮아있다라고 생각했습니다. 

여태까지의 저는 테스트는 따라오는 존재였다면, 오픈소스 생태계에서는 테스트가 먼저 앞서고 코드가 나중에 따라오는 것 같은 느낌이었습니다. 

 

또, 위에서 패치가 올바른지 아닌지에 대한 고민들이 있던 부분도 테스트로부터 해소할 수 있었는데요. 리뷰어들로부터 테스트 시나리오를 공유 받거나 추가 테스트가 필요하다라고 피드백을 받았는데 이런 것들이 모여서 올바른 방향의 패치인가를 판단하는데 큰 도움이 되었습니다. 테스트를 변경하고 추가 하다보니 잘못 파악한 원인들도 종종 있었습니다.

 

위에서는 힘든 것 같은 뉘앙스를 보였지만, 그냥 순수하게 이 과정자체가 재밌었습니다. 개발을 처음 시작했던때의 기분도 들고 코드를 작성하는 것 자체도 재미있었고, 배운다는 느낌도 정말 좋았습니다.

 

익숙하지 않은 곳에서의 개발, 그리고 리뷰과정을 거치면서 꽤 많은 성장을 했다고 스스로 자부할 수 있습니다.

 

맺으며

실제로 오픈소스에 관심은 많지만 시작하기에는 어려워하는 분들이 대부분일 것이라고 생각합니다. 물론 저도 그랬구요.

 

그래도 관심이 있다면 시도해보는 것을 추천드립니다. 무조건 Merged 되는 것만이 목표는 아닙니다. 디버깅과 리뷰를 받는 과정에서 성장하는 것이 가장 크고 어떠한 이유로 거절되었다면 더 나은 방향을 생각해보는 계기도 될 것입니다.

 

저는 글을 쓰는 지금 이 순간에도 계속해서 장고 컨트리뷰터로서 활동을 하고 있습니다. 이 열기가 언제 식을지는 잘 모르겠습니다 ㅎㅎ 식더라도 관심자체는 계속 유지될 것 같네요.

 

 

지금까지 긴 시리즈 읽어주셔서 감사합니다.

다음에는 더 유익하고 알찬 글로 찾아뵙겠습니다 :)