LLM을 래핑(Wrap)하지 마세요. 실패 모드(Failure Modes)에 도달할 수 없게 만드세요.

현대적인 생성형 AI (GenAI) 제품에는 Martin Fowler와 Venkat Subramaniam의 9가지 패턴에서 해결책을 찾을 수 없는 일종의 버그 클래스가 존재합니다. 바로 채팅 인터페이스를 통해 도구(Tool)로 전달되는 프롬프트 인젝션 (Prompt Injection)입니다. 표준적인 완화 방법은 사용자의 프롬프트를 또 다른 LLM (가드레일 (Guardrail))을 통해 보내어, 해당 프롬프트가 악의적인지 여부를 결정하게 하는 것입니다. 하지만 그 가드레일은 자신이 보호하려는 모델과 동일한 속성을 가집니다. 즉, 비결정론적 (Non-deterministic)이며, 환각 (Hallucination)에 취약하고, 자신이 잡아내야 할 바로 그 기술들에 속을 수 있습니다. 당신은 신뢰할 수 없는 시스템에 신뢰할 수 없는 검사기를 추가한 것입니다. 치명적인 실패의 확률은 낮아졌을지 모르지만, 그 구조적 가능성 자체는 사라지지 않았습니다.

저는 방금 반대 방향의 통합 작업을 마쳤습니다. 제가 단독으로 구축해 온 클라우드 보안 추론 엔진인 Stave의 AI 에이전트 인터페이스는 Model Context Protocol (MCP) 서버를 통해 자신의 기능을 노출합니다. 에이전트는 search, diff, gaps, readiness

패턴	대상	감소시키는 요소
RAG	LLM이 잘못된 정보를 알고 있음	도메인 질문에 대한 환각 (Hallucination)
...

만약 여러분이 챗봇, 대화형 검색 어시스턴트, 또는 사용자가 LLM과 직접 대화하는 형태의 제품을 만들고 있다면, 이러한 패턴들은 필수적입니다. 이는 출력을 사전에 제약할 수 없는 생성 모델 (Generative Model)로부터 프로덕션 수준의 신뢰성을 확보하는 방법입니다. 저는 이 패턴들을 반대하는 것이 아닙니다.

제가 주장하는 바는, 이 패턴들이 어떤 상황에서는 완전한 해답이 되지만, 또 다른 상황에서는 위험한 반쪽짜리 해답이 된다는 것입니다.

진단: 비결정론(Non-determinism)을 비결정론으로 래핑하는 것은 결정론(Determinism)으로 수렴하지 않는다

이 아홉 가지 패턴을 기능(Feature)이 아닌 아키텍처(Architecture)로 읽으십시오. 모든 패턴은 동일한 형태를 띠고 있습니다. 즉, 비결정론적인 시스템 (LLM)이, 래핑된 시스템을 더 안전하게 만들기 위해 또 다른 비결정론적인 구성 요소 (더 많은 LLM 호출, 또는 보정(Calibration)이 드리프트되는 스코어링 함수)에 의해 래핑되어 있다는 점입니다.

패턴	무엇이 무엇을 래핑하는가
RAG	LLM (답변)이 LLM 또는 임베딩 (검색)을 래핑함
...

각 래핑 계층은 특정 실패의 _확률(Probability)_을 줄여줍니다. 하지만 그 어떤 것도 _가능한 실패의 범위(Space of possible failures)_를 바꾸지는 못합니다. 가드레일(Guardrail) LLM은 메인 LLM을 탈옥(Jailbreak)시키는 것과 동일한 프롬프트에 의해 탈옥될 수 있습니다. 판사(Judge) LLM은 판결 대상이 되는 LLM과 동일한 방식으로 환각을 일으킬 수 있습니다. 리랭커(Reranker)는 어떤 문서가 관련 있는지에 대해 확신을 가지고 틀릴 수 있습니다. 계층을 더 많이 추가하는 것은 중앙값(Median) 케이스에서는 확률적으로 시스템을 더 안전하게 만들지만, 치명적인 실패의 꼬리 부분(Tail of catastrophic failures)은 구조적으로 변하지 않은 채로 남겨둡니다.

챗봇의 경우에는 괜찮습니다. 가끔 발생하는 잘못된 출력의 비용은 나쁜 사용자 경험(User Experience)일 뿐이며, 이는 명확한 질문이나 재시도를 통해 복구할 수 있습니다. 하지만 출력이 증명 가능하게 정확해야(provably correct) 하는 제품들 — 커밋되는 코드, 배포되는 인프라, 프로덕션 릴리스를 제어하는 보안 판정 — 의 경우, 중앙값(Median)보다 꼬리 부분(Tail)이 더 중요합니다. 실패 확률이 0에 가까워진다고 해서 실패 가능성이 제거된 것은 아닙니다. 그리고 앞서 언급한 패턴들은 그 기저(Substrate)가 구조적으로 비결정론적(Non-deterministic)이기 때문에 실패 가능성을 제거할 수 없습니다.

