스프린트는 오픈소스 프로젝트의 메인테이너들이나 많이 참여해 본 사람들이 새로 참여해 보고 싶은 사람들을 도와주어 기여해 볼 수 있게 해주는 행사이다. 내가 처음 스프린트에 대해서 들은 것은 PyCon 후기를 들으면서 알게 되었고 PyCon Korea에서도 몇 년 전부터 콘퍼런스와 함께 스프린트를 진행하고 있다. Node.js에는 Code + Learn이라는 비슷한 행사가 있다.

PyCon 스프린트에 한 번도 참여해 본 적이 없지만, 작년부터 lqez님과 scari님이 SprintSeoul이라는 행사를 만들어서 격월로 스프린트 행사를 진행하고 있다.(SprintSeoul도 그렇지만 PyCon도 Python으로만 스프린트를 하는 것은 아니다.) 나는 올 2월부터 mocha로 참여하기 시작했고 그렇게 보면 이번 PyCon 스프린트는 4번째 참석하는 행사이다.

스프린트에 참여하는 것은 다른 사람이 기여할 수 있도록 돕는 것도 있지만 어쩌다가 mocha의 메인테이너가 되었음에도 여전히 mocha 코드 대부분을 아는 것도 아니고 나도 겨우 해나가고 있다. 그런데도 mocha란 이름으로 자꾸 뭔가 하는 것은 mocha를 더 열심히 해야겠다는 자극을 받으려고 하는 이유가 크다.(일종의 벼랑 끝 전술이랄까...)

사실 스프린트에 대해서 잘 몰랐기에 처음 참여할 때부터 가서 무엇을 해야 하지 걱정하면서 참여를 했다. 지난 SprintSeoul에서는 항상 mocha는 1~2명의 참여자분들만 있었기 때문에 이슈고르는 것을 도와주고 실행 방법이나 테스트 방법 등을 도와주는 정도였고 머지까지는 안되더라도 대부분 PR 올리는 데까지는 성공하셨다. 나도 어떻게 도와드려야 하는지 몰라서 어정쩡하게 있었던 것도 있었고 알아서 작업을 잘하셔서 크게 뭔가 한 것은 없었다.

PyCon 스프린트 참석

원래는 다른 언어도 되는지 몰랐다가 mocha로 참여해도 된다는 걸 알게 되었지만 참여할지 말지를 좀 고민했다. PyCon이란 것을 망각하고 몇 번 해본 SprintSeoul 느낌으로만 참여 여부를 고민하고 있었기에 내 고민은 주말 포함 2일동안 스프린트를 하고 2일 PyCon 콘퍼런스를 참여하고 나면 너무 피곤하지 않을까 따위의 일이었다. 심지어 2일 스프린트지만 평일인 둘째 날은 사람이 없을 수도 있는데 휴가를 쓰지 말까? 같은 생각을 하고 있었다. 그러다가 요즘 코딩 많이 못 하는데 이틀 열심히 코딩이나 하고 오지라는 생각에 느지막이 참가를 신청했다.

그러고 스프린트 행사가 다가오면서 참석자가 18명까지 늘어나는 것을 보고 엄청나게 놀랬다. 18명이면 교육을 해도 적지 않은 숫자인데 어떻게 도와드리지? 스프린트를 도와줄 다른 사람이라도 구해야 하나 하는 걱정을 하다가 당일이 되었고 어떻게 되겠지 하는 마음으로 참석했다.(pandas는 참석자가 70명이나 되었기에 난 그나마 괜찮지 하고 은근 안심했는지도 모르겠다.)

불행인지 다행인지 스프린트 첫날인 15일에는 비가 많이 왔고 참석자는 5명이 오셨다. 둘째 날도 5명이 오셨는데 4명은 이틀을 다 오셨기 때문에 총 참석은 6명이었다. 결론부터 말하자면 실제로 해보니 내가 하루에 도와드릴 수 있는 분은 5명 정도가 한계인 것 같다. 그 이상 오시면 제대로 못 도와드리거나 할 것 같다.(더 익숙해지면 또 모르겠지만...)

