AI 레드팀은 출시 직전 행사가 아니라 제품 요구사항이다

핵심 요약

AI 레드팀은 모델에 위험한 문장을 입력해 보는 일만이 아니다. 검색 데이터, 사용자 권한, 도구 호출, 출력 렌더링, 로그와 대응 절차까지 제품 전체를 반복 검증해야 한다. 출시 기준에는 재현 가능한 공격 사례, 차단 위치, 잔여 위험, 운영 탐지 신호가 포함돼야 한다.

생성형 AI 기능의 레드팀을 출시 직전 일주일에 몰아서 진행하면 대개 두 가지 결과 중 하나가 나온다. 심각한 문제가 발견돼도 일정 때문에 완화책만 붙인 채 출시하거나, 테스트가 모델 답변의 불쾌함과 정책 위반 여부에만 머물러 실제 권한 우회와 데이터 노출을 놓친다. 이는 레드팀을 보안 행사로 보고 제품 요구사항으로 보지 않았기 때문이다.

AI 기능은 모델 하나가 아니다. 사용자 입력, 시스템 지침, 검색 인덱스, 문서 권한, 플러그인과 도구, API 자격증명, 후처리 코드, 화면 렌더링, 평가 로그가 연결된 시스템이다. 공격자는 이 연결부를 이용한다. 따라서 레드팀의 대상도 모델 동작과 주변 실행 경계 전체여야 한다.

먼저 시스템 경계를 그린다

테스트 케이스를 만들기 전에 다음 흐름을 한 장으로 정리한다.

사용자·외부 콘텐츠
  → 입력 정규화
  → 시스템/개발자 지침
  → 검색·메모리·파일
  → 모델 추론
  → 도구 선택과 인자 생성
  → 권한 검증과 실제 실행
  → 출력 검증·렌더링
  → 사용자·외부 시스템

각 화살표마다 신뢰 수준, 데이터 민감도, 실행 권한, 로그 위치를 표시한다. 특히 사용자가 볼 수 없는 시스템 프롬프트를 “비밀 경계”로 취급하면 안 된다. 모델이 읽는 문자열은 공격자가 간접적으로 영향을 줄 수 있다고 가정하고, 진짜 비밀과 권한은 모델 밖의 서버 통제로 보호해야 한다.

레드팀 범위를 여섯 개 층으로 나눈다

층	대표 공격	확인할 통제
입력·대화	직접 프롬프트 인젝션, 역할 혼동, 인코딩 우회	입력 분류, 위험 작업 분리, 세션 경계
검색·메모리	문서 속 간접 지시, 다른 사용자의 데이터 검색	검색 전 ACL, 출처 표시, 데이터 격리
도구·에이전트	임의 명령, 과도한 인자, 연쇄 실행	서버 측 허용 목록, 최소 권한, 사람 승인
출력	HTML·Markdown 주입, 비밀 노출, 잘못된 자동 실행	스키마 검증, escaping, DLP, 후속 실행 분리
자원·경제성	무한 루프, 긴 컨텍스트, 반복 호출, 비용 폭증	단계·시간·토큰 한도, rate limit, 예산 경보
운영·대응	공격 재현 불가, 로그 누락, 모델 변경 후 회귀	추적 ID, 버전 기록, 테스트 자동화, kill switch

OWASP Top 10 for LLM Applications는 프롬프트 인젝션, 민감정보 노출, 과도한 대행 권한 같은 위험을 분류하는 출발점이 된다. NIST AI 600-1은 생성형 AI 위험을 조직의 측정·관리 과정에 연결할 때 참고할 수 있다. 목록을 그대로 체크하는 것보다 실제 제품 데이터 흐름과 권한에 매핑해야 한다.

테스트 케이스는 재현 가능해야 한다

“모델이 이상한 답을 했다”는 보고만으로는 수정 우선순위를 정하기 어렵다. 최소한 다음 필드를 남긴다.

필드	내용
케이스 ID	버전과 추세를 비교할 수 있는 고유 번호
전제조건	사용자 역할, 테넌트, 기능 플래그, 연결 도구
입력·콘텐츠	사용자 프롬프트뿐 아니라 검색 문서와 첨부파일
모델 구성	모델·시스템 프롬프트·검색기·도구 버전
기대 결과	거부, 축소 실행, 사람 승인, 안전한 출력 등
실제 결과	응답과 도구 호출, 부수 효과, 로그
영향	읽기 노출, 쓰기 실행, 비용, 고객 범위
재현성	반복 횟수 중 성공 횟수와 변동성
차단 위치	모델, 오케스트레이터, 권한 서비스, UI 중 어디서 막을지
잔여 위험	완화 후에도 남는 조건과 모니터링 계획

확률적 시스템이므로 한 번의 성공·실패만으로 판단하지 않는다. 온도, 모델 버전, 문맥 순서, 언어, 인코딩을 바꿔 반복하고 성공률을 기록한다. 중요한 공격은 자동 회귀 테스트로 전환해 모델이나 프롬프트 변경 때마다 실행한다.

출시 전에 반드시 시험할 공격 시나리오

직접·간접 프롬프트 인젝션

사용자 입력뿐 아니라 웹페이지, 이메일, PDF, 코드 주석, 이미지 OCR 결과에 숨은 지시를 넣는다. 검색된 콘텐츠가 “이전 지시를 무시하라”고 말할 때 모델이 이를 데이터로 취급하는지 확인한다. 완벽한 문장 필터를 기대하기보다 위험한 도구 호출이 별도 권한 검사를 거치는지를 본다.

테넌트와 역할 경계 우회

