클로드 코드 코덱스 비교: 지금 결제한다면 Opus 5.5와 GPT-6.1 Sol 중 무엇을 고를까

클로드 코드와 코덱스를 처음 고른다면 이미 결제한 Claude Pro나 ChatGPT Plus에 포함된 도구부터 쓰는 편이 낫다. 둘 다 처음이고 제품 기능을 구상하며 기존 코드까지 고칠 개발자라면 Claude Code의 Opus 5.5를, 명세가 정해진 작업을 반복하면서 API 지출을 줄이려면 Codex의 GPT-6.1 Sol을 먼저 시험할 만하다. 2026년 11월의 선택을 가르는 것은 로컬·클라우드 구분보다 실제로 끝낸 기능과 사람이 검토할 변경량이다.

이미 쓰는 구독이 있으면 도구를 하나 더 결제할 이유부터 찾는다

작은 프로그램을 처음 만들려는 사람과 서비스 코드를 매일 고치는 개발자는 같은 추천을 따를 필요가 없다. 처음에는 설치·로그인과 결과 확인에 익숙해지는 시간이 든다. 이미 쓸 수 있는 도구에서 작업 하나를 끝낸 뒤, 어떤 문제가 남는지를 보고 두 번째 도구를 고르면 된다.

아래 평가는 Every의 제품 개발, Stet의 저장소 티켓, Sonar의 Java 생성 과제처럼 서로 다른 일을 다룬다. 현행 Opus 5.5와 GPT-6.1 Sol을 같은 저장소·권한·추론 설정으로 붙인 직접 대결은 확보하지 못했다. 따라서 표는 작업이 비슷한 사례에서 출발하는 추천이며 종합 성능 순위가 아니다.

Opus 5.5는 기존 코드 구현에서도 먼저 시험할 이유가 생겼다

Every가 2026년 9월 22일 공개한 사용기는 출시 전 7일 동안 Claude Code와 데스크톱 앱으로 작업한 기록이다. 개발자 Kieran Klaassen은 같은 Ruby 작업에서 Fable 5.1 High가 26줄, Opus 5.5 Extra-high가 14줄을 만들었다고 보고했다. 매번 지우던 설명 주석이 빠지고 Ruby에 맞는 간결한 코드가 나왔다는 이유로 일상 개발의 기본 모델을 Opus로 바꿨다.

Mike Taylor는 기존 Rails 앱의 MCP 서버에 파일 업로드를 추가하도록 했다. 약 8분 뒤 17개 파일·251줄의 변경이 나왔고 자동 검사 다섯 개 중 네 개를 통과했다. 실패한 항목은 변경 크기였다. 사람이 구현한 변경은 14개 파일·171줄이었다. 기능을 구현할 능력과 작은 수정으로 끝낼 능력은 이 작업에서도 달랐다.

이 경험은 Claude를 화면 초안에만 쓰고 기존 코드 구현은 무조건 Codex에 넘길 이유를 줄인다. 반면 결제·인증처럼 수정 범위를 작게 유지할 기능이라면 “기존 업로드 경로를 재사용하고 관련 없는 구조는 바꾸지 말라”는 조건을 작업에 넣는 편이 좋다. 파일 수가 늘어난 이유를 검토자가 설명할 수 있어야 한다.

Fable을 계속 써야 할지는 더 어려운 과제에서 갈린다. Every의 평가자들도 모두 Opus로 옮긴 것은 아니다. 큰 문제에서는 Fable을 선호한 사람도 있었다. 일반 작업은 Opus에서 시작하고 Opus가 풀지 못한 재현 가능한 문제를 Fable에 넘기면, 비싼 모델을 남길 이유가 결과로 드러난다.

Snorkel의 9월 23일 터미널 과제 평가는 이 추천에 필요한 반례다. 과제 24개의 실행 경로를 분석했을 때 Opus 5.5는 200개 중 136개를 통과했지만, 과제별 첫 시도 성공률인 pass@1은 60.7%로 Fable 5.1의 61.5%보다 낮았다. 실패 중에는 양 끝 날짜를 포함한 정상 청구 기간 계산을 버그로 오해해 고치려 한 경우와, 필요한 절차 일부만 끝낸 경우가 있었다.

기존 서비스를 고칠 때는 보존할 동작을 예제 입력·출력으로 전달할 필요가 있다. 청구 기간이라면 시작일·종료일을 모두 세는지까지 적는다. 모델이 “버그를 고쳤다”고 보고했어도 그 예제의 결과가 바뀌었다면 먼저 요구사항과 맞는지 판단한다.

GPT-6.1 Sol은 작업비가 줄었지만 사람이 읽을 코드는 늘었다

