팀에서 Codex 도입하기: 권한, 규칙, Bedrock 경로를 위한 의사결정 가이드

팀이 Codex를 함께 쓰기 시작하면 보안과 운영이 가장 먼저 묻는 질문은 보통 “어떤 플랜을 사야 하나요?”가 아닙니다. 대개는 “누가 full access를 가지는가, .env는 무엇을 읽을 수 있는가, 사용량과 감사 로그는 어디서 보는가?”입니다. 이 질문들이 도입의 첫 단계를 결정합니다. 답은 API Key를 먼저 고르는 것이 아닙니다. 먼저 권한 경계를 정하는 것입니다. 이 글은 기업 도입을 위한 의사결정 프레임워크를 제안합니다. requirements.toml과 permission profiles로 구성원 권한을 제한하고, 공유 AGENTS.md 규칙을 표준화하고, ChatGPT workspace, API Key, Amazon Bedrock 같은 배포 경로를 고른 뒤, 마지막에 analytics와 compliance를 연결하는 흐름입니다. 하나 더 분명히 해야 할 사실이 있습니다. AWS는 2026-06-03에 GovCloud에서 GPT-5.4 사용 가능을 발표했지만, Codex용 Bedrock provider는 현재 GovCloud endpoint를 지원하지 않습니다. 이 둘은 같은 사실이 아닙니다.

1. 기업 권한 프레임워크: full access를 모든 로컬 머신에 두지 마세요

회사가 Codex를 표준화하려면 cloud-managed requirements로 로컬 동작을 제한할 수 있습니다. requirements.toml은 Codex의 정책 파일입니다. 관리자는 모든 구성원이 각자 환경을 마음대로 설정하게 두는 대신, 사용자 그룹별로 다른 정책을 적용할 수 있습니다.

1.1 requirements.toml의 핵심 항목

이 배포를 시작할 때 가장 자주 쓰는 항목은 다음과 같습니다.

항목	용도	권장 값
approval_policy	사람 승인 필요 여부를 제어	"suggest" 또는 "auto-edit"; 팀 기본값으로 "never"는 쓰지 마세요
approvals_reviewer	승인 담당자 지정	팀 owner 또는 보안 책임자
automatic_review_policy	자동 검토 규칙	프로젝트 위험 수준에 맞게 설정
permission profiles	더 새로운 권한 모델(0.138.0+)	새 배포에 권장
sandbox_mode	이전 권한 모델	레거시 마이그레이션에만 사용
web_search_mode	웹 검색 허용 여부	선택 사항이지만 민감한 프로젝트에서는 제한 권장
managed_hooks	통합된 hook 설정	lint-check, test-runner 같은 훅
MCP servers allowlist	사용할 MCP 서버 목록	승인된 filesystem, github만

Codex 0.138.0 이후는 allowed_permission_profiles와 default_permissions가 있는 permission profiles를 권장합니다. 이전 배포는 allowed_sandbox_modes를 사용할 수 있습니다.

1.2 금지 조합

팀 기본값으로 아래 조합은 쓰면 안 됩니다.

danger-full-access + approval_policy = "never"

이건 최대 권한에 승인 없음 조합입니다. 개별 로컬 설정에 나타나지 않도록 클라우드 관리 요구사항에서 막아야 합니다.

1.3 설정 예시

# requirements.toml
[managed]
approval_policy = "suggest"
allowed_permission_profiles = ["suggest", "auto-edit"]
default_permissions = "suggest"

[mcp]
allowed_servers = ["filesystem", "github"]

[hooks]
managed_hooks = ["lint-check", "test-runner"]

이 예시는 구성원을 "suggest" 또는 "auto-edit"로 제한하고, 기본값은 "suggest"로 두며, MCP는 filesystem과 github만 허용하고, 훅은 일관되게 유지합니다. 핵심 개발 그룹에 "auto-edit"를 주고 더 제한된 프로필에는 "suggest"를 유지하고 싶다면 여기가 맞는 자리입니다.

2. 최소 권한과 sandbox 설계: 구체 규칙, deny glob, 민감 파일 보호

보안 담당자에게 필요한 것은 “최소 권한”이라는 구호가 아닙니다. 어떤 파일은 읽을 수 있고, 어떤 파일은 쓸 수 있고, 어떤 파일은 완전히 금지되는지에 대한 구체 규칙입니다.

2.1 filesystem의 세 가지 값

Codex의 filesystem 권한은 세 가지 값을 지원합니다.

