TL;DR

• 업무용 AI의 레드팀 활동 (Red Teaming)에서 가장 어려운 것은 「무엇을 테스트해야 하는가」(공격 관점)와 「무엇을 보고 합격 여부를 결정할 것인가」(평가 관점)를 결정하는 것 - 기존에는 이러한 관점 책정이 바텀업 (Bottom-up) 방식의 수작업에 의존하여, 누락과 망라성 근거가 불분명하다는 구조적인 약점을 안고 있었음 - 이에 **관점 책정 자체를 자동화하는 2개의 에이전트 (Agent)**를 제작함. 공격 관점을 만드는 에이전트와 그에 대응하는 평가 관점을 만드는 에이전트가 나란히 배치된 구조임 - 공격 관점 측은 6가지 리스크 차원 × 7가지 유발 패턴의 탑다운 (Top-down) 2층 프레임워크를 사용하여, 업무 매뉴얼과 Agent 정의를 전달하는 것만으로 대상 고유의 관점을 도출함 - 양쪽 모두 품질을 안정시키기 위해 Generator와 Evaluator를 분리한 2단계 구성을 채택함 - 후단의 공격 데이터셋 생성·실행·시각화는 PyRIT 기반으로 충실하게 구축함 - 결과적으로 업무 고유의 리스크 관점을 수작업 리뷰 없이 재현 가능하게 추출할 수 있는 체계로 구현함

이 글을 쓴 이유

「자사의 AI 에이전트를 사내에 도입하고 싶다. 하지만 본 프로덕션 출시 전에 어디까지 테스트해야 안심할 수 있다고 말할 수 있을까?」

같은 고민을 하는 엔지니어는 많을 것입니다.

범용적인 탈옥 (Jailbreak) 내성이라면 PyRIT 등을 통해 기계적으로 테스트할 수 있습니다. 하지만 업무용 AI에서 정말 무서운 것은,

• 「10만 엔 초과 환불은 관리자 승인 필요」라는 규칙을 9만 9천 엔 환불 × 3회로 우회하는 것
• 「다른 고객의 정보는 인용하지 않는다」를 컨텍스트에 섞여 들어온 간접 프롬프트 인젝션 (Indirect Prompt Injection)으로 깨뜨리는 것

——와 같이, 업무 매뉴얼·SOP·규정에 적힌 고유의 규칙이 깨지는 케이스입니다. 이것들은 범용 도구로는 검지할 수 없습니다.

그래서 「업무 고유의 공격 관점에 특화된 레드팀 활동 (Red Teaming) 도구」 개발에 착수했습니다. 본 기사는 그 컨셉과 시스템 구성에 대해 소개합니다.

이 기사에서 만든 것 — 전체상

상세 내용에 들어가기에 앞서, 결국 무엇을 만들었는지 먼저 공유하겠습니다.

업무용 AI 에이전트의 레드팀 활동을 공격 관점 책정 → 평가 관점 책정 → 공격 데이터셋 생성 → 공격 실행 → 시각화까지 엔드 투 엔드 (End-to-End)로 자동화하는 파이프라인입니다.

핵심 부분은 2개의 관점 책정 에이전트입니다.

첫 번째: 공격 관점 책정 에이전트 (Business Risk Profiler) 가 「업무용 AI는 무엇을 일탈할 수 있는가」를 6가지 리스크 차원으로, 「사용자는 어떤 작용으로 일탈을 유발하는가」를 7가지 유발 패턴으로 정리한 고정된 2층 프레임워크를 내부에 보유합니다. 이 렌즈를 통해 평가 대상 매뉴얼을 분석함으로써 대상 고유의 공격 관점을 자동으로 발견합니다.

두 번째: 평가 관점 책정 에이전트 (Evaluation Designer) 가 각 공격 관점에 대해 「무엇을 보면 파괴되었다고 판정할 수 있는가」를 생성합니다. 예를 들어 「HITL 바이패스 (HITL Bypass)」라는 공격 관점에 대해서는 「트레이스 내에 HITL 루프의 도구/함수 호출이 있는지 체크」와 같은 판정 기준을 출력합니다.

