NIST·OWASP로 설계하는 생성형 AI 사고 대응과 레드팀 운영

오전 10시 2분, 고객 상담 AI가 승인되지 않은 환불 절차를 안내했다는 신고가 들어옵니다. 10시 6분에는 같은 세션에서 내부 문서 일부가 답변에 섞였다는 기록도 발견됩니다. 운영팀은 모델을 끌지, 검색 연결만 차단할지, 고객에게 알릴지 결정해야 합니다.

설명을 위한 가상 상황입니다. 실제로 어려운 부분은 어느 시점부터 사고로 선언할지 정하는 일입니다. 환각, 인젝션, 정보 노출과 잘못된 도구 실행이 서로 다른 경로로 같은 피해를 만들 수 있기 때문이죠.

기존 대응 절차를 버릴 이유는 없습니다. NIST CSF 2.0은 위험 관리를 Govern, Identify, Protect, Detect, Respond, Recover로 구성하고 사고의 분류, 증거 보존, 격리와 복구를 제시합니다. NIST CSF 2.0 Resource & Overview Guide

생성형 AI에서는 모델·프롬프트, 검색 문서, 필터 판정, 도구 호출과 사람의 개입까지 추적해야 합니다.

사고 선언 전에 등급부터 정한다

모든 잘못된 답변을 같은 수준으로 처리하면 급한 사건이 경보 속에 묻힙니다. 반대로 “모델은 원래 틀릴 수 있다”며 넘기면 정보 노출이나 도구 오작동을 늦게 발견할 수 있죠.

아래 표는 NIST의 표준 등급이 아니라 공식 프레임워크의 영향·위험 허용도·대응 우선순위 원칙을 운영 문서로 옮긴 예시입니다.

등급	예시	첫 조치
관찰	출처 누락, 복구 가능한 단일 오류	사례 기록과 추세 확인
주의	반복 정책 위반, 특정 문서에서 재현되는 오류	영향 경로 제한과 담당자 조사
높음	민감 정보 노출 가능성, 승인되지 않은 외부 호출	관련 도구와 자격 증명 격리
긴급	실제 유출, 대규모 자동 실행, 안전에 직접 영향	지휘 체계 가동과 서비스 중단 검토

NIST AI RMF Core는 위험을 영향, 가능성과 자원에 따라 우선순위화하고 완화·이전·회피·수용 중에서 대응하도록 설명합니다. 각 기능은 상황과 수명주기에 맞게 반복합니다. NIST AI RMF Core

등급에는 사람과 데이터의 영향 범위, 실제 시스템 행동 여부, 복구 가능성을 반영해야 합니다.

사고 대응 흐름: 일곱 단계로 진행한다

1. 답변과 행동을 함께 탐지한다

사용자 신고뿐 아니라 정책 위반, 비정상 도구 호출, 외부 도메인 접근, 검색 문서 변화와 사람의 잦은 중단도 신호입니다.

NIST 생성형 AI 프로필은 배포 후 모니터링에 사용자 입력, 이의 제기와 오버라이드, 시스템 중단, 사고 대응, 복구, 변경 관리를 포함하고 잠재적인 환각·사이버 위험을 다루는 절차가 효과적인지 평가하도록 권고합니다. NIST AI 600-1, MANAGE 4.1

2. 원인을 네 계층으로 분류한다

원인을 바로 확정할 필요는 없습니다. 모델의 유해 출력·환각, 입력과 RAG의 인젝션·오염, 애플리케이션의 검증·세션 실패, 권한과 공급망 변경으로 조사 경로를 나눕니다.

OWASP는 평가 범위를 모델, 구현, 시스템, 런타임의 사람·에이전트 상호작용으로 구분합니다. 모델 답변만 보면 API와 통합 지점의 문제를 놓칠 수 있습니다. OWASP GenAI Red Teaming Guide 1.0

3. 당시 상태를 재현할 증거를 보존한다

