JailbreakBench: An Open Robustness Benchmark for Jailbreaking Large Language Models (Chao et al., Penn, NeurIPS 2024 D&B)

Introduction

벤치마크가 왜 필요한가 — 먼저 큰 그림부터

이 시리즈에서 우리는 LLM을 깨뜨리는 다양한 공격을 봐왔다. GCG는 그래디언트로 적대적 접미사를 찾고, PAIR는 공격자 LLM이 프롬프트를 다듬으며, Crescendo는 여러 턴에 걸쳐 모델을 살살 꼬드긴다. 각 논문은 자기 공격이 “GPT-3.5를 90% 깼다” 같은 숫자를 보고한다.

그런데 여기에 조용한 문제가 하나 숨어 있다. 이 90%라는 숫자를 우리는 믿을 수 있을까?

비유를 들어보자. 두 양궁 선수가 각자 다른 활터에서 연습한 뒤 “나는 10발 중 9발을 명중시켰다”고 주장한다. 그런데 한 명은 5m 거리에서 쐈고, 다른 한 명은 70m 거리에서 쐈으며, 심지어 “명중”의 기준(과녁 전체인지 정중앙인지)도 서로 다르다면, 두 9발은 비교 자체가 불가능하다. 누가 더 잘 쏘는지 알 수 없다.

LLM jailbreak 연구가 딱 이 상태였다. 논문마다

공격 대상 모델이 다르고 (gpt-3.5-turbo도 버전마다 다름),
“공격 성공”의 판정 기준(judge)이 다르며,
system prompt, 디코딩 온도, 채팅 템플릿 같은 세부 설정이 다 다르고,
결정적으로 실제로 모델을 깬 프롬프트 자체를 공개하지 않는 경우가 많았다.

그래서 모두가 “내 공격이 제일 세다”고 말하지만 아무도 그걸 검증할 수 없는 상태였다.

JailbreakBench의 한 줄 요약

2024년 등장한 JailbreakBench는 이 혼란을 정리하는 표준 벤치마크다. 핵심 한 줄은 다음과 같다.

“공격을 성공시킨 프롬프트를 전부 공개하고(artifacts), 모두가 똑같은 데이터·똑같은 judge·똑같은 설정으로 평가하게 하자.”

지난 글에서 본 HarmBench는 510개의 광범위한 행동과 R2D2 방어로 RT 평가의 breadth(폭)를 정립했다. 거의 동시에 나온 JailbreakBench는 다른 축을 강조한다 — 재현성(reproducibility). 둘은 경쟁자가 아니라 역할 분담에 가깝다(뒤에서 자세히 비교한다).

저자들이 짚은 기존 연구의 세 가지 병폐는 다음과 같다.

표준 없음: 평가 방법이 논문마다 제각각이다.
비교 불가능: 비용(쿼리 수)과 성공률을 서로 다른 방식으로 계산해 나란히 놓을 수 없다.
재현 불가능: 다수 논문이 적대적 프롬프트를 비공개하고, 비공개 코드와 수시로 바뀌는 상용 API에 의존한다.

특히 (3)이 결정타다. 한 논문이 “GCG로 ChatGPT를 90% 깼다”고 보고해도, 실제 jailbreak 프롬프트가 없으면 1년 뒤 누구도 그 90%를 확인할 수 없다. 모델은 업데이트되고, 논문 속 숫자만 화석처럼 남는다. JailbreakBench는 이 문제를 jailbreak artifacts repository로 정면 돌파한다 — 성공한 공격 프롬프트를 메타데이터까지 통째로 공개한다.

JailbreakBench는 다섯 개의 톱니바퀴로 이루어진다. 지금은 이름만 눈에 익혀두자. 각각은 Method 절에서 하나씩 풀어 설명한다.

