[AgentShield] 프로젝트 후 코드 분석 및 연구 (3): 판정 에이전트 아키텍처 변화 과정

안녕하세요! 오늘은 판정 에이전트(Judge Agent)의 아키텍처가 어떻게 변해왔는지를 기록하는 블로그 입니다. 단순 if-else 구조에서 시작해서, 3레이어 규칙 기반 구조를 거쳐, 최종적으로 LangGraph 기반 멀티 에이전트 합의 구조에 도달하기까지의 과정과 그 이유들에 대해서 정리해보겠습니다.

---

1. 개요 및 판정에이전트에 대해서 정리

아키텍쳐를 알아보기 위해서 판정에이전트에 대해서 살짝 알아볼 필요가 있다.

 

판정이 중요한 이유는 레드 에이전트가 아무리 강한 공격을 생성해도, 그 결과를 "취약이냐, 방어했냐"로 판정하는 것은 판정 에이전트의 몫이다. 판정이 틀리면 모든 게 틀어진다.

 

특히 파인튜닝과 맞물리면 문제가 심각해진다. 판정 에이전트가 오판을 내려 잘못된 공격문에 성공 판정이 붙으면, 그 데이터가 SFT 학습에 들어가 버린다. 그러면 학습된 모델은 "값 자체"를 외워서 공격하는 오염된 모델이 만들어진다. 판정의 신뢰도가 곧 전체 파이프라인의 신뢰도다.

 

이 판정에이전트의 모든 과정들도 정말 많은 시간을 투자했다. 판정이 잘못되면 내가 진행하는 SFT 파인튜닝, 공격 프롬프트 데이터셋 생성, 파인튜닝 전과 후 모델 성능 테스트 등등에 모든 과정에서 치명적이다.

---

2. 초기 구조: 3레이어 규칙 기반 판정

처음 판정 시스템은 단순 3레이어 구조였다. 규칙 기반 필터링 후, 가벼운 모델이 1차 판정을 하고, 더 큰 모델이 최종 판정을 내리는 방식이었다. 카테고리별로 판정 루브릭(평가 기준)도 나눠놨다.

• LLM01(Prompt Injection)은 시스템 지침 준수 여부를 분석해서 score가 0.8을 넘으면 취약 판정을 내렸다.
• LLM02(Data Leak)는 정규식 패턴 매칭을 최우선 지표로 사용했다.
• LLM06(Excessive Agency)는 <tool_call> 태그 유무와 미승인 권한 실행 여부를 확인했다.
• LLM07(Prompt Leak)은 시스템 내부 설정값이나 시스템 프롬프트 노출 여부를 확인했다.

 

하지만 곧 근본적인 모순에 부딪혔다. 공격이 고도화될수록 방어와 판정 모델도 무작정 거대해져야 한다면,

이건 막대한 비용을 초래하며 "지속 가능하고 가벼운 보안 솔루션"이라는 초기 목표를 잃어버리는 길이다. 단일 거대 모델에 의존하는 구조로는 한계가 명확했다.

 

LLM 모델 변화 과정

2-1 단순 3레이어 규칙 기반 판정

규칙 기반이란 타겟의 응답이나 공격의 응답에서 특정 위험 단어나 문장을 LLM 과정을 거치지 않고 바로 판정하는 방식이다. 보안 회사 이외에도 대부분의 회사들이 규칙 기반으로 운영하고 있는 것으로 알고 있다.
장점은 빠른 속도와 유지 보수에 유리하다는 것이다. 규칙을 개별적으로 넣어주면 되기 때문에 적용이 매우 간편하다. 단점도 존재한다. 너무 복잡한 규칙을 넣어주면 안전한 응답도 판정이 이상하게 나올 수 있다. 적절하게 사용하는 것이 중요하다.

💡참고: 테스트베드의 모델은 Qwen2.5 추론 모델을 사용했습니다. 

 

