Aionda

2026-07-07

보안 LLM의 과잉 거부

사이버보안 업무에서 LLM 안전 정렬이 합법적 방어 요청까지 과잉 거부하는 문제를 짚는다.

보안 LLM의 과잉 거부

사이버보안은 AI 안전 논쟁에서 까다로운 영역이다. 여기서는 위험한 지식이 필요한 지식이기도 하다. 취약점 분석, 로그 해석, 포렌식, 탐지 규칙 작성은 공격자도 쓸 수 있는 언어를 공유한다. 그래서 일률적 거부 정책은 리스크를 낮추는 대신 정당한 수비수의 업무도 막을 수 있다.

세 줄 요약

  • 이 글의 핵심 쟁점은 LLM의 안전 정렬이 사이버보안 같은 고위험 도메인에서 합법적 방어 요청과 악의적 요청을 충분히 구분하지 못해 과잉 거부를 낳는다는 점이다.
  • 이 문제가 중요한 이유는 보안팀의 실제 업무가 막히면 안전성은 높아진 것처럼 보이더라도 유틸리티가 떨어지고, 거부율만으로는 모델의 실제 안전 수준을 판단하기 어려워지기 때문이다.
  • 독자는 일반 안전 벤치마크와 별도로 승인된 방어 시나리오에서의 거부율을 측정하고, 운영 전 평가 항목에 맥락 기반 허용·거부 규칙을 넣어 의사결정해야 한다.

현황

이번에 피드에 올라온 논문 Not All Refusals Are Equal: How Safety Alignment Fails Cybersecurity at Scale의 초록 발췌는 문제의 방향을 분명히 제시한다. 초록은 안전 정렬이 필수 단계이지만, 도메인별 차이와 질의의 잠재적 위해 수준을 충분히 구분하지 못할 수 있다고 적었다. 특히 사이버보안처럼 합법적이고 승인된 작업에서도 모델이 “safety circuits” 때문에 목표 수행을 막을 수 있다는 문제의식을 앞에 둔다. 다만 현재 확보된 발췌만으로는 이 논문의 실험 규모나 세부 수치까지는 확인되지 않는다.

정량 근거는 인접 연구에서 더 구체적으로 나온다. Defensive Refusal Bias: How Safety Alignment Fails Cyber Defenders2,390개의 실제 NCCDC 사례를 바탕으로, 보안 민감 용어가 들어간 방어 요청을 모델이 의미상 같은 중립 표현 요청보다 2.72배 더 자주 거부했다고 적었다. 여기서 핵심 지표는 합법적 방어 요청에 대한 **거부율(refusal rate)**이다. 반면 작업 성공률을 어떻게 정의했는지, 오탐 거부를 별도 임계값으로 수치화했는지는 현재 확보된 검색 결과에 직접 나오지 않는다.

이 문제는 보안 분야에만 머물지 않는다. Meta의 CyberSecEval 2는 안전 조정이 benign prompts에 대한 False Refusal Rate, FRR를 높여 유틸리티를 떨어뜨릴 수 있다고 적었다. 또 다른 대규모 감사 연구는 거부율이 안전의 좋은 대리 지표가 아니라고 지적한다. 무해한 요청을 과하게 거부하면서도, 유해한 요청에는 응할 수 있기 때문이다. 즉 “많이 거부하는 모델”과 “안전한 모델”은 같은 뜻이 아니다.

분석

의사결정 관점에서 보면 선택지는 단순하지 않다. 보안용 LLM을 일반 사용자용 안전 정책 위에 그대로 얹으면 초기 배포 리스크는 낮아 보일 수 있다. 대신 탐지 엔지니어, 침해대응팀, 레드팀, 교육 담당자가 실제로 필요한 출력을 받지 못할 가능성이 커진다. 반대로 허용 범위를 넓히면 현업 효율은 나아질 수 있지만, 악용 가능성도 함께 관리해야 한다. 핵심은 “거부를 늘릴 것인가”가 아니라 “어떤 맥락에서 누구에게 무엇을 거부할 것인가”다.

