AI를 이용해 오픈소스에 기여하는 방법

두 달 동안 오픈소스 프로젝트에 PR 58개를 머지시켰다. black(Python), rubocop(Ruby), symfony(PHP), hugo(Go), nushell(Rust), html-react-parser(TypeScript)… 언어가 제각각이다.

나는 이 언어들을 다 잘 다루지 못한다.

AI를 쓰면 이게 된다. 그런데 이 문장만 보면 딱 요즘 메인테이너들이 제일 싫어하는 부류이기도 하다. 남의 프로젝트에 AI로 뽑은 PR을 쏟아붓는 사람. 실제로 나는 그러다 한 번 차단당했다.

거기서 알게 된 게 이 글의 전부다. 코드를 못 짜는 건 이제 장벽이 아니다. 남은 병목은 그 코드를 읽어줘야 하는 사람의 시간이다.

코드 장벽이 사라진 자리

시작은 첫 PR 하나였다. 5월 16일, html-react-parser라는 라이브러리의 버그를 고쳐 올렸고 메인테이너와 몇 번 대화하며 다듬은 끝에 머지됐다. 그 얘기는 휴학 회고에 적었다.

예전이라면 Ruby 프로젝트에 기여하려면 먼저 Ruby를 어느 정도 해야 했다. 지금은 순서가 바뀌었다. rubocop의 버그를 재현하고, 회귀 테스트를 짜고, 최소한으로 고치는 걸 에이전트와 함께 하면서 그 언어의 그 부분을 배운다.

진입점이 "이 언어를 마스터한 다음"에서 "이 버그 하나를 고치면서"로 내려온 것이다. 58개가 여러 생태계에 걸쳐 있는 건 그래서 가능했다. 대단한 게 아니라 진입 장벽이 무너진 시대의 당연한 결과에 가깝다.

차단당하고 나서야 선이 보였다

그런데 장벽이 낮아졌다는 건 나 말고 다른 수천 명한테도 낮아졌다는 뜻이다. 메인테이너 쪽에서 보면 갑자기 AI로 만든 PR이 쏟아지기 시작한 거다.

나도 그 쏟아붓는 쪽이었다. vitest라는 프로젝트에 PR을 올렸는데, 그 저장소가 "AI로 PR 보내지 말라"고 명시해둔 걸 못 보고 저지른 일이었다. 결과는 그 GitHub 조직 차원의 차단이었다. 이 사건이 나한테 어떤 규칙들을 남겼는지는 따로 자세히 썼다.

그때 알았다. 내가 아낀 시간만큼 누군가는 시간을 쓴다. 에이전트를 붙여 빠르게 뽑아낸 diff라도, 그걸 읽고 판단하는 쪽은 사람이고 그 시간은 줄어들지 않는다. 기여와 민폐를 가르는 건 코드 품질이 아니라 내가 남의 시간을 얼마나 아껴줬느냐였다.

그래서 선을 두 개 그었다.

• 그 저장소가 AI 기여를 어떻게 대하는지부터 확인한다. 금지한 곳은 아예 건드리지 않고 우회할 방법도 찾지 않는다. 다른 계정으로도, 다른 표현으로도. 고지나 Co-Authored-By를 요구하면 그대로 따르고, 규정이 없어도 필요하면 AI를 썼다고 짧고 정직하게 밝힌다.
• 새로 여는 PR은 전부 합쳐 하루 한 개까지. 같은 저장소에 내 PR이 이미 열려 있으면 거기엔 새 걸 올리지 않는다.

PR 하나가 만들어지는 순서

나머지는 전부 리뷰하는 사람의 시간을 줄이려고 만든 장치다. 문서로 박아두고 매번 그대로 돌린다.

1. 후보 고르기. 최근 활동, 테스트 명령어 유무, good first issue 신호, 재현 가능성을 점수로 매겨 통과한 것만 고른다. 이미 같은 걸 고치는 PR이 열려 있으면 버린다.
2. 재현. 로컬에서 실제로 재현한다. 안 되면 손대지 않는다.
3. 실패하는 테스트부터. 고치기 전에, 그 버그 때문에 실패하는 회귀 테스트를 먼저 짠다.
4. 최소 수정. 테스트를 통과시키는 가장 작은 변경만. 관련 없는 포맷팅이나 리팩터는 넣지 않는다.
5. 검증. 테스트·린트·빌드를 돌리고, 못 돌린 게 있으면 못 돌렸다고 적는다.
6. 좁은 PR. "뭐가 고장 나 있었고, 뭘 바꿨고, 어떻게 검증했는지"를 몇 문장으로 적는다.

