AI가 만든 PR, 테스트만 통과하면 병합해도 될까? 인기 오픈소스의 검증 체계 분석

1. 초록색 체크가 모두 켜졌다면 끝난 걸까

GitHub 스타 10만 개를 넘긴 프로젝트를 포함한 세 오픈소스가 AI의 도움을 받은 Pull Request를 어떻게 검증하는지 살펴봤습니다. 출발점은 단순한 질문이었습니다. 테스트가 모두 통과한 AI PR이라면 바로 병합해도 될까요?

공개 자료에서 확인한 검증 공백을 하나의 가상 상황으로 묶어보겠습니다. AI 에이전트가 버그를 고치고 회귀 테스트도 추가했습니다. lint와 build, CI까지 모두 초록색입니다. 그런데 작성자에게 왜 이 계층을 수정했는지 묻자 설명하지 못합니다. 새 API가 프로젝트의 방향과 맞는지, 문서와 라이선스까지 확인했는지도 불분명합니다.

테스트가 틀렸다는 뜻은 아닙니다. 테스트는 매우 중요한 근거입니다. 다만 테스트가 답하는 질문은 “실행한 사례에서 기대한 결과가 나왔는가”에 가깝습니다. “이 변경이 필요한가”, “설계가 맞는가”, “사람이 책임질 수 있는가”까지 한 번에 판정하지는 않습니다.

세 프로젝트의 공개 정책과 실제 CI·병합 코드를 함께 보면 공통 구조가 드러납니다.

1. 입구 계약: 다룰 문제와 AI 사용 여부, 작성자의 책임을 확인합니다.
2. 자동 검증: 테스트, lint, 문서, 라이선스, 보안과 호환성을 검사합니다.
3. 인간 판단: 프로젝트 방향, 설계, API와 설명 가능성을 검토합니다.
4. 병합 제어: 허용된 승인자와 상태 검사를 마지막 단계에서 다시 확인합니다.

이 글에서는 이 네 층이 실제로 어떻게 나뉘는지 살펴봅니다. 공개 저장소에서 확인할 수 없는 결함 감소율이나 실제 AI 사용량은 추정하지 않습니다. workflow가 있다는 사실과 모든 병합을 예외 없이 막는다는 주장도 구분합니다.

2. 테스트 통과는 판결문이 아니라 한 종류의 증거입니다

단위 테스트는 작성자가 예상한 입력과 결과를 확인합니다. 통합 테스트는 여러 구성 요소가 함께 동작하는지 봅니다. 여러 운영체제와 런타임 조합에서 같은 검사를 반복하는 matrix는 호환성 범위를 넓힙니다. 정적 분석과 보안 검사는 실행 테스트가 찾기 어려운 패턴을 보완합니다.

하지만 이 검사들은 대체로 이미 표현된 계약을 확인합니다. 테스트에 쓰지 않은 요구사항이나 잘못 이해한 문제는 초록색 결과 뒤에 남을 수 있습니다. AI가 존재하지 않는 API를 전제로 테스트와 구현을 함께 만들었다면, 둘이 서로 일치한다는 이유만으로 제품 요구까지 맞았다고 할 수도 없습니다.

자동 검증이 직접 답하기 어려운 질문도 있습니다.

• 이미 다른 사람이 해결 중인 문제는 아닌가
• 새 기능이 프로젝트가 받아들이려는 방향과 맞는가
• 기존 아키텍처의 책임 경계를 지켰는가
• 공개 API와 기존 사용자의 동작을 의도치 않게 바꾸지 않았는가
• 가져온 코드와 생성된 내용의 배포 권한이 분명한가
• 작성자가 코드를 이해하고 후속 질문과 수정에 책임질 수 있는가

따라서 좋은 검증 체계는 테스트를 약하게 만들지 않습니다. 테스트가 잘하는 일은 자동화하고, 테스트가 판정하지 못하는 일은 다른 단계의 소유자에게 넘깁니다.

3. 특정 오픈소스 A: AI 공개 항목도 실행 가능한 검사로 만듭니다

특정 오픈소스 A의 기여 정책은 AI 사용 자체를 금지하지 않습니다. 대신 어떤 도구를 어디에 사용했는지 공개하고, 생성된 모든 결과를 사람이 검토하도록 요구합니다. 코드가 아키텍처에 맞는지, 필요한 테스트와 문서가 있는지, 전체 테스트와 관련 검사를 통과하는지도 함께 확인해야 합니다.

