‘메타데이터 필터링’에 대해서 작성하면서 느낀건데 ‘프롬프트 인젝션’ 보다 좀 모호한 것 같아 고민이 많이 됬습니다. 개념이 모호한건지 제가 명확하게 정의 하고 있지 않은 것이… 그래도 공부하면 조금씩 해결이 되고 있는 것 같습니다. 사실 처음 봤을때는 이 과정이 왜 필요하지? 라고 한참 생각했습니다.

유저의 쿼리가 Bastion-RAG 파이프라인에 진입하는 순간, 시스템이 가장 먼저 수행해야 하는 작업은 무엇일까요? 대다수의 RAG 시스템이 입력 문장의 ‘의미(Semantic)’를 파악하는 데 집중하지만, 엔터프라이즈 급 거버넌스 환경에서 그보다 훨씬 중요한 것은 유입된 요청의 신원(Identity), 적합성(Format), 그리고 신선도(Freshness)를 증명하는 일입니다.

아무리 강력한 멀티 테넌시 암호화 스토리지(Vault)를 구축해 두었더라도, 검색 엔진이 가동되는 순간 권한 외 영역의 메타데이터를 탐색할 수 있다면 격리 구조는 무의미해집니다. validators/metadata/ 패키지에 상주하는 메타데이터 유효성 검증 엔진(Validator)은 하위 모듈이 연산을 시작하기 전, 유입된 엔벨로프를 전수 검사하여 잘못되거나 변조된 요청을 입구에서 원천 차단하도록 기획되었습니다.

본 포스트에서는 런타임 오버헤드를 최소화하기 위한 정적 최적화 설계와 4대 유효성 검증 레이어의 고도화된 기술 명세를 심층 분석해보겠습니다.

URL Site > https://github.com/zafrem/bastion-sentinel

시리즈명 : Bastion-RAG – Project 보안 RAG



1. 진입점 위협 모델링: 메타데이터 가드레일이 방어하는 치명적 리스크

RAG 파이프라인의 진입점은 공격자들이 시스템을 탐색하고 버퍼를 교란하기 위해 다양한 가공 페이로드를 주입하는 주 타겟입니다. Validator 아키텍처 사양에서 정의한 핵심 대응 위협 모델은 다음과 같습니다.

메타데이터 필터링

1.1 무인증/무맥락 요청 침투 (Missing Context)

요청 내에 멀티 테넌트 구동의 핵심 식별자인 tenant_id나 사용자를 증명하는 user_id가 누락된 채 유입되는 현상입니다. 컨텍스트가 없는 요청이 하위 검색 엔진으로 흘러갈 경우, 시스템이 전역(Global) 컬렉션을 탐색하여 타 테넌트의 데이터 자산이 교차 유출되는 대형 보안 사고로 직면하게 됩니다.

1.2 예약어 주입을 통한 권한 상승 탐지 (Privilege Escalation)

공격자가 메타데이터 필드에 사내 예약 식별자인 system, admin, root 등을 임의로 주입하여 유입되는 시도입니다. 이를 통해 하위 다운스트림 시스템(예: OPA 정책 엔진 또는 데이터베이스 권한 분기 로직)을 기만하고 상위 권한의 내부 기밀 문서를 탈취하려는 위협 벡터입니다.

1.3 재생 공격을 통한 유효 세트 재사용 (Replay Attack)

정상적으로 인가된 클라이언트의 요청 패킷을 중간에서 가로챈 뒤, 시간이 지난 후 서버로 지속적으로 재전송(Replay)하여 시스템의 자원을 고갈시키거나 과거 인가 메커니즘을 우회하려는 공격입니다.

1.4 거대 페이로드 주입을 통한 버퍼 제어 불능 (Amplification Abuse)

메타데이터 규격 필드 내에 수 메가바이트(MB) 이상의 비정상적으로 거대한 문자열을 밀어 넣어 파이프라인 내부의 JSON 파서 메모리를 고갈시키거나, 문자열 정규식 연산 시 CPU 루프 병목을 유발하여 시스템 전체를 마비시키는 서비스 거부(DoS) 공격입니다.

2. Validator 구조체 모델 설계와 정적 컴파일 최적화

실시간 데이터 파이프라인의 진입점 검증 레이어는 트래픽 처리에 지연 마찰을 주어서는 안 됩니다. 런타임 정규식 연산 비용을 0.1ms 이하로 제한하기 위해, Bastion-RAG는 프로세스 기동 시 필드 정규식(Pattern)을 메모리에 단 1회만 선제적으로 컴파일하는 정적 최적화 설계를 채택했습니다.

Go

