GPT-6.1 Sol vs GPT-6 Sol: 일주일 만의 업데이트, Claude 5.5와 얼마나 관련 있을까?

GPT-6.1 Sol vs GPT-6 Sol: 일주일 만의 업데이트, Claude 5.5와 얼마나 관련 있을까?#

GPT-6 Sol이 출시된 지 일주일 만에 GPT-6.1 Sol이 나왔다. 이 출시 간격을 이해하려면 같은 시기에 나온 Opus 5.5와 Sonnet 5.5부터 살펴봐야 한다고 나는 생각한다.

두 회사의 출시 일정을 하나의 표에 놓으면 경쟁 구도가 뚜렷해진다.

날짜	출시 내용
9월 22일	OpenAI, GPT-6 Sol·Luna 출시; Anthropic, Opus 5.5 출시
9월 28일	Anthropic, Sonnet 5.5 출시
9월 29일	OpenAI, DevDay에서 GPT-6.1 Sol 공개

날짜는 두 회사의 공식 발표를 기준으로 했다.[1][2][4][5] Sonnet 5.5와 6.1 Sol의 공개 시점은 하루 차이다.

내 판단으로는 이번 출시 간격을 이해할 때 경쟁 압력을 가장 먼저 고려해야 한다. Opus 5.5는 복잡한 작업의 비교 기준을 높였고, Sonnet 5.5는 Sol이 노리는 일상 업무의 주력 모델 자리에 직접 뛰어들었다. DevDay는 이에 대한 대응을 한꺼번에 선보일 기회였다.

이 판단을 뒷받침하는 것은 출시 시점이 가깝다는 사실만이 아니다. 두 회사의 발표문에서 비교 대상이 뚜렷하게 달라졌다는 점도 있다.

6 Sol이 막 출시됐는데, 경쟁 상대는 이미 한 차례 바뀌었다.

9월 22일의 6 Sol 발표문은 AutomationBench 등의 평가에서 Opus 5와 비교했다. 그런데 6.1 Sol 발표문에서 OpenAI는 AutomationBench에서 6.1 Sol이 medium 추론 강도로 Opus 5.5보다 2.2%포인트 높은 점수를 기록했다고 명시했다. GDP.pdf에서는 테스트한 모든 추론 설정에서 폴백 메커니즘을 적용한 Opus 5.5보다 높은 점수를 기록했다고 밝혔다.[1][3]

이는 6.1의 출시 자료가 이미 새로운 질문에 답하고 있다는 뜻이다. 막 출시된 Claude를 상대로 Sol은 어떤 실제 업무에서 여전히 우위를 차지할 수 있을까?

Opus 5.5가 가한 압력에는 구체적인 내용도 있다. Anthropic은 대규모 코드 마이그레이션, 여러 저장소에 걸친 작업, 전문 분석, 장시간 자율 실행을 발표의 핵심으로 내세웠고, 여러 평가에서 GPT-6 Astra와 직접 비교했다.[4]

이는 Sol의 포지셔닝에 질문을 던진다. 사용자가 복잡한 작업에는 더 강력한 Claude를 선택할 수 있다고 생각한다면, Sol은 어떤 이유를 제시해야 사용자의 일상 업무 대부분을 계속 맡을 수 있을까? Astra의 성능만으로 이 질문에 대한 Sol의 답이 저절로 나오지는 않는다.

Sonnet 5.5는 여기에 압력을 한층 더했다. Anthropic은 Sonnet 5.5를 범위가 명확한 일상 업무, 버그 수정, 문서·슬라이드·스프레드시트 제작에 적합한 모델로 분명하게 포지셔닝했다. 지속적인 판단이 필요한 복잡하고 개방적인 작업은 Opus 5.5가 맡도록 했다.[5]

더 직접적인 대목은 Sonnet 발표문이 GPT-6 Sol을 지목했다는 점이다. 출시 페이지의 설명에 따르면 Sonnet 5.5는 FrontierCode의 high 설정에서 이미 6 Sol의 최고 점수와 동률을 이뤘다. 두 모델을 장기 지식 업무에서도 비교했다.

한쪽은 복잡한 작업의 성능 한계에 도전하고, 다른 한쪽은 매일 도구를 열 때 기본으로 선택하는 모델 자리를 노렸다. 이 두 차례의 출시는 Sol에 연속적인 압력을 가했다. 여기서 인용한 것은 두 회사의 출시 페이지에 실린 평가 내용이다. 이를 합쳐 동일한 조건에서 측정한 업체 간 종합 순위로 볼 수는 없다.