여섯 단계가 노리는 건 하나다. 리뷰하는 사람이 짧은 시간 안에 "아 이거 맞네" 할 수 있는 크기. 그래서 큰 리팩터나 기능 추가는 안 한다.

최근에는 앞부분(후보 탐색부터 PR 생성까지)을 자동화해서, 아침 9시에 열린 PR을 점검하고 낮 동안 세 번 새 후보를 찾는 실험을 하고 있다. 이 경로로 나간 PR은 아직 한 손에 꼽는다. 그리고 완전 자율은 아니다. 후속 push는 자동으로 나가지만 공개 답글은 내가 확인한 뒤에 나가고, PR을 접을지는 에이전트와 얘기해보고 내가 정한다.

다 이해하지 못한 코드를 올린다는 것

여기서 솔직해야 한다. 나는 PR에 올리는 코드를 줄 단위로 다 이해하지 않는다. 그게 이 방식에서 사람들이 제일 걸고넘어질 부분이다.

대신 올리기 전에 이건 직접 확인한다. 내가 바꾼 함수와 그게 불리는 경로, 실패의 원인, 테스트가 검증하는 범위, 그리고 내가 검증하지 못한 범위가 어디까지인지. 마스터하지 않은 언어라도 이 변경이 왜 맞는지 내 입으로 설명할 수 있을 때만 올린다.

이건 대충 한다는 뜻이 아니다. 오히려 반대다. 사람이 눈으로 훑고 "괜찮아 보인다"로 넘기는 것보다, 재현과 테스트로 강제하는 검증이 더 빡세다. 리뷰어 입장에서도 작은 diff에 동작을 붙잡는 테스트가 붙어 있으면 읽기가 빠르다.

숫자를 정직하게 까면 이렇다. 2026년 7월 24일 기준으로 머지 58개, 닫힘·미병합 40개, 아직 열려서 대기 중인 게 47개다(개인·팀 저장소 제외, 공개 검색으로는 57개로 잡힌다). 두 달 동안 145개쯤 열어서 58개가 안착했다.

선을 다 지켜도 절반 가까이는 닫힌다는 뜻이다. 중복이었거나, upstream이 바뀌었거나, 내가 철회했거나, 구현이 틀렸거나. 그래서 머지 비율을 실력 점수로 보지 않는다. 닫힌 이유를 읽으면 그 프로젝트가 뭘 받아주고 뭘 안 받아주는지가 다음 기여에 쌓인다.

그러니 "AI가 다 해준 거 아니냐"고 물으면 절반은 맞다. 코드 탐색과 초안, 반복 검증의 상당 부분은 에이전트가 한다. 하지만 어떤 버그를 고를지, 그게 진짜 재현되는지, 이 저장소가 AI 기여를 받아주는지, 리뷰에 뭐라고 답할지는 사람이 정하고 책임진다. AI는 진입 장벽을 낮췄지, 판단을 대신해주지 않았다.

시간과 돈

대학생 입장에서 제일 궁금할 부분이라 솔직하게 적는다.

시간. PR 하나에 내가 실제로 쓰는 시간은 단순한 건 10분 안팎이다. 리뷰가 한 번 달리면 코멘트 해석하고 수정 범위 정하는 데 10~30분, 설계를 바꿔야 하거나 CI가 터지면 누적 한두 시간까지 간다. 에이전트가 후보 찾고 테스트 돌리는 데는 수십 분이 걸리지만 그동안 내가 화면을 붙잡고 있을 필요는 없다.

돈. 매일 고성능 모델로 돌리면 비싸다. Claude Max나 ChatGPT의 상위 플랜은 월 $100~200 선이고(세금·지역가 별도), 둘 다 상위로 쓰면 $400까지도 간다. 나는 프로모션이 적용된 구간이 있어서 실제 지출은 정가보다 낮았지만 누구나 같은 값에 쓸 수 있는 건 아니다.

시작하는 사람한테 현실적인 조언은 이거다. 둘 다 구독할 필요 없다. 하나만 월 $20에 쓰고 매일이 아니라 주 1~2회 돌려도 첫 머지는 충분히 가능하다.

시작하려는 사람에게

두 달 전의 나는 오픈소스 기여가 나 같은 사람한텐 먼 얘기라고 생각했다. 지금은 여러 언어의 프로젝트에 내 코드가 들어가 있고, 그 코드는 내가 자는 동안에도 어딘가에서 누군가의 버그를 막고 있다. 그 감각은 수상이나 스펙과는 다른 종류의 것이다.

딱 하나만 남긴다면, 그 저장소가 AI 기여를 어떻게 대하는지부터 확인하고, 남이 5분 안에 이해할 수 있는 작은 버그 하나부터 고쳐라. 나도 거기서 시작했고, 그게 전부였다.