Codex 완벽 가이드 2026: CLI부터 Plan, Review, 스킬까지 한 번에 정리

여러분, “Claude Code 말고 Codex도 다뤄 달라”는 요청을 정말 많이 받았습니다. OpenAI Codex는 단순히 터미널에서 대화하는 AI 도구가 아닙니다. 개발자의 로컬 작업 흐름과 GitHub 리뷰 흐름까지 연결하는 에이전트형 개발 환경에 가깝습니다. 그래서 이번 글에서는 Codex를 처음 접하는 분도 바로 시작할 수 있도록 설치와 기본 조작을 짚고, 이미 쓰고 계신 분도 놓치기 쉬운 세션 관리, Plan 모드, Review 모드, 스킬 활용까지 한 번에 정리해보겠습니다.

요즘 Claude Code가 뭔가 답답하다고 느끼셨던 분들이 많을 겁니다. 그래서 Codex를 함께 검토하는 개발자도 늘고 있습니다. 아래에서 Claude Code의 추론 설정, 캐싱, 출력량 조정이 품질 체감에 어떤 영향을 줬는지 짚은 뒤, Codex가 어떤 상황에서 대안이 될 수 있는지 살펴보겠습니다. 결론부터 말하면, 둘 중 하나만 고르는 게 아닙니다. 각 도구의 강점을 이해하고 작업 성격에 맞게 나눠 쓰는 것이 핵심이라고 봅니다.

• Codex는 로컬 파일 읽기와 수정, 외부 접근 승인, 전체 권한 실행을 구분하는 권한 모드를 제공해 작업 위험도에 따라 실행 방식을 조절할 수 있다.
• /statusline, /model, /fast 같은 설정은 현재 세션의 상태와 모델 동작 방식을 눈에 보이게 만들고, 반복 작업에서 생산성 차이를 만든다.
• /clear, codex resume, codex fork, /compact는 긴 대화로 인한 컨텍스트 누적 문제를 관리하는 핵심 도구다.
• $imagegen 같은 스킬은 Codex 내부에서 개발 작업과 이미지 생성 작업을 같은 워크플로우로 묶을 수 있게 해 준다.
• Plan 모드와 Review 모드는 바로 구현하기보다 계획과 검토를 먼저 거치게 하므로, 기능 단위 개발과 PR 전 셀프 리뷰에 특히 유용하다.
• Codex Cloud와 GitHub 리뷰 연결을 활용하면 PR 단계에서 자동 리뷰와 수정 요청까지 이어지는 팀 단위 워크플로우를 만들 수 있다.

Codex를 쓰기 전에 이해해야 할 배경

Claude Code와 Codex는 같은 문제를 다르게 푼다

출발점은 Claude Code 사용자들이 느끼는 답답함입니다. Anthropic은 Claude Code 품질 저하의 원인으로 세 가지를 공식적으로 밝혔습니다. 기본 추론 난이도가 ‘높음’에서 ‘중간’으로 바뀐 문제, 한 시간 이상 활동이 없던 세션의 이전 사고 과정을 지운 캐싱 변경, 그리고 출력량을 줄이려는 시스템 프롬프트 조정입니다. 제가 말하고 싶은 건 특정 도구를 비판하자는 게 아닙니다. AI 코딩 도구의 품질이 모델 성능만으로 결정되지 않는다는 점입니다. 기본 추론 단계, 세션 기억 방식, 시스템 지침처럼 겉으로 잘 보이지 않는 설정이 실제 개발 경험을 크게 바꿀 수 있습니다.

Codex 역시 이런 설정의 영향을 받습니다. 다만 Codex는 권한 모드, 모델 선택, reasoning 단계, fast mode, Plan/Review 같은 조작면을 CLI 안에서 비교적 명확하게 드러냅니다. 덕분에 개발자는 “지금은 빠른 초안이 필요한가”, “깊은 추론이 필요한가”, “파일 수정까지 맡겨도 되는가”를 작업 단위로 선택할 수 있습니다.

중요한 포인트는 Codex를 Claude Code의 대체재로만 보지 않는 것입니다. 계획, 리뷰, 장시간 자율 실행에 강한 또 하나의 작업자로 이해하는 게 좋습니다.

설치와 첫 실행

Codex는 npm으로 설치한 뒤 터미널에서 codex 명령으로 실행합니다. 실행하면 Claude Code와 비슷한 대화형 CLI UI가 뜨고, 일반 채팅처럼 “현재 코드베이스 분석해줘” 같은 요청을 바로 보낼 수 있습니다. 그러면 Codex가 현재 프로젝트 파일을 읽고 구조를 파악한 뒤 분석 결과를 돌려줍니다.

