메인 콘텐츠로 건너뛰기
보안 검사는 실제로 실행되어야 의미가 있습니다 — 하지만 안전을 위해 처리량을 희생할 필요는 없습니다. 이 페이지는 개발자들이 가장 많이 묻는 질문에 답합니다: 강제가 에이전트를 느리게 하나요, 얼마나? 짧은 답: 내장 규칙은 측정할 수 없을 정도의 비용이 듭니다. 고급 규칙은 최대 하나의 제한된, 동시적, 페일 오픈 모델 호출 비용이 듭니다. 이유와 조정 방법을 설명합니다.

​
1. 두 가지 검사 클래스

모든 guardrail 규칙과 모든 firewall 평가는 두 클래스 중 하나에 해당합니다.

​
내장 / 결정적 검사

키워드 거부 목록 (keyword), 정규 표현식 (regex), PII 탐지 (pii), 최대 길이 (max_chars) guardrail 규칙은 순수 로컬 문자열 및 정규식 작업입니다 — 모델 호출 없음, 네트워크 홉 없음, 타임아웃이 가능한 것 없음. Firewall 규칙 평가 (툴 이름 glob 매칭, 인자 조건, egress 범위)도 동일합니다: 결정적이고 로컬. 실용적인 목적으로, 이러한 검사는 요청에 무시할 수 있는 지연 시간을 추가합니다. 핫 경로에서 안전하게 실행되며, 내장 guardrail 템플릿이 이루어진 것입니다.

​
고급 / 의미적 검사

llm_judge, grounding, external 벤더 규칙은 검사를 모델이나 벤더에 위임합니다. 이들은 라운드 트립 비용이 듭니다. 세 가지 속성이 그 비용을 제한합니다:
  1. 동시 디스패치. 정책에 여러 고급 규칙이 있으면, 이들은 병렬로 디스패치됩니다 — 느린 검사 하나가 결코 다른 검사 뒤에서 직렬화되지 않습니다.
  2. 규칙별 타임아웃. 각 고급 규칙에는 타임아웃이 있습니다 (judge_timeout_ms / grounding_timeout_ms / timeout_ms). grounding 검사는 기본적으로 ~3 000 ms입니다; 심판은 구성 가능한 값을 사용합니다 (0 → 엔진 기본값). 규칙은 제한됩니다 — 무기한 중단될 수 없습니다.
  3. 기본 페일 오픈. 규칙이 타임아웃되거나 벤더가 오류를 반환하면, 이벤트가 기록되지만 요청은 계속됩니다. 페일 클로즈로 전환하려면 judge_fail_open: false (심판) 또는 fail_open: false (external)를 설정하세요.
따라서 임의 개수의 고급 규칙에 대한 최악의 경우는 모든 타임아웃의 합이 아니라 가장 긴 단일 타임아웃입니다.

​
2. 한눈에 보기

검사 타입지연 시간 추가?제한 방법
keyword 거부 목록무시할 수 있음 — 로컬 문자열 스캔네트워크 없음; 타임아웃 불필요
regex무시할 수 있음 — RE2 로컬 매치네트워크 없음; 타임아웃 불필요
pii 탐지무시할 수 있음 — 로컬 정규식/엔티티 스캔네트워크 없음; 타임아웃 불필요
max_chars무시할 수 있음 — 문자 수네트워크 없음; 타임아웃 불필요
Firewall 규칙 평가무시할 수 있음 — glob + 조건 매칭네트워크 없음; 타임아웃 불필요
llm_judge하나의 제한된 모델 호출judge_timeout_ms; 기본 페일 오픈
grounding하나의 제한된 모델 호출grounding_timeout_ms (기본 ~3 000 ms); 기본 페일 오픈
external 벤더하나의 제한된 벤더 호출timeout_ms; 기본 fail_open
여러 고급 규칙하나의 제한된 라운드 트립 (동시 디스패치)최악의 경우 = 최대 단일 타임아웃, 합산 아님

​
3. 검사가 요청 수명 주기에서 실행되는 위치

강제가 모두 같은 지점에서 일어나지 않습니다. 입력 및 출력 검사는 다른 위치에서 시간을 추가합니다: 
클라이언트
  │
  ▼
[입력 guardrail 검사]     ← 여기서 시간 추가, 업스트림 전
  │
  ▼
업스트림 모델 호출
  │
  ▼
[출력 guardrail 검사]    ← 여기서 시간 추가, 모델 응답 후
  │
  ▼