• read: 읽기 전용, 수정 불가
• write: 읽기/쓰기 가능, 수정 허용
• deny: 완전 차단

우선순위 규칙은 단순합니다. 더 구체적인 규칙이 우선하고, deny가 가장 높습니다. 예를 들어 "**/*.env" = "deny"와 ":workspace_roots" = "write"를 같이 두면, workspace root가 쓰기 가능해도 .env는 막힙니다.

2.2 workspace 범위 제한

:workspace_roots로 작업 범위를 제한하세요. 예:

[permissions.filesystem]
":workspace_roots" = "write"

이렇게 하면 Codex는 현재 workspace root와 그 하위에서만 동작합니다. 바깥 파일에는 닿지 못합니다.

2.3 민감 파일 보호

deny glob을 써서 환경 파일과 비밀 디렉터리를 접근 불가로 만들 수 있습니다.

[permissions.filesystem]
":workspace_roots" = "write"
"**/*.env" = "deny"
"**/secrets/**" = "deny"
"**/*.log" = "read"

이 설정은 다음을 의미합니다.

• workspace root와 하위는 쓰기 가능
• 모든 .env 파일은 전체 트리에서 차단
• secrets/ 디렉터리와 하위는 차단
• .log 파일은 읽기 전용

2.4 네트워크 권한

네트워크 권한은 도메인 allow/deny 목록으로 제어할 수 있습니다.

[permissions.network]
enabled = true
allow = ["github.com", "api.openai.com"]
deny = ["localhost", "127.0.0.1"]

이 설정은 github.com과 api.openai.com은 허용하고, localhost와 loopback은 차단합니다. 로컬/프라이빗 네트워크에 대한 추가 보호도 있으므로 팀은 자체 정책에 맞게 도메인을 정할 수 있습니다.

2.5 permission profiles와 sandbox mode

비교	Permission profiles	Sandbox mode
출시 단계	더 새로운 모델	레거시 모델
세분화	더 세밀함	더 거침
설정 필드	allowed_permission_profiles + default_permissions	allowed_sandbox_modes
권장	새 배포에 우선	레거시 마이그레이션용

새 배포는 permission profiles를 우선해야 합니다. sandbox mode는 점진적으로 줄여 나가면 됩니다.

3. 팀 공통 규칙: 사람마다 AGENTS.md를 따로 쓰지 마세요

팀에는 공유 프롬프트와 공유 컨텍스트 규칙, 공유 review 지침이 필요합니다. 각자 따로 버전을 관리하면서 유지보수 부담을 나눠 갖는 식은 필요 없습니다. AGENTS.md는 Codex의 지침 파일이며, 계층형 규칙과 우선순위를 지원합니다.

3.1 instruction chain 순서

Codex가 시작할 때 만드는 instruction chain은 다음 순서입니다.

global rules (~/.config/codex/AGENTS.md)
  -> project rules (project AGENTS.md)
  -> nearest-to-current-directory rules

가장 가까운 파일이 겹칠 때 우선합니다.

3.2 계층형 구조

모든 규칙을 거대한 파일 하나에 넣지 마세요. 다음처럼 나누는 편이 좋습니다.

• ~/.config/codex/AGENTS.md: 전역 규칙, 스타일, 테스트 기대치, 일반 금지
• 프로젝트 AGENTS.md: 아키텍처, 의존성, 배포 방식
• 모듈 AGENTS.md: 모듈별 특수 요구사항

각 계층은 10-15 KiB 정도로 유지하는 것이 관리와 잘림 방지에 좋습니다.

3.3 32 KiB 제한 다루기

Codex는 기본적으로 project_doc_max_bytes를 32 KiB로 둡니다. AGENTS.md가 너무 커지면 잘릴 수 있습니다.

해결 방법은 두 가지입니다.

1. project_doc_max_bytes를 올린다
2. 문서를 중첩 디렉터리로 나눈다

보통은 두 번째가 더 낫습니다. 책임과 유지보수가 더 명확해지기 때문입니다.

3.4 AGENTS.override.md의 용도

AGENTS.override.md는 상위 AGENTS.md를 덮어쓰는 파일이고 우선순위가 가장 높습니다. 다음 경우에 사용하세요.

• 특정 하위 디렉터리에 임시 규칙이 필요할 때
• 실험적 모듈에 더 느슨한 제한이 필요할 때
• 모듈이 프로젝트 정책과 달라야 할 때