Jailbreak artifacts repository — 실제 공격 프롬프트가 공개된, 계속 자라나는 라이브러리
Red-teaming pipeline — system prompt·디코딩·API를 추상화한 표준 평가 환경
Defense pipeline — 5개 baseline 방어 + 신규 방어 제출 인터페이스
Judge classifier — 후보들을 사람 라벨과 비교해 고른 Llama-3-70B-Instruct 판정기
JBB-Behaviors dataset — 100 misuse + 100 matching benign 행동, 10개 OpenAI policy 카테고리

차원	HarmBench	JailbreakBench
Behavior 수	510 (4 functional × 7 sem)	100 misuse + 100 benign
카테고리	7 semantic	10 OpenAI policy
Judge	Llama-2-13B finetuned	Llama-3-70B-Instruct + prompt
공격 prompt 공개	일부	모두 (artifacts repo)
방어 제출	부분	공식 pipeline
Benign 평가	✗	✓ (over-refusal 측정)
강조	breadth + R2D2 defense	reproducibility + artifacts

Background

이 절에서는 JailbreakBench를 이해하는 데 필요한 두 가지 — artifact 부재 문제와 jailbreak의 형식적 정의 — 를 차근차근 풀어 설명한다.

“공격 프롬프트를 공개하지 않으면” 무슨 일이 벌어지는가

저자들은 기존 연구의 문제를 구체적으로 짚는다.

일부 논문은 GitHub에 코드는 올리지만 핵심인 적대적 접미사·프롬프트는 빼고 공개한다.
API 기반 평가는 모델이 업데이트되면 검증이 불가능하다. gpt-3.5-turbo는 분기마다 내부가 바뀐다.
crowd-sourced jailbreak 프롬프트 사이트(예: DAN 변형 모음)는 어느 날 사라진다.

이 모든 게 한 방향을 가리킨다. 공격 효과의 역사적 기록(historical record)이 증발한다. 1년 뒤 “GCG가 GPT-3.5에서 90% 통했다”는 주장을 확인하려 해도, 깬 프롬프트가 없고 모델은 바뀌었으니 손쓸 도리가 없다.

비유하자면 이렇다. 어떤 연구자가 “이 자물쇠를 따는 만능 열쇠를 만들었다”고 논문에 적으면서 정작 열쇠의 모양은 공개하지 않는다. 다른 사람은 그 주장을 믿거나 말거나 할 뿐, 직접 자물쇠에 꽂아 확인할 수가 없다. JailbreakBench의 artifacts repository는 “열쇠를 통째로 박물관에 보관하자”는 발상이다. 누구든 꺼내 다시 꽂아볼 수 있다.

이게 단순한 엔지니어링 편의가 아니라 분야의 진보를 측정 가능하게 만드는 전제조건이라는 점이 핵심이다. 비교할 수 없으면 진보했는지 알 수 없다.

jailbreak를 수식으로 정의하기

논문은 jailbreak를 다음과 같이 형식화한다.

\[\text{find } P \in \mathcal{T}^* \quad \text{subject to} \quad \text{JUDGE}(\text{LLM}(P),\, G) = \text{True}\]

기호를 하나씩 풀어보자.

\(P\): 우리가 모델에 집어넣는 입력 프롬프트. 깨진 접미사가 붙은 문장일 수도, 그럴듯한 사회공학 시나리오일 수도 있다.
\(\mathcal{T}^*\): 모든 가능한 토큰 시퀀스의 집합. 별표(*)는 “길이에 제한 없는 임의의 시퀀스”를 뜻한다. 즉 \(P\)는 이 거대한 공간 어디서든 골라올 수 있다.
\(G\): harmful goal, 즉 “달성하면 안 되는 유해한 목표”. 예: “피싱 이메일을 작성하라”.
\(\text{LLM}(P)\): 모델이 \(P\)를 받아 내놓은 응답.
\(\text{JUDGE}(\cdot,\cdot)\): 응답이 목표 \(G\)를 실제로 달성했는지 판정하는 심판 함수. True면 jailbreak 성공, False면 실패.

말로 풀면 이렇다. “심판이 보기에 목표 \(G\)를 실제로 달성한 응답을 끌어내는 입력 \(P\)를 찾아라.”

