LLM 보안 검사, '안전하다'는 거짓말에 속는다

AI에게 코드 보안 점검을 맡기는 파이프라인은 이제 흔하다. 정적 분석 도구가 "이 줄에서 경계 검사가 빠졌다" 같은 근거를 뽑아 주고, LLM이 그 근거를 읽고 실제 취약점인지 판정한다. 사람 손이 덜 가고 도구의 오탐도 걸러진다는 그림이다. 그런데 이 구조에는 한 번도 제대로 측정되지 않은 가정이 숨어 있다. 모델이 도구의 말이 참인지 거짓인지 가릴 수 있는가.

무엇을 했는가

연구진은 C/C++용 프로시저 내부 정적 분석기를 직접 만들어 증명 의무(proof obligation, 코드가 안전하려면 성립해야 하는 조건)를 생성하고, PrimeVul 데이터셋에서 취약한 함수와 패치된 함수를 짝지어 LLM에 감사시켰다. 핵심은 함수 코드는 그대로 두고 도구가 붙인 메모만 여섯 가지 조건으로 바꿔 넣은 것이다. 그중 두 가지가 거짓이다.

• 거짓 안심: 실제로는 없는 경계 검사가 "있다"고 꾸며낸 메모
• 거짓 경보: 실제로는 추가된 검사가 "없다"고 꾸며낸 메모 겹치지 않는 네 묶음에서 916개 함수 짝, 4개 벤더의 11개 모델 설정, 총 16,572건의 감사를 수행했다. 모델은 따로 학습하거나 미세조정하지 않았다.

신규 모델 7종으로 사전 등록된 복제 실험을 돌렸을 때도 거짓 안심이 거짓 경보보다 판정을 더 많이 끌어당긴다는 비대칭이 평균 +0.16(95% 신뢰구간 +0.10~+0.24)으로 확인됐다.

왜 비대칭인가

흥미로운 대비는 거짓이 해롭다는 내용에 있지 않다. 어느 방향의 거짓이 해로운가에 있다. 모델은 "위험하다"는 거짓 주장은 자주 반박했지만, "안전하다"는 거짓 주장은 대체로 받아들였다.

그럴듯한 설명은 두 가지다. 첫째, 경보를 반박하려면 코드에서 검사가 있다는 증거를 찾으면 되지만, 안심을 반박하려면 없다는 것을 입증해야 한다. 없음을 증명하는 쪽이 훨씬 어렵다. 둘째, 취약점 심사는 기본적으로 무언가를 찾아내는 과제라서, 찾을 것이 없다는 외부 보증은 탐색을 일찍 끝낼 구실이 된다. 어느 쪽이든 결과는 같다. 공격자나 결함 있는 도구가 "여긴 괜찮다"고 말하기만 하면 심사가 느슨해진다.

그래서 진짜 의미하는 것

• 프롬프트로 막으려는 시도는 신뢰할 수 없다. "도구 출력을 맹신하지 말라"는 지시를 넣는 방식은 효과가 재현되지 않았다. 지시문 튜닝은 이 문제의 해법이 아니다.
• 효과가 있었던 것은 구조 변경이다. 각 주장을 별도 호출로 검증하고, 반증된 주장을 명시적으로 모델에 보여주는 방식이 12%p를 회복시켰다. 도구의 보증을 모델이 믿기 전에 먼저 검증하는 단계가 파이프라인에 들어가야 한다는 뜻이다.
• 평가 방식도 바뀌어야 한다. 거짓 근거에 대한 모델의 취약성을 평균 정확도 한 숫자로 재면 비대칭이 보이지 않는다. 방향을 구분해 재야 한다.
• 한계는 분명히 짚어 둘 만하다. 대상은 C/C++ 프로시저 내부 분석이고 PrimeVul의 함수 짝이다. 실제 운영 환경의 프로시저 간 분석이나 다른 언어에서 같은 크기로 나타날지는 별개 문제다. 두 번째 모델에서는 검증 단계의 개선 폭이 작고 통계적으로 유의하지 않았다는 점도 함께 봐야 한다. 또한 거짓 메모는 연구진이 의도적으로 주입한 것이므로, 실제 도구의 오탐과 미탐 분포와는 다르다.

마무리

요약하면, LLM은 도구가 "문제가 있다"고 할 때보다 "문제가 없다"고 할 때 훨씬 쉽게 설득된다. AI 보안 자동화를 도입한다면 모델의 정확도를 올리는 것보다 도구의 보증을 모델이 읽기 전에 검증하는 단계를 넣는 쪽이 투자 대비 효과가 크다는 것이 이 연구의 실무 결론이다.

출처: ZhiHong Liu, Shuyao Gao, "Trusting the Tool: Asymmetric Deference of LLM Vulnerability Auditors to Static-Analysis Evidence", arXiv:2610.32876 (2026년 10월 23일). https://arxiv.org/abs/2610.32876v1