<div id="readability-page-1" class="page"><div><p><h2 id="fa43">꼼수로 오픈소스 기여하기</h2></p><div><h2 id="e242">오픈소스 기여로 매력적인 GitHub 프로필 만들기</h2><div><p><a rel="noopener" href="/?source=post_page-----b34ee4cc2bc2--------------------------------"><img alt="Woosik Kim" src="https://miro.medium.com/fit/c/56/56/1*ObWTeqH8kLqaOJFwAqWipA.jpeg" width="28" height="28"></a></p></div></div><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/3840/1*j-YArWldAM4J7Ez08bEY5A.jpeg" width="1920" height="1271" role="presentation"></p></div></figure><h2 id="018a">들어가면서 😀</h2><p id="3fe8">GitHub은 정말 내게 큰 의미를 주는 서비스이다. 비전공자인 내가 취업을 준비할 당시에는 이렇다 할 경험도 없었고, 이력서에서 보여줄 수 있는 거라고는 GitHub 프로필과 각 Repository에 대한 소개 정도 밖에 없었는데 취업뽀개기에 성공했기 때문이다. (열심히 잔디를 심은 보람이 있었다)</p><p id="26e5">사진도 바꾸고, 프로필 정보도 입력하고, 열심히 잔디도 가꾸고나면 제법 내 Github 페이지가 볼만해진다. 그러나 주관적인 관점에서 매력적인 페이지라고 하기에 2% 부족하다는 생각이 든다.</p><p id="1863"><strong>좀 더 Professional한 페이지를 완성하기 위해서는 무엇을 해야할까?</strong></p><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/5496/1*7uq10CDdiDYif5VwRv69pw.png" width="2748" height="1632" sizes="700px" role="presentation" data-old-src="https://miro.medium.com/max/60/1*7uq10CDdiDYif5VwRv69pw.png?q=20"></p></div><figcaption>이현수(incleaf)님의 GitHub 페이지</figcaption></figure><p id="7fb6">나는 <strong>오픈소스 기여</strong>라고 말하고 싶다. 앞에서는 단순히 돋보이는 GitHub 프로필에 대해서 이야기했지만 이것 외에도 <strong>오픈소스에 기여하는 행위로 얻을 수 있는 다양한 가치들이 존재한다.</strong></p><p id="57e6">대표적인 것들을 정리해보자면 아래와 같다.</p><ul><li id="1230">앞서 말했듯 경우에 따라서 <strong>스펙</strong>이 될 수 있다.</li><li id="b0a3">다양한 사람들과의 <strong>커뮤니케이션 </strong>경험을 얻을 수 있다.</li><li id="e4fc">실력있는 개발자들의 <strong>코드</strong>를 읽고 배울 수 있다.</li></ul><p id="c55a">물론 <span id="rmm"><span id="rmm">회</span></span>사에서도 수없이 많은 코드를 읽고 쓴다. 얼마 전까지 회사에서 개발을 리드해주시던 분께서 내게 해주셨던 말이 생각난다.</p><blockquote><p id="3ed9"><strong>회사에서는 커뮤니케이션을 익히시고, 스킬은 GitHub에서 익히세요.</strong></p></blockquote><p id="22a7">회사에서 볼 수 있는 소스코드를 평가절하하는 것은 아니지만 회사에서 개발하는 서비스에는 상대적으로 <strong>시간과의 타협, 비즈니스와의</strong> <strong>타협 등의 흔적이 많이 묻어있다는 사실을 부정할 수는 없을 것이다.</strong></p><p id="695e">물론 오픈소스로 운영되고 있는 서비스에 내 코드를 반영한다는 것은 쉬운 일이 아니다. 그래서 이번 글에서는 <strong>오픈소스 세상으로 첫걸음을 내딛기 위한 과정</strong>들을 경험에 비추어 생생하게 공유해보려고 한다.</p><p id="fab7">제목에서 팁이나 노하우가 아닌 <strong>꼼수</strong>라고 표현한 이유에는 마케팅적인 요소도 내포하고 있지만 필자 역시 오픈소스 세계에 발을 들인지 얼마 되지 않았고, <strong>비기너인 독자를 대상</strong>으로 쓴 글인 만큼 깊이 있게 기여하는 방법에 대해서 다루지는 않기 때문이다.</p><p id="54f3">그렇다 이 글은 <strong>오픈소스에 기여하는 것이 생각보다 어마어마하게 어려운 일은 아니라는 것</strong>을 보여준다. 그러니 겁먹지 말고 천천히 완독하길 바란다.</p><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/5312/1*4nvRlKmMRMOKxYjmhY-WNA.png" width="2656" height="1414" sizes="700px" role="presentation" data-old-src="https://miro.medium.com/max/60/1*4nvRlKmMRMOKxYjmhY-WNA.png?q=20"></p></div><figcaption>firstcontributions에서 포크한 저장소와 내가 기여한 Organization 아이콘</figcaption></figure><p id="5896">오픈소스를 기여하는 플로우에 대해서 전혀 모른다면 비기너들을 위한 튜토리얼을 제공해주는 <a href="https://github.com/firstcontributions/first-contributions" rel="noopener nofollow"><strong><em>firstcontributions</em></strong></a>을 살펴보자.</p><p id="f54a">해당 튜토리얼을 완료하면 스크린샷처럼 전리품을 남길 수 있으니 꼭 직접 실습해보는 걸 추천한다.</p><h2 id="bbcf">기여할만한 오픈 소스 둘러보기 🧐</h2><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/4328/1*TR4g_OpG3FXuybkXbWR4Vw.png" width="2164" height="680" sizes="700px" role="presentation" data-old-src="https://miro.medium.com/max/60/1*TR4g_OpG3FXuybkXbWR4Vw.png?q=20"></p></div><figcaption><a href="https://github.com/search/advanced" rel="noopener nofollow">https://github.com/search/advanced</a></figcaption></figure><p id="2474">먼저 우리가 기여할만한 오픈소스를 찾아야한다. 사실상 비기너들에게 있어서 이 작업이 가장 답답하고 어려운 작업일 것이다. 하지만 <strong>advanced search</strong> 기능을 활용한다면 이 부담을 조금 덜 수 있다.</p><p id="bd9e">이곳에서 <strong><em>With the labels</em></strong> 옵션에서 <strong><em>good first issue</em> </strong>키워드를 사용하여 검색해보면 아래와 같은 화면이 나타난다. 좌측에 저장소의 주력언어를 선택할 수 있으니 내게 맞는 언어를 선택하고 천천히 내가 기여할만한 것들이 있는지 둘러보고 하나 선택해보자.</p><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/6720/1*foMhXliSkPcrvJJsOhO92g.png" width="3360" height="1668" sizes="700px" role="presentation" data-old-src="https://miro.medium.com/max/60/1*foMhXliSkPcrvJJsOhO92g.png?q=20"></p></div><figcaption>good first issue 라벨로 검색한 결과</figcaption></figure><p id="d888">검색 단계에서 포기하는 사람들이 정말 많은데 끈기를 가지고 꾸준히 찾아보면 이런 이슈도 찾을 수 있다.</p><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/4952/1*ewlAyIdbpSMRezzMdBcgkw.png" width="2476" height="942" sizes="700px" role="presentation" data-old-src="https://miro.medium.com/max/60/1*ewlAyIdbpSMRezzMdBcgkw.png?q=20"></p></div><figcaption><a href="https://github.com/chris-mcdonald-dev/korean-discord-app/issues/31" rel="noopener nofollow">https://github.com/chris-mcdonald-dev/korean-discord-app/issues/31</a></figcaption></figure><p id="7ff9">링크로 들어가서 읽어보면 알겠지만 이정도면 거의 이슈를 제기한 사람이 답까지 다 공유해 둔 케이스다. 그러니 <strong>절대 포기하지말자 !</strong></p><h2 id="978b">이슈 배정받기 🙏</h2><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/3712/1*nJ-6U2yQ06RQmGrtEe-C0g.png" width="1856" height="294" sizes="700px" role="presentation" data-old-src="https://miro.medium.com/max/60/1*nJ-6U2yQ06RQmGrtEe-C0g.png?q=20"></p></div></figure><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/3708/1*KgvPEpPW6gAfgQepispEog.png" width="1854" height="310" sizes="700px" role="presentation" data-old-src="https://miro.medium.com/max/60/1*KgvPEpPW6gAfgQepispEog.png?q=20"></p></div><figcaption>Assignees로 임명받기</figcaption></figure><p id="981c">내가 기여할 수 있거나 도전해보고 싶은 이슈를 발견했다면 내 기준으로는 거의 절반이상 성공했다고 생각한다. 바로 PR을 생성하고 이슈 넘버를 태깅하더라도 크게 문제되지는 않지만 위처럼 <strong>해당 이슈를 진행해도 되는지 컨펌을 받고 작업하는게 국룰이다.</strong></p><p id="0f70">보통 요청을 하면 <strong>따봉 이모지</strong>를 붙여주거나 <strong>go ahead ! go for it ! </strong>같은 답변을 남겨주는데 이러한 신호를 감지했다면 이제 기쁜 마음으로 코딩을 시작하면 된다.</p><h2 id="97e6">CONTRIBUTING.md 읽어보기 📑</h2><p id="f3cc"><code>CONTRIBUTING.md</code>은 Issue, Pull Request, 코딩 스타일 등 <strong>Contribution을 하기 위해서 봐야하는 가이드라인을 명시하고 있다</strong>.</p><p id="f42c">내용은 거의 비슷하지만 저장소마다 양식이 조금씩 다르니 읽어보면 도움이 될 것이다. 간혹 규모가 작은 프로젝트에는 해당 파일이 없을 수 있는데 그런 경우에는 Merge된 PR을 보면서 <strong>센스를 잘 발휘하여 작성하면 된다.</strong></p><h2 id="7fc7">저장소 포크하기 🛒</h2><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/1652/1*O_bJan3nsRLe0YTskEGPuw.png" width="826" height="106" sizes="700px" role="presentation" data-old-src="https://miro.medium.com/max/60/1*O_bJan3nsRLe0YTskEGPuw.png?q=20"></p></div><figcaption>Fork Repository interface</figcaption></figure><p id="5450">당연한 이야기지만 이슈를 배정받았다고 신나서 <code>git clone</code>으로 <strong>원본 저장소를 가져와 작업을 하고 </strong><code><strong>git push</strong></code> 하면 안된다. 작업을 시작하기 위해서는 저장소를 Fork 해야한다.</p><h2 id="446d">작업하기 🔥</h2><p id="7d79">Fork한 Repository를 <code>git clone</code> 명령으로 로컬로 가져온 후에 적당한 이름의 branch를 지어주자. 거의 모든 경우 <code><strong>README.md</strong></code><strong>에 개발환경을 구축하는 가이드라인</strong>이 있으니 잘 읽어보면서 프로젝트를 빌드한 후에 작업에 착수하면 된다.</p><p id="11e2">빌드 과정에서 잘 안되는 부분이 있다면 멤버들에게 질문해도 좋다. 또한 도중에 버그나 수정사항을 발견할 경우 이를 이슈로 생성한다면 정말 좋은 경험이 되기도 한다.</p><figure><div><p><img alt="" src="https://miro.medium.com/max/1156/1*8SwwKgWinuP9gLSZxehyUw.png" width="578" height="314" sizes="578px" role="presentation" data-old-src="https://miro.medium.com/max/60/1*8SwwKgWinuP9gLSZxehyUw.png?q=20"></p></div><figcaption>localhost:7070 root api <strong>not found</strong></figcaption></figure><p id="031e">나같은 경우는 API 코드를 리팩토링하는 이슈를 배정받고 개발 환경을 세팅했는데 서버를 띄워보니 <code>Not Found</code>가 떠서 세팅 과정에서 문제가 있는줄 알고 혼란을 겪었던 경험이 있다.</p><p id="17c4">이는 알고보니 <code>/</code> 경로에 연결된 핸들러가 없었기 때문이었다.</p><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/5052/1*lfV_hQgmdysoN23jUiocLA.png" width="2526" height="1360" sizes="700px" role="presentation" data-old-src="https://miro.medium.com/max/60/1*lfV_hQgmdysoN23jUiocLA.png?q=20"></p></div><figcaption>셀프로 가져가기</figcaption></figure><p id="929d">이런 경우는 <strong>이슈를 생성함과 동시에 조심스럽게 Assign을 요청할 수도 있다.</strong></p><h2 id="8af3">Pull Request 생성하기 🤝</h2><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/3908/1*5sDJ4wFDQU02KjVDIKptwA.png" width="1954" height="1256" sizes="700px" role="presentation" data-old-src="https://miro.medium.com/max/60/1*5sDJ4wFDQU02KjVDIKptwA.png?q=20"></p></div><figcaption>PR 생성</figcaption></figure><p id="d602">작업을 마쳤다면 PR을 생성해보자. PR을 생성하면 멤버들이 만들어둔 양식이 있으니 이에 맞춰서 작성해주면 된다. 만약 양식이 없더라도 내가 진행한 <strong>작업개요</strong>와 <strong>이슈 번호</strong>를 작성하는건 절대 잊지말자!</p><p id="38b7">PR을 생성하면 멤버들의 코드 리뷰가 이행될 때까지 기다려야한다. 자꾸만 새로고침을 누르게 된다. (사실 이 순간이 가장 힘든 부분이다)</p><p id="f34d">수정할 사항이 없다면 고맙다는 인사와 함께 Merge 되겠지만 아래처럼 <strong>수정사항이 생길 수도 있다.</strong></p><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/3236/1*EH9-gmTLdrtB8ItXMFKifw.png" width="1618" height="744" sizes="700px" role="presentation" data-old-src="https://miro.medium.com/max/60/1*EH9-gmTLdrtB8ItXMFKifw.png?q=20"></p></div><figcaption>Code Review</figcaption></figure><p id="f760">질문이나 토론이 필요하다면 해도 되고, 수정사항이 생기면 진행상황을 공유해주며 Merge를 기다리면 된다.</p><h2 id="3497">야나두 Contributor ! 🥳</h2><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/3736/1*SD6xjPRic2fwvrkH_FpOHQ.png" width="1868" height="498" sizes="700px" role="presentation" data-old-src="https://miro.medium.com/max/60/1*SD6xjPRic2fwvrkH_FpOHQ.png?q=20"></p></div></figure><p id="8ae4">멤버들의 코드 리뷰가 끝나면 드디어 나의 코드가 오리지널 저장소의 일부분으로 병합이 되면서 <strong>프로젝트의 Contributor로 기록된다.</strong></p><h2 id="5031">마치며 🤗</h2><p id="3653">이렇게 오픈소스에 기여하는 과정을 살펴보았다. 사람마다 오픈소스에 기여하는 이유는 모두 다르다.</p><p id="1870">나같은 경우에도 처음에는 오직 <strong>성장</strong>을 위해서 시작했지만 몇차례 해보니 <strong>성취감</strong>이나 <strong>보람</strong>을 느끼는 부분이 더 크게 작용하는 거 같다.</p></div><div><p id="716b">다른 무엇보다도 Approve와 동시에 달리는 <strong>멤버들의 감사인사는 정말 소중하다. 여러분들도 이 느낌을 꼭 경험해봤으면 한다.</strong></p></div></div>

