Codex Mac App 가이드(1) : 설치부터 권한, MCP, 자동화까지 - Codex App으로 코드를 직접 맡기는 시대
- -
안녕하세요! 갓대희 입니다.

Codex 앱은 워크트리를 들고 코드를 직접 바꾸는 에이전트 도구다.
이 글은 OpenAI 공식 문서를 기준으로 Codex 앱의 설치·권한·설정·플러그인·자동화를 정리하고, 공식 문서에 아직 세부 설명이 부족한 부분만 실제 Mac 설정 화면으로 보완한 글이다. 공식 문서상 Codex 앱은 macOS와 Windows에서 제공되지만, 여기서는 Mac 화면과 macOS 권한 흐름을 중심으로 다룬다.
사실 Codex 앱은 사용한지 오래 되었는데, 많이 활용하는 편은 아니었다.
그러던 중 최근 Codex 5.5로 업그레이드 되고 난 후 코딩에서 활용시에도 만족스럽고, 기획서를 만들어 가는데에도 많이 활용하고, 그 퀄리티가 많이 올라 가게 되었다. (이 상세 활용에 대해서는 별도의 글에서 작성할 수 있도록 하겠다.)
이제 코덱스 앱에 대해서 충분히 알아갈만한 가치가 매우 커진것 같아서 Codex App에대해 하나하나 자세히 살펴보는 시간을 갖게 되었다.
ex) 개발 및 소스리뷰 진행 예시

ex) 자주 사용하는 excel, powerpoint 플러그인

OpenAI는 Codex 앱을 "parallel threads, built-in worktree support, automations, Git functionality"를 갖춘 데스크탑 경험으로 설명한다. 아래 기능들은 공식 Codex App 문서의 기능 목록을 기준으로 재구성한 것이다.
| 공식 기능 | 무엇을 의미하나 | 글에서 다루는 위치 |
|---|---|---|
| Parallel project threads | 여러 프로젝트 스레드를 나란히 실행하고 전환 | 사이드바, 사용량, agents.max_threads |
| Worktrees | 병렬 변경을 Git worktree로 격리 | 깃 통합, 워크트리 자동 정리 |
| Review and ship | diff 검토, 파일 stage, commit, push | 깃 통합, ChatGPT 앱과의 차이 |
| Automations | 반복 작업 예약 또는 기존 스레드 웨이크업 | Standalone vs Thread 자동화 |
| Computer use / Browser | macOS 앱, 브라우저 플로우, 로컬 페이지 테스트 | 플러그인, 권한, Computer Use 주의 |
| Plugins / Skills / MCP | 앱 통합, 재사용 지침, 외부 도구 서버 연결 | 플러그인, MCP, 개인 맞춤 |
목차
1. 설치 · 계정 · 사용 한도
공식 문서 기준으로 Codex는 ChatGPT Plus, Pro, Business, Edu, Enterprise 플랜에 포함된다.
설치는 chatgpt.com/codex에서 시작하면 되고, Mac 사용자는 Apple Silicon 또는 Intel용 DMG를 받는다. Windows는 Microsoft Store 경로가 따로 제공된다.
일반적인 로그인 경로는 ChatGPT 계정이다.
공식 문서에는 OpenAI API 키 로그인도 가능하다고 되어 있지만, API 키 방식은 cloud threads 같은 일부 클라우드 기능이 제한될 수 있고 사용량 기반 API 과금이 적용된다. 따라서 데스크탑 앱을 일반 개발 워크플로우에 쓰려면 ChatGPT 계정 로그인을 기본 전제로 보는 편이 맞을 것 같다.
사용 화면 읽는 법

사용 메뉴에서는 실제 남은 한도를 확인할 수 있다.
내 화면 기준으로는 일반 사용 한도(5시간 / 주간), GPT-5.3-Codex-Spark 사용 한도(5시간 / 주간), 잔액 영역이 분리되어 표시된다.
(글에서 자주 부르는 "잔여 크레딧"의 GUI 라벨은 잔액이며 그 안에 "0크레딧 남음" 표시와 구매하기/자동 충전 설정 버튼이 있다).
일반 사용 한도와 Spark 한도가 따로 보이는 이유는 GPT-5.3-Codex-Spark가 별도 usage limit을 가진 research preview 모델로 안내되기 때문이다.
( 난 gpt pro 요금제 사용중이다. 현재 5월 2일기준)
| 화면 항목 | 의미 | 공식 문서 기준 해석 |
|---|---|---|
| 일반 사용 한도 | 현재 계정의 기본 Codex 사용량. 화면에는 5시간 사용 한도와 주간 사용 한도가 함께 표시된다. | 공식 pricing 문서는 local messages와 cloud tasks가 5시간 창을 공유하고, 추가 주간 한도가 적용될 수 있다고 설명한다. |
| GPT-5.3-Codex-Spark 사용 한도 | Spark 모델용 별도 한도. 일반 사용 한도와 별도 섹션으로 표시된다. | 공식 pricing 문서는 GPT-5.3-Codex-Spark가 Pro 사용자 대상 research preview이며, 별도 사용 한도로 관리된다고 설명한다. |
| 잔액 (GUI 라벨) | 포함 한도에 도달한 뒤 계속 작업할 때 사용할 수 있는 크레딧 잔액. 화면에는 "0크레딧 남음"과 함께 구매하기 버튼이 표시된다. | 공식 pricing 문서는 Plus/Pro 사용자가 한도 도달 후 추가 크레딧을 구매할 수 있고, Business/Edu/Enterprise는 flexible pricing 조건에서 workspace credits를 사용할 수 있다고 설명한다. |
| 크레딧 자동 충전 | 잔액이 최소값에 도달하면 크레딧을 자동으로 추가하는 설정. | 공식 pricing 문서는 한도 도달 후 크레딧을 사용해 작업을 이어갈 수 있다고 설명한다. 자동 충전 토글은 앱 화면 기준 세부 UI다. |
요약하면, 이 화면은 "지금 얼마나 남았는가"를 보는 곳이다. 구체적인 메시지 수는 모델과 작업 복잡도에 따라 범위로 계산되므로, 숫자를 외우기보다 일반 한도·Spark 한도·크레딧 잔액이 따로 움직인다는 점을 이해하는 것이 더 중요하다.
공식 pricing 문서는 Fast 모드가 지원 모델에서 크레딧을 더 빠르게 소모하고, 이미지 생성은 일반 턴보다 평균 3-5배 빠르게 포함 한도를 사용한다고 안내한다.
또한 Free 플랜에서는 Codex 이미지 생성이 제공되지 않고, API 키 사용 시에는 ChatGPT 포함 한도 대신 API 가격이 적용된다고 명시한다.
이미지 생성 가능 여부와 별도 한도는 ChatGPT 플랜/지역/시점에 따라 달라질 수 있으므로, 여기서는 Codex 포함 한도에서 더 빠르게 차감될 수 있다는 점을 중심으로 이해하면 된다.
2. 사이드바 + 작업 모드 + 권한 3단계
설정 창을 열면 왼쪽 사이드바에 12개 메뉴가 보인다. 각 메뉴가 어떤 영역을 담당하는지 한 번 훑어 두면 이후 섹션이 빠르게 이해된다.

