저는 원래 Claude Code를 주로 썼습니다. 익숙한 스킬을 붙여서 코드를 읽고, 리뷰하고, 필요한 부분을 고치는 방식으로 작업해왔어요. 최근에는 작업 환경을 Codex 쪽으로 옮기고 있는데, 코드를 만드는 것과 별개로 한 가지가 궁금했습니다.
Codex에 보안 검토를 맡기면 어디까지 볼 수 있을까?
일반 코드 리뷰 프롬프트로도 보안 문제를 어느 정도 찾을 수는 있습니다. 하지만 새 도구로 넘어온 김에, Codex 앱에 따로 들어 있는 보안 탭과 Codex Security 플러그인은 무엇이 다른지 직접 확인해보고 싶었어요.
그래서 실제로 사용 중인 저장소 하나를 골라 두 번 봤습니다. 먼저 일반적인 코드 리뷰 방식으로 인증과 권한 부분을 확인했고, 이어서 같은 커밋을 Codex Security의 Standard 검사에 넣었습니다. 원본 코드는 건드리지 않았고 두 검사 모두 같은 시점의 코드를 보게 했습니다.
일반 리뷰에서 남은 보안 후보는 1개였습니다. Codex Security에서는 그 항목을 포함해 12개가 나왔습니다. 높음 5개, 중간 6개, 낮음 1개였습니다.
물론 이걸 “실제 서비스에 취약점이 12개 있다”는 뜻으로 받아들이면 곤란합니다. 이번 검사는 소스 코드를 따라가며 확인한 정적 검토였고, 운영 서버의 설정이나 실제 외부 접근 가능성까지 시험한 것은 아닙니다.
Codex 앱에서 바로 실행해봤다
Codex Security를 설치하면 데스크톱 앱에 보안 탭이 생깁니다. 안으로 들어가면 스캔, 발견 항목, 리포지터리 세 화면이 있습니다.
이번에는 스캔에서 + 검사를 누르고 저장소 전체를 선택했습니다. 검사 종류는 Standard, 모델은 GPT-5.6 Sol로 설정했고, 추가 컨텍스트에는 일반 리뷰 결과와 비교하되 소스는 읽기 전용으로 다루고 공개하기 곤란한 세부 내용은 보고서 밖으로 꺼내지 말라고 적었습니다.
터미널 명령을 따로 만들거나 결과 폴더를 준비할 필요는 없었습니다. 저장소, 검사 범위, 모델과 추론 수준을 고른 뒤 앱 안에서 바로 시작할 수 있었어요. 공식 워크벤치 문서에 따르면 저장소 전체나 특정 폴더는 Codebase, 미커밋 변경이나 특정 커밋·리비전 범위는 Changes로 검사할 수 있습니다.
진행 중인 화면이 생각보다 유용했다
검사를 시작하면 지금 무엇을 하고 있는지가 화면에 표시됩니다.
제가 캡처했을 때는 검사 준비와 위협 모델 생성, 코드 검토가 끝난 상태였습니다. 이어서 12개 후보를 하나씩 다시 확인하고 있었고, 그다음 순서로 공격 경로 추적과 검사 마무리가 남아 있었습니다.
여기서 일반 코드 리뷰와 다른 느낌이 났습니다. 보통 리뷰를 요청하면 모델이 파일을 읽은 뒤 바로 문제를 이야기합니다. Codex Security는 먼저 이 저장소에서 보호해야 할 것이 무엇인지, 외부 입력이 어디로 들어오는지, 사용자의 권한이 어느 지점에서 갈리는지부터 정리했습니다.
그다음 수상한 코드를 모으고, 각 후보가 실제 경로로 이어지는지 다시 확인합니다. 후보를 찾는 단계와 검증하는 단계가 나뉘어 있는 셈입니다. 검증이 끝난 뒤에는 입력부터 영향 지점까지 이어지는 경로와 심각도를 정리하고 보고서를 만듭니다.
Codex Security Standard 검사 문서는 이 흐름을 위협 모델링, 발견, 검증, 영향·경로 분석, 보고, 마무리 단계로 설명합니다. 이번에 실제 화면에서 본 순서도 거의 같았습니다.
검사 작업 자체는 평소와 같은 Codex 작업에서 돌아갑니다. 대신 진행 상황과 결과는 보안 탭에 따로 남습니다. 검사가 오래 걸려 다른 작업으로 이동하더라도 다시 스캔으로 돌아오면 어디까지 진행됐는지 볼 수 있었습니다.
결과는 1개 대 12개였다
검사가 끝난 화면에는 발견 개수만 나온 것이 아니었습니다. 어떤 커밋을 검사했는지, 범위는 어디까지였는지, 몇 개 파일을 봤는지, 어떤 산출물이 만들어졌는 지가 같이 남았습니다.
이번 검사는 전체 리포지터리의 파일 756개를 대상으로 했습니다. 결과는 높음 5개, 중간 6개, 낮음 1개였습니다. 일반 리뷰에서 찾았던 예약 작업 인증 문제도 포함됐고, 그 밖에 객체 권한, OAuth, 토큰 처리 순서, CLI 설정, 외부 콘텐츠를 신뢰하는 경계까지 결과가 넓어졌습니다.
그렇다고 756개 파일을 전부 같은 깊이로 읽었다는 뜻은 아닙니다. 생성된 파일과 외부 의존성 등은 제외했고, 보안에 민감한 경로를 우선해서 봤습니다. 그래서 최종 커버리지는 partial로 남겼습니다.
이 부분이 좋았습니다. 발견 개수만 크게 보여주고 끝내지 않고, 어디까지 봤고 무엇을 확인하지 못했는지도 같이 남았습니다. 운영 환경의 비밀값이 실제로 설정돼 있는지, 배포 플랫폼이 별도의 접근 제어를 하고 있는지 같은 내용은 이번 검사만으로 알 수 없다고 구분했습니다.
산출물은 스캔 매니페스트, 발견 항목 JSON, 커버리지 JSON, Markdown 보고서, SARIF까지 다섯 종류가 만들어졌습니다. 보고서는 사람이 읽고, JSON과 SARIF는 다른 도구나 후속 에이전트가 이어서 쓰기 좋았습니다.
발견 항목을 한곳에서 다시 볼 수 있다
검사가 끝난 뒤에는 결과가 대화 속에 묻히지 않습니다. 발견 항목 탭에서 여러 검사 결과를 모아서 검색하고, 심각도나 상태로 걸러볼 수 있습니다.
각 항목에는 저장소와 소스 경로가 연결돼 있습니다. 하나를 열면 요약, 코드 근거, 검증 내용과 영향을 볼 수 있고, 필요하면 패치 작업으로 이어갈 수 있습니다. 리포지터리 탭에서는 같은 저장소를 언제 검사했는지와 아직 열려 있는 항목도 다시 확인할 수 있습니다.
일반 리뷰도 결과를 Markdown으로 저장하면 비슷하게 관리할 수는 있습니다. 다만 파일명과 폴더 구조, 상태 관리를 직접 정해야 합니다. Codex Security는 이 부분이 앱 안에 이미 마련돼 있었습니다. 검사를 돌린 작업과 결과 목록, 저장소 이력이 처음부터 연결돼 있다는 게 차이였습니다.
일반 코드 리뷰와 무엇이 달랐나
처음에는 같은 모델이 같은 코드를 읽는데 결과가 크게 다를까 싶었습니다. 직접 해보니 모델 차이보다는 질문과 절차의 차이가 더 컸습니다.
일반 리뷰에서는 “이 코드에서 위험해 보이는 부분을 찾아달라”고 요청했습니다. 그러니 눈에 띄는 인증 패턴 하나를 빠르게 찾았습니다. Codex Security는 바로 답을 내는 대신 위협 모델을 만들고, 신뢰 경계마다 후보를 찾은 뒤, 다시 반증하는 과정을 거쳤습니다.
Codex Security가 언제나 더 낫다는 얘기는 아닙니다. PR 하나를 빠르게 보거나 기능 버그와 함께 확인할 때는 일반 리뷰가 훨씬 가볍습니다. 반대로 저장소 전체를 처음 점검하거나, 같은 기준으로 정기 검사를 남기고 싶다면 Codex Security 쪽이 편했습니다.
이번의 1개 대 12개도 성능 점수라기보다 검토 방식의 차이로 보는 편이 맞습니다. 일반 리뷰는 좁은 질문에 빠르게 답했고, 보안 검사는 더 많은 경계를 확인하는 절차를 택했습니다.
유명한 보안 감사 스킬과도 비교해봤다
Codex Security만 이런 식으로 움직이는 것은 아닙니다. 보안 회사들이 공개한 에이전트 스킬 중에도 저장소를 여러 단계로 감사하는 방식이 있습니다. 그중 Codex Security와 비교하기 좋은 것은 Cloudflare와 Trail of Bits가 공개한 스킬들이었습니다.
Cloudflare security-audit-skill
Cloudflare의 security-audit-skill은 Codex Security와 가장 비슷했습니다. 아키텍처와 신뢰 경계를 파악하는 정찰 단계부터 시작해 여러 에이전트가 취약점을 찾고, 별도 에이전트가 발견 내용을 반박하며 검증합니다. 이후 사람이 읽는 보고서와 findings.json을 만들고, 마지막에는 새로운 에이전트가 소스 코드를 기준으로 사실을 다시 확인합니다.
“발견한 에이전트가 자기 결과를 검증하지 않는다”는 원칙이 특히 인상적이었습니다. 여러 번 실행하면 이전 결과를 읽고 아직 보지 않은 영역을 우선한다는 점도 좋습니다. 스킬 내용이 GitHub에 공개돼 있어 감사 절차를 읽고 원하는 방식으로 고칠 수 있고, Agent Skills를 지원하는 여러 코딩 에이전트에 설치할 수 있습니다.
반면 실행과 결과 관리는 기본적으로 코딩 에이전트와 출력 폴더 안에서 이뤄집니다. Codex Security처럼 데스크톱 앱에 검사 목록, 통합 발견 항목, 저장소 이력이 준비돼 있지는 않습니다. 감사 방법을 직접 통제하고 싶다면 Cloudflare 스킬이 매력적이고, 설치 후 바로 실행하고 결과를 계속 관리하는 편의성은 Codex Security가 앞섰습니다.
Trail of Bits audit-context-building과 differential-review
Trail of Bits의 공개 보안 스킬은 조금 다른 방향입니다. 하나의 버튼으로 전체 감사를 끝내기보다는 전문 감사자가 필요한 단계를 골라 쓰는 도구에 가깝습니다.
audit-context-building은 낯선 저장소를 감사하기 전에 코드를 한 줄씩 이해하고, 왜 이런 구조가 됐는지 파고드는 데 집중합니다. differential-review는 PR이나 커밋을 볼 때 Git 이력과 삭제된 코드, 호출 범위와 테스트까지 확인합니다. 변경된 줄만 보는 게 아니라 그 변경이 어디까지 영향을 미치는지 계산하는 방식입니다.
이런 스킬은 감사자가 이미 무엇을 확인해야 할지 알고 있을 때 강합니다. 전체 저장소를 자동으로 훑는 것보다, 인증 시스템을 깊게 이해하거나 위험한 변경의 파급 범위를 좁혀 보는 데 잘 맞습니다. 반대로 처음 보안 검사를 시작하는 사람에게는 어떤 스킬을 어느 순서로 써야 할지 판단이 필요합니다.
Codex Security는 세밀한 감사 도구라기보다 전체 과정을 묶은 제품에 가까웠습니다. Trail of Bits 스킬은 감사자가 운전대를 직접 잡는 느낌이고, Codex Security는 시작부터 결과 관리까지 정해진 길을 안내하는 느낌이었습니다.
한눈에 비교하면
셋 중 하나가 무조건 제일 좋다고 보기는 어렵습니다. 제가 Codex로 넘어오면서 처음 보안 상태를 확인하는 상황에서는 Codex Security가 가장 시작하기 쉬웠습니다. 이미 감사 절차를 운영하고 있거나 여러 모델과 에이전트에서 같은 스킬을 쓰고 싶다면 Cloudflare 방식이 더 유연합니다. 특정 변경과 코드 맥락을 깊게 파야 한다면 Trail of Bits 스킬이 더 날카롭습니다.
직접 실행하려면
Codex 앱에서는 다음 순서로 실행할 수 있습니다.
- Codex Security 플러그인을 설치하고 활성화합니다.
- 왼쪽의
보안탭을 엽니다. 스캔에서+ 검사를 누릅니다.- 저장소나 폴더를 선택합니다.
- 전체 저장소는
Codebase, 미커밋 변경이나 커밋 범위는Changes를 선택합니다. - 모델과 추론 수준, 추가 컨텍스트를 정하고 검사를 시작합니다.
- 완료 후 발견 개수뿐 아니라 리비전, 커버리지와 제외 영역, 산출물을 같이 확인합니다.
일반 Codex 대화에서도 실행할 수 있습니다.
Use $codex-security:security-scan to scan this repository for security vulnerabilities.
현재 저장소 전체를 Standard 검사해줘.
원본 소스는 수정하지 말고 인증, 권한, 토큰, 명령 실행 경계를 우선해서 봐줘.
후보마다 실제 소스 경로를 확인하고, 운영에서 확인하지 않은 내용은 미검증으로 표시해줘.
완료 후 발견 항목 수뿐 아니라 커버리지, 제외 영역과 생성된 산출물을 함께 요약해줘.대화에서 시작한 검사도 같은 워크벤치를 사용하면 보안 탭에 나타납니다. 앱에서 진행 상황과 결과를 다 시 열어볼 수 있습니다.
써보고 나서
Claude Code에서 Codex로 넘어온다고 해서 보안 검토 방식까지 전부 바꿀 생각은 없었습니다. 익숙한 코드 리뷰와 공개 보안 스킬은 여전히 쓸 만합니다. 오히려 각각 잘하는 일이 달랐습니다.
빠르게 변경을 볼 때는 일반 리뷰가 편했고, 감사 과정을 직접 설계하고 싶을 때는 Cloudflare나 Trail of Bits의 공개 스킬이 매력적이었습니다. Codex Security는 그 사이에서 보안 검사를 처음 시작하고, 결과를 계속 쌓아두는 일이 가장 편했습니다.
이번에 12개가 나왔다는 사실보다 더 유용했던 건 따로 있었습니다. 같은 저장소를 다음에 다시 검사했을 때 비교할 기준이 생겼고, 지금 확인한 것과 아직 운영에서 확인하지 못한 것이 분리돼 남았습니다.
저처럼 Claude Code를 쓰다가 Codex로 넘어오면서 보안 검토를 어떻게 이어갈지 고민하고 있다면, 우선 Standard 검사를 한 번 돌려 기준선을 만들어보는 정도로 시작해볼 만합니다. 그 결과를 보고 더 깊은 감사가 필요할 때 Cloudflare나 Trail of Bits 같은 공개 스킬을 함께 쓰는 방식도 괜찮아 보입니다.
