찾기와 뚫기는 달랐다

자료 기준: 2026년 8월 16일 오전, 한국 시간

오늘 가장 흥미로웠던 AI 소식은 점수 84.5가 아니었다. 같은 모델이 취약점을 찾는 시험에서는 높게 나오고, 실제 공격을 완성하는 시험에서는 훨씬 낮아졌다는 차이였다. 나는 이 간격이 오히려 유용하다고 봤다. “수상한 문을 찾는 능력”과 “그 문을 실제로 여는 능력”은 원래 다른 기술이다.

단, GLM‑5.3 수치는 Z.ai의 자체 발표다. 독립 기관이 같은 조건으로 재현하기 전에는 모델 간 최종 순위로 쓰지 않았다. 벤치마크 표에 금메달 그림을 붙이는 데는 1초가 걸리지만, 같은 트랙을 다시 까는 데는 시간이 든다.

1. 먼저 평가 질문을 둘로 쪼갠다

CyberGym은 실제 코드베이스에서 알려진 취약점을 재현하는 능력을 다룬다. ExploitBench와 ExploitGym은 그보다 복잡한 공격 개발 능력을 살펴본다. 이름이 비슷해도 문제 난이도와 성공 조건이 다르다.

내 평가표에서는 적어도 아래를 분리한다.

단계	묻는 질문	성공 기준
후보 탐지	수상한 코드 위치를 찾았나	파일·함수·원인을 근거와 함께 제시
재현	실제 오류를 다시 만들었나	고정된 테스트에서 같은 실패 발생
악용 가능성	권한·데이터 영향이 있나	격리 환경에서 영향 범위 확인
수정	안전한 패치를 만들었나	회귀 테스트와 사람 검토 통과

한 숫자로 합치면 탐지는 잘하지만 근거를 못 남기는 모델과, 느리지만 재현까지 끝내는 모델을 구분하기 어렵다. 평균 점수는 회의 시간을 줄여 주지만 사고 원인까지 줄여 주지는 않는다.

출처: CyberGym, ExploitGym, Anthropic exploit 평가 연구

2. 모델에게 바로 공격 권한을 주지 않는다

보안 모델이 의심 코드를 찾았다고 운영망에서 PoC를 실행하게 하면 안 된다. 내가 둘 실행 구조는 이렇다.

읽기 전용 분석 → 재현 계획 → 일회용 샌드박스 → 제한된 테스트 자격증명 → 결과 저장 → 샌드박스 폐기

샌드박스의 기본값은 외부 네트워크 차단이다. 필요한 패키지는 검증된 미러에서만 받고, 운영 비밀정보는 넣지 않는다. CPU·메모리·시간·프로세스 수에도 한도를 둔다. 성공 여부와 관계없이 파일 변경, 네트워크 시도와 명령 실행 로그를 남긴다.

에이전트에게 “안전하게 해”라고 프롬프트 한 줄 넣는 것은 안전장치가 아니다. 그건 공구함에 포스트잇으로 “손 조심”을 붙인 것에 가깝다. 손은 여전히 공구함 안으로 들어간다.

3. 발견과 수정 사이에 증거 묶음을 만든다

보안 AI가 만든 결과는 사람이 다시 확인할 수 있어야 한다. 나는 각 발견에 다음 묶음을 요구한다.

• 영향을 받는 파일과 정확한 버전
• 취약 조건과 입력값
• 최소 재현 테스트
• 실제 결과와 기대 결과
• 영향 범위와 확신 수준
• 제안 패치와 새 회귀 테스트

모델 설명이 그럴듯해도 테스트가 실패하면 ‘미확인’으로 돌린다. 반대로 모델이 설명을 서툴게 해도 재현 테스트가 안정적으로 실패하면 사람이 이어서 분석한다. 말솜씨와 취약점은 같은 커피를 마시지 않는다.

4. 모델 공급자보다 평가 계층을 오래 남긴다

Pax Silica처럼 AI 공급망 협력이 반도체·클라우드·모델까지 묶이면 국가와 산업별 사용 가능한 모델이 달라질 수 있다. 그래서 보안 파이프라인에 특정 모델 이름을 직접 넣지 않는다.

SecurityTask → ModelRouter → 후보 모델 → 공통 Evidence Schema → SandboxRunner

모델이 바뀌어도 동일한 취약 샘플, 시간 제한, 도구 권한과 판정 기준으로 다시 시험한다. 지역마다 모델이 달라도 결과 형식은 같게 유지한다. 이 구조가 있어야 “어느 모델이 더 유명한가”가 아니라 “우리 저장소에서 어느 모델이 더 잘 끝내는가”를 비교할 수 있다.

출처: 미 국무부 Pax Silica 자료, 한국 외교부 Pax Silica Summit 결과

5. 회사 발표 수치를 운영 승인으로 바꾸지 않는다

Axios 보도에 따르면 Z.ai는 GLM‑5.3 공개 가중치를 약 2주 미루고 안전성 검토를 진행할 계획이다. 이 조치는 필요한 출발점이지만, 회사가 발표한 성능과 안전성을 동시에 증명하지는 않는다.

내가 도입 전에 확인할 항목은 다음과 같다.

1. 모델 카드와 라이선스가 공개됐는가
2. 독립 평가에서 결과가 재현됐는가
3. tool calling과 긴 작업에서 권한 경계를 지키는가
4. 위험 요청의 차단과 합법적 방어 연구 허용 기준이 일관적인가
5. 로그·가중치·프롬프트 데이터 보관정책이 맞는가

출처: Axios의 GLM‑5.3 보도

내가 적용할 최소 운영선

• 탐지율과 exploit 성공률을 한 점수로 합치지 않는다.
• 모델은 운영망과 운영 자격증명에 직접 접근하지 않는다.
• 모든 주장에 재현 테스트와 증거 묶음을 붙인다.
• 모델별 성능보다 같은 평가 환경을 먼저 고정한다.
• 공개 전 안전성 검토와 독립 검증을 구분한다.

오늘의 결론은 AI가 버그를 찾았다는 말 뒤에 반드시 “어디서, 어떻게, 다시 되나?”를 붙이자다. 빨간 펜을 잘 쓰는 모델이 반드시 열쇠공은 아니다. 나는 일단 문 앞에 샌드박스부터 놓겠다.

이 기술이 실제 서비스와 지역정책에 미치는 영향은 하루이슈: 지도부터 펼쳤다에 이어 적었다.