Codex Security 안전장치만 믿어도 될까 2026, sandbox·승인·로그 운영 기준

OpenAI는 2026년 2월 2일 공개한 Introducing the Codex app에서 Codex를 secure by default, configurable by design이라고 설명했다.

이 문장 자체는 맞다.

문제는 운영자가 이 문장을 기본 안전장치가 있으니 마음 놓아도 된다로 번역하는 순간부터 시작된다.

그건 보안 문장을 안심 문장으로 오해한 셈이기 때문이다.

실무에서는 보통 여기서 사고가 난다.

sandbox가 있으니 괜찮겠지.

승인 팝업이 뜨니 괜찮겠지.

기본값이 보수적이니 팀 전체도 괜찮겠지.

아쉽지만 셋 다 반만 맞다.

운영 관점에서 더 정확한 문장은 이쪽에 가깝다.

secure by default는 시작점이고, safe enough for my team은 별도 설계다.

이 글은 제품 소개가 아니다.

OpenAI 공식 문구를 운영 언어로 번역하는 글이다.

핵심은 단순하다.

Codex를 볼 때는 하나의 안전장치가 아니라 세 층을 따로 봐야 한다.

첫째는 sandbox.

둘째는 permission approval.

셋째는 logs, handoff, review.

앞의 두 개는 도구가 많이 도와준다.

마지막 하나는 대부분 팀이 직접 설계해야 한다.

여기서부터가 중요하다.

OpenAI 공식 문서가 말하는 사실과 내가 운영 기준으로 해석한 부분은 구분해서 보자.

공식 문서가 직접 말한 사실은 2026년 2월 2일 앱 소개 글과 2025년 12월 18일 GPT-5.2-Codex 시스템 카드 부록에 있다.

반대로 그래서 우리 팀은 승인 기록을 어디까지 남겨야 하나 언제 사람 리뷰를 더 붙여야 하나 같은 질문은 운영 해석의 영역이다.

즉, 이 글의 목적은 OpenAI 문장을 베껴 쓰는 게 아니라 그 문장을 팀 운영 규칙으로 바꾸는 데 있다.

결론부터 말하면,
기본 안전장치만으로는 부족하지 않지만 충분하지도 않다.
Codex를 안전하게 굴리는 기준은 sandbox만 켜졌나가 아니라
sandbox 위에 승인과 로그 검토 체계가 붙어 있나로 봐야 한다.

secure by default를 운영자는 어떻게 읽어야 하나

OpenAI가 말한 핵심을 먼저 정리해보자.

2026년 2월 2일 글에서 Codex app은 기본적으로 작업 중인 폴더 또는 브랜치 안의 파일 편집과 cached web search만 허용한다고 설명한다.

그리고 네트워크 접근 같은 elevated permission이 필요한 명령은 승인을 요청한다고 적었다.

2025년 12월 18일 시스템 카드 부록은 이 그림을 더 운영적으로 풀어준다.

Codex 에이전트는 격리된 안전한 환경에서 동작하도록 의도되며,

cloud에서는 isolated container 안에서 돌고, network access는 기본적으로 꺼져 있다.

local에서는 sandbox가 기본이고, 필요하면 사용자가 승인해서 unsandboxed full access로 명령을 실행할 수 있다.

또 기본 sandbox의 목표도 꽤 명확하게 적혀 있다.

기본적으로 네트워크를 끈다.

파일 수정 범위를 현재 workspace로 제한한다.

인터넷 접근을 열면 prompt injection, credential leakage, license restriction 같은 리스크가 생길 수 있으니 trusted domains와 safe HTTP methods 위주로 제한하라고 말한다.

여기까지는 공식 사실층이다.

이제 운영 해석층으로 넘어가보자.

이 문서들이 말하는 건 초기 blast radius를 줄여준다에 가깝다.

반대로 이제 사람이 덜 봐도 된다 로그를 자세히 안 남겨도 된다 승인만 누르면 책임이 끝난다 까지 뜻하진 않는다.

