실무/회고

오픈소스를 열어보며 (작은 기여와 깨달음)

ziro 2021. 8. 9. 21:38

오픈소스에 기여 한다는 것은 오픈소스 기여 경험이 없는 개발자들에게 상당히 이상적인 일입니다.
저 같은 경우엔 어떤 프로젝트에, 무엇을, 어떻게 해야할지 모든 단계가 부담스러웠습니다.
그렇다보니 기여는 언젠간 해볼 숙제 같은 존재였는데요

그랬던 제가 정말 우연히, 쉽게,
그것도 JPA를 사용하는 개발자들은 한번쯤 들어봤을 법한 오픈소스인 querydsl 에 기여하게 되었습니다.

제가 기여한 경우는 ‘매우 작은 코드 개선’ PR이었습니다.
해당 코드는 querydsl을 공부하다가 우연히 발견하게 되었습니다.

솔직히 코드를 개선했다고 하기엔 상당히 민망하긴 합니다만, 그럼에도 불구하고 그 과정안에서 많은 깨달음과 배움이 있었습니다.

어쩌다 발견했는지, 그래서 어떻게 기여하게 됐는지 그 과정과 배움의 결과를 공유합니다.

 

과정1: Querydsl 도입 시도

querydsl을 팀 전체 프로젝트에 도입하는 것이 제 궁국적 목표였습니다.
작은 프로젝트에 querydsl을 도입해본 후, 엄청난 매력을 느꼈기 때문입니다.
(tmi: 팀의 기존 select는 criteriaquery를 사용하고 있었다.)

최소한 제가 소속된 팀에는 적용하고 싶었기 때문에, 팀 내 가장 큰 프로젝트(이하 A프로젝트)에 도입이 가능한지 먼저 확인이 필요했습니다.

과정2: 설정 과정에서 문제점 발견

A프로젝트 에 querydsl 설정을 마친 후, QClass가 생성되길 기대했습니다. 하지만 QClass는 어디에도 생성되지 않았습니다.(ㅠㅠ)

아무래도 A프로젝트의 Entity 관리 방식 때문인 것으로 추측이 되었습니다.
(entity를 외부 저장소에 모듈화하여 저장하고, 프로젝트에 외부 모듈로 의존성 추가하여 사용)

많은 검색을 해보았지만 속 시원히 알려주는 글이 없었고, 궁지에 몰린 저는 직접 querydsl 코드와 마주하길 결심했습니다.(…)

과정3: querydsl 오픈소스에 접근, QClass 생성 기준을 찾아서

일단 querydsl 코드를 찾아야 했는데, 구글에 querydsl github을 검색하니 쉽게 찾을 수 있었습니다.

그리고 구글링을 통해 몇가지 과정을 시도하던 중에 QuerydslAnnotationProcessor 에서 특정 어노테이션을 읽어서 QClass를 만든다는 것을 알게되었습니다.
(QClass 생성 과정을 공부한 상세한 과정은 추후 작성 예정입니다.)

그래서 QuerydslAnnotationProcessor 코드를 확인해보았습니다.

특정 어노테이션들에 해당하는 class를 읽어서 생성한다는 것을 알 수 있었습니다.

코드를 확인함으로써 코드를 까본 목적은 달성되었습니다.

하지만 이왕 코드를 뜯어보기 시작한거 메소드에서 리턴되는 DefaultConfiguration의 내용까지 알고자 DefaultConfiguration 클래스 코드를 확인하게 되었는데요

그러던중 IDE(intelliJ)가 친절히 warnig을 뿜어내는 코드를 발견하게 되었습니다.

심지어 이 warning은 IDE가 수정 내용까지 추천해주었습니다!
추천 내용은 다음과 같습니다.

undant boxing inside 'Boolean.valueOf(xxx)'

어설프게 번역해보자면 대충 boxing 이 불필요하게 발생하는 것 같습니다.

여기서부터 해당 warning과 관련된 사항들을 공부했습니다.

  • Boolean.valueOf()
  • Boolean.parseBoolean()
  • boxing/unboxing

해당 과정을 통해 원인은, boxing 했다가 다시 unboxing 되는 코드 (boolean -> Boolean -> boolean) 라는 것을 알게되었습니다.

‘PR이라는거 나도 한번 해보자’

이해를 완전히 하게 된 순간, PR해야겠다는 생각이 들었습니다.

하지만.. 커밋과 PR에 앞서, 제가 한 역할이 너무나도 작게 느껴졌습니다.
제가 한 일이라곤 warning을 발견한 것 뿐이니까요.

