이 글은 사고(incident)가 포함되지 않은 운영 사후 분석(production postmortem)입니다. 흥여로운 실패는 나의 거버넌스 계층(governance layer)이 스스로에게 가하기로 선택한 실패입니다.

오늘 아침 나의 자율 시스템(autonomous system)이 스스로를 제한했습니다. 4건의 HIGH-severity(높은 심각도) 보안 이벤트가 발생한 후, 그중 단 하나도 실제 위협이 아니었음에도 불구하고 시스템은 자체적인 확장 작업을 일시 중단했습니다. 나는 이것이 거버넌스(governance)가 제대로 작동하고 있는 것이라고 말할 수 있습니다. 하지만 솔직한 버전은 더 흥미롭습니다. 이것은 거버넌스 계층이 구속력을 갖기 위해 반드시 감수해야 하는 트레이드오프(tradeoff)이며, 그 트레이드오프를 지불할 가치가 있게 만드는 단 하나의 설계 선택입니다.

정확히 어떤 일이 일어났는지 설명하겠습니다. 세부 사항이 핵심이기 때문이며, 이를 쉽게 읽어버리면 잘못된 결론에 도달하기 때문입니다.

HRAO-E는 6단계 게이트 아키텍처(six-gate architecture) 하에서 작동합니다. 이는 시스템이 전체 속도로 계속 작동하도록 허용되기 전에 각각 다른 종류의 리스크를 평가하는 6개의 결정론적 제어 지점(deterministic control points)입니다. 그중 하나인 리스크 게이트(Risk Gate)는 신뢰 손상을 방지하기 위해 존재합니다. 그 규칙은 단순합니다. 만약 24시간 이동 창(rolling 24-hour window) 내에 3건 이상의 HIGH-severity 보안 이벤트가 발생하면, 게이트는 HOLD 상태로 전환됩니다. 그리고 단 하나의 게이트라도 HOLD 상태가 되면 시스템은 THROTTLE(속도 제한) 상태에 진입합니다. 이는 거버넌스, 백업 및 핵심 운영은 유지하되 확장적인 모든 작업을 일시 중단하는 보수적인 모드입니다. 세상이 멈추는 것은 아닙니다. 시스템이 새롭고 외부를 향하는 일을 시작하는 것을 막는 것입니다.

24시간 동안 4건의 HIGH-severity 보안 이벤트 발생 — 임계값인 3건을 초과함. 4건 모두 해당 날 아침 처음 발견된 단일 네트워크에서 발생했습니다. 게이트 사유 문자열(Gate reason string) 원문은 다음과 같습니다: "Multiple HIGH security events in 24h (4 ≥ 3) → THROTTLE."

4가지 이벤트

이 이벤트들은 하나의 주소 블록에서 발생했으며 두 가지 일반적인 노이즈 유형으로 나뉩니다:

불편한 부분 — 그리고 나는 이를 숨기지 않을 것입니다

회의적인 보안 책임자라면 무엇보다 먼저 무언가를 알아차릴 것이며, 그들의 판단은 옳습니다. 그 네 가지 사건 중 그 어느 것도 실제 위협이 아니었습니다. Credential stuffing (자격 증명 스터핑)은 lockout (잠금)에 의해 차단되었습니다. 봇들은 rate-limited (속도 제한) 처리되었습니다. 이 모든 것은 자동으로 작동하며 아무도 필요로 하지 않는 20년 된 baseline controls (기초 제어 장치)에 의해 억제되었습니다. 그리고 그 후 Risk Gate (리스크 게이트)는 어쨌든 확장 운영을 throttle (제한)했습니다.

따라서 솔직한 해석은 "거버넌스가 위기를 구했다"가 아닙니다. 대신 두 가지 까다로운 질문이 남습니다.

• 게이트가 배경 소음(background noise)에 반응하여 시스템 자체의 역량을 저하시킨 것뿐인가?
• 만약 억제된 credential-stuffing 시도가 HIGH (높음) 심각도로 간주된다면, 심각도 척도(severity scale)가 잘못 설정된 것인가?

