~/오늘의 바이브
Published on

120만 커밋에서 버그 1만개, Codex Security의 충격

Authors
  • avatar
    Name
    오늘의 바이브
    Twitter

120만 커밋, 1만 개의 버그가 쏟아졌다

코드 보안 스캔을 상징하는 녹색 매트릭스 화면

2026년 3월 7일, OpenAI가 Codex Security를 리서치 프리뷰로 공개했다. AI 기반 보안 에이전트다. 취약점을 찾고, 검증하고, 수정안까지 제안한다. 외부 오픈소스 저장소의 120만 커밋을 스캔한 결과가 함께 공개됐다.

수치는 단순하다. 심각(critical) 792건. 고위험(high-severity) 10,561건. 합치면 11,353건이다. 이 중에는 GnuPG, GnuTLS, GOGS, Thorium, OpenSSH, libssh, PHP, Chromium 등 인터넷 인프라의 근간이 되는 프로젝트들이 포함됐다. 발견된 취약점에는 실제 CVE 번호가 부여됐다. 연구실에서 나온 이론이 아니라 현실에서 작동하는 공격 벡터다.

ChatGPT Pro, Enterprise, Business, Edu 고객이 Codex 웹 플랫폼에서 사용할 수 있으며, 한 달간 무료로 제공된다. OpenAI가 코딩 도구를 넘어 보안 도구 시장에 본격적으로 뛰어든 것이다. 코드를 생성하는 AI가 이제 코드를 감시하는 AI까지 만들었다.

Aardvark에서 Codex Security로, 6개월의 진화

Codex Security는 갑자기 튀어나온 제품이 아니다. 2025년 10월, OpenAI는 비공개 베타로 Aardvark라는 보안 도구를 선보인 바 있다. 개발자와 보안팀이 대규모로 취약점을 탐지하고 수정할 수 있도록 설계된 도구였다. 당시에는 제한된 기업 고객에게만 접근이 허용됐고, 외부에 공개된 성과 지표도 없었다.

Codex Security는 그 Aardvark의 진화형이다. 핵심 차이는 프론티어 AI 모델의 추론 능력을 본격적으로 결합했다는 점이다. 단순히 패턴 매칭으로 취약점을 찾는 것이 아니라, 코드의 맥락을 이해하고 실제 위협 수준을 평가한다. 자동화된 검증과 취약점 발견을 결합한 것이다. Aardvark가 "여기 위험해 보이는 코드가 있다"고 했다면, Codex Security는 "이 코드가 왜 위험한지, 어떻게 공격할 수 있는지, 어떻게 고쳐야 하는지"까지 말한다.

6개월 만에 비공개 베타에서 리서치 프리뷰로 올라왔다. OpenAI 기준으로는 빠른 편이다. Aardvark 시절에는 제한된 고객에게만 제공됐지만, 이제 ChatGPT 유료 고객 전체로 문이 열렸다. "리서치 프리뷰"라는 딱지가 붙어 있지만, 실제 CVE를 발견한 결과물을 들고 나온 것은 자신감의 표현이다. 논문이 아니라 성적표를 들고 나왔다.

3단계 프로세스, AI가 보안을 하는 방식

보안 코드 분석 화면

Codex Security의 작동 방식은 세 단계로 나뉜다. 기존 정적 분석(SAST) 도구가 규칙 기반으로 코드를 훑는 것과는 근본적으로 다르다.

1단계: 맥락 분석. 저장소 구조를 분석해 "보안 관련 구조(security-relevant structure)"를 파악한다. 그리고 편집 가능한 위협 모델을 생성한다. 보안 전문가가 아니라 AI가 위협 모델링을 수행하는 것이다. 중요한 건 이 위협 모델이 사람이 수정할 수 있다는 점이다. AI가 맥락을 잡고, 사람이 방향을 교정한다.