Stories by Woosik Kim on Medium

오픈소스 기여로 매력적인 GitHub 프로필 만들기
들어가면서 😀
GitHub은 정말 내게 큰 의미를 주는 서비스이다. 비전공자인 내가 취업을 준비할 당시에는 이렇다 할 경험도 없었고, 이력서에서 보여줄 수 있는 거라고는 GitHub 프로필과 각 Repository에 대한 소개 정도 밖에 없었는데 취업뽀개기에 성공했기 때문이다. (열심히 잔디를 심은 보람이 있었다)
사진도 바꾸고, 프로필 정보도 입력하고, 열심히 잔디도 가꾸고나면 제법 내 Github 페이지가 볼만해진다. 그러나 주관적인 관점에서 매력적인 페이지라고 하기에 2% 부족하다는 생각이 든다.
좀 더 Professional한 페이지를 완성하기 위해서는 무엇을 해야할까?
나는 오픈소스 기여라고 말하고 싶다. 앞에서는 단순히 돋보이는 GitHub 프로필에 대해서 이야기했지만 이것 외에도 오픈소스에 기여하는 행위로 얻을 수 있는 다양한 가치들이 존재한다.
대표적인 것들을 정리해보자면 아래와 같다.
앞서 말했듯 경우에 따라서 스펙이 될 수 있다.
다양한 사람들과의 커뮤니케이션 경험을 얻을 수 있다.
실력있는 개발자들의 코드를 읽고 배울 수 있다.
물론 회사에서도 수없이 많은 코드를 읽고 쓴다. 얼마 전까지 회사에서 개발을 리드해주시던 분께서 내게 해주셨던 말이 생각난다.
회사에서는 커뮤니케이션을 익히시고, 스킬은 GitHub에서 익히세요.
회사에서 볼 수 있는 소스코드를 평가절하하는 것은 아니지만 회사에서 개발하는 서비스에는 상대적으로 시간과의 타협, 비즈니스와의 타협 등의 흔적이 많이 묻어있다는 사실을 부정할 수는 없을 것이다.
물론 오픈소스로 운영되고 있는 서비스에 내 코드를 반영한다는 것은 쉬운 일이 아니다. 그래서 이번 글에서는 오픈소스 세상으로 첫걸음을 내딛기 위한 과정들을 경험에 비추어 생생하게 공유해보려고 한다.
제목에서 팁이나 노하우가 아닌 꼼수라고 표현한 이유에는 마케팅적인 요소도 내포하고 있지만 필자 역시 오픈소스 세계에 발을 들인지 얼마 되지 않았고, 비기너인 독자를 대상으로 쓴 글인 만큼 깊이 있게 기여하는 방법에 대해서 다루지는 않기 때문이다.
그렇다 이 글은 오픈소스에 기여하는 것이 생각보다 어마어마하게 어려운 일은 아니라는 것을 보여준다. 그러니 겁먹지 말고 천천히 완독하길 바란다.
오픈소스를 기여하는 플로우에 대해서 전혀 모른다면 비기너들을 위한 튜토리얼을 제공해주는 firstcontributions을 살펴보자.
해당 튜토리얼을 완료하면 스크린샷처럼 전리품을 남길 수 있으니 꼭 직접 실습해보는 걸 추천한다.
기여할만한 오픈 소스 둘러보기 🧐
먼저 우리가 기여할만한 오픈소스를 찾아야한다. 사실상 비기너들에게 있어서 이 작업이 가장 답답하고 어려운 작업일 것이다. 하지만 advanced search 기능을 활용한다면 이 부담을 조금 덜 수 있다.
이곳에서 With the labels 옵션에서 good first issue 키워드를 사용하여 검색해보면 아래와 같은 화면이 나타난다. 좌측에 저장소의 주력언어를 선택할 수 있으니 내게 맞는 언어를 선택하고 천천히 내가 기여할만한 것들이 있는지 둘러보고 하나 선택해보자.
검색 단계에서 포기하는 사람들이 정말 많은데 끈기를 가지고 꾸준히 찾아보면 이런 이슈도 찾을 수 있다.
링크로 들어가서 읽어보면 알겠지만 이정도면 거의 이슈를 제기한 사람이 답까지 다 공유해 둔 케이스다. 그러니 절대 포기하지말자 !
이슈 배정받기 🙏
내가 기여할 수 있거나 도전해보고 싶은 이슈를 발견했다면 내 기준으로는 거의 절반이상 성공했다고 생각한다. 바로 PR을 생성하고 이슈 넘버를 태깅하더라도 크게 문제되지는 않지만 위처럼 해당 이슈를 진행해도 되는지 컨펌을 받고 작업하는게 국룰이다.
보통 요청을 하면 따봉 이모지를 붙여주거나 go ahead ! go for it ! 같은 답변을 남겨주는데 이러한 신호를 감지했다면 이제 기쁜 마음으로 코딩을 시작하면 된다.
CONTRIBUTING.md 읽어보기 📑
CONTRIBUTING.md은 Issue, Pull Request, 코딩 스타일 등 Contribution을 하기 위해서 봐야하는 가이드라인을 명시하고 있다.
내용은 거의 비슷하지만 저장소마다 양식이 조금씩 다르니 읽어보면 도움이 될 것이다. 간혹 규모가 작은 프로젝트에는 해당 파일이 없을 수 있는데 그런 경우에는 Merge된 PR을 보면서 센스를 잘 발휘하여 작성하면 된다.
저장소 포크하기 🛒
당연한 이야기지만 이슈를 배정받았다고 신나서 git clone으로 원본 저장소를 가져와 작업을 하고 git push 하면 안된다. 작업을 시작하기 위해서는 저장소를 Fork 해야한다.
작업하기 🔥
Fork한 Repository를 git clone 명령으로 로컬로 가져온 후에 적당한 이름의 branch를 지어주자. 거의 모든 경우 README.md에 개발환경을 구축하는 가이드라인이 있으니 잘 읽어보면서 프로젝트를 빌드한 후에 작업에 착수하면 된다.
빌드 과정에서 잘 안되는 부분이 있다면 멤버들에게 질문해도 좋다. 또한 도중에 버그나 수정사항을 발견할 경우 이를 이슈로 생성한다면 정말 좋은 경험이 되기도 한다.
나같은 경우는 API 코드를 리팩토링하는 이슈를 배정받고 개발 환경을 세팅했는데 서버를 띄워보니 Not Found가 떠서 세팅 과정에서 문제가 있는줄 알고 혼란을 겪었던 경험이 있다.
이는 알고보니 / 경로에 연결된 핸들러가 없었기 때문이었다.
이런 경우는 이슈를 생성함과 동시에 조심스럽게 Assign을 요청할 수도 있다.
Pull Request 생성하기 🤝
작업을 마쳤다면 PR을 생성해보자. PR을 생성하면 멤버들이 만들어둔 양식이 있으니 이에 맞춰서 작성해주면 된다. 만약 양식이 없더라도 내가 진행한 작업개요와 이슈 번호를 작성하는건 절대 잊지말자!
PR을 생성하면 멤버들의 코드 리뷰가 이행될 때까지 기다려야한다. 자꾸만 새로고침을 누르게 된다. (사실 이 순간이 가장 힘든 부분이다)
수정할 사항이 없다면 고맙다는 인사와 함께 Merge 되겠지만 아래처럼 수정사항이 생길 수도 있다.
질문이나 토론이 필요하다면 해도 되고, 수정사항이 생기면 진행상황을 공유해주며 Merge를 기다리면 된다.
야나두 Contributor ! 🥳
멤버들의 코드 리뷰가 끝나면 드디어 나의 코드가 오리지널 저장소의 일부분으로 병합이 되면서 프로젝트의 Contributor로 기록된다.
마치며 🤗
이렇게 오픈소스에 기여하는 과정을 살펴보았다. 사람마다 오픈소스에 기여하는 이유는 모두 다르다.
나같은 경우에도 처음에는 오직 성장을 위해서 시작했지만 몇차례 해보니 성취감이나 보람을 느끼는 부분이 더 크게 작용하는 거 같다.
다른 무엇보다도 Approve와 동시에 달리는 멤버들의 감사인사는 정말 소중하다. 여러분들도 이 느낌을 꼭 경험해봤으면 한다.

꼼수로 오픈소스 기여하기

댓글