스노우플레이크 CEO는 무승부라 했다. 반복 원장은 달랐다.

CEO가 거의 동률이라고 말하는 것과 그 아래의 반복 횟수를 읽는 것은 전혀 다른 일입니다. 그리고 이 이야기의 핵심은 바로 그 둘 사이의 간극에 있습니다.

Snowflake DuckDB 실험의 설계와 결과

2026년 6월 24일, Snowflake CEO 스리다르 라마스와미는 Zhipu/Z.ai의 오픈웨이트 GLM-5.2가 실제 코딩 작업에서 Anthropic의 Claude Opus 4.7과 경쟁력 있는 성능을 보였고, 비용은 훨씬 낮았다고 말했습니다 . 이 주장은 벤더의 마케팅 테스트가 아니라 Snowflake 내부 평가에 근거합니다. 현실 세계의 프로그래밍 과제 103개를 각각 세 번 시도하게 했고, 모델은 DuckDB와 Snowflake 플랫폼에서 동시에 실행되는 코드를 만들어야 했습니다 .

pass@3 결과는 거의 동률이었습니다. GLM-5.2는 문제의 66%를 풀었고 Opus 4.7은 67%를 풀어, 격차는 1%포인트였습니다 . 이 숫자는 조심해서 읽어야 합니다. SQL과 데이터 엔지니어링 과제만을 대상으로 하며, 한 도메인에서 한 명의 임원이 채점한 결과일 뿐, 동료 검토를 거쳤거나 공개적으로 재현 가능한 평가가 아닙니다.

라마스와미의 해석은 양면적이었습니다. 그는 GLM-5.2가 특정 크로스플랫폼 프로그램, 즉 DuckDB와 Snowflake 양쪽에서 동시에 실행되어야 하는 코드를 Opus가 풀지 못했을 때 유일하게 검증해냈다고 평가했습니다 . 동시에 그는 실패 양상도 지적했습니다.

라마스와미는 "특정 과제는 GLM만 풀 수 있었다"고 언급하면서도, 다른 과제에서는 GLM이 "너무 일찍 포기했고" 과도하면서도 효과 없는 검증 루프를 돌렸다고 보았습니다 (source: The Decoder, 2026-06).

이 결과를 리더보드에 대응시키기 전에 중요한 단서가 하나 있습니다. Snowflake가 비교 대상으로 삼은 것은 당시 프로덕션에 있던 Opus 4.7이었고, 현재 대부분의 공개 비교표는 더 새로운 Opus 4.8을 앞세웁니다 . 비교 대상이 같은 모델이 아니므로, 여기서의 근소한 동률을 저쪽의 근소한 동률로 그대로 옮겨갈 수는 없습니다. 다만 이 실험이 보여주는 것은 구체적이고 실제 작업부하에 근거한 데이터 포인트입니다. Snowflake 자체의 SQL 중심 과제에서 오픈웨이트 도전자는 프리미엄 모델과 1%포인트 이내에 들어왔고, 그 지점에 도달하는 비용이 다음으로 따져볼 문제입니다.

비용 차이는 어디서 생기고, 어디서 줄어드는가

정가 기준으로 큰 할인 폭이 있는 것은 사실이지만, 그 크기는 구매 방식에 따라 달라집니다. Z.ai 공식 가격에서 GLM-5.2는 입력 토큰 100만 개당 $1.40, 출력 토큰 100만 개당 $4.40이며, 캐시된 입력은 100만 개당 $0.26이고 캐시 저장은 한시적으로 무료로 표시되어 있습니다. Anthropic의 Opus 4.7은 모델 ID claude-opus-4-7 기준 입력 100만 토큰당 $5, 출력 100만 토큰당 $25입니다.

