2026년 9월, Codex vs Claude Code vs Cursor - 다들 실제로 뭐 쓰고 있음?

보통은 회사에서 결제해 주는 걸 쓰는데, 셋 다 어떻게든 잘 활용할 수 있어서임. 하지만 개인적인 용도로는 Codex를 씀.

가성비가 가장 좋다고 생각함.

예산이 부족하다고 불평하는 사람들은 대부분 skill issue거나, 본인이 하려는 작업에 비해 충분한 플랜을 결제하지 않은 경우라고 봄.

Codex는 20달러 플랜으로는 도저히 못 써먹음. 예전에 Cursor 쓸 때는 Grok 4.6으로 거의 멈춤 없이 작업했었음. 지금은 둘 다 가지고 있는데, Codex는 이틀 만에 주간 제한에 걸리고 5일 동안 리셋도 안 되고 뱅크드 리셋도 없어서 그냥 손가락 빨고 있어야 함. 20달러 예산인 사람들은 고민하지 말고 Cursor가 최고의 선택임. Codex나 Claude Code를 써도 Opus/fable이나 Astra/Sol 같은 최상위 모델은 못 쓰고 Sonnet 5나 Luna에 갇힐 텐데, 내 생각엔 얘네가 Grok 4.6보다 딱히 나은 것도 아님.

혹시 '생리'라는 거 들어봄?

역겹네

나는 최근 몇 달간 Cursor Pro+와 Codex Plus를 조합해서 쓰고 있음.

계획 단계에서는 주로 Cursor에서 Grok을 쓰는데, 코드 외에 깊은 조사가 필요하면 Kimi K3 Max를 사용함. 나는 아주 작은 변경 사항까지 전부 계획을 세우고, 계획 모드 없이 에이전트를 쓰는 일은 거의 없음. 그래야 LLM이 범위를 제대로 파악하고, 실제로 변경하기 전에 내가 검토할 수 있으니까. 프로젝트 내 문서화를 중요하게 생각해서 항상 최신 상태로 유지하고, 내가 직접 모든 계획을 검토한 뒤 문제가 있으면 LLM에게 수정을 요청함(Cursor와 Codex 내장 마크다운 뷰어는 구려서 주로 Joplin으로 검토함). Codex는 계획용으로 거의 안 쓰고, 시도해 봐도 항상 Cursor보다 결과가 안 좋았음. 흥미로운 건 Cursor에서 계획용으로 GPT를 쓰면 Codex에서보다 더 잘 작동한다는 점임. OpenAI 시스템 프롬프트가 계획에 최적화가 안 된 느낌임.

실행 단계에서는 Composer 2.5와 GPT Luna Max를 번갈아 씀. Composer는 구현용으로 주로 쓰는데, 간단한 변경은 Luna를 써서 Composer를 검토용으로 돌림. Composer는 자기 변경 사항을 검토하거나 복잡한 diff를 검토할 때는 구린데, 이상하게 Luna가 생성한 간단한 것들을 검토할 때는 괜찮음.

변경 사항 검토는 Luna가 한 간단한 작업이 아닐 경우, GPT Terra/Sol Max, Grok High, Kimi K3 Max를 번갈아 씀. GPT는 구현의 개념적 결함을 찾는 데 좋고, Grok은 순수 코드 결함을 찾는 데 능숙해서 GPT보다 깊이 있고 철저하지만 가끔 개념적인 부분을 놓침. Kimi K3는 대규모 변경에 좋고 Grok이나 Terra/Sol이 놓치는 개념적 공백을 자주 찾아냄. 나는 모든 변경 사항을 모델 4~5개를 돌려가며 검토하고, 코드의 여러 측면(정확성, 엣지 케이스, UX, 유지보수성, DRY, 일관성 등)을 확인하는 미리 만들어둔 검토 프롬프트를 사용함. 내 프롬프트에는 항상 '나쁜 게 보이면 바로 고치고, 의심스럽거나 애매한 변경 사항은 검토 결과에 제안으로 포함해서 내가 다음에 뭘 할지 결정하게 해달라'는 식의 내용을 넣음. 그 후 검토 프롬프트 결과를 Joplin에 붙여넣고 배치로 묶어서 보통 여러 에이전트를 통해 병렬로 구현 계획을 세움.

이런 방식 덕분에 코드 품질을 직접 짠 것처럼 유지하면서도 코드베이스의 모든 변경 이유를 파악할 수 있음. 여전히 직접 코딩하는 걸 좋아해서 프로토타이핑할 때 자주 하지만, 요즘은 LLM 도움을 받으면 10배는 더 빠름.