사이드바 12개 메뉴
| 번호 | 메뉴 | 역할 |
|---|---|---|
| 1 | 일반 | 작업 모드 · 권한 · 단축키 · 속도 · 후속 행동 |
| 2 | 모양 | 테마 · 폰트 · 레이아웃 |
| 3 | 구성 | config.toml · 승인 정책 · 샌드박스 · Codex 종속성 |
| 4 | 개인 맞춤 설정 | 성격 · 맞춤형 지침 · 메모리(실험용) |
| 5 | MCP 서버 | MCP 프로토콜 서버 추가/관리 |
| 6 | 깃 | 브랜치 접두사 · PR 병합 방식 · 워크트리 자동 정리 |
| 7 | 환경 | 실행 환경 변수 · 셸 통합 |
| 8 | 작업 트리 | Codex가 만든 워크트리 목록(자동 삭제 토글·한도는 깃 메뉴에 있음) |
| 9 | 브라우저 사용 | 앱 내장 브라우저(Browser Use) 설정 |
| 10 | 컴퓨터 사용 | Computer Use 플러그인(macOS 앱 제어 + 앱별 승인) |
| 11 | 보관된 채팅 | 아카이브된 스레드 |
| 12 | 사용 | 5시간 / 1주 사용 한도 · 계정 정보 |
사이드바가 12개로 늘어난 만큼, 한 번에 모두 다듬기보다 일반 → 구성 → 깃 → MCP 순서로 자주 쓰는 메뉴부터 정돈하는 편이 효율적이다.
작업 모드 — 코딩용 vs 일상 작업용

일반 메뉴 상단에서 코딩용과 일상 작업용 두 모드 중 하나를 선택한다. 같은 모델·같은 권한이라도 응답 톤과 디테일 수준이 달라진다.
| 모드 | 응답 성향 | 권장 용도 |
|---|---|---|
| 코딩용 | 기술 디테일 우선. 파일 경로·diff·테스트 명령어를 빠짐없이 노출하는 편이다. | 기능 구현, 리팩터, 테스트 작성 |
| 일상 작업용 | 간결한 응답. 자연어 설명과 결정 요약 중심이다. | 스탠드업 정리, 릴리스 노트, 회의 후속 |
권한 3단계 — GUI 라벨과 config.toml 매핑

Codex 앱의 권한은 샌드박스 모드 · 승인 정책 두 축이 합쳐진 결과다.
일반 메뉴 상단의 권한 영역에는 기본 권한 · 자동 검토 · 전체 접근 권한 세 항목이 토글로 표시되는데, 이는 단계별 권한 상승 토글에 가깝다. 실제 sandbox_mode 값은 구성 메뉴의 샌드박스 설정 드롭다운(Read only / Workspace write / Full access)에서 선택하고, config.toml에는 두 키로 분리해 적는다.
매핑 관계는 다음과 같다. (출처: Sandbox concepts, Agent approvals & security)
| GUI 라벨 | sandbox_mode 값 |
파일 시스템 | 셸 실행 |
|---|---|---|---|
| 기본 권한 | "read-only" |
읽기 전용 | 읽기·조회 중심. 쓰기나 경계 밖 액션은 승인 흐름으로 넘어간다. |
| 자동 검토 | "workspace-write" |
현재 워크스페이스 쓰기 허용 | 워크스페이스 안 작업은 진행하고, 위험하거나 경계 밖이면 승인 요청. |
| 전체 접근 권한 (구성 메뉴 라벨: Full access) |
"danger-full-access" |
호스트 전체 쓰기 가능 | 샌드박스 제한을 해제한다. 승인 정책을 별도로 보수적으로 잡아야 한다. |
함께 쓰는 승인 정책(approval_policy)은 실제 GUI 드롭다운 기준 네 값이 모두 활성화되어 있다.
Untrusted — "Always ask before taking action"
On failure — "Ask only when a command fails"
On request — "Ask when escalation is requested"
Never — "Run without asking for approval"가 표시된다.
화면에서는 On request가 기본으로 잡혀 있다. 일반적으로 workspace-write + on-request 조합이 가장 자주 쓰이는 편이다.
danger-full-access) 위험성이 모드는 호스트 시스템 전체를 수정할 수 있다. 실수로 키 파일이나 시스템 설정을 덮어쓸 수 있고, 외부 명령·앱 조작의 피해 범위도 커진다. 실서비스 코드베이스나 개인 노트북에서는 기본값으로 켜지 않는 것이 좋다. 사용한다면 컨테이너·전용 VM·격리된 워크트리에서만 활성화한다. (출처: Agent approvals & security)
3. 일반 / 받아쓰기 / 알림 / 후속 행동
일반 메뉴는 자잘하지만 매일 손에 닿는 옵션이 모여 있다.

