대시보드는 에이전트 거버넌스가 아닙니다: 사전 실행 게이트(pre-action gates)의 필요성

2026년 4월에 발표된 Cloud Security Alliance와 Token Security의 연구에 따르면, 지난 1년 동안 조직의 65%가 AI 에이전트로 인해 발생한 최소 하나 이상의 보안 사고를 경험한 것으로 나타났습니다. 이러한 사고 중 61%는 민감한 데이터 노출을 포함했습니다. 41%는 비즈니스 프로세스 전반에서 의도하지 않은 동작을 초래했습니다.

만약 여러분이 실제 도구 접근 권한을 가진 코딩 에이전트 — Claude Code, Cursor, Codex, Gemini CLI, Cline — 를 실행하고 있다면, 이 수치는 여러분이 "에이전트 거버넌스 (agent governance)"를 생각하는 방식을 바꿔 놓아야 합니다. 왜냐하면 오늘날 거버넌스로 판매되는 대부분의 것은 대시보드(dashboard)이기 때문입니다. 그리고 대시보드는 이 작업에 적합하지 않은 도구입니다.

탐지는 예방이 아닙니다

대시보드는 에이전트가 무엇을 했는지 알려줍니다. rm -rf, 유출된 키(key), main 브랜치로의 강제 푸시(force-push), 운영 테이블에 대한 DROP 명령 등을 기록하고, 그 피해에 대한 멋진 타임라인을 보여줍니다.

문제는 타이밍입니다. 자율 에이전트(autonomous agent)는 머신 스피드(machine speed)로 동작합니다. 사고가 대시보드에 나타날 때쯤이면, 버킷(bucket)은 이미 비어 있고 키는 이미 누군가의 로그에 남겨진 상태입니다. 여러분은 아무것도 예방하지 못했습니다. 그저 사후 분석(postmortem) 보고서를 생성했을 뿐입니다.

보안 엔지니어링(Security engineering)에는 나쁜 동작이 일어나기 전에 이를 차단하는 것을 일컫는 용어가 있습니다: 바로 통제(control)입니다. 이것이 대부분의 에이전트 툴링(agent tooling)에서 결여되어 있는 부분입니다.

"하지만 저에게는 CLAUDE.md / .cursorrules가 있는데요"

지침 파일(Instruction files)은 유용하지만, 모델이 무시할 수 있는 제안 사항일 뿐입니다. 이 파일들은 프롬프트(prompt) 내에 존재하며, 컨텍스트(context) 내의 다른 모든 요소와 경쟁합니다. 또한 긴 세션이나 영리한 인젝션(injection) 공격은 이를 우회할 수 있습니다. 이들은 강제되지 않습니다. 에이전트는 "운영 환경(production)을 절대 건드리지 마시오"라는 문구를 읽고 나서도 운영 환경을 건드릴 수 있으며, 물리적으로 이를 막는 것은 아무것도 없습니다.

여러분이 원하는 것은 에이전트의 *의도(intent)*와 실행된 동작(executed action) 사이에 위치하는 강제 경계(enforcement boundary)입니다. 즉, 모델이 준수하기로 선택하는 것에 의존하지 않는 경계 말입니다.

사전 실행 게이트(pre-action gate)의 위치

이것이 사전 실행 게이트(pre-action gate)의 핵심 아이디어입니다. 구체적으로 에이전트 생태계에서는 PreToolUse 훅(hook)으로 구현됩니다. 즉, 어떤 도구 호출(tool call)이 실행되기 전에, 이 훅이 명령을 가로채어 평가합니다. 만약 명령이 차단 규칙(block rule)에 부합한다면, 해당 호출은 실행되지 않습니다.

보안 담당자에게 중요한 구현 세부 사항은 다음과 같습니다: 게이트의 결정은 결정론적(deterministic)이어야 하며, 모델 호출을 포함해서는 안 됩니다. 문자열 패턴 매칭(pattern match), 그 다음 추상 구문 트리(AST) 매칭, 그리고 스코프가 지정된 규칙 조회(scoped rule lookup) 순으로 진행되어야 합니다. 집행 경로(enforcement path)에 LLM이 없다는 것은 프롬프트 인젝션(prompt injection)이 협상할 대상이 없음을 의미합니다. 정규 표현식(regex)은 탈옥(jailbreak)할 수 없기 때문입니다.

  에이전트 시도:   aws s3 rm s3://prod-backups --recursive
  게이트:          차단됨(BLOCKED) - 도구 호출 실행 전
                 규칙: 운영(prod) 버킷의 일괄 삭제는 절대 금지
...

이것이 전체적인 구조입니다. 위험한 호출은 에이전트가 실행되는 로컬 머신에서 평가되고 중단되며, 서버로의 왕복(round-trip)이나 실행 경로(hot path)에서의 추론 비용이 발생하지 않습니다.