특정 오픈소스 A의 기여 정책. 문장을 한국어로 옮기고 설명에 필요한 조건만 남겼습니다.

AI 도구를 사용했다면:- 사용한 도구와 용도를 공개합니다.- AI가 만든 모든 결과를 직접 검토하고 확인합니다.- 아키텍처, 테스트, 문서와 관련 검사를 함께 점검합니다.

여기서 중요한 점은 테스트 통과가 목록의 한 항목이라는 사실입니다. 사람이 내용을 이해했는지, 프로젝트 구조와 문서까지 맞는지는 별도 요구사항으로 남습니다. 자동 AI 리뷰도 인간 리뷰를 대체하지 못하며 유지관리자의 판단을 방해할 수 있다는 이유로 공식 PR에서는 요청하지 않도록 합니다.

정책은 안내문에서 끝나지 않습니다. PR 템플릿에는 AI를 사용하지 않았다는 항목과, AI를 사용했고 결과를 전부 검토했다는 항목이 나란히 있습니다. 제출자는 둘 중 하나만 선택해야 합니다. AI를 썼다면 도구와 사용 방식을 추가로 적습니다.

PR 품질 workflow는 열기, 수정, 다시 열기, review 준비, 새 commit push 같은 사건에 반응합니다. 그리고 PR 본문을 저장소의 검사 스크립트에 넘깁니다. 아래는 그 판단만 읽기 쉽게 줄인 편집 발췌입니다.

특정 오픈소스 A의 PR 품질 검사 코드. 식별자를 단순화하고 부수 처리를 생략했습니다.

if no_ai_checked == ai_used_checked:    return missing_ai_disclosureif ai_used_checked and description_word_count < 5:    return missing_ai_description

이 코드는 AI가 작성했는지를 탐지하지 않습니다. 제출자가 요구된 선택을 했고 설명을 남겼는지 검사합니다. 즉, 자동화가 진실을 알아내는 것이 아니라 사람이 책임질 수 있는 진술 형식을 만듭니다.

검사에 실패하면 PR에 이유를 설명하는 댓글을 남깁니다. 공식 저장소에서 최근 기여가 없는 작성자가 필수 항목을 누락한 경우에는 PR 종료까지 이어질 수 있습니다. 반면 일정한 기여 이력이 있는 작성자는 이 품질 검사 전체를 건너뜁니다. 그러므로 “모든 작성자에게 같은 방식으로 강제된다”고 일반화하면 안 됩니다.

코드 검증도 하나의 거대한 test job으로 묶지 않습니다. Python과 JavaScript, 저장소 스크립트 테스트가 나뉘고, lint와 문서 검증도 별도 workflow입니다. 지원 Python 버전을 순회하는 matrix는 특정 라벨이 있을 때 실행됩니다. 문서만 바뀐 PR은 코드 테스트 대신 문서 lint, format, spelling 검사를 탑니다.

여기서 얻을 수 있는 첫 번째 원칙은 간단합니다. “CI 통과”라고만 기록하지 말고 어떤 계약과 어떤 job을 통과했는지 말해야 합니다. AI 공개 형식, 코드 동작, 문서 품질은 서로 다른 검사입니다.

4. 특정 오픈소스 B: 테스트 결과와 승인자를 병합 단계에서 결합합니다

특정 오픈소스 B는 AI가 만든 내용에 공개와 사람의 해설을 요구합니다. PR의 코드는 제출 전에 직접 읽고 단순화해야 하며, 사람이 이해하고 책임져야 합니다. 완전 자율 에이전트가 만든 기여는 받지 않는다는 경계도 분명히 둡니다.

코드를 만들기 전 단계도 검증 체계에 포함합니다. 신규 기여자는 일반적으로 유지관리자가 "지금 구현할 가치가 있는 문제"라는 뜻의 actionable 라벨을 붙인 이슈와 PR을 연결해야 합니다. 방금 이슈를 만들었다면 유지관리자가 문제를 검토하고 라벨을 붙이기 전에 구현부터 보내지 말라고 안내합니다.

이 절차는 “코드가 동작하는가”보다 먼저 “프로젝트가 이 문제를 풀기로 했는가”를 확인합니다. AI는 그럴듯한 해결책을 빠르게 만들 수 있지만, 해결할 문제의 우선순위와 제품 방향까지 결정할 권한을 자동으로 얻지는 않습니다.

