Claude Opus 5.5 vs GPT-6 Sol: 팀의 기본 런타임 선택하기

설정 한 줄이 이번 분기에 팀 토큰 대부분이 어디로 흘러갈지를 결정한다. 2026-09-22, 그 한 줄에 들어갈 후보 두 개가 동시에 바뀌었다. Anthropic은 Claude Opus 5.5를, OpenAI는 GPT-6 Sol과 GPT-6 Luna를 출시했다. 여러 코딩 에이전트를 병렬로 돌리고 있다면, 문제는 어느 모델이 더 똑똑한가가 아니다. 여러분의 Agents가 기본값으로 어느 모델을 쓰는지, 그리고 그것이 사람이 승인하기를 기다리는 작업 큐에 어떤 영향을 주는지다.

근거에는 함정이 하나 있고, 두 출시 글 중 어느 것을 읽든 그 전에 알아둘 만하다. OpenAI는 Sol을 Claude Opus 5와 비교해 벤치마크했다. Opus 5.5가 아니다. 그 글이 작성될 당시 Opus 5.5는 존재하지 않았고, 불과 몇 시간 뒤 백만 입력 토큰당 $4, Opus 5의 $5에 맞서 출시됐다. 따라서 OpenAI 글에 나오는 모든 “훨씬 저렴한 비용으로 Opus 5를 능가한다”는 문구는 같은 날 대체된 모델을 기준으로 측정된 셈이다. 그렇다고 숫자가 틀린 것은 아니다. 다만 현재의 숫자가 아니라 마지막으로 공개된 숫자가 된 것이다.

TL;DR

기본 Runtime은 아무도 따로 지정하지 않았을 때 Agents가 사용하는 모델이며, 실제로는 대부분의 실행이 여기에 해당한다. 세 가지 축으로 고르면 된다. 완료된 작업당 비용, 사람의 개입 없이 작업을 얼마나 오래 붙들고 있는지, 그리고 막혔을 때 어떻게 하는지다. 공개된 수치만 보면 Sol이 완료된 작업당 더 저렴하지만, 공개된 유일한 비교 대상이 Opus 5이고, 멈추지 않고 긴 작업을 계속 유지하는 쪽은 Opus 5.5다. 두 모델을 공통 하네스에서 서로 맞붙여 돌린 사람은 아무도 없으니, 두 출시 글 모두 벤더의 주장으로 취급하고 직접 여러분의 저장소에서 판단하라.

각 벤더가 실제로 공개한 것

Anthropic은 Opus 5.5가 Opus 5보다 실행 비용이 40% 적고, 출력 속도는 약 30% 빠르며, 18시간 이상 작업을 유지한다고 밝힌다. 최대 출력은 128k 토큰이고, 고속 모드는 별도로 $8 / $40에 책정된다.

OpenAI는 Sol과 Luna가 각각 GPT-5.6 프로모션 가격보다 50% 저렴하다고 밝힌다. ‘프로모션’이라는 단어는 OpenAI가 직접 쓴 것이고 중요하다. 비교 대상이 정가가 아니라 할인된 요금이라는 뜻이기 때문이다. OpenAI는 또 GPT-6 Astra가 “전반적으로 계속 우리의 최고 모델”이라고 말하는데, 이는 Sol이 자사 제품군의 가성비 등급이지 플래그십이 아니라는 점을 잘 보여준다.

축 1: 백만 토큰당 비용이 아니라 완료된 작업당 비용

토큰 가격은 실제로 지불하는 금액의 대리 지표일 뿐이다. 요금이 절반이어도 세 번 시도해야 하는 모델은 한 번에 끝내는 모델보다 비싸다. OpenAI는 점수와 함께 작업당 비용을 공개하는데, 이는 드물게 직접적인 방식이다.

사람들이 인용하는 건 첫 번째 행이다. 매우 높음 추론 설정의 Sol은 최대 추론의 Claude Opus 5보다 높은 점수를 기록하면서, 작업당 비용은 Opus 5의 약 9%에 불과하다. $0.27에 11.1을 곱하면 그 하네스에서 최대 설정의 Opus 5는 작업당 약 $3이 되는데, 이는 OpenAI가 인쇄한 숫자가 아니라 OpenAI의 두 수치로 우리가 계산한 값이다.