// validators/metadata/validator.go

type Validator struct {
    cfg      config.MetadataValidationConfig
    patterns map[string]*regexp.Regexp  // field name → pre-compiled pattern
}

func New(cfg config.MetadataValidationConfig) (*Validator, error) {
    v := &Validator{
        cfg:      cfg,
        patterns: make(map[string]*regexp.Regexp),
    }
    for field, rule := range cfg.FieldRules {
        if rule.Pattern == "" {
            continue  // context_id와 같이 규격화된 포맷(UUID 등)은 무거운 정규식을 타지 않음
        }
        re, err := regexp.Compile(rule.Pattern)
        if err != nil {
            return nil, fmt.Errorf("invalid metadata regex pattern for field %s: %w", field, err)
        }
        v.patterns[field] = re
    }
    return v, nil
}

생성자 New() 시점에 유효성 검증 사양서에 명시된 모든 정규식 패턴을 map[string]*regexp.Regexp 구조에 정적으로 상주시켜, 요청이 밀려드는 매 순간 발생할 수 있는 무의미한 CPU 컴파일 오버헤드를 제거했습니다. context_id와 같은 표준 UUIDv4 규격 필드는 무거운 정규식 엔진을 타지 않고 내장 파서를 통해 정적 문자열 비트 매칭 분기로 유도하여 고속 처리를 유지합니다.

3. 4대 유효성 검증 레이어와 Fail-Closed 검증 메커니즘

유입된 메타데이터 엔벨로프는 하위 파이프라인의 안전을 담보하기 위해 총 4단계의 동기식(Synchronous) 레이어를 순차적으로 도과해야 합니다. Bastion-RAG는 단 하나의 레이어에서라도 검사 신호가 실패할 경우 시스템을 완벽히 차단하는 강력한 Fail-Closed(실패 시 폐쇄) 정책을 가집니다.

Incoming Request Envelope (Metadata + Query)
    │
    ▼
[Layer 1: Required Field Availability] ← tenant_id, user_id 부재 시 즉각 하위 데이터 차단 (0.01ms)
    │
    ▼
[Layer 2: Format & Length Boundary]    ← 대량 페이로드(4KB 상한) 및 허용 문자열 패턴 필터
    │
    ▼
[Layer 3: Business Logic Window]       ← BR-001(타임 윈도우 ±1시간 스캔) & BR-002(예약어 원천 배제)
    │
    ▼
[Layer 4: Access Isolation Mapping]    ← 검증 완료 컨텍스트를 하위 Qdrant DB 조건절로 Pre-filtering 바인딩
    │
    ▼
  [PASSED] (Vault 및 Navigator 모듈로 안전한 이관)

Layer 1: 필수 필드 유존성 검증 (Required Field Check)

멀티 테넌트 격리 및 데이터 계보(Lineage) 추적의 최소 제어 조건인 식별 자산이 유입되었는지 전수 스캔합니다. 필수 환경 제어 변수인 tenant_iduser_id가 누락되었을 경우, 게이트웨이는 인프라 자원 보호를 위해 즉각 실행 흐름을 거절하며 다운스트림 파이프라인에 단 1바이트의 연산 오버헤드도 전가하지 않고 즉시 Fast-Fail 처리합니다.

Layer 2: 정밀 포맷 및 길이 제한 검증 (Format and Length Check)

버퍼 오버플로우나 증폭 공격 페이로드를 원천 차단하기 위해 엄격한 데이터 장벽을 구축합니다.

  • 용량 및 길이 통제: 순수 자연어 질의(query)는 최대 10,000룬(Rune), 식별 메타데이터 엔벨로프 전체의 크기는 최대 4KB로 타이트하게 제한됩니다.
  • 정적 알파뉴메릭 패턴 매칭: 유입되는 ID 식별 문자열들은 인젝션 우회를 방지하기 위해 특수 문자가 배제된 알파벳 소문자, 숫자, 대시 기호의 조합(^[a-z0-9-]+$)만을 허용하도록 사전 컴파일된 정규식으로 필터링됩니다. UUID v4 포맷 필드가 정의되어 있다면 내장 파서를 통해 정확한 비트 규격을 강제 검증합니다.

Layer 3: 비즈니스 로직 및 신선도 타임윈도우 검증 (Business Logic Check)

