이세계에선 내가 오픈소스 기여 개발자!?

오픈소스 기여, 나도 할 수 있을까?

오픈소스 기여를 했다는 말을 들었을 때, 참 대단하게만 느껴졌습니다. 저도 오픈소스 기여를 하고 싶다는 마음은 있었지만, 막상 시작하려니 막막했습니다. React, Next.js 같은 큰 라이브러리를 보면 이슈도 복잡하고, 코드베이스도 방대해서 제가 기여할 수 있을까 하는 두려움이 앞섰습니다.

"이건 내가 해결할 수 있는 문제가 아닌 것 같은데..."
"코드가 너무 복잡하다..."
"PR을 보내도 리뷰를 통과할 수 있을까?"

이런 생각들이 머릿속을 맴돌았고, 결국 기여는 미뤄지기만 했습니다.

작은 불편함이 기회가 되다

회사에서 프로젝트의 폴더 구조와 네이밍이 통일되지 않았고, 어떤 동작을 위한 폴더인지 명확하지 않아 회의 안건으로 제안했습니다.
곧바로 작업을 진행하게 되었고, 프로젝트의 린트 규칙을 정하던 중 eslint-plugin-check-file 플러그인을 통해 폴더명과 파일명을 검증하려고 하였습니다.

그런데 해당 플러그인을 사용하면서 Next.js의 동적 라우트를 사용할 때 문제가 발생했습니다.

// [[...slug]].tsx 같은 파일에서 에러 발생

.test, .setup 같은 중간 확장자를 무시하는 옵션(ignoreMiddleExtensions)을 사용하면, Next.js의 동적 라우트 파일명에서 대괄호 안의 점(...)이 확장자 구분자로 잘못 인식되어 버그가 발생했습니다.

예를 들어, [[...userId]].tsx 파일이고 카멜케이스이기 때문에 통과가 되어야하지만, 통과가 되지 않아 규칙을 적용할 수 없었습니다.

적용은 해야했기 때문에 임시적으로 모든 중간 확장자 케이스를 모두 추가하여 검증하는 방법을 사용했습니다.

문제를 해결하다

이 문제를 발견하고, 왜 이런 문제가 발생하는지 고민하게 되었고. 소스를 직접 파악해보기로 했습니다.

코드를 살펴보니 getBasename 함수가 단순히 점(.)을 기준으로 파일명을 분리하고 있었습니다. 대괄호 안의 점은 파일명의 일부이므로 확장자 구분자로 취급하면 안 되는데, 이를 고려하지 않고 있었던 것이었습니다.

원했던 반환 값

[[...slug]].tsx ==> [[...slug]]

실제 반환 값

[[...slug]].tsx ==> [[

해결 방법은 간단했습니다. 대괄호 안에 있는 .은 확장자 구분자로 인식하지 않도록 수정하기만 하면 되는 작업이었습니다. 이렇게 수정하면 [[...slug]].tsx 같은 파일명도 올바르게 처리할 수 있었습니다.

PR을 보내다

수정 사항을 작성하고 테스트를 추가한 후, PR을 보냈습니다. 생각보다 간단한 수정이었지만, 머지가 된다면 나도 오픈소스 기여자가 될 수 있겠다 라는 생각에 뿌듯했습니다.

PR 리뷰 과정도 거쳤고, 특별한 이슈 없이 머지까지 성공적으로 완료할 수 있었습니다.

작은 것부터 시작하자

이번 경험을 통해 깨달은 것은, 오픈소스 기여는 거창한 기능을 추가하는 것만이 아니라는 점이었습니다.

• 내가 실제로 사용하면서 불편했던 점
• 작은 버그 수정
• 문서 개선
• 테스트 추가

이런 작은 것들부터 시작해도 충분히 의미 있는 기여가 될 수 있습니다. 내가 직접 사용하는 라이브러리에서 문제를 발견했다면, 그 문제를 해결하는 것이 가장 자연스러운 기여의 시작점이 될 수 있다고 생각합니다.

어떤 일이든 입문에서 바로 고급으로 넘어가기 어려운 것처럼, 오픈소스 기여도 마찬가지입니다. 작은 것부터 시작해 점점 큰 라이브러리로 나아가는 것이 더 자연스러운 방향이 아닐까요?