즉, secure by default는 면책 버튼이 아니다.

안전 기본값을 깔아주는 시작점이다.

이 차이를 놓치면 도구의 보수적 기본값을 팀의 완성된 운영 체계로 착각하게 된다.

그 순간부터 권한 예외가 늘어나고, 누가 승인했는지 흐려지고, 나중에 로그를 봐도 왜 그 행동이 허용됐는지 복원되지 않는다.

그래서 운영자는 OpenAI 문장을 이렇게 읽는 편이 좋다.

기본 안전장치는 이미 있다.

하지만 그 위에 사람 승인 기준과 로그 회고 체계는 우리가 따로 세워야 한다.

이게 훨씬 덜 멋있지만 훨씬 쓸모 있다.

3층 가드레일로 봐야 하는 이유

Codex 운영을 하나의 보안 기능으로 보면 자꾸 놓친다.

세 층으로 나누면 오히려 훨씬 덜 헷갈린다.

층	질문	기본 역할	과신하면 생기는 일
sandbox	에이전트가 어디까지 닿을 수 있나	네트워크와 파일 범위를 기본 제한	승인 이후 확장된 권한을 놓침
permission approval	누가 예외를 열어줬나	위험 명령 앞에서 사람 판단 삽입	승인 자체를 검토 없이 통과
logs-handoff-review	나중에 어떻게 재구성하나	사후 검토, 인수인계, 책임 경계 확보	사고 뒤 설명 불가

이 표가 별거 아닌 것 같아도 운영 회의에서 제일 많이 살려준다.

왜냐면 세 층은 서로 역할이 다르기 때문이다.

sandbox는 기본 제한이다.

approval은 예외 허용이다.

logs와 review는 사후 설명과 재발 방지다.

셋은 비슷해 보여도 한 개가 다른 두 개를 대체하지 못한다.

sandbox가 있다고 승인 기록이 생기지는 않는다.

승인 절차가 있다고 나중에 누가 무엇을 봤는지 자동 복원되진 않는다.

로그가 있다고 실행 시점의 권한 경계가 자동으로 안전해지는 것도 아니다.

운영에서 사고가 나는 순간은 대개 이렇다.

우리는 sandbox를 쓰고 있었다.

그러니 승인도 대충 넘어가도 되겠지.

로그는 나중에 필요하면 보자.

이 흐름이 누적되면 보안이 무너진다기보다 운영 설명 가능성이 먼저 무너진다.

그리고 설명 가능성이 무너지면 팀은 곧장 더 보수적으로 돌아간다.

웃긴 얘기지만 안전장치를 과신한 팀일수록 사고 뒤에는 전부 금지 모드로 가는 경우가 많다.

너무 믿어서 너무 못 믿게 되는 코스다.

그러니 처음부터 세 층을 따로 설계하는 편이 낫다.

1층: sandbox는 blast radius를 줄여주지만 판단을 대신하지 않는다

sandbox의 장점은 분명하다.

기본적으로 네트워크를 끄고, 파일 수정 범위를 현재 workspace로 제한하면, 초기 실수의 반경이 줄어든다.

특히 로컬 환경에서 에이전트가 실수로 다른 프로젝트나 시스템 파일을 건드리는 위험을 낮춘다.

cloud 쪽에서도 격리된 컨테이너 안에서 돌고 기본 네트워크 접근이 꺼져 있으면 호스트 시스템과 민감한 데이터에 바로 닿는 경로가 줄어든다.

이건 진짜 중요하다.

괜히 기본값이 보수적인 게 아니다.

그런데 운영자는 여기서 한 발 더 가야 한다.

sandbox는 무엇을 못 하게 하는가를 정의하지, 무엇을 해도 괜찮은가를 최종 판정하지는 않는다.

예를 들어보자.

현재 workspace 안에서만 파일을 수정한다는 사실은 좋은 기본값이다.

