Codex Security란 무엇인가 — 출시 배경과 위치

Codex Security는 OpenAI가 2026년 3월 6일 공식 리서치 프리뷰로 출시한 AI 기반 애플리케이션 보안 에이전트입니다. (출처: OpenAI 공식 블로그, 2026.03.06)
단순히 코드를 스캔하는 게 아니라, 취약점을 찾고 → 샌드박스에서 실제 재현 가능한지 검증하고 → 패치까지 제안하는 세 단계 워크플로를 자동화합니다.

이 도구의 전신은 Aardvark입니다. OpenAI가 2025년 10월 내부 도구로 운영하다가 공개한 건데, 이미 Aardvark 단계에서 Next.js의 취약점(CVE-2025-59471, CVE-2025-59472)을 발견해 Vercel에 제보한 이력이 있습니다. 공식 페이지에 직접 기재된 내용입니다.

지금 쓸 수 있는 플랜은 ChatGPT Pro, Enterprise, Business, Edu입니다. 리서치 프리뷰 기간 동안은 무료로 사용할 수 있고, 오픈소스 프로젝트 유지관리자는 별도 신청 폼을 통해 무료 접근 권한을 받을 수 있습니다. (출처: OpenAI 공식 블로그, 2026.03.06)
Plus나 무료 플랜은 현재 포함되지 않는다는 점, 지금 바로 쓰려는 분이라면 먼저 확인할 부분입니다.

▲ 목차로 돌아가기

베타에서 실제로 뭘 찾았나 — 공식 수치 그대로

OpenAI가 공개한 베타 성과는 꽤 구체적입니다. 외부 저장소 120만 건 이상의 커밋을 스캔해서 치명적(Critical) 취약점 792개, 고위험(High-severity) 취약점 10,561개를 발견했습니다. (출처: OpenAI 공식 블로그, 2026.03.06) 전체 저장소 중 치명적 결함이 발견된 비율은 0.1% 미만이었습니다. 숫자만 보면 적어 보이지만, 수십 년간 전문가 리뷰와 퍼징(Fuzzing)을 견뎌온 오픈소스 프로젝트에서 나온 수치라는 점에서 맥락이 다릅니다.

오탐(False Positive) 수치도 공개됐는데, 베타 기간 동안 전체 저장소 대비 오탐률이 50% 이상 감소했다고 OpenAI는 밝혔습니다. (출처: OpenAI 공식 블로그, 2026.03.06) 오탐이 줄었다는 건 실무에서 꽤 중요한 포인트인데, 기존 SAST 도구의 가장 큰 불만이 “결과가 너무 많아서 진짜를 고르기 힘들다”는 것이었기 때문입니다. 그리고 여기서 흥미로운 역설이 나옵니다.

▲ 목차로 돌아가기

SAST를 일부러 쓰지 않는 이유 — 설계 철학 분석

OpenAI는 2026년 3월 16일, Codex Security가 SAST 리포트를 시작점으로 삼지 않는 이유를 공식 문서로 따로 발표했습니다. 핵심 논리는 이렇습니다. SAST는 “입력이 오염된 소스에서 위험한 싱크로 흐르는가”를 추적하는 도구입니다. 데이터 흐름을 잘 잡아내지만, 정작 중요한 질문 — “그 검사가 실제로 보안 속성을 보장하는가”는 답할 수 없습니다. (출처: OpenAI 공식 문서 whyCodexSecurityDoesntIncludeSAST, 2026.03.16)

OpenAI가 든 구체적 예시가 인상적이었습니다. 어떤 웹 앱이 JSON 페이로드를 받아서 리다이렉트 URL을 추출하고, 허용 목록 정규식으로 검증한 다음 URL 디코딩을 거쳐 리다이렉트 핸들러에 넘기는 흐름을 생각해보면, SAST는 “정규식 체크가 있다”를 감지할 수 있습니다. 그런데 그 체크가 URL 디코딩 이전에 실행된다면? 정규식을 통과해도 디코딩 이후에 제약이 사라집니다. CVE-2024-29041이 딱 이 경우였습니다. Express.js에서 수년간 발견되지 않았던 오픈 리다이렉트 취약점인데, 데이터 흐름은 SAST로 보이지만 변환 체인의 순서 문제는 보이지 않았습니다.

