💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

프롤로그 — 2026년, "안전"은 한 가지 도구로 풀리지 않는다

2026년 5월. 모델 회사는 매달 새 모델을 내고, 앱 회사는 그걸 가져다 에이전트를 만든다. 그리고 매주 누군가는 새 jailbreak를 트윗에 올리고, 매달 어딘가의 AI Safety Institute가 새 평가 보고서를 낸다. 안전은 더 이상 "RLHF 잘 했으니 됐다"로 끝나지 않는다. 안전은 **평가(eval) · 레드티밍(red-team) · 정책(policy) · 표준(standards)** 네 영역이 동시에 굴러가는 시스템이다.

문제는 이 네 영역의 도구가 전부 다르고, 회사마다·정부마다·학계마다 다른 이름을 쓴다는 점이다. Inspect AI는 무엇이고 Garak과는 어디서 다른가? PyRIT은 왜 Microsoft가 만들었고 누가 쓰는가? Promptfoo는 학술용인가 production용인가? OpenAI Evals와 lm-evaluation-harness는 같은 일을 하는가? UK AISI와 한국 AISI는 무엇이 다른가?

이 글은 2026년 현재 AI 안전·평가·레드티밍 생태계를 한 장에 그린다. 도구 하나하나를 깊게 파는 게 아니라, **각 도구가 누가 만들었고 어떤 문제를 풀고 어디에 들어가는지**를 정리한다. 그래서 우리 팀이 "안전 인프라" 한 줄 회의를 할 때, 무엇을 깔고 무엇을 안 깔지 결정할 수 있게.

1장 · 2026년 AI 안전 지도 — eval / red-team / policy / standards 네 영역

먼저 큰 그림. 2026년의 AI 안전 생태계는 네 영역으로 나뉜다. 각 영역은 다른 사람이 만들고 다른 사람이 쓴다.

| --- | --- | --- | --- |

이 네 영역은 서로 의존한다. **Eval은 red-team의 결과를 자동화한다**(새 jailbreak가 발견되면 eval suite에 들어간다). **Policy는 eval 점수를 임계값으로 쓴다**("CBRN 카테고리에서 X% 미만이면 출시 보류"). **Standards는 eval과 red-team이 무엇을 측정해야 하는지의 공통 어휘를 준다**.

이 글의 흐름은 위 순서대로 — eval(2~9장) → red-team(3·4장) → policy(11장) → standards(12장) — 그리고 지역별 차이(13장)와 누가 무엇을 골라야 하는지(14장).

핵심 통찰 한 줄: **"안전"은 한 도구로 풀리지 않는다. 안전은 네 영역의 합이다.** 그리고 2026년 현재, 네 영역을 모두 보고 있는 팀은 거의 없다. 대부분은 한두 영역만 본다.

2장 · Inspect AI (Anthropic, 2024.5) — UK AISI가 쓰는 eval 프레임워크

**한 줄 정의**: Anthropic이 2024년 5월 오픈소스로 공개한 LLM 평가 프레임워크. 영국 AI Safety Institute(UK AISI)가 핵심 평가 도구로 채택했고, 2025~2026년에 사실상 "정부급 평가의 표준"이 됐다.

**왜 만들어졌나**: 2024년까지 LLM 평가 코드는 대부분 "한 번 쓰고 버리는 스크립트"였다. 모델별로 다른 API, 비결정성 처리, 도구 사용(tool-use) 평가, 멀티턴 평가, 채점 모델(judge) — 매번 다시 짰다. Inspect AI는 이걸 한 프레임워크로 묶는다. **Dataset → Solver → Scorer** 세 컴포넌트로 평가를 표현한다.

**핵심 개념 셋**:

- **Task**: 한 평가의 단위. 데이터셋 + solver(어떻게 풀지) + scorer(어떻게 채점할지)를 묶는다.

- **Solver**: 모델이 문제를 푸는 전략. 단순 generate부터 chain-of-thought, tool-use, multi-turn agent까지.

- **Scorer**: 채점 방식. exact match, includes, model-graded(다른 모델이 채점), custom.

from inspect_ai import Task, task

from inspect_ai.dataset import example_dataset

from inspect_ai.scorer import includes

from inspect_ai.solver import generate

@task

def theory_of_mind():

return Task(

dataset=example_dataset("theory_of_mind"),

solver=generate(),

scorer=includes(),

)

이 한 파일이 한 평가다. `inspect eval theory_of_mind.py --model anthropic/claude-sonnet-4-5` 로 돌린다.

**UK AISI의 채택**이 결정적이었다. AISI는 모델 회사로부터 출시 전 모델을 받아 정부 차원의 평가를 한다. 그 평가의 인프라가 Inspect AI다. 이게 사실상 "정부가 인정한 평가 표준"이라는 시그널이 됐고, 2025년부터 US AISI·일본 AISI·한국 AISI도 Inspect AI 기반 평가를 표준 옵션 중 하나로 채택했다.