두 질문 모두 타당합니다. 심각도에 관한 질문은 실질적인 문제이며 나중에 다시 다루겠지만, 그것은 조절 가능한 수치(dial)일 뿐 이야기의 본질은 아닙니다. 첫 번째 질문이야말로 입장을 견지하며 방어할 가치가 있는 문제입니다.

명확하게 기술한 트레이드오프 (tradeoff)

제가 실제로 방어하고자 하는 입장은 다음과 같습니다. 확인되었고 억제되지 않은 침해 사고에 대해서만 작동하는 거버넌스 게이트는, 당신이 은밀하게 주저하도록 가르친 게이트입니다. 그리고 주저하는 게이트는 enforcement (강제 집행)가 아니라 dashboard (대시보드)에 불과합니다. Fail-safe (페일 세이프) 거버넌스는 그 반대의 도박을 합니다. 그것은 HIGH 심각도의 신호 뭉치를 주의를 기울여야 할 충분한 근거로 취급하며, 사후적으로 보았을 때 그러한 throttle (제한) 중 일부가 불필요했을 것임을 받아들입니다. 잘못된 throttle (제한)은 해당 설계의 버그가 아닙니다. 그것은 단순히 기계에 조언만 하는 것이 아니라 기계를 실제로 _결속(bind)_시키는 제어 장치를 위해 지불하는 프리미엄입니다.

그 프리미엄이 저렴하지 않다면 그것은 나쁜 거래입니다. 이것이 오늘 아침 논의의 핵심이며, 대부분의 거버넌스 관련 글들이 생략하는 부분입니다.

프리미엄을 저렴하게 만드는 설계 선택

throttle (제한)은 누군가가 리셋하는 것을 기억해야 하는 latch (래치)가 아닙니다. 네 가지 사건이 24시간의 윈도우(window)를 벗어나면, 게이트는 PASS 상태로 돌아가며 시스템은 스스로 다시 완전한 autonomy (자율성) 상태로 복귀합니다. 별도의 정리 작업도, 티켓 발행도, 상황이 안전하다고 결정하는 인간도 필요하지 않습니다.

그 대칭성이 바로 핵심입니다. 오직 억제(clamp down)만 할 수 있고, 이를 해제하기 위해 사람이 필요해야 하는 제어 방식은 단순히 가끔씩 발생하는 일시 정지 비용만을 발생시키는 것이 아닙니다. 그것은 그 시스템 하에서 작동하는 사람들에게 당신의 신뢰성을 잃게 만듭니다. 사람이 직접 해제해야 하는 모든 불필요한 제한(throttle)은 조직에게 그 게이트가 장애물이라는 사실을 가르치며, 사람들은 장애물을 우회하는 데 매우 능숙합니다. 신호가 해제되는 즉시 스스로를 해제하는 게이트는 신중하게 행동할 여유가 있습니다. 왜냐하면 틀리는 비용이 저렴하고 스스로 교정 가능하기 때문입니다. 그렇게 할 수 없는 게이트는 조용히 모든 이로 하여금 그 기능을 비활성화하도록 훈련시키고 있는 것입니다.

억제만 할 수 있는 강제 조치는 꺼지게 됩니다. 해제까지 가능한 강제 조치는 그대로 유지됩니다.

