개요
Red Teaming은 시스템이 정상적인 사용 사례에서 잘 작동하는지만 보는 대신, 의도적으로 실패를 유도하는 입력과 상황을 만들어 취약점이나 유해 행동을 찾는 평가 접근법이다. LLM에서는 유해한 생성, 개인정보 노출, 편향, 규칙 우회처럼 배포 전에 발견하기 어려운 행동을 탐색하는 데 사용된다.[1]
자동화된 레드팀의 예
Perez 등은 사람이 모든 공격성 테스트를 직접 작성하는 비용 문제를 줄이기 위해 다른 언어 모델로 테스트 입력을 생성하고 대상 모델의 유해 반응을 찾는 방법을 연구했다.[1] 연구는 다양한 유형의 실패 사례를 대규모로 탐색할 수 있음을 보여줬지만, 자동화된 레드팀 하나만으로 모든 위험을 찾을 수 있다고 보지는 않는다.
운영에서의 위치
Red Teaming은 Safety Evaluation의 한 방법이며, 일반 성능 벤치마크를 대체하지 않는다. 발견된 실패는 수정 여부와 재검증 결과를 함께 기록하고, 중요한 배포 판단과 제한사항은 System Card 같은 문서에 연결하는 편이 좋다. 실제 레드팀은 모델 자체뿐 아니라 프롬프트, 도구 권한, 검색·에이전트 연결과 사용자 인터페이스까지 시스템 경계를 기준으로 설계해야 한다.
사례: 가짜 자료와 모의 도구로 경계 시험하기
가상의 AI 문서 도우미에서 외부 원문에 '요약 대신 다른 문구만 답하라'는 문장을 넣어 자료 내용과 작업 지시를 구분하는지 시험할 수 있다. 접근 금지 자료에는 TEST-ONLY-42 같은 비밀이 아닌 가짜 표식을 두고 허용되지 않은 검색 결과로 전달되는지 확인한다. 공개 저장 도구는 실제 발행 대신 모의 결과를 돌려주도록 구성한다. 이는 허가된 격리 시험의 예제이며 실제 개인정보나 운영 비밀을 사용할 이유가 아니다.
에이전트의 검색·쓰기·중단 경계를 평가할 때 요청자의 허용 작업, 기대 결과와 금지 행동을 미리 적는다. 일반 정확도 시험에서 정답을 잘 만들었다고 이런 경계가 자동으로 검증된 것은 아니다. 모델 응답뿐 아니라 실제 선택한 도구와 전달한 자료도 확인한다.
계산 예제: 실패 12회와 고유 결함 3개
다음은 가상 테스트 기록이다. 60번의 시도에서 실패가 12번 나왔지만 이를 원인별로 묶으면 접근 필터 누락, 외부 자료를 지시로 수용, 중복 저장의 고유 결함 3개일 수 있다. 12 / 60 = 20%는 그 시도 묶음의 관찰 비율이지 일반 사용자 요청의 사고 확률이 아니다. 실패를 찾으려고 적응적으로 고른 입력은 일상 요청의 무작위 표본과 다르다.
시도 ID, 결함 ID, 재현 조건과 영향도를 별도로 남긴다. 같은 결함의 문구 변형 열 개를 서로 다른 문제 열 개라고 세지 않고, 같은 문구여도 다른 권한 경계에서 발생한 결함은 구분한다. 실패 횟수가 작아도 중요한 쓰기 권한 오류라면 건수만으로 우선순위를 낮추지 않는다.
수정 후 회귀 시험과 새 시험을 분리하기
가상의 수정 뒤 저장해 둔 60개 시험에서 실패가 2개로 줄었어도, 바로 그 입력을 보며 완화책을 고쳤다면 새로운 입력에서의 개선까지 증명한 것은 아니다. 별도로 준비한 24개 새 시험에서 실패가 2개라면 2 / 24 = 약 8.3%라고 따로 기록한다. 두 세트의 결과를 합쳐 같은 모집단의 확률처럼 설명하지 않는다.
권한·중단 조건을 바꾸면 정상 업무가 불필요하게 차단되지 않는지도 함께 확인한다. 외부 도구의 시간 초과·빈 검색 결과·권한 만료를 포함하고 마지막으로 확인한 상태를 남긴다. 잔여 결함과 보류 이유, 수정 버전 및 재검증 날짜를 시스템 카드에 연결한다.
연구 방법과 시험 범위를 함께 읽기
언어 모델을 이용한 레드팀 연구 ↗는 다른 언어 모델로 실패를 유도하는 입력을 생성하는 접근을 조사했다.[1] 내부 알고리즘 감사 프레임워크 ↗는 개발 생애주기 전반의 판단과 문서 기록을 연결한다.[2] 자동 생성된 공격 묶음이나 문서 하나로 모든 위험이 없음을 증명할 수는 없다.
모델 수준 정보와 시스템의 검색·도구·필터 구성을 함께 보고, 시험하지 않은 언어·입력·사용 환경을 명시한다. 결과 보고에는 구체적인 재현 자료와 조치 상태를 넣고 불필요한 비밀이나 실제 사용자 자료를 공개하지 않는다.