OpenAI Codex 보안 정책에서 SAST 리포트가 빠진 이유

Codex로 코드를 뽑아보면 꽤 그럴듯한 결과가 나옵니다. 그런데 한 가지 이상한 점이 있어요. 생성된 코드에 대한 보안 스캔 결과—그러니까 SAST(정적 애플리케이션 보안 테스트) 리포트 같은 건 어디에도 없습니다. 같이 나와주면 편할 텐데, OpenAI는 의도적으로 이걸 빼놨습니다.

"아직 안 만들었다"가 아니라, 만들지 않기로 한 겁니다. 코드 생성 도구와 보안 검증 도구의 역할을 의도적으로 분리하겠다는 OpenAI의 설계 철학이 깔려 있어요. 왜 그런 결정을 내렸는지, 그리고 Codex를 CI/CD 파이프라인에 넣으려는 팀이 뭘 해야 하는지 정리해봤습니다.

Codex 보안 정책이 실제로 커버하는 것

Codex의 보안 장치는 크게 두 갈래로 나뉩니다. 첫 번째는 생성 단계 필터링 입니다. 악성 코드나 사이버 공격 도구, 취약점 익스플로잇 코드를 요청하면 거부하는 콘텐츠 정책이에요. ChatGPT 전반에 걸친 사용 정책과 같은 맥락입니다.

두 번째는 좀 더 미묘한데, 출력 품질에 대한 면책 입니다. 생성된 코드가 보안상 안전하다는 보장을 명시적으로 하지 않아요. 코드를 만들어주긴 하지만, 그게 실제로 안전한지 확인하는 건 쓰는 사람 몫이라는 거죠. OpenAI 공식 사용 정책 문서 에도 이 점이 일관되게 명시되어 있습니다.

쉽게 말해서, Codex는 "코드를 제안하는 도구"이지 "코드베이스를 감사하는 도구"가 아닙니다. 이 구분을 무시하고 도입하면 보안 공백이 생겨요.

SAST 리포트를 왜 안 넣었을까

기술적으로 맞지 않는다

SAST가 제대로 작동하려면 전체 코드베이스를 봐야 합니다. 데이터가 어디서 들어와서 어디로 흘러가는지, 어떤 라이브러리에 의존하는지, 제어 흐름이 어떻게 분기하는지—이 전부를 종합해야 의미 있는 취약점 탐지가 가능해요.

그런데 Codex는 뭘 하는 도구인가요? 프롬프트와 주변 컨텍스트 몇 줄을 보고 코드 조각을 생성합니다. 전체 프로젝트를 보고 있는 게 아니에요. 50줄짜리 함수 하나만 놓고 SAST를 돌리면 결과가 쓸모없습니다. 컨텍스트가 없으니까요.

비유하자면, 책 한 페이지만 읽고 전체 줄거리에 모순이 있는지 판단하라는 것과 비슷합니다. 두 도구의 작동 방식이 기술 구조적으로 맞지 않는 거죠.

오탐 문제와 책임 리스크

설령 기술적으로 가능하다고 쳐도, 정책 차원에서 골치 아픈 문제가 생깁니다. AI가 생성한 코드 스니펫에 SAST를 자동 적용하면 오탐(false positive)이 쏟아져요. 전체 코드베이스 맥락 없이 패턴 매칭만 하니까 당연한 결과입니다.

이걸 공식 출력에 포함하면 두 가지 역효과가 나타납니다. 하나는 개발자가 오탐을 진짜 위협으로 오인해서 없는 문제를 고치느라 시간을 쓰는 것. 다른 하나는 경고가 너무 많아져서 결국 전부 무시해버리는 경고 피로(alert fatigue)예요. 보안 관점에서 둘 다 최악의 시나리오입니다.

거기에 더해서, SAST 리포트를 공식 출력으로 제공하는 순간 "이 리포트가 틀렸는데 왜 문제를 못 잡았냐"는 법적·계약적 책임 문제도 따라옵니다. OpenAI 입장에서는 굳이 안 질 싸움을 벌일 이유가 없어요. 코드 생성과 보안 검증의 책임을 분리해서, 각자 잘하는 일에 집중하게 만드는 게 현재 구조의 핵심입니다.

그래서 개발팀은 뭘 해야 하나

결론부터 말하면, Codex가 안 해주는 걸 우리가 직접 해야 합니다. CI/CD 파이프라인에 Codex를 넣는다면, 보안 검증 단계는 별도로 설계해야 해요. 실무에서 바로 적용할 수 있는 방향을 정리하면 이렇습니다.

• SAST 도구는 따로 돌려야 합니다 : SonarQube, Semgrep, Checkmarx 같은 전문 도구를 파이프라인에 독립 스테이지로 넣으세요. "AI가 만든 코드니까 괜찮겠지"라고 스캔을 건너뛰면 안 됩니다.
• 사람 리뷰를 빼면 안 됩니다 : SAST 도구 경고와 코드 리뷰를 함께 적용하는 이중 검증 구조가 필요해요. AI 생성 코드에는 숙련된 개발자도 처음 보는 패턴이 섞여 나올 수 있거든요.
• SCA도 빠뜨리지 마세요 : Codex가 제안하는 라이브러리에 알려진 취약점(CVE)이 있을 수 있습니다. SAST가 코드 자체를 보는 거라면, SCA(소프트웨어 구성 분석)는 의존성을 봅니다. 커버하는 영역이 다르니까 둘 다 필요해요.
• 이 모든 걸 문서로 남기세요 : "우리 팀은 Codex 생성 코드에 이런 보안 검증 절차를 적용한다"는 내부 문서가 있어야 합니다. 새 팀원 온보딩할 때도, 보안 감사 받을 때도 이 문서가 근거가 됩니다.

Codex = 생성 담당, SAST·SCA = 검증 담당. 이 분업 체계를 파이프라인에 명시적으로 반영하는 게 핵심입니다.

마무리

Codex가 SAST를 안 해주는 건 빠뜨린 게 아니라 의도된 설계입니다. 코드 생성과 보안 검증은 원래 다른 일이고, OpenAI는 그 경계를 명확히 지키겠다는 입장이에요. 이 구조를 이해하지 않고 Codex를 도입하면, 파이프라인 어딘가에 보안 검증 공백이 생길 수밖에 없습니다.

우리 몫은 간단합니다. Codex가 코드를 만들어주면, 그 다음 단계에 SAST와 코드 리뷰를 배치하면 돼요. AI가 생산성을 높여주는 만큼, 검증 도구는 더 단단하게 가져가야 균형이 맞습니다. OpenAI가 생성과 검증의 역할 분리를 일관되게 유지하는 만큼, 우리도 그 원칙을 파이프라인 설계의 기준점으로 삼으면 됩니다.