Codex CLI, 기본 설정으로 상주하며 자동 업데이트되는 백그라운드 데몬 설치

Codex CLI와 Claude Code의 품질이 LLM 기반 개발의 현주소를 솔직하게 보여준다고 생각함. 미래가 그리 밝아 보이지 않음.

그래도 코드를 간신히 작성하던 수준에서 지금까지 오는 데 불과 3년 정도 걸렸음. 이 고비를 넘지 못할 것이라는 쪽에 돈을 걸지는 않겠음.

하루에도 서른 번쯤 혼잣말하게 됨. “토큰이 무제한인데, 대체 어떻게 이 모든 게 이렇게 형편없을 수 있지?”

두 CLI 모두 점점 나빠지고 있음. 코드 품질보다는 충분히 고민하지 않은 기능을 계속 덧붙이는 것이 원인 같음.
기능을 순식간에 구현할 수 있게 되면서 잘못된 UX 결정을 내리는 속도까지 폭발적으로 빨라졌을 수도 있음.

사람이 작성한 코드 중에는 이보다 품질이 훨씬 나쁜 것도 있음. 그 작은 표본도 인간 주도 개발의 현주소를 보여주는 것인가? 그렇다면 그쪽 미래도 밝지 않은 것인가?

널리 쓰이는 제품 중 쓸 만한 LLM 하네스가 하나도 없다고 느끼는 지경에 금세 도달함. 써본 것마다 사소한 업데이트에서도 기이한 방식으로 망가짐.

이를 끄는 문서화된 설정은 없지만, 현재는 daemon_auto_start 기능 플래그로 제어할 수 있음. ~/.codex/config.toml의 [features] 아래에 daemon_auto_start = false를 설정하면 됨.
시작할 때 ~/.codex에 PID 파일과 잠금 파일 등도 기록함. 이 파일들을 지우고 /dev/null을 가리키는 심볼릭 링크로 바꾼 뒤 chattr +i 등으로 쓰기를 막을 수도 있음. 기능 플래그가 없어지더라도 이렇게 하면 백그라운드 데몬이 시작 중에 죽을 것으로 추정함. 설정 스키마에서 확인할 수 있음.

기본값은 비활성화여야 함. 데몬은 pi나 pi-durable 커스텀 하네스처럼 데몬 서버 위에 앱을 구축할 때 유용함.

무슨 이유인지 데몬이 시작되지 않아 Codex가 계속 경고했음. 이 데몬이 어디서 생겼는지 의아했고, 내가 이전에 뭔가 놓쳤다가 이제 고장 난 것인가 싶었음.

핵심은 원래 없던 것을 Codex 0.157.0에서 활성화하면서, 마지막 Codex 인스턴스를 종료해도 살아남는 상주 프로세스를 설치했다는 것임. 정말 불쾌함.
끄려면 codex features disable daemon_auto_start, codex app-server daemon stop, pkill -f 'app-server daemon pid-update-loop'를 실행하면 됨. 관련 이슈를 참고하면 됨.

데몬에는 버그가 많음. 자동 업데이트 중 권한이 멋대로 망가져 .git이 읽기 전용이 되고 작업이 막히기도 함. 몇 시간마다 뜬금없는 버그에 걸리는 일이 잦아 Codex에 어떤 목표도 믿고 맡기기 어려움. 관련 이슈에 자세한 내용이 있음.

Codex에서는 가장 기본적인 두 기능인 "New Chat"과 "Scheduled Tasks"조차 간헐적으로 클릭할 수 없음.

이 부분에서는 CLI가 앱보다 훨씬 나았음. 적어도 예전에는 그랬음.

이전 버전들이 디스크를 채우는 것도 문제임. 확인해 보니 내 시스템에서 약 12GB를 차지했는데, 고작 하네스라는 점을 생각하면 황당함.
Claude Code가 엉망이라고들 하지만 Codex는 모든 지표에서 훨씬 나빠 보임.

써본 하네스들은 하나같이 자기가 남긴 파일을 정리하는 데 형편없음. 개발용 VM에 온갖 찌꺼기가 쌓여서, 이제 하루 한 번 LLM을 돌려 디스크를 훑고 잔여 쓰레기로 보이는 것을 지우게 함.
불을 끄겠다고 방화범을 고용하는 격임.