일반 옵션 6가지(자주 쓰는 항목)
- 기본 열림 위치: 드롭다운에서 IDE 선택. 기본 옵션에 VS Code가 잡혀 있다.
- 언어: 자동 탐지가 기본. 영어/한국어 등으로 강제 지정 가능.
- 메뉴 막대에 표시: macOS 메뉴바 상단에 Codex 아이콘 노출.
- 팝아웃 창 단축키: 미니 채팅 창을 띄우는 단축키. 작업 흐름을 끊지 않을 때 유용하다.
- 실행 중 절전 모드 방지: 장시간 작업 중 Mac이 잠들지 않게 한다.
- 긴 프롬프트를 보내려면 ⌘+Enter 필요: 활성화하면 여러 줄 프롬프트는 ⌘+Enter로만 보내진다. 실수로 미완성 프롬프트가 전송되는 사고를 줄인다.
속도 — 보통 / Fast

속도 옵션은 보통과 Fast 두 가지다. Fast는 지원 모델의 응답 속도를 올리는 대신 포함 크레딧을 더 빠르게 쓴다.
공식 Speed 문서 기준 Fast 모드는 GPT-5.5와 GPT-5.4에서 1.5배 속도를 목표로 하며, 크레딧 차감률은 각각 Standard 대비 2.5배, 2배로 안내되어 있다.
API 키 로그인에서는 Fast 모드 크레딧이 아니라 표준 API 가격이 적용된다. 보통은 추론 시간을 더 두므로 멀티파일 리팩터나 복잡한 에이전트 작업에 더 안정적인 경향이 있다. (출처: Speed)
후속 행동 / 코드 리뷰

| 옵션 | 선택지 | 의미 |
|---|---|---|
| 후속 행동 | 대기열 추가 / 스티어링 | 대기열은 현재 작업을 끝낸 뒤 다음 차례로 실행한다. 스티어링은 진행 중인 에이전트 작업을 즉시 중단하고 새 지시로 방향을 전환한다 — 진행 중 작업은 취소된다. 이미 실행 중인 내용이 필요 없어졌을 때만 스티어링을 쓴다. |
| 코드 리뷰 | 인라인 / 분리됨 | 인라인은 본문 diff 옆에 주석을 박아 맥락과 함께 본다. 분리됨은 별도 패널에서 전체 리뷰를 한 번에 훑을 때 유용하다. |
받아쓰기 4개

- 누르고 말하기 단축키: 키를 누르고 있는 동안만 음성 입력.
- 말하기 단축키 켜기/끄기: 토글식 단축키. 한 번 누르면 켜지고 다시 누르면 꺼진다.
- 받아쓰기 사전: 자주 잘못 인식되는 고유명사·약어 등록.
- 최근의 받아쓰기 기록: 최근 발화 텍스트 검토.
알림 3개

- 완료 알림 — 집중하지 않았을 때만: 다른 앱에 포커스가 있을 때만 작업 완료를 알린다. 사용 중인 동안엔 조용하다.
- 권한 알림 활성화: 권한 승인이 필요한 순간 시스템 알림으로 띄운다.
- 질문 알림 사용: 에이전트가 사용자에게 질문할 때 알림을 보낸다.
추천 프롬프트

일반 메뉴 하단의 추천 프롬프트는 ON/OFF 토글이다. 화면 설명: "프로젝트 파일과 연결된 앱을 검색해 다음에 할 일을 제안합니다." 즉 사용자가 사내 가이드를 직접 등록하는 곳이 아니라, Codex가 현재 프로젝트 컨텍스트를 보고 후속 작업 후보를 띄워 주는 옵션이다.
환경 메뉴 — 실행 환경 변수 · 셸 통합
사이드바 7번 환경 메뉴는 에이전트 실행 시 주입할 환경 변수를 GUI에서 등록하는 곳이다.


API 키·프록시 주소·내부 서비스 엔드포인트처럼 하드코딩하기 싫은 값을 여기 넣어 두면 에이전트가 셸 명령을 돌릴 때 해당 변수를 자동으로 받는다.
시스템 ~/.zshrc나 .env 파일을 직접 열지 않아도 된다는 점이 편리하다.
일반 메뉴 화면 하단에 있는 "다른 에이전트 설정 가져오기"는 별도 영역이라 섹션 9 개인 맞춤에서 자세히 다룬다.
4. 플러그인 마켓 — Featured 18개 외 다수


