오픈소스 기여를 포트폴리오로 만드는 법: 병합 PR 4가지 사례

오픈소스 기여의 가치는 PR 개수만으로 설명하기 어렵습니다. 어떤 문제를 골랐고, 왜 그 변경이 맞으며, 기존 동작을 깨지 않았다는 것을 어떻게 증명했는지가 더 중요합니다.

저는 기여 과정을 다음 네 단계로 고정합니다.

1. 저장소의 기여 규칙과 CI를 먼저 읽는다.
2. 문제를 재현하고 실패 원인을 한 문장으로 설명한다.
3. 수정 범위를 최소화하고 회귀 테스트를 추가한다.
4. 저장소가 신뢰하는 검증 명령과 실행하지 못한 항목을 함께 기록한다.

아래 사례는 모두 upstream에 병합된 실제 PR입니다. 구현과 검증에는 OpenAI Codex의 도움을 사용했고, 각 PR에서 그 사실과 검증 범위를 공개했습니다.

Effect: property test가 실행되기 전에 실패한 이유 찾기

Effect PR #6416은 @effect/vitest의 record 형태 property input에 Schema를 넣을 때 test collection이 실패하는 문제를 고쳤습니다.

핵심 원인은 단순했습니다. Schema.toArbitrary로 변환한 값을 만든 직후 원래 Schema로 다시 덮어써 FastCheck가 Arbitrary 대신 Schema를 받았습니다. 수정은 변환 결과를 보존하는 한 줄이었지만, 중요한 부분은 { value: Schema.Int } 형태의 회귀 테스트였습니다.

검증은 변경 패키지에서 점진적으로 넓혔습니다.

• 대상 테스트 파일: 25개 통과, expected failure 1개, skip 4개
• packages/vitest/test 전체: 34개 통과, expected failure 1개, skip 4개
• 저장소 check, lint, git diff --check 통과
• 컨테이너 런타임이 없어 완료하지 못한 저장소 전체 통합 테스트는 별도 환경 한계로 기록

여기서 배운 점은 “작은 diff”와 “충분한 증거”는 서로 반대가 아니라는 것입니다. 변경은 한 줄이어도 재현과 회귀 테스트, 패키지 전체 검증이 있으면 리뷰어가 안전성을 빠르게 판단할 수 있습니다.