**언제 쓰나**:

- 모델 회사의 출시 전 능력·안전 평가

- AISI 같은 정부 기관의 외부 평가

- 학계의 새 벤치마크 발표(점점 Inspect AI 호환으로 나온다)

- 앱 회사가 자체 모델 비교를 할 때

**언제 안 쓰나**: 단순 프롬프트 A/B 테스트(Promptfoo가 더 가볍다), production observability(Phoenix·Langfuse가 더 맞다).

3장 · Garak (NVIDIA → 독립) — LLM 취약점 스캐너

**한 줄 정의**: LLM판 nmap·OWASP ZAP. 모델에 알려진 공격 시나리오를 자동으로 쏴서 어디가 깨지는지 보고서를 낸다. NVIDIA가 2023년 시작해, 2024~2025년에 독립 프로젝트로 분리됐다.

**왜 만들어졌나**: Leon Derczynski(NVIDIA, 이후 독립)는 "LLM의 보안 스캐너가 없다"는 문제를 봤다. 웹 보안에는 ZAP·Burp가 있고 네트워크엔 nmap이 있는데, LLM에는 없었다. Garak은 **공격 라이브러리(probe) + 채점기(detector) + 보고서(report)** 세 부분으로 그 자리를 채운다.

**핵심 개념**:

- **Probe**: 한 카테고리의 공격. 예: `dan` (DAN 계열 jailbreak), `promptinject` (Prompt Injection), `lmrc.SlurUsage` (혐오 표현 유도), `realtoxicityprompts`, `goodside` (이전 알려진 공격).

- **Detector**: 모델이 깨졌는지 판단하는 채점기. 키워드 매칭, 모델 기반 판정, toxicity classifier.

- **Generator**: 대상 모델 인터페이스. OpenAI, Anthropic, HuggingFace, REST, 로컬 등.

전체 스캔 (시간 오래 걸림)

garak --model_type openai --model_name gpt-4o-mini

특정 probe만

garak --model_type huggingface --model_name meta-llama/Llama-3-8b \

--probes dan.Dan_11_0,promptinject

보고서: garak.<timestamp>.report.html

**Garak이 보여주는 것**: 모델별로 어느 공격 카테고리에서 깨지는지의 매트릭스. "이 모델은 DAN 11.0에 47% 응답, RealToxicityPrompts에 12% 응답" 같은 식.

**2026년 현재의 가치**:

- 모델 출시 전: 모델 회사가 "최소 기준선"으로 돌린다.

- 앱 출시 전: 회사가 선택한 모델이 우리 use case에서 깨지는 패턴을 본다.

- 학술: 새 jailbreak가 나오면 Garak probe로 PR이 올라온다(공격 DB의 일부).

**한계**: "알려진 공격"이 중심이다. zero-day jailbreak는 못 잡는다. 그래서 PyRIT 같은 "공격을 생성하는" 프레임워크와 보완 관계다.

4장 · PyRIT (Microsoft) — Python Risk Identification Toolkit

**한 줄 정의**: Microsoft AI Red Team이 2024년 오픈소스로 공개한 적대적 평가 프레임워크. Garak이 "알려진 공격 카탈로그"라면, PyRIT은 "공격을 자동으로 만드는 오케스트레이션".

**왜 다른가 (Garak vs PyRIT)**:

| 차원 | Garak | PyRIT |

| --- | --- | --- |

| 주력 | 알려진 공격 스캔 | 적대적 공격 자동 생성 |

| 비유 | nmap·OWASP ZAP | Metasploit |

| 공격 흐름 | 정해진 probe 발사 | LLM이 LLM을 공격(자동 변형) |

| 학습 곡선 | 낮음(CLI 한 줄) | 중간(orchestrator 코드) |

| 누가 만들었나 | NVIDIA → 독립 | Microsoft AI Red Team |

**핵심 개념**:

- **Orchestrator**: 공격 흐름의 조립. Single-turn(한 번 쏘기), Multi-turn(대화하면서 jailbreak), Red Teaming(공격 모델이 대상 모델을 깨려고 시도).

- **Converter**: 같은 의도를 다양한 표현으로 변형. base64 인코딩, ROT13, 다국어 번역, 우회 표현.

- **Scorer**: 응답이 정책을 위반했는지 판정. Azure Content Safety, self-ask, 정규식.

- **Target**: 공격 대상. OpenAI, Azure OpenAI, HuggingFace, 사용자 정의 엔드포인트.

의사 코드 — Red Teaming Orchestrator

from pyrit.orchestrator import RedTeamingOrchestrator

from pyrit.score import SelfAskTrueFalseScorer