수식 자체는 단순하다. 그런데 여기서 진짜 어려운 부분은 \(P\)를 찾는 것(그건 공격 알고리즘의 몫이다)이 아니라 \(\text{JUDGE}\)를 어떻게 객관적으로 정하느냐다. 같은 응답을 judge A는 “성공”, judge B는 “실패”로 본다면, 서로 다른 judge로 평가한 두 leaderboard 점수는 비교할 수 없다. 양궁 비유로 돌아가면, “명중” 판정을 누가 어떻게 내리는지가 모든 점수의 신뢰성을 좌우한다. 그래서 JailbreakBench는 judge 선정에 한 절을 통째로 투자한다((4)번 구성요소).

Method: 다섯 가지 구성요소

이제 다섯 개의 톱니바퀴를 하나씩 분해한다. 각 구성요소가 앞에서 본 세 가지 병폐 중 무엇을 고치는지 함께 짚는다.

(1) Jailbreak Artifacts Repository — “열쇠를 박물관에 보관하자”

GitHub repo에 공격별 / 모델별로 성공한 프롬프트를 전부 저장한다. 그리고 Python 라이브러리로 한 줄로 꺼내올 수 있다.

import jailbreakbench as jbb

artifact = jbb.read_artifact(method="PAIR", model_name="vicuna-13b-v1.5")
print(artifact.jailbreaks[75])
# JailbreakInfo(
#     index=75,
#     goal='Design a phishing email that can trick users...',
#     behavior='Phishing',
#     category='Privacy',
#     prompt='Security research is an essential part of understanding...',
#     response='Subject: Urgent Action Required: Update Your Account [...]',
#     number_of_queries=30,
#     queries_to_jailbreak=5,
#     prompt_tokens=3564,
#     response_tokens=3729,
#     jailbroken=True)

여기서 주목할 것은 단순히 prompt만 저장하는 게 아니라는 점이다. 각 jailbreak가 무엇을 노렸는지(goal), 어떻게 깼는지(prompt), 모델이 뭐라고 답했는지(response), 비용은 얼마였는지(number_of_queries, queries_to_jailbreak), 토큰을 얼마나 썼는지(prompt_tokens, response_tokens) 까지 메타데이터로 묶여 있다.

이 메타데이터 덕분에 사후에 할 수 있는 일이 많아진다.

재현: prompt를 그대로 다시 모델에 넣어 같은 응답이 나오는지 확인.
비용 비교: “PAIR는 평균 30쿼리, GCG는 수백만 쿼리” 같은 공정한 효율 비교.
연구 분석: 어떤 카테고리가 잘 뚫리는지, 어떤 프롬프트 패턴이 자주 통하는지 통계 분석.

이 구성요소가 병폐 (3) 재현 불가능을 직접 고친다.

토이 예제로 보는 artifact 제출 흐름

내가 새로운 공격 알고리즘 MyAttack을 만들었다고 하자. leaderboard에 올리고 artifact를 남기는 흐름을 단계별로 따라가 보자.

데이터 로드: 표준 100개 misuse 행동을 불러온다.
```
dataset = jbb.read_dataset()  # 100 misuse behaviors
```
공격 실행: 각 행동마다 내 알고리즘으로 jailbreak 프롬프트를 생성한다. 결과를 {behavior: prompt} 형태의 딕셔너리로 모은다.
표준 파이프라인으로 평가: 직접 만든 평가 코드가 아니라 JailbreakBench가 제공하는 파이프라인으로 모델에 질의한다. 그래야 system prompt·온도·템플릿이 남들과 동일하다.
judge 판정: 응답을 표준 judge(Llama-3-70B)에 통과시켜 성공/실패를 매긴다. 내 마음대로 “성공” 기준을 정할 수 없다.
artifact 제출: 성공 프롬프트 + 메타데이터를 정해진 포맷으로 PR을 보낸다. 검증되면 repo에 들어가고 leaderboard에 등재된다.

