책에 포함된 노트요즘 바이브 코딩: Codex로 일하는 개발자의 완전 가이드

PART 06-23. 엔터프라이즈 배포

2026-04-25Views 13약 11분생성형 AI 활용

PART 06-23. 엔터프라이즈 배포

개인이 Codex를 잘 쓰는 것과, 조직이 Codex를 안전하게 쓰는 것은 완전히 다른 문제입니다. 개인은 "이 설정이 편하다"로 끝날 수 있지만, 조직은 "누가 어디까지 할 수 있고, 그 기록을 나중에 설명할 수 있는가"까지 답해야 합니다.

여기서 많은 팀이 한 번 넘어집니다. 파일 하나 설치하고, 로그인만 붙이고, 몇 명이 잘 쓰기 시작하면 배포가 끝났다고 생각합니다. 하지만 엔터프라이즈 배포의 진짜 시작점은 설치가 아니라 통제 설계입니다. 한 개발자는 danger-full-access + never로 돌리고, 다른 개발자는 read-only로 묶여 있고, 어떤 팀은 승인 안 된 MCP를 붙여서 사내 문서를 읽고 있다면, 그 조직은 Codex를 도입한 것이 아니라 사람마다 다른 Codex를 제각각 운용하는 상태에 가깝습니다.

Codex는 다행히 이 문제를 다룰 수 있는 구조를 이미 갖고 있습니다. 관리형 기본값, 관리자 강제 정책인 requirements.toml, 그룹별 정책 배포, 감사용 거버넌스 API가 모두 따로 존재합니다. 즉, 잘만 설계하면 개인 생산성 도구를 조직 표준으로 올릴 수 있습니다.¹²³

이 장의 핵심은 하나입니다.

조직 도입에서 먼저 설계해야 할 것은 모델이 아니라 보안·정책·감사 체계다.

PART 06-23. 엔터프라이즈 배포

엔터프라이즈 배포는 네 층으로 생각하면 쉽다

Codex를 조직에 깔끔하게 배포하려면 복잡한 옵션을 한꺼번에 외우기보다, 네 층으로 나눠 생각하는 편이 훨씬 쉽습니다.

층	질문	대표 수단	주 책임자
접근 제어	누가 쓸 수 있나	RBAC, 그룹, SCIM, SSO	IT/보안
기본값	무엇으로 시작하나	managed defaults, 팀 공용 config	플랫폼 팀
강제 정책	어디까지는 절대 안 되나	requirements.toml, 정책 페이지	보안/플랫폼
감사와 추적	실제로 무슨 일이 있었나	Analytics, Compliance API, OTel, 로컬 로그	보안/감사

이 표가 중요한 이유는, 많은 조직이 두 번째 층만 만지기 때문입니다. 예를 들어 공용 config.toml만 배포해 놓고 "우리 회사는 안전한 설정을 씁니다"라고 말합니다. 하지만 그건 기본값일 뿐입니다. 개발자가 세션에서 바꿀 수 있으면, 운영 문서로는 안전하고 실제 운용으로는 제각각인 상태가 됩니다.¹

엔터프라이즈 배포는 이렇게 기억하면 됩니다.

첫째, RBAC는 사람을 묶고, 둘째, managed defaults는 출발점을 맞추고, 셋째, requirements.toml은 선을 넘지 못하게 막고, 넷째, 감사 로그는 나중에 설명 가능하게 만든다.²⁴

이 네 층이 같이 가야 합니다.

requirements.toml은 보안팀의 잔소리가 아니라 조직의 안전벨트다

requirements.toml은 개발자 개인 설정을 불편하게 만들기 위한 파일이 아닙니다. 조직이 허용 가능한 범위를 코드로 선언하는 장치입니다. 사용자가 로컬 config.toml이나 CLI 옵션으로 다른 값을 주더라도, 관리자 정책이 허용하지 않는 방향으로는 갈 수 없습니다.¹²

