회사 AI 에이전트한테 결제도 시키고 메일도 보내게 했다면, 딱 하나만 확인해보세요. "안 돼"라고 말할 장치가 지금 이 순간 실제로 있나요? 정책 문서 말고요.
정책 문서는 있는데, 왜 자꾸 사고가 나죠
AI 에이전트를 쓰는 국내 기업·기관 중 67%가 이미 AI 관련 보안사고를 경험했어요. 지난 1년으로 좁히면 74.9%까지 올라가고요. 사고 원인 1위는 AI의 부정확한 응답이 실무 오류로 번진 경우(54.4%)였고, AI 오작동(12.2%)과 아무도 모르게 퍼진 '섀도우 AI'(8.8%)가 뒤를 이었어요.
해외도 사정은 비슷해요. Gravitee의 2026년 리포트를 보면, 프로덕션에 올라간 AI 에이전트의 48%가 보호되지 않은 채로 돌아가고 있고, 평균 모니터링 커버리지는 52%에 그쳐요. 더 심각한 건 이거예요 — 에이전트를 실제로 배포하기 전에 전체를 완전히 보안·거버넌스 처리했다고 답한 조직은 19.7%뿐이고, 에이전트 행동에 공식적으로 책임지는 사람을 지정해둔 조직은 7.2%에 불과해요.
정책이 없어서가 아니에요. 대부분 조직엔 "에이전트는 이런 건 하면 안 된다"는 문서가 이미 있어요. 문제는 그 문서가 에이전트가 실제로 API를 호출하는 순간에는 아무 힘도 못 쓴다는 것이에요. 정책과 실행 사이에 아무도 안 지키는 빈틈이 그대로 남아있는 거예요.
근데 다 틀어막는다고 능사도 아니더라고요
여기서 반전이 하나 있어요. Gartner는 2026년 5월, "모든 AI 에이전트에 동일한 통제를 적용하면 오히려 배포 실패로 이어진다"고 경고했어요. 이 예측대로면 2027년까지 기업 40%가 자율 AI 에이전트를 강등하거나 아예 폐지하게 될 거예요.
이유는 단순해요. 읽기 전용으로 요약만 하는 에이전트와, 메일을 보내고 시스템 설정을 바꾸는 에이전트를 똑같은 강도로 막으면 둘 다 못 쓰게 돼요. Gartner의 Shiva Varma는 이렇게 짚었어요. "기업들이 AI 에이전트 거버넌스를 이진법으로 취급하고 있습니다. 철저히 제한되거나 완전히 신뢰받는 형태로만 봅니다."
그래서 나온 게 4단계 자율성 프레임워크예요. 관찰(읽기 전용) → 조언(권장만, 실행은 사람) → 승인 후 행동(변경 가능하나 승인 필수) → 완전 자율(가드레일 안에서 독립 실행). 단계별로 다른 수위의 통제를 매기는 방식이에요. 실제로 이 원칙을 적용한 Microsoft의 위협 탐지 에이전트는 경보 정확도 80.1%, 작업 실패율 0.38%를 기록했어요 — 일괄 통제 없이도 성과가 나온다는 증거예요.
이 흐름을 타고 아예 새로운 카테고리가 생겼어요. 이름하여 '가디언 에이전트(Guardian Agents)'. 이미 기업 70%가 AI 에이전트를 운영 중이고 23%가 2026년 안에 추가 배포할 계획인데, 도입 속도가 전통적 거버넌스 통제를 앞질러버린 상황이에요. Gartner는 가디언 에이전트가 갖춰야 할 핵심 능력으로 가시성·지속적 보증·런타임 검사 및 실행 세 가지를 꼽았어요. 문서화가 아니라 '지금 이 행동을 막을 수 있느냐'가 기준이라는 거예요.
그래서 에이전트와 시스템 사이에 문을 세웠다
2026년 8월 Product Hunt에 올라온 Execlave가 이 지점을 정확히 겨냥해요. 태그라인부터가 "AI 에이전트와 실제 세계 사이의 문(gate)"이에요. 에이전트가 도구를 호출하고, API를 때리고, DB에 쓰는 그 순간에 끼어들어서 미리 정해둔 정책과 맞는지 검사한 다음에야 통과시켜요.
비슷해 보이는 Credo AI 같은 서비스와는 계층이 달라요. Execlave 팀이 직접 쓴 비교 글에 이런 문장이 있어요. "프로그램 문서화는 이미 뚫린 에이전트가 잘못된 API를 호출하는 걸 막지 못한다. 런타임 집행이 막는다."
| 거버넌스 프로그램 계층 (Credo AI류) | 실행 강제 계층 (Execlave) | |
|---|---|---|
| 역할 | 조직 전체 AI 시스템 등록·위험평가·규제문서 작성 | 요청 경로에서 실시간 차단 |
| 작동 시점 | 배포 전/사후 감사 | 에이전트가 행동하는 바로 그 순간 |
| 속도 | 주 단위 리뷰 사이클 | p50 20ms 이내 |
| 산출물 | 정책 문서, 규제 매핑표 | 암호 서명된 감사 기록 |
Execlave는 이 실행 계층을 Enforce·Prove·Stop·Report 네 가지로 쪼갰어요. Enforce는 3~25ms 안에 정책을 평가하고, Stop은 6ms 이내에 에이전트를 통째로 멈추는 긴급 스위치예요. Report는 SOC 2, HIPAA, GDPR, ISO 27001, EU AI Act 등 7개 규제 프레임워크 기준으로 증거를 자동 생성해요. 정책은 19가지가 내장돼 있고, 위반을 발견했을 때 반응은 차단(block)·경고(warn)·모니터링(monitor)·승인 요청(require_approval) 네 가지 모드 중에 고를 수 있어요.
Product Hunt 댓글에서 오간 질문들이 흥미로워요. "프로덕션 전에 재현 어려운 시나리오는 어떻게 테스트하냐"는 질문에 팀은 "정책 엔진에 적대적 프로브를 돌리고, 실제 트래픽에서는 차단 없이 지켜만 보는 observe 모드를 쓴다"고 답했어요. "에이전트가 막히면 왜 막혔는지 알고 재시도할 수 있냐"는 질문엔, 위반 정책 ID와 사유가 담긴 구조화된 거부 메시지를 돌려준다고 답했고요.
이 게이트도 만능은 아니에요
창업자 Rishit Mavani가 직접 인정한 부분이에요. "게이트는 제공하는 정책만큼만 좋습니다. 첫 주는 에이전트가 실제로 무엇을 할 수 있는지 결정하는 데 다 씁니다." 즉 도구를 붙인다고 끝나는 게 아니라, 우리 조직의 에이전트가 뭘 해도 되고 뭘 하면 안 되는지부터 사람이 정리해야 한다는 뜻이에요.
지금 팀에 적용하는 법
특정 제품을 쓰든 안 쓰든, 순서는 비슷해요. Gartner의 자율성 단계와 Execlave류 도구의 집행 모드를 그대로 매핑하면 됩니다.
- 에이전트 인벤토리부터 만들기
지금 몇 개의 에이전트가 어떤 도구·API에 접근하는지 목록화해요. 조직 절반 이상이 76개 이상의 에이전트를 굴리면서도 이 목록조차 없다는 게 현실이에요. - 자율성 단계로 나누기
관찰·조언·승인 후 행동·완전 자율 네 단계 중 어디에 속하는지 에이전트별로 분류해요. 읽기 전용 에이전트까지 완전 자율과 똑같이 취급하지 마세요. - 위험도별로 집행 모드 매핑
낮은 위험엔 monitor, 애매하면 warn이나 require_approval, 되돌리기 힘든 행동(결제·삭제·외부 전송)엔 block을 걸어요. - observe 모드로 먼저 지켜보기
바로 차단부터 걸면 오탐으로 정상 업무가 멈춰요. 실제 트래픽에서 관찰만 하며 정책을 튜닝한 뒤 차단으로 넘어가세요. - 감사 증거를 자동으로 쌓기
규제 대응 문서를 그때그때 손으로 만들지 말고, 위반·차단 이력이 자동으로 감사 기록에 쌓이게 세팅해두세요. 나중에 물어보면 로그로 바로 증명할 수 있어야 해요.