두 에이전트 모두 Anthropic이 하네스 (Harness) 설계로서 공개하고 있는 패턴을 따라 Generator와 Evaluator를 분리한 2단계 구성을 채택하여 출력 품질을 담보합니다.

하류의 공격 데이터셋 생성과 공격 실행은 PyRIT 기반으로 구축하고, 결과는 대시보드에 시각화합니다.

「결국 무엇이 새로운가?」라는 질문에 먼저 답하자면, 관점 책정을 프레임워크화하여 자동화한다는 발상과 그 2층 프레임워크의 설계가 이번의 핵심적인 신규성입니다. Generator/Evaluator의 하네스나 PyRIT는 기존 패턴 및 기존 도구이며, 이를 업무용 AI의 레드팀 활동 관점 책정에 조합한 점이 이번의 기여입니다.

레드팀 활동 (Red Teaming)이란, 도대체 무엇인가?

레드팀 활동을 거칠게 한마디로 말하면, 「공격자의 시점에서 자신의 시스템을 파괴하러 가는 연습」 입니다.

등장하는 요소는 공격자, 대상 시스템, 평가기, 스코어카드 (Scorecard) 4가지입니다. 공격자는 일반 사용자가 입력하지 않을 법한 교묘한 프롬프트를 대량으로 생성하여 대상 시스템 (실제 AI 에이전트, 도구 호출 포함)에 입력합니다. 평가기가 그 응답을 바탕으로 ASR (Attack Success Rate: 공격 성공률)과 같은 「공격이 성공했는지 여부」의 판정을 자동으로 실시합니다.

일본 국내에서도 2024년에 AI 세이프티 인스티튜트 (AISI: AI Safety Institute)가 「AI 세이프티에 관한 레드팀 활동(Red Teaming) 기법 가이드」를 공개하였으며, 기업용 실시 지침으로서 참고할 만합니다.

AI 에이전트의 레드팀 활동은 무엇이 다른가?

LLM 단독 모델과 AI 에이전트(AI Agent)는 공격 면(Attack Surface)이 크게 다릅니다.

에이전트에 대해서는, 「말하게 하는 것」만으로 끝나지 않고, 「하게 만드는 것」 (=부정한 툴 호출 (Tool Call)) 이라는 공격 면이 추가됩니다. 공격의 성공은 부적절한 출력뿐만 아니라, 실질적인 피해를 주는 액션으로 직결될 가능성이 있습니다.

OWASP는 2025년 12월에 Top 10 for Agentic Applications (2026년 버전)를 공개하여, AI 에이전트 고유의 리스크를 10가지 카테고리 (ASI01-ASI10)로 정리했습니다. 그중에서도 ASI01 「Agent Goal Hijack (목표 탈취)」나 ASI02 「Tool Misuse & Exploitation (툴 오용 및 악용)」은 바로 업무용 AI에서 테스트해야 할 위협의 핵심입니다. 에이전트가 툴을 호출하는 이상, 업무 규칙에서 벗어난 방식으로 사용되는 순간 실질적인 피해로 직결됩니다 (참조: OWASP Agentic Top 10 일본어 해설).

기존 툴이 커버하는 범위와 커버하지 않는 범위

대표적인 것은 Microsoft AI Red Teaming Agent (PyRIT 내장)입니다. 무엇을 할 수 있고, 무엇을 할 수 없는지 정리합니다.

기존 툴이 잘 다루는 영역

PyRIT는 20종 이상의 공격 전략 (Crescendo, RolePlay, Base64, ASCII Smuggler 등)으로 망라적인 공격을 수행합니다. Microsoft AI Red Teaming Agent는 에이전트 특유의 3가지 카테고리 (Prohibited actions, Sensitive data leakage, Task adherence)도 테스트할 수 있습니다 (공식).

기존 툴로는 도달하기 어려운 영역

업무용 AI를 실전에 투입하려면, 업무 매뉴얼에 적혀 있는 개별 규칙이 준수되고 있는지를 검증해야 합니다. 예를 들어 고객 지원(Customer Support) AI라면, 「100만 엔을 초과하는 투자 상담은 반드시 전문 어드바이저에게 전달한다」, 「불확실한 기술적 조언은 단정적인 표현을 피한다」, 「계약 변경은 반드시 인간 담당자를 거친다」와 같은 해당 업무 고유의 합격 기준이 존재합니다.