기존 도구는 이 단계가 없다. 코드를 받으면 곧바로 규칙을 적용한다. "입력값이 SQL 쿼리에 직접 삽입되면 경고"같은 식이다. 맥락이 없으니 오탐이 넘친다. 테스트 코드의 하드코딩된 쿼리도 "SQL 인젝션 위험"으로 잡히고, 의도적으로 열어둔 디버그 포트도 "미인증 접근 가능"으로 보고된다.

2단계: 취약점 탐지. 1단계에서 확보한 맥락을 기반으로 취약점을 식별한다. 여기서 핵심은 분류 방식이다. 단순히 "이 줄이 위험하다"가 아니라, 실제 영향도(real-world impact) 기준으로 분류한다. 발견된 이슈는 샌드박스 환경에서 "압력 테스트(pressure-tested)"를 거친다. 진짜 공격 가능한지를 AI가 직접 확인하는 것이다.

3단계: 수정 제안. 취약점을 찾는 것에 그치지 않는다. 시스템 동작과 일관된 수정안을 제안한다. 회귀(regression)를 최소화하면서 리뷰와 배포를 간소화하는 방향이다. OpenAI는 The Hacker News에 "Codex Security가 프로젝트에 맞는 환경으로 구성되면, 실행 중인 시스템의 맥락에서 직접 잠재적 이슈를 검증할 수 있다"고 밝혔다.

단계기존 SAST 도구Codex Security
분석패턴 매칭 기반 정적 분석저장소 구조 이해 + 위협 모델 생성
탐지규칙 기반 경고실제 영향도 기반 분류 + 샌드박스 검증
수정없음 또는 문서 링크시스템 맥락에 맞는 코드 수정안 제안
오탐높음 (30~70%)50% 이상 감소

CVE가 쏟아진 프로젝트들

Codex Security가 실제로 발견한 취약점 목록은 구체적이다. 이론적 가능성이 아니라 CVE 번호가 부여된 실제 취약점이다. 각 프로젝트의 성격을 보면 발견의 무게가 더 분명해진다.

GnuPG에서 CVE-2026-24881과 CVE-2026-24882가 발견됐다. GnuPG는 이메일 암호화의 사실상 표준이다. 1997년부터 존재했고, 전 세계 보안 전문가들이 수십 년간 코드를 검토해 왔다. 그런 프로젝트에서 AI가 새로운 취약점 2건을 잡아냈다. 인간이 놓친 것을 기계가 찾은 것이다.

GnuTLS에서는 CVE-2025-32988과 CVE-2025-32989가 확인됐다. GnuTLS는 TLS/SSL 프로토콜의 오픈소스 구현체다. 이 라이브러리의 취약점은 HTTPS 통신 전체의 보안에 영향을 미칠 수 있다. 웹 서버, 이메일 서버, VPN 등 TLS에 의존하는 모든 시스템이 잠재적 영향권이다.

GOGS(Go 기반 Git 서비스)에서도 CVE-2025-64175와 CVE-2026-25242가 나왔다. GOGS는 경량 Git 호스팅 솔루션으로, 소규모 팀과 개인 개발자들이 자체 서버에 설치해 쓰는 경우가 많다. GitHub이나 GitLab을 쓸 수 없는 환경에서 대안으로 선택된다. 보안 전담팀이 없는 환경에서 운영되는 경우가 대부분이라, 취약점이 발견돼도 패치가 늦어질 수 있다. 실질적 위험도가 높다.

가장 많은 CVE가 발견된 프로젝트는 Thorium이다. CVE-2025-35430부터 CVE-2025-35436까지 총 7개의 CVE가 한 프로젝트에서 쏟아졌다. Thorium은 Chromium 기반의 브라우저로, Chromium의 코드를 포크해서 만든 만큼 취약점의 영향 범위가 넓다.

프로젝트발견된 CVE영향 범위
GnuPGCVE-2026-24881, CVE-2026-24882이메일 암호화
GnuTLSCVE-2025-32988, CVE-2025-32989TLS/SSL 통신
GOGSCVE-2025-64175, CVE-2026-25242Git 호스팅
ThoriumCVE-2025-35430~35436 (7건)Chromium 기반 브라우저

