결론부터 셋.

  • 두 도구의 차이는 지능이 아니라 빈칸 처리 방식이다. 클코는 내가 안 적은 칸을 알아서 채우고, 코덱스는 빈칸을 빈칸으로 남긴다.
  • 그래서 작업별로 갈린다. 안 적히는 결정이 수십 개씩 쏟아지는 구현 작업은 클코가, 스펙이 고정된 설계·검토 작업은 코덱스가 손에 붙는다.
  • 내 운영 결론은 클코로 만들고 코덱스로 검증하는 것이다. 반대 방향은 잘 안 된다.

6월에 주력 에이전트를 뭘로 둘지 정리한 적이 있다. 그건 쓰기 전의 분석이었고, 이 글은 실제로 한 달 굴려본 뒤의 현장 기록이다. 그리고 결론이 예상과 정확히 같지는 않았다.

전제 — 선택이 아니라 환경이었다

새 프로젝트에 들어가면서 도구 구성이 바뀌었다. 회사가 지원하는 건 GPT 크레딧이고 — 1인당 100만원 한도 — 클로드 쪽은 지원 항목에 없다. 즉 “어느 쪽이 더 나은가”를 따져서 옮긴 게 아니라, 비용을 회사가 대주는 쪽으로 무게중심이 먼저 옮겨갔다.

이런 배치는 생각보다 흔하다. 조직이 코딩 에이전트를 도입할 때 기준은 개발자 체감이 아니라 전사 계약, 보안 검토, 이미 깔린 오피스 제품군이다. 개발 도구를 개발자가 못 고르는 상황은 새삼스럽지 않다.

그래서 이 글은 도구 추천글이 아니다. 한쪽만 공짜인 환경에서 한 달을 버텨보고, 뭐가 다른지 몸으로 안 기록에 가깝다. 참고로 양쪽 플래그십은 9월 초에 이틀 간격으로 나왔다. Fable 5.1이 9월 1일, GPT-6 Astra가 9월 3일. 비교하기엔 시점이 나쁘지 않았다.

차이의 정체 — 프롬프트 탄력성

한 달 동안 가장 일관되게 느낀 건 이거다.

클코는 내 프롬프트 품질이 나빠도 결과가 별로 안 나빠지고, 코덱스는 정직하게 같이 나빠진다.

대충 던져도 클코는 90점대를 가져온다. 내가 미처 생각 못 한 항목까지 챙겨서 온다. 코덱스는 다르다. 애매하게 말하면 애매한 게 오고, 빠짐없이 적으면 적은 그대로 정확하게 온다. 요구사항 수행률로만 보면 흠잡을 데가 없는데, 요구사항에 없던 건 절대 안 해준다.

표로 정리하면 이렇다.

내 입력 Claude Code Codex
애매한 한 줄 의도를 추론해 90점대 적은 만큼만, 60점대
정밀한 스펙 스펙 + α 스펙 100%, 딱 거기까지
스펙이 틀렸을 때 종종 “이거 이상한데요” 하고 걸러줌 틀린 스펙을 정확히 구현

처음엔 이걸 코덱스의 약점이라고 생각했다. 지금은 성격 차이로 본다. 나만의 감상도 아니다. 두 도구를 100시간 넘게 병행한 기록들에도 같은 문장이 반복된다 — 코덱스는 말 그대로 시킨 것을 하고, 클코는 프롬프트가 느슨해도 의도를 잡아낸다. 같은 프롬프트를 줬을 때 클코는 열 개쯤 되묻고 코덱스는 바로 만들기 시작하더라는 관찰도 있다. 되묻는 쪽의 결과물이 사용자 머릿속 그림에 더 가까웠다는 것도 함께.

그러니까 두 도구는 내 명세 능력에 대한 민감도가 다르다. 클코는 내 애매함을 흡수해서 가려주고, 코덱스는 그걸 그대로 출력에 반영한다.

빈칸의 개수가 작업의 성격을 정한다

민감도 차이를 작업에 대입하면 갈림길이 선명해진다. 기준은 하나다. 그 작업에 “안 적힌 결정”이 몇 개나 들어 있는가.

웹 프론트엔드 구현을 시킨다고 하자. “이 목록에 필터 추가”라는 한 줄 뒤에는 안 적힌 결정이 최소 수십 개 붙어 있다. 로딩 상태, 빈 결과 화면, 에러 토스트, 디바운스 간격, URL 쿼리 동기화, 키보드 접근성, 기존 컴포넌트 네이밍 관례. 이걸 다 적을 거면 프롬프트가 아니라 설계 문서를 쓰는 셈이다. 백엔드도 비슷하다. 트랜잭션 경계, 예외 변환, 로깅 레벨, 페이지네이션 기본값 — 안 적어도 누군가는 정해야 하는 것들이다.

