첫 오픈소스 도전 후기

오픈소스 기여모임

그동안 계속 오픈소스에 기여를 하고 싶었다. 사용하던 오픈소스 도구에 문제가 있으면 깃허브 이슈 탭을 찾아보기도 했고, 문제 원인을 분석해서 이슈에 댓글로 남기기도 했다. 내가 사용하는 터미널 애뮬레이터 Alacritty는 한글 입력 문제가 있어서 직접 해결해보려고 분석해서 원인까지 다 찾아냈지만 개발 언어가 Rust여서 진입하기가 어려웠다. (덕분에 러스트 공식문서를 5페이지 정도 깔짝했던 것 같다.)

그러던 중 우연히 참가하게 된 GDG 인천에서 오픈소스를 주제로 한 강연(박종훈님)을 듣게 되었고, 오픈소스 기여모임이 있다는 것을 알게 되었다. 많은 운영진들이 친절하게 도와준다는 말에 도전해볼까 하는 생각이 들었다.

활동 기간이 되어 기여 가이드를 보니 AI 덕분에 기여하기가 정말 쉬워졌다는 것을 체감했다. AI가 이슈를 다 분석해주고 추천해준다. 개발 과정에서도 도움을 얻을 수 있으니 할 수 있다는 자신감이 생겼다.

이슈 선정

앞서 생긴 자신감과는 달리 이슈 선정 과정에서 생각보다 어려움을 겪었다. 김인제님이 제공해주신 프롬프트로 클로드에게 프로젝트만 알려주고 이슈를 선정해달라고 하니까(클로드 연구 기능 사용) 수백개의 이슈를 검토하는 것 같았음에도 질문할 때마다 추천하는 이슈가 달랐다. 그리고 막상 들어가보면 메인테이너가 작성한 ‘작업하지 않기로 했다’는 코멘트가 자주 있었다. 결국 AI로 딸깍만 하는 건 불가능했고, 내가 직접 이슈를 읽어보며 ‘이슈 보는 눈’을 길러야 했다. 가장 큰 문제는

이 작업을 반복하다보니 (난 스프링 프로젝트 위주로 찾아보았는데) 대충 어떤 이슈가 가능하고 불가능한지 알 수 있었다. 가장 좋다는 first-timers-only와 ideal-for-contribution은 아예 존재하지도 않았고, 대부분 status 관련 라벨이 붙으면 기여할 수 없는 이슈였다. 기여할 수 있는 이슈는 작업 분류가 되어 있고(waiting-for-triage가 없는 것) 담당자가 없는 이슈이다. 마일스톤도 반드시 작업한다는 의지가 있다는 뜻이기 때문에 잘 살펴보았다. 특히 마일스톤 페이지에 가서 기한이 빠른 순서대로 찾아보면 메인테이너가 작업하고자 하는 의지가 높은 이슈를 찾을 수 있다. 그 중에서도 메인테이너가 ‘작업할 수 있다’ 혹은 ‘이런 방향으로 할 것이다’는 댓글을 단 것이 가장 좋았다.

나는 전략을 바꿔서 내가 직접 이슈를 모아서 AI에게 분석해달라고 했다. 내가 모은 이슈의 기준은 다음과 같다:

담당자와 PR이 없는 것
라벨: status나 for-team 등의 태그 없이 분류가 끝난 것

여기서 AI의 문제가 또 드러났다. 클로드와 제미나이로 이 작업을 해보았는데, 둘 다 이슈의 본문만 읽을 수 있었고 댓글은 전혀 읽지 못했다. 깃허브 이슈의 댓글은 동적으로 로드되어서 클로드로 웹페이지를 가져올 때는 본문밖에 인식하지 못한다. 그래서 한 번 필터링한 결과로 다시 내가 기준을 세워 이슈를 분석했다:

마일스톤이 있는 것
댓글로 메인테이너와 어느 정도 논의가 끝난 것(논의 결과가 긍정적이어야 함)