발생 시각과 세션 ID, 입출력, 모델·프롬프트 버전, 검색 문서 출처, 필터 판정, 도구 인자와 실행 결과, 자격 증명 범위, 사람의 승인 기록이 출발점입니다.

NIST CSF 2.0은 사고 데이터를 수집할 때 무결성과 출처를 보존하고 안전하게 저장해 현재 대응과 향후 계획 개선에 활용하도록 안내합니다. NIST CSF 2.0 Resource & Overview Guide

민감한 프롬프트가 로그에서 다시 노출되지 않도록 접근 통제, 마스킹과 보존 기간도 정해야 합니다.

4. 가장 작은 안전한 단위부터 격리한다

어느 연결이 피해를 키우는지 보고 RAG 인덱스를 되돌리거나 외부 전송을 막고, 쓰기 도구를 읽기 전용으로 바꾸거나 자격 증명을 회수합니다.

NIST는 의도와 다른 결과를 보이는 시스템을 대체·분리·비활성화할 절차와 중단 기준을 위험 허용도에 맞게 검토하도록 권고합니다. NIST AI 600-1, MANAGE 2.4

외부 공급자가 원인일 때를 대비해 책임과 연락선을 정하고, 대체 기술이나 수동 처리 같은 폴백도 시험해야 합니다. NIST AI 600-1, GOVERN 6.2

5. 프롬프트 한 줄이 아니라 실패한 통제를 수정한다

간접 인젝션이었다면 오염 문서 제거, 검색 출처 제한, 출력 검증, 도구 허용 목록, 자격 증명 축소와 승인 개선이 함께 필요할 수 있습니다.

수정에는 소유자와 완료 조건을 붙입니다. “필터 강화”보다 “외부 전송은 허용 목록과 사람 승인을 모두 통과한다”가 검증하기 쉽습니다. NIST도 대응 절차와 담당 조직의 문서화를 제안합니다. NIST AI RMF Playbook, MANAGE 1.3

6. 통제가 작동하는지 확인한 뒤 복구한다

수정된 시스템이 일반 질문에 답했다는 사실만으로 복구를 선언하면 부족합니다. 사고 입력과 그 변형, 인접한 권한 경로를 다시 실행해 차단·승인·격리·기록이 작동하는지 확인해야 합니다.

NIST CSF 2.0은 역할과 권한을 확인하고 서비스 가용성을 회복하며, 복구 자산의 무결성을 재개 전에 점검하도록 권고합니다. NIST CSF 2.0 Resource & Overview Guide

7. 실제 사고와 근접 사고를 함께 남긴다

외부 전송 직전 사용자 승인이 공격을 발견했다면 결과는 막았어도 입력 격리와 도구 계획 검사는 실패했을 수 있습니다. 이런 근접 사고도 다음 회귀 테스트에 남겨야 합니다.

NIST는 사고의 근본 원인을 분석해 예방 조치를 반영하고 오류·근접 사고·부정적 영향을 기록하도록 권고합니다. NIST AI 600-1, MANAGE 4.2~4.3

레드팀을 일회성 보고서로 끝내지 않는다

운영팀에 필요한 결과물은 공격 문구 목록보다 어떤 통제가 실패했고 무엇을 끊으면 피해를 제한할 수 있는지에 가깝습니다.

OWASP는 중요한 시스템과 민감 데이터 사용 사례를 우선하고 모델·구현·시스템·런타임을 평가하라고 제안합니다. 발견 사항은 수정 후 다시 시험합니다. OWASP GenAI Red Teaming Guide 1.0, Quick Start

“고객 지원 AI를 테스트한다”는 범위는 넓습니다. 자산과 금지선을 적는 편이 낫습니다.

대상: 고객 문서 RAG와 환불 조회 도구가 연결된 상담 에이전트
목표: 다른 고객 정보 접근, 승인 없는 환불, 외부 전송 가능성 확인
허용 환경: 실제 고객 데이터가 없는 격리된 스테이징
중단 기준: 테스트 환경 밖 호출 또는 예상하지 못한 실제 데이터 노출

