지난 글에서 Spring-Boot Project 의 모듈 및 커밋을 분석하는 글을 작성하였다.
이후에 추가적으로 Issue 나 PR 이 어떻게 작성되는지 궁금해서 아래와 같이 조사를 해보았는데
Issue 내용 해석
STATELESS Session 에서 Authenticated User 에 대한 Response Body 가 빠져있다.
즉, Forbidden User 던 Accepted User 던 Response Body 로 해당 명세가 돌아와야 하지만 response 만 올 뿐 response body 가 빠져있다.
PR 내용 해석
spring-boot-starter-oauth2-client project 에 불필요한 의존성이 존재한다.
oauth2-client 는 mail dependency 가 없지만 d6a869f 에서
oauth2-client 에 mail depencdency 가 추가되었다.
답변으로 해당 시점에서는 oauth2-oidc-sdk 에서 해당 의존성을 사용해서 추가를 한 것이고, oidc sdk 8.23 을 업그레이드한 현재는 해당 의존성을 사용하지 않아 삭제가 되는 것이 맞다라고 하였다.
실제로 추가적인 답변을 확인한 결과 spring-projects/spring-boot@1e601df
에서 의존성 구문 삭제를 진행하였다.
또한 내부적으로 불필요한 의존성을 탐지하는 gradle task 를 추가한다고 하였음.
PR을 결심하게 된 계기
위와 같이 자료조사를 마치고, 여느 때와 마찬가지로 Spring 학습을 하던 도중에 Reference 의 Custom JSON Serializer 를 만드는 코드를 참고하다가 다소 이상한 점을 발견했다.
보통 RestController 에서 Response Body 를 반환할 때 Json Serialization 이 수행되는데 예제 코드를 살펴보니 JsonGenerator 의 writeStartObject 메소드가 빠져있는 것을 확인했다.
내가 기존에 알고있던 바로는 JsonGenerator 는 새로운 Context 를 시작할 때 최초 한번 위 메소드를 선언해야하는 것으로 알고있고, Serializer 맥락 상 Json 데이터를 최초 생성 후에 반환 해 주는 것이 자연스럽기 때문에 이미 존재하는 Generator 를 주입시킨다는 생각 또한 하기가 어려웠다.
내가 틀렸다면 조금의 창피함을 감수할 것을 각오하고 PR 을 날렸다.
틀렸다면 답변을 통해 배우고
내가 맞았다면... 오히려 좋아
PR 발행
사실 이렇게 간단한 코드를 PR 해도 되는지 긴가민가 했다.
내가 발견한 문제가 정확한 오류인지 확인하는 과정은 길었지만, 코드로만 봤을 때는 단 두 줄 밖에 안되었기 때문이다.
실제로 이 코드 수정이 정확한 것인지도 모른채로 코드 두 줄을 수정하고 커밋하는 입장으로써 프로젝트 개발자 분들에게 최대한 누가 되지 않도록 확신이 설 때 까지 고민을 했던 것 같다.
그리고 답변
!!!
사실 이 답변을 보기 전까지(답변까지 몇 분 안걸렸지만) 그냥 시간 지나고 보면 아무 답변 없이 closed 돼있겠거니 생각하고 있었는데, 댓글이 달린 것을 확인하고 심장이 두근거렸다...
정말 운이 좋게도 내가 찾은 오류는 실제로 예외를 발생시키는 코드가 맞았고, 오류 확인부터 코드 수정까지 신속하게 이루어졌다... 갓스프링
마무리
spring-projects 의 컨트리뷰터가 되었다...!!
첫 오픈소스 컨트리뷰션을 그것도 대규모 프로젝트에 반영되는 짜릿한 경험을 했다.
그 과정에서 나는 단 두 줄의 코드로 이렇게 많은 고민과 검증의 시간을 거칠 수도 있다는 것을 알았고, 어느 누구의 코드도 그 줄의 수로 판단할 수 없다고 느꼈다.
며칠 지난 후에 Spring Boot Reference 에도 내가 수정한 코드가 반영이 되었다.
이 두 줄의 코드로 나는 JsonGenerator 객체를 처음 접한 사용자가 나처럼 예외를 만나지 않고 첫 코드를 작성해 나갈 수 있을거라 생각하고, writeStartObject 메소드가 무엇인지 궁금해하지 않을까? 하는 기대도 해본다.