하지만 현재 workspace 안에 배포 스크립트, 민감한 설정 파일, 대규모 삭제가 가능한 툴링, 사내 프롬프트 템플릿이 다 들어 있다면 여전히 운영 리스크는 존재한다.

즉, workspace 제한은 무한한 자유를 유한한 자유로 바꾸는 장치다.

유한한 자유가 자동으로 무해한 자유가 되진 않는다.

또 하나.

local에서 sandbox가 기본이더라도 사용자가 승인해서 unsandboxed full access를 열 수 있다고 시스템 카드 부록은 분명히 적고 있다.

이 말의 운영 번역은 간단하다.

우리 팀은 예외를 열 수 있다.

즉, 안전은 기본값으로 시작하지만 현실 운영은 예외 관리로 끝난다.

그래서 sandbox 운영에서 봐야 할 포인트는 켜져 있냐 아니냐보다 예외가 얼마나 자주, 어떤 이유로, 누구 승인으로 열리느냐다.

이 질문을 안 보면 sandbox는 멀쩡한데 실제 운영은 늘 unsandboxed에 가까운 팀이 생긴다.

그 팀은 겉으론 안전해 보이는데 실제로는 매번 문을 열고 다니는 셈이다.

보안판 자동문 참사 같은 거다.

문은 있는데 늘 열려 있음.

sandbox를 과신하면 안 되는 순간

아래 상황이 보이면 sandbox만 믿으면 안 된다.

의존성 설치나 업데이트가 자주 필요하다
외부 문서, 패키지 레지스트리, 사내 위키 접근이 반복된다
에이전트가 생성한 스크립트가 워크스페이스 내부에서 대량 변경을 일으킬 수 있다
현재 workspace 안에 이미 배포 자격증명이나 민감한 산출물이 있다
여러 워커가 같은 저장소에서 동시에 작업한다

이 경우엔 기본 sandbox가 있어도 실제 위험은 예외 승인 패턴과 검토 습관 쪽에 더 가깝다.

운영 기준으로 다시 쓰면 이렇다.

sandbox는 첫 방어선이다.

하지만 반복 예외가 많아지는 프로젝트에서는 두 번째, 세 번째 방어선이 더 중요해진다.

2층: permission approval은 보안 팝업이 아니라 책임 경계선이다

OpenAI 공식 설명에서 네트워크 같은 elevated permission은 승인을 요청한다.

이 문장을 운영자는 귀찮은 팝업 설명으로 읽으면 안 된다.

이건 사실상 사람 판단이 들어가는 인터럽트 지점이다.

여기서 하나 더 봐야 할 공식 포인트가 있다.

2026년 2월 2일 앱 소개 글은 프로젝트나 팀 단위 규칙으로 특정 명령을 elevated permission으로 자동 실행하게 구성할 수 있다고도 안내한다.

이 말은 곧 승인을 없애도 된다가 아니라 승인 정책을 코드화할 수 있다는 뜻에 가깝다.

즉, 자동 허용은 편의 기능이면서 동시에 운영 규칙의 책임 구간이다.

approval의 역할은 단순 허가 버튼이 아니다.

세 가지가 있다.

첫째, 속도를 일부러 늦춘다.

둘째, 행동이 예외였다는 사실을 남긴다.

셋째, 나중에 리뷰할 기준점을 만든다.

특히 네트워크 접근은 시스템 카드 부록이 왜 위험한지까지 적어놨다.

prompt injection, leaked credentials, license restrictions.

이 세 단어만 봐도 왜 approval을 생산성 저해 요소로만 보면 안 되는지 감이 온다.

문제는 많은 팀이 approval을 한 번 누르면 끝으로 다룬다는 점이다.

그렇게 되면 approval은 남아 있는데 판단은 사라진다.

실무에서 필요한 건 승인 자체보다 승인 기준이다.

예를 들어 이런 구분이 있어야 한다.