쉽게 말해 이렇게 나뉩니다.

config.toml은 "나는 평소 이렇게 쓰고 싶다"이고, managed_config.toml은 "회사가 기본값은 이렇게 시작했으면 좋겠다"이며, requirements.toml은 "아무리 그래도 여기 아래로는 내려가면 안 된다"입니다.¹

실무에서 가장 많이 쓰는 패턴은 아래와 비슷합니다.

allowed_approval_policies = ["on-request", "untrusted"]
allowed_sandbox_modes = ["read-only", "workspace-write"]
allowed_web_search_modes = ["disabled", "cached"]

[features]
voice_transcription = false

[rules]
prefix_rules = [
  { pattern = [{ token = "git" }, { any_of = ["push", "commit"] }], decision = "prompt", justification = "Require review before mutating remote or history." },
  { pattern = [{ token = "curl" }], decision = "forbidden", justification = "Use approved connectors or managed proxy." },
]

이 정도만 걸어도 조직 운영이 많이 달라집니다. 개발자는 실수로 전체 권한을 열지 못하고, 무심코 라이브 웹 검색을 켜지 못하고, 원격 상태를 바꾸는 명령은 한 번 더 멈춰서 확인하게 됩니다.¹⁴

여기서 포인트는 "엄격함"이 아니라 "일관성"입니다. 같은 Next.js + Supabase 버그를 고치더라도, 어떤 개발자는 로컬 전체 권한으로 실행하고 어떤 개발자는 워크스페이스 안에서만 실행한다면, 결과보다 운영 리스크 차이가 더 커집니다. 엔터프라이즈는 평균 속도보다 최악의 실수 반경을 줄이는 쪽이 먼저입니다.

관리형 기본값과 강제 정책은 반드시 분리하자

조직 도입에서 자주 생기는 오해가 하나 있습니다. 기본값을 배포하면 정책도 배포한 것처럼 느껴진다는 점입니다. 하지만 둘은 다릅니다.

관리형 기본값은 "처음 켜면 이렇게 시작"입니다. 사용자가 세션 중 바꾸더라도, 다음 시작 때 다시 회사 기본값으로 돌아오게 만들 수 있습니다. 반면 강제 정책은 그 값을 아예 넘어가지 못하게 막습니다.¹

예를 들어 플랫폼 팀이 이런 기본값을 주는 것은 자연스럽습니다.

approval_policy = "on-request"
sandbox_mode = "workspace-write"

[sandbox_workspace_write]
network_access = false

이 설정은 건강한 출발점입니다. 하지만 이것만으로는 부족합니다. 누군가 세션에서 더 느슨한 쪽으로 바꾸면 끝이기 때문입니다. 그래서 엔터프라이즈에서는 기본값 위에 requirements.toml을 반드시 겹쳐야 합니다.¹⁴

배포 경로도 알아둘 필요가 있습니다. Business나 Enterprise에서는 로그인 시 클라우드 관리형 정책을 받아 로컬 CLI, 앱, IDE 확장에 적용할 수 있고, macOS는 MDM 프로필의 com.openai.codex 도메인 아래 config_toml_base64, requirements_toml_base64로 관리형 설정을 내려보낼 수 있습니다. 그룹별로 다른 정책을 주고 싶다면 관리자 설정 페이지에서 정책을 나눠 적용하는 방식이 훨씬 운영하기 편합니다.¹²

이 말은 곧, 엔터프라이즈 환경에서 정책 문서는 위키에 두는 것이 아니라 배포 가능한 구성물로 관리해야 한다는 뜻입니다.

그룹별 정책은 "덧붙이기"보다 "완결형 프로필"로 설계하라

조직은 보통 하나가 아닙니다. 같은 회사 안에서도 모바일 팀, 백엔드 팀, 데이터 팀, 보안 팀, 재무 시스템 팀의 위험 수준이 다릅니다. 그래서 정책도 하나로 끝나지 않는 경우가 많습니다.

