가장 위험한 노드는 자동 승인이었다 - 조용한 과신을 뺄셈으로 잡는 법

앞 노드가 흔들렸는데 뒤 노드가 더 확신하면 경보가 뜬다. 그 뺄셈 하나가 3.6점짜리 노드를 4.9로 올린다. 법무 계약 검토와 한국 신용 심사를 같은 채점표로 돌렸더니 자동 승인 노드와 자동 심사 결정 노드가 최고점에 몰렸다. 왜 이 노드가 세 방향에서 동시에 위험한지, 오류 없이 진행되는 실패를 어떤 계산으로 잡는지, 그리고 색이 빨간 것과 사람에게 넘어가는 것이 왜 다른 사건인지 적는다.

2편에서 36셀 채점표와 실행 중에 핸드오프 점수가 올라가는 구조를 정리했다. 이 글은 그 표로 실제 워크플로를 돌렸을 때 나온 결과다.

최고점 두 개가 같은 자리에 있었다

법무 계약 검토와 신용 심사는 도메인도 규제도 노드 구성도 다르다. 그런데 최고점 노드는 둘 다 같은 성격이었다.

세 값이 소수점까지 같다. 우연이 아니라 두 노드가 같은 이유로 높다.

일반 실패 축이 높은 건 결과가 되돌아오지 않아서다. 조항 추출 노드가 조항 하나를 빠뜨리면 다음 노드에서 잡힐 가능성이 남지만, 자동 승인이 잘못 나가면 계약은 이미 체결됐고 대출은 이미 실행됐다. 같은 오류율이라도 회복 가능성이 다르면 점수가 달라야 한다.

보안 축이 높은 건 권한 범위 때문이다. 이 노드는 사람 확인 없이 외부에 영향을 미치는 동작을 실행할 권한을 갖는다. OWASP LLM Top 10의 과도한 권한 항목이 지목하는 형태이고, 워크플로 전체에서 이 조건을 만족하는 노드는 대개 한둘이다.

핸드오프 축이 높은 건 이 노드가 게이트를 지나가는 방식 때문이다. 앞 노드의 임계 판정이 조용한 관문이 되는데, 그 판정의 근거는 하류로 전달되지 않는다. 감사 기록에 “자동 승인됨”이라는 도장만 남으면 나중에 되짚을 수 없다.

낮은 노드와 나란히 놓으면

최고점이 의미를 가지려면 낮은 쪽도 봐야 한다. 법무 계약 검토의 접수·분류 노드는 3.4, 3.0, 3.4다. 세 축 모두 자동 승인 노드보다 1점 이상 낮다.

이 노드도 오작동한다. 계약서 종류를 잘못 분류하면 뒤 단계가 엉뚱한 플레이북을 쓴다. 그런데 점수가 낮은 이유가 셋이다. 오류가 하류에서 드러날 여지가 남아 있고, 권한이 읽기와 태깅에 그치며, 잘못된 분류는 결과물에 눈으로 보인다. 되돌릴 수 있고, 좁고, 조용하지 않다.

이 세 열이 곧 채점 기준이다. 위험을 오류율로만 재면 자동 승인 노드는 오히려 안전해 보인다. 규칙이 간단하고 입력도 정형이라 실제 오작동 빈도는 낮을 수 있다. 빈도가 아니라 되돌릴 수 있는지, 권한이 얼마나 넓은지, 실패가 보이는지로 재면 순서가 뒤집힌다.

조용한 과신을 뺄셈으로 잡는다

이 노드들의 실패가 곤란한 건 결과가 나쁘다는 게 아니라 실패하는 동안 아무 신호도 안 난다는 데 있다. 그래서 “조용하다”를 계산 가능한 값으로 바꿔야 했다.

방법은 뺄셈이다. 뒤 노드의 확신도에서 앞 노드의 확신도를 뺀다.

decay = downstream_conf - upstream_conf
over_trust = max(0.0, decay) if upstream_conf < 0.8 else 0.0
if over_trust > 0.2:
    band, alert = "over_trust_alert", True

