코드는 6년 썼는데 PR 버튼은 처음: 오픈소스 첫 기여 일지

얼마 전에 매일 쓰던 라이브러리 README에서 오타를 하나 발견했어요. 고치면 되겠다 싶어서 마우스를 올렸는데, PR 버튼 앞에서 손이 딱 멈추더라고요. 6년차인데 말이죠.

 

웃긴 건, 제 깃허브(GitHub) 잔디는 회사 저장소랑 개인 토이 프로젝트에만 초록색으로 빼곡했어요. 남의 저장소에 뭔가를 보태본 적은 6년 동안 한 번도 없었습니다. 매일 코드를 쓰면서도 오픈소스 첫 기여는 계속 미뤄뒀던 셈이에요.

 

오픈소스 기여 안 해본 6년차, 통계로 보면 다수파

혼자 자책하다가 숫자를 좀 찾아봤는데요. 한 설문에서는 기여를 안 하는 개발자의 67%가 공개 저장소가 아예 0개라고 해요. 반대로 기여자의 48%는 2개 이상 갖고 있고요. 그러니까 "쓰기만 하던" 상태는 부끄러운 소수가 아니라 오히려 다수파라는 얘기입니다.

 

문제는 다른 데 있었어요. 코드를 쓰는(write) 것과, 남의 코드베이스 규칙에 나를 맞추는(collaborate) 건 완전히 다른 기술이더군요. 6년치 문법 실력이 커밋 메시지 규칙 하나 앞에서 무력해지는 순간을 겪어봤습니다.

 

여기에 자격 불안이 얹힙니다. 소프트웨어 엔지니어의 대략 절반 이상이 임포스터 증후군을 겪는다는 조사가 있어요(2024 ICSE 발표). 신입은 "몰라서 묻는 게 당연"한데, 경력자는 "이 정도는 알아야 하는데" 하면서 자기검열을 하거든요. 첫 PR이 신입보다 6년차일 때 더 무서운 건 그래서예요.

 

good first issue 찾는 방법과 첫 저장소 고르기

그래서 저는 방향을 바꿨습니다. 새 기능으로 시작하지 않기로요. 첫 기여는 오타·문서·주석이 정석이라고 하는데, 실제로 문서 PR이 기능 PR보다 병합률이 높은 편이라고 해요(AI 에이전트가 올린 PR을 분석한 자료 기준). 제 첫 PR이 README 오타 한 줄이었던 것도 그래서였습니다.

 

시작점 잡기 좋은 곳들을 정리해두면요.

 

1. 깃허브에서 label:"good first issue" 로 검색하면 초심자용 이슈만 걸러집니다.
2. goodfirstissue.dev, up-for-grabs.net, First Timers Only 같은 큐레이션 사이트를 둘러봐도 좋아요.
3. firstcontributions/first-contributions 저장소는 포크만 수만 개 찍힌, 생애 첫 PR 연습장으로 굳어진 곳이라 절차만 익히기엔 딱입니다.

 

한 가지 요즘 분위기를 덧붙이면, 2025년 들어 AI가 자동 생성한 저품질 PR이 급증하면서 메인테이너들 리뷰 피로가 커졌다고 하고요. 그래서 방향이 애매한 큰 이슈를 덥석 물면 방어적으로 걸러질 수 있어요. 작지만 명확한 걸 고르는 게 지금 시점에선 더 안전하다고 봅니다.

 

CONTRIBUTING.md와 CLA, git보다 먼저 막히는 관문

막상 오타를 고치려는데, git 문법이 문제가 아니었어요. 진짜 관문은 따로 있더라고요.

 

대부분의 저장소는 CONTRIBUTING.md라는 파일에 기여 규칙을 적어둡니다. 어떤 곳은 CLA라는 기여자 동의서에 서명해야 병합해주고요. 이걸 모르면 "코드는 통과했는데 왜 안 머지되지?" 하고 멍하니 기다리게 됩니다. 저도 이 파일을 안 읽고 덤볐다가 한 번 헤맸어요.

 

표준 절차는 이렇습니다. 저장소를 내 계정으로 포크(Fork)하고, main이 아닌 새 branch를 만들어서 거기서 수정하고, 제목·설명을 명확히 단 PR을 올리는 거예요. main에 직접 작업하면 나중에 리뷰 반영할 때 히스토리가 꼬여버립니다.

 

근데 제일 의외였던 병목은 git이 아니라 사회적 절차였어요. 이슈에 먼저 "Hi, I'd like to work on this—does it make sense to start here?" 한 줄 남기는 것.

 

Hi, I'd like to work on this—does it make sense to start here?

 

이 짧은 코멘트 하나가 중복 작업이랑 거절을 눈에 띄게 줄여준다고 합니다.

 

첫 pull request 리뷰 대응, 감정 빼고 코드로

며칠 뒤 'Changes requested'가 달렸을 때, 솔직히 심장이 툭 떨어지더라고요. 여기서 초보가 저지르기 쉬운 실수가, 지적받고 새 PR을 또 여는 겁니다.

 

그럴 필요 없어요. 같은 branch에 수정 사항을 push하면 열려 있는 PR에 그대로 반영됩니다. 그리고 다시 리뷰를 요청하면 돼요. 지적은 하나씩 대응하지 말고 모아서 한 번에 반영하는 게 메인테이너 시간을 존중하는 방식이라고 합니다.

 

여기서 마음 하나만 다잡으면 편해집니다. PR 거절은 실력 부정이 아니에요. 대부분은 로드맵이나 범위가 안 맞거나, 이미 누가 고쳤거나, 타이밍 문제인 경우가 많더라고요. 좋은 프로젝트는 설명 없이 PR을 닫지 않거든요. 지적을 인신공격이 아니라 코드 논의로 떼어내서 보는 것, 이게 오픈소스 협업의 실제 근육이라고 봅니다.

 

머지된 뒤에 남은 것, 그리고 남지 않은 것

리뷰 두어 번 왕복하고 머지 버튼이 초록색으로 바뀌던 순간, 생각보다 담담했어요. 오타 한 줄이 뭐 대단한 일이라고요.

 

그래서 미화는 안 하고 싶습니다. 오타 PR 하나를 거창한 성장 서사로 포장하는 글이 워낙 많은데, 솔직히 지속적인 참여랑 이슈 정리, 남의 PR 리뷰가 첫 기여보다 몇 배는 어렵거든요. 첫 PR은 그냥 출발선입니다.

 

오픈소스 기여가 커리어 필수도 아니에요. 사내 도메인을 깊게 파는 것도 완전히 정당한 길이고, "기여 안 하면 뒤처진다"는 말은 좀 과장이라고 봅니다. 무보수 노동에 감사 없는 리뷰까지 딸려오는, 그림자도 분명 있는 세계니까요.

 

그래도 딱 하나 남은 게 있어요. 남의 저장소 PR 버튼을 처음 눌러본 그 문턱이 사라졌다는 겁니다. 다음 이슈는 확실히 덜 무섭더군요.

 

6년차의 첫 관문은 git 문법이 아니라 자기검열이었어요. "이 실력으로 껴도 되나" 고민하던 그 시간에 CONTRIBUTING.md를 한 번 열어봤더라면, 다음번 README 오타를 만났을 땐 PR 버튼 앞에서 손이 멈추는 일도 없었겠죠.