자료 근거 | Codex 플레이북

이 페이지는 “이 사이트의 말은 어디까지 믿어도 되는가?”를 확인하는 곳입니다. 기능 사실은 OpenAI 공식 문서를 기준으로 삼고, 제공 PDF는 문장이나 구조를 옮기지 않고 문제의식만 추출했습니다.

먼저 결론

구분	이 사이트에서 쓰는 방식
OpenAI 공식 문서	Codex 기능, 지원 표면, 보안·승인·클라우드·Skills 같은 사실 확인 기준
제공 PDF	입문자 눈높이, 작업을 작게 나누는 법, 검증과 인계의 중요성을 읽는 보조 자료
플레이북 자체 해석	`작업 패킷`, `패치 루프`, `팀 운영 기준`처럼 실제 운영에 맞게 재배열한 권장 운영 방식

1차 기준: 공식 문서

다음 문서는 기능 사실을 확인하는 1차 기준입니다.

Codex app: 데스크톱 앱, thread, worktree, review, automation 같은 작업 표면.
Codex CLI: 로컬 터미널에서 파일 읽기, 수정, 명령 실행, 승인 모드를 다루는 기준.
Codex IDE extension: 열린 파일, 선택 영역, 명령 팔레트, cloud delegation을 편집기에서 다루는 기준.
Codex Web: 클라우드 작업, 환경 설정, 인터넷 접근, GitHub 연결 기준.
Codex Workflows: IDE, CLI, cloud 작업을 완료 정의와 검증 기준으로 읽는 예시.
AGENTS.md: 저장소 안에서 Codex가 따라야 할 작업 규칙을 남기는 기준.
Sandboxing: 로컬 명령, 파일 쓰기, 네트워크 접근의 기술적 경계.
Agent approvals & security: sandbox, approval, cloud 환경, network access를 함께 운영하는 기준.
Codex Security: 외부 콘텐츠, prompt injection, agent 권한, secret 취급의 신뢰 경계.
Auto-review: 승인 요청을 reviewer agent가 자동 검토할 때의 운영 기준.
Non-interactive mode: codex exec로 CI, 스크립트, scheduled job에서 Codex를 실행하는 기준.
Codex GitHub Action: GitHub Actions workflow에서 Codex를 실행하는 기준.
Remote connections: 다른 기기에서 연결된 host의 Codex 작업을 이어가는 기준.
Memories: 개인 반복 맥락과 팀 규칙을 분리하는 기준.
Chronicle: 화면 맥락 기반 기억의 개인정보·보안 주의점.
Agent Skills: 반복 작업 절차를 SKILL.md와 관련 자료로 묶는 방식.
Plugins: skills, app integration, MCP server를 설치 가능한 워크플로로 묶는 방식.
Model Context Protocol: Codex가 외부 문서와 도구를 쓰게 만드는 연결 기준.
Subagents: 명시적으로 요청한 병렬 agent 작업과 custom agent 운영 기준.
Codex use cases: PR 리뷰, 프론트엔드 구현, 대형 코드베이스 이해 같은 실제 작업 예시.
Codex use case: follow a goal: 긴 목표를 여러 단계의 작업과 검증으로 이어가는 방식.
Codex use case: create a CLI: 반복 작업을 Codex가 호출할 수 있는 명령 도구로 만드는 방식.
Codex use case: AI app evals: AI 기능 품질을 샘플과 기준으로 반복 평가하는 방식.
Codex changelog: CLI, app, remote connection, plugin, skill 같은 기능 변경을 확인하는 릴리스 기준.

공식 문서와 이 플레이북 설명이 충돌하면 공식 문서를 우선합니다.

참고 PDF에서 가져온 문제의식

아래 자료는 구조나 문장을 복제하지 않고, Codex 플레이북의 독자 설계와 설명 난이도를 잡는 데만 사용합니다.

자료	반영한 문제의식
Codex 실무 메모	Codex를 자동완성이 아니라 실무형 작업자로 볼 때 필요한 범위, 검증, 승인선, 인계
입문자용 코드 에이전트 가이드	초보자가 기능명보다 실제 장면과 작은 성공으로 진입해야 한다는 관점
심화 운영 가이드	어려운 용어를 파일, 폴더, 인계 노트처럼 쉬운 작업 언어로 풀어야 한다는 관점
지시·위임 자료	“좋은 프롬프트”보다 위임, 판별, 검증의 순환이 중요하다는 관점

이 자료들은 다른 도구 중심 자료가 섞여 있으므로 Codex 기능 설명의 근거로 쓰지 않습니다. Codex 기능 범위는 항상 OpenAI 공식 문서로 다시 확인합니다.

