책에 포함된 노트요즘 바이브 코딩: Codex로 일하는 개발자의 완전 가이드

PART 02-6. 슬래시 명령어와 키보드 단축키

2026-04-25Views 238약 11분생성형 AI 활용

Chapter 06. 슬래시 명령어와 키보드 단축키

Codex를 처음 쓰면 모델 성능부터 보게 된다. 하지만 며칠만 지나면 진짜 생산성을 가르는 것은 모델보다 조작법이라는 걸 알게 된다. 같은 Codex를 써도 어떤 사람은 한 시간 동안 헤매고, 어떤 사람은 10분 만에 버그를 고치고 테스트까지 끝낸다. 차이는 대개 거창한 프롬프트가 아니라 /model, /compact, /fork, /resume 같은 명령어를 얼마나 자연스럽게 쓰느냐에 있다.

이 장의 목표는 단순하다. 자주 쓰는 명령어 몇 개와 손에 붙는 단축키 몇 개만 확실히 익히는 것이다. 그러면 Codex가 "신기한 채팅 도구"에서 "통제 가능한 작업 파트너"로 바뀐다.

Codex의 슬래시 명령어는 대화창을 벗어나지 않고 세션, 모델, 권한, 리뷰 흐름을 제어하게 해 준다. 지원되는 명령은 클라이언트와 권한에 따라 달라질 수 있지만, 기본적으로 대화 입력창에서 /를 입력해 목록을 열고 바로 실행하는 방식이다. 또한 Skills는 대화창에서 $로 명시적으로 호출할 수 있다.¹

PART 02-6. 슬래시 명령어와 키보드 단축키

왜 슬래시 명령어가 중요한가

보통 초보자는 이렇게 쓴다.

"지금부터 더 빠르게 해줘." "컨텍스트가 너무 길어진 것 같아." "아까 하던 작업 다시 이어서 해줘."

이런 말도 Codex가 어느 정도 알아듣긴 한다. 하지만 내장 명령어가 있는 작업은 자연어보다 명령어가 훨씬 정확하고 빠르다. /compact는 그냥 요약해 달라는 요청이 아니라, 세션 컨텍스트를 압축해 다음 작업을 계속할 수 있게 만드는 전용 동작이다. /resume은 "아까 하던 거 이어서"보다 훨씬 정확하게 이전 세션을 복원한다. /fork는 "여기서 다른 방법도 해보자"를 안전하게 분기한다.

쉽게 말해 자연어가 회의라면, 슬래시 명령어는 단축키다. 둘 다 일을 하지만, 속도와 실수율이 다르다.

먼저 익힐 6개만 정하자

이 장에서 가장 먼저 몸에 익힐 명령어는 다음 여섯 가지다.

/model
/compact
/agent
/fork
/skills
/resume

여기에 실전 효율을 크게 올려 주는 보조 명령으로 /status, /diff, /review, /permissions를 함께 익히면 된다. 다 외울 필요는 없다. 많이 쓰는 것부터 손에 익히면 된다.

`/model`: 똑똑함과 속도의 기어를 바꾸는 명령

/model은 현재 세션에서 사용할 모델과 추론 강도(reasoning effort)를 바꾸는 명령이다.² 이 명령을 잘 쓰면 "왜 이렇게 느리지?"와 "왜 이렇게 대충하지?" 사이를 오가며 짜증 낼 일이 크게 줄어든다.

예를 들어 Next.js + Supabase 프로젝트에서 로그인 버그 하나만 고칠 때는 무거운 모델과 높은 추론 강도가 과할 수 있다. 반대로 인증 흐름 전체를 재설계하거나 RLS 정책, SSR, 미들웨어까지 한꺼번에 건드리는 작업이라면 가벼운 모델로는 자꾸 얕은 답이 나올 수 있다.

실무에서는 이렇게 생각하면 편하다.

