핵심 정리

조직 운영 표면
- Analytics Dashboard: 채택률, 사용량, Code Review 영향 빠른 확인
- Analytics API: 일/주 단위 지표를 내부 BI나 데이터 웨어하우스로 연결
- Compliance API: 감사, 조사, 보안 모니터링용 활동 로그 export
- Requirements: 사용자가 우회할 수 없는 보안 제약
- Managed defaults: 다음 시작 시 다시 적용되는 조직 기본값

운영 표면

Analytics는 도입 현황과 비용 흐름을 보는 표면이다

Codex Enterprise 거버넌스에서 Analytics Dashboard는 일상적인 운영 가시성에 가깝습니다. 관리자는 CLI, IDE extension, cloud, desktop, Code Review 같은 제품 표면별 active user와 usage를 보고, workspace와 개인 사용량, credit과 token 사용량, 모델별 사용 흐름을 확인합니다. Code Review를 쓰는 조직이라면 PR 리뷰 수, 우선순위별 코멘트, 반응과 피드백까지 함께 보면서 실제 엔지니어링 영향도를 추적할 수 있습니다.

Analytics API는 같은 지표를 내부 대시보드나 데이터 웨어하우스로 가져올 때 씁니다. 공식 문서는 일/주 단위 bucket, workspace-level과 per-user usage, client별 breakdown, Code Review throughput과 engagement 지표를 API로 다루는 흐름을 설명합니다. 운영 리포트를 수동 캡처로 만들기 시작했다면 API 전환 시점입니다.

Compliance API는 보안과 감사용 로그 export 표면이다

Compliance API는 사용량 대시보드가 아니라 감사 가능성을 위한 표면입니다. 보안, 법무, eDiscovery, DLP, SIEM 같은 체계로 Codex 활동 로그와 메타데이터를 내보낼 때 사용합니다. ChatGPT로 인증한 Codex 사용은 Compliance API export에 포함될 수 있지만, API-key 기반 Codex 사용은 API 조직 설정을 따르며 Compliance API export 범위와 다를 수 있습니다. 이 경계를 모르면 "모든 Codex 활동이 같은 로그에 남는다"고 잘못 가정하기 쉽습니다.

requirements와 managed defaults는 강제력 기준이 다르다

Enterprise admins는 local Codex 동작을 requirements와 managed defaults 두 방식으로 제어할 수 있습니다. requirements는 사용자가 우회할 수 없는 제약입니다. approval policy, approvals reviewer, automatic review policy, sandbox mode, web search mode, managed hooks, MCP server allowlist 같은 보안 민감 설정을 제한하는 데 씁니다.

managed defaults는 시작값입니다. 사용자가 세션 중 바꿀 수 있지만, Codex가 다음에 시작할 때 조직 기본값이 다시 적용됩니다. 따라서 보안 정책처럼 반드시 막아야 하는 값은 requirements로 두고, 팀 권장값이나 초기 설정은 managed defaults로 두는 것이 맞습니다.

어디에 둘까

주의할 점

실패 예시
- Analytics Dashboard에서 사용량을 보고 있으니 조직 통제가 충분하다고 판단함
- 실제로는 web search mode, sandbox mode, MCP server 범위를 사용자가 넓힐 수 있었음
- 대응: 관측은 Analytics/Compliance, 강제는 requirements/managed config로 분리한다