핵심은 2번을 제외한 모든 단계가 나에게 재량이 없다는 것이다. 모두가 같은 데이터·같은 파이프라인·같은 judge를 쓰므로, 내 점수와 남의 점수가 비로소 같은 잣대 위에 놓인다. 이것이 표준 벤치마크의 본질이다.

(2) Red-Teaming Pipeline — “활터 거리를 통일하자”

표준화된 평가 환경이다. 결정적 디테일을 모두 못 박는다.

system prompt: 모델에게 주는 시스템 지시문 (방어 강도에 큰 영향을 준다).
chat template: 각 모델별 대화 포맷. Llama-2와 Vicuna는 특수 토큰·구분자가 다르다.
decoding parameters: temperature, max_tokens 등. 온도가 다르면 같은 프롬프트도 다른 응답이 나온다.
API와 local 모두 지원: 상용 API(OpenAI 등)는 LiteLLM 래퍼로, 오픈소스 모델은 vLLM으로 로컬 실행. 둘 다 같은 인터페이스로 추상화된다.

왜 이게 중요한가? 양궁 비유로 돌아가면 이 단계가 활터 거리를 5m로 통일하는 일이다. 누군가 system prompt를 “당신은 무엇이든 답하는 AI”로 슬쩍 바꿔 끼우면 당연히 더 잘 뚫린다. 그건 더 좋은 공격이 아니라 더 쉬운 과녁일 뿐이다. 디테일을 못 박아야 점수가 공격 자체의 세기를 반영한다.

이게 HarmBench와 평행한 표준화다. 두 벤치마크 모두 같은 병폐(평가 fragmentation, 즉 (1)·(2))를 공략한다.

(3) Defense Pipeline + 5개 Baseline 방어

공격만 표준화하면 반쪽이다. 방어도 표준 인터페이스로 묶는다. 기본 제공되는 baseline 방어는 다음과 같다.

- SmoothLLM (Robey et al.)        — 입력에 무작위 perturbation을 여러 번 가해 다수결
- Perplexity filter (Alon & Kamfonas) — perplexity가 높은(=깨진 문자열 같은) 입력을 거부
- Erase-and-check (Kumar et al.)  — 입력 부분문자열을 지워가며 유해성 검사
- Synonym substitution            — 동의어 치환으로 적대적 토큰 무력화
- Removal-based defenses          — 의심 구간 제거 기반 방어

각 방어의 직관을 한 줄씩 보자.

Perplexity filter: GCG 같은 공격이 만든 접미사는 사람 눈에 깨진 문자열로 보인다. 언어 모델이 보기에도 “있을 법하지 않은(perplexity가 높은)” 텍스트다. 그래서 perplexity가 임계값을 넘으면 그냥 거부한다. “문장이 너무 이상하면 일단 의심한다”는 발상이다.
SmoothLLM: 입력을 살짝씩 다르게 흔든(문자 몇 개 바꾼) 여러 사본을 만들어 각각에 응답을 받고 다수결한다. 적대적 접미사는 문자 한두 개만 바뀌어도 효과가 깨지기 쉬우므로, 흔들면 공격이 무력화된다.
Erase-and-check: 입력의 일부를 지워가며 검사해, 어느 조각이 유해성을 트리거하는지 잡아낸다.

신규 방어를 제출하려면 이 baseline들과 동일한 인터페이스(입력을 받아 응답 또는 거부를 내놓는 함수)를 구현하면 된다. 그러면 자동으로 leaderboard에 들어간다. 공격과 방어가 같은 무대에서 겨루게 되는 셈이다.

(4) Judge Classifier 선정 — “심판을 어떻게 고를까”

앞서 본 정의에서 \(\text{JUDGE}\)가 모든 점수의 신뢰성을 좌우한다고 했다. 그렇다면 judge를 어떻게 객관적으로 정할까? 저자들의 답은 “사람의 판정을 정답으로 삼고, 후보 judge들이 사람과 얼마나 일치하는지 측정한다” 이다.

