AI 슬롭이 구글을 멈췄다, 작은 팀이 길러야 할 것

구글 오픈소스 보안 포상 프로그램(OSPS)이 일시 동결됐다. 새 제출을 아예 받지 않겠다는 결정이었다. 원인은 보안 취약점이 너무 적어서가 아니다. AI가 생성한 제출물이 너무 많아서였다.

핵심부터 말하면, 이건 AI가 "생산"을 가속했을 때 병목이 "평가"로 이동한다는 걸 구글이 공식으로 인정한 사건이다. 이 이동은 채용·코드 리뷰·콘텐츠 검토 전반에서 이미 진행 중이다. 버그 바운티 동결처럼 눈에 띄는 형태로 드러나지 않았을 뿐이다. 그리고 "검수 인력을 늘리는" 방식으로 대응할 수 없는 작은 팀이, 사실 더 큰 위험에 놓여 있다.

버그 바운티는 먼저 포화된 채널이다

보안 연구는 AI 도구를 가장 빠르게 흡수한 분야 중 하나다. Semgrep이나 CodeQL 같은 정적 분석 도구에 LLM 기반 보고서 생성이 붙으면, 공개 저장소 하나를 돌리는 것만으로 수십 개의 그럴듯한 취약점 보고서가 나온다. 진입 비용이 거의 없어졌다.

문제는 그 보고서가 실제로 익스플로잇 가능한지, 아니면 패턴만 유사한 false positive인지는 여전히 사람이 판단해야 한다는 점이다. 리뷰어 한 명이 하루에 처리할 수 있는 건수는 고정인데, 제출 속도가 기하급수적으로 늘면 결국 대기열이 터진다. 구글이 그 벽에 부딪혔다.

HackerOne, Bugcrowd 같은 주요 플랫폼들도 같은 흐름을 경험하고 있다. AI 생성 제출물 비중이 빠르게 늘면서 리뷰어 1인당 처리 시간이 늘어났고, 일부 기업 프로그램은 이미 사전 심사 단계를 강화했다. 구글의 동결은 이 흐름의 가장 가시적인 사례일 뿐, 업계 전반의 현상이다.

이 패턴이 버그 바운티에서만 나타난다고 보면 오산이다. 채용 공고의 지원서, 기고·협업 제안, 오픈소스 이슈 트래커, 학술지 심사 큐 — 전부 같은 구조다. 한 채널이 먼저 포화되고, 그다음 채널이 줄 서서 기다리고 있다.

작은 팀에게 더 가혹한 이유

구글은 리뷰어를 늘리거나 자동화 필터를 추가하면서 버텼다. "일시 동결"이라는 표현처럼, 준비가 되면 재개할 수 있다. 리소스가 있기 때문에 가능한 대응이다.

작은 팀은 다르다. 노이즈 한 건이 팀원 한 명의 집중력 두 시간을 잡아먹는다. 전담 트리아지 인력은 없고, 모든 검토는 실무자가 직접 소화한다. 대기열이 쌓이면 진짜 중요한 것과 그렇지 않은 것을 구분하는 대신, 전체를 무시하거나 빠르게 훑고 넘기는 방향으로 흘러간다. 그게 또 다른 종류의 리스크다.

AI 산출물이 넘치는 환경에서 작은 팀의 방어선은 팀원 한 명 한 명의 평가 감각이다. 대기업은 규모로 버티지만, 우리는 판단력으로 버텨야 한다. 그렇다면 채용 기준도, 내부 역량 개발 방향도 그 감각을 키우는 쪽으로 재편될 수밖에 없다.

우리가 실제로 마주쳤던 것

HEDVION은 콘텐츠 자동화 봇을 여러 개 운영한다. AI가 글을 생성하고, 다른 AI가 검수해 OK/REJECT를 판정하는 파이프라인이다. 겉보기엔 깔끔하다.

직접 운영해보니 예상보다 빠르게 한계가 드러났다. AI 검수자가 체계적으로 잡지 못하는 오류 유형이 있었다. "그럴듯한 수치를 포함한 허위 사실"이 대표적이었다. 생성 모델이 자연스럽게 만들어내고, 검수 모델이 표면적 그럴듯함만 보고 통과시키는 패턴이다. 생성과 검수가 같은 학습 패턴 기반에서 나왔기 때문에, 양쪽이 동시에 틀리는 지점이 존재한다.

