Codex CLI를 처음 보면 “터미널에서 AI가 코드를 고쳐준다”는 점이 먼저 눈에 들어온다. 그런데 실제 개발 루틴에 넣을 때 더 중요한 건 설치 명령보다 운영 방식이다. 어디까지 읽게 할지, 어떤 명령은 직접 승인할지, 비용은 어떤 기준으로 볼지, 실패하면 어디서 멈출지를 미리 정하지 않으면 편한 도구가 금방 불안한 도구가 된다.
OpenAI 도움말은 Codex CLI를 로컬 터미널에서 실행되는 오픈소스 명령줄 도구로 설명한다. 로컬 코드를 읽고, 수정하고, 명령을 실행할 수 있으며, 기본적으로는 사용자가 승인하는 흐름을 둔다. 이 지점 때문에 “AI 코딩 도구”라기보다 “권한을 가진 작업자”처럼 다뤄야 한다.
설치보다 먼저 볼 것은 권한 모드다
공식 도움말 기준으로 Codex CLI에는 크게 세 가지 성격의 승인 흐름이 있다. 기본에 가까운 제안 모드는 파일을 읽고 수정안이나 명령을 제안하지만, 실제 반영 전에는 사용자의 확인을 요구한다. 자동 편집 모드는 파일 수정까지는 더 적극적으로 진행하고, 명령 실행은 여전히 확인을 요구하는 식이다. 더 자동화된 모드는 샌드박스 안에서 읽기, 쓰기, 명령 실행까지 맡길 수 있다.
처음부터 가장 자동화된 흐름으로 시작하는 건 별로 권하고 싶지 않다. 특히 개인 프로젝트가 아니라 회사 코드, 비공개 레포, 배포 키가 섞인 디렉터리라면 더 그렇다. 처음 며칠은 제안 모드로 두고 “이 도구가 어떤 파일을 보려고 하는지, 어떤 명령을 실행하려 하는지”를 보는 편이 낫다.
내가 실제로 붙인다면 이런 순서로 시작한다.
- 낯선 레포 분석: 제안 모드
- 문서 오타, 타입 이름 정리: 자동 편집 모드
- 테스트가 있는 작은 리팩터링: 제한된 디렉터리에서 자동화 모드
- 배포, 인증, 결제, 데이터 삭제 관련 작업: 자동화 모드 금지
여기서 중요한 건 도구를 불신하자는 말이 아니다. AI가 잘못해서라기보다, 로컬 개발 환경은 애초에 위험한 권한이 많이 모인 장소이기 때문이다.
작업 단위는 작게 잡는 편이 안전하다
Codex CLI 같은 도구는 “이 프로젝트 전체를 개선해줘” 같은 요청에도 뭔가를 시도한다. 하지만 이런 요청은 결과가 좋아도 검토가 어렵다. 수정 파일이 많아지고, 왜 바뀌었는지 따라가기 힘들고, 중간에 의도와 다른 방향으로 가도 늦게 알아차린다.
반대로 작업 단위를 좁히면 장점이 커진다.
이 API 응답 타입 이름만 정리해줘. 공개 함수 이름은 바꾸지 말고, 수정 후 관련 테스트만 실행해줘.
이 정도면 Codex가 움직일 수 있는 범위, 건드리면 안 되는 선, 마지막에 확인할 방법이 같이 들어간다. 좋은 AI 코딩 요청은 멋진 프롬프트보다 “작업장 안전선”에 가깝다.
비용은 플랜 이름만 보고 판단하면 안 된다
Codex CLI는 ChatGPT 계정 로그인 흐름과 API 계정 연결 흐름이 같이 언급된다. OpenAI 도움말에는 ChatGPT 계정으로 로그인하는 흐름, API 크레딧, Codex용 모델과 토큰 가격에 대한 설명이 따로 있다. 즉 “Plus를 쓰니까 모든 CLI 사용이 무제한” 같은 식으로 단순화하면 안 된다.
2026년 5월 6일 기준으로는 발행 직전 공식 가격 페이지와 도움말을 다시 보는 것이 안전하다. 가격, 포함량, 모델명은 자주 바뀐다. 특히 팀이나 회사에서 쓰는 경우에는 개인 구독료보다 API 사용량, 워크스페이스 정책, 코드가 어떤 제품 경로로 처리되는지가 더 중요하다.
내 기준은 이렇다.
- 짧은 코드 설명, diff 리뷰: 비용 부담이 낮은 편
- 대형 레포 전체 분석: 토큰 사용량이 빠르게 커질 수 있음
- 반복 테스트와 긴 수정 루프: 시간과 토큰이 같이 늘어남
- 이미지·스크린샷 기반 작업: 편하지만 매번 필요한지 따져볼 것
가격표를 외우는 것보다 “어떤 작업이 비용을 키우는지”를 아는 쪽이 오래 간다.
비공개 정보는 프롬프트에 섞지 않는 게 원칙이다
Codex CLI는 로컬에서 실행되지만, 모델에게 전달되는 프롬프트와 작업 맥락은 서비스 경로를 탄다. 도움말도 코드가 어떻게 다뤄지는지, 어떤 정보가 공유되는지 확인하라고 안내한다. 그래서 API 키, 실서비스 토큰, 고객 데이터, 사내 URL, 아직 공개하지 않은 제품명은 애초에 요청문에 넣지 않는 편이 맞다.
실무적으로는 .env, 인증 파일, 배포 설정, 고객 샘플 데이터가 있는 디렉터리를 조심해야 한다. 레포 루트에서 바로 시작하기보다, 작업할 패키지나 문서 폴더로 들어가서 시작하는 습관도 도움이 된다.
cd packages/web
codex
이런 작은 습관 하나가 검토 범위를 크게 줄인다.
검증 명령은 요청에 같이 넣어야 한다
AI 코딩 도구를 쓰면서 가장 아쉬운 순간은 “수정은 됐는데 맞는지 모르겠다”는 때다. 그래서 요청할 때 마지막 확인 방법을 같이 주는 편이 좋다.
수정 후 npm test와 npm run lint를 실행하고, 실패하면 원인만 요약해줘. 큰 구조 변경은 하지 마.
테스트가 없다면 더 좁혀야 한다. 예를 들어 문서 수정은 빌드만 확인하고, 타입 수정은 타입체크까지만 확인하는 식이다. 검증 없는 자동 수정은 속도는 빠르지만 신뢰가 쌓이지 않는다.
GitHub Copilot과 비교할 때의 관점
GitHub Copilot coding agent 쪽은 이슈와 GitHub 작업 흐름 안에서 움직이는 느낌이 강하다. Codex CLI는 로컬 터미널에서 바로 파일과 명령을 다룬다는 점이 다르다. 둘 중 하나가 무조건 낫다기보다, 어디서 일하게 할지가 다르다.
내가 보기에는 이런 구분이 자연스럽다.
| 상황 | 더 자연스러운 방향 |
|---|---|
| 로컬에서 빠르게 원인 찾기 | Codex CLI |
| GitHub 이슈 기반 작업 위임 | Copilot coding agent |
| 비공개 파일이 많은 실험 | 승인 모드의 Codex CLI |
| 팀 단위 리뷰 흐름 | GitHub 중심 도구 |
도구 비교를 승패로 보면 금방 얕아진다. 실제로는 “어떤 권한 경계에서 일하게 할 것인가”가 더 큰 차이다.
내가 정한 결론
Codex CLI는 개발자가 매일 쓰는 터미널에 AI 코딩 에이전트를 붙이는 방식이라 매력적이다. 하지만 로컬 파일 수정과 명령 실행이 가능한 도구인 만큼, 처음부터 많이 맡기기보다 권한과 검증 흐름을 먼저 정하는 편이 낫다.
내가 오늘 새 프로젝트에 붙인다면 이렇게 시작할 것 같다.
- Git으로 변경 사항을 바로 볼 수 있는 상태에서만 실행
- 처음은 제안 모드로 시작
- 작업 범위는 한 디렉터리나 한 기능으로 제한
- API 키와 배포 설정 파일은 요청에 넣지 않음
- 수정 후 실행할 명령을 요청문에 명시
- 결과가 애매하면 자동으로 더 진행하지 말고 멈추게 함
Codex CLI의 가치는 “AI가 알아서 다 한다”보다 “내가 정한 안전한 범위 안에서 반복 작업을 빠르게 밀어준다”에 있다. 이 선을 정해두면 도구를 더 과감하게 써도 불안이 줄어든다.
참고한 자료
'개발자 정보' 카테고리의 다른 글
| GitHub MCP Server Secret Scanning GA: AI 코딩 에이전트에서 비밀키 유출 막기 (0) | 2026.05.08 |
|---|---|
| Ubuntu 26.04 LTS 개인 서버, 지금 바로 올릴까 조금 기다릴까 (0) | 2026.05.07 |
| 리튬 배터리팩을 직접 만질 때 먼저 봐야 하는 것들 (0) | 2026.05.05 |
| Codex CLI의 /goal, AI 코딩이 ‘한 번 시키는 작업’에서 벗어나기 시작했다 (0) | 2026.05.03 |
| 라즈베리파이5 AI Kit와 AI HAT+ 2, 로컬 LLM과 비전 AI는 어디까지 될까 (1) | 2026.05.03 |