이때 가장 좋은 방식은 예외를 계속 쌓는 것이 아니라, 아예 완결형 프로필을 나누는 것입니다.²⁴

예를 들어 이렇게 나눌 수 있습니다.

baseline: 전체 조직 기본값
engineering: 일반 개발팀
restricted: 재무·인사·보안처럼 민감 데이터가 많은 팀
admin: 플랫폼·DevOps 운영자

이 구조가 좋은 이유는 설명이 쉽기 때문입니다. "너는 왜 이 옵션이 안 되죠?"라는 질문에 "정책 A 위에 정책 B를 덧씌우고, 예외 C를 빼고…"라고 말하기 시작하면 운영이 금방 복잡해집니다. 반대로 "당신은 restricted 프로필이라서 live web search와 외부 MCP가 막혀 있습니다"라고 말하면 끝입니다.

그룹 매핑도 사람 이름이 아니라 IdP 그룹으로 하는 편이 좋습니다. 실제 운영에서는 codex-admins, codex-local-users, codex-cloud-users, codex-restricted처럼 역할 기반 그룹을 만들고 SCIM으로 동기화하는 패턴이 가장 덜 흔들립니다.⁴

승인된 MCP만 허용하는 것이 조직 도입의 분기점이다

개인 사용 단계에서는 MCP가 "연결 편의 기능"처럼 보입니다. 하지만 조직으로 올라가면 MCP는 곧 외부 시스템 권한입니다.

GitHub MCP는 저장소 읽기와 쓰기 권한이 될 수 있고, Notion MCP는 문서 접근 권한이 되고, Postgres MCP는 데이터베이스 조회 통로가 됩니다. 여기서 중요한 건 "이름"이 아니라 "정체성"입니다. 이름만 같고 실제 실행 커맨드나 URL이 다르면, 전혀 다른 서버일 수 있습니다.

Codex의 관리자 강제 정책은 이 지점을 꽤 현실적으로 다룹니다. 승인된 MCP는 이름과 identity가 모두 일치해야 활성화되고, 허용 목록이 비어 있으면 MCP를 전부 꺼 버릴 수도 있습니다.¹

예를 들어 조직에서 정말 필요한 것만 열고 싶다면 이렇게 가져갈 수 있습니다.

[mcp_servers.github]
identity = { url = "https://mcp.github.internal.example.com" }

[mcp_servers.linear]
identity = { url = "https://mcp.linear.internal.example.com" }

[mcp_servers.docs]
identity = { command = "/usr/local/bin/internal-docs-mcp" }

이 정책의 의미는 명확합니다. 개발자가 로컬에서 이름만 github로 맞춰 놓은 임의 MCP를 띄운다고 해서 통과되지 않습니다. 조직이 믿는 서버만, 조직이 아는 정체성으로 붙습니다.¹

실무 감각으로 말하면, 엔터프라이즈 배포의 첫 번째 분기점은 여기입니다. MCP를 자유 설치로 두면 생산성은 빨리 올라가지만, 보안팀이 나중에 감당할 수 없는 연결 지점이 급증합니다. 반대로 승인된 MCP만 열면 속도는 조금 느려지지만, 어떤 데이터가 어떤 길로 나가는지 설명 가능해집니다.

MCP 승인과 네트워크 통제는 같은 문제가 아니다

여기서 한 번 더 구분해야 할 것이 있습니다. 승인된 MCP 목록은 "무슨 서버를 믿을 것인가"의 문제이고, 네트워크 통제는 "실제로 어디로 나갈 수 있는가"의 문제입니다.

이 둘을 섞으면 정책이 자꾸 구멍 납니다.

예를 들어 승인된 MCP가 하나뿐이어도, 에이전트 프로세스 자체가 공용 인터넷으로 마음대로 나갈 수 있으면 데이터 유출 경로는 여전히 남습니다. 그래서 엔터프라이즈에서는 보통 두 겹으로 막습니다. 바깥쪽은 requirements.toml이 어떤 설정이 가능한지 묶고, 안쪽은 관리형 프록시나 운영체제 샌드박스가 실제 네트워크 호출을 제한합니다.⁵

