2년 전 나는 국비 지원교육을 받고 있었다. 쉬는 시간이면 블로터를 보거나 궁금한 키워드들을 검색해보곤 했다. 어느 날 나는 스프링 Dispatcher-Servlet의 개념은 알겠는데, 어떻게 구현되어 있는지 궁금했다. 그래서 깃허브에서 spring-framework 프로젝트를 찾았고 분석하기 시작했다.
이때 만약 코드 베이스 전체를 이해하는 천재 개발자면 좋았겠지만, 난 지극히 평범한 사람이었기 때문에 하나도 이해하지 못했다. 하지만 대충 어떤 식으로 작동하고, 어떻게 코드가 작성되어 있는지 볼 수 있었다. 무엇보다 선지자들의 코드를 볼 수 있다는 건 공부하는 사람 입장에서는 매우 매력적인 경험이었다. 이때부터 나는 오픈소스를 좋아하게 됐다.
그리고 시간이 흘러 얼마 전 꾸준히 참여하고 있던 yorkie-team의 메인테이너가 됐다. 언젠가는 메인테이너를 해보고 싶다는 생각은 했었지만, 아직 부족한 내게 기회가 올 거라고는 생각도 못 했다. 현재는 메인테이너 업무를 진행하면서 콜라보레이터 때와 또 다른 배움을 얻고 있다.

글을 쓰는 이유

이 글은 깃을 다루는 방법, PR을 보내는 방법, 이슈 등록하기 등을 가이드하는 글이 아니다. yorkie-team의 컨트리뷰터에서 메인테이너가 되면서 그간 느꼈던 것들을 정리한 글이다. 팁(?)이라고 생각하면 좋을 것 같다. 오픈소스 활동을 동경하던 1년전 나와 같은 개발자가 이 글을 보고 조금이나마 도움이 됐으면 하는 마음으로 글을 작성한다.

왜 오픈소스인가?

성장

성장이 처음에 나오는 것은 너무 당연한 것 같다. 이 부분은 나와 같은 주니어 개발자들에게 특히 말해주고 싶다. 진행 중인 사이드 프로젝트가 없다면? 당장 오픈소스를 시작해라.

회사 업무별 차이는 있겠지만, 하는 일이 반복되면 그 업무에 익숙해지는 게 당연하다. 가끔 딴생각하면서도 업무를 척척해나가고 있는 모습을 보면 익숙함의 힘은 대단하다. 하지만 개발자는 이것을 조심해야 한다. 익숙한 기술, 아키텍처, 코드, 협업방식, 업무 프로세스 등 익숙함을 지속하면 획일적인 사고방식에 갇혀버릴 수 있다.

만약 당신이 회사 협업환경에 너무 익숙해져 있다면? 오픈소스라는 새로운 환경에서 입사자의 마음으로 다양한 프로젝트에 참여해봤으면 좋겠다.

커리어

실제 깃허브 활동을 긍정적으로 보고 채용 관련 연락을 주셨던 분들이 있었다. 이런 경험을 보면 깃허브는 개발자를 표현하는 좋은 플랫폼이라고 생각한다. 내가 작성한 코드, PR, issue, 커밋 메시지 등 많은 걸 노출할 수 있다. 그래서 어떤 채용담당자에게는 개발자를 검증할 수 있는 좋은 공간으로 활용된다.

영어

깃허브는 전 세계의 개발자들이 모여있는 플랫폼이다. 다양한 국가의 사람들이 활용하는 협업 환경이라 대부분의 프로젝트에서 영어가 표준언어로 사용되고 있다. 나도 영작을 많이 하게 되면서 영어 실력 향상에 많은 도움이 되고 있다. (물론 Grammarly, 구글 번역기는 내가 가장 좋아하는 툴이 되었다)

준비자세

침착하고 인내하자

오픈소스 참여를 시작하기 전 나는 호흡을 통한 침착함을 유지하는 방법에 대해 이야기하고 싶다. 뜬금없지만 중요한 이야기다.

호흡을 불편하지 않을 정도로 적당히 들이쉰다.
몸이 축 처진 것처럼 힘을 뺀다.
코에서 바람이 새어 나오듯이 천천히 호흡을 내쉰다.
몸에 모든 공기가 빠져나간 느낌이 될 때까지 호흡에 집중한다

실제 내가 개발하면서 침착함과 집중력을 유지하기 위해 자주 사용하는 호흡법이다. 이 이야기를 하는 이유는 침착함이 매우 중요하기 때문이다. 절대 급하게 하지 말라고 당부하고 싶다.

오픈소스에 참여할 때는 회사처럼 누군가 옆에 앉아 설명해주지 않는다. 개발자는 단지 문서와 히스토리, 그리고 코드를 보며 이 프로젝트를 분석하는 모험을 해야 한다. 이 일은 결코 쉽지 않으며 꽤 피곤한 여정이 될 수 있다. 그렇기 때문에 우리의 마음가짐은 항상 고요한 호수와 같아야 한다.

이유를 준비하자