기본 모델이라는 자리에는 지속성도 있다. 사용자가 특정 모델에 맞춰 프롬프트, 결과 검수 방식, 도구 사용 절차를 조정하고 나면 이후 작업도 그 모델에 계속 맡기기 쉽다. 따라서 경쟁은 사용자가 주력 모델을 다시 고르는 시기에 벌어진다. 이번에 더 많은 일을 맡아 처리하는 모델이 다음에도 기본 선택지가 될 가능성이 높다.

이렇게 보면 “6 Sol이 이제 막 나왔다”는 사실이 반드시 기다려야 할 이유는 아니다. 버전의 신구 여부는 자사의 일정에 따라 정해지지만, 경쟁에서의 위치는 같은 시기에 다른 회사가 무엇을 내놓았는지에 달려 있다. 사용자가 도구를 다시 비교하는 상황이라면, 실제로 제공할 수 있는 개선을 갖춘 버전에는 서둘러 출시할 외부적 동기가 생긴다.

나는 6.1 Sol을 이 경쟁에 대한 신속한 대응으로 본다. 확인할 수 있는 것은 출시 순서, 명확하게 바뀐 비교 대상, 서로 겹치는 역량의 방향이다. OpenAI가 이 때문에 내부 출시 일정을 앞당겼는지는 아직 공개된 근거가 없다.

DevDay의 의미는 이 대응을 실제로 활용할 수 있는 환경까지 함께 마련했다는 데 있다.

같은 날 출시된 Codex Cloud의 재사용 가능한 개발 환경과 Agents API의 컴퓨터 사용 기능은 모두 모델이 직접 실행할 수 있는 작업 범위를 넓힌다.[2] 6.1 Sol은 ChatGPT 업무, Codex, API에서 이용할 수 있었으며, 당시 일반 채팅에서는 제공되지 않았다.[3]

모델의 역량과 실행 환경이 함께 개선돼야 사용자가 발표문 속 진전을 실제 업무로 가져올 수 있다. 환경이 완비될수록 모델이 스스로 문제를 찾아내고, 피드백을 이해하고, 해결 방안을 수정할 수 있는지가 최종적으로 무엇을 완성할 수 있는지를 좌우한다.

그래서 이번 업데이트에서 주목할 역량 변화는 경쟁사가 강조하는 방향과 상당히 겹친다. 복잡한 작업의 완성도, 지속적인 실행 능력, 그리고 실행 중 오류가 발생했을 때도 통제 가능한지 여부다. 이제 6.1이 6 Sol에 비해 얼마나 개선됐는지 살펴보자.

가장 무게 있는 근거는 이전 버전의 추론 강도를 최대로 높여도 새 버전의 더 낮은 설정에 뒤처졌다는 점이다.

DeepSWE v1.1에서 6.1 Sol은 더 낮은 추론 강도로 6 Sol의 최고 점수보다 6.4%포인트 높은 점수를 기록했다. 이 평가의 과제는 실제 코드 저장소에서 가져온 것으로, 장기적인 계획과 실행이 필요하다.[3]

이 비교는 매우 현실적인 질문과 맞닿아 있다. 어려운 문제를 만났을 때 기존 모델의 추론 강도를 계속 높이면, 부족한 부분을 과연 얼마나 메울 수 있을까?

실제 저장소에서는 접근 방향을 선택하는 단계에서 실패하기도 한다. 예를 들어 모델이 문제가 발생한 모듈을 잘못 짚은 뒤, 그 오판에 맞춘 테스트를 작성할 수 있다. 또는 일부 문제를 수정하면서 프로젝트에 이미 존재하는 호환성 제약을 놓칠 수도 있다. 그 방향을 따라 더 치밀하게 생각하더라도 방향 자체가 잘못된 수정안을 내놓을 가능성은 여전히 남는다.

DeepSWE 결과는 적어도 이 평가에서 6.1의 개선 효과가 6 Sol의 추론 강도를 더 높여 얻을 수 있는 범위를 넘어섰음을 보여준다. 이는 행동 선택과 피드백 활용의 질에 주목할 근거를 더해 준다. 다만 평가에서는 각 역량이 얼마나 기여했는지 분리해 분석하지 않았고, 구체적인 훈련 방법도 공개되지 않았다.

또 다른 근거는 AutomationBench다. 동일한 medium 추론 강도에서 6.1 Sol은 4.8%포인트 향상됐다. 이 결과는 “모든 개선은 모델이 더 오래 생각하게 한 덕분”이라는 설명을 받아들이기 어렵게 한다.

주요 수치를 한데 모으면 공통된 방향이 더 잘 보인다.

