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