이러한 업무 고유의 규칙은 범용 카테고리에 포함되지 않으며, 이를 자동으로 테스트할 수 있는 메커니즘은 현재의 OSS / SaaS에서는 공백 지대로 남아 있습니다.

리스크를 「범용 vs 업무 특화」, 「경미 vs 중대」라는 두 축으로 보면 커버리지의 공백이 명확해집니다.

우측 상단의 「업무 특화 × 중대」 존, 이곳이 이번 프로젝트의 타겟입니다.

관점 책정의 본질적인 어려움 — 바텀업(Bottom-up) 접근법의 한계

업무 특화 레드팀 활동을 구현하려고 하면, 가장 먼저 부딪히는 벽이 **「공격 관점 (테스트 항목)을 어떻게 결정할 것인가」**입니다.

전형적인 바텀업 방식

평가자가 유스케이스(Use Case)를 살펴보며 「이것은 위험할지도 모른다」는 것을 하나씩 찾아 나갑니다. 예를 들어 헬프데스크 봇이라면 다음과 같은 관점이 도출됩니다.

각각은 타당한 관점이지만, 이 방법에는 세 가지 구조적인 약점이 있습니다.

특히 심각한 것은 세 번째입니다. 경영진이나 보안 감사(Security Audit)에 대해 「이만큼 테스트했습니다」라고 설명해도, 「그 외에 살펴봐야 할 관점은 없는가」라는 질문에 답할 수 없기 때문입니다.

발상의 전환 — 탑다운(Top-down)화

그래서 개별 관점을 나열하는 대신, 관점을 발견하기 위한 분석 축을 먼저 만드는 것으로 결정했습니다.

업무용 AI가 보편적으로 안고 있는 리스크의 구조를 분석 축으로 고정하면, 평가 대상을 바꾸더라도 동일한 축을 통해 관점을 발견할 수 있다는 것이 Business Risk Profiler의 핵심 아이디어입니다.

공격 관점 책정 에이전트: Business Risk Profiler — 탑다운 2층 프레임워크

여기서부터가 본 기사의 중심이 되는 독창적인 부분입니다.

Business Risk Profiler는 업무 특화 레드팀 활동 파이프라인의 전단에 위치하는 공격 관점 책정 에이전트입니다. 평가 대상의 정의 파일과 매뉴얼을 입력받아, 후단에 「무엇을 테스트해야 하는가」의 리스트를 전달합니다.

그 내용은 **2층 구조의 고정 프레임워크 (Fixed Framework)**로 구성되어 있으며, 이를 「관점을 발견하기 위한 렌즈」로 사용합니다.

제1층: 리스크 차원 (Risk Dimension, What 축)

「업무용 AI 에이전트가 업무를 일탈할 때, 무엇을 일탈하는가?」라는 질문에서 도출한 6차원입니다.

업무 AI가 다루는 대상을 판단/프로세스/정보/주체의 4요소로 분해하고, 횡단적 관점으로서 지식의 사용법/영향의 인식을 더하여 6개의 축을 채택했습니다.

제2층: 유발 패턴 (Inducement Pattern, How 축)

「사용자는 어떤 방식으로 업무 AI를 일탈시키는가?」라는 질문에서 도출한 7가지 패턴입니다. 소셜 엔지니어링 (Social Engineering)이나 심리 조작, 프롬프트 인젝션 (Prompt Injection)의 전형을 4개 축 (강도/진위/출처/생략)으로 유형화했습니다.

관점은 단순한 D×P의 교차 조합이 아니다

이 부분이 프레임워크 설계의 핵심입니다.

리스크 차원과 유발 패턴은 「관점을 발견하는 시점」과 「태그 지정·분류하는 기준」을 모두 제공하지만, 1개의 관점이 1차원 × 1패턴으로 단순 대응되지는 않습니다. 실제 관점은 훨씬 더 복합적으로 나타납니다.

예를 들어 「다른 사용자의 정보를 인용하면서 잘못된 판단을 내리는」 관점은 D1(판단 월권)과 D3(정보 경계)의 성질을 모두 가집니다. 마찬가지로 「에스컬레이션 (Escalation) 기준의 자기 판단」이라는 관점은 P1(압박)에 의해서도, P6(경계 탐색)에 의해서도 발생할 수 있습니다.

