18.1 Red Teaming

이전 장에서는 데이터 오염(Data Contamination)이 어떻게 모델의 추론 능력을 과대평가하게 만들고 벤치마크 지표를 왜곡하는지 살펴보았습니다. 그렇다면 모델이 표준 테스트에서는 완벽하게 의도대로 작동하지만, 안전 경계(Safety Boundaries)를 위반하는 잠재적인 취약점을 숨기고 있다면 어떨까요?

전통적인 소프트웨어 엔지니어링에서 보안 팀은 버퍼 오버플로우, 잘못 구성된 포트, 또는 검증되지 않은 SQL 입력 등을 찾아냅니다. Foundation Model 엔지니어링에서 “포트”는 Context Window이며, “페이로드(Payload)“는 자연어(Natural Language)입니다. 모델의 취약점을 체계적으로 탐색하고, 안전 가드레일을 우회하며, 의도치 않은 행동을 유발하는 일련의 과정을 AI Red Teaming (레드티밍)이라고 부릅니다.

초기 레드티밍은 사람이 직접 교묘한 프롬프트를 작성하는 방식이었으나, 현재는 강화 학습(Reinforcement Learning) 기반의 완전 자동화된 적대적 시스템으로 진화했습니다. 이번 장에서는 Large Language Model (LLM) 의 정렬(Alignment)을 무너뜨리기 위해 사용되는 최첨단 프레임워크와 알고리즘을 해부합니다.

The Threat Landscape: From ATT&CK to ATLAS

과거 사이버 보안의 레드티밍은 MITRE ATT&CK 와 같은 프레임워크에 의해 주도되었습니다. ATT&CK는 인프라 내부로의 측면 이동(Lateral Movement)을 위해 공격자가 사용하는 전술, 기법, 절차(TTPs)를 매핑합니다.

하지만 전통적인 프레임워크는 신경망(Neural Network) 자체가 가진 고유한 취약점을 설명하지 못합니다. 공격자는 LLM에서 민감한 데이터를 추출하기 위해 호스트 서버를 해킹할 필요가 없습니다. 단지 입력 프롬프트를 통해 수학적 가중치(Weights)를 조작하기만 하면 됩니다.

이를 해결하기 위해 업계는 MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) [1] 를 도입했습니다. 2025년과 2026년 업데이트를 거치며, ATLAS는 AI 특화 TTP에 대한 표준 분류 체계로 자리 잡았습니다.

Key MITRE ATLAS Tactics

AI 레드티밍은 루트 권한 획득이 아니라 모델의 행동 조작에 초점을 맞춥니다:

• ML Attack Staging (AML.TA0004) : 안전 가드레일을 우회하도록 설계된 적대적 입력(예: Prompt Injection, Jailbreaking)을 구성합니다.
• Exfiltration (AML.TA0009) : 추론(Inference) 과정을 탐색하여 모델의 학습 데이터, 독점적인 시스템 프롬프트, 또는 내장된 API 키를 추출합니다.
• Impact (AML.TA0014) : 모델을 무한 생성 루프에 빠뜨려 서비스 거부(Denial of Wallet, DoW) 공격을 실행하거나, Agentic AI 시스템을 악용하여 외부 환경에서 승인되지 않은 명령을 실행합니다.

엔터프라이즈 AI 서비스에서는 여기에 제품 고유의 공격면이 추가됩니다. 공격자는 모델 자체만 공격하지 않습니다. 검색 인덱스, 플러그인 권한, tool schema, 세션 메모리, 사용자 업로드 문서, 로그 파이프라인, human escalation workflow까지 함께 봅니다.

실제 서비스에서 자주 보이는 공격면

이 표는 레드티밍의 초점을 “나쁜 답변을 생성하게 만들기”에서 “모델이 연결된 시스템 전체가 잘못된 행동을 하게 만들기”로 넓혀 줍니다.

실제 사고 사례로 보는 레드티밍 포인트