Codex 앱은 OpenAI가 큐레이트한 GUI 플러그인을 한곳에 모아두었다.
공식 문서에서 플러그인은 앱·스킬·MCP 서버를 묶어 Codex가 할 수 있는 일을 확장하는 단위로 설명된다.
Built by OpenAI 필터로 보면 Featured 카테고리에 18개, 그 외에 Coding / Design / Lifestyle / Productivity 등 여러 카테고리가 추가로 보이며 총 50개 이상이 노출된다.
아래 표는 그중 가장 자주 쓰이는 Featured 18개를 카테고리별로 정리한 것이다. 플러그인 목록은 자주 추가·변경되므로 정확한 개수와 항목은 화면에서 직접 확인하는 편이 안전하다.
| 플러그인 | 설명 (GUI 그대로) | 카테고리 |
|---|---|---|
| Computer Use | Control Mac apps from Codex | 앱/시스템 제어 |
| Browser Use | Control the in-app browser with Codex | 웹 탐색 |
| Spreadsheets | Create and edit spreadsheet files | 파일 작업 |
| Presentations | Create and edit presentations | 파일 작업 |
| GitHub | Triage PRs, issues, CI, and publish flows | 개발 도구 |
| Slack | Read and manage Slack | 업무 도구 |
| Notion | Notion workflows for specs, research,... | 업무 도구 |
| Linear | Find and reference issues and projects. | 개발 도구 |
| Statsig | Bring your Statsig workspace into Codex. | 개발 도구 |
| Gmail | Read and manage Gmail | 업무 도구 |
| Google Calendar | Manage Google Calendar events and... | 업무 도구 |
| Google Drive | Work across Drive, Docs, Sheets, and... | 업무 도구 |
| Teams | Summarize Teams and draft follow-ups | 업무 도구 |
| SharePoint | Summarize SharePoint sites and files | 업무 도구 |
| Outlook Email | Triage Outlook inboxes and draft replies | 업무 도구 |
| Outlook Calendar | Manage Outlook schedules and meetings | 업무 도구 |
| Figma | Design-to-code workflows | 디자인/개발 |
| Vercel | Build and deploy web apps and agents | 개발 도구 |
위 18개는 Featured 카테고리이고,
그 외
Coding 카테고리에 Hugging Face / Netlify / CircleCI / Cloudflare / Sentry / Build iOS · macOS · Web Apps / Test Android Apps / Expo / CodeRabbit / Neon Postgres / Supabase / Codex Security 등
Design에 Canva / Remotion / BioRender / HyperFrames
Productivity에 Documents / Atlassian Rovo / Jam / Stripe / Box / Amplitude 등이 추가로 보인다.
일반 플러그인은 설정 → 플러그인 → + 버튼으로 추가한다.
OAuth가 필요한 항목은 클릭 시 별도 인증 창이 뜬다.
Computer Use는 공식 문서 기준 설정 → Computer Use에서 설치하며, 프롬프트 내용상 필요하다고 판단되면 대화 입력창 위에 설치 유도 배너가 뜰 수도 있다.
ex) Computer Use 권한 요청




한 번에 너무 많이 연결하면 권한 알림이 누적되니, 실제로 쓰는 것만 켜두는 편이 깔끔하다.
Computer Use 플러그인은 macOS 전용이며, 출시 시점 기준 EEA(유럽경제지역)·영국·스위스에서는 사용할 수 없다. 사용하려면 macOS의 화면 기록(Screen Recording)과 손쉬운 사용(Accessibility) 권한이 필요하고, Codex 안에서도 앱별 허용 프롬프트를 별도로 승인한다. 해당 지역 사용자는 메뉴에서 비활성화로 표시될 수 있다. (출처: Computer Use)
Computer Use를 켜야 하는 경우와 켜지 말아야 하는 경우
| 상황 | 권장 | 이유 |
|---|---|---|
| 로컬 웹앱 화면 확인 | 브라우저 사용 먼저 | 공식 문서는 로컬 웹앱 검증에는 in-app browser를 먼저 쓰라고 안내한다. 파일 변경과 화면 검증이 한 스레드 안에서 정리된다. |
| macOS 앱, 시뮬레이터, 로그인된 브라우저, 여러 앱을 오가는 흐름 | Computer Use 적합 | 명령줄이나 MCP로는 볼 수 없는 GUI 상태를 보고 클릭·입력·메뉴 이동을 해야 하기 때문이다. |
| 계정, 결제, 보안, 개인정보, 관리자 권한이 걸린 흐름 | 옆에서 직접 승인 | 화면 내용과 클릭 결과가 계정 상태에 영향을 줄 수 있다. 민감한 단계는 사용자가 직접 확인해야 한다. |
| 터미널 앱이나 Codex 앱 자체 조작 | 불가 / 부적합 | 실제 앱 검증에서 Codex 자체는 Computer Use 대상 앱으로 차단됐다. 터미널이나 Codex 자체를 대신 조작하게 만들면 기존 승인·샌드박스 정책을 우회할 수 있기 때문이다. |
플러그인 vs MCP vs Skills
셋이 자주 헷갈린다.
플러그인은 OpenAI가 큐레이트한 GUI 확장으로 앱·스킬·MCP 서버 같은 구성요소를 묶어 설치한다.
MCP는 표준 프로토콜 서버로 사용자가 직접 호스팅하거나 외부 서버를 가져와 붙인다.
Skills는 재사용 가능한 지침·워크플로우 묶음이라 코드/문서 형태로 공유된다. Skills 내부 구조는 이 글의 범위 밖이라 자세히 다루진 않으려 한다.
5. 예약 채팅 자동화 — Standalone vs Thread

