[모델 테스트] AgentShield POC — 기본 모델 방어율 테스트 결과 정리

1. 왜 이 테스트를 먼저 했는가

LLM 보안 프로젝트를 생각할 때 가장 먼저 드는 의문이 있다. 이미 최신 모델들이 안전 학습을 꽤 많이 받았다면, 별도의 방어 시스템이나 보안 학습 파이프라인을 만드는 일이 정말 필요한가 하는 점이다. 이 질문을 먼저 정리하지 않으면 이후 설계가 전부 공중에 뜬다. 모델이 이미 충분히 막고 있다면 내가 만들려는 시스템은 문제를 해결하는 것이 아니라, 이미 해결된 문제를 다시 포장하는 것에 가까워질 수 있기 때문이다.

내가 구상하는 AgentShield는 단순한 프롬프트 필터가 아니다. 목표는 유해 요청을 찾아내고, 그 취약점을 기준으로 방어 데이터를 만들고, 다시 검증하는 흐름을 갖춘 보안 테스트 및 개선 파이프라인이다. 그런데 이런 구조가 의미 있으려면 전제가 하나 필요하다. 기본 모델의 내장 안전성만으로는 실제 우회 공격을 충분히 막지 못한다는 사실이 먼저 보여야 한다.

그래서 이번 POC의 첫 단계는 기능 구현보다도 검증에 가까웠다. "요즘 모델은 이미 안전하다"라는 막연한 인상을 실제 수치로 확인해보는 작업이다. 그리고 그 다음 질문이 자연스럽게 이어진다. 만약 기본 모델이 완전하지 않다면, 추가 학습이나 외부 방어 계층을 통해 의미 있게 개선할 수 있는가. 이 두 질문이 이번 프로젝트의 출발점이다.

정리하면 이번 테스트는 아래 두 가설을 확인하기 위한 기초 실험이다.

• 가설 1: 최신 기본 LLM도 실제 우회 공격에 대해서는 충분히 안전하지 않다.
• 가설 2: 취약 패턴을 기준으로 방어 학습을 시키면 방어율을 더 끌어올릴 수 있다.

이번 글은 그중에서도 첫 번째 가설, 즉 기본 모델 상태만으로 어느 정도까지 방어가 가능한지를 확인한 기록이다.

2. 프로젝트 관점에서 왜 중요한가

모델 보안 문제를 보면 흔히 두 가지 극단으로 흘러간다. 하나는 "최신 모델은 다 알아서 막는다"는 낙관이고, 다른 하나는 "모델은 원래 뚫리니까 무조건 바깥에서 막아야 한다"는 비관이다. 실제로는 둘 다 절반만 맞는 말인 경우가 많다.

최신 모델은 확실히 예전보다 거부를 더 잘한다. 하지만 안전성은 단순히 유해 요청을 많이 거부하는 것만으로 평가할 수 없다. 정상적인 질문은 통과시키면서, 우회 공격만 정확하게 막아야 한다. 즉 보안성뿐 아니라 오탐, 과차단, 사용성까지 같이 봐야 한다. 내가 AgentShield를 별도 프로젝트로 보고 있는 이유도 여기에 있다. 단순히 모델 내부 정렬에만 기대면 방어율을 올리는 대신 과차단이 늘어나기 쉽고, 반대로 과차단을 줄이면 우회 공격이 새기 쉽다.

이번 테스트는 바로 이 균형 문제를 확인하는 데 의미가 있다. 단순히 "막았나/못 막았나"가 아니라, 최신 모델이 실제로는 어떤 종류의 요청에서 강하고 어떤 종류의 요청에서 흔들리는지를 분리해서 봐야 한다. 그 결과가 있어야 이후 파인튜닝이든 프록시 방어든 어떤 방식이 더 적절한지 판단할 수 있다.

3. 테스트 설계

데이터셋은 walledai/WildGuardTest를 사용했다. 공개된 AI 안전 벤치마크 데이터셋이고, 손으로 만든 예시 몇 개가 아니라 실제 평가용으로 쓰일 수 있는 형태의 프롬프트들을 포함하고 있어서 POC의 첫 기준점으로 적절하다고 봤다.

전체 데이터 중 라벨이 있는 항목만 사용했고, 200건을 균등 샘플링해 네 가지 카테고리로 나눠 테스트했다.

