기술 사용자 중심 사이트인데도, 하나의 서비스가 용도별로 여러 소프트웨어를 제공할 수 있다는 점을 이해하지 못하는 사람이 많아 보임. codex는 OpenAI의 에이전트 실행 환경으로, OpenAI 모델이 내 컴퓨터에서 작업하게 할 때 사용하며 저수준 API 기능을 추상화해 줌. openai-cli는 OpenAI REST API의 저수준 작업을 노출하는 단순한 CLI로, completions API를 직접 호출하는 스크립트나 계정 관리 등에 쓰는 도구임.
이름만으로도 차이가 분명하다고 봄. 이해되지 않는다면 대상 사용자가 아닌 것이니, 자신을 위한 소프트웨어가 아니라는 이유로 불만을 가질 필요는 없음.
공식 사이트의 예제를 보면 cURL과 CLI의 명령 길이가 비슷한데, 별도 CLI를 유지할 필요가 있는지 모르겠음. openai responses create에 --model, --input, --raw-output, --transform 'output.#(type=="message").content.0.text'를 붙이는 것과, curl로 https://api.openai.com/v1/responses 에 인증·콘텐츠 형식 헤더와 모델·입력 JSON을 보내는 것을 비교하면 차이가 크지 않음.
차이를 이해하는 사람도 있고 나도 이해하지만, 에이전트 경험(AX) 이나 일부 사용자에게 친절한 구성은 아님. 문서에 왜, 언제 사용하는지가 없어 사람이 먼저 파악한 뒤 AI에 설명해야 한다는 점에서 README가 부족함.
누군가에게 당연한 내용이 다른 사람에게 모호하다면 좋은 문서가 아님. 내가 쓰려면 Codex에 이 도구가 필요한 이유와 문서부터 알려주고, 설치하게 한 다음, 기존 에이전트 실행 환경 대신 저수준 API를 직접 호출할 시점까지 지시해야 함.
약 1년간 비슷한 종류의 도구인 llcat을 개발하고 있음. cURL, awk, sed처럼 작동하는 유닉스 친화적 LLM 도구를 찾지 못해 직접 만들었으며, 숨은 상태나 모드 설정 없이 명시적이고 저수준이며 조합 가능한 도구를 지향함.
별도 설정 파일에 의존하는 대신, 내장 jq 문법과 줄 번호로 파일의 값을 참조할 수 있음. 예를 들어 -k "@/credentials.txt:12", -u "@settings.json:.[3].host", -s "@system_prompts:8"처럼 자격 증명·호스트·시스템 프롬프트를 지정하고, --save invocation.json으로 호출 설정을 저장한 뒤 --load invocation.json으로 불러와 원하는 매개변수만 덮어쓸 수 있음. 동료에게 채팅으로 보내거나 공유 폴더에 보관하기도 편함. 대화도 JSON 파일이며 입력과 출력 파일을 다르게 지정할 수 있음. 고정된 context.json을 읽으면서 셸 반복문과 파이프로 여러 파일에 같은 작업을 적용하거나, -a로 첨부 파일을 전달하고 -c로 전체 문맥을 저장할 수 있음. llcat -k @/secrets.json:.anthropic -u api.anthropic.com이나 llcat -k @~/secrets.json:.openrouter -u openrouter.ai/api처럼 제공자를 명시하는 패턴을 특히 좋아함. 숨은 상태가 없어 셸 스크립트에서도 동작을 예측할 수 있음. 공을 많이 들였고 매일 사용 중이니, 써보고 피드백과 버그 제보를 부탁함. https://github.com/day50-dev/llcat
시스템 관리나 DevOps의 운영 환경에서 LLM 도구를 쓰는 것은 아직 무척 조심스러움. 그래도 최상위 모델의 Bash 실력은 나보다 훨씬 뛰어나고 토큰 생성 속도도 엄청남. cURL, cat, JSON을 조합하는 접근은 좋아 보임.
Codex가 OpenAI의 CLI 아니었나? chat과 work 같은 제품명도 너무 헷갈려서, 전체를 바이브 코딩으로 만든 듯한 느낌임.
두 제품은 목적이 다르므로 구분하는 게 합리적임. 하나는 OpenAI 작업 공간과 API 관리용이고 다른 하나는 소비자용 제품임. 관리자가 openai-cli는 허용하되 Codex는 허용하지 않는 것도 충분히 가능한 선택임.
Codex는 대화형이고, 이 도구는 일괄 처리용으로 보임.
명백히 LLM 기반인 조직과 제품을 두고 “바이브 코딩으로 만들었다”고 비판하는 이유는 여전히 이해하기 어려움.
Codex 대신 언제 써야 하는지 궁금함. 다른 도구나 에이전트가 호출하도록 만든 것인가?
Codex는 에이전트 실행 환경이고, OpenAI CLI는 API 래퍼임.
나도 그렇게 추측했음. 가령 Claude를 쓰면서 OpenAI 이미지 생성 기능을 호출하게 하려는 용도일 수 있음. 다만 딱히 와닿지는 않음.
이름만으로 도구가 설명된다는 건 설득력이 약함. CLI 래퍼라도 어떤 문제를 해결하고 누가 써야 하는지 한 줄은 필요함.
README 부제에 “OpenAI REST API용 공식 CLI”라고 적혀 있음. README를 읽어봤는가?
월 정액 구독 한도와 API 크레딧 중 어느 쪽을 사용하는가? Anthropic에도 비슷한 도구가 있는지 궁금함. claude -p는 구독 한도로 사용하기가 불안정하고, 종종 “extra usage” 크레딧이 필요했던 것으로 알고 있음.
claude -p가 추가 사용량으로 과금된 적은 없음. 그렇게 바꾸겠다는 계획을 발표했다가 조용히 보류했음.
이 도구를 어디에 쓸 수 있는지 예시 몇 가지를 알려줄 수 있는가?
자사 도구를 가장 효율적으로 활용해 문제를 풀도록 모델을 강화학습(RL) 시키고, 결국 관리형 에이전트 같은 자사 서비스를 기본적으로 사용하게 만드는 전략으로 보임.
오히려 이런 도구가 더 일찍 나오지 않았다는 게 놀라움.
보통이라면 비용 때문에 굳이 할 필요 없는 작업이겠지만, 구현 비용이 낮다면 만들지 않을 이유도 없음. OpenAI가 잘한 일임.
기업가치가 2조 달러인 회사가 무엇이고, 왜 유용하고, 어디에 쓰는지 한 문장도 제대로 쓰지 못하고 기술 용어만 쏟아냄.
이해하기 어려운 IKEA 조립 설명서의 20~40쪽만 건네면서 신나 하길 기대하는 것과 같음. 대체 무엇에 관심을 가지라는 것인가?
애초에 흥분하길 바라는 제품은 아닌 듯함. OpenAI 모델과 상호작용하는 REST API가 있고, 이것은 그 API를 위한 CLI임. 이름에 담긴 것 이상으로 설명할 내용이 별로 없으며, REST API에 관심이 없다면 대상 사용자가 아닌 셈임.
“OpenAI REST API용 공식 CLI”라는 설명이 명확하지 않다면, 아마 이 도구의 대상 사용자가 아닐 것임.
설명에 “OpenAI API용 공식 CLI”라고 바로 적혀 있음. 특별히 흥분할 제품이 아니라, 그냥 API용 CLI임.