Codex CLI가 빈 결과를 돌려줄 때 확인할 것들

빈 결과는 먼저 세 갈래로 나눠 본다

Codex CLI가 아무 말 없이 빈 결과를 돌려주면, 처음부터 “모델이 이상한가?”로 가면 오래 헤맨다. 내 경우에는 먼저 프롬프트가 비어 보였는지, 실행 위치가 틀렸는지, 아니면 인증이나 네트워크가 조용히 막힌 건지를 나눠 봐야 했다.

제일 먼저 현재 위치부터 본다.

pwd

여기서 내가 생각한 프로젝트 폴더가 아니면, Codex가 엉뚱한 곳을 보고 있었을 가능성이 있다. 빈 출력처럼 보여도 사실은 읽을 파일이 없거나, 내가 기대한 컨텍스트가 안 들어간 상태일 수 있다.

CLI 자체가 살아 있는지 본다

명령이 뜨는지부터 확인한다. 버전이 나오면 적어도 설치된 바이너리는 잡힌 상태다.

codex --version

도움말도 한 번 본다.

codex --help

여기서 exec, login, doctor 같은 하위 명령이 보이면 기본 설치는 살아 있다. 반대로 여기서부터 이상하면 글의 범위가 “빈 결과 디버깅”이 아니라 설치 문제로 넘어간다.

로그인은 API key부터 떠올리지 않는다

Codex CLI는 일반 사용 흐름에서는 ChatGPT 로그인, 그러니까 OAuth 기반 로그인을 먼저 보는 쪽이 자연스럽다. 내 경우에도 빈 결과가 나오면 API key를 새로 넣기보다, 지금 CLI가 어떤 로그인 상태인지부터 확인하는 편이 덜 꼬였다.

codex login status

정상이라면 ChatGPT로 로그인되어 있다는 식의 상태가 나온다. 여기서 로그인이 풀려 있거나 다른 계정처럼 보이면, 그때 로그인 흐름을 다시 타면 된다.

API key는 별개로 OpenAI API를 직접 호출하거나, CLI 사용과 API 호출 방식을 비교하는 글에서 다루는 게 맞다. 일반적인 Codex CLI 설치, 로그인, 초기 점검 글에서 API key 명령부터 꺼내면 초점이 흐려진다.

`exec`가 조용할 때는 프롬프트 전달 방식을 의심한다

대화형 Codex와 codex exec는 느낌이 다르다. 대화형 세션에서는 내가 중간에 설명을 덧붙일 수 있지만, exec는 한 번에 던진 입력이 거의 전부다. 그래서 빈 결과가 나오면 “Codex가 못 했다”보다 “내가 뭘 넘겼지?”를 먼저 봐야 한다.

exec가 어떤 입력 방식을 받는지는 도움말에서 바로 확인할 수 있다.

codex exec --help

여기서 볼 부분은 프롬프트를 인자로 받을 수 있고, -나 파이프 입력을 통해 stdin도 읽을 수 있다는 점이다. 처음엔 이게 별것 아닌 것처럼 보이는데, 자동화로 묶기 시작하면 여기서 많이 헷갈린다.

예를 들면 이런 식이다.

의심 지점	보는 방법
프롬프트가 비어 있었나	쉘 변수나 파이프 입력이 실제로 값이 있는지 먼저 확인한다
작업 폴더가 달랐나	pwd로 현재 위치를 본다
exec 옵션을 잘못 붙였나	codex exec --help로 옵션 위치를 다시 본다
인증은 되어 있나	codex login status를 본다
네트워크나 런타임이 막혔나	codex doctor로 나눠 본다

여기서 헷갈렸던 건, 빈 출력이 항상 같은 원인처럼 보인다는 점이다. 프롬프트가 빈 경우도 조용하고, 네트워크가 막힌 경우도 조용하고, 내가 다른 폴더에서 실행한 경우도 결과만 보면 그냥 “아무것도 안 했네”처럼 보인다.

`doctor`는 한 번에 많이 보여주지만, 다 고치라는 뜻은 아니다

상태를 넓게 보고 싶을 때는 doctor가 편하다.

codex doctor --summary --ascii

이 명령은 설치, 설정, 인증, 네트워크 같은 걸 한 번에 훑는다. 다만 여기서 경고가 나온다고 전부 지금 문제의 원인이라고 보면 안 된다. 빈 결과를 보고 있다면 먼저 auth, connectivity, reachability 쪽을 본다.

내 경우에는 인증은 되어 있는데 네트워크 쪽이 막혀 있는 식으로 갈라진 적이 있었다. 이러면 codex login을 다시 해도 문제는 그대로다. 로그인 문제가 아니기 때문이다.

대화형 세션과 `exec`를 같은 기준으로 보면 헷갈린다

대화형 세션은 중간에 “아, 그 파일 말고 이 파일”이라고 고칠 수 있다. 그래서 첫 입력이 조금 부족해도 이어서 수습이 된다. 반대로 codex exec는 자동화에 좋지만, 처음 넘기는 문장이 부실하면 결과도 부실해진다.

대충 나누면 이렇다.

상황	더 편한 쪽
여러 번 설명하면서 방향을 잡아야 한다	대화형 세션
같은 작업을 반복해서 돌린다	codex exec
결과를 스크립트나 CI에 붙인다	codex exec
원인 분리가 아직 안 됐다	대화형 세션
프롬프트가 이미 확정되어 있다	codex exec

처음엔 기능 이름으로 고르려고 했다. 그런데 실제로는 “이 작업이 한 번에 끝나는가, 중간 대화가 필요한가”를 보면 더 빨리 정해진다.

빈 결과를 보면 이 순서로 줄인다

나는 이제 빈 출력이 나오면 아래 순서로 본다.

1. 지금 폴더가 맞는지 본다.
2. CLI가 정상 설치되어 있는지 본다.
3. 로그인 상태를 본다.
4. exec에 실제 프롬프트가 들어갔는지 본다.
5. doctor로 네트워크와 런타임 문제를 본다.

이 순서가 좋은 이유는 간단하다. 앞쪽은 빠르고, 내 실수일 가능성이 높다. 뒤쪽으로 갈수록 환경 문제에 가깝다. 처음부터 로그인이나 모델 탓으로 가면, 실제로는 폴더 하나 잘못 들어가 있었던 걸 한참 뒤에야 발견한다.