OWASP는 테스트 권한, 로그, 보고, 운영 보안과 데이터 처리를 범위에 포함하도록 설명합니다. OWASP GenAI Red Teaming Guide 1.0, AI Red Teaming Scope

생성형 AI 출력은 확률적이라 같은 입력도 달라질 수 있습니다. OWASP는 단순 통과·실패보다 통계적 임계값과 지속적인 감시가 필요하다고 설명합니다. 모델·프롬프트 버전, 반복 횟수, 공격 성공 판정과 사람 평가 기준을 남기고 정상 요청 차단률도 함께 봐야 합니다. OWASP GenAI Red Teaming Guide 1.0, Key Differences

NIST는 정기적인 적대적 테스트 결과를 설계, 배포 go/no-go, 모니터링과 중단 결정에 반영하도록 권고합니다. NIST AI 600-1, MEASURE 4.2

자동 테스트는 많은 변형과 회귀 확인에 적합하고, 도메인 전문가와 일반 사용자는 실제 피해의 맥락을 찾는 데 유리합니다. NIST도 일반 사용자·전문가·혼합 팀·사람과 AI의 조합이 서로 다른 위험 탐색에 적합할 수 있다고 설명합니다. NIST AI 600-1, Appendix A.1.5

운영팀 체크리스트

준비와 탐지

시스템 담당자, 공급자, 모델·프롬프트·데이터 버전을 목록화했는가
사고 등급, 선언 권한, 중단 기준과 연락망이 있는가
도구 차단, 자격 증명 회수와 수동 폴백을 연습했는가
답변뿐 아니라 도구 호출과 외부 통신을 감시하는가

대응과 복구

입력·출력·검색 문서·정책 판정·도구 호출을 보존하는가
가장 작은 안전 단위부터 권한과 연결을 격리하는가
원래 공격과 변형 시나리오를 수정 후 다시 실행했는가

학습과 레드팀

근본 원인, 근접 사고와 실패한 통제를 기록했는가
발견 사례를 회귀 테스트와 경보에 추가하고 오탐도 측정하는가
권고마다 담당자, 기한과 완료 증거가 남는가

세 가지 한계

레드팀에서 공격을 찾지 못했다고 시스템이 안전하다고 말할 수는 없습니다. OWASP는 레드팀을 변하는 위협에 맞춰 반복하는 과정으로 설명하고, NIST도 보안 조치가 계속 유효한지 정기적으로 확인하도록 권고합니다. OWASP GenAI Red Teaming Guide 1.0 NIST AI 600-1, MS-2.7

평가 수치는 범위를 벗어나면 의미가 줄어듭니다. 특정 모델과 프롬프트의 성공률을 다른 권한과 데이터에 그대로 적용할 수 없으며 RAG나 커넥터가 달라져도 다시 확인해야 합니다.

공식 프레임워크도 동일한 의무 목록은 아닙니다. NIST Playbook은 산업, 사용 사례와 자원에 맞게 선택하는 자발적 지침이며 법적 신고 기준은 별도 검토가 필요합니다. NIST AI RMF Playbook

OpenAI의 Preparedness Framework는 모델 공급자가 역량 평가, 다층 보호와 배포 판단을 연결한 사례지만 일반 기업의 사고 대응을 대신하지는 않습니다. OpenAI Updated Preparedness Framework

다음 모의훈련에서는 작은 질문 하나로 시작해도 됩니다. “외부 문서 때문에 에이전트가 승인되지 않은 메일을 보내려 할 때, 10분 안에 어느 자격 증명을 누가 끊는가?” 담당자와 실제 차단 방법이 나오지 않는다면 레드팀 도구를 더 사기 전에 대응 문서부터 고칠 차례입니다.