어쩌다 나는 Open Source Committer 가 되었나? (3) — Apache Storm, and more

어쩌다 나는 Open Source Committer 가 되었나? (1) — introduction
어쩌다 나는 Open Source Committer 가 되었나? (2) — Jedis

Jedis 커미터가 되고, 회사 업무와 Jedis 프로젝트를 병행하는 게 습관이 되어갈 즈음 유닛장님으로부터 (유닛은 팀 바로 상위 그룹) 개인 역량 계발 면담을 실시할테니 개인 목표를 정해오라는 이야기를 들었다. 오픈 소스 공헌에 한창 흥미를 느끼고 있었고, 팀에서는 사용하는 오픈 소스에 깊게 파고드는 분위기가 없어서 개인적으로 아쉬움을 많이 갖고 있던 차여서, 수집기 플랫폼으로 사용 중이었던 Storm 을 제대로 공부해보는 것으로 결정했다.

목표라는 건 평가할 수 있는 기준이 있어야 하니, 다음으로 기준을 생각해 보았다. Jedis 커미터가 되어도 Apache TLP 에 대한 동경은 남아 있었다. 오케이. 맞아 떨어진다. Storm 은 아예 커미터를 목표로 달려보자고 결심.

그렇게 지극히 세속적인(!) 목표에 대한 도전이 시작되었다.

Jedis 프로젝트 경험 때문인지 어떻게 공헌해야 하는가에 대해서는 긴 시간 학습이 필요하진 않았다. 그 대신, 합의 (consensus) 기반 프로젝트가 동작하는 방식에 적응해야 했다. vote 가 무엇인지, binding 과 non-binding 이 무엇인지, bylaw 로 정해진 게 어떻게 실제로 동작하는지 익숙해져야 했다.

아는 사람은 알겠지만, Storm 프로젝트의 주요 core 는 Clojure 로 구현되어 있다. Storm 프로젝트에 기여를 마음먹었을 때 Clojure 라는 장벽은 엄청나게 컸지만, core 중 중요 부분이 Clojure 로 되어 있을 뿐 나머지 코드들은 Java 로 되어 있어서 Java 코드 부분으로 해결 가능한 수준부터 시작하고, Clojure 는 읽는 게 어느정도만 가능하게 준비했다. 뭐 간단한 로직 수정은 구글링으로 어떻게든 하면 된다는 마음가짐으로…

이번에는 버그 수정부터 시작하진 않았다. (나중에는 업무 관련 버그도 몇 개 수정하긴 헀다.) newbie 라벨이 붙은 이슈들 중 간단해보이는 것들부터 해결하기 시작했다. 익숙해진 이후에는 제보된 버그나 기능 개선 요청들을 해결해 나갔다. 유저 그룹과 개발 그룹의 메일링도 구독하고 이해가 안 가더라도 오는 메일은 대부분 한 번씩 훑어보았다. Storm 은 이슈의 activity 와 pull request 의 activity 를 모두 개발 그룹 메일로 쏘고 있다. 한 마디로, 이것만 파악하면 끝이라는 얘기. 엄청난 시간의 희생을 필요로 했지만 익숙해지기 위해 이해가 되지 않더라도 들여다보았다.

이번에도 운이 좋아 (?) 내가 한창 관심 갖기 시작한 시점에 버그와 기능 개선거리 들이 많이 남아 있었다. 그래도 Storm 은 Yahoo! 와 Hortonworks 의 개발자들이 업무 겸으로 커미터 활동을 하고 있어서 내가 올리는 pull request 들을 늦지 않게 잘 리뷰해 주었다. Jedis 프로젝트와 가장 큰 차이점이었다. 활동적인 커미터들이 상대적으로 많고 실력도 좋아 보였다. 잊을만 하면 자격지심이 생겨났지만 뭐 내 능력 되는 선에서 하는거지 뭐…

