OpenAI Codex 주요 기능 11가지 정리

CHZEE93·2026년 8월 16일

AI개발

목록 보기

11/11

메타프롬프팅부터 Worktree, `/review`, `/goal`, Plan Mode까지

OpenAI Codex를 사용하다 보면 단순히

이 기능 만들어줘

라고 요청하는 것보다, 작업을 어떻게 정의하고, 분리하고, 검증하고, 이어갈 것인지를 잘 활용하는 것이 훨씬 중요합니다.

Codex에는 이를 도와주는 여러 기능과 명령어가 있습니다.

이번 글에서는 자주 언급되는 기능 11가지를 정리해보겠습니다.

2026년 8월 기준 OpenAI 공식 문서를 참고해 작성했습니다.
Codex CLI, IDE Extension, ChatGPT 데스크톱 앱에서는 제공되는 기능이나 UI가 조금씩 다를 수 있습니다.

한눈에 보기

기능	한 줄 설명
메타프롬프팅	Codex에게 작업용 프롬프트 자체를 먼저 설계하게 하기
Worktree	같은 저장소에서 독립적인 작업 공간을 만들어 병렬 작업
`/review`	현재 코드 변경사항을 Codex에게 코드 리뷰시키기
`/fork`	현재 대화를 복제해 다른 방향으로 작업하기
`/compact`	긴 대화 내용을 요약해 컨텍스트 공간 확보
`/goal`	Codex에게 지속적으로 추적할 목표와 완료조건 설정
Steering	실행 중인 Codex에게 추가 지시를 넣어 방향 수정
`/plan`	코드 수정 전에 조사와 실행 계획부터 만들기
`/mcp`	Codex가 사용할 수 있는 외부 MCP 도구 확인
Skills	반복 작업을 재사용 가능한 작업 방식으로 저장
`/status`	현재 세션, 모델, 컨텍스트 등의 상태 확인

1. 메타프롬프팅(Meta Prompting)

무엇인가?

메타프롬프팅은 Codex의 특정 /명령어라기보다는 프롬프트를 만드는 방법입니다.

바로 작업을 시키는 대신,

"이 작업을 Codex가 잘 수행할 수 있도록 프롬프트부터 만들어줘."

라고 요청하는 방식입니다.

즉,

사람 → Codex → 작업

이 아니라,

사람 → Codex에게 좋은 프롬프트 작성 요청
     → 완성된 프롬프트
     → Codex가 실제 작업 수행

구조를 사용하는 것입니다.

OpenAI 역시 Codex 프롬프트에서는 원하는 결과, 관련 코드나 재현 방법, 제약사항, 검증 방법 등을 명확하게 제시하는 방식을 권장합니다.

사용 예시

처음부터 이렇게 요청할 수 있습니다.

다음 요구사항을 Codex가 구현하기 좋은 작업 프롬프트로 다시 작성해줘.

목표:
React 프로젝트에 로그인 기능 추가

프롬프트에는 다음을 포함해줘.
- 목표
- 작업 범위
- 제약사항
- 검증 방법
- 완료 조건

아직 코드는 수정하지 말고 프롬프트만 만들어줘.

그러면 만들어진 프롬프트를 다시 Codex에 넣어 실제 작업을 시작하면 됩니다.

언제 좋을까?

요구사항이 아직 모호할 때
큰 기능을 구현할 때
리팩터링 작업
여러 파일을 수정해야 할 때
/plan, /goal을 사용하기 전에 요구사항을 정리할 때

2. Worktree

무엇인가?

Worktree는 쉽게 생각하면

같은 Git 저장소의 복사된 작업 공간을 하나 더 만드는 기능

입니다.

Git Branch와 비슷하게 느껴질 수 있지만 정확히는 다릅니다.

Branch가 Git의 변경 이력과 포인터를 분리하는 개념이라면, Worktree는 하나의 Git 저장소에서 실제로 별도의 작업 디렉터리(checkout)를 만들어 동시에 작업할 수 있게 하는 기능입니다.

Codex에서는 Worktree를 활용해 여러 작업을 서로 간섭하지 않고 병렬로 진행할 수 있습니다.