팀이 헷갈리지 않도록 override 이유를 기록하세요.

3.5 유지보수 팁

AGENTS.md를 유지할 때는 다음을 명확히 하세요.

• Ownership: 어느 계층을 누가 유지하는가
• Maintenance budget: sprint마다 review 시간을 얼마나 쓰는가
• Review cycle: 전역 규칙은 분기별, 프로젝트 규칙은 월별로 볼지

이렇게 해야 AGENTS.md가 개인 문서가 아니라 살아 있는 공유 기준이 됩니다.

4. 배포 경로 선택: ChatGPT workspace, API Key, Bedrock 중 어떻게 고를까

조직은 어떤 계정 경로를 채택할지 정해야 합니다. 세 옵션은 장점, 한계, 적합한 상황이 다릅니다.

4.1 비교 표

항목	ChatGPT Business/Enterprise	API Key	Amazon Bedrock
인증	ChatGPT 로그인	OPENAI_API_KEY	Bedrock API key 또는 AWS IAM
과금 주체	OpenAI workspace	OpenAI API 계정	AWS 계정
팀 거버넌스	Analytics Dashboard, managed requirements	팀 거버넌스 없음	AWS IAM과 CloudTrail
기능 완성도	가장 완전함	가장 유연함	일부 기능만 제공(4.2 참조)
규정/리전	OpenAI 리전	OpenAI 리전	AWS 리전과 data residency
GovCloud 지원	없음	없음	모델은 가능할 수 있지만 Codex provider 지원은 별도(4.3 참조)
적합한 팀	workspace 관리를 원하는 중소팀	유연한 개발 연동이 필요한 개발자	AWS 중심으로 과금, IAM, compliance를 원하는 팀

4.2 Bedrock에서 빠진 기능

2026-06-08 기준으로 아래 기능은 이 경로에서 사용할 수 없습니다.

• Fast Mode
• hosted web/file search
• computer use
• shell tool
• image generation tool
• remote MCP servers
• on-demand inference only는 지원되지 않으며 Provisioned Throughput을 사용해야 합니다

이 기능들은 OpenAI 호스팅 클라우드 서비스, hosted tool, 클라우드 관리 탐색에 의존하므로 이 경로 바깥입니다. 팀이 이 기능에 의존한다면 ChatGPT workspace나 API Key를 쓰세요.

4.3 GovCloud 정리

여기에는 서로 다른 사실이 두 개 있습니다.

1. AWS GovCloud (US-West)에서 GPT-5.4는 사용 가능

   • 모델 자체가 GovCloud에서 사용 가능
   • GPT-5.4는 Bedrock API로 호출 가능

2. Codex용 Bedrock provider는 GovCloud endpoint를 지원하지 않음

   • Codex의 amazon-bedrock provider는 현재 AWS GovCloud 리전의 Bedrock Mantle endpoint를 지원하지 않음
   • 오늘 기준으로 GovCloud에 Codex를 Bedrock으로 연결할 수 없음

“Codex on Bedrock supports GovCloud”라고 적으면 안 됩니다. 같은 사실이 아니기 때문입니다.

4.4 적용 시나리오

조직에 따라 경로를 고르세요.

ChatGPT Business/Enterprise

• 작은 팀과 중간 규모 팀
• workspace 관리가 필요
• 가장 완전한 기능이 필요
• AWS 과금이나 IAM은 필요 없음

API Key

• 유연한 연동이 필요한 개발자
• 팀 거버넌스는 불필요
• OpenAI API 계정으로 직접 과금
• compliance 관리가 필요 없음

Amazon Bedrock

• 기존 AWS 계정, IAM, 과금 체계를 가진 AWS 중심 팀
• AWS 약정 아래로 비용을 모으고 싶음
• data residency 또는 특정 AWS 리전이 필요
• 일부 기능 축소를 받아들일 수 있음(4.2 참조)

5. Bedrock 설정과 한계: AWS-native auth, 빠진 기능, GovCloud 리스크

Bedrock을 고른 팀은 정확한 설정, 인증 방식, 빠진 기능, GovCloud 경계를 이해해야 합니다.

5.1 amazon-bedrock provider 설정

Codex 설정 파일에서 provider를 이렇게 둡니다.

{
  "provider": "amazon-bedrock",
  "aws_region": "us-east-1",
  "model_id": "openai.gpt-5.5"
}

모델 ID와 리전은 공식 문서를 따라야 합니다.

5.2 AWS-native auth

