개발 도구 가이드

터미널 코딩 에이전트 Codex CLI,
꼭 알아야 할 18가지 기능

채팅으로 코드를 받아 적는 단계를 넘어, 이제는 명령줄에서 직접 코드를 읽고 고치고 검증하는 코딩 에이전트가 일상 도구가 되었다. 기본 사용법만 알면 절반만 쓰는 셈이다. 자율 작업·병렬 작업·문맥 관리까지, 생산성을 가르는 핵심 기능 18가지를 개념부터 정리한다.

OpenAI(오픈에이아이)의 Codex(코덱스)는 코드를 작성하고 버그를 고치는 AI 에이전트로, 2025년 4월 명령줄 도구(Codex CLI, Command Line Interface, 명령줄 인터페이스)로 처음 공개되었다. 2026년 3월 기준 주간 활성 사용자가 200만 명을 넘었고, 웹·명령줄·전용 데스크톱 앱(윈도우/맥)·여러 통합개발환경(IDE, Integrated Development Environment) 확장으로 쓸 수 있다. 이 글은 명령줄 버전을 기준으로 하되, 데스크톱 앱에서도 거의 동일하게 적용되는 기능들을 다룬다.

아래 기능들은 크게 일곱 갈래로 묶을 수 있다. 차례대로 따라가면 단순 채팅 사용에서 벗어나, 에이전트에게 일을 맡기고 결과를 통제하는 작업 흐름이 잡힌다.

1부. AI와 제대로 대화하기

같은 모델이라도 입력을 어떻게 구성하느냐에 따라 결과가 갈린다.

01 메타프롬프팅 — 프롬프트를 AI에게 맡기기

"AI에게 무엇을 어떻게 시켜야 할지 모르겠다"는 고민은 흔하다. 해법은 단순하다. 좋은 지시문을 만드는 일 자체를 AI에게 시키면 된다. 예를 들어 "이 프로젝트를 체계적으로 디버깅하기 위한 프롬프트를 작성해 줘"라고 요청하면, 에이전트는 프로젝트 구조를 살펴 적합한 점검 항목과 단계가 담긴 지시문을 만들어 준다.

이렇게 얻은 지시문을 새 세션에 그대로 붙여 넣고 실행하면, 처음부터 막연하게 시작하는 것보다 훨씬 정돈된 작업을 끌어낼 수 있다. 사람이 프롬프트 작성법을 따로 익히는 대신, 모델이 가진 작업 이해도를 프롬프트 설계 단계에서 한 번 더 활용하는 방식이다.

02 플랜 모드 — 짓기 전에 설계도부터

"다크 모드 만들어 줘"처럼 막연히 지시하면 에이전트는 곧장 코드를 고치기 시작한다. 작은 작업이면 괜찮지만, 여러 파일을 건드리는 변경에서는 의도와 어긋난 결과가 나오기 쉽다. 플랜 모드는 이 순서를 뒤집는다. /plan을 입력하면 에이전트는 곧바로 손대는 대신, 목표 달성에 필요한 단계를 먼저 계획으로 정리해 마크다운 형태로 보여 준다.

계획에서 마음에 들지 않는 부분이 있으면 "이 단계는 빼고, 저 부분은 이렇게 바꿔 달라"고 수정 요청을 넣을 수 있다. 계획이 다듬어진 뒤 실행 버튼을 누르면 그 계획을 기준으로 작업이 진행된다. 진행 중에는 /plan을 다시 쓸 수 없으므로, 계획 검토는 작업 시작 전에 끝내는 것이 원칙이다.

03 스티어링 — 달리는 작업의 방향 틀기

장시간 작업을 돌리다 보면 "어, 이건 내가 원한 방향이 아닌데" 싶은 순간이 온다. 이때 두 가지 선택지가 있다. 작업이 진행되는 중에 새 지시를 입력하고 그대로 두면 그 지시는 대기열(큐)에 들어가 현재 작업이 끝난 뒤 실행된다. 반대로 스티어링을 쓰면 지금 진행 중인 작업에 곧바로 지시가 끼어들어 방향이 바뀐다.

명령줄에서는 작업이 도는 동안 Enter로 지시를 현재 턴에 즉시 주입하고, Tab으로 다음 턴에 실행할 지시를 예약하는 식으로 둘을 구분한다. 예컨대 전체 프로젝트를 디버깅하던 중 "범위를 특정 하위 프로젝트로 좁혀라"고 스티어링하면, 멈췄다가 다시 시작할 필요 없이 작업이 그 자리에서 좁혀진다.

2부. 여러 갈래로 동시에 일하기

하나의 시도가 다른 시도를 망치지 않도록 작업 공간을 분리한다.

