구글이 자사의 오픈소스 버그 바운티 프로그램 중 제품 취약점 수신 창구를 2027년까지 한시적으로 닫았다. 공개된 이유는 AI가 생성한 유효하지 않은 제보가 너무 많아 담당자들이 실제 취약점을 처리할 여력이 사라졌다는 것이다. 프로그램을 중단한 쪽은 구글이지만, 이 상황이 던지는 질문은 구글에 국한되지 않는다.
오픈소스를 적극적으로 활용하거나 직접 관리하는 조직이라면 같은 구조적 문제에 이미 노출되어 있다. AI 도구로 작성한 취약점 보고서, 패치 기여, 이슈 등록이 늘어날수록 리뷰어의 판단 비용은 높아지고, 진짜 문제를 걸러내는 능력은 떨어진다. 보안 프로세스가 AI 자동화의 부산물에 의해 서서히 무력화되는 방식이다.
이 글은 그 상황을 막기 위해 지금 조직 내부에서 정비해야 할 순서와 각 단계에서 확인해야 할 항목을 설명한다.
왜 AI 스팸이 보안 프로세스를 망가뜨리는가
버그 바운티나 취약점 보고 채널은 신호 대 잡음비(SNR)로 작동한다. 보고서가 많아도 질이 고르면 리뷰어는 일정한 속도로 처리할 수 있다. 그런데 AI 생성 보고서가 섞이기 시작하면 두 가지 문제가 동시에 생긴다.
첫째, 형식은 정교하지만 내용이 검증되지 않은 보고서가 늘어난다. LLM이 작성한 취약점 설명은 겉모습이 설득력 있어 보이는 경우가 많다. 리뷰어는 이를 기각하기 위해서도 진짜 보고서를 검토하는 것과 비슷한 시간을 써야 한다.
둘째, 보고서 양이 임계치를 넘으면 처리 자체를 포기하거나 일괄 기각하는 방향으로 기울 수 있다. 구글이 창구를 닫은 것이 그 예다. 문제는 이 결정이 진짜 취약점 제보도 함께 막는다는 점이다.
오픈소스 의존도가 높은 조직은 외부에서 받는 보고서뿐 아니라 내부에서 발신하는 기여물에도 같은 위험이 있다. 팀원이 AI 도구로 생성한 패치나 보안 이슈를 충분히 검토하지 않고 업스트림에 제출하면, 조직 신뢰도 문제로 이어진다.
먼저 정비할 것은 기여자 검증 단계다
모든 보안 관련 기여의 입구에서 기여자 자격을 확인하는 과정이 있어야 한다. 신원 확인 자체보다 기여 이력과 최소한의 맥락 이해가 있는지를 보는 것이 목적이다.
기여자 검증 체크리스트
- 해당 기여자가 이전에 같은 프로젝트에서 유효한 기여를 남긴 이력이 있는가.
- 보고서나 패치가 특정 버전, 환경, 재현 조건을 명시하고 있는가.
- 보고한 취약점이나 변경사항이 실제 코드베이스의 맥락에 부합하는가. 존재하지 않는 함수명이나 의존성을 참조하지는 않는가.
- 신규 기여자라면, 연락 가능한 채널과 조직 내 담당자를 연결할 수 있는가.
이 항목들은 자동화 스크리닝과 사람의 1차 확인을 조합해 처리할 수 있다. 완전히 사람이 하기엔 수고롭고, 완전히 자동화하기엔 맥락 판단이 필요하다는 점에서 하이브리드 접근이 현실적이다.
신규 기여자의 경우, 첫 제출물에 대해서는 처리 시간을 명시한 수신 확인 메시지와 함께 추가 정보 요청 템플릿을 자동으로 보내는 방식도 검토할 만하다. 기여자가 응답하지 않거나 추가 질문에 맥락 없는 AI 답변으로 응하는 경우, 제보 자체의 신뢰도를 낮게 평가하는 근거가 된다.
보고서 품질 기준을 명시하지 않으면 모호함이 기준이 된다
많은 오픈소스 프로젝트와 내부 보안 채널이 보고서 양식을 제공하지만, 각 항목에서 어떤 수준의 응답을 기대하는지 명시하지 않는 경우가 많다. AI 도구가 이런 양식을 채우기 쉬운 이유가 여기 있다. 빈칸을 그럴듯한 문장으로 채우는 것은 LLM이 잘하는 일이다.
품질 기준을 정의할 때 유용한 축은 두 가지다.
하나는 재현 가능성이다. 리뷰어가 동일한 환경에서 문제를 다시 발생시킬 수 있는가. 버전, OS, 의존성 버전, 재현 단계가 구체적일수록 AI 생성 보고서와 실제 검증된 보고서를 구분하기 쉬워진다.
다른 하나는 최소 기술 검증 증거다. 스크린샷, 로그 출력, 개념 증명(PoC) 코드 중 하나 이상이 포함되어야 보고서를 유효한 것으로 간주한다는 기준을 명시할 수 있다. 모든 보고서에 PoC를 요구하는 것이 현실적이지 않다면, 심각도 등급에 따라 요구 수준을 달리하는 방식도 실행 가능하다.
이 기준은 외부 기여자에게 공개 문서로 안내되어야 하고, 내부 리뷰 가이드에도 동일하게 반영되어야 한다. 기준이 공개될수록 무성의한 제출의 통과율이 낮아지고, 진지한 기여자는 제출 전에 스스로 점검하게 된다.
AI 도구 사용 정책은 금지보다 공개 의무화가 실용적이다
기여자나 팀원이 AI 도구를 써서 보고서를 작성하거나 코드를 생성하는 것을 막을 수는 없다. 막으려는 시도도 실효성이 낮다. 그보다는 AI 도구 사용 여부를 제출 시 명시하도록 요구하는 편이 현실적이고 관리하기도 쉽다.
이 정책의 핵심은 AI 사용 자체를 결격 요인으로 보지 않되, 사용했다면 추가 검증 단계를 거친다는 원칙을 세우는 것이다. 예를 들어 AI 보조 작성임을 표시한 보고서는 리뷰 우선순위를 낮추거나, 기여자에게 핵심 항목의 수동 검증을 요청하는 식으로 처리 흐름을 분리할 수 있다.
내부 팀에 대해서는 더 구체적인 기준이 필요하다. 팀원이 AI로 생성한 취약점 분석을 외부에 제출하기 전에 어떤 내부 검토 과정을 거쳐야 하는지를 정하지 않으면, 조직이 의도치 않게 스팸 발신자 역할을 하게 된다. 이 정책은 보안팀뿐 아니라 외부 기여를 담당하는 엔지니어링 팀 전체에 공유되어야 한다.
운영 중에 잡아야 할 조기 신호
검증 체계를 갖추더라도 운영하면서 지속적으로 모니터링해야 할 지표가 있다. 아래 상황이 나타나기 시작하면 프로세스를 다시 점검해야 한다는 신호로 볼 수 있다.
- 제출량 대비 유효 처리율이 눈에 띄게 떨어지고 있다. 이것이 일시적 증가인지 구조적 변화인지를 구분하는 것이 먼저다.
- 리뷰어가 특정 유형의 보고서를 기계적으로 기각하는 패턴이 생겼다. 이는 리뷰 피로의 신호이며, 필터링 기준을 앞 단계로 당겨야 한다는 뜻이기도 하다.
- 동일하거나 유사한 취약점 내용이 다른 기여자 이름으로 반복 제출된다. AI 도구가 같은 프롬프트에서 비슷한 결과물을 대량 생성하는 경우에 나타날 수 있는 패턴이다.
- 기여자가 보완 요청에 응하지 않거나, 추가 질문에 맥락이 없는 답변만 반복한다.
이 신호들을 감지하기 위해 별도의 정교한 도구가 필요한 것은 아니다. 제출 이력을 주기적으로 검토하고, 리뷰어의 부담 수준을 정기적으로 확인하는 것만으로도 조기에 발견할 수 있다.
체계를 갖추기 전에 먼저 확인할 것
위의 항목들을 한꺼번에 도입하려 하면 시작이 어렵다. 지금 당장 가능한 시작점은 세 가지다.
첫 번째, 현재 운영 중인 취약점 수신 또는 기여 채널에서 지난 몇 개월간의 유효 처리율을 실제로 계산해본다. 직감이 아니라 수치로 문제의 크기를 파악하는 것이 우선이다.
두 번째, 보고서 양식이나 기여 가이드에 재현 조건과 최소 증거 항목이 명시되어 있는지 확인한다. 없다면 두 항목만 추가하는 것도 즉각적인 효과가 있다.
세 번째, 팀 내에서 AI 도구로 작성한 보안 관련 제출물을 외부로 보내기 전에 누가, 어떤 기준으로 검토하는지 정해져 있는지 확인한다. 정해진 담당자가 없다면, 그것이 지금 가장 먼저 정해야 할 항목이다.
