Skip to main content

Command Palette

Search for a command to run...

오픈소스 기여모임 10기 후기 - 첫 Pr을 올리기까지

Updated
5 min read

개발자라면 누구나 한 번쯤 오픈소스 기여에 대한 환상을 가져본 적 있을 거다. 하지만 막상 시작하려면 어디서부터 해야 할지 막막하고, 괜히 대단한 걸 해야 할 것 같은 부담감에 선뜻 시작하기는 어려운 것 같다. 나 또한 해보고 싶다는 마음만 가지고 계속 미뤄왔다.

그러다 2025년 말 쯤에 오픈채팅방과 글또 슬랙 채널에서 "오픈소스 기여모임" 10기 모집글을 봤다. 2년 넘게 500명 이상의 참가자와 함께 1000개 이상의 PR을 만들어온 커뮤니티라고 했다. 운영진도 Next.js, Spring, OpenJDK, ESLint 같은 메이저 오픈소스 기여자/메인테이너 분들이라 믿음이 갔다.

오픈소스 기여 모임 팀 블로그도 살펴봤다. 운영진인 김인제님이 작성하신 모임 소개글과 기여 가이드를 읽어보니, "누구나 쉽게 오픈소스 기여를 시작할 수 있도록 돕겠다"는 진심이 느껴졌다. 모임 내에서 처음부터 끝까지 1:1로 운영진이 도와준다고 하고, PR 올리고 기부하면 보증금 환급도 해준다고 한다. 안 할 이유가 없는 모임이라고 생각해서 바로 지원했다.

운영진이신 인제님에 대한 간증까지 있었다

나의 기여 결과

오픈소스 기여모임의 필수 인증 조건은 두 가지다.

  1. PR 오픈

  2. 오픈소스 프로젝트에 5$ 기부

나는 Uptime Kuma라는 모니터링 서비스에 PR을 올렸다.
홈서버를 운영하면서 이 서비스를 직접 쓰고 있어서 기여할 프로젝트로 선택했다.

PR: RSS Pub Date 타임존 버그 수정

그리고 약 26시간 만에 머지됐다! 🎉

기부는 회사에서 주로 쓰고 있는 웹 프레임워크 fastify에 했다. 5$가 큰 금액은 아니지만, 내가 매일 쓰는 생태계에 조금이라도 보탰다는 느낌이 생각보다 뿌듯했다. 덤으로 GitHub 프로필에 스폰서 뱃지도 달렸다.

기여 과정: 마감 3일 전부터 시작한 스프린트

솔직히 말하면 끝까지 미루다가 마감 3일 전에야 본격적으로 시작했다. 모임에 들어온 건 12월 말이었는데, 내가 먼저 시작해야 운영진이 도와줄 수 있는 구조라 결국 2~3주를 날린 셈이다. 다행히 인제님이 올려주신 AI와 함께 오픈소스 기여하기 블로그 글 덕분에 빠르게 방향을 잡을 수 있었다.

1. 이슈 수집기로 후보 이슈 모으기

블로그에서 소개된 이슈 수집기를 사용해서 Uptime Kuma의 이슈들을 수집했다. 이슈 수집기는 GitHub 이슈 페이지의 내용을 페이지별로 가져온 후 AI에게 분석을 요청할 수 있는 프롬프트를 생성해주는 도구다. 손쉽게 수십개의 이슈를 모아서 볼 수 있어서 매우 편리하다.

수집한 이슈들을 ChatGPT와 Gemini에 넣어서 난이도별, 종류별로 분류하고 분석했다. AI가 "이 이슈는 첫 기여에 적합하다", "이건 난이도가 높다" 같은 판단을 내려줘서 탐색 시간을 많이 줄일 수 있었다.

2. 이슈 탐색 후 디스코드에 "이슈 선정 도움" 포스팅

분석된 이슈들을 하나씩 읽어보면서 할 만한 것을 골랐다. 그리고 오픈소스 기여모임 디스코드에 "이슈 선정 도움" 글을 올렸다.

내가 올린 글에는 AI 분석 결과를 그대로 포함했다. "왜 기여하기 좋은지", "원인 추정", "해결 방향", "기준 적합도/난이도" 같은 항목들이 정리되어 있어서 운영진이 빠르게 판단할 수 있었던 것 같다.

3. 히스토리 있는 이슈, 최소 수정으로 접근

내가 선택한 이슈는 RSS 피드의 pubDate가 서버 타임존만큼 잘못된 시간을 표시하는 버그였다.
예를 들어 UTC+9 서버에서는 실제보다 9시간 앞당겨진 시간이 표시되는 식이었다.

