오픈소스 첫 PR 올리기까지의 여정

3년간 star만 눌렀다

GitHub에서 유명한 오픈소스 프로젝트의 contributor 목록을 보면 위축됐다. 이 사람들은 다 어떤 사람들이길래 이런 코드를 짜는 걸까. 나 같은 평범한 개발자가 끼어들 자리가 있을까.

3년간 오픈소스를 구경만 했다. star는 눌렀지만 issue 하나 안 올렸다.

매일 쓰는 날짜 포맷팅 라이브러리에서 버그를 발견했다. 한국어 로케일에서 '화요일'이 '월요일'로 나오는 문제.

처음에는 우리 코드 문제인 줄 알고 3시간을 디버깅했다. 결국 라이브러리 코드까지 타고 들어가서 원인을 찾았다. 로케일 데이터에 오타가 있었다. 배열 인덱스가 하나 밀려 있었다.

(3시간 동안 내 코드를 의심한 거다.)

GitHub에 issue를 올렸다. 재현 방법, 예상 결과, 실제 결과를 정리했다. 영어로 쓰는 게 부담이었지만, 기술적인 내용이라 문장이 간단해도 충분했다.

30분 만에 메인테이너가 답변을 달았다. "Good catch! Would you like to submit a PR?"

심장이 뛰었다.

레포를 fork하고 클론했다. contributing guide를 꼼꼼히 읽었다. 브랜치 네이밍 규칙, 커밋 메시지 형식, 테스트 실행 방법. 이 가이드를 무시하고 PR을 올리면 바로 reject당한다는 이야기를 들은 적이 있어서 신중했다.

수정 자체는 간단했다. 로케일 데이터 파일에서 배열 원소 하나의 위치를 바꾸는 것. 코드 변경은 1줄이었다. 근데 테스트를 추가하는 데 1시간이 걸렸다. 해당 로케일의 요일 출력을 검증하는 테스트 케이스를 작성했다.

변경 사항을 설명했다. 어떤 버그인지, 왜 발생했는지, 어떻게 수정했는지, 테스트는 어떻게 추가했는지. 스크린샷도 첨부했다. 수정 전과 수정 후의 출력 결과 비교 이미지.

올리고 나서 1시간 동안 알림을 계속 확인했다. 혹시 뭔가 잘못한 건 아닌지.

다음 날 아침에 리뷰가 왔다. 코드 자체는 문제없었지만, 다른 로케일에도 같은 문제가 없는지 확인해달라는 요청이었다. 12개의 아시아 로케일을 전부 검증했고, 다행히 한국어만 문제가 있었다.

이틀 후 "LGTM, merging!" 메시지가 달렸다. 작은 수정이었지만, 내 코드가 수천 명이 쓰는 라이브러리에 들어갔다는 사실에 괜히 뿌듯했다.

거창한 기능 추가가 아니어도 된다는 걸 알았다. 오타 수정, 문서 개선, 타입 정의 추가. 이런 작은 기여도 환영받는다.

지금까지 5개 프로젝트에 8개의 PR을 올렸다. 대부분 작은 수정이다. 근데 하나를 올릴 때마다 다른 사람의 코드를 읽는 능력이 올라가는 걸 느낀다.

"good first issue" 라벨을 찾아보라는 조언은 유효하다. 근데 나처럼 직접 쓰다가 발견한 버그를 고치는 게 더 자연스러운 시작이다. 자기가 겪은 문제니까 동기부여가 확실하다.

오픈소스 기여의 진입 장벽은 기술이 아니라 심리다. "나 같은 사람이 해도 되나?"라는 생각을 버리는 순간 이미 절반은 온 거다.

코드 1줄이어도 좋다. 일단 올려보자.