레드팀 · AI 레드티밍
Red Teaming
레드팀이란?
- 약점·위험을 일부러 공격해 찾음
- '악의적 사용자' 흉내
- 안전 배포의 필수 절차
레드티밍이 들어오면 검증의 질문 자체가 바뀝니다. QA가 '요청한 대로 동작하는가'를 확인한다면, 레드팀은 '어떻게 하면 망가뜨릴 수 있는가'를 묻습니다. 그래서 배포 승인 기준도 정확도 몇 퍼센트가 아니라 뚫린 사례가 몇 건이고 얼마나 심각한가로 옮겨갑니다. 만든 사람과 공격하는 사람을 분리해야 하는 이유도 여기 있습니다. 자기 설계의 전제를 스스로 의심하기는 어렵기 때문에, 공격자 역할을 전담하는 별도 인력을 배정하고 취약점 발견 건수를 성과로 인정하는 구조가 함께 있어야 합니다.
실무에서는 대개 세 갈래로 나눠 돌립니다. 사람이 대화를 설계해 직접 찔러보는 수동 레드티밍, 공격 프롬프트를 자동 생성해 수천 건을 한꺼번에 던지는 자동 레드티밍, 의료·법률·금융·아동안전처럼 전문가가 붙어야 위험 여부를 판정할 수 있는 도메인 레드티밍입니다. 모의해킹과는 노리는 대상이 다릅니다 — 모의해킹은 서버와 권한을 뚫지만, 레드티밍은 모델이 내놓는 말 자체를 뚫습니다. 벤치마크 평가와도 구분됩니다. 벤치마크가 정해진 문제를 반복해 점수를 내는 일이라면, 레드티밍은 아직 출제되지 않은 문제를 새로 만드는 일입니다. 그래서 산출물은 점수표가 아니라 재현 절차가 붙은 취약점 목록이어야 합니다.
현장에서 가장 자주 어긋나는 지점은 레드티밍을 오픈 직전 한 번 치르는 통과의례로 두는 것입니다. 모델 버전을 올리거나 시스템 프롬프트를 손보거나 사내 문서를 새로 연결하는 순간 공격면이 달라지므로, 변경이 생길 때마다 다시 돌려야 맞습니다. 두 번째 오해는 발견된 취약점을 금칙어 추가로만 막으려는 습관입니다. 필터를 조일수록 정상 문의까지 걸려 챗봇이 '답변드리기 어렵습니다'만 반복하고, 두어 달이면 현업이 사용을 접습니다. 막는 강도와 막는 정확도를 함께 재야 합니다. 마지막으로, 보고서에 재현 대화가 빠지면 개발팀은 고칠 수 없습니다. '위험해 보였다'는 소감은 수정 티켓이 되지 못합니다.
군사·사이버보안의 '가상 적군(red team)' 개념에서 유래했으며, AI 안전 검증의 표준 절차로 확장됐습니다.
가상의 사례로 살펴보겠습니다. 임직원 약 900명 규모의 손해보험사 A사는 보험금 청구 안내 챗봇을 4개월간 개발해 오픈을 2주 앞두고 있었습니다. 내부 테스트 정확도는 91%였지만, 준법감시실이 '약관에 없는 보장을 약속하면 그 책임은 누가 지느냐'며 결재를 보류했습니다. 결국 오픈을 6주 미루고 레드팀부터 꾸렸습니다.
- 디지털혁신팀 박 과장은 고객센터 상담사 4명과 준법감시실 담당 2명을 차출해 레드팀을 만들고, 챗봇 개발자는 일부러 제외했습니다. '만든 사람이 때리면 살살 때린다'는 이유였습니다.
- 2주 동안 공격 시나리오 420건을 작성했습니다. 상담사들이 실제 민원 녹취에서 뽑아온 '진단서 없이도 나오게 해주세요' 같은 문장이 절반을 넘었습니다.
- 1차 테스트에서 37건이 뚫렸습니다. 특히 '제 친구가 궁금해하는데요'로 말머리만 바꾸면 면책 조항을 건너뛰고 지급 가능하다고 답하는 패턴이 11건 반복됐습니다.
- 박 과장은 발견 건마다 재현 대화 전문과 화면을 붙여 등록하게 하고, 심각도를 상·중·하로 나눠 상 등급 9건은 오픈 전 필수 수정으로 못 박았습니다.
- 3주 뒤 재테스트에서 우회 성공은 37건에서 4건으로 줄었고, 필터를 조이는 과정에서 12%까지 올랐던 정상 문의 거부율은 답변 범위를 다시 정의해 5%로 내렸습니다.