하고 나니 참여하길 참 잘했다고 생각하고 있는데 이틀을 아주 알차게 같이 오픈소스로 즐겁게 논 것 같은 기분이고 스프린트가 어떻게 진행되는지 조금 이해하게 된 것 같다. 그리고 내가 어떤 위치로 오픈소스 기여를 도와주길 원하는지도 깨닫게 되었다.

스프린트 진행

SprintSeoul에서는 안 그랬었는데 5분이나 오셨으니 전체적으로 프로젝트 설명해 드렸다. 소스 레벨에서 설명한 건 아니고(앞에도 말했지만 나도 내가 본 곳 몇 곳 외에는 잘 모른다.) 폴더 구조는 어떻게 되어 있고 관련 프로젝트 구조나 사용하는 도구들을 위주로 설명해 드렸다. 코드야 어차피 이슈 해결하면서 자세히 봐야 하는 거니 처음에 바로 파악하기 어려워 보이는 것들 위주로 설명을 했는데 막상 설명하다 보니 CI니 Lint니 실행 방법이니 설명할 게 꽤 많았다.

mocha 강의가 아니었기 때문에 설명은 간단히 끝내고 일단 이슈를 찾아야 그 부분에 대해서 더 자세히 얘기할 수 있어서 각자 이슈 찾기를 했다. SprintSeoul에서 그랬듯이 그러고 나도 내가 처리할 이슈를 작업하고 있었는데 대부분 이슈를 못 찾고 있다는 걸 깨달았다.

처음 설명해 드릴 때 교과서처럼 good-first-issue에서 먼저 보면 좋고 그렇지 않으면 confirmed-bug나 help wanted처럼 작업하기로 확정된 이슈를 하시는 게 좋을 거라고 했는데 일단 good-first-issue 레이블이 제대로 관리되고 있지 않아서 실제로 작업할 만한 이슈가 내가 봐도 없었고 간단한 이슈들은 또 금방금방 이미 처리되었기 때문에 처음 오신 분들이 판단하기가 쉽지 않았다. SprintSeoul에서도 비슷한 방식으로 도와드리긴 했는데 그때는 1~2분이었기 때문에 크게 의식하고 있지 않았던 것 같다.

그래서 내가 하던 작업을 내려두고 같이 이슈를 찾아드렸다. 또 이틀 내에 처리할 수 있으면서 어느 정도는 명확한 작업이 좋다고 생각했기 때문에 이슈를 하나씩 보면서 해볼 만 한 이슈를 찾았다. 참석하신 분이 코딩 경험이나 JavaScript 이해도를 정확히 모르기 때문에 난이도를 고려하는 게 꽤 어려웠는데 어차피 그냥 쉽게 해결할 수 있는 이슈는 거의 없었기 때문에 난이도보다는 문제 상황이 명확한 이슈를 위주로 골라드렸다. 사실 내가 봤던 부분이 아니면 어디를 수정해야 하는지는 나도 찾아봐야 해서 잘 알지 못했다.

"이 이슈는 어떠한 문제를 얘기하고 있는 거고 그 문제는 발생한 이유는 무엇이고 어떤 식으로 수정하면 해결해 볼 수 있을 것 같다." 정도로만 설명해 드리고 해볼 만 할지 물어보면서 진행을 했다. 실제로 진행할 때 해결방법이 얼마나 복잡해 나도 알지 못했다. 좀 "무책임한가"라는 생각도 했지만 금세 해결할 수 있는 건 내가 했거나 이미 해결됐을 거고 당연히 뭔가 복잡한 이유가 있어서 남아있다고 생각하는 게 당연한 것 같다. 다른 팀은 어떻게 하는지 모르겠지만 메인테이너라도 어디를 어떻게 수정할지 다 알려주는 것은 원하는 것이 아니었고(실제로 몰라서 그렇게 할 수도 없다.) 오픈소스 작업할 때도 여러 시간을 작업한 뒤에도 무의미한 작업이 되는 일이 허다했기 때문에 그 작업 과정 자체가 의미 있다고 위안했다. 맘 같아서는 그렇게 작업한 PR이 다 무사히 머지가 되고 contributor에 이름을 올리게 하고 싶었지만 나 혼자 임의로 머지할 수는 없고 그 PR이 왜 필요한지를 설득하고 어떻게 수정할지 논의하는 과정도 다 오픈소스 기여의 과정이라고 생각하고 있다. 옆에서 약간 먼저 해본 사람으로서 방향만 좀 알려주는 정도가 내가 원하는 역할 정도인 것 같다.