이것은 LLM에 대한 비판이 아닙니다. 출력이 감사 가능해야(Auditable) 하는 시스템에서 LLM을 _하중을 견디는 추론 요소(Load-bearing reasoning element)_로 사용하는 것에 대한 비판입니다. 역할이 잘못되었으며, 아무리 래핑(Wrapping)을 해도 잘못된 역할은 고칠 수 없습니다.

구조적 대안: 준수해야 할 사항을 선언하고, 결정론적으로 검증하며, 실행을 제어하라

훨씬 더 오래된 계보를 가진 다른 아키텍처 패턴이 있습니다. 이는 LLM보다 오래되었고, 소프트웨어보다 오래되었으며, 컴퓨팅보다도 오래되었습니다. 시스템 안전 공학(Systems Safety Engineering, IEC 61508, DO-178C)에서 유래한 방식은 다음과 같습니다: 시스템이 반드시 만족해야 하는 불변량(Invariants)을 선언하고, 그것이 유지되는지 기계적으로 검증하며, 해당 검증을 통과해야만 실행을 제어(Gate)하는 것입니다. 항공 분야가 이를 수행합니다. 거래 전 금융 리스크 체크도 이를 수행합니다. 산업용 안전 계장 시스템(Safety Instrumented Systems)도 이를 수행합니다. 도요타 생산 방식(Toyota Production System)은 이 제조 버전의 방식을 jidoka — 자율화(Autonomation), 즉 인간의 손길이 닿은 자동화 — 라고 불러왔습니다. 이는 사키치 도요다의 1902년 자동 직기가 단 하나의 실이 끊어지는 즉시 직조를 멈춘 이래로 이어져 왔습니다. 그 직기 이전에는 실이 끊어지면 기계가 계속 작동하여 엄청난 양의 망가진 천을 만들어냈고, 결함은 작업이 끝난 후 검사를 통해서야 발견되었습니다. 도요다의 메커니즘은 이 순서를 뒤집었습니다: 근원에서 결함을 감지하고, 즉시 라인을 멈추며, 결함이 있는 제품이 아예 존재하지 못하도록 방지하는 것입니다.

그 4단계의 형태 — 자동으로 감지하고(detect automatically), 즉시 중단하며(stop immediately), 문제를 해결하고(fix the problem), 근본 원인을 조사하는(investigate the root cause) 것 — 은 Toyota Production System (TPS)의 두 기둥 중 하나가 되었습니다 (다른 하나는 Just-In-Time입니다). 직조기는 더 열심히 노력하지 않았습니다. 다른 직조기에게 조언을 구하지도 않았습니다. 결함이 있는 천을 계속 생산하는 것을 거부했습니다. 결함은 결정론적 테스트(deterministic test, 예: 끊어진 실 = 회로 차단)에 의해 감지되었으며, 그 대응은 자동적이고 절대적이었습니다.

LLM 용어로 설명하자면: LLM은 _후보(candidates)_를 생성합니다. LLM이 전혀 건드리지 않는 명세(specification)를 바탕으로 비-LLM 검증기(non-LLM verifier)가 해당 후보를 확인합니다. 만약 검증에 실패하면, 그 후보는 출력에 도달하지 못합니다. 검증기는 diff, JSON Schema 검증기(validator), CEL 표현식 평가기(evaluator), Datalog 규칙 엔진(rule engine), SMT 솔버(solver) 등, 그 판결이 결정론적이며 LLM이 방해할 수 없는 무엇이든 될 수 있습니다.

검증기가 LLM보다 더 똑똑한 것은 아닙니다. 검증기는 더 좁은(narrower) 범위를 가집니다. 검증기는 단 하나의 기계적인 질문에 답합니다: "이 후보가 명세를 충족하는가?" 명세는 인간에 의해 작성되었고 인간에 의해 검토되었습니다. 검증기의 알고리즘은 문서화되어 있으며 재현 가능합니다. 판결은 동일한 입력에 대해 매번 pass 또는 fail로 나뉩니다.

Building Stave를 통해 저는 LLM이 추론 엔진(reasoning engine)이 아닌 _구현 엔진(implementation engine)_일 때, 이 패턴이 프로덕션 규모에서 작동한다는 19주간의 증거를 얻었습니다. 다음은 Fowler의 9가지 패턴이 Stave의 아키텍처 내에서 어떻게 구조적으로 도달 불가능한(structurally-unreachable) 대응물로 매핑되는지에 대한 내용입니다.