공식 평가	6 Sol 대비 6.1 Sol의 변화	해당 작업
DeepSWE v1.1	더 낮은 추론 강도로 이전 버전의 최고 점수를 6.4%포인트 상회	실제 저장소에서 수행하는 장기 소프트웨어 엔지니어링
AutomationBench 1.0.6	동일한 medium 설정에서 4.8%포인트 향상	47종의 도구를 사용하는 업무 워크플로
OSWorld 2.0	각 모델의 최대 추론 강도에서 7%포인트 향상	장기 컴퓨터 조작; 오프라인 평가 세트 v2026.08.08, 지표는 부분 보상 점수
Terminal-Bench Science 0.1	최대 추론 강도에서 이전 버전 점수의 두 배 초과	코드와 터미널을 활용하는 과학 연구 워크플로

이 작업들은 프로그래밍, 업무, 데스크톱, 과학 연구에 걸쳐 있지만, 모두 모델이 같은 순환을 반복해야 한다. 현재 상태를 이해하고, 행동하고, 피드백을 읽은 다음, 후속 행동을 조정하는 과정이다.

이 순환에서는 오류가 이후의 입력까지 바꾼다. 도구의 결과를 한 번 잘못 읽으면 이후 여러 단계가 잘못 파악한 상태를 바탕으로 진행될 수 있다. 엉뚱한 파일을 수정하면 새로운 오류가 발생하고, 원인을 찾는 과정이 더 멀리 빗나갈 수 있다. 따라서 긴 작업의 어려움에는 방향이 어긋났음을 알아차리고 제때 바로잡는 일도 포함된다.

이것이 내가 이해하는 6.1 업그레이드의 핵심이다. 여러 벤치마크가 함께 개선됐다는 것은 지속적인 실행에서 모델이 감당할 수 있는 범위가 넓어졌음을 시사한다. 이 결과만으로 계획, 피드백 이해, 오류 수정이 각각 얼마나 기여했는지 나눠 설명할 수는 없다. 그래도 개별적인 고난도 문제 하나의 결과보다는 이 판단을 더 잘 뒷받침한다.

발표문이 복잡한 PDF를 강조한 점도 같은 맥락에서 이해할 수 있다. GDP.pdf는 표, 차트, 도식, 작은 글씨로 적힌 세부 사항을 다룬다. 실제 업무에서는 표의 각주에 적힌 적용 조건을 놓치면, 이후 분석이 아무리 체계적이어도 첫 단계부터 잘못된 근거 위에 세워질 수 있다.

문서 이해는 전체 작업 흐름의 출발점이다. 이후 모델이 실제로 어떤 문제를 다루게 되는지를 결정한다. 공식 발표는 이 방향을 강조했지만, 본문에는 6 대비 6.1의 PDF 성능 개선 폭을 직접 인용할 수 있는 수치가 제시되지 않았다.

또 하나 과소평가하기 쉬운 개선은 시스템이 실패를 알아차릴 수 있는지에 관한 것이다.

공식 발표는 서로 다른 두 가지 신뢰성 데이터를 공개했다. 어려운 대화에서 xhigh 설정으로 생성한 답변 중 사실 오류가 포함된 비율은 4.5%에서 4.1%로 낮아졌다. 검색 도구 장애 테스트에서는 최대 추론 강도에서 장애 사실을 알리지 않은 비율이 4.9%에서 2.1%로 낮아졌다. 두 평가 모두 의도적으로 선별한 어려운 표본을 사용했다.[3]

이 역시 두 회사가 함께 경쟁하는 역량에 속한다. Opus 5.5 발표문도 허용된 범위를 벗어나는 행동을 줄이는 점을 강조했고, 더 긴 작업, 완수할 수 없는 작업, 실제 사고 상황을 정렬 테스트에 포함했다.[4] 두 회사의 테스트 기준은 다르지만, 사용자가 일을 맡길 때 느끼는 같은 우려에 답하고 있다. 모델이 장애물에 부딪히면 어떻게 행동할 것인가?

한 업무 절차를 가정해 보자. 모델이 다음 처리를 결정하려면 최신 정책을 찾아야 한다. 검색에 실패한 뒤 자료를 확보하지 못했다고 명확히 보고하면, 시스템에는 재시도하거나 다른 데이터 출처를 사용하거나 사람에게 넘길 기회가 생긴다.

반대로 모델이 마치 확인을 거친 듯한 답을 바로 내놓으면, 후속 단계는 그대로 진행될 가능성이 높다. 한 번의 검색 장애가 사용 가능한 근거로 포장되고, 심지어 최종 결과물까지 전달되는 것이다.