빈칸이 많은 작업에서는 빈칸을 알아서 채우는 쪽이 이긴다. 내 한 달의 체감으로 구현 작업은 클코가 확실히 편했다.

반대로 아키텍처 논의는 빈칸이 적다. 제약 조건, 트래픽 가정, 기존 시스템 경계, 우선순위가 이미 문장으로 나와 있다. 여기서 필요한 건 상상력이 아니라 적힌 조건을 곧이곧대로 따져주는 태도다. 클코의 “알아서 챙김”은 이 자리에서 오히려 노이즈가 된다. 묻지도 않은 확장 시나리오를 얹어 결론을 흐리는 식이다. 코덱스는 조건만 물고 늘어진다. 그래서 설계를 검토받는 자리에서는 코덱스 쪽 답이 더 쓸모 있었다.

여기서 하나 정직하게 짚고 간다. 이 체감은 통설과 어긋난다. 도구 비교 글 다수는 “플래닝과 추론은 클코, 실행 속도와 에이전시는 코덱스”로 정리한다. 내 경험은 그 반대쪽이다. 확인 불가 — 단정 못 한다. 다만 어긋나는 이유로는 두 가지가 그럴듯하다.

  1. 내 입력 품질이 작업마다 다르다. 나는 아키텍처를 논할 때 스펙을 정밀하게 쓰고, 구현을 시킬 땐 대충 던진다. 코덱스가 유리한 조건을 내가 아키텍처 작업에만 만들어주고 있는 셈이다.
  2. 내 아키텍처 작업은 대부분 “이미 있는 안을 따지는” 자리다. 새로 그리는 게 아니라 클코가 뽑은 안을 검토하는 흐름이라, 독립된 2차 의견의 가치가 크다. 이건 플래닝 능력 비교라기보다 검토자 역할 비교에 가깝다.

즉 통설이 틀렸다기보다, 내 워크플로가 두 도구에게 서로 다른 난이도의 문제를 주고 있었을 가능성이 크다. 도구 비교글을 읽을 때 이 함정은 늘 있다고 본다.

크레딧 — 체감과 벤치마크가 정반대로 간 지점

가장 헷갈렸던 대목이다. Astra 크레딧이 녹는다. 체감상 Fable보다 빨리 사라진다. 그런데 벤치마크는 정반대를 말한다.

Artificial Analysis 측정으로 Astra는 지능 프런티어 부근에서 토큰 효율 최상위권이다. max effort 기준 태스크당 출력 토큰 약 27k인데, 비슷한 점수대의 Fable 5.1은 약 78k를 쓴다. 대략 3분의 1이다. 하네스 단위 비교에서도 같은 점수를 내는 데 Astra 3.3M, Fable 5.1 5.7M이라는 수치가 나온다.

숫자를 이렇게 보고도 크레딧이 더 빨리 마르는 이유를 정리하면 이렇다.

이유 내용
토큰 효율 ≠ 비용 효율 Astra는 $10/$50(1M 기준). 토큰 수가 적어도 토큰 단가가 최상단이다
effort가 지배 변수 xhigh는 medium 대비 리팩터링 1.76배, UI 재설계 2.52배 토큰을 쓴다는 측정이 있다
Fast(2x) 모드 속도 배수만큼 소모도 배수다
대화 누적 매 턴 전체 대화가 다시 올라가고, 보이지 않는 추론 토큰이 얹힌다. 세션이 길수록 가팔라진다
9월의 소모 버그 백그라운드 기능이 예상보다 토큰을 빨리 먹는 문제가 있었고, OpenAI가 9월 3·4·7·8·12일에 걸쳐 반복적으로 한도를 리셋해줬다

마지막 줄이 중요하다. $200 Pro 플랜이 12시간 만에, Max + 2x 조합에선 한 시간 만에 말랐다는 보고가 줄을 이었고, 제조사가 리셋을 다섯 번 뿌렸다. 내 체감이 유별난 게 아니었다. 그 기간의 소모량 일부는 모델 특성이 아니라 버그였다.

그래도 내 탓 가능성은 남겨둔다. 나는 클코를 더 오래 써서 더 잘 다룬다. 같은 작업을 코덱스에 시킬 때 애매하게 말해 한 번 더 시킨 횟수가 분명히 더 많았다. 그리고 이게 벤치마크와 체감이 갈리는 진짜 지점이라고 본다.

실효 효율 = (시도당 토큰) × (작업당 시도 횟수)