orchestrator = RedTeamingOrchestrator(

attack_strategy=...,

chat_target=victim_model, # 공격 대상

red_teaming_chat=attacker_model, # 공격 모델

scorer=SelfAskTrueFalseScorer(...),

)

await orchestrator.apply_attack_strategy_until_completion_async(max_turns=5)

PyRIT의 핵심은 **"한 LLM이 다른 LLM을 자동으로 깨려고 시도"**다. 사람이 매번 새 jailcase를 짜는 게 아니라, 공격 LLM이 대화를 이어가며 우회 표현을 자동으로 시도한다.

**누가 쓰나**: Microsoft AI Red Team 자체, 그리고 Microsoft 고객사의 보안팀. 2025년부터 OpenAI·Anthropic 외부 평가팀도 일부 채택. 학계의 새 jailbreak 논문이 PyRIT orchestrator로 재현되는 사례가 늘었다.

**Garak과 PyRIT 둘 다 필요한가**: 그렇다. Garak은 매일 회귀 스캔(빠르고 정해진 카탈로그), PyRIT은 분기별 깊은 레드팀(시간 들고 새 패턴 발굴).

5장 · Promptfoo (YC) — 프롬프트 테스팅의 사실상 표준

**한 줄 정의**: 프롬프트·모델·체인을 단위 테스트하듯이 비교하는 OSS CLI. Y Combinator를 거쳐 2024~2025년에 가장 빠르게 자리잡았다. JS/TS 생태계의 진입 도구.

**왜 만들어졌나**: 앱 회사 입장에서는 "어떤 모델을 써야 하나" "이 프롬프트가 이전보다 나은가" 같은 단순한 질문이 가장 자주 나온다. Inspect AI는 너무 무겁고, OpenAI Evals는 학술적이다. Promptfoo는 **YAML 한 파일로 케이스 정의 → CLI 한 줄로 비교 → 웹 UI로 결과** 흐름을 만들었다.

promptfooconfig.yaml

prompts:

- "Translate to French: {{text}}"

- file://prompts/translate_v2.txt

providers:

- openai:gpt-4o-mini

- anthropic:claude-haiku-4-5

tests:

- vars:

text: "Hello world"

assert:

- type: contains

value: "Bonjour"

- type: llm-rubric

value: "Translation is natural French, not literal."

`promptfoo eval` 한 줄로 모델 x 프롬프트 매트릭스를 돌리고, `promptfoo view`로 웹 UI에서 diff를 본다.

**Promptfoo가 빨리 자리잡은 이유**:

- 진입 장벽이 낮다(YAML + CLI).

- 빌트인 assertion이 다양하다(contains, regex, llm-rubric, javascript, similar, factuality, latency, cost).

- Red-team 모드가 있다(promptfoo redteam — Garak/PyRIT 만큼은 아니지만 OWASP LLM Top 10 일부 커버).

- CI 통합이 쉽다(GitHub Action, GitLab).

- 데이터셋 import가 쉽다(CSV, JSONL, HuggingFace).

**언제 쓰나**:

- 프롬프트 A/B 테스트(가장 흔한 use case)

- 모델 비교(같은 입력으로 여러 provider)

- CI에서 회귀 검증(이전 프롬프트보다 점수가 떨어지면 fail)

- 가벼운 red-team(OWASP LLM Top 10 입문)

**언제 안 쓰나**: 정부급 평가(Inspect AI), 학술 벤치마크(lm-eval-harness), production observability(Phoenix).

6장 · OpenAI Evals — 오픈소스 평가의 원조

**한 줄 정의**: OpenAI가 2023년 3월 오픈소스로 공개한 평가 프레임워크. "OpenAI가 자기 모델 평가에 쓰는 도구"라는 후광. 2024~2026년에 활동성은 줄었지만 여전히 데이터셋과 패턴의 레퍼런스다.

**왜 중요한가 (역사적 의미)**: 2023년 이전엔 "평가 코드를 어떻게 짜야 하는가"의 공통 패턴이 없었다. OpenAI Evals는 그걸 "Eval class + 데이터 JSONL + sampler" 패턴으로 정리했다. 이 패턴이 이후 다른 모든 프레임워크의 영향을 미쳤다.

**핵심 구조**:

- **Eval class**: 한 평가의 구현 (Python 클래스).

- **JSONL 데이터셋**: 한 줄에 한 샘플 (input, ideal, etc).

- **Sampler**: 모델에 쿼리하는 인터페이스.

- **registry**: YAML로 eval 메타데이터 정의.

evals/registry/evals/my-eval.yaml

my-eval:

id: my-eval.dev.v0

description: My custom eval

metrics: [accuracy]

my-eval.dev.v0:

class: evals.elsuite.basic.match:Match

args:

samples_jsonl: my_eval/samples.jsonl