Codex 앱의 자동화는 두 형태다.
둘은 동작 방식이 다르고, 화면에서도 분리되어 있다. (출처: Automations)
| 유형 | 동작 | 결과 보고 |
|---|---|---|
| Standalone | 독립 실행. 매번 새 컨텍스트로 시작한다. | Triage/Inbox(분류함)에 보고된다. 보고할 내용이 없으면 자동 보관될 수 있다. |
| Thread | 현재 스레드에 붙어 하트비트처럼 반복 웨이크업한다. | 스레드 안에 메시지로 추가된다. |
GUI 4 카테고리와 예시 타일
자동화 화면 상단에는 4개 카테고리가 있다. 카테고리는 시작점일 뿐이고, 자유롭게 새 자동화를 만들 수도 있다.
| 카테고리 | 예시 타일 (화면 그대로) |
|---|---|
| Status reports | "스탠드업용으로 어제 Git 활동을 요약해줘", "이번 주 PR·롤아웃·인시던트·리뷰를 종합해 주간 업데이트로 정리해줘", "지난주 PR을 팀원별·주제별로 요약해주고 리스크를 강조해줘" |
| Release prep | "병합된 PR로 주간 릴리스 노트를 초안으로 작성해줘", "태그를 달기 전에 변경 로그·마이그레이션·기능 플래그·테스트를 확인해줘", "이번 주 하이라이트와 핵심 PR 링크를 반영해 변경 로그를 업데이트해줘" |
| Incidents & triage | "지난 CI 기간의 CI 실패와 플래키 테스트를 요약하고 우선 수정 사항을 제안해줘", "CI 실패를 확인하고 가능한 근본 원인별로 묶은 다음 최소한의 수정안을 제안해줘", "새 이슈를 분류하고 담당자·우선순위·라벨을 제안해줘" |
| Code quality | 테스트 커버리지·정적 분석 보고 등 코드 품질 지표(예시 타일은 환경에 따라 다르게 노출되므로 화면에서 직접 확인) |
설정 방법
- 자동화 화면에서 새 자동화를 만든다.
- 스케줄(예: 매일 09:00) 지정. 커스텀 주기가 필요하면 cron 구문을 쓴다.
- 대상 프로젝트와 사용할 플러그인 선택.
- 결과 보고 위치(Triage / 현재 스레드) 선택.
실행 위치 — 로컬 프로젝트 vs 백그라운드 워크트리
자동화를 만들 때 실행 위치를 선택할 수 있다.
로컬 프로젝트는 현재 열려 있는 프로젝트 폴더에서 직접 실행한다.
백그라운드 워크트리는 Git 저장소에 별도 워크트리를 만들어 돌리므로, 현재 작업 브랜치에 영향을 주지 않는다.
프로젝트 범위 자동화는 앱이 실행 중이고 선택한 프로젝트가 디스크에 있어야 안정적으로 동작한다. 정기 릴리스 노트·PR 요약처럼 메인 브랜치를 건드리지 않고 반복 실행해야 하는 자동화라면 백그라운드 워크트리 쪽이 안전하다. 자동화는 기본 샌드박스 설정을 사용하며, 조직 정책이 허용하면 approval_policy = "never"로 실행될 수 있어 권한 설정을 보수적으로 잡는 편이 좋다.
(출처: Automations)
ex) 이미 기존 템플릿을 사용해볼 수 있고, 로컬 / worktree, 프로젝트, 주기 등을 임의로 설정해 보았다.

ex) 바로 실행도 가능하다.

ex)



6. config.toml + 샌드박스 + 승인 정책
Codex의 핵심은 config.toml 한 파일이다.
앱·CLI·IDE 확장이 같은 파일을 읽는다. 한 곳을 고치면 세 환경이 동시에 영향을 받는다. (출처: Config Reference)
| 위치 | 경로 | 우선순위 |
|---|---|---|
| 사용자 레벨 | ~/.codex/config.toml |
기본값 |
| 프로젝트 레벨 | .codex/config.toml (프로젝트 루트) |
신뢰된 프로젝트에서 사용자 레벨을 덮어쓴다. untrusted 프로젝트는 프로젝트 스코프 .codex/ 설정을 건너뛴다. |
구성 화면 — GUI에서 보이는 항목
사이드바의 구성 메뉴에는 다음 컨트롤이 있다.

- 사용자 지정 드롭다운: 사용자 설정이 기본. 워크스페이스나 프로젝트 단위 프로필을 선택할 수 있다.
- config.toml 열기: 기본 텍스트 에디터로
~/.codex/config.toml을 연다. - 승인 정책: On request가 기본 선택. 드롭다운에는
Untrusted,On failure,On request,Never네 값이 모두 노출된다. - 샌드박스 설정: Read only가 기본 선택.다른 값은
Workspace write,Full access(config.toml에는danger-full-access로 적힘). - Codex 종속성: ON이면 앱이 번들된 Node.js·Python을 사용. OFF면 시스템 PATH의 런타임을 사용.
- 현재 버전: 직접 검증한 로컬 앱은
26.430.10722로 표시(2026-05-02 기준). - 진단 / 재설치 버튼: 종속성 손상 시 진단을 돌리고, 필요하면 번들 런타임을 재설치한다.
샌드박스 모드 표
| GUI 라벨 | sandbox_mode |
동작 |
|---|---|---|
| Read only | "read-only" |
읽기·조회 중심. 파일 쓰기나 경계 밖 액션은 승인 정책에 따라 멈춘다. |
| Workspace write | "workspace-write" |
현재 워크스페이스 안에서 쓰기 허용. 외부 디렉터리·네트워크·민감 액션은 추가 제한을 받을 수 있다. |
| Full access | "danger-full-access" |
"Can edit files outside this workspace" — 샌드박스 제한 해제. config.toml 값은 danger-full-access이지만 GUI 라벨은 Full access로 표시된다. 호스트 전체에 영향을 줄 수 있으므로 별도 격리 환경에서만 쓴다. |
승인 정책 표

Read only / Workspace write / Full access

