AI 생성 코드 대응법: 코딩 정책·보안 프롬프트·자동 선별·취약점 트리아지 네 가지 축

핵심 메시지

• 2026년 초 한 계정이 몇 주 만에 100개 가까운 저장소에 수정 사항을 올린 뒤 메인테이너에게 유료 서비스를 제안했고, 스스로 '나는 사람이 아니라 쉬지 않고 일하는 봇'이라고 홍보했다.
• 어떤 메인테이너가 기여 안내문에 '자동화 에이전트라면 풀리퀘스트에 아이콘 세 개를 붙여달라'는 문구를 넣었더니 첫 24시간 신규 PR 상당수가 표시를 달았고, 실제 비율은 70%에 가까울 것으로 추정했다.
• AI는 코드 생성을 싸게 만들었지만 코드 리뷰를 싸게 만들지는 못했다. 기여는 몇 분, 검토는 몇 시간이 드는 역전된 구조가 지금의 병목이다.
• 정책 문서는 길 필요가 없다. 리눅스 커널의 AI 코딩 정책은 130단어 수준이며, 저작권 시비를 피하려면 'co-authored by AI'가 아니라 'assisted by AI'로 표기하라고 권한다.
• 스캐너와 품질 게이트 같은 결정론적 자동화를 AI로 대체하지 말고, AI는 슬롭 선별과 취약점 1차 트리아지를 돕는 보조 수단으로 배치해야 한다.

쉽게 이해하기

레드햇에서 20여 년간 보안 업무를 해 온 로만 주코프는 NDC 토론토 강연을 두 가지 최신 사례로 시작했다. 하나는 짧은 기간에 대규모로 오픈소스 저장소에 기여한 뒤 스스로 봇임을 밝히고 유료 서비스를 영업한 계정이고, 다른 하나는 기여 안내문에 자동화 에이전트 표시를 요구해 실제 AI 기여 비율을 추정해 본 메인테이너의 실험이다. 그는 과거 xz 백도어 사건이 사람 손으로 2년 넘게 신뢰를 쌓아야 가능했던 일이었음을 지적하며, 이제 같은 규모의 압력이 훨씬 짧은 시간에 발생한다고 말한다.

문제의 핵심은 비용의 비대칭이다. 예전에는 기여자가 시간을 들여 코드를 이해하고 리뷰어는 두어 번의 의견 교환으로 병합 여부를 판단했지만, 지금은 몇 분 만에 만들어진 기여가 존재하지 않는 함수나 재현되지 않는 크래시를 근거로 제출되고 메인테이너는 이를 확인하느라 몇 시간을 쓴다. 버그바운티도 같은 압력을 받아, curl은 6년간 10만 달러를 지급하며 운영해 온 프로그램을 AI로 작성된 허위 신고가 늘면서 닫았고 이후 금전 보상 없이 재개했다. 발표자는 프로그램을 닫는 선택이 산업 전체에 잘못된 신호를 준다고 평가한다.

그는 오픈소스 진영의 정책 스펙트럼을 세 갈래로 정리한다. 품질과 법적 문제를 이유로 AI 생성 기여를 전면 금지하고 영구 차단까지 명시한 elementary OS, 18개월에 걸친 합의 과정을 거쳐 조건부 허용 정책을 만든 페도라, 그리고 어차피 상당수가 AI 도움을 받는다는 전제에서 기계가 읽을 수 있는 YAML 형식의 PR 템플릿을 제시해 검토 자동화를 쉽게 만든 프로젝트들이다. 사내 개발에도 같은 스펙트럼이 적용되며, 첫 정책은 60~100단어로 시작해도 충분하다는 것이 그의 조언이다.

대응 방법론은 명확한 정책, 안전한 AI 코딩 습관 학습, 프레임워크와 도구·품질 게이트, 취약점 대응 가속이라는 네 축으로 제시된다. 두 번째 축에서 그는 OpenSSF의 무료 교육과 보안 중심 프롬프트 예시를 소개한다. '사용자 입력을 받는 검색 함수를 작성해줘'라고만 요청하면 XSS나 SQL 인젝션이 섞여 나오지만, 위험한 함수를 쓰지 말고 준비된 질의문을 쓰라는 조건을 프롬프트에 넣으면 결과가 달라진다. 이런 지침은 이제 에이전트 시대의 스킬 파일이나 CLAUDE.md 같은 규칙 파일의 상시 구성 요소가 되어야 한다고 말한다.

세 번째와 네 번째 축에서는 실제 워크플로가 등장한다. 풀리퀘스트가 들어오면 15초 안에 31개 항목을 검사해 AI 슬롭 가능성을 점수화하는 오픈소스 필터(이모지 과다 사용, 커밋 규약 위반, 24시간 내 포크 수 같은 신호를 본다), 그다음 정적 분석과 의존성·라이선스 검사, 그리고 보안 스킬 카탈로그를 붙인 AI 코드 리뷰가 이어진다. 발표자는 사내에서 검증한 128개 규모의 보안 스킬 카탈로그를 공개해 두었다고 밝히며, 라이브 데모에서는 비밀번호 해싱을 고친다며 SQL 인젝션을 함께 들여온 PR을 AI 검토가 근거 링크와 함께 거절 권고로 판정하는 과정을 보여줬다. 취약점 신고 폭증에는 접수 요건 강화, 신고자 평판 확인, AI 1차 트리아지를 단계적으로 배치하되 사람의 최종 확인은 유지하라고 정리한다.

주요 인사이트

• AI 기여 문제를 '품질' 문제로만 보면 대응이 늦는다. 발표자는 슬롭에서 시작해 메인테이너 번아웃, 소셜 엔지니어링, CI/CD 오염, 공급망 침해로 이어지는 위협 상승 피라미드를 제시하며 보안 사고 대응 관점으로 다뤄야 한다고 말한다.
• 정책의 실효성은 길이가 아니라 존재와 가시성에서 나온다. 강연장에서 '조직에 AI 코딩 정책이 있고 모두가 이해한다'에 손을 든 사람은 소수였고, '회사 규칙이 속도를 못 따라간다'에는 훨씬 많은 손이 올라갔다.
• 표기 문구 하나가 법적 리스크를 가른다. 'AI가 공동 저작했다'는 표현은 저작권 논쟁을 부르므로 'AI의 보조를 받았다'로 적는 것이 안전하다는 것이 실무에서 얻은 교훈이다.
• AI 도입이 기존 자동화를 대체하지는 않는다. 정적 분석기와 품질 게이트가 결정론적인 것은 결함이 아니라 설계 의도이며, AI는 그 결과를 워크플로로 엮는 층에 놓아야 한다.
• 데모가 네트워크 문제로 절반만 돌아갔지만, 발표자는 같은 검토를 12번 반복했을 때 지적 항목의 수와 내용이 일정했다고 밝혔다. 순서만 달라졌다는 점이 AI 코드 리뷰를 게이트에 넣을 근거가 된다.

자주 묻는 질문

관련 AI 소식