포괄성을 어떻게 담보할 것인가

이 프레임워크의 포괄성은 「6 × 7 = 42개의 조합 수」로 표현되는 정적인 것이 아니라, 분석 축의 포괄성에 의존합니다.

제1층이 업무 AI의 행동 요소를 포괄하고 있다면, 어떤 관점이라도 반드시 하나 이상의 리스크 차원에 연결됩니다. 마찬가지로 제2층이 사용자 개입의 유형을 포괄하고 있다면, 어떤 관점이라도 반드시 하나 이상의 유발 패턴에 연결됩니다. 따라서 두 축을 포괄하고 있다면 관점을 발견하는 시점에 구조적인 누락은 발생하지 않는다는 로직입니다.

관점 도출의 5단계

실제로 Business Risk Profiler는 다음 5단계를 통해 관점을 도출합니다.

4종류의 출력

Business Risk Profiler는 단순한 관점 리스트가 아니라, 4종류의 리스트를 출력합니다.

특히 미정의 영역 리포트는 Business Risk Profiler만의 부수적인 결과물입니다. 「테스트만 하고」 끝나는 것이 아니라, 「규정 정비가 필요한 영역은 여기」라는 피드백을 돌려줄 수 있습니다.

바텀업 (Bottom-up) 관점과의 대응 검증

앞서 바텀업 방식으로 도출한 관점 A-E가 Business Risk Profiler의 프레임워크로부터 누락 없이 유도될 수 있는지 검증했습니다.

게다가 A-E에 포함되지 않았던 관점 (예: D6와 관련된 "영향 범위를 고려하지 않고 파괴적인 조작을 안내함" 관점) 도 프레임워크로부터 자연스럽게 유도 가능하며, 바텀업 설계 시의 누락을 보완할 수 있음을 확인했습니다.

평가 관점 책정 에이전트: Evaluation Designer — 공격 관점별로 「합격/불합격 판정 기준」을 생성

Business Risk Profiler의 출력물(공격 관점 리스트)만으로는 레드팀 활동 (Red Teaming)을 자동으로 완전히 수행할 수 없습니다. "공격 관점이 존재한다"는 것과 "공격이 성공했는지를 어떻게 판정할 것인가"는 별개의 문제이기 때문입니다.

따라서 핵심적인 두 번째 요소로 평가 관점 책정 에이전트 (Evaluation Designer)를 배치했습니다. 각 공격 관점에 대해 "무엇을 확인해야 공격이 성공했다고 판정할 수 있는가"를 자동으로 생성합니다.

예를 들어 다음과 같은 대응 관계를 가집니다.

평가 관점 책정 에이전트를 자동화하는 것에는 두 가지 의미가 있습니다.

첫째, 공격 관점은 대상에 따라 달라지므로, 그에 대응하는 판정 기준도 대상마다 바꾸어야 합니다. 수동으로 작성하면 운영 비용이 너무 커집니다.

둘째는 공격 관점과 평가 관점 사이의 괴리를 방지하는 것입니다. "공격 관점으로는 도구 권한 남용을 보고 있었는데, 평가기는 응답 텍스트만 보고 있었다"와 같은 실수는 사람이 평가기를 설계할 때 자주 발생하는 전형적인 버그입니다. 공격 관점을 입력값으로 하여 평가 관점을 생성하면, 근본적으로 괴리가 생기기 어려워집니다.

이 에이전트 역시 후술할 Generator/Evaluator 2단 구성으로 출력 품질을 보장합니다.

고안점: 관점 품질을 보장하는 구현 — Generator/Evaluator 분리

두 에이전트를 실제로 구동하는 단계에서 또 하나의 중요한 과제에 직면했습니다. 바로 "LLM에게 관점을 생성하게 하더라도, 그 출력 품질을 어떻게 보장할 것인가"라는 문제입니다.