참석자분들이 이슈를 골라서 나랑 논의하면서 그 작업 내용이 어떤지 어떤 문제인지 논의하기도 하고 내가 먼저 찾아서 알려드리기도 하면서 참석자 5분이 작업할 이슈를 다 고르고 나니 오후 3~4시쯤 되었다. 그쯤 되니 5분 정도 계시면 내 작업은 못 하는 거구나 하는 걸 깨닫게 되었다.

막히는 부분은 같이 논의했지만, 구현 방법은 각 참석자분들이 직접 고민해서 해결하셨고 나는 주로 어떤 파일의 어느 부분을 수정하면 될 것 같은지 관련 테스트는 어디 있는지 이 부분을 수정했을 때 다른 영향은 없는지나 지금 진행 중인 다른 작업과 충돌 날 게 있는지 등을 설명해 드렸다. 명확하지 않은 부분은 이슈에 댓글로 메인테이너들과 논의를 하고 좀 명확해 지면 작업하는 게 더 좋다고는 생각하지만, mocha처럼 작은 프로젝트는 모든 댓글에 대응하기 어렵기도 하고 2일 내에 집중해서 작업해야 하므로 어느 정도 내 판단으로 해보면 좋겠다고 의견 드리기도 했는데 다른 메인테이너들과는 의견이 다를 수도 있어서 좀 걱정이 되긴 했다.

억지로 고생시켜드리려는 건 아니었고 오픈소스 기여라는 것이 작업한다고 항상 의미 있게 되지는 않고 그 작업을 의미있게 만드는 과정이라고 생각해서 최대한 어떤 식으로 진행되는지 설명해 드렸는데 어떤 느낌이셨을지는 잘 모르겠다. 사실 첫 기여는 결과까지 좋으면 제일 좋기는 한데...

스프린트 결과

같이 작업하신 분들을 생각해 보면...

