오픈소스 세계로 전생: PR 하나 날렸을 뿐인데

2. 자기소개
• 강시온
• Intern @ Lablup
• Github @Yaminyam
• 액션가면
2
안녕하세요 오픈소스 세계로 전생이라는 주제로 발표하게된 래블업 인턴 강시온 입니다.
야미냠이라는 이름으로 여러곳에서 활동하고 있고 최근에는 Github Actions를 주로 다루고 있어 주변 사람들에게 액션가면이라는 별명으로 불리고 있습니다 ㅋㅋ
그럼 발표 시작 하겠습니다!

3. 오픈소스 세계로 전생
강시온
저는 굉장히 실력이 부족한 초보 주니어 개발자 입니다.
막막하기만한 오픈소스에 제가 어떻게 기여 할 수 있었을까요.
저는 오늘 초보 개발자도 오픈소스에 기여 할 수 있었던 방법들에 대해서 이야기 해보려고 합니다.

4. 오픈소스 진입장벽 뚫어보기
코드로 기여하는 것만이 기여가 아니다
많은 분들은 처음 오픈소스에 입문하는것을 어려워합니다.
하지만 처음이 어렵지 한번 익히게 되면 자연스럽게 물 흐르듯이 여러곳에 기여하게 되는 자신을 발견하게 됩니다.
그래서 처음 오픈소스에 기여할때 알아두면 좋은것들과 어떻게 기여할 수 있는지들에 대해서 말씀드리려고 합니다.

5. 오픈소스 한 발 내딛기
주변에서부터 찾아보기
1. 사용하는 프로그램 혹은 라이브러리에서 찾기
2. 스스로 불편한 점을 겪고 있는 것에서 찾아보기
3. 큰 프로젝트부터 시작하지 않기
5
1. 사용하는 프로그램 혹은 라이브러리에서 찾기
관심이 있거나 사용하는 라이브러리에 기여하자
-> 관심이 없는 라이브러리는 쉽게 흥미가 떨어지고, 지친다.
2. 스스로 불편한 점을 겪고 있는 것에서 찾아보기
사용하는 것에서 스스로 불편하다고 느끼는 것을 고쳐보자
-> 내가 불편하면 의욕을 가지고 고치게 됨
3. 큰 프로젝트부터 시작하지 않기
너무 큰 프로젝트는 구조 파악부터 오래 걸린다
실제로 수일 ~ 수주가 걸릴 수 있고, 기여를 시작하려다 지칠 수도 있습니다.
이러한 이유 때문에 작은 라이브러리부터 기여하는 것을 추천합니다.
작은 프로젝트가 도움이 필요한 경우가 더 많습니다.
시작한지 얼마 안 된 프로젝트들을 기여자도 적기 때문에, 더 많은 도움을 필요로합니다.
이렇게 작은 프로젝트는 프로젝트 파악도 비교적 쉽고, 시작하기도 쉽다.
그렇기 때문에, 나는 작은 프로젝트라도 흥미를 느낄 수 있는 프로젝트라면 기여를 시작하는 것을 추천한다.
>> 사실 이 내용들은 제가 작성은 내용들은 아닙니다 ㅋㅋㅋ 인터넷에서 많이 들었고 어디선가에서 들었던 내용들인데 굉장히 공감되는 내용도 있지만 좀 더 초보 개발자의 관점에서 그리고 실제
기여하는 관점에서 볼때 저는 동의하지 않는 부분들도 있어서 그 이야기를 좀 더 첨언해보겠습니다
먼저 2. 스스로 불편한 점을 겪고 있는 것에서 찾아보기 저는 이게 오픈소스 입문하는 사람 입장에서 굉장히 어려운 일이라고 생각합니다.
왜냐면 초보 개발자들은 단순한 기능들을 많이 사용할텐데 초보 개발자가 느낄정도로 있는 오류인데 아직도 안고쳐졌다? 그렇다면 그냥 유지보수를 포기한거거나 아니면 이미 수정된 PR이 올라와

