LMSM, 리눅스 보안 모듈 구조를 LLM 런타임 방어에 적용

배경

대규모 언어 모델의 안전성 문제는 유용한 탐지 신호가 전혀 없어서만 발생하지 않습니다. 모델 내부에서 발견한 신호를 실제 온라인 서빙 경로에 안정적으로 연결하는 일이 어렵다는 점도 큰 장애물입니다. 해석 가능성 기법은 생성 과정에서 모델 내부 상태를 관찰할 수 있지만, 그 신호 자체가 곧바로 보안 통제가 되는 것은 아닙니다. 지금까지는 새로운 프로브나 오토인코더를 도입할 때마다 별도의 보정, 정책 로직, 개입 코드를 작성해야 하는 경우가 많았습니다. 결과적으로 새로운 연구 성과를 적용할 때마다 통합 비용이 반복됩니다.

싱가포르국립대학교 연구진은 이 문제를 해결하기 위해 LMSM(Language Model Security Modules) 을 제안했습니다. Linux Security Modules(LSM)의 분리 구조를 LLM 서빙 환경에 적용한 접근입니다.

핵심 구조

• 증거와 집행을 분리합니다. 선택된 보안 백엔드는 보정된 모델 내부 증거를 제공하고, 버전 관리 정책은 신뢰할 수 있는 요청별 컨텍스트를 바탕으로 규칙을 평가합니다. 별도의 게이트는 버퍼에 저장된 출력을 실제로 공개할지 결정합니다.
• 백엔드를 교체할 수 있습니다. 하나의 실행 기반에서 희소 오토인코더(SAE), transcoder 기반 산출물, 작업에 맞춰 학습한 dense probe를 사용할 수 있습니다. 증거 방식이나 규칙, 스케줄을 바꿔도 요청 처리와 집행 경로를 다시 구축할 필요가 없도록 설계했습니다.
• 연속 배치 환경을 고려합니다. 프로토타입은 Hugging Face Transformers와 연속 배치를 지원하는 vLLM에서 구현됐습니다. 스케줄러가 처리 순서를 바꾸더라도 각 요청에 대한 안전성 판단이 다른 요청과 섞이지 않도록 하는 것이 중요한 목표입니다.
• 규칙을 선택적으로 조합합니다. 모든 요청에 동일한 방어를 적용하는 대신, 요청별로 필요한 규칙만 활성화하고 여러 규칙을 함께 적용할 수 있습니다.

결과와 한계

Qwen3-4B에서 LMSM-Checkpoint는 HarmBench 공격 성공률을 39.20%에서 3.32%로 낮췄습니다. 반면 XSTest의 오거부율은 2.40%에서 4.40%로 상승했습니다. 32개의 활성 시퀀스를 사용하는 조건에서, 모니터링 작업을 수행하지 않는 비교 서빙 경로 대비 처리량의 98.14%를 유지했습니다.

이는 테스트한 환경에서 런타임 모니터링을 추가해도 서빙 성능을 크게 희생하지 않을 수 있음을 보여줍니다. 동시에 방어 강도를 높이면 정상 요청까지 거부할 가능성이 커질 수 있으므로, 신호의 보정과 정책 설계가 여전히 핵심이라는 점도 드러냅니다.

의미와 전망

LMSM의 핵심은 새로운 단일 탐지기를 만드는 데 있지 않습니다. 모델 내부 증거를 정책 판단으로 전달하고, 그 결과를 출력 통제로 연결하는 공통 구조를 제시했다는 데 의미가 있습니다. 새로운 해석 가능성 산출물을 증거 백엔드로 추가할 수 있다면, 연구 단계의 기법을 운영 환경에 적용할 때마다 서빙 코드를 크게 수정하는 부담을 줄일 수 있습니다.

다만 LMSM이 증거의 신뢰성, 임계값 설정, 공격 유형의 범위 문제를 자동으로 해결하는 것은 아닙니다. 보고된 수치는 특정 모델과 벤치마크, 프로토타입 구현에 기반하므로 더 다양한 모델과 실제 부하에서 추가 검증이 필요합니다. 그럼에도 LMSM은 발전하는 내부 분석 기법을 런타임 안전 제어로 전환하기 위한 실용적인 공통 경로를 제시합니다.

출처: Hugging Face Daily Papers