`oaieval gpt-4o-mini my-eval`로 돌린다.

**2026년의 위치**:

- 새 프로젝트가 OpenAI Evals를 선택하는 일은 줄었다(Inspect AI·Promptfoo가 더 활발).

- 그러나 "수백 개의 reference eval 데이터셋"이 들어 있고, 새 평가의 사실상 ground truth로 자주 인용된다.

- OpenAI 자체는 더 이상 Evals를 단독 인프라로 쓰지 않는다(내부 도구로 옮겨갔다는 추정).

- 호환성 면에서는 Inspect AI가 "OpenAI Evals 데이터셋을 import할 수 있다"고 광고한다.

**언제 쓰나**: 레퍼런스 데이터셋이 필요할 때, 기존 OpenAI Evals 자산을 재활용할 때.

7장 · lm-evaluation-harness (EleutherAI) — 학술 표준

**한 줄 정의**: EleutherAI가 만든 학술용 LLM 벤치마크 러너. HuggingFace 모델 leaderboard의 백엔드. 새 모델 논문의 표 안 숫자가 거의 다 이 도구에서 나온다.

**왜 학술 표준이 됐나**: 2022년 즈음, 새 LLM이 나올 때마다 논문 저자가 자기 평가 스크립트로 MMLU 점수를 보고했다. 그러다보니 같은 모델·같은 벤치마크인데 논문마다 점수가 달랐다. 채점 방식·few-shot 수·프롬프트 차이로. lm-evaluation-harness는 그걸 표준화했다 — "다 같은 코드로 돌린 숫자만 비교한다."

**핵심**:

- 200+ 벤치마크 빌트인(MMLU, HellaSwag, GPQA, ARC, TruthfulQA, GSM8K, HumanEval-derived, BBH, ...).

- HuggingFace `transformers`, `vllm`, OpenAI/Anthropic API, llama.cpp 등 다양한 backend.

- HuggingFace Open LLM Leaderboard의 공식 백엔드.

MMLU 5-shot

lm_eval --model hf --model_args pretrained=meta-llama/Llama-3.1-8B \

--tasks mmlu --num_fewshot 5 --device cuda --batch_size 8

여러 벤치마크 한 번에

lm_eval --model hf --model_args pretrained=... \

--tasks mmlu,gpqa,hellaswag,arc_challenge --num_fewshot 5

**Inspect AI와의 관계**: 겹친다. lm-eval-harness는 "정해진 학술 벤치마크 표준 러너"에 강하고, Inspect AI는 "커스텀 평가·agent·multi-turn"에 강하다. 2026년 현재 둘 다 살아 있고, 모델 회사·AISI는 보통 둘 다 쓴다(서로 다른 워크플로우에).

**언제 쓰나**:

- 새 모델의 논문용 벤치마크 표

- HuggingFace 리더보드 제출

- "다른 모델과 동일 조건 비교"가 필요할 때

8장 · MLflow Evals / Arize Phoenix / DeepEval / Giskard — 운영 영역의 4총사

위 도구들이 "평가 인프라"라면, 이 네 개는 **평가와 observability의 경계**에서 일한다.

MLflow Evals (Databricks)

MLflow에 2023년 추가된 LLM 평가 모듈. ML 라이프사이클 안에서 "이 모델 실험과 저 모델 실험을 비교"하는 흐름에 들어간다. Databricks 고객 기본 옵션. 빌트인 평가 메트릭이 LLM 시대용으로 확장됐다(`mlflow.evaluate(model_type="question-answering")`).

**언제 쓰나**: MLflow을 이미 쓰는 ML 팀. ML 모델과 LLM을 한 라이프사이클로 관리할 때.

Arize Phoenix (오픈소스)

OpenTelemetry 기반의 LLM observability + eval. trace를 받아 시각화하고, 그 trace 위에서 평가를 돌린다. **Tracing 우선, eval은 거기에 얹는 흐름**. 자기-호스팅 OSS와 SaaS(Arize) 둘 다 있다.

**언제 쓰나**: production traffic을 보면서 평가하고 싶을 때. RAG 디버깅("왜 이 retrieval이 틀렸지").

DeepEval (Confident AI)

"pytest 같은 LLM 평가". Python 단위 테스트 데코레이터로 LLM eval을 짠다. 빌트인 메트릭이 풍부하다(GEval, AnswerRelevancy, Faithfulness, ContextualPrecision/Recall, Hallucination, ToxicityMetric, BiasMetric).

의사 코드

@pytest.mark.eval

def test_answer_quality():

metric = AnswerRelevancyMetric(threshold=0.7)

test_case = LLMTestCase(input="...", actual_output="...")

assert_test(test_case, [metric])

**언제 쓰나**: Python 개발자가 익숙한 pytest 흐름으로 LLM eval을 짜고 싶을 때.