이 이슈에는 이미 다른 기여자가 시도했다가 중단한 PR이 있었다.
간단한 이슈임에도 여러 방식을 시도하다가 논쟁이 길어진 케이스였다.

  • “문자열에 Z 붙이기 방식” → 동작하지만 메인테이너가 찝찝해함

  • “regex 조건부 Z” → 더 복잡하고 리뷰가 늘어남

  • “dayjs.utc로 강제 파싱” → hacky하다는 논쟁

결국 작성자가 "더 이상 논쟁하기 싫다"며 PR을 닫았다. 이 히스토리를 보면서 오픈소스 기여도 결국 존중에서부터 시작하는 거구나 느꼈다.

인제님이 리뷰해주시면서 **"닫힌 PR도 보면 방향성을 메인테이너와 싱크하는 게 중요할 것 같다"고** 조언해주셨다. 그리고 "최소변경으로 리뷰거리를 줄여야 한다", "버그 티켓이니 로컬에서 버그 재현부터 해보라"는 피드백도 주셨다.

4. 최소 수정 + 테스트 코드로 PR 완료

피드백을 받고 바로 로컬에서 버그를 재현했다. 재현 후 수정 코드를 내 fork에 올리고, 인제님께 공유드렸더니 테스트 작성하고 PR open하면 될 거라고 말씀주셨다. 이런 빠른 피드백 덕분에 자신감을 가지고 파바박 진행할 수 있었다.

버그의 원인은 DB에 저장된 heartbeat.time이 타임존 정보 없는 UTC 타임스탬프인데, JavaScript의 Date 생성자가 이를 로컬 시간으로 해석하면서 발생한 것이었다. 해결은 단 1줄이었다.

// 변경 전
new Date(heartbeat.time)

// 변경 후
dayjs.utc(heartbeat.time).toDate()

이전 기여자가 복잡하게 접근했던 것과 달리, 핵심만 건드리니까 리뷰도 빠르게 진행됐다. 메인테이너도 "That is what I wanted"라며 긍정적으로 반응해줬고, 인제님도 축하해주셨다. 😊

솔직한 후기

좋았던 점

가장 좋았던 건 "혼자가 아니다"라는 점이었다. 이슈 선정부터 PR까지, 내가 놓치고 있는 포인트를 운영진이 계속 잡아줬다.

  • 다른 참가자들 보니까 이슈가 너무 크거나 이미 진행 중인 건 미리 걸러주시더라

  • 내 경우는 간단한 이슈였지만, "버그 재현 → 수정 확인 → 테스트 코드 작성" 순서로 명확하게 가이드해주셨다

  • "첫 기여는 간단한 이슈 + 최소 변경"을 계속 강조해줘서 마음이 가벼워졌다

  • 디스코드에서 다른 참가자들의 진행 상황도 볼 수 있어서 덜 외로웠다

어려웠던 점

오픈소스는 내가 책임질 수 없는 환경(다양한 DB, 타임존, 배포 방식)까지 고려해야 해서 "어디까지가 적절한 수정인가?"의 감이 잘 안 왔다. 다행히 여러 환경에서의 테스트가 마련되어 있었고 매우 작은 변경이라 아무 문제가 없었다. 그리고 이전 PR의 내용을 보니까 메인테이너의 성향까지 고려를 해야 한다는 게 생각지도 못했던 어려운 부분인 것 같다.

반성할 점

마감 3일 전까지 미룬 건 앞에서도 말했지만, 돌이켜보면 시작만 했으면 됐다. 첫 이슈 선정 글 올리는 데 30분도 안 걸렸는데, 그걸 2~3주나 미룬 거다. 뭔가 대단한 걸 해야 할 것 같은 부담감이 시작을 막았는데, 막상 해보니 이슈의 난이도와 상관없이 모든 기여가 의미있으니 도와준다는 느낌으로 하면 되는 것 같다.

배운 점

  1. 이슈를 고를 때는 "증상이 명확한가"가 제일 중요하다. 스크린샷, 재현 방법, 메인테이너 코멘트가 있는 이슈가 해결하기 쉽다.

  2. AI는 분석과 초안에 도움되지만, 최종 판단은 사람이 해야 한다. 프로젝트 문화나 리뷰 논점은 결국 사람이 챙겨야 한다.

  3. 기여는 거창한 기능 추가가 아니다. 작은 버그 하나를 정리해서 전 세계 사용자의 시간을 아껴주는 것도 의미 있는 기여다.