이슈를 선정하는 과정도 쉽지 않았다. 꼬박 하루를 쏟은 것 같다. 그 결과 기여하기 괜찮은 5개의 이슈를 찾았다. 기술적으로 내가 할 수 있는지도 중요했기 때문에 쉬워보이는 것 중에 하나를 선택했다.

제가 할게요

내가 하겠다고 댓글을 다는 것부터 힘들었다. 자신있게 자원해놓고 그저 그런 결과물을 내놓으면 어떡하지, 메인테이너가 불만족스러워하면 어떡하지 하는 고민이 앞섰다. 나는 거절과 실패에 참 약한 것 같다. 코드 리뷰를 받을 때도 비슷했다. 항상 극복해야 한다고 생각해왔지만 절대적인 경험치가 부족한지 떨렸다.

그럼에도 용기를 내서 도전했다. 운영진분들과 메인테이너의 코드 리뷰는 실패의 경험이 아니라 내 수준으로는 받기 힘든 훌륭한 피드백이라는 생각이 들었다.

댓글을 달고 얼마 되지 않아 wilkinsona가 작업해도 좋다는 댓글을 달아주었다. 그 즉시 기여 가이드를 정독하며 작업을 시작했다.

Contributin to Spring Boot

https://github.com/spring-projects/spring-boot/blob/main/CONTRIBUTING.adoc

기여할 때 지켜야 하는 규칙은 생각보다 별로 없었다. 워낙 많은 사람들이 기여를 해서 그런지 커밋 컨벤션이나 브랜치명이 다 제각각이었다. 특별히 신경써야 하는 건 두 가지가 있었다.

모든 작업은 스쿼시해서 하나의 커밋으로 제출한다.
반드시 커밋에 Signed-off-by를 추가한다.

PR 후기

https://github.com/spring-projects/spring-boot/pull/48879

결론부터 말하자면 빠꾸먹었다.

이 작업은 Spring Boot의 Configuration Properties를 추가하는 작업이었는데, 이전부터 팀 내부적으로도 합의가 끝나지 않은 상황이었다. 어떤 속성들을 제공할지, 얼마나 다양하게 제공할지, 어떤 속성을 우선으로 할지, 오버라이드할 때는 어떻게 동작하도록 할지 등등 속성에 관련된 논의가 끝나지 않았다. 그런 상황에서 내가 작업을 맡겠다고 한 것이다. 처음에 메인테이너인 Andy Wilkinson은 “이 작업은 속성 관련 논의가 끝나지 않아도 작업 가능한 내용인 것 같다”며 나에게 이슈를 할당해주었지만, 내 작업을 보고는 “너의 작업을 보니 설계에 대한 논의가 먼저 이루어져야겠다는 확신이 든다”며 논의가 끝난 이후에 다시 작업하겠다고 했다.

이렇게 된 이유에는 내가 Andy Wilkinson이 제시한 작업과는 조금 다르게 작업한 것도 있는 것 같다. 원래는 spring.mongodb하위의 5개 속성(read-concern, write-concern, read-preference.name, read-preference.tags, read-preference.max-staleness)을 제시했다. 하지만 나는 write concern을 더 쪼개서 write-concern.w, write-concern.journal, write-concern.w-timeout을 추가했다. 메인테이너는 이렇게 많은 속성은 복잡도를 증가시키기 때문에 프리셋으로 정해진 write-concern만 제공하려던 거라고 설명했다.

그래도 처음으로 기여하며 많은 것을 배웠다.

오픈소스 기여에 대한 두려움이 사라졌다.
내가 작업한 MongoDB의 read/write consistency에 대해 배웠다.
이슈 찾는 법을 익혔다.

이제는 누군가의 도움 없이 혼자 계속해서 기여해나갈 수 있을 것 같다.

그런데 그냥 하라는대로 했으면 아무 생각 없이 머지시켜줬을까..?