개발 업무뿐만 아니라 모든 일이 그렇듯 ‘왜?’가 중요하다. 개발자는 작성하는 코드에 관해 설명할 수 있어야 한다. 그리고 개발자는 이 규칙을 지키기 위해 노력해야 한다.

오픈소스 협업에서는 특히 중요하다. 모든 대화, PR, 이슈 트래킹, 제안 등은 설득할 수 있는 이유가 명확해야 된다. 오픈소스 관리자들은 회사처럼 밀착해서 소통할 수 있는 개발자들이 아니다. 또한 당신에 대해 알지 못한다. 따라서 언제든 당신의 행동에 많은 질문을 던질 준비가 되어 있는 사람들이다. 그러니 항상 내 행동을 설명할 수 있는 준비를 해두면 좋다.

뻔뻔해지자

오픈소스에 익숙하지 않은 개발자들이 공통으로 겪을 수 있는 기분은 거절에 대한 두려움이다. 나도 공감한다. 하지만 이건 마음에 드는 이성에게 번호를 물어봐서 거절당하는 것보다는 덜 부끄럽다. 그러니 뻔뻔해졌으면 좋겠다.
일화로 나는 어떤 프로젝트에서 부족한 영어 실력 때문에 벙어리라는 소리를 들으며 이슈가 닫힌 적이 있었다. 그때의 상처는 아물어서 아무렇지 않다. 그러니 자신감 있게 소통했으면 좋겠다.

깃, 깃허브는 공부하자

깃과 깃허브와 친해져야하는 것은 언급하지 않아도 모두 공감할 거라고 생각한다.

본업이 더 중요하다

프로답게 행동해야 한다. 항상 나의 본업에 영향을 줄 만큼 무리하지 않도록 주의해야 한다. 조절이 어렵다면 집에 있는 가족을 생각해보자. 회사는 금전적 보상이 따르지만, 오픈소스는 그렇지 않다.

어떤 프로젝트에 참여할까?

동기부여

프로젝트를 선택할 때 내가 재밌게 할 수 있는걸 선택하는 게 중요하다. 내가 Yorkie를 선택한 이유는 이러했다.

회사에서 협업 도구를 교체하자는 이슈가 있었다.
내가 만들어보면 어떨까?
Real-time application에 관심이 생겼다.
어? Yorkie가 실시간 동기화 스토리지를 지원하네?

이러한 동기가 있어서 프로젝트를 시간 가는 줄 모르고 분석했다. 어떤 행동에 대해 타당한 이유가 있다면 높은 추진력을 낼 수 있도록 도와준다.

사용하고 싶은 기술

관심사가 없다면 평소 관심 있는 기술로 생각을 좁혀보자. 나의 경우 Go 언어를 매우 좋아한다. 그래서 Yorkie에 참여하기 전 mattermost-server 또는 docker에 참여해보려고 문서를 읽고 있었다. 다행히 Yorkie는 Go를 쓰고 있었고 덕분에 코딩하는 게 즐거웠다. 평소에 관심 있는 기술을 사용하는 프로젝트라면 작업에 즐거움을 더해줄 것이다. 적어도 회사 밖에서는 우리가 좋아하는 것을 하자.

문서화 수준

문서화 여부는 꽤 중요하다. 회사는 책임자가 있기 때문에 문서화가 안 되어 있어도 어느 정도 프로젝트 관리가 될 수 있다. 하지만 오픈소스는 아니다. 프로젝트 규모가 커질수록 문서화의 중요도는 배로 늘어난다.

이것은 해당 프로젝트의 진입 장벽을 낮춰주기도 한다. CONTRIBUTING.md, CHANGELOG.md, README.md 등을 먼저 살펴보고 문서화 수준을 파악하자. 문서화 관리가 잘 되고 있다면 일관성 있게 프로젝트가 관리되고 있을 가능성이 높다. 그리고 이것은 초보자들에게 혼란스러움을 줄여줄 것이다.

테스트 코드 관리

프로젝트에서 테스트는 건물의 기둥과도 같다. 특히 오픈소스에서는 많은 개발자의 자발적 참여를 통해 관리되기 때문에 그 중요성이 배가 된다. 그래서 많은 오픈소스 프로젝트들이 테스트 코드를 꼼꼼하게 관리한다.

테스트 관리가 잘 되어 있는 프로젝트라면 진입장벽이 낮을 것이다. 어떤 로직을 분석할 때 테스트 코드는 좋은 시작점이 될 것이다. 그러니 초보자라면 테스트 코드 관리가 잘 되어 있는지 살펴보고 선택하자.

Issues & PR History

이슈와 PR 히스토리를 살펴보자. 아래 기준으로 메인테이너들의 흔적을 살펴보면 좋다.

이슈 라벨관리가 잘되어 있는가?
지속해서 업데이트가 잘 되고 있는가?
코드리뷰가 잘 되고 잇는가?
메인테이너는 친절한가?