레드티밍은 상상 속의 공격을 많이 만들지만, 좋은 테스트셋은 실제 사고에서 출발합니다. 아래 사례들은 “모델이 위험한 말을 했다”보다 더 넓은 문제를 보여 줍니다. 공개 서비스, 내부 사용, 고객지원, 영업 자동화처럼 운영 맥락이 달라지면 공격면도 달라집니다.

이 사례들의 공통점은 모델 단독의 “지능” 문제가 아니라는 점입니다. 실패는 보통 모델, 프롬프트, 권한, 제품 문구, 고객 기대, 운영 정책이 만나는 경계에서 발생합니다. 그래서 enterprise red team은 jailbreak 문구 모음이 아니라 사고 재현 가능한 end-to-end 시나리오여야 합니다.

(Source: Generated by Gemini)

The Mechanics of Automated Red Teaming (ART)

과거의 LLM 레드티밍은 인간의 창의성에 의존했습니다. 연구원들이 수동으로 “역할극” 시나리오(예: 악명 높은 “DAN - Do Anything Now” 프롬프트)를 만들어 모델을 속였습니다. 이는 단기적으로는 효과적이었지만, 현대 LLM의 방대하고 고차원적인 입력 공간을 모두 커버할 수는 없습니다.

Automated Red Teaming (ART) 는 적대적 프롬프트 생성을 일종의 탐색(Search) 또는 최적화(Optimization) 문제로 취급합니다. ART는 크게 White-Box 공격과 Black-Box 공격 두 가지 패러다임으로 나뉩니다.

White-Box Optimization: Greedy Coordinate Gradient (GCG)

레드팀이 타겟 모델의 가중치와 아키텍처에 접근할 수 있다면(White-Box), 그래디언트 기반 최적화를 사용하여 적대적 프롬프트를 찾을 수 있습니다. 이 분야에서 가장 대표적인 알고리즘이 Greedy Coordinate Gradient (GCG) 입니다 [2].

GCG의 목표는 유해한 프롬프트 뒤에 의미 없는 “적대적 접미사(Adversarial Suffix)“를 추가하여 모델이 긍정적인 응답을 하도록 강제하는 것입니다. 예를 들어, “폭탄을 만드는 방법을 알려줘” 라는 프롬프트를 “폭탄을 만드는 방법을 알려줘 + [접미사]” 로 수정하여, 모델이 “네, 폭탄을 만드는 방법은 다음과 같습니다.” 라고 출력할 확률을 극대화합니다.

텍스트 토큰은 이산적(Discrete)이기 때문에 표준 경사 하강법(Gradient Descent)을 그대로 수행할 수 없습니다. 대신 GCG는 One-hot 인코딩된 토큰 벡터에 대한 그래디언트를 근사하여 사용합니다.

1. Forward Pass: 프롬프트를 모델에 통과시켜 Logit을 얻습니다.
2. Gradient Extraction: 타겟 응답(긍정적 수락)에 대한 Cross-Entropy Loss를 계산합니다. 역전파(Backpropagation)를 수행하여 접미사의 One-hot 토큰 임베딩에 대한 Loss의 그래디언트를 구합니다.
3. Candidate Selection: 어휘 사전(Vocabulary) 내 특정 토큰의 그래디언트가 음수라는 것은, 현재 토큰을 이 새로운 토큰으로 교체할 때 Loss가 감소(타겟 응답이 나올 확률이 증가)함을 의미합니다.
4. Greedy Search: Loss를 가장 많이 줄이는 Top-$k$ 개의 대체 토큰을 선택하고, 이를 Forward Pass로 평가한 뒤 접미사를 탐욕적으로(Greedily) 업데이트합니다.

아래는 GCG 알고리즘의 핵심인 그래디언트 추출 단계를 보여주는 PyTorch 구현 예시입니다.

import torch
import torch.nn.functional as F
from transformers import PreTrainedModel