상황	권장 선택
오타 수정, 작은 UI 수정, lint 정리	빠른 모델 + 낮은 추론
버그 원인 분석, 테스트 실패 추적	중간급 모델 + 중간 추론
다중 파일 리팩터링, 아키텍처 변경	강한 모델 + 높은 추론

가장 흔한 실수는 처음부터 무조건 가장 센 모델을 고정하는 것이다. 그러면 응답 속도가 느려지고, 사소한 수정에도 지나치게 큰 설계를 들고오기도 한다. 반대로 너무 가벼운 모델만 고집하면 "맞는 말 같은데 실제 코드는 안 되는" 결과가 늘어난다.

실전 감각으로 정리하면 이렇다.

Next.js 화면의 버튼 정렬이 깨졌다면 /model로 빠른 쪽으로 내리고 바로 수정하게 한다. 반면 Supabase 인증 리다이렉트 루프처럼 원인이 여러 레이어에 걸칠 수 있는 문제는 모델을 올리고 "먼저 원인 가설 3개를 제시한 뒤 가장 가능성 높은 순서로 확인"하라고 주는 편이 낫다.

`/compact`: 긴 대화를 다시 가볍게 만드는 압축 버튼

Codex를 오래 쓰다 보면 대화가 길어진다. 처음엔 버그 하나만 보려 했는데, 테스트를 돌리고, 로그를 보고, 다른 파일을 열고, 또 수정하다 보면 세션은 금방 무거워진다. 이때 필요한 게 /compact다. 공식 문서와 실무 자료가 공통으로 설명하듯, 이 명령은 중요한 맥락을 남기면서 대화를 요약해 토큰 공간을 확보하는 역할을 한다.³⁴

초보자는 보통 컨텍스트가 길어질수록 "이제 Codex가 점점 멍청해진다"고 느낀다. 사실 멍청해졌다기보다, 중요한 맥락과 덜 중요한 대화가 한데 섞여 세션 효율이 떨어진 경우가 많다. /compact는 책상을 한 번 치우는 행동에 가깝다.

언제 쓰면 좋을까. 감으로는 세 가지 순간이 있다.

한 문제를 오래 붙잡아 대화가 길어졌을 때
이미 결정한 내용이 많은데, 이제 구현만 남았을 때
응답이 느려지거나 앞서 합의한 제약을 자꾸 놓칠 때

예를 들어 Express + MongoDB 백엔드에서 회원가입 버그를 잡다가 다음 순서로 흘렀다고 해 보자. 에러 로그 확인, 인덱스 문제 확인, DTO 검증 수정, 테스트 추가, Postman 시나리오 점검까지 갔다면 이미 세션은 꽤 길어졌을 것이다. 이때 /compact를 한 번 해 두면, Codex는 "현재 목표, 이미 확인한 원인, 남은 TODO" 중심으로 대화를 압축하고 이후 턴을 더 효율적으로 이어간다.

중요한 점은 /compact가 만능 저장 버튼은 아니라는 것이다. 아주 세부적인 중간 사고과정이나 덜 중요한 부가 대화는 사라질 수 있다. 그래서 압축 전에 다음처럼 한 줄을 던지는 습관이 좋다.

"압축 전에 현재 결정사항, 금지사항, 남은 작업을 짧게 정리해줘."

그러면 압축 후에도 핵심 제약이 더 잘 살아남는다.

`/fork`: 같은 대화에서 안전하게 평행우주 만들기

/fork는 현재 대화를 복제해 새로운 스레드로 분기하는 명령이다.⁵ 이 기능을 이해하는 순간 Codex 사용 습관이 확 달라진다. 이전에는 한 세션 안에서 "그럼 아까 방식 말고 다른 방법도 해보자"를 반복하다가 문맥이 꼬이기 쉬웠다. 이제는 분기하면 된다.

/fork가 특히 좋은 순간은 이런 때다.

첫째, 해결 방향이 둘 이상일 때다. 예를 들어 Next.js + Supabase 프로젝트에서 인증 문제를 미들웨어에서 막을지, 서버 액션 구조를 손볼지 고민될 수 있다. 이때 메인 스레드는 그대로 두고 /fork로 대안을 실험하면 된다.

