최근 신호는 분명합니다. curl은 2026년 1월 bug bounty를 종료하며 AI 기반 저품질 리포트와 확인 비용을 공개적으로 문제 삼았습니다. 2026년 6월에는 7월 한 달 동안 취약점 리포트 접수를 쉬겠다는 보도까지 나왔습니다. arXiv에 올라온 2026년 논문도 AI slop을 리뷰 마찰, 품질 저하, 공동체 비용 전가의 문제로 분석했습니다. GitHub Community 토론에서도 메인테이너가 PR 코드뿐 아니라 작성자의 이해 수준까지 평가해야 하며, 리뷰 부담이 AI 이전보다 커졌다는 문제 제기가 이어졌습니다.

이 흐름은 Agentic PR Governance, Code Quality Policy Gate, AI Code Provenance와 SBOM, Package Release Quarantine Gate와 이어집니다. 핵심은 AI 사용 금지냐 허용이냐가 아닙니다. 사람이 검증할 가치가 있는 기여만 리뷰 큐에 들어오게 만드는 접수 게이트가 필요하다는 점입니다.

참고 신호:

• Daniel Stenberg, “The end of the curl bug-bounty”: https://daniel.haxx.se/blog/2026/01/26/the-end-of-the-curl-bug-bounty/
• arXiv 2603.27249, “An Endless Stream of AI Slop”: https://arxiv.org/html/2603.27249v1
• GitHub Community Discussion #185387: https://github.com/orgs/community/discussions/185387
• Cybernews, curl July 2026 vulnerability report pause: https://cybernews.com/security/curl-stops-accepting-bug-reports-for-july/

이 글에서 얻는 것

• AI가 오픈소스 기여 흐름에서 어떤 병목을 만드는지 이해합니다.
• PR, 이슈, 보안 리포트를 사람 리뷰 전에 걸러내는 intake gate 기준을 잡을 수 있습니다.
• AI 사용을 무조건 금지하지 않고도 테스트 증거, 변경 범위, 책임 소재를 요구하는 운영 모델을 설계합니다.
• 내부 플랫폼 팀과 오픈소스 메인테이너가 적용할 수 있는 숫자 기반 리뷰 큐 정책을 정리합니다.

핵심 개념/이슈

1) AI 기여 문제의 본질은 나쁜 코드가 아니라 비대칭 비용이다

AI가 만든 코드가 항상 나쁜 것은 아닙니다. 문제는 작성자가 충분히 이해하지 못한 변경도 매우 그럴듯한 형식으로 제출할 수 있다는 점입니다. PR 제목은 깔끔하고, 설명은 길고, 코드 스타일도 맞을 수 있습니다. 그러나 경계 조건을 묻거나 테스트 실패를 설명하라고 하면 기여자가 답하지 못하는 경우가 생깁니다. 이때 메인테이너는 코드 리뷰어이면서 튜터, 디버거, 품질 보증자 역할까지 떠안습니다.

비대칭은 숫자로 보면 더 선명합니다.

• 기여자는 10분 만에 PR 3개를 만들 수 있다.
• 메인테이너는 PR 하나를 이해하고 반박하는 데 30~60분을 쓴다.
• 보안 리포트 하나가 실제 취약점인지 확인하는 데 재현 환경과 threat model 검토가 필요하다.
• 저품질 리포트가 20개 들어오면 진짜 중요한 1개가 늦게 보인다.

따라서 목표는 “AI PR을 모두 막자"가 아니라 “검증 비용을 지불할 준비가 된 기여만 review queue에 넣자"입니다.

2) PR 접수는 CI 이후가 아니라 CI 이전에도 필요하다

많은 프로젝트는 CI가 실패하면 리뷰하지 않는다는 규칙을 둡니다. 이제는 그보다 앞단이 필요합니다. CI가 green이어도 의미 없는 refactor, issue와 연결되지 않은 대형 변경, 테스트 증거 없는 버그 수정, 보안 모델을 오해한 취약점 주장은 리뷰 시간을 잡아먹습니다.

Contribution Intake Gate는 다음 질문을 자동·반자동으로 확인합니다.

이 기준은 오픈소스에만 필요한 것이 아닙니다. 내부 플랫폼 팀도 다른 팀이 AI로 만든 PR을 대량으로 보내기 시작하면 같은 병목을 겪습니다.

3) 보안 리포트는 severity 주장보다 재현성과 영향 범위가 먼저다

AI 도구는 “critical vulnerability"처럼 강한 표현을 쉽게 만듭니다. 하지만 보안 triage에서 중요한 것은 표현 강도가 아니라 조건입니다. 어떤 버전에서, 어떤 설정으로, 어떤 권한을 가진 공격자가, 어떤 데이터에 접근하거나 어떤 행위를 할 수 있는지가 먼저입니다.

