AI가 오픈소스를 망가뜨린다는 말, 과장일까: 유지보수자 관점에서 본 ‘기여 품질 전쟁’

## 결론 먼저

지금 오픈소스 생태계의 병목은 코드 생성 속도가 아니라 **리뷰 가능한 기여의 비율**입니다. AI가 기여 장벽을 낮춘 건 사실이지만, 유지보수자 입장에서는 ‘검토 가능한 신호’보다 ‘처리해야 할 잡음’이 더 빠르게 늘고 있습니다.

## 왜 이 이슈가 중요한가

최근 논쟁은 “AI가 코드를 잘 쓰느냐”에 집중돼 있지만, 현장 문제는 더 운영적입니다.

GitHub가 2026년 오픈소스 전망에서 말한 핵심도 여기에 닿아 있습니다. AI는 신규 참여를 늘렸지만, 동시에 low-quality 기여(일명 AI slop)를 키워 유지보수 비용을 끌어올렸습니다.

## 차별화 포인트 1: 문제의 본질은 ‘모델 성능’이 아니라 ‘리뷰 대역폭 관리’

많은 팀이 “더 좋은 모델을 쓰면 해결된다”고 기대하지만, 유지보수 관점의 KPI는 다릅니다.

- PR 수 증가율

- 실제 머지율

- 리뷰 1건당 소요 시간

- 반려 후 재제출 품질 개선률

즉, LLM 품질보다 먼저 봐야 할 것은 **인간 리뷰 파이프라인의 처리량과 정책**입니다.

## 차별화 포인트 2: 공격 벡터가 ‘보안 취약점’에서 ‘주의력 고갈’로 이동

과거 오픈소스 리스크는 악성 코드나 취약점이 중심이었습니다. 지금은 여기에 더해, 대량의 저품질 자동 기여가 유지보수자의 판단력을 소모시키는 형태로 바뀌고 있습니다.

이건 단순 불편이 아니라, 장기적으로는

- 핵심 기여자의 번아웃,

- 이슈 대응 지연,

- 보안 패치 우선순위 왜곡으로 이어질 수 있습니다.

## 실무 시사점

### 1) 저장소별 “기여 입장권”을 설계해야 한다

모든 PR을 동일하게 받는 시대는 끝났습니다. 저장소 성격에 따라

- 신규 기여자 경로(이슈 템플릿/작은 태스크 한정),

- 신뢰 기여자 fast lane,

- 자동 생성 코드에 대한 증빙 요구(재현 로그, 테스트 결과)

를 분리해야 합니다.

### 2) AI를 ‘생산 도구’와 동시에 ‘방어 도구’로 써야 한다

생성에만 AI를 붙이면 큐가 폭증합니다. 반대로

- 중복 이슈 탐지,

- 템플릿 준수 여부,

- 최소 재현 가능성 검사

같은 triage 자동화를 먼저 붙이면 유지보수자 시간을 되찾을 수 있습니다.

## 마무리

AI가 오픈소스를 망친다는 표현은 과장처럼 들릴 수 있습니다. 하지만 유지보수자의 운영 지표로 보면, 이미 구조적 스트레스는 시작됐습니다.

핵심은 AI를 금지하느냐가 아니라, **기여 품질을 통제하는 운영면(control plane)을 먼저 세우느냐**입니다.

---

## Sources / References

- Jeff Geerling, *AI is destroying Open Source, and it's not even good yet*

- GitHub Blog, *What to expect for open source in 2026*

- (관련 맥락) Daniel Stenberg, *The end of the curl bug bounty*