기술

오픈 소스에 컨트리뷰트하기 (feat.Spring)

임동휘 2024. 4. 28. 22:13

얼마 전, 살면서 첫 오픈 소스 컨트리뷰트를 했다. 무려 내가 매일 회사에서, 사이드 프로젝트에서 쓰고 있는 Spring 프로젝트에 첫 컨트리뷰트를 했다.

첫 걸음! 색칠하기(깃허브 잔디입니다.)

 

 최근, 담당 프로젝트에서 Http 통신을 위한 클라이언트를 WebClient에서 RestClient로 전환 중이다. 프로젝트가 코틀린 + 스프링 MVC 프로젝트인데, RestTemplate이 Deprecated 될지도 모른다는 이야기(안됩니다)에 WebClient를 사용 중이었다. 현재 담당하고 있는 프로젝트는 내부 코어 시스템과 외부를 연결해주는 인터페이스 역할을 하는 모듈이다. 그렇다 보니, 외부 호출이 굉장히 잦은 프로젝트인데, 이를 할 때마다 항상 runBlocking을 코드에 묻히고 가야하는게 참 불편하다고 느꼈다. 그래서 빠르게 스프링 버전을 올린 김(5년 넘은 프로젝트인데, 현재 부트 3.2.x 버전이다.)에, 새로 나온 RestClient로 전환하고 있었다.

 

 그런데 이를 전환하는 과정에서 다른 분이 올려주신 PR을 리뷰하다 보니, 항상 이런 코드가 있었다. (회사 프로젝트라 내용을 대충 재구성했다.)

// 기존 코드
return runBlocking {
    webClient.get()
        .uri("https://foo.com")
        .retrieve()
        .awaitBody<String>()
}

// 변경된 코드
return restClient.get()
    .uri("https://foo.com")
    .retrieve()
    .body(String::class.java) ?: throw NullPointerException("blah")

 

 내가 해당 PR에 이런 내용의 리뷰를 남겼고,

null 검사를 항상 하는 방법보단, webClient처럼 리턴 타입이 Not Null인 Extension 구현해서 처리하는 건 어떨까요?
inline fun RestClient.ResponseSpec.bodyNotNull(): T = body(object : ParameterizedTypeReference() {}) ?: throw NoSuchElementException()
webClient는 awaitBody / awaitBodyOrNull 둘 중 사용하도록, RestClient도 body / bodyOrNull 이면 좋을 것 같은데 왜 이렇게 구현을 해뒀는지 모르겠네요. 이슈 남겨둬야겠어요.

 

 담당자분이 긍정적으로 답변을 해주셨고,

패치 해줄것 같아서 따로 구현 안했는데, 해 놓는것도 좋겠네요.

 

 다른 팀원분도 같은 방향으로 추가 피드백을 주셨다.

WebClientExtensions.kt 와 RestClientExtensions.kt 을 비교해보니, WebClient.ResponseSpec.bodyToMono에서 반환되는 Mono는 코틀린에서 awaitSingleOrNull, awaitSingle 두 가지로 받을 수 있어서 자연스럽게 awaitBody와 awaitBodyOrNull 두 가지 확장함수가 추가된 것 같습니다. 반면에 RestClient.ResponseSpec.body는 리액터 기반이 아니라서 그냥 자연스럽게 reified type parameter 지원만을 위한 nullable 확장함수로 추가된 것 같네요.
body, bodyOrNull 두 가지로 바꾸기에는 이미 6.1에서 추가된 nullable body 때문에 번거로울 것 같으니 bodyNotNull 명칭으로 RestClientExtensions에 추가하는걸로 XX님께서 이슈에 올리거나 PR로 올려주시면 contributor 될 좋은 기회네요 ㅋㅋ
checkNotNull, mapNotNull 등 ~NotNull도 자주 쓰는 postfix라 문제 없을것 같습니다.


 그래서 RestClient에서 Null 핸들링을 따로 하지 않아도 Body를 받을 수 있는 익스텐션을 추가해, 스프링에 첫 PR을 올렸다.


 중간에 거절당할 뻔 했으나, 열심히 내 논리를 말해가며 설득한 끝에 메서드 네이밍만 피드백을 받고 해당 변경 사항이 머지되었다! 영광스러운 내 첫 오픈소스 커밋이었다.

 

마치며

최근 개발자로의 성장이 멈춘 것 같고, 매일 같은 일을 하는 것 같아서 약간 허우적대는 기분에 빠져있었다. 그런데 이런 작은 기여를 통해서 굉장히 큰 성취감과 뿌듯함을 느낄 수 있었다. 특히, 거절당할 뻔 했지만 나름의 논리로 설득해서 이 부분이 받아들여진게 참 기분이 좋았다. 역시, 번뇌는 참으로 내 안에 있었던 것 같다. 

 

그리고 이런 오픈소스에 컨트리뷰트해보라고 응원해주는 팀, 회사의 분위기에도 참 감사하다. 좋은 코드를 위해서 같이 고민하고 이야기 할 수 있는 사람들과 분위기가 있는 조직에 있다는게 얼마나 큰 축복인지 모르겠다.

 

마지막으로 한 줄의 코드를 위해서 함께 고민하고, 개선 방향을 찾아가는 오픈소스 생태계에 다시 한 번 경외심이 들었고, 이 생태계를 유지하기 위해 열심히 노력하는 모든 세상의 개발자에게 감사함을 느꼈다. (내가 밥 벌어먹을 수 있게 해줘서 고마워!)

 

다들, 일하다가 이게 왜이래? 싶으면 오픈 소스에 한 번 컨트리뷰트 해보는 건 어떨까?

 

읽을 거리

오픈소스에 컨트리뷰트하는 법 - https://mangkyu.tistory.com/215