둘째, 리뷰용과 구현용을 나누고 싶을 때다. 원본 스레드는 분석과 결정 기록용으로 남기고, 포크한 스레드에서는 실제 수정과 테스트만 진행할 수 있다.

셋째, 위험한 변경을 실험할 때다. 예를 들어 Express API에서 에러 핸들링 체계를 전체 교체하려면 수정 범위가 커지기 쉽다. 이럴 때 메인 스레드는 보수적으로 유지하고, 포크 스레드에서 과감한 안을 탐색하는 편이 좋다.

이 명령은 Git 브랜치와 닮았다. 둘 다 원본을 지키면서 다른 길을 실험하게 해 준다. 차이가 있다면 Git 브랜치는 코드 상태를 나누고, /fork는 대화 문맥과 작업 흐름을 나눈다는 점이다.

`/resume`: 어제의 나를 다시 불러오는 가장 현실적인 방법

Codex는 이전 세션을 저장해 두었다가 다시 열 수 있다. CLI에서는 codex resume이 세션 선택기를 열고, codex resume --last는 가장 최근 세션을 바로 재개한다. 현재 작업 디렉터리 밖의 세션까지 보고 싶다면 --all 옵션을 사용할 수 있다.⁶⁷

대화 중에는 /resume으로 이전 세션을 다시 불러올 수 있다. 이 기능이 왜 중요하냐면, 실제 개발은 한 번에 끝나지 않기 때문이다. 저녁에 버그를 잡다가 퇴근했고, 아침에 다시 이어서 해야 하는 일이 훨씬 많다.

가령 슈퍼앱 클론 프로젝트에서 알림 센터 기능을 만들다가 다음 상태로 끝냈다고 하자.

API 스키마 정리 완료
MongoDB 인덱스 추가 완료
읽음 처리 API 구현 완료
프론트 배지 카운트 계산만 미완료

이런 작업은 다음 날 다시 들어오면 기억이 흐릿해진다. 그런데 /resume으로 세션을 열면 당시 어떤 파일을 봤는지, 어떤 테스트가 실패했는지, 왜 그런 결정을 내렸는지까지 이어서 볼 수 있다. 즉, 회의록을 다시 읽는 시간이 줄어든다.

여기서 좋은 습관이 하나 있다. 세션을 끝내기 전에 Codex에게 "오늘 한 일, 남은 일, 다음 시작 지점"을 10줄 안으로 요약하게 해 두는 것이다. 그러면 /resume의 품질이 체감상 더 좋아진다.

`/agent`: 여러 에이전트를 쓸 때 길을 잃지 않기

Codex는 환경에 따라 하위 에이전트나 병렬 스레드를 다룰 수 있고, /agent는 현재 활성 에이전트 스레드를 전환할 때 쓰인다.⁸ 이 장에서는 깊게 들어가기보다 "언제 필요해지는가"만 확실히 잡아두자. 본격적인 병렬 워크플로는 뒤 챕터에서 더 다룬다.

처음에는 이 명령이 별로 필요 없어 보인다. 혼자 한 스레드에서만 작업하면 되기 때문이다. 하지만 조금만 욕심을 내면 금방 필요해진다. 예를 들어 하나의 작업을 이렇게 나누고 싶을 수 있다.

메인 에이전트는 구현 유지
서브 에이전트 하나는 테스트 실패 원인 분석
또 다른 서브 에이전트는 관련 파일 구조 탐색

이때 /agent로 현재 어떤 에이전트와 대화 중인지 바꾸지 못하면 금방 헷갈린다. 누구에게 어떤 지시를 내렸는지, 어느 쪽이 구현 중인지, 어느 쪽이 조사 중인지 뒤섞인다.

실전에서는 이름 붙여 생각하면 편하다. "메인 구현 담당", "테스트 탐정", "문서 수집 담당"처럼 역할을 머릿속에 붙여 두고 /agent로 전환한다. 멀티탭 브라우저를 잘 쓰는 사람과 비슷한 감각이다.