난이도 표기

문서마다 다음 세 독자를 염두에 둡니다.

입문: Codex를 어디서 켜고, 첫 요청을 어떻게 맡길지 알고 싶은 사람.
실무: 버그 수정, 기능 구현, UI 확인, CI 실패처럼 매일 하는 일을 안정적으로 끝내고 싶은 사람.
팀 운영: 여러 사람이 같은 저장소에서 같은 승인선과 리뷰 기준으로 Codex를 쓰게 만들고 싶은 사람.

공식 문서와 비교해 보강한 기준

2026-05-19 점검에서 다음 기준을 보강했습니다.

보강 영역	플레이북 반영 방식
IDE extension	`IDE`라는 느슨한 표현을 `IDE extension`으로 바꾸고, 열린 파일·선택 영역·cloud delegation 기준을 추가
sandbox와 approval	둘을 하나의 “승인선”으로 뭉뚱그리지 않고, 기술적 울타리와 사람 확인 정책으로 분리
신뢰 경계	외부 문서, issue, log, MCP/browser 결과를 Codex 지시가 아니라 작업 대상 데이터로 다루는 기준 추가
cloud 환경	GitHub 연결, 환경 설정, 인터넷 접근, setup 단계와 agent 작업 단계 구분을 반영
skills와 plugins	반복 절차 형식과 설치 가능한 배포 단위를 분리
subagent	명시 요청, 병렬성, 비용, 승인 흐름을 함께 고려하는 운영 단위로 설명
automation/CI	`codex exec`, GitHub Action, machine-readable output, 최소 권한, 테스트 재실행 기준을 운영 단위로 추가
Memories/Chronicle	개인 기억과 팀 규칙을 분리하고, 화면 맥락과 민감 정보 취급 기준을 팀 도입 문서에 추가
remote connection	실행 권한은 지시를 보내는 기기가 아니라 연결된 host 설정을 따른다는 기준을 추가
goal/CLI/eval	반복 작업을 작업 패킷, Skill, Codex용 CLI, eval, CI로 언제 승격할지 판단하는 기준을 추가
`codex doctor`	CLI 문제가 생겼을 때 설정 변경보다 진단 증거를 먼저 모으고 민감 단서를 확인하는 기준을 추가

운영 사이트에서 흡수한 기준

Claude Code 플레이북 운영 사이트는 기능 사실의 근거가 아니라, 공개 문서 허브가 갖춰야 할 운영 표면을 점검하는 참고 대상으로만 봅니다. 그대로 복제하지 않고 Codex 플레이북의 본질에 맞는 것만 반영합니다.

관찰한 장점	Codex 플레이북 반영
공개 사이트의 `robots.txt`와 `sitemap.xml`	build 후 sitemap을 생성하고, deploy surface 검사로 누락을 막음
Cloudflare와 Vercel 같은 이중 배포 표면	`_redirects`, `vercel.json`, `astro.config.mjs` redirect가 어긋나면 build 실패
입문자가 바로 고를 수 있는 읽기 경로	홈의 첫 CTA를 독자별 경로로 연결하고, navigation에 읽기 경로를 추가
변경 이력과 운영 기준의 공개	`reference/update-log`를 nav와 footer에서 바로 접근 가능하게 함

이번에는 블로그, 뉴스레터, 검색, 대형 커리큘럼 구조는 넣지 않았습니다. 아직 문서 수가 작고, 이 플레이북의 핵심은 많은 콘텐츠가 아니라 작업 패킷, 패치 루프, 승인선, handoff의 실행 표준이기 때문입니다.

자주 나오는 질문

왜 기능 목록이 아니라 작업 표준인가요?

기능 목록만 알면 “무슨 버튼이 있는지”는 알 수 있지만 “내 작업을 어디서 시작하고 어떻게 끝낼지”는 여전히 흐립니다. 이 플레이북은 기능을 작업 흐름 안에 배치합니다.

입문자는 어디부터 보면 되나요?

처음 시작 지도와 작업 패킷부터 보면 됩니다. 먼저 Codex를 어디서 실행할지 고르고, 작은 요청 하나를 안전하게 맡기는 법을 익히는 것이 좋습니다.

실무자는 무엇을 얻나요?

패치 루프에서 버그 수정, 기능 수정, UI 검증, CI 재실행, PR 리뷰를 어떻게 diff와 검증 증거로 닫는지 가져갈 수 있습니다.

팀 리드는 무엇을 봐야 하나요?

안전선과 승인, 병렬·클라우드 운영, 팀 도입을 보면 됩니다. 핵심은 개인 프롬프트가 아니라 공통 규칙, 승인선, 리뷰 증거, handoff입니다.