Sonnet 5.5 vs GPT-6 Sol: 일상적인 코딩에는 무엇을 쓸까?

Claude Sonnet 5.5와 GPT-6 Sol은 일상적인 코딩에서 비교할 만하지만, 어느 한쪽이 모든 저장소 작업에서 더 저렴하다는 증거는 없습니다. Sonnet의 표준 Claude API 입력·출력 요금은 100만 토큰당 2달러·10달러입니다. GPT-6 Sol의 짧은 컨텍스트 표준 요금도 같지만, 긴 컨텍스트 요금은 별도로 다뤄야 합니다. 단가가 같아도 토큰 사용량과 성공률까지 같지는 않습니다.

이 글은 범위가 한정된 버그 수정, 작은 기능 추가, 코드 리뷰 단계에 쓸 모델을 고르는 개발자를 위한 안내입니다. 2026년 9월 29일 확인한 공식 문서와 독립 출시 평가를 사용했습니다. Ofox가 직접 수행한 코딩 대결 벤치마크는 아닙니다. 아래 절차는 순위표를 운영 환경의 보장으로 받아들이지 않고, 자신의 저장소에서 판단하기 위한 방법입니다.

먼저 실행 조건을 비교하자

출처: Sonnet 사양, GPT-6 Sol 모델 문서, OpenAI 요금. 서로 다른 공급사의 effort 이름을 동등한 설정으로 간주하지 않았습니다.

출시 평가가 알려주는 것과 한계

Artificial Analysis는 Sonnet 5.5가 높은 effort에서 좋은 결과를 내는 동시에 많은 출력 토큰을 소비한다고 설명합니다. 비용 대비 능력 분석에서 Sonnet high는 한 Sol 구성과 가까웠지만 다른 설정의 균형은 덜 유리했습니다. 대표 점수만 보고 고르기보다 둘 다 시험할 이유가 됩니다.

평가 기관은 구조화 출력 버그가 있던 출시 전 Sonnet 환경을 테스트했으며 관련 평가를 다시 진행할 예정이라고 밝혔습니다. 이 조건을 빼면 안 됩니다. 공급사 차트, 서로 다른 벤치마크, 이전 배포 환경의 테스트를 같은 작업과 조건으로 실행한 것처럼 한 표에 섞을 수는 없습니다.

운영 팀의 질문은 더 구체적입니다. 우리 작업을 예산 안에서 해결해 검수를 통과하는 패치를 만드는 구성은 무엇일까요? 터미널 벤치마크는 에이전트 실행 능력에 관한 정보를 주지만 리뷰어의 시간, 프로젝트 규칙, 추가 배포 롤백 비용까지 측정하지는 않습니다.

범위를 정한 코딩 비교 실행하기

인상적인 데모 하나보다 대표 작업 여러 개를 고르세요. 실패하는 테스트가 알려진 회귀 수정, 명확한 합격 기준이 있는 기능, 미리 문제를 넣어 둔 리뷰 작업을 포함합니다. 어느 모델의 답변도 보기 전에 기대 결과를 정하고 입력에서 운영 비밀을 제외하세요.

각 시도에서 다음을 지킵니다.

1. 같은 깨끗한 커밋과 도구 권한에서 시작합니다.
2. 같은 이슈 설명, 저장소 지침, 관련 파일을 제공합니다.
3. 정확한 모델, effort, API 또는 구독 경로, 클라이언트 버전, 날짜를 기록합니다.
4. 같은 테스트를 실행하고 무관한 수정까지 포함해 최종 diff를 검토합니다.
5. 토큰 사용량, 캐시 구분, 재시도, 경과 시간, 사람의 리뷰 시간을 저장합니다.

세 번 재시도한 뒤 통과한 모델은 최종 패치가 비슷하다는 이유로 첫 시도 성공과 같다고 볼 수 없습니다. 반대로 한 번 실패했다고 모델이 해당 작업을 못 한다고 단정할 수도 없습니다. 승자 표시만 붙이지 말고 작업 수와 성격을 공개하세요.

재시도가 비용을 바꾸는 예

시도당 0.10달러라고 가정할 때 10번 시도로 10개 작업이 통과하면 작업당 비용은 0.10달러입니다. 다른 구성이 같은 10개 작업을 완료하는 데 0.07달러짜리 시도를 20번 했다면 통과 작업당 비용은 0.14달러입니다. 이는 가상의 숫자이며 Sol이나 Sonnet의 측정값이 아닙니다.