즉, 좋은 정책은 보통 이렇게 생깁니다.

기본 네트워크는 꺼 둔다.
필요한 도메인만 allow-list로 연다.
가능하면 읽기 성격의 메서드만 통과시킨다.
MCP 승인과 네트워크 egress 제한을 별도로 설계한다.⁵

이 차이를 이해하면 보안팀과 개발팀의 대화가 쉬워집니다. "왜 MCP 승인까지 받았는데 인터넷은 또 막아요?"라는 질문에, "그건 신뢰 목록이고, 이건 유출 경로 제어입니다"라고 답할 수 있어야 합니다.

감사 로그는 세 가지로 나눠 봐야 한다

엔터프라이즈에서 감사라고 하면 보통 한 가지만 떠올리기 쉽습니다. 하지만 실제 운영에서는 세 층이 나뉩니다.

첫 번째는 일상 운영 가시성입니다. 오늘 누가 많이 쓰는지, 코드 리뷰가 늘었는지, 어떤 팀이 거의 안 쓰는지를 보는 층입니다. 이건 Analytics Dashboard가 가장 편합니다.³

두 번째는 자동 보고와 비용 배부입니다. 팀별 사용량, 사용자별 세션 수, 코드 리뷰 활동을 BI나 데이터 웨어하우스로 보내는 층입니다. 이건 Analytics API가 맞습니다.³⁹

세 번째는 감사와 포렌식입니다. 누가 언제 어떤 프롬프트를 보냈고, 어떤 모델을 썼고, 어떤 결과가 나왔는지 조사 가능한 기록이 필요할 때입니다. 이건 Compliance API의 역할입니다.³⁴⁹

이 세 가지를 한데 묶어 "로그"라고 부르면 운영이 항상 꼬입니다. 대시보드는 보기 쉽지만 포렌식용이 아니고, Compliance API는 감사에 강하지만 매니저가 매일 보기에는 무겁습니다. 도구를 섞지 말고 목적을 나눠야 합니다.

Compliance API는 "무슨 질문이 오갔는가"를 남긴다

Codex의 엔터프라이즈 거버넌스에서 가장 중요한 축은 Compliance API입니다. 이 API는 상세 활동 로그를 내보내 보안팀이나 감사팀이 SIEM, DLP, eDiscovery 파이프라인으로 연결할 수 있게 해 줍니다. 일반적으로 여기에는 사용자와 워크스페이스 식별자, 타임스탬프, 프롬프트와 응답, 모델 식별자, 토큰 사용량, 요청 메타데이터가 포함됩니다.³⁴⁹

중요한 점은 두 가지입니다.

첫째, 이 로그는 실시간 스트림이라기보다 시간 구간별 내보내기용 JSONL에 가깝습니다. 즉, 사건 조사와 보관에는 좋지만, 실시간 탐지는 별도 계층이 필요합니다.⁴

둘째, 이 로그는 "무엇을 물었고 무엇을 받았는가"에는 강하지만, "그 코드가 실제로 머지되었는가"까지는 혼자 설명하지 못합니다. 그래서 실제 감사에서는 Compliance API만 보는 것이 아니라 Git 히스토리, PR 리뷰, CI 결과와 함께 엮어 봐야 합니다.⁹

실무에서는 보통 CODEX_LOG, CODEX_SECURITY_LOG 같은 이벤트를 수집하고, 일 단위 배치로 보안 저장소에 적재한 뒤, 사건이 생기면 사용자·시간 범위·세션 식별자로 좁혀 들어갑니다.²⁹

세션 추적은 "사람 → 세션 → 코드 변경"으로 이어져야 한다

