오픈소스에 기여하는 것은 항상 두려웠다. “내 코드가 좋지 않으면 어쩌지?”, “거절당하면 어떡하지?” 이런 생각에 망설였다. 하지만 작은 버그 수정 하나로 시작한 기여가 나에게 큰 의미를 주었다. 이 글은 그 첫 경험의 기록이다.
시작: 오픈소스 기여에 대한 두려움
왜 기여하지 않았나
개발자로 일한 지 3년이 되었지만, 오픈소스에 기여한 적은 없었다. 이유는 간단했다. 두려웠다.
“내 코드가 좋지 않으면 어쩌지?” “거절당하면 어떡하지?” “영어로 소통해야 하는데 괜찮을까?” “이슈를 제대로 이해했을까?”
이런 생각들에 막혀서 기여하지 못했다.
첫 기여의 계기
2025년 10월, 자주 사용하던 오픈소스 라이브러리에서 작은 버그를 발견했다. 타입 정의에 오타가 있었다.
// 잘못된 타입 정의
interface User {
emial: string; // email의 오타
}“이 정도는 수정할 수 있겠다”라고 생각했다. 작은 버그였고, 명확한 수정이었다.
첫 번째 시도: PR 작성
저장소 포크
GitHub에서 저장소를 포크했다. 처음 해보는 작업이라 조금 어색했다.
브랜치 생성
기여 가이드를 읽고, 브랜치를 생성했다.
git checkout -b fix/typo-in-user-interface브랜치 이름을 어떻게 지어야 할지 고민했다. “fix/typo”가 적절한지 확인했다.
코드 수정
간단한 수정이었다. 오타만 고치면 됐다.
// 수정 후
interface User {
email: string; // 오타 수정
}하지만 이 작은 수정에도 시간이 걸렸다. “정말 이게 맞나?”라는 생각이 계속 들었다.
커밋 메시지 작성
커밋 메시지를 작성하는 것도 어려웠다.
첫 번째 시도:
fix typo너무 간단했다. 가이드를 다시 읽고 수정했다.
두 번째 시도:
fix: typo in User interface email property
Fixed typo in User interface where 'emial' was used instead of 'email'이제 괜찮아 보였다.
PR 생성
PR을 생성했다. 제목과 설명을 작성하는 것도 어려웠다.
PR 제목:
Fix typo in User interfacePR 설명:
Fixed typo in User interface where 'emial' was used instead of 'email'.
This was causing TypeScript errors when using the email property.영어로 작성하는 것이 부담스러웠다. 문법이 맞는지 확인하고, 다시 확인했다.
첫 번째 리뷰: 거절당함
리뷰어의 피드백
3일 후, 리뷰어의 피드백을 받았다.
Thanks for your contribution! However, I noticed that this typo
exists in multiple places. Could you fix all occurrences?
Also, please add a test case to ensure this doesn't happen again.거절당한 것은 아니었지만, 추가 작업이 필요했다.
좌절감
“작은 수정인데 왜 이렇게 복잡해?”라는 생각이 들었다. 하지만 리뷰어의 요청이 합리적이었다. 모든 오타를 수정하고, 테스트도 추가해야 했다.
다시 시작
전체 코드베이스를 검색해서 모든 오타를 찾았다. 5곳에서 같은 오타가 발견되었다. 모두 수정했다.
테스트도 추가했다. 처음에는 테스트를 어떻게 작성해야 할지 몰랐지만, 기존 테스트를 참고해서 작성했다.
describe('User interface', () => {
it('should have correct email property', () => {
const user: User = { email: 'test@example.com' };
expect(user.email).toBe('test@example.com');
});
});두 번째 시도: 승인
수정된 PR
모든 오타를 수정하고, 테스트를 추가한 후 PR을 업데이트했다.
변경사항:
- 5곳의 오타 수정
- 테스트 케이스 추가
- 문서 업데이트
승인
1주일 후, PR이 승인되었다.
LGTM! Thanks for your contribution. This is a great catch!승인 메시지를 받았을 때의 기쁨은 말로 표현하기 어려웠다.
배운 점들
1. 작은 것부터 시작하라
처음부터 큰 기능을 추가하려고 하지 말고, 작은 버그 수정부터 시작하라. 작은 기여도 의미가 있다.
2. 가이드를 읽어라
모든 오픈소스 프로젝트에는 기여 가이드가 있다. 가이드를 읽고 따라하라. 브랜치 이름, 커밋 메시지, PR 형식 등이 프로젝트마다 다를 수 있다.
3. 피드백을 받아들이라
리뷰어의 피드백을 방어적으로 받지 말고, 건설적으로 받아들이라. 피드백은 코드를 개선할 기회다.
4. 테스트를 작성하라
작은 수정이라도 테스트를 작성하라. 테스트가 있으면 버그를 방지할 수 있고, 리뷰어도 신뢰할 수 있다.
5. 인내심을 가져라
PR 리뷰는 시간이 걸린다. 리뷰어들도 바쁘고, 여러 PR을 검토해야 한다. 인내심을 가지고 기다리라.
오픈소스 커뮤니티의 따뜻함
리뷰어의 친절함
리뷰어가 매우 친절했다. 피드백을 줄 때도 “Thanks for your contribution!”이라고 먼저 감사를 표현했다.
“이 부분을 이렇게 수정하면 더 좋을 것 같아요”라고 건설적인 피드백을 주었다.
다른 기여자들의 격려
PR이 승인된 후, 다른 기여자들도 격려의 메시지를 남겼다.
“Great first contribution!” “Welcome to the project!”
오픈소스 커뮤니티가 생각보다 따뜻했다.
두 번째 기여
자신감 생김
첫 기여가 성공하자 자신감이 생겼다. 두 번째 기여를 시작했다.
이번에는 문서 개선이었다. README에 누락된 내용을 추가했다.
더 큰 기여
세 번째 기여에서는 작은 기능을 추가했다. 버그 수정보다는 조금 더 복잡했지만, 첫 기여 경험을 바탕으로 자신 있게 진행했다.
다른 개발자들에게
오픈소스 기여를 시작한다면
오픈소스 기여를 시작하려는 개발자들에게 조언한다:
- 작은 것부터: 작은 버그 수정이나 문서 개선부터 시작하라
- 가이드 읽기: 기여 가이드를 반드시 읽어라
- 피드백 받아들이기: 리뷰어의 피드백을 건설적으로 받아들이라
- 테스트 작성: 테스트를 작성하는 습관을 들여라
- 인내심: 리뷰는 시간이 걸린다. 인내심을 가져라
두려워하지 말라
오픈소스 기여는 두려울 필요가 없다. 대부분의 커뮤니티는 신규 기여자를 환영한다. 작은 기여도 의미가 있고, 실수를 두려워하지 말라.
결론: 작은 PR의 의미
작은 PR 하나가 나에게 큰 의미를 주었다. 오픈소스에 기여하는 것이 그렇게 어려운 일이 아니라는 것을 배웠다.
지금은 정기적으로 오픈소스에 기여하고 있다. 작은 버그 수정부터 시작해서, 이제는 작은 기능도 추가하고 있다.
오픈소스 커뮤니티는 생각보다 따뜻하다. 두려워하지 말고, 작은 것부터 시작하라. 작은 PR 하나가 큰 의미가 될 수 있다.