04 워크트리 — 독립된 복사본에서 실험하기

의외로 잘 쓰이지 않지만 효과가 큰 기능이다. 워크트리(worktree)는 깃(Git)의 기능을 활용해, 같은 저장소에서 서로 충돌하지 않는 독립된 작업 복사본을 만든다. 워크트리 안에서 에이전트가 하는 모든 작업은 원래 저장소에 곧바로 반영되지 않고, 격리된 공간 안에서만 이뤄진다.

워크트리를 쓸 때 한 가지 주의할 점이 있다. 워크트리는 기본적으로 아직 커밋되지 않은 파일을 가져오지 않는다. 따라서 환경 변수 설정 파일이나 실행에 꼭 필요한 포트 설정처럼 저장소에 커밋되지 않은 항목들은 새 워크트리로 직접 복사해 넣어야 한다. 이 환경 설정을 워크트리별로 미리 맞춰 두면, 훨씬 쾌적하게 병렬 작업을 돌릴 수 있다.

05 포크 — 대화를 통째로 복제해 두 갈래 시도

워크트리가 코드 공간을 가른다면, 포크(fork)는 대화 자체를 가른다. /fork를 실행하면 지금까지의 대화 맥락이 그대로 유지된 채, 새로운 식별자를 가진 별도의 대화로 복제된다. 원본 대화는 손대지 않은 채 남아 있어, 같은 출발점에서 서로 다른 두 방향을 동시에 시도할 수 있다.

로직을 두 가지 버전으로 짜 보거나, 화면 구성을 A안과 B안으로 나눠 비교할 때 특히 유용하다. 포크한 대화에서 "프로젝트를 분석해 줘"라고 하면, 포크 이전까지 쌓인 맥락을 모두 기억한 상태로 작업이 이어진다. 포크는 횟수 제한 없이 반복할 수 있어, 한 지점에서 여러 갈래로 뻗어 나가며 가지치기하듯 탐색할 수 있다.

06 사이드 — 본 대화를 흐트러뜨리지 않는 곁가지 질문

작업 도중 잠깐 곁다리로 물어볼 일이 생긴다. "이 에러가 무슨 뜻이지?", "지금 계획의 위험 요소가 뭐지?" 같은 질문이다. 이런 걸 본 대화에 그대로 던지면 핵심 작업의 맥락이 곁가지로 어수선해진다. 사이드(side)는 이 문제를 푼다. /side를 실행하면 본 대화와 독립된 임시 대화가 열린다.

흥미로운 점은, 이 곁가지 대화가 본 대화의 맥락을 읽을 수는 있다는 것이다. "지금까지 무슨 작업을 하고 있었지?"라고 물으면 정확히 답한다. 즉 새 창을 따로 여는 것과 달리, 본 작업의 문맥을 참고하면서도 그 질문·답변이 본 대화의 문맥을 오염시키지는 않는다. 본 대화를 깔끔하게 유지하면서 필요한 정보만 곁에서 얻을 수 있다. 다만 사이드나 리뷰 안에서 사이드를 또 여는 식의 중첩은 지원하지 않는다.

3부. 며칠씩 혼자 일하게 만들기

목표 단위로 묶어, 끝날 때까지 멈추지 않게 한다.

07 골 모드 — 목표 달성까지 스스로 반복

일반 프롬프트는 몇 번의 주고받음(턴)이 지나면 자동으로 멈춘다. 골 모드(goal mode)는 다르다. /goal 뒤에 목표를 적으면, 에이전트는 그 목표가 달성될 때까지 계획·실행·테스트·검토·재시도의 순환을 스스로 반복한다. 몇 시간, 길게는 며칠 단위의 작업도 사람이 옆에서 지켜보지 않은 채 굴릴 수 있다.

골 모드의 효과는 목표를 어떻게 적느냐에 달려 있다. 핵심은 목표와 완료 조건을 함께 명시하는 것이다. "마이그레이션을 끝내되 테스트를 모두 통과시켜라"처럼 적으면, 에이전트는 언제 작업이 끝났다고 판단할지 명확한 기준을 갖는다. 완료 조건이 모호하면 끝없이 변경만 쌓일 수 있다. 목표는 비워 둘 수 없고, 길이에도 상한이 있다. 한번 설정한 목표는 /goal pause로 멈추고, /goal resume으로 재개하고, /goal clear로 해제한다.

일반 작업과의 결정적 차이는 막혔을 때의 태도다. 보통은 작은 장애물에도 에이전트가 "이거 해결해 달라"며 사람에게 돌아온다. 골 모드에서는 막히더라도 스스로 우회로를 찾아 반복 시도하고, 정말 도저히 안 될 때만 막힘 상태로 돌아와 도움을 청한다. 무한 리팩터링처럼 "방향은 정해졌고 손이 많이 가는" 작업에 잘 맞는다.

