실전 가이드 · 3분 · 05.22

Claude Code로 만든 내 에이전트, 출시 전에 red-team 한 번 돌리는 5분 워크플로 — Microsoft RAMPART 핸즈온

loopy vibecoder

#draft #보안 #red-team #RAMPART #Clarity #Microsoft #AI-zero-day #GTIG #cross-prompt-injection #pytest #CI #바이브코딩보안 #화이트해커

핵심 요약 (TL;DR)

5/20 Microsoft AI Red Team(리드 Ram Shankar Siva Kumar)이 RAMPART와 Clarity 두 가지 도구를 GitHub에 오픈소스로 풀었습니다. RAMPART는 Pytest-native AI 에이전트 안전·보안 테스트 프레임워크라 CI/CD에 fixture 한 줄로 끼울 수 있고, Clarity는 "코드 쓰기 전에 문제 정의를 강제하는 sounding board"입니다. 정확히 9일 전(5/11) Google GTIG가 "AI로 작성한 것으로 추정되는 zero-day가 실제 공격에서 처음 발견됐다"고 보고한 흐름에 대한 디펜시브 카운터예요. 바이브코더에게 "red-team이 출시의 게이트"가 되는 첫 표준 도구가 무료로 도착했습니다.

공격은 AI로 빨라졌습니다, 그래서 디펜스도 CI까지 내려와야 합니다

바이브코더 루피입니다. 5/11 Google GTIG가 무거운 보고서를 하나 풀었어요. APT45(북한)·중국 국가 행위자가 AI로 익스플로이트 후보를 수천 개 단위로 스크리닝하고 있고, 그중 하나가 실제 in-the-wild 공격으로 발견됐다는 내용이었습니다. 2FA 우회를 노린 mass exploitation 캠페인이 마지막 단계에서 차단됐어요. "AI로 작성한 것으로 추정되는" zero-day가 등장한 첫 공식 사건입니다. (단정이 아니라 hallucinated CVSS·docstring 패턴 기반 추정이라는 점은 짚어둘게요.)

그 9일 뒤, Microsoft가 디펜시브 카운터를 풀었습니다. 공식 발표는 Microsoft Security Blog에서 직접 확인하실 수 있고, 코드는 GitHub의 microsoft/RAMPART·microsoft/clarity-agent에 올라가 있습니다. 핵심 메시지가 단순해요. "PyRIT는 빌드 끝난 시스템을 보안연구자가 공격하는 도구였다. RAMPART는 엔지니어가 빌드하면서 CI에서 돌리는 도구다."

RAMPART가 메우는 빈자리: pytest 한 줄

RAMPART의 진가는 "이미 익숙한 도구"라는 점에 있습니다. pytest fixture로 들어가서 GitHub Actions·Azure Pipelines에 그대로 끼워지거든요. 잡아내는 위협 카테고리는 cross-prompt injection, data exfiltration, behavioral regression 같은 에이전트 특유의 실패 모드들이에요.

비유하자면 unit test가 "내 함수가 어제와 똑같이 동작하는가"를 매번 검사해주듯, RAMPART는 "내 에이전트가 어제와 똑같이 안전한가"를 매번 검사합니다. 어제 막혔던 prompt injection이 오늘 모델 업데이트로 다시 뚫리는 회귀(regression)를 자동으로 잡는 거죠.

5분 핸즈온: 첫 fixture 깔기

# tests/test_agent_safety.py
import pytest
from rampart import RedTeam, scenarios

@pytest.fixture
def red_team():
    return RedTeam(
        target="http://localhost:8000/agent",
        scenarios=[
            scenarios.CrossPromptInjection(),
            scenarios.DataExfiltration(),
            scenarios.BehavioralRegression(baseline="baseline.json"),
        ],
    )

def test_no_injection(red_team):
    report = red_team.run()
    assert report.severity["critical"] == 0, report.summary()

GitHub Actions에 넣을 때는 pytest tests/test_agent_safety.py 한 줄을 기존 CI 파이프라인 끝에 추가하면 됩니다. main 머지 전에 critical severity가 0이 아니면 PR이 막히는 게이트가 자연스럽게 생기는 거예요. (정확한 API명은 GitHub 레포를 보고 최신 버전 기준으로 맞추셔야 합니다 — 공개 직후라 release tag별로 시그니처가 바뀔 수 있어요.)

Clarity는 "코드 쓰기 전 sounding board"

같이 풀린 Clarity는 결이 다른 도구예요. 코드 작성 전에 문제 정의·해결책 탐색·실패 분석을 강제로 거치게 만드는 "되받아치는 AI thinking partner"입니다. desktop app, web UI, coding agent embed 세 가지 모드를 지원해서 기존 워크플로에 어떤 형태로든 붙일 수 있어요.

바이브코더가 보기엔 spec-kit과 같은 카테고리("코드 짜기 전 단계 도구")이고, 차이는 Clarity가 "동의가 아니라 반박을 디폴트로 한다"는 점입니다. AI에게 무비판적 동의를 받고 시작하는 위험을 한 번 차단하는 거예요.

한국 화이트해커 바이브코더에게 던지는 의미

바이브코딩이 보안과 만나는 자리는 두 방향이 있습니다. "내가 빌드한 에이전트가 안전한가"(디펜스)와 "내가 빌드한 에이전트로 다른 시스템을 어떻게 공격해볼 수 있는가"(공격 시뮬레이션). RAMPART는 정확히 그 첫 방향의 표준 도구가 됐고, 둘째 방향은 같은 5/11 GTIG 보고서가 보여줬듯 국가 행위자 레벨에서 이미 시작된 게임입니다.

외화를 노리는 한국 바이브코더가 보안 니치를 고민한다면, 지금이 정확히 진입 시점이에요. "AI로 작성된 zero-day가 in-the-wild에 처음 등장한 주"에 디펜시브 표준 도구가 무료로 풀렸으니, 이 두 흐름을 같이 다루는 콘텐츠·서비스가 곧 수요로 들어옵니다. 출시 전 red-team 라운드가 "있으면 좋은 것" → "기본 게이트"로 바뀌는 변곡점이거든요.

FAQ

Q. RAMPART가 PyRIT의 fork인가요, 별개 코드베이스인가요?
A. 본 발표문에는 "PyRIT의 후속"이라는 표현이 쓰였습니다. 기술적으로 fork인지 별개인지는 GitHub 레포의 LICENSE·commit history에서 확인 가능해요. 핵심 차이는 사용 시점(빌드 후 → 빌드 중)과 인터페이스(연구자 SDK → pytest fixture)예요.

Q. 한국어 prompt injection 시나리오도 잡히나요?
A. RAMPART의 시나리오는 영어 기반 페이로드가 디폴트지만, 시나리오 클래스를 상속받아 한국어 페이로드를 직접 정의할 수 있는 구조입니다. 한국어 환경에서 운영하는 에이전트라면 자체 한국어 attack corpus를 추가하는 게 권장돼요.

Q. Clarity와 spec-kit 중 하나만 쓰면 되나요?
A. 둘은 보완 관계입니다. spec-kit은 "무엇을 만들지" 명세에 집중하고, Clarity는 "문제 정의가 맞는지"를 되묻는 단계예요. 큰 결정 전에 Clarity로 가설을 깎고, 명세는 spec-kit으로 박는 흐름이 자연스럽습니다.