Codex Security의 접근 방식은 다릅니다. 저장소 아키텍처를 먼저 읽고 시스템이 보장하려는 속성이 무엇인지 파악한 다음, 그 속성을 직접 반증(Falsify)하려 시도합니다. 구체적으로는 마이크로 퍼저 작성, z3-solver를 이용한 정수 오버플로 제약 해결, 샌드박스 환경에서 End-to-End PoC(개념 증명) 생성까지 자동화됩니다. “의심스럽다”에서 “실제 문제다, 여기 증거다”까지 가는 겁니다.

OpenAI는 SAST를 쓰지 말라는 게 아닙니다. 공식적으로 “SAST는 알려진 패턴을 대규모로 탐지하는 데 여전히 가치 있다”고 못 박았습니다. 다만 Codex Security는 SAST가 구조적으로 볼 수 없는 영역, 즉 로직 레벨과 상태 불변식(Invariant) 문제를 겨냥합니다.

▲ 목차로 돌아가기

True Positive Rate 18%의 진짜 의미

Semgrep 연구팀이 2025년 9월 발표한 벤치마크에서는 11개의 대형 실제 Python 웹 애플리케이션(Django, Flask, FastAPI)을 대상으로 Codex(v0.2.0, o4-mini 기반)를 테스트했습니다. Codex가 생성한 전체 보안 탐지 결과를 수동으로 검토한 결과, 전체 True Positive Rate는 18%였습니다. (출처: Semgrep Security Research, 2025.09) 100개 결과를 받으면 실제 취약점은 18개라는 뜻입니다.

Path Traversal에서 47%로 상당한 강점을 보인 반면, IDOR·SQL Injection·XSS에서는 정탐률이 0%였습니다. Semgrep은 XSS와 SQL Injection 같은 인젝션 유형에서 이런 결과가 나온 이유로 “프로시저 간 데이터 흐름 분석의 한계”를 꼽았습니다. SAST를 쓰지 않는 Codex Security가 정작 SAST 방식으로 잘 잡히는 주입형 취약점에서 약한 건 아이러니한 결과입니다.

여기에 비결정성(Non-determinism) 문제도 있습니다. 같은 코드베이스에 동일한 프롬프트를 세 번 실행하면 결과가 매번 다릅니다. Semgrep 실험에서 동일 애플리케이션에 대해 세 번 연속 스캔했더니 탐지 결과가 3개, 6개, 11개로 달랐습니다. 취약점을 “고쳤다”고 판단했는데 다음 스캔에서 사라졌을 때, 그게 정말 수정됐기 때문인지 확인할 방법이 없다는 뜻입니다.

▲ 목차로 돌아가기

Claude Code Security와 직접 비교했을 때

Anthropic도 OpenAI 출시 14일 전인 2026년 2월 20일, Claude Code Security를 Enterprise·Team 고객 대상으로 먼저 출시했습니다. (출처: VentureBeat, 2026.03.10) 두 회사가 독립적으로 같은 결론에 도달했다는 점이 흥미롭습니다. 패턴 매칭 기반 SAST로는 잡을 수 없는 취약점 유형이 실제로 존재한다는 것이죠.

DryRun Security가 2026년 3월 발표한 비교 연구는 Claude Code(Sonnet 4.6 기반), Codex(GPT-5.2 기반), Gemini(2.5 Pro 기반) 세 에이전트를 30개의 풀 리퀘스트에 적용해 결과를 수동 검토했습니다. 30개 중 26개에서 적어도 하나의 취약점이 발견됐고, 발견 비율은 87%였습니다. (출처: DryRun Security, 2026.03) 생각보다 훨씬 많은 보안 결함이 AI 에이전트 생성 코드에 들어간다는 뜻입니다.

흥미로운 지점이 있습니다. Checkmarx Zero의 테스트에서는 Claude Code Security가 전체 프로덕션급 코드베이스를 스캔했을 때 8개 취약점을 보고했지만 실제 True Positive는 2개뿐이었습니다. (출처: VentureBeat, 2026.03.10) Codex Security가 18%, Claude Code Security가 이 케이스에서 25%였지만, 어느 쪽도 독립 감사를 통과한 수치가 아니라는 점은 두 도구 모두에 해당하는 공통 주의사항입니다.

