Why I Got Hired After Failing to Submit My PR

# PR을 못 냈는데 채용이 됐다고요? 오픈 소스 기여 실패가 커리어로 이어진 경험담

혹시 오픈 소스 프로젝트에 기여하려고 마음먹었지만, PR(Pull Request)을 끝내 제출하지 못한 경험 있으신가요? 저도 그랬어요. 처음엔 막막하더라고요.  
“이슈는 찾았는데, 어디서부터 손대야 할지 모르겠네.”  
“내가 이 정도 실력으로 기여해도 될까?”  
이런 고민에 휩싸여 결국 PR을 계속 미루다 보니 어느새 시간이 훌쩍 지나버리곤 했죠.

그런데, 정말 놀라운 일이 벌어졌어요. 저는 결국 그 PR을 제출하지 못했음에도 불구하고, 해당 프로젝트 팀에 채용되었습니다.  
“PR도 못 냈는데 채용이 됐다고?”  
이런 반응, 당연히 나올 수밖에 없죠. 저 역시 처음엔 믿기지 않았어요. 하지만 이 경험을 통해 오픈 소스 기여가 단순히 코드 한 줄을 올리는 것 이상이라는 걸, 그리고 그 과정이 개발자의 성장과 커리어에 얼마나 큰 영향을 줄 수 있는지 뼈저리게 느꼈습니다.

이 글에서는 저의 실제 경험을 바탕으로, PR 제출에 실패했지만 오히려 채용으로 이어진 과정을 풀어보려고 해요. 오픈 소스에 처음 도전하는 분들, 취업을 준비하는 개발자 분들, 그리고 기여자의 가능성을 알아보고 싶은 리크루터 분들 모두에게 도움이 될 이야기입니다.

이 글에서 얻어갈 수 있는 것들:

- 오픈 소스 기여 과정에서 흔히 겪는 현실적인 어려움과 고민
- PR을 완성하지 못해도 드러날 수 있는 역량과 태도
- 오픈 소스 활동이 이력서 이상의 의미를 갖는 이유
- 채용자 입장에서 바라본 ‘기여자’의 가치

저의 스토리를 통해 오픈 소스에 도전하는 길이 꼭 PR의 성공과 실패로만 평가되지 않는다는 점, 그리고 그 과정 자체가 여러분의 커리어에 얼마나 소중한 자산이 될 수 있는지 함께 알아보시죠. 혹시 여러분도 “PR을 못 냈으니 실패한 건 아닐까?” 고민하고 계시다면, 이 글이 새로운 시각을 드릴 수 있을 거예요.

---

## 목차