Bedrock 경로는 OPENAI_API_KEY가 아니라 AWS-native authentication을 사용합니다.

• Bedrock API key: 최대 12시간 또는 session duration의 단기 키, IAM principal permissions를 상속
• AWS IAM credentials: IAM role 또는 IAM user로 구성

운영 환경에는 단기 키나 IAM role을 권장합니다. 장기 키는 탐색용으로만 쓰세요.

5.3 지원되는 상용 AWS 리전

공식 문서는 현재 다음 상용 AWS 리전을 지원합니다.

• us-east-1
• us-west-2
• eu-west-1
• ap-northeast-1

현재 목록은 AWS Bedrock OpenAI models 문서를 확인하세요.

5.4 Bedrock API key 거버넌스

Bedrock 키의 관리 규칙은 다음과 같습니다.

• Short-term key: 최대 12시간 또는 session duration, IAM principal permissions 상속, 운영 환경 권장
• Long-term key: 탐색용만, 운영 환경 비권장
• CloudTrail logging: API 호출은 AWS CloudTrail에 기록되며 키 자체는 평문 로그에 남지 않음
• IAM actions control: 누가 API key를 만들고 사용할지 IAM actions로 제어 가능

5.5 빠진 기능 목록(재확인)

2026-06-08 기준으로 Bedrock에서는 아래 기능을 사용할 수 없습니다.

• Fast Mode
• hosted web/file search
• computer use
• shell tool
• image generation tool
• remote MCP servers
• on-demand inference only는 지원되지 않으며 Provisioned Throughput을 사용해야 합니다

팀이 이 기능에 의존한다면 ChatGPT workspace나 API Key로 옮기세요.

5.6 GovCloud 리스크(재강조)

다시 한 번 분리해서 보세요.

• AWS GPT-5.4는 GovCloud (US-West)에서 사용 가능: 모델 자체는 GovCloud에서 사용 가능
• Codex Bedrock provider는 GovCloud endpoint를 지원하지 않음: 오늘 기준 AWS GovCloud 리전에 Codex를 Bedrock으로 연결할 수 없음

팀이 GovCloud가 필요하다면 Codex가 이미 거기에 붙는다고 가정하면 안 됩니다.

6. 거버넌스와 감사: 사용량과 compliance 로그는 어디서 보나

관리자는 adoption, usage, code review 영향을 추적해야 하고, 이를 위해 analytics와 audit 출력을 써야 합니다.

6.1 세 가지 거버넌스 경로 비교

경로	기능	지연	적합한 용도
Analytics Dashboard	adoption, usage, code review feedback	최대 12시간 지연 가능	rollout 추적
Analytics API	일/주 단위 bucket, workspace/user 사용량, client별 분해, Code Review 지표	거의 실시간부터 몇 시간	비용 거버넌스와 심층 분석
Compliance API	Codex 활동과 audit metadata export	SIEM/eDiscovery 통합에 따라 다름	compliance 감사

6.2 사용 시나리오

6.2.1 rollout 추적

Analytics Dashboard로 팀 adoption과 usage를 보세요.

• 구성원 활성화율
• code review feedback 품질
• client별 사용 분포

대시보드 데이터는 최대 12시간 지연될 수 있으므로 실시간 모니터링보다 주간/월간 리포트에 더 적합합니다.

6.2.2 비용 거버넌스

Analytics API로 더 깊게 분석하세요.

• workspace/user/model별 사용량 분해
• 일별/주별 bucket 비교
• Codex App/CLI/IDE/Cloud별 분포
• Code Review 지표 요약

내부 비용 거버넌스와 최적화 작업에 맞는 경로입니다.

6.2.3 compliance 감사

Compliance API로 audit log를 내보내세요.

• Codex 활동 기록
• audit metadata
• SIEM/eDiscovery 연동
• compliance 검토 지원

금융, 공공, 의료 같은 규제 산업에 맞는 경로입니다.

6.3 거버넌스 경로 추천

• Analytics Dashboard: 팀 rollout을 보는 기술 책임자와 PM에 적합
• Analytics API: 비용 거버넌스와 심층 분석을 하는 platform engineer에 적합
• Compliance API: SIEM과 eDiscovery를 붙이는 보안/컴플라이언스 팀에 적합

세 경로는 조직 요구에 맞게 조합할 수 있습니다.

7. 팀 rollout 경로: 개인 파일럿에서 조직 거버넌스로