6. 있을 가능성이 큽니다. 예를 들어 저는 nodejs 백엔드 개발을 메인으로 하는데 nodejs 개발자분들은 아시겠지만 express-generator라는 패키지가 있습니다. express로 백엔드를 만드는 템플릿
을 만들어주는데 해당 레포로 프로젝트를 생성하면 충격적이게도 2022년에 아직도 변수를 var 로 선언하고 있습니다. 이걸 고쳐보려고 했으나 이미 해당 문제는 2017년에 언급됐던 이슈고 수정하
는 pr이 올라왔지만 아직까지도 방치되고 있습니다. 스스로 불편한점을 고치면서 오픈소스에 기여하는것이 굉장히 좋은 오픈소스 기여지만 이런 경험을 하기는 쉽지 않다고 생각됩니다. 특히 초보
개발자에게는 말이죠.

7. 오픈소스 기여시 주의 할 점
• 기다림은 필수
• 가이드라인 준수
• 좌절하지 않기
6
기다림은 필수
대부분의 오픈소스 maintainer는 자신의 본업이 있기 때문에, Review부터 Merge까지 몇달이 걸리는 경우도 있다.
가이드라인 준수
CONTRIBUTING.md 같은 파일의 가이드라인을 확인하고 준수하자
보통 이 파일에 아래의 사진과 같이 PR, Issue 등의 기여를 하는 방법이 적혀있다. 꼭 확인하고 안내된 방법을 따르자.
좌절하지 않기
코드에 문제가 있거나 이런 저런 이유 때문에, PR이 Merge되지 않는 경우도 있음
그렇다해도, 오픈소스 기여를 위한 시도 자체도 의미가 있는 행위니까 좌절하지 말자.
스스로 배운 것도 있을 것이다. 긍정적으로 생각하자.
>>> 해당페이지에서도 가이드라인 준수 파트에 대해서 한가지 첨언을 하려고 합니다.
가이드라인 준수에 관련된 내용도 굉장히 많이 언급되는 부분 중 하나인데 물론 가이드라인을 준수하는것 중요합니다.
하지만 이러한 가이드라인에 대해서 공부하고 실수할까봐 겁이나서 기여를 포기하게 되는경우도 굉장히 많습니다.
그렇기에 저는 가이드라인을 준수하는것은 중요하지만 실수하더라도 메인테이너들이 친철하게 어떻게 수정해야한다고 알려줍니다.
왜냐면 메인테이너에서는 새로운 기여자는 언제나 환영하거든요.
그래서 꼭 완벽한 PR을 올리지 않아도 됩니다.
내가 작업을 진행하고 PR을 올려둔상태로 이런이런 문제가 있어서 도움을 요청한다고 해서 다른 개발자들과 협업하여 하나의 문제를 해결해 나가는것도 오픈소스의 큰 묘미 거든요.

8. 오픈소스 기여 팁
강시온
지금까지는 흔히 많이 듣던 이야기였죠? 이제부터는 제가 실제로 오픈소스에 기여하면서 얻은 다른곳들에서는 들을수없던 저만의 경험들을 이야기해보면서 오픈소스의 블루오션이라고 해야할까
요? ㅎㅎ 제가 이용하고 있는 팁들을 이야기해보려고 합니다.