| GUI 라벨 | approval_policy |
설명 |
|---|---|---|
| Untrusted | "untrusted" |
Always ask before taking action. 모든 액션마다 승인 요청. |
| On failure | "on-failure" |
Ask only when a command fails. 명령이 실패했을 때만 승인 요청. |
| On request | "on-request" |
Ask when escalation is requested. 에이전트가 권한 상승을 요청할 때만 승인. 화면 기본값. |
| Never | "never" |
Run without asking for approval. 자동화·CI처럼 사람이 중간 승인할 수 없는 환경에서만 신중히 사용. |
네 문자열 값 외에 approval_policy = { granular = { ... } } 객체 형태도 지원된다. sandbox_approval, rules, mcp_elicitations, request_permissions, skill_approval 카테고리별로 승인 여부를 독립 제어할 수 있다. 기본 네 값으로 충분한 경우가 대부분이지만, MCP 호출만 별도 승인하고 싶은 경우 등에 유용하다.
(출처: Config Reference)
config.toml 예시
# ~/.codex/config.toml
# 샌드박스: 워크스페이스 안에서만 쓰기 허용
sandbox_mode = "workspace-write"
# 승인 정책: 필요한 경우에만 승인 요청
approval_policy = "on-request"
[agents]
# 동시에 돌릴 수 있는 에이전트 스레드 수 (기본값 6)
max_threads = 6
# MCP 서버 등록 — 섹션 7 참조
[mcp_servers.context7]
command = "npx"
args = ["-y", "@upstash/context7-mcp"]
GUI에서 토글한 값은 즉시 config.toml에 반영된다. 반대로 config.toml을 직접 편집하면 다음 실행 시 GUI에 그대로 보인다. 다만 GUI와 파일을 동시에 편집할 때 어느 쪽이 우선인지는 공식 docs에 명확한 안내가 보이지 않는다. 한쪽만 골라 쓰는 편이 깔끔하다.
ON이면 앱이 자체 번들한 Node.js·Python을 사용한다. 시스템에 어떤 버전이 깔려 있어도 영향이 없다.
OFF면 PATH 상의 시스템 런타임을 사용한다. nvm·asdf·pyenv 환경을 그대로 쓰고 싶을 때 끈다.
종속성이 깨졌다는 메시지가 보이면 진단 → 재설치 순서로 복구한다.
7. MCP 서버 통합
MCP(Model Context Protocol)는 외부 도구·데이터를 표준화된 방식으로 LLM에 붙이는 프로토콜이다.
공식 MCP 문서는 CLI와 IDE 확장의 공유 설정을 중심으로 설명하고, 플러그인 문서는 MCP 서버를 플러그인 구성요소 중 하나로 설명한다. 현재 Codex 앱 화면에도 MCP 서버 메뉴가 있어 앱에서 직접 관리할 수 있다.
즉 특정 벤더 락인 없이 직접 호스팅한 서버, 오픈소스 서버, 사내 서버를 가져와 붙이는 구조로 이해하면 된다.
(출처: MCP server integration, Plugins)
추가 방법 — GUI vs config.toml
공식 문서 기준 CLI와 IDE 확장은 같은 config.toml 설정을 공유한다. Codex 앱은 화면에서 MCP 서버를 관리할 수 있으므로, GUI에서 보이는 값과 config.toml을 함께 확인하는 방식이 안전하다.
- GUI: 설정 → MCP 서버 → + 서버 추가 → 이름·command·args 입력.
- config.toml 직접 편집:
~/.codex/config.toml에[mcp_servers.<name>]블록 추가.
물론 요즘엔 그냥 자연어로 ~~ MCP 추가해줘 라고 말만해도 쉽게 등록이 가능하다.
예시 — context7 MCP
# ~/.codex/config.toml
[mcp_servers.context7]
command = "npx"
args = ["-y", "@upstash/context7-mcp"]
# 사내 서버 추가 예시
[mcp_servers.internal_kb]
command = "node"
args = ["/Users/me/mcp-servers/internal-kb/dist/index.js"]
CLI와 IDE 확장이 같은 config.toml을 읽는다는 점이 가장 큰 장점이다.
반복해서 쓰는 MCP 서버는 파일에 명시해 두면 터미널 codex 명령과 IDE 확장에서 같은 설정을 재사용할 수 있다. 앱 GUI에서 추가한 서버도 같은 이름과 실행 명령이 들어갔는지 config.toml에서 한 번 확인해 두면 혼선을 줄일 수 있다.
추가 필드 — enabled, required, HTTP 서버
command/args 외에 실용적인 필드가 더 있다.
enabled = false를 추가하면 블록을 삭제하지 않고 서버를 일시 비활성화한다.
required = true로 설정하면 해당 서버가 연결되지 않을 때 앱 시작이 실패하므로, 팀 필수 서버에 달아 두면 빠뜨릴 수 없다.
(출처: MCP server integration)
HTTP 기반 MCP 서버는 command 대신 url과 bearer_token_env_var를 쓴다. 토큰은 환경 변수 이름으로 전달해 파일에 직접 노출되지 않게 한다.
# HTTP 서버 예시 (bearer token 인증)
[mcp_servers.company_api]
url = "https://mcp.internal.example.com/sse"
bearer_token_env_var = "COMPANY_MCP_TOKEN"
# stdio 서버 — 일시 비활성화
[mcp_servers.context7]
command = "npx"
args = ["-y", "@upstash/context7-mcp"]
enabled = false
# 팀 필수 서버 — 없으면 시작 실패
[mcp_servers.internal_kb]
command = "node"
args = ["/opt/mcp/internal-kb/index.js"]
required = true
플러그인은 OpenAI가 골라 둔 GUI 통합이고, MCP는 사용자가 직접 가져와 붙이는 표준 프로토콜이다. 같은 서비스(예: GitHub)를 두 경로 모두로 연결할 수도 있는데, 동작 범위가 겹치면 혼선이 생기니 한쪽만 활성화하는 편이 정리된다.
8. 깃 통합 — 브랜치 접두사 · 워크트리
깃 메뉴는 Codex가 만든 변경을 어떤 모양으로 저장할지 결정한다. 기본값이 잘 잡혀 있어 그대로 써도 무방하지만, 팀 규칙에 맞춰 한 번 손보면 PR 흐름이 깔끔해진다.