Giskard (오픈소스)

ML 모델(전통 ML + LLM 둘 다)의 **편향 · 견고성 · 드리프트** 검출에 강점. 자동으로 issue를 발견한다(예: 인구 통계 그룹별 정확도 차이).

**언제 쓰나**: 규제 산업(금융·헬스케어). 편향·공정성 보고서가 필요할 때.

**4총사 요약 표**:

| 도구 | 주력 | 누가 쓰나 |

| --- | --- | --- |

| MLflow Evals | ML 라이프사이클 통합 | Databricks 고객 |

| Phoenix | Tracing + eval | RAG·agent observability 팀 |

| DeepEval | Pytest 스타일 | Python 개발자 |

| Giskard | 편향·드리프트 | 규제 산업 |

9장 · 벤치마크 배터리 — HumanEval / MMLU / GPQA / SWE-Bench / BigCodeBench

도구가 아니라 **데이터셋**. 2026년 현재 새 모델 발표마다 표에 들어가는 표준 배터리.

HumanEval (OpenAI, 2021)

164개 파이썬 함수 작성 문제. 모델이 docstring을 보고 함수 본문을 채운다. 채점은 단위 테스트 통과 여부. "코드 생성 능력"의 가장 오래된 벤치마크. 2026년 현재 거의 saturated(상위 모델 95%+)이지만 여전히 표준 한 줄.

MMLU (Massive Multitask Language Understanding, 2021)