• 테스트 커버리지 관련 이슈를 알려드렸는데 오랫동안 해결이 안 되어서 간단한 이슈라고 생각하진 않았지만, 생각보다 훨씬 복잡한 이슈였던 것 같다. 이를 처리하는 이슈가 이미 올라왔다가 마지막까지 작업이 안 되고 닫힌 상황이라(메인테이너가 리젝한게 아니라...) 참고해서 하면 되지 않았을까 생각했지만, 옆에서 좀 보니 생각보다 복잡한 게 많은 문제였던 것 같다. 옆에서 너무 고생하시는데 진행이 잘 안되시는 것 같아서 걱정되었다.
• 플래그의 기본값을 바꾸는 이슈는 처음 알려드릴 때는 꽤 간단히 생각했는데 이틀 동안 계속 얘기하다 보니 생각보다 복잡한 문제였다. 물론 문제만 해결하려면 어떻게든 되긴 하겠지만 깔끔한 형태로 들어가야 했기 때문에 여러 가지를 많이 논의했다. CI라는 개념에 익숙하지 않아서 그 부분에 설명을 많이 드렸었는데 내가 직접 수정해보면서 해결방법을 논의한 게 아니라서 중간에 잘못 생각한 것도 있고 그랬다. 이분하고 이틀 동안 제일 많이 얘기한 것 같은데 어떻게 수정하면 좋을지? 어떤 부분이 문제인지? 왜 이렇게 동작하는지? 등 많이 얘기했고 최종 구현은 2~3줄로 나왔다.(2~3줄 고치기에도 많은 시간이 걸리는게 대부분이다) 테스트까지 수정해서 올렸는데 미처 생각지 못한 영향받는 테스트가 있는데 시간이 끝나서 좀 걱정이다.
• 한 분은 diff 성능 개선 쪽이었는데 난이도는 꽤 있어 보였지만 댓글에서 대안 라이브러리에 대한 얘기와 임시 수정 코드도 올라와 있었기에 구현 방향을 잡기가 좋아 보였다. 열심히 작업하셔서 diff 자체는 성능 개선이 되었지만, diff 결과를 리포트 하는 방식이 기존과 다른데 기존 방식이 훨씬 좋아 보여서 판단하기가 어려웠다. 나도 실제로 해볼 시간은 없어서 WIP로 PR을 올리고 구현한 부분과 막힌 부분을 설명하고 의견을 구하는 쪽으로 안내해 드렸다. 이슈에서 논의해도 되긴 하지만 코드를 올려서 논의를 시작하면 메인테이너들도 얘기하기 더 좋기 때문에 실제로도 괜찮은 방법이라고 생각한다.(물론 이런 경우 논의가 항상 활발히 되는 것은 아니다.)
• 한 분은 리팩토링 이슈를 직접 찾아오셔서 해볼 만한지를 얘기하셨다. 이런 부분은 나도 약한 부분이라서 정확히 판단은 안 되었지만 최근 올라온 PR에 충돌 날 부분이 보이는 게 있어서 그 부분을 설명해 드렸고 그분이 변경하고자 하는 부분이 나쁘지 않아 보여서 해보면 좋겠다고 말씀드렸다. 중간중간도 몇 번 말씀드렸는데 그 부분 코드는 내가 깊게 봤던 코드는 아니라서 자세히 말씀드리지는 못했다. 다른 PR과의 충돌이 좀 걱정되긴 했지만 오픈소스에서 아직 머지되지 않은 PR과의 관계를 고려해서 작업하기는 쉽지 않은 일이고 둘 다 머지되어도(늦은 쪽은 충돌을 처리해야겠지만) 충분히 의미 있어 보였다. 하지만 나중에 댓글 보니 다른 메인테이너는 다르게 생각하고 있었고 충돌나는 PR도 아직 깊게 리뷰를 못 한 상태라 그분께 죄송했는데 오늘 보니 다른 PR을 또 올리셨다!
• 다른 분은 오래도니 이슈를 먼저 찾아오셨는데 오래된 이슈라 처음보는 거였지만 여전히 유효한 이슈였고 난이도도 그리 높지 않아보였다. 어디를 수정해야 하는지 모르겠다고 하셔서 한참을 찾아서 위치와 테스트를 알려드리고 나중에 수정된 코드에 몇가지 리뷰를 해드렸다.
• 둘째날 늦게 오신 분은 시간이 많지 않아서 간단한 홈페이지 쪽 이슈를 드렸는데 해보시던 작업이 아니라 문서를 보면서 해야해서 고생하시는 것 같았다. CSP 관련인데 세세하게 어느 부분을 넣어야 하는지는 테스트하면서 해봐야 알 수 있어서 직접 CSP로 컨텐츠가 대부분 나오게 작업까지는 하셨는데 가실 시간이 되어서 마무리를 잘 하실 수 있었으면 좋겠다.

어쨌든 4개의 PR이 올라왔고 둘째 날은 나도 틈이 좀 나서 웹사이트 관련 간단한 PR을 올렸다.

• https://github.com/mochajs/mocha/pull/3993
• https://github.com/mochajs/mocha/pull/3987
• https://github.com/mochajs/mocha/pull/3989
• https://github.com/mochajs/mocha/pull/3991

이틀 동안 꽤 즐거웠는데 다들 좋은 경험이셨으면 좋겠다. 이렇게 밀착되어 작업하면서 스프린트에 대해서 이해를 하게 되었고 사람들이 어떤 부분에서 막히는지도 알게 되었다.

mocha 쪽의 레이블이 제대로 안 되어 있거나 작업에 대한 설명이 명확하지 않아서 이런 부분에도 신경 써야겠다는 생각도 했고 PR 올릴 때도 내용을 어떻게 정리해서 올리는지도 꽤나 어려워 하셔서 이 부분도 "PR 올리시면 돼요"로 끝낼 얘기가 아니라는 걸 알게 되었다. CLA 같은 것도 처음 하시는 분들에게 장벽이 상당히 많다는 것을 알게 되었다. 다음 달에는 컨트리뷰톤에 mocha로 참가하게 되었는데 이날의 경험은 이때에도 도움이 많이 될 것 같다.

도움 된 것도 그렇지만 오픈소스 기여를 한팀처럼 작업한 것은 빡세면서도 아주 재미있었다. 좋은 행사 준비해주신 PyCon 준비위원회 분들과 참석해서 열심히 같이 코딩해 주신 분들에게 감사드립니다.