이 외에도 OpenSSH, libssh, PHP, Chromium 등에서 추가 발견이 있었다. 눈에 띄는 공통점은 발견된 프로젝트 대부분이 보안이 곧 존재 이유인 인프라 소프트웨어라는 것이다. 가장 많이 감사받은 코드에서 가장 많은 새 구멍이 나왔다.

주목할 점이 하나 더 있다. 이 CVE들은 Codex Security가 발견한 뒤 해당 프로젝트에 보고되어 공식 CVE 번호를 받았다. AI가 찾아낸 취약점이 보안 커뮤니티의 공식 검증 절차를 통과한 것이다. AI의 판단이 인간 전문가의 검증을 받고 인정된 사례로, Codex Security의 탐지 정확도를 간접적으로 뒷받침한다.

오탐률 50% 감소, 숫자 뒤의 진짜 의미

보안 도구의 최대 적은 오탐(false positive)이다. 기존 SAST 도구들의 오탐률은 악명 높다. 연구에 따라 30%에서 70%까지 다양하게 보고된다. 개발자들이 보안 경고를 무시하게 되는 가장 큰 이유다. 경고가 10건이면 그중 5건 이상이 오탐이니, 나머지 진짜 위험한 건도 함께 무시된다. 보안팀이 "이건 진짜 고쳐야 한다"고 말해도 개발팀은 "또 오탐 아니냐"고 반응한다.

Codex Security는 모든 저장소에서 오탐률이 50% 이상 감소했다고 주장한다. 이 수치가 사실이라면 상당히 의미 있다. 기존 도구에서 100건의 경고 중 50건이 오탐이었다면, Codex Security에서는 25건 이하로 줄었다는 뜻이다. 개발자 입장에서 경고의 신뢰도가 두 배 이상 올라간다.

비결은 2단계의 샌드박스 검증에 있다. 패턴 매칭만으로 "이 코드가 위험해 보인다"고 판단하는 것이 아니라, 실제 실행 환경에서 공격 가능성을 테스트한다. 이론적 위험과 실질적 위험을 구분하는 것이다. 테스트 코드에서 하드코딩된 비밀번호를 "자격 증명 유출"로 잡는 식의 오탐은 줄어든다.

물론 이건 OpenAI의 자체 보고서에 기반한 수치다. 독립적인 제3자 검증은 아직 없다. 자기가 만든 도구를 자기가 평가한 결과니, 건강한 회의가 필요하다.

하지만 방향 자체는 맞다. 보안 도구의 가치는 찾아낸 취약점의 수가 아니라, 진짜 위험한 것과 그렇지 않은 것을 구분하는 능력에 달려 있다. SAST 도구가 1,000건을 찾아봤자 개발자가 전부 무시하면 의미가 없다. 보안 업계에는 "경고 피로(alert fatigue)"라는 용어가 있을 정도다. 너무 많은 거짓 경보에 지친 개발자가 진짜 위험한 경고까지 무시하는 현상이다. Codex Security가 100건만 찾더라도 그 100건이 전부 진짜 위험이라면, 그게 1,000건의 오탐 섞인 결과보다 낫다.

Anthropic과의 경쟁, AI 보안 도구 전쟁

AI 보안 기술을 상징하는 디지털 회로 이미지

Codex Security의 등장은 고립된 사건이 아니다. 불과 몇 주 전, Anthropic이 Claude Code Security를 출시했다. 코드베이스를 스캔하고 패치를 제안하는 도구다. AI 보안 도구 시장에서 양대 AI 기업이 거의 동시에 제품을 내놓은 것이다. 우연이라 보기 어렵다. 둘 다 같은 문제를 보고 있다.