벤치마크는 앞의 항만 잰다. 뒤의 항은 사용자와 도구의 궁합이 정한다. 시도당 토큰이 3분의 1이어도 내가 세 번씩 다시 시키면 효율은 제자리다. 프롬프트가 느슨할수록 재수행률이 올라가는 도구라면, 토큰 효율 1등이라는 타이틀은 내 계정 명세서에서 사라진다.

그리고 어느 쪽도 면죄부는 없다. Fable 5.1 역시 Max 플랜 5시간 쿼터를 30분, 심하면 한 프롬프트로 태웠다는 보고가 즐비하다. 단가는 양쪽 다 $10/$50으로 같다. 플래그십을 상시로 굴리면 어느 진영이든 녹는다가 지금 시점의 정직한 요약이다.

실무 처방은 단순하다. effort를 기본값에서 한 칸 내리고, Fast는 끄고, 세션을 짧게 끊고, 무엇보다 시키기 전에 스펙을 한 번 더 쓴다. 마지막 항목의 효과가 가장 크다. 재수행 한 번이 프롬프트 다듬는 3분보다 훨씬 비싸다.

지금의 운영 방식 — 만들기는 클코, 따지기는 코덱스

한 달의 결론을 그림으로 옮기면 이렇다.

스펙 작성(사람) → 구현(클코) → 검증·리뷰(코덱스) → 수정(클코)

단계 담당 이유
스펙 정리 나 이 단계 품질이 뒤 전부를 좌우한다
구현 Claude Code 안 적힌 결정이 수십 개 — 채워주는 쪽이 유리
검증·설계 리뷰 Codex 적힌 것만 따지는 태도가 검토자에겐 미덕
반영 Claude Code 맥락을 이미 들고 있는 쪽이 싸다

이 조합이 나만의 발명은 아니다. 두 도구를 병행하는 팀들이 수렴하는 지점이 대체로 “클코가 만들고, 머지 전에 코덱스가 검토한다”이고, 코덱스가 논리 오류·경합 조건·엣지 케이스를 곧잘 잡아낸다는 평이 붙는다.

반대 방향, 그러니까 코덱스로 만들고 클코로 검증하는 건 잘 안 된다. 이유가 두 겹이다.

  • 역할과 성격의 궁합. 생성자에게 필요한 건 빈칸을 메우는 능력이고, 검증자에게 필요한 건 빈칸을 빈칸이라고 지적하는 능력이다. 성격을 거꾸로 배치하면 코덱스는 빈칸이 숭숭 뚫린 결과물을 만들고, 클코는 그 빈칸을 지적하는 대신 조용히 채워버린다. 문제가 리뷰 단계에서 드러나지 않고 덮인다.
  • 연동 방향. 6월 글에서 짚은 그대로 공식 플러그인은 여전히 Codex → Claude Code 단방향이다. 클코 세션 안에서 코덱스를 호출하는 건 정식 경로가 있지만, 반대는 없다. 허브를 클코에 두는 게 구조적으로 자연스럽다.

지금 내 환경에선 이게 좀 얄궂다. 회사가 사주는 건 GPT 크레딧인데, 허브는 내 돈 내는 클코다. 구현을 코덱스로 옮겨 크레딧 부담을 회사 쪽으로 넘기는 그림도 그려봤지만, 그러려면 내가 지금보다 훨씬 촘촘하게 스펙을 써야 한다. 그 시간이 아깝지 않은 작업이 어디까지인지는 아직 실험 중이다.

마무리 — 코덱스는 계측기였다

한 달 써보고 남은 가장 쓸모 있는 문장은 도구 우열이 아니다.

코덱스는 내 프롬프트 품질을 측정하는 계측기다.

클코를 쓸 땐 내가 프롬프트를 잘 쓰는 줄 알았다. 결과가 늘 괜찮았으니까. 코덱스로 옮기고 나서야 그 괜찮음의 상당 부분이 내 실력이 아니라 모델이 내 빈칸을 메워준 덕이었다는 걸 알았다. 같은 문장을 던졌는데 결과가 눈에 띄게 못하다면, 문제는 대개 문장 쪽에 있다.

예전 글에서 결과물의 차이는 기법이 아니라 출력에서 뭐가 틀렸는지 알아보는 눈에서 나온다고 썼는데, 여기에 하나를 더 붙이게 됐다. 입력에서 뭐가 비어 있는지 알아보는 눈. 관대한 도구만 쓰면 이 감각은 자라지 않는다.

그래서 당분간은 지금 구성을 유지한다. 애매하게 던져도 되는 자리에선 클코의 관대함을 쓰고, 정확해야 하는 자리에선 코덱스의 엄격함으로 나를 점검한다. 도구를 하나로 줄이는 게 목표였던 적은 없다.

Sources: