[AISec] Day 5: Red Teaming AI - 모델과 파이프라인의 취약점을 테스트하는 법

서론: 보안은 설계 문서가 아니라 공격 실험으로 완성된다

LLM/RAG 시스템은 새로운 공격면을 가진다. 정적 리뷰만으로는 실제 취약점이 드러나지 않는다. Red Teaming은 공격자 관점으로 시스템을 반복 검증하는 운영 절차다.

1. Red Teaming 범위 정의

테스트 대상은 모델 하나가 아니라 전체 파이프라인이어야 한다.

1. 입력 채널(프롬프트, 파일 업로드, API)
2. RAG 인덱싱/회수 경로
3. 툴 호출/에이전트 권한
4. 출력 필터/로그/권한 시스템

2. 대표 시나리오

• 직접/간접 프롬프트 인젝션
• 권한 없는 문서 회수 유도
• PII 재구성 및 우회 질의
• 가드레일 회피(표현 변형, 다단계 유도)
• 서비스 간 권한 상승 체인

시나리오는 단발 테스트가 아니라 회귀 테스트로 관리해야 한다.

3. 평가 지표

Red Teaming 효과는 다음 지표로 측정한다.

• 공격 성공률(ASR)
• 취약점 재현률
• 탐지 시간(MTTD)
• 차단/완화 성공률
• 패치 후 재발률

보안팀 지표와 제품팀 SLO를 연결해야 우선순위 충돌이 줄어든다.

4. 운영 프로세스

1. 위협 모델 업데이트
2. 공격 시나리오 설계 및 자동화
3. 사전 환경 테스트(staging/canary)
4. 결과 분류(심각도/영향 범위)
5. 패치 및 회귀 검증

중요한 점은 “한 번의 대회”가 아니라 배포 파이프라인에 통합된 상시 검증이다.

5. 조직 협업 모델

• Security Team: 위협 시나리오/정책 기준
• Platform Team: 테스트 자동화/관측성 계측
• Product Team: 사용자 영향 최소화 대응

세 팀이 동일한 실패 사례를 공유하지 않으면 동일 취약점이 반복된다.

6. 시리즈 종합 체크리스트

1. 인젝션 위협 모델을 입력-회수-출력 전 구간에 적용했다.
2. PII 유출 차단과 권한 기반 retrieval를 결합했다.
3. 벡터DB 보안과 membership inference 대응을 설계했다.
4. 다층 가드레일(네이티브+외부) 구조를 구축했다.
5. Red Teaming을 CI/CD 또는 정기 운영 절차에 통합했다.

시리즈 마무리

AISec의 결론은 명확하다. 모델 자체의 안전성만으로는 충분하지 않다.

실제 방어력은 “모델 + 데이터 파이프라인 + 권한 체계 + 관측성 + 공격 테스트”를 하나의 시스템으로 운영할 때 만들어진다.