9. Good First Issue
8
첫번째는 Good First Issue 입니다.
오픈소스에는 Good First Issue 라는 문화가 있는데, 레포지토리에 생성된 issue 중 처음 해당 프로젝트에 기여하는 사람이 해볼만한 쉬운 이슈를 제공해주는 문화입니다.
Good First Issue를 해결하면서 프로젝트를 파악해보고 사용해보고 기여하는 과정을 파악 할 수 있는 좋은 기회가 됩니다.
그리고 이는 다들 오픈소스를 입문 할 때 큰 레포를 선택하지 말라고 이야기하는 이유 중 하나 입니다.
프로젝트가 안정된 큰 레포에서는 이미 해결하기 쉬운 문제들은 다 해결된 경우가 많고 그리고 기여자도 많이 때문에 쉬운 이슈가 생기더라도 이를 낚아채기 쉽지 않습니다.
그래서 본인이 담당해보고 싶은 이슈가 있다면 부끄러워하지 않고 이슈에 빠르게 내가 이 이슈를 담당해보고 싶다고 comment를 남기는게 좋습니다.
오픈소스 굉장히 깐깐한 분들이 관리하실것 같지만 수많은 기여자들을 만나온 메인테이너들은 생각보다 굉장히 친절하게 대해주십니다.

10. 코드만이 기여가 아니다
9
두번째는 코드만이 기여가 아니다 입니다.
오픈소스에 기여하려면 꼭 엄청난 코드를 작성해야 할 것 같지만 그렇지도 않습니다.
문서화나 번역에 기여 할 수도 있고 테스팅에 기여 할 수도 있습니다.
매년 10월마다 전세계적으로 열리는 오픈소스 행사인 핵토버페스트 2022에서도 올해에는 로우코드, 노코드 참여를 공식적으로 강조하고 있습니다.

11. 코드만이 기여가 아니다
10
실제로 깃허브의 star 가 많은 레포들을 보면 개발 프로젝트보다 정보공유를 위한 레포들이 많습니다.
저도 그래서 이번 hacktoberfest 2022에 Rank 6번에 있는 developer-roadmap 이라는 레포지토리에 nodejs 관련 정보들을 추가하면서 참가 했습니다.

12. Github 파헤치기
• issue
• review
• actions
• security
11
세번째는 깃허브 파헤치기 입니다.
오픈소스 == 깃허브는 아니지만 대부분의 오픈소스는 깃허브에서 운영되니다.
대표적으로 리눅스 같은 프로젝트는 깃허브가 아니라 따로 운영되고 있습니다.
저는 그래서 오픈소스에 익숙해지기 위해선 깃허브에 익숙해지는 것도 굉장히 중요하다고 느꼈습니다.
사실 발표에서 앞에서 이야기한 내용들은 오픈소스 관련 정보를 검색해보면 흔히 접하는 팁들인데 이번 발표는 해당 챕터가 가장 중요한것 같습니다.

13. issue
12
현재 대부분의 소프트웨어는 오픈소스를 포함해서 개발됩니다.
하지만 오픈소스는 비영리적인 목적으로 수많은 사람들에 의해 개발되다보니 완벽하지 않은 경우가 많습니다.
오픈소스에 익숙해지면 내가 여러가지를 사용하다 불편하거나 버그를 발견하면 issue를 제보하는것이 습관이 되었습니다.
해당사진은 제가 자주사용하는 레포지토리인 typeorm의 issue인데, docs의 설명에 빠진 내용이 있어 제보한 내용입니다.
날짜를 보시면 10월 13일인데 아직까지 아무런 답변이 없기는 합니다 ㅋㅋㅋ
아까 말씀드렸었죠? 기다림은 필수 입니다 ㅋㅋㅋ
너무 익숙해지다보니 오픈소스가 아닌 프로그램을 사용하다가도 개선할 사항이나 버그가 보이면 제보하고 싶어지기도 하는것 같습니다 ㅋㅋ.

14. issue
13
그리고 issue라 하면 보통 외부기여자는 버그제보가 대부분이긴 합니다.
하지만 오픈소스인 만큼 메인테이너들 뿐만 아니라 해당 프로젝트는 많은 사람들에 의해 만들어지는 프로젝트입니다.
그렇기에 해당 프로젝트의 발전방향에 의견을 남기는것도 굉장히 큰 기여라 생각됩니다.
물론 개인이 운영하는 프로젝트들이 많은 만큼 보통은 해당 메인테이너의 생각이 매우 크게 반영되긴 하지만 의견을 제시하고 그 의견이 다른 사람들의 많은 동의를 얻는다면 그 의견이 반영되는 경
우도 더러 많습니다.