따라서 정가 기준 GLM-5.2의 입력은 약 3.6배, 출력은 5.7배 더 저렴합니다. 서드파티 라우팅을 쓰면 격차는 더 벌어집니다. OpenRouter는 GLM-5.2를 입력 $0.95 / 출력 $3로 표시하며, 이는 Opus 4.7 가격의 약 19%와 12% 수준입니다. 정확한 배수는 구매 채널, 캐싱 정책, 요청 구성에 따라 달라집니다. 그래서 "비용의 일부"라는 표현은 방향성으로는 탄탄하지만 고정된 숫자는 아닙니다.

하지만 토큰당 가격이 곧 과제당 지출은 아닙니다. Snowflake의 에이전트 실행에서 GLM-5.2는 Opus의 ~439M 토큰 대비 약 860M 토큰을 소비했습니다. 거의 두 배에 가깝습니다. 이런 오버헤드는 명목상 5.7배인 출력 가격 차이를 갉아먹습니다. 완료까지 두 배의 토큰이 필요한 모델은 토큰당 할인 폭의 절반을 되돌려주는 셈입니다.

그럼에도 이 작업부하에서는 계산이 여전히 Z.ai 쪽에 유리했습니다. 토큰 수가 약 2배 늘어도 3.6~5.7배의 가격 우위가 있으면 완료 과제당 비용에는 여유가 남습니다. 다만 경계 조건에서는 그림이 달라집니다.

• 토큰을 많이 쓰는 작업 — 긴 에이전트 루프나 대규모 컨텍스트 검색은 GLM의 반복 오버헤드가 실행 규모와 함께 커지므로 마진을 가장 빠르게 줄입니다.
• 지연시간에 민감한 작업 — 토큰이 많다는 것은 더 긴 실제 소요 시간을 뜻하며, 속도가 제약인 경우 달러 절감보다 더 크게 작용할 수 있습니다.
• 캐시에 잘 맞는 작업부하 — 프롬프트가 반복되는 경우 GLM의 $0.26 캐시 입력 가격은 경제성을 Z.ai 쪽으로 더 기울입니다.

모델 라우팅을 검토하는 빌더에게 실무적인 결론은 이렇습니다. 할인 폭은 가격표가 아니라 토큰 수 안에 있으므로, 자신의 과제 형태에서 직접 벤치마크해야 합니다.

반복 횟수는 두 배, 첫 시도 일관성은 낮음

토큰 격차는 반올림 오차가 아니라 지배적인 비용 변수입니다. Snowflake의 103개 프로그램 실행에서 Opus 4.7은 작업당 평균 80회 반복, 총 4억 3,900만 토큰을 사용한 반면, GLM-5.2는 평균 99회 반복, 약 8억 6,000만 토큰을 사용했습니다. pass@3 결과가 거의 동일했는데도 소비량은 거의 두 배였습니다 . 그만큼의 오버헤드가 있어도 할인 효과는 남지만, 줄어듭니다. 그리고 워크로드에 따라 줄어드는 폭도 고르지 않습니다.

첫 시도의 신뢰성도 또 다른 트레이드오프입니다. GLM-5.2는 첫 시도에서 문제의 47.6%를 해결했고, Opus 4.7은 53.7%를 해결했습니다. 약 6%포인트 차이입니다 . 재시도를 허용하는 배치 작업에서는 무시할 만한 수준입니다. 하지만 지연 시간에 민감하거나 단발성으로 끝나야 하는 경로, 예를 들어 인라인 에이전트 단계나 동기식 코드 수정 엔드포인트에서는 첫 시도 실패 하나하나가 추가 왕복 호출이 되고, 토큰 계산은 다시 Opus 쪽으로 기울어집니다.

공개 벤치마크도 비슷한 패턴을 보여줍니다. 다만 대부분은 Snowflake가 테스트한 4.7이 아니라 더 최신인 Opus 4.8과 비교합니다. Z.ai의 Hugging Face 카드 자체 보고치는 다음과 같습니다.