결국 사람이 주기적으로 끼어들어 "AI가 AI를 체계적으로 못 잡는 유형"을 식별하고, 검수 프롬프트에 반영하는 루틴을 따로 만들었다. 이게 없으면 파이프라인이 시간이 지나면서 조용히 표류한다. Google OSPS가 자동화 필터가 있어도 결국 사람 검토 없이는 버티지 못한 것과 정확히 같은 구조다.

한국인공지능소프트웨어산업협회(KAIIPA)를 비롯한 국내 AI 업계 단체들이 'AI 리터러시' 논의에서 빠지지 않고 다루는 지점도 여기다. 도구를 쓸 줄 아는 능력과, 도구 산출물의 품질을 의심할 줄 아는 능력은 완전히 다른 것이다.

병목이 이동하면 채용 기준도 달라진다

AI 이전에는 병목이 "생산"이었다. 코드를 짜고, 글을 쓰고, 버그를 찾는 것 — 전부 사람의 시간이 제약이었다. AI가 생산을 가속하자 병목이 "평가"로 이동했다. 수백 개의 버그 리포트 중 진짜를 고르는 것, 수십 개의 지원서 중 실력자를 찾아내는 것, AI가 만든 코드 중 실제로 안전한 걸 판별하는 것. 이 모든 게 새로운 병목이다.

작은 팀에서 지금 필요한 사람은 단순히 "AI 도구를 잘 쓰는 사람"이 아니다. "AI 산출물의 실패 패턴을 알고, 잘못된 아웃풋을 빠르게 식별하는 사람"이다. 전자는 이미 흔해졌다. 후자는 여전히 드물다.

이 판단력을 면접에서 어떻게 확인하는가. 지원자에게 AI가 만든 문서를 주고 "이 내용에서 확인이 필요한 부분을 표시해보세요"라고 하면, 반응이 두 종류로 나뉜다. 전체적으로 괜찮아 보인다고 답하는 부류가 있다. 반면 인용 출처 없는 수치, 너무 매끄럽게 연결된 논리, 약간 어색한 전문 용어 사용을 바로 짚어내는 부류도 있다. 두 번째 반응이 나오면 그 사람은 이미 AI 아웃풋을 다량으로 다뤄본 경험이 있다는 뜻이다. 그 경험이 지금 팀에 필요한 것이다.

지금 바로 적용할 수 있는 것

팀 내 "AI 아웃풋 감사" 루틴을 만들어라. 주기적으로 AI 생성 결과물 일부를 무작위로 뽑아 직접 검토하는 시간이다. 우리 기준으로는 봇 발행분 중 주 1회 5건을 직접 읽는다. 자동 검수가 놓친 패턴이 나오면 프롬프트에 즉시 반영한다. 이 루틴 없이는 AI 검수 파이프라인이 서서히 표류한다. 운영하는 규모가 작을수록 표류가 더 빨리 누적된다.

채용 과제에 "AI 결과물 비판적 검토" 항목을 실기로 넣어라. 이력서에 "AI 활용 능력"이 적혀 있다고 가산점을 줄 게 아니다. AI가 만든 코드나 문서를 30분 동안 검토하고 문제를 찾는 실기 과제가 훨씬 실용적이다. 특히 "AI가 잘 못 잡는 실수 유형"을 후보자가 알고 있는지 여부가 이 과제에서 명확하게 갈린다.

외부 인풋 채널에 간단한 사전 필터를 달아라. 버그 리포트든, 콘텐츠 기고든, 파트너십 제안이든 — "구체적 재현 경로 없이 추상적 서술만 있는 제출물"은 일단 반려하는 기준 하나만 세워도 트리아지 부담이 크게 줄어든다. AI 생성 여부를 100% 잡을 수는 없지만, 구체성 없는 제출물을 걸러내는 것만으로도 충분한 효과가 있다.

"AI 슬롭 저항성"을 팀 문화로 박아라. AI 산출물을 읽을 때 한 번은 의심하고, 구체성이 빠진 주장을 그대로 신뢰하지 않는 기준을 공유하는 것이다. 시스템이 판단을 대신하는 게 아니라 사람이 시스템 위에서 최종 판단한다는 감각을 유지하는 것. 구글이 동결로 배운 교훈을, 우리는 동결 전에 적용할 수 있다.

원문: AI News & Artificial Intelligence | TechCrunch