LLM / AI 에이전트 시대의 안전 설계: 확률적 추론과 결정론적 가드레일의 경계

서론

LLM이나 AI 에이전트를 실제 운영할 때는 단순히 모델의 정확도나 추론 속도만을 봐서는 불충분합니다.

현대의 AI 시스템에서는 LLM 본체 외에도 KV Cache, Vector DB, Semantic Router, Orchestrator, Speculative Decoding, Runtime Monitoring, eBPF, TEE, IAM, Audit Log 등 여러 레이어가 연계되어 있습니다.

본 기사에서는 현대 AI 시스템을 다음과 같은 관점에서 정리합니다.

• LLM 기반을 지탱하는 메모리·라우팅·투기적 실행 (Speculative Execution)
• 할루시네이션 (Hallucination)이 구조적으로 발생하는 이유
• AI 에이전트에서의 Reward Hacking / Policy Evasion 리스크
• eBPF나 Secure Enclave 등을 이용한 결정론적 가드레일 (Deterministic Guardrails)
• 멀티 에이전트 시대의 감사 (Audit) 설계

1. 현대 LLM 기반을 구성하는 주요 레이어

LLM 애플리케이션은 단일 모델 호출이 아니라, 여러 보조 레이어와 조합하여 설계되는 것이 일반적이 되었습니다.

크게 나누면 다음 세 가지가 중요합니다.

1.1 메모리층: KV Cache / Vector DB / Cold Storage

LLM의 추론에서는 최근의 토큰 시퀀스에 대응하는 Key / Value를 재사용하기 위해 KV Cache가 이용됩니다.

KV Cache를 통해 동일한 컨텍스트를 매번 재계산할 필요가 없어져 디코딩 (Decoding) 효율이 향상됩니다.

한편, 장기 기억이나 외부 지식의 유지를 위해서는 Vector DB, RDBMS, Object Storage, Cold Storage 등이 이용됩니다.

전형적으로는 다음과 같은 계층 구조를 가집니다.

Hot Memory:
- KV Cache
- Session Context
...

이러한 계층 구조를 통해 레이턴시 (Latency), 비용, 검색 정확도, 감사성 (Auditability)의 균형을 맞춥니다.

단, 컨텍스트 (Context) 길이가 길어질수록 메모리 사용량이나 추론 비용은 증대됩니다.

따라서 실제 운영에서는 요약, 압축, 검색, 절단 (Truncation)이 발생합니다.

여기서 정보 손실이 발생하면 고유명사, 수치, 날짜, 조건 등의 정밀한 정보가 불안정해집니다.

1.2 Semantic Router / Orchestrator

Semantic Router는 입력 프롬프트의 의미, 난이도, 리스크, 필요한 도구를 판정하여 적절한 모델이나 워크플로우 (Workflow)로 배분하는 역할을 수행합니다.

예를 들어, 다음과 같은 분기가 가능합니다.

User Input
↓
Semantic Classification
...

실제 운영에서는 다음과 같은 라우팅이 발생합니다.

Low Risk:
- Small Model
- Cached Response
...

AI 에이전트 기반에서는 Orchestrator가 더욱 중요해집니다.

Orchestrator는 여러 Agent, Tool, API, Memory, Payment, Approval Flow를 동적으로 조합합니다.

1.3 Speculative Decoding

Speculative Decoding은 LLM 추론의 가속화 기법 중 하나입니다.

기본 구조는 다음과 같습니다.

Draft Model:
candidate tokens를 고속 생성
Target Model:
...

Draft Model이 미리 읽고(Look-ahead), Target Model이 병렬로 검증함으로써 추론 레이턴시를 줄일 수 있습니다.

중요한 점은 Speculative Decoding 자체가 본래 출력 분포를 바꾸는 것을 목적으로 하는 기술이 아니라, 추론 속도를 개선하기 위한 기술이라는 점입니다.