여기서 중요한 건 Codex가 단순 질의응답 도구가 아니라는 점입니다. 실제 로컬 작업 디렉터리를 기준으로 동작합니다. 어떤 프로젝트 경로에서 실행했는지, 어떤 브랜치에서 작업 중인지, 현재 컨텍스트를 얼마나 사용했는지가 결과 품질에 영향을 줍니다.

권한, 상태 표시, 모델 설정

Permission 모드로 실행 범위를 정한다

Codex의 /permissions 명령은 에이전트가 어느 정도까지 자율적으로 움직일 수 있는지 정하는 설정입니다. 크게 세 가지 수준이 있습니다. 기본 모드는 파일 읽기와 수정은 비교적 자유롭게 허용하되, 외부 인터넷 접근이나 현재 디렉터리 밖의 파일 수정처럼 위험도가 있는 행동은 사용자 승인을 받습니다. 일반적인 개발 작업에서는 이 방식이 균형이 좋습니다.

두 번째는 auto review 성격의 모드입니다. 에이전트가 명령을 실행하려 할 때, 그 명령이 안전한지 판단하는 리뷰어 역할을 거쳐 조금 더 자율적으로 진행합니다. 세 번째는 full access에 가까운 모드로, 모든 명령을 에이전트가 자율적으로 실행하게 합니다. 속도는 빠르지만 위험도도 높습니다. 그래서 신뢰할 수 있는 격리 환경이나 명확한 작업 범위가 있을 때만 적합하다고 봅니다.

모드	적합한 상황	주의점
기본 권한	일반 개발, 파일 수정, 빌드/테스트	외부 접근은 승인 필요
auto review	반복 명령이 많고 어느 정도 자율성이 필요한 작업	리뷰 판단을 맹신하지 말고 결과 확인 필요
full access	격리된 환경에서 빠른 자동화가 필요한 작업	파괴적 명령 실행 위험 관리 필요

Statusline은 세션의 계기판이다

/statusline은 채팅창 아래쪽에 표시되는 상태 정보를 조절하는 기능입니다. 모델명, reasoning 단계, Git 브랜치, 컨텍스트 사용량, fast mode 여부, 프로젝트 이름 등을 표시하도록 설정할 수 있습니다. 저는 이 항목들을 켜두고 씁니다. 이 정보는 단순 장식이 아니거든요. 긴 작업을 맡겨 두었을 때 지금 어떤 모델로 돌고 있는지, 컨텍스트가 얼마나 찼는지, fast mode가 켜져 있는지 바로 판단할 수 있게 해줍니다.

AI 코딩 도구는 컨텍스트가 쌓일수록 느려지거나 판단이 흐려질 수 있습니다. 그래서 statusline으로 컨텍스트 사용량을 계속 보는 습관은 작업 품질 관리와 직접 연결된다고 봅니다.

모델과 reasoning, fast mode

/model 명령에서는 사용할 모델뿐 아니라 reasoning 단계를 선택할 수 있습니다. reasoning 단계가 높을수록 더 깊게 추론하는데, 저는 보통 high로 두고 씁니다. 복잡한 설계, 코드 리뷰, 장기 작업에는 reasoning을 높이는 편이 유리하고, 단순한 수정이나 빠른 초안에는 더 가벼운 설정으로도 충분할 수 있습니다.

/fast는 응답 속도를 높이는 토글입니다. fast mode는 일부 모델에서만 지원되는데, 현재 기준으로는 GPT 5.5와 5.4에서 쓸 수 있습니다. 다만 표준 모드보다 크레딧을 더 소모합니다. GPT 5.5는 2.5배, GPT 5.4는 2배를 쓰니까, 빠른 응답이 중요한 순간과 비용 효율이 중요한 순간을 구분해서 쓰는 게 좋습니다.

세션과 컨텍스트를 관리하는 법

Queue, Copy, Clear

Codex에서 작업이 진행되는 동안 다음 요청을 미리 넣고 싶을 때는 프롬프트 작성 후 Tab을 눌러 queue에 쌓을 수 있습니다. 긴 분석이나 빌드가 진행되는 동안 후속 작업을 몇 개든 예약해 둘 수 있어서, 흐름을 끊지 않고 다음 단계를 준비하기 좋습니다.

/copy 또는 Ctrl+O는 마지막 응답을 클립보드로 복사합니다. 분석 결과를 다른 세션, 문서, Claude Code 등에 넘겨야 할 때 유용합니다. 반대로 /clear는 현재 대화 내역을 초기화해 새로운 세션처럼 시작하게 합니다. 제가 권장하는 방식은 하나의 세션에서 끝없이 대화를 이어가는 게 아닙니다. 맥락이 이어지는 기능 단위로 세션을 나누고, 필요할 때 clear로 컨텍스트를 낮게 유지하는 쪽이 더 좋습니다.