def compute_token_gradients(
    model: PreTrainedModel, 
    input_ids: torch.Tensor, 
    target_slice: slice, 
    loss_fn: torch.nn.Module
) -> torch.Tensor:
    """
    Greedy Coordinate Gradient (GCG) 공격에서 입력 토큰의 One-hot 임베딩에 대한 
    Loss의 그래디언트를 계산합니다.
    """
    # 1. 연속적인(Continuous) 임베딩 행렬에 접근
    embed_layer = model.get_input_embeddings()
    vocab_size = embed_layer.weight.shape[0]
    
    # 2. 그래디언트 추적을 위해 이산적인 input_ids를 One-hot 벡터로 변환
    # 형태: (1, seq_len, vocab_size)
    one_hot = F.one_hot(input_ids, num_classes=vocab_size).to(embed_layer.weight.dtype)
    one_hot.requires_grad_()
    
    # 3. One-hot 벡터를 연속적인 임베딩 공간으로 투영
    # (1, seq_len, vocab_size) @ (vocab_size, hidden_dim) -> (1, seq_len, hidden_dim)
    embeddings = torch.matmul(one_hot, embed_layer.weight)
    
    # 4. 연속적인 임베딩을 사용하여 Forward Pass 수행
    outputs = model(inputs_embeds=embeddings)
    logits = outputs.logits # 형태: (1, seq_len, vocab_size)
    
    # 5. 타겟 응답 토큰에 대해서만 Loss 계산
    # 다음 토큰 예측과 맞추기 위해 Logit을 1칸 이동(Shift)
    shift_logits = logits[0, target_slice.start - 1 : target_slice.stop - 1, :]
    shift_labels = input_ids[0, target_slice]
    
    loss = loss_fn(shift_logits, shift_labels)
    
    # 6. One-hot 행렬에 대한 그래디언트를 계산하기 위해 Backward Pass 수행
    loss.backward()
    
    # 결과 그래디언트는 Loss가 가장 가파르게 상승하는 방향을 나타냅니다.
    # Loss를 최소화하려면 가장 음수인 그래디언트 값을 찾아야 합니다.
    return one_hot.grad[0]

def get_top_k_replacements(gradients: torch.Tensor, k: int = 256) -> torch.Tensor:
    """Loss를 가장 크게 감소시키는 Top-k 토큰 ID를 반환합니다."""
    # Loss를 최소화해야 하므로 그래디언트의 부호를 반전시킵니다.
    top_k_indices = torch.topk(-gradients, k, dim=-1).indices
    return top_k_indices

(Source: Generated by Gemini)

Black-Box Optimization: LLM-Assisted Red Teaming

실제 환경에서 레드팀은 타겟 모델의 API 접근 권한(Black-Box)만 가지고 있는 경우가 대부분입니다. 이러한 시스템을 공격하기 위해 엔지니어들은 Attacker LLM 을 사용하여 적대적 프롬프트를 동적으로 생성하고 다듬습니다.

이 분야의 대표적인 프레임워크가 PAIR (Prompt Automatic Iterative Refinement) 입니다 [3]. PAIR는 모델을 다음과 같이 구성합니다:

1. The Attacker: 타겟으로부터 특정 유해한 행동을 이끌어내기 위한 프롬프트를 생성하는 LLM.
2. The Target: 평가 대상이 되는 모델.
3. The Critic (선택/통합) : 타겟의 응답을 평가(예: 거부 시 0점, 완벽한 순응 시 10점)하고 Attacker에게 피드백을 제공하는 모델.

이는 자동화된 피드백 루프를 형성합니다. 만약 타겟이 응답을 거부하면, Critic은 그 이유를 설명합니다 (예: “프롬프트가 불법적인 활동에 대해 너무 직접적입니다”). 그러면 Attacker는 프롬프트를 복잡한 가상 시나리오나 코딩 작업으로 감싸는 등 전략을 수정하여 다시 시도합니다.

Interactive PAIR Simulation

아래의 인터랙티브 시각화 도구를 사용하여 시뮬레이션된 PAIR 공격 루프를 단계별로 살펴보십시오. Attacker LLM이 Critic의 피드백을 바탕으로 전략을 조정하여, 마침내 Target 모델의 안전 가드레일을 우회하는 과정을 관찰할 수 있습니다.