앞 노드가 0.8 아래로 미덥지 않았을 때만 그 차이를 센다. 차이가 0.2를 넘으면 경보다. 앞이 흔들렸는데 뒤가 더 확신했다는 뜻이고, 이게 오류 없이 진행되는 실패의 모양이다. 반대 방향도 본다. 앞이 0.9를 넘게 확신했는데 뒤가 그만큼 못 받으면 과소 활용 경고가 뜬다.

확신도 자체를 한 신호로 만들지 않은 것도 이유가 있다. 토큰 로그 확률에서 뽑은 값 0.3, 모델에게 직접 물어 받은 자기 보고 0.3, 도구 호출이 정상 종료하고 구조화된 출력을 냈는지 0.2, 타임아웃까지 얼마나 갔는지 0.2를 가중합한다. 로그 확률 하나에 기대면 그 하나가 흔들릴 때 지표 전체가 흔들린다.

여기에 지표 둘이 더 붙는다. 앞 노드 출력과 뒤 노드 진단을 임베딩해 코사인 유사도를 재는 의도 보존 점수는 0.5 미만이면 맥락 소실 경보이고, 별도 언어 모델이 앞뒤 출력의 정렬을 채점하는 판정 지표는 0.6 미만이면 사람 검토 신호다. 판정 지표는 기본 백엔드가 모의값이라 실제 판정을 돌리려면 따로 지정해야 한다.

실제 사고가 이 모양이다

2026년에 확인된 사고 중 두 건이 이 형태를 그대로 보여준다.

아마존웹서비스의 코딩 에이전트가 라이브 환경을 삭제하고 재생성한 사건에서 에이전트는 오류를 낸 게 아니라 자기가 판단한 대로 실행했다. 사람이 개입할 지점이 없었다. 아마존은 원인이 AI가 아니라 잘못 설정된 접근 권한이라고 반박했는데, 그러면서 내놓은 사후 조치는 AI 보조 변경 작업에 시니어 엔지니어 승인 절차를 붙이는 것이었다. 완화책이 게이트 추가였다는 사실이 원인이 권한 범위였다는 걸 보여준다.

두 번째가 더 곤란하다. 아마존 리테일에서 내부 지침을 꺼내주는 AI 에이전트가 오래된 참조를 물어왔고, 그 조언을 받은 사람이 그대로 움직여 3월 한 주에 고심각도 사고 네 건이 났다. 하나는 여섯 시간 이어졌다. 여기서는 사람이 루프 안에 있었다. 사람이 있었는데도 안 막혔다.

---
config:
  look: handDrawn
  theme: neutral
---
flowchart LR
    A["앞 노드<br/>확신도 0.55"] -->|"오류 없음"| B["뒤 노드<br/>확신도 0.85"]
    B -->|"과신 격차 0.30"| C["경보 · 핸드오프 +0.5"]
    C --> D["자동 승인 게이트"]
    D -->|"도장만 기록"| E["감사 로그"]

사람이 체인 마지막에 있어도 같은 일이 벌어진다. 사람은 앞선 판단들을 근거로 보고, 그 근거의 근거는 확인하지 않는다.

여기에 붙는 법적 선례가 둘이다. 하나는 2024년 2월 브리티시컬럼비아 민사분쟁해결심판소의 Moffatt v. Air Canada 판결이다. 챗봇이 안내한 요금 정책이 실제와 달랐고, 항공사는 챗봇이 별개 주체라는 취지의 주장을 했지만 받아들여지지 않았다.

더 최근 것이 2026년 5월 12일 독일 함 고등법원 판결이다. 회사가 챗봇에 올바른 데이터를 공급했음을 입증하더라도 출력에 대한 책임은 회사에 귀속된다는 취지다. 입력을 제대로 넣었다는 항변이 통하지 않는다는 뜻이라 앞의 판결보다 한 걸음 더 나간다. 자동으로 나간 판단의 책임은 자동화했다는 이유로도, 입력이 옳았다는 이유로도 줄지 않는다. 그러면 남는 문제는 그 판단이 왜 그렇게 내려졌는지를 나중에 설명할 수 있느냐인데, 도장만 남긴 감사 기록으로는 설명이 안 된다.