• SWE-bench Pro: GLM-5.2 62.1, Opus 4.8 69.2
• Terminal-Bench 2.1: 81.0 대 85.0
• SWE-Marathon: 13.0 대 26.0. 가장 긴 시간축의 작업에서 Opus 4.8이 가장 크게 앞섭니다

눈여겨볼 지점은 SWE-Marathon의 격차입니다. 과도한 반복이 누적되는 영역이 바로 지속적인 다단계 에이전트 작업이기 때문입니다.

Ramaswamy의 설명을 보면 이것은 고정된 한계라기보다 조정 가능한 문제에 가깝습니다. 그는 GLM이 때때로 "너무 일찍 포기했고", "과도하고 비효율적인 검증 루프"를 돌았다고 언급했습니다 . 이는 단단한 아키텍처 한계라기보다 프롬프트 엔지니어링 신호로 읽힙니다. 재시도 깊이를 제한하고, 중단 조건을 더 엄격히 하거나, 시스템 프롬프트에 명시적인 검증 예산을 넣으면 토큰 오버헤드의 상당 부분을 되찾을 수 있습니다. 즉, 오늘 측정한 작업당 경제성은 고정된 판정이 아니라, 더 낮출 가능성이 큰 바닥값에 가깝습니다.

지정학적 출처: Ascend 칩과 데이터 소재지 우려

그 경제적 바닥값 아래에는 특이한 공급망이 있습니다. GLM-5.2는 Z.ai의 오픈 웨이트 Mixture-of-Experts 플래그십 모델로, Hugging Face에 zai-org/GLM-5.2라는 이름으로 MIT 라이선스하에 2026년 6월 16일 공개되었습니다. 총 753B 파라미터를 갖고 있으며, 포워드 패스당 활성화되는 파라미터는 약 40B입니다 . 또한 사용 가능한 컨텍스트를 GLM-5.1의 200K에서 1M 토큰으로 확장했습니다 .

이 이야기를 단순한 가격 이야기 이상으로 만드는 것은 출처입니다. Decrypt에 따르면 GLM-5.2는 NVIDIA 관여 없이 전적으로 Huawei Ascend 칩에서 훈련된 것으로 전해졌습니다 . 다만 이를 확인된 사실이 아니라 보도된 내용으로 봐야 합니다. Z.ai는 하드웨어 관련 공시를 내놓지 않았습니다.

비용 수치에도 같은 단서가 붙습니다.

"훈련 비용 약 2,500만 달러," — Emad Mostaque의 추정으로 제시된 수치 (source: Decrypt).

이 숫자는 벤더 공시가 아니라 제3자의 해석입니다 . 방향성을 보여주는 신호로는 유용하지만, 회계 항목처럼 받아들일 수는 없습니다.

개발자 입장에서는 오픈 웨이트 라이선스가 거버넌스 계산을 바꿉니다.

• 호스팅 API: Z.ai 엔드포인트를 호출하면 규제 대상 워크로드에서 중국 데이터 소재지와 이전 문제가 생깁니다.
• 셀프 호스팅: MIT 라이선스의 다운로드 가능한 체크포인트는 이 문제를 통째로 우회합니다. 자체 인프라에서 웨이트를 실행하면 대부분의 엔터프라이즈 시나리오에서 국경 간 데이터 이전 우려가 사라집니다 .

구조적 패턴은 익숙합니다. Business Insider와 Axios는 모두 GLM-5.2를 또 하나의 DeepSeek식 순간으로 설명합니다. 중국에서 나온 오픈 웨이트 도전자로, 사용자가 다운로드하고 수정하며 자체 시스템 안에서 운영할 수 있어 폐쇄형 미국 제공업체에 대한 의존을 줄일 수 있다는 것입니다 . Axios는 이 반응이 중국이 얼마나 빠르게 격차를 좁히고 있는지에 대한 논쟁을 다시 불붙였다고 짚으면서도, 컴퓨트, 데이터, 인프라 제약을 고려하면 벤치마크 승리가 곧바로 프런티어 동급을 뜻하지는 않는다고 덧붙였습니다 . 2025년 초 DeepSeek R1과 같은 플레이북입니다. 달라진 점은 이제 워크로드가 채팅이 아니라 에이전트형 코딩이라는 점입니다.