타 프로젝트 경험은 프로젝트 공헌하는 데 도움을 많이 준다. Jedis 활동이 Storm 활동에 도움을 준 대목이 몇 가지 있었는데 그 중 하나가 Travis CI 적용이었다. Jedis 는 다른 컨트리뷰터의 도움으로 Travis CI 빌드를 걸어 두고 잘 활용하고 있었는데, 마침 Apache Storm 에 CI 가 적용되지 않았다. 커미터들이 고민하고 시도한 히스토리는 있었지만 답보 상태인 듯 보였다. 이거다. 몇 가지 난관을 돌파하면서 적용했고, 좋은 성과로 평가받았다.

두 번째는 storm-redis connector 구현이었다. 다른 컨트리뷰터가 초기 버전을 pull request 로 올렸는데, 구현이 누락된 부분들도 보였고, Jedis 사용 (운 좋게도 Jedis 를 드라이버로 쓰고 있었다) 에 미숙한 듯 보였다. 덕분에 숟가락을 얹는 것을 넘어 마지막에는 많은 양의 코드를 내가 구현하게 되었다.

Jedis 와는 다르게 세속적인 목표로 시작해서인지 중간중간 난관들이 많았고 그만둘까 생각도 많이 했다. 내일부터 하지 말아야지… 라고 마음 먹으면 내가 공헌할 만한 일이 나타나고, 그 일을 통해 의지를 계속 이어갔다.

공헌을 시작한 지 6개월을 넘어 1년에 가까워질 무렵, 한 달만 집중해서 티내서 일해보고 알아주지 않으면 진짜로 그만두자는 결심을 했다. 운이 좋다고 해야 될까? 마침 첫째 (고양이) 가 매일같이 새벽 4시~5시 사이에 깨우는 만행(?) 을 거의 한 달 내내 저질러 주어서 시간을 최대한 투자할 수 있었다.

할 만큼 했다는 생각이 들 시점에, PMC Chair 인 Taylor Goetz 로부터 커미터 / PMC 초대 메일을 받았다. 꾸준한 것이 먹힌 것인지 마지막에 몰아서 공헌한 것이 먹힌 것인지는 모르겠지만 세속적인(?) 목표 달성에 성공한 것이다. 개인 목표 달성에 6개월 정도 늦었지만, 목표 성취가 주는 보람과 직간접적인 혜택이 많이 커졌다. (직접적인 혜택에 대해선 아직은 얘기하기 어렵고 조만간 언급할 수 있지 않을까 생각한다.) Apache TLP 도 크던 작던 개발 프로젝트이고, 누구라도 공헌할 수 있는 부분들은 존재한다는 것을 확인했다.

Jedis 와 Apache Storm 프로젝트 공헌을 통해 얻은 자신감을 바탕으로 다른 오픈 소스 프로젝트도 필요한 경우 최대한 공헌하려고 노력하고 있다. 최근 사례는 업무 상 challenge 과제를 진행하기 위해 AsyncHBase 라이브러리에 reverse scan 기능을 추가해서 (다른 사람이 많은 부분 개발해 둔 것을 다시 정리) pull request 를 요청해 두기도 하고, Spark + Zeppelin 연계를 테스트하다 Spark REPL Executor Classloader 의 버그를 발견해 (어떻게 생각하면 난 참 운이 좋다… 일하면서 한 번씩 버그를 만나고 그 버그를 수정하는 것으로 공헌을 시작한다.) 수정하고 pull request 를 올려서 accept (1.6 릴리즈로 배포될 예정) 되는 기쁨을 얻기도 했다.

마지막으로 오픈 소스 프로젝트에 공헌하고 싶어 이 글을 보고 있다면, 작은 것부터 시작하고, 커미터들의 간지러운 곳을 긁어주는 게 중요하며 (특히 문서화!), 꾸준해야 인정받는다는 것을 포인트로 짚고 싶다. 개발 능력이 좋으면 이런 조언이 필요 없을 수도 있다. 하지만 나처럼 극히 일반적인 개발자에게는 유용한 조언이 되길 바라며 긴 글을 마친다.