30초 답변
생성형 AI 사고는 기존 서비스 장애 절차로 대응하되 모델, prompt, 검색 index, Tool, 데이터 권한을 각각 독립적인 변경 단위로 다뤄야 한다. 먼저 사용자와 외부 시스템에 미치는 영향을 줄이고, release ID와 trace를 보존한 뒤, 문제가 된 경로를 차단하거나 읽기 전용·사람 승인 모드로 낮춘다.
복구가 끝나면 사고 입력을 그대로 보관하는 데 그치지 말고 민감정보를 제거한 재현 사례를 평가셋, guardrail, 알림, Runbook에 반영한다. 같은 실패가 다음 배포에서 자동으로 걸러져야 사고 대응이 학습으로 끝난다.
이 글의 핵심
- 모델 장애, 잘못된 답변, 권한 누출, Tool 오작동, 비용 폭증을 같은 severity 체계로 관리한다.
- 전체 서비스를 끄는 것 외에 Tool 차단, 읽기 전용, 승인 강화, 이전 index 전환 같은 부분 격리가 필요하다.
- 원인 분석 후 재현 사례를 평가와 모니터링 자산으로 바꾼다.
AI 사고의 범위
다음은 모두 사고가 될 수 있다.
- 민감 문서나 개인정보 노출
- prompt injection으로 승인되지 않은 Tool 실행
- 잘못된 정책 답변의 대규모 확산
- 특정 사용자 권한을 넘는 retrieval
- 모델·provider 장애로 서비스 중단
- index 업데이트 실패로 오래된 답변 제공
- 출력 schema 오류로 downstream 시스템 오작동
- 재시도 loop와 token 사용 급증
- 사람이 취소했는데 외부 작업은 계속 실행
- 안전 필터 오탐으로 핵심 업무가 전부 막힘
정확도 문제와 보안 문제를 완전히 분리하지 않는다. 잘못된 답변이 실제 결재·주문·고객 통지로 이어지면 운영 사고다.
사고 전 준비해야 할 것
Release manifest
한 시점의 운영 조합을 재현할 수 있어야 한다.
- model과 provider
- system·developer prompt
- policy와 guardrail
- Tool schema와 버전
- retrieval 설정
- index·embedding·reranker
- feature flag
- 배포 시간과 승인자
Trace와 감사로그
사용자 요청부터 Tool 결과까지 연결하되 민감 원문은 마스킹과 접근 통제를 적용한다. 쓰기 Tool은 누가 어떤 권한으로 어떤 변경을 승인·실행했는지 별도 audit trail을 남긴다.
Kill switch와 저하 모드
- 특정 Tool 비활성
- 쓰기 금지·읽기 전용
- Agent를 Q&A로 축소
- 자동 실행을 사람 승인으로 전환
- 특정 corpus·tenant 격리
- 이전 index alias로 전환
- provider fallback
- 전체 기능 중지
사고 중 처음 설계하지 말고 정기적으로 연습한다.
Severity 예시
조직의 기존 사고 등급에 AI 기준을 추가한다.
| 등급 | 예시 | 초기 행동 |
|---|---|---|
| Critical | 민감정보 외부 노출, 무단 고위험 실행 | 즉시 경로 차단, 보안·법무 호출, 증거 보존 |
| High | 다수 사용자의 권한 오류, 잘못된 대량 실행 | 영향 기능 격리, 쓰기 중단, rollback |
| Medium | 특정 업무 품질 급락, 반복 timeout | traffic 축소, 이전 release 전환 검토 |
| Low | 소수 표현 오류, 경미한 UX 문제 | ticket, 평가셋 추가, 정기 배포 |
수치 임계값과 보고 의무는 조직의 서비스·계약·법적 요구에 맞춰 승인받는다.
대응 순서
1. 탐지와 분류
경보 또는 사용자 신고를 받으면 먼저 다음을 확인한다.
- 보안, 개인정보, 무단 실행인가
- 현재도 영향이 계속되는가
- 어떤 tenant·사용자·업무·release인가
- 읽기 응답인가 실제 시스템 변경인가
- 재현을 시도하면 피해가 커지는가
민감 사고는 운영자가 임의로 원문을 복사해 협업 도구에 붙이지 않는다.
2. 영향 차단
가장 작은 안전 경계를 우선 격리한다.
- 문제 Tool만 off
- 해당 index·tenant 차단
- 자동 승인을 수동 승인으로 전환
- 긴 작업의 새 시작 중단
- 위험 응답을 정적 안내와 사람 이관으로 교체
데이터 유출이나 무단 실행 위험이 있으면 가용성보다 확산 방지가 우선이다.
3. 증거 보존
- incident ID
- release manifest
- trace ID
- 관련 사용자·tenant의 익명 식별자
- 최초 탐지 시간과 마지막 정상 시간
- model·prompt·Tool·index 버전
- 승인과 실제 외부 시스템 변경
- 경보·대시보드·배포 이벤트
보존은 최소 필요 범위와 승인된 저장소를 사용한다. 개인정보와 비밀정보 접근을 감사한다.
4. 원인 가설과 복구
모델을 무조건 원인으로 보지 않는다.
- prompt 변경
- Tool description·schema 변경
- 권한 metadata 누락
- index alias 전환 실패
- cache 오염
- provider 응답 형식 변경
- UI의 승인 상태 불일치
- retry의 idempotency 오류
가장 최근 변경을 기준으로 후보를 좁히되 증거 없이 단정하지 않는다. 이전 release 조합으로 rollback하고 영향이 멈추는지 확인한다.
5. 검증 후 재개
- 사고 재현 사례 통과
- 전체 회귀 평가 통과
- 권한·안전 P0 사례 통과
- 쓰기 Tool dry run
- canary
- 모니터링과 담당자 대기
복구 속도를 이유로 안전 평가를 생략하지 않는다.
6. 커뮤니케이션
상태 메시지는 확인된 사실, 영향, 임시 조치, 다음 업데이트 시간을 구분한다. 모델이 틀렸다는 모호한 설명보다 어떤 기능과 데이터가 영향받았는지 말한다. 외부 통지와 법적 의무는 보안·법무 책임자의 절차를 따른다.
Prompt injection 사고의 특별한 점
OWASP는 Prompt Injection을 주요 LLM 위험으로 분류하며 직접 입력뿐 아니라 문서·웹페이지·Tool 결과 안에 숨은 간접 지시도 다룬다.
사고 대응 시 확인:
- 공격 지시가 들어온 원본
- model이 지시와 데이터를 구분했는지
- 어떤 Tool과 권한이 노출됐는지
- 출력 검증과 승인 단계가 있었는지
- 같은 문서가 cache·index에 남았는지
- 공격 입력이 다른 사용자에게 재사용되는지
단순히 공격 문구를 blocklist에 추가하는 것으로 끝내지 않는다. 최소 권한, 신뢰 경계, Tool 승인, 출력 검증을 함께 수정한다.
사후 분석
비난보다 시스템 학습에 집중한다.
- 타임라인
- 사용자·데이터·외부 시스템 영향
- 직접 원인과 기여 요인
- 탐지가 늦은 이유
- 격리·복구가 어려웠던 이유
- 잘 작동한 통제
- 단기·장기 개선
- 담당자와 기한
NIST AI RMF와 생성형 AI 프로필은 AI 위험을 지속적으로 식별·측정·관리·거버넌스하는 관점을 제공한다. Runbook은 일회성 문서가 아니라 이 순환의 운영 도구다.
사고를 평가 자산으로 바꾸기
- 민감정보를 제거한 재현 입력
- 기대되는 거절·승인·검색·Tool 동작
- 규칙 검사와 grader
- 배포 게이트
- 온라인 경보
- 사용자 안내 문구
같은 종류의 실패가 다시 생기면 배포 전에 또는 더 작은 영향에서 감지되어야 한다.
실무 체크리스트
- AI 사고 유형과 severity가 기존 사고 체계에 포함된다.
- model·prompt·Tool·index를 묶은 release manifest가 있다.
- Tool별 kill switch와 읽기 전용 모드가 있다.
- 사람 승인 강화와 전체 이관 모드가 있다.
- trace와 쓰기 audit trail이 연결된다.
- 민감 증거의 접근·보존·삭제 절차가 있다.
- rollback 단위와 담당자가 문서화되어 있다.
- 복구 전 P0 평가와 canary를 실행한다.
- 사고 사례가 eval·guardrail·알림으로 반영된다.
- 정기 tabletop 또는 장애 훈련을 한다.
자주 묻는 질문
잘못된 답변도 보안 사고인가?
항상 그런 것은 아니다. 그러나 의료·재무·정책 판단이나 외부 시스템 실행처럼 실제 피해 가능성이 있으면 높은 운영·안전 사고로 다뤄야 한다.
사고가 나면 먼저 모델을 바꾸면 되나?
아니다. prompt, retrieval 권한, Tool, cache, UI 승인 상태가 원인일 수 있다. 먼저 영향 차단과 증거 보존을 하고 release 구성요소별로 확인한다.
모든 AI 기능을 끄는 것이 가장 안전하지 않나?
즉시 확산을 막아야 할 때 전체 중지가 필요할 수 있다. 평소에는 Tool 비활성, 읽기 전용, 특정 tenant 격리처럼 작은 경계를 준비해야 불필요한 전체 중단을 줄일 수 있다.