바이브 코딩을 운영 코드로 넘기기 전: Codex의 Sandbox·승인 정책을 ‘차단 테스트’로 검증하는 법
테스트가 통과했더라도 에이전트가 워크스페이스 밖을 수정하거나 네트워크에 접근할 수 있다면, 운영 전환 준비가 끝난 것은 아닙니다.
테스트가 통과했더라도 에이전트가 워크스페이스 밖을 수정하거나 네트워크에 접근할 수 있다면, 운영 전환 준비가 끝난 것은 아닙니다.
들어가며 — 독자가 지금 이 문제를 검색하는 이유
AI 코딩 에이전트가 만든 코드가 정상 동작하는지 확인했다면, 다음으로 보통 이런 질문이 나옵니다.
“이 에이전트가 허용 범위 밖의 명령도 실행할 수 있는가?”
프로토타입 단계에서는 빠른 실행이 우선일 수 있습니다. 하지만 팀 개발 환경이나 운영 코드에 가까워질수록, 에이전트가 무엇을 할 수 있는지만큼 무엇을 할 수 없어야 하는지도 확인해야 합니다.
Codex의 보안 모델에서 구분해 볼 요소는 두 가지입니다.
- Sandbox: 파일 시스템과 네트워크 접근을 기술적으로 제한하는 경계
- 승인 정책(approval policy): 특정 작업을 실행하기 전에 사용자 확인을 요청하는 시점
OpenAI 공식 문서는 Codex CLI·IDE 환경에서 기본적으로 네트워크를 비활성화하고, 활성 워크스페이스 안에서의 쓰기 권한을 기준으로 실행 범위를 다룬다고 설명합니다. 그래서 운영 전환의 첫 기준은 “코드 생성 테스트 통과”가 아니라, 허용된 작업은 성공하고 차단돼야 할 작업은 실제로 실패하는지를 기록으로 남기는 일입니다.
Sandbox와 승인 정책은 같은 안전장치가 아닙니다
Sandbox와 승인 정책은 함께 언급되지만 역할은 다릅니다.
Sandbox는 에이전트 실행에 기술적 경계를 둡니다. 예를 들어 활성 워크스페이스 안의 파일 수정은 허용하되, 워크스페이스 밖 파일 수정이나 네트워크 접근은 제한하는 방식입니다. 반면 승인 정책은 에이전트가 특정 명령을 실행하려 할 때 사용자에게 확인을 받도록 하는 제어입니다.
이 차이를 놓치면 다음과 같은 오해가 생길 수 있습니다.
- 승인 창이 떴으니 기술적으로도 완전히 차단됐다고 생각한다.
- 네트워크가 기본 비활성화이니 모든 실행 환경에 같은 정책이 적용된다고 생각한다.
- 로컬 환경에서 확인한 실행 결과를 클라우드나 다른 OS 환경에도 그대로 적용한다.
운영 전환에서는 “승인을 받는다”와 “실행할 수 없다”를 따로 확인해야 합니다. 승인 정책은 사용자가 개입할 지점을 정하고, Sandbox는 실행 가능한 범위를 제한하기 때문입니다.
OpenAI는 Sandbox를 파일 시스템·네트워크 등 실행 환경의 경계로 설명하며, 승인과 Sandbox를 별도로 구성할 수 있는 보안 모델을 안내합니다.
출처: OpenAI Codex — Sandboxing, OpenAI Codex — Agent approvals & security
운영 전환의 첫 산출물은 ‘환경별 허용·차단 테스트 기록표’입니다
운영 코드로 넘어가기 전에 필요한 것은 복잡한 정책 문서가 아니라, 재현 가능한 테스트 기록표 한 장입니다.
각 실행 환경에서 아래 두 종류의 시나리오를 모두 실행하는 것이 핵심입니다.
1. 허용돼야 하는 작업
- 활성 워크스페이스 안의 테스트용 파일을 생성하거나 수정하는 작업
- 변경 뒤 프로젝트의 기존 테스트 또는 검증 명령을 실행하는 작업
2. 차단돼야 하는 작업
- 활성 워크스페이스 밖의 파일을 수정하려는 작업
- 현재 정책에서 허용하지 않은 네트워크 접근을 시도하는 작업
중요한 점은 차단 시나리오를 설명으로만 남기지 않는 것입니다. 실제 에이전트 세션에서 요청한 뒤, 결과가 거부·승인 요청·실행 성공 중 무엇으로 나타났는지 기록해야 합니다.
예시는 다음처럼 단순하게 시작할 수 있습니다.
구분 | 테스트 요청 | 기대 결과 | 실제 결과 | 판정 |
|---|---|---|---|---|
허용 | 활성 워크스페이스 안에 테스트 파일 수정 | 수정 성공 | 실행 후 기록 | 통과/실패 |
차단 | 워크스페이스 밖 파일 수정 시도 | 차단 또는 승인 정책에 따른 중단 | 실행 후 기록 | 통과/실패 |
차단 | 네트워크 접근 시도 | 현재 정책에 따른 차단 또는 승인 요청 | 실행 후 기록 | 통과/실패 |
승인 | 승인 대상 명령 실행 | 지정된 시점에 사용자 확인 요청 | 실행 후 기록 | 통과/실패 |
이 표의 목적은 “가장 강한 제한”을 증명하는 데 있지 않습니다. 팀이 선택한 실행 경계가 실제 설정과 일치하는지 확인하는 데 있습니다. 예를 들어 네트워크 사용이 필요한 업무라면 무조건 차단하기보다, 어떤 작업에서 어떤 승인 절차를 거칠지 따로 정의해야 합니다.
Codex의 고급 설정 문서는 실행 환경과 설정에 따라 Sandbox 및 승인 동작을 조정할 수 있다고 안내합니다. 따라서 기본값만 인용해 운영 기준을 확정하기보다, 팀이 실제로 사용하는 실행 환경에서 같은 시나리오를 재현해 볼 필요가 있습니다.
출처: OpenAI Codex — Advanced Configuration
테스트 통과 이후에는 ‘권한 확대’가 아니라 ‘변경 관리’로 넘어가야 합니다
차단 테스트가 통과했다고 해서 이후 설정을 그대로 고정할 수 있는 것은 아닙니다. 다음 변경은 다시 검증해야 합니다.
- Codex 실행 위치가 로컬에서 다른 환경으로 바뀌는 경우
- 워크스페이스 범위가 달라지는 경우
- 네트워크 접근 정책을 변경하는 경우
- 승인 정책을 완화하거나 자동화를 늘리는 경우
- 팀 공통 설정과 개인 로컬 설정이 달라지는 경우
특히 조직의 관리 정책, OS, 로컬·클라우드 실행 위치에 따라 실제 승인과 Sandbox의 적용 범위는 달라질 수 있습니다. 이 부분은 공개 문서의 일반 설명만으로 단정하지 말고, 각 팀 환경에서 확인해야 합니다.
운영 전환의 기준은 다음처럼 정의하는 편이 실용적입니다.
에이전트가 필요한 작업을 수행할 수 있고, 금지한 작업은 실제 실행 환경에서 기대한 방식으로 차단되며, 그 결과를 재검증할 기록표가 있을 때 운영 전환을 검토한다.
바로 적용하는 체크리스트 또는 비교 기준
- [ ] Codex가 실행되는 위치를 정리했습니다.
- 로컬인지, 별도 실행 환경인지 확인합니다.
- [ ] 활성 워크스페이스의 범위를 명확히 했습니다.
- 에이전트가 수정해도 되는 디렉터리를 팀 기준으로 정의합니다.
- [ ] Sandbox와 승인 정책을 각각 확인했습니다.
- “승인 요청”과 “기술적 차단”을 같은 의미로 처리하지 않습니다.
- [ ] 허용 시나리오 1건을 실제 실행했습니다.
- 워크스페이스 안의 파일 수정 또는 검증 명령처럼 필요한 업무를 대상으로 합니다.
- [ ] 차단 시나리오 2건을 실제 실행했습니다.
- 워크스페이스 밖 수정 시도
- 현재 정책에서 허용하지 않은 네트워크 접근 시도
- [ ] 결과를 환경별 기록표에 남겼습니다.
- 요청 내용, 기대 결과, 실제 결과, 판정을 함께 기록합니다.
- [ ] 설정 변경 시 재검증 조건을 정했습니다.
- 실행 위치, 네트워크 정책, 워크스페이스 범위, 승인 정책 변경을 재시험 조건으로 둡니다.
- [ ] 조직 관리 정책과 실제 적용 범위를 확인했습니다.
- 이 항목은 사용 중인 플랜, 관리자 구성, OS 및 실행 위치에 따라 달라질 수 있으므로 확인이 필요합니다.
마무리
AI 코딩 에이전트를 운영 코드에 가까운 환경으로 옮길 때 중요한 질문은 “얼마나 잘 코드를 만드는가”만이 아닙니다.
“이 에이전트가 하면 안 되는 일을 실제로 못 하게 만들었는가”도 함께 확인해야 합니다.
Codex의 Sandbox와 승인 정책을 나눠 이해하고, 허용 작업과 차단 작업을 각각 실제로 시험해 보세요. 그러면 추상적인 보안 우려를 실행 가능한 운영 기준으로 바꿀 수 있습니다.
생각해볼 질문: 우리 팀의 에이전트는 지금 승인받아야 하는 작업과 어떤 경우에도 실행되면 안 되는 작업을 구분해 두었을까요?
이 글이 도움이 되었나요?
관련 포스트
AI 생성 코드, PR 머지 전에 CodeQL Autofix를 보안 게이트로 쓰는 법
바이브 코딩으로 만든 코드를 운영 브랜치에 넣기 전에는 "테스트 통과"만 보면 부족합니다. CodeQL 경고, Autofix 제안, 사람 리뷰, 머지 보호 규칙까지 PR 안에 남겨야 합니다.
Claude Agent Skills로 반복 문서 산출물을 팀 표준으로 만드는 법
매번 프롬프트를 다시 쓰는 대신, `SKILL.md`·템플릿·검증 체크리스트를 한 폴더에 묶으면 리서치 브리프나 보고서 같은 반복 문서 업무를 팀 표준 산출물로 재현할 수 있습니다.
AI Mode 시대 글 구조, “키워드 1개”보다 “하위 질문 지도”부터 만들어야 합니다
AI 검색에 맞는 글쓰기는 새로운 꼼수가 아니라, 하나의 키워드를 독자의 후속 질문 묶음으로 쪼개고 각 질문마다 근거·예시·다음 행동을 붙이는 구조 설계입니다.
n8n·Zapier·Make, AI에게 실행 권한을 주기 전에 먼저 비교해야 할 것
노코드 자동화 도구를 AI/MCP에 연결할 때는 “무엇을 자동화할 수 있나”보다 “AI가 어디까지 실행·수정할 수 있나”를 먼저 봐야 합니다.
Chrome DevTools MCP, AI 코딩 에이전트에게 “브라우저 실행 결과”를 보게 하는 법
AI가 코드를 고쳤다고 끝내지 말고, Chrome DevTools MCP로 실제 브라우저의 DOM·콘솔·성능 트레이스까지 확인하게 만들어야 합니다.
P&ID·설계 PDF를 RAG에 넣기 전: 표·도형·체크박스 추출 품질부터 검증하는 법
설계 PDF 기반 RAG의 첫 산출물은 챗봇이 아니라, 원문과 대조해 통과 여부를 판단할 수 있는 **추출 승인표**여야 합니다.