이제 그 함정을 적용해 보자. Anthropic은 Opus 5.5의 실행 비용이 Opus 5보다 40% 적다고 하니, 그 $3이라는 수치는 이미 낡았다. 그렇다고 정확히 40%만큼 떨어지는 것도 아니다. 작업당 비용은 정가만이 아니라 모델이 거기까지 가는 데 태우는 토큰 수에 따라 달라지기 때문이다. 공개된 격차는 컸고, 그 한쪽이 같은 날 명시된 만큼 움직였으며, 아무도 그 비교를 다시 돌리지 않았다. 여러분의 코드베이스에 대한 그 숫자가 필요하다면, 연구소가 대신 돌려주기를 기다리지 말고 직접 저장소에서 비교를 실행하라.

규모를 가늠해 보자. OpenAI에 따르면 중간값에 해당하는 연구원은 코딩 에이전트에 하루 $600 이상을, 90번째 백분위는 하루 $7,000을 쓴다. 작업당 비용은 금세 추상적인 개념이 아니게 된다.

축 2: 작업을 얼마나 오래 붙들고 있는가

두 벤더는 같은 문제를 서로 다른 지점에서 해결했다.

Anthropic은 모델 차원에서 해결했다. Opus 5.5는 18시간 이상 작업을 유지한다. 근무 시간보다 오래 살아남는 실행은 감독 방식을 바꾼다. 지켜보는 대신 다시 돌아오게 되는데, 이게 제대로 작동하려면 실행 결과가 여러분이 닫아버린 터미널이 아닌 다른 곳에 보고돼야 한다.

OpenAI는 캐시 차원에서 해결했다. GPT-6는 캐시된 입력 읽기를 90% 할인하고, 기본적으로 적중률을 높이며, 에이전트 작업에서 중요한 점인데, 추론 강도나 사용 가능한 도구 집합을 바꿔도 더 이상 캐시를 깨뜨리지 않는다. 명시적 브레이크포인트를 통해 캐시 접두사가 어디서 끝나는지 직접 고를 수 있다. GitHub는 수십억 건의 요청에서 새로 처리해야 하는 프롬프트 토큰이 50% 이상 줄었다고 보고한다. 긴 에이전트 실행은 대부분 같은 컨텍스트를 여러 번 읽는 것이므로, 이는 지속 시간 자체를 고치는 게 아니라 지속 시간에 드는 비용을 고치는 해법이다.

Opus 5.5를 기본값으로 삼아야 하는 경우는 일반적인 Task가 마이그레이션이나 넓은 범위의 리팩터링, 또는 중간에 멈추는 비용이 토큰보다 큰 작업일 때다. Sol을 기본값으로 삼아야 하는 경우는 일반적인 Task가 범위가 한정되어 있고, 하루에 여러 번 반복되며, 재시도가 저렴할 때다. 대부분의 팀에는 두 종류가 모두 있으므로, 기본값을 정하는 일보다 예외를 의식적으로 다루는 일이 더 중요하다.

축 3: 막혔을 때 무엇을 하는가

이 축에는 벤치마크가 없고, 정작 지원 요청을 만들어내는 건 이 축이다.

두 벤더가 아닌 제3자인 Artificial Analysis는 “max” 추론 변형을 측정했는데, Sol은 초당 출력 토큰 115.2개에 첫 토큰까지 102.15초, Luna는 초당 153.9개에 124.23초였다. 이는 최대 노력 설정이며, 여기에 걸기 전에 현재 목록과 대조해 확인하는 게 좋다. 중요한 건 형태다. 높은 추론 강도에서는 저렴한 모델이 빠르게 시작하는 모델이 아니다.

102초 동안 생각 중인 에이전트와 멈춰버린 에이전트는 터미널에서 똑같아 보인다. 40분 전에 끝난 것과 아무도 못 본 질문을 하려고 멈춘 것도 마찬가지다. 어떤 모델 출시도 이걸 해결하지 못한다. Task로 되돌아오는 상태가 해결한다. 진행 중, 사람 대기, 실패, 릴리스 준비 완료 — 로그와 질문을 함께 붙여서. Agents는 조사하고, 실행하고, 테스트하고, 보고한다. 사람은 방향을 정하고, 권한을 부여하고, 결과를 승인한다.

