독자 = API를 통해 모델을 전환하며 개발하는 사람; 얻어갈 수 있는 것 = 반복 검증 설계 및 3개 모델의 사용처 판단 기준.
모델을 교체할 때, 많은 사람은 몇 건의 요청으로 테스트합니다. 이로 인해 큰 문제가 발견되기도 하지만, 안정성은 알기 어렵습니다.
한 번의 실패가 '우연'인지 아니면 '해당 모델의 고질적인 특성(癖)'인지는 한 번으로는 구별할 수 없기 때문입니다. 같은 문제를 5번 던져보면 이 두 가지를 구분할 수 있습니다.
2026년 10월 28일, Sonnet 4.6, Sonnet 5.5, GPT-6.1 Sol 세 모델에 동일한 12문제를 각각 5회씩 던져 총 180회의 호출을 진행했습니다. 여기서는 그 설계와 결과, 그리고 실무에서의 사용처를 정리합니다.
같은 프롬프트를 단 한 번만 던지면, 돌아온 답변이 좋았는지 나빴지만 알 수 있습니다.
알고 싶은 것은 그 다음입니다. 매번 같은 방식으로 실패하는 것인지, 아니면 5번에 한 번 정도 무너지는 것인지. 전자는 모델 변경이나 검사 추가가 필요하고, 후자는 재시행으로 흡수할 수 있습니다. 비용의 규모 자체가 달라집니다.
그래서 횟수를 늘렸습니다. 12문제 × 5회 × 3모델로 총 180회입니다.
과제는 작고 정답이 유일하게 결정되는 문제들로 구성했습니다. 계산, 확률, 글자 수 제한이 있는 용어 설명, 구조화된 출력, 코드 재작성 등이 포함되었습니다.
8문제는 자동 판별이 가능했고, 4문제(코드 및 재작성)는 사람이 직접 확인해야 하므로 통과율에는 포함하지 않았습니다.
| 모델 | 자동 판별 통과 건수 | 중앙값 응답 시간 | 1회당 비용 |
|---|
| Sonnet 4.6 | 30/35 | 3.29초 | 0.0033달러 |
| ... | | | |
분모가 40으로 맞춰져 있지 않은 이유는, 180회 중 13회가 네트워크 오류로 판별할 수 없었기 때문입니다. 여기서 분모를 맞추게 되면 모델이 아닌 회선을 비교하게 됩니다.
첫 번째 차이는 가장 평범한 문제에서 나왔습니다. 'MoE를 60자 이내로 설명하고, '전문가'라는 단어를 사용하지 마시오'라는 지시였습니다.
3개 모델의 길이는 각각 65자, 58자, 48자였습니다. Sonnet 4.6만 상한선을 초과했습니다.
Sonnet 4.6의 출력(한국어 번역):
일종의 모델 아키텍처로, 네트워크를 여러 서브 모듈로 나누고, 입력마다 게이트 메커니즘이 소수의 서브 모듈을 동적으로 선택하여 계산에 참여시킴으로써, 계산량을 낮게 유지하면서 총 파라미터 수를 확장하는 방식입니다.
5자 초과였습니다. 내용은 정확하지만, 지시는 '60자 이내'라는 제약이지 제안이 아니었습니다.
나머지 4회도 시도했습니다. 길이는 각각 65자, 62자, 68자, 66자, 70자였습니다. 5회 모두 60자를 초과했습니다.
이는 계산 착오가 아닙니다. 모델은 '설명을 완성하는 것'을 우선시하고, '상한선에 맞추는 것'을 뒤로 미루고 있습니다. 글을 쓰는 상황에서는 장점이지만, 글자 수 체크가 필요한 배치 처리에서는 매번 손으로 줄여야 하는 작업이 발생합니다. 그 수고로움은 호출 비용보다 더 비싸게 돌아옵니다.
두 번째는 좀 더 조용한 차이였습니다. 1부터 5까지의 숫자 중 3개를 골라 합이 짝수가 될 확률을 구하는 문제였습니다. 정답은 3/5입니다.
Sonnet 5.5는 5회 중 4번 정답을 맞혔습니다. 틀린 1회의 추론 과정은 다음과 같습니다(한국어 번역 및 발췌).
세 개 모두 짝수: 짝수는 2와 4, 두 개밖에 없으므로, 세 개를 고를 수 없어 0가지 경우의 수입니다. 홀수 1개와 짝수 2개: C(3,1)×C(2,2)=3가지 경우의 수. 따라서 확률은 3/10입니다.
원래는 '홀수 2개와 짝수 1개'를 세야 하는데, '홀수 1개와 짝수 2개'로 착각했습니다. 조합의 수가 절반이 되고, 답도 절반이 되었습니다.
여기서 5회라는 횟수가 효과를 발휘합니다. 단 한 번만으로는 이 모델은 '완벽하다' 아니면 '사용할 수 없다' 중 하나로 보였을 것입니다. 실제로는 39/40으로, 문제 하나만 놓친 경우였습니다.
실무에서는 재시행으로 흡수할 수 있는 종류의 오류입니다. 모델을 바꿀 필요도, 검사를 추가할 필요도 없습니다.
세 번째는 비용입니다. Sonnet 5.5와 GPT-6.1 Sol은 100만 토큰당 입력 2달러, 출력 10달러로 동일한 단가입니다.
토큰 단가는 Sonnet 5.5의 요금 페이지에 기재되어 있습니다.
그런데 1회당 실비는 Sol이 0.0265달러, 5.5가 0.0047달러였습니다. 동일한 단가임에도 불구하고 5.6배 차이가 납니다.
차이는 단가가 아니라 문제 하나당 소비량에서 발생합니다. Sol은 중간 계산에 많은 토큰을 사용합니다.
그리고 이 추가 비용이 정확도를 구매해주지 못했습니다. 포물선과 직선이 접할 때의 접점 x좌표의 제곱을 구하는 문제에서, Sol은 5회 중 2번만 '4/5'라고 답했습니다. 정답은 16/5입니다. Sonnet 4.6과 5.5는 같은 문제를 5회 모두 정답 처리했습니다.
높고, 느리며, 다른 두 모델이 틀리지 않는 문제에서 2번 오류를 범합니다. 이는 '최상급 버전'이라기보다는 구조가 다른 모델이라고 생각하는 것이 자연스럽습니다.
12문제는 인공적인 소규모 문제입니다. 실무에 가깝게, 지원 티켓 20건에서 5개 항목(번호, 고객, 제품, 금액, 날짜)을 추출하는 작업도 시도했습니다. 총 100셀입니다.
세 모델 모두 100셀 전체를 정답으로 맞혔습니다. 정확도 면에서는 차이가 없습니다.
차이가 난 것은 속도입니다. Sonnet 5.5가 7.5초, GPT-6.1 Sol이 29.3초, Sonnet 4.6이 37.9초였습니다.
한 번당 30초의 차이는 작아 보일 수 있습니다. 하지만 하루에 1만 건이라면 84시간 이상, 즉 3일 이상의 계산 시간이 됩니다.
글자 수나 형식이 까다로운 처리(배치 생성, 구조화 출력, API 반환값)에서는 Sonnet 5.5가 가장 순응적입니다. 5회 모두 제한 위반이 없었으며, 중앙값 응답 시간도 가장 짧았습니다.
사람이 읽고 수정한다는 전제 하의 글에서는 Sonnet 4.6 그대로 사용해도 문제가 없습니다. 길고 정보량이 많은 출력은 해당 상황에서 장점이 됩니다.
GPT-6.1 Sol은 '저렴한 대체재'가 될 수 없습니다. 단가는 같지만 실비는 5.6배이며, 간단한 계산 문제에서 2번 오류를 범합니다. 선택하는 이유를 '싸기 때문에' 외에 설명할 수 있어야 합니다.
| 용도 | 판단 | 선택 모델 |
|---|
| 글자 수・형식을 엄수하는 배치 처리 | 교체 고려 | Sonnet 5.5 |
| ... | | |
| 표의 마지막 행은 사양에 근거한 판단이며, 이번 검증에서는 측정하지 않았습니다. | | |
측정된 것은 단일 턴(single turn), 짧은 입력, 정답이 명확한 과제뿐입니다. 긴 컨텍스트(context), 다중 턴 대화, 도구 호출(tool calling), 이미지 입력은 측정하지 않았습니다. 따라서 이 능력들에 대해서는 위의 표가 아무것도 말해주지 않습니다.
180회 중 13회는 네트워크 오류로 판정 불가했으며, 4문제는 수동 판정으로 집계에서 제외되었습니다. 요금은 2026년 10월 28일 시점의 모델 목록에 기재된 단가이며, 실제 청구액은 이용 상황에 따라 달라집니다.
동일한 절차를 자신의 과제로 돌려보는 것이 가장 확실합니다. 프롬프트를 하나 고정하고 5회 테스트하여 통과 수와 소요 시간을 기록하는 것만으로도, 기사의 결론보다 자신에게 맞는 판단을 내릴 수 있습니다.