이 패턴에는 이름이 있습니다: 신경-기호 AI (Neuro-Symbolic AI)

이러한 구조적 변화는 Stave만의 독창적인 것이 아닙니다. 이는 Transformer보다 더 오래된 연구 계보인 **신경-기호 AI (Neuro-Symbolic AI)**에 속합니다. 신경-기호 AI는 신경망 구성 요소(확률적, 학습된, 통계적)와 기호적 구성 요소(결정론적, 선언적, 정확한)를 결합하여, 각 측면이 가장 잘하는 일을 수행하도록 하는 하이브리드 시스템을 구축합니다. Henry Kautz는 2020년 AAAI Engelmore Memorial Lecture에서 가능한 여섯 가지 신경-기호 형태에 대한 분류 체계(taxonomy)를 소개했습니다. Garcez와 Lamb은 2023년에 신경-기호 시스템이 기호적 AI (1세대)와 연결주의 (2세대) 이후 AI의 세 번째 물결이라고 주장했습니다. DeepMind의 AlphaGeometry는 최근 가장 주목받는 사례입니다. 기호적 연역 엔진(symbolic deduction engine)이 증명을 처리하고, 언어 모델(language model)이 추측 생성(conjecture generation)을 담당합니다. 신경망 측이 제안하면, 기호적 측이 결정합니다.

모든 신경-기호 아키텍처에 던져야 할 질문은 어느 측이 _권한(authority)_을 갖느냐 하는 것입니다. 오늘날 구축되고 있는 대부분의 AI 에이전트는 신경망 측에 주도권을 부여합니다. 즉, LLM이 추론기(reasoner) 역할을 하며, 필요할 때 기호적 도구(계산기, SQL 데이터베이스, 코드 인터프리터)를 호출합니다. Kautz의 유형학에 따르면, 이는 Type 6 — Neuro[Symbolic] — 에 해당하며, 기호적 도우미가 내장된 신경망 시스템입니다. LLM이 도구를 사용할지 여부와 방법을 결정합니다. LLM이 도구의 출력을 판단합니다. LLM의 추론이 사용자에게 도달합니다. 모든 Fowler 패턴은 이 형태에 부합하는데, 왜냐하면 모든 Fowler 패턴은 LLM이 하중을 견디는 추론기(load-bearing reasoner)임을 전제로 하기 때문입니다. Type-6 시스템을 더 많은 LLM 호출(가드레일, 평가, 리랭커)로 래핑(wrapping)하는 것은 형태를 바꾸지 않습니다. 단지 이미 신경망 추론이 출력에 도달하도록 허용하는 시스템 위에 더 많은 신경망 계층을 추가할 뿐입니다.

Stave는 권한을 역전시킵니다. Stave의 프로덕션 런타임(Production runtime)은 순수 심볼릭(Pure symbolic) 방식입니다 — CEL, Z3, Soufflé, Clingo, Prolog, PRISM, TLA+, PySAT를 사용합니다. 결과(Finding)가 출력될 때 의사결정 루프(Decision loop)에 LLM이 개입하지 않습니다. 개발 시점에는 LLM이 생산성 승수(Productivity multiplier) 역할을 수행하지만(Claude Code가 Go 구현체, JSON 스키마, 테스트 픽스처를 생성함), 그 출력물은 배포되기 전에 심볼릭 엔진(Symbolic engine)에 의해 검증됩니다. 에이전트 접점(Agent surface)에서는 MCP 서버가 LLM 에이전트에게 심볼릭 엔진에 대한 타입이 지정된 RPC 접근 권한을 부여합니다 — 즉, 에이전트는 결과물을 생성하는 것이 아니라 소비하는 것입니다. 저작(Authoring), 런타임(Runtime), 에이전트 통합(Agent integration)에 이르는 전체 라이프사이클에 걸쳐 심볼릭 측이 권한을 가지며 뉴럴(Neural) 측은 제한됩니다. 이것이 바로 Kautz Type-2 형태인 Symbolic[Neuro] 입니다 — AlphaGeometry와 같은 계열이며, 대부분의 에이전트 프레임워크와는 정반대입니다. Fowler 패턴이 틀린 것은 아닙니다. 그것들은 Type-6 아키텍처를 위해 올바르게 설계되었습니다. 하지만 출력이 증명 가능하게 정확해야 하는 Type-2 아키텍처에는 불충분합니다. 올바른 프레임워크 설정은 LLM을 더 잘 사용하는 것이 아닙니다. _심볼릭 측에 주도권을 주는 것_입니다.

아홉 가지 패턴, 구조적으로 도달 불가능한 아홉 가지 대응물