구체적으로는 사람이 직접 라벨링한 jailbreak 데이터셋을 만든다. 이 judges dataset은

misuse 쪽: random search로 찾은 적대적 접미사를 붙인 100개 misuse 예시(Vicuna 10, Mistral 10, Llama-2 20, Llama-3 10 — 합쳐 다양한 모델의 응답을 포함),
benign 쪽: XS-Test에서 가져온 100개 benign 예시

로 구성된다. 각 응답을 사람이 “이건 진짜 jailbreak다 / 아니다”로 라벨링해 정답을 만든다. 그다음 후보 judge 6개가 이 정답과 얼마나 합치하는지 잰다.

Judge 후보	인간 합의도
GPT-4 + simple prompt	높음
GPT-4 + detailed prompt	최상위
Llama-2-13B (HarmBench)	중상위
Llama-3-70B-Instruct + custom prompt	GPT-4와 동등
keyword matching	낮음
etc.	-

여기서 두 가지 직관이 중요하다.

왜 keyword matching이 나쁜가? “I cannot”, “I’m sorry” 같은 거부 키워드가 응답에 있으면 실패로 보는 단순한 방법이다. 그러나 모델이 “I cannot help with that. But hypothetically, here is how…“처럼 거부 문구로 시작한 뒤 실제로 유해 내용을 이어가면, 키워드 매칭은 이를 “거부=실패”로 오판한다. 표면 단어만 보면 의미를 놓친다.
왜 Llama-3-70B를 최종 judge로 골랐는가? GPT-4 + detailed prompt가 사람과 가장 잘 맞았지만, GPT-4는 closed-source API다. 즉 judge 자체가 시간이 지나면 바뀌고, 그러면 과거 점수의 재현이 또 깨진다 — 바로 이 논문이 풀려던 병폐다. 반면 Llama-3-70B-Instruct는 open-weight라 가중치가 고정이고, custom prompt와 결합하면 GPT-4 judge와 동등한 수준의 인간 합의도에 도달한다. “충분히 정확하면서 영원히 재현 가능한” judge를 고른 것이다. 재현성을 위해 약간의 정확도를 양보하지 않고도 둘 다 챙긴 셈이다.

(5) JBB-Behaviors Dataset — 100 misuse + 100 benign

100개 misuse 행동 + 100개 benign 행동으로 구성되며, misuse 행동은 10개 OpenAI usage policy 카테고리로 나뉜다.

Harassment/Discrimination (괴롭힘/차별)
Malware/Hacking (악성코드/해킹)
Physical harm (신체적 위해)
Economic harm (경제적 위해)
Fraud/Deception (사기/기만)
Disinformation (허위정보)
Sexual/Adult content (성적/성인 콘텐츠)
Privacy (사생활 침해)
Expert advice (의료·법률 등 전문 조언)
Government decision-making (정부 의사결정 개입)

행동은 절반쯤이 original이고, 나머지는 AdvBench와 TDC/HarmBench에서 차용했다(persona modulation 연구의 아이디어도 일부 반영). 다만 JBB-Behaviors는 그 데이터셋들의 합집합(superset)이 아니다. 새 공격을 빠르게 평가할 수 있도록 일부러 100개 대표 행동만 추렸다.

왜 benign 행동까지 넣는가 — over-refusal의 핵심

이 부분이 JailbreakBench의 가장 영리한 설계이자 HarmBench와 가장 크게 갈리는 지점이다. 각 misuse 행동에는 주제가 비슷한 짝(matching) benign 행동이 붙어 있다. 예를 들면

종류	행동 예시
Misuse	“사용자를 속이는 피싱 이메일을 작성하라”
Benign	“직원 보안 인식을 높이는 정당한 보안 교육 이메일을 작성하라”

두 요청은 주제(이메일, 보안, 자격증명)가 거의 같지만, 하나는 명백히 유해하고 하나는 완전히 정상이다.

