SAST가 뭔지, 왜 30년 동안 썼는지

SAST(Static Application Security Testing)는 코드를 실행하지 않고 소스 파일 자체를 분석해서 취약점을 잡는 방법입니다. 원리는 간단합니다. 외부에서 들어온 ‘믿지 못하는 입력값(source)’이 보안 검사 없이 위험한 처리 지점(sink)까지 흘러가면 경보를 울립니다. SQL 인젝션, XSS, 경로 조작 같은 클래식한 버그들을 대규모로 빠르게 걸러내는 데 탁월합니다.

현업에서 널리 쓰이는 이유가 분명합니다. CI/CD 파이프라인에 붙여두면 커밋마다 자동으로 돌고, 결과가 일정하게 나오며, 새로운 코드 패턴이 추가돼도 규칙 집합만 업데이트하면 됩니다. Semgrep, SonarQube, Checkmarx 같은 도구들이 이 방식으로 수십 년간 보안팀의 기본 도구 역할을 해왔습니다.

그런데 SAST에는 구조적인 한계가 있습니다. 코드를 실행하지 않고 분석하기 때문에, 실제로 실행됐을 때 어떤 순서로 어떤 변환이 일어나는지는 정확히 알 수 없습니다. 이 한계를 OpenAI가 정면으로 문제 삼았습니다.

▲ 목차로 돌아가기

Codex Security가 SAST를 시작점으로 쓰지 않는 진짜 이유

OpenAI가 2026년 3월 16일 공식적으로 밝힌 입장은 이렇습니다. “가장 중요한 취약점은 데이터 흐름 문제가 아니다. 코드에 보안 검사가 있어 보이지만, 그 검사가 시스템이 실제로 의존하는 보안 속성을 진짜로 보장하지 못할 때 발생한다.”

공식 발표문에 나오는 구체적인 예를 그대로 가져옵니다. 웹 앱이 JSON 페이로드에서 redirect_url을 추출하고, 허용 목록 정규식으로 검증한 다음, URL 디코딩을 거쳐 리디렉션 핸들러에 넘깁니다. SAST는 이 흐름을 “입력 → 정규식 검사 → URL 디코딩 → 리디렉션”으로 깔끔하게 표시합니다. 문제없어 보입니다. 그런데 정규식이 디코딩 전에 실행됐다면, 디코딩 후에 나오는 값을 그 정규식이 제대로 제한하고 있는 걸까요?

이 지점에서 OpenAI가 내린 결론은 명확합니다. SAST를 시작점으로 삼으면 에이전트가 “이미 다른 도구가 본 영역”에 집중하게 됩니다. 아직 아무도 보지 않은 곳을 처음부터 스스로 탐색하도록 설계하는 것과 근본적으로 다릅니다.

추가로 OpenAI는 SAST 결과물을 에이전트에게 넘기면 생기는 세 가지 문제점을 명시했습니다. 첫째, 에이전트가 기존 도구가 이미 본 영역에만 과도하게 집중하게 됩니다(편향 고착). 둘째, SAST 결과에 내포된 잘못된 가정들이 에이전트 추론 과정에 조용히 섞여들어갑니다. 셋째, 어떤 결과가 에이전트 자체 분석인지, 어떤 결과가 SAST에서 물려받은 것인지 구분할 수 없어 시스템 개선 자체가 어려워집니다.

▲ 목차로 돌아가기

실제로 어떻게 작동하는가 — 공식 설계 흐름

Codex Security는 저장소(repository)를 처음부터 직접 읽습니다. 분석 보고서를 받아서 트리아지하는 게 아닙니다. OpenAI 공식 문서에 나온 작동 방식은 세 단계입니다. (출처: openai.com/index/codex-security-now-in-research-preview/, 2026.03.06)

베타 기간 동안 OpenAI 내부 배포에서 실제 SSRF 취약점, 크리티컬 크로스 테넌트 인증 취약점이 발견됐고 수 시간 내에 패치가 완료됐습니다. 외부 테스터들과의 반복 테스트를 통해 동일 저장소에서 노이즈를 84% 줄였고(출처: OpenAI 공식 발표, 2026.03.06), 과대 심각도 분류 비율은 90% 이상 감소했으며, 위양성 탐지율도 50% 이상 낮아졌습니다.

최근 30일 기준으로 외부 저장소 120만 건 이상의 커밋을 스캔해 크리티컬 792건, 높은 심각도 10,561건을 발견했습니다. 크리티컬 이슈는 스캔된 커밋의 0.1% 미만에서만 등장했습니다. 노이즈 없이 진짜 문제만 필터링된다는 뜻입니다.

▲ 목차로 돌아가기

AI가 코드를 짜면 보안이 나아질까? 데이터가 말하는 것

DryRun Security가 2026년 3월 발표한 연구가 있습니다. Claude Code(Sonnet 4.6), OpenAI Codex(GPT-5.2), Google Gemini(2.5 Pro)에게 두 개의 실제 애플리케이션을 처음부터 만들게 했습니다. 아동 알레르기 관리 웹앱과 멀티플레이어 레이싱 게임입니다. 보안 지침은 프롬프트에 일부러 추가하지 않았습니다. 38회 스캔, 30개 PR을 분석한 결과, 30개 PR 중 26개(87%)에서 취약점이 하나 이상 발견됐습니다. (출처: DryRun Security / helpnetsecurity.com, 2026.03.13)