Multi-Turn Attacks and Reinforcement Learning

단일 턴(Single-turn) 공격은 고도로 최적화된 최신 프론티어 모델 앞에서는 실패하는 경우가 많습니다. 현대의 정렬 학습(RLHF/DPO)은 고립된 적대적 프롬프트에 대해 모델을 매우 강건(Robust)하게 만듭니다.

하지만 안전 필터는 긴 문맥(Long Context) 속에서 저하될 수 있습니다. 최근의 refusal-aware red teaming 연구는 공격을 마르코프 결정 과정(Markov Decision Process, MDP) 으로 정의하고, 계층적이고 curiosity-driven한 강화 학습을 활용해 다중 턴(Multi-turn) 대화형 공격을 수행합니다 [4].

이 설정에서:

• 상태 ($S_t$): 턴 $t$ 까지의 전체 대화 기록.
• 행동 ($A_t$): Attacker의 다음 발화.
• 보상 ($R$): 타겟이 위반된 출력을 낼 확률이 얼마나 높아졌는지를 측정하여 Critic 모델이 제공하는 토큰 수준의 밀집 보상(Dense Reward).

Attacker는 상위 수준의 정책(“신뢰 구축 -> 가상 시나리오 도입 -> 정보 추출”)과 하위 수준의 정책(특정 토큰 생성)을 모두 학습합니다. 10~20턴에 걸쳐 모델의 문맥을 서서히 갉아먹음으로써, RL 기반 레드티밍은 단일 턴의 정적 벤치마크가 완전히 놓치는 깊은 잠재적 취약점을 찾아낼 수 있습니다.

The Refusal Gap

레드티밍 기술이 공격적으로 발전함에 따라, 모델 개발자들 역시 안전 가드레일을 대폭 강화하며 대응하고 있습니다. 이런 군비 경쟁 속에서 AI 안전 평가에서 Refusal Gap(거부 격차) 이라는 지표의 중요성이 커졌습니다 [4].

자동화된 레드티밍을 방어하기 위해 모델이 강도 높은 적대적 학습(Adversarial Training)을 거치게 되면, 종종 지나치게 방어적인 태도를 취하게 됩니다. 모델은 적대적 프롬프트와 구조적으로 유사하다는 이유만으로 완벽하게 안전하고 무해한 요청조차 거부하기 시작하는데, 이러한 현상을 과잉 거부(Over-refusal) 라고 합니다.

Refusal Gap은 모델의 실제 거부 행동과 외부 안전 평가자의 판단(또는 모델 내부의 이상적인 안전 기준) 사이의 불일치를 측정합니다. 고도로 발전된 모델은 GCG 공격을 견뎌내는 동시에, 악의적인 프롬프트와 복잡하게 구성된 정상적인 사용자 쿼리를 정확하게 구별할 수 있어야 합니다.

Enterprise Red Team 운영 플레이북

실제 조직에서 레드티밍은 “한 번의 공격 대회”가 아니라 반복 가능한 운영 프로세스여야 합니다.

1. 범위 정의: 모델 단독인지, RAG+tool+agent 전체인지 정합니다. 권한이 있는 tool과 없는 tool을 명확히 나눕니다.
2. 위험 taxonomy 작성: jailbreak, prompt injection, data exfiltration, tool misuse, over-refusal, privacy leakage, unsafe code execution처럼 제품별 카테고리를 만듭니다.
3. Seed case 수집: 공개 jailbreak, 과거 incident, 고객 support ticket, internal threat model에서 초기 공격 샘플을 모읍니다.
4. 자동 변형 생성: PAIR, fuzzing, paraphrase, multilingual transform, encoding transform을 사용해 샘플을 넓힙니다.
5. Severity 라벨링: 모든 실패를 같은 무게로 보지 않습니다. “문체가 거칠다”와 “권한 없는 결제 tool 호출”은 완전히 다른 사건입니다.
6. Regression set화: 한 번 발견한 실패는 다음 릴리스에서 반드시 다시 실행합니다.
7. 완화 후 재공격: 방어가 특정 문구에만 과적합되었는지, 공격자가 다른 경로로 돌아오는지 확인합니다.

