AI 레드티밍은 공격자처럼 생각하며 AI 시스템을 일부러 속이고 망가뜨려 약점을 찾는 시험이다. 일반 테스트가 기능이 잘 작동하는지 확인한다면, 레드티밍은 속이는 입력과 악용 시나리오 앞에서 무엇이 무너지는지 살핀다.
지금 이 시험이 중요한 이유는 AI가 답변을 넘어 행동까지 하기 때문이다. 여러 시스템에 연결된 에이전트는 사람이 상황을 파악하기 전에 잘못되거나 악의적인 행동을 수천, 수백만 건의 상호작용으로 퍼뜨릴 수도 있다(p.12). KCBCA Signals 편집자 글은 성공 경로와 함께 거절·철회·격리 경로를 시험하고, 중요한 행동을 나중에 설명할 증거를 남기라고 권한다(p.6). 이 글에서는 공공 AI, 자금 거래를 승인하는 AI, 영향이 큰 배포, 시험용 에이전트라는 네 가지 상황에서 무엇을 확인할지 정리한다.
이 글은 KCBCA Signals Vol.1 Issue 1에 실린 기고 다섯 편(p.6·12·27·31·33)을 바탕으로 한다.
레드티밍은 일반 테스트와 무엇이 다를까?
레드팀은 공격자 역할로 시험하는 팀이고, 레드티밍은 그 활동을 뜻한다. 일반 테스트가 "설계대로 작동하는가?"를 묻는다면, AI 레드티밍은 "어떻게 속이면 무너지는가?"를 묻는다.
| 구분 | 일반 테스트 | AI 레드티밍 |
|---|---|---|
| 묻는 것 | 기능이 설계대로 작동하는가? | 어떻게 속이면 무너지는가? |
| 관점 | 개발자·사용자 | 공격자 |
| 입력 | 정상 입력, 예상된 오류 | 일부러 속이는 입력, 악용 시나리오 |
| 확인 범위 | 모델과 기능 | 모델이 틀렸을 때 주변 시스템 전체 (p.12) |
| 결과 | 통과·실패 | 재현 가능한 발견과 독립 검증 (p.27) |
국내에서도 참고할 가이드가 나왔다. 과학기술정보통신부와 한국인터넷진흥원(KISA)은 2026년 7월 'AI 보안 위협 대응 매뉴얼'과 'AI 보안 레드티밍 가이드'를 발간했다. 레드티밍 가이드는 국제표준안(ISO/IEC 42119-7)을 바탕으로 기획부터 결과 보고까지의 운영 과정과 체크리스트, 직무기술서를 담았다(보안뉴스, 2026.7.8).
공공 AI: 모델이 틀릴 때 주변 시스템은 버틸까?
KCBCA Signals에서 Paul Kim은 공공 AI의 실패 상황부터 시험하자고 제안한다. 레드팀 훈련, 시스템 장애 모의, 백업 절차 점검을 거쳐 AI가 불확실하거나 침해됐거나 틀렸을 때 무슨 일이 일어나는지 확인하라는 것이다(p.12).
이때 AI 레드티밍의 목표는 모델이 작동함을 보여주는 데 그치지 않는다. 모델이 작동하지 않을 때도 주변 시스템 전체가 작동하는지 확인해야 한다. 침해된 신원 확인 단계, 오염된 데이터 소스, 인증 취약점, 에이전트 수준의 사이버 공격도 그가 꼽은 시나리오다(p.12).
돈이 걸린 AI: 승인 권한을 주기 전에 속여 보기
실제 자금 거래를 승인할 에이전트라면 권한을 주기 전에 일부러 속이는 입력으로 시험해야 한다. 시험 중에 에이전트를 속이는 데 성공하면, 주변 통제가 금지된 행동을 실제로 막는지 드러난다. 정해 둔 한도를 넘는 반복 송금이 그 확인 대상이다(p.33).
운영팀은 이 과정에서 에이전트의 권한을 정지하고, 비활성화 뒤에도 남은 권한을 회수하는 연습을 할 수 있다(p.33). 한 회사의 시험만으로는 여러 회사가 함께 쓰는 서비스의 취약점을 놓칠 수 있다. Marc Krisjanous는 규제기관과 업계 단체가 공용 서비스 침해에 대한 공동 대응 훈련을 도울 수 있다고 본다(p.33).
배포 전: 약점을 없앴나, 시연만 막았나?
영향이 큰 배포라면 비공개로 진행하는 AI 보조 적대적 시험을 승인 절차에 넣자고 Anton Kaiser는 제안한다. AI 레드티밍으로 근본 원인을 다시 따지고, 다른 공격 경로와 수정 과정에서 새로 생긴 약점을 확인하라는 것이다. 발견 내용은 재현할 수 있어야 하고 독립 검증도 거쳐야 한다(p.27).
승인 전에는 이렇게 물어야 한다. "약점을 없앴나, 아니면 처음 시연만 막았나?" Google Project Zero는 패치가 기존 개념증명(PoC)만 막고 근본 원인은 해결하지 못한 사례를 기록했다(p.27).
시험용 AI 에이전트도 격리해야 한다
다음 큰 사고가 외부 공격자가 아닌 우리 쪽 AI 보안 시험 에이전트에서 시작된다면 어떨까? Anton Kaiser는 시험용 에이전트를 격리하고 외부 통신을 제한하며, 실제 서명 키를 시험 환경 밖에 두라고 말한다. 비공개로 진행 중인 취약점 수정 내용이 에이전트를 통해 밖으로 퍼지지 않도록 하기 위해서다(p.27).
거절·철회·중단 경로도 시험
KCBCA Signals에서 Ted Kim은 성공한 시연뿐 아니라 거절 경로도 시험하라고 말한다. 권한이 회수됐을 때, 파일이 바꿔치기됐을 때, 작업이 중간에 끊겼을 때 시스템이 어떻게 반응하는지 확인해야 한다. 연쇄적으로 이어진 행동을 멈추고 추적하며, 접근 권한을 회수하고 영향받은 작업 흐름을 격리하는 연습도 필요하다(p.31).
상황별 AI 레드티밍 체크표
| 상황 | 시험할 것 | 확인할 질문 |
|---|---|---|
| 공공 AI | 레드팀 훈련, 장애 모의, 백업 절차 | 모델이 틀려도 주변 시스템이 작동하는가? (p.12) |
| 돈이 걸린 AI | 일부러 속이는 입력, 권한 정지 연습 | 속아도 한도를 넘는 반복 송금이 막히는가? (p.33) |
| 영향이 큰 배포 | 비공개 AI 보조 적대적 시험 | 약점을 없앴나, 시연만 막았나? (p.27) |
| 시험용 에이전트 | 격리, 외부 통신 제한, 실제 서명 키 배제 | 시험 내용이 밖으로 퍼지지 않은가? (p.27) |
| 모든 AI | 거절·철회·중단 경로 | 권한을 거두면 멈추고 추적할 수 있는가? (p.31) |
자주 묻는 질문
Q1. 작은 팀도 AI 레드티밍을 할 수 있는가?
할 수 있다. 처음부터 모든 기능을 다룰 필요는 없다.
실제 자금 거래 승인처럼 결과가 큰 행동 하나를 골라 일부러 속이는 입력을 넣어 본다. 권한을 거뒀을 때 멈추는지도 함께 확인한다. 과기정통부·KISA 가이드의 체크리스트도 출발점이 될 수 있다.
Q2. 외부 업체에 맡기면 끝인가?
아니다.
시험 결과는 에이전트의 권한을 넓힐지 판단하는 근거가 되어야 한다. 경영진도 에이전트와 평소 도구를 믿을 수 없을 때 어떤 확인 장치가 여전히 작동하는지 설명할 수 있어야 한다(p.33). 남은 불확실성을 누가 받아들일지도 조직이 정해야 한다(p.27). 한 회사 안의 시험이 놓치는 공용 서비스 위험도 남는다(p.33).
Q3. 얼마나 자주 해야 하는가?
정해진 주기보다 변화가 생길 때가 기준이다. 실제 자금 거래 승인 권한을 주거나 에이전트의 권한을 넓히기 전(p.33), 영향이 큰 배포를 승인하기 전(p.27)에 시험한다. 비상 상황이 닥치기 전에 비공개 시험 경로를 마련하고 연습해 두라는 제안도 있다(p.27).
한눈에 정리
- AI 레드티밍은 AI 시스템을 일부러 속이고 망가뜨려 약점을 찾는 시험이다
- 성공 경로와 함께 거절·철회·격리 경로를 시험하고 증거를 남긴다 (p.6)
- 공공 AI는 모델이 틀릴 때, 돈이 걸린 AI는 속았을 때를 시험한다 (p.12·33)
- 배포 전에는 근본 원인을 확인하고, 시험용 에이전트는 격리한다 (p.27)
우리 AI가 가장 큰 일을 하는 순간 하나를 골라, 이번 주에 일부러 속여 본다. 원문은 KCBCA Signals에서 무료로 읽을 수 있다.
KCBCA Signals Vol.1 Issue 1 원문 읽기 (p.26–27)
참고: KCBCA Signals Vol.1 Issue 1 JJ Park(KCBCA GLOBAL 출판 총괄) p.6, Paul Kim(KCBCA GLOBAL 설립자·회장) p.12, Anton Kaiser(Corpay 사이버 보증 부문 부사장) p.27, Ted Kim(Shorti CEO) p.31, Marc Krisjanous(Zanarc 창업자·수석 컨설턴트) p.33 보안뉴스(2026.7.8) 과기정통부·KISA AI 보안 가이드 2종 발간 기사
