첫 오픈소스 기여 후기

119 views

오픈소스에 처음 기여한 경험

회사에서 메일함을 가져오는 코드가 간헐적으로 멈추는 문제가 발생했다.
처음에는 로그 상 특별한 에러가 없었기 때문에 단순한 이메일 서버 문제라고 판단하고 재 시작 처리만 했지만, 이후에도 일부 케이스에서 메일이 제대로 읽히지 않는 현상이 계속되었다.

문제 원인 분석

문제를 해결하기 위해 직접 소스 코드를 분석했고, 의심 가는 이메일들을 따로 저장하면서 원인을 추적해 나갔다.
그 과정에서 POP3 프로토콜의 RFC 문서를 읽게 되었고, 문서에 정의된 일부 규칙이 코드에 반영되어 있지 않다는 것을 발견했다.

RFC에 따르면, 특정 명령어의 응답이 여러 줄일 경우 CRLF.CRLF 로 끝나야 한다.
하지만 기존 코드에서는 특정 명령어의 마무리를 .\r\n 를 응답의 마무리로 처리하여, 응답이 다 읽히지도 않았는데 종료되면서 이슈가 발생한 것 이였다.
이 부분을 수정하자, 그동안 문제가 되었던 이메일들도 정상적으로 읽히기 시작했다.

PR 제출

문제가 되는 오픈소스 라이브러리에 수정을 반영하기 위해 PR을 보냈다.
PR에서는 문제 상황과 함께 RFC 문서의 내용을 인용하며, 수정이 필요한 이유를 상세히 설명했다.

I found a problem where emails sometimes weren't parsed.

Some data events ends with .\r\n, But they doesn't finished parse whole email.
I found some rfc documents and multiline commands should finish \r\n.\r\n.

Responses to certain commands are multi-line. In these cases, which
are clearly indicated below, after sending the first line of the
response and a CRLF, any additional lines are sent, each terminated
by a CRLF pair. When all lines of the response have been sent, a
final line is sent, consisting of a termination octet (decimal code
046, ".") and a CRLF pair. If any line of the multi-line response
begins with the termination octet, the line is "byte-stuffed" by
pre-pending the termination octet to that line of the response.
Hence a multi-line response is terminated with the five octets
"CRLF.CRLF". When examining a multi-line response, the client checks
to see if the line begins with the termination octet. If so and if
octets other than CRLF follow, the first octet of the line (the
termination octet) is stripped away. If so and if CRLF immediately
follows the termination character, then the response from the POP
server is ended and the line containing ".CRLF" is not considered
part of the multi-line response.

[https://www.ietf.org/rfc/rfc1939.txt](Rfc for POP3)

Please review my code, and if there are no problems, please merge.
Opinions are always appreciated, thank you for your hard work.

코드 리뷰 & 병합

PR을 보낸 뒤, 라이브러리의 원 작성자인 @agsh님께서 리뷰를 남겨주셨고, 그에 따라 코드를 조금 더 수정해서 반영했다.
오픈소스라는 특성상, 내 코드가 다른 서비스들에 영향을 줄 수도 있다는 걱정에 처음엔 소극적으로 수정했지만,
오히려 @agsh님이 내가 처음에 시도했던 방식이 더 좋다며 추천해 주셔서 확신을 가질 수 있었다.

결과적으로 해당 PR이 머지되었고, 라이브러리도 새 버전으로 업데이트되었다.
그리고 나는 contributor 목록에 내 이름을 올릴 수 있었다.

그 후

이후 블로그를 만들면서 Strapi에도 작게나마 기여한 적이 있다.
물론 복잡한 수정은 아니었지만, 오픈소스 코드 구조를 읽고 직접 개선 포인트를 찾으며 참여하는 경험 자체가 의미 있었다.

회고 및 느낀 점

오픈소스에 처음 기여한다는 건 쉽지 않은 일이었다.
하지만 한 줄 한 줄 남의 코드를 읽고 이해해가며 내 코드도 함께 성장할 수 있었다고 느꼈다.
앞으로도 꾸준히 오픈소스를 통해 더 나은 개발자로 성장해보고 싶다.