`/skills`: 자주 하는 일을 프롬프트가 아니라 기능으로 부르기

공식 문서 기준으로 Codex에서는 대화 입력창에서 $를 입력해 Skills를 명시적으로 호출할 수 있다.¹ 일부 환경에서는 /skills나 관련 진입점으로 사용 가능한 스킬을 확인하거나 불러오는 흐름을 제공하기도 한다. 중요한 건 문법 자체보다 사고방식이다. "매번 길게 설명하는 일"을 "이름 붙은 작업 단위"로 바꾸는 것이다.

예를 들어 한국 개발자가 자주 할 만한 작업을 스킬로 만들 수 있다.

PR 리뷰 요약 스킬
Next.js 폴더 구조 설명 스킬
Supabase 마이그레이션 점검 스킬
배포 전 체크리스트 스킬

이렇게 되면 매번 "이 PR을 보고 위험 포인트, 테스트 누락, API 변경 여부, 한국어 릴리즈 노트까지 정리해줘"라고 길게 쓰지 않아도 된다. $pr-review-korean 같은 이름으로 부르면 된다.

슬래시 명령어 장에서 이걸 다루는 이유는 간단하다. 많은 사람이 Skills를 거대한 자동화 프레임워크처럼 오해하는데, 실제 체감은 "자주 쓰는 작업을 빠르게 호출하는 명령어 묶음"에 가깝기 때문이다. 자주 하는 일이 있다면, 명령어와 스킬은 결국 같은 방향을 가리킨다. 반복을 줄이는 쪽이다.

`/status`: 지금 Codex가 어떤 상태인지 확인하는 습관

/status는 현재 세션의 설정과 상태를 보여준다. 보통 활성 모델, 권한 정책, 쓰기 가능한 경로, 토큰 사용량 같은 정보를 확인할 수 있다.⁹

별것 아닌 것 같지만, 실전에서는 꽤 자주 사람을 살린다. 왜냐하면 Codex가 이상한 게 아니라 내가 다른 상태로 실행해 둔 경우가 많기 때문이다. 예를 들어:

왜 파일을 안 고치지? → read-only였다.
왜 계속 승인창이 뜨지? → approval 정책이 보수적이었다.
왜 응답이 느리지? → 무거운 모델과 높은 추론 강도였다.
왜 아까와 다르게 동작하지? → 다른 스레드나 다른 세션이었다.

작업이 꼬인 것 같으면 감으로 추측하지 말고 /status부터 본다. 디버깅의 절반은 상태 확인이다.

`/diff`와 `/review`: 대화보다 결과를 보는 사람으로 바뀌기

Codex를 오래 쓸수록 중요한 것은 "뭘 말했는가"보다 "실제로 뭐가 바뀌었는가"다. /diff는 현재 워킹 트리의 Git 변경사항을 보여주고, 추적되지 않은 파일까지 포함해 확인할 수 있다.⁸¹⁰ /review는 변경사항을 검토해 잠재적 문제나 개선점을 짚어주는 흐름이다.⁸

특히 /review는 자기 코드에 대한 두 번째 시선을 하나 더 붙이는 효과가 있다. 예를 들어 Next.js 앱에서 결제 페이지를 급하게 고쳤다면, 구현 직후 바로 머지하지 말고 /review를 돌려 보자. 의외로 이런 지점을 잘 잡아낸다.

실패 케이스 테스트 누락
타입은 맞지만 런타임에서 깨질 가능성
접근성 속성 누락
에러 메시지 처리의 일관성 문제

이 장의 핵심은 명령어를 많이 아는 것이 아니라, 작업 루프를 바꾸는 것이다. 좋은 루프는 보통 이렇다.

"지시 → 구현 → /diff 확인 → 테스트 → /review → 최종 판단"

이 루프가 자리 잡으면 Codex를 맹신할 가능성이 크게 줄어든다.

`/permissions`: 속도와 안전의 균형을 세션 중간에 조절하기

