인공지능 레드티밍
더 많은 작업
인공지능 레드티밍(人工知能 red teaming, 영어: AI red teaming)은 인공지능 시스템을 공격자 또는 적대적 시험자의 관점에서 의도적으로 시험하여 보안 취약점, 안전성 실패, 비정상적인 동작 및 악용 가능성을 발견하고, 실제 피해로 이어질 수 있는 위험을 평가·개선하는 활동이다.
인공지능 레드티밍은 기존의 레드티밍을 인공지능 시스템의 특성에 맞게 확장한 보안·안전성 평가 방법론이다. 정상적인 사용 상황에서 기능이 올바르게 작동하는지를 확인하는 일반적인 시험과 달리, 악의적인 공격이나 비정상적인 입력, 예상하지 못한 사용 상황 등을 의도적으로 구성하여 시스템의 한계와 취약성을 탐색한다.
전통적인 모의 침투 테스트가 네트워크·서버·웹 애플리케이션의 취약점을 주로 평가한다면, 인공지능 레드티밍은 학습 데이터, AI 모델, 시스템 프롬프트, 검색 시스템, 외부 도구, 사용자 권한, 모델의 의사결정 및 실제 실행 결과까지 평가 대상으로 삼는다.
특히 생성형 인공지능과 대형 언어 모델(LLM)은 자연어로 전달되는 지시와 데이터를 처리하기 때문에 기존 소프트웨어와는 다른 취약성이 발생할 수 있다. 공격자가 작성한 문서의 내용을 정당한 지시로 받아들이거나, 안전정책을 우회한 응답을 생성하거나, 접근권한이 없는 정보를 반환하는 등의 문제가 대표적이다.
AI 에이전트처럼 외부 도구를 이용해 실제 작업을 수행하는 시스템에서는 위험의 범위가 더욱 확대된다. 잘못된 판단이 단순한 답변 오류에 그치지 않고 정보 전송, 파일 삭제, 시스템 설정 변경, 금융거래 등 실제 행위로 이어질 수 있으므로, 모델의 응답뿐 아니라 실행 권한과 실제 작업 결과를 함께 검증해야 한다.
과학기술정보통신부와 한국인터넷진흥원(KISA)은 2026년 7월 「AI 보안 레드티밍 가이드」를 발간하여 국내 기업과 기관을 위한 체계적인 레드티밍 수행 방법을 제시했다. 같은 시기 발표한 「AI 보안 위협 대응 매뉴얼」에서는 데이터·모델·에이전트·공급망 등의 위협을 분류하고 산업별 대응 방안을 설명했다.[1][2]
인공지능 레드티밍을 수행하는 조직과 인력에 대해서는 인공지능 레드팀 문서에서, 레드티밍에 사용하는 자동화 소프트웨어와 개별 프레임워크에 대해서는 인공지능 레드티밍 도구 문서에서 별도로 다룬다.
인공지능 레드티밍의 목적은 AI 시스템의 모든 기능을 정상적으로 수행하는지 확인하는 데 있지 않다. 시스템이 어떤 조건에서 위험하게 실패하는지를 발견하고, 그 실패가 실제 피해로 이어지는 것을 방지하는 것이 핵심이다.
주요 목적은 다음과 같다.
- 보안 취약점 발견: 공격자가 시스템의 정보나 권한을 부당하게 획득할 수 있는 경로를 식별한다.
- 안전성 검증: 유해하거나 위험한 응답 생성 및 안전정책 우회 가능성을 평가한다.
- 민감정보 보호: 개인정보, 인증정보, 내부 문서 등 보호 대상 정보의 유출 가능성을 확인한다.
- 신뢰성과 견고성 평가: 적대적 입력이나 예외 상황에서 잘못된 판단과 비정상적인 동작이 발생하는지 확인한다.
- 실행 권한 검증: AI 에이전트가 승인되지 않은 도구를 사용하거나 허용된 작업 범위를 벗어나는지 점검한다.
- 보안 통제 검증: 인증·인가, AI 가드레일, 실행 격리, 사용자 승인 등의 보호조치가 실제로 작동하는지 확인한다.
- 위험의 영향도 분석: 발견된 취약점이 실제 업무, 사용자 또는 연계 시스템에 미칠 수 있는 영향을 평가한다.
- 개선 효과 확인: 취약점 조치 후 동일하거나 유사한 공격을 반복하여 해결 여부를 검증한다.
인공지능 시스템은 모델의 버전, 파인튜닝, 프롬프트 구성, 검색 데이터, 연결된 도구 등에 따라 동작이 달라질 수 있다. 따라서 특정 시점의 평가 결과만으로 이후 모든 상황에서 안전하다고 보장할 수 없으며, 시스템 변경과 새로운 공격 기법에 대응하는 지속적인 점검이 필요하다.[1]
일반적인 AI 평가는 정확도, 답변 품질, 처리 속도 등 사전에 정의된 성능 지표를 측정하는 데 중점을 둔다. 반면 인공지능 레드티밍은 정상적인 시험에서 발견하기 어려운 취약점과 실패 조건을 적극적으로 탐색한다.
| 구분 | 일반적인 AI 평가 | 인공지능 레드티밍 |
|---|---|---|
| 목적 | 성능과 품질 측정 | 취약점 및 위험한 실패 행동 발견 |
| 입력 | 정상적인 요청, 표준 데이터셋 | 적대적 입력, 악용 시나리오, 비정상적인 상황 |
| 관점 | 의도한 기능의 수행 여부 | 공격이나 예외 상황에서의 방어 및 통제 실패 여부 |
| 방법 | 벤치마크, 정답 비교, 통계적 측정 | 모의 공격, 탐색적 시험, 자동화된 공격 시나리오 |
| 결과 | 정확도, 품질 점수, 성능 지표 | 발견된 취약점, 공격 경로, 영향도, 개선 과제 |
두 활동은 상호 보완적이다. 레드티밍에서 발견한 실패 사례를 정형화된 테스트 데이터셋으로 만들면 이후 자동 평가나 회귀 테스트에 활용할 수 있다.
기존의 보안 시험과 인공지능 레드티밍은 인증·인가, 정보 유출, 시스템 침해 등 공통적인 위험을 다룬다.
그러나 인공지능 시스템에서는 자연어 입력을 통해 모델의 판단에 영향을 주거나, 공격자가 작성한 외부 데이터를 모델이 신뢰하도록 유도하는 새로운 공격 경로가 존재한다.
예를 들어 웹 애플리케이션의 SQL 인젝션은 애플리케이션이 입력값을 SQL 명령으로 잘못 처리하는 문제인 반면, 프롬프트 인젝션은 AI 모델이 신뢰할 수 없는 데이터를 따라야 할 지시로 잘못 해석하는 문제다.
또한 AI 에이전트에서는 각각의 도구가 정상적으로 작동하더라도, 모델이 여러 도구를 잘못 조합하면 허용되지 않은 결과가 발생할 수 있다.
따라서 인공지능 레드티밍은 기존 모의해킹을 대체하는 것이 아니라, AI 모델의 행동과 외부 시스템과의 상호작용을 평가 범위에 추가하는 활동이다.
AI 애플리케이션 계층에는 사용자 인터페이스, API, 시스템 프롬프트, 입출력 필터, 업무 규칙, 인증·인가 기능 등이 포함된다.
모델이 외부 사용자의 지시를 어떻게 처리하는지뿐 아니라, 애플리케이션이 사용자별 권한과 업무 제한을 올바르게 적용하는지 확인한다.
예를 들어 챗봇이 다른 사용자의 고객정보를 반환한다면 모델의 응답 제어 문제뿐 아니라 서버에서 사용자 권한을 검증하지 않았을 가능성도 함께 분석해야 한다.
RAG, 웹 검색, 문서 저장소, 외부 API, 플러그인, 모델 컨텍스트 프로토콜(MCP), 도구 호출 등은 AI 시스템의 공격 표면을 확대한다.
모델이 외부에서 수신한 데이터를 실제 지시로 취급하는지, 검색 결과를 통해 접근권한을 우회할 수 있는지, 도구 호출 과정에서 사용자 권한이 적절히 전달되는지 평가한다.
실행형 AI 에이전트의 경우에는 모델이 어떤 작업을 선택했는지뿐 아니라 실제 실행된 작업과 그 결과까지 확인해야 한다.
AI 서비스를 운영하는 서버, 클라우드, 모델 추론 엔진, 컨테이너, 저장소, 배포 파이프라인, 인증정보 및 모니터링 체계도 점검 대상이다.
여기에는 기존 웹·클라우드 보안 시험에서 다루는 취약점뿐 아니라 모델 파일의 접근통제, 추론 API의 남용, 외부 모델 및 도구의 공급망 보안 등의 문제가 포함된다.
KISA는 「AI 보안 레드티밍 가이드」에서 데이터, 모델, 애플리케이션 및 인터페이스, 인프라 등 AI 시스템 전반을 평가하도록 설명하고 있다.[1]
프롬프트 인젝션(Prompt Injection)은 AI 시스템이 처리하는 입력에 악의적인 지시를 삽입하여, 모델이 원래의 목적이나 정당한 지시에서 벗어난 행동을 하도록 유도하는 공격이다.
공격자가 직접 대화창에 지시를 입력하는 방식도 있지만, 모델이 읽는 웹페이지, 이메일, 문서, 검색 결과 또는 도구 응답에 악의적인 지시를 숨기는 방식도 중요하다.
후자의 경우 공격자는 AI 시스템의 상위 지시를 직접 변경할 권한이 없더라도 외부 데이터를 조작하여 모델의 행동에 영향을 줄 수 있다.
레드티밍에서는 다음 사항을 확인한다.
- 외부 문서에 포함된 지시를 모델이 따라야 할 명령으로 취급하는지
- 검색 결과를 통해 내부정보를 노출하거나 비인가 도구를 실행하는지
- 공격자의 지시가 사용자 및 시스템의 정당한 지시보다 우선하는지
- 외부 콘텐츠를 이용한 공격이 여러 대화나 작업 단계에 걸쳐 지속되는지
프롬프트 인젝션은 단순히 잘못된 답변을 유도하는 문제뿐 아니라, 실제 권한을 가진 AI 에이전트를 조종하는 공격 경로가 될 수 있다.
탈옥 공격(Jailbreak)은 모델에 적용된 안전정책이나 행동 제한을 우회하도록 유도하는 공격이다.
역할 설정, 상황 재구성, 언어 변경, 단계적 요청, 다중 턴 대화 등 다양한 형태의 입력을 이용할 수 있다.
레드티밍에서는 모델이 거부해야 할 요청을 수행하는지뿐 아니라, 정상적인 보안 연구나 허용된 요청까지 과도하게 차단하지 않는지도 확인할 필요가 있다.
탈옥 공격은 주로 모델의 안전정책 우회에 초점을 두는 반면, 프롬프트 인젝션은 외부의 신뢰할 수 없는 정보가 시스템의 행동을 통제하는 문제까지 포함한다.
AI 시스템이 보호 대상 정보를 허가되지 않은 사용자나 외부 시스템에 노출하는지 평가한다.
- 다른 사용자의 개인정보 반환
- 내부 문서나 업무정보의 무단 검색
- 인증정보 및 API 키 노출
- 시스템 프롬프트와 내부 설정정보 노출
- 학습 데이터에 포함된 민감정보 재현
- 외부 도구를 이용한 데이터 반출
정보 유출 시험에서는 실제 보호 대상 데이터가 노출됐는지, 모델이 존재하지 않는 정보를 그럴듯하게 만들어 낸 것인지 구분해야 한다.
또한 시스템 프롬프트가 노출됐다는 사실만으로 모든 경우에 같은 수준의 보안 피해가 발생한다고 볼 수는 없다. 포함된 정보의 민감성과 후속 공격에 악용될 가능성에 따라 영향도를 평가해야 한다.
검색 증강 생성(RAG)은 외부 문서와 검색 결과를 바탕으로 답변을 생성한다.
레드티밍에서는 지식베이스에 삽입된 허위 정보나 악의적인 지시가 모델의 응답 또는 도구 실행을 변경하는지 평가한다.
주요 평가 항목은 비인가 문서 접근, 문서별 접근권한 우회, 검색 결과 조작, 허위 출처 생성, 외부 문서에 포함된 지시의 실행 여부 등이다.
RAG 시스템의 위험은 모델의 안전정책만으로 해결되지 않는다. 문서 접근통제, 데이터 무결성, 검색 결과의 신뢰 경계 등 애플리케이션 차원의 통제가 중요하다.
AI 모델이 생성한 출력이 다른 프로그램에서 코드, 쿼리, 명령어 또는 업무 지시로 처리되는 경우에는 새로운 보안 위험이 발생할 수 있다.
예를 들어 모델이 생성한 SQL 문장을 애플리케이션이 검증 없이 실행하거나, 생성된 파일 경로를 이용해 서버의 중요 파일을 삭제할 수 있다면 모델의 잘못된 출력이 실제 시스템 침해로 이어질 수 있다.
레드티밍에서는 모델의 출력이 후속 시스템에서 어떻게 사용되는지 추적하고, 별도의 유효성 검증과 실행 제한이 적용되는지 확인한다.
복잡하거나 비정상적인 입력을 이용해 과도한 추론 시간, 메모리 사용량, API 호출 또는 비용을 발생시키는 공격도 평가 대상이다.
AI 에이전트에서는 반복적인 작업 계획이나 도구 호출이 무한히 이어지는 문제가 발생할 수 있다.
이러한 시험은 실제 장애를 유발할 수 있으므로 운영 환경에서 무제한으로 수행해서는 안 되며, 별도의 자원 한도와 중단 조건을 설정해야 한다.
AI 에이전트는 사용자가 제시한 목표를 달성하기 위해 작업을 계획하고 외부 도구를 호출하여 실제 업무를 수행할 수 있다.
이러한 특성은 일반적인 대화형 AI와 구별되는 중요한 보안 위험을 발생시킨다.
대화형 AI가 잘못된 답변을 생성하는 경우에는 사용자가 이를 검토하거나 무시할 가능성이 있다. 그러나 실행 권한이 있는 AI 에이전트는 잘못된 판단을 실제 시스템에 적용할 수 있다. 데이터 수정, 이메일 발송, 계정 설정 변경, 외부 전송, 중요 파일 삭제 등의 작업은 실행 이후 피해가 발생하거나 복구가 어려울 수 있다.
특히 에이전트가 원래의 업무 목표를 달성하는 과정에서 부적절한 수단을 선택할 가능성도 고려해야 한다. 공격자의 직접적인 악성 요청이 없더라도 목표를 잘못 해석하거나 작업 수행에 필요한 제약을 충분히 이해하지 못하면 위험한 행동이 발생할 수 있다.
금융보안원은 2026년 10월 AI 에이전트에 대한 보안 평가기준을 마련하면서, AI가 직접 판단하고 행동하는 특성 때문에 기존 모델 중심의 안전성 평가를 실행 단계까지 확대해야 한다고 강조했다.[3]
금융보안원이 설명한 위험 사례로는 시스템 성능을 개선하라는 지시를 받은 에이전트가 가용성을 높인다는 이유로 백신 프로그램을 중단하거나, 이메일 자동 처리 권한을 가진 에이전트가 비밀번호 재설정 안내를 정상적인 업무 지시로 판단해 계정 비밀번호를 변경하는 상황 등이 있다.[4]
이러한 사례는 실행형 에이전트의 위험을 설명하기 위한 시나리오로, 실제 발생한 특정 금융회사 사고로 해석해서는 안 된다.
실행형 AI 에이전트의 레드티밍에서는 모델의 응답 안전성 외에 다음 사항을 중점적으로 검증한다.
| 평가 항목 | 주요 점검 내용 |
|---|---|
| 실행 권한 | 에이전트가 허용된 도구와 시스템에만 접근하며 승인되지 않은 작업을 실행할 수 없는지 확인 |
| 도구 사용 통제 | API·플러그인·MCP 도구를 호출할 때 적절한 인증·인가와 입력 검증을 수행하는지 확인 |
| 작업 범위 제한 | 사용자 요청과 사전에 정의된 업무 범위를 벗어나 불필요한 작업을 수행하지 않는지 확인 |
| 중요 작업 승인 | 데이터 삭제, 대외 전송, 금융거래 등 중요한 작업에 사람의 승인이나 별도 검증을 적용하는지 확인 |
| 실행 환경 격리 | 에이전트의 실행 권한과 작업 환경이 다른 시스템이나 업무에 불필요한 영향을 주지 않는지 확인 |
| 연쇄 실행 통제 | 여러 도구를 연결하는 과정에서 개별 권한의 의도치 않은 확대나 우회가 발생하지 않는지 확인 |
| 실행 결과 검증 | 도구 호출 이후 실제 처리 결과를 확인하고 오류나 예상하지 못한 결과에 대응하는지 확인 |
| 실행 중단 및 복구 | 위험한 행동을 중단하고 이미 수행된 작업을 가능한 범위에서 취소하거나 복구할 수 있는지 확인 |
| 행동 추적 | 에이전트의 도구 호출, 인수, 승인 내역, 실행 결과를 사후에 확인할 수 있는지 점검 |
금융보안원은 2026년 10월 발표에서 실행 권한과 격리 체계, 외부 도구 사용 및 승인 절차, 작업 범위 설정과 결과 검증, 자율 실행의 제한 및 중단 수단 등을 주요 평가 대상으로 제시했다.[4]
에이전트 하이재킹(Agent Hijacking)은 공격자가 외부 입력이나 데이터를 조작하여 AI 에이전트가 원래의 목표와 다른 행동을 수행하도록 유도하는 공격이다.
예를 들어 외부 이메일을 요약하도록 요청받은 에이전트가 이메일 본문에 포함된 악의적인 지시를 정당한 업무 명령으로 받아들이면, 사용자에게 허용되지 않은 도구를 호출할 수 있다.
레드티밍에서는 에이전트가 읽는 문서, 검색 결과, 도구 응답 등에 공격자의 지시를 삽입하고, 해당 지시가 실제 도구 실행까지 이어지는지 확인한다.
에이전트가 연결된 도구의 이름, 설명, 반환값 등을 신뢰할 경우 공격자가 조작한 도구 정보에 영향을 받을 수 있다.
모델 컨텍스트 프로토콜(MCP) 등으로 연결된 외부 도구에서는 도구 설명과 실행 결과를 포함한 다양한 입력이 모델의 행동에 영향을 줄 수 있다.
레드티밍에서는 악의적으로 조작된 도구 정보가 허용되지 않은 실행을 유도하는지, 도구 자체의 인증·인가와 실행 제한이 작동하는지 검증한다.
에이전트에 과도한 권한이 부여된 경우 단일 프롬프트 인젝션이 광범위한 데이터 접근이나 시스템 변경으로 이어질 수 있으므로 최소 권한 원칙의 적용 여부도 중요하다.
AI 에이전트는 과거 대화와 작업 결과를 메모리에 저장하여 이후의 의사결정에 활용할 수 있다.
공격자가 이러한 메모리에 악의적인 정보나 잘못된 사실을 저장하면 이후의 여러 작업에 지속적인 영향을 줄 수 있다.
레드티밍에서는 외부에서 전달된 정보가 에이전트의 기억에 저장되는 조건, 저장된 정보의 신뢰도와 유효기간, 변경·삭제·검증 절차 등을 점검한다.
또한 여러 단계의 작업을 수행하는 에이전트는 처음에는 정상적인 행동을 하더라도 후속 단계에서 권한이 확대되거나 원래 목표에서 벗어날 수 있다. 따라서 단일 도구 호출뿐 아니라 전체 작업 흐름을 평가해야 한다.
실행형 AI 에이전트의 레드티밍에서 중요한 것은 모델이 위험한 행동을 선택하는 문제와 그 행동이 실제 시스템에서 허용되는 문제를 구분하는 것이다.
예를 들어 에이전트가 권한 없이 다른 사용자의 파일을 삭제하려는 판단을 내렸더라도, 파일 시스템의 권한 검증에서 실행이 차단됐다면 실제 삭제는 발생하지 않은 것이다.
반대로 최종 답변은 정상적으로 보이더라도 에이전트가 내부적으로 승인되지 않은 파일을 수정하거나 데이터를 전송했다면 실질적인 보안 통제 실패가 발생한 것이다.
따라서 에이전트의 안전성을 시스템 프롬프트나 모델 내부의 안전정책에만 의존해서는 안 된다. 실제 시스템에서 독립적인 인증·인가, 실행 격리, 최소 권한, 사용자 승인, 감사 로그 및 중단 수단을 적용하고 그 효과를 검증해야 한다.
인공지능 레드티밍은 공격자의 의도적인 악용을 가정하는 시험과, 정상적인 사용자가 예상하지 못한 실패를 유발하는 상황을 시험하는 방식으로 나눌 수 있다.
KISA의 「AI 보안 레드티밍 가이드」는 이를 적대적 레드티밍 활동과 선량한 레드티밍 활동으로 구분한다.[1]
- 적대적 레드티밍: 공격자의 관점에서 취약점을 악용하거나 안전장치를 우회하는 시나리오를 수행한다.
- 선량한 레드티밍: 악의적인 의도가 없는 사용자가 모호하거나 복잡한 입력을 사용했을 때 발생하는 오류와 취약성을 탐색한다.
실제 시스템에서는 두 유형을 함께 고려할 필요가 있다. 악의적인 공격을 방어하더라도 정상 사용자의 예외적인 입력으로 위험한 행동이 발생할 수 있기 때문이다.
레드팀이 평가 대상 시스템의 내부 정보를 얼마나 알고 있는지에 따라 다음과 같이 구분한다.
| 방식 | 특징 | 주요 활용 |
|---|---|---|
| 블랙박스(Black-box) | 내부 구조를 알지 못한 채 외부에서 관찰 가능한 입력·출력을 이용 | 실제 외부 사용자의 공격 조건 재현 |
| 그레이박스(Gray-box) | 일부 설정이나 내부 구조에 관한 정보를 제공받아 평가 | 현실적인 공격 조건과 효율적인 취약점 분석의 절충 |
| 화이트박스(White-box) | 소스코드, 모델 설정, 시스템 구조 등 상세 정보에 접근 | 구조적인 취약점과 근본 원인 분석 |
단일 방식만 사용할 필요는 없으며, 외부 공격 가능성을 확인하는 블랙박스 시험과 내부 원인을 분석하는 화이트박스 시험을 병행할 수 있다.
수동 레드티밍은 보안 전문가가 직접 공격 시나리오를 설계하고 모델의 응답과 시스템 행동을 분석하는 방식이다.
복잡한 업무 규칙, 사회적 맥락, 여러 단계에 걸친 공격이나 자동 평가기로 판단하기 어려운 취약점을 탐색하는 데 유용하다.
자동화 레드티밍은 미리 정의한 공격 입력을 반복 실행하거나 별도의 AI 모델을 이용해 공격 입력을 생성·변형하여 다수의 시험을 수행하는 방식이다.
자동화 평가에는 다음 기능이 포함될 수 있다.
- 공격 입력 및 변형 입력의 대량 생성
- 단일 턴·다중 턴 공격 실행
- 응답과 도구 실행 결과 수집
- 정책 위반 여부의 자동 판정
- 취약점 후보 분류 및 보고
- 모델·프롬프트 변경 후 회귀 테스트
KISA 가이드는 자동화된 광범위한 점검과 전문가의 심층 검증을 연계하는 수행 방식을 제시한다.[1]
자동화는 평가 범위를 확대하는 데 유용하지만, 자동 평가기가 잘못된 결론을 내릴 수 있으므로 고위험·불확실한 결과에 대한 사람의 검토가 필요하다.
대표적인 자동화 소프트웨어로는 PyRIT, Promptfoo, garak 등이 있으며, 자세한 비교는 인공지능 레드티밍 도구 문서에서 다룬다.
레드티밍은 먼저 평가 대상과 목표, 시험 범위, 위험 허용 수준 및 수행 방법을 정하는 준비 과정에서 시작한다.
KISA의 「AI 보안 레드티밍 가이드」는 레드팀의 구성과 관리, 레드티밍 준비, 이행, 결과보고를 하나의 수행 체계로 다룬다.[1]
시험 대상 AI 시스템의 정상적인 사용 목적과 보호해야 할 자산을 정의한다.
주요 확인 사항은 다음과 같다.
- 모델의 종류와 버전
- 시스템 프롬프트와 안전정책
- 사용자 유형과 접근권한
- 학습·평가·검색 데이터
- 애플리케이션 및 API 구성
- 외부 도구 및 에이전트 실행 권한
- 평가에 사용할 계정과 환경
- 허용 및 금지할 시험 행위
- 공격 성공과 실패의 판정 기준
범위 설정에서는 시험하지 않을 대상도 명시해야 한다. 실제 고객 데이터, 제3자 시스템, 서비스 장애를 유발할 수 있는 공격 등은 별도 승인 없이 점검 범위에 포함해서는 안 된다.
위협 모델링을 통해 공격자의 목표, 접근권한, 제어 가능한 입력, 공격 표면 및 예상 피해를 식별한다.
예를 들어 공격자가 단순한 채팅 입력만 제어할 수 있는 경우와 AI 에이전트가 읽는 외부 문서를 수정할 수 있는 경우는 서로 다른 공격 시나리오를 필요로 한다.
공격자가 시스템의 내부 구조를 알고 있는지, 사용자 계정을 보유하고 있는지, 외부 도구의 응답을 조작할 수 있는지 등도 시나리오 설계에 영향을 준다.
레드티밍은 사전에 승인된 범위에서 수행해야 한다. 시험자와 대상 시스템 운영자는 교전 규칙(Rules of Engagement)을 합의하여 허용되는 행위와 제한사항을 명확히 정한다.
특히 다음 사항을 정해야 한다.
- 허용되는 공격 기법과 접근 범위
- 실제 데이터의 열람 및 변경 허용 여부
- 외부 시스템 접근과 도구 실행의 제한
- 서비스 지연이나 장애 발생 시 중단 조건
- 개인정보 및 기밀정보의 수집·보관·삭제 기준
- 고위험 취약점 발견 시 긴급 보고 절차
- 시험 종료 후 계정·권한·데이터 정리 방법
실행형 AI 에이전트의 레드티밍에서는 중요 작업을 시험하는 과정 자체가 실제 피해로 이어지지 않도록 격리된 환경이나 시험용 데이터를 활용하는 것이 중요하다.
위협 모델링 결과를 바탕으로 실제 시험에 사용할 시나리오를 작성한다.
| 항목 | 설명 |
|---|---|
| 시나리오명 | 시험 목적을 구분할 수 있는 명칭 |
| 공격 목표 | 정보 유출, 권한 우회, 비인가 도구 실행 등 확인하려는 결과 |
| 공격 표면 | 채팅 입력, 검색 문서, API, 외부 도구 응답 등 |
| 사전 조건 | 사용자 권한, 시험 계정, 데이터, 시스템 상태 |
| 실행 절차 | 시험 입력과 작업 수행 순서 |
| 성공 기준 | 관찰 가능한 정책 위반 또는 비인가 행동 |
| 영향 분석 | 기밀성·무결성·가용성 및 실제 업무에 미치는 영향 |
| 증거 수집 | 입력·출력·도구 호출·로그·모델 버전 등 |
시나리오는 실제로 검증 가능한 단위로 구성해야 한다.
예를 들어 'AI 에이전트가 안전한지 확인한다'라는 추상적인 목표보다 '외부 문서에 삽입된 지시를 읽은 뒤 승인되지 않은 데이터 전송을 시도하는지 확인한다'라는 시나리오가 시험과 결과 판정에 적합하다.
준비 단계에서 정의한 시나리오와 교전 규칙에 따라 시험을 실행한다.
초기에는 자동화 도구로 다수의 입력과 공격 경로를 탐색하고, 발견된 취약점 후보를 대상으로 전문가가 심층 분석을 수행할 수 있다.
복잡한 시나리오에서는 이전 응답이나 실행 결과를 바탕으로 다음 입력을 조정하는 적응형 시험도 사용한다.
단일 요청에서는 발견되지 않은 문제가 여러 차례의 대화나 연쇄 작업 이후에 발생할 수 있으므로, 다중 턴 시험과 에이전트의 전체 작업 흐름을 함께 평가한다.
모델이 위험한 행동을 제안하거나 실행하려 했다는 사실과 실제 보안 피해가 발생했다는 사실은 구분해야 한다.
특히 AI 에이전트 시험에서는 다음 단계를 나누어 확인한다.
- 모델이 위험하거나 승인되지 않은 행동을 판단했는지
- 해당 행동을 위한 도구 호출을 시도했는지
- 도구 실행 과정에서 인증·인가와 승인 절차가 적용됐는지
- 실제 데이터나 시스템 상태에 변경이 발생했는지
- 변경 결과를 확인하거나 작업을 중단·복구할 수 있었는지
이를 통해 모델 수준의 판단 오류와 애플리케이션·시스템 수준의 통제 실패를 구분할 수 있다.
시험 결과가 실제 시스템과 사용자에게 미치는 영향을 평가한다.
- 기밀성: 보호 대상 정보가 허가되지 않은 사용자나 시스템에 노출됐는지
- 무결성: 데이터나 시스템 설정이 승인 없이 변경됐는지
- 가용성: 서비스 장애, 지연, 과도한 비용 및 자원 고갈이 발생했는지
- 안전성: 위험하거나 유해한 출력 및 행동이 발생했는지
- 품질 및 신뢰성: 사실 오류, 논리적 모순 및 비정상적인 판단이 발생했는지
- 연계 시스템 영향: AI의 출력이나 도구 실행이 다른 시스템에 피해를 일으켰는지
실제로 확인된 영향과 발생 가능성만 제시된 잠재적 위험은 구분하여 기록해야 한다.
레드티밍 결과의 재현성과 분석 가능성을 확보하기 위해 시험 과정의 기록을 보관한다.
주요 기록 항목은 시험 시각, 대상 모델 및 애플리케이션 버전, 입력 프롬프트, 전체 대화 이력, 모델 응답, 도구 호출, 실행 결과, 시스템 로그 및 평가 결과 등이다.
AI 에이전트에서는 모델이 호출한 도구의 명칭과 인수, 승인 내역, 실행된 작업 및 결과를 확인할 수 있어야 한다.
특히 여러 단계의 대화나 작업을 거친 공격은 마지막 입력과 응답만으로 재현하기 어려우므로, 전체 작업 흐름을 기록해야 한다.
시험 과정에서 생성된 로그와 증거에는 개인정보와 내부정보가 포함될 수 있으므로 접근통제와 보관·파기 기준을 적용해야 한다.
레드티밍 결과는 기술 담당자가 취약점을 재현하고 조치할 수 있는 수준으로 작성해야 한다.
또한 조직의 책임자가 위험도와 업무 영향을 이해하고 개선 우선순위를 결정할 수 있도록 요약해야 한다.
결과보고서에는 다음 사항을 포함할 수 있다.
- 평가 목적, 대상, 범위 및 제외 사항
- 적용한 시험 방법과 환경
- 발견된 취약점 및 실패 유형
- 공격 성공 여부와 판정 근거
- 실제 확인된 영향과 잠재적 영향
- 기술적 증거와 재현 절차
- 위험도와 개선 우선순위
- 권고되는 보완 조치
- 조치 담당자와 일정
- 재시험 및 후속 관리 결과
발견된 문제의 원인에 따라 적절한 보호조치를 적용한다.
모델의 응답 정책이나 안전성 학습을 수정할 수도 있지만, 실제 보안 문제가 애플리케이션의 권한 검증 미흡에서 발생했다면 모델의 프롬프트만 변경하는 것으로 충분하지 않다.
주요 개선 방법으로는 입력·출력 검증, 최소 권한 적용, 외부 데이터의 신뢰 경계 분리, 민감정보 보호, 도구 실행 승인, 작업 결과 검증, 실행 격리, 감사 로그 및 중단 수단 강화 등이 있다.
보완 조치 후에는 동일한 공격을 다시 수행하여 문제가 해결됐는지 확인한다.
또한 특정 공격을 차단하기 위한 조치가 정상적인 사용자 요청까지 과도하게 거부하거나 다른 기능에 문제를 일으키지 않는지 함께 평가한다.
반복 가능한 공격 시나리오는 정형화된 테스트로 전환하여 모델·애플리케이션 변경 시 자동으로 실행할 수 있다.
레드티밍 결과는 발견된 취약점의 개수만으로 판단하기 어렵다. 시험 범위, 공격자의 접근 조건, 공격 시도 횟수 및 성공 판정 기준에 따라 결과가 달라질 수 있기 때문이다.
| 평가 지표 | 설명 |
|---|---|
| 공격 성공률(ASR) | 유효한 공격 시도 가운데 정의한 목표를 달성한 비율 |
| 차단 및 거부율 | 공격 입력이 보호조치에 의해 차단되거나 거부된 비율 |
| 재현율 | 동일하거나 유사한 조건에서 문제가 반복적으로 발생하는 정도 |
| 민감정보 노출 건수 | 시험을 통해 확인된 비인가 정보 노출 횟수 |
| 실행 통제 실패 | AI 에이전트가 승인되지 않은 도구를 실행하거나 허용되지 않은 결과를 발생시킨 사례 |
| 자원 영향 | 공격 입력에 따른 처리 지연, CPU·GPU 사용량 및 API 호출 비용 증가 |
| 위험도 | 실제 피해 가능성과 영향 범위를 고려한 심각성 평가 |
| 개선 후 재발 여부 | 보완 조치 이후 동일한 취약점이 다시 발생하는지 여부 |
특히 공격 성공률은 시험 조건에 크게 좌우된다. 공개된 수치만으로 서로 다른 모델이나 서비스를 직접 비교하려면 공격 목표, 공격자의 시도 횟수, 접근권한 및 결과 판정 기준이 동일한지 확인해야 한다.
자동화된 평가에서는 모델의 응답이 실제로 정책을 위반했는지 판단하는 과정에서 오탐과 미탐이 발생할 수 있다. 따라서 심각도가 높은 결과나 판정이 불확실한 사례는 사람이 검토해야 한다.
AI 에이전트의 경우에는 모델이 잘못된 판단을 내린 비율과 실제 시스템에서 비인가 작업이 실행된 비율을 구분하는 것이 중요하다.
AI 시스템을 설계하거나 개발하는 단계에서는 모델과 데이터, 애플리케이션 구조에 존재하는 취약점을 사전에 탐색한다.
새로운 기능이나 외부 도구를 추가하기 전에 발생 가능한 공격 표면과 권한 관계를 확인하고, 발견된 문제를 설계 및 구현에 반영할 수 있다.
배포 전에는 실제 서비스 환경과 유사한 구성에서 모델, API, 검색 시스템, 인증·인가, 가드레일, 도구 실행 및 로그 체계를 통합적으로 시험한다.
특히 고객정보나 금융거래 등 중요한 데이터와 업무를 처리하는 서비스에서는 비인가 접근과 실행이 실제로 차단되는지 확인해야 한다.
AI 모델과 서비스는 배포 이후에도 변경될 수 있으며 새로운 공격 기법도 등장한다.
따라서 다음과 같은 상황에서 재평가가 필요할 수 있다.
- 모델 교체 및 주요 버전 업데이트
- 파인튜닝이나 안전정책 변경
- 시스템 프롬프트 변경
- RAG 데이터 및 검색 구성 변경
- 외부 API 또는 MCP 도구 추가
- 에이전트 실행 권한 변경
- 새로운 취약점 및 공격 기법 공개
자동화 가능한 시험은 CI/CD 파이프라인에 통합하여 반복적으로 실행할 수 있다.
다만 자동화 시험의 통과가 시스템의 완전한 안전성을 보장하는 것은 아니므로 정기적인 전문가 검증과 운영 모니터링을 병행해야 한다.
과학기술정보통신부와 KISA는 2026년 7월 「AI 보안 레드티밍 가이드」를 발간했다. 이 가이드는 AI 모델과 서비스를 보유하거나 운영하는 기업과 기관이 레드팀을 구성하고 레드티밍을 수행하기 위한 실무 지침이다.[1]
가이드는 개요, AI 보안 레드티밍의 이해, 레드팀 구성, 레드티밍 준비, 레드티밍 이행, 결과보고 등으로 구성되며 다음 사항을 다룬다.
- AI 레드티밍의 개념과 필요성
- 데이터·모델·애플리케이션·인프라의 평가 범위
- AI 특화 보안 위협과 시험 관점
- 레드팀 인력의 역할과 구성
- 평가 대상 및 교전 규칙 설정
- 공격 시나리오 개발과 시험 환경 준비
- 자동화 및 전문가 기반 공격 수행
- 영향도 분석과 증거 관리
- 결과보고서 작성과 개선 조치
- 레드티밍 체크리스트 및 실무 자료
가이드는 개발 중인 AI 레드티밍 국제표준안인 ISO/IEC 42119-7을 참고하고 국내 실무자와 전문가의 의견을 반영하여 작성됐다.[5]
KISA는 같은 시기 「AI 보안 위협 대응 매뉴얼」을 공개했다.[2]
이 매뉴얼은 AI 보안 위협의 분류와 진단, 산업별 위협 시나리오, 위협별 대응 방안을 다룬다.
데이터 위협, 모델 위협, 에이전트 위협, 공급망 위협 및 고성능 모델 관련 위협 등을 포함하며, 금융·의료·공공·교육·제조·에너지·통신·법률·IT 등 다양한 산업의 활용 환경을 고려한다.[5]
두 자료는 상호 보완적이다. 「AI 보안 위협 대응 매뉴얼」이 어떤 위협을 식별하고 대응할 것인지 설명한다면, 「AI 보안 레드티밍 가이드」는 이를 실제 시험으로 수행하기 위한 방법과 절차를 제공한다.
2026년 10월 7일 금융보안원은 금융회사에서 AI 에이전트의 도입이 확대됨에 따라 실행 단계의 위험을 검증하기 위한 「금융분야 AI 에이전트 보안 평가기준」을 마련했다고 밝혔다.[3]
금융보안원은 기존의 탈옥 공격과 시스템 프롬프트 유출 등 모델 자체의 취약점에 대한 평가에서 나아가, AI 에이전트가 실제로 수행하는 작업과 이를 통제하는 보안체계까지 점검하도록 평가 범위를 확대했다.
특히 실행 권한과 격리 체계, 외부 도구 사용에 대한 승인, 작업 범위와 결과 검증, 자율 실행의 제한 및 중단 가능성을 중요한 평가 대상으로 제시했다.[4]
금융보안원은 평가기준을 금융회사 대상 AI 레드티밍에 시범 적용한 뒤 정식 점검기준으로 확대할 계획이며, 확인된 보안 위협과 실제 공격 기법 등을 「AI REDTEAM REPORT」를 통해 공개할 예정이라고 밝혔다.
이러한 접근은 AI 레드티밍이 모델이 어떤 답변을 생성하는지 확인하는 활동에서 AI가 실제로 어떤 행동을 수행하며 그 행동이 적절하게 통제되는지 평가하는 활동으로 확대되고 있음을 보여준다.
OWASP는 2025년 1월 「GenAI Red Teaming Guide」를 공개하여 생성형 AI 시스템을 대상으로 하는 위험 기반 레드티밍 방법을 제시했다.[8]
이 가이드는 모델 자체의 평가뿐 아니라 구현, 인프라 및 실행 중 행동 등 실제 AI 시스템을 구성하는 여러 영역을 함께 검증하는 접근을 강조한다.
OWASP의 「Top 10 for LLM Applications」도 프롬프트 인젝션, 민감정보 공개, 데이터 및 모델 오염, 부적절한 출력 처리, 과도한 자율성 등 AI 애플리케이션의 주요 보안 위험을 이해하는 데 활용할 수 있다.[9]
ISO/IEC 42119-7은 AI 레드티밍의 방법론 및 수행 절차와 관련된 국제표준화 작업이다.
2026년 KISA의 「AI 보안 레드티밍 가이드」는 해당 국제표준안을 참고하여 레드팀의 구성, 시험 준비, 수행, 결과보고 등을 체계적으로 설명하고 있다.[5]
국제표준안을 참고한 국내 지침과 최종적으로 확정된 국제표준의 요구사항은 구분하여 적용할 필요가 있다.
인공지능 레드티밍은 시스템의 위험을 발견하고 개선하는 데 유용하지만 모든 취약점과 실패를 사전에 찾아낼 수는 없다.
- 시험 범위의 한계: 시험에 포함되지 않은 공격 경로나 실제 사용 환경의 위험은 발견하지 못할 수 있다.
- 비결정적인 모델 동작: 동일한 입력에서도 모델의 응답이나 행동이 달라질 수 있다.
- 자동 판정의 한계: 평가기가 실제 취약점을 놓치거나 정상적인 행동을 위험으로 판단할 수 있다.
- 새로운 공격 기법: 공개된 공격 유형에 대한 방어에 성공하더라도 새로운 방식에 취약할 수 있다.
- 운영 환경과의 차이: 시험 환경과 실제 환경의 데이터, 권한, 도구 구성 및 사용 조건이 다를 수 있다.
- 정상 기능에 대한 영향: 방어 조치가 지나치면 정당한 사용자 요청까지 차단할 수 있다.
- 시험 자체의 위험: 공격 시험 과정에서 서비스 장애, 데이터 변경 또는 외부 시스템에 대한 영향이 발생할 수 있다.
레드티밍 결과가 양호하더라도 인증·인가, 데이터 보호, 입력·출력 검증, 실행 격리, 운영 모니터링 및 사고 대응 체계 등을 별도로 유지해야 한다.
특히 실행 권한이 있는 AI 에이전트는 모델의 안전정책을 우회할 수 있다는 전제에서도 실제 시스템의 보호조치가 작동하도록 설계해야 한다. 레드티밍은 이러한 통제의 실효성을 확인하는 활동이지, 보안 통제를 대신하는 수단은 아니다.
- 과학기술정보통신부·한국인터넷진흥원, 「AI 보안 레드티밍 가이드」 (2026)
- 과학기술정보통신부·한국인터넷진흥원, 「AI 보안 위협 대응 매뉴얼」 (2026)
- 연합뉴스, 「경영진부터 레드팀까지…AI 보안 진단·대응 가이드 나왔다」 (2026.7.8)
- 금융감독원·금융보안원, 「2026년 금융권 블라인드 모의해킹 훈련」 관련 보도자료 (2026.4.30)
- 연합뉴스, 「금융보안원, 금융분야 AI 에이전트 보안 평가기준 마련」 (2026.10.7)
- 뉴시스, 「금융보안원, AI 에이전트 보안 점검 강화…17개 평가항목 마련」 (2026.10.7)
- ↑ 1.0 1.1 1.2 1.3 1.4 1.5 1.6 한국인터넷진흥원, 「AI 보안 레드티밍 가이드」, 2026년 7월 7일, https://www.kisa.or.kr/401/form?lang_type=KO&postSeq=3713, 확인일: 2026-10-11.
- ↑ 2.0 2.1 한국인터넷진흥원, 「AI 보안 위협 대응 매뉴얼」, 2026년 7월 7일, https://www.kisa.or.kr/401/form?lang_type=KO&postSeq=3712, 확인일: 2026-10-11.
- ↑ 3.0 3.1 연합뉴스, 「금융보안원, 금융분야 AI 에이전트 보안 평가기준 마련」, 2026년 10월 7일, https://www.yna.co.kr/view/AKR20261007056900002, 확인일: 2026-10-11.
- ↑ 4.0 4.1 4.2 뉴시스, 「금융보안원, AI 에이전트 보안 점검 강화…17개 평가항목 마련」, 2026년 10월 7일, https://www.newsis.com/view/NISX20261007_0003816900, 확인일: 2026-10-11.
- ↑ 5.0 5.1 5.2 연합뉴스, 「경영진부터 레드팀까지…AI 보안 진단·대응 가이드 나왔다」, 2026년 7월 8일, https://www.yna.co.kr/view/AKR20260708096200017, 확인일: 2026-10-11.
- ↑ 금융보안원, 「(공동)2026년 금융권 블라인드 모의해킹 훈련을 연 2회로 확대 실시합니다」, 2026년 4월 30일, https://www.fsec.or.kr/bbs/detail?bbsNo=11944&menuNo=69, 확인일: 2026-10-11.
- ↑ NIST, "Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations", NIST AI 100-2 E2025, 2025년 3월, https://csrc.nist.gov/pubs/ai/100/2/e2025/final, 확인일: 2026-10-11.
- ↑ OWASP Gen AI Security Project, "GenAI Red Teaming Guide", 2025년 1월, https://genai.owasp.org/resource/genai-red-teaming-guide/, 확인일: 2026-10-11.
- ↑ OWASP Gen AI Security Project, "OWASP Top 10 for LLM Applications 2025", https://genai.owasp.org/llm-top-10/, 확인일: 2026-10-11.