예를 들어,

Local
└── main 작업

Worktree A
└── 로그인 기능 개발

Worktree B
└── 결제 버그 수정

Worktree C
└── 테스트 코드 작성

처럼 사용할 수 있습니다.

사용법

지원되는 Codex 환경에서는 다음 명령을 사용할 수 있습니다.

/worktree

Codex 데스크톱 환경에서는 새로운 작업을 시작할 때 Worktree를 선택하고 기준 Branch를 선택하는 방식으로도 사용할 수 있습니다. /worktree 역시 새로운 Git worktree에서 대화를 실행하는 명령으로 문서화되어 있습니다.

언제 좋을까?

특히 여러 Codex Agent에게 동시에 작업시킬 때 유용합니다.

Agent 1 → 로그인 기능
Agent 2 → 관리자 페이지
Agent 3 → 테스트 작성

세 Agent가 동일한 작업 폴더를 수정하면 충돌할 수 있지만 각각 Worktree를 사용하면 작업을 분리할 수 있습니다.

3. `/review`

무엇인가?

Codex에게 코드 리뷰를 요청하는 기능입니다.

직접 작성했거나 Codex가 수정한 코드를 커밋하기 전에 문제를 검사할 수 있습니다.

Codex는 현재 Working Tree의 변경사항이나 특정 Base Branch와의 차이를 대상으로 리뷰할 수 있습니다.

사용법

/review

조금 더 구체적으로 요청할 수도 있습니다.

/review 보안 취약점과 예외 처리 위주로 확인해줘

또는

/review Focus on edge cases and security issues

활용 흐름

기능 구현
↓
테스트
↓
/review
↓
문제 수정
↓
다시 /review
↓
Commit

Codex를 사용할 때 상당히 유용한 습관입니다.

4. `/fork`

무엇인가?

/fork는 현재 Codex 대화를 복사해서 새로운 대화로 분기하는 기능입니다.

여기서 주의할 점은 GitHub의 Fork 기능과는 다른 개념이라는 것입니다.

현재까지의 대화와 컨텍스트는 유지하면서 새로운 방향을 시험해볼 수 있습니다. CLI에서는 새로운 Chat ID를 가진 대화가 만들어지고 기존 대화는 그대로 유지됩니다.

사용법

/fork

예를 들어 현재 대화에서 React 기반으로 개발하고 있었다고 가정해보겠습니다.

현재 대화
React 방식으로 구현

여기서 /fork를 사용하면

기존 대화
└── React 구현 계속

Fork한 대화
└── Next.js 방식으로 다시 시도

처럼 다른 방향을 실험할 수 있습니다.

언제 좋을까?

구현 방법 A/B 비교
현재 대화를 망치지 않고 실험하고 싶을 때
다른 아키텍처를 테스트할 때
다른 모델이나 접근법으로 다시 시도할 때

5. `/compact`

무엇인가?

긴 대화를 하다 보면 Codex가 처리해야 하는 Context가 계속 증가합니다.

/compact는 지금까지의 대화 내용을 핵심 내용 중심으로 요약해서 컨텍스트 공간을 확보하는 기능입니다. 이전 대화 전체를 그대로 유지하는 대신 중요한 정보를 간결한 요약으로 교체합니다.

쉽게 표현하면

대화 100페이지
↓
핵심 내용 5페이지로 요약

하는 느낌입니다.

따라서 흔히 "기억력 압축"이라고 설명할 수 있지만, 정확하게는 장기 기억(Memory)을 만드는 기능이라기보다 현재 대화의 Context를 압축하는 기능입니다.

사용법

/compact

긴 작업 중에 컨텍스트가 많이 쌓였다면 실행하면 됩니다.

언제 사용하면 좋을까?

같은 작업을 오래 진행했을 때
수많은 파일을 분석했을 때
대화가 매우 길어졌을 때
Context 사용량이 많아졌을 때

/status와 같이 사용하면 현재 Context 상황을 확인하는 데 도움이 됩니다.

6. `/goal` — 목표와 완료 조건 설정

무엇인가?

/goal은 Codex에게 지속적으로 추적해야 하는 목표를 설정하는 기능입니다.