PR이 열린 뒤에는 CI가 build와 test를 수행합니다. 기본 테스트는 여러 분할 작업(shard)으로 나뉘고, 문서 테스트와 하위 호환성, 분산 실행 같은 구성이 붙습니다. lint workflow도 변경 파일에 따라 C++ 계열 검사, 타입 검사와 그 밖의 lint를 나누어 실행합니다.

그러나 초록색 job만으로 병합되지는 않습니다. 저장소의 병합 규칙은 변경 경로와 승인 가능한 사람, 필수 상태 검사를 한 묶음으로 선언합니다.

특정 오픈소스 B의 병합 규칙. 실제 경로와 계정은 일반 이름으로 치환했습니다.

- name: 한 기능 영역  patterns:    - 해당 영역의 코드와 테스트  approved_by:    - 해당 영역을 맡은 검토자  mandatory_checks_name:    - CLA    - Lint    - pull

병합 스크립트는 바뀐 파일에 맞는 규칙을 찾고, GitHub에서 승인한 계정을 읽어 허용된 검토자와 대조합니다. 그다음 필수 검사가 실패했거나 아직 끝나지 않았는지 확인합니다. 경로, 승인자, 상태 검사 중 하나라도 맞지 않으면 일반 병합 흐름은 진행되지 않습니다.

여기서 CLA는 기여자가 프로젝트의 라이선스 조건에 동의했는지 확인하는 절차입니다. 즉, 코드가 잘 동작하는지만 아니라 그 코드를 프로젝트가 합법적으로 받아들일 수 있는지도 병합 조건에 포함합니다.

기여 문서는 승인 이후에도 유지관리자가 병합 봇 명령을 호출하도록 안내합니다. 이 구조에서 CI는 사람을 대체하지 않습니다. 반대로 사람의 승인도 실패한 필수 검사를 평범한 초록색으로 바꾸지 않습니다. 서로 다른 두 근거를 마지막 단계에서 결합합니다.

다만 공개 코드에는 필수 검사를 건너뛸 수 있는 강제 병합 경로도 있습니다. 병합 규칙은 여러 개 중 하나를 만족하면 되는 구조이고, 변경에 따라 실행할 CI도 선택됩니다. 따라서 “모든 PR이 같은 전체 테스트를 통과하고 어떤 예외도 없이 차단된다”고 쓰는 것은 공개 근거보다 강한 주장입니다.

두 번째 원칙은 검사 결과와 승인 권한을 분리해서 기록하는 것입니다. tests passed와 approved by an owner는 같은 뜻이 아닙니다. 전자는 실행 결과이고 후자는 설계와 책임에 대한 판단입니다.

5. 특정 오픈소스 C: 넓은 CI도 리뷰의 첫 라운드로 둡니다

특정 오픈소스 C는 다양한 운영체제와 컴파일러, TLS backend에서 사용되는 C 프로젝트입니다. 공식 CI 문서는 모든 PR을 Linux, macOS, Windows, BSD 계열에서 확인하고 clang과 gcc, autotools와 CMake, 여러 build 방식과 배포 archive를 검증한다고 설명합니다.

GitHub Actions에는 source style, 맞춤법, 여러 linter, 라이선스 상태, 함수 복잡도와 길이를 보는 workflow가 있습니다. 별도 CodeQL workflow는 Actions와 Python, Linux·Windows의 C build를 분석합니다. fuzzing, sanitizer, 정적 분석과 다른 CI 서비스도 호환성 표면을 넓힙니다.

이 정도면 테스트만으로 충분해 보일 수 있습니다. 하지만 이 프로젝트의 코드 리뷰 문서는 자동화의 자리를 다르게 표현합니다.

특정 오픈소스 C의 코드 리뷰 지침. 여러 절을 검토 순서에 맞게 줄였습니다.

1. 도구와 테스트가 먼저 결과를 냅니다.2. 숙련된 유지관리자가 변경의 필요성을 판단합니다.3. 공개 API와 바이너리 호환성(ABI), 기존 동작, 이식성, 메모리와 thread safety를 봅니다.4. 코드와 함께 문서가 정확히 바뀌었는지 확인합니다.

공개 지침은 모든 제출물이 병합 전에 숙련된 유지관리자 한 명 이상의 리뷰를 받아야 한다고 말합니다. 자동 검사가 style 위반을 찾더라도 프로젝트가 원하는 변경인지는 사람이 판단합니다. 테스트가 통과해도 기존 API와 동작을 보존하는지, 다른 환경에서 쓸 수 있는지, 오류 경로의 메모리가 안전한지는 리뷰 대상입니다.

