AI 에이전트가 쏟아낸 PR, GitHub이 '문'을 닫다
AI-First 팀을 리빌딩하면서 제가 가장 먼저 팀원들에게 강조하는 말이 있습니다. "AI는 동료지만, 검증 없는 동료는 사고를 친다." 최근 Jeff Geerling이 자신의 블로그에서 고발한 현실이 정확히 이 문장을 증명합니다. 300개 이상의 오픈소스 프로젝트를 관리하는 그에게 AI가 생성한 이른바 'slop PR' — 테스트도 안 된 저품질 코드 제안 — 이 폭증했고, curl 유지관리자 Daniel Stenberg는 AI 생성 버그 리포트의 유용성이 15%에서 5%로 추락하자 버그 바운티 프로그램 자체를 중단했습니다(GeekNews 요약).
GitHub이 Pull Request 비활성화 기능을 도입한 것은 상징적입니다. 오픈소스 협업의 핵심 메커니즘인 PR을 아예 꺼야 할 만큼, AI 에이전트가 만들어낸 노이즈가 인간 리뷰어의 한계를 넘어선 겁니다. 문제의 본질은 '노력의 비대칭성'입니다. 예전에는 나쁜 PR을 만들려면 최소한의 수고가 필요했지만, 지금은 클릭 몇 번이면 됩니다. 이건 AI-First 팀 내부에서도 동일하게 적용됩니다. 팀원이 Claude Code로 생성한 코드를 리뷰 없이 올리는 순간, 우리 리포지토리도 오픈소스 생태계가 겪는 바로 그 문제의 축소판이 됩니다.
MCP 서버가 SSH 키를 읽는 데 3초면 충분하다
품질 가드레일만으로는 부족합니다. 보안 방어선이 없으면 AI 도구 자체가 백도어가 됩니다. dev.to에 공개된 mcpwall 개발자의 경험은 소름 끼칩니다. Claude Code에 MCP(Model Context Protocol) 서버를 연결한 지 3초 만에, read_file 호출 하나로 ~/.ssh/id_rsa가 읽혔습니다. 경고도, 프롬프트도, 로그도 없이. MCP는 AI 코딩 도구가 외부 서비스와 통신하는 표준 프로토콜인데, "AI가 결정한 것"과 "서버가 실행한 것" 사이에 정책 레이어가 전혀 없다는 게 핵심 취약점입니다.
Claude Code의 내장 권한은 이진법 — 도구를 허용하거나 거부하거나 — 이라서, read_file을 허용하면 프로젝트 파일과 SSH 키를 구분하지 못합니다. 설치 시점에 도구 설명을 스캔하는 mcp-scan의 탐지율은 학술 테스트에서 120개 중 4개, 즉 3.3%에 불과했습니다. CVE-2025-6514(CVSS 9.6)은 43만 7천 건 이상의 MCP 설치에 영향을 미쳤습니다. AI-First 팀이라면 MCP 도구를 도입할 때 iptables처럼 런타임에서 모든 tools/call의 인자를 검사하는 방화벽 — mcpwall 같은 YAML 기반 정책 레이어 — 을 반드시 끼워야 합니다. "AI로 자동화하면 우리가 더 중요한 일에 집중할 수 있어요"라는 말, 보안 구멍을 막지 않으면 가장 중요한 일이 '사고 수습'이 됩니다.
하나의 LLM으로 모든 걸 해결하려 하지 마세요
품질과 보안 가드레일을 세운 뒤에는, 워크플로우 자체를 최적화할 차례입니다. dev.to의 한 개발자가 공유한 멀티 LLM 4단계 접근법이 흥미롭습니다. Claude Code에 "ADR이 뭐야?"라고 물으면 "Architecture Decision Record. 중요한 결정을 기록하는 것"이라는 무미건조한 답이 돌아옵니다. 개발 에이전트는 구현 맥락에 최적화되어 있기 때문입니다. 그래서 개념 이해는 Gemini나 표준 Claude에게, 베스트 프랙티스는 ChatGPT에게, 다중 소스 종합은 NotebookLM에게 맡기는 분업 구조를 설계한 겁니다.
이걸 팀 차원으로 확장하면 "어떤 LLM에게 무엇을 물어볼지 미리 정해두라"는 원칙이 됩니다. 제가 팀에 적용하고 있는 룰은 단순합니다: 구현 질문은 Claude Code, 설계 검증은 Gemini, 보안 리뷰는 별도의 정적 분석 + LLM 크로스체크. 이렇게 역할을 나누면 "AI가 생성해준 걸 기반으로 우리가 다듬는" 협업 모델이 훨씬 정밀해집니다.
AI-First 팀의 가드레일 설계 원칙
세 소스 기사가 공통으로 가리키는 지점은 하나입니다. AI 코딩 에이전트는 '도입'이 아니라 '제어'가 핵심입니다. 구체적으로 세 겹의 방어선을 제안합니다.
- 품질 가드레일: AI 생성 코드는 반드시 인간이 테스트·리뷰한 뒤 커밋. 'slop PR'을 내부에서 먼저 차단하는 CI 게이트를 설계합니다.
- 보안 가드레일: MCP 등 AI-외부 서비스 연결에는 런타임 정책 레이어(인자 수준 검사, 시크릿 탐지)를 필수 적용합니다.
- 워크플로우 가드레일: LLM별 역할 분담을 팀 컨벤션으로 문서화하고, 단일 LLM 의존도를 낮춰 환각과 편향을 교차 검증합니다.
Geerling은 로컬 오픈모델로 블로그를 이전하면서 "모든 생성 코드를 직접 테스트·검토 후 배포했다"고 밝혔습니다. AI-First라는 말이 'AI에게 전부 맡기기'가 아니라 'AI 생성물을 팀의 품질 기준으로 필터링하는 시스템을 설계하기'라는 뜻이라는 걸, 100개의 slop PR과 3초짜리 SSH 키 탈취가 다시 한번 증명합니다. AI로 리뷰 받아보니까 이런 게 나오더라고요 — 가 아니라, AI의 리뷰를 리뷰하는 구조를 만드는 것. 그게 AI-First 팀 리빌딩의 진짜 출발점입니다.