승인 대상	기본 태도	이유
단순 docs 조회용 GET	제한적 허용 가능	업무 필요성이 높고 변경 부작용이 낮음
패키지 설치용 registry 접근	프로젝트별 allowlist 권장	공급망, 라이선스, 버전 변동 리스크
외부 POST/PUT/PATCH	별도 승인 강하게 권장	상태 변경과 정보 유출 가능성
full unsandboxed 실행	케이스별 승인	파일 범위와 시스템 경계 확대
배포/발행 관련 명령	사람 검토 후 승인	외부 영향이 즉시 발생

여기서 trusted domains와 safe HTTP methods only가 왜 중요한지 나온다.

OpenAI 문구를 운영적으로 해석하면 모든 인터넷 허용이 아니라 목적이 분명한 좁은 인터넷 허용을 권장한다는 뜻이다.

즉, approval은 yes/no 버튼이라기보다 허용 범위를 좁게 자르는 작업에 가깝다.

이때 팀 룰이 없으면 승인은 늘 상황극이 된다.

누군가는 어제 됐는데 왜 오늘 안 되냐고 하고, 누군가는 일단 되게 해달라고 하고, 누군가는 나중에 닫자고 한다.

이 세 문장을 많이 들으면 거의 확실하게 규칙이 없는 팀이다.

그러니 approval 단계에서 최소한 아래 네 가지는 미리 정해두는 편이 좋다.

어떤 도메인은 기본 허용 후보인가
어떤 HTTP method는 기본 차단 또는 재승인 대상인가
어떤 명령은 항상 사람 리뷰 후 실행인가
어떤 경우 full access 승인을 금지하거나 더 좁게 제한할 것인가

이걸 프로젝트 규칙으로 못 박아두면 승인이 빨라지면서도 덜 무모해진다.

언제 trust domain allowlist가 꼭 필요할까

모든 프로젝트가 같은 수준의 allowlist를 필요로 하진 않는다.

하지만 아래 셋 중 두 개 이상 해당하면 프로젝트 규칙을 두는 게 낫다.

첫째, 반복적으로 접속하는 외부 서비스가 정해져 있다.

예를 들면 공식 문서 사이트, 패키지 레지스트리, 사내 Git 호스트, 이슈 트래커, 배포 대상 API 같은 것들이다.

둘째, 네트워크 허용이 생산성 병목이 되고 있다.

매번 같은 승인 요청이 뜨는데 사람이 의미 없이 누르고 있다면 그건 자동 허용을 고민할 시점이지 그냥 익숙해질 시점은 아니다.

셋째, 라이선스나 출처 규칙이 명확하다.

아무 사이트나 긁어오면 안 되고 공식 문서나 사내 허용 저장소만 써야 한다면 allowlist는 편의 기능이 아니라 정책 구현이다.

특히 TECHTAEK처럼 실험과 운영이 자주 섞이는 팀은 allowlist가 꽤 큰 차이를 만든다.

리서치용 browsing과 실행용 network access를 같은 것으로 취급하면 안 된다.

문서 조회는 괜찮아도 의존성 설치, 원격 스크립트 실행, 외부 POST 요청은 전혀 다른 급이다.

같은 네트워크여도 행동 의미가 다르다.

그래서 trusted domain allowlist는 무엇을 볼 수 있나만 정하는 게 아니라 어떤 행동 유형으로 접근할 수 있나까지 같이 봐야 한다.

이 부분은 공식 문서의 safe HTTP methods 언급과 잘 맞물린다.

쉽게 말해 GET 하나 허용했다고 POST까지 묶음 할인으로 열어주면 안 된다는 뜻이다.

보안 할인마트 열면 안 된다.

3층: logs, handoff, review는 왜 따로 봐야 하나

이제 제일 많이 빠지는 층으로 가자.

많은 팀이 sandbox와 approval을 보면 거기서 멈춘다.

하지만 운영자는 마지막 층을 따로 봐야 한다.