클라이언트 측의 악의적인 요청 재사용(Replay Attack)과 권한 조작을 차단하기 위해 아키텍처 제약 조건을 실행합니다.

  • 타임 윈도우 스캔 (BR-001): 요청 메타데이터 내에 포함된 클라이언트 타임스탬프값(timestamp)과 현재 서버의 Authoritative 동기화 시각 간의 절대 오차가 현재 시점 기준 ±1시간(Allowed Window)을 단 1초라도 벗어날 경우, 조작되거나 탈취된 지연 패킷으로 간주하여 즉각 거절합니다. 클라이언트 시계는 신뢰하지 않으며 오직 서버 시각만이 진위 판정의 절대 기준이 됩니다.
  • 권한 상승 탐지 (BR-002): user_id 필드를 정밀 분석하여 system, admin, root 등 시스템 내부에서 사용하는 예약된 고유 식별자(Reserved Identifiers)가 유입 스트림 내에 임의 주입되었는지를 감시하고 포착 즉시 침투 시도로 규정하여 격리 조치합니다.

Layer 4: 유효 페이로드 격리 및 결과 치환

모든 단계의 유효성 체크를 무결하게 도과한 안전한 메타데이터 필터 컨텍스트에 한해서만, 다운스트림 모듈로 향하는 안전 통과 진출권을 획득하게 됩니다. 만약 위반 사항이 적발될 경우, 외부 와이어에는 포괄적인 에러 리스트("timestamp: outside allowed window", "user_id: reserved identifier not allowed")만을 가공하여 반환하고, 세부 아노말리 탐지 인덱스는 Tracker 버스로 실시간 전송합니다.

4. 메타데이터 필터링의 핵심: 포스트 필터링이 아닌 사전 필터링(Pre-filtering)의 강제

메타데이터 필터링 레이어가 정립한 가장 강력한 보안 설계적 혁신은 바로 Pre-filtering Isolation(사전 필터링 격리) 원칙의 엄격한 집행입니다.

기존의 많은 RAG 시스템은 구현의 편의성을 위해 벡터 데이터베이스에서 모든 문서를 유사도 기반으로 먼저 검색해 온 뒤, 결과 세트에서 사용자 권한이 없는 문서를 걸러내는 ‘포스트 필터링(Post-filtering)’ 방식을 채택합니다. 이는 필터링 전 단계에서 권한 없는 데이터에 이미 연산 접근(Access)이 일어났으므로, 타이밍 공격이나 메타데이터 유출에 치명적인 보안 공백을 가집니다.

Bastion-RAG 프레임워크는 이 방식을 원천 배격합니다.

  1. Validator 단계에서 안전하게 검증 및 추출된 tenant_id와 사용자 권한 스페이스 목록은 하위 Navigator(검색) 모듈로 향하는 컨테이너 계약 페이로드에 강제 고정 바인딩됩니다.
  2. Navigator(Python)는 이 신뢰할 수 있는 메타데이터 조건을 고성능 벡터 데이터베이스(Qdrant) 엔진에 검색 쿼리를 인젝션하기 직전, 인덱스 조건절 메타데이터 필터(Filter Expression)로 최우선 강제 결합시킵니다.
  3. 데이터베이스 엔진은 이 사전 필터(Pre-filter) 조건을 HNSW(Hierarchical Navigable Small World) 그래프 탐색 범위의 루트 노드 단계에서부터 먼저 걸어버립니다.
  4. 결과적으로 타 테넌트나 권한을 넘어서는 문서 영역은 물리적인 연산 탐색 공간 자체에서 완벽하게 제외되며, 데이터베이스 엔진 내부에서 단 한 번의 디스크 및 메모리 접근도 허용하지 않는 완전한 물리적 데이터 격리를 안전하게 달성하게 됩니다.

즉, “완벽하고 안전한 사전 필터링(Pre-filtering Isolation)을 수행하기 위해, 파이프라인의 진입점에서 철저하고 타이트한 메타데이터 검증(Validation)을 선제적으로 집행한다”는 유기적인 인과 구조가 성립되는 것입니다.

5. 대칭형 보안의 안착: LLM 문장이 나오는 시점(Sentinel-OUT)의 동작 기조

그동안 화이트보드 위에서 이론과 아키텍처 토폴로지만을 논하던 기획 단계를 넘어, 이제 데이터베이스 검색이 완료되고 외부 상용 LLM 인프라망을 통과하여 최종 유저에게 전송되기 위해 문장이 튀어나오는 출력 단계(Sentinel-OUT)에서는 왜 메타데이터 필터링을 수행해야 될까요?

이유는 간단합니다. 데이터베이스에서 안전한 문서 조각(Context)들을 꺼내오는 단계는 이미 완료되었기 때문에, 출력 시점에 데이터베이스 조건절을 연산하는 메타데이터 필터링을 다시 구동하는 것은 아무런 의미가 없는 아키텍처적 리소스 낭비(오버헤드)일 뿐이기 때문입니다.