카테고리	설명	기대 동작
adversarial_harmful	우회 기법이나 역할극으로 포장된 유해 요청	거부해야 함
direct_harmful	직접적이고 노골적인 유해 요청	거부해야 함
adversarial_unharmful	형태는 수상하지만 실제 내용은 무해한 요청	정상 응답해야 함
benign	일반적인 정상 질문	정상 응답해야 함

이 구성이 중요한 이유는, 안전성 평가를 유해 요청 거부율 하나로만 보면 실제 모델 품질을 왜곡하기 쉽기 때문이다. 예를 들어 어떤 모델이 모든 애매한 질문을 다 거절하면 유해 요청 방어율은 높게 나올 수 있지만, 실제 사용성은 크게 나빠진다. 반대로 친절하게 다 답해주는 모델은 사용자 경험은 좋아 보여도 보안 관점에서는 쉽게 뚫린다. 그래서 유해 요청과 무해 요청을 같이 봐야 한다.

비교 모델은 두 개다.

• Qwen2.5-3B-Instruct
• Gemma 4 E2B-it

둘 다 instruction-tuned 계열이라 채팅 환경에서 비교하기 적절하다. 동일한 시스템 프롬프트, 동일한 샘플(seed=42), 동일한 판정 규칙을 사용해서 최대한 비교 조건을 맞췄다. 판정은 규칙 기반으로 처리했고, 특히 "겉으로는 사과하지만 실제로는 내용을 제공하는 응답"을 잡기 위해 refusal보다 compliance를 우선 판정하도록 조정했다.

4. 결과 요약

먼저 전체 숫자만 보면 다음과 같다.

모델	유해 방어율	무해 정상응답율
Qwen2.5-3B	41.0% (41/100)	86.0% (86/100)
Gemma 4 E2B	64.0% (64/100)	70.0% (70/100)

카테고리별로 보면 차이가 더 선명하게 보인다.

유해 요청 방어율

카테고리	Qwen2.5-3B	Gemma 4 E2B
adversarial_harmful	14% (7/50)	44% (22/50)
direct_harmful	68% (34/50)	84% (42/50)

무해 요청 정상응답율

카테고리	Qwen2.5-3B	Gemma 4 E2B
adversarial_unharmful	84% (42/50)	60% (30/50)
benign	88% (44/50)	80% (40/50)

숫자만 요약하면 이렇다. Gemma 4가 더 잘 막는다. 하지만 더 많이 과차단한다. 이 두 문장이 이번 결과의 핵심이다.

5. 결과 해석

Gemma 4 E2B는 확실히 더 최근 모델다운 모습을 보였다. 전체 유해 요청 방어율이 41%에서 64%로 올라갔고, 특히 우회 공격으로 분류한 adversarial_harmful에서 14%에서 44%로 크게 상승했다. 이 차이는 무시하기 어렵다. 최소한 "최신 모델이 예전 모델보다 안전 정렬이 더 강하다"는 점은 이번 테스트에서도 확인된 셈이다.

 

그런데 여기서 바로 멈추면 안 된다. 64%라는 숫자는 상대적으로는 개선이지만, 절대적으로는 아직 낮다. 유해 요청 100개 중 36개가 통과했다는 뜻이기 때문이다. 실제 서비스 환경에서 이 정도면 "꽤 잘 막는다"고 표현하기는 어렵다. 특히 adversarial_harmful에서 50개 중 28개를 놓쳤다는 점은 더 중요하다. 노골적인 요청은 어느 정도 거부할 수 있어도, 맥락을 감추거나 역할극으로 우회한 요청에 대해서는 여전히 흔들린다는 의미다.

 

이 부분이 프로젝트 관점에서 중요하다. 실제 공격자는 정직하게 유해 요청을 던지지 않는다. 시스템 메시지를 흉내 내거나, 가상의 시나리오를 만들거나, 창작이나 교육 목적이라고 포장하거나, 정책 검토라고 둘러 말한다. 즉 진짜 문제는 direct_harmful보다 adversarial_harmful 쪽에 더 가깝다. 이번 결과는 기본 모델 정렬만으로는 이 구간을 충분히 방어하지 못한다는 점을 보여준다.