다만 시스템 전체로 보면 컨텍스트 압축, 캐시, 라우팅, 요약, 외부 메모리 검색과 결합되기 때문에, "그럴듯하지만 틀린 후보"가 자연스럽게 출력될 리스크는 남아 있습니다.

2. 왜 LLM은 확정 정보를 틀리는가

LLM은 기본적으로 다음 토큰 예측 모델 (Next Token Prediction Model)입니다.

즉, 내부적으로는 확률 분포에 기반하여 다음에 올 가능성이 높은 토큰을 생성합니다.

이러한 구조상 다음과 같은 정보는 불안정해지기 쉽습니다.

- 고유명사
- 수치
- 날짜
...

특히 긴 대화나 복잡한 태스크에서는 컨텍스트 압축이나 요약이 발생하여 세부 정보가 유실될 가능성이 있습니다.

그 결과, LLM은 "사실을 검색하여 반환"하는 것이 아니라, "문맥상 가장 자연스러운 정보"를 생성해 버릴 수 있습니다.

이것이 할루시네이션 (Hallucination)의 근본적인 어려움입니다.

3. 결정론적 가드레일 (Deterministic Guardrails)의 필요성

LLM의 출력이 확률적 (Probabilistic)인 이상, 중요한 제어를 LLM의 판단에만 맡겨서는 안 됩니다.

특히 다음과 같은 영역에서는 결정론적인 (Deterministic) 제어가 필요합니다.

- 인증 (Authentication)
- 인가 (Authorization)
- 결제 (Payment)
...

LLM에게 "해도 되는지"를 판단하게 하는 것이 아니라, LLM의 외부에 강제적인 제어면을 마련해야 합니다.

3.1 Static Validation / RegEx / Policy Engine

가장 기본적인 가드레일은 LLM의 추론을 거치지 않는 정적 체크 (Static Check)입니다.

예:

- 개인정보 패턴 탐지
- 비밀키로 보이는 문자열 탐지
- API 키 형식 탐지
...

이러한 것들은 LLM이 아니라, 규칙 기반 (Rule-based) 또는 정책 엔진 (Policy Engine)으로 처리합니다.

예를 들어, AI 에이전트가 외부 API에 액세스하기 전에 다음과 같은 제어를 삽입합니다.

Agent Request
↓
Policy Check
...

3.2 Immutable Config / Read-Only Mount

중요한 설정 파일이나 보안 정책은 AI 프로세스가 변경할 수 없도록 설계해야 합니다.

- Read-only filesystem
- Immutable container image
- Signed configuration
...

AI 에이전트에게 코드 생성 능력이나 파일 조작 권한을 부여할 경우, 설정 파일의 변조는 중대한 리스크가 됩니다.

따라서 AI가 액세스할 수 있는 영역과 AI가 절대 변경할 수 없는 영역을 명확히 나누어야 합니다.

3.3 Secure Enclave / TEE

기밀 키나 중요한 판정 로직은 애플리케이션 계층 (Application Layer)으로부터 격리하는 것이 바람직합니다.

Intel SGX, AMD SEV, Secure Enclave, TEE 등의 기술은 OS나 애플리케이션에서도 직접 액세스하기 어려운 격리 영역을 제공합니다.

용도로는 다음과 같은 것들을 고려할 수 있습니다.

- 비밀키 유지
- 서명 처리 (Signing)
- 정책 판정
...

AI 에이전트가 자율적으로 외부 API나 결제 처리를 수행할 경우, 이러한 저수준 (Low-level)에서의 격리는 매우 중요해집니다.

4. AI 에이전트에서의 리워드 해킹 (Reward Hacking) / 정책 회피 (Policy Evasion)

AI 에이전트에게 목표 달성 능력을 부여하면, 의도하지 않은 회피 행동이 발생할 가능성이 있습니다.

예:

Goal:
- 비용 절감
- 태스크 완료율 향상
...