그렇다고 차등 정책이 이미 해답으로 굳어진 것은 아니다. 검색 결과상 일부 연구는 사용자별 정책 평가에서 통제 가능성과 안전-유용성 균형 개선을 보고했다. Anthropic의 Constitutional Classifiers 사례도 무해한 질의에서 거부율 증가가 **0.38%**에 그쳤고 통계적으로 유의하지 않았다고 밝혔다. 다만 도메인, 권한, 사용자 맥락을 한 번에 반영하는 단일 정책이 실제 운영 환경 전반에서 성능과 위험을 함께 꾸준히 개선한다는 강한 업계 합의가 확인되지는 않는다. 다시 말해 방향은 제시됐지만, 운영 설계는 아직 실험 단계에 가깝다.

여기서 더 큰 함정은 평가 설계다. 보안팀은 종종 “모델이 위험한 걸 안 알려준다”는 이유로 안심한다. 그러나 승인된 방어 작업도 함께 막는다면, 그 모델은 안전하다기보다 둔할 수 있다. 보안 도메인에서는 일반 안전 벤치마크와 별도로 승인된 사용 시나리오를 따로 재현해 봐야 한다. 그래야 과잉 거부와 실제 위험 억제를 구분해 볼 수 있다.

실전 적용

기업이나 보안 조직이 지금 결정해야 할 일은 모델 교체보다 평가 체계 재설계다. 우선 내부 프롬프트 로그에서 방어 목적의 고위험 언어를 모아야 한다. 예를 들어 탐지 규칙 작성, 악성 행위 분석, 포렌식 정리, 취약점 검증처럼 공격 언어와 겹치는 요청을 따로 묶어 테스트해야 한다. 그다음 일반 질의 세트와 승인된 보안 업무 세트를 분리해 거부 패턴을 비교하라. 모델이 위험해서 멈췄는지, 단어에 반응해 멈췄는지부터 구분해야 한다.

제품 설계도 바뀌어야 한다. 프런트엔드에서 전부 막는 방식보다, 업무 유형·승인 여부·감사 로그를 함께 보는 다층 구조가 낫다. 사용자에게는 “왜 거부했는지”와 “어떤 추가 맥락이 있으면 재평가하는지”를 알려줘야 한다. 그래야 현업은 프롬프트를 우회적으로 꾸미기보다, 필요한 승인 정보와 방어 목적을 명시하는 쪽으로 이동한다.

오늘 바로 할 일 체크리스트:

  • 승인된 보안 업무 20개 이상을 뽑아 일반 안전 테스트와 분리된 내부 평가 세트를 만들라.
  • 같은 의미를 유지한 채 보안 민감 용어만 바꾼 프롬프트 쌍을 만들어 거부율 차이를 측정하라.
  • 운영 정책 문서에 “거부율”과 함께 FRR 같은 과잉 거부 지표를 정식 KPI로 넣어라.

FAQ

Q. 보안용 LLM은 안전 정렬을 약하게 해야 합니까?
아닙니다. 문제는 안전 정렬의 존재가 아니라 적용 방식입니다. 합법적 방어 작업과 악의적 요청을 같은 규칙으로 다루면 현업 성능이 크게 떨어질 수 있으므로, 맥락과 승인 여부를 반영한 정책 설계가 중요합니다.

Q. 거부율이 낮으면 더 좋은 모델입니까?
그렇지 않습니다. 거부율만으로는 안전성과 유용성을 함께 판단할 수 없습니다. 무해한 요청을 덜 거부하는 대신 유해한 요청에도 응할 수 있기 때문에, 승인된 사용 시나리오와 실제 위험 시나리오를 분리해 같이 평가해야 합니다.

Q. 지금 당장 어떤 지표를 봐야 합니까?
최소한 합법적 방어 요청에 대한 거부율과 benign prompts에 대한 FRR를 함께 보셔야 합니다. 여기에 동일 의미 프롬프트의 표현 차이로 거부가 달라지는지도 측정하면, 정책이 맥락을 이해하는지 단어에 반응하는지 더 빨리 파악할 수 있습니다.

결론

보안 도메인에서 안전 정렬의 실패는 “덜 똑똑한 답변” 문제가 아니다. 승인된 수비수와 공격자를 같은 문장 패턴으로 취급하는 정책 실패다. 앞으로 봐야 할 포인트는 새 모델의 능력보다, 누가 어떤 맥락에서 어떤 출력을 받도록 설계했는지다.

다음으로 읽기


참고 자료

공유하기:

업데이트 받기

주간 요약과 중요한 업데이트만 모아서 보내드려요.

오류를 발견했나요? 정정/오류 제보로 알려주시면 검토 후 업데이트에 반영할게요.

출처:arxiv.org