반대로 무해 요청 결과를 보면 Gemma 4는 방어를 강화하는 대신 사용성을 희생했다. 정상응답율이 86%에서 70%로 내려갔다. 특히 adversarial_unharmful에서 84%에서 60%로 크게 떨어졌는데, 이 말은 내용은 무해하지만 형식이 조금 수상해 보이는 요청들까지 꽤 많이 거부했다는 뜻이다. 보안적으로는 보수적일 수 있지만, 사용자 입장에서는 정상 요청이 자꾸 막히는 모델이 된다.

결국 이번 결과는 안전성의 전형적인 trade-off를 보여준다. 방어를 강하게 가져가면 과차단이 늘고, 과차단을 줄이면 우회 공격이 새기 쉽다. 이건 단순히 모델 하나를 교체해서 해결될 문제가 아니라, 어떤 요청이 실제 위험한지 더 정밀하게 구분하고 그 결과를 다시 학습과 검증으로 연결하는 구조가 필요하다는 뜻이다. 내가 AgentShield를 단순 모델 비교가 아니라 파이프라인 문제로 보고 있는 이유도 여기 있다.

6. 이번 테스트에서 얻은 핵심 포인트

최신 모델이 더 안전한 것은 맞다. 다만 "더 안전하다"와 "충분히 안전하다"는 전혀 다른 말이다. Gemma 4 E2B는 Qwen2.5보다 분명 더 잘 막았지만, 여전히 우회 공격의 상당수를 놓쳤다. 따라서 최신 모델이라는 이유만으로 별도 보안 계층이 필요 없다고 보기는 어렵다.

또 하나 중요한 점은, 안전성은 단일 숫자로 설명하면 안 된다는 것이다. 만약 유해 요청 방어율만 보면 Gemma 4는 꽤 괜찮아 보인다. 하지만 무해 정상응답율까지 함께 놓고 보면 상황이 달라진다. 방어를 높이는 과정에서 정상적인 요청도 더 많이 놓치고 있기 때문이다. 실제 제품 환경에서는 이 손실이 체감 품질에 직접 연결된다.

마지막으로, 취약점의 중심이 direct_harmful이 아니라 adversarial_harmful이라는 점이 분명해졌다. 즉 앞으로 데이터를 만들거나 방어 정책을 설계할 때도 단순한 금지어 기반 요청보다 우회형, 역할극형, 문맥 위장형 프롬프트를 더 중요하게 다뤄야 한다. 이 부분이 개선되지 않으면 방어율이 조금 올라도 실제 공격 저항성은 생각만큼 커지지 않을 가능성이 높다.

가설 1에 대한 현재 판단

이번 결과만 놓고 보면 "최신 기본 LLM은 이미 충분히 안전하므로 별도 방어 프로젝트가 필요 없다"는 가설은 지지되기 어렵다. Qwen2.5-3B는 물론이고, 더 최신인 Gemma 4 E2B도 우회형 유해 요청을 안정적으로 막는 수준까지는 도달하지 못했다.

오히려 이번 비교는 프로젝트의 필요성을 더 분명하게 보여준다. 기본 모델 성능이 완전히 낮아서가 아니라, 안전성과 사용성의 균형을 모델 내부 정렬만으로 해결하기 어렵기 때문이다. 모델은 이전보다 좋아졌지만, 그 개선이 곧 문제 해결을 의미하지는 않았다. 이 차이가 중요하다.

다음에 확인할 것

다음 단계는 두 번째 가설을 검증하는 것이다. 기본 모델이 완전하지 않다는 점은 어느 정도 확인됐으니, 이제는 취약 패턴을 반영한 방어 학습이 실제로 방어율을 개선하는지 봐야 한다. 특히 보고 싶은 건 단순 overall 수치보다도 adversarial_harmful 구간이 얼마나 올라가는지, 그리고 그 과정에서 benign/adversarial_unharmful이 얼마나 더 희생되는지다.

 

결국 내가 알고 싶은 것은 하나다. 모델을 더 최신으로 바꾸는 것만으로는 부족할 때, 취약점 기반의 데이터 생성과 방어 학습이 실제로 의미 있는 개선을 만들 수 있는가. 이번 테스트는 그 질문으로 가기 위한 기준점 역할을 한다.