오픈소스는 코드에 관한 것이라 생각했지만, 내가 틀렸다.
Source: Dev.to
내가 오픈소스 기여를 통해 배운 가장 큰 교훈은 코드 자체에서 찾은 것이 아니었다. 커뮤니케이션, 협업, 그리고 워크플로우가 내가 생각했던 것보다 훨씬 더 중요했다.
어느 정도는 내가 기여한다는 것이 코드를 작성하는 것이라고 가정했기 때문이었다. 독학 개발자로서 그 생각은 위압감을 주었다. 또 다른 이유는 “Git 불안감”이었다. 포크, 브랜치, 풀 리퀘스트, 머지 충돌, CI 체크 등은 기여를 시작하기 전에 이해해야 할 것들이 너무 많아 보였다.
결국 나는 작은 것부터 시작했다. 코드를 고집하기보다 문서, README 파일, 학습 자료를 개선할 기회를 찾았다. 놀랍게도 실제 변경 사항을 작성하는 것이 가장 쉬운 부분인 경우가 많았다.
대부분의 학습은 코드 밖에서 이루어졌다: 기여 가이드라인, 저장소 워크플로우, 자동화, 리뷰 기대치 등을 이해하는 과정이었다. 시간이 지나면서 현대 오픈소스 기여는 단순히 코드를 쓰는 것 이상이라는 것을 깨달았다.
많은 사람들이 오픈소스 기여를 생각할 때 여전히 매우 단순한 모델을 떠올린다:
버그 찾기 ↓ 코드 작성 ↓ PR 열기실제로는 대부분의 최신 저장소가 그보다 훨씬 복잡하다.
변경을 하기 전에 기여자는 프로젝트 워크플로우, CI 파이프라인, 자동화 체크, 기여 가이드라인, 리뷰 기대치를 이해해야 한다. 코드 자체는 몇 분이면 끝날 수 있지만, 저장소가 어떻게 운영되는지를 파악하는 데는 훨씬 더 오래 걸린다.
현대적인 기여 흐름은 대략 다음과 같다:
저장소 이해 ↓ 워크플로우 이해 ↓ 자동화 이해 ↓ 변경 사항 적용 ↓ PR 열기 ↓ 리뷰에 답변겁이 날 수도 있지만, 이 흐름이 커뮤니케이션이 늘어날수록 프로젝트를 유지 보수 가능하게 만든다.
여러 프로젝트에 기여하면서 깨달은 점은 오픈소스가 단순히 코딩 스킬만을 요구하지 않는다는 것이다. 프로젝트가 어떻게 동작하는지를 빠르게 파악할수록, 사용 기술 스택과 무관하게 기여가 쉬워진다.
대부분의 저장소는 기여 프로세스를 잘 문서화한다. README, CONTRIBUTING 가이드, 이슈 템플릿, PR 템플릿 등이 기본적인 절차를 설명한다.
하지만 내가 더 오래 걸려 이해한 부분은 하나의 문서에 담기지 않는 기대치들이다. 예를 들어, 유지관리자는 작은 PR을 선호할 수 있지만 명시적으로 언급하지 않을 수도 있다. 어떤 저장소는 기능 기여를 받지만 최근 활동을 보면 문서 개선이 더 빠르게 리뷰되는 경우가 있다. 일부 프로젝트는 PR을 열기 전에 아이디어를 논의하길 원하고, 다른 프로젝트는 바로 변경을 제출하길 바란다.
자동화 역시 기대치를 전달한다. GitHub Actions, CI 파이프라인, pre‑commit 훅은 단순히 코드를 검증하는 것이 아니라 프로젝트가 중요하게 여기는 것을 보여준다. 포맷팅 규칙, 테스트 커버리지, 커밋 규칙, 품질 체크 등이 자동으로 강제되는 경우가 많다.
시간이 지나면서 나는 단일 ‘진실의 원천’을 찾으려 하지 않게 되었다. 대신 저장소를 여러 신호들의 집합으로 보게 되었다. 공식 문서는 절차를 알려주고, 워크플로우, 자동화, 최근 PR들은 실제 일상적인 운영 방식을 보여준다.
내가 GitHub를 처음 사용했을 때 사람들은 주로 Git을 배우는 데 집중했다. 하지만 되돌아보면 Git 자체가 가장 어려운 부분은 아니었다.
동시에 여러 시스템을 익혀야 했기 때문이다:
GitGitHub- CI 파이프라인
- 자동화 체크
- 코드 리뷰 워크플로우 등
간단한 문서 수정이라도 포크를 만들고, PR을 열고, 자동화 체크를 통과시키고, 리뷰 피드백에 답해야 한다. 변경 자체는 작아도 과정이 처음엔 압도적으로 느껴질 수 있다.
CI 체크가 실패하거나, (요즘은 AI가) 수정 요청을 받거나, 아이디어가 거절된다고 해서 오픈소스에 어울리지 않는다는 뜻은 아니다. 이는 협업 소프트웨어 개발의 일부분일 뿐이다.
기여를 시험이 아니라 학습 과정으로 바라보기 시작하니 오픈소스가 훨씬 덜 위협적으로 느껴졌다.
크고 작은 여러 프로젝트에 기여하면서, 이슈나 PR을 열기 전에 확인하는 간단한 체크리스트를 만들었다.
- 프로젝트가 활발히 유지 관리되고 있는가?
- 어떤 종류의 기여를 환영하는가?
- 최근 PR은 어떻게 리뷰되는가?
- CI 체크와 자동화는 무엇을 강제하는가?
- 기여 가이드라인이나 코딩 표준이 있는가?
- 유지관리자가 선호하는 기여 패턴은 무엇인가?
이 질문들은 깊은 기술 지식을 요구하지 않지만, 많은 시간과 혼란을 줄여준다.
저장소를 이해하는 데 최소 10~20분 정도 투자하면, 바로 변경을 시도하거나 제안하는 것보다 훨씬 부드러운 기여 경험을 얻을 수 있다.
모든 오픈소스 프로젝트는 다르고 다양하지만, 여러 저장소에 기여해 보니 많은 프로젝트가 겉으로는 다르지만 공통된 패턴을 가지고 있다는 것을 알게 되었다.
물론 코드는 여전히 중요하다. 하지만 성공적인 기여는 워크플로우, 자동화, 협업 문화, 커뮤니케이션 스킬을 이해하는 것만큼이나 중요하다. 명확한 주석을 달고, 토론에 참여하며, 강력한 소프트 스킬을 키우는 것이 유지관리자와 다른 기여자와 효과적으로 작업하는 데 코딩만큼이나 큰 역할을 한다.
나에게 오픈소스에서 얻은 가장 큰 교훈 중 하나는 기여가 단순히 코드를 작성하는 것이 아니라, 커뮤니티 안에서 효과적으로 일하는 방법을 배우는 과정이라는 점이다. 저장소를 그런 시각으로 바라보니 기여가 훨씬 덜 위협적이고, 더 큰 보람을 느낄 수 있었다.
지속 가능한 오픈소스 습관을 만들고 싶다면, 나는 “하루에 한 커밋” 챌린지를 통해 나만의 여정을 기록하고 있다. 목표는 매일 거대한 기여를 하는 것이 아니라, 꾸준히 참여하고 배우며, 점차 오픈소스 프로젝트와 커뮤니티에 익숙해지는 것이다.