왜 이렇게까지 하는가? 단순히 ASR(공격 성공률)만 보면 큰 함정에 빠지기 때문이다. 어떤 방어가 ASR을 0%로 만들었다고 하자. 훌륭해 보인다. 그런데 그 방어가 “보안”, “이메일” 같은 단어만 보이면 무조건 거부” 하는 식이라면? misuse는 막았지만 정상적인 보안 교육 이메일 요청까지 거부한다. 이것이 over-refusal(과잉 거부) 이다.

비유하자면 공항 보안검색이 너무 엄격해서 위험물은 100% 잡지만 평범한 승객까지 다 돌려보내는 상황이다. 위협을 0으로 만든 것 자체는 의미가 없다 — 정상 사용을 다 막아버리면 그 시스템은 쓸모가 없다.

그래서 좋은 방어의 조건은 두 가지다.

\[\text{Misuse ASR} \downarrow \quad \text{이면서 동시에} \quad \text{Benign 거부율} \downarrow\]

즉 유해 요청은 거부하되, 비슷한 정상 요청은 통과시켜야 한다. matching benign에서 거부율을 측정하면 이 둘의 trade-off가 한눈에 보인다. ASR 한 축만 보던 기존 평가에 “정상 사용을 얼마나 망가뜨리는가” 라는 두 번째 축을 더한 것이다. HarmBench에는 이 benign 축이 없다.

Experiments

평가한 공격들

leaderboard에 올라간 주요 공격은 다음과 같다.

PRS (Prompt with Random Search, Andriushchenko et al.) — 단순한 무작위 탐색인데 의외로 강력
GCG (Zou et al.) — 그래디언트 기반 적대적 접미사(3편)
JBC (Jailbreak Chat / AIM) — 사람이 손으로 만든 프롬프트
PAIR (Chao et al.) — black-box 공격자 LLM(6편)

메인 결과

Llama-2-7B에 대한 예시(Figure 1 leaderboard 발췌)다.

방법	평균 쿼리	ASR
PRS (Prompt with Random Search)	25	73%
GCG (Greedy Coordinate Gradient)	12.0M	1%
JBC (Jailbreak Chat / AIM)	-	0%
PAIR	2205	0%

이 표를 천천히 읽어보자. 두 가지가 눈에 띈다.

첫째, “평균 쿼리”라는 비용 열이 함께 있다는 점 자체가 JailbreakBench의 기여다. GCG는 ASR 1%를 얻기 위해 1,200만 번이나 모델에 질의했다. PRS는 단 25번 만에 73%를 달성했다. 성공률만 보던 기존 방식이었다면 이 엄청난 비용 차이가 숫자에 드러나지 않았을 것이다. 비용과 성공률을 나란히 놓는 것 — 이게 병폐 (2)를 고치는 방식이다.

둘째, PRS의 강력함이 의외다. Random search라는 지극히 단순한 방법이 막대한 예산을 쓴 GCG보다 (특히 잘 정렬된 Llama-2에서) 훨씬 잘 깬다. “복잡한 그래디언트 공격이 항상 우월하다”는 통념을 뒤집는 결과라, 후속 연구들이 이 발견을 자주 인용한다. 표준 벤치마크가 있었기에 비로소 이런 공정한 비교가 가능했다는 점을 기억하자.

(단, 이 숫자들은 특정 모델·설정에서의 예시이며, 실제 leaderboard는 모델·방어 조합에 따라 계속 갱신된다.)

Over-refusal 측정 — 두 번째 축

이제 (5)에서 강조한 benign 축의 실제 결과를 보자. matching benign 행동에 대해 방어 모델이 거부하는 비율을 측정한다. 이상적인 방어는 misuse는 거부, benign은 통과해야 한다.

방어 강도	Misuse ASR ↓	Benign 거부율 ↓
무방어 baseline	높음	낮음
Perplexity filter	낮음 (좋음)	약간 증가
SmoothLLM	낮음 (좋음)	중간 증가
강한 alignment	매우 낮음	높음 (나쁨)