이것은 제가 Enterprise Agent Architecture 시리즈에서 계속 주장해 온 내용의 비극적이지 않은 버전입니다. 에이전트가 인용할 수는 있지만 런타임(runtime)이 강제하지 않는 규칙은 보여주기식(theater)에 불과합니다. 여기서의 규칙은 기계에 경고만 하고 계속 진행한 것이 아니라, 기계를 **구속(bound)**했고, 그 후 인간의 개입 없이 스스로를 **해제(unbound)**했습니다. 저는 게이트의 이유 문자열(reason string)을 보여줄 수 있고, 그 뒤에 숨겨진 카운트가 신호로 위장한 '실패 시 폐쇄(fail-closed)' 기본값이 아니라 실제였다는 것을 보여줄 수 있습니다. 시스템 자체의 메트릭 마스킹(metric-masking) 체크 결과가 비어 있었기 때문입니다. 제가 당신에게 말할 수 없는 것은, 4가 완벽한 임계값이라거나 이 심각도 척도가 튜닝의 범위를 벗어났다는 사실입니다. 그것들은 보정(calibration)의 문제이며, 보정은 시스템의 수명 동안 돌려야 하는 다이얼과 같습니다. 아키텍처 문제는 그 모든 것에 앞섭니다. 규칙이 구속하는가, 그리고 스스로를 해제하는가? 여기서 두 질문에 대한 답은 모두 '예'였습니다. 그리고 당신은 이미 구속력을 가진 게이트만을 튜닝할 수 있습니다.

자동 해제(auto-release)에도 살아남는 더 날카로운 반론

자동 해제(auto-release)에도 살아남는 더 날카로운 반론: 공격자가 저렴하고 지속적인 노이즈를 통해 당신을 THROTTLE(속도 제한) 상태로 묶어둘 수 있다는 점입니다. 이벤트가 계속 유입되는 동안에는 윈도우(window)가 결코 비워지지 않기 때문입니다. 이것은 실패하는 것이 아니라 페일 세이프(fail-safe) 로직이 제대로 작동하고 있는 것입니다. 활발하고 지속적인 적대적 공격을 받는 시스템은 더 작은 자율성 표면(autonomy surface)을 실행해야 하며, 압박이 지속되는 동안 신중함을 유지하는 것이 올바른 태도이지, 당신이 스스로에게 가한 서비스 거부(denial-of-service)가 아닙니다. 그리고 이러한 이벤트들이 단일 소스 네트워크를 공유하기 때문에, 해당 계층에서 압박을 차단할 수 있습니다. 소스를 차단하면 윈도우는 스스로 비워집니다. 자동 해제는 일시적인 사례에 대응하며, 네트워크 차단은 지속적인 사례에 대응합니다. 그리고 둘 다 인간의 개입을 기다리지 않습니다.

시사점 (The takeaway)

제어된 자율성(governed autonomy)의 기준은 오직 실제 위협에만 작동하는 게이트가 아닙니다. 그런 상태에 도달할 수 있도록 튜닝하는 것은 불가능하며, 그것을 쫓다 보면 구속력이 너무 약한 게이트를 만들게 됩니다. 기준이 되는 게이트는 그럴듯한 신호(plausible signal)가 포착되면 구속력을 발휘하고, 신호가 사라지면 스스로 해제되는 게이트입니다. 페일 세이프(fail-safe) 강제 조치는 때때로 아무 이유 없이 당신의 속도를 제한할 것입니다. 자동 해제는 이러한 현상을 '시스템을 꺼야 할 이유'가 아니라 '지불할 가치가 있는 비용'으로 바꾸어 주는 것입니다.

이 글은 Enterprise Agent Architecture 시리즈의 현장 노트(field note)입니다. 에이전트 워크포스(agent workforce)를 그 자체의 아키텍처 도메인으로 관리해야 한다는 논지를 다룹니다. 파트 3에서는 전체 논거를 구축합니다: 런타임(runtime)이 강제하지 않는 규칙은 보여주기식(theater)에 불과합니다.

이 노트의 수치들은 2026년 7월 16일, 라이브 시스템의 추가 전용(append-only) security_events 감사 로그와 게이트 상태에서 직접 읽어온 것입니다. "가려지지 않은 실제 신호"라는 주장은 시스템 자체의 빈 masked_metrics 체크 결과입니다. 소스 네트워크는 공개되지 않았습니다. 어떠한 지표도 조작되지 않았습니다.

원문 현장 노트: cognitivethoughtengine.com · 포지션 페이퍼: doi.org/10.5281/zenodo.21105314