요청 한 건이 싸더라도 재시도 후에는 더 비쌀 수 있다는 뜻입니다. 실패 횟수도 별도로 보존하세요. 어려운 작업을 계속 포기하면서 그 실패를 집계에서 빼면 저렴한 모델이 실제보다 효율적으로 보일 수 있습니다.

대화형 작업에서는 시간도 중요합니다. 초당 출력 토큰 수만 보지 말고 쓸 수 있는 패치가 나올 때까지의 시간을 측정하세요. 첫 답변이 빨라도 디버깅을 한 차례 더 해야 한다면 전체 작업은 느릴 수 있습니다.

단가가 같아도 같은 비용이 아닌 경우

캐시 없는 입력 50,000토큰과 과금 출력 3,000토큰으로 고정하면 두 모델의 표준 짧은 컨텍스트 비용은 $0.10 + $0.03 = $0.13입니다. 이는 토큰 수를 고정해 요율만 비교한 계산입니다. 두 모델이 모두 3,000토큰, 한 턴으로 같은 답을 낸다고 예측하는 것은 아닙니다. 따라서 고정 사용량의 가격과 실제 검수 통과 작업당 비용을 별도로 봐야 합니다.

긴 입력에서는 요율 비교부터 달라집니다. 입력 300,000토큰과 출력 5,000토큰이면 Sol의 272K 초과 규칙이 전체 요청에 $4/$15를 적용해 $1.20 + $0.075 = $1.275가 됩니다. Sonnet의 공개 표준 $2/$10을 적용하면 $0.60 + $0.05 = $0.65입니다. 모두 캐시, 별도 도구, 비표준 서비스 옵션을 제외한 공급사 정가 계산입니다. 해당 조건의 요율 차이를 보여줄 뿐 Sonnet의 품질 우위를 증명하지 않습니다. 300K를 보내라는 뜻도 아닙니다. 무관한 맥락을 줄이면 예산과 검토 편의성이 함께 개선될 수 있습니다.

Sol 임계값 양쪽에 입력을 준비해 파일 크기 추정이 아닌 제공자의 실제 입력 토큰 수를 기록하면 경계를 확인할 수 있습니다. 초과 요율은 마지막 몇 토큰이 아니라 전체 요청에 적용됩니다. 따라서 이력을 조금 추가하는 것이 답변 길이의 작은 차이보다 더 중요할 수 있습니다. 이 경계를 예산 코드에 고정하기 전 현재 가격 문서를 다시 확인하세요.

구체적인 코딩 작업에서 출발점 정하기

아래 추천은 통합 비용과 검증 가능성에 근거한 편집 제안입니다. 공개하지 않은 벤치마크 순위가 아닙니다.

회귀 수정에는 실패 테스트, 실제 출력, 의도한 동작을 주세요. 유용한 답은 구현을 고치고 관련 없는 동작을 유지합니다. 테스트 기대값만 바꿔 통과시키는 것은 수정이 아닙니다. 기능 추가라면 이전 버전 호환성, 접근성, 데이터 마이그레이션이 범위에 드는지 편집 전에 정하세요. 그렇지 않으면 작업 범위를 임의로 좁힌 모델이 유리해집니다.

리뷰에는 확인된 결함과 정상 변경을 섞습니다. 결함을 찾아 검증 가능한 설명을 했는지뿐 아니라 정상 코드에 잘못된 문제를 제기했는지도 셉니다. 댓글이 많다고 유용한 것은 아닙니다. 추측성 경고 다섯 개가 정확한 한 개보다 검토 시간을 더 쓸 수 있습니다. 모델 자신의 확신은 독립적인 결함 확인이 아닙니다.

작업은 같게, API 의미는 각각 올바르게

공정한 비교를 위해 호환되지 않는 API에 동일 JSON을 보낼 필요는 없습니다. 작업, 소스 파일, 가능한 동작, 합격 조건을 같게 유지한 뒤 각 공급사의 올바른 요청 구조를 구현하세요. 어댑터 경계에서 도구 선언과 결과를 변환하고, 호출과 결과를 연결하는 식별자를 유지합니다. 여러 호출, 실패, 최종 텍스트를 루프가 모두 처리하는지 확인합니다.