명확히 드러난 실패에는 여전히 복구할 여지가 남는다. 숨겨진 실패는 오류 수정 메커니즘이 작동할 계기 자체를 없앤다.

따라서 도구를 호출할 수 있는 모델에서 ‘솔직함’은 매우 구체적인 엔지니어링적 의미를 갖는다. 시스템이 언제 계속 진행하고, 언제 멈추며, 언제 상위 단계로 처리를 넘겨야 하는지 판단하는 데 영향을 준다.

6.1의 이 수치만으로 전체 업무 절차의 신뢰성이 높아졌다고 입증할 수는 없다. 재시도를 더 잘한다는 뜻도 아니다. 하지만 신뢰할 수 있는 실행에 필요한 한 가지 전제는 분명히 개선됐다. 계속 실행하는 데 필요한 근거가 없다는 사실을 모델이 인정하는지 여부다.

이와 연결되는 것이 발표문에서 언급한 제약 준수와 승인되지 않은 결과의 감소다. 모델이 더 오래 실행할수록 이러한 경계를 계속 유지해야 한다. 작업을 완수하는 능력과 언제 더 진행해서는 안 되는지 아는 능력이 함께, 모델에 얼마나 많은 자율성을 맡길 수 있는지를 결정한다.

다만 내가 직접 진행한 비교 테스트에서는 새 버전이 전반적으로 앞서는 결과가 나오지 않았다.

나는 이전까지 GPT-5.6 Sol을 오랫동안 주력으로 사용하다가 최근 GPT-6 Astra로 바꿨다. 내게 이번 비교는 실제 결정과도 관련이 있다. Sol의 발전이 내가 맡기는 일을 다시 배분할 만큼 충분한가?

9월 30일, 나는 Crazyrouter의 OpenAI 모델 연동을 통해 동일한 게이트웨이 채널에서 두 모델에 같은 문제와 시스템 프롬프트를 보냈다. 설정은 모두 reasoning_effort=high, 출력 상한은 8192 token으로 통일했다. 8개 유형의 작업을 각각 두 번씩 반복해 본 테스트에서 총 32회의 요청을 보냈으며, 최초 결과를 그대로 기록했다.

이번 실측	GPT-6 Sol	GPT-6.1 Sol
보낸 요청	16	16
완전한 답변 수신	16	14
문제 전체 정답	16	13
답변을 받았으나 오류 포함	0	1
약 240초 대기 후 타임아웃	0	2
전체 시도의 완료 시간 중앙값	21.52초	18.13초

6.1의 오류는 구체적이었다. 자료에서 조건에 맞는 항목은 실제로 72개였지만, 71개로 셌다. 질문에 잘못된 전제가 있다는 점은 이미 알아차렸는데도 한 항목을 누락했다. 두 차례의 타임아웃은 각각 긴 표 검색과 제약 조건 풀이에서 발생했으며, 같은 문제의 다른 한 차례 시도는 모두 통과했다.

작은 함수 문제 두 개에서는 두 모델 모두 모든 비공개 검사를 통과했다. 추가로 한 차례 진행한 2라운드 읽기 전용 도구 절차도 두 모델 모두 통과했다.

이 결과가 내게 일깨워 준 점은 다음과 같다. 주력 모델을 바꿔도 될지 판단하려면, 평가가 이전에 내가 직접 개입해야 했던 단계를 반드시 다뤄야 한다.

함수 문제 두 개에 경계 조건 검증을 수백 개 추가하면 코드의 정확성을 더 엄격하게 확인할 수 있다. 하지만 모델이 스스로 문제를 찾아내고, 저장소의 제약을 이해하고, 실행 결과에 따라 해결 방안을 바꿀 기회가 늘어나는 것은 아니다. 짧은 도구 사용 절차로는 십여 단계가 지난 뒤 상태를 놓치는 실패도 드러내기 어렵다.

따라서 이번 실측으로 “새 버전도 여전히 개수를 누락할 수 있고, 이 서비스 경로에서 타임아웃이 발생했다”는 기록은 남길 수 있다. 하지만 공식 발표가 주로 강조한 장기 실행 역량까지 다루지는 못했다. 현재 주력인 Astra를 곧바로 6.1 Sol로 교체할 만큼 충분한 근거도 얻지 못했다.

속도 역시 결과물과 함께 봐야 한다. 6.1의 대기 시간 중앙값은 더 짧았지만, 이번 테스트에서는 결과물을 받지 못한 요청도 두 건 있었다. 목표가 검수를 통과하는 수정안을 받는 것이라면, 첫 응답까지 걸린 시간은 전체 과정의 일부일 뿐이다. 재작업과 사람이 직접 이어받는 과정도 최종 소요 시간을 바꾼다.