각 Runtime이 진행 상황과 실패를 어떻게 알리는지에도 벤치마크 표와 같은 비중을 두어라. 상태는 일주일에 백 번 읽게 되지만, 벤치마크는 한 번 읽는다.

두 벤치마크 표를 나란히 놓지 마라

두 벤더 모두 이번 주에 AutomationBench 수치를 공개했다. OpenAI는 매우 높음 추론 설정의 Sol이 AutomationBench 1.0.6에서 33.2%를 기록했다고 밝혔다. Anthropic은 Opus 5.5가 AutomationBench에서 40.0%를 기록했다고 밝혔다. 둘 다 OSWorld 2.0을 보고했는데 각각 60.5%와 81.8%이고, OpenAI의 수치는 오프라인 세트 기준이다.

이것들은 정면 대결이 아니다. 추론 설정도 다르고, 최소 하나는 벤치마크 변형도 다르며, 하네스도 다르고, 공유된 작업당 비용 수치도 없으며, 각각 이해관계가 있는 쪽이 직접 돌린 것이다. Opus 5.5와 GPT-6 Astra를 특정 수치로 비교한 글들은 벤더 데이터가 아니라 트윗이다. Artificial Analysis는 하나의 공통 지수는 공개하는데, Opus 5.5가 58로 212개 모델 중 1위, Sol이 48, Luna가 37이며, 이는 여러분의 코드베이스를 측정한 게 아니라 제3자의 집계다.

다음 출시에도 살아남는 결정

기본값을 문서로 남겨라. 누군가 머릿속에 품은 선호가 아니라 Agent에 붙은 규칙으로. 이 Agent는 이 Runtime으로 돌아가고, 이런 Tasks는 여기로 가며, 일상적인 작업은 더 저렴한 저 Agent가 맡는다는 식으로. 팀이 읽을 수 있는 곳에 이렇게 적어두면 된다.

Default Runtime: Claude Code on claude-opus-5-5
  Tasks: migrations, wide refactors, anything that fails badly halfway
Second Runtime: Codex on gpt-6-sol
  Tasks: bounded, repeated many times a day, cheap to retry
Escalation: a Sol Task that fails twice returns to the Task for a person,
  it does not silently re-run on the expensive Runtime

그렇게 해야 어떤 모델이 어떤 작업을 맡는지가 처리량으로 바뀌고, 다음 출시에도 살아남는다. 답이 바뀌면 여섯 명에게 뭘 쓰고 있었는지 물어보는 대신 규칙 하나를 고치면 되기 때문이다. 두 연구소가 같은 날 각자의 가장 강력한 가성비 등급을 내놓았고, 그중 하나는 몇 시간 만에 낡아버린 모델을 상대로 벤치마크했다. 한 곳에서 바꿀 수 있는 기본 Runtime이 이번 주에 정답을 고르는 것보다 가치 있다.

두 출시가 바꾸지 않은 것이 바로 큐다. 완료된 작업당 비용은 양쪽 모두 크게 떨어졌으므로, 같은 예산으로 지난주보다 몇 배나 많은 에이전트 작업을 끝낼 수 있다. 하지만 리뷰어 시간은 한 시간도 더 사지 못한다. 리뷰 용량이 상한이고, 가격 인하는 그 부담을 덜어주기는커녕 물량을 상한 쪽으로 밀어붙인다. 요청부터 릴리스까지 목표, 실행, 병목, diff, 사람 리뷰를 한곳에서 볼 수 있게 유지하면, 기본 Runtime은 판돈이 아니라 설정이 된다.

Sharkly는 모델을 실행하지도, 대신 골라주지도 않는다. 모델을 실행하는 도구들 둘레의 공유된 Task, Computer, 컨텍스트, 리뷰 계층이다. 하나의 생태계에 전념하는 대신 여러 코딩 에이전트를 계속 쓰고 싶다면, 바로 그 문제를 위해 설계됐다. Computer 하나를 연결하고, 각 Runtime마다 Agent 하나씩 만들어, 똑같이 지루한 Task를 맡겨라.