Codex는 별로임

흥미롭네. 내 경험상 다른 도구들보다 지시사항을 더 잘 따르던데. 난 주로 지식 작업 위주라 코딩 관련은 적어서 그런가.

어떤 모델을 써?

어떤 작업에 쓰고 있어?

우리가 어떻게 상호작용하느냐에 따라 효율이 달라지는 것 같아. 나랑은 잘 안 맞는 걸지도. 개발용으로 Codex 6.1 sol 기본 설정을 쓰고 있어.

안 좋은 경험을 하신 것 같은데, 그것 때문에 바로 취소하지는 마. 난 정기적으로 Codex에 광범위한 애플리케이션이나 기능 아이디어를 주는데 아주 안정적으로 만들어줘. UX는 잘 못해서 구조가 잡히면 Claude를 가져와서 해결하는 식으로 조정했어.

이 경우에는 어떤 과정으로 진행했어? Sol 6.1이랑 프로젝트를 논의하고 그냥 알아서 하게 뒀어, 아니면 요구사항이랑 작업 목록을 만들어서 그걸 수행하게 했어? 내가 묻는 이유는 Codex를 쓰면서 긍정적인 경험을 한 건 대부분 반복적인 대화형 상호작용을 통해서였기 때문이야. "에이전트가 자격 증명이 필요할 때 쓸 안전한 키 저장소가 필요해"라거나 "Railway에 호스팅해줘", "직접 쓰거나 CLI, MCP로 쓸 수 있는 깔끔한 API가 필요해"라고 말하면 그 작은 가이드 노트들을 정확히 따라주거든. 아마 내가 설계를 맡기고 구현하게 해서 그런 것 같아. 완성된 제품 계획이랑 작업 목록을 들고 가서 시킨 적은 없는데, 아마 거기서 문제가 생기는 게 아닐까 싶어.

그리고 난 환경에 기술이나 가이드를 많이 넣어두지 않아. 핵심 개발 언어/모범 사례나 빌드 중인 서비스에 대한 것만 한두 개 넣어두지. 이미 알겠지만, 환경이 깨끗할 때랑 오래되거나 충돌하는 문서와 가이드가 잔뜩 있을 때는 결과가 다를 거야.

굳이 묻지는 않겠지만, 난 Codex로 워낙 좋은 경험을 해서 결정하기 전에 당신도 그런 경험을 해봤으면 좋겠어.

맥락이 부족하다기보다는 제약 조건을 무시하는 것 같은데.

하루 만에 판단하는 건 좀 가혹하지만, 백로그 점프는 진짜야. 전체 큐를 다 주지 말고 티켓을 하나씩만 줘봐. 그러면 대부분 해결돼. 안 그러면 그냥 제일 재밌어 보이는 걸 골라버리거든.

오케스트레이터 에이전트가 서브 에이전트를 호출해서 작업하게 하는 게 좋아. 그러면 컨텍스트 윈도우의 노이즈가 작업 처리에 덜 영향을 미치거든.

난 headless cli 모드에서 필요한 아티팩트만 접근하게 하고 결과물로 아티팩트를 기대하는 방식으로 작업을 많이 해. 이런 일시적인 실행 방식은 백로그나 PR 처리할 때 꽤 잘 작동해. 바이브 코딩 모드로 빌드하는 게 아니라.

인정해야겠네... Codex를 정말 좋아했었는데... 요즘은 Claude Code가 더 좋아...

응, 난 1월부터 Claude를 써왔는데 한 제공업체만 고집하는 장점은 그 도구의 꼬인 부분이나 문제를 파악해서 잘 쓰는 법을 터득하게 된다는 거야. 자주 바꾸면 항상 긴장해야 할걸, 모르는 문제들이 계속 나올 테니까.

Codex랑 Claude Code 둘 다 좋지만, 최근엔 pi harness를 쓰고 있어. 커스터마이징이 정말 잘 돼서 마음에 들어.

난 Codex로 엄청난 것들을 만들어냈는데. 무슨 소리를 하는 건지 모르겠네.

글 쓴 것처럼 프롬프트를 작성한다면, 문제는 뻔하지. 쓰레기를 넣으면 쓰레기가 나온다(Garbage in, garbage out); 그 규칙은 거의 100년 된 거야.