이번 요청은 동시에 실행했고, 캐시 조건은 통일하지 않았다. 측정 시간에는 게이트웨이와 업스트림 서비스의 영향도 포함된다. 두 모델에 공통으로 사용한 다른 채널에서도 타임아웃이 발생한 적이 있다. 여기 기록한 것은 서비스 경로에서 관찰한 현상이므로, 이를 근거로 6.1 자체가 더 쉽게 타임아웃된다고 단정할 수는 없다.

내게 다음 비교에서 가장 중요한 질문은 이것이다. 같은 실제 작업을 맡겼을 때, 모델을 올바른 방향으로 되돌려 놓아야 하는 횟수는 몇 번인가?

예를 들어 검수 기준이 명확한 저장소의 버그를 선택한다. 문제 설명만 제공하고, 모델이 스스로 원인을 찾아 수정하고 테스트를 실행한 뒤 변경 사항을 제출하게 한다. 환경과 권한을 동일하게 맞춘 상태에서, 독립적으로 검수를 통과할 수 있는지, 사람의 교정이 몇 번 필요한지, 실패를 만나도 계속 진행할 수 있는지, 검증하지 않고 완료를 선언하는 일이 있는지 비교하는 것이다.

이렇게 하면 “모델이 더 강력해졌다”는 말을 관찰 가능한 변화로 구체화할 수 있다. 예전에는 내가 보완해야 했던 판단의 일부를 이제는 모델이 스스로 해낼 수 있는가?

6 Sol은 이미 에이전트 코딩과 전문 업무를 주력 역량으로 내세웠다. 6.1 Sol은 어려운 실행 과제의 성능을 한층 높였고, 실행 실패를 숨기는 한 유형의 행동도 줄였다. 사용량이 많은 사용자에게는 이 두 변화가 결합돼야 주력 모델의 교체로 이어질 수 있다.

다시 “일주일 만의 업데이트”로 돌아가면, 나는 Opus 5.5와 Sonnet 5.5의 경쟁 압력을 가장 중요한 외부적 설명으로 보고, DevDay를 개선 사항을 한꺼번에 선보이는 기회로 본다. 이 판단을 뒷받침하는 핵심은 두 회사가 이미 출시 자료에서 서로를 직접 비교하고 있다는 점, 그리고 6.1의 개선이 경쟁사가 확보하려는 업무 역량에 집중돼 있다는 점이다.

이 경쟁이 궁극적으로 노리는 것은 사용자가 다음에 코딩 도구를 열거나 전문 업무를 맡길 때 기본으로 선택하는 모델의 자리다. 내게 6.1이 그 자리를 차지할 수 있을지는, 지금까지 내가 반복해서 바로잡아야 했던 일을 제대로 맡아낼 수 있는지에 달려 있다. 한 번 덜 빗나가고, 완료했다는 잘못된 보고를 한 번 덜 하는 것이 버전 번호보다 더 설득력 있다.

---

자료 출처 및 테스트 설명:

[1] OpenAI: 「GPT-6 Sol과 Luna 소개」. 공식 사이트에 표시된 게시일은 2026년 9월 22일이다.

[2] OpenAI: 「DevDay 2026 돌아보기」. 2026년 9월 29일 게시됐으며, 본문에서 GPT-6.1 Sol을 발표했다.

[3] OpenAI: 「GPT-6.1 Sol 소개」. 이 글은 2026년 9월 30일에 확보한 공식 본문을 기준으로 작성했다.

[4] Anthropic: Claude Opus 5.5 소개. 2026년 9월 22일.

[5] Anthropic: Claude Sonnet 5.5 소개. 2026년 9월 28일.

실측은 https://api.crazyrouter.com/v1/chat/completions를 통해 진행했다. 본 테스트는 채널 266으로 고정하고 일반 버전 모델을 사용했다. 모델별 코드 검사 항목은 총 496개로, 함수 문제 두 개에서 각각 받은 출력 두 개를 검사한 수치이며 독립적인 작업의 수가 아니다. 이번 소규모 표본 테스트는 공식 벤치마크를 재현하지 않았으며, 실제 저장소의 장기 개발, 컴퓨터 조작, 복잡한 PDF도 다루지 않았다. 공식 점수는 개선 방향을 분석하는 데 사용했고, 자체 테스트 기록은 이번에 실제로 받은 결과물을 보여주는 데 사용했다.