AI 에이전트에 가드레일을 붙이는 방법을 고를 때, 대부분의 팀은 두 경로 앞에 선다. 호출마다 판단하는 두 번째 모델을 두거나, 데이터가 도구 사이를 이동하는 경로 자체에 규칙을 심거나. 이 선택이 보안 수준뿐 아니라 에이전트가 실제로 작업을 완수할 수 있느냐에도 직결된다는 점이 문제를 복잡하게 만든다.
어느 접근도 단독으로 완전한 방어를 보장하지 않는다. 그 전제를 먼저 받아들인 상태에서, 어떤 조건에서 무엇을 중심에 두어야 하는지를 비교해보자.
모델 기반 승인이 막아주는 것과 막지 못하는 것
모델 기반 가드레일은 각 도구 호출을 별도 분류기(classifier)나 판단 모델이 검토하는 방식이다. 에이전트의 행동 의도를 자연어 수준에서 해석하기 때문에, 명백히 비정상적인 호출 패턴이나 정책에 어긋나는 요청 문구를 잡아내는 데 유리하다.
구조적 한계는 분류기 자체가 프롬프트 인젝션에 노출될 수 있다는 점에서 온다. 이 때문에 실제 구현에서는 판단 모델에게 도구 출력을 숨기는 경우가 많다. 도구 A에서 읽은 민감 정보가 도구 B를 거쳐 외부로 흐르는 경로, 즉 도구 간 데이터 이동은 이 구조로는 추적하기 어렵다. 판단 모델이 데이터를 보지 못한 채 호출의 적절성을 평가하는 셈이다.
확률적 설계라는 점도 빼놓을 수 없다. 단일 호출 기준으로 99%대 탐지율을 달성하더라도, 에이전트가 수백만 번 호출을 처리하는 환경에서는 0.x%의 실패율이 실제 침해 건수로 누적된다. 빈도가 낮은 공격보다 대규모 반복 작업에서 위험이 오히려 더 커지는 역설이다.
결정론적 데이터 흐름 통제가 다르게 접근하는 이유
결정론적 접근은 "이 호출이 악의적인가"를 묻지 않는다. "이 데이터는 지금 어디서 왔고, 어디까지 갈 수 있는가"를 추적한다.
핵심은 데이터에 보안 레이블을 붙이고, 그 레이블이 도구 실행마다 단방향으로 좁아지게 만드는 것이다. 비공개 저장소에서 읽으면 허용 범위가 좁아지고, 검증되지 않은 외부 페이지를 읽으면 신뢰 수준이 낮아진다. 한 번 좁아진 레이블은 다시 넓어지지 않는다. 그래서 인젝션된 지시가 에이전트에게 "이 내용을 외부로 보내라"고 시켜도, 레이블이 해당 전송을 허용하지 않으면 실행 자체가 막힌다. 언어적 조작이 아니라 대수적 규칙이 판단 주체이기 때문이다.
또 다른 이점은 검증 가능성이다. 설정이 선언적으로 작성되어 있으면, CI/CD 파이프라인에서 현재 도구 그래프 전체가 규칙으로 커버되는지를 자동으로 확인할 수 있다. 어떤 경로가 열려 있고 어떤 경로가 막혀 있는지를 명시적으로 확인할 수 있다는 점에서, 블랙리스트 방식과 구조적으로 다르다.
도구 그래프가 커질수록 블랙리스트가 먼저 무너지는 이유
결정론적이라는 말이 같은 안전 수준을 뜻하지는 않는다. 커맨드나 패턴을 차단 목록으로 관리하는 방식이 대표적인 예다.
특정 명령을 막으면 에이전트는 같은 결과를 내는 다른 경로를 찾는다. 규칙을 촘촘하게 쌓을수록 정상 작업도 함께 막히고, 규칙을 느슨하게 두는 순간 어느 경로가 열려 있는지 아무도 모른다. 세 개의 평범한 도구를 연결했을 때 데이터가 새는지 여부를 차단 목록으로 확인할 방법은 없다. 도구가 하나 추가될 때마다 규칙을 다시 검토해야 하고, 그 검토가 완전한지도 보장하기 어렵다.
이것이 데이터 흐름 기반 결정론과 갈라지는 지점이다. 무엇을 막을지 대신 데이터가 어디까지 갈 수 있는지를 정의하면, 새 도구가 추가되거나 에이전트 수가 늘어나도 설정 전체를 다시 짜지 않아도 된다.
두 접근을 실제로 비교할 때 봐야 할 세 가지 축
위험 유형: 도구 간 데이터 누출이나 프롬프트 인젝션을 통한 유출이 주된 위협이라면 결정론적 데이터 흐름 통제가 구조적으로 더 적합하다. 복잡한 사용자 의도 검증, 정책 예외 처리, 맥락 의존적 승인이 필요한 경우에는 모델 기반 판단이 더 유연하게 작동할 수 있다. 다만 이 두 위협은 실제 환경에서 따로 존재하지 않는 경우가 많으므로, 편집 분석으로서 덧붙이면 두 레이어를 역할 분리하여 병행하는 구성이 현실적으로 더 안전하다.
성능 비용: 모델 기반 검토는 호출마다 추가 추론이 필요해 레이턴시와 비용이 누적된다. 에이전트가 동시에 수백만 호출을 처리하는 환경이라면, 이 비용이 설계 제약 자체가 된다. 결정론적 흐름 검증은 대수적 규칙 적용이므로 호출 수에 정비례하지 않는다. 대신 설정을 설계하고 초기 커버리지를 구성하는 데 사전 투자가 필요하다.
운영 복잡도: 모델 기반 접근은 판단 기준을 바꾸기 쉽고 즉각적인 정책 변경에 유리하다. 결정론적 설정은 변경할 때 CI 검증을 거쳐야 하지만, 변경 범위와 영향이 그만큼 명확하다. 규정 준수나 감사 요건이 있는 환경에서는 후자의 감사 추적이 훨씬 다루기 쉽다.
차단만 하는 가드레일이 에이전트를 멈추게 하는 문제
결정론적 가드레일이 실제 도입에서 부딪히는 벽은 흔히 보안 강도가 아니라 에이전트 유용성 쪽이다. 규칙이 차단만 돌려주면 에이전트는 거기서 멈추거나 반복 재시도하다 실패한다. 이 문제를 해결하지 않으면 보안과 실용성이 트레이드오프처럼 보이게 된다.
실제로는 트레이드오프가 아니다. 차단 결과를 에이전트가 읽을 수 있는 형식으로 돌려주되, "이 경로는 막혀 있지만 이 방식으로는 가능하다"는 대안을 함께 제시하면 에이전트가 작업을 이어갈 수 있다. 민감 정보를 마스킹한 뒤 더 넓은 수신 범위에 전달하거나, 특정 행동 하나를 개별 승인 경로로 처리하거나, 신뢰하기 어려운 소스를 별도 격리 컨텍스트에서 실행하는 식이다.
OpenAPPA가 공개한 벤치마크를 보면, 이 접근 방식으로 구현한 도구의 작업 완료율은 89%로 측정되었으며, 비교 대상인 Claude Auto mode는 90%, FIDES(Microsoft)는 41%였다. 공격 성공률은 OpenAPPA 0%, Claude Auto mode 10%, FIDES 31%로 보고되었다. 이 수치는 특정 벤치마크 조건에서의 결과이므로 환경에 따라 다를 수 있지만, 차단 방식 대신 대안 제시 방식이 실용성에 미치는 영향은 설계 시점에 진지하게 고려할 만하다.
요구사항 단계에서 먼저 정해야 하는 것
어떤 조합이 맞는지는 두 가지를 먼저 확인하면 윤곽이 잡힌다.
하나는 위협 모델이다. 공격자가 에이전트의 언어 처리를 통해 데이터를 빼내려 하는가, 아니면 에이전트가 정책 범위 안에서 의도에 어긋나는 행동을 하도록 설득하려 하는가. 전자라면 데이터 흐름 통제가 핵심이고, 후자라면 의도 검증 레이어가 더 관련 있다.
다른 하나는 도구 그래프의 커버리지 확인 가능 여부다. 지금 에이전트가 사용하는 도구 전체에서 데이터가 어떻게 흐르는지를 한눈에 그릴 수 있는가. 그릴 수 없다면 블랙리스트 방식은 어디서 구멍이 생길지 예측하기 어렵고, 모델 기반 판단도 어느 호출에서 놓쳤는지를 사후에야 알게 된다.
가드레일 기술을 고르기 전에 에이전트가 어떤 도구를 어떤 순서로 쓰는지, 그 경로에서 민감 데이터가 어디서 합류하고 어디로 나갈 수 있는지를 도식으로 그려보길 권한다. 그 도식 없이 보안 레이어를 먼저 추가하면, 나중에 교체하거나 보완할 때 공수가 두 배로 든다.