사실 이 리스트들에서 말하는 ‘잘 되고 있다’는 것은 기준이 없다. 관리 수준이 높을수록 초보자의 진입 장벽이 낮을 수 있기 때문에 참고 정도만 하면 좋을 것 같다.

goodfirstissue

이것저것 찾기 귀찮다면 https://goodfirstissue.dev/를 살펴보면 좋다. 처음 오픈소스 기여하기 좋은 프로젝트를 추천해주고 있다.

기여하기

문서 읽기

컨트리뷰터를 위한 문서 중 대표적으로 CONTRIBUTING.md, README.md 같은 것들이 있다. 로마에서는 로마법을 따라야 하니까 적어도 두 문서는 읽어보자.

REAMDE.md는 프로젝트에 대한 설명과 사용방법 등을 포함하고 있기 때문에 당연히 읽게 될 것이다. 중요한 건 CONTRIBUTING.md(다른 이름일 수도 있다)를 읽는 것이다. 이 문서에는 프로젝트 관리자가 컨트리뷰터에게 전하는 요구사항들이 있다. 읽고 이 규칙들을 지키려고 노력하자. 꼭!

기여하는 방법들

버그를 수정하고 새로운 피처를 만드는 것 만이 기여가 아니다. 이슈 제보, 버그 수정, 오타 수정, 테스트 추가, 리팩토링, 프로파일링, 제안 등 그 범위는 다양하다. 당신이 할 수 있는 일이 많다는 뜻이다.

이슈 고르기

무작정 프로젝트를 클론 받아서 분석하는 건 더 험난한 길이 될 수 있다. 나는 지름길을 택하라고 말하고 싶다.

처음 시작하는 사람이라면 good first issue 라벨이 붙어있는 이슈를 시작하는 걸 추천한다. good first issue는 말 그대로 처음 시작하기 좋은 이슈다. 진행하면서 프로젝트 흐름을 이해할 수 있는 이슈들이 이 라벨에 해당한다. <Yorkie good first issue>

그리고 이슈를 진행하고 싶다면 Could I try this issue?라고 물어보자. 이미 진행하고 있는 일을 중복하는 수고를 줄일 수 있다. <허락 받았다 :)>

코드 분석

새로운 개발자의 진입장벽을 낮출 수 있다는 것은 테스트 코드의 또 다른 힘이다. 선택한 이슈를 진행하게 되었다면 관련 테스트 코드를 먼저 살펴보면서 좀 더 빠르게 로직의 흐름을 파악할 수 있다.

만약 분석이 필요한 기능의 테스트 케이스가 존재하지 않는다면 테스트 코드를 작성해서 PR을 보내보자. 테스트 코드를 작성하다 보면 자연스럽게 해당 로직을 분석할 것이다. 어쩌면 그 기능에 대해 누구보다 더 잘 알게 될 수도 있다.

분석도 어렵고 테스트 코드 작성도 어렵다면 메인테이너에게 정중히 질문하면 된다. 대부분의 메인테이너들이 매우 친절하게 잘 설명해줄 것이다.

Pull request

꼭 완벽하게 완성된 코드를 PR할 필요는 없다. 대부분의 메인테이너는 당신이 어떤 고충을 겪고 있는지 이해하려고 노력하는 사람들이다. 미완성된 PR이라도 어려움이 있다면 PR을 보낸 뒤 코멘트를 남기자. 그러면 메인테이너가 피드백을 통해 당신이 작업을 지속할 수 있도록 도와줄 것이다.

그리고 작성된 코드가 많다면 한 번에 병합되는 일은 드물다. 오히려 PR이 한참 동안 진행되는 경우가 많다. 심지어 반려될 수도 있다. 이것은 매우 자연스러운 일이니 ‘내가 실력이 부족한가?’와 같은 어리석은 생각은 하지 말도록 하자.

코드리뷰

나는 코드리뷰를 진행할 때 제일 중요한 건 ‘상대방의 작업을 존중하는 것’이라고 생각한다. 그래서 코멘트에 항상 칭찬을 아끼지 않으려고 한다. 특히 따봉은 중요하기 때문에 항상 빼먹지 않으려고 노력한다.

<칭찬을 아끼지 않는 Yorkie>

모두가 이런 마음으로 코드리뷰에 임한다면 코드리뷰 분위기가 대체로 밝을 것이다. 실제 Yorkie에서는 이런 분위기를 지향하고 있어서 그런지 몰라도 코드리뷰 분위기가 좋다. 그러니 당신도 이런 마음으로 리뷰에 임했으면 좋겠다. 그렇게 되면 자연스럽게 ‘이거 바꿔주세요’ 보다는 ‘이걸 이렇게 바꾸는 건 어떨까요?’라고 말하는 친절한 개발자가 될 수 있을 것이다.

마무리

주말에 코로나 때문에 집에만 있어야 하는데 심심하다면 깃허브를 추천하고 싶다. 여기가 바로 최고의 놀이터다.

추가로 만약 마음에 드는 프로젝트를 찾지 못했다면 내가 속한 yorkie-team을 추천하고 싶다. 정말 멋진 개발자들이 모인 곳이다.