올해 초 GitHub 저장소 설정에 풀 리퀘스트(PR)를 누가 열 수 있는지 정하는 옵션이 생겼어요. 그동안은 공개 저장소라면 GitHub 계정만 있으면 누구나 PR을 열 수 있었잖아요. 이슈나 위키는 예전부터 끌 수 있었는데, PR만은 공개 저장소라면 당연히 열려 있는 기능이었어요. 이번 변화로 그 전제가 바뀌었어요.
작은 설정 하나 같지만, 요즘 오픈소스 메인테이너들이 겪는 고민을 생각하면 꽤 의미가 있어요. 무엇이 바뀌었는지, 왜 이런 기능이 나왔는지 같이 볼게요.
무엇이 바뀌었나
공개된 변경 내용의 핵심은 두 가지예요. 하나는 PR을 열 수 있는 사람을 ‘모든 사용자’와 ‘협업자(collaborator)만’ 중에서 고를 수 있게 된 것이고, 다른 하나는 PR 기능 자체를 꺼버릴 수 있게 된 것이에요.
협업자는 저장소에 직접 초대받아 권한을 가진 사람을 말해요. 회사로 치면 같은 팀원이죠. ‘협업자만’으로 설정하면 외부 사람은 자기 포크에서 코드를 고쳐볼 수는 있어도 원본 저장소로 PR을 보낼 수는 없게 돼요.
헷갈리기 쉬운 게 하나 있는데요, 기존의 브랜치 보호 규칙이나 룰셋(rulesets)과는 하는 일이 달라요. 브랜치 보호는 누가 머지할 수 있는지, 그러니까 PR이 들어온 다음 단계를 관리해요. 이번 설정은 그 앞단에서 누가 PR을 열 수 있는지를 정하고요. 비유하자면 브랜치 보호가 결재 라인이고, 이번 설정은 사무실 출입 권한이에요.
GitHub에는 원래 상호작용 제한(interaction limits)이라는 기능도 있었어요. 이슈, PR, 댓글 활동을 기존 기여자나 협업자로 최대 6개월까지 묶어둘 수 있는 기능이에요. 다만 기간이 지나면 풀리는 임시방편이었어요. 이번 설정은 저장소의 기본 정책으로 계속 유지할 수 있다는 점이 달라요.
왜 하필 지금일까: 저품질 PR 홍수
배경에는 AI 코딩 도구의 확산이 있어요. 몇 분이면 그럴듯한 코드를 뽑아낼 수 있게 되면서, 프로젝트를 제대로 이해하지 않고 대량으로 찍어낸 PR이 크게 늘었어요. 영어권에서는 이런 걸 ‘AI 슬롭(slop)’이라고 부르는데, 대충 만든 찌꺼기라는 뜻이에요.
문제는 PR을 만드는 비용은 거의 0이 됐는데 리뷰하는 비용은 그대로라는 거예요. 메인테이너는 PR마다 코드를 읽고, 테스트를 돌리고, 왜 안 되는지 설명해야 해요. 보내는 사람은 5분 썼는데 받는 사람은 1시간을 쓰는 구조인 거죠.
실제로 curl 프로젝트는 AI가 만든 엉터리 보안 리포트에 지쳐 버그 바운티 프로그램을 접었고, Ghostty 같은 프로젝트는 AI의 도움을 받은 기여라면 그 사실을 밝히도록 기여 정책을 바꿨어요. 이번 GitHub 설정도 이런 흐름에서 나온 변화로 볼 수 있어요.
업계 맥락: ‘오픈 소스’와 ‘오픈 기여’는 다르다
코드는 공개하되 기여는 받지 않는 모델이 새로운 건 아니에요. 대표적인 예가 SQLite예요. 소스는 퍼블릭 도메인으로 누구나 볼 수 있지만 외부 코드 기여는 받지 않기로 유명하죠. 리눅스 커널도 GitHub에 미러 저장소가 있지만 실제 패치는 메일링 리스트로만 받아요. 이런 미러 저장소에는 엉뚱한 PR이 자주 들어와서 일일이 닫거나 자동화로 처리해야 했는데, 이제는 설정 하나로 해결돼요.
물론 걱정도 있어요. 오픈소스의 매력은 처음 온 사람이 버그를 고쳐 PR을 보내고, 그게 머지되면서 기여자가 되는 경험이잖아요. 문을 쉽게 닫아버리면 새 기여자가 들어올 길도 좁아져요. 그래서 많은 프로젝트가 PR 전에 이슈부터 열어 방향을 맞추도록 하고 있어요. 이 설정을 쓰더라도 신규 기여자가 들어올 경로는 따로 열어두는 게 좋아요.
한국 개발자에게 주는 시사점
마침 10월이에요. 매년 이맘때 열리는 Hacktoberfest 기간에는 실적을 채우려는 의미 없는 PR이 몰리곤 하거든요. 2020년에는 README에 한 줄 덧붙이는 스팸 PR이 쏟아져서, 참여 의사를 밝힌 저장소만 집계하는 방식으로 규칙이 바뀌기도 했어요. 공개 저장소를 운영하고 있다면 이참에 설정을 한번 점검해 보세요.
- 회사의 공개 저장소: SDK 샘플이나 기술 블로그 예제처럼 외부 기여를 받을 계획이 없다면 ‘협업자만’이 깔끔해요.
- 미러·자동 생성 저장소: PR을 아예 꺼두면 잘못 들어온 PR을 정리하는 수고가 사라져요.
- 커뮤니티 기여를 원하는 오픈소스: 열어두되 CONTRIBUTING.md와 PR 템플릿으로 기대치를 분명히 하는 게 먼저예요.
마무리
한 줄 정리: 이제 GitHub에서 PR은 당연히 열려 있는 기능이 아니라 메인테이너가 고르는 정책이 됐어요.
여러분이 운영하는 저장소라면 PR을 계속 열어두실 건가요, 협업자만으로 좁히실 건가요? 그리고 AI가 만든 PR은 받는 입장에서 어디까지 괜찮다고 보시나요?
🔗 출처: Hacker News