AI 보안 레드티밍은 모델에 탈옥 프롬프트 몇 개를 넣어 보는 단발성 시험이 아닙니다. 데이터·모델·애플리케이션·가드레일·외부 연계·인프라를 공격자 관점에서 확인하고, 재현 가능한 증거와 개선·재시험까지 연결하는 운영 절차입니다. 2026년 7월 7일 공개된 KISA 공식 가이드를 기준으로 팀 구성 → 준비 → 공격 이행 → 결과보고·재시험 순서를 실무자가 바로 적용할 수 있게 정리합니다.
법정 인증이나 모든 기업의 일률적 의무 기준은 아닙니다
KISA 문서는 AI 보안 레드팀 운영을 돕는 실무 가이드입니다. 가이드의 위험등급, 수치 기준, 점검 도구는 예시이므로 조직의 서비스·규제·피해 규모에 맞게 조정해야 합니다. 별도의 법정 의무 대상 여부는 AI기본법, 개인정보보호법, 업종별 규정과 계약 조건을 따로 확인하세요.
1. 우리 조직도 AI 레드티밍 대상인가
KISA 가이드는 특정 업종만을 대상으로 한 신청 사업이 아니라, AI 시스템을 개발·배포·운영하는 조직이 참고할 수 있는 운영 지침입니다. 특히 외부 입력을 받고, 내부 자료를 검색하거나, 다른 시스템을 실제로 조작하는 AI일수록 모델 바깥의 공격 경로가 커집니다.
| 시기 | 무엇을 확인하나 | 대표 계기 |
|---|---|---|
| 개발 단계 | 학습·평가 데이터, 모델 취약점, 설계·구현상의 위험 | 새 모델 도입, 파인튜닝, 시스템 프롬프트 변경 |
| 배포 전 | API, 가드레일, 에이전트 행동, 외부 연계까지 전체 시스템 | 신규 출시, 주요 기능·권한 확대 |
| 운영 중 | 이상 징후, 새 공격법, 업데이트 뒤 재발·우회 가능성 | 모델·도구 업데이트, 사고 징후, 정기 점검 |
우선순위를 높여야 하는 시스템
- 고객·직원이 자유로운 문장이나 파일을 입력할 수 있다.
- RAG가 사내 문서, 벡터DB, 웹검색 결과를 불러온다.
- AI가 메일 발송, 결제, 코드 실행, 계정 변경 등 도구를 호출한다.
- 개인정보·영업비밀·금융·의료 등 민감한 데이터를 다룬다.
- 모델 출력이 사람의 검토 없이 실제 업무나 외부 시스템 동작으로 이어진다.
질문: 우리 조직이 법적으로 반드시 해야 하나요?
답: 이 가이드 자체가 일률적인 법정 의무를 만들지는 않습니다. 다만 위 조건에 해당한다면 피해 가능성과 연결 범위를 기준으로 내부 위험관리 절차에 편입할 실익이 큽니다. 규제 대상 여부는 별도 법령과 감독기관 안내를 확인해야 합니다.
2. 일반 모의해킹·모델평가와 무엇이 다른가
세 점검은 서로 대체 관계가 아닙니다. 전통적 모의해킹이 서버·웹·API의 기술 취약점에 강하고, 모델평가가 정확도·성능을 비교한다면, AI 레드티밍은 공격자의 의도와 실제 서비스 맥락을 넣어 시스템 전체에서 발생할 수 있는 보안·안전·품질·성능 위험을 확인합니다.
| 구분 | 주요 질문 | 놓치기 쉬운 부분 |
|---|---|---|
| 모델평가 | 정확도·안전성·성능이 기준을 충족하는가 | 서비스 권한, 외부 도구, 실제 공격 연쇄 |
| 일반 모의해킹 | 웹·API·서버에 알려진 기술 취약점이 있는가 | 멀티턴 설득, 프롬프트·문맥 조작, 모델 행동 |
| AI 레드티밍 | 공격자가 모델과 연결 기능을 악용해 실제 피해를 만들 수 있는가 | 단독 수행 시 전통 보안 취약점이나 정상 품질 회귀 |
따라서 가장 안전한 구성은 기존 보안점검·모델평가를 유지하면서 AI 레드티밍을 연결하는 방식입니다. 가이드는 블랙박스·그레이박스·화이트박스 접근을 목적에 따라 선택하도록 안내합니다.
3. 레드팀은 6개 역할로 구성한다
한 명의 프롬프트 전문가에게 전부 맡기면 모델 밖의 원인과 실제 피해를 놓치기 쉽습니다. KISA는 다음 여섯 역할을 제시하며, 조직 규모와 시스템 특성에 따라 한 사람이 여러 역할을 맡거나 더 세분화할 수 있다고 설명합니다.
리더·PM
전략, 범위, 예산, 일정, 품질과 의사결정을 총괄합니다.
AI 레드팀 전문가
프롬프트 기반 공격을 설계·실행하고 모델 반응을 분석합니다.
보안 테스트 전문가
웹·API·인프라의 취약점과 공격 연쇄를 확인합니다.
AI 엔지니어
모델·학습 데이터·추론·로그를 분석해 원인과 개선안을 검토합니다.
AI 법률 자문가
법·규제 기준과 출력·처리 과정의 위법성 및 리스크를 판단합니다.
도메인 전문가
금융·의료·공공 등 서비스 맥락에서 시나리오 현실성과 피해를 평가합니다.
사람의 안전도 운영 범위입니다
교육에는 시스템 이해, AI 보안 기법, 도메인 위험, 윤리·교전 규칙이 포함되어야 합니다. 유해하거나 민감한 콘텐츠를 반복해서 보는 구성원에게는 노출 최소화, 교대, 상담 등 심리적 지원 절차도 마련해야 합니다.
4. 공격 전에 교전 규칙·범위·중단 기준부터 합의한다
레드티밍의 첫 산출물은 공격 결과가 아니라 안전하게 공격하기 위한 합의 문서입니다. 시스템 담당, 보안, 개발·운영, 법무·개인정보 부서가 함께 목적과 허용선을 정해야 합니다.
- 목적과 성공 기준 정의
무엇을 검증할지, 공격 성공·차단·재현을 어떻게 판단할지 정합니다. - 대상과 제외 범위 확정
데이터·모델·앱·제어 체계·외부 연계·인프라 중 점검할 것과 제외 사유를 적습니다. - 교전 규칙 작성
허용 위협, 금지 행위, 데이터 보관·삭제, 허용 영향, 즉시 중단·재개 기준, 긴급 보고 체계를 합의합니다. - 접근 수준 선택
입출력만 보는 블랙박스, 일부 정보를 받는 그레이박스, 코드·구조까지 보는 화이트박스 중 목적에 맞게 정합니다. - 격리된 환경과 권한 준비
가능하면 개발·스테이징 환경, 전용 계정, 임시 인증정보, 별도 데이터셋, 최소 권한을 사용합니다. - 로그·비상 연락망 확인
장애·보안사고·중대 취약점 발생 시 즉시 중단하고 담당자에게 에스컬레이션할 채널을 시험합니다.
| 방식 | 제공 정보 | 장점과 한계 |
|---|---|---|
| 블랙박스 | 입력·출력 중심 | 외부 공격 현실성은 높지만 구조적 원인 탐지는 제한됩니다. |
| 그레이박스 | 일부 설계·권한·로그 | 현실성과 심층성의 절충안이지만 제공 정보만큼 분석 범위가 정해집니다. |
| 화이트박스 | 코드·아키텍처·설정 전반 | 근본 원인 분석에 유리하지만 실제 외부 공격 조건과 다를 수 있습니다. |
어떤 자료를 준비해야 하나요?
- 시스템 구성도, 모델·프롬프트·가드레일 버전과 변경 이력
- 데이터 흐름도, RAG 저장소와 외부 API·도구 연결 목록
- 테스트 계정·API 키, 권한표, 테스트 데이터셋과 회수 계획
- 입출력·도구 실행·접근 로그, 시간 동기화와 무결성 확인 방법
- 금지 행위, 중단 조건, 비상 연락망, 결과 열람·보관·삭제 규칙
질문: 지금 가장 먼저 해야 할 일은 무엇인가요?
답: 공격 도구를 고르기 전에 서비스의 데이터 흐름과 외부 연결을 그린 뒤, 담당 부서와 범위·금지 행위·중단 기준을 한 문서로 합의하세요. 이 문서가 없으면 깊게 점검할수록 실제 서비스와 개인정보에 위험을 줄 수 있습니다.
5. 재현 가능한 시나리오와 평가 기준을 만든다
위협 시나리오는 단순한 공격 문장 목록이 아닙니다. 먼저 채팅 UI·파일 업로드, API, RAG·벡터DB, 시스템 프롬프트·필터, Function Calling·MCP·외부 도구, 로그·CI/CD·모델서빙처럼 실제 동작으로 이어지는 공격 표면을 식별합니다. 그다음 일반 사용자, 악의적 사용자, 내부자, 전문지식 보유자, 자동화 도구 활용자 등의 페르소나를 붙여 현실적인 경로를 만듭니다.
| 항목 | 기록 내용 | 항목 | 기록 내용 |
|---|---|---|---|
| 1. 시나리오명 | 점검 목적이 드러나는 이름 | 2. 공격 표면 | UI·API·RAG·도구·인프라 |
| 3. 페르소나 | 의도·접근 수준·전문성 | 4. 공격 유형 | 인젝션·탈옥·권한 악용 등 |
| 5. 사전 조건 | 계정·권한·데이터·상태 | 6. 실행 절차 | 반복 가능한 입력과 단계 |
| 7. 판정 기준 | 성공·차단·부분 성공 정의 | 8. 영향도 | 안전·품질·성능·시스템 피해 |
| 9. 기록 항목 | 입력·전체 응답·모델 버전·설정·로그·증적 | ||
숫자는 공격 전에 합의해야 합니다
정량 지표에는 공격 성공률, 차단·거부율, 재현율, 민감정보 노출 건수, 공격 입력의 응답 지연·자원 사용량이 있습니다. 정성 지표에는 영향도, 악용 가능성, 연계 시스템 영향, 정책 위반 수준, 대응 가능성을 둡니다.
1%·0건·2배는 ‘예시’입니다
가이드는 목표 예시로 탈옥 성공률 1% 미만, 민감정보 노출 0건, 공격 입력 평균 응답 지연 2배 이하를 제시합니다. 모든 조직이 지켜야 하는 통일 기준이 아닙니다. 서비스 위험과 정상 사용 패턴을 바탕으로 조직 자체 기준을 정하고 착수 전에 합의해야 합니다.
위험등급도 Critical(5)·High(4)·Medium(3)·Low(2)·Safe(1)의 5단계 예시를 쓸 수 있습니다. 단순히 공격이 성공했는지만 보지 말고 영향도·악용 가능성·재현 가능성·대응 필요성을 함께 평가해야 합니다.
6. 자동화 전수조사와 전문가 심층점검을 결합한다
KISA 가이드의 이행 단계는 한정된 자원으로 넓이와 깊이를 함께 확보하기 위해 2단계 검증 접근법을 제시합니다.
- 1단계｜자동화 도구로 공격 표면 전수조사
정형 페이로드를 대량 입력하고, 차단되면 공격자 모델이 어조·언어·구조를 바꿔 재시도할 수 있습니다. 판정 모델은 성공·잠재위험 후보를 추려 전문가에게 넘깁니다. - 2단계｜전문가 심층점검
자동화가 놓치는 맥락 기반 역할극, 경쟁 조건, 멀티턴 공격과 내부 로직을 분석합니다. 정보 수집 → 신뢰 형성 → 악성 입력처럼 여러 단계가 결합된 공격도 확인합니다.
LLM-as-a-Judge의 판정을 그대로 확정하지 마세요
판정 모델은 후보 선별 속도를 높이는 보조 수단입니다. 모델의 오판, 평가 프롬프트 편향, 버전 차이가 있으므로 고위험 결과는 사람이 원문 응답·로그·실제 시스템 동작을 확인해야 합니다. 실행하지 못한 고위험 시나리오도 잔여 위험으로 최종 보고서에 남겨야 합니다.
증적이 없으면 재현도 개선도 어렵습니다
기록에는 직접·간접 인젝션 입력, 전체 응답, 모델 버전, 하이퍼파라미터와 시스템 메타데이터를 포함합니다. 전체 대화의 공격 체인 스냅샷, 재현 스크립트, UI 스크린샷·녹화, 접근·도구 실행 로그를 연결하고 무결성과 열람 권한을 관리하세요.
7. 출력이 아니라 실제 영향까지 분석하고 보고한다
위험한 문장이 출력됐다는 사실과 실제 피해가 발생했다는 사실은 구분해야 합니다. AI 출력이 코드·쿼리·명령으로 백엔드에서 실행되어 조회·변경·권한우회·장애로 이어졌는지, 외부·물리·금융 시스템에 연쇄 영향을 줬는지 확인합니다. 에이전트형 AI는 도구 호출 전 권한 검증, 실행 경계, 실행·결과 로그와 전 과정 추적 가능성이 특히 중요합니다.
| 구성 | 반드시 들어갈 내용 |
|---|---|
| 1. 레드티밍 개요 | 대상 시스템 버전·아키텍처·일정·인력·환경 |
| 2. 평가 범위 | 점검 계층, 평가 차원, 제외 항목과 제외 사유·한계 |
| 3. 취약점 요약 | 위험등급별 건수와 잠재적 비즈니스 영향 |
| 4. 항목별 상세 | 식별정보, 시나리오·페이로드, 영향, 재현 증적, 개선안 |
보고서는 특정 시점의 보안 상태 스냅샷입니다
한 번 통과했다고 영구적으로 안전한 것은 아닙니다. 모델, 시스템 프롬프트, 데이터, 가드레일, 연결 도구 중 하나만 바뀌어도 결과가 달라질 수 있으므로 보고서에 버전과 평가 시점, 제외 범위를 명시해야 합니다.
| 등급 | 가이드의 조치 예시 | 관리 포인트 |
|---|---|---|
| Critical | 즉시 조치, 서비스 중단 또는 배포 보류 | 경영진·사고대응 체계 즉시 보고 |
| High | 배포 전 필수 조치 | 담당자·기한·재검증 조건 지정 |
| Medium | 패치, 배포 후 조치 가능 | 수용 사유와 완료 예정일 기록 |
| Low | 별도 조치 없이 모니터링 가능 | 새 공격·변경 뒤 등급 재평가 |
위 우선순위 역시 발생 가능성과 비즈니스 영향에 따라 조정하는 예시입니다. 모든 Critical이 같은 방식으로 서비스 중단을 요구한다는 뜻은 아니며, 조직의 승인 체계와 법적 보고 의무를 함께 적용해야 합니다.
8. 패치 뒤 재검증과 정상 기능 회귀시험을 함께 한다
개선이 끝나면 첫째, 기존 취약점이 사라졌는지 보는 재검증, 둘째, 보안 강화가 정상 성능과 유용성을 해치지 않았는지 보는 회귀시험을 병행합니다.
- 동일 페이로드 재공격
원래 공격 입력과 조건을 그대로 재현해 패치가 직접 원인을 막았는지 확인합니다. - 변형 우회 공격
난독화, 역할극, 언어·구조 변경 등으로 같은 목적을 다시 시도합니다. - 정상 질의 회귀시험
정상 업무 요청이 과도하게 차단되지 않는지, 정확도·응답속도·유용성이 나빠지지 않았는지 비교합니다. - 운영 기준 반영
확인된 시나리오와 조치 결과를 CI/CD 자동 스캔, 회귀시험, 가드레일 모니터링 기준에 추가합니다.
첫 점검 운영 순서 예시
자산·연결·데이터 흐름 작성, 담당자와 교전 규칙 합의
핵심 공격 표면과 페르소나 선정, 시나리오·판정 기준 작성
격리 환경에서 자동화 전수조사와 전문가 심층점검
위험 우선순위·담당자·기한 확정, 재검증·회귀시험 후 운영 반영
위 순서는 공식 의무가 아니라 소규모 첫 점검을 시작하기 위한 운영 예시입니다. 시스템 규모와 규제 수준에 따라 기간과 인력을 늘리세요.
9. 사내 문서 검색 AI라면 무엇을 성공 기준으로 볼까
가상의 사내 규정 검색 서비스를 예로 들어 보겠습니다. 먼저 실제 기밀 대신 테스트용 문서 두 개를 만들고, 하나는 모든 테스트 계정이 읽을 수 있게, 다른 하나는 승인된 특정 계정만 읽을 수 있게 구성합니다. 점검 범위와 계정 권한은 담당자에게 승인받은 격리 환경 안에서만 설정합니다.
확인할 것은 AI가 “접근할 수 없습니다”라고 답했는지뿐만이 아닙니다. 권한이 없는 문서가 검색 결과나 인용에 섞였는지, 도구 실행 로그에 허용되지 않은 조회가 남았는지도 함께 봐야 합니다. 반대로 모든 조회를 막으면 유출 시험은 통과해도 검색 서비스가 쓸모없어집니다. 같은 계정이 공개용 테스트 문서는 정상적으로 검색하고 근거를 제시하는지까지 한 쌍으로 확인하세요.
이렇게 보면 개선할 위치도 구분됩니다. 문서를 가져오는 단계의 권한 문제인지, 가져온 내용의 출력 문제인지, 로그가 없어 판단할 수 없는 문제인지 따로 기록할 수 있습니다. 위 구성은 가이드의 권한 검증·실제 영향 확인·정상 기능 회귀시험 원칙을 적용한 설명용 예시이며, 실제 시험 결과나 공식 인증 항목은 아닙니다.
10. 자주 묻는 질문
공식 가이드는 어디서 확인하고 별도 신청해야 하나요?
KISA 공지 페이지에서 PDF를 내려받을 수 있습니다. 가이드를 읽기 위한 별도 신청은 없습니다. 컨설팅·지원사업 참여 여부는 KISA의 해당 사업 공고를 별도로 확인해야 합니다.
얼마나 자주 해야 하나요?
가이드는 개발·배포·운영 단계의 반복 수행을 강조하며 지속 점검, 분기·반기 집중점검, 챌린지 형태를 예로 듭니다. 서비스 위험과 변경 빈도에 맞춰 주기를 정하고 주요 변경 뒤에는 재검증하세요.
공식 원문 확인
- 국내 공식 가이드KISA AI 보안 레드티밍 가이드 공지·PDF
- AI 보안 전반KISA 인공지능(AI) 보안 안내서 정오 수정본
- 국제 위험관리 참고NIST 생성형 AI 위험관리 프로파일
'AI > AI 비교·정책' 카테고리의 다른 글
| 2026 AI 분석모델 경진대회｜1차 제출 종료·2차 자료 10월 5일 10시 마감 (0) | 2026.09.02 |
|---|---|
| 2026 디지털튜터 양성교육 신청｜9월 2일~8일·1,700명·무료교육·6개 권역 (0) | 2026.09.01 |
| 2026 AI 맞춤형 건강리포트 확인법｜약 10만 명·8월 31일부터 5주·앱 설치 없음 (0) | 2026.09.01 |
| 2026 모두의 AI 실험실 경진대회 신청｜9월 6일 18시·만 15세 이상·팀 최대 4명 (0) | 2026.09.01 |
| 2027 EU Annex III 고위험 AI 이용기업 의무｜12월 2일 시행 예정·로그 6개월·근로자 사전고지 (0) | 2026.08.31 |