AI 보조 코드도 받을 수 있지만 별도의 낮은 기준을 적용하지 않습니다. 명확한 코드, coding standard, 문서, 테스트 사례와 일반 기여 요건을 그대로 충족해야 합니다. 제출자는 코드의 배포 권한도 책임집니다. 테스트가 라이선스 출처나 사람의 설명 가능성을 증명해주지는 않기 때문입니다.

반대 방향의 한계도 문서에 적혀 있습니다. 외부 dependency service나 가상 환경, 같은 코드에서도 간헐적으로 실패하는 flaky test 때문에 CI가 실패할 수 있습니다. 빨간 체크가 항상 코드 결함을 뜻하지 않는다면, 초록색 체크도 모든 위험이 사라졌다는 선언은 아닙니다. 결과를 해석하고 다음 행동을 정하는 사람이 필요합니다.

PR 템플릿에는 AI 없이 자신의 작업을 설명할 수 없다면 제출하지 말라는 숨은 안내문이 있습니다. 그러나 HTML 주석은 자동 차단 장치가 아닙니다. AI 사용 공개도 PR에 대해 명시적으로 강제된다고 볼 근거는 없습니다. 정책 문장, 실행 가능한 검사와 실제 병합 제한을 같은 것으로 취급하지 않아야 합니다.

6. 세 프로젝트가 보여준 네 겹의 검증 체계

세 프로젝트는 같은 도구를 쓰지 않지만 테스트 바깥의 위험을 서로 다른 위치에서 다룹니다. A는 제출자의 설명을 입구에서 확인하고, B는 테스트와 승인자를 병합 순간에 결합하며, C는 넓은 자동 검증 뒤에도 숙련된 리뷰를 남겨둡니다. 이를 팀에 옮기면 다음 네 층으로 정리할 수 있습니다.

입구 계약

• 연결된 이슈와 수용된 문제인가
• PR의 범위와 변경 이유가 설명되어 있는가
• AI 사용 여부와 사용 범위를 공개해야 하는가
• 작성자가 모든 변경을 읽고 후속 수정에 책임지는가

자동 검증

• 변경된 행동을 보호하는 회귀 테스트가 있는가
• 관련 suite와 지원 runtime·OS matrix를 실행했는가
• lint, type check, build, 문서 검사를 분리해 확인했는가
• 보안, 라이선스, 생성 파일과 하위 호환성 검사가 필요한가
• 실행하지 않은 job과 제외된 경로를 성공으로 보고하지 않았는가

인간 판단

• 프로젝트가 원하는 문제와 해결 방식인가
• 기존 계층과 공개 API의 책임을 지키는가
• 테스트가 표현하지 못한 오류·권한·데이터 경계는 무엇인가
• 작성자가 코드의 핵심 선택과 위험을 설명할 수 있는가
• 문서와 migration, 사용자 경험이 코드와 일치하는가

병합 제어

• 변경 영역을 아는 사람이 승인했는가
• 필수 상태 검사의 정확한 이름과 범위가 정해져 있는가
• 새 commit 뒤 이전 승인이 무효가 되는 조건이 있는가
• 긴급 우회 권한과 사용 기록, 사후 검토 책임이 분명한가

이 네 층은 AI PR만을 위한 특별 대우가 아닙니다. 사람의 PR에도 같은 품질 기준이 필요합니다. 다만 AI가 구현과 설명을 빠르게 대량 생성할 수 있으므로, 문제 선택과 인간 책임을 명시하지 않았을 때 검토 부담이 더 쉽게 다른 사람에게 넘어갈 수 있습니다.

7. 병합 여부보다 먼저 PR 검증 기록을 남깁니다

다음 예시는 어느 프로젝트의 원문도 아닙니다. 앞서 확인한 공개 정책과 코드를 팀에서 남길 수 있는 검증 기록으로 재구성한 것입니다.

PR 검증 기록문제와 책임- 연결된 이슈와 수용 상태:- 변경 범위와 AI 사용 공개:- 작성자가 직접 설명할 수 있는 핵심 선택:자동 검증- 실행해 통과한 검사:- 건너뛰었거나 아직 끝나지 않은 검사:- 문서·보안·라이선스·호환성 확인:인간 검토- 변경 영역을 아는 승인자:- 설계·공개 API·사용자 영향:병합 경계- 공개 파일에서 확인한 필수 조건:- 조직 설정이라 확인하지 못한 조건:- 남은 위험과 최종 판단 책임자:

AI는 이 양식을 채우며 흩어진 근거를 모을 수 있지만, 빈칸을 추정으로 메우거나 최종 승인자를 대신해서는 안 됩니다. 구체적인 finding을 행동 테스트로 연결하는 방법은 AI 프론트엔드 코드 리뷰 Skill: 결함을 행동 테스트로 연결하는 법에서 더 자세히 다룹니다.

저장소의 작업 규칙과 검증 명령을 AI 가까이에 두는 방법은 스타 10만 오픈소스는 AGENTS.md를 어떻게 설계했을까에서 이어서 볼 수 있습니다. AGENTS.md는 작업 전 판단을 돕고, 이 글의 CI와 병합 규칙은 작업 뒤 증거와 승인 경계를 만듭니다.

8. 공개 저장소 분석으로 알 수 없는 것

이 글은 공개된 정책, PR 템플릿, workflow와 병합 스크립트가 어떤 절차를 설계했는지 분석했습니다. 실제 조직 설정과 모든 PR의 실행 결과를 조사한 것은 아닙니다.

GitHub workflow 파일은 자동화가 구성되어 있음을 보여줍니다. 하지만 저장소 관리자가 설정하는 병합 보호 규칙(branch protection과 ruleset)까지 모두 공개하지는 않습니다. 문서가 “필수”라고 표현해도 예외 권한이나 직접 push 경로가 있는지는 별도 확인이 필요합니다.

검사가 존재한다는 사실로 결함 감소율이나 유지관리 시간 절감도 계산할 수 없습니다. AI로 작성된 PR의 비율, 공개 내용의 정확성, 사람이 실제로 어느 정도 검토했는지도 공개 파일만으로 알 수 없습니다.

본문의 A·B·C는 가명이며 편집 발췌는 원문의 구조를 설명하기 위해 번역, 축약하거나 식별자를 바꿨습니다. 원문 그대로의 코드가 아닙니다. 실제 프로젝트와 분석에 사용한 고정 파일은 마지막 출처에서 확인할 수 있습니다.

9. 결론: 초록색 체크 다음에 물어야 할 질문

처음의 AI PR로 돌아가 보겠습니다. 테스트와 CI가 모두 통과했다면 중요한 첫 관문은 넘었습니다. 이제 무엇을 실행했고 무엇을 건너뛰었는지, 연결된 문제가 수용됐는지, 작성자가 코드를 설명할 수 있는지, 설계와 문서를 아는 사람이 승인했는지를 확인해야 합니다.

좋은 검증 체계는 AI를 알아맞히는 탐지기에 의존하지 않습니다. 제출자가 책임질 내용을 명시하고, 자동 검사를 목적별로 나누며, 사람이 판단할 질문을 남기고, 병합 순간에 승인과 상태를 다시 결합합니다.

테스트 통과는 병합 판단의 강한 근거이지, 그 자체로 충분조건은 아닙니다. 초록색 체크 뒤에 누가 무엇을 확인했고, 무엇은 아직 모르는가까지 남을 때 AI가 만든 PR도 검토 가능한 변경이 됩니다.

분석한 오픈소스와 원문 출처

본문에서는 분석 대상을 특정 오픈소스 A·B·C라는 가명으로 표현했습니다. 아래에서만 실제 프로젝트명을 밝힙니다. 링크는 분석에 사용한 파일 상태를 그대로 가리키는 고정 주소이며, 이 글은 각 프로젝트의 공식 문서나 공식 입장이 아닙니다.

• 특정 오픈소스 A = Django — 공식 저장소, AI 기여 정책, PR 템플릿, PR 품질 workflow, AI 공개 검사, 검사 예외와 PR 종료 처리, 코드 테스트, Python matrix, 문서 검증.
• 특정 오픈소스 B = PyTorch — GitHub 공개 저장소의 스타가 10만 개를 넘긴 분석 대상입니다. 공식 저장소, AI 정책, 책임과 actionable 이슈, 승인과 병합 봇, PR 테스트 workflow, 경로별 병합 규칙, 일반 승인 규칙, 승인·필수 검사 판정 코드, 병합 workflow와 우회 경로.
• 특정 오픈소스 C = curl — 공식 저장소, 테스트·리뷰 절차, AI PR 요구와 라이선스 책임, 코드 리뷰 기준, CI 범위와 flaky 한계, source·라이선스·복잡도 검사, CodeQL 설정, PR 템플릿의 AI 안내.