Claude Sonnet 5.5 vs GPT-6 Sol: 같은 가격대의 두 런타임 비교

Anthropic은 9월 28일 입력 토큰 100만 개당 2달러, 출력 토큰 100만 개당 10달러의 가격으로 Claude Sonnet 5.5를 출시했습니다. OpenAI 역시 9월 22일 동일하게 2달러와 10달러의 가격으로 GPT-6 Sol을 내놓았습니다. 불과 6일 간격으로 출시되었고 정가도 같으며, 두 모델 모두 각 연구소의 플래그십 바로 아래 단계에 위치합니다. 코딩 에이전트의 기본 모델을 고민하는 팀에게 이 가격표는 아무런 답도 주지 못합니다. 진짜 선택해야 할 문제는 각 모델을 감싸는 런타임(Runtime)으로서의 Claude Code 대 Codex의 비교, 그리고 완료된 작업(Task)당 각 조합에 실제로 들어가는 비용입니다.

제대로 된 테스트를 하려면 두 개의 런타임, 두 가지 설정, 두 벌의 결과가 필요하며, 리뷰어 한 명이 어느 터미널에서 어떤 diff가 나왔는지 기억해 내느라 애를 먹게 됩니다. 모델을 고르는 것은 설정 파일 한 줄이면 끝나지만, 둘을 실제로 비교하는 과정은 에이전트가 만들어내는 혼란의 축소판이나 다름없습니다.

핵심 요약 (TL;DR)

Claude Sonnet 5.5와 GPT-6 Sol은 토큰당 비용이 동일하며, 팀에서 이들을 구동할 때 일반적으로 사용하는 런타임에서 차이가 납니다. Sonnet 5.5는 Claude Code, Sol은 Codex를 사용합니다. Anthropic의 공식 출시 자료에는 GPT-6 Sol과 비교한 네 개의 행이 있습니다. Sonnet 5.5는 세 개 항목에서 확실한 우위를 보이지만, 네 번째인 FrontierCode는 노력 수준(effort)에 따라 결과가 갈립니다. 벤치마크에 따라 작업당 비용도 정반대로 나타납니다. FrontierCode에서는 Sonnet 5.5가 Sol의 최고 성능을 약 5분의 1 비용으로 따라잡는 반면, AA-Briefcase에서는 Sol의 최고 성능 구성이 작업당 2.67달러인 데 비해 Sonnet 5.5는 29.19달러가 듭니다. 하지만 이는 특정 벤더가 제공한 수치일 뿐입니다. 여러분의 코드베이스에서 두 런타임에 동일한 Task를 실행해 보고, 변경 사항을 승인하기까지 걸린 리뷰 시간을 측정하여 Sonnet 5.5와 GPT-6 Sol 중 무엇을 쓸지 결정하세요. Task를 기록의 중심으로 유지한다면 두 모델을 모두 병행해 사용하는 것도 훌륭한 해답이 됩니다.

공개된 수치가 실제로 보여주는 것

비교 가능한 데이터는 네 개의 행뿐입니다. Claude Sonnet 5.5 출시 발표 글에서는 Sonnet 5.5, Sonnet 5, Opus 5.5, 그리고 GPT-6 Sol을 비교하고 있으며, Sol의 수치가 명시된 항목은 다음 네 가지가 전부입니다.

이것은 한쪽 벤더가 발표한 자료입니다. OpenAI의 Sol 발표 글은 Sonnet 5.5가 나오기 6일 전에 올라왔기 때문에, 두 모델이 함께 실린 벤더 측 공식 비교표는 Anthropic의 자료가 유일합니다. 게다가 양쪽 수치 모두 버그와 관련된 전제 조건이 있습니다. Sonnet 5.5의 Artificial Analysis 테스트는 구조화된 출력(structured-output) 버그가 있던 프리릴리스 배포본을 사용했으며(현재는 해결됨), OpenAI 역시 최근 Sol의 이미지 이해 버그를 수정했으나 Artificial Analysis 및 Surge AI 점수에는 이 수정 사항이 반영되지 않았을 수 있습니다.

