iOS 공부를 시작한 지도 벌써 8개월가량 흘렀습니다.
처음 Swift 언어를 공부할 때는, 옵셔널이 뭔지 … 프로토콜이 뭔지… 구조체는 뭔지… 공식 문서를 읽으며 이해하는 것도 만만치 않았는데요.
요즘에는 문서를 넘어서, 오픈 소스인 Swift 언어의 깃헙까지 들어가서 코드 단위로 살펴보곤 합니다.
그러다, 우연히 Optional.swift 파일에서 문서 오류를 발견하게 됩니다.
이 글은 문서 오류를 찾아 애플에 PR 을 보내고, 하루 만에 main 브랜치에 merge 받아 들뜬 신입 개발자의 회고입니다.
오류 발견
처음엔 내가 잘못 읽었나? 싶어서 여러 번을 다시 읽었습니다.
친구에게도 공유해서, 나만 이상하게 느끼는 건지 물어보기도 했구요.
Swift 언어의 핵심 중 핵심인 옵셔널(Optional) 문서에 틀린 게 있다니 … 심장이 두근거렸습니다.
오픈 소스에 기여하기 위한 ‘프로세스’는 알고 있었습니다.
해당 레포를 fork 한 뒤, 자신의 레포 → 오픈 소스 레포로 PR 을 제출해야 한다는 걸요.
제가 아는 프로세스 대로, 오류를 살짝 수정하고 commit 을 준비하던 찰나…
커밋 메시지 뭐라고 적어야 하지? 🤔
라는 생각이 번쩍 들었습니다.
평소에는 그저 카르마 스타일에 맞춰서 한글로만 커밋을 해왔는데, 일단 메시지부터 영어로 적어야 했습니다.
무엇보다, 그 까다로운 애플이기 때문에, 커밋 메시지나 PR 내용의 ‘가이드라인’을 따르지 않는다면, 제 PR 이 그냥 무시되진 않을까 우려됐습니다.
우선 Swift 레포에서 평소에 이뤄지는 PR 리스트를 살펴보기로 했습니다.
PR 제출을 위한 가이드라인 조사
처음 PR 리스트를 보고, 자신감이 급감했습니다.
제목만 읽어도 이해할 수 있는 게 하나도 없고, 애플 개발자들끼리 뭔가 엄청난(?) 코멘트를 주고받으며 업무를 하고 있었습니다.
하지만 Swift 언어는 ‘오픈 소스’이고, 나는 당당히 오류를 수정하러 온 거니까, 자신감을 갖기로 했습니다.
PR 에도 종류가 있기 때문에, 저는 typo(오기) 키워드를 위주로 조사해보기 시작했습니다.
특히 이미 Merged 된 PR 들 위주로 살펴봤는데요.
위의 캡처 이미지처럼, PR 내용이 굉장히 심플하고, 반응도 쿨한 걸 확인할 수 있었습니다.
그리고 3가지를 알게 됐습니다.
- 대부분의 경우엔 커밋 메시지를 그대로 PR 내용에 재사용한다.
- typo 관련 PR 은 main 브랜치를 대상으로 제출한다.
- swift-ci 란 이름의 젠킨스 봇이 테스트를 한 뒤 자동으로 merge 까지 해준다.
그 후, 최대한 다른 PR 들과 유사한 형식으로 커밋 메시지와 PR 내용을 작성했습니다.
혹시 애플 개발자가 변경 사항 확인하기 번거롭진 않으실까.. 친절하게 수정한 부분을 통째로 주석으로 달기도 했습니다. 😅
PR 제목의 맨 앞에 붙인 [stdlib] 은 “Standard Library” 의 약자입니다.
Swift 레포에 폴더가 워낙 많기 때문에, PR 이 어떤 카테고리에 해당하는지 표기하는 걸 권장하더라구요.
결과
새벽에 PR 제출하고 꿀잠을 자고 일어나니, merge 됐다는 이메일 알람이 와있었습니다.
깃헙을 확인해보니, 영롱한 애플 마크와 함께 swift 언어에 contributed 했다는 메시지가 보였습니다.
사실, 어디가서 자랑할 만큼 대단한 수정은 전혀 아니에요.
하지만 Swift 라는 거대한 산에, 티스푼 하나 만큼 기여했다는 사실이 제게는 정말 값진 경험이었습니다.
Swift 언어 자체에 대한 애정도 커졌구요.
혹시 Swift 문서를 읽다가 오류를 찾으신다면, 꼼꼼하게 검토하고 PR 을 보내서 컨트리뷰터가 되어보시길 바랍니다.
물론 저는 그 후로도 꾸준히 Swift 깃헙을 살펴보고 있지만 … 쉽지 않네요. 🤣
제가 merge 받은 PR 은 아래 링크로 첨부합니다.
2022–05–18 내용 추가
첫 컨트리뷰션 이후로, 추가로 4건의 PR 을 제출했습니다.
먼저 제출한 2건의 PR 은 이미 merge 받았고, 나머지 2건은 검토 중입니다.
모두 최근 1달 안에 이뤄진 일입니다. 😄
이제 typo 또는 간단한 문서 수정은 나름 편하게(?) 할 수 있게 된 것 같습니다.
그리고 여러 번의 PR 을 제출하면서, 어떤 패턴을 발견하기도 했는데요.
- 명백하게 틀린 코드에 대해선, 대략 하루 만에 Approval 을 받을 수 있다.
- 틀린 코드를 단순 수정하는 게 아닌, 개선을 위한 리팩토링을 시도하면 일주일 이상 리뷰가 지연될 수 있다.
- 변경 사항이 많을 땐, 여러 맥락이 섞이지 않도록 커밋과 PR 을 짧게 분리하면 좋다.
이러한 패턴을 경험하고 있습니다.
아직 merge 되지 않은 PR 도 있기 때문에, 아직은 섣부르게 경험을 정리하기 어렵긴 하네요. 😅
시간이 좀 더 지나서, 리뷰가 완료되면 다시 컨트리뷰션 관련한 글을 작성해보겠습니다!
저의 모든 PR 리스트는 아래 링크에서 확인하실 수 있습니다.