엔터프라이즈 감사가 자주 실패하는 이유는 로그가 없어서가 아니라, 서로 연결되지 않아서입니다. 프롬프트 로그는 있는데 어떤 PR과 연결되는지 모르고, PR은 있는데 누가 어떤 세션에서 만든 변경인지 모르는 식입니다.

조직에서는 최소한 아래 다섯 축이 이어져야 합니다.

사람: SSO 사용자, 부서, 그룹
세션: session ID, request ID, 시작 시간
작업 대상: 저장소, 브랜치, 이슈, 티켓
실행 정보: 모델, 승인 결정, 사용한 MCP, 토큰
산출물: diff, 커밋, PR, CI 결과

이 연결이 되면 조사도 쉬워집니다. 예를 들어 "어제 밤 production 설정을 바꾼 PR이 왜 나왔지?"라는 질문이 들어왔을 때, Git만 보면 커밋 작성자만 보입니다. 하지만 세션 추적까지 되면 "누가 어떤 세션에서 어떤 MCP를 켜고, 어떤 승인 과정을 거쳐, 어떤 제안에서 그 변경이 나왔는지"까지 따라갈 수 있습니다.

이때 로컬 진단 정보도 의외로 도움이 됩니다. CLI 세션 안의 /feedback는 Request ID와 Session ID를 빠르게 확인하는 데 유용하고, 기본 로그는 ~/.codex/log/codex-tui.log에 남습니다. 파일 단위 증적은 중앙 감사 대체재가 아니지만, 파일럿 단계나 장애 분석, 사용자 이슈 재현에는 아주 실용적입니다.⁶

제 경험상 가장 좋은 방식은, PR 템플릿이나 자동 코멘트에 세션 식별자를 남기는 것입니다. 그러면 "이 PR은 어느 대화에서 왔는가"가 이어지고, 나중에 감사팀과 개발팀이 서로 다른 화면만 바라보며 싸울 일이 줄어듭니다.

실시간 관측이 필요하면 OTel을 별도로 붙여라

보안팀은 종종 이렇게 묻습니다. "이상 행동을 나중에 말고 바로 볼 수는 없나요?"

그 질문에는 Compliance API만으로는 부족할 수 있습니다. 왜냐하면 그쪽은 감사 내보내기에 가깝기 때문입니다. 실시간 가시성이 필요하다면 OpenTelemetry 같은 사내 관측 파이프라인으로 conversation metadata, API 요청, approval 결과, tool execution 결과를 보내는 구성이 더 어울립니다. 이때 프롬프트 본문은 기본적으로 가리거나, 최소한 민감도 검토를 거친 뒤 선택적으로 남기는 편이 안전합니다.⁴⁹

중요한 것은 욕심을 줄이는 것입니다. "다 남기자"는 감사 설계는 대개 오래 못 갑니다. 한국 조직에서는 특히 개인정보와 업무기밀이 섞이기 쉬우므로, 누가·언제·어디서·무엇을 실행했는지를 기본 축으로 남기고, 프롬프트 원문은 최소 수집 원칙으로 접근하는 편이 현실적입니다.

한국 조직은 기술 도입보다 반출 기준부터 정해야 한다

한국에서 엔터프라이즈 도입이 까다롭게 느껴지는 이유는 기술이 어려워서만은 아닙니다. 조직 문화상 "외부 서비스에 무엇을 넣어도 되는가"가 훨씬 민감하기 때문입니다.

실제로 국내에서는 생성형 AI 사용과 관련해 민감 정보와 업무 기밀 입력을 제한하는 지침 흐름이 꾸준히 나왔습니다. 국가정보원은 공공 부문을 포함한 AI 사용 보안 규칙 필요성을 강조했고, 경찰 역시 수사 정보나 사건 관련 개인정보를 생성형 AI에 입력하지 말라는 주의 지침을 전국 단위로 내린 바 있습니다.⁷⁸