재시도가 많은 환경과 한 번에 맞혀야 하는 환경

라우팅 전환을 검토하는 개발자라면, 결정 기준은 워크로드의 형태에 따라 깔끔하게 갈립니다. 재시도 비용이 낮고 허용되는 곳에서는 GLM-5.2가 경제적으로 더 나은 선택입니다. 반대로 한 번의 시도에서 반드시 맞아야 하는 곳에서는 Opus 4.7/4.8이 여전히 우위에 있습니다. Snowflake의 근소한 차이, 즉 pass@3 기준 66% 대 67% 는 세 번의 시도에서만 성립하므로, 이미 재시도를 전제로 설계된 하니스에 그대로 대응됩니다.

GLM-5.2가 유리한 경우:

• 벽시계 시간과 토큰 수가 빡빡하게 제한되지 않는 배치형 에이전트 작업.
• 설계상 재시도하는 pass@3 방식 하니스. Snowflake의 설정이 정확히 여기에 해당합니다.
• 검증 루프를 허용 가능한 오버헤드로 볼 수 있는, 지연 시간에 민감하지 않은 파이프라인.

Opus 4.7/4.8이 유리한 경우:

• 첫 시도에서 Opus가 53.7% 대 47.6%로 앞선 것처럼 , 단일 시도 정밀도가 필요한 작업.
• Snowflake 평가가 측정한 SQL/데이터 엔지니어링 영역 밖의 작업.
• 토큰당 예산이 고정된 경우. GLM의 약 2배 토큰 사용량 때문에 재시도 오버헤드가 비싸집니다.

SQL 밖의 독립 신호도 같은 방향을 가리킵니다. Semgrep의 사이버 벤치마크에서는 IDOR 탐지에서 GLM-5.2가 39% F1을 기록해 Claude Code의 32%를 앞섰고, 발견한 취약점당 비용은 약 $0.17였습니다 . 영역은 다르지만 방향은 같습니다. 큰 비용 할인과 함께 경쟁력 있는 정확도를 보인다는 뜻입니다. 이 보강 신호가 중요한 이유는 Snowflake 테스트가 공개 엔드포인트에서 재현 가능하지 않고, SQL 에이전트 영역에서 독립적으로 검증된 결과가 아직 없기 때문입니다.

결론은 의도적으로 좁게 잡아야 합니다. Ramaswamy는 내부의 특정 도메인 실행 한 건에서 동률이라고 했지만, 반복 기록은 그렇지 않았습니다. GLM은 99회 반복과 약 8억 6천만 토큰, Opus는 80회 반복과 약 4억 3,900만 토큰이었습니다 . Claude Code나 비슷한 하니스 안에서 Opus 호출을 GLM-5.2로 돌리기 전에, 반드시 자신의 작업으로 직접 평가를 돌리세요. 가격 차이는 실제입니다. 그 차이가 당신의 토큰 사용 패턴에서도 유지되는지, 그 숫자 하나가 결정을 좌우합니다.

자주 묻는 질문

pass@3란 무엇이고, 에이전트 코딩 성능 평가에서 왜 중요한가요?

Pass@3는 모델이 첫 시도만이 아니라 최대 세 번의 시도 안에 문제를 해결하는지를 측정합니다. 에이전트 하니스는 자동으로 재시도하므로, pass@3는 단일 시도 정확도보다 실제 성공률에 더 가깝게 맞닿아 있습니다. 이 관점 때문에 GLM-5.2의 낮은 첫 시도 성공률이 여기서는 치명적이지 않습니다. 첫 시도에서는 Opus가 53.7% 대 47.6%로 앞섰지만, pass@3에서는 GLM-5.2가 66%, Opus 4.7이 67%였습니다 . 하니스가 재시도한다면 pass@3를 봐야 하고, 그렇지 않다면 첫 시도 신뢰도가 더 중요합니다.