수정을 규칙으로 전환하기

수동으로 관리하는 정적 차단 목록(denylist)은 당신이 작성하는 것을 기억해낸 패턴만을 정확히 커버합니다. 더 흥미로운 버전은 학습 루프(learning loop)입니다.

이것이 ThumbGate — 오픈 소스이며 MIT 라이선스를 따르는 로컬 우선(local-first) 구현체 — 가 수행하는 방식입니다. 잘못된 에이전트 동작에 대해 한 번의 '엄지 아래로(thumbs-down)'를 누르면 영구적인 방지 규칙이 됩니다. '엄지 위로(thumbs-up)'는 좋은 패턴을 강화합니다. 규칙 코퍼스(rule corpus)는 새로운 실수 형태마다 정규 표현식을 직접 작성할 필요 없이, 실제 결과로부터 더욱 정교해집니다.

직접 만든 훅(hand-rolled hook)이 구조적으로 할 수 없는 두 가지가 있습니다:

1. 에이전트 간 전파 (Cross-agent propagation). permissions.deny 패턴이 한 에이전트의 설정(config)에 존재하면 그곳에 머물게 됩니다. MCP를 통해 분산되는 게이트(gate)는 Cursor에서 한 번 거부된 패턴이 다음 세션에서 Claude Code, Codex, Gemini CLI, 그리고 Cline에서도 동일하게 차단됨을 의미합니다. 설정 간의 복사-붙여넣기가 필요 없습니다.
2. 학습 루프 (A learning loop). 어떤 에이전트로부터든 발생하는 수정 사항은 모든 에이전트를 자동으로 강화하며, 의미적으로 유사한 패턴들은 로컬 CPU 전용 임베딩 (local CPU-only embeddings, 외부 API 미사용)을 통해 탐지 범위 내로 들어옵니다.

내장된 체크 기능은 흔히 발생하는 비용 낭비 요인들을 즉시 차단합니다: 강제 푸시(force-push) 및 보호된 브랜치(protected-branch)로의 푸시, .env 비밀 정보 노출, 파괴적인 락 파일(lock-file) 편집 등입니다. 사용자는 피드백을 통해 자신만의 규칙을 추가할 수 있습니다.

컴플라이언스 담당자가 관심을 갖는 부분

차단(block), 허용(allow), 경로 재지정(reroute)과 같은 모든 게이트 결정은 규칙 버전 및 타임스탬프와 함께 감사 추적(audit trail)에 기록됩니다. 이를 통해 에이전트가 무엇을 했는지뿐만 아니라, 무엇을 _시도했는지_에 대한 기록을 가질 수 있습니다. 규제 대상 워크플로우(regulated workflows)에서 이 차이는 매우 결정적입니다.

사용해 보기

npx thumbgate init   # 에이전트를 자동 감지하고 훅(hooks)을 연결합니다, 약 30초 소요
npx thumbgate capture down "Never run DROP on production tables"

연결된 에이전트가 운영 환경(production) 테이블에 DROP을 실행하려고 할 때, 도구 호출(tool call)이 실행되기 전에 체크가 작동합니다.

적용 범위 (및 적용되지 않는 범위)

사전 실행 게이트(pre-action gate)는 코드 리뷰, 테스트, 또는 최소 권한 자격 증명(least-privilege credentials)을 대체하는 것이 아닙니다. 이는 나머지 통제 수단들이 존재한다고 가정하는 실행 경계(execution boundary)입니다. 또한 모델 미세 조정(model fine-tuner) 도구도 아닙니다. 가중치(weights)를 변경하는 것이 아니라 동작을 차단하는 것입니다. 만약 에이전트가 실제 부작용(side effects)이 없는 샌드박스(sandbox)에서만 실행된다면 아직 필요하지 않을 수도 있습니다. 하지만 에이전트가 셸 액세스(shell access), 배포 권한(deploy rights), 또는 운영 환경 자격 증명(production credentials)을 갖게 되는 순간, 계산법은 달라집니다.

솔직한 요약은 다음과 같습니다: 더 나은 대시보드가 에이전트를 더 신뢰할 수 있게 만들지는 않습니다. 어려운 부분은 가시성(visibility)이 아니라, 생성된 의도(generated intent)와 실행된 동작(executed action) 사이의 경계입니다. 그 경계가 바로 거버넌스(governance)가 실제로 일어나는 지점입니다.

Repo (MIT, local-first): https://github.com/IgorGanapolsky/ThumbGate

만약 귀하의 팀이 에이전트(agents)에게 실제 셸(shell)이나 API 접근 권한을 부여하고 있다면, 현재 이를 어떻게 게이팅(gating)하고 있는지 진심으로 듣고 싶습니다. 무엇이 효과적이었는지, 무엇이 과하게 작동했는지, 그리고 강제 실행 계층(enforcement layer)에 무엇을 원하는지 알려주세요.