오픈 소스 기여

처음엔 무서웠습니다

오픈 소스 기여라는 말을 처음 들었을 때, 솔직히 말하면 겁이 났습니다. GitHub에서 유명한 프로젝트들을 보면 전 세계 개발자들이 영어로 토론하고, 복잡한 코드를 주고받고, 뭔가 엄청나게 전문적인 일을 하는 것처럼 보였거든요. "나 같은 초보가 끼어들 자리가 있을까?" 하는 생각이 먼저 들었습니다.

그런데 제 서비스를 만들면서 이런 일이 생겼습니다. 어떤 라이브러리를 쓰는데 문서에 오타가 있더라고요. 영어 문서인데 "teh"라고 써있는 걸 발견했습니다. 명백한 오타였죠. "the"여야 하는데 말이죠. 그 순간 "아, 이 정도는 나도 고칠 수 있겠는데?"라는 생각이 들었습니다.

그게 제 첫 오픈 소스 기여의 시작이었습니다. 오타 하나 고치는 거였지만, 그 경험을 통해 오픈 소스 기여가 생각보다 훨씬 접근 가능한 일이라는 걸 깨달았습니다.

오픈 소스는 공짜 코드가 아니었습니다

처음엔 오픈 소스를 그냥 "무료로 쓸 수 있는 코드"라고만 생각했습니다. 필요한 라이브러리 찾아서 npm install 하고, 문서 보고 따라 쓰면 되는 거라고요. 그런데 직접 기여를 시작하면서 보니까, 오픈 소스는 단순히 코드가 아니라 살아있는 커뮤니티였습니다.

누군가 버그를 발견하면 이슈를 올리고, 다른 누군가는 그걸 재현해보고, 또 다른 사람은 해결 방법을 제안하고, 메인테이너는 그걸 검토해서 머지하고. 이 모든 과정이 공개적으로, 투명하게 진행됩니다. 마치 거대한 집단 지성이 작동하는 걸 보는 것 같았습니다.

그리고 깨달았습니다. 내가 매일 쓰는 React, Next.js, TypeScript 같은 도구들이 모두 이런 과정을 거쳐서 만들어진 거라는 걸요. 수천, 수만 명의 개발자들이 조금씩 기여해서 지금의 모습이 된 겁니다. 그 사실을 이해하고 나니, 오픈 소스에 대한 시각이 완전히 바뀌었습니다.

첫 번째 진짜 기여 - 문서 개선

오타 수정 이후로 용기를 얻어서, 조금 더 의미 있는 기여를 해보고 싶었습니다. 그래서 제가 자주 쓰는 라이브러리의 문서를 꼼꼼히 읽어봤습니다. 그런데 이상한 점을 발견했어요. 어떤 기능에 대한 설명은 있는데, 실제 사용 예제가 없는 겁니다.

저도 그 기능을 쓰면서 삽질했던 기억이 있었습니다. 설명만 읽어서는 어떻게 써야 할지 감이 안 와서, 결국 GitHub Issues를 뒤져서 다른 사람들이 올린 코드를 보고 이해했거든요. "아, 이거 예제 하나만 있었어도 훨씬 쉬웠을 텐데"라고 생각했던 기억이 났습니다.

그래서 제가 직접 쓴 코드를 바탕으로 예제를 만들어서 PR을 올렸습니다. 이렇게요:

// 기존 문서: 설명만 있음
// "useCustomHook accepts options parameter"

// 제가 추가한 예제
import { useCustomHook } from 'library';

function MyComponent() {
  const { data, loading } = useCustomHook({
    enabled: true,
    refetchInterval: 5000
  });
  
  if (loading) return <div>Loading...</div>;
  return <div>{data}</div>;
}

며칠 후에 메인테이너가 댓글을 달았습니다. "Great addition! This will help many users." 그리고 머지되었습니다. 그 순간의 기분이란... 제 코드가 전 세계 개발자들이 보는 공식 문서에 들어간다는 게 믿기지 않았습니다.

버그 수정 - 진짜 코드를 만지다

문서 기여로 자신감이 붙어서, 이번엔 실제 코드를 고쳐보고 싶었습니다. 마침 제 서비스에서 쓰는 라이브러리에 작은 버그가 있었습니다. 특정 조건에서 에러가 나는 건데, 재현 조건이 명확했습니다.

먼저 GitHub Issues에서 같은 문제를 겪는 사람이 있는지 찾아봤습니다. 있더라고요! 누군가 이미 이슈를 올려놨는데, 아직 해결되지 않은 상태였습니다. 그래서 그 이슈에 댓글을 달았습니다. "I can reproduce this. Let me try to fix it."

프로젝트를 포크하고, 로컬에서 클론하고, 개발 환경을 세팅하는 과정이 처음엔 복잡했습니다. 각 프로젝트마다 CONTRIBUTING.md 파일이 있는데, 거기에 개발 환경 세팅 방법이 나와 있더라고요. 그걸 따라 하니까 됐습니다.

버그를 재현하고, 원인을 찾고, 수정하는 과정은... 솔직히 말하면 제 실력으로는 벅찼습니다. 하지만 기존 코드를 읽으면서 엄청나게 많이 배웠습니다. "아, 이런 식으로 에러 핸들링을 하는구나", "이렇게 타입을 정의하면 안전하겠네" 같은 걸요.