공격자가 없는 쪽이 다수다

이 사례들에는 공통점이 하나 더 있다. 공격자가 없다.

수집한 2026년 사고 여섯 건 중 다섯 건이 그랬고, Cyera가 정리한 344건의 기업 사례 중에서도 188건이 그랬다. 손해는 에이전트가 시킨 일을 사람이 개입할 수 있는 속도보다 빠르게, 되돌릴 수 없을 만큼 넓은 권한으로 수행하면서 났다.

이 관찰이 채점표를 한 번 흔들었다. 과도한 권한을 보안 축에 둔 근거는 OWASP와 MITRE ATLAS인데 둘 다 적대자를 전제한다. 공격자 없는 사고가 다수라면 이 셀의 완화책이 적대적 통제 쪽으로 잘못 배정될 수 있다. 축을 옮기는 대신 해당 셀에 공격자 없음 표시를 달고 완화안을 권한 범위와 게이트 쪽으로 정렬했다.

3.6점 노드가 4.9로 올라가는 계산

신용 심사 워크플로를 돌리면 실행 조건에 따라 결과가 달라진다. 이 차이가 이 채점표에서 가장 볼 만한 부분이다.

임베딩 모델이 없는 환경에서 돌리면 런타임 지표가 계산되지 않는다. 온톨로지 조회만 남고, 최종 점수는 축 평균에 가중치를 곱한 값이 된다.

최고 4.76, RED 세 개다.

지표를 켜고 돌리면 달라진다. 신용 평점 노드에서 의도 보존 경보와 과신 경보가 뜨고 판정 점수가 0.6 아래로 떨어지면 가산이 0.5 더하기 0.5 더하기 0.3, 합쳐서 1.3이다. 핸드오프 축이 3.6에서 4.9로 오르고 최종 점수가 이렇게 된다.

handoff = min(5.0, 3.6 + 1.3) = 4.9
final   = 0.4 × 4.9 + 0.3 × 3.4 + 0.3 × 3.6 = 4.06   → RED

세 축 원점수가 전부 3점대인 노드가 RED로 넘어온다. 온톨로지만 보면 평범한 노드인데, 이번 실행에서 앞뒤 노드 사이가 실제로 어긋났기 때문이다. 자동 심사 결정 노드도 가산이 붙어 핸드오프가 5.0 상한에 닿으면 최종이 4.88로 올라간다.

정리하면 같은 워크플로가 축소 모드에서 최고 4.76에 RED 세 개, 전체 모드에서 최고 4.88에 RED 네 개로 나온다. 표는 노드 유형만 알고, 이번 실행에서 무슨 일이 있었는지는 지표가 안다.

위 계산은 가산표에 있는 조합을 그대로 대입한 것이다. 실행 화면에 찍힌 값이 어느 조합에서 나왔는지는 로그를 따로 봐야 알 수 있고, 화면만으로는 되짚을 수 없다. 진단 결과에 어느 지표가 몇 점을 올렸는지를 함께 적어 두지 않으면 나중에 그 점수를 설명하지 못한다는 뜻이라, 이건 이 도구 자신에게 걸리는 지적이기도 하다.

색이 빨간 것과 사람에게 가는 것은 다르다

게이트를 설계할 때 보통 나오는 질문은 “누가 승인하나”다. 그런데 위 사례들이 보여주는 문제는 승인자가 아니라 언제 사람에게 넘어가느냐다.

그래서 게이트 조건을 담당자 판단이 아니라 계산 결과가 정하게 만들었다. 조건은 넷이고, 하나라도 걸리면 사람에게 간다.

