오픈소스에 기여하면서 느낀 점

PR 세분화의 중요성

저는 오픈소스에 기여해봤습니다. 코드베이스를 옮기는 작업을 해봤는데요, 최근 React Native 쪽에서 나오는 New Architecture를 점진적으로 적용하는 작업을 해보았습니다.

앞서 나와있듯이, 코드베이스를 옮기는 작업이라 꽤나 git diff 가 많이 생깁니다.

오픈소스 기여에 성공한 PR

https://github.com/TheWidlarzGroup/react-native-video/pull/3487

오픈소스 기여에 실패한 PR

https://github.com/TheWidlarzGroup/react-native-video/pull/3122

자, 오픈소스에 기여하려면 우리가 넘어야 할 상대는 바로 해당 레포의 Maintainer 입니다!

우리가 개발자로 일하면서 회사에서 넘어야 할 상대는 바로 내 옆자리에 있는 나의 동료입니다!

과연, 나의 동료와 오픈소스 Maintainer들의 관점의 공통점은 무엇일까요?

바로 비판적인 시선 입니다. 아무리 문제를 해결하려고 하더라도, 이 사람이 무엇을 해결하려고 하는지 혹은 어떻게 해결하려고 하는지에 대한 것이 먼저 이해가 되지 않으면, 코드를 아무리 봐도 총체적으로 좋은 리뷰를 하기는 힘들다고 개인적으로는 생각합니다.

즉, 첫번째로, 이 사람이, 즉 PR 을 만든 사람의 의도가 리뷰어에게 명확하게 이해가 되어야 된다는 말입니다.

PR 은 코드로 다른 사람을 설득하는 수단이라고 생각합니다. 즉 설득이 되려면 나의 의도를 이해시켜야 한다는 말인데, 어떻게 해야 상대방이 잘 받아들일 수 있을까요?

기술적인 고도화, 버그가 나오지 않을 만큼의 퀄리티가 있는 코드 등등 하드스킬적인 부분들도 물론 존재 할 것 입니다.

하지만 첫번째로 가장 나의 동료를 설득시킬 수 있는 방법은, PR의 크기 라고 생각합니다.

저는 동료와 함께 아주 들뜬 마음으로, 나도 오픈소스에 기여해야지 하고 무턱대로 큰 PR 을 메인테이너에게 들이 밀었습니다. 너무 좋아하겠지? 라는 예상과는 다르게, 메인테이너는 비판적인 시선으로 보았습니다.

“이 PR 이 들어가면 어떤 버그가 나올지 예상이 안 된다. 따라서 그 PR 의 크기를 더 분해해줘.” 라는 답변이 왔습니다.

각각의 PR 은 항상 더 추상화가 가능해지고, 오래보다보면 더 분해할 수 있음이 파악됩니다.

따라서 각 기능별로 리뷰를 하는 사람이 봤을때 직관적으로 이해가 갈 수 있는 범위, 혹은 리버트가 깔끔하게 가능한 범위의 PR 이 제일 이상적인 PR 의 크기가 아닐까 싶습니다.

← Go home