Codex CLI 승인 설정, 모델과 WSL 맞추기

2026-06-03

Codex CLI 사용법은 설치보다 운영 기준을 먼저 잡아야 덜 헷갈립니다

Codex CLI 사용법을 찾는 사람은 보통 설치 화면까지는 이미 넘긴 경우가 많습니다. 막히는 지점은 그다음입니다. 승인 범위를 어디까지 둘지, ChatGPT 로그인으로 들어갈지 API key를 쓸지, model을 기본값으로 둘지 gpt-5.5로 고정할지, Windows에서는 PowerShell과 WSL 중 어디를 주 작업장으로 잡을지에서 흐름이 멈춥니다. 이 선택을 초반에 정해두면 같은 문제를 다시 되풀이할 가능성이 줄어듭니다.

특히 개인 사용자와 팀 사용자는 시작 기준이 다릅니다. 개인은 이미 쓰고 있는 구독 흐름 안에서 편하게 이어가고 싶어 하고, 팀은 비용 구분과 자동화 연결을 먼저 봅니다. 같은 Codex를 쓰더라도 인증 방식과 과금 경로가 다르면 운영 방식도 달라집니다. 그래서 설치 명령 하나만 보고 끝내기보다, 처음에 기준선을 정해두는 편이 훨씬 실용적입니다.

Step 1: 로그인 방식은 편의보다 과금 기준으로 고르기

처음 실행했을 때 브라우저 로그인 흐름으로 들어간다면 자연스럽게 ChatGPT 로그인부터 떠올리게 됩니다. 개인이 데스크톱에서 바로 작업을 이어갈 목적이라면 이 경로가 단순합니다. 반대로 프로젝트별 비용 분리, 서버 작업, 자동화 스크립트, CI/CD 연결이 필요하다면 API key 방식이 더 잘 맞습니다. 둘 중 하나가 더 상위 개념이라기보다 돈이 청구되는 방식과 세션을 다루는 기준이 다르다고 보는 편이 정확합니다.

여기서 먼저 봐야 할 것은 누구 기준으로 비용이 잡히는가입니다. ChatGPT 로그인은 구독 흐름과 연결되고, API key는 OpenAI Platform 사용량 기준으로 이어집니다. 그래서 Codex CLI 사용법을 정리할 때 설치 다음 단계로 인증 방식을 먼저 고르는 게 맞습니다. 나중에 자동화까지 붙일 생각인데 로그인 흐름으로만 시작하면 다시 손보는 일이 생기기 쉽습니다.

브라우저 로그인 창이 반복해서 뜨지 않는다면 기존 세션 정보가 남아 있을 수 있습니다. 반대로 회사 환경에서 인증이 자주 끊긴다면 개인 설정만 볼 일이 아니라 조직 보안 정책이나 브라우저 제한도 함께 점검해야 합니다. 이 구간은 화면이 비슷해 보여도 실제 원인은 꽤 다르게 나옵니다.

Step 2: 승인 설정은 낮게 시작하고 필요할 때 올리기

승인 방식은 처음부터 넓게 열어두는 것보다 작업 성격에 맞춰 단계적으로 올리는 편이 다루기 쉽습니다. Codex CLI에서는 보통 Auto, Read-only, Full Access 같은 선택지를 보게 되는데, 파일 읽기와 가벼운 수정이 중심이면 Auto만으로도 충분한 경우가 많습니다. 코드 구조를 먼저 훑거나 문서 검토가 핵심이면 Read-only가 부담이 적습니다.

Auto는 작업 폴더 안에서 읽기, 수정, 명령 실행을 진행하다가 범위가 커지거나 민감한 작업으로 넘어갈 때 확인을 요구하는 흐름입니다. 일상적인 수정, 테스트 실행, 리뷰라면 이 단계가 가장 무난합니다. Read-only는 안전하지만 실제 수정으로 넘어갈 때 한 번 더 단계를 바꿔야 합니다. Full Access는 반복 확인 없이 밀고 갈 수 있지만, 작업 범위와 영향도를 알고 있을 때 쓰는 편이 맞습니다.

중요한 건 승인 단계를 성격에 맞게 쓰는 것입니다. 익숙한 프로젝트에서는 속도를 우선할 수 있지만, 처음 보는 오픈소스나 외부 스크립트가 섞인 폴더에서는 넓은 권한이 바로 편리함으로 이어지지 않습니다. 권한을 줄였다가 올리는 쪽이, 반대로 시작했다가 범위를 되돌리는 것보다 실수가 적습니다.

Step 3: model은 세션마다 흔들리지 않게 기준을 정해두기