접근 방식의 차이가 흥미롭다. Anthropic의 Claude Code Security는 기존 Claude Code 에코시스템의 확장이다. 개발자가 이미 쓰고 있는 Claude Code 안에서 보안 기능을 제공한다. 코딩과 보안이 하나의 워크플로우에 통합된다. 코드를 쓰면서 동시에 보안 검사가 이루어지는 방식이다.

반면 OpenAI의 Codex Security는 독립적인 보안 에이전트다. Codex 웹 플랫폼에서 별도로 작동한다. 보안을 코딩과 분리된 전문 영역으로 다루는 것이다. 개발이 끝난 뒤에 별도로 보안 검사를 수행하는 전통적인 보안 워크플로우에 가깝다. 다만 그 검사의 깊이와 정확도가 기존 도구와는 차원이 다르다.

어떤 접근이 더 효과적일지는 아직 알 수 없다. 통합형은 개발 속도를 유지하면서 보안을 챙기는 "shift-left" 전략에 유리하다. 독립형은 더 깊고 체계적인 분석이 가능하다. 확실한 건 기존 보안 도구 시장에 지각 변동이 시작됐다는 것이다. Snyk, Veracode, Checkmarx 같은 전통 보안 벤더들이 AI 네이티브 도구와 경쟁해야 하는 시대가 왔다.

한 달 무료라는 가격 정책은 시장 점유율을 빠르게 확보하려는 전형적인 플랫폼 전략이다. 기존 보안 도구는 연간 수천만 원의 라이선스 비용을 받는다. OpenAI가 이걸 AI 구독에 포함시키면 가격 경쟁 자체가 성립하지 않을 수 있다. 보안 스타트업 입장에서는 갑자기 OpenAI와 Anthropic이라는 두 거인이 자신들의 시장에 진입한 셈이다. 기존 고객들이 "이미 쓰고 있는 AI 구독에 보안 기능이 포함되는데 굳이 별도 도구를 살 이유가 있나"라고 묻기 시작하면, 기존 벤더들의 입지는 좁아진다.

구분Codex Security (OpenAI)Claude Code Security (Anthropic)
형태독립 보안 에이전트기존 Claude Code 확장
접근Codex 웹 플랫폼Claude Code 내부
방식3단계 분석-탐지-수정코드베이스 스캔 + 패치 제안
가격한 달 무료 (이후 미정)유료 구독 포함

120만 커밋이 말해주는 불편한 사실

숫자를 다시 보자. 120만 커밋에서 심각 792건, 고위험 10,561건. 단순 계산하면 커밋 약 106건당 고위험 취약점 1건이 숨어 있었다는 뜻이다. 물론 이 비율을 그대로 모든 코드에 적용할 수는 없다. 스캔 대상이 보안이 중요한 인프라 소프트웨어에 집중됐을 수 있고, 선별 기준에 따라 수치는 달라진다.

그러나 핵심은 다른 데 있다. 이 프로젝트들은 인류가 가장 많이 검토한 코드다. GnuPG는 1997년부터 존재했다. OpenSSH는 인터넷 인프라의 뼈대다. PHP는 전 세계 웹의 상당 부분을 구동한다. Chromium은 브라우저 시장의 70% 이상을 차지하는 엔진이다. 수천 명의 보안 전문가가 수십 년간 리뷰해 온 코드에서 AI가 새로운 구멍을 찾았다.

이건 인간 보안 전문가가 무능하다는 뜻이 아니다. 코드베이스가 커지고 복잡해질수록 인간의 리뷰만으로는 물리적 한계가 있다는 뜻이다. 한 줄의 코드가 다른 모듈의 맥락에서 어떤 보안적 의미를 갖는지, 수만 개의 상호작용을 동시에 추적하는 건 인간의 인지 능력을 넘어선다. AI는 지치지 않고, 맥락을 잊지 않고, 10만 줄의 코드를 동시에 조망할 수 있다. 여기서 차이가 난다.