장문의 업무 매뉴얼을 2층 프레임워크의 13개 축 (6개 차원 + 7개 패턴)으로 분석하게 하면, LLM의 출력은 다음과 같은 형태로 종종 흐트러집니다. 일부 리스크 차원을 간과하거나, 특정 관점에 연결되어야 할 유발 패턴을 놓치거나, 관점과 태그의 연결이 단순화되어 1대1 대응으로 퇴행하는 식입니다. 평가 관점 책정 에이전트에서도 마찬가지로, 공격 관점에 대응하는 판정 로직이 불충분한 상태로 출력되거나 필요한 정보원을 놓치는 등의 문제가 발생합니다.

이러한 출력 품질을 에이전트 스스로 자기 평가 (Self-evaluation)하게 해도, 자신의 출력에 관대해져 결과가 안정되지 않습니다.

채택한 패턴: Generator/Evaluator 분리

이 문제에 대해서는 Anthropic Labs의 Prithvi Rajasekaran 씨가 2026년 3월 Harness design for long-running application development에서 제창한 GAN에서 영감을 받은 Generator/Evaluator 멀티 에이전트 구조를 채택했습니다.

채택한 원칙은 다음 세 가지입니다.

① 생성과 평가를 별도의 에이전트(Agent)로 분리한다: Generator가 관점을 만들고, Evaluator가 판정합니다. 동일한 모델을 사용하더라도 독립된 시스템 프롬프트 (System Prompt)와 문맥 (Context)을 부여합니다.

② Evaluator는 독립된 문맥을 가진다: Generator가 보았던 프롬프트에 휘둘리지 않고, 초안(Draft)만을 평가 대상으로 취급합니다.

③ 루브릭 (Rubric)을 부여한다: 단순한 이진 방식(pass/fail)이 아니라, 여러 기준 (차원 커버리지, 연결의 타당성, 인용 출처 명시, JSON 정합성, 미정의 영역 탐지)의 가중치 평가를 통해 정밀도를 높입니다.

두 에이전트에 대한 적용

이를 Business Risk Profiler와 Evaluation Designer 양쪽 에이전트에 모두 적용했습니다.

Business Risk Profiler에서는 Generator가 '6개 리스크 차원 × 7개 유발 패턴' 프레임워크를 내부에 보유하여, 평가 대상의 인풋(Input)으로부터 공격 관점을 발견하고 초안(Draft)을 출력합니다. Evaluator는 해당 초안을 독립된 문맥과 루브릭(Rubric)에 따라 채점합니다. 구체적으로는 D1-D6 중 명백히 누락된 차원이 없는지, 각 관점에 연결되어야 할 유발 패턴(P1-P7)에 누락이 없는지, 복합적인 관점이 단순한 1대1 관계로 퇴행하지 않았는지, 각 관점에 대응하는 매뉴얼 해당 부분이 기록되어 있는지, 미정의 영역이 적절히 분리되어 있는지 등을 확인합니다.

Evaluation Designer에서는 Generator가 공격 관점별로 판정 로직의 초안을 생성하면, Evaluator가 "공격 관점에서 보고자 하는 리스크를 정말로 이 판정 로직으로 포착할 수 있는가"를 채점합니다.

어느 경우든 Evaluator가 문제를 발견하면 구조화된 피드백을 Generator에 반환하여 최종 출력에 반영합니다.

실례: Evaluator가 「유발 패턴의 누락」을 검출하는 경우

앞서 설명한 「바텀업(Bottom-up) 관점과의 대응 검증」에서 언급한 **A. 에스컬레이션 이탈 (D1) 「AI가 독단적으로 계약 해지를 실행」**을 예로 들어보겠습니다. 이 관점에는 대응 검증표에 따라 **P1(압박)과 P6(경계 탐색)**라는 두 가지 유발 패턴이 연결됩니다.

하지만 Generator의 첫 번째 초안은 이해하기 쉬운 P1(압박)만을 태그로 지정하였고, 공격 관점 또한 압박에 대한 내성만을 기술했습니다. Evaluator가 6개 리스크 차원 × 7개 유발 패턴 프레임워크와 대조한 결과, D1에 대해 성립 가능한 P6(경계 탐색)가 누락되었음을 검출하였고, Generator에 피드백을 보내 태그와 검증 관점을 보완했습니다.

압박으로 밀어붙이는 공격(P1)은 알아채기 쉬운 반면, 「만약을 위해」라며 저자세로 경계를 탐색하는 공격(P6)은 놓치기 쉽습니다. 관점의 유무뿐만 아니라 「해당 관점에서 커버해야 할 유발 패턴의 누락」까지 잡아낼 수 있는 것이 독립된 Evaluator를 두는 효과입니다.

