코덱스 툴 사용법 25: 권한 프로필로 작업장 경계 고정하기 | DAKER 커뮤니티

코덱스 툴 사용법 25: 권한 프로필로 작업장 경계 고정하기

Codex 자동화를 매일 돌리다 보면 “이번 작업은 파일을 고쳐도 되지만 .env는 읽으면 안 되고, 네트워크는 특정 API만 허용하고 싶다” 같은 요구가 생깁니다. 이때 매번 프롬프트에 길게 쓰는 것보다, 반복되는 경계는 권한 프로필로 고정하는 편이 낫습니다.

OpenAI Codex 공식 문서 기준으로 sandbox는 Codex가 로컬 명령을 실행할 때의 기술적 경계이고, approval policy는 그 경계를 넘으려 할 때 언제 멈춰 물어볼지를 정하는 흐름입니다. 최근 문서의 permissions 프로필은 파일시스템과 네트워크 접근을 작업 종류별로 묶어 재사용하는 방식입니다.

어제 24편에서 Rules로 “명령 prefix를 어떻게 허용할까”를 다뤘다면, 오늘은 그보다 바깥의 작업장 지도를 다룹니다. Rules가 특정 명령의 승인 기준이라면, 권한 프로필은 “이 세션이 어디까지 읽고, 쓰고, 연결할 수 있는가”를 정합니다.

한 줄 요약

반복 작업에는 danger-full-access를 기본값으로 두지 말고, 파일 쓰기 범위와 네트워크 도메인을 좁힌 권한 프로필을 만들어 Codex가 멈춰야 할 지점을 명확히 하세요.

sandbox와 approval을 분리해서 생각하자

Codex의 안전장치는 두 층입니다.

이 셋을 섞으면 설정이 위험해집니다. 예를 들어 “승인 질문이 귀찮다”는 이유로 full access를 켜면 문제는 해결된 것처럼 보이지만, 실제로는 파일시스템과 네트워크 경계를 동시에 없앤 것입니다. 반대로 권한 프로필을 좁게 잡으면 Codex가 반복 작업을 계속하되, 민감한 위치나 외부 연결에서는 멈추게 만들 수 있습니다.

기본값은 보통 workspace-write가 맞다

공식 문서는 버전 관리되는 폴더에서 기본적으로 Auto, 즉 워크스페이스 쓰기와 필요 시 승인 요청에 가까운 흐름을 권장합니다. 로컬 개발에서는 이 조합이 가장 현실적입니다.

codex --sandbox workspace-write --ask-for-approval on-request

이 모드에서 Codex는 현재 작업 디렉터리 안의 파일을 읽고 고치며, 테스트나 빌드 같은 로컬 명령을 실행할 수 있습니다. 하지만 워크스페이스 밖 파일을 수정하거나, 막힌 네트워크 접근이 필요하면 승인 흐름으로 넘어갑니다.

문제는 모든 작업이 같은 경계를 원하지 않는다는 점입니다. 문서 감사는 읽기만 필요하고, 블로그 게시 자동화는 특정 초안 폴더와 특정 도메인만 필요합니다. 이 차이를 세션마다 말로 반복하지 않으려면 프로필로 나눕니다.

권한 프로필은 작업 이름에서 시작한다

좋은 프로필 이름은 권한보다 작업을 설명합니다.

[permissions.audit-readonly.filesystem]
":workspace_roots" = "read"

[permissions.project-edit.filesystem]
":minimal" = "read"

[permissions.project-edit.filesystem.":workspace_roots"]
"." = "write"
".devcontainer" = "read"
"**/*.env" = "deny"

audit-readonly는 코드를 읽고 분석하는 작업입니다. 쓰기가 필요 없습니다. project-edit는 일반 개발 작업입니다. 워크스페이스는 쓸 수 있지만 .env 같은 민감 파일은 읽기까지 막습니다.