이 흐름은 Codex 도입에서도 그대로 이어집니다. 한국 조직이 먼저 정해야 하는 질문은 "개발자가 얼마나 빨리 코드를 짜는가?"가 아니라, 아래에 가깝습니다.

고객 PII가 포함된 원문 로그를 넣어도 되는가
내부 DB 덤프를 MCP로 열어도 되는가
미공개 재무 자료, 인사 자료, 보안 사고 보고서를 프롬프트에 붙여도 되는가
외부 연결이 필요한 경우 어떤 프록시와 인증 체계를 반드시 거쳐야 하는가

이 질문에 답하지 않은 채 도입하면, 엔지니어링 팀은 생산성을 얻고 보안팀은 불신을 얻습니다. 그 상태는 오래 못 갑니다.

한국 보안 컴플라이언스 관점에서 현실적인 최소 원칙

국내 기업이라면 세부 업종 규제는 다르더라도, 최소한 아래 원칙은 거의 공통으로 가져가는 편이 좋습니다.

첫째, 개인정보와 기밀정보는 원문 투입 금지를 기본으로 둡니다. 주민등록번호, 계좌번호, 건강정보, 사건 기록, 고객 원문 대화, 미공개 사업 수치 같은 데이터는 외부 AI 표면에 그대로 넣지 않는 것이 출발점입니다.

둘째, 레드액션과 익명화를 먼저 자동화합니다. 예를 들어 Express + MongoDB 장애 분석을 Codex에 맡기고 싶다면, 원본 운영 로그를 그대로 넣는 대신 이메일, 전화번호, 토큰, 계정 식별자를 먼저 가리는 스킬이나 사전 스크립트를 붙이는 식입니다.

셋째, 규제 강도가 높은 팀은 restricted 프로필로 분리합니다. 엔지니어링 전체에 같은 정책을 쓰려고 하지 말고, 인사·재무·법무·보안 운영은 웹 검색, 외부 MCP, cloud task를 더 좁게 가져가는 편이 현실적입니다.

넷째, 감사 로그 접근권한 자체도 감사 대상으로 봅니다. 로그를 많이 남기는 것보다, 누가 그 로그를 볼 수 있는지 통제하는 것이 더 중요할 때가 많습니다.

다섯째, 데이터 레지던시와 계약 조건은 기술 설정 전에 확인합니다. 한국 기업, 특히 금융·공공·헬스케어 계열은 기술팀이 먼저 기능을 붙이기보다 법무·보안·구매와 함께 계약 범위, 저장 위치, 보관 기간, 위탁 처리 범위를 먼저 정리해야 마찰이 적습니다.

이 다섯 가지만 지켜도 "일단 금지"에서 "제한적 허용"으로 넘어갈 수 있는 팀이 많습니다.

한국 대기업에서 자주 나오는 인프라 변수도 미리 봐야 한다

문서만 보면 정책이 전부처럼 보이지만, 실제 도입을 막는 건 종종 네트워크와 인증서입니다. 한국 대기업은 사내 프록시, TLS 검사, 망 구간 분리, EDR 정책이 강한 편이라서, Codex가 정상 연결되기 전에 인증서 경로와 프록시 체인을 먼저 맞춰야 하는 경우가 많습니다.

특히 엔터프라이즈 가이드 기준으로는 기업 TLS 검사 환경에서 SSL_CERT_FILE 또는 CODEX_SSL_CERT_FILE 설정이 필요할 수 있고, 모든 외부 통신을 회사 프록시로 강제하는 구조라면 Codex 쪽 프록시 설정과 상위 프록시 체인을 함께 검증해야 합니다.⁴⁵

이건 생각보다 중요합니다. 플랫폼 팀은 "정책은 잘 내렸는데 왜 현장에서 자꾸 reconnecting이 뜨죠?"라고 묻고, 개발팀은 "도구가 불안정하다"고 느끼기 쉽습니다. 사실은 대부분 보안 인프라와의 접점 문제인 경우가 많습니다.