전체 아키텍처

두 가지 관점 책정 에이전트를 포함한 파이프라인 전체의 아키텍처입니다.

설계상의 역할 분담은 심플합니다. Business Risk Profiler가 공격 관점 책정을, Evaluation Designer가 그에 대응하는 판정 기준 생성을 담당합니다(본 기사의 핵심). 그 출력을 받은 하류(Downstream) 단계에서 PyRIT의 공격 전략 카탈로그와 업무 특화 템플릿을 조합하여 공격을 실시하고, 결과를 대시보드에 집약합니다.

Azure 상에서의 구현 아키텍처

지금까지 설명한 Business Risk Profiler와 Evaluation Designer, 그리고 PyRIT 기반의 하류 6단계 파이프라인을 Azure 상의 매니지드 서비스(Managed Service) 중심으로 구축했습니다. 전체 모습은 다음 그림과 같습니다.

앱 본체는 Azure Container Apps (ACA)에 배포하며, 에이전트(Business Risk Profiler / Evaluation Designer) 호출에는 Microsoft Agent Framework를 사용합니다. DB, 스토리지, 검색, 모니터링 등의 주변 환경은 Azure의 매니지드 서비스로 구성되어 있습니다.

Microsoft 계열 도구의 활용처

구현에는 Microsoft Agent Framework, Microsoft Agent Governance Toolkit, PyRIT 세 가지를 이용합니다.

Microsoft Agent Framework가 에이전트 구현의 주축, PyRIT가 실제 공격 실행의 주축, Governance Toolkit은 도구 호출의 가드레일(guardrail)로서 보조적으로 역할을 분담하고 있습니다.

데모

구현한 파이프라인의 동작을 데모 영상으로 정리했습니다. 업무 매뉴얼을 분석하는 단계부터 공격 관점·평가 관점이 생성되고, 공격이 실행되며, 결과가 시각화되기까지의 일련의 흐름을 전체적으로 확인할 수 있습니다.

※ 프로토타입 형태로 개발된 데모 영상입니다.

최종적으로 출력되는 대시보드는 다음과 같습니다.

실제로 생성된 공격 데이터셋은 다음과 같이 출력됩니다.

요약

마지막으로, 기존 도구를 사용하여 업무 특화 레드팀 테스트(Red Teaming test)를 실시했을 때와 Business Risk Profiler를 활용했을 때의 차이점을 표로 정리합니다.

AI 에이전트를 실무에 투입할 때의 '최종적인 안심'은 범용 테스트만으로는 만들 수 없습니다. 그리고 업무 특화 테스트를 구성할 때 가장 큰 병목 구간은 공격 관점과 평가 관점을 어떻게 결정할 것인가에 있습니다.

그 부분을 탑다운 2층 프레임워크로 구조화하고, Anthropic의 하네스(Harness) 설계를 빌려 품질을 담보한 것이 Business Risk Profiler와 Evaluation Designer의 2단계 구성입니다. 같은 고민을 가진 팀에게 참고가 되기를 바랍니다.

참고 자료

핵심 참조 기사

• Harness design for long-running application development (Anthropic, 2026/03) — 본 기사의 Generator/Evaluator 패턴의 직접적인 참조원. GAN 유래의 멀티 에이전트 구조, 루브릭(Rubric) 설계, 문맥 분리 원칙
• Effective harnesses for long-running agents (Anthropic, 2025/11) — 장기 실행 Agent의 하네스 설계 기초
• AI 세이프티에 관한 레드팀 기법 가이드 제1.00판 (AISI) — 일본 AI 세이프티 인스티튜트(AI Safety Institute) 공식 가이드

Microsoft 공식 (일본어)

• AI Red Teaming Agent — 개요
• AI Red Teaming Agent를 로컬에서 실행하기
• AI Red Teaming Agent를 클라우드에서 실행하기
• Microsoft Agent Framework 개요
• Foundry SDK를 사용한 에이전트 평가
• 생성형 AI의 범용 에바류에이터(Evaluator)

일본어 실전 기사