우리가 초반 구축에 사용한 규칙 기반 도구는 NVIDIA의 garak이다.

https://github.com/NVIDIA/garak

GitHub - NVIDIA/garak: the LLM vulnerability scanner

garak의 규칙 기반 파일을 사용했다. 약 80개 정도의 규칙이 들어 있었고, 환각, 데이터 유출, 즉시 주입, 허위 정보, 독성 생성, 탈옥 등 취약점을 탐색하는 데 맞춰져 있었다.

1레이어에서 위와 같은 규칙 기반 판정을 거친다. 그다음 2레이어에서 가벼운 LLM이 판정한다. 우리는 이 과정에서 Qwen2.5:0.5B를 사용했다.

Qwen/Qwen2.5-0.5B · Hugging Face

이 과정에서도 많은 테스트를 진행했다. 어떻게 판정을 해야 좋을 지. 우리의 판정 규칙은 타겟 LLM(검사 대상)에서 실제 취약점을 말했는지를 기준으로 잡고 판단했다. 그러면서 판정 규칙도 추가하고 수정을 거듭하면서 점점 안정화가 되었다.

하지만 공격 에이전트의 프롬프트가 너무 정교해지면서 판정에이전트의 규칙기반과 0.5B의 한계가 드러났다. 그래서 후에 4B로 성능 업그레이드를 진행했다.

 

단순 판단으로 올린 것이 아니다. 기간 안에 결과물이 나와야 하는 프로젝트이기 때문에 0.5B로 계속 테스트를 진행하기에는 시간이 너무 촉박했다. 더 똑똑한 모델로 성능을 안정화시킨 뒤에 파인튜닝을 진행하는 방식이 옳다고 판단했다.

Qwen/Qwen3.5-4B · Hugging Face

---

3. LangGraph 전환 — 멀티 에이전트 협업 구조

모델의 크기를 키우는 대신, 역할을 세분화한 LangGraph 기반의 멀티 에이전트 구조로 전면 개편했다.

 

사실 이 과정에는 스토리가 조금 있다. 국비 과정에서 선생님께서 내주신 시험 중에 LLM을 LangGraph 기반으로 AI끼리 추론하여 더 나은 결과를 도출하는 과제가 있었다. 시험을 보면서 흥미로워서 추가로 찾아봤다. 이 복잡하지만 확실하고, 느린 과정을 실제로 어디서 사용할까? 검색해봤더니 의료 시스템에서 많이 사용한다는 것을 알게 됐다. 당연하다. 의료는 틀리면 안 되니까. 그런데 단어만 다르지 보안에서도 틀리면 안 되는 건 마찬가지로 중요했다. 

 

그래서 전체 파이프라인의 멀티 에이전트 과정에 더해, "판정 에이전트 내부에서도 LangGraph로 서로 맞짱을 뜨게 하면 더 좋은 결과가 나올 것 같다!"는 가설을 세우고 바로 작업을 시작한 것이다.

💡"판정 에이전트 내부에서도 LangGraph로 서로 맞짱을 뜨게 하면 더 좋은 결과가 나올 것 같다!" 실제 그 당시 속으로 한 말이다.

 

첫 LangGraph 구조는 다음과 같았다.

 

단계노드명역할

Layer 1	Triage	정규식/키워드 기반 고속 스캔. 명확한 거부/유출 시 즉시 판정 후 종료
Layer 1.5	Scanner	도구 호출 및 구조적 패턴 분석. LLM06(권한 남용) 탐지 특화
Layer 2	Auditor	LLM 기반 의도/문맥 분석. 카테고리별 루브릭 주입 및 심층 추론
Layer 3	Consensus	에이전트 결과 취합 및 최종 판정. 결과 상충 시 가중치 기반 합의

핵심은 Triage에서 명확한 케이스를 빠르게 걸러내는 것이었다. 모든 요청이 무거운 LLM Auditor 노드를 거칠 필요는 없다. 명확한 거부나 유출은 정규식만으로 충분히 판정할 수 있고, 애매한 케이스만 LLM에게 넘기면 된다. 이렇게 하면 판정 속도도 확보하면서 정확도도 유지할 수 있다.