그렇다면 어느 쪽이 나은가. 단일 정답은 없습니다. Codex Security는 Path Traversal과 SSRF에서 앞서고, Claude Code Security는 IDOR(22%)에서 강세를 보입니다. 두 도구를 같은 저장소에 병렬로 돌려 차이를 비교하는 것이 현시점에서 가장 현실적인 사용 방식입니다.

▲ 목차로 돌아가기

지금 당장 쓸 수 있는 사람과 아닌 사람

솔직하게 정리하면 이렇습니다. Codex Security는 지금 연구 프리뷰 단계입니다. 아직 모든 언어 생태계와 프레임워크 유형에서 커버리지가 완성됐다고 보기 어렵습니다. OpenAI도 이 부분을 공식 문서에서 직접 인정하고 있습니다.

vLLM 프로젝트는 이미 Codex Security를 실제 코드베이스에 적용 중이고, OpenAI는 오픈소스 프로젝트들과 협업을 이어가고 있습니다. 리서치 프리뷰 특성상 사용량 제한이 있고, 샌드박스 검증 방식이 일반 SAST보다 컴퓨팅 비용이 더 든다는 점도 고려할 필요가 있습니다.

개인적으로는, 지금 단계에서 Codex Security를 기존 SAST를 대체하는 용도로 쓰는 건 시기상조입니다. 두 도구가 보는 취약점 유형이 구조적으로 다르기 때문에 하나가 나머지를 대신할 수 없습니다. Snyk이 지적한 것처럼, 찾는 것보다 대규모 저장소에서 수정하는 것이 병목인 팀이라면 이 도구가 패치 제안 기능에서 더 많은 가치를 줄 수도 있습니다.

▲ 목차로 돌아가기

Q&A

▲ 목차로 돌아가기

마치며

Codex Security가 진짜로 의미 있는 이유는 “AI가 취약점을 찾는다”는 것보다, 기존 정적 분석이 구조적으로 볼 수 없었던 취약점 유형을 공략한다는 점입니다. 수십 년간 전문가 리뷰와 퍼징을 견뎌온 GnuTLS·GOGS에서 CVE가 나왔다는 사실이 그걸 증명합니다.

그런데 막상 써보면 다릅니다. IDOR·XSS·SQL Injection에서 정탐률 0%라는 수치는, 이 도구가 모든 취약점을 잘 잡는다는 기대를 정면으로 흔듭니다. Codex Security는 “SAST보다 낫다”는 도구가 아니라 “SAST가 못 보는 것을 본다”는 도구입니다. 그 차이를 이해하고 나면, 어디에 써야 하는지가 명확해집니다.

지금 단계에서 가장 실용적인 활용법은 기존 SAST 파이프라인을 유지하면서, Codex Security를 로직·상태 레벨 취약점을 잡는 보완 도구로 병렬 운용하는 것입니다. 두 도구가 같은 저장소에 대해 내놓는 결과의 차이, 바로 거기서 기존에 보이지 않던 취약점 지형도가 만들어집니다.

▲ 목차로 돌아가기

본 포스팅 참고 자료

1. OpenAI 공식 블로그 — Codex Security: now in research preview (2026.03.06) https://openai.com/index/codex-security-now-in-research-preview/
2. OpenAI 공식 문서 — Why Codex Security doesn’t include SAST (2026.03.16) https://openai.com/index/why-codex-security-doesnt-include-sast/
3. The Hacker News — OpenAI Codex Security Scanned 1.2 Million Commits (2026.03.07) https://thehackernews.com/2026/03/openai-codex-security-scanned-12.html
4. VentureBeat — Anthropic and OpenAI just exposed SAST’s structural blind spots (2026.03.10) https://venturebeat.com/security/
5. Semgrep Security Research — AI Agent Security Benchmark (2025.09) / AdwaitX 분석 https://www.adwaitx.com/openai-codex-security-no-sast-report/
6. OpenAI 공식 개발자 문서 — Codex Security https://developers.openai.com/codex/security