코딩 팀이라면 특히 주목해야 할 항목은 FrontierCode 행입니다. 이 항목은 이미 런타임 간의 비교이기 때문입니다. 52.1% 대 49.3%라는 수치는 Sonnet 5.5 기반의 Claude Code와 Sol 기반의 Codex CLI를 비교한 것으로, 실제 프로덕션 환경에 배포하게 될 조합 그대로입니다. 최대(max) 점수에 달린 각주도 이에 못지않게 중요합니다. FrontierCode는 요구 범위를 벗어난 코드 변경에 감점을 부여하는데, Sonnet 5.5는 최대 노력 수준에서 수많은 서브에이전트를 생성하는 Claude Code의 코드 리뷰 스킬을 더 빈번하게 실행했습니다. Cognition이 분석한 두 가지 사례에서는 이로 인해 타임아웃이 발생하거나 작업 범위를 벗어난 수정이 이루어졌습니다. 더 많은 노력을 기울일수록 diff가 커지고, 그만큼 검토해야 할 내용도 늘어난 셈입니다.

해당 페이지에서 Sol의 수치가 포함된 항목은 이것이 전부입니다. Terminal-Bench 4.0 및 CursorBench 4.0의 노력 수준별 차트에는 GPT-6 Sol 수치가 공개되지 않아 대신 GPT-5.6 Sol이 표시되어 있습니다.

제3자가 집계한 벤치마크도 하나 있습니다. Artificial Analysis에 따르면, 9월 29일 기준으로 Sonnet 5.5의 최대 노력 엔드포인트는 인텔리전스 지수(Intelligence Index)에서 56점을 기록하며 216개 모델 중 3위에 올랐습니다. 9월 23일 마지막으로 기록된 Sol의 점수는 48점이었습니다. 측정 일자도 다르고 지수 자체도 계속 변하는 데다, 두 수치 모두 여러분의 실제 저장소 환경을 측정한 결과는 아닙니다.

토큰당 비용이 아닌, 완료된 작업당 비용

토큰 가격이 같다는 사실은 실제 청구 금액에 대해 많은 것을 말해주지 못합니다. 작업당 소비되는 토큰 수는 모델, 노력 수준, 그리고 런타임에 따라 천차만별이기 때문입니다. Anthropic의 출시 페이지에는 두 모델이 공유하는 벤치마크 중 두 항목에 대해 노력 수준별 점수와 작업당 비용을 공개하고 있습니다.

먼저 FrontierCode를 살펴보겠습니다. Sonnet 5.5는 'high' 설정에서 작업당 0.42달러로 49.4%를 기록하여, Sol의 최고 기록인 49.3%(2.07달러)와 대등한 성능을 보입니다. Anthropic이 "작업당 비용이 약 5분의 1"이라고 요약한 이유입니다. 하지만 실제 실무에서 주의 깊게 봐야 할 부분은 그 아래에 있습니다. 'medium' 설정에서 Sonnet 5.5는 36.5%에 그쳐 Sol의 'low' 설정보다도 낮은 점수를 기록하는데, 바로 이 'medium'이 Claude Code에서 Sonnet 5.5의 기본 노력 수준입니다. Anthropic의 프롬프팅 가이드에서는 작업을 'high'로 시작하거나, 요구사항이 명확히 정의된 에이전트 코딩 작업에 대해서는 'medium'으로 시작할 것을 권장합니다. 기본값이라 무심코 지나치는 설정 하나가 비교 결과를 완전히 뒤바꿀 수 있습니다.

반면 지식 작업(knowledge-work) 벤치마크인 AA-Briefcase는 정반대의 양상을 보입니다. Sol의 최고 점수 구성은 작업당 2.67달러가 드는 반면, Sonnet 5.5의 최고 점수 구성은 29.19달러로 약 11배나 비싸며 점수 차이도 그리 크지 않습니다. Sol의 'max' 비용과 가장 비슷한 Sonnet 5.5의 설정은 'medium'(1.64달러)인데, 이 경우 1483점 대 1461점으로 Sol이 앞섭니다. 동일한 두 모델을 두고도, 결과물 대비 어느 쪽이 더 저렴한지에 대한 답이 정반대로 갈리는 것입니다.