더 많은 토큰 사용량까지 반영하면 GLM-5.2의 완료 프로그램당 비용은 어느 정도인가요?

작업당 기준으로 보면, GLM-5.2는 더 많은 토큰을 쓰고도 여전히 더 저렴합니다. Snowflake 실행에서 GLM-5.2는 평균 약 8억 6천만 토큰을 사용했고, Opus는 약 4억 3,900만 토큰을 사용했습니다. 대략 2배입니다 . 하지만 정가 기준 출력 가격은 GLM-5.2가 100만 토큰당 $4.40, Opus 4.7이 100만 토큰당 $25입니다 . 따라서 토큰 수가 두 배가 되어도 약 5.7배의 출력 가격 격차를 메우지는 못합니다. 정확한 배수는 출력/입력 비율, 캐싱, 그리고 직접 구매인지 OpenRouter 같은 라우터를 거치는지에 따라 달라집니다. OpenRouter는 GLM-5.2를 입력 $0.95 / 출력 $3로 표시합니다 .

GLM-5.2를 셀프 호스팅할 수 있나요? 그러면 기업의 데이터 레지던시 우려가 해결되나요?

가능합니다. 가중치는 Hugging Face의 zai-org/GLM-5.2로 MIT 라이선스하에 제공되므로, 자체 인프라에서 실행할 수 있습니다 . 셀프 호스팅을 하면 Z.ai 서버로 API 호출을 보내지 않아도 되므로, 호스팅형 사용에서 제기되는 중국으로의 데이터 이전 우려를 제거할 수 있습니다. Mixture-of-Experts 구조 덕분에 전체 753B 파라미터 중 토큰당 활성화되는 것은 약 40B입니다 . 따라서 헤드라인 규모가 암시하는 것보다는 추론 요구 사항이 다루기 쉽습니다. 다만 753B 가중치를 서빙하려면 여전히 상당한 메모리가 필요합니다.

Snowflake 벤치마크는 제3자가 재현할 수 있나요?

현재는 아닙니다. 이 평가는 Snowflake CEO Sridhar Ramaswamy가 2026년 6월 24일 공개 발언을 통해 밝힌 내부 Snowflake 평가입니다 . 103개 작업 하니스, 세 번 시도 프로토콜, DuckDB와 Snowflake를 더한 테스트 스위트는 공개 다운로드가 불가능하므로, 외부자가 명시된 방식 그대로 다시 실행할 수 없습니다. 확정된 동료 심사 결과가 아니라 비중립 출처에서 나온 방향성 신호로 봐야 합니다. Snowflake는 더 저렴한 모델 라우팅에 이해관계가 있습니다. 실제 적용 전에는 자신의 워크로드로 벤치마크하세요.

Snowflake 테스트는 GLM-5.2를 Opus 4.7과 비교했나요, 아니면 더 최신 Opus 4.8과 비교했나요?

Opus 4.7입니다. 거의 동등하다는 표현은 그 체크포인트에만 구체적으로 적용됩니다. Z.ai의 Hugging Face 모델 카드를 포함한 공개 리더보드 표들은 GLM-5.2를 주로 더 최신인 Opus 4.8과 비교합니다. 이 경우 Anthropic은 더 넓은 격차로 앞섭니다. SWE-bench Pro에서는 69.2 대 62.1, Terminal-Bench 2.1에서는 85.0 대 81.0입니다 . 따라서 “Opus와 맞먹는다”는 표현은 Snowflake가 사용한 4.7 실행에 대해서는 정확하지만, Anthropic의 현재 최상위 모델까지 그대로 확장되지는 않습니다.