여기서 중요한 점은 deny입니다. “수정하지 말라”가 아니라 “읽지 말라”까지 표현할 수 있어야 합니다. Codex가 의도치 않게 비밀값을 요약하거나 로그에 섞는 일을 줄이려면, 민감 파일은 프롬프트 경고보다 권한 거부로 막는 편이 더 낫습니다.

더 구체적인 규칙이 더 넓은 규칙을 이긴다

permissions 문서는 파일 접근에 read, write, deny를 사용합니다. 더 구체적인 항목이 더 넓은 항목을 덮고, 같은 경로에서는 deny가 write보다 강하고 write가 read보다 강합니다.

예를 들어 아래 설정은 워크스페이스 전체를 쓸 수 있게 하면서도, .env 계열 파일은 거부합니다.

[permissions.project-edit.filesystem.":workspace_roots"]
"." = "write"
"**/*.env" = "deny"

이런 구조는 실무에서 유용합니다. 대부분의 소스 파일은 Codex가 고칠 수 있어야 하지만, 환경 변수와 키 파일은 작업 편의 때문에 열어둘 이유가 거의 없습니다. 프롬프트에 “비밀값 읽지 마”라고 쓰는 것보다, 프로필에서 읽기 자체를 거부하는 것이 더 확실합니다.

네트워크는 켜는 순간 도메인을 좁힌다

로컬 Codex의 기본 workspace-write 흐름은 네트워크를 꺼둡니다. 네트워크가 필요한 프로필을 만들 때는 enabled = true만 두고 끝내지 말고, 도메인 규칙까지 같이 적어야 합니다.

[permissions.publish-draft.network]
enabled = true

[permissions.publish-draft.network.domains]
"daker.ai" = "allow"
"api.openai.com" = "allow"
"*" = "deny"

실제 도메인 정책에서는 deny가 allow보다 우선합니다. 넓은 * 허용은 사실상 외부 네트워크를 모두 여는 선택이므로, 자동화에는 되도록 쓰지 않는 편이 좋습니다.

로컬 개발 서버도 따로 봐야 합니다. 공식 문서는 로컬과 사설 주소 접근을 기본적으로 조심스럽게 다룹니다. localhost가 필요하면 정확히 허용하고, allow_local_binding = true 같은 넓은 설정은 정말 필요한 경우에만 씁니다.

Mermaid로 보는 프로필 선택 흐름

아래는 초안 단계에서 쓴 Mermaid 의사결정 흐름입니다. 게시 본문에는 같은 흐름을 SVG로 렌더링해 넣습니다.

Mermaid 원본:
flowchart TD
  A[작업이 파일을 바꾸는가?] -->|아니오| B[읽기 전용 프로필]
  A -->|예| C{외부 네트워크가 필요한가?}
  C -->|아니오| D[워크스페이스 편집]
  C -->|예| E[네트워크 예외 검토]
  B --> F[민감 파일 deny 확인]
  D --> F
  E --> F
  F --> G[필요하면 Rules와 approval 유지]

핵심은 질문의 순서입니다. 처음부터 “어디까지 풀어줄까?”라고 묻지 말고 “읽기만 하는가, 파일을 바꾸는가, 외부 네트워크가 필요한가”를 차례로 묻습니다. 그러면 full access가 필요한 작업이 생각보다 적다는 것을 알 수 있습니다.

Rules는 프로필을 대체하지 않는다

Rules와 permissions profile은 서로 보완 관계입니다.

예를 들어 gh pr view 같은 조회 명령을 반복해서 허용하고 싶다면 Rules가 맞습니다. 하지만 “이 프로젝트 자동화는 drafts/와 assets/만 쓰고, 외부 연결은 DAKER와 OpenAI 문서만 허용한다”는 요구는 프로필에 가깝습니다.

둘을 섞는 좋은 방식은 이렇습니다. 프로필로 넓은 작업장을 좁히고, Rules로 그 안에서 반복되는 명령 승인 소음을 줄입니다. 반대로 Rules에 모든 보안 기대를 밀어 넣으면 파일 읽기나 네트워크 범위 같은 기본 경계가 흐려집니다.

자동화용 프로필 예시