하지만 굳이 머뭇거릴 이유는 없었습니다. 그 이유는,

  1. 수정하지 않아야 할 이유가 없다.
  2. 누군가는 언젠간 수정할 코드다.
  3. 기여로 인해 묘한 소속감이 생길 것 같았다.
  4. 앞으로의 '오픈소스 기여'에 한 발자국이 될 것이다.

그렇게 두근거리는 마음으로 PR을 했습니다. 👏👏👏

오픈소스에 PR을 날려본 경험이 없었기 때문에 구글링을 통해 방법을 알게 되었습니다.
해당 과정은 오픈소스 입문을 위한 아주 구체적인 가이드를 참고하였습니다 : )

여차저차 커밋 메세지를 영어로 작성하고, 다음과 같은 내용으로 PR을 날렸습니다.

Change 'Boolean.valueOf()' to 'Boolean.parseBoolean()'

- These variables are not used as 'Boolean' Object.
- Java provides Autoboxing and Unboxing, but this is an unnecessary process.

PR하고약 2주간 제가 날린 PR엔 먼지가 쌓여갔는데요….
(그 기간동안 괜히 작아지는 기분이었습니다..)

다행히 존버(?) 후 제 PR이 Merged 되었다는 것을 알게되었습니다!

드디어 첫 기여가 된 순간입니다…
저 merge 마크가 괜히 뿌듯하네요 😭

겨우 이정도 수준의 기여?

커밋 내용을 보시다시피 기여 내용은 아무것도 아니라고 볼 수도 있습니다.
IDE가 고치라고 알려준 코드를 PR만 날렸을 뿐이니까요.

그래도, 개인 github에 붙은 querydsl 기여 딱지는 여러가지로 저에게 긍정적인 영향을 주었습니다.

  1. 오픈소스는 누구나 개선할 수 있다.
    • 간단한 개선이라도 오픈소스의 퀄리티를 더 높일 수 있다면 누구나 기여할 수 있습니다. 심지어 저처럼 IDE가 고쳐준 코드일지라도요 … : ) 해당 코드는 아무도 열어보거나 발견하지 않았다면 그대로 방치되었을테니까요.
  2. PR하기까지 배움은 반드시 존재한다.
    • PR은 PR 내용에 어느정도 확신이 있어야 가능하다고 생각합니다. 확신이 들기 까지 코드 및 로직을 이해해야 합니다. 그 과정에서 개인적인 공부가 정말 많이 되었습니다. 다른 사람이 작성한 코드를 읽고 이해하는 과정에서 크고 작은 배움는 반드시 있다고 생각합니다.
  3. 오픈소스 생태계를 대하는 마음가짐이 달라졌다.
    • 오픈소스 생태계에 한 발짝 다가가게 된 것 같습니다. '누군가가 만든것을 사용' 하는 것이 아닌 '우리 모두가 만들어갈 수 있는 것' 이라는 생각이 생겼습니다.

 

채용 공고에서 말하는 '오픈소스 기여 경험'이 말하는 의미는 무엇일까?

요즘 많은 채용 공고에서 '오픈소스 기여 경험'에 대한 항목을 많이 볼 수 있습니다. 그 의미가 무엇일지 해당 과정을 통해 생각해보았는데요. 기여를 하기 위해서는 코드(및 프로젝트)에 대한 집요한 관심이 있을 수 밖에 없기 때문입니다. 집중해서 이해하고 관심을 보이지 않으면 아무리 간단한 기여도 할수 없습니다. 행여라도 '오타 피드백', '코드에 대한 질문' 등 사소한 것 일 지라도 유심히 이해하지 않으면 할 수 없는 일이기 때문입니다. 그만큼 남이 작성한 코드를 얼마나 관심을 가지고 읽어나갈 수 있는지를 보고자 하는것이 아닐까 합니다 :)

마치며

누군가에겐 별 것 아닌 일일 수 있지만, 제겐 소중한  경험이었습니다. 오픈소스를 사용할 때는 더 많은 관심과 책임감을 가지고 개발할 수 있게 된 것 같습니다.

오픈소스에 기여해보고 싶은 개발자라면, 기여에 목적을 두기보단 사용하고 있는 오픈소스에 디테일하게 관심을 가지면 자연스럽게 기여하게 될 것이라고 말해주고 싶습니다.

앞으로 진지하게 오픈소스를 대하며 더 큰 의미있는 기여를 하고자 합니다.

긴 글 읽어주셔서 감사합니다!