Prompt history와 임시 저장

이전에 작성했던 프롬프트를 다시 쓰고 싶을 때는 위아래 방향키로 히스토리를 탐색할 수 있고, Ctrl+R로 특정 프롬프트를 검색할 수 있습니다. 작성 중인 프롬프트를 잠시 버퍼처럼 보관하고 싶을 때는 Ctrl+C를 활용하면 됩니다. 작성 중이던 입력 내용은 삭제되지만 히스토리에 남기 때문에, 이후 방향키로 다시 불러와 이어서 쓸 수 있습니다. 참고로 Claude Code에서는 이 동작을 ESC로 했는데, Codex에서는 ESC가 반응하지 않으니 Ctrl+C를 기억해 두면 좋습니다.

프롬프트를 메모장에 복사해 두는 대신 CLI 내부의 히스토리와 검색을 활용하면 반복 요청을 더 빠르게 다듬을 수 있습니다.

Resume, Fork, Compact

codex resume은 이전 세션을 복구하는 명령입니다. 기본적으로 현재 프로젝트 디렉터리에서 진행했던 세션을 보여주는데, 전체 프로젝트의 세션까지 보고 싶다면 --all 옵션을 붙이면 됩니다. 이미 진행하던 작업의 맥락을 이어가야 할 때 유용합니다.

fork는 현재 세션을 복제해 같은 대화 맥락을 가진 새 세션을 만드는 기능입니다. 기존 작업을 보존한 채 다른 방향으로 실험을 해보고 싶을 때 적합하죠. /compact는 긴 대화 내역을 필요한 맥락만 남기도록 압축합니다. 완전히 새로 시작하는 /clear와 달리, 기존 맥락을 유지해야 하는 작업에서 성능 저하를 줄이는 중간 선택지입니다.

스킬과 이미지 생성 워크플로우

$skill 호출 방식

Codex에서 스킬은 $를 입력해 호출합니다. 예를 들어 $imagegen을 입력하면 개발 워크플로우 안에서 로고나 이미지를 생성할 수 있습니다. 여기서 중요한 건 이미지 생성이 별도 도구로 분리되지 않는다는 점입니다. Codex CLI 내부의 같은 흐름에서 그대로 진행됩니다. 이 스킬은 Codex 요금제에 포함돼 사용량이 측정되고, 따로 추가 결제를 할 필요는 없습니다.

예를 들어 CLI 도구의 로고를 만들고, 그 이미지를 README나 환영 배너에 적용하는 작업을 한 세션 안에서 이어갈 수 있습니다. 이렇게 되면 기획, 이미지 생성, 코드 반영, 실행 확인이 하나의 작업 흐름으로 묶입니다.

$imagegen 우리 CLI 도구에 어울리는 로고를 만들어줘
생성된 이미지를 README 상단과 CLI welcome banner에 적용해줘

개발 작업과 비개발 작업의 경계가 줄어든다

스킬의 장점은 반복되는 전문 작업을 Codex가 더 잘 수행하도록 지침과 도구를 묶어 둘 수 있다는 데 있습니다. 이미지 생성뿐 아니라 블로그 동기화, 배포, PR 생성, 문서화 같은 작업도 스킬로 정리하면 “무엇을 어떤 순서로 해야 하는지”를 매번 다시 설명하지 않아도 됩니다.

이렇게 보면 Codex는 단순 코딩 보조자가 아닙니다. 개발자가 자주 수행하는 주변 작업까지 흡수하는 워크플로우 허브에 가깝다고 봅니다.

Plan과 Review로 작업 품질을 높인다

Plan 모드는 바로 코딩하지 않는다

/plan 또는 Shift+Tab으로 전환하는 Plan 모드는 Codex가 바로 파일을 수정하지 않습니다. 계획 문서를 먼저 만든 다음 개발에 들어갑니다. 예를 들어 이미지 생성 결과를 프로젝트 README와 CLI welcome banner에 반영하는 작업을 시키면, Codex가 필요한 질문을 역으로 던지고 실행 계획을 세운 뒤, 사용자가 실행 방식을 선택하게 합니다.

이 방식은 기능 단위 작업에 특히 좋습니다. 계획을 먼저 만들면 수정 범위와 검증 방법이 명확해지고, 필요하다면 현재 컨텍스트를 초기화한 뒤 계획만 들고 새로 실행할 수 있죠. 저는 보통 하나의 플랜을 피처 단위로 보기 때문에, 컨텍스트를 초기화하고 계획 기반으로 새로 실행하는 옵션을 자주 씁니다. 컨텍스트가 낮은 상태에서 명확한 계획을 실행하면 에이전트의 품질도 안정적으로 유지됩니다.