결국 수정을 완료하고 PR을 올렸습니다. 메인테이너가 코드 리뷰를 해주면서 몇 가지 개선 사항을 제안했고, 저는 그걸 반영해서 다시 푸시했습니다. 이 과정에서 프로덕션 레벨의 코드 리뷰를 직접 경험할 수 있었습니다. 회사에서 일하는 것도 아닌데, 이렇게 고급 개발자들에게 피드백을 받을 수 있다는 게 놀라웠습니다.

기여하면서 배운 것들

오픈 소스 기여를 하면서 가장 크게 얻은 건 경험이었습니다. 책이나 강의에서는 배울 수 없는 것들이었죠.

1. 코드 읽는 법

다른 사람의 코드를 읽는 게 처음엔 정말 어려웠습니다. 특히 큰 프로젝트는 파일이 수백 개가 넘고, 구조도 복잡하고. 그런데 계속 읽다 보니까 패턴이 보이기 시작했습니다. "아, 이 프로젝트는 이런 식으로 폴더를 구성하는구나", "에러 처리는 이렇게 하는구나" 같은 거요.

실제로 유명한 오픈 소스 프로젝트들의 코드를 보면, 제가 혼자 짤 때는 생각도 못 했던 패턴들이 많이 나옵니다. 그걸 보면서 "아, 이게 베스트 프랙티스구나"라고 배우게 됩니다.

2. 커뮤니케이션

영어로 이슈를 쓰고, PR 설명을 작성하고, 코드 리뷰 댓글에 답하는 게 처음엔 부담스러웠습니다. 하지만 계속하다 보니 요령이 생기더라고요.

좋은 PR은 이렇게 생겼다는 걸 배웠습니다:

## Problem
Users get error when calling API with empty array

## Solution
Added validation check before API call:
- Return early if array is empty
- Show user-friendly error message

## Testing
- Added unit test for empty array case
- Tested manually in development environment
- All existing tests still pass

간결하게, 명확하게, 그리고 왜 이 변경이 필요한지를 설명하는 게 중요했습니다.

3. 협업 프로세스

오픈 소스 프로젝트들은 대부분 명확한 워크플로우가 있습니다. 이슈 템플릿, PR 템플릿, 코드 리뷰 프로세스, CI/CD 파이프라인 등등. 이런 걸 직접 경험하면서, "아, 실제 개발 현장에서는 이렇게 일하는구나"를 배웠습니다.

특히 인상 깊었던 건 자동화였습니다. PR을 올리면 자동으로 테스트가 돌아가고, 린트 체크가 되고, 빌드가 되고. 이 모든 게 GitHub Actions나 다른 CI 도구로 자동화되어 있더라고요. 그걸 보고 제 프로젝트에도 적용했습니다.

작게 시작하세요

제 경험을 돌이켜보면, 오픈 소스 기여는 작게 시작하는 게 핵심입니다. 처음부터 복잡한 기능을 추가하려고 하면 압도당합니다. 대신 이렇게 시작해보세요:

1단계: 문서 읽으면서 오타 찾기

• 진짜로 오타가 많습니다
• 영어 문서라도 오타는 누구나 찾을 수 있습니다
• PR 하나 올려보는 경험이 중요합니다

2단계: 예제 추가하기

• 본인이 쓰면서 헷갈렸던 부분
• 문서에 설명은 있는데 예제가 없는 부분
• 실제로 쓴 코드를 정리해서 올리면 됩니다

3단계: 작은 버그 수정

• "good first issue" 라벨이 붙은 이슈 찾기
• 본인이 직접 겪은 버그 고치기
• 테스트 코드 추가하기

4단계: 기능 추가

• 이건 좀 더 경험이 쌓인 후에
• 먼저 이슈나 디스커션에서 논의하기
• 메인테이너의 방향성과 맞는지 확인하기

실패도 배움입니다

모든 PR이 머지되는 건 아닙니다. 제가 올린 PR 중에도 거절당한 게 있습니다. 처음엔 좀 속상했는데, 메인테이너의 설명을 읽어보니 이해가 됐습니다. "이 기능은 프로젝트의 방향성과 맞지 않습니다", "이미 다른 방식으로 해결할 수 있습니다" 같은 이유였죠.

그것도 배움이었습니다. 오픈 소스 프로젝트는 명확한 비전과 방향성이 있고, 모든 기여가 그 방향과 맞아야 한다는 걸요. 그래서 기여하기 전에 프로젝트의 로드맵이나 이슈 디스커션을 먼저 확인하는 게 중요합니다.

한 줄 요약

오픈 소스 기여는 오타 수정 같은 작은 것부터 시작해서, 문서 개선, 버그 수정, 기능 추가로 확장해나가는 과정입니다. 처음엔 무섭지만, 한 번 시작하면 경험과 커뮤니티 네트워킹을 동시에 얻을 수 있는 최고의 학습 방법이라는 걸 깨달았습니다. 그리고 무엇보다, 내가 매일 쓰는 도구들을 조금이라도 더 좋게 만드는 데 기여한다는 게 뿌듯합니다.

---