타임아웃이나 네트워크 에러 발생 시에는 retry_count 상태를 활용해 최대 3회 재시도 루프를 구성했다. 최종 실패 시 ambiguous로 안전하게 폴백시켜 시스템 중단을 방지했다.

---

4. 구조의 진화 — 단순 토론에서 증거 기반 합의로

이 과정도 결코 순탄하지 않았다. 단순히 모델 간 토론을 시키는 구조에서 시작해, 증거 기반 추론을 더하고, 각 증거에 가중치를 부여하고, 최종적으로 찬반 가중치를 종합하는 구조로 수없는 수정과 개선을 거쳤다.

 

Auditor를 하나로 두는 것도 문제였다. 하나의 LLM이 "안전한가, 위험한가"를 동시에 판단하면 어중간한 답이 나온다. 그래서 Auditor를 두 개로 분리했다. Strict Auditor는 안전 입장에서 대변하고, Context Auditor는 위험 입장에서 대변한다.

최종적으로 정리된 내부 워크플로우는 이렇다.

---

5. 최종 구조 — 확률 기반 5단계 판정

여러 번의 변화를 거쳐 최종적으로 정착한 판정 흐름은 5단계 확률 조정 방식이다.

 

1단계: 검수한 데이터로 학습된 분류 모델(classifier)이 가장 먼저 공격과 응답을 받아 위험/안전 각각의 초기 확률을 산출한다. 분류 모델이 0.9 이상의 높은 확률을 내더라도 0.5에 가깝게 시작할 수 있도록 정규화를 진행했다. 분류 모델을 맹신하지 않기 위함이다.

2단계: Pattern Agent가 응답에서 나오면 안 되는 단어가 나왔는지 정규식 검사를 수행한다. 패턴이 하나씩 감지될 때마다 가중치에 따라 초기 확률을 조정한다.

3단계: Strict Agent와 Context Agent가 각각 판정을 내린다. Strict는 안전 입장에서 "이 응답이 왜 안전한지"를 대변하고, Context는 위험 입장에서 "이 응답이 왜 위험한지"를 대변한다. 이 두 에이전트의 점수 자체를 받는 것이 아니라, 각각의 judgment에 따라 가중치를 부여하여 확률을 조정한다.

4단계: 두 에이전트의 판정이 충돌하면 Debate로 넘어간다. Debate에서도 마찬가지로 judgment에 따라 가중치를 부여하여 확률을 조정한다.

5단계: Consensus Agent가 감지된 패턴, 각 대변인의 이유를 종합하여 최종 판정을 내린다. vulnerable과 safe의 확률 합이 1이 되도록 최종 산정하고, 그 확률에 대한 이유를 추론한다.

 

판정에이전트의 전체 구조를 변경하면서 계속해서 판정에이전트의 LoRA학습 모델도 업데이트가 꾸준했다.

최종 판정에이전트 모델: Qwen3.5-2B SFT 파인튜닝 모델이다.

베이스 모델: https://huggingface.co/Qwen/Qwen3.5-2B

Qwen/Qwen3.5-2B · Hugging Face

💡레드에이전트 모델과는 다르게 검열 된 순수 모델을 사용해도 됐다.

 

모델의 크기를 키우지 않고도 논리적인 판정 구조를 만들어낸 것이 이 아키텍처의 핵심이다. 단일 거대 모델 하나가 "맞다/아니다"를 판단하는 것이 아니라, 작은 모델 여러 개가 각자의 역할에서 증거를 내놓고, 그 증거들의 가중치를 종합해서 최종 판정이 나온다.

---

분석 시리즈 2편

[AgentShield] 프로젝트 후 코드 분석 및 연구 (2): 레드 에이전트 강화 일지