무엇이 실행됐는가보다 그 실행을 나중에 어떻게 설명할 수 있는가가 중요하기 때문이다.

여기서 분명히 해둘 점이 있다.

OpenAI가 위 두 공식 문서에서 그래서 승인 로그와 handoff 로그를 이렇게 남기세요 라고 세세한 운영 템플릿까지 제시한 것은 아니다.

이 지점부터는 공식 문서의 안전 기본값을 실제 팀 운영으로 번역한 해석이다.

왜 이런 해석이 필요하냐면 실제 사고의 절반은 실행 순간보다 사후 복원 실패에서 커지기 때문이다.

누가 승인을 눌렀는지 모르겠다.

왜 그 도메인을 열었는지 기록이 없다.

어느 시점부터 full access가 필요해졌는지 안 남았다.

다음 워커가 이어받았는데 어떤 예외가 이미 허용됐는지 모른다.

이러면 사고가 없어도 운영 품질은 무너진다.

즉, 로그는 감시 장치가 아니라 회복 장치다.

handoff는 친절 메모가 아니라 권한 맥락 전달 장치다.

review는 불신이 아니라 예외 사용을 좁게 유지하는 마찰 장치다.

이 셋을 따로 놓아야 하는 이유는 approval이 순간의 판단이라면 logs와 review는 시간 축의 판단이기 때문이다.

실행 당시엔 괜찮아 보여도 일주일 뒤 회고에서 보면 너무 넓게 열어준 예외가 보일 수 있다.

반대로 지나치게 빡센 승인이 전부 사람의 습관적 클릭으로 변했다는 것도 로그를 모아봐야 보인다.

그래서 운영 팀은 승인이 있었다만 보면 안 되고 그 승인이 어떤 패턴으로 누적되고 있는가를 봐야 한다.

로그를 남길 때 최소한 필요한 항목

이건 OpenAI 원문 문장이라기보다 운영 체크리스트다.

그래도 실제로는 이 정도만 남겨도 상당히 많은 문제를 줄인다.

요청한 작업 목적
승인 대상 명령 또는 접근 유형
승인 시점과 승인자
허용 범위와 조건
결과 요약
다음 워커가 알아야 할 경계선

조금 더 실무적으로 적으면 이렇다.

로그 항목	왜 필요한가
task context	왜 예외가 필요했는지 복원
permission type	network, full access, 외부 write 구분
scope	어떤 도메인, 어떤 명령, 어떤 workspace 범위인지 확인
approver	판단 책임 경계 확보
outcome	실제로 무엇이 수행됐는지 확인
follow-up	다음 세션에서 다시 승인할지, 닫을지 판단

핵심은 장황한 transcript를 전부 읽자는 게 아니다.

오히려 반대다.

나중에 볼 가치가 있는 승인 로그와 handoff 메모를 따로 추출하자는 얘기다.

이게 없으면 raw 로그는 많아도 운영 지식은 안 쌓인다.

로그 창고는 있는데 찾으면 다 박스뿐인 상황이다.

정리 안 된 창고는 창고가 아니라 허리 통증 제조기다.

왜 raw transcript만으로는 부족한가

일부 팀은 이렇게 말한다.

어차피 세션 기록이 다 남는데 굳이 승인 로그를 따로 볼 필요가 있나.

겉으로는 그럴듯하다.

하지만 운영 기준으로는 부족하다.

이유는 세 가지다.

첫째, transcript는 대화 중심이고 운영 검토는 예외 중심이다.

둘째, 세션이 길어질수록 정말 중요한 승인 포인트가 묻힌다.

셋째, 다음 워커는 전체 대화보다 권한 변화와 위험 경계부터 알아야 한다.

그래서 handoff 문서나 승인 리뷰 메모는 채팅의 요약본이 아니라 권한 이벤트의 요약본이어야 한다.

무슨 얘기냐면 오늘 무엇을 만들었나보다 오늘 무엇을 예외로 열었나가 운영 보안에서는 더 중요할 때가 많다는 뜻이다.