일반 사용자가 관리자 문서를 검색하거나, 다른 조직의 대화 메모리를 참조하거나, 공유 링크를 통해 비공개 데이터를 가져오는지 시험한다. ACL은 검색 결과를 모델에 넣기 전에 적용해야 한다. 모델이 결과를 보고 나중에 가리는 구조는 이미 데이터가 노출 경계를 넘은 것이다.

도구 인자 조작과 과도한 대행

메일 발송, 티켓 생성, 파일 삭제, 결제, 코드 실행 같은 도구에 예상하지 않은 수신자·경로·금액·명령을 넣는다. 도구 설명에 “안전하게 사용하라”고 적는 것만으로는 부족하다. 서버가 사용자 권한과 리소스 범위를 다시 검증하고, 고위험 쓰기 작업은 미리보기와 사람 승인을 요구해야 한다.

데이터 유출과 추론

명시적 비밀뿐 아니라 여러 답변을 조합해 민감 정보를 추론할 수 있는지 본다. 로그와 분석 시스템에 원문 프롬프트, 검색 결과, 액세스 토큰이 남는지도 확인한다. 테스트 데이터와 실제 고객 데이터를 섞지 않고, 레드팀 계정의 접근 범위를 명확히 제한한다.

자원 고갈과 비용 남용

매우 긴 문서, 반복 도구 호출, 순환 에이전트, 대량 동시 요청, 실패 후 재시도를 시험한다. 최대 단계 수, wall-clock 시간, 토큰, 도구별 호출 수, 사용자·테넌트별 비용 한도를 넘으면 중단되는지 검증한다.

출력 채널 공격

모델 출력이 HTML, Markdown, SQL, 쉘 명령, 템플릿, 이메일로 이어질 때 escaping과 스키마 검증을 시험한다. “모델이 생성했으니 신뢰한다”는 경로를 없애고 일반 사용자 입력과 같은 수준으로 검증해야 한다.

출시 게이트를 위험 등급으로 만든다

모든 발견을 0건으로 만들 때까지 출시를 미루는 방식은 현실적이지 않다. 대신 영향과 실행 가능성에 따라 게이트를 정한다.

출시 차단

다른 사용자 또는 테넌트의 민감 데이터에 접근 가능
사람 승인 없이 금전·삭제·권한 변경 같은 고위험 작업 실행
서버 비밀, 장기 토큰, 내부 시스템 자격증명 노출
공격을 탐지하거나 기능을 중지할 방법이 없음

제한 출시

낮은 성공률이지만 영향이 큰 공격이 남아 있음
완화책은 있으나 특정 언어·파일 형식에서 검증이 부족함
운영 로그와 대응 인력이 준비됐지만 자동 차단이 미완성

이 경우 대상 사용자, 데이터, 도구 권한, 호출 한도를 줄이고 종료 조건을 정한다.

잔여 위험 수용

영향이 제한되고 서버 측 통제로 피해 범위가 묶이며, 탐지와 복구가 가능할 때만 소유자와 만료일을 붙여 수용한다. “모델 특성상 어쩔 수 없음”은 수용 근거가 아니다.

운영에서 볼 탐지 신호

시스템 지침·비밀·내부 식별자를 요구하는 프롬프트 비율
검색 문서에서 명령형 패턴이나 비정상 인코딩이 발견된 횟수
사용자 권한과 맞지 않는 문서가 검색 후보에 포함된 사건
거부된 도구 호출과 인자 검증 실패, 사람 승인 취소율
평소와 다른 도구 호출 연쇄, 단계 수, 토큰·비용 급증
동일 사용자의 반복 우회 시도와 계정·IP·기기 상관관계
출력 DLP·스키마 검증 실패와 렌더링 차단 건수
모델·프롬프트·검색기 변경 뒤 회귀 테스트 실패율
kill switch 또는 읽기 전용 모드 전환 시간

로그에는 프롬프트 원문을 무조건 저장하지 않는다. 민감 정보를 최소화하고, 필요하면 해시·분류 결과·추적 ID를 남기며 원문 접근 권한과 보존 기간을 제한한다.

팀별 책임

제품팀은 허용·금지 사용 사례와 고객 영향 기준을 정의한다. AI 플랫폼팀은 모델, 검색, 도구, 평가 버전을 재현 가능하게 관리한다. 보안팀은 공격 시나리오와 차단 기준을 만들고, 데이터 소유자는 검색 권한과 보존 정책을 승인한다. 운영팀은 경보, 기능 비활성화, 고객 통지, 증거 보존 절차를 맡는다.

레드팀이 한 팀의 보고서로 끝나지 않게 발견 항목을 제품 백로그와 연결한다. 수정된 통제에는 자동 테스트와 운영 지표가 하나 이상 따라야 한다.

출시 전 체크리스트

프롬프트 인젝션 권한 경계는 도구와 검색의 서버 측 통제를 더 자세히 다루고, AI 데이터 유출 방지와 로깅은 관측 가능성과 데이터 최소화 기준을 보완한다. 수정 코드는 데이터 흐름 중심 보안 코드리뷰의 source-to-sink 방식으로 다시 검토하는 것이 좋다.

최종 판단

AI 레드팀의 결과물은 공격 프롬프트 모음이 아니라 제품의 안전 요구사항이어야 한다. 어떤 데이터가 모델에 들어가고, 어떤 권한이 도구에 전달되며, 실패했을 때 어디서 차단하고 어떻게 탐지할지를 설계에 반영해야 한다. 출시 직전 한 번의 점검보다 작은 공격 세트를 개발 과정에 반복 삽입하는 조직이 모델 변경과 새로운 사용 사례에도 더 안정적으로 대응할 수 있다.