그래서 파일럿에서는 반드시 정책 검증과 네트워크 검증을 분리해서 테스트해야 합니다. policy pass와 connectivity pass는 다른 시험입니다.

조직 도입은 한 번에 전사 배포하지 말고 세 단계로 나누자

Codex는 생산성 체감이 빨라서, 성공한 팀일수록 금방 전사 확대를 꿈꿉니다. 하지만 엔터프라이즈 배포는 속도보다 순서가 중요합니다.

1단계: 로컬 파일럿

5명에서 10명 정도의 개발자로 시작합니다. Next.js + Supabase, Express + MongoDB처럼 회사에서 실제로 흔한 스택을 골라, 로컬 CLI와 IDE 확장만 먼저 엽니다. 이 단계의 목표는 "정말 빨라졌는가"가 아니라 "정책이 일을 방해하지 않으면서도 유지되는가"입니다.

성공 기준은 이런 쪽이 좋습니다.

requirements.toml 충돌 없이 세션이 시작되는가
승인 정책이 과도하게 잦지 않은가
로컬 로그와 세션 ID 수집이 가능한가
승인된 MCP만으로 실제 업무가 돌아가는가

2단계: 팀 표준화

파일럿이 안정되면 팀 공용 Skills, 공용 AGENTS.md, 공용 rules, managed defaults를 붙입니다. 이 단계부터는 개인 튜닝보다 팀 표준이 중요해집니다. PR 리뷰 스킬, 마이그레이션 스킬, 장애 트리아지 스킬처럼 반복 업무를 표준 자산으로 바꾸는 시점이기도 합니다.

동시에 Analytics Dashboard와 Analytics API를 붙여, "누가 쓰는가"뿐 아니라 "어떤 팀이 어떤 표면에서 쓰는가"를 보기 시작해야 합니다.³⁹

3단계: 감사 가능한 확장

마지막으로 cloud task, code review, Slack 연동, 배경 작업 같은 자동화를 넓힙니다. 이 단계에서 반드시 같이 붙어야 하는 것이 Compliance API와 중앙 SIEM 적재입니다. 자동화 범위를 넓히는데 감사 경로가 없으면, 문제 발생 시 신뢰를 잃습니다.³⁴

엔터프라이즈 배포에서 가장 위험한 방식은 "코드 리뷰 자동화부터 크게 열고, 감사는 나중에 붙이자"입니다. 순서를 반대로 가야 합니다.

실전 예시: 한국 SaaS 회사의 안전한 도입 시나리오

가상의 B2B SaaS 회사를 떠올려 봅시다. 프론트는 Next.js, 백엔드는 Express + MongoDB, 데이터 접근은 Supabase와 내부 어드민 API가 섞여 있습니다.

첫 달에는 프론트엔드 3명, 백엔드 3명, 플랫폼 2명만 codex-local-users 그룹으로 엽니다. 기본값은 workspace-write + on-request, 네트워크는 꺼 둡니다. MCP는 GitHub와 내부 문서 서버만 승인합니다.

둘째 달에는 반복되는 워크플로를 Skills로 옮깁니다. 예를 들어 "로그인 리다이렉트 버그 트리아지", "Mongo 인덱스 점검", "PR 리뷰 체크리스트" 같은 작업입니다. 동시에 git push, git commit, 외부 curl은 무조건 prompt 또는 forbidden으로 묶습니다.

셋째 달에는 Compliance API를 SIEM에 넣고, 플랫폼 팀은 Analytics API로 팀별 사용량 리포트를 만듭니다. 여기서부터 비로소 cloud background task나 자동 PR 리뷰를 일부 레포지토리에 엽니다.

이 순서의 장점은 간단합니다. 개발자는 바로 체감하고, 보안팀은 통제와 증적을 보고, 경영진은 사용량과 ROI를 볼 수 있습니다. 셋이 같은 타이밍에 안심하게 됩니다.