Review는 커밋 전과 PR 단계 모두에서 쓴다

/review는 로컬 변경사항을 커밋하기 전에 스스로 검토하는 데 쓸 수 있습니다. Codex는 Git 상태와 diff를 확인하고, 필요하면 로컬에서 테스트나 빌드 결과까지 참고해 문제를 찾습니다. 사람 리뷰어에게 PR을 올리기 전 기본적인 결함을 줄이는 데 효과적이죠.

여기서 한발 더 나아갈 수 있습니다. Codex Cloud와 GitHub를 연결하면 PR이 열리거나 업데이트될 때 Codex가 자동으로 코드 리뷰를 남깁니다. GitHub connector 설정, 리뷰 트리거, repository별 활성화, PR 코멘트, 그리고 Codex에게 직접 수정 요청을 보내는 흐름까지 가능합니다. 로컬 CLI에서 계획과 구현을 하고, Cloud에서 PR 리뷰와 수정까지 이어지는 구조입니다. 팀원에게 리뷰를 받는 것처럼 Codex 에이전트를 저장소에 붙여두는 셈이죠.

Codex와 Claude Code를 함께 쓰는 전략

Codex가 특히 잘 맞는 작업

결론부터 말하면, Codex가 Claude Code보다 무조건 낫다는 건 아닙니다. 다만 제 경험과 주변 개발자들 얘기를 들어보면 Codex만의 강점이 분명히 있습니다. 같은 작업에서 토큰을 2~3배 정도 덜 쓰는 경향이 있고, 장기간 자율 실행이 필요한 작업에서 유용하거든요. 저는 백엔드 작업, 터미널 도구를 많이 쓰는 작업, 그리고 계획과 리뷰 단계에서 Codex를 자주 씁니다.

Codex가 Claude Code보다 느리게 느껴질 수는 있습니다. 그런데 어차피 작업 하나를 시켜두고 그것만 계속 보고 있는 건 아니잖아요. 한 세션에 작업을 맡겨둔 동안 다른 세션에서 병렬로 일을 진행할 수 있다면, 단일 응답 속도보다 전체 처리량이 더 중요해집니다. 이 관점에서는 Codex의 세션 관리, fork, resume, Plan/Review 기능이 큰 장점이 됩니다.

Claude Code가 여전히 맞는 작업도 있다

사실 저는 Claude Code도 함께 씁니다. 일상적인 개발이나 대규모 리팩터링처럼 Claude Code가 익숙하고 강점을 보이는 영역에서는 그대로 쓰고, Codex는 계획 수립, 리뷰, 장시간 자율 작업에 배치하는 식이죠. 두 도구를 경쟁 관계로만 볼 필요는 없습니다. 가장 좋은 건 둘 다 각각의 장단점이 있으니 같이 쓰는 거라고 봅니다.

실무적으로는 다음처럼 나눠 쓸 수 있습니다.

1. 기능 설계와 작업 계획은 Codex Plan 모드로 정리한다.
2. 구현은 Codex 또는 Claude Code 중 현재 프로젝트와 작업 성격에 맞는 도구로 진행한다.
3. 커밋 전에는 Codex Review로 로컬 변경사항을 먼저 점검한다.
4. PR 단계에서는 Codex Cloud 리뷰를 붙여 팀 리뷰 전에 자동 검토를 받는다.
5. 긴 세션은 /clear, /compact, resume, fork로 관리해 컨텍스트 품질을 유지한다.

마무리

Codex를 제대로 쓰려면 설치 후 채팅만 하는 수준을 넘어야 합니다. 권한 모드와 모델 설정, 세션 관리, 스킬, Plan, Review를 하나의 개발 루틴으로 묶는 게 핵심입니다. 특히 컨텍스트 사용량을 관리하고, 기능 단위로 계획을 세우고, PR 전후에 리뷰를 자동화하는 흐름을 만들면 Codex의 장점이 분명해집니다.

제가 말하고 싶은 건 Codex가 “또 하나의 AI 코딩 도구”가 아니라는 점입니다. 로컬 CLI, 스킬, 이미지 생성, GitHub 리뷰, Cloud 수정 요청까지 이어지는 작업 시스템으로 보면 활용 범위가 훨씬 넓어집니다. Claude Code와 Codex를 둘 다 이해하고, 작업의 성격에 따라 계획, 구현, 리뷰 역할을 나눠 배치하는 것. 저는 이게 2026년 AI 개발 워크플로우의 현실적인 전략이라고 봅니다.

---

관련 영상

이 글과 연결된 영상은 개발동생 유튜브 채널에서 보기에서 확인할 수 있습니다.