클라이언트
입력 guardrails는 업스트림 모델 호출 전에 실행됩니다. 내장 입력 규칙은 미미한 오버헤드를 앞에 추가합니다. 고급 입력 규칙 (예: 프롬프트 인젝션을 검사하는 llm_judge)은 메인 모델 호출이 시작되기 전에 제한된 모델 호출을 추가합니다. 출력 guardrails는 모델이 응답한 후 실행됩니다. 내장 출력 규칙은 꼬리에 무시할 수 있는 오버헤드를 추가합니다. 고급 출력 규칙 (예: RAG 충실도를 검사하는 grounding)은 이미 모델의 답변이 있는 후에 제한된 호출을 추가합니다. Firewall 규칙 평가는 결정적이며 툴 호출 라우팅에서 인라인으로 일어납니다 — 위에서 언급한 것처럼 무시할 수 있습니다.
차단된 요청은 모델 토큰을 소모하지 않으며 input-stage 차단에 대해 업스트림 지연 시간을 추가하지 않습니다. 입력 차단은 계량 전에 그리고 업스트림 호출 전에 발동하므로, 쿼터도 업스트림 라운드 트립 시간도 지불하지 않습니다. 출력 단계 차단은 응답이 거부된 후 사전 소모된 쿼터를 환불합니다.

​
4. 타임아웃과 페일 오픈이 최악의 경우를 제한하는 방법

고급 규칙에는 두 개의 다이얼이 있습니다: 타임아웃 — 검사에 허용되는 최대 벽시계 시간. 요청은 그 규칙을 위해 최대 이 시간을 기다립니다. 동시 디스패치는 이 한도가 규칙별로 적용됨을 의미합니다, 정책별이 아닙니다. 각각 2 000 ms 타임아웃이 있는 세 llm_judge 규칙이 있으면, 세 가지 모두 동시에 실행되고 총 대기 시간은 ~6 000 ms가 아닌 ~2 000 ms입니다. 페일 오픈 vs 페일 클로즈 — 규칙이 제때 완료되지 않을 때 (또는 벤더가 오류를 반환할 때) 무엇을 할지:
설정타임아웃 / 오류 시 동작
fail_open: true (기본값)이벤트를 기록하고; 검사가 통과된 것처럼 요청을 계속합니다
fail_open: false타임아웃 / 오류를 차단으로 취급하고; HTTP 400 guardrail_blocked를 반환합니다
페일 오픈은 놓친 검사의 비용으로 가용성을 보존합니다. 페일 클로즈는 심판이 느리거나 도달 불가능할 경우 가용성 비용으로 정책 보장을 보존합니다. 사용 사례에서 더 중요한 것에 따라 선택하세요.

​
5. 실용적인 지침

핫 경로 규칙은 내장으로 유지하세요. PII, 자격 증명 유출, 프롬프트 길이, 키워드 거부 목록 — 이 모두는 내장 규칙입니다. 측정 가능한 지연 시간을 추가하지 않으며 텍스트 매칭이 처리할 수 있는 모든 검사에서 기본 선택이어야 합니다. 의미론이 필요한 곳에 llm_judge와 grounding을 사용하세요. 독성, 괴롭힘, 주제 이탈 탐지, 프롬프트 인젝션 의도, RAG 충실도는 진정으로 모호합니다 — 어떤 정규식도 신뢰할 수 있게 포착하지 못합니다. 이것들이 고급 규칙의 올바른 경우입니다. 각각이 제한된 추가 모델 호출을 추가한다는 것을 받아들이세요. 지연 시간 예산에 맞게 타임아웃을 조정하세요. 엔드 투 엔드 목표가 1 000 ms라면, 심판이 전체 예산을 소모할 수 없도록 judge_timeout_ms: 800 (또는 더 낮게)을 설정하세요. 엔진의 기본 타임아웃은 안전한 시작점입니다; 엄격한 요구 사항이 있다면 낮추세요. 출력 그라운딩의 경우, 모델 호출이 이미 완료되었습니다. grounding 검사는 업스트림 모델이 응답한 후 실행됩니다 — 추가 지연 시간은 첫 번째 토큰까지의 시간에 대한 중요 경로가 아닌 꼬리에만 있습니다. 이것은 의미적 강제를 추가할 낮은 위험 장소입니다. 여러 고급 규칙? 작업을 분산하세요. 고급 규칙이 동시에 실행되므로, 세 llm_judge 규칙을 쌓으면 하나와 거의 같은 비용이 듭니다 — 가장 긴 개별 타임아웃이 벽시계 시간을 결정하며, 수가 아닙니다. 이것을 사용해서 추가 비용 없이 의미적 검사를 레이어하세요.

강제 모드

페일 오픈 vs 페일 클로즈 — 타임아웃과 오류 조건 하에서 정책 동작을 조정하는 전체 레퍼런스.

Guardrails

규칙 타입, 심판 필드, 그라운딩 임계값, 전체 guardrail 구성 레퍼런스.
내장 규칙은 모든 경로에서 무시할 수 있습니다; 고급 규칙은 하나의 제한된, 동시적, 페일 오픈 호출 비용이 듭니다 — 타임아웃과 페일 모드를 조정하면, 강제가 에이전트에 통제되지 않은 지연 시간을 추가하지 않습니다.