Stet 창업자 Ben의 2026년 10월 12일 평가는 자기 Go·TypeScript 저장소에 병합했던 변경 24개를 다시 구현한 시험이다. 두 Sol 모델을 모두 Codex·Medium으로 한 번씩 실행했다. 변경 전 저장소와 과제를 주고 정답 변경·테스트는 숨겼다. 정확성 53%와 모델의 체크리스트·코드 검토 평가 47%를 합친 결과에서 GPT-6.1 Sol은 이전 GPT-6 Sol에 9승·10무·5패였다.

작업당 평균 API 비용은 3.01달러(약 4124원)에서 1.10달러(1507원)로 줄었다. 비싼 일부 작업이 평균을 끌어올렸고 보통 작업의 비용은 대략 절반이었다는 것이 작성자의 설명이다. 작업당 소요 시간의 중앙값은 12.7분에서 11분으로 줄었다. 반복 티켓을 API로 처리하는 개발자에게는 이전 Sol을 대체할 근거가 된다.

품질의 세부 항목은 엇갈렸다. 정확성 평균 점수는 0.638에서 0.606으로 내려갔고 체크리스트·검토 점수는 올랐다. 수정 줄 수 중앙값도 197줄에서 303줄로 늘었으며, 24개 중 20개에서 변경이 커졌다. 테스트 코드의 비중도 늘었다. “저렴해졌으니 검토도 빨라진다”는 결론은 이 결과에서 나오지 않는다.

Sonar가 10월 9일 공개한 Java 평가에서도 비슷한 문제가 보인다. 두 모델을 Medium으로 실행했을 때 테스트가 있는 544개 과제의 통과율은 83.09%에서 85.29%로 올랐다. 전체 4444개 과제에서 생성한 코드는 48만125줄에서 66만9155줄로 늘었고, 분석기가 잡은 버그 수도 302건에서 407건으로 늘었다. 줄당 버그 밀도가 낮아져도 검토할 버그 총량은 커졌다.

테스트와 코드 분석기를 이미 운영하는 팀은 이 비용 절감을 활용하기 쉽다. 반대로 생성된 코드를 읽을 사람이 한 명뿐이라면 수정 범위를 좁힌 티켓부터 맡기는 편이 낫다. 한 번에 넓게 리팩터링시키고 검토를 뒤로 미루면 API에서 아낀 돈보다 사람이 쓰는 시간이 커질 수 있다.

20달러 구독 두 개와 100달러 플랜은 같은 사용량이 아니다

가격은 2026년 11월 2일 미국 웹 월 결제 기준이다. 원화는 1달러=1370원으로 환산했으며 세금과 국내 결제액은 별도다. Claude 공식 가격표와 Codex 공식 가격 문서를 기준으로 비교했다.

Pro와 Plus를 함께 결제하면 월 40달러(5만4800원)다. 월 100달러 플랜 하나보다 60달러(8만2200원) 저렴하지만 한쪽에 몰아 쓸 수 있는 사용량은 다르다. 구현을 맡긴 쪽이 매일 한도에 걸린다면 검토용 구독 하나를 추가해도 그 도구의 한도는 늘지 않는다. 먼저 구현 중단이 문제인지, 두 번째 의견이 필요한지를 가르는 것이 좋다.

API는 작업이 소비한 토큰으로 따로 계산한다. 표준 처리·100만 입력/출력 토큰당 GPT-6.1 Sol은 2/10달러(2740/1만3700원), Opus 5.5는 4/20달러(5480/2만7400원), Fable 5.1은 10/50달러(1만3700/6만8500원)다. 캐시와 추론량·처리 속도 옵션에 따라 실제 작업비가 달라진다. Stet의 1.10달러는 해당 실행의 API 환산비이며 Plus에서 작업을 한 번 보낼 때마다 붙는 요금이 아니다.

Claude Max·Ultra는 공식 가격표에 각각 월 100·200달러의 API 크레딧도 안내한다. API 자동화까지 쓰는 독자라면 이 크레딧의 적용 조건과 소진액을 구독료와 함께 본다. 반면 Code만 쓰는 독자는 크레딧 액면가를 현금 절약으로 모두 계산할 이유가 없다.

양쪽 모두 터미널과 원격 서버에서 쓴다

Codex를 클라우드 전용, Claude Code를 로컬 전용으로 나누면 지금 필요한 도구를 잘못 고르게 된다. 양쪽 모두 터미널에서 저장소 파일을 읽고 고치며, 데스크톱·편집기에서도 쓴다. 사내 DB나 Docker에 연결해야 한다면 도구 이름보다 실제 명령을 실행하는 머신에 그 환경이 준비돼 있는지가 중요하다.

