누구나 돌리는 '거절 없는' LLM, 보안을 다시 짜야 할 1년

보안 연구자 jyn이 쓴 이 글의 문제의식은 단순하다. 위험한 해킹을 수행할 만큼 유능한 모델이 이제 소수 연구소의 통제된 서버가 아니라 개인의 책상 위 하드웨어에서 돌아가기 시작했다는 것이다. 저자는 오픈웨이트 모델 GLM 5.3-flash의 공개를 그 분기점으로 지목하며, 산업 전반의 취약점을 미리 찾아 고칠 시간이 약 1년밖에 남지 않았다고 주장한다. 흥미로운 역설은, 인간보다 빠른 프런티어 LLM 덕분에 사상 처음으로 방어 측도 그 일을 해낼 능력을 갖게 됐다는 점이다. 남은 진짜 난제는 취약점을 찾는 일이 아니라 고친 것을 실제로 배포하는 일이라고 저자는 못 박는다.

거절하지 않는 모델과 소비자용 하드웨어

GLM 계열은 중국 Z.ai(옛 Zhipu AI)가 개발한다. 회사가 직접 호스팅할 때는 법적 제약이 걸리지만, 가중치가 공개되면 사정이 달라진다. DeAlignAI 같은 조직이 거절 기능을 외과적으로 제거한 '어블리터레이션(abliterated)' 버전을 배포하기 때문이다. 저자에 따르면 이 변형은 허위정보·사이버범죄·생물무기 같은 불법 요청의 거절 여부를 측정하는 Harmbench-320에서 0%를 기록했다. 사실상 무엇이든 하려 드는 모델이라는 뜻이다. 게다가 'flash'라는 이름과 달리 성능이 결코 장난감 수준이 아니다. 약 6천 달러대 GPU에서 초당 20토큰가량이 나오고, 9월 22일 출시 예정인 256GB 통합 메모리의 M5 맥 스튜디오(약 9,500달러부터)라면 30토큰, 디코더 개선까지 얹으면 45토큰까지 가능하다는 추정이다. 개인의 저축 범위 안에서, 그것도 24시간 돌릴 수 있는 성능이라는 점이 핵심이다.

벤치마크가 말하는 것과 말하지 않는 것

능력의 근거로 저자는 두 지표를 든다. 과거 오픈소스 프로젝트가 발견·패치한 실제 취약점을 재현하는 CyberGym에서 GLM 5.3은 84.5%, 취약점을 실제 공격으로 연결하는 ExploitBench에서 54.4%를 기록했다. ExploitBench 선두는 100%의 GPT-6 Astra, 다음이 78.5%의 GPT-5.6 Sol이지만, CyberGym 1위는 오히려 GLM 5.3이다. 즉 공개된 소스코드와 CVE 설명만 보고도 대표 표본 취약점의 84.5%를 재현했다는 얘기다. 저자는 이를 두고 '사이버 공격을 for 루프로 돌릴 수 있는 세계'가 됐다고 표현한다. 다만 여기엔 유보가 필요하다. flash 버전과 어블리터레이션 버전의 실제 수치는 아직 없고, '깨뜨리기'에서 완전한 익스플로잇까지 가는 데는 여전히 사람의 개입이 필요할 수 있다. 저자 스스로도 이 한계들을 인정하되, 모델은 계속 좋아지므로 일시적 제약일 뿐이라고 본다. 역사적으로 GLM이 OpenAI·Anthropic보다 3~6개월 뒤처져 온 만큼, 1년 안에 Astra급 GLM이 나올 가능성이 높다는 것이다.

진짜 병목은 패치가 아니라 배포다

미국 프런티어 연구소들은 이 흐름을 예견하고 Project Glasswing과 Daybreak를 통해 기업·정부·재단·NGO와 함께 프런티어 모델로 취약점을 미리 찾아 고쳐왔다. 저자는 그 성과를 인정하면서도, 초기 공적 자금 이후 두 프로젝트가 상품으로 팔린 점은 다소 미심쩍다고 짚는다. 더 중요한 지적은 따로 있다. 스캔은 싸졌지만 배포는 그렇지 않다는 것이다. 중요 시스템은 물리적 접근이나 다운타임을 피하기 위한 단계적 롤아웃을 요구하고, 리눅스 커널을 패치해봐야 전력망이 Windows Server 2012에서 돌아가면 소용이 없다. 현재 정책 궤도에서 가장 큰 위험은 '분류되지 않은 경고의 산더미가 끝내 고쳐지지 않는' 상황이라고 저자는 경고한다.

한국 실무자에게 남는 것

대응책에서 이 글은 실용적이다. 정책 측면에서는 특정 모델이나 기법을 의무화하지 말라고 한다. 이 분야는 너무 빨리 변해 12개월 전 방어가 곧 무력해지므로, 규제해야 할 것은 테스트와 책임성이지 특정 기술이 아니라는 것이다. GLM 가중치 금지는 해적판처럼 파일공유 사이트에서 되살아날 뿐이고, GPU·대용량 메모리 수출 규제는 창구를 조금 늘릴 뿐 장기적 해법이 못 된다고 본다. 오히려 방어자에게서 Astra·Mythos 같은 최강의 도구를 뺏는 전면 차단은 상황을 악화시킨다는 것이다. 엔지니어링 측면의 조언은 한국 팀이 당장 적용할 만하다. 에이전트 자체를 샌드박싱하고 자격증명을 좁은 범위로 제한할 것, GET 필터링에 의존하지 말고 방화벽에서 신뢰 도메인만 열 것, 모든 변경과 요청 로그를 남길 것, 형식 검증·퍼징·메모리 안전 언어에 투자하고 신규 코드에 C/C++를 쓰지 말 것을 권한다. 무엇보다 엔지니어의 시간을 새 취약점 탐색이 아니라 분류·백포트·서명된 재현 가능한 릴리스·배포 자동화에 쓰라는 조언은, 지금 넘쳐나는 투자금을 어디에 태울지에 대한 분명한 우선순위를 제시한다. 다만 이 글의 여러 전제—특정 모델명과 출시 일정, 벤치마크 수치—는 저자의 관측과 추정에 기댄 것이므로, 결론의 절박함과 별개로 각 수치는 스스로의 환경에서 검증한 뒤 받아들이는 편이 안전하다.