일반 프롬프트가

"이번 요청에서 이것을 해줘."

에 가깝다면 /goal은

"이 상태가 될 때까지 이 목표를 계속 추적해."

에 가깝습니다.

OpenAI는 Goal을 검증 가능한 종료 조건을 가진 지속적인 목표로 설명하고 있습니다.

좋은 Goal의 구성

Goal에는 가능하면 세 가지가 들어가는 것이 좋습니다.

1. Outcome
   무엇을 만들 것인가?

2. Constraints
   무엇을 지켜야 하는가?

3. Verification
   무엇을 만족하면 완료인가?

그리고 가능하다면 Stop Condition, 즉 완료 조건도 명확하게 만드는 것이 좋습니다.

Goal을 메타프롬프팅으로 만들기

바로 /goal을 작성하기 어렵다면 Codex에게 Goal부터 만들어 달라고 요청할 수 있습니다.

내가 설명하는 작업을 Codex /goal에 넣기 좋은 형태로 다시 작성해줘.

반드시 포함할 것:
- 최종 목표
- 변경 범위
- 변경하면 안 되는 것
- 검증 방법
- 명확한 완료 조건

Goal은 Codex가 스스로 완료 여부를 판단할 수 있도록 작성해줘.

그 다음 결과를 /goal로 실행합니다.

예:

/goal 로그인 기능을 구현한다.
기존 REST API 인터페이스는 변경하지 않는다.
잘못된 로그인과 정상 로그인을 모두 테스트한다.
lint와 전체 인증 테스트가 통과하고 로그인 상태가 새로고침 후에도 유지되면 완료한다.

CLI에서는 다음과 같이 Goal 상태를 관리할 수도 있습니다.

/goal
/goal edit
/goal pause
/goal resume
/goal clear

7. Steering

무엇인가?

Steering은 Codex가 이미 작업하고 있는 도중에 추가 지시를 넣어서 현재 작업 방향을 수정하는 기능입니다.

예를 들어 Codex가 작업 중인데

아, DB 스키마는 건드리면 안 되는데...

라는 사실을 뒤늦게 발견했다고 해보겠습니다.

작업이 끝날 때까지 기다릴 필요 없이 바로

DB 스키마는 수정하지 마.
현재 방식에서 API 코드만 변경해.

라고 추가 지시할 수 있습니다.

Codex는 이 메시지를 현재 실행 중인 작업에 반영할 수 있습니다.

Steer와 Queue의 차이

Codex에는 비슷해 보이는 두 개념이 있습니다.

Steer
→ 지금 실행 중인 작업에 바로 반영

Queue
→ 현재 작업이 끝난 다음 요청으로 실행

Codex CLI에서는 작업 중 메시지를 작성한 뒤 Enter를 사용하면 현재 Turn을 Steer, Tab을 사용하면 다음 Turn에 Queue하는 방식이 지원됩니다. 데스크톱/IDE 환경에서는 설정에 따라 후속 메시지를 Steer 또는 Queue 방식으로 처리할 수 있습니다.

언제 좋을까?

Codex가 잘못된 방향으로 가고 있을 때
추가 요구사항이 생겼을 때
특정 파일을 건드리지 말라고 알려줄 때
구현 방식을 중간에 수정할 때

8. Plan Mode — `/plan`

무엇인가?

Plan Mode는 바로 코드를 수정하지 않고 먼저

문제 분석
↓
관련 코드 조사
↓
변경 범위 판단
↓
구현 방법 설계
↓
실행 계획 작성

을 하도록 만드는 기능입니다.

/plan을 사용하면 Codex가 구현을 시작하기 전에 실행 계획을 제안하도록 할 수 있습니다.

사용법

/plan

또는 바로 요청을 붙일 수도 있습니다.

/plan 인증 시스템을 JWT에서 Session 기반으로 변경하는 계획을 만들어줘

그 다음 Plan을 검토하고 수정할 수 있습니다.

DB Migration 없이 가능한 방식으로 계획을 수정해줘.

계획이 마음에 들면 구현을 요청하면 됩니다.

언제 사용하는 것이 좋을까?

특히 다음 작업에서는 바로 구현시키기보다 Plan Mode를 사용하는 것이 좋습니다.

대규모 리팩터링
DB Migration
인증 구조 변경
여러 서비스에 영향을 주는 작업
요구사항이 애매한 작업
실패했을 때 영향이 큰 작업

9. `/mcp`

MCP란?

MCP는 Model Context Protocol의 약자입니다.

쉽게 말하면 Codex가 외부 도구나 시스템을 사용할 수 있도록 연결하는 인터페이스라고 생각하면 됩니다.

예를 들어 MCP를 통해 Codex가 연결된 도구를 사용할 수 있습니다.

Codex
 ├── 사내 API
 ├── 데이터베이스 도구
 ├── 문서 시스템
 ├── 개발 도구
 └── 기타 MCP Server

사용법

현재 사용할 수 있는 MCP 도구를 확인하려면

/mcp

를 사용합니다.

CLI에서 서버에 대한 자세한 진단 정보까지 보고 싶다면

/mcp verbose

를 사용할 수 있습니다.

MCP 서버 자체를 관리할 때는 CLI의 codex mcp 명령을 사용할 수 있습니다.

예:

codex mcp list

codex mcp get 서버이름

codex mcp remove 서버이름

즉,

/mcp

는 현재 세션에서 사용할 수 있는 MCP 확인,

codex mcp ...

는 MCP 서버 설정 관리

정도로 구분해 생각하면 쉽습니다.

10. Find Skill / Skills

Skill이란?

Skill은 Codex에게 특정 작업 방법을 가르쳐 놓고 반복해서 사용할 수 있도록 만든 재사용 가능한 작업 지침입니다.

예를 들어 팀에서 항상 같은 방식으로 PR을 리뷰한다고 해보겠습니다.

1. 변경사항 분석
2. Breaking Change 검사
3. Security 검사
4. 테스트 누락 검사
5. 결과를 특정 포맷으로 작성

이 과정을 매번 프롬프트로 입력하는 대신 Skill로 만들어 사용할 수 있습니다.

Skill에는 SKILL.md를 중심으로 지침과 참고자료, 필요하면 실행 스크립트까지 포함할 수 있습니다.

Skill 찾기

"find skill"이라는 별도의 공식 Slash Command가 있는 것이라기보다는 현재 Codex에서는 다음 방법으로 Skill을 탐색하고 사용할 수 있습니다.

/skills

CLI나 IDE에서는 $를 입력해 Skill을 직접 호출할 수도 있습니다.

예:

$plan

또는

$skill-creator

Skill 만들기

$skill-creator

를 사용하면 새로운 Skill을 만드는 과정을 도와줍니다.

Skill 설치하기

로컬 Codex에서 추가 Skill을 설치할 때는

$skill-installer

를 사용할 수 있습니다.

예:

$skill-installer linear

Codex는 Skill 이름과 설명을 보고 필요한 작업에서 Skill을 자동으로 선택할 수도 있습니다.

11. `/status`

무엇인가?

/status는 현재 Codex 세션의 상태를 확인하는 명령입니다.

/status

를 입력하면 환경에 따라 현재 세션과 관련된 정보를 볼 수 있습니다.

예를 들어 CLI에서는 다음과 같은 정보를 확인하는 데 사용할 수 있습니다.

현재 모델
Context 사용량
Approval 설정
Writable Root
세션 설정

데스크톱 환경에서는 Chat ID, Context 사용량, Rate Limit 등의 상태를 확인할 수 있습니다.

언제 사용하면 좋을까?

특히 긴 Codex 작업에서는 중간중간 확인하는 것이 좋습니다.

/status

로 Context가 많이 사용되었다면

/compact

를 고려하는 식입니다.

실전에서는 어떻게 조합하면 좋을까?

각 기능을 따로 사용하는 것보다 하나의 Workflow로 이해하면 훨씬 쉽습니다.

예를 들어 큰 기능을 개발한다고 가정해보겠습니다.

STEP 1. 메타프롬프팅

먼저 요구사항을 정리합니다.

이 기능을 Codex가 구현하기 좋은 프롬프트로 바꿔줘.
목표, 제약사항, 검증 방법, 완료조건을 포함해줘.

↓

STEP 2. Plan

/plan

Codex가 코드베이스를 조사하고 구현 계획을 작성합니다.

↓

STEP 3. Goal 설정

계획이 확정되면

/goal ...

로 최종 목표와 완료조건을 지정합니다.

OpenAI 역시 복잡한 작업에서는 Plan으로 접근 방법을 정한 뒤 Goal로 지속적인 결과를 정의하는 패턴을 설명하고 있습니다. Plan은 "어떻게 할 것인가?", Goal은 "무엇이 되어야 완료인가?"를 담당한다고 보면 됩니다.

↓

STEP 4. Worktree

다른 작업과 충돌할 가능성이 있다면

/worktree

로 독립된 작업 공간에서 실행합니다.

↓

STEP 5. Steering

Codex가 작업하다 잘못된 방향으로 가면 바로 추가 지시합니다.

기존 API 인터페이스는 절대 변경하지 마.

↓

STEP 6. Review

개발이 끝나면

/review

↓

STEP 7. Context 관리

대화가 너무 길어졌다면

/status

확인 후

/compact

↓

최종적으로 테스트와 리뷰를 통과하면 작업을 종료합니다.

정리

Codex를 단순히

코드를 만들어주는 AI

라고 생각하면 기능의 일부만 사용하는 셈입니다.

실제로는 다음과 같은 Agent 작업 관리 도구에 더 가깝습니다.

메타프롬프팅
        ↓
      /plan
        ↓
      /goal
        ↓
   Worktree
        ↓
 Codex 작업 실행
        ↓
    Steering
        ↓
     /review
        ↓
 /status + /compact
        ↓
       완료

그리고 반복적으로 사용하는 작업 방식은

Skills

로 만들고,

외부 시스템이나 도구가 필요하다면

MCP

를 연결할 수 있습니다.

특히 개인적으로 먼저 익히기 좋은 기능을 뽑는다면 다음 순서를 추천합니다.

/plan
/review
Steering
/compact
Worktree
/fork
/goal
Skills
MCP

이 정도만 익혀도 Codex를 단순한 코드 생성 AI가 아니라 여러 개발 작업을 계획하고 실행하고 검증하는 Agent로 활용하기 훨씬 쉬워집니다.

CHZEE93

치즈 키우는 사람

이전 포스트

OpenAI Codex 주요 기능 11가지 정리

AI개발

메타프롬프팅부터 Worktree, /review, /goal, Plan Mode까지

한눈에 보기

1. 메타프롬프팅(Meta Prompting)

무엇인가?

사용 예시

언제 좋을까?

2. Worktree

무엇인가?

사용법

언제 좋을까?

3. /review

무엇인가?

사용법

활용 흐름

4. /fork

무엇인가?

사용법

언제 좋을까?

5. /compact

무엇인가?

사용법

언제 사용하면 좋을까?

6. /goal — 목표와 완료 조건 설정

무엇인가?

좋은 Goal의 구성

Goal을 메타프롬프팅으로 만들기

7. Steering

무엇인가?

Steer와 Queue의 차이

언제 좋을까?

8. Plan Mode — /plan

무엇인가?

사용법

언제 사용하는 것이 좋을까?

9. /mcp

MCP란?

사용법

10. Find Skill / Skills

Skill이란?

Skill 찾기

Skill 만들기

Skill 설치하기

11. /status

무엇인가?

언제 사용하면 좋을까?

실전에서는 어떻게 조합하면 좋을까?

STEP 1. 메타프롬프팅

STEP 2. Plan

STEP 3. Goal 설정

STEP 4. Worktree

STEP 5. Steering

STEP 6. Review

STEP 7. Context 관리

정리

맘에 드는 AI 그림체 프롬프트 저장

0개의 댓글

메타프롬프팅부터 Worktree, `/review`, `/goal`, Plan Mode까지

3. `/review`

4. `/fork`

5. `/compact`

6. `/goal` — 목표와 완료 조건 설정

8. Plan Mode — `/plan`

9. `/mcp`

11. `/status`