팀은 어디서 시작할지, 어떤 순서로 확장할지, 첫 파일럿 작업을 어떻게 고를지 잘 모를 때가 많습니다.

7.1 세 단계 rollout 프레임워크

단계 1: 개인 제어(권한 경계 정의)

목표: 각 구성원의 권한 경계를 통제 가능하게 만들어 민감한 파일이 로컬 머신에 퍼지지 않게 하는 것.

핵심 행동:

• 팀 기본값으로 danger-full-access + approval_policy = "never" 금지
• .env와 secrets/를 deny glob으로 보호
• :workspace_roots로 작업 영역 제한

성공 기준: 누구도 승인 없이 민감 파일에 접근할 수 없음.

단계 2: 소규모 팀 파일럿(공유 규칙 + 저위험 작업)

목표: 소규모 팀에서 AGENTS.md와 skills를 통일하고, 저위험 작업부터 시작해 흐름이 잘 도는지 검증하는 것.

핵심 행동:

• 전역 AGENTS.md 작성(스타일과 테스트 기대치)
• 프로젝트 AGENTS.md 작성(아키텍처, 의존성, 배포)
• 문서 생성, lint 수정, 테스트 추가 같은 저위험 작업 선택
• 프로덕션 배포나 결제 로직 자동화는 피하기

성공 기준: 대부분이 공유 AGENTS.md를 사용하고 큰 안전 사고가 없음.

단계 3: 조직 거버넌스(managed requirements + Analytics/Compliance API)

목표: 권한과 규칙을 조직 거버넌스로 끌어올리고, 관찰성과 감사 체계를 연결하는 것.

핵심 행동:

• 사용자 그룹별 cloud-managed requirements 설정
• Analytics Dashboard/API로 adoption과 usage 추적
• Compliance API를 SIEM에 연결
• permission profiles와 MCP allowlist를 정기 점검

성공 기준: 거버넌스 대시보드가 올라오고 감사 로그가 추적 가능함.

7.2 추천 파일럿 작업

먼저 저위험 작업부터

첫 파일럿에 좋은 작업:

• 문서 생성: README, API docs, 노트 정리
• lint 수정: eslint, prettier, 포맷 자동화
• 테스트 추가: 단위 테스트와 통합 테스트 뼈대
• 리팩터링 제안: 사람 검토가 필요한 구조 개선

직접 자동화는 피하기

첫 파일럿에 맞지 않는 작업:

• production deploy
• payment logic
• permission change
• data deletion

이런 작업은 위험이 높으니 거버넌스와 감사가 충분히 성숙한 뒤에 하세요.

7.3 시리즈 내 위치

이 글은 팀 도입 의사결정 페이지입니다. 뒤의 글에서는 더 깊게 다룰 수 있습니다.

• AGENTS.md 작성 방식: 계층형 규칙 작성, truncation 회피, 유지보수법
• 개인 블로커와 sandbox: 권한 문제, sandbox 설정, 흔한 실수
• Cloud/GitHub 통합: 원격 개발, GitHub review, cloud task
• 비용과 quota 최적화: token 절감 기술과 예산 제어
• 자동화와 장기 작업: scheduled trigger, heartbeat, 며칠에 걸친 작업

요약과 다음 단계

당신이 Codex를 팀에 도입하는 기술 책임자라면 순서는 다음이어야 합니다.

1. 먼저 권한 설정을 읽기(1, 2장)해서 위험한 조합을 막기
2. 그다음 규칙 표준화(3장)로 AGENTS.md의 형식을 공유하기
3. 그다음 배포 경로 선택(4, 5장)으로 workspace, API Key, Bedrock 중 고르기
4. 마지막에 거버넌스 연결(6장)로 Analytics와 Compliance API를 붙이기

그 다음에는 더 구체적인 모듈로 들어가면 됩니다.

• AGENTS.md 작성 방식: 계층형 규칙 작성, truncation 회피, 유지보수법
• 개인 블로커와 sandbox: 권한 문제, sandbox 설정, 흔한 실수
• Cloud/GitHub 통합: 원격 개발, GitHub review, cloud task
• 비용과 quota 최적화: token 절감 기술과 예산 제어
• 자동화와 장기 작업: scheduled trigger, heartbeat, 며칠에 걸친 작업

관련 기초 개념:

• 팀 Git 협업 기초: Git flow, 브랜치 전략, code review 흐름
• CI secret과 권한 안전: GitHub Actions secrets, 권한 경계, 보안 실천