OpenAI가 보안 스캐너를 공짜로 풀었다 — Snyk와 Semgrep은 이제 뭘 먹고 사나

개발자 도구 시장에서 가장 무서운 문장은 “OpenAI가 그거 오픈소스로 풀었대"입니다. OpenAI가 Codex 기반 보안 스캐너를 공개하면서, 코드 취약점을 찾아 고치는 일이 유료 SaaS의 영역에서 CLI 한 줄로 내려왔습니다. 문제는 이게 기존 보안 도구 회사들만의 위기가 아니라는 점인데요, AI가 만들어낸 취약점 보고서를 누가 검증할 것인가라는 더 골치 아픈 질문이 따라옵니다.

먼저 솔직하게 짚고 가겠습니다. 이번 주제는 커뮤니티 데이터가 거의 없습니다. 지난 30일간 레딧에서 확인된 관련 스레드가 0건이었습니다. 그래서 이 글은 “커뮤니티가 이렇게 반응했다"는 여론 리포트가 아니라, 이 변화가 어떤 구조적 의미를 갖는지를 따져보는 분석에 가깝습니다. 다만 데이터 부재 자체도 신호입니다. 보안 도구는 개발자가 트위터에서 열광하는 종류의 물건이 아니라, 조용히 CI 파이프라인에 꽂아놓고 잊어버리는 물건이거든요. 화제성이 낮다고 파급력이 낮은 건 아닙니다.

AI 보안 스캐너가 기존 도구와 다른 점

지금까지의 정적 분석 도구는 대부분 패턴 매칭이었습니다. Semgrep이 대표적인데요, “이런 모양의 코드는 SQL 인젝션 위험이 있다"는 규칙을 사람이 미리 써두고, 코드베이스를 훑으면서 그 모양과 일치하는 곳을 찾아냅니다. 빠르고 결정론적입니다. 같은 코드를 백 번 스캔하면 백 번 같은 결과가 나옵니다.

Snyk 같은 도구는 다른 축을 공략했습니다. 의존성 트리를 파고들어서 “당신이 쓰는 라이브러리의 하위 의존성 어딘가에 알려진 CVE가 있다"를 알려주죠. 이건 사실상 데이터베이스 조회 문제입니다. 취약점 DB를 얼마나 잘 관리하느냐가 경쟁력이었습니다.

AI 스캐너는 세 번째 축입니다. 코드의 의미를 읽습니다. 규칙에 없는 형태여도, 이 함수가 사용자 입력을 받아서 검증 없이 파일 경로로 쓰고 있다는 걸 문맥으로 파악합니다. 여러 파일에 걸쳐 있는 취약점, 비즈니스 로직의 허점, 인증 우회 경로처럼 “규칙으로 쓰기 어려운” 것들이 여기 걸립니다. 게다가 찾은 다음에 패치까지 써줍니다.

왜 지금 시장이 흔들리는가

애플리케이션 보안 도구 시장의 비즈니스 모델은 단순했습니다. 규칙 세트가 곧 자산이었습니다. 수년간 축적한 탐지 규칙, 큐레이션된 취약점 DB, 오탐을 줄이려고 다듬어온 튜닝 노하우. 이걸 개발자 시트당 연간 수십에서 수백 달러에 팔았습니다.

AI 모델이 코드를 읽고 취약점을 추론할 수 있다면, 그 규칙 세트의 해자가 얕아집니다. 게다가 오픈소스로 풀렸다면 진입 장벽 자체가 사라집니다. 남는 차별화 요소는 기업 환경에서의 정책 관리, 규제 대응용 감사 로그와 컴플라이언스 리포트, 대규모 조직에서 수만 개의 리포지토리를 다루는 운영 능력 정도입니다. 다 중요하긴 한데, 하나같이 “코어 기술"이 아니라 “주변 인프라"입니다.

이건 익숙한 패턴입니다. 코드 자동완성 도구 시장이 그랬고, 문서 검색 도구 시장이 그랬습니다. 모델이 잘하게 된 영역은 상품화되고, 회사들은 워크플로우와 거버넌스 쪽으로 밀려납니다. 그 자리가 나쁜 자리는 아닙니다. 다만 마진이 다릅니다.

AI가 뱉은 취약점 보고서, 어디까지 믿나