여러 파일을 함께 수정하거나 리뷰와 검증이 길게 이어지는 작업에서는 gpt-5.5를 먼저 떠올리는 사람이 많습니다. 긴 흐름을 붙잡아야 하는 작업에서는 이런 선택이 잘 맞을 때가 있습니다. 반대로 짧은 확인, 간단한 탐색, 작은 수정이 중심이라면 현재 기본 모델이 더 가볍게 느껴질 수 있습니다. 핵심은 매번 느낌으로 바꾸기보다, 자주 하는 작업에 맞는 기본선을 정해두는 것입니다.

기본 모델은 CLI 버전이나 현재 설정에 따라 다르게 보일 수 있습니다. 어제는 답이 짧았는데 오늘은 계획이 길어지고, 어떤 날은 수정 범위가 과하게 넓어진다면 model 기준이 흔들리고 있을 가능성이 있습니다. 이런 때는 세션 시작부터 직접 고정하는 편이 낫습니다. 반대로 빠르게 확인만 끝내고 싶은 시간에는 기본값으로 내려서 확인용 세션과 작업용 세션을 나누는 방식도 깔끔합니다.

Codex CLI 사용법을 익히는 초반에는 프롬프트 문장보다 model 고정이 더 큰 차이를 만들기도 합니다. 같은 요청을 넣어도 세션 성격이 달라지면 결과 밀도와 수정 스타일이 바뀌기 때문입니다. 그래서 자주 하는 일 기준으로 하나를 먼저 정하고, 예외 상황에서만 바꾸는 쪽이 운영하기 편합니다.

Step 4: Windows에서는 native와 WSL을 역할별로 나누기

Windows에서 많이 헷갈리는 부분은 PowerShell로 바로 돌릴지, WSL2 안에서 리눅스 도구 체인으로 갈지입니다. 여기서는 한쪽만 정답처럼 볼 필요가 없습니다. PowerShell 스크립트, Windows 앱 연동, 로컬 폴더 중심 작업은 native가 자연스럽습니다. 셸 스크립트, 리눅스 패키지, 경로 규칙이 민감한 프로젝트는 WSL이 더 잘 맞습니다.

WSL 안으로 들어갔을 때 경로가 /home/...로 이어지면 리눅스 쪽을 기준으로 작업하는 상태입니다. 반대로 /mnt/c/...에서만 계속 움직이면 파일 접근은 되더라도 권한이나 속도에서 자잘한 불편이 생길 수 있습니다. Windows 개발이라고 해서 무조건 WSL이 필요한 것은 아니지만, 사용하는 도구가 리눅스 중심이라면 처음부터 역할을 나눠두는 편이 훨씬 덜 복잡합니다.

여기서 자주 생기는 오해는 설치만 하면 끝난다는 생각입니다. 실제로는 어떤 프로젝트를 어디에서 열 것인지가 더 중요합니다. 프론트엔드나 파이썬 작업은 native에서도 충분히 잘 돌아갈 수 있지만, bash 기반 스크립트와 리눅스 의존 패키지가 많은 환경에서는 WSL 쪽이 관리가 쉽습니다.

Step 5: auth.json은 일반 설정 파일처럼 다루면 곤란합니다

Codex는 인증 상태를 유지하기 위해 로컬에 세션 정보를 남길 수 있습니다. 운영체제의 credential store를 쓰기도 하고, 파일 기반이면 ~/.codex/auth.json 같은 경로에 남을 수 있습니다. 이름만 보면 설정 파일처럼 보이지만 성격은 로그인 정보에 더 가깝습니다. 그래서 다른 설정 파일과 같은 감각으로 복사하거나 공유하면 문제가 커질 수 있습니다.

개인 PC에서는 무심코 지나가기 쉬운 부분이지만, 팀 노트북이나 원격 환경에서는 기준이 달라야 합니다. 채팅창에 붙여 넣거나 버전 관리에 섞이는 순간 계정 이슈로 이어질 수 있습니다. 승인 방식과 model만 보고 넘어가기보다, 인증 정보가 어디에 남는지도 함께 확인해야 운영이 깔끔해집니다.

Codex CLI 사용법에서 먼저 맞춰야 할 것은 화려한 프롬프트가 아닙니다. 로그인 방식, 승인 단계, model 기준, Windows에서 native와 WSL을 어떻게 나눌지 이 네 가지입니다. 이 기준이 잡혀 있으면 설치 뒤에 바로 흔들리던 구간이 눈에 띄게 줄어들고, 나중에 자동화나 팀 작업으로 넘어갈 때도 다시 처음부터 정리할 일이 적습니다.