보안 리포트 intake 기준은 아래처럼 잡는 편이 안전합니다.

• 재현 절차가 5~10단계 이내로 명확하다.
• affected version과 fixed/unknown version을 구분한다.
• exploit 전제 조건을 적는다. 인증 필요 여부, 네트워크 접근, 설정 플래그를 포함한다.
• 실제 영향이 crash, data leak, privilege escalation, integrity violation 중 어디인지 밝힌다.
• PoC가 있다면 외부 네트워크 호출, secret 출력, destructive action을 포함하지 않는다.
• 단순 bug, hardening suggestion, best practice 논쟁은 security queue가 아니라 issue queue로 보낸다.

curl 사례가 보여주는 것은 “보안 리포트는 항상 최우선"이라는 오래된 반사작용도 재검토해야 한다는 점입니다. 최우선 큐는 신뢰할 수 있는 증거가 있을 때만 의미가 있습니다.

실무 적용

1) PR 템플릿을 증거 중심으로 바꾼다

좋은 템플릿은 긴 설명을 요구하지 않습니다. 리뷰어가 바로 판단할 수 있는 증거를 요구합니다.

## Problem
- Linked issue:
- Reproduction:

## Change
- Scope:
- Files intentionally changed:
- Public API / schema / security impact:

## Evidence
- Tests run:
- Before/after result:
- Known limitations:

## Responsibility
- Did you use AI assistance?
- I have read and understood the generated code:

마지막 문항의 목적은 AI 탐지가 아닙니다. 작성자가 책임을 지도록 만드는 것입니다. “AI가 써줬다"가 면책 사유가 되지 않게 해야 합니다.

2) 리뷰 큐에 들어오기 전 자동 라벨링을 둔다

자동화는 메인테이너를 대체하지 않습니다. 대신 메인테이너가 보기 전에 분류합니다.

권장 라벨:

• needs-repro: 재현 절차 없음
• needs-tests: 테스트 증거 없음
• large-change: diff 500줄 초과 또는 파일 10개 초과
• security-claim: 취약점 주장 포함
• ai-assisted: 작성자 고지 또는 패턴 기반 표시
• owner-required: public API, schema, auth, crypto, build pipeline 변경

숫자 기준은 프로젝트 규모에 맞춰 조정합니다. 작은 라이브러리는 diff 200줄 초과만으로도 대형 변경일 수 있고, 큰 프레임워크는 1,000줄도 일상일 수 있습니다. 중요한 것은 기준이 공개되어 있어야 한다는 점입니다. 기여자는 무엇을 채워야 하는지 알고, 메인테이너는 “왜 아직 리뷰하지 않는지"를 반복 설명하지 않아도 됩니다.

3) maintainer SLO를 둔다

기여자에게만 기준을 요구하면 반쪽입니다. 프로젝트도 리뷰 큐 운영 기준을 가져야 합니다.

• needs-repro 상태가 14일 이상 응답 없으면 close한다.
• CI 실패 PR은 7일 이상 방치하지 않고 자동 안내한다.
• security claim은 48시간 안에 접수 여부만 판단하고, 근거 부족이면 일반 issue로 전환한다.
• maintainer review는 green CI, 작은 diff, 테스트 증거가 있는 PR부터 처리한다.
• 월 1회 저품질 유입 비율, close 사유, maintainer 시간 사용량을 본다.

이 수치를 두면 “기여를 막는다"는 인상보다 “유지 가능한 리뷰 흐름을 만든다"는 메시지가 강해집니다. 오픈소스의 친절함은 무한 대기와 무제한 리뷰를 뜻하지 않습니다.

4) 정책 매트릭스로 자동 처리와 사람 판단을 나눈다

Intake gate를 운영할 때 가장 흔한 실패는 모든 조건을 hard fail로 만드는 것입니다. 그러면 신규 기여자는 작은 실수에도 막히고, 메인테이너는 예외 처리 요청에 시간을 씁니다. 반대로 모든 조건을 warning으로 두면 큐가 정리되지 않습니다. 그래서 조건마다 “자동 차단”, “대기”, “사람 판단"을 나누는 매트릭스가 필요합니다.

이 매트릭스는 저장소의 CONTRIBUTING.md, PR 템플릿, 라벨 설명에 같은 언어로 들어가야 합니다. 자동화가 붙어 있어도 기준이 문서에 없으면 기여자는 봇이 임의로 막는다고 느낍니다. 반대로 기준이 공개되어 있으면 maintainer는 “개인 취향으로 거절한다"는 부담을 줄일 수 있습니다.

롤백 방법도 미리 정해야 합니다. gate가 너무 공격적으로 동작해 정상 PR을 막는다면 해당 라벨을 warning으로 낮추고, 2주 동안 false positive를 기록한 뒤 기준을 조정합니다. bot이 중복 댓글을 남기거나 label thrashing을 만들면 자동 댓글을 끄고 라벨만 남기는 모드로 후퇴합니다. intake gate도 제품 기능처럼 점진 배포와 회귀 대응이 필요합니다.