작업하다 보면 처음엔 읽기만 하다가, 나중엔 수정도 맡기고 싶을 때가 있다. 또는 반대로 처음엔 마음이 커서 다 허용했는데, 막상 불안해져서 권한을 줄이고 싶을 수도 있다. 이때 /permissions가 필요하다.⁸

Codex의 권한은 크게 두 축으로 보면 된다. 하나는 샌드박스 범위다. 파일을 어디까지 읽고 쓸 수 있는지, 네트워크를 쓸 수 있는지 같은 환경 제약이다. 다른 하나는 승인 정책이다. 어떤 행동을 자동으로 진행하고, 어떤 행동은 사람에게 물어볼지 정하는 규칙이다.¹⁰

실무 감각으로는 아래 표 정도만 기억해도 충분하다.

프로파일	의미	언제 쓰나
read-only	읽기 전용, 수정 불가	분석, 코드리뷰, 원인 조사
workspace-write	프로젝트 범위 내 수정 가능	일반적인 버그 수정, 기능 구현
full-access	더 넓은 접근 허용	시스템 설정, 특수 작업, 매우 신중히

여기서 중요한 것은 "빠를수록 좋은 설정"이 아니라 "현재 작업에 맞는 최소 권한"이다. 예를 들어 인증 버그 원인을 찾는 단계에서는 read-only로도 충분하다. 그런데 원인이 확인되어 테스트와 수정이 필요해지면 workspace-write로 올리는 것이 합리적이다. 처음부터 full-access로 들어가는 건 자전거 배우는데 오토바이 헬멧 대신 아무것도 안 쓰는 것과 비슷하다.

승인 정책은 귀찮은 게 아니라 브레이크다

승인 정책은 보통 다음 감각으로 이해하면 쉽다.

untrusted: 안전한 읽기 중심만 자동, 그 외는 자주 묻는다.
on-request: 모델이 필요할 때 승인 요청을 올린다.
never: 묻지 않고 진행한다. 자동화나 통제된 환경에서만 신중히 쓴다.¹⁰

많은 초보자가 승인창을 보고 짜증을 낸다. 하지만 그 승인창은 내 레포와 시스템을 지켜 주는 브레이크다. 특히 실무 레포에서는 rm, 패키지 설치, 외부 네트워크 접근, Git 쓰기 작업 같은 행동이 섞일 수 있다. 잘 모를 때는 귀찮더라도 물어보게 두는 편이 낫다.

키보드 단축키: 마우스를 덜 쓸수록 Codex가 빨라진다

키보드 단축키는 별거 아닌 것 같지만, 실제 생산성은 여기서 크게 갈린다. CLI 기준으로 자주 쓰는 핵심 단축키는 다음과 같다.⁸¹⁰

단축키	의미	실전 용도
`Enter`	메시지 전송, 실행 중엔 즉시 지시 주입	"그 파일은 건드리지 마" 같은 급정정
`Tab`	실행 중 후속 프롬프트 예약	"끝나면 테스트도 돌려줘" 같은 다음 작업 큐잉
`Ctrl+C`	현재 작업 취소	잘못된 방향으로 가는 작업 중단
`Ctrl+D`	세션 종료	작업 마무리
`Ctrl+L`	화면만 지우기	로그가 길어져 터미널이 지저분할 때
`Ctrl+G`	외부 에디터로 프롬프트 편집	긴 지시문, 복잡한 PRD 작성
`Esc` `Esc`	이전 메시지 수정	방금 보낸 프롬프트를 다듬고 싶을 때
`Up/Down`	드래프트 기록 이동	자주 쓰는 요청 재활용

이 중에서 특히 Enter와 Tab의 차이는 꼭 익혀야 한다. Codex가 작업 중일 때 Enter는 현재 턴에 바로 개입하는 것이다. 반면 Tab은 지금 하는 일은 끝까지 하게 두고, 그 다음 턴에 후속 요청을 예약하는 느낌이다.⁸

