Codex 명령표를 먼저 봐야 하는 이유: 같은 명령도 실행 표면에 따라 달라집니다 | DAKER 커뮤니티
Codex를 쓰다 보면 같은 이름의 명령이 어디서나 그대로 통할 것처럼 느껴질 때가 있습니다. 하지만 ChatGPT 웹, 데스크톱 앱, CLI, IDE 확장은 접근 방식과 실행 맥락이 다르기 때문에, 명령어만 보고 문서를 만들면 금방 어긋나기 쉽습니다.
특히 팀 온보딩 문서나 자동화 스크립트를 정리할 때는 이 차이가 더 크게 드러납니다. 그래서 명령을 외우기 전에 먼저 확인할 것이 있습니다. 바로 그 명령이 어느 실행 표면에서 동작하는지입니다.
중요한 것은 명령 이름보다 그 명령이 어느 표면에서 실행되는지입니다.
Codex 명령표란, Codex 개발자 표면에서 쓸 수 있는 slash command, CLI 하위 명령, 실행 플래그를 표면별로 확인하는 공식 참조입니다.
Codex 명령표를 왜 먼저 열어야 하나요?
Codex 명령표는 ChatGPT 웹, 데스크톱 앱, CLI, IDE 확장에서 같은 명령이 모두 통한다고 가정하지 않게 해 주는 기준표입니다. 공식 문서는 ChatGPT 웹의 composer 명령 메뉴와 Codex CLI·데스크톱 명령 집합이 다르다고 분리합니다. 자동화나 팀 운영 문서를 만들 때 이 차이를 먼저 확인해야 잘못된 명령 안내를 줄일 수 있습니다.
원문에서도 강조하듯, 명령표를 먼저 보는 이유는 더 많은 명령을 익히기 위해서가 아닙니다. 안 되는 표면에서 시간을 쓰지 않기 위해서입니다.
명령표를 보는 목적은 더 많은 명령을 외우는 것이 아니라, 안 되는 표면에서 시간을 쓰지 않는 것입니다.
실행 표면이 바뀌면 무엇이 달라지나요?
ChatGPT 웹에서는 composer 명령 메뉴를 기준으로 움직이고, Codex CLI에서는 하위 명령과 flag를 기준으로 움직입니다. 데스크톱 앱과 IDE 확장도 접근 가능한 명령과 맥락이 다를 수 있으므로, 팀 문서에는 표면을 먼저 적는 것이 좋습니다.
| 상황 | 바로 명령부터 치는 방식 | 명령표 먼저 보는 방식 |
|---|---|---|
| 웹에서 시작 | CLI 명령을 붙여 넣고 막힙니다 | 웹 composer 명령 메뉴 기준으로 가능한 일을 고릅니다 |
| CLI 자동화 | 대화형 명령을 스크립트에 넣습니다 | 하위 명령과 JSON 출력 옵션을 먼저 찾습니다 |
| 팀 문서 | 명령 이름만 남아 재현이 어렵습니다 | 표면, 명령, 기대 결과가 함께 남습니다 |
| 권한 확인 | 실행 후 오류에서 확인합니다 | 실행 전 표면과 위험 조합을 먼저 봅니다 |
실무에서는 어떻게 적용하면 되나요?
명령어를 복사하기 전에 한 번 멈춰서 실패 지점을 줄이는 루틴으로 적용하면 됩니다.
- 지금 요청을 실행할 표면을 먼저 적습니다. ChatGPT 웹, 데스크톱 앱, CLI, IDE 확장, cloud 중 하나로 시작합니다.
- 명령표에서 같은 이름의 slash command, CLI subcommand, flag가 그 표면에 있는지 확인합니다.
- 팀 문서에는 명령어만 쓰지 말고 실행 표면과 기대 결과를 함께 남깁니다.
- 자동화 스크립트에는 대화형 slash command 대신 CLI subcommand나 JSON 출력 옵션을 우선 검토합니다.
- 명령이 없거나 표면이 다르면, 같은 목표를 이루는 다른 공식 흐름으로 바꾼 뒤 완료 기준을 다시 씁니다.
짧은 예시는 어떻게 쓰면 좋을까요?
온보딩 문서에 상태 확인 절차를 넣는다고 가정해 보겠습니다. 이때 명령 이름만 적어 두면 실제 사용자가 어느 환경에서 무엇을 눌러야 하는지 알기 어렵습니다. 데스크톱 앱에서는 composer에서 상태 명령을 찾는다고 쓰고, CLI 자동화에서는 로그인 상태나 작업 목록을 기계가 읽을 수 있는 출력으로 확인한다고 분리해 두는 편이 더 정확합니다.
실수는 어디서 자주 생기나요?
실수는 대개 명령 자체보다 문서화 방식에서 생깁니다. 웹의 명령 메뉴와 CLI 명령표를 같은 것으로 설명하거나, 자동화에 사람이 눌러야 하는 흐름을 그대로 넣는 경우가 대표적입니다.
- ChatGPT 웹 명령 메뉴를 Codex CLI 명령표와 같은 것으로 설명하지 않았나요?
- CLI 기본값이 config 파일에서 오고, 실행 시점 override가 우선한다는 점을 문서에 남겼나요?
- 자동화에는 사람이 눌러야 하는 slash command 대신 기계가 읽을 수 있는 출력 방식을 골랐나요?
- 위험한 조합이나 실험적 옵션을 팀 문서에서 별도 확인 대상으로 표시했나요?
- 게시·배포·삭제처럼 되돌리기 어려운 명령은 권한과 실행 표면을 한 번 더 확인했나요?
참고 자료
기능 사실은 작성 기준일에 OpenAI 공식 공개 문서로 비공개 검증했습니다. 공개 본문에는 DAKER 정책에 맞춰 DAKER 내부 링크만 남깁니다.
자주 묻는 질문
Codex 명령표는 언제 먼저 봐야 하나요?
팀 문서나 자동화 스크립트에 명령어를 넣기 전입니다. 표면이 다르면 같은 이름의 명령도 기대한 방식으로 동작하지 않을 수 있습니다.
ChatGPT 웹에서 Codex CLI 명령을 그대로 쓰면 되나요?
그렇게 가정하지 않는 편이 안전합니다. 공식 문서는 ChatGPT 웹의 composer 명령 메뉴와 Codex CLI 명령 집합을 분리해 설명합니다.
자동화에는 slash command와 CLI 중 무엇이 더 맞나요?
사람이 선택해야 하는 화면 흐름보다 CLI 하위 명령과 기계가 읽을 수 있는 출력이 보통 더 안정적입니다.
명령표를 봐도 기능이 안 보이면 어떻게 하나요?
현재 표면에서 지원하지 않는 기능일 수 있습니다. 다른 Codex 표면이나 공식 워크플로로 목표를 바꿔야 합니다.
오늘 바로 고칠 문서는 무엇인가요?
팀 온보딩 문서의 명령 예시 옆에 실행 표면과 기대 결과를 한 줄씩 붙이는 것부터 시작하면 됩니다.
여러분은 Codex 관련 문서를 정리할 때 명령어보다 실행 표면을 먼저 적고 계신가요?