Agent가 스스로 "이상하다"고 오판했다면, 대량 쓰기는 무엇이 막는가
← 전체 목차 · 이전: 파일 하나 읽고 함락된다 · 다음: Agent가 사내 시스템을 만지는데 "유출 금지"라고만 쓰면 될까
기업용 운영 Agent의 원래 설계는 단순했다: 고객 자료에 이상이 있을 때만 데이터 편집 도구를 호출한다. 그런데 사용자는 그냥 평범한 문의를 했을 뿐인데, 모델이 환각으로 "이 사용자 정보는 만료됐다"고 근거 없이 판단해버렸다. 판단은 곧바로 실행으로 이어졌다 — 데이터 편집 도구를 연속 호출해 정상 사용자 수천 건의 업무 태그를 통째로 뒤바꿨다. 권한 오류도 아니고 계층 오류도 아니다. 도구는 원래부터 이 Agent가 쓸 수 있는 도구였다. 무너진 것은 "이 도구를 지금 써도 되는가"를 가르는 업무 전제였다.
더 나쁜 것은 사고 이후다. Agent는 실행 결과를 바로 DB에 반영시켰고, 아무도 심사하지 않았고, 로그로 되짚을 수 없었고, 되돌릴 수단이 없었다. 실행 시점이 야간 무인 배치였다는 것까지 겹쳐, 오류는 아무도 지켜보지 않는 창구 안에서 조용히 굳어졌고 다음 날 업무 전체가 뒤틀린 채로 발견됐다.
사고 전개: 오판 1건이 업무 전체를 삼키는 경로
오판(사용자 1명, 근거 없음)
→ 편집 도구 연속 호출(권한은 원래 있었음)
→ 정상 사용자 수천 건의 태그 일괄 변경
→ 권한 등급·계층 태그 동시 오염
→ 후속 리포트·통계 전부 왜곡
→ 다음 날 업무 전면 오류, 원인 규명에 하루 소요
자동화는 증폭기이지 이득기가 아니다. 같은 자동화 능력이 옳은 판단 위에서는 효율이 되고, 틀린 판단 위에서는 재해가 된다. 이 사고에서 자동화가 증폭한 것은 "판단"이 아니라 "실행"이었다는 점을 놓치면 안 된다.
네 가지 사각지대
| # | 사각지대 | 이 사고에서의 실체 |
|---|
| 1 | 업무 전제 미검증 | "이상 시에만 편집"이라는 규칙이 문서·프롬프트에만 존재하고, 실행 전에 그 전제가 참인지 코드로 검증하는 장치가 없었다 |
| 2 | 배치 증폭 무방비 | 오판 1건이 반복 호출로 이어져도 이를 막는 건수·속도 임계값이 없었다 |
| 3 | 무인 시간대의 기본값이 평시와 동일 | 야간 자동 실행에 대해 승인 문턱을 더 높이는 별도 정책이 없었다 |
| 4 | 집행 후 관측·회수 불가 | 즉시 DB 반영, 무심사, 무로그, 무롤백 — 네 가지가 동시에 빠져 있어 사고를 발견하는 것조차 다음 날 사람이 리포트를 보고서야 가능했다 |
권한은 있었다 — 검증해야 했던 것은 "전제"였다
AGENT/16의 등급화, AGENT/45의 실행 전 검증은 모두 **"이 Agent가 이 도구를 쓸 자격이 있는가"**를 묻는다. 이 사고에서는 그 질문의 답이 이미 "예"였다 — 편집 도구는 원래 이 Agent의 권한 범위 안에 있었다. 진짜 구멍은 한 단계 더 위에 있다: **"이번 호출의 전제로 모델이 댄 근거(사용자 정보가 이상하다)가 실제로 참인가"**라는, 권한과는 별개의 사실 검증이다.
권한 검증(AGENT/16, 45) : 이 Agent가 이 도구를 쓸 수 있는가? → 예/아니오
전제 검증(이 문서) : 이번 호출의 근거가 실제 데이터와 맞는가? → 예/아니오
두 검증은 독립적으로 실패할 수 있다. 권한은 맞는데 전제가 거짓인 이번 사고가 그 증거다. 그래서 권한 체계를 아무리 정교하게 짜도 전제 검증이 없으면 이런 사고는 다시 난다.
① 전제 이중 검증: 모델은 제안하고, 규칙은 근거를 대조한다
편집류 도구를 호출할 때 모델은 파라미터만 넘기는 것이 아니라 판단 근거를 구조화 필드로 함께 제출해야 한다 — "왜 이상하다고 판단했는가", "어느 필드가 어떤 값이라서 이상인가". 규칙 엔진은 이 근거를 실제 데이터와 대조해, 근거가 실제와 맞지 않으면 실행 전에 드랍한다. 모델의 자연어 확신은 승인 사유가 되지 못하며, 판정 권한은 언제나 결정론적 규칙 쪽에 있다.
② 배치 임계값 기반 자동 회로차단
단일 작업 안에서 연속 쓰기 건수·속도를 실시간 집계
↓
사전 정의 임계값 초과 (예: 동일 작업에서 N건 초과 수정)
↓
즉시 작업 전체 중단 + 이상 큐 등록 + 담당자 경보
↓
이미 실행된 건은 남기되, 남은 배치는 진행하지 않는다
단발성 오판은 피해가 제한적이지만, 같은 오판이 반복 실행으로 이어질 때 재해가 된다. 배치 규모 자체를 이상 신호로 취급하는 이 장치가 없으면, 개별 호출은 매번 "정상적인 도구 호출"로 보여 그 무엇도 걸리지 않는다.
③ 무인 시간대는 기본값을 별도로 낮춘다
야간·무인 배치 창구에서는 편집류 임계값을 평시보다 대폭 낮추거나, 편집을 아예 승인 대기 상태로 큐잉만 하고 사람이 출근한 뒤 일괄 검토하게 한다. 사람이 지켜보지 않는 시간에 되돌릴 수 없는 쓰기가 조용히 쌓이는 것이 이 사고의 핵심 조건이었다.
④ Agent 규칙·도구 변경은 카나리로 반영한다
Agent의 판단 규칙이나 도구가 바뀔 때마다 전량에 바로 올리지 않는다. 소량 트래픽으로 먼저 흘려 위반율·데이터 이상률을 관찰하고, 지표가 안정적일 때만 전량 반영한다. 이번 사고를 일으킨 판단 로직 자체가 배포 시점부터 카나리를 거쳤다면, 소량 구간에서 이미 이상 신호가 잡혔을 가능성이 높다.
이 문서와 인접 문서의 경계
- AGENT/16 · AGENT/45 — "이 Agent가 이 도구를 쓸 자격이 있는가"를 다룬다. 이 문서는 자격이 있다고 전제한 뒤, "이번 호출의 근거가 사실인가"를 검증한다.
- AGENT/47 — 실행 환경의 파괴 반경을 제한하는 백스톱을 다룬다. 이 문서는 환경이 아니라 업무 데이터 쓰기 자체의 사전·사중 통제를 다룬다.
- 도구 호출 원자성과 Saga 롤백 · 도구 호출 절대 멱등성 — 이미 실행된 다단계 쓰기를 어떻게 되돌리고 중복을 막는지의 메커니즘을 다룬다. 이 문서는 그 이전 단계, 애초에 잘못된 대량 실행이 시작되지 않게 막는 것에 집중한다.
핵심 통찰
- 권한 검증과 전제 검증은 서로 다른 질문이며, 하나가 맞아도 다른 하나는 얼마든지 틀릴 수 있다 — "이 도구를 쓸 자격이 있는가"를 아무리 정교하게 설계해도 "이번 호출의 근거가 사실인가"를 검증하지 않으면, 권한 체계가 완벽한 상태에서도 대량 오사고가 난다. 이 사고의 근본 교훈은 권한 모델을 더 촘촘히 짜는 것이 아니라 검증해야 할 층을 하나 더 인식하는 것이다.
- 자동화는 판단의 옳고 그름을 가리지 않고 결과를 증폭한다 — 같은 반복 실행 능력이 옳은 판단 위에서는 생산성이고 틀린 판단 위에서는 재해다. 그래서 자동화 수준을 높이려면 판단 오류율을 낮추는 노력과 동시에 오류가 집행됐을 때의 폭발 반경을 제한하는 장치가 함께 올라가야 한다.
- 모델의 확신은 근거가 아니라 검증 대상이다 — 모델이 "이상하다"고 판단한 그 진술 자체를 승인 사유로 삼으면, 모델이 틀리는 순간 그 오류가 그대로 집행된다. 판단의 근거를 구조화해 실제 데이터와 대조하는 별도 관문이 있어야, 모델의 착각이 실행으로 이어지는 경로가 끊긴다.
- 배치 규모는 그 자체로 리스크 신호다 — 단발 오판은 견딜 수 있어도, 같은 오판이 반복 호출로 증폭되면 재해가 된다. 개별 호출을 아무리 안전하게 설계해도 "얼마나 많이, 얼마나 빨리"를 보는 배치 차원의 임계값이 없으면 증폭 경로가 열려 있는 것과 같다.
- 무인 시간대는 리스크 허용치가 아니라 리스크 승수다 — 사람이 지켜보지 않는 창구에서 되돌릴 수 없는 쓰기가 쌓이면 발견 자체가 지연된다. 평시와 같은 기본값을 야간·무인 배치에 그대로 적용하는 것은 감독이 가장 약한 순간에 가장 위험한 동작을 허용하는 것과 같다.
- 관측 불가와 회수 불가는 사고를 키우는 것이 아니라 사고를 "발생"시킨다 — 오판 자체는 언젠가 일어난다. 그러나 즉시 DB 반영·무심사·무로그·무롤백이 겹치면 오류를 잡을 수 있는 마지막 네 개의 관문이 동시에 사라진다. 사고의 크기를 결정한 것은 오판의 확률이 아니라 이 네 관문의 부재였다.
- 변경은 전량 반영 전에 소량으로 관찰돼야 한다 — Agent의 판단 규칙이나 도구가 바뀔 때마다 카나리 없이 전량에 올리면, 이번처럼 로직 자체의 결함이 전면 사고로 번지고 나서야 발견된다. 위반율·이상률을 소량 구간에서 먼저 보는 것이 사고를 최소 비용으로 걸러내는 마지막 기회다.
엔지니어링 실전 Tips
- 편집류 도구 호출에는 "판단 근거" 필드를 강제할 것: 파라미터만 받지 말고 왜 이 판단을 했는지를 구조화된 근거로 함께 받아, 규칙 엔진이 실제 데이터와 대조할 수 있게 할 것.
- 작업 단위 배치 임계값을 코드에 하드 세팅할 것: 동일 작업에서 연속 편집 건수가 임계값을 넘으면 남은 배치를 자동 중단하고 이상 큐에 등록. 임계값은 업무팀과 함께 정하고 변경 이력을 남길 것.
- 무인 시간대 전용 정책을 따로 둘 것: 야간·배치창에서는 편집류 임계값을 낮추거나 승인 대기 큐잉으로 전환. "사람이 없을 때는 더 신중하게"를 코드로 강제할 것.
- DB 반영 직전에 스냅샷 한 장을 남길 것: 대량 쓰기 전 영향받는 레코드의 스냅샷을 저장해 두면, 이후 원자성·롤백 메커니즘(도구 호출 원자성과 Saga 롤백)과 바로 연결된다.
- 모든 편집 호출의 입력 근거와 결과를 감사 로그에 남길 것: "무엇을 했는가"가 아니라 "왜 그렇게 판단했는가"까지 남아야 사후에 재현하고 규칙을 고칠 수 있다.
- 규칙·도구 변경은 반드시 카나리를 거칠 것: 소량 트래픽에서 위반율·데이터 이상률을 관찰한 뒤 전량 반영. 이 단계를 생략하는 것이 대형 사고의 가장 흔한 전제조건이다.
- "실행 성공"과 "판단이 옳았음"을 같은 로그 레벨로 섞지 말 것: 성공률 지표만 보면 근거가 틀린 채로 성공한 호출이 그대로 숨는다. 판단 근거의 정확도는 별도 지표로 추적해야 한다.