2026년은 AI가 코드를 쓰는 속도가 인간이 리뷰하는 속도를 추월한 해이기도 하다. GitHub Copilot, Claude Code, Codex 등 AI 코딩 도구의 보급으로 코드 생산량은 폭발적으로 늘었다. 개발자 92%가 AI 코딩 도구를 사용한다는 조사 결과도 있다. 그런데 보안 리뷰 인력은 그대로다. 늘어난 건 코드뿐이다.

Veracode의 2026년 보고서에 따르면 AI가 생성한 코드의 취약점은 인간 코드의 2.74배다. 코드는 더 빨리, 더 많이 만들어지는데, 그 코드는 더 위험하다. 수동 리뷰로는 절대 따라갈 수 없는 속도다. AI가 하루에 만들어내는 코드를 인간 보안 전문가가 일주일을 들여도 다 리뷰하지 못한다.

도구의 한계를 아는 것이 시작이다

Codex Security의 성과는 인상적이다. 120만 커밋에서 1만 건 이상의 고위험 취약점을 찾아냈고, 실제 CVE가 부여된 결과물을 내놓았다. 오탐률 50% 감소는 기존 보안 도구가 넘지 못한 벽을 넘은 것일 수 있다. GnuPG, GnuTLS 같은 프로젝트에서 새로운 취약점을 발견한 건 AI 보안 도구의 가능성을 구체적으로 증명한다.

하지만 질문은 남는다. 120만 커밋이라는 숫자는 얼마나 대표성이 있는가. 보안이 중요한 프로젝트만 골라 스캔해서 좋은 수치를 뽑아낸 것은 아닌가. 일반적인 웹 애플리케이션이나 모바일 앱 코드에서도 같은 수준의 성과를 낼 수 있을까.

오탐률 감소가 50%라는 건 OpenAI의 자체 보고서이며, 독립적인 제3자 검증은 아직 없다. 한 달 무료 이후의 가격 정책은 어떻게 될까. "리서치 프리뷰"라는 이름은 결과에 대한 책임을 유보하는 장치이기도 하다. 제품이 아니라 연구라고 하면, 오류가 발생해도 "아직 연구 단계"라고 말할 수 있다.

더 근본적인 질문도 있다. AI 보안 도구가 보편화되면, 공격자도 같은 AI를 사용해 공격 벡터를 찾을 것이다. 방어자가 한 수 앞서는 것처럼 보이는 지금의 상황이 얼마나 오래갈까. Codex Security가 GnuPG에서 찾아낸 취약점을, 다른 누군가가 Codex Security 없이도 비슷한 AI로 찾아 공격에 활용할 수 있다. 칼은 양날이다.

AI가 코드를 쓰고, AI가 검증하고, AI가 수정한다. 이 파이프라인에서 인간은 어디에 서야 하는가. OpenAI가 1단계에서 위협 모델을 "편집 가능"하게 만든 이유가 여기에 있을 것이다. 하지만 그 위협 모델을 편집할 보안 전문가가 모든 팀에 있지는 않다.

결국 Codex Security는 도구다. 좋은 도구이지만, 도구일 뿐이다. 보안은 도구가 아니라 프로세스이고, 프로세스를 설계하는 건 여전히 인간의 몫이다. AI가 1만 개의 버그를 찾아줘도, 그걸 수정할지 말지를 결정하는 건, 그리고 수정의 우선순위를 매기는 건, 아직은 사람이 해야 한다.

120만 커밋에서 1만 개의 버그를 찾아낸 건 끝이 아니라 시작이다. 진짜 질문은 "AI가 버그를 찾을 수 있는가"가 아니라 "AI가 찾아낸 버그를 누가 책임지는가"다. Codex Security가 제안한 수정안을 그대로 적용했는데 새로운 취약점이 생기면, 그 책임은 OpenAI에 있는가, 개발팀에 있는가. 도구가 강력해질수록 그 도구에 대한 의존도가 높아지고, 의존도가 높아질수록 도구의 실패가 가져올 충격도 커진다. 가장 위험한 건 도구가 만능이라는 착각이다.


출처