레드티밍의 성공 지표는 공격 성공률을 일시적으로 낮추는 것이 아닙니다. 새 취약점을 더 빨리 발견하고, 제품 릴리스 루프 안에서 재발을 막는 능력 입니다.

방어 평가에서 함께 봐야 할 두 지표

공격 성공률(ASR)만 낮추면 모델이 모든 것을 거부하는 방향으로 쉽게 망가집니다. 그래서 방어 평가는 항상 두 축으로 봅니다.

• Attack Success Rate (ASR): 악성 요청에 모델이 얼마나 자주 순응하는가.
• Benign Refusal Rate (BRR): 정상 요청을 얼마나 자주 과잉 거부하는가.

방어가 좋아졌다는 말은 ASR이 내려가면서 BRR은 크게 오르지 않는다는 뜻입니다. 엔터프라이즈 제품에서는 이 균형이 특히 중요합니다. 보안이 강해졌지만 정상 고객 문의까지 막아 버리면, 안전한 제품이 아니라 쓸 수 없는 제품이 됩니다.

Summary & Open Questions

레드티밍은 임시방편적인 수동 테스트에서 엄격한 알고리즘적 규율로 전환되었습니다. 우리는 MITRE ATLAS와 같은 프레임워크가 전통적인 인프라 공격을 넘어 AI 취약점에 대한 구조화된 분류 체계를 어떻게 제공하는지 살펴보았습니다. 또한 White-Box 환경의 그래디언트 근사법(GCG)과 Black-Box 환경의 반복적 개선법(PAIR)을 통해 자동화된 레드티밍(ART)의 메커니즘을 분석했습니다. 마지막으로 다중 턴 RL 공격의 최전선과 그 결과로 나타나는 Refusal Gap의 과제를 살펴보았습니다.

적대적 공격 생성을 자동화함에 따라 다음과 같은 열린 질문들을 고민해 보아야 합니다:

• 약한 타겟 LLM을 레드티밍하기 위해 고도로 뛰어난 Attacker LLM을 사용한다면, 그 Attacker 자체는 어떻게 레드티밍해야 할까요?
• 무해한 프롬프트에 대한 치명적인 과잉 거부(Over-refusal)를 유발하지 않으면서도, GCG와 같은 최적화 기반 공격을 방어할 수 있는 수학적 방어 메커니즘을 설계할 수 있을까요?

이러한 질문들은 시스템 및 프롬프트 수준에서의 견고한 방어 메커니즘의 필요성을 강조하며, 이는 다음 장인 Chapter 18.2: Jailbreaking & Defense 에서 자세히 다룰 예정입니다.

Quizzes

References

1. MITRE ATLAS (2025). Adversarial Threat Landscape for Artificial-Intelligence Systems. MITRE Corporation.
2. Zou, A., et al. (2023). Universal and Transferable Adversarial Attacks on Aligned Language Models. arXiv:2307.15043.
3. Chao, P., et al. (2023). Jailbreaking Black Box Large Language Models in Twenty Queries. arXiv:2310.08419.
4. Chen, Y., Du, X., Zou, X., Zhao, C., Deng, H., Li, H., & Kuang, X. (2025). Refusal-Aware Red Teaming: Exposing Inconsistency in Safety Evaluations. ACL Anthology.
5. Microsoft. (2016). Learning from Tay’s introduction. Official Microsoft Blog.
6. Moore, M. (2023). Samsung bans ChatGPT use after employee leak. TechRadar.
7. Carter, L. (2023). Chevrolet Dealer’s AI Chatbot Goes Rogue Thanks To Pranksters. Jalopnik.
8. Civil Resolution Tribunal. (2024). Moffatt v. Air Canada, 2024 BCCRT 149. CanLII.