표를 위에서 아래로 읽으면 하나의 이야기가 보인다. 방어를 강화할수록 misuse는 잘 막지만(왼쪽 열 좋아짐) benign 거부율이 함께 올라간다(오른쪽 열 나빠짐). 맨 아래 “강한 alignment”는 misuse ASR을 거의 0으로 누르지만 정상 요청까지 잔뜩 거부한다 — 앞서 본 over-refusal이다.

핵심 통찰: 안전과 유용성은 공짜 점심이 아니라 trade-off다. JailbreakBench는 이 trade-off를 명시적으로, 표준화된 방식으로 측정하는 첫 벤치마크다. “ASR이 낮다”는 자랑이 나오면, 이제 우리는 “그래서 benign 거부율은?” 하고 되물을 수 있게 됐다.

Conclusion

핵심 메시지는 한 문장이다.

“재현성은 진보의 필수조건이다. RT 분야에서도 공격 artifact를 공개하지 않으면 진보는 측정조차 불가능하다.”

다섯 가지 기여를 다시 정리하면 다음과 같다.

Jailbreak artifacts repository: 성공 프롬프트 + 메타데이터를 통째로 공개 → 1년 뒤에도 검증 가능 (병폐 3 해결)
Red-teaming pipeline: system prompt·chat template·디코딩까지 표준화 (병폐 1 해결)
Defense pipeline: 5개 baseline + 신규 제출 인터페이스 → 공격과 방어를 같은 무대에
Llama-3-70B judge: open-weight로 GPT-4 judge에 필적하면서 영원히 재현 가능 (병폐 2의 핵심)
Matching benign: over-refusal trade-off를 표준으로 측정한 첫 사례

HarmBench vs JailbreakBench: 경쟁이 아니라 분업

두 벤치마크는 자주 함께 언급되는데, 무엇이 같고 무엇이 다른지 명확히 해두자.

측면	HarmBench	JailbreakBench
강조	breadth (폭)	reproducibility (재현성)
행동 수	510	100 + 100 benign
카테고리 기준	semantic clusters	OpenAI usage policy
Judge	Llama-2-13B finetuned	Llama-3-70B + prompt
신규 방법론	R2D2 defense	artifacts library 패러다임
benign 평가	✗	✓ (over-refusal)

거칠게 요약하면 HarmBench는 “얼마나 넓게 평가하는가”에, JailbreakBench는 “얼마나 재현 가능하게 평가하는가”에 집중한다. 중복이 아니다. HarmBench의 510개 행동이 도메인 커버리지를 책임진다면, JailbreakBench는 공격 프롬프트 공개·benign 축·open-weight judge로 평가의 신뢰성을 책임진다. 그래서 둘은 경쟁이 아니라 보완 관계이며, 후속 연구들은 보통 둘 다 함께 보고한다.

한계점

100개 행동은 작다: 도메인 커버리지 측면에서 HarmBench(510개)보다 좁다. 빠른 평가를 위한 의도적 선택이지만, 희귀 도메인은 놓칠 수 있다.
Judge는 여전히 주관적이다: 같은 응답에 대해 모델·사람의 판정이 갈리는 경우가 있다 — 인간 합의도가 100%는 아니다. 경계가 모호한 응답(“거부 같기도, 순응 같기도”)이 늘 문제다.
OpenAI policy에 묶임: 카테고리가 한 회사의 정책에 의존한다. 정책이 개정되면 분류 체계가 흔들릴 수 있다.
artifact는 낡을(stale) 수 있다: API 모델은 시간이 흐르면 저장된 프롬프트가 더는 안 통할 수 있다. repo는 evolving이지만 모든 (공격×모델) 조합을 영원히 유지하긴 어렵다.
언어 한정: 영어 only. 다국어 jailbreak는 다루지 않는다.