| 설정 | 기본값 | 설명 |
|---|---|---|
| 브랜치 접두사 | codex/ |
에이전트가 만드는 모든 브랜치 앞에 자동으로 붙는다. 예: codex/fix-login |
| PR 병합 방법 | 병합 / 스쿼시 | 팀 컨벤션에 맞춰 선택한다. |
| 사이드바 PR 아이콘 | OFF | 사이드바에 PR 상태 아이콘 표시 여부. |
| 항상 강제 푸시 | OFF | ON으로 두면 --force-with-lease 류의 강제 푸시를 매번 수행한다. 팀 환경에선 신중히 켠다. |
| 초안 PR 생성 | ON | PR을 Draft로 먼저 만들고, 검토 후 Ready로 승격한다. |
기본값 조합이 이미 팀 친화적으로 잡혀 있다. 브랜치 접두사 codex/는 에이전트가 만든 브랜치를 사람이 만든 브랜치와 명확히 구분하고, 초안 PR ON은 리뷰 없이 바로 병합되는 사고를 막는다.
항상 강제 푸시는 OFF가 기본이라 협업 브랜치를 실수로 덮어쓸 위험이 낮다.
팀 컨벤션이 스쿼시 병합이라면 PR 병합 방법만 교체하면 나머지는 건드리지 않아도 된다.
처음엔 기본값 그대로 쓰고, 브랜치 이름이 PR 리스트에서 눈에 띄게 정리된 다음에 접두사만 팀 규칙으로 바꾸는 순서가 안전하다.
워크트리 자동 정리
Codex 앱은 작업마다 별도 워크트리를 만든다.
자동 정리 토글과 한도는 작업 트리 메뉴가 아니라 깃 메뉴 하단에 있다. 기본값은 오래된 작업 트리 자동 삭제 ON, 자동 삭제 한도 15이며 한도를 넘으면 오래된 워크트리부터 삭제된다. 사이드바의 작업 트리 메뉴는 현재 생성된 워크트리 목록을 보여주는 화면이고, 정리 옵션이 따로 있지는 않다.
한 가지 헷갈리지 않게 둘은 다른 값이다. 자동 삭제 한도는 디스크에 남기는 워크트리 개수이고, agents.max_threads = 6(공식 기본값)은 동시에 돌릴 수 있는 에이전트 스레드 수다. 한쪽은 보관, 한쪽은 동시성이다. (출처: Config Reference)
# 워크트리 목록 확인 (Codex가 만든 트리도 함께 표시된다)
$ git worktree list
/Users/me/projects/myapp abc1234 [main]
/Users/me/projects/myapp/.codex/wt-001 def5678 [codex/fix-login]
/Users/me/projects/myapp/.codex/wt-002 ghi9012 [codex/refactor-auth]
/Users/me/projects/myapp/.codex/wt-003 jkl3456 [codex/add-tests]
# 수동 정리가 필요한 경우
$ git worktree remove /Users/me/projects/myapp/.codex/wt-001
9. 개인 맞춤 + 다른 에이전트 설정 가져오기
개인 맞춤 메뉴는 응답 톤과 컨텍스트 메모리를 조정한다.