여기서 눈여겨볼 것은 색 밴드와 게이트 임계가 다르다는 점이다. 노드가 빨갛게 칠해지는 기준은 4.0이고 사람에게 넘어가는 기준은 4.5다. 앞의 계산에서 신용 평점 노드는 4.06으로 RED가 됐지만 게이트는 넘지 않는다. 히트맵에는 위험하다고 뜨는데 승인 화면은 안 만들어진다. 자동 심사 결정 노드가 4.88로 게이트를 발화시킨다.

이 간격이 실무에서 필요하다. 색이 곧 에스컬레이션이면 노란색과 빨간색 사이의 노드들이 전부 사람에게 올라가고, 그러면 승인 화면이 흔해져서 아무도 안 읽는다. 보이는 것과 멈추는 것을 분리해야 게이트가 게이트로 남는다.

그리고 점수만 게이트를 여는 게 아니다. 최종 점수가 4.5에 못 미쳐도 어느 노드 쌍에서 과신 격차가 0.2를 넘으면 그것만으로 사람에게 간다. 노드 각각은 괜찮은데 이음매가 어긋난 경우를 잡기 위한 조건이다.

게이트가 있는 조직이 열에 넷도 안 된다

이 설계가 실제로 필요한지는 현장 조사로 확인된다. 클라우드 시큐리티 얼라이언스와 Token Security가 2026년 4월에 418개 조직을 대상으로 물었더니, 에이전트가 권한 범위를 벗어날 때 사람 승인을 요구하는 곳은 38%였다. 무단 액션을 자동으로 차단하는 곳은 11%다.

앞에서 본 사고들과 겹쳐 보면 그림이 맞는다. 아마존웹서비스 사례의 사후 조치가 승인 절차 추가였고, 검증된 사고의 절반 이상에 공격자가 없었다. 필요했던 건 방어가 아니라 게이트인데 열 곳 중 여섯 곳에 그게 없다. 게이트를 붙이기로 한 조직도 어디에 붙일지는 따로 정해야 하고, 이 채점표가 답하려는 게 그 질문이다.

승인자가 실제로 쥐는 선택지

게이트가 발화하면 승인 화면이 만들어진다. 함께 가는 것은 워크플로 이름, 최고 위험 점수, 임계 초과 노드 수, 사람에게 온 사유, 한 장짜리 요약이다. 사유 문자열에는 어느 조건이 걸렸는지가 그대로 들어간다. “과신 격차 0.30이 임계 0.2를 넘음” 같은 문장이다. 승인자가 히트맵 전체를 다시 읽고 판단하게 두면 게이트가 형식이 된다.

선택지는 셋이다. 그대로 승인하면 프로세스가 원래 경로로 재개되고 승인 판단과 그 시점의 진단 결과가 함께 기록된다. 조건부 승인은 필수 완화안을 적용하는 조건을 붙여 통과시키는 것이고, 반려는 워크플로 설계를 고쳐 다시 제출하게 하는 것이다.

실무에서 가장 자주 쓰일 것은 조건부 승인이다. 배포 일정이 잡힌 상태에서 반려는 부담이 크고 그대로 승인은 게이트를 세운 의미가 없다. 그래서 필수 단에 무엇을 넣느냐가 이 게이트의 실효를 정한다. 필수 단이 길면 조건부 승인이 사실상 반려가 되고, 비어 있으면 게이트가 형식이 된다. 자동 승인 노드의 핸드오프 셀에서 필수 단을 하나로 유지한 이유가 여기 있다. 그 하나는 자동 승인 기록에 판단 근거를 영구 보존하는 것이다.

검토자 위축은 아직 측정하지 못한다

선택 단에 들어간 검토자 순환은 근거가 가장 약하다. 자동 승인 비율이 올라갈수록 사람 검토자가 실사례를 다루는 빈도가 줄고 그만큼 실제 검토 역량이 떨어진다는 가설인데 공개 선례를 찾지 못했다.

