Redis contributor 된 이야기

1) 서론 

Redis 공식 깃허브 저장소에 PR 후 merge 된 이야기입니다. 

 

수정 내용은 매우 허접하니, 주의하세요!

 

Redis 저장소: https://github.com/redis/redis

해당 PR: https://github.com/redis/redis/pull/10072

 

처음에 오픈소스란게~

---

2) 왜 주말에 Redis 코드를 봤을까?

저는 개발자가 된 지 약 3개월 1주 정도가 지난 주니어 개발자입니다. 

 

혼자서 개발할 때는 제가 작성하는 코드가 나름대로 "좋은 코드"라고 부를 수 있다고 생각했었습니다. 왜냐하면 작성하는 사람과 좋은 코드를 정의한 사람은 저 한 명이니까요.

 

하지만 회사에서 개발을 하면서 느낀 것이 있습니다. 10명의 코드에는 10가지 스타일이 있고, 각자 생각하는 좋은 코드의 스타일은 다르다는 겁니다. 

 

그러다 보니 의문이 들었습니다. "그렇다면 천재들이 만든 유명한 오픈소스의 코드는 어떻게 되어 있을까?", "그 사람들이 짠 코드를 보면, 뭔가 공통점이 있지 않을까?"라는 막연한 생각으로 보기 시작했습니다.

 

참고하는 대상 선정은 개인적으로 관심 있는 기술인 Redis, Kafka 저장소의 코드를 보기 시작했습니다.

---

3) 앗! 오타다!

무심코 redis.conf 파일을 보던 중 주석에 오타를 발견했습니다.

# This option, when set to yes, allows nodes to serve pubsub shard traffic while the
# the cluster is in a down state, as long as it believes it owns the slots.

 

while the...  the cluster...???

 

영어가 짧은 저는 일단 의심합니다.

 

"혹시 내가 모르는 어떤 문법이 있거나, 뭔가 강조할 때 쓰는 건가?"

 

"영어 원어민이 작성했을 텐데, 오타 일리가 없어..."

 

몇 시간을 의심하고 검색해봤지만, 저런 건 없는 것 같습니다.

 

에라 모르겠다! PR 하자!

---

4) PR

우선 Redis 저장소의 contribute 규칙을 모아둔, CONTRIBUTING 파일을 읽고 다른 PR들을 참고합니다. 

 

Redis에서 말하는 PR의 규칙은 간단합니다.

a. Fork Redis on github ( https://docs.github.com/en/github/getting-started-with-github/fork-a-repo )
b. Create a topic branch (git checkout -b my_branch)
c. Push to your branch (git push origin my_branch)
d. Initiate a pull request on github ( https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/creating-a-pull-request )
e. Done :)

• 일반적으로 PR 올리는 프로세스와 다를 게 없습니다.

 

4. 1) 첫 PR 후 응답 없음

request를 날렸으면, response를 받아야 개발자입니다. 근데 응답이 없습니다.

 

"내 거만 안 해주나?" 하는 추측과 함께 다른 PR을 살펴봅니다.

 

아래를 보면 476개의 PR들이 reiew와 merge를 기다리고 있습니다. 그렇다면 제가 올린 PR은 매우 허접하니, 우선순위가 낮을 거라고 예상합니다.

하지만 인생 첫 오픈소스 PR인 만큼, 실패든 성공이든 결과를 빠르게 보고 싶어 전략을 수정합니다. 

 

전략명은 "닦달"입니다.

 

4. 2) 닦달

누가 리뷰 해주는지도 모르겠고, 어떤 프로세스로 merge가 되는지도 잘 모르겠습니다.

 

이전에 merge 된 PR들을 참고하여 reviewer를 일단 호출해봅니다.

• 최대한 부드럽지만, 요청을 하는듯한 어투로 해봅니다.
• 영어가 짧아, 의도한 대로 부드러운 어투인지는 모르겠습니다.

 

4. 3) 응답

짧은 영어 탓에 인성 나쁜 것을 티 냈지만, 닦달의 효과가 있습니다. 

• 주말이기도 하고, 다른 일 때문에 바빴답니다.
• 같은 직장인으로서, 미안합니다...

---

5) Merge!

 

TADA!

---

6) 의문점

분명히 merge가 됐는데, 저장소의 contributor 목록에 제가 없습니다. 

 

이름 옆에 태그는 나오긴 합니다.

---

7) 느낀 점

이전에 개인이 관리하는 저장소에 commit 해본 경험이 있습니다. 하지만 Redis처럼 대형 오픈소스에 commit이 된 것은 처음입니다. 

 

사실 오타 수정. 그것도 주석의 오타 수정이라서 민망합니다. 하지만 개발자로서 처음으로 오픈소스에 commit을 하게 되니, 왠지 모를 뿌듯함과 개발의 재미가 막 샘솟습니다. 

 

거대한 오픈소스 세상에 겨우 한 발 내디딘 느낌이 듭니다.