GLM-5.3이 찾은 취약점 2,436건 — 40년 묵은 것도 있었는데, 세 벤치 중 앞서는 건 하나뿐입니다

GLM-5.3이 나왔을 때는 코딩 50퍼센트 향상이 헤드라인이었습니다. 그런데 공식 문서를 다시 열어 보니 그때 없던 절이 하나 붙어 있었습니다 — 보안 능력 이야기입니다. 만든 쪽 표현으로는 예상보다 빠르게 자란 능력인데, 숫자가 구체적이었습니다. 실제 코드베이스에서 취약점 2,436건을 찾았고 가장 오래된 건 약 40년 묵은 것이었습니다. 그런데 같은 문서가 바로 다음 문단에서 스스로 김을 뺍니다 — 벤치 셋 중 1위는 하나뿐이라고요.

📌 30초 요약

• 269개 프로젝트에서 2,436건을 찾았고 그중 1,097건이 중·고위험이라고 문서가 밝힙니다.
• 가장 오래된 취약점이 약 40년 전 것입니다. 커널·브라우저 엔진·네트워크 프로토콜까지 걸쳐 있습니다.
• 그런데 벤치 셋 중 1위는 하나뿐입니다. 나머지 둘은 최전선 모델에 한참 뒤집니다.
• 문서가 그 이유를 스스로 적습니다 — 가장 뒤처진 곳에서 능력이 가장 빨리 자란다고요.
• 이제 추론을 끌 수 없습니다. 끄고 쓰던 앱은 순서를 지켜 고치지 않으면 요청이 실패합니다.
• 코딩 플랜에는 이미 완전히 열렸습니다. API만 아직이고, 포인트 차감은 주말에 절반입니다.

40년 묵은 취약점까지

문서가 밝힌 경위는 이렇습니다. 이전 모델부터 중국의 여러 보안팀과 협업해 실제 코드베이스에 모델을 돌려봤고, 전문가 검토와 선별, 중복 제거를 거친 뒤 남은 것이 269개 프로젝트에 걸친 2,436건입니다. 이 중 1,097건이 중간 이상 심각도라고 적혀 있고요. 분포도 좁지 않습니다 — 시스템 커널, 운영체제, 브라우저 엔진, 오픈소스 인프라, 웹 애플리케이션, 네트워크 프로토콜입니다.

🕰️ "수십 년간 아무도 못 봤던 것들"

이 대목이 가장 눈에 걸렸습니다. 문서 표현으로는 상당수가 수년, 심지어 수십 년 동안 눈에 띄지 않은 채 남아 있었고 가장 오래된 것은 대략 40년 전으로 거슬러 올라간다고 합니다. 40년이면 그 코드가 사람 손을 수없이 거쳤다는 뜻입니다. 리뷰도 받았을 테고 정적 분석 도구도 돌았을 텐데 안 걸렸다는 얘기죠. 여기에 덧붙는 게 하나 더 있는데, 만든 쪽이 공개 원장을 따로 만들어 발견 건들이 공개 절차를 밟는 과정을 기록하고 있다고 합니다. 이미 공개된 것과 아직 절차 중인 것을 구분하고, 공개된 건에 대해서는 영향받은 프로젝트·심각도·식별 번호·그 취약점이 코드에 남아 있던 기간까지 적는다고요. 벤더 주장을 검증 가능한 형태로 내놓는 방식이라 이 부분은 후하게 볼 만합니다.

그런데 앞서는 건 셋 중 하나뿐입니다

같은 문서가 벤치마크 셋을 나란히 놓는데, 자기에게 불리한 쪽까지 그대로 적습니다. 세 벤치는 취약점 분석과 공격의 단계가 다릅니다 — 하나는 소스를 보고 결함을 찾아 재현되는지 확인하는 단계, 다른 하나는 실제 취약점을 더 깊이 추론하는 단계, 마지막은 시간을 정해두고 몇 건이나 끝내는지를 봅니다.

단계	GLM-5.2	GLM-5.3	최전선 모델	결과
찾아내기	77.2%	84.5%	83.8% · 83.6%	1위
깊이 추론하기	24.4%	54.4%	78.0% · 76.5%	2배 이상 올랐지만 뒤짐
시간 안에 끝내기	29건 · 39건	105건 · 130건	181건 · 247건	3배 넘게 올랐지만 뒤짐

📉 문서가 스스로 정리한 한 문장

표를 세로로 읽으면 규칙이 하나 보입니다. 단계가 올라갈수록 이전 모델 대비 향상 폭은 커지는데, 최전선과의 격차도 같이 커집니다. 찾아내기는 7.3포인트 올라 1위를 했고, 깊이 추론하기는 2배 넘게 올랐는데도 20포인트 넘게 뒤지며, 시간 안에 끝내기는 3배 넘게 올랐는데도 여전히 절반 수준입니다. 그리고 문서가 이걸 한 문장으로 요약합니다 — 능력이 가장 빨리 자라는 곳이 바로 우리가 가장 뒤처진 곳이다. 벤더 문서에서 보기 드문 서술이라 그대로 옮겼습니다. 뒤집어 말하면 지금 격차가 크다는 게 앞으로도 크다는 보장은 아니라는 뜻이기도 합니다.

토큰을 덜 쓰면서 점수는 올랐습니다

코딩 쪽에서 눈여겨볼 건 점수보다 점수를 내는 데 쓴 토큰입니다. 자체 벤치 기준으로 가장 높은 추론 강도에서 34.5퍼센트를 출력 토큰 약 7만 5천 개로 냈는데, 이전 모델은 23.4퍼센트를 9만 6천 개로 냈습니다. 점수는 약 47퍼센트 오르고 토큰은 22퍼센트 줄었습니다.

비교 대상을 바꾸면 더 선명해집니다. 한 단계 낮은 추론 강도에서 31.4퍼센트를 약 5만 토큰으로 냈는데, 문서가 나란히 놓은 상용 모델은 29.5퍼센트를 12만 토큰으로 냈습니다. 점수는 더 높은데 토큰은 2.4배 적게 쓴 셈이죠. 토큰이 곧 요금인 종량제에서는 이 차이가 그대로 청구서로 갑니다. 다만 문서가 곧바로 단서를 답니다 — 가장 높은 추론 강도 기준으로 39.5퍼센트를 낸 다른 상용 모델에는 여전히 뒤집니다. "어떤 모델보다는 앞서고 어떤 모델보다는 뒤진다"를 자기 문서에 같이 적어둔 것이라, 이 표는 비교적 곧이곧대로 읽어도 될 것 같습니다.

덧붙이면 베이스 모델은 이전 버전과 같습니다. 문서가 개선은 전부 사후 학습에서 나왔다고 밝힙니다. 공개 벤치 쪽 상승폭도 적어뒀는데 터미널 작업 벤치가 4.6에서 28.3으로, 소프트웨어 엔지니어링 벤치가 46.2에서 66.9로 올랐습니다. 사양은 텍스트 전용, 컨텍스트 100만 토큰, 최대 출력 12만 8천 토큰입니다. 저가 오픈모델로 갈아타는 선택지 전반은 제가 오픈모델 총정리 글에 묶어뒀습니다.

이제 추론을 끌 수 없습니다

동작 방식에서 하나가 바뀌었습니다. 추론을 끄는 설정이 더 이상 지원되지 않습니다. 대신 강도를 셋 중에서 고르는데 가벼움·강화·깊이 세 단계이고 기본값이 가장 깊은 단계입니다. 복잡한 코딩 작업이면 그 기본값을 권한다고 적혀 있고요.

⚠️ 순서를 어기면 요청이 실패합니다

문서가 이전 방식으로 쓰던 사람들을 위해 마이그레이션 주의사항을 따로 박스로 달았습니다. 요지는 이렇습니다 — 지금 추론을 끄고 쓰고 있다면, 모델 이름을 바꾸기 전에 먼저 추론을 켜고 강도를 가벼움으로 설정하라. 그러지 않으면 요청이 실패한다. 순서가 조건입니다. 모델 이름부터 바꾸면 그 순간 깨집니다. 자동화나 배치 작업에 모델 이름을 박아둔 경우라면 바꾸기 전에 설정부터 손봐야 한다는 뜻이고요. 그리고 이 변화에는 비용 측면도 있습니다 — 끄는 선택지가 없어졌으니 간단한 작업에도 최소한 가벼운 추론은 돌아갑니다. 짧은 요청을 대량으로 던지던 쪽이라면 강도를 가벼움으로 명시하는 게 사실상 필수가 됐습니다.

지금 쓸 수 있는 경로, 아직 못 쓰는 경로

제가 출시 소식을 정리했을 때는 API가 아직 준비 중이라는 점을 짚었습니다. 그 상태는 그대로인데, 반대쪽이 열렸습니다 — 문서가 코딩 플랜에서는 완전히 사용 가능하고 원하는 코딩 에이전트에 붙여 쓰면 된다고 적습니다.

경로	지금 상태	조건
코딩 플랜 구독	완전 사용 가능	개인·팀 플랜 각각 있음
모델 API	아직 준비 중	프로토콜 세 갈래는 이미 공개
과거 구독자	일부만 가능	세 프로토콜 중 하나로만

세 번째 줄이 놓치기 쉬운 조건입니다. 과거에 코딩 플랜을 구독한 적이 있다면, 만료된 구독까지 포함해서 지금은 세 프로토콜 중 한 갈래로만 모델 API에 접근할 수 있다고 문서가 적어뒀습니다. 앞으로 개선하겠다는 단서가 붙어 있고요. 그리고 요금 구조도 바뀌었습니다 — 포인트를 차감하는 방식으로 가면서, 비수기 시간대와 주말 하루 종일은 포인트를 절반만 쓴다고 합니다. 기존 크레딧 구조에서 시간 한도에 걸리던 이야기는 제가 코딩 플랜 크레딧 글에 정리해뒀는데, 계산 단위 자체가 달라진 셈이라 그 글의 셈법은 다시 볼 필요가 있습니다.

🙋 정직하게 밝혀둘 것

• 전부 만든 쪽이 낸 숫자입니다. 취약점 2,436건도, 벤치 점수도 제3자가 검증한 값이 아닙니다. 특히 코딩 점수의 근거인 벤치는 자체 제작한 비공개 벤치라 비교에 쓸 때 감안해야 합니다.
• 다만 검증 가능성을 스스로 높인 부분은 있습니다. 공개 원장에 영향 프로젝트·심각도·식별 번호·잠복 기간을 기록한다고 했으니, 시간이 지나면 확인이 가능한 형태입니다. 저는 그 원장을 직접 대조해 보지 않았습니다.
• "보안 능력이 늘었다"는 양날입니다. 찾는 쪽에 쓰이면 방어가 되고 반대면 아닙니다. 문서도 이 능력을 의도한 것보다 빠르게 자란 것으로 표현합니다. 다만 이 글은 공개된 벤치 수치와 공개 절차를 옮긴 것이고, 악용 방법은 다루지 않습니다.
• 제가 직접 돌려보지 않았습니다. 코딩 플랜에서 체감이 어떤지, 추론 강도를 낮췄을 때 품질이 얼마나 떨어지는지는 제가 잰 값이 없습니다.
• "40년"은 문서 표현 그대로입니다. "대략"이라는 단서가 붙어 있고 어느 프로젝트인지는 밝히지 않았습니다. "없다"가 아니라 "이 문서에 없다"는 뜻으로 읽어주세요.

🗺️ AI 지출 전체 지도

같은 점수를 절반 토큰으로 내면 그대로 요금이 절반입니다. 이번 문서의 토큰 효율 표가 실제로 재현되는지가 갈아탈지 말지를 정하죠. 구독과 종량제 고르기부터 캐시, 모델 조합, 상한 걸기까지 지금까지 확인한 것들을 일곱 단계 지도 한 장으로 묶어뒀습니다.

🔎 이번엔 「스스로」가 기준이 됐습니다

취약점을 많이 찾는다는 소식은 이제 흔해졌습니다. 그런데 새로 나온 모델은 사람 지시 없이 끝까지 스스로 간다는 이유로 자체 위험 평가에서 최고 단계를 받았습니다. 숫자보다 「누가 단계를 이끌었나」가 기준이 되고 있으니, 앞으로 발표를 볼 때 성능표와 안전 등급표를 같이 보세요.

자주 묻는 것

Q. 지금 갈아타도 되나요?

코딩 플랜을 쓰는 중이라면 이미 쓸 수 있습니다. 원하는 코딩 에이전트에 붙이면 되고요. 반면 API로 직접 호출하는 구조라면 아직 기다려야 합니다. 갈아타기 전에 확인할 건 둘입니다 — 추론을 끄고 쓰던 코드가 있는지(있으면 순서대로 고쳐야 합니다), 그리고 짧은 요청을 대량으로 던지는지(그렇다면 강도를 가벼움으로 명시해야 합니다). 무료로 시작할 수 있는 경로는 오픈코드로 붙이는 글에 적어뒀습니다.

Q. 베이스가 같은데 어떻게 이만큼 올랐나요?

문서 설명으로는 전부 사후 학습이고, 핵심은 학습 환경을 실제 업무에 가깝게 만든 것입니다. 예로 든 게 인상적인데 — 엔지니어와 같은 작업 환경을 통째로 주고 연산 클러스터·저장소·내부 문서·코드베이스·실험 결과에 접근하게 한 뒤, 병목을 진단하고 최적화를 구현하고 실험을 돌려 실제로 빨라졌음을 보이라고 시킵니다. 문서 표현으로 일부 과제는 숙련 엔지니어에게도 며칠짜리라고 합니다. 다만 이런 환경을 많이 만드는 게 어려워서 환경 자체를 자동 생성하는 파이프라인을 짰고, 여전히 사람 손이 상당히 들어간다고 스스로 밝힙니다.

Q. 취약점을 찾는 능력이 늘면 위험한 것 아닌가요?

방향이 양쪽이라 단순하게 좋다 나쁘다로 말하기 어렵습니다. 확인되는 사실만 정리하면 — 만든 쪽은 보안팀과 협업해 찾고, 전문가 검토를 거치고, 공개 절차를 원장으로 관리한다고 밝혔습니다. 그리고 벤치상 공격 단계로 갈수록 최전선 상용 모델이 더 앞서 있습니다 — 즉 이 능력이 이 모델만의 특성은 아닙니다. 실무자 입장에서 의미 있는 건 내 코드에도 수십 년 묵은 게 있을 수 있다는 쪽이라고 봅니다.

✨ 정리하면

헤드라인은 40년 묵은 취약점이지만, 문서를 끝까지 읽으면 그림이 더 정확해집니다 — 찾아내는 단계에서는 1위를 했고, 공격 단계로 갈수록 향상 폭도 격차도 같이 커집니다. 실무에서 지금 챙길 건 셋입니다. 코딩 플랜이면 이미 쓸 수 있고, 추론을 끄고 쓰던 코드는 순서대로 고쳐야 하며, 같은 점수를 절반 토큰으로 낸다는 표가 사실이면 그게 갈아탈 이유입니다.

※ 출처: Z.ai 공식 문서 docs.z.ai/guides/llm/glm-5.3 (2026-08-18 확인). 벤치 수치·취약점 건수는 모두 제조사 발표이며 제3자 검증을 거치지 않았습니다. 코딩 점수의 근거는 자체 제작 비공개 벤치라고 문서가 밝히고 있습니다. 비교 대상 상용 모델명은 문서에 실명으로 적혀 있으나, 벤더가 자사에 유리한 조건을 고를 수 있는 구조이므로 본문에서는 수치와 조건 위주로 옮겼습니다. 요금·플랜 조건은 변동될 수 있습니다.