측정이 어려운 건 이 현상이 사고로 기록되지 않기 때문이다. 사고가 났을 때 사람이 못 잡았다는 결과로만 드러나고, 그때 원인은 검토자 개인의 실수로 적힌다. 자동화 비율과 검토 품질의 관계를 재려면 자동 승인된 건을 표본으로 뽑아 사람에게 다시 돌리고 정확도를 비교하는 절차가 있어야 하는데, 그런 절차를 갖춘 조직을 자료에서 찾지 못했다.

근거가 약하니 필수 단에 올리지 않았다. 항목 자체를 지우지도 않았다. 표에서 지우면 다음 갱신 때 다시 발견해야 하고, 선택 단에 남겨 두면 근거가 생겼을 때 올리기만 하면 된다.

배포 전 점검이 볼 수 없는 것

이 채점표는 설계 시점의 구조를 읽는다. 노드가 어떤 권한을 갖는지, 어디에 게이트가 있는지, 결과가 되돌아오는지. 반대로 실행 중에만 드러나는 것은 못 본다.

에이전트 실패를 찾는 법 시리즈에서 정리한 궤적 단위, 구간 단위, 주장 단위의 실패 위치 추정은 전부 실행 후 기록을 대상으로 한다. 어떤 호출에서 처음 어긋났는지 찾으려면 그 호출이 일어났어야 한다.

둘은 서로를 대체하지 않는다. 설계에 게이트가 없다는 건 실행 기록 없이도 읽히고, 게이트가 있는데 사람이 그대로 통과시킨다는 건 실행 기록에서만 읽힌다. 앞의 예에서 아마존웹서비스 사례는 앞쪽에서, 아마존 리테일 사례는 뒤쪽에서 잡힌다. 런타임 지표를 진단 안에 넣은 것도 그 경계를 조금 밀어 본 것이다. 배포 전 점검이 실행 신호를 일부 끌어와 쓰는 셈이다.

마무리 - 값이 가장 큰 자리가 위험도 가장 크다

두 워크플로에서 최고점이 같은 노드에 찍힌 건 채점표가 그렇게 설계돼서가 아니다. 세 축을 각각 다른 근거로 매겼는데 같은 노드에서 만났다.

그 노드가 자동화의 값이 가장 큰 자리이기도 하다. 사람 검토를 한 단계 빼면 처리량이 오르고 비용이 내려간다. 그래서 자동화 프로젝트는 대개 이 노드를 목표로 잡는다. 같은 이유로 이 노드는 되돌릴 수 없는 결과를 만들고, 넓은 권한을 갖고, 근거를 남기지 않은 채 통과한다.

자동화하고 싶은 자리와 게이트를 세워야 하는 자리가 겹치는 것이 이 문제의 구조다. 그래서 게이트를 다느냐 마느냐를 논의로 두면 대개 안 다는 쪽으로 기운다. 계산이 정한 임계로 자동 발화하게 만들면 논의 자체가 없어진다.

남은 것은 그 게이트를 어디에 걸 것인가다. 진단 코드 안에 조건문으로 넣으면 게이트는 코드가 되고, 프로세스 정의 안에 두면 게이트는 그림이 된다. 둘의 차이는 생각보다 크다.

출처

• AI Incident Database, 사건 1442번 (AWS Kiro), 사건 639번 (Moffatt v. Air Canada)
• Fortune, 2026-03-12 보도 (아마존 리테일 내부 에이전트 관련 고심각도 사고 4건)
• Cloud Security Alliance · Token Security, 에이전트 거버넌스 현황 조사 (2026-04, n=418)
• Cyera, Agent-Inflicted Damage: Inside the Real-World Failures of Enterprise AI Systems
• OWASP, Top 10 for LLM Applications 2025 중 과도한 권한 항목
• Moffatt v. Air Canada, 2024 BCCRT 149 (2024-02)
• 점수 계산 scripts/agents/aggregator.py, 게이트 조건 scripts/core/tools.py (evaluate_hitl), 임계 scripts/core/contracts.py (공개 저장소)