성격 (Personality)
드롭다운으로 응답 톤을 선택한다. 화면 기본값은 실용적이다. 다른 옵션은 화면에서 직접 확인할 수 있다.
맞춤형 지침
"이 프로젝트는 FastAPI + Python 3.12 기준" 같은 영구 컨텍스트를 적어 둔다. AGENTS.md 파일과 연동되며, 위치는 사용자 레벨이라면 ~/.codex/AGENTS.md, 프로젝트 단위라면 프로젝트 루트의 AGENTS.md를 따른다. 화면에는 자세히 알아보기 링크가 함께 노출된다. (출처: AGENTS.md guide — developers.openai.com)
AGENTS.md — 실제로 무엇을 쓰는가
AGENTS.md는 에이전트에게 줄 자유형식 지침 파일이다. YAML이나 특별한 문법이 없고, 마크다운 텍스트로 자연어 규칙을 적으면 된다. 프로젝트 루트의 AGENTS.md는 CLI·앱·IDE 어디서 호출해도 동일하게 읽힌다.
# AGENTS.md — 프로젝트 규칙 예시
## 기술 스택
- Python 3.12 / FastAPI / SQLAlchemy 2.x
- 테스트: pytest, 커버리지 80% 이상 유지
## 코딩 규칙
- main 브랜치에 직접 커밋하지 않는다.
- 모든 외부 호출은 httpx 비동기 클라이언트를 쓴다.
- 환경 변수는 pydantic-settings로 로드한다.
## PR 규칙
- PR 제목은 `feat:`, `fix:`, `refactor:` 접두사를 붙인다.
- 릴리스 PR에는 CHANGELOG.md 항목을 함께 추가한다.
임시로 전역 AGENTS.md를 재정의하고 싶다면 ~/.codex/AGENTS.override.md(사용자 레벨) 또는 프로젝트 루트의 AGENTS.override.md를 만들면 된다. 같은 범위에 override 파일이 있으면 일반 AGENTS.md보다 우선 적용되고, 삭제하면 원래 지침으로 돌아간다. 특정 기간만 다른 규칙을 적용할 때 유용하다.
메모리(실험용) — 토글 3개 + 초기화 버튼
개인 맞춤 화면 하단의 메모리(실험용) 영역에는 토글 3개와 액션 버튼 1개가 있다.
내 화면 기준 토글은
메모리 활성화(채팅에서 새 메모리를 생성해 새 채팅에 가져옴),
Chronicle 리서치 미리보기(작업을 도울 수 있도록 화면 맥락을 활용해 메모리 보강),
도구 사용 채팅 제외(MCP 도구나 웹 검색을 사용한 채팅에서는 메모리를 생성하지 않음)이고,
마지막에 메모리 초기화 버튼(모든 Codex 메모리 삭제)이 별도로 있다.
실험용이라는 라벨이 붙은 만큼 베타 단계로 보는 편이 안전하다.
실험용 메모리 토글은 안정 기능보다 동작이 자주 바뀐다. 사내 워크플로우의 핵심 의존으로 묶기 전에 동일 효과를 AGENTS.md·맞춤형 지침으로 옮길 수 있는지 먼저 검토한다.
다른 에이전트 설정 가져오기
외부 에이전트 설정 2개가 자동으로 감지되었고, 항목 옆에 가져오기 버튼이 표시된다(설명 문구: "Codex가 다른 로컬 에이전트 앱에서 유용한 설정을 찾았습니다"). 감지 개수와 어떤 앱(예: Cursor, Continue, Claude 등)을 인식하는지는 환경에 따라 다르므로 화면에서 직접 확인한다. 가져오기를 누르면 해당 도구의 시스템 프롬프트나 규칙이 Codex의 맞춤형 지침으로 전환되어 옮겨진다.
10. ChatGPT Mac 앱과의 차이
두 앱은 같은 OpenAI 출시이지만 목적이 다르다. ChatGPT 앱이 물어보고 받아보는 도구라면, Codex 앱은 맡기고 결과를 받는 에이전트 도구다. 표로 정리하면 다음과 같다.
| 항목 | ChatGPT Mac 앱 | Codex Mac 앱 |
|---|---|---|
| 주 사용 목적 | 질문·요약·아이디어 정리 | 코드 변경·테스트·PR 자동화 |
| 전역 호출 | Option+Space (Chat Bar) | 메뉴바 아이콘 + 팝아웃 창 단축키 |
| IDE 연동 | Work with Apps — IDE 파일 컨텍스트 읽고 diff 적용 | 자체 워크트리 생성 + 깃 커밋·PR까지 수행 |
| 샌드박스/권한 | macOS 권한 + 앱별 연결 권한 중심 | 3단계 샌드박스 + 3단계 승인 정책 + 플러그인별 권한 |
| 설정 공유 범위 | 앱 자체 설정 | ~/.codex/config.toml로 앱·CLI·IDE 공유 |
| 확장 방식 | Work with Apps / ChatGPT Apps | 화면 기준 14개 GUI 플러그인 + MCP 서버 직접 등록 + Skills |
| 자동화 | 예약 작업 영역 별도 노출 안 함 | Standalone / Thread 자동화 |
| 워크트리 관리 | 없음 | 자체 워크트리 + 자동 정리(기본 한도 15) |
| 음성 | ChatGPT Voice는 웹·iOS·Android·Windows 쪽과 구분해야 한다. 공식 릴리스 노트에는 macOS 앱 Voice 경험이 2026-01-15 종료된다고 공지되어 있으나, Work with Apps 도움말에는 Advanced Voice 관련 문구가 남아 있어 현재 앱 화면 기준 확인이 필요하다. | 받아쓰기 4종 옵션 제공 |
표를 정리해 보면 두 앱은 겹치는 듯해도 사용 흐름이 갈린다. ChatGPT 앱은 IDE 옆에서 짧게 묻고 답을 가져오는 사이드킥에 가깝고, Codex 앱은 워크트리·브랜치·PR을 들고 들어가 끝까지 처리하는 에이전트다. 권한 모델도 Codex 쪽은 샌드박스·승인 정책·플러그인 권한이 겹치므로, 코드를 바꾸는 작업에서는 설정을 먼저 정리하는 편이 안전하다. 자동화 측면에서도 Codex 쪽이 한 단계 더 깊다.
한 줄 요약: ChatGPT 앱은 정보를 가져오는 도구, Codex 앱은 코드를 바꾸는 도구다.
처음 켰을 때는 사이드바 12개가 빽빽해 보이지만, 실제로 자주 만지는 곳은 일반·구성·깃·MCP 네 메뉴 정도다. 이 글을 옆에 두고 한 번씩 토글해 보면 한 시간 안에 익숙해진다. 더 깊은 자동화나 CLI 통합은 별도 글에서 이어 다룬다.
참고 출처
- Codex App — developers.openai.com
- Codex Config Reference — developers.openai.com
- Sandbox concepts — developers.openai.com
- Agent approvals & security — developers.openai.com
- MCP server integration — developers.openai.com
- Codex Plugins — developers.openai.com
- Codex App Automations — developers.openai.com
- Computer Use — developers.openai.com
- Codex Pricing & usage limits — developers.openai.com
- Using Codex with your ChatGPT plan — OpenAI Help Center
- Work with Apps on macOS — OpenAI Help Center
- ChatGPT Release Notes — OpenAI Help Center
- Codex App 공식 다운로드 페이지 — chatgpt.com
'AI > Codex 기초 사용방법' 카테고리의 다른 글
당신이 좋아할만한 콘텐츠
-
Codex CLI 입문(4) : AGENTS.md와 Rules 설정 방법 - Codex에게 팀 규칙과 권한을 알려주는 방법 2026.05.11
-
Codex CLI 입문(3) : Codex Subagents와 Workflows 사용 방법 - 큰 작업을 나누어 처리하는 방법 2026.05.11
-
Codex CLI 입문(2) : OpenAI Codex 핵심 개념 4가지 - Prompting, Memories, Sandboxing, Models 2026.05.07
-
Codex CLI 입문(1) : OpenAI Codex CLI 빠른 시작 - codex 설치, 인증 하기 2026.05.07
소중한 공감 감사합니다