참고로 골 모드는 실험적 기능으로 분류되어 있어, 환경에 따라 설정 파일에서 기능을 켜야 목록에 나타난다. 메타프롬프팅(01번)과 결합하면 효과가 더 좋다. "이 목표에 맞는 골 모드용 지시문을 만들어 줘"라고 먼저 시키면, 에이전트가 목표 구조를 이해한 상태에서 완료 조건이 잘 짜인 지시문을 만들어 준다.

4부. 코드 품질을 지키는 장치

합치기 전에 한 번 더 거르는 전용 검토 단계.

08 리뷰 — 합치기 전 전용 검토

작업을 끝낸 뒤 곧장 합치기 전에, /review로 전용 검토를 돌리는 습관을 들이면 좋다. 그냥 "검토해 줘"라고 부탁하는 것보다, 리뷰 명령은 변경 부분을 더 꼼꼼하고 체계적으로 살핀다. 검토 전용 에이전트가 선택한 변경 묶음을 읽고, 작업 트리는 건드리지 않은 채 우선순위가 매겨진 문제점을 짚어 준다.

리뷰는 몇 가지 방식 중에서 고를 수 있다. 기준 브랜치와 비교해 합치기 전 위험을 짚는 방식, 아직 커밋하지 않은 변경 전체를 점검하는 방식, 특정 커밋 하나를 지정해 그 변경만 읽게 하는 방식, 그리고 "접근성 문제에 집중해 줘"처럼 직접 적은 지시로 검토하는 방식이다. 문제 위치와 함께 구체적인 코멘트가 달리므로, 고치고 싶은 부분을 그대로 짚어 수정을 요청할 수 있다.

5부. 기억을 다루는 법

에이전트가 한 번에 떠올릴 수 있는 양에는 한계가 있다.

09 콤팩트 — 문맥을 압축해 여유 확보

대화가 길어지면 에이전트가 다룰 수 있는 정보량(컨텍스트)이 차오른다. 콤팩트(compact)는 지금까지의 대화를 요약해 차지하는 용량을 줄인다. /compact를 입력하면 진행되던 내용이 핵심 위주로 압축되고, 그만큼 새 작업에 쓸 여유가 생긴다.

콤팩트가 진행되는 동안에는 잠시 입력을 할 수 없고, 끝나면 압축이 완료되었다는 표시와 함께 확보된 여유가 보인다. 별도의 자동 방식인 오토 콤팩트도 있다. 컨텍스트가 한계에 가까워지면 알아서 압축이 일어나는데, 한계를 넘을 수는 없으니 시스템이 스스로 정리하는 셈이다. 명령어 대신 사용량 화면에서 콤팩트를 눌러 실행할 수도 있다.

다만 압축에는 비용이 따른다. 요약 과정에서 사소하지만 나중에 필요한 세부가 사라질 수 있으므로, 한 가지 문제에 집중하는 대화라면 무리하게 잘게 쪼개기보다 한 흐름을 유지하는 편이 추론의 맥락을 보존하는 데 유리하다.

10 메모리 — 세션을 넘어 기억할지 정하기

콤팩트가 한 대화 안의 용량을 다룬다면, 메모리(memory)는 대화를 넘어선 기억을 다룬다. 메모리를 켜면 에이전트는 과거 대화에서 중요했던 내용, 사용자의 직업·작업 맥락 같은 정보를 기억해 두었다가 이후 응답에 반영한다. 매번 같은 배경을 설명하지 않아도 되는 대신, 기억이 끼어드는 것을 원치 않는 작업도 있다.

그래서 메모리는 대화별로 켜고 끌 수 있게 되어 있다. 기억을 활용할지(use memory), 그리고 중요한 내용이 생길 때마다 새 기억으로 적어 둘지(generate memory)를 각각 설정한다. 한 가지 제약은, 이미 시작한 대화에서는 메모리 사용 여부를 도중에 바꿀 수 없다는 점이다. 기억 없이 깔끔하게 시작하고 싶다면 새 대화를 열 때 정해 두는 것이 안전하다.

6부. 모델과 사고 깊이 조절

같은 작업도 어떤 모델로, 얼마나 깊게 생각하게 하느냐로 결과와 비용이 갈린다.

11 모델 선택 — 작업에 맞는 두뇌 고르기