여기가 진짜 문제입니다. 오픈소스 커뮤니티는 이미 이 문제로 몸살을 앓고 있습니다. curl 프로젝트의 관리자가 AI로 생성된 가짜 취약점 신고 때문에 버그 바운티 운영이 어렵다고 공개적으로 토로한 게 대표적인 사례입니다. 그럴듯한 문장, 그럴듯한 CVE 형식, 그럴듯한 코드 인용. 그런데 실제로는 존재하지 않는 취약점입니다.

AI 보안 스캐너의 오탐은 기존 정적 분석의 오탐과 성격이 다릅니다. Semgrep이 오탐을 내면 “아, 이 규칙이 너무 넓게 잡네"하고 규칙을 보고 판단할 수 있습니다. 원인이 눈에 보입니다. AI가 오탐을 내면 설명이 그럴듯해서 검증에 더 오래 걸립니다. 취약점을 설명하는 문단이 논리적으로 완결되어 있으니까요. 리뷰어가 코드를 직접 따라가 보기 전까지는 진짜인지 알 수 없습니다.

그리고 결정론이 깨집니다. 같은 코드를 두 번 스캔했는데 결과가 다르면, CI 파이프라인에서 무엇을 기준으로 빌드를 실패시킬까요. 어제는 통과했는데 오늘은 막히는 빌드는 팀이 가장 빨리 무시하게 되는 종류의 경고입니다.

자동 패치가 더 위험할 수도 있습니다

“찾아주고 고쳐준다"는 매력적으로 들립니다. 그런데 보안 패치는 일반 버그 수정과 다릅니다. 잘못 고치면 취약점이 사라진 게 아니라 다른 곳으로 옮겨갑니다. 입력 검증을 추가했는데 우회 가능한 검증이라면, 이제 팀은 “그 부분은 처리했다"고 믿게 됩니다. 아무것도 안 한 상태보다 나쁩니다.

특히 위험한 조합은 이겁니다. AI가 취약점을 찾고, AI가 패치를 쓰고, AI 코드 리뷰어가 그 패치를 승인합니다. 사람이 회로 안에 한 번도 들어오지 않습니다. 각 단계는 그럴듯하고, 전체 결과는 검증되지 않았습니다. 도구가 편할수록 이 경로로 흘러가기 쉽습니다.

현실적인 사용법은 AI 스캐너를 차단 게이트가 아니라 우선순위 정렬기로 쓰는 겁니다. 빌드를 막지는 않되, 사람이 볼 목록의 순서를 정하게 하는 거죠. 기존 규칙 기반 도구는 결정론이 필요한 자리에 그대로 두고요. 그리고 진짜 취약점이면 재현 가능한 증거를 요구해야 합니다. 설명이 아니라 실행 가능한 PoC 말입니다.

그래서 누가 이득을 보나

가장 큰 수혜자는 보안 팀이 없는 소규모 조직입니다. 지금까지는 정적 분석 도구 라이선스를 살 예산이 없어서 아예 아무것도 안 하던 팀들이 있었습니다. 이들에게 “무료 + 로컬 실행 + 컨텍스트 이해"는 0에서 1로 가는 변화입니다. 오탐이 30% 있어도 아무것도 안 하는 것보다는 낫습니다.

반대로 이미 성숙한 보안 프로세스를 가진 조직에게는 추가 소음일 가능성이 높습니다. 이미 규칙 기반 도구가 돌고 있고, 트리아지 프로세스가 있고, 담당자가 있습니다. 여기에 검증 부담이 큰 새 신호원을 하나 더 붙이는 게 순이득인지는 따져봐야 합니다.

그리고 아무도 이야기하지 않는 수혜자가 하나 더 있습니다. 공격자입니다. 취약점을 찾는 도구는 방어자와 공격자가 똑같이 씁니다. 오픈소스 코드베이스를 대규모로 스캔해서 아직 알려지지 않은 취약점을 찾는 일이, 이제 훨씬 싸졌습니다. 패치가 나오는 속도와 익스플로잇이 나오는 속도가 동시에 빨라지는 경주가 시작된 셈입니다.

마무리

보안 도구의 가치는 “취약점을 찾아내는 능력"에서 “찾아낸 것 중 진짜를 골라내는 능력"으로 옮겨가고 있습니다. 찾는 건 이제 싸졌으니까요. 앞으로 경쟁력은 탐지가 아니라 검증에서 나옵니다.

여러분의 팀이라면 어떻게 붙이시겠습니까. CI에서 빌드를 막는 게이트로 쓰시겠습니까, 아니면 사람이 검토할 목록의 정렬 기준으로만 쓰시겠습니까. 이 선택이 앞으로 몇 년간 개발팀의 보안 문화를 갈라놓을 것 같습니다.