이 글은 OpenAI Developers 내 Codex 문서에 기반해 작성되었습니다.
코딩 에이전트를 처음 접하는 분들이 자주 던지는 질문이 있습니다.
코덱스가 챗GPT랑 뭐가 다른가요? 클로드 코드랑은 뭐가 다르죠? 그냥 코드 자동 완성 도구 아닌가요?
이 질문은 코덱스의 정의, 코덱스가 돌아가는 구조, 그리고 코덱스를 어디서 어떻게 쓰는지라는 세 가지가 한꺼번에 묶여 있는 형태입니다.
이 글은 위의 질문을 해결하기 위한 코덱스 시리즈 10편 중 첫 번째 편입니다. 다음 다섯 가지를 다룹니다.
- 코덱스의 정의와 역할
- 네 가지 사용 환경(앱, IDE 익스텐션, CLI, 웹)
- 에이전트 루프와 샌드박싱(Sandboxing) 작동 원리
- 모델 라인업과 가격 정책
- 코덱스를 쓰면 안 되는 상황
1. 코덱스(Codex)의 정의와 역할
코덱스는 오픈에이아이(OpenA)I가 만들었으며, 사람이 의도를 설명하면 파일을 읽고 명령을 실행하고 코드를 수정하는 능동적인 코딩 에이전트(Coding Agent)입니다. 챗GPT(ChatGPT) Free, Go, Plus, Pro, Business, Edu, Enterprise 플랜에 모두 포함되어 있어 별도 구독 없이 같은 계정으로 바로 쓸 수 있습니다.
코덱스가 할 수 있는 일은 다섯 가지로 정리됩니다.
| 역할 | 구체적 작업 |
|---|---|
| 코드 작성 | 의도 설명을 받아 프로젝트 구조와 코딩 컨벤션에 맞춰 코드 생성 |
| 코드베이스 이해 | 복잡하거나 오래된 레거시 코드를 읽고 동작 방식을 설명 |
| 코드 리뷰 | 잠재적 버그, 로직 오류, 처리되지 않은 엣지 케이스 식별 |
| 디버깅 | 실패 추적, 근본 원인 진단, 수정 제안 |
| 개발 작업 자동화 | 리팩토링, 테스트 작성, 마이그레이션, 셋업 같은 반복 작업 |
이 다섯 가지로 코덱스는 “코딩 어시스턴트”와 차이가 있습니다. 어시스턴트는 사람이 요청한 한 덩어리의 코드를 만들어 돌려주고 끝나지만, 에이전트는 사람이 큰 의도를 던지면 작업을 잘게 쪼개 파일을 열고 명령을 돌리고 결과를 보고 다시 시도합니다.
1) 코덱스의 네 가지 사용 환경
코덱스는 같은 코딩 에이전트를 앱, IDE 익스텐션, CLI, 웹(클라우드) 네 가지 인터페이스에서 제공합니다.
| 환경 | 설치 방식 | 지원 OS | 실행 위치 | 적합한 작업 결 | 고유 기능 |
|---|---|---|---|---|---|
| 앱 | dmg/exe 설치 | macOS, Windows | 로컬 | 다중 프로젝트 병렬, GUI 선호 | 워크트리, 자동화, 인앱 브라우저, 컴퓨터 유즈 |
| IDE 익스텐션 | 마켓플레이스 | macOS, Windows, Linux | 로컬 | 에디터에서 즉시 컨텍스트 활용 | 열린 파일·선택 영역 자동 컨텍스트 |
| CLI | npm/brew | macOS, Windows, Linux | 로컬 | 스크립팅, CI 자동화, 헤드리스 | codex exec, 오픈소스 |
| 웹(클라우드) | 브라우저 접속 | OS 무관 | 클라우드 | 병렬 위임, 디바이스 무관 접근 | 격리 컨테이너, 깃허브 PR 통합 |
용어 안내
- 앱: 일반 프로그램처럼 내 컴퓨터에 직접 설치해서 쓰는 독립 애플리케이션입니다. macOS에서는 .dmg, Windows에서는 .exe 파일을 다운로드해 설치하며, 아이콘을 클릭하면 별도 창이 열립니다. 카카오톡이나 Slack 데스크톱 앱을 설치하는 것과 같은 방식이라고 보면 됩니다.
- IDE 익스텐션: IDE(통합 개발 환경)는 코드를 작성·실행·디버깅할 수 있는 전문 편집기입니다. 대표적으로 VS Code, JetBrains(IntelliJ, PyCharm 등), Cursor 같은 도구가 있습니다. 익스텐션은 이런 IDE에 플러그인 형태로 추가하는 확장 기능으로, IDE 안의 마켓플레이스(확장 프로그램 탭)에서 검색 후 클릭 한 번으로 설치할 수 있습니다. 코드를 편집하면서 바로 옆에서 AI를 호출할 수 있다는 점이 장점입니다.
- CLI(Command Line Interface): 마우스와 그래픽 화면 대신, 터미널이라 불리는 텍스트 창에서 명령어를 직접 입력해 조작하는 방식입니다. macOS에서는 기본 내장된 “터미널” 앱이나 iTerm2, Windows에서는 PowerShell이나 Windows Terminal, Linux에서는 기본 터미널 에뮬레이터를 열어 사용합니다. 예를 들어
codex "버그 수정해줘"처럼 한 줄을 입력하면 AI가 작업을 수행하는 식입니다. 그래픽 화면이 없는 대신, 스크립트를 짜서 반복 작업을 자동화하거나 CI/CD 파이프라인에 연결하기에 유리합니다.- 웹(클라우드): 별도 설치 없이 브라우저(Chrome, Safari, Edge 등)에서 URL에 접속해 바로 사용하는 방식입니다. 코드가 내 컴퓨터가 아닌 원격 서버(클라우드)에서 실행되기 때문에, 사양이 낮은 노트북이나 태블릿에서도 동일한 성능으로 작업할 수 있습니다. 구글 Docs로 문서를 편집하는 것과 비슷한 원리라고 생각하면 이해하기 쉽습니다.
2) 코덱스와 클로드 코드의 포지셔닝 차이
같은 코딩 에이전트 카테고리 안에서 코덱스는 앤스로픽(Anthropic)의 클로드 코드(Claude Code)와 자주 비교됩니다. 둘 다 빠르게 진화 중이라 기능 범위는 계속 변하지만, 설계 철학에는 다음과 같은 결의 차이가 있습니다.
| 항목 | 코덱스 | 클로드 코드 |
|---|---|---|
| 주요 인터페이스 | 앱(App), IDE 익스텐션, CLI, 웹(Cloud) 4종 멀티 인터페이스 | CLI 중심, IDE 연동과 깃허브 워크플로 확장 |
| 격리 실행 | 샌드박싱 기본 내장(macOS Seatbelt, Linux bubblewrap, Windows 네이티브) | 권한·승인 흐름 중심, 운영체제 단위 샌드박스는 추가 설정 영역 |
| 데스크톱 앱 | 독립 macOS/Windows 앱 제공 | 별도 데스크톱 앱 없음(IDE·CLI 중심) |
| 클라우드 실행 | chatgpt.com/codex 로 브라우저에서 격리 컨테이너 실행 | 깃허브 액션 등 외부 자동화로 확장 |
어느 한쪽이 더 낫다는 비교는 무의미할 정도로 둘 다 한 달 단위로 기능이 추가되고 있고, 팀의 작업 환경에 따라 적합도가 갈립니다. 다만 코덱스는 멀티 인터페이스 전략과 OS 단위 샌드박스를 처음부터 같이 끌고 가는 설계라는 점이 두드러집니다.
2. 코덱스의 작동 원리
코덱스가 한 번의 요청을 처리하는 흐름은 세 가지 개념으로 정리됩니다. 에이전트 루프, 스레드, 샌드박싱입니다.
| 개념 | 한 줄 정의 | 핵심 역할 | 비유 |
|---|---|---|---|
| 에이전트 루프 | 모델 추론 → 도구 실행 → 결과 피드백을 반복하는 실행 사이클 | 하나의 요청을 완료할 때까지 “생각하고 행동하고 확인하는” 과정을 자동 반복 | 요리사가 레시피를 보고(추론) → 재료를 손질하고(도구 실행) → 맛을 보고(결과 확인) → 다음 단계로 넘어가는 과정 |
| 스레드 | 하나의 작업 세션 단위. 프롬프트·응답·도구 호출 이력을 보관 | 대화 맥락을 유지하고, 실행 환경(로컬/워크트리/클라우드/채팅)을 결정 | 메신저 대화방. 방을 나갔다 들어와도 이전 대화가 남아 있고, 같은 주제로 이어서 대화 가능 |
| 샌드박싱 | 에이전트가 자율적으로 움직일 수 있는 기술적 경계 | 낮은 위험 작업은 자동 실행, 경계 밖 작업에서만 사람에게 승인 요청 | 놀이터처럼 안에서는 자유롭게 놀지만, 밖으로 나가려면 보호자 허락이 필요 |
1) 에이전트 루프 (Agent Loop)
에이전트 루프를 이해하려면 **모델**과 **하네스(harness)**라는 두 역할을 구분해야 합니다.
모델은 GPT 계열의 대규모 언어 모델로, “다음에 뭘 해야 하는가”를 추론하는 역할입니다. 하네스는 모델을 감싸고 있는 실행 엔진으로, 모델이 내린 판단을 실제로 수행합니다. 파일을 읽거나 쓰고, 셸 명령을 실행하고, 결과를 수집해서 다시 모델에게 넘기는 일이 모두 하네스의 몫입니다.
사용자가 프롬프트를 보내면 코덱스는 다음 흐름을 반복합니다.
[사용자 프롬프트]
│
▼
┌─────────────────────────────────────────────────────┐
│ 하네스가 프롬프트 조립 │
│ (시스템 지시문 + AGENTS.md + 도구 정의 + 대화 이력 │
│ + 샌드박스 권한 + 사용자 메시지) │
└──────────────────────┬──────────────────────────────┘
│
▼
[모델에 프롬프트 전송]
│
▼
┌─── 모델의 응답 확인 ───────┐
│ │
도구 호출 요청 최종 메시지
│ │
▼ ▼
[하네스가 도구 실행] [사용자에게 결과 전달]
├─ 파일 읽기/쓰기 (턴 종료)
├─ 셸 명령 실행
└─ 외부 도구 호출
│
▼
[실행 결과를 프롬프트에 추가]
│
└──→ [모델에 프롬프트 재전송] ──→ (반복)
먼저 하네스가 프롬프트를 조립합니다. 사용자의 메시지만 보내는 것이 아니라, 시스템 지시문, 프로젝트 설정(AGENTS.md), 도구 정의, 샌드박스 권한 정보, 이전 대화 이력까지 하나로 묶어 모델에게 전송합니다. 이것이 “모델 호출”입니다.
모델은 이 프롬프트를 읽고 다음 행동을 결정합니다. 이때 모델의 응답은 두 가지 중 하나입니다. 사용자에게 보낼 최종 답변이거나, “이 셸 명령을 실행해줘”와 같은 도구 호출 요청입니다. 도구 호출 요청이 돌아오면 하네스가 해당 명령을 실행하고, 그 결과를 프롬프트에 덧붙여 모델을 다시 호출합니다. 이 사이클이 반복되는 것이 에이전트 루프입니다.
사용자가 같은 대화에서 후속 프롬프트를 보내면 새로운 턴이 시작됩니다. 이때 이전 턴의 모든 이력, 즉 도구 호출과 그 결과까지 포함한 전체 대화가 새 프롬프트에 담깁니다. 모델이 앞서 읽은 파일과 실행한 명령의 맥락을 기억한 채로 이어서 작업할 수 있는 이유입니다. 대화가 길어질수록 프롬프트도 커지는데, 코덱스는 프롬프트 캐싱과 자동 요약(Compaction)으로 이 문제를 관리합니다.
2) 스레드(Thread)
스레드는 코덱스에서 하나의 작업 세션을 뜻합니다. 한 스레드 안에는 사용자가 보낸 프롬프트, 모델의 응답, 모델이 호출한 도구와 그 결과가 모두 기록됩니다. 같은 스레드에서 프롬프트를 이어 보낼 수 있어서, 먼저 “이 코드의 구조를 설명해줘”라고 물은 뒤 같은 맥락에서 “그러면 여기에 테스트를 추가해줘”라고 후속 작업을 시키는 흐름이 자연스럽습니다.
스레드를 시작할 때 실행 모드를 선택합니다. 코덱스 앱 기준으로 네 가지입니다.
| 스레드 모드 | 실행 위치 | 핵심 특징 | 적합한 작업 |
|---|---|---|---|
| 로컬(Local) | 내 컴퓨터 | 현재 프로젝트 폴더에서 직접 파일을 수정 | 바로 결과를 확인하며 작업할 때 |
| 워크트리(Worktree) | 내 컴퓨터 (별도 Git 워크트리) | 현재 브랜치를 복제한 독립 작업 공간에서 실행. 원본 코드에 영향 없음 | 실험적 변경을 격리해서 시도할 때, 두 에이전트를 동시에 돌릴 때 |
| 클라우드(Cloud) | OpenAI의 원격 서버 | GitHub 저장소를 클론한 격리 컨테이너에서 실행. 노트북을 닫아도 작업이 계속됨 | 시간이 오래 걸리는 작업을 위임하고 나중에 결과만 확인할 때 |
| 채팅(Chat) | 프로젝트 없는 대화 | 특정 프로젝트 폴더 없이 시작. 코드 수정 대신 외부 도구 연결 중심 | 리서치, 기획, 슬랙·노션 연동 워크플로 |
터미널에서 CLI 세션을 닫으면 그 컨텍스트가 사라지는 것과 달리, 코덱스 앱에서 만든 스레드는 앱을 닫았다 다시 열어도 대화 이력과 컨텍스트가 그대로 남아 있습니다. 작업을 위해 쌓아둔 맥락을 잃지 않는다는 점이 스레드의 핵심 가치입니다.
3) 샌드박싱 (Sandboxing)
코딩 에이전트는 파일을 읽고, 코드를 수정하고, 셸 명령을 실행할 수 있습니다. 하지만 제한 없이 풀어주면 위험합니다. 에이전트가 프로젝트 폴더 바깥의 시스템 파일을 건드리거나, 의도치 않게 외부 서버에 데이터를 보내는 상황이 생길 수 있습니다. 샌드박싱은 이런 위험을 막기 위해, 에이전트가 움직일 수 있는 기술적 경계를 미리 정해두는 장치입니다.
샌드박싱이 실제로 해주는 일은 승인 작업으로 인한 피로(approval fatigue)를 줄이는 것입니다. 샌드박스가 없다면 에이전트가 실행하는 모든 명령에 대해 사람이 일일이 “허용”을 눌러야 합니다. 샌드박스가 있으면, 경계 안의 낮은 위험 작업(파일 읽기, 워크스페이스 내 수정, 테스트 실행 등)은 자동으로 진행되고, 경계를 넘는 작업(인터넷 접근, 워크스페이스 밖 파일 수정 등)에서만 멈춰서 묻습니다. 사소한 명령마다 흐름이 끊기는 일이 줄고, 사람은 정말 중요한 판단에만 개입하면 됩니다.
샌드박스와 승인 정책은 따로 작동하는 두 가지 통제 장치입니다. 샌드박스는 코덱스가 무엇을 할 수 있는지의 기술적 경계를 정하고, 승인 정책은 그 경계를 넘어야 할 때의 행동 규칙을 정합니다.
(1) sandbox_mode (샌드박스 모드)
| 모드 | 권한 |
|---|---|
read-only | 파일 읽기만 허용. 수정·명령 실행은 승인 필요 |
workspace-write (기본) | 워크스페이스에서 파일 읽기·쓰기·명령 실행 가능. 인터넷 접근과 워크스페이스 밖은 승인 필요 |
danger-full-access | 파일시스템과 네트워크 제한 없음. 위험성을 이해한 작업에만 사용 |
(2) approval_policy (승인 정책)
| 정책 | 동작 |
|---|---|
untrusted | 신뢰되지 않은 명령은 항상 승인 요청 |
on-request (기본) | 샌드박스 경계를 넘을 때만 승인 요청 |
never | 승인 요청 없이 모두 실행 (위험) |
기본 조합은 workspace-write + on-request입니다. 이 조합에서 코덱스는 워크스페이스에서 자율적으로 움직이다가, 인터넷에 접근하거나 워크스페이스 밖 파일을 건드려야 할 때만 사람에게 묻습니다.
플랫폼별로 이 경계를 강제하는 방식은 다릅니다.
| 플랫폼 | 구현 |
|---|---|
| 맥 | 시트벨트(Seatbelt) 프레임워크 |
| 리눅스, WSL2 | 버블랩(bubblewrap) |
| 윈도우 (파워셸) | 윈도우 네이티브 샌드박스 |
| 윈도우 (WSL2) | 리눅스 구현을 그대로 사용 |
구현 방식은 OS에 따라 다르지만 “에이전트에게 정해진 경계 안에서만 자율을 준다”는 아이디어는 같습니다.
승인 검토자를 정하는 approvals_reviewer도 함께 있습니다. 기본은 user로 사람이 승인하고, auto_review로 두면 별도 리뷰어 에이전트가 자동 검토를 맡습니다. 자동 리뷰는 샌드박스 경계를 바꾸지 않고, 경계를 넘는 요청을 누가 검토할지만 바꾼다는 점에 주의해야 합니다.
4. 사용 가능 모델과 가격 정책
코덱스는 OpenAI의 최신 모델들을 골라 쓸 수 있게 되어 있습니다. 모델을 고를 때는 속도, 비용, 추론 깊이의 균형을 어디에 둘지가 기준이 됩니다.
| 모델 | 결 | 적합한 작업 |
|---|---|---|
| gpt-5.5 | 최신 주력 프론티어 모델 | 복잡한 코딩, 컴퓨터 유즈, 지식 작업, 리서치 워크플로 |
| gpt-5.4 | 코딩·추론·도구 사용 올라운더 | 전문가용 일반 작업 |
| gpt-5.4-mini | 빠르고 가벼운 미니 모델 | 응답성 중심의 가벼운 코딩, 서브에이전트 |
| gpt-5.3-codex | 코딩 특화 모델 | 복잡한 소프트웨어 엔지니어링 |
| gpt-5.3-codex-spark | Pro Only Research Preview 텍스트 전용, 초저지연 | 거의 즉시 응답이 필요한 실시간 코딩 이터레이션 |
| gpt-5.2 | 이전 세대 일반 모델 | 깊은 디버깅, 심층 사고가 필요한 작업 |
기본 추천은 gpt-5.5입니다. 모델 선택기에서 gpt-5.5가 보이지 않으면 gpt-5.4로 시작하면 됩니다. 가벼운 작업이나 서브에이전트용으로는 gpt-5.4-mini를, Pro 플랜에서 실시간 코딩 이터레이션이 필요하면 gpt-5.3-codex-spark를 씁니다.
모델 설정 방법은 환경마다 다릅니다.
| 환경 | 설정 방법 |
|---|---|
| 로컬 기본값 | config.toml에 model = "gpt-5.5" |
| CLI 일회성 | codex -m gpt-5.4 또는 세션 중 /model |
| IDE 익스텐션 | 입력창 아래 모델 선택기 |
| 클라우드 태스크 | 기본 모델 고정 (현재 사용자 변경 불가) |
CLI와 IDE 익스텐션은 같은 config.toml을 공유합니다. 클라우드 태스크는 사용자 단에서 모델을 바꿀 수 없고, OpenAI가 정한 기본 모델로 돌아갑니다.
1) 가격 정책
코덱스는 챗GPT 플랜에 묶여 있어, 별도 청구가 아니라 챗GPT 구독료 안에 사용량이 포함됩니다. 플랜별 차이는 모델 접근 범위, 사용량 한도, 관리자 기능에서 갈립니다.
| 플랜 | 월 요금 | 핵심 차이 |
|---|---|---|
| Free | $0 | 가벼운 코딩 탐색용 |
| Go | $8 | 가벼운 코딩 작업 |
| Plus | $20 | 주 몇 차례 집중 코딩 세션. 웹·CLI·IDE·iOS, 클라우드 코드 리뷰, 슬랙 연동, 최신 모델(GPT-5.5/5.4/5.3-Codex) 접근 |
| Pro | $100~$200 | Plus 대비 사용량 5배($100 티어) / 20배($200 티어). $100 티어는 2026년 5월 31일까지 프로모션으로 10배 적용. GPT-5.3-Codex-Spark 접근 |
| Business | 종량제 | 좌석 단위 과금, 대형 가상 머신, 관리자 제어, SAML SSO, MFA |
| Enterprise / Edu | 영업 문의 | 우선 처리, SCIM/EKM/RBAC, 감사 로그, 데이터 보존·거주지 제어 |
| API Key | 토큰 사용량 기반 | CLI/SDK/IDE에서만 사용, 클라우드 기능 없음, API 토큰 단위 과금 |
2) 사용량 한도 구조
코덱스의 사용량 한도는 5시간 롤링 윈도우 기준으로 계산됩니다. 로컬 메시지와 클라우드 태스크는 이 5시간 창을 공유합니다. 같은 모델이라도 작업 복잡도에 따라 메시지 한 건이 소비하는 양이 크게 달라지기 때문에, 공식 문서도 정확한 메시지 수가 아닌 범위로 한도를 표기합니다.
Plus와 Pro 5배 티어의 5시간 한도를 비교하면 다음과 같습니다.
| 모델 | Plus 로컬 메시지 (5시간당) | Pro 5배 로컬 메시지 (5시간당) | Pro 5배 클라우드 태스크 (5시간당) |
|---|---|---|---|
| GPT-5.5 | 15~80건 | 80~400건 | 미지원 |
| GPT-5.4 | 20~100건 | 100~500건 | 미지원 |
| GPT-5.4-mini | 60~350건 | 300~1,750건 | 미지원 |
| GPT-5.3-Codex | 30~150건 | 150~750건 | 50~300건 |
같은 Plus 사용자가 가벼운 코딩 질문을 던지면 GPT-5.5로 80건 정도까지 메시지를 보낼 수 있지만, 큰 코드베이스에서 컨텍스트가 무거운 작업을 시키면 15건 안팎에서 한도에 닿습니다. 가격표의 숫자가 범위로 적혀 있는 이유입니다.
3) 크레딧 시스템
한도를 넘으면 코덱스는 크레딧을 차감해 작업을 이어갑니다. 2026년 4월 2일 이후 과금 모델이 토큰 기반으로 바뀌면서, 크레딧이라는 결제 단위는 그대로 두되 소비 계산 방식이 “메시지 1건당 평균 크레딧”에서 “토큰 100만 개당 크레딧”으로 옮겨가는 중입니다. Business와 신규 Enterprise 고객은 이미 토큰 기반 요율로 전환되어 있고, Plus·Pro 사용자는 순차 전환이 진행되고 있습니다.
토큰 기반 요율의 핵심은 입력 토큰, 캐시된 입력 토큰, 출력 토큰의 단가가 따로 책정된다는 점입니다. 아래는 Business 및 신규 Enterprise 고객 기준 요율입니다.
| 모델 | 입력 토큰 100만 개당 | 캐시된 입력 토큰 100만 개당 | 출력 토큰 100만 개당 |
|---|---|---|---|
| GPT-5.5 | 125 크레딧 | 12.5 크레딧 | 750 크레딧 |
| GPT-5.4 | 62.5 크레딧 | 6.25 크레딧 | 375 크레딧 |
| GPT-5.4-mini | 18.75 크레딧 | 1.875 크레딧 | 113 크레딧 |
| GPT-5.3-Codex | 43.75 크레딧 | 4.375 크레딧 | 350 크레딧 |
출력이 많은 작업일수록 큰 모델과 작은 모델의 비용 차이가 더 벌어집니다. GPT-5.5의 출력 토큰 단가(100만 개당 750 크레딧)는 GPT-5.4-mini(113 크레딧)의 약 6.6배입니다.
아직 메시지 기반 요율이 적용되는 Plus·Pro 사용자의 경우, 대략적인 크레딧 소비는 다음과 같습니다.
| 작업 유형 | GPT-5.5 | GPT-5.4 | GPT-5.3-Codex | GPT-5.4-mini |
|---|---|---|---|---|
| 로컬 메시지 1건 | 약 14 크레딧 | 약 7 크레딧 | 약 5 크레딧 | 약 2 크레딧 |
| 클라우드 태스크 1건 | 미지원 | 미지원 | 약 25 크레딧 | 미지원 |
| 코드 리뷰 1건 | 미지원 | 미지원 | 약 25 크레딧 | 미지원 |
4) 한도 절약 팁
같은 한도에서 더 오래 일하려면 다음 사항들을 점검하는 것이 좋습니다.
- 프롬프트 크기 조절: 정확한 지시만 남기고 불필요한 컨텍스트는 빼기
- AGENTS.md 경량화: 큰 프로젝트에서는 레포지토리 하위 디렉토리에 중첩 배치해 필요한 범위에만 적용
- MCP 서버 정리: 안 쓰는 MCP는 꺼두기. MCP 서버 하나가 추가될 때마다 매 메시지의 컨텍스트가 늘어남
- 작은 모델로 전환: 루틴 작업은 GPT-5.4나 GPT-5.4-mini로 처리
이 네 가지는 사용량 한도뿐 아니라 응답 품질에도 영향을 줍니다. 컨텍스트가 깔끔하면 모델이 더 정확하게 작업합니다.
6. 코덱스에 맡기면 안 되는 작업
코덱스는 편리하지만, 이 자율성에는 양면성이 있습니다. 코덱스가 혼자 루프를 돌 때는 중간 확인 없이 다음 단계로 넘어가기 때문에, 한 단계에서 생긴 실수가 다음 단계의 입력이 됩니다. 작은 실수가 루프를 한 바퀴 돌 때마다 눈덩이처럼 점차 커지는 셈입니다.
아래 다섯 가지는 이런 실수 누적이 특히 위험해지는 작업입니다.
| 상황 | 위험 | 권장 처리 |
|---|---|---|
| 되돌릴 수 없는 대규모 데이터 변환 | 롤백 없이 자동 실행하면 데이터 손실 | 코덱스는 스크립트 생성까지만, 실행은 사람이 단계별로 |
| 운영 환경의 비밀번호·API 키 노출 | 민감 정보가 모델 컨텍스트에 올라가 의도치 않게 유출 | 별도 보안 도구에 보관, 코덱스에는 권한 제한된 임시 토큰만 전달 |
| 실행할 때마다 결과가 달라지는 테스트 환경 | 멀쩡한 코드를 “실패”로 오판해 엉뚱하게 수정 | 결과가 일정한 테스트 환경으로 분리, 검증 기준 명시 |
| 프로젝트 전체를 한 번에 리팩토링 | 변경 범위가 넓어 충돌·누락 통제 불가 | 마일스톤 단위로 분할, PR마다 사람이 검토 |
| 승인 없는 풀 액세스 자동화 | 파일시스템·네트워크 전 영역에서 묻지 않고 실행 | 격리된 환경에서만, 의도가 명확한 경우에만 사용 |
1) 되돌릴 수 없는 대규모 데이터 변환
데이터베이스의 구조를 통째로 바꾸거나, 수백 개 테이블의 형식을 일괄 변환하는 작업이 여기에 해당합니다. 이런 작업은 한 번 실행하면 원래 상태로 되돌리기가 어렵거나 아예 불가능합니다.
코덱스가 변환 스크립트를 자동으로 만들고 바로 실행까지 하면, 중간에 잘못된 변환이 끼어 있어도 루프가 끝날 때까지 알아차리기 어렵습니다. 엑셀 파일 수천 줄을 일괄 수정했는데 저장 버튼까지 눌러버린 상황과 비슷합니다. Ctrl+Z가 안 되는 규모라는 점이 다릅니다.
이런 작업에는 코덱스에게 스크립트 생성까지만 맡기고, 실행은 사람이 결과를 검토한 뒤 직접 하는 것이 안전합니다. 변환을 한 번에 하지 말고 단계별로 쪼개서, 각 단계 사이에 사람이 확인하는 체크포인트를 넣어야 합니다.
2) 운영 환경의 비밀번호·API 키가 노출되는 작업
코덱스가 일하려면 프로젝트 폴더의 파일을 읽어야 합니다. 그런데 그 폴더에 실제 서비스의 API 키, 데이터베이스 비밀번호, 클라우드 접속 토큰 같은 민감 정보가 들어 있으면, 이 정보가 모델의 컨텍스트에 그대로 올라갑니다.
비유하면 집 열쇠를 심부름꾼에게 맡기는 것과 같습니다. 심부름은 편하지만, 그 열쇠가 어디에 놓이는지는 통제할 수 없습니다. 코덱스가 민감 정보를 의도치 않게 로그에 남기거나, 실행하는 명령어의 일부로 노출할 수 있습니다.
민감 정보는 별도의 보안 관리 도구(Vault, AWS Secrets Manager 같은 서비스)에 보관하고, 코덱스에는 권한이 제한된 임시 토큰만 전달해야 합니다. 3장에서 다룬 샌드박스 설정에서 민감 파일의 경로를 읽기 금지로 지정하는 것도 방법입니다.
3) 실행할 때마다 결과가 달라지는 테스트 환경
에이전트 루프의 핵심은 “실행 → 결과 확인 → 다음 판단”의 반복입니다. 이 구조가 제대로 작동하려면, 같은 코드를 돌렸을 때 같은 결과가 나와야 합니다.
그런데 현실에는 결과가 매번 달라지는 테스트가 많습니다. 외부 서버에 요청을 보내는 테스트는 서버 상태에 따라 성공하기도 하고 실패하기도 합니다. 타이밍에 민감한 테스트는 컴퓨터가 바쁠 때 느려져서 실패합니다. 이런 환경에서 코덱스를 무인으로 돌리면, 코드에 문제가 없는데도 “테스트가 실패했으니 고쳐야 한다”고 판단해서 멀쩡한 코드를 엉뚱하게 수정할 수 있습니다.
코덱스에게 테스트를 돌리게 하려면, 외부 의존 없이 항상 같은 결과가 나오는 테스트 환경을 먼저 만들어야 합니다. 그리고 “어떤 조건이면 성공이고 어떤 조건이면 실패인지”를 AGENTS.md에 명확하게 적어두는 것이 좋습니다.
4) 프로젝트 전체를 한 번에 리팩토링
리팩토링은 코드의 동작은 그대로 두고 구조만 정리하는 작업입니다. 파일 하나, 함수 하나 단위로 하면 코덱스가 잘 해냅니다. 문제는 “프로젝트 전체를 한 번에 정리해줘”처럼 범위가 넓은 경우입니다.
수십 개 파일을 동시에 고치면, 파일 A의 변경이 파일 B에 영향을 주고, 그 영향이 다시 파일 C로 번집니다. 코덱스는 에이전트 루프 안에서 이 연쇄를 한꺼번에 처리하려고 하는데, 범위가 넓어질수록 어딘가에서 빠뜨리거나 충돌이 생길 확률이 높아집니다. 퍼즐 조각 열 개를 맞추는 건 쉽지만, 천 개를 한 번에 맞추라고 하면 중간에 틀린 조각이 끼어도 모르는 것과 같습니다.
이런 작업은 마일스톤 단위로 쪼개야 합니다. “이번에는 이 모듈만 정리해줘”처럼 범위를 좁히고, 한 단위가 끝날 때마다 PR(Pull Request)을 만들어 사람이 검토한 뒤 다음으로 넘어가는 방식이 안전합니다.
5) 승인 없는 풀 액세스 자동화
가장 위험한 승인 설정 조합이 danger-full-access + approval_policy = "never"입니다. 이 설정을 켜면 코덱스가 사용자에게 아무것도 묻지 않고, 파일시스템과 네트워크 전 영역에서 마음대로 명령을 실행할 수 있게 됩니다.
자동차의 브레이크와 핸들을 동시에 떼어내는 것과 같습니다. 도로에서는 문제없이 달릴 수 있지만, 예상 밖의 상황이 오면 멈출 수도 방향을 바꿀 수도 없습니다. 코덱스가 의도와 다른 판단을 내려도, 사람이 끼어들 수 있는 지점이 아예 없습니다.
이 조합은 “실수가 생겨도 피해가 없는 완전히 격리된 환경”에서, “정확히 무엇을 하려는지 사용자가 이해하고 있을 때”에만 써야 합니다. 예를 들어 일회용 테스트 컨테이너 안에서 빌드를 돌리는 경우라면 괜찮습니다. 실제 서비스가 돌아가는 환경에서는 절대 이 조합을 쓰면 안 됩니다.
마무리
코덱스는 사용자의 의도를 받아 에이전트 루프를 돌면서 스스로 파일을 읽고, 명령을 실행하고, 결과를 확인하는 코딩 에이전트입니다. 앱·IDE 익스텐션·CLI·웹 네 가지 환경에서 같은 에이전트를 쓸 수 있고, 샌드박싱과 승인 정책으로 자율성의 범위를 조절합니다. 모델은 작업 성격에 따라 gpt-5.5부터 gpt-5.4-mini까지 골라 쓸 수 있고, 비용은 챗GPT 플랜에 묶여 있어 별도 청구 없이 사용량 한도 안에서 소진됩니다.
다만 코덱스는 중간 확인 없이 루프를 돌기 때문에, 되돌릴 수 없는 데이터 변환, 민감 정보가 포함된 작업, 프로젝트 전체 리팩토링처럼 실수가 누적되기 쉬운 작업에는 사람의 체크포인트가 반드시 필요합니다.
Codex 시리즈