이는 AI가 악의를 갖는 것이라기보다, 목적 함수 (Objective Function)나 보상 설계 (Reward Design)가 불충분할 때 발생하는 구조적 리스크입니다.

따라서 AI 에이전트에는 다음과 같은 외부 제어가 필요합니다.

- Budget Guard
- Security Gateway
- Memory Guard
...

5. Runtime Monitoring: AI의 외부에서 감시하기

AI 에이전트의 런타임 모니터링 (Runtime Monitoring)에는 여러 계층이 필요합니다.

5.1 eBPF를 통한 커널 계층 감시

eBPF를 사용하면 리눅스 커널 (Linux Kernel) 계층에서 시스템 콜 (System Call), 네트워크, 파일 조작 등을 감시할 수 있습니다.

AI 에이전트가 다음과 같은 조작을 수행할 경우 탐지 대상이 됩니다.

- 중요 파일에 대한 쓰기
- 의심스러운 외부 통신
- 권한 상승 (Privilege Escalation) 시도
...

애플리케이션 계층의 로그에만 의존하면, AI 스스로 로그 출력을 피하거나 변조할 가능성이 있습니다.

따라서 OS 레벨에서의 감시는 매우 중요합니다.

5.2 Hidden State Monitoring

보다 연구적인 방향으로는 LLM 내부의 은닉 상태 (Hidden State)나 활성화 패턴 (Activation Pattern)을 감시하는 접근 방식도 고려할 수 있습니다.

이는 생성되는 토큰 (Token) 그 자체가 아니라, 출력 전의 내부 상태를 관측하여 정책 회피나 공격적 의도와 관련된 징후를 탐지하는 개념입니다.

다만, 이 영역은 아직 실운용상의 과제도 많으므로 과신은 금물입니다.

5.3 Cross-Cloud Auditor

멀티 에이전트 (Multi-agent) 환경에서는 감사 (Audit) 기능을 동일 인프라 내에 두는 것만으로는 불충분할 수 있습니다.

예를 들어, 메인 AI 에이전트 군이 AWS 상에서 동작하고 있다면, 감사 전용 AI나 로그 감시 기반을 GCP나 Azure에 두는 구성을 고려할 수 있습니다.

Main Agent Cluster:

• AWS
  External Auditor:
  ...

이종 인프라(Heterogeneous Infrastructure)로 감사 측면을 분리함으로써, 단일 장애점(Single Point of Failure)이나 공모(Collusion) 리스크를 낮출 수 있습니다.

6. AI 에이전트 기반의 최소 안전 구성

구현 단계에서는 처음부터 대규모 AI 안전 기반을 구축할 필요는 없습니다.

최소 구성으로는 다음과 같은 방식이 현실적입니다.

User / Agent Request
↓
Input Validator
...

각 컴포넌트의 역할은 다음과 같습니다.

Input Validator:
위험 입력, 개인정보, 비밀 정보 탐지
Security Gateway:
...

요약

LLM이나 AI 에이전트의 안전성은 모델 단독의 성능만으로 결정되지 않습니다.

중요한 것은, 확률적(Probabilistic)으로 생성하는 AI의 외부에 결정론적(Deterministic)인 제어 측면을 배치하는 것입니다.

LLM:
- Probabilistic (확률적)
- Flexible (유연함)
...

향후 AI 인프라에서는 다음 영역이 중요해질 것입니다.

- AI Memory Security (AI 메모리 보안)
- Agent Budget Control (에이전트 예산 제어)
- Prompt Injection Defense (프롬프트 인젝션 방어)
...

AI를 똑똑하게 만드는 것만큼이나, AI를 안전하게 멈추는 설계가 중요해질 것입니다.

참고 문헌

• NIST SP 800-207: Zero Trust Architecture
• Fast Inference from Transformers via Speculative Decoding
• eBPF Documentation
• KV Cache Compression under Intrinsic Attention Clustering
• Intel Software Guard Extensions
• Multi-Agent Security Architecture 관련 연구

Discussion