도구 권한도 실험 조건입니다. 한쪽은 테스트를 실행하고 다른 쪽은 읽기만 한다면 그 차이를 표시하세요. 외부 부작용이 있는 도구는 양쪽 모두 격리된 데이터나 실제 실행을 하지 않는 대체물을 사용합니다. 현실적인 시나리오를 만든다는 이유로 진짜 이메일을 보내거나 운영 레코드를 바꾸거나 패키지를 게시하지 않습니다.

응답 형식과 모델 품질도 분리해서 진단합니다. 어댑터가 응답을 받고 필요한 내용을 추출하며 도구 결과를 제대로 전달했는지 확인한 다음 패치를 평가하세요. 잘못된 클라이언트 요청은 통합 준비 상태의 증거이지 모델이 문제를 못 푼다는 증거가 아닙니다. 운영 비용에는 포함하되 능력 점수에 넣는다면 별도 유형으로 표시해야 합니다.

평가표와 의사결정 규칙 만들기

시도마다 작업 ID, 기준 commit, 설정, 비용, 시간, 테스트 결과, 리뷰 판정, 실패 유형을 기록하세요. 모든 시도를 포함하는 작업별 요약도 만듭니다. 열 개짜리 파일럿은 단순히 80%가 아니라 “8/10 합격”이라고 써서 작은 분모를 드러냅니다. 변동이 큰 사례는 반복한 뒤 넓은 결론을 내리세요. 작은 내부 실험은 배포 판단 자료이며 통계적으로 확립된 보편 순위가 아닙니다.

합성 예를 들면 설정 A는 열 개 중 아홉 개를 총 $2.70에, B는 여덟 개를 $2.00에 완수했다고 합시다. 합격 작업당 $0.30와 $0.25입니다. 그러나 B가 놓친 작업이 출시를 막는 마이그레이션이면 낮은 평균으로 결정할 수 없습니다. 평균 옆에 실패 유형을 놓고 중요 작업에는 별도 완료 기준을 두세요. 반대로 더 비싼 설정이 설명만 늘리고 합격 작업을 추가하지 못하면 추가 비용을 정당화하기 어렵습니다.

출력을 보기 전에 규칙을 정합니다. 모든 중요 회귀 통과, 무관한 편집 없음, 기존 절차 안의 검토 시간이라는 제약을 만족한 후보끼리만 비용을 비교할 수 있습니다. 다른 팀은 대화 지연 시간을 우선할 수 있습니다. 이는 제품 요구사항이지 공급사의 사실이 아닙니다. 나중에 결과를 공개할 때 규칙도 공개해야 독자가 자기 작업에 적용할 수 있는지 판단할 수 있습니다.

전환에는 유지 비용도 듭니다. 새 어댑터 개발 시간을 예상 처리량에 나눠 반영하되 임의의 시급을 만들거나 토큰 청구액에 숨기지 마세요. 소규모 사용에서는 작업당 몇 센트보다 안정적인 통합이 중요할 수 있고, 대규모 사용에서는 작은 실측 절감도 전환을 정당화할 수 있습니다. 입력 단가만으로는 어느 쪽도 결론 낼 수 없습니다.

어느 모델부터 시험할까

이미 검증된 Claude 도구 루프가 있다면 API 계열을 바꾸는 것보다 Sonnet을 시험하는 데 클라이언트 작업이 적게 들 수 있습니다. 다만 5.5 마이그레이션은 여전히 확인해야 합니다. OpenAI 도구 중심의 흐름이라면 Sol을 기존 비교 기준으로 유지하는 것이 자연스럽습니다. 이는 연동 비용에 관한 판단이지 능력 순위가 아닙니다.

현재 연동으로 통제된 실험을 하기 쉬운 모델부터 시작하세요. 이후 다른 모델이 통과 작업당 비용, 시간, 패치 품질, 특정 실패율처럼 실제 측정한 결과를 개선할 때 전환합니다. Sonnet과 Sol의 비교를 모든 최상위 모델의 종합 순위로 확장할 필요는 없습니다.

입력·출력·캐시 과금은 Sonnet 비용 기록표로 나눌 수 있습니다. Claude 내부 선택은 Sonnet 5.5와 Opus 5.5 비교, OpenAI의 모델 등급 선택은 Sol·Luna·Astra 작업 가이드를 참고하세요.