1. [서론: 예상치 못한 채용 여정](#서론-예상치-못한-채용-여정)
2. [오픈 소스 PR 제출 과정, 처음엔 이렇게 헷갈릴 수 있다](#오픈-소스-pr-제출-과정-처음엔-이렇게-헷갈릴-수-있다)
3. [자주 겪는 실패 포인트와 그 원인](#자주-겪는-실패-포인트와-그-원인)
4. [실패를 기회로: 내가 문제를 해결한 방법](#실패를-기회로-내가-문제를-해결한-방법)
5. [자발적 기여와 꾸준함의 힘](#자발적-기여와-꾸준함의-힘)
6. [채용자는 오픈 소스 기여에서 무엇을 볼까?](#채용자는-오픈-소스-기여에서-무엇을-볼까)
7. [실제 사례: PR 실패에서 채용까지](#실제-사례-pr-실패에서-채용까지)
8. [실전 팁: PR 실패를 기회로 바꾸는 방법](#실전-팁-pr-실패를-기회로-바꾸는-방법)
9. [결론: 비선형 커리어, 그 자체가 성장](#결론-비선형-커리어-그-자체가-성장)

---

## 서론: 예상치 못한 채용 여정

처음엔 저도 “오픈 소스에서 채용까지 가려면 PR을 멋지게 내야 한다”고 생각했어요. 깔끔한 코드, 통과된 테스트, 리뷰어의 승인. 이게 당연한 공식인 줄 알았죠. 그런데 실제로 오픈 소스 프로젝트에 지원했을 때, 예상과는 달랐습니다.  
결정적인 PR을 끝내 제출하지 못했거든요.  
솔직히 “이제 끝이구나” 싶었어요. 대부분의 회사가 오픈 소스 PR을 실력 검증의 기준으로 삼는다는 얘기, 다들 들어보셨을 거예요. PR은 코드 실력, 문제 해결력, 협업 능력을 보여주는 창구니까요.  
그래서 PR을 못 냈다는 사실이 엄청난 실패처럼 느껴졌죠.

그런데, 여기서 반전이 생겼어요.  
PR 제출에 실패했음에도, 저는 그 팀에 합격했습니다.

무엇이 달랐을까요?  
팀에서는 제가 이슈에 꾸준히 참여하고, 토론을 주도하며, 어려움을 솔직하게 공유한 점을 높이 평가했어요. 단순히 코드만 보는 게 아니라, 소통 방식, 배우려는 태도, 그리고 포기하지 않는 끈기를 봤던 거죠.  
저 역시 처음엔 코드에만 집착했지만, 이 과정을 통해 오픈 소스 채용이 기술적 완성도만 보는 게 아니라는 걸 깨달았습니다.

  
실패에 너무 좌절하지 마세요. 댓글, 질문, 심지어 실패한 PR도 모두 여러분의 관심과 신뢰성을 보여줄 수 있는 기회입니다.  
어떤가요? 오픈 소스 채용은 ‘완벽한 PR’만 보는 게 아니라, 사람 전체를 본다는 점이 인상적이죠.



 기여 과정에서 문제를 겪더라도, 프로젝트 관리자와 꾸준히 소통하고 상황을 투명하게 공유하세요.
 최종 코드뿐 아니라, 문제 해결 과정과 협업 태도도 충분히 드러내는 것이 중요합니다.
 PR이나 이슈 코멘트에 자신의 고민과 학습 과정을 기록해두면, 성장하는 모습을 자연스럽게 보여줄 수 있습니다.

---



오픈 소스 PR(Pull Request) 제출 과정, 처음 해보면 정말 복잡하게 느껴질 수 있어요.  
저 역시 처음엔 “이걸 어디서부터 시작해야 하지?” 싶었죠.  
하지만 한 번만 제대로 경험해보면, 그 다음부터는 훨씬 수월해집니다.

일반적인 PR 제출 흐름은 이렇습니다:

   
   원본 저장소를 포크해서 내 깃허브 계정에 복사본을 만듭니다.  
   이렇게 하면 내 작업이 원본에 바로 영향을 주지 않으니 부담이 덜하죠.

   

처음엔 브랜치 이름을 대충 지었는데, 나중에 보니 명확한 이름이 훨씬 관리하기 좋더라고요.

3. **수정 및 커밋**  
파일을 고치고, 커밋 메시지를 남깁니다.

커밋 메시지는 짧고 명확하게! 리뷰어도, 미래의 나도 이해하기 쉽습니다.

4. **내 포크에 푸시**  

5. **깃허브에서 PR 생성**  
브라우저에서 내 브랜치로 이동해 “New Pull Request”를 클릭합니다.  
관련 이슈를 연결하고, 변경 내용을 자세히 설명하면 유지보수자들이 정말 고마워해요.

---

**자주 겪는 어려움과 팁**

- **브랜치 관리 & 머지 충돌**  
원본 프로젝트가 업데이트되면 내 브랜치와 충돌이 날 수 있어요.

저도 처음엔 merge만 썼다가 히스토리가 엉망이 됐는데, rebase로 바꾸니 훨씬 깔끔해졌어요.

- **기여 가이드라인**  
CONTRIBUTING.md 파일, 꼭 읽으세요!  
포맷, 테스트, 문서화 등 요구사항이 다 들어있어요.  
헷갈리면 커뮤니티 채팅방이나 이슈에 질문 남겨도 괜찮아요.

- **문서화**  
막히는 부분이 있으면 이슈나 Discussions를 검색해보세요.  
의외로 비슷한 고민을 한 사람이 많더라고요.

여기까지 따라오셨나요?  
이런 과정을 반복하다 보면, 점점 더 자연스럽게 기여할 수 있게 됩니다.  
그리고 이 경험이, 때로는 예상치 못한 커리어 기회로도 이어지죠.

### 💡 실전 팁

- upstream 저장소와 자주 동기화해서 충돌을 최소화하세요.
- CONTRIBUTING.md와 PR 템플릿을 꼼꼼히 읽고, 요구사항을 꼭 지키세요.
- 커밋 메시지는 한 가지 논리적 변경만 담고, 명확하게 작성하세요.

---

## 자주 겪는 실패 포인트와 그 원인

오픈 소스 PR을 준비하다 보면, 생각보다 다양한 이유로 실패를 경험하게 됩니다.  
저 역시 처음엔 “이 정도면 됐겠지” 했다가 여러 번 좌절을 맛봤어요.

**대표적인 실패 포인트는 다음과 같아요:**

- **메인 브랜치에서 바로 작업**  
별도 브랜치 없이 main에서 바로 커밋했다가, 다른 사람과 충돌이 생겨 리뷰가 꼬이기 쉽습니다.  
저도 한 번은 이 실수로, 다른 기여자의 코드와 엉켜버려 리뷰어가 고생하셨죠.

- **충돌 해결 미숙**  
두 명 이상이 같은 파일을 수정하면 충돌이 납니다.  
대충 한쪽만 살리고 넘어가면, 중요한 코드가 날아가거나 빌드가 깨질 수 있어요.  
저도 처음엔 무작정 삭제했다가, 몇 시간 동안 원인 찾느라 고생했습니다.

- **가이드라인 미준수**  
코드 스타일, 커밋 메시지, 테스트 등 프로젝트별로 요구하는 규칙이 있습니다.  
CONTRIBUTING.md를 꼼꼼히 안 읽으면, PR이 바로 닫히기도 해요.

- **소통 부족**  
리뷰어가 피드백을 남겼는데 답이 없거나, 질문이 오갔는데 묵묵부답이면 PR이 방치될 수 있습니다.  
헷갈릴 땐 “이 부분이 잘 이해가 안 되는데, 좀 더 설명해주실 수 있을까요?”라고 솔직하게 물어보세요.

이런 실수는 누구나 할 수 있어요.  
중요한 건, 실수를 통해 배우고, 다음엔 더 나은 방식으로 시도하는 거죠.

### 💡 실전 팁

- 항상 별도의 브랜치에서 작업하세요.
- 가이드라인(코딩 스타일, 커밋 규칙 등)을 꼼꼼히 확인하세요.
- 리뷰어와의 소통은 빠르고 명확하게! 궁금한 점은 적극적으로 질문하세요.

---

## 실패를 기회로: 내가 문제를 해결한 방법

실제로 PR을 준비하다 보면, 예상치 못한 문제가 한두 개가 아니에요.  
저도 “merge conflict”와 “CI 실패” 알림을 처음 봤을 때, 솔직히 멘붕이 왔습니다.  
그런데, 여기서부터가 진짜 시작이었죠.

**제가 실제로 했던 해결 과정은 이렇습니다:**

1. **문제 진단**  
 CI 로그와 PR 리뷰 코멘트를 꼼꼼히 읽었어요.  
 에러 메시지에서 충돌 파일, 커밋 메시지 포맷 불일치 등 원인을 찾았습니다.

2. **브랜치 충돌 해결**  
 처음엔 upstream/main을 merge만 하다가 히스토리가 꼬였는데, 나중엔 rebase로 바꿨어요.

충돌이 나면 직접 수정하고, 테스트까지 돌린 뒤 rebase를 이어갔죠.

3. **가이드라인 맞추기**  
CONTRIBUTING.md를 다시 읽고, 커밋 메시지도 포맷에 맞게 수정했습니다.