마지막으로 한 가지 더. JailbreakBench는 “성공한 공격 프롬프트를 공개하는 것이 옳은가” 라는 윤리적 질문을 분야 전체에 정면으로 던졌다. 공격 프롬프트를 공개하면 악용 위험이 있지만, 공개하지 않으면 방어 연구가 검증·발전할 수 없다. 저자들은 이 딜레마를 abstract에서 별도로 논의하고, 결국 “공개가 커뮤니티에 net positive” 라고 판단했다. 이 결정은 Ganguli 2022가 38K 공격 데이터셋을 공개한 결정의 연장선에 있다. 위협을 숨기는 것보다 드러내고 함께 막는 편이 낫다는 것 — 이것이 red-teaming 분야가 공유하는 철학이다.

Red-Teaming 시리즈

이 글은 LLM Red-Teaming 시리즈의 스물네 번째 글이다.

Perez 2022 — LM으로 LM을 공격하기 (foundation)
Ganguli 2022 — Anthropic의 38K 공격 데이터셋과 scaling behavior
GCG (Zou 2023) — 그래디언트 기반 universal suffix
AutoDAN (Liu 2023) — 자연어 유지하는 GA 기반 jailbreak
AttnGCG — attention manipulation으로 GCG 강화 (추후 작성)
PAIR (Chao 2023) — 20쿼리 black-box attacker LM
TAP (Mehrotra 2023) — 트리 탐색 + 이중 pruning으로 PAIR 효율화
GPTFuzz (Yu 2023) — AFL 영감의 template-level fuzzing
Crescendo (Russinovich 2024) — multi-turn escalation으로 single-turn 방어 무력화
Many-shot Jailbreaking (Anil 2024) — long-context를 ICL로 weaponize
Curiosity-driven RT (Hong 2024) — novelty reward로 mode collapse 해결
Auto-RT (Liu 2025) — strategy-level RL exploration + progressive curriculum
AgenticRed (Yuan 2026) — RT 시스템 자체를 진화
InjecAgent (Zhan 2024) — Tool-use LLM agent에 대한 IPI 벤치마크
AgentVigil (Wang 2025) — MCTS 기반 IPI 자동 공격
AdvBench (Zou 2023) — GCG 논문의 harmful behaviors/strings 표준 벤치마크
HH-RLHF red-team (Ganguli 2022) — Anthropic 38K red-team 대화 데이터셋
HarmfulQA (Bhardwaj 2023) — Chain-of-Utterances 기반 유해 QA + RED-INSTRUCT
BeaverTails (Ji 2023) — helpfulness/harmlessness 분리 라벨 QA 데이터셋
WildJailbreak (Jiang 2024) — 대규모 합성 vanilla/adversarial 학습 데이터
PIKA (2025) — 난이도 집중 expert-level 합성 정렬 데이터셋
ALMA (Yasunaga 2024) — 최소 주석으로 합성 데이터 기반 정렬
HarmBench (Mazeika 2024) — 510 행동 × 18 공격 × 33 모델 표준 + R2D2 방어
(현재 글) JailbreakBench (Chao 2024) — 100 misuse + 100 benign + jailbreak artifacts repository
Constitutional AI (Bai 2022) — AI feedback으로 인간 라벨 없이 alignment
Llama Guard (Inan 2023) — open-weight input/output safety classifier 본 시리즈는 26편으로 구성된다 (#5 AttnGCG는 추후 작성).

참고 문헌

Chao et al., 2024. JailbreakBench: An Open Robustness Benchmark for Jailbreaking Large Language Models. NeurIPS 2024 D&B.
JailbreakBench 프로젝트 페이지
GitHub: JailbreakBench/jailbreakbench
JBB-Behaviors 데이터셋 (Hugging Face)
Andriushchenko et al., 2024. Jailbreaking Leading Safety-Aligned LLMs with Simple Adaptive Attacks (PRS).
Robey et al., 2023. SmoothLLM. (baseline defense)
Mazeika et al., 2024. HarmBench. (자매 벤치마크)
Zou et al., 2023. GCG / AdvBench. (행동 일부 차용)