다음에도 오픈소스 기여 모임에 참여한다면 이렇게 하려고 한다:

  • 최대한 1주차에 이슈 선정 + 재현까지 끝내기

  • PR 설명은 미리 초안이라도 써두기 (나중에 쓰려면 기억이 휘발됨)

  • 작은 변경이라도 검증 근거(빌드/테스트/재현 환경)를 남기기

이런 분들에게 추천합니다

  • "해보고 싶은데 어디서부터 시작해야 할지 모르겠다" 하는 사람

  • 혼자 PR 올리다 지치거나 재미를 못 느꼈던 사람

  • 내가 쓰는 오픈소스에 한 번쯤은 흔적을 남기고 싶은 사람

오픈소스 기여가 막막할수록 이 모임을 더 추천한다. 운영진 분들이 정말 친절하고, 체계적인 프로세스가 있어서 첫 기여의 두려움을 많이 덜어준다. 보증금 3만원도 PR 완료 후 전액 환불되고, 오프라인 밋업에 참석하면 오픈소스 키링 굿즈와 PR 썸네일 스티커도 받을 수 있다.

나는 참여를 못했지만, 모임 기간 중 오프라인 세션과 온라인 모임도 열어서 이슈 선정에 어려움이 있는 분들을 운영진이 직접 도와주셨다. 다음에 참여하는 분들은 이런 기회도 꼭 활용하면 좋겠다. 그만큼 오픈소스의 접근성을 높이는 데 진심인 모임이다.

마무리

처음에는 오픈소스 기여가 대단한 사람들만 하는 일처럼 느껴졌는데, 이번 모임 덕분에 "그냥 한 걸음씩 하면 되는 거구나"를 몸으로 배웠다.

PR 하나 올리고, 5$ 기부까지 하고 나니까 2026년을 시작하는 느낌이 꽤 좋았다. 다음에는 더 여유 있게, 더 꾸준하게 해봐야겠다.


참고 자료

More from this blog

😢 글또 10기 활동 회고 — “글또야, 가지 마…”

들어가며 드디어 글또 10기 활동 회고를 정리해본다.6개월간의 여정을 뒤돌아보니 정말 많은 일들이 있었다. 글또라는 커뮤니티를 8기가 한창 진행되고 있을 때 알았는데 이름부터 인상이 강렬했다. "글쓰는 또라이가 세상을 바꾼다." 유쾌하고 독특한 문구에 피식 웃으며, '여긴 도대체 어떤 사람들이 모이는 곳이지?' 하고 넘겼었다. 재밌는 건 결국, 나도 그 "또라이들" 중 한 명이 되었다는 것이다. 😌 글또는 개발자들이 2주에 한 번 글을 ...

Jul 31, 20255 min read
😢 글또 10기 활동 회고 — “글또야, 가지 마…”

Serverless 환경에서 배포 전 환경변수 검증 자동화하기: TypeBox와 Bitbucket Pipeline 활용기

들어가며 배포 직후, 환경변수가 제대로 설정되지 않아 여러 API가 제대로 작동하지 않는 일이 있었습니다. 다행히 밤에 사용자가 없을 때 문제가 있었던 거라 영향도는 크지 않았지만 앞으로도 계속해서 발생할 수 있는 문제이기 때문에 해결해야 겠다고 생각했습니다. 개발 단계에서 문제가 발견되면 가장 좋겠지만, 현재 팀 상황에서는 백엔드 개발을 혼자 담당하고 있어 코드 리뷰나 검증 프로세스를 갖추기가 쉽지 않았습니다. 그래서 최소한 배포 전에 자동으...

Mar 16, 20254 min read

Cloudflare Tunnel로 포트포워딩 없이 홈서버 운영하기

이 글에서 다루는 내용 포트포워딩이 안 되는 이유 (CGNAT 환경 이해) CGNAT 우회 방법들의 장단점 비교 Cloudflare Tunnel 설정 방법 (MacOS 기준) 외부에서 내 PC로 접근할 수 있도록 허용하는 방법을 생각하면 포트포워딩이 가장 먼저 떠오릅니다. 공유기에서 특정 포트를 열어 외부에서 서버에 접속할 수 있도록 설정하는 방식으로, 마인크래프트 멀티를 해보셨던 분이라면 분명 해보셨을 방법입니다. 😊 작년에 저는 홈서...

Mar 2, 20256 min read
Cloudflare Tunnel로 포트포워딩 없이 홈서버 운영하기

구름고래 공방

48 posts