5) 내부 조직에도 같은 기준을 적용한다

기업 내부에서는 AI PR 문제가 더 조용히 나타납니다. 같은 회사 사람이 보낸 PR이라 거절하기 어렵고, 도구 사용 장려 정책 때문에 품질 기준이 흐려질 수 있습니다. 하지만 플랫폼, 보안, 공통 라이브러리 팀은 오픈소스 메인테이너와 같은 위치에 있습니다. 여러 팀의 변경을 받아야 하고, 잘못된 merge의 비용은 공통 인프라에 쌓입니다.

내부 기준은 더 직접적으로 잡을 수 있습니다.

• platform-owned repo에는 AI-generated 대형 refactor 금지
• schema/auth/build 변경은 담당 owner 승인 전 merge 금지
• AI PR은 테스트 증거와 rollback plan 없으면 draft 유지
• 반복 저품질 PR을 보내는 팀에는 enablement 세션을 제공하되, review bypass는 허용하지 않음

이 흐름은 Review Ops Unified Human Gate와도 맞닿습니다. 사람 리뷰는 마지막 방어선이므로, 그 앞의 큐를 정리해야 합니다.

트레이드오프/주의점

첫째, intake gate가 너무 엄격하면 신규 기여자가 떠날 수 있습니다. 그래서 처음부터 완벽한 문서를 요구하기보다, 위험도가 낮은 작은 PR에는 빠른 안내와 자동 수정 제안을 제공하는 편이 좋습니다.

둘째, AI 사용 여부를 탐지하려 들면 부정확한 판정과 불필요한 갈등이 생깁니다. 더 좋은 기준은 “작성자가 이해하고 테스트했는가"입니다. 사람이 썼어도 설명 못 하고 테스트가 없으면 리뷰 큐에 들어오면 안 됩니다.

셋째, 보안 리포트의 문턱을 높이면 실제 제보가 줄어들 수 있습니다. 따라서 요구사항은 명확해야 합니다. 재현 정보, 영향 범위, 버전, 설정, PoC 안전 조건처럼 필요한 증거를 공개하고, 좋은 리포트에는 빠르게 반응해야 합니다.

넷째, 자동 close는 신중해야 합니다. 저품질 유입을 줄이는 데 효과적이지만, 프로젝트 문화가 차갑게 보일 수 있습니다. close 메시지는 짧고 구체적이어야 합니다. “품질 낮음"이 아니라 “재현 절차가 없어 검증할 수 없음. 이 템플릿을 채워 다시 열어 달라"가 낫습니다.

체크리스트 또는 연습

• PR 템플릿에 문제 재현, 테스트 결과, 변경 범위, AI 사용 여부, 작성자 책임 확인을 넣었다.
• CI green 이전에 사람 리뷰 큐로 들어오지 않도록 라벨과 상태를 분리했다.
• diff size, 파일 수, public API/schema/auth 변경 여부로 owner review 기준을 만들었다.
• 보안 리포트는 severity 주장보다 exploit 조건과 재현성을 우선 보게 했다.
• 7일/14일/30일 기준의 stale PR·needs-repro 처리 정책을 공개했다.
• 자동 gate의 false positive와 maintainer override 사유를 2주 단위로 확인한다.
• 봇 댓글, 라벨, 상태 체크가 중복으로 기여자에게 같은 요구를 반복하지 않는지 점검했다.
• 내부 플랫폼 repo에도 같은 intake gate를 적용했다.

연습:

1. 최근 닫은 PR 20개를 보고 close 사유를 분류해 보세요. 재현 없음, 테스트 없음, 범위 과대, owner 불명, 중복 제안 중 무엇이 많은지 확인합니다.
2. 현재 PR 템플릿을 10줄 이내의 증거 중심 템플릿으로 바꿔 보세요. 설명 문장이 아니라 리뷰 판단에 필요한 항목만 남깁니다.
3. security report intake 기준을 만들어 보세요. 최소 version, 설정, exploit 조건, impact, PoC 안전 조건을 요구하고, 근거 부족 리포트는 일반 issue로 전환하는 절차를 정합니다.

AI 코딩 도구는 계속 좋아질 것입니다. 그럴수록 기여 생성량은 더 늘어납니다. 지속 가능한 프로젝트는 AI를 썼는지 아닌지보다, 검증 가능한 기여만 사람의 주의력을 쓰게 하는 구조를 갖춘 프로젝트가 될 가능성이 높습니다. 이제 오픈소스 운영의 핵심 기술은 코드 리뷰 그 자체만이 아니라, 리뷰할 가치가 있는 변경을 선별하는 intake 설계입니다.