OSSCA에 합격하다!
OSSCA(Open Source SW Contribution Academy)란 초급 개발자가 멘토와 함께 오픈소스 프로젝트에 직접 기여할 수 있도록 도와주는 멘토링 프로그램이다.
오픈소스 기여에 관심이 있었기도 했고 좋은 기회라고 생각되어 바로 지원했고, 운 좋게 선발될 수 있었다. (게다가 전 과정이 무료임!)
참고: https://www.contribution.ac
발대식 참석
7월 12일에 발대식이 있어서 참석하고 왔다.
맛있는 커피와 과자도 주시고 드론으로 문어 뽑기 등의 이벤트들도 있었다. (문어가 탐났지만 아쉽게 못 뽑았다ㅠ)
생각보다 규모가 컸고 주최 측에서 많이 신경써주신게 느껴져서 좋았다.
초청 강연 1 - OpenStack Global Maintainer
행사의 첫 순서는 OpenStack의 메인테이너 Kendall Nelson 님이었다. 오픈소스에 대한 애정과 열의가 느껴진 강연이었다.
초청 강연 2 - 국내 Top 개발자의 경험 및 조언
이어 OSSCA 과정 소개가 끝나고, 개발자 방진호님이 강연을 해주셨다. 오픈소스 기여에 처음 입문하는 나 같은 사람에게 정말 좋은 내용이었다. 수 년 전부터 OSSCA에 참여해오셨다는데, 확실히 내공이 대단하시다고 느껴졌다.
1. 목표 설정
구체적이고 달성 가능한 목표를 세워라
Bad
- 1개월 동안 열심히 해야지 (추상적)
- 다음 달에 당장 커미터가 돼야지 (무리수)
- 이번엔 공부 좀 하고, 내년부터 기여해야지 (미루기)
Good
- 3개월 동안 매주 패치 2개씩 올려야지 (구체적)
- 1개월은 쉬운 패치 10개, 2개월은 어려운 패치 5개 (현실적)
- 7월 31일까지는 첫 패치를 완료해야지 (데드라인 설정)
2. 오픈소스 개발 프로세스
- 검색이나 LLM보다, "공식 문서" 정독하기
- 빌드, 테스트, Git 등 개발 도구 사용법에 능숙해지기
- 이슈 트래커, 패치 관리, 코드 리뷰, 브랜치 관리 등 정책과 프로세스 이해하기
- 코딩 스타일 가이드를 직접 읽어보기 (lint나 formatter를 사용하더라도)
3. 작은 문제부터 해결
작고 간단한 문제를 반복적으로 해결하라
-> 오탈자 수정, 문서 기여도 충분히 훌륭함
-> 대부분의 오픈소스는 Good First Issue 목록을 제공
오픈소스 참여가 어려운 이유
- 방대한 코드 베이스와 빠른 변경
- 책, 강의, 검색으로 지식 습득이 어려움 => 이에 따라 "코드 읽기"가 중요해짐
- 학교/회사와는 달리, 자발적인 참여를 통한 맥락 파악이 중요
- 기술적 어려움보다 환경적 어려움
간단한 패치(Trivial Patch)를 반복해서 얻을 수 있는 것들
- 오픈소스 개발 프로세스 및 정책에 대한 학습
- 빌드 및 테스트 실행
- 이슈 트래커 관리
- 패치 작성
- 테스트 작성
- 코드 리뷰 요청
- 오픈소스에 꾸준히 기여하기 위한 습관
4. 코드 작성
항상 "소통하기 쉬운 코드"를 작성하기 위해 최선을 다하라
= "가독성이 좋은 코드"
최고의 소통 수단
- 그것은 바로 "코드 그 자체"
- 코드는 유일한 자산이다.
- 코드는 가장 완벽한 문서다.
가독성 좋은 코드 작성 방법
- 참여하는 프로젝트의 정해진 룰을 최대한 준수
- lint, formatter 등의 도구 적극 활용
- 지구 반대편 사람과 협업하더라도 한 사람이 짠 것 같은 일관성 유지
- 내 기준이 아닌 남을 배려하는 코드 작성
5. 커밋 메시지 작성
커밋 메시지를 "코드의 일부"로 취급하라
-> 코드 작성만큼이나 공들여라
-> 코드와 마찬가지로 남을 배려하는 메시지를 작성하라
생각보다 많은 사람들이 커밋 메시지의 중요성을 간과한다.
심지어는 유명 오픈소스에서도!
커밋 메시지의 중요성
- 코드 변경의 이유를 기록하고 관리할 수 있는 유일한 방법
- 디버깅, 코드 리뷰, 히스토리/맥락 파악, 소통 등 협업에 아주 큰 도움
- 프로젝트의 역사와 맥락을 담고 있는 일종의 설계 문서
- 과거에는 CHANGELOG 파일을 작성 => 즉 커밋 메시지는 코드의 일부
커밋 메시지 잘 작성하기
- 기본적으로 프로젝트에서 가이드하는 형식을 따르자
- HOW보다는 WHAT과 WHY를 작성
- 제목은 전체 내용을 함축적으로 요약해야 한다
- 내 기준이 아니라 "코드"를 기준으로 작성
6. 코드 리뷰
불쌍한 리뷰어를 배려하는 패치를 작성하라
-> "더 작은" 패치 작성하기
-> 커밋 메시지 잘 작성하기
-> 사전 점검 충분히 하기
검사받는 "일방적" 과정이 아니라, 더 나은 코드를 위한 "상호 협업" 과정이다.
리뷰어 관점에서 생각해보기
- 인지 부하: 리뷰어는 당신의 코드를 모름. 방대한 코드는 이해하기 어렵다.
- 맥락 전환: 리뷰를 위한 Context Switching 비용은 생각보다 크다.
- 책임감과 부담감: 버그를 놓치면 안된다는 심리적 압박감이 있다.
작은 패치로 분할했을 때의 장점
- 더 빠르고 꼼꼼하게 검토할 수 있다.
- 전반적인 버그 발생 가능성이 줄어든다.
- 설계가 더 쉬워지고, 방향이 잘못되더라도 낭비되는 작업량이 줄어든다.
- 문제 발생 시 Revert가 간단해진다.
효율적으로 패치 분할하는 법
- 먼저 인터페이스 수준의 "스켈레톤 코드" 구현하기
- 이후 개별 서브 기능을 구현하기
7. 테스트 작성
모든 변경사항에 대해 반드시 관련 테스트를 포함하라
-> 테스트는 항상 "변경사항과 함께" 작성하는 것이고, 별도로 작성하는 것이 아니다.
-> TDD든 뭐든 상관 없다.
왜 테스트가 중요한가?
- 지구 반대편 기여자까지도 신뢰할 수 있게 하는 힘
- 테스트는 구현 코드가 어떻게 동작하는지 설명하는 명세서다.
- 코드 변경 시 의도치 않은 버그를 방지할 수 있는 안전망 역할을 한다.
- QA 대신 품질을 보장하는 오픈소스의 테스트와 CI/CD
8. 멘토 활용하기
멘토를 최대한
괴롭혀라활용하라
그래도 이건 금지
- 멘토님을 지나치게 배려한 나머지 아무런 질문도 안하기
- 앞뒤 설명 없이, 구체적 맥락 없이 냅다 질문 던지기
- 문제 하나를 내내 붙들고 있기
- 아무런 연락 없이 잠수타기
9. 시간 투자의 필요성
일주일에 4일은 최소 4시간이상 투자하라
- 최대한 연속된 시간(4시간 이상)을 사용하라
- 주말에 몰아서 하지 말고 꾸준히
- 짜투리 시간에는 집중 안해도 되는 것을 진행
10. 끝이 아니라 다시 시작
OSSCA가 끝나도 오픈소스에 꾸준히 기여하라
끝나고 난 뒤가 진짜 오픈소스 개발자 탄생의 시간입니다!
마치며
이제 막 오픈소스 기여의 여정을 시작한 초보 입장에서 의지가 샘솟기 시작한 시간이었다. OSSCA를 꼭 완주하여 거대한 오픈소스 생태계에 작은 발자국 하나를 남기고 싶다.