예를 들어 Codex가 테스트를 돌리고 있을 때 에러 로그를 보며 생각이 바뀌었다고 해 보자.

"아, staging DB를 쓰면 안 되는데."

이건 Enter로 즉시 주입해야 한다. 지금 당장 막아야 하니까. 반대로,

"끝나면 changelog도 업데이트해줘."

이건 Tab으로 큐에 넣는 편이 자연스럽다.

파일 첨부와 로컬 명령 실행: `@`와 `!`의 감각

슬래시 명령어만큼이나 실전에서 자주 쓰는 입력 문법이 있다. @는 파일을 빠르게 찾아 대화에 붙이고, !는 로컬 셸 명령을 직접 실행한다는 개념이다.⁸

예를 들어 @src/app/login/page.tsx처럼 붙이면 Codex가 그 파일을 우선 문맥으로 본다. 레포가 큰데 특정 파일을 정확히 지정하고 싶을 때 아주 유용하다. 특히 "알아서 찾아봐"는 Codex에게도, 사람에게도 비효율적이다.

또 !git log --oneline -5처럼 쓰면 최근 커밋을 바로 확인할 수 있다. 다만 이 출력은 도구적 확인에 가깝지, 항상 자동으로 모델의 장기 문맥이 되는 것은 아니라는 감각을 가져야 한다. 즉, 확인은 빠르지만 설명이 필요하면 다시 대화로 연결해 주는 것이 좋다.

통합 터미널 읽기 기능은 왜 강력한가

Codex의 진짜 무서운 점은 단순히 코드를 쓰는 것이 아니라, 터미널 결과를 보고 다음 행동을 이어갈 수 있다는 데 있다. 테스트 로그, 빌드 실패, lint 오류, 서버 실행 결과를 읽고 수정 방향을 조정하는 루프가 만들어지면 비로소 "대화형 코딩 보조"를 넘어 "작업 에이전트"처럼 느껴진다.

예를 들어 Next.js + Supabase 프로젝트에서 npm run build가 깨졌다고 하자. 사람이면 보통 로그를 읽고, 원인을 추정하고, 파일을 열고, 다시 수정한다. Codex도 비슷하게 움직일 수 있다. 여기서 중요한 것은 내가 명령어를 직접 다 아는 사람이 되는 게 아니라, Codex가 어떤 로그를 읽고 어떤 기준으로 다음 행동을 할지 지시하는 사람으로 바뀌는 것이다.

좋은 프롬프트는 이렇게 짧고 구체적이다.

"빌드를 실행하고, 실패 로그를 근거로 가장 작은 수정만 해. 다른 파일은 건드리지 말고, 수정 후 다시 빌드해."

이런 식으로 주면 Codex는 터미널 읽기와 수정 사이를 꽤 자연스럽게 왕복한다.

음성 입력은 생각보다 개발자 친화적이다

지원되는 앱 환경에서는 음성 입력을 활용해 빠르게 지시를 던질 수 있다. 특히 손은 키보드에 두고, 말로만 의도를 정리할 수 있다는 점이 생각보다 편하다. 긴 프롬프트를 멋지게 말할 필요는 없다. 오히려 짧게 끊어 말하는 편이 좋다.

예를 들어 디자인 시안을 보고 다음처럼 말할 수 있다.

"로그인 모달만 수정해. 배경 레이아웃은 건드리지 마. 버튼 간격 12픽셀 정도로 맞추고 모바일에서도 줄바꿈 안 생기게 해."

음성 입력이 빛나는 순간은 두 가지다. 하나는 브라우저, 에디터, 디자인 시안을 동시에 보고 있어 손이 바쁠 때다. 다른 하나는 지시를 먼저 빠르게 던지고, 세부 제약은 이후 텍스트로 다듬을 때다. 말은 방향을 정하고, 텍스트는 제약을 정확히 박는 용도로 나누면 좋다.

추천 워크플로 1: 버그 수정 루프

실무에서 가장 많이 쓰는 패턴부터 보자. 예시는 Express + MongoDB API의 회원가입 실패 버그다.