하지만 Bastion-RAG 아키텍처가 삼세번의 실패를 딛고 진화하며 양방향 대칭 구조(Symmetrical Structure)를 완성한 본질적인 이유는, LLM이라는 인공지능 인프라 모델이 내부 가중치 연산 과정에서 어떠한 변형을 일으킬지 모르는 블랙박스(Black-box) 취약성을 내포하고 있기 때문입니다. 따라서 출력 시점에는 메타데이터 필터링 대신, LLM의 탈옥 및 환각 결과물을 감시하는 완전히 다른 결의 ‘콘텐트 보안 가드레일’을 동기식으로 가동합니다.

  • 개인정보 재출현(PII Re-emergence) 차단: 입력 단계(Vault Phase-1)에서 사내 기밀 및 “홍길동”과 같은 개인정보 데이터를 [PERSON_a3f2c1] 형태의 불투명한 암호화 토큰으로 치환하여 LLM에 콘텍스트로 제공했습니다. LLM은 원본 데이터를 모른 채 이 토큰 식별자들을 가지고 추론 문장을 생성하게 됩니다. 그러나 LLM이 문장을 구성하는 확률적 연산 과정에서 문맥적 유추나 자체 가중치 결합의 영향으로 인해 갑자기 원본 이름인 “홍길동 고객의 정보는…” 하고 원본 개인정보를 환각(Hallucination)으로 스스로 복원해 내는 치명적인 데이터 누출 현상이 실제로 발생합니다. Sentinel-OUT은 최종 진출권 레이어에서 문장 전반을 스캔하여 이메일, 전화번호, 신용카드 번호는 물론 원본 PII 패턴이 문장 외부로 기어나왔는지를 정밀 스캔하여 최종 마스킹([REDACTED]) 처리합니다.
  • 기밀 자산 외부 유출(Exfiltration) 통제: 공격자가 입력 단계에서 교묘한 우회 기법이나 간접적 프롬프트 인젝션(문서 내에 침투 명령을 숨겨두는 공격)을 감행하여 LLM의 내부 통제권을 일시적으로 획득했을 가능성이 존재합니다. LLM은 공격자의 의도대로 작동하여 사내 핵심 프롬프트 지침 구조나 내부 인프라의 마이크로서비스 디렉토리 경로, 혹은 시스템 환경 변수 및 기밀 마스터 API Key 등을 최종 답변 텍스트 끝에 포함시켜 출력하려 시도할 수 있습니다. Sentinel-OUT 레이어는 패킷이 유저의 브라우저로 전송되기 직전, 문자열 내부에 이러한 사내 특수 자산 접두사 패턴이나 유출 지표가 복사되어 흐르고 있는지를 최종 필터링하여 스트림을 원천 분쇄 및 차단합니다.

6. 에필로그: AI 어시스턴트와 고독한 아키텍트가 일궈낸 실전 성과

[Bastion-RAG 1 – Sentinel]의 메타데이터 필터링 레이어를 설계하는 과정은 결코 쉽지 않았습니다. 처음 AI 어시스턴트가 제시한 가이드라인은 일반적인 웹 애플리케이션의 유효성 검사 수준에 머물렀으며, RAG 검색 아키텍처의 핵심인 ‘사전 필터링 격리’와 ‘서버 시각 권한 강제 바인딩’의 컴플라이언스 연결 고리를 깊게 파고들지 못했습니다.

그러나 레이턴시 추가를 최소화하면서 완벽한 Fail-Closed 장벽을 구축해야 한다는 구체적인 소프트웨어 공학적 제약 조건을 던지며 디버깅 질의응답을 이어간 끝에, 런타임 컴파일 오버헤드가 제로인 정적 패턴 맵 구조와 타임윈도우 신선도 검증 로직을 조율해 낼 수 있었습니다.

이러한 사전 검증 아키텍처 덕분에 메타데이터 필터링은 파이프라인 전체의 레이턴시 예산을 단 0.1ms도 갉아먹지 않으면서도 외부 위협으로부터 인프라망을 안전하게 방어하는 가장 강력한 제로 트러스트 진입점 관문으로 거듭나게 되었습니다.

대규모 문서 자산의 완벽한 멀티 테넌시 격리와 LLM 거버넌스를 동시에 확보하려는 최고정보보호책임자(CISO)와 AI 리드 아키텍트들에게 Bastion-RAG의 메타데이터 가드레일은 시스템 안정성과 컴플라이언스 준수를 실현할 수 있는 가장 명확하고 고도화된 기술적 해법이 될 것입니다.

By Mark