/model로 작업 중에도 모델을 바꿀 수 있고, 명령줄을 띄울 때 옵션으로 지정할 수도 있다. 일상적인 코딩에는 코딩에 최적화된 표준 모델이 권장되며, 복잡한 아키텍처 설계나 까다로운 디버깅에는 더 강력한 추론 모델을 고르는 식으로 쓴다. 간단한 수정에 가장 무거운 모델을 쓰는 것은 비용과 시간 낭비이고, 반대로 어려운 문제에 가벼운 모델을 쓰면 수정 횟수가 늘어난다.

12 추론 레벨 — 얼마나 깊게 생각하게 할까

모델이 답을 내기 전에 "얼마나 깊이 따져 보게 할지"를 정하는 설정이다. 보통 낮음·중간·높음·매우 높음(low·medium·high·xhigh) 단계로 나뉜다.

간단한 오타 수정에는 낮은 단계로 충분하고, 인증 모듈 재설계처럼 분기와 예외가 많은 작업에는 높은 단계가 유리하다. 정답은 없으며 작업 종류와 취향에 따라 무엇이 잘 맞는지 직접 시험해 보는 편이 좋다.

13 패스트 모드 — 시간을 돈으로 사기

유료 구독에서는 처리 속도 자체를 끌어올리는 패스트 모드(fast mode)를 쓸 수 있다. 같은 작업을 더 빠르게 받아 보는 대신 사용량을 더 소모하는 방식이다. 사용량 여유가 넉넉할 때는 켜 두고 빠르게 진행하고, 여유가 줄어들면 일반 속도로 천천히 쓰는 식으로 운영하면 한도를 효율적으로 관리할 수 있다.

7부. 도구 확장과 상태 점검

에이전트의 능력을 넓히고, 지금 상태를 들여다보는 도구들.

14 MCP — 외부 도구와 연결하기

/mcp를 입력하면 현재 연결된 외부 도구 목록을 볼 수 있다.

15 스킬 탐색 — 남이 만든 작업 묶음 찾아 쓰기

스킬(skill)은 특정 작업을 잘 처리하도록 미리 묶어 둔 지시·절차 모음이다. 공개된 스킬을 찾아 활용할 수 있는데, 예컨대 "디버깅 관련 스킬을 찾아 줘"라고 요청하면 쓸 만한 스킬들을 정리해 준다. 팀이 만들어 공유한 스킬을 탐색해 가져다 쓰는 것도 가능하다. 매번 같은 절차를 손으로 적는 대신, 검증된 작업 묶음을 재사용하는 셈이다.

16 퍼스널리티 — 응답 말투 고르기

/personality로 에이전트의 응답 성향을 바꾼다. 기본은 군더더기 없이 실용적으로 답하는 성향(pragmatic)이고, 더 친근하고 살가운 말투(friendly)나 성향 지정을 끄는 선택(none)도 있다. 작업 결과 자체보다는 대화 경험에 영향을 주는 설정이라, 취향에 맞게 고르면 된다. 모델이 성향별 지시를 지원하지 않으면 이 명령은 목록에 나타나지 않는다.

17 스테이터스 — 지금 상태 한눈에 보기

"내가 지금 어떤 모델로, 어떤 권한으로, 사용량을 얼마나 쓰고 있는지" 헷갈릴 때가 있다. /status를 쓰면 현재 모델·권한·컨텍스트 상태와 사용량, 진행 속도 같은 정보를 확인할 수 있다. 무엇을 얼마나 썼는지 불확실할 때 가장 먼저 열어 보면 좋은 화면이다.

18 펫 — 소소한 부가 요소

마지막은 기능이라기보다 재미 요소다. 일부 버전에는 작업을 거드는 작은 캐릭터 같은 부가 요소가 들어 있는데, 환경이나 시점에 따라 동작하지 않을 수도 있다. 생산성과는 무관하니 가볍게 알아 두는 정도면 충분하다.

정리하며

이 18가지를 다시 묶으면 결국 네 가지 능력으로 수렴한다. 첫째, 입력을 설계하는 힘(메타프롬프팅·플랜 모드). 둘째, 작업을 안전하게 나누는 힘(워크트리·포크·사이드). 셋째, 자율과 통제의 균형(골 모드·스티어링·리뷰). 넷째, 자원을 관리하는 힘(콤팩트·메모리·모델·추론·속도)이다.

기본 채팅만 쓰면 에이전트는 "코드를 적어 주는 도구"에 머문다. 위 기능들을 손에 익히면 비로소 "일을 맡기고 결과를 통제하는 동료"로 바뀐다. 모든 걸 한 번에 쓸 필요는 없다. 플랜 모드와 리뷰부터 습관으로 들이고, 긴 작업이 잦아지면 워크트리와 골 모드로, 비용이 신경 쓰이면 모델·추론·속도 조절로 넓혀 가는 순서를 권한다.