57개 학문 분야의 객관식 문제 약 16,000개. 4지선다. "광범위한 지식"의 표준. 2026년 현재 상위 모델은 90%+이고, 여기서 갈리는 게 별로 없어 **MMLU-Pro**(2024, 더 어려운 버전)와 **HLE** (Humanity's Last Exam, 2025)로 보강한다.

GPQA (Google-Proof Q&A, 2023)

대학원 수준 과학 문제 약 448개. 전문가도 65% 정도. Google 검색으로도 풀리지 않게 설계. "진짜 어려운 추론"의 대표. 추론 모델(o-시리즈, Claude의 extended thinking) 이후 점수가 빠르게 올랐다.

SWE-Bench / SWE-Bench Verified (Princeton, 2024)

실제 GitHub 이슈를 보고 PR을 만드는 task. 채점은 PR이 원래 통과시켜야 할 단위 테스트를 통과시키는가. Verified는 OpenAI가 사람이 검토해 풀이 가능성·테스트 정확성을 검증한 500개 서브셋. **에이전트 평가의 대표 벤치마크**.

BigCodeBench (BigCode, 2024)

HumanEval보다 훨씬 현실적인 코드 생성 — 표준 라이브러리·외부 라이브러리(NumPy, Pandas, etc) 호출이 섞인 1,140개 문제. HumanEval saturate 이후의 후속.

**기타 자주 보이는 것**:

- **GSM8K / MATH**: 수학.

- **BBH (Big-Bench Hard)**: BIG-bench의 어려운 서브셋.

- **ARC / ARC-AGI**: 추상 추론.

- **WebArena / VisualWebArena / OSWorld**: 에이전트가 브라우저·OS를 조작.

- **τ-bench (tau-bench)**: 멀티턴 고객 서비스 agent.

핵심: 한 벤치마크만 보면 안 된다. **MMLU/GPQA(지식)·HumanEval/BigCodeBench/SWE-Bench(코드)·MATH(수학)·τ-bench/SWE-bench(agent)** 같이 배터리로 보고, 우리 use case와 가까운 걸 가중치 높게 봐야 한다.

10장 · AI Safety Institute — UK / US / 일본 / 한국 / 싱가포르 / 프랑스

2024년 영국이 첫 AI Safety Institute(UK AISI)를 세운 이후, 2025~2026년 사이 주요국 대부분이 동일 모델의 기관을 만들었다.

UK AISI (2023.11 발표, 2024 운영)

세계 첫 AISI. 영국 정부 산하. **사전 출시 모델 평가**(deployment 전 모델을 받아 위험 평가)와 **공동 연구**가 중심. Inspect AI 프레임워크의 핵심 사용자이자 사실상 후원자. 2024~2025년 보고서는 학계의 표준 참조가 됐다.

US AISI (2024년 NIST 산하 설립)

NIST(National Institute of Standards and Technology) 안에 설립. 미국 정부의 AI 안전 평가·표준 개발. NIST AI Risk Management Framework(AI RMF)의 운영 기관 역할도 겸한다.

일본 AISI (AI Safety Institute of Japan, 2024년 IPA 산하)

IPA(Information-technology Promotion Agency) 산하. 일본 정부의 AI 안전 평가·정책 자문. 가이드라인·평가 방법론 문서 발간.

한국 AISI (2024년 발표)

ETRI(한국전자통신연구원) 중심으로 구성. 정부 차원의 AI 안전 평가·표준화 활동. KAIST·KISTI 등 학계와 협력.

싱가포르 AI Verify Foundation (2023)

엄밀히 "AISI"라는 명칭은 아니지만 동급 기관. AI Verify(평가 toolkit)와 Project Moonshot(LLM red-team toolkit)을 OSS로 공개.

프랑스 AI Safety Office (Inria 산하, 2024)

Inria(프랑스 국립 연구소) 안에 설치. 유럽 차원에서는 EU AI Office와 협력.

**공통점**:

- 정부 자금.

- 사전 출시 평가(주요 모델 회사와 MoU).

- 공동 평가 방법론 개발(국제 협력 — AISI Network).

- 결과 공개(보고서 발간).

**왜 중요한가**: 2026년 시점에서 **"무엇이 위험한지"의 공통 어휘가 AISI들에서 나온다**. CBRN(화학·생물·방사선·핵), 사이버 공격, 자율성, 모델 기만 같은 카테고리 정의가 AISI 평가 보고서에서 표준화되고 있다.

11장 · OpenAI Preparedness Framework + Anthropic RSP

두 모델 회사의 **자체 안전 정책 문서**. "어디까지의 위험이면 출시할지" 회사 내부 의사결정을 외부에 공개한 문서다.

OpenAI Preparedness Framework (2023.12 발표, 이후 개정)

OpenAI가 자체적으로 정의한 **위험 카테고리별 임계값**:

- 카테고리: Cybersecurity, CBRN, Persuasion, Model Autonomy.

- 각 카테고리에서 모델의 위험을 Low / Medium / High / Critical로 평가.

- 임계값 이상이면 출시 보류 또는 mitigation 의무.

- "Preparedness Team" 별도 조직, "Safety Advisory Group" 의사결정.

Anthropic Responsible Scaling Policy (RSP, 2023.9 발표, 이후 개정)

Anthropic의 동급 문서. **AI Safety Level(ASL)** 개념:

- ASL-1: 명백히 무위험 (예: 작은 모델, 게임 AI).

- ASL-2: 현재의 frontier 모델 — 약간의 위험 신호.

- ASL-3: 자율성·사이버·CBRN에서 실질적 위험.

- ASL-4+: 향후 정의.

각 레벨에 대응하는 **deployment standard와 security standard**가 정의돼 있다. ASL-3 이상은 더 강한 weight 보안, 더 엄격한 deployment 검증이 필요하다.

공통 패턴

- "위험 카테고리 정의 → 평가 → 임계값 → 의사결정 게이트".

- **평가**가 이 의사결정의 입력이다 — 그래서 Inspect AI·red-team 도구가 정책 게이트의 인프라가 된다.

- 2025년 이후 Google DeepMind도 비슷한 Frontier Safety Framework을 발표, 사실상 frontier lab의 공통 패턴이 됐다.

**Voluntary commitments vs 법적 의무**: 위 두 문서는 모두 회사의 자발적 약속이다. 법적 강제력은 EU AI Act가 들어온 2025년 이후 GPAI(General Purpose AI) 의무로 일부 반영됐고, 미국은 SB 53(캘리포니아 transparency act) 같은 주(州) 단위 입법이 들어왔다.

12장 · MITRE ATLAS + OWASP LLM Top 10

산업 표준의 두 기둥.

MITRE ATLAS (Adversarial Threat Landscape for AI Systems)

MITRE의 ATT&CK(전통 사이버 공격의 표준 분류)을 AI 시스템 공격용으로 확장한 매트릭스. 2020년 초기 공개, 2024~2026년에 LLM/GenAI 전술이 대거 추가됐다.

**구성**:

- **Tactics (전술)**: Reconnaissance, Resource Development, Initial Access, ML Model Access, Execution, Persistence, Defense Evasion, Discovery, Collection, Exfiltration, Impact.

- **Techniques (기법)**: 각 전술 안의 구체적 공격. 예: "Jailbreak via Multi-Turn Coaxing", "Prompt Injection", "Model Theft", "Data Poisoning".

- **Case Studies**: 실제 발생한 공격 사례.

**누가 쓰나**: 보안팀이 "우리 AI 시스템에 적용 가능한 공격을 빠짐없이 따져본다"는 체크리스트로. red-team 보고서의 분류 어휘.

OWASP LLM Top 10 (2023 v1 → 2025 v2)

OWASP가 정의한 LLM 애플리케이션의 가장 흔한 10가지 보안 위험. 2025 버전(v2) 항목:

1. Prompt Injection

2. Insecure Output Handling

3. Training Data Poisoning

4. Model Denial of Service

5. Supply Chain Vulnerabilities

6. Sensitive Information Disclosure

7. Insecure Plugin/Tool Design

8. Excessive Agency

9. Overreliance

10. Model Theft

**왜 중요한가**: 앱 개발자에게 가장 친숙한 어휘. "우리 앱은 OWASP LLM Top 10에 대응했다"가 컴플라이언스 체크리스트의 한 줄이 됐다.

**도구와의 매핑**:

- Promptfoo redteam 모드 → OWASP LLM Top 10 일부 자동 점검.

- Garak probe → OWASP의 카테고리에 매핑된다.

- PyRIT orchestrator → OWASP 시나리오를 시뮬레이션.

ATLAS vs OWASP LLM Top 10

- ATLAS: 광범위·전술 중심·전 AI 시스템(ML·CV·LLM).

- OWASP: 좁고·앱 중심·LLM 한정.

- 둘 다 본다. ATLAS는 위협 분석에, OWASP는 앱 보안 체크리스트에.

13장 · 한국 / 일본 — KAIST, KISTI, AI Safety Institute of Japan, RIKEN AIP

한국

- **KAIST AI Safety 그룹**: KAIST 안의 AI 안전·정렬 연구. 학계 차원에서 안전·해석성 논문을 내는 중심.

- **KISTI (한국과학기술정보연구원) Safety**: 정부 출연 연구기관. 데이터·인프라 차원의 안전(데이터셋 거버넌스, 인프라 보안)에 강점.

- **ETRI (한국전자통신연구원)**: 한국 AISI의 운영 주체. 정부 차원의 표준·평가 개발.

- **TTA (한국정보통신기술협회)**: AI 신뢰성 표준.

- 산업 측: 네이버 CLOVA Safety, 카카오 안전·윤리팀, LG AI Research 안전 그룹.

한국의 강점: **한국어 평가 데이터셋**(KoBest, KMMLU, 한국어 toxicity 등)과 **K-pop·법령·의료** 같은 한국 특화 도메인에서의 안전 평가.

일본

- **AI Safety Institute of Japan**: 2024년 IPA 산하 설립. 정부 차원의 안전 평가·가이드라인.

- **RIKEN AIP (Center for Advanced Intelligence Project)**: 일본 최대 AI 연구 센터. 안전·정렬·신뢰성 연구.

- **NICT (정보통신연구기구)**: 일본어 LLM(JapaneseLM 시리즈) + 안전 평가.

- 산업 측: SoftBank·NTT·Rakuten의 사내 안전 그룹.

일본의 강점: **일본어 평가 데이터셋**(JGLUE, llm-jp-eval), 그리고 **위계·정중 표현·문화 특화** 평가.

공통 흐름

2025~2026년 사이, 한일 모두에서 "**자체 LLM이 영어 모델 대비 우리 언어·문화에서 안전한가**"를 평가하는 데이터셋이 빠르게 늘었다. 영어 평가 도구(Inspect AI·lm-eval-harness)를 그대로 쓰되, 데이터셋 레이어에서 자국어를 채우는 패턴.

14장 · 누가 무엇을 골라야 하나 — 모델 출시 / 앱 통합 / 거버넌스 / 학술

마지막 장. 페르소나별 권장 스택.

A. 모델 회사 (frontier lab의 안전·평가 팀)

- **필수**: Inspect AI(custom eval + AISI 호환), lm-evaluation-harness(학술 벤치마크 호환), PyRIT(레드팀 자동화), 자체 내부 platform.

- **권장**: Garak(외부 회귀 스캔), OpenAI Evals(레퍼런스 데이터셋 import), Anthropic RSP / OpenAI Preparedness 같은 자체 정책 문서.

- **출시 게이트**: 정책 문서(RSP/Preparedness)의 임계값 ← 평가(Inspect AI) + 레드팀(PyRIT) 결과.

B. 앱 회사 (Foundation 모델을 가져다 쓰는 팀)

- **필수**: Promptfoo(프롬프트 A/B + CI 회귀), 어느 observability(Phoenix·Langfuse·LangSmith 중 하나).

- **권장**: DeepEval(pytest 통합), Garak(분기별 외부 모델 보안 검사), OWASP LLM Top 10 체크리스트.

- **선택**: Inspect AI(사내 자체 벤치마크가 커지면), Giskard(규제 산업).

C. 거버넌스 / 컴플라이언스 / 보안팀

- **필수**: OWASP LLM Top 10(체크리스트), MITRE ATLAS(위협 분석), NIST AI RMF / ISO 42001(거버넌스 프레임).

- **권장**: PyRIT(분기 red-team), Garak(외주 펜테스트와 별개로 자체 회귀 스캔), Giskard(편향 보고서).

- **자문**: 자국 AISI의 평가 방법론과 가이드라인.

D. 학계 / 연구자

- **필수**: lm-evaluation-harness(논문 표준), Inspect AI(새 eval 발표).

- **권장**: OpenAI Evals(레퍼런스), Promptfoo(가벼운 실험).

- **연구 영역별**: jailbreak 논문이면 PyRIT/Garak 재현, 안전 분류기면 Atla 같은 안전 분류기 베이스라인.

조합의 일반 원칙

- **Eval과 red-team은 분리**해서 운영해라(다른 사람이 만든다, 다른 주기로 돈다).

- **CI에 들어가는 eval**(매 PR)과 **분기 깊은 red-team**(매 분기)을 구분해라.

- **데이터셋은 자국어·자국 도메인을 추가**해라(영어 벤치마크만 보면 우리 use case에서 어떤지 모른다).

- **정책 문서를 흉내내라** — frontier lab의 RSP/Preparedness 패턴은 작은 팀에도 적용된다("어떤 카테고리에서 어느 수준이면 출시 보류"를 명문화).

**한 줄 결론**: 2026년의 안전은 한 가지 도구로 풀리지 않는다. 네 영역(eval·red-team·policy·standards)을 자기 팀 규모에 맞게 조합하는 게 안전 인프라의 일이다. 그리고 그 조합의 출발점은 **"누가 무엇을 만들었고 무엇을 풀려고 했는가"**를 아는 것 — 이 글이 그 한 장 짜리 지도가 되기를.

참고 / References

- Inspect AI (Anthropic, 공식): https://inspect.aisi.org.uk/ (UK AISI 호스팅 문서)

- Inspect AI GitHub: https://github.com/UKGovernmentBEIS/inspect_ai

- Garak (LLM vulnerability scanner): https://github.com/NVIDIA/garak

- Garak paper, "garak: A Framework for Security Probing Large Language Models", Derczynski et al., arXiv:2406.11036

- PyRIT (Microsoft): https://github.com/Azure/PyRIT

- PyRIT introduction (Microsoft Security blog): https://www.microsoft.com/security/blog/2024/02/22/announcing-microsofts-open-automation-framework-to-red-team-generative-ai-systems/

- Promptfoo: https://www.promptfoo.dev/ , GitHub: https://github.com/promptfoo/promptfoo

- OpenAI Evals: https://github.com/openai/evals

- lm-evaluation-harness (EleutherAI): https://github.com/EleutherAI/lm-evaluation-harness

- HuggingFace Open LLM Leaderboard: https://huggingface.co/spaces/open-llm-leaderboard/open_llm_leaderboard

- HumanEval, "Evaluating Large Language Models Trained on Code", Chen et al., arXiv:2107.03374

- MMLU, "Measuring Massive Multitask Language Understanding", Hendrycks et al., arXiv:2009.03300

- GPQA, "GPQA: A Graduate-Level Google-Proof Q&A Benchmark", Rein et al., arXiv:2311.12022

- SWE-bench, "SWE-bench: Can Language Models Resolve Real-World GitHub Issues?", Jimenez et al., arXiv:2310.06770

- SWE-bench Verified (OpenAI 발표): https://openai.com/index/introducing-swe-bench-verified/

- BigCodeBench: https://github.com/bigcode-project/bigcodebench , arXiv:2406.15877

- DeepEval (Confident AI): https://github.com/confident-ai/deepeval

- Arize Phoenix: https://github.com/Arize-ai/phoenix

- MLflow Evals: https://mlflow.org/docs/latest/llms/llm-evaluate/index.html

- Giskard: https://github.com/Giskard-AI/giskard

- UK AI Safety Institute: https://www.aisi.gov.uk/

- US AI Safety Institute (NIST): https://www.nist.gov/aisi

- AI Safety Institute of Japan: https://aisi.go.jp/

- Singapore AI Verify Foundation, Project Moonshot: https://aiverifyfoundation.sg/

- OpenAI Preparedness Framework: https://openai.com/safety/preparedness

- Anthropic Responsible Scaling Policy: https://www.anthropic.com/news/anthropics-responsible-scaling-policy

- Google DeepMind Frontier Safety Framework: https://deepmind.google/discover/blog/introducing-the-frontier-safety-framework/

- MITRE ATLAS: https://atlas.mitre.org/

- OWASP Top 10 for LLM Applications: https://owasp.org/www-project-top-10-for-large-language-model-applications/

- NIST AI Risk Management Framework: https://www.nist.gov/itl/ai-risk-management-framework

- ISO/IEC 42001 (AI management systems): https://www.iso.org/standard/81230.html

- EU AI Act: https://artificialintelligenceact.eu/

- KMMLU (Korean MMLU): arXiv:2402.11548

- JGLUE (Japanese GLUE): https://github.com/yahoojapan/JGLUE

- RIKEN AIP: https://aip.riken.jp/