컴파일 언어로 잘 설계한 하네스가 나와 컴퓨터를 불필요하게 비대하게 만들지 않았으면 함. Codex는 이 조건들과 정반대라서, 아마 OpenAI가 아닌 다른 회사가 만들어야 할 듯함.

chatgpt.com과 aistudio.google.com도 최근 본 웹사이트 중 버그가 가장 많은 축에 듦. 왜 늘 LLM 관련 제품에서 이런 일이 생기는 걸까?

내가 즐겨 쓰는 Nix 패키지는 적어도 그 동작은 패치로 제거하는 것으로 알고 있음. 패치와 저장소를 참고하면 됨.

소프트웨어의 시대를 끝내겠다는 소프트웨어가 정작 그 자체로는 꽤 형편없는 소프트웨어라는 게 매우 역설적임.

새로운 AI 도구 상당수가 이미 해결한 문제를 다시 풀고 있음. 소프트웨어 업데이트는 패키지 관리자로 해결해 왔는데, 업데이트를 계속 확인하는 데몬과 패키지 관리자를 우회하는 셸 스크립트가 꼭 필요한가? 설치 스크립트를 보면 기존 패키지 관리자를 쓰지 않고 설치를 직접 관리함. 설치를 쉽게 만드는 건 좋지만, 굳이 떠맡지 않아도 될 설치 관리까지 책임지게 됨. 더 나은 해법이 있으니 그 시간을 다른 데 쓰는 편이 낫겠음. 나만 이렇게 생각하는 걸까?

최근 몇 달간 도구를 최소한으로 갖춘 간소한 하네스 hax로 GPT 모델을 사용하면서, 대부분의 작업을 bash에 맡기고 있음. 과도하게 복잡한 하네스들 사이에서 숨통이 트이는 느낌임.
특별한 동작이 필요하면 Mac에 CLI 도구를 만들고 시스템 프롬프트 한 줄로 해당 도구가 있다고 알려주면 끝임. 아주 만족스럽게 쓰고 있음. hax와는 아무 관계 없는 일반 사용자임.

표현상 작은 차이를 짚자면, “그런 도구가 있다”는 말은 명령줄 도구가 아니라 하네스가 제공하는 도구로 해석될 수도 있음. 다시 읽으니 CLI 도구라는 뜻이 분명하지만, 둘의 차이를 알아두면 좋겠음.
군더더기 없는 방향이 좋아 pi를 쓰기 시작한 입장에서 hax도 써봐야겠음. MCP와 코드 모드 지원을 둘러싼 논쟁은 격렬하지만, 하네스 제공 도구를 보강하면 실행 왕복 성능이 눈에 띄게 개선된다는 수치는 부정하기 어려움.

휴대전화에서 ChatGPT를 쓸 때 내 에이전트들이 전부 알림음을 낸 게 이것 때문이었나?

Codex는 상태와 설정 데이터를 섞어 관리하는 등 구조가 매우 좋지 않음. 초기부터 썼지만 nix-darwin 환경에서 선언적으로 관리하기 어려워 한동안 사용을 중단함. 이번 문제와 개발진의 대응을 보니 이 하네스를 다시는 신뢰하기 어려움.
지금은 opencode에서만 Codex를 사용하며, 그럭저럭 괜찮게 작동함. 적어도 OpenAI는 Anthropic처럼 자사 하네스만 쓰도록 제품 접근을 제한하지는 않음. opencode도 이상한 일을 꽤 하므로 칭찬 일색일 생각은 없지만, Codex 수준은 아님.

본론과는 별개로 ChatGPT/Codex 데스크톱 및 Android 앱의 프런트엔드 품질은 끔찍하다고 생각함. 이렇게 많은 오류가 빈번하게 발생하는 제품이 어떻게 운영 환경에 배포됐는지 이해하기 어려움. 사람이 직접 테스트하는 과정이 아예 없는 것인가?

이럴 때 운영체제 배포판 모델의 장점이 드러남. 소프트웨어를 패키징하고 테스트하며 합리적인 기본값을 정하는 사람들이 있어서, 대체로 이런 제멋대로인 동작을 막아줌.

Nix/NixOS는 한 걸음 더 나아가, 패키징할 때 자동 업데이트를 활성화하려면 일부러 별도 작업을 해야 함.