배경
사실 이전에 간단한 개발 문서 번역 등 오픈 소스에 기여를 한 적은 있었다.
문서 번역은 크게 어려운 작업이 아니기 때문에 간단하게 작업했었는데, 그 결과물이 웹사이트에 게시된 경험이 있다.
처음 PR을 보내고 머지되기 전까지, 나의 작은 기여가 다른 사람에게 도움이 된다는 것에 즐거움을 느껴 긍정적인 마음을 가지고 있었다. 하지만 사실 단순한 문서 번역이 아닌, 코드 자체에 기여를 하는 것은 그 오픈 소스 자체에 상당한 이해를 필요로 했기 때문에, 쉽게 도전하기에는 어려움이 있었다.
그러던 와중, 개인적으로 게시판을 만들다가 기존의 클래스 검색에 DB 데이터를 꺼내오도록 하는 것보다 검색 성능 향상을 위해 Elastic Search를 이용하면 훨씬 간단하게 사용할 수 있을 것이라 기대하게 되었다 (당연히 한국어도 사용 가능하고 오픈 소스이다!). 엘라스틱 서치를 둘러보던 와중, 한글에 대한 검색은 대체 어떤 식으로 구현된 것인지 궁금하여 순수한 호기심으로 코드를 살펴보게 됐다.
과정
먼저 엘라스틱 서치는 공식적으로 Nori Analyzer라는 한글 형태소 분석기를 사용한다. 자세한 내용은 Elastic 공식 가이드북을 참고하자. Nori-Analyzer을 이해하고자 docs 디렉토리의 관련 문서를 읽던 중, 사소하지만 한 가지 거슬리는 것을 발견했다.
"c++", "C샤프", "세종" 은 일반 명사를 나타낸 것이고 (1)
"세종시" "세종 시" 는 "세종" + "시" 의 합성을 통해 "세종시"가 구성된다는 것을 나타낸다. (2)
물론 이는 예시일 뿐이라 c++ 와 C샤프가 꼭 동일해야할 필요는 없다.
하지만 "세종"이라는 명사를 예시로 먼저 들고, 그 뒤에 "세종"과 "시"의 합성어인 "세종시"를 설명한 것 처럼, 더 나은 이해를 위해서는 첫번 째 예시인 "c++"와 "C샤프"가 동일한 의미이되, 언어만 다른 것으로 맞추는 게 맞다고 생각했다. 우리야 한국인이니까 c++와 C샤프가 다르다는 것 쯤은 이해할 수 있지만 외국인이 보기에는 이 둘이 같은 의미라고 오해할 수 있는 여지가 있다고 생각했다. (아래 세종시 예시가 유사하다보니 c++이 한글로 C샤프라고 번역된다는 오해의 소지를 제거하고 싶었고, 세종시 예제처럼 같은 뜻인 언어를 사용해 두 개의 명사가 뜻은 같되 언어가 다른 형식으로 수정하고 싶었다.)
검색해보니 해당 내용은 Nori-Analyzer의 "userdict_ko.txt" 즉, 사용자의 사전과 같은 역할을 하는 파일, 설명 파일 및 테스트 코드를 포함해 총 4개의 파일에 존재했고 수정도 굉장히 간단해보였다.
문제가 아니었으니 issue는 당연히 열지 않았고 간단하게 두 명사의 뜻을 통일하는 PR을 보냈다.
🖐️ 여기서 잠깐!!
PR을 보낼 때는 보통 오픈 소스 리포지토리에 관련 숙지 사항들이 나와있을 가능성이 크다.
오픈 소스에 기여할 때는 꼭! 커밋 컨벤션이나 코딩 컨벤션을 지키도록 하자!
예를 들어 엘라스틱 서치의 같은 경우에는 contributing을 위한 마크다운 파일이 따로 존재했다!
컨트리뷰팅을 위한 동의서라던지, Java의 환경은 어떠한지, 테스트는 어떻게 하는지, 실행은 어떻게 하는지 등 보통 PR 전 지켜야하는 사항 등이 있었고 이러한 내용을 숙지하고 PR을 보내야 추후 리뷰어가 불필요한 요청을 하지 않을 수 있다!
위기
앗! 그런데 간단한 수정이라 생각과는 다르게 테스트 실패가 났다!... ㅠㅠ
캡쳐해두지는 않았지만, C샤프 와 C#으로 통일했을 때, 사전에 작성된 테스트에서 # 을 인식 못하더라... #을 제외한 다른 예시를 넣어가며 테스트를 돌려보았지만 마찬가지였다.
그래서 오류를 생성하는 C#보다, 기존의 C++을 유지하고 C샤프를 C쁠쁠로 수정했다.
그리고 이 수정은 기존의 part-1 테스트들을 모두 통과시켰다 🙌 🙌 하지만 이상하게 bwc 테스트에서 오류는 계속 발생하더라.
젠킨스를 확인해보니 7.17.8 버전에서 계속 build failed가 발생했고,
아래 사진과 같이 아마 브런치가 최신이 아니기 때문일 수 있다는 문구도 찾을 수 있었다. (젠킨스의 중요성을 느끼게 해주는 순간...)
혹시나 싶어 해당 버전에 테스트가 필요한 다른 이들의 PR들을 확인해보니 나와 같은 문제로 bwc 테스트가 실패된 경우들을 몇 확인했다.
몇 번의 테스트를 해보고 나의 코드로 인한 문제가 아닐 거라고 확신, (또 다른 버전에서는 오류가 없었으니까) 다시 코멘트를 남겼다.
결과
해당 브랜치를 업데이트 후에는 모든 테스트를 통과했고 나의 PR은 머지되었다!
정말 간단하게 시작한 PR이었는데도 불구하고 머지되기까지 시간이 걸렸었다. 하지만 꾸준히 리뷰 및 업데이트 하시는 분들을 보며 정말 대단하다고 느꼈다. 또한 이번에 오픈 소스에 기여하게 되면서 많은 것을 느끼게 되었고, 그 경험을 나누고 싶었다. 먼저, 오픈 소스 기여는 내가 정말 그 오픈 소스에 대해 충분한 이해가 있을 때 깊은 기여를 할 수 있다는 것이다. 무턱대고 '오픈 소스에 기여를 하겠어!' 라는 생각으로 큰 프로젝트를 선택했다가 생각보다 큰 스케일에 당황할 수 있어, 제대로 된 기여를 위해서는 본인이 잘 이해하고 있는 오픈 소스에 기여하는 게 더 가치있는 일이라 생각된다.
나와 같은 경우에는 엘라스틱 서치를 사용하다가 관련 문서를 찾던 중 우연치않게 개선점을 발견하고 PR을 보낸 것이었기에 엘라스틱 서치 자체에 대한 이해는 부족했었다. 간단한 테스트 예시들을 수정한 것임에도 거치는 과정을 몸소 느껴보면서 제대로 된 컨트리뷰션을 통해 얻는 가치는 굉장히 클 것이라는 기대감을 가지게 되었다. 실제로 오픈 소스를 사용하면서 개선점을 느끼고, issue를 올려 그것을 직접 해결하거나, 또는 해결하는 과정을 지켜보는 것은 정말 멋질 것이다. 더 나은 코드를 만들고, 무언가의 발전에 이바지할 수 있다는 것은 참 즐거운 것 같다. 언젠가 더 성장한 나는 지금보다 훨씬 활발하게 오픈 소스에 기여를 할 수 있기를 바라며 이번 글은 이만 줄이도록 하겠다! 총총
'𝑫𝑰𝑨𝑹𝒀' 카테고리의 다른 글
2022/11월 중순의 회고록 (3) | 2022.11.15 |
---|---|
[GITHUB] 깃허브 프로필 꾸미기 (0) | 2022.06.14 |
개발 블로그 첫 시작! (0) | 2022.01.23 |