Claude 데스크톱 문서는 SSH 환경에서 원격 작업을 안내한다. Codex 원격 연결 문서도 SSH 호스트의 프로젝트로 연결하는 방법을 제공한다. 원격 개발이 필수라는 이유 하나로 어느 쪽을 제외할 단계는 아니다. 서버의 프로젝트 경로, 인증, 실행 도구가 준비된 환경에서 먼저 작은 수정과 테스트가 되는지 본다.

저장소 규칙은 Codex의 AGENTS.md, Claude의 CLAUDE.md에서 시작한다. 자주 실행하는 테스트와 수정 금지 경로를 넣어 두면 같은 설명을 매번 반복할 필요가 줄어든다. 규칙의 위치와 적용 범위는 AGENTS.md 사용법, 반복 작업을 묶는 방법은 Codex Skills 사용법에서 이어진다.

모델 이름도 실제 세션에서 본다. Claude의 모델 설정 문서에 따르면 Opus 5.5는 v2.1.280 이상이 필요하고, 기본 추론 강도는 Medium이다. Codex에서도 모델과 추론 강도를 골라 기록한다. 오래된 사용기의 High·Extra-high 결과를 현재 기본 설정의 속도로 기대하면 작업 시간부터 달라진다.

내 저장소에서 같은 기능을 끝내는 데 든 시간을 비교한다

8만 줄 프로젝트에서 100시간과 20시간을 썼다는 비교는 각 도구로 작업한 누적 시간을 말한다. 2026년 4월 18일 소개된 그 사례의 모델은 Opus 4.6과 GPT-5.4였다. 같은 작업을 끝내는 데 각각 100시간과 20시간이 걸렸다는 뜻으로 읽어서는 안 된다. 이를 현행 모델의 속도 차이로 받아들여 구독을 고르면, 실제로 더 빨리 일을 끝낼 도구를 잘못 선택할 수 있다.

현재 선택에는 최근 실제로 처리한 작은 티켓 하나가 더 유용하다. 원래 커밋에서 시작하는 별도 작업 폴더 두 개에 같은 요구를 주고, 모델·추론 강도·권한·테스트 환경을 기록한다. 프롬프트에는 새 기능, 유지할 동작, 건드리지 않을 경로, 완료 시 실행할 명령을 적는다. UI 작업이면 클릭 뒤 저장한 내용이 다시 열리는지도 완료 조건에 넣는다.

비교할 것은 첫 응답까지의 시간이 아니라 사람이 반영할 수 있게 된 시점까지의 시간이다. 테스트에 실패해 다시 시킨 시간, 필요 없는 변경을 지운 시간, 화면을 열어 확인한 시간을 합친다. 이미 쓸 수 있는 구독부터 이 작업을 해 보고, 다른 도구가 그 부담을 줄이는지 비교하면 된다.

교차 검토는 같은 파일을 번갈아 고치기 전에 역할을 정한다

두 도구를 사용할 수 있다면 한쪽이 구현하고 다른 쪽은 변경과 실행 결과를 읽게 한다. 검토자에게는 파일을 고치는 대신 결함 위치·재현 조건·사용자 영향을 요구한다. 그러면 두 도구가 각자 선호하는 구조로 같은 코드를 다시 쓰는 일을 줄일 수 있다.

예를 들어 업로드 기능이라면 “허용한 파일이 저장되고 다시 열리는가, 금지한 확장자는 거절하는가, 다른 사용자의 파일을 읽을 수 없는가”가 반영 여부를 바꾸는 질문이다. 변수명이나 추상화 제안과 이런 결함을 같은 수준으로 처리하면 기능이 완성된 뒤에도 수정이 계속된다.

필수 테스트가 모두 통과하고 미해결 치명적·높음 결함이 0건인 상태에서 사람이 실제 동작과 변경 범위를 보고 반영한다. 자동 재검토를 두 번까지만 하기로 정했다면, 두 번 뒤에도 실패가 남을 때는 사람에게 넘긴다. 횟수를 채운 사실이 성공을 대신하지 않는다. 반복이 길어질 때의 운영 예는 끝없는 리뷰 루프를 끊는 방법에서 이어진다.

첫 결제는 기존 구독을 활용하고, 두 번째 결제는 실제 작업에서 남은 문제를 줄일 때 한다. 제품 기능을 다듬는 일이 많으면 Opus 5.5부터, 반복 티켓의 API 지출이 크면 GPT-6.1 Sol부터 같은 작업을 맡겨 본다. 구독료나 API 비용이 줄어도 수정·검토 시간이 늘었다면 그 작업에서는 전환을 미룰 이유가 있다.