특히 여러 워커가 동시에 움직이는 환경에선 더 그렇다.

누가 같은 저장소에서 작업 중인지, 어떤 예외가 이미 열린 상태인지, 어느 명령은 사람이 마지막으로 다시 봐야 하는지, 이런 정보가 없으면 handoff가 아니라 바통 던지기가 된다.

받는 사람만 고생한다.

safe enough for my team은 어디서 갈리나

여기서 질문을 다시 던져보자.

secure by default와 safe enough for my team의 차이는 뭘까.

나는 이걸 기본 안전장치와 운영 안전장치의 차이로 본다.

기본 안전장치는 OpenAI가 제공하는 product baseline이다.

운영 안전장치는 팀이 결정하는 policy baseline이다.

둘은 겹치지만 같지 않다.

예를 들면 이런 식이다.

항목	secure by default	safe enough for my team
파일 수정 범위	workspace 제한	민감 디렉터리 추가 보호, 리뷰 규칙 포함
네트워크	기본 비활성, 승인 필요	도메인 allowlist, method 규칙, secret 정책 추가
권한 예외	필요 시 승인	누가 어떤 조건에서 승인 가능한지 명문화
실행 흔적	도구 수준 기록 가능	승인 요약, handoff, 회고 루틴 추가
사고 대응	기본 보호에 기대	재현, 설명, 재발 방지 루프까지 설계

즉, OpenAI가 제공하는 기본 안전장치를 탓할 이유는 없다.

오히려 꽤 보수적으로 시작한다.

문제는 그다음이다.

팀이 자기 정책을 안 만들면 기본값은 곧 습관적 예외로 덮인다.

그리고 습관적 예외는 문서 없는 특권이 된다.

그때부터 운영 품질이 흔들린다.

사람 승인이 꼭 필요한 순간

무조건 사람이 다 보라는 얘기는 아니다.

그렇게 하면 운영이 느려지고 결국 다 우회한다.

중요한 건 사람이 봐야 하는 순간을 정확히 자르는 것이다.

내 기준에선 아래 경우 사람 승인을 남기는 편이 안전하다.

네트워크를 새 도메인으로 처음 연다
허용된 도메인이어도 unsafe method가 필요하다
full unsandboxed access가 필요하다
현재 workspace 안이라도 대량 삭제나 reset 성격의 명령이 돈다
외부 시스템 상태를 바꾸는 write가 있다
비밀정보가 세션에 노출되거나 새로 주입된다
배포, 발행, 청구, 티켓 상태 변경처럼 되돌리기 비용이 큰 작업이다

반대로 상대적으로 자동화 여지를 넓힐 수 있는 구간도 있다.

이미 검증된 공식 문서 도메인에 대한 읽기 전용 접근
반복되는 사내 read-only 조회
결과를 로컬에만 남기고 외부 상태를 바꾸지 않는 검증
팀이 미리 규칙화한 패키지 조회 또는 버전 확인

포인트는 이거다.

사람 승인은 사람의 감으로 하지 말고 행동 유형으로 정의해야 한다.

그래야 바뀌는 사람마다 기준이 흔들리지 않는다.

사람 로그 검토가 꼭 필요한 순간

승인과 별도로 로그 검토 주기를 두면 좋은 순간도 있다.

이건 즉시 승인과는 다르게 하루 끝, 릴리스 전, 주간 회고처럼 묶어서 볼 수 있다.

특히 아래 상황이면 로그 검토를 따로 두는 편이 좋다.

같은 프로젝트에서 network approval 빈도가 급증한다
full access 승인 비율이 높아진다
여러 워커가 같은 파일 군을 번갈아 수정한다
외부 write가 있었는데 실패와 재시도가 반복된다
handoff 후 같은 예외가 매 세션 다시 열린다
누가 왜 승인했는지 회고에서 자꾸 설명이 안 된다

이런 패턴은 실행 중엔 잘 안 보인다.

하지만 로그를 모아보면 운영 냄새가 확 난다.

바로 그 냄새가 규칙 수정의 출발점이다.

좋은 운영은 사고 후 문책보다 패턴 후 수정이 많다.

팀에서 바로 쓸 수 있는 운영 체크리스트

여기부터는 진짜로 바로 옮겨 적을 수 있게 적어보자.

프로젝트 시작 전에

현재 workspace 안에 민감 파일이 무엇인지 정리한다
네트워크가 꼭 필요한지 먼저 판단한다
자주 쓰는 trusted domains 후보를 적는다
읽기 전용과 상태 변경 요청을 분리한다
full access가 필요한 작업을 별도 lane으로 뺀다

승인 규칙을 만들 때

허용 도메인과 금지 도메인을 구분한다
GET/HEAD와 상태 변경 method를 다르게 다룬다
package install, deploy, publish는 별도 승인으로 둔다
destructive command의 예시를 명시한다
반복 승인되는 작업은 자동 허용이 아니라 규칙 재설계 대상으로 본다

로그와 handoff를 만들 때

승인 이벤트만 따로 모은다
다음 워커가 알아야 할 예외를 요약한다
세션의 목표보다 권한 변화 중심으로 적는다
재승인 필요 여부를 남긴다
비밀값 자체는 로그에 남기지 않는다

주간 회고에서

어떤 예외가 자주 열렸는지 본다
allowlist를 넓힐지 좁힐지 결정한다
사람이 의미 없이 누른 승인 패턴을 찾는다
full access 사용률을 점검한다
raw transcript가 아니라 승인 요약본이 실제로 도움이 됐는지 본다

여기까지 해두면 보안팀 흉내를 내는 게 아니라 운영팀답게 굴릴 수 있다.

그게 훨씬 현실적이다.

흔한 오해 세 가지

오해 1. sandbox가 있으니 로그는 대충 봐도 된다

아니다.

sandbox는 실행 범위를 좁히는 장치고 로그는 판단 맥락을 남기는 장치다.

둘은 용도가 다르다.

실수 반경이 작아도 왜 예외를 열었는지 설명이 안 되면 같은 실수를 반복한다.

오해 2. 승인 팝업이 뜨면 이미 충분히 안전하다

승인 팝업은 질문이지 답이 아니다.

누가, 무엇을, 어디까지, 왜 허용하는지 기준이 없으면 approval은 클릭 이벤트로 끝난다.

오해 3. 로그를 많이 남기면 자동으로 안전해진다

이것도 아니다.

너무 많은 raw 로그는 아무도 안 보는 로그가 된다.

중요한 건 양보다 분리다.

승인 로그, handoff 메모, 리뷰 포인트를 따로 보이게 만들어야 한다.

운영자의 한 줄 기준

내가 이 주제에서 제일 자주 쓰는 기준은 이거다.

기본값은 blast radius를 줄이고, 운영은 설명 가능성을 만든다.

둘 중 하나만 있어도 아쉽다.

둘 다 있어야 팀이 오래 간다.

secure by default가 좋다는 말과 별도 로그 검토가 필요하다는 말은 서로 모순이 아니다.

오히려 정확히 이어지는 말이다.

기본값이 보수적이기 때문에 우리는 더 좁고 명확한 예외 운영을 설계할 수 있다.

그리고 예외 운영을 설계했기 때문에 secure by default가 실제 팀 안전으로 이어진다.

둘 사이의 다리가 바로 approval 기준과 logs-handoff-review다.

지금 결론

OpenAI가 말하는 secure by default는 운영자가 가볍게 볼 문장이 아니다.

실제로 Codex는 기본 네트워크 차단, workspace 제한, 승인 기반 예외라는 꽤 강한 기본선을 깔고 있다.

하지만 그 기본선이 곧바로 팀 운영의 완성본은 아니다.