프롬프트 캐싱은 이 격차를 좁히기도 하고 양상을 바꾸기도 합니다. Sonnet 5.5는 캐시된 입력 읽기 비용이 100만 토큰당 0.10달러이며, 5분 캐시 쓰기 비용은 2.50달러입니다(Anthropic 요금 안내). GPT-6는 캐시된 입력 읽기 시 90% 할인을 적용하여 기본 2달러 기준 0.20달러가 되므로, 캐시 읽기 비용 자체는 Sonnet 5.5가 절반 수준으로 저렴합니다. 차이는 캐시가 무효화되는 조건에 있습니다. OpenAI에 따르면 추론 노력 수준이나 도구 가용성을 변경해도 더 이상 캐시가 무효화되지 않습니다. 반면 Anthropic의 Sonnet 5.5 프롬프팅 가이드에서는 요청 간 최상위 노력 수준을 변경하면 캐시가 무효화된다고 명시하고 있으며, 베타 기능인 메시지별 노력 설정을 대안으로 제시합니다. 작업 중간에 노력 수준을 변경하는 에이전트를 운용한다면 청구서에서 그 차이를 확연히 체감하게 될 것입니다.

물론 이 수치들 중 그 어떤 것도 여러분의 '승인된 변경 사항당 실제 비용'을 대변하지는 못합니다. 당장 실행 비용이 저렴하더라도 재실행이 두 번 필요하고 코드 리뷰에 긴 시간이 들어간다면, 결국 그것이 가장 비싼 선택이 됩니다.

자체 코드베이스에서 직접 검증하는 방법

두 런타임에 동일한 Task를 실행하고, 사람이 그 결과를 검토하고 승인하는 데 들인 시간을 측정해 보세요. 구체적인 평가 기준은 자체 코드베이스에서 코딩 에이전트를 비교하는 방법에 정리되어 있으며, 이번 두 모델 조합을 위한 테스트 환경 구성은 다음과 같습니다.

Sharkly는 임의로 모델을 선택하지 않습니다. 에이전트 공식 문서에도 명확히 나와 있습니다. "에이전트는 런타임의 기본 모델을 따릅니다. 특정 모델 이름을 보장하거나 표시하지 않습니다. 모델 변경은 에이전트가 아니라 런타임 또는 Computer 도구 설정에서 진행하십시오." 따라서 실제 모델 설정은 Computer에서 이루어집니다.

• claude-sonnet-5-5 기반 Claude Code: Claude Code v2.1.284 이상이 필요합니다. Claude Code의 default 모델은 Pro, Max, Team, Enterprise 요금제 및 Anthropic API에서 Opus 5.5로 설정되어 있으므로, 설정을 직접 변경하기 전까지 Computer는 Opus를 실행합니다. 또한 sonnet 별칭이 Sonnet 5.5를 가리키는 것은 Anthropic API 환경뿐입니다. 따라서 해당 호스트에서 전체 ID를 고정하고 claude --model claude-sonnet-5-5 명령어로 확인해야 합니다. 세부 설정 경로는 Sharkly에서 Sonnet 5.5 에이전트 실행하기를 참고하세요.
• gpt-6-sol 기반 Codex: 해당 Computer의 Codex 설정에서 모델을 지정합니다. 세부 단계는 Sharkly에서 GPT-6 Sol 에이전트 실행하기에 정리되어 있습니다.
• 두 에이전트 모두 독립된 임시 작업 디렉터리 사용: 각 실행마다 격리된 디렉터리가 할당되며, 저장소 기반 실행 시 새로운 worktree를 준비할 수 있으므로 두 시도가 동일한 체크아웃 환경을 공유하지 않습니다.

그다음, 테스트를 실행하기 전에 계획을 미리 문서화해 둡니다.

Task:    SH-312, one real Task, same description and starting commit for both runs
Run A:   Claude Code Agent, claude-sonnet-5-5, effort: medium (Claude Code default) or high
Run B:   Codex Agent, gpt-6-sol, effort: whatever Codex on that Computer is set to, written here
Accept:  the same acceptance test for both
Record:  accepted y/n, human review minutes, reruns, files touched outside scope,
         provider cost from your own Anthropic and OpenAI bills
Decide:  after several Tasks of each kind you actually assign, not one

Task를 한 에이전트에게 할당하고, 다른 에이전트는 댓글에서 멘션하여 시작합니다. Sharkly에서는 명시적 멘션을 통해 담당자(Assignee)로 지정되지 않은 에이전트도 실행할 수 있습니다. 두 실행 결과가 동일한 Task로 취합되므로 두 개의 diff, 두 번의 테스트 실행 결과, 그리고 모든 질의응답이 개별 터미널 히스토리에 흩어지지 않고 하나의 타임라인에 모입니다. 단일 버그에 대한 평가 방식과 채점 기준표는 동일한 버그에서 Claude Code 대 Codex 비교하기를 참조하세요.