Fowler / Subramaniam 패턴	Stave의 구조적 대응물	변경된 점
RAG (런타임에 관련 컨텍스트를 검색하고, LLM이 이를 올바르게 사용하기를 기대함)	임베디드 카탈로그 (Embedded catalog) — 버전 관리되는 YAML 형태의 2,662개 CEL 술어(Predicate), PR마다 감사(Audit) 수행, 시작 시 인덱싱됨	의사결정 시점에 검색을 수행하지 않음. "지식" 자체가 카탈로그임.
...	...	...
모든 행은 동일한 구조적 치환을 수행합니다: 비결정론적(Non-deterministic) 완화책을 결정론적(Deterministic) 메커니즘으로 교체하는 것입니다. Fowler의 문제 클래스는 더 잘 처리되는 것이 아니라, 이 아키텍처에서는 발생 자체가 불가능해집니다.

"파인튜닝 (Fine-tuning)" → "새로운 파일"

이 부분은 Fowler의 접근 방식에 대해 가장 무시하는 듯한 어조로 들리는 대목이기에, 가장 많은 증거가 필요합니다. 파인튜닝 (Fine-tuning)의 역할은 모델의 도메인 역량 (Domain competence)을 확장하는 것, 즉 LLM에게 당신의 문제에 대해 더 많이 가르치는 것입니다. 이에 대응하는 결정론적 (Deterministic) 방식은 다음과 같습니다: 도메인 역량을 모델에 아예 넣지 마세요. 대신 결정론적 엔진이 소비할 수 있는 버전 관리되는 아티팩트 (Artifacts)에 넣으세요.

Stave의 카탈로그는 1월 11일에 불변량 (Invariant) 1개에서 5월 26일에 2,662개의 컨트롤 (Controls)로 늘어났습니다. 이는 19주 만에 2,662배 증가한 수치입니다. 이 중 그 어떤 것도 모델 학습을 필요로 하지 않았습니다. 모든 추가 사항은 이름, 심각도 (Severity), 서술어 (Predicate), 그리고 메타데이터 (Metadata)를 포함한 YAML 파일이었습니다. 엔진은 새 파일을 읽고, 인덱싱하고, 스냅샷 (Snapshots)과 대조하여 평가했습니다. 동일한 엔진에 지식만 더 많아진 것입니다.

주요 변곡점들은 다음과 같습니다:

2026년 4월 8일: IAM 컨트롤 팩 추가. 첫 번째 비(非) S3 도메인입니다. 엔진에는 IAM 코드가 없었지만, 필요하지도 않았습니다. 컨트롤은 관찰된 IAM 자산의 속성에 대해 CEL을 사용하여 IAM 로직을 표현합니다.
2026년 4월 9일: 하루 만에 7개의 새로운 도메인이 도입되었습니다 — DNS (벤더 중립적), VPC, EC2, RDS, ELB, Kubernetes, Backup. 각각은 YAML과 관찰 스키마 (Observation-schema) 확정으로 구성된 피처 커밋 (Feat commit)이었습니다. 엔진은 전혀 수정되지 않았습니다.
2026년 4월 22일: 첫 번째 AI 보안 도메인 (AWS Bedrock — 9개 컨트롤) 추가. Google의 AI 지원 익스플로잇 (AI-assisted exploits)에 관한 GTIG 2026년 2분기 보고서에 의해 촉발되었습니다. 동일한 엔진, 새로운 YAML입니다.
2026년 5월 7일: 파일 경계에서 9개의 추론 엔진 (Reasoning engines)이 구성되었습니다. CEL (인프로세스), Z3 (SMT), Soufflé (Datalog), Clingo (ASP), Prolog (Resolution), PRISM (Probabilistic), TLA+ (Temporal), PySAT (SAT), 그리고 게임 이론 비용 분석기 (Game-theory cost analyzer)가 포함됩니다. 각 엔진은 동일한 stave export-sir 사실 파일 (Fact file)을 각자의 네이티브 형식으로 읽습니다. 재학습은 전혀 없습니다. 열 번째 엔진을 추가하는 것은 모델을 학습시키는 문제가 아니라, 사실 내보내기 어댑터 (Fact-export adapter)를 작성하는 문제입니다.
2026년 5월 10일: Pareto에 의해 두 번 스코핑된 AI 에이전트 정체성 도메인(identity domain) — 4가지 실패 모드(에이전트 역할 과잉 권한(agent role overprivilege), 유령 참조(ghost references), RAG 데이터 경계 위반(RAG data-boundary violations), AI 파이프라인 교차 서비스 복합체(AI-pipeline cross-service compounds)), 6회 반복으로 제한, 49개의 제어 항목(controls) + 13개의 복합 체인(compound chains). 모든 제어 항목은 YAML 형식입니다.