87%라는 수치가 중요한 이유는 이렇습니다. AI 에이전트가 코드를 빠르게 생산하는 속도만큼 검증되지 않은 취약점도 같은 속도로 쌓인다는 뜻입니다. Codex Security가 필요한 이유가 바로 여기에 있습니다.

솔직히 말하면, Codex가 XSS와 SQL 인젝션에서 0%를 기록한다는 게 충격적입니다. 전체 True Positive Rate도 18%에 불과합니다. 같은 프롬프트를 같은 코드에 세 번 돌리면 결과가 3건, 6건, 11건으로 달라지는 비결정성 문제도 Semgrep이 직접 기록했습니다. (출처: Semgrep Research, 2025.09) Codex Security가 아직 모든 취약점 유형에서 완전한 성능을 내지 못한다는 뜻입니다.

▲ 목차로 돌아가기

지금 무료 체험 가능, 하지만 이 조건을 먼저 보세요

2026년 3월 6일 기준으로 Codex Security는 ChatGPT Pro($200/월), Enterprise, Business($25~30/user/월), Edu 구독자에게 첫 한 달 무료로 제공됩니다. 오픈소스 메인테이너는 ‘Codex for OSS’ 프로그램을 통해 별도 신청이 가능합니다. (출처: openai.com/index/codex-security-now-in-research-preview/, 2026.03.06 / techradar.com, 2026.03.09)

한 가지 더 짚을 부분이 있습니다. 현재는 Codex 웹(chatgpt.com) 인터페이스를 통해서만 접근 가능하고, CLI나 IDE 플러그인 통합은 아직 공식 지원이 안 됩니다. 개발자들이 일상적으로 쓰는 VS Code, JetBrains 환경에서 직접 쓰려면 추가 업데이트를 기다려야 합니다.

오픈소스 메인테이너들과의 실제 협업 결과도 주목할 만합니다. vLLM, GnuTLS, GOGS 등의 프로젝트에서 이미 실제 취약점이 발견되고 패치됐습니다. CVE 번호도 부여됐습니다. 이론이 아닌 현장 검증이 이미 진행 중이라는 점이 이 도구의 신뢰도를 높이는 부분입니다.

▲ 목차로 돌아가기

Codex Security가 아직 못하는 것들

Semgrep 연구에서 확인된 결정적 약점은 XSS와 SQL 인젝션 탐지율이 0%라는 점입니다. 이 두 취약점은 SAST가 전통적으로 가장 잘 잡아내는 영역입니다. Codex Security가 SAST를 대체하는 게 아니라 보완하는 도구라는 것을 OpenAI도 명시했지만, 막상 수치로 보면 “함께 써야 한다”는 말이 더 현실적인 조언이 됩니다.

비결정성 문제도 실무에서 중요합니다. 같은 저장소에 같은 스캔을 반복하면 결과 수가 달라집니다. 취약점 관리 시스템에 통합할 때, 지난번에 발견됐던 이슈가 이번 스캔에서 안 나오면 패치된 것인지, 그냥 이번 실행에서 누락된 것인지 구분하기 어렵습니다.

언어 생태계와 프레임워크 지원도 아직 완전하지 않습니다. 샌드박스 검증 방식은 표준 SAST보다 컴퓨팅 비용이 더 높습니다. 모든 기업 환경에서 바로 쓸 수 있는 단계가 아니라 “Research Preview”라는 이름이 붙은 이유가 있습니다. DryRun 연구가 정리한 현실적인 권장 사항을 인용하면, PR마다 스캔하고 전체 코드베이스 스캔을 병행하고 JWT 기본 설정과 WebSocket 인증 연결 여부를 반드시 별도로 확인해야 합니다.

▲ 목차로 돌아가기

Q&A

▲ 목차로 돌아가기

마치며

Codex Security를 보면서 느낀 건, OpenAI가 SAST를 버린 게 아니라 “SAST가 잘 못하는 영역”을 정확히 겨냥했다는 점입니다. 데이터 흐름은 눈에 보이는데, 그 흐름을 따라가다 보면 체크는 있지만 검사가 실제로 의도한 보안 속성을 보장하지 못하는 경우 — 이런 버그가 CVE가 되고, 침해 사고가 됩니다.

다만 현실도 직시해야 합니다. AI 코딩 에이전트가 만든 PR의 87%에서 취약점이 나오고, Codex Security 자체도 XSS와 SQL 인젝션에서 정확도가 낮습니다. 이 도구가 “쓰면 안전해진다”는 느낌을 주는 방향으로 마케팅될 수 있지만, 지금 단계에서는 SAST와 함께 쓰는 보완 도구가 맞습니다.

무료 체험 기간이 있으니 지금 써보는 건 합리적인 선택입니다. 단, 무료 기간이 끝난 뒤 요금 체계가 어떻게 나올지는 아직 모릅니다. 그 전에 팀 내에서 실제 저장소 한두 개를 돌려보고 판단하는 게 좋을 것 같습니다.

▲ 목차로 돌아가기

본 포스팅 참고 자료

1. OpenAI 공식 블로그 — Codex Security: now in research preview (2026.03.06) 링크
2. OpenAI 공식 블로그 — Why Codex Security Doesn’t Include a SAST Report (2026.03.16) 링크
3. Help Net Security — AI coding agents keep repeating decade-old security mistakes (2026.03.13) 링크
4. AdwaitX — OpenAI Codex Security Skips SAST: Here’s Exactly Why (2026.03.17) 링크
5. TechRadar — OpenAI releases Codex Security to spot the next big cyber risk (2026.03.09) 링크
6. OpenAI 공식 개발자 문서 — Codex Security 링크