팀이 별도로 설계해야 할 것은 세 가지다.

첫째, sandbox 예외를 언제 여는지.

둘째, permission approval을 어떤 기준으로 누르는지.

셋째, 그 예외와 판단을 어떤 로그와 handoff 형식으로 검토할지.

이 셋이 붙어야 안전장치가 있다가 우리 팀도 안전하게 쓸 수 있다로 바뀐다.

한 줄로 끝내면 이렇다.

Codex Security를 믿지 말자는 얘기가 아니다.

Codex Security를 운영 언어로 끝까지 번역하자는 얘기다.

FAQ

Q. OpenAI가 secure by default라고 했으면 기본값만 써도 충분한 것 아닌가

기본값은 훌륭한 출발점이지만, 팀 운영에서 필요한 승인 기준과 로그 회고 체계까지 자동으로 대신해주진 않는다.

공식 문서가 보장하는 것은 기본 보호선이고, 팀이 필요로 하는 것은 그 위의 정책선이다.

Q. sandbox가 켜져 있으면 unsandboxed 승인만 조심하면 되나

그보다 넓게 봐야 한다.

새 도메인 네트워크 허용, 상태 변경 HTTP method, 외부 write, 민감 파일이 포함된 workspace 작업도 같이 관리 대상이다.

Q. 로그는 세션 transcript만 있으면 충분하지 않나

대화 기록만으로는 권한 이벤트를 빠르게 재구성하기 어렵다.

운영에선 승인 이유, 허용 범위, 후속 조치가 따로 보이는 로그가 더 유용하다.

Q. trusted domain allowlist는 작은 팀에도 필요한가

반복해서 접근하는 외부 서비스가 정해져 있고 승인 요청이 계속 같은 패턴으로 반복된다면 작은 팀일수록 오히려 효과가 크다.

규칙 없는 반복 승인은 작은 팀에서 더 빨리 습관이 된다.

Q. 사람 리뷰를 너무 넣으면 생산성이 떨어지지 않나

그래서 모든 작업에 리뷰를 붙이는 게 아니라 새 도메인, 상태 변경 요청, full access, 외부 write처럼 되돌리기 비용이 큰 순간만 자르는 게 핵심이다.

리뷰는 많이 하는 것보다 정확히 하는 게 낫다.

공식 출처

OpenAI, Introducing the Codex app, 2026-02-02

<https://openai.com/index/introducing-the-codex-app/>

이 글에서 확인한 핵심은 Codex app이 secure by default, configurable by design으로 설명되며, 기본적으로 작업 폴더 또는 브랜치 내부 파일 편집과 cached web search만 허용하고, network access 같은 elevated permission은 승인 요청으로 처리된다는 점이다.

OpenAI, Addendum to GPT-5.2 System Card: GPT-5.2-Codex, 2025-12-18

<https://openai.com/index/gpt-5-2-codex-system-card/>

PDF 원문:

<https://cdn.openai.com/pdf/ac7c37ae-7f4c-4442-b741-2eabdeaf77e0/oai_5_2_Codex.pdf>

이 문서에서 확인한 핵심은 Codex 에이전트가 격리된 환경에서 동작하도록 설계됐고, cloud에서는 isolated container와 default-off network, local에서는 sandbox default와 필요 시 unsandboxed full access 승인 모델을 사용한다는 점이다.

또 기본 sandbox 목표로 network disabled by default와 current workspace로의 file edit 제한을 명시했고, network access를 열면 prompt injection, credential leakage, license restriction 위험이 있어 trusted domains와 safe HTTP methods 위주로 제한해야 한다고 적고 있다.

이 글의 logs-handoff-review 부분은 위 공식 문서의 제품 기본선 위에 운영자가 추가로 설계해야 할 검토 체계를 해석한 내용이다.

Codex Security가 말하는 안전장치만 믿어도 될까 2026 — sandbox·승인·로그를 따로 봐야 하는 이유