DAKER 게시 자동화 같은 작업을 상상해보면 프로필은 이렇게 나눌 수 있습니다.

[permissions.daker-post.filesystem]
":minimal" = "read"

[permissions.daker-post.filesystem.":workspace_roots"]
"drafts" = "write"
"assets" = "write"
"scripts" = "read"
"**/*.env" = "deny"

[permissions.daker-post.network]
enabled = true

[permissions.daker-post.network.domains]
"daker.ai" = "allow"
"developers.openai.com" = "allow"

이 프로필은 초안과 이미지 자산은 만들 수 있게 하면서, 스크립트는 읽기만 허용합니다. 네트워크도 게시 대상과 공식 문서 확인에 필요한 도메인만 엽니다.

실제 운영에서는 API 토큰이나 쿠키를 직접 읽지 않도록 해야 합니다. 로그인된 브라우저 세션이 필요한 경우에는 Chrome 확장 같은 별도 표면을 쓰고, 로컬 프로필은 초안 생성과 payload 검증까지로 제한하는 편이 안전합니다.

danger-full-access는 디버깅 도구에 가깝다

공식 문서는 danger-full-access를 sandbox 제한 없이 실행하는 넓은 모드로 설명합니다. 여기에 approval policy never까지 붙이면 사실상 Codex가 로컬 머신과 네트워크를 거의 제약 없이 다루게 됩니다.

이 모드가 전혀 쓸모없다는 뜻은 아닙니다. 격리된 throwaway 환경, 재현용 컨테이너, 이미 폐기 가능한 임시 워크스페이스에서는 필요할 수 있습니다. 하지만 일상 개발 저장소의 기본값으로 두면 나중에 “왜 이 파일을 읽었지?”, “왜 외부로 연결했지?”를 추적하기 어렵습니다.

일상 자동화에서는 반대로 접근하세요.

1. 읽기 전용으로 가능한지 먼저 본다.

2. 쓰기가 필요하면 워크스페이스 또는 하위 폴더만 연다.

3. 네트워크가 필요하면 도메인을 나열한다.

4. 반복되는 낮은 위험 명령만 Rules로 줄인다.

5. 그래도 막히는 작업만 한 번 승인하거나 별도 프로필로 분리한다.

실패 모드

첫째, write를 주면 민감 파일을 읽지 않을 것이라고 착각합니다. 쓰기 권한은 보통 읽기도 포함합니다. 민감 파일은 별도 deny가 필요합니다.

둘째, 네트워크를 켜고 도메인 규칙을 비워둡니다. 자동화가 외부 문서를 확인해야 한다면 필요한 공식 도메인만 적고, 게시 대상도 명시하세요.

셋째, 한 프로필에 모든 작업을 담습니다. 읽기 감사, 일반 편집, 게시 자동화, 배포 작업은 위험이 다릅니다. 이름을 나눠야 검토도 쉬워집니다.

넷째, Rules를 권한 프로필처럼 씁니다. Rules는 명령 prefix 판정에 강하지만 파일 읽기 범위나 네트워크 목적지를 설명하는 도구가 아닙니다.

시니어 엔지니어의 결론

Codex 권한 프로필은 “AI에게 더 많이 맡기기” 위한 설정이 아니라, 더 오래 맡겨도 되는 작업장 경계를 만드는 설정입니다. 읽기, 쓰기, 네트워크, 승인 흐름을 분리해서 생각하면 Codex 자동화가 훨씬 예측 가능해집니다.

팀에서 반복되는 AI 코딩 작업이 있다면 먼저 세 가지 프로필부터 만드세요. audit-readonly, project-edit, publish-draft입니다. 그리고 각 프로필에 민감 파일 deny와 필요한 도메인만 넣으세요. 그러면 바이브코딩 속도는 유지하면서도, 사고가 나기 쉬운 경계는 코드처럼 리뷰할 수 있습니다.

참고: OpenAI Codex sandboxing, permissions, agent approvals & security, rules 문서를 2026-06-17 Asia/Seoul 기준으로 확인했습니다.