15. security
14
다음으론 security 입니다.
Github 에는 레포지토리에 Security 탭이 있습니다.
해당 Security에는 dependabot이라는 기능이 있는데 오른쪽 사진과 같이 봇이 해당 레포지토리에서 의존하고 있는 의존성에서 발생 할 수 있는 보안적 이슈를 알려줍니다.
보안적 이슈가 해결된 버전이 업데이트 되었다면 해당 의존성 패키지를 자동으로 업데이트 해주는 기능까지 담당하고 있습니다.

16. security
15
제가 보안에 관심이 많았던것은 아니고 처음 이 기능에 대해 신경쓰지 시작한것은 위의 사진과 같이 레포에서 저 노랑색 알림이 너무 제 신경에 거슬렸기 때문입니다 ㅋㅋㅋ
요즘은 안보이는것 같긴하더라구요? 너무 거슬려서 깃허브에서 지워버린게 아닌가 싶긴합니다 ㅋㅋ
요즘은 dependency graph탭에 들어가야 확인 할 수 있는 알림창 입니다.
보안이슈가 발생하면 다 업데이트 하면 해결되는거 아닌가요? 라고 생각 할 수 있지만 생각보다 저 노락색 알림을 없애는 일은 쉽지 않았습니다.

17. security
16
첫번째 이유는 그냥 해당 보안적 이슈가 아직 해결된 버전이 업데이트 되지 않았을 경우입니다.
잘 관리되는 프로젝트라면 보안적 이슈가 발생하면 대부분 바로 핫픽스되어 새로운 버전이 배포되기 때문에 첫번째 상황은 많이 발생하지 않습니다. 문제는 두번째 이유 입니다.
두번째 이유는 제가 의존하고 있는 패키지에서 또 다시 의존하고 있는 곳에서 발생한 문제는 제 프로젝트의 문제가 아니기 때문에 함부로 버전을 수정 할 수 없습니다.

18. security
17
그렇기 때문에 문제가 되는 레포에 가서 직접 버전을 올리는 PR을 작성하게 되었습니다.
확실히 이런 보안적 이슈까지 까다롭게 신경을 쓰는건 중요한 서비스를 운용하는 회사들 같은 경우 인것 같더라구요.
그래서 ejs, microsoft와 같은 엄청난 분들과 작업하고 있는 듯한 느낌을 받았고 이게 오픈소스 활동에도 큰 동기부여가 됐던것 같습니다.

19. Actions
18
다음으론 Github 에서 제공되는 CI/CD 도구인 Actions에 관한 이야기를 해보려고 합니다.
저는 자동화에 굉장히 관심이 많았고 Actions는 귀찮은 일들을 자동화하는데 매우 유용했습니다.
처음에 소개할때 말씀드린것처럼 제가 요즘 가장 관심가지고 있는 분야이기도 합니다.
Actions를 통한 오픈소스의 기여는 보안적으로 예민한 권한을 가지므로 기여하기 쉽지 않을 수 있습니다.
하지만 Actions 기여의 장점은 프로젝트가 Python이던 Javascript든 공통적으로 필요한 도구들이 많기 때문에 언어에 종속적이지 않고 수많은 프로젝트에 기여 할 수 있다는 점입니다.

20. auto-label-in-issue
19
여러가지 깃허브 파헤치기를 하셨다면 파는도중에 돌맹이가 걸리면서 귀찮게 하는 부분들이 있었을 겁니다.
깃허브를 사용하는데 불편한 점들이죠.
저는 그 중 가장 불편했던게 라벨과 관련된 기능들 이었습니다.
외부기여자를 수용하는 오픈소스의 경우에는 Labels은 메인테이너만 관리할 수 있는 권한을 가지므로 전부 메인테이너가 관리해야합니다.
레포지토리의 규모가 커지고 수많은 이슈들과 PR들이 생기게되면 이것을 관리하는것이 메인테이너에게 굉장히 귀찮은 일이 될 것이라 생각했습니다.
그래서 저는 Issue에 달았던 라벨들을 해당 Issue를 해결한 PR에 똑같이 달아줘야하는 불편함이 있어 이를 해결하기 위한 Actions인 auto-label-in-issue를 개발했습니다.
한 레포에 기여하는 것이 아닌 모든 깃허브 레포지토리에서 활용 될 수 있어 오픈소스에 많은 도움이 될 것이라 생각되었습니다.
오른쪽 qr 링크에서 해당 액션을 확인 하실 수 있습니다.

