AI 안전은 시스템의 문제입니다: 4계층 런타임 방어 체계 구축하기

LLM(대규모 언어 모델) 보안에 대해 이야기할 때, 대화는 보통 의미론적 프롬프트 분석(semantic prompt analysis)이나 일반적인 대역외(out-of-band) 중재 루프로 단순화되곤 합니다. 하지만 만약 당신의 가드레일(guardrail) 전략이 전적으로 비동기식 추론 후 API 호출이나 기본적인 문자열 매칭에 의존하고 있다면, 당신은 보안 경계를 설계한 것이 아니라 겉치레(facade)를 배치한 것입니다. 상태를 변형하는 에이전트 시스템(agentic systems)을 출시하고 있다면, 안전은 사후 처리 기능이 아닙니다. 그것은 근본적인 라우팅(routing) 및 실행 인프라의 제약 조건입니다. 진정한 운영 제어를 위해서는 수동적인 모니터링을 넘어, 명시적이고 계층화된 런타임 방어(runtime defense)를 실행 파이프라인(execution pipeline)에 직접 내장해야 합니다. 다음은 제가 결정론적이고 시스템 우선적인 엔지니어링 아키텍처를 분류하는 방식입니다.

핵심 논지: 검증되지 않은 의도는 원격 코드 실행(RCE)과 같습니다

함수 호출(function calling), 네이티브 도구 통합(native tool integration), 또는 데이터베이스 연결을 통해 LLM 인프라에 접근 권한을 부여하면, 근본적으로 애플리케이션의 위협 프로필(threat profile)이 변화합니다. 당신은 정적인 데이터 검색에서 동적이고 비결정론적인(non-deterministic) 실행 생성 단계로 이동하고 있는 것입니다. 만약 에이전트가 자신의 다운스트림 실행 경로를 동적으로 구성할 수 있도록 허용된다면, 프롬프트 인젝션(prompt injection)은 단순한 텍스트 처리 버그가 아닙니다. 그것은 기능적인 무단 원격 코드 실행(RCE) 또는 검증되지 않은 파괴적인 데이터베이스 쓰기(database write)가 됩니다. 이를 처리하기 위해서는 AI의 비결정론적인 출력을 엄격하고 결정론적인 시스템 경계 내에 격리해야 합니다. 이를 위해서는 데이터 경로(data path)에 직접 매핑된 4계층 런타임 스택이 필요합니다.

┌────────────────────────────────────────────────────────┐
│ 1. 인그레스 표면 (INGRESS SURFACE) (페이로드 파싱, 입력 게이팅) │
├────────────────────────────────────────────────────────┤
│ 2. 출력 경계 (OUTPUT BOUNDARY) (타입 강제, 토큰 슬라이싱) │
├────────────────────────────────────────────────────────┤
│ 3. 실행 게이트 (EXECUTION GATE) (도구 가로채기, 범위 블록) │
├────────────────────────────────────────────────────────┤
│ 4.

POLICY TRACE (결정론적 상태 감사 (Deterministic State Auditing)) │ └────────────────────────────────────────────────────────┘

1. 인그레스 표면 (The Ingress Surface)
   방어 인프라는 단 하나의 토큰이 추론 엔드포인트 (inference endpoint)에 도달하기 전에 실행되어야 합니다. 인그레스 표면 (Ingress Surface)은 엄격한 네트워크 경계 및 페이로드 필터 역할을 수행합니다. 파싱되지 않은 사용자 입력을 오케스트레이션 커널 (orchestration kernel)로 직접 전달하는 대신, 인그레스 표면은 다음과 같은 작업을 처리하도록 설계된 인라인 인터셉터 (inline interceptor) 역할을 합니다:

• 구조적 입력 검증 (Structural Input Validation): 오케스트레이션 파이프라인 (orchestration pipeline)이 데이터를 흡수하기 전에, 들어오는 텔레메트리 (telemetry), 컨텍스트 페이로드 (context payloads), 사용자 문자열이 정확하고 엄격한 타입 기대치와 일치하는지 확인합니다.
• 선제적 페이로드 정화 (Proactive Payload Sanitization): 텍스트 데이터 스트림을 스캔하여 알려진 간접 주입 벡터 (indirect injection vectors)를 탐지하고, 악성 문자를 이스케이프 (escaping) 처리하며, 기본 시스템 프롬프트 (system prompts)를 조작하려는 구조적 구분자 (structural delimiters)를 제거합니다.
• 사전 비행 정책 평가 (Pre-Flight Policy Evaluation): 비용이 많이 드는 비결정론적 (non-deterministic) 모델 추론 루프를 가동하기 전에 논리적 정책 충돌을 해결하고 요청을 중단합니다.

2. 출력 경계 (The Output Boundary)
   모델의 가공되지 않은 출력 (raw model outputs)을 절대 신뢰하지 마십시오. 고도로 미세 조정 (fine-tuned)된 전문 모델이라 할지라도 구조적 구문 (structural syntax)을 환각 (hallucinate)하거나, 부하 상황에서 타입 일관성 (type consistency)을 유지하지 못하거나, 내부 시스템 컨텍스트 (internal system context)를 유출할 수 있습니다. 출력 경계는 명시적인 이그레스 검증 프록시 (egress validation proxy) 역할을 합니다:

• 타입 및 스키마 강제 (Type & Schema Enforcement): 생성된 모델 응답을 JSON 스키마 (JSON Schemas), Zod 타입, 또는 Protobuf 정의와 기계적으로 파싱하여 일치시킵니다. 응답 구조가 컴파일 규칙을 위반하면 프록시가 즉시 이를 포착합니다.
• 결정론적 출력 슬라이싱 (Deterministic Output Slicing): 데이터 프레임이 다운스트림 서비스 (downstream service)나 클라이언트 UI에 도달하기 전에, 애플리케이션 경계를 우회하거나 의도하지 않은 개인정보 (PII)를 유출하거나 시스템 구성 데이터를 출력하려는 데이터 스트림을 프로그래밍 방식으로 절단, 편집 또는 차단합니다.

3. 실행 게이트 (The Execution Gate)
   이는 함수 호출 (function calling) 또는 도구 호출 (tool invocation)을 사용하는 모든 에이전트 시스템 (agentic system)을 위한 핵심 집행 커널 (enforcement kernel)입니다.

에이전트는 사용자의 기반 실행 계층 (execution layer)에 대한 직접적인 네트워크 또는 프로세스 가시성을 절대 가져서는 안 됩니다. 대신, 에이전트는 실행 의도 (execution intent, 즉 도구 호출 요청)를 방출하며, 이는 Execution Gate에 의해 가로채지고 평가됩니다: 엄격한 파라미터 게이팅 (Strict Parameter Gating): 함수 이름에 대해 엄격한 화이트리스트 (whitelist)를 강제하고, 명시적인 컴파일 타임 경계 제약 조건 (compile-time boundary constraints)에 따라 인자를 검증합니다. 만약 에이전트가 승인되지 않은 인자를 제공하거나 범위를 벗어난 메서드를 호출하려고 시도하면, 실행 스레드는 즉시 차단됩니다. 상태 유지 권한 부여 루프 (Stateful Authorization Loops): 영향력이 크거나 파괴적인 작업 (데이터 변조 또는 외부 API 웹훅 등)을 중단시켜, 명령을 발송하기 전에 인간 참여형 검증 (human-in-the-loop validation)을 요구하거나 독립적인 암호화 검증 체크를 통과하도록 합니다. 4. 정책 트레이스 (The Policy Trace) 비결정론적 파이프라인 (non-deterministic pipeline)이 애플리케이션 상태를 깨뜨릴 때, 표준 비구조화 syslog 파일이나 비구조화 텍스트 블록은 디버깅에 무용지물입니다. 여러분에게는 결정론적이고 고도로 구조화된 진단 관측성 (diagnostic observability)이 필요합니다. 정책 트레이스는 전체 실행 주기에 대한 불변의 단계별 감사 기록 (audit record) 역할을 합니다: 상태 및 토큰 아카이빙 (State & Token Archiving): 정확한 시스템 프롬프트 상태, 원시 토큰 유입 구조 (raw token ingress structures), 일치하는 정책 트리거, 중간 함수 페이로드, 그리고 정확한 Execution Gate 응답을 캡처합니다. 결정론적 재현성 (Deterministic Reproducibility): 실행 로그를 결정론적 재생 그래프 (deterministic replay graphs)로 구조화하여, 엔지니어가 정확한 실패 파라미터를 개발 환경에 다시 입력하고, 아키텍처 누출을 격리하며, 정책 설정을 패치할 수 있도록 합니다. 이론에서 코드 베이스로의 이동 수동적인 검증에서 능동적인 런타임 집행 (runtime enforcement)으로 전환한다는 것은 보안 로직을 데이터 경로 (data path)로 직접 이동시키는 것을 의미합니다. 비동기식 크론 (cron) 체크나 대역 외 (out-of-band) 평가를 실행하는 대신, 저지연 인프라를 구축해야 합니다: 인라인 네트워크 프록시 (Inline Network Proxies): 악성 페이로드를 제거하거나 규정 준수하지 않는 호출을 중단하기 위해, 오케스트레이션 계층 (orchestration layer)에 도달하기 전 원시 HTTP/gRPC 요청을 가로챕니다.

분리된 정책 엔진 (Decoupled Policy Engines): 검증 로직을 격리된 엔진(Open Policy Agent 또는 특화된 WASM 모듈 등)으로 오프로딩(offloading)하여, 정책 변경 시 핵심 애플리케이션을 재배포할 필요가 없도록 합니다. 런타임 인터셉터 (Runtime Interceptors): 에이전트의 도구 호출 (tool-calling) SDK에 결정론적 훅 (deterministic hooks)을 주입하여, 실행 커널 (execution kernel)이 함수 인자를 트리거하기 전에 이를 가로채고, 검사하며, 변형(mutate)합니다. 저는 현재 Open AI Guardrails에서 바로 이 런타임 스택을 위한 기술 아키텍처, 핵심 프록시(proxies) 및 SDK 통합을 개발하고 있습니다. 만약 여러분이 현재 런타임 검증을 위한 미들웨어를 작성 중이거나, 정책 규칙을 코드로 컴파일하거나, 에이전트 워크플로 (agentic workflows)를 위한 결정론적 격리 경계 (deterministic isolation boundaries)를 구축하고 있다면, 지연 시간 (latency) 트레이드오프를 어떻게 처리하고 계신지 정말 알고 싶습니다. 아래 댓글에서 구현 세부 사항에 대해 이야기해 봅시다.