먼저 /model로 너무 무겁지 않은 모델을 고른다. 이어서 이렇게 요청한다.

"먼저 원인을 분석하고, 수정은 최소 범위로만 해. 관련 파일과 에러 원인을 설명한 뒤 진행해."

분석이 끝나면 /permissions를 확인해 workspace-write로 올린다. 수정이 시작되면 로그가 길어질 수 있으니 필요하면 Tab으로 "끝나면 테스트도 돌려줘"를 예약한다. 수정 후에는 /diff로 변경 범위를 확인하고, /review로 놓친 부분이 없는지 한 번 더 본다.

대화가 길어졌다면 /compact를 실행한다. 오늘 못 끝냈다면 마무리 전에 "남은 작업 3개로 요약해줘"라고 하고 종료한다. 다음 날 /resume으로 다시 들어가면 된다.

이 루프 하나만 익혀도 Codex 사용 품질이 꽤 올라간다.

추천 워크플로 2: 대안 비교 루프

이번엔 Next.js + Supabase 프로젝트에서 인증 구조를 손보는 상황을 생각해 보자. 이건 단일 정답이 없는 문제라 한 스레드에서 밀어붙이면 엉키기 쉽다.

먼저 메인 스레드에서 /plan 또는 일반 대화로 접근 후보를 정리한다. 예를 들어 미들웨어 중심, 서버 액션 중심, 클라이언트 가드 최소화 같은 선택지가 나올 수 있다. 그다음 /fork로 두 개의 분기 스레드를 만든다.

한 스레드에서는 미들웨어 강화안을 실험하고, 다른 스레드에서는 서버 액션 중심안을 실험한다. 필요하면 /agent로 탐색 중인 에이전트를 바꿔 가며 비교한다. 마지막에는 두 스레드의 결과를 메인으로 가져와 장단점을 비교한 뒤 하나를 선택한다.

이 방식의 장점은 나중에 "왜 이 방향을 골랐는가"를 다시 설명하기 쉬워진다는 점이다. 즉흥적인 대화가 아니라, 비교 가능한 작업 기록이 남는다.

Codex 초보자가 가장 자주 하는 실수

첫 번째 실수는 한 세션에 너무 많은 주제를 섞는 것이다. 결제 버그 보다가 UI 손보고, 갑자기 README 업데이트하고, 다시 테스트 실패를 잡기 시작하면 세션이 혼탁해진다. 이럴 땐 /new나 /fork가 더 낫다.

두 번째 실수는 /compact를 너무 늦게 쓰는 것이다. 세션이 이미 지저분해진 뒤에만 압축하면 손실 체감이 커질 수 있다. 길어진다 싶을 때 미리 쓰는 편이 좋다.

세 번째 실수는 /diff를 안 보는 것이다. Codex가 설명을 잘했다고 해서 변경이 좋은 것은 아니다. 실제 diff가 진실이다.

네 번째 실수는 권한을 감정으로 정하는 것이다. 조급하면 full-access, 불안하면 read-only로 극단을 오간다. 하지만 실제로는 작업 단계에 맞춰 조절하면 된다.

다섯 번째 실수는 /resume을 단순 복구로만 생각하는 것이다. 잘 관리된 세션은 다음 날의 생산성을 저장해 두는 일종의 작업 자산이다.

이 장의 결론: 명령어는 기능이 아니라 작업 습관이다

슬래시 명령어와 단축키를 익힌다는 것은 버튼 이름을 외우는 일이 아니다. 작업의 리듬을 만드는 일이다.

/model은 작업의 기어를 바꾼다. /compact는 세션을 가볍게 만든다. /fork는 안전한 대안을 만든다. /resume은 맥락을 이어 준다. /agent는 병렬 작업을 정리한다. /skills는 반복을 기능으로 바꾼다. 여기에 /status, /diff, /review, /permissions가 붙으면 Codex는 훨씬 빠르면서도 덜 위험한 도구가 된다.