21. 오픈소스의 벽 부수기
강시온
이렇게 그동안 접해왔던 프로젝트 개발에 참여를 통한 오픈소스 기여뿐만 아니라 여러가지 많은 방법으로 오픈소스에 기여 할 수 있음을 이야기 했습니다. 저는 그 다음단계로 해야할 일은 오픈소스
의 벽을 부수는 일이라고 생각했습니다.
많은 사람들이 오픈소스를 시작하기 굉장히 어려워 합니다. 오픈소스는 많은 사람들이 참여할 수록 발전 할 수 있기에 오픈소스를 어려워 하는 사람들이 더욱 많이 오픈소스 생태계에 참여 할 수 있
도록 벽을 부수는 일이 굉장히 중요하다고 생각되었습니다.

22. 널리 알리기
21
바로 지금 제가 발표하고 있는것과 같이 오픈소스에 관한 내용을 사람들이 관심을 가지도록 해야합니다.
발표중 언급됐던 핵토버페스트, 오픈소스 컨트리뷰션 아카데미등 많은 행사들이 이런 역할을 하고 있다고 생각합니다.
이런 행사에 참가하게 되면 오픈소스에 처음들어오는 신입분들을 매우 친절하게 맞이해주기 위해 마중나와 있는 분들이 많기에 이런 행사를 통해 오픈소스를 입문해 보는것이 굉장히 큰 도움이 될
것 입니다.
오픈소스를 주저하게 되는 가장 큰 이유가 어떻게 시작해야지? 뭘 해야하지? 일텐데 그 문제들을 단기간적인 확실한 목표와 노하우를 가진 선배들이 해결해 준다고 생각합니다.

23. devrank
22
마지막으로는 최근 제가 진행하고 있는 프로젝트를 좀 소개해 보려고 합니다.
제가 오픈소스를 하면서 가장 의욕이 생겼던 부분은 성취감 이었습니다.
최근에 깃허브에 업적시스템이 추가됐는데 이런 소소한 성취감이 저에게 큰 즐거움을 줬던것 같습니다.
이런 성취감을 더 증진시켜 사람들이 더 활발하게 활동 할 수 있도록 하고 싶었습니다.

24. devrank
23
제가 깃허브를 파헤치면서 얻었던 정보들을 바탕으로 깃허브에서 할 수 있는 활동들을 다음과 같은 수식을 통해 점수화 하고자 하고 있습니다.
최대한 여러가지 활동들을 종합적으로 활용하려고 하고있습니다.

25. 마치며
24
@Yaminyam
이렇게 코드 기여부터 시작해서 깃허브 밖에서 오픈소스에 기여 할 수 있는 방법까지 나와봤습니다.
최대한 흔하게 들을 수 있는 이야기 보다는 제 개인적으로 경험했던 특별한 경험들을 위주로 이야기 해봤습니다.
이렇게 다들 본인이 관심있고 잘 할 수 있는 영역에서 오픈소스에 기여 할 수 있다는 이야기를 하고 싶었습니다.
다들 오픈소스 많이많이 관심 가져주시고 auto-label-in-issue도 많이 사용부탁드립니다 ㅎㅎ
커피챗 언제든 환영하니 편하게 위 깃허브 계정에서 연락주시면 환영합니다 ㅎㅎ
발표 들어주셔서 감사합니다!!