비교 시 가장 큰 가중치를 두어야 할 요소는 '리뷰 시간'입니다. Anthropic의 프롬프팅 가이드에 따르면 Sonnet 5.5는 모든 노력 수준에서 테스트 코드, 문서, 보조 파일들을 추가하는 경향이 있으며, 'low'와 'medium'에서는 긴 작업 초기에 조기 점검을 진행하고, 'xhigh'와 'max'에서는 추가적인 리뷰 라운드를 돌리거나 리뷰어 서브에이전트를 띄웁니다. 동일한 상황에서 Sol 기반의 Codex가 어떻게 반응하든, 직접 진행하는 테스트를 통해 그 차이가 명확히 드러날 것입니다. 이 모든 과정은 고스란히 사람의 리뷰 시간으로 이어지지만, 공개 벤치마크 점수에는 결코 반영되지 않습니다.

‘둘 다 사용’하는 것이 현명한 해답인 이유

공개된 벤치마크 수치만으로는 모두를 만족시키는 단 하나의 승자를 가려낼 수 없으며, 여러분의 자체 테스트 결과 역시 마찬가지일 수 있습니다. 우열을 가리기 힘든 결과가 나왔다면 그것은 실패가 아니라 유의미한 발견입니다.

리뷰 시간 차이가 거의 없거나, 소규모 팀이라 단일 구독과 단일 설정 환경을 유지하는 편이 더 낫다면 하나의 런타임을 선택하십시오. 오직 Claude Code만 사용하고 터미널 중심의 워크플로를 선호한다면 별도의 관리 계층 자체가 필요하지 않을 수도 있습니다. 반면 작업 유형에 따라 결과가 확연히 나뉘거나, 기존 워크플로를 갈아엎지 않고 다음 달에 기본 모델을 유연하게 교체하고 싶다면 둘 다 유지하십시오. '다음 달'이라는 가정은 결코 과장이 아닙니다. Opus 5.5, Sol, Luna가 같은 날 발표되었고, 불과 6일 뒤에 Sonnet 5.5가 나왔으니까요.

두 모델을 함께 운용하려면 런타임이 아닌 Task 자체가 단일 기록 저장소 역할을 해야 합니다. Sonnet 5.5의 thinking 블록을 다른 모델이 읽을 수는 없으므로, Task가 Claude Code 에이전트에서 Codex 에이전트로 넘어갈 때 내부 추론 과정은 전달되지 않고 Task에 명시적으로 기록된 내용만 이어집니다. 따라서 핵심 결정 사항, 전제 조건, 미해결 질문 등은 반드시 설명란이나 댓글에 남겨야 합니다. 일상적인 협업 구성 방식은 단일 코드베이스에서 Claude Code와 Codex 함께 사용하기에서 다루며, Claude 생태계 내에서의 라우팅 전략은 Sonnet 5.5 대 Opus 5.5 비교를 확인하십시오.

에이전트는 조사하고, 실행하고, 테스트하고, 보고합니다. 방향을 정하고, 권한을 부여하며, 최종 결과를 승인하는 것은 사람의 몫입니다. 런타임은 분기마다 바뀔 수 있지만, 요청부터 릴리스에 이르기까지 맥락, 진행 상황, 장애 요인, 결과물, 그리고 인간의 리뷰 내역은 언제나 한곳에서 투명하게 관리되어야 합니다.

지난주에 다루었던 기본 런타임으로서의 Opus 5.5 vs GPT-6 Sol 역시 거울을 보듯 똑같은 근거 데이터 문제를 안고 있었습니다. OpenAI의 발표 자료는 불과 몇 시간 뒤 구버전이 되어버린 이전 Claude 모델을 상대로 Sol의 벤치마크를 진행했기 때문입니다. 기본 설정을 명확히 기록하고, 여러분의 실제 코드에서 측정하며, 런타임은 언제든 변경 가능한 설정 값으로 유지하십시오. 특정 단일 생태계에 얽매이지 않고 여러 코딩 에이전트를 유연하게 활용하고 싶다면, 바로 그것이 Sharkly가 해결하고자 설계된 문제입니다. Computer 한 대를 연결하고, 런타임별로 Agent를 생성한 다음, 두 에이전트에게 동일한 실제 Task를 맡겨 보십시오.