코덱스(Codex) 18가지 필수 기능 완전 정복
📺 원본 영상: 코덱스 18가지 필수 기능 12분 정리 🎙️ 채널: 코드팩토리 📅 정리 일자: 2026-05-28 ⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료(차트, 코드, 슬라이드 등)는 포함되지 않을 수 있습니다.
개요
OpenAI의 Codex는 Claude Code와 함께 최근 개발자들 사이에서 급속도로 사용자가 늘고 있는 AI 코딩 에이전트다. 단순히 코드를 생성하는 수준을 넘어, Git 워크트리 관리·장기 목표 기반 실행·플랜 모드·메모리 설정 등 개발 워크플로우 전반을 자동화하는 방향으로 진화하고 있다. 이 리포트는 코드팩토리 채널이 정리한 Codex의 18가지 핵심 기능을 단순 나열이 아닌, 실무 활용 맥락에서 분류하고 해설한다.
프롬프트를 더 잘 쓰는 법: 메타 프롬프팅(Meta Prompting)
많은 개발자들이 AI 코딩 도구를 쓰면서 “어떻게 프롬프트를 작성해야 할지 모르겠다”는 막막함을 느낀다. Codex는 이 문제를 매우 실용적인 방식으로 해결한다. 바로 “이 프로젝트를 잘 디버깅할 수 있는 프롬프트를 만들어줘”처럼, 프롬프트 자체의 작성을 AI에게 맡기는 메타 프롬프팅(Meta Prompting) 방식이다.
이 접근이 강력한 이유는 AI가 프로젝트 맥락을 이미 이해하고 있기 때문에, 인간이 즉흥적으로 작성하는 프롬프트보다 훨씬 구조화되고 완성도 높은 프롬프트를 생성할 수 있다는 점에 있다. 강연자에 따르면, 생성된 프롬프트를 그대로 복사하여 새 세션에 붙여넣고 실행하면 훨씬 정밀한 디버깅이 가능하다고 한다. 특히 뒤에서 소개할 Goal 모드와 결합할 때 메타 프롬프팅의 효과가 극대화된다는 점도 강조하고 있다.
00:25 - 메타 프롬프팅으로 생성된 디버깅 프롬프트 결과 화면
독립된 작업 공간: 워크트리(Worktree)와 포크(Fork)
워크트리(Worktree): 메인 브랜치를 건드리지 않는 작업 환경
Git 워크트리(Worktree)는 이미 Git 사용자라면 익숙한 개념이지만, Codex 내에서 워크트리를 직접 생성하고 관리할 수 있다는 점이 핵심이다. Codex UI 하단에서 프로젝트와 Git 저장소를 연결한 뒤 컴퓨터 아이콘을 통해 메인 브랜치에서 작업하거나 새로운 워크트리를 생성할 수 있으며, 환경 설정과 브랜치를 선택하여 어떤 커밋 시점부터 워크트리를 시작할지 결정할 수 있다.
01:12 - 워크트리 생성 후 왼쪽 사이드바에 워크트리 아이콘이 표시된 화면
워크트리를 생성하면 이후 실행되는 모든 작업은 원본 저장소에 직접 반영되지 않고, 완전히 격리된 복사 공간 안에서 이루어진다. 이 구조 덕분에 실험적인 기능을 구현하거나 파괴적인 변경을 시도할 때도 메인 브랜치가 안전하게 보호된다. 작업이 완료된 후 “메인 브랜치에 Merge해줘”라고 요청하면 변경 사항이 원본 저장소로 통합되며 워크트리는 삭제된다.
실무적으로 중요한 설정이 하나 있다. 워크트리는 기본적으로 아직 커밋되지 않은(uncommitted) 파일을 가져오지 않기 때문에, .env 파일과 같은 환경 변수나 포트 설정 등은 수동으로 워크트리 환경에 넣어 주어야 한다. 강연자는 이 작업을 워크트리 세팅 시 반드시 처리해야 쾌적한 환경에서 작업할 수 있다고 강조한다.
포크(Fork): 하나의 대화에서 두 갈래의 시도
포크 기능은 현재 진행 중인 대화 맥락을 유지하면서, 동일한 출발점에서 두 가지 다른 방향의 작업을 병렬로 시도하고 싶을 때 사용한다. 예를 들어 같은 로직을 두 가지 다른 방식으로 구현하거나, 동일한 UI를 서로 다른 스타일로 만들어 비교할 때 적합하다. 포크를 실행하면 기존 대화의 모든 컨텍스트가 그대로 유지된 채로 새로운 독립 대화가 생성되며, 두 대화는 서로에게 어떤 영향도 주지 않는다. 강연자에 따르면 포킹은 워크트리 기반 또는 로컬 환경 양쪽 모두에서 실행 가능하며, 무한하게 반복할 수 있다.
코드 품질을 높이는 리뷰 자동화: /review 커맨드
Codex의 /review 커맨드는 단순히 “코드 리뷰해줘”라고 요청하는 것보다 훨씬 체계적이고 포괄적인(comprehensive) 리뷰를 제공한다. 커맨드를 입력하면 탭(Tab) 메뉴에서 두 가지 옵션이 제시된다. 첫 번째는 베이스 브랜치와 현재 브랜치를 비교하는 diff 기반 리뷰이고, 두 번째는 아직 커밋하지 않은 변경 사항을 대상으로 하는 인라인 리뷰다.
02:28 - /review 커맨드 실행 후 오른쪽 패널에 코드 위치와 리뷰 코멘트가 표시된 화면
리뷰가 완료되면 오른쪽 패널에 어느 파일의 어느 위치에 어떤 문제가 있는지, 그리고 실제 코멘트까지 작성되어 나타난다. 강연자는 리뷰를 확인한 후 수정이 필요하면 그 자리에서 “고쳐줘”라고 요청하면 된다고 설명한다. 이름 자체가 “Review”인 만큼 일반 요청보다 더 심층적으로 검토해 주기 때문에, 머지(Merge) 전에 이 커맨드를 습관적으로 실행하는 것을 강연자는 강력히 권장한다.
컨텍스트 관리: Compact와 Auto Compact
Codex를 장시간 사용하다 보면 컨텍스트 윈도우(Context Window)가 점차 채워지게 된다. 이때 /compact 커맨드를 실행하면 대화 이력을 압축하여 컨텍스트 크기를 줄일 수 있다. 강연자는 이를 “사람이 세월이 흘러 어릴 때 기억 중 중요한 것만 남기는 것”에 비유한다. 8살 때의 기억이 자연스럽게 희미해지는 것처럼, Compact는 모든 대화를 기억하는 대신 핵심적인 맥락만 유지하며 나머지를 정리한다.
Compact 진행 중에는 Codex를 사용할 수 없으며, 완료되면 context compacted라는 메시지와 함께 확보된 컨텍스트 공간이 표시된다. 이 기능의 자동화 버전인 Auto Compact도 존재하는데, 컨텍스트가 한계에 가까워지면 시스템이 자동으로 압축을 수행한다. 커맨드를 사용하지 않을 경우에는 Usage 메뉴에서 직접 Compact를 선택하여 실행할 수도 있다.
목표 지향 자율 실행: Goal 모드와 Steering
Goal 모드: 목표가 달성될 때까지 멈추지 않는 에이전트
Goal 모드는 Codex의 가장 강력한 기능 중 하나로, 일반 프롬프팅과 근본적으로 다른 방식으로 동작한다. 일반 프롬프팅에서는 에이전트가 몇 번의 턴(turn)이 지나면 자동으로 멈추지만, Goal 모드에서는 설정한 목표가 달성될 때까지 작업을 지속한다. 몇 시간, 심지어 며칠에 걸친 작업도 가능하다는 점에서, 대규모 리팩터링이나 장기적인 기능 구현에 특히 적합하다. 강연자가 예시로 든 것처럼 “무한 리팩터링”과 같은 작업이 가장 전형적인 활용 사례다.
05:43 - Goal 모드 실행 중 pursuing goal 상태 표시 화면
Goal을 설정할 때는 두 가지 요소가 필수적이다. 첫째는 목표(Objective), 즉 무엇을 이루어야 하는가이고, 둘째는 완료 조건(Completion Criteria), 즉 어떤 상태가 되었을 때 작업이 끝났다고 볼 것인가이다. 이 두 요소를 명확하게 정의해야 에이전트가 언제 멈춰야 할지 알 수 있고, 어떤 결과물을 만들어야 하는지도 방향이 잡힌다. 강연자는 Goal 모드의 프롬프트 작성에도 앞서 설명한 메타 프롬프팅을 활용하도록 권장한다. /goal을 입력한 뒤 “이 프로젝트를 디버깅하는 Goal을 설정하는 프롬프트를 만들어줘”처럼 요청하면, Codex가 해당 목표에 최적화된 Goal 프롬프트를 자동으로 생성해 준다.
일반 프롬프팅과 또 다른 중요한 차이점은 오류 처리 방식이다. 일반 프롬프팅에서는 작업이 막히면 에이전트가 즉시 사용자에게 돌아와 해결을 요청하는 반면, Goal 모드에서는 막히더라도 스스로 반복적으로 문제를 해결하려 시도하고, 정말로 해결이 불가능한 경우에만 Blocked 상태로 사용자에게 개입을 요청한다.
Steering: 진행 중인 작업의 방향을 즉시 수정
Goal 모드처럼 장시간 실행되는 작업에서는 중간에 방향을 수정하고 싶어질 수 있다. 일반적으로 프롬프트를 입력하면 현재 Goal이 끝난 후 대기열(queue)에 들어가 순서를 기다리지만, Steer 버튼을 사용하면 진행 중인 Goal에 즉시 반영된다는 점이 핵심이다. 예를 들어 전체 프로젝트 디버깅이 진행 중인 상황에서 “Next.js 프로젝트만 디버깅해줘”라고 입력하고 Steer를 누르면, 현재 실행 중인 Goal의 범위가 즉시 Next.js 프로젝트로 좁혀지며, 강연자에 따르면 이 시점에서 “범위를 앱스/웹/Next.js 프로젝트로 좁히겠다”는 메시지가 출력에 함께 나타난다.
계획 먼저, 실행은 나중: 플랜 모드(Plan Mode)
💡 STT 교정 안내: 트랜스크립트에서 “플랫모드”로 기록된 부분은 문맥상 “플랜 모드(Plan Mode)“의 STT 오인식입니다.
플랜 모드(Plan Mode)는 작업을 바로 실행하는 대신, 목표를 달성하기 위한 계획을 먼저 수립하게 하는 모드다. + 버튼을 누르거나 /planning을 입력하여 활성화할 수 있다. 예를 들어 “라이트 모드 구현해줘”라는 요청을 플랜 모드 없이 실행하면 바로 코드를 작성하지만, 플랜 모드를 켠 상태에서 실행하면 어떤 파일을 수정하고 어떤 순서로 작업할지에 대한 계획이 먼저 마크다운(Markdown) 형태로 출력된다.
07:51 - 플랜 모드(Plan Mode) 결과가 마크다운 형태로 출력된 화면
계획 결과를 확인한 후 마음에 들지 않는 부분이 있다면 수정 요청을 입력하고, 최종적으로 계획이 확정되면 “Yes, Implement This Plan” 버튼을 눌러 실제 구현을 시작할 수 있다. 강연자에 따르면, 이 계획-실행 분리 방식이 개발자의 의도와 일치하는 방향으로 작업을 유도하는 가장 효과적인 방법 중 하나다. 단순히 실행부터 하는 것보다 계획을 거쳐 작업하면 불필요한 수정 사이클을 크게 줄일 수 있기 때문에, 적극적으로 활용할 것을 권장한다.
확장성과 멀티태스킹: MCP, Find Skill, Side 대화
MCP 커맨드와 Find Skill
/mcp 커맨드를 실행하면 현재 활성화(enabled)된 MCP(Model Context Protocol) 서버들의 목록을 한눈에 확인할 수 있다. MCP는 Codex가 외부 도구나 서비스와 연동할 수 있도록 해주는 프로토콜로, 이를 통해 Codex의 활용 범위를 크게 확장할 수 있다. Find Skill 기능은 다른 사용자들이 공개한 스킬(Skill)들을 검색하는 기능이다. 예를 들어 “디버깅 관련 스킬 찾아줘”라고 요청하면 활용 가능한 스킬들을 목록으로 정리해 주는데, 커뮤니티 기반의 스킬 생태계를 적극 활용할 수 있다는 점에서 실용적인 기능이다.
Side 대화: 메인 컨텍스트를 오염시키지 않는 보조 창
/side 커맨드를 실행하면 화면 오른쪽에 새로운 독립 대화 창이 열린다. 이 사이드 대화의 특징은 메인 대화의 컨텍스트에 아무런 영향을 미치지 않는다는 점이다. 단순히 새로운 창을 여는 것과 다른 이유는, 사이드 대화가 현재까지의 대화 내용을 인식하고 있다는 것에 있다. 즉, 메인 대화에서 진행 중인 작업에 영향을 주지 않으면서도 현재 상황을 이해하는 별도 공간에서 추가 질문을 하거나 새로운 방향을 탐색할 수 있다. 강연자는 이를 “메인 대화를 더욱 풍부하게 이어나가도록 돕는 보조 수단”으로 설명했다.
개인화와 사용자 경험 설정
Memory(메모리): AI가 나를 기억하는 방식을 제어하기
/memories 커맨드를 통해 Codex의 메모리 기능을 세밀하게 제어할 수 있다. Codex는 대화 중 사용자에 대한 정보(직업, 선호도, 작업 방식 등)를 학습하고 이후 대화에 반영하는 메모리 기능을 갖추고 있다. 이 기능이 불필요하거나 프라이버시가 우려된다면 “Use Memories” 옵션을 비활성화하면 된다. 메모리 설정은 대화(Conversation) 단위로 관리할 수 있으며, “Generate Memories” 옵션을 통해 중요한 내용이 있을 때마다 메모리를 업데이트할지 여부를 제어할 수 있다.
09:26 - Memory 커맨드 실행 후 Use Memories 및 Generate Memories 설정 화면
중요한 제약 사항이 하나 있는데, 이미 시작된 대화에서는 메모리 사용 여부를 더 이상 변경할 수 없다는 점이다. 따라서 메모리를 쓸지 말지는 대화를 시작하기 전에 미리 결정해 두어야 한다.
Personality(퍼스낼리티): 대화 스타일 조정
Personality 설정은 Codex의 응답 스타일을 변경하는 옵션으로, 기본값은 Pragmatic(실용적) 스타일이다. Friendly 스타일로 변경하면 훨씬 친근하고 감성적인 방식으로 대화해 준다. 강연자 본인은 개인적으로 사용하지 않는 옵션이라고 솔직하게 밝혔다.
Pet: 현재 파업 중
Pet 기능은 귀여운 마스코트가 등장하는 것으로 알려진 기능이지만, 강연자가 영상을 촬영하던 시점에는 정상 작동하지 않았다. 강연자는 이를 유머러스하게 “파업 중”이라고 표현했다.
성능 최적화 설정: Model, Fast Mode, Reasoning
Model 선택과 Fast Mode
/model 커맨드 또는 UI 오른쪽 하단의 선택 메뉴를 통해 Codex에서 사용할 모델을 자유롭게 선택할 수 있다. Fast Mode는 추가 비용을 지불하는 대신 훨씬 빠른 응답 속도를 제공하는 옵션으로, 강연자는 사용량(Usage)이 충분할 때는 Fast Mode를 켜두고 사용량이 줄어들 때 꺼서 아끼는 전략을 권장한다. 강연자의 체감으로는 1.5배 이상의 속도 향상이 있을 때도 있다고 했으며, “시간도 돈”이라는 논리로 Fast Mode의 가치를 긍정적으로 평가했다.
Reasoning: 생각의 깊이를 설정하기
Reasoning 설정은 AI가 답변을 생성하기 전에 얼마나 깊이 추론(reasoning)할지를 결정한다. Low, Medium, High, Extra High의 네 단계가 있으며, 레벨이 높을수록 더 많은 내부 추론 과정을 거친다. 강연자에 따르면 가장 기본적인 원리는, 프롬프트에 대한 답변을 다시 AI에게 입력하여 더 깊이 생각하게 하고, 그 결과를 또 다시 입력하는 순환 과정을 반복하는 것이다. 이 반복의 횟수와 깊이가 Reasoning 레벨에 따라 달라지는 것이며, 각 LLM 회사들이 세부 구현 방식에서 저마다 다른 방식으로 차별화를 꾀하고 있다고 강연자는 설명했다.
사용 현황 모니터링: Status
/status 커맨드 또는 UI의 Status 토글을 통해 현재 사용량과 처리 속도를 실시간으로 확인할 수 있다. 얼마나 많은 사용량을 소비했는지, 그리고 현재 초당 몇 토큰(Tokens per Second)의 속도로 처리되고 있는지를 한눈에 볼 수 있다. 강연자에 따르면 이 기능을 어디서 확인하는지 묻는 사람들이 많다고 하며, 처음에는 위치를 찾기 어려울 수 있으니 Status 토글의 존재를 기억해 두는 것이 좋다.
11:58 - /status 토글 활성화 후 사용량과 Tokens per Second가 표시된 화면
마무리: Codex를 제대로 활용하기 위한 핵심 관점
Codex의 18가지 기능을 통해 알 수 있는 것은, 이 도구가 단순한 코드 생성기를 넘어 **자율적으로 목표를 추구하는 에이전트(Agent)**로 설계되었다는 점이다. 메타 프롬프팅과 Goal 모드의 결합은 개발자가 프롬프트 작성에 소비하는 시간과 에너지를 최소화하면서 최대의 결과를 끌어낼 수 있는 구조를 제공하고, 워크트리와 포크 기능은 실험적인 작업을 안전하게 격리하여 메인 코드베이스를 보호한다. 플랜 모드는 실행 전에 계획을 검토하는 기회를 줌으로써 의도치 않은 방향으로 작업이 흘러가는 것을 방지하며, Steering은 장시간 작업 중에도 방향을 즉시 수정할 수 있는 유연성을 제공한다.
강연자가 영상 말미에 강조했듯이, 설정 관련 잡다한 작업들은 직접 손으로 처리하지 말고 AI에게 프롬프팅으로 맡기는 것이 Codex를 가장 효율적으로 활용하는 방법이다. 도구를 제대로 이해하고 나면 어떤 기능에서 인간의 개입이 필요하고 어떤 작업은 완전히 자동화할 수 있는지가 명확해지는데, 이 영상은 그 이해를 높이는 데 좋은 출발점이 된다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | 코덱스 18가지 필수 기능 12분 정리 |
| 채널 | 코드팩토리 |
| 영상 길이 | 약 12분 |
| 리포트 작성 | 2026-05-28 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.