AWS용 프롬프트 인젝션 방화벽: 제가 구축할 것과 측정한 내용

프롬프트 인젝션(Prompt injection)은 2023년에 시작된 OWASP Top 10 for LLM Applications 목록에서 최상위에 자리했으며, 2025년 및 2026년 판에서도 여전히 1위를 차지하고 있습니다. 이는 이례적인 일입니다. 대부분의 취약점 클래스는 실제 해결책이 나와서 순위가 하락합니다. SQL injection에는 파라미터화된 쿼리(parameterized queries)가 있었고, XSS에는 출력 인코딩(output encoding)과 CSP(Content Security Policy)가 있었습니다. 하지만 프롬프트 인젝션은 이에 상응하는 것이 없습니다. 왜냐하면 이 결함이 구조적이기 때문입니다: LLM은 시스템 프롬프트(system prompt), 사용자 입력(user's input), 그리고 검색된 문서나 도구 출력(tool output)을 신뢰할 수 있는 지침과 신뢰할 수 없는 데이터 사이에 내장된 경계가 없이 하나의 구별되지 않은 텍스트 스트림으로 읽습니다.

저는 AWS에서 LLM 시스템을 다루고 있으며, 이것이 제가 계속 마주치는 문제입니다. 이 글은 제품 발표가 아닙니다. 이는 만약 제가 오늘 프롬프트 인젝션 방화벽을 구축한다면 설계할 것과, 실제 연구 결과와 현재 존재하는 것에 대한 솔직한 설명을 바탕으로 한 내용입니다. 저는 어떤 부분이 확립된 사실이고 어떤 부분이 제 제안하는 접근 방식인지 명확하게 밝힐 것입니다.

요약 (TL;DR)

• 프롬프트 주입(Prompt injection)은 OWASP가 모든 버전에 걸쳐 지정한 1순위 LLM 위험 요소이며, 2026년의 한 증명 연구는 순수 입력 래퍼 방어(pure input-wrapper defenses)가 연속성(continuous), 유틸리티 보존(utility-preserving), 완전성(complete)이라는 세 가지 속성을 동시에 가질 수 없다는 어려운 삼중고리(hard trilemma)에 직면함을 보여줍니다.
• 이 분야는 더 이상 비어있지 않습니다. NeuralTrust가 상용 "생성형 애플리케이션 방화벽(Generative Application Firewall)"을 출시했으며, Check Point는 Lakera를 인수했고, Cloudflare는 AI용 방화벽을 보유하고 있으며, 오픈 소스 프로젝트들도 존재합니다. 진정한 격차는 "아무도 이 문제를 해결하지 못했다"가 아니라, 클라우드 네이티브(cloud-native)하고, AWS를 참조하며, 에이전트 인지적인 설계입니다.
• 제 제안은 가중치 결정 엔진을 가진 다층 앙상블(multi-layer ensemble)과 출력 및 도구 호출 강제화(output and tool-call enforcement), 그리고 피드백 루프를 결합한 것입니다. 이 삼중고리를 극복하려 하기보다는 설계 자체에 포함시키는 방식입니다.
• 저는 오프라인 코어(휴리스틱 + 벡터 탐지기 + 결정 엔진)를 구축하고 285개의 레이블링된 프롬프트로 벤치마킹했습니다. 측정된 트레이드오프는 명확합니다. 공격의 92%를 포착하는 임계값에서는 합법적인 프롬프트의 25%가 플래그 지정되고, 오탐률(false positives)이 거의 0에 가까워질 때까지 조정하면 탐지율은 39%로 떨어집니다. 어떤 설정도 이 두 가지를 동시에 제공할 수 없습니다. 이것이 측정된 삼중고리이며, 의미론적 계층(semantic layer)의 근거입니다.

이 문제가 깨끗한 해결책을 거부하는 이유

2026년 논문 "Why Prompt Injection Defense Wrappers Fail?"은 실무자들이 오랫동안 느꼈던 것을 공식화했습니다. 이 논문은 입력을 감싸는 방어 메커니즘이 한 번에 모두 유지될 수 없는 세 가지 속성의 삼중고리(trilemma)에 직면한다고 주장합니다:

• 연속성 (Continuity) — 입력에 작은 변화가 발생하더라도 방어 결정이 바뀌어서는 안 됩니다.
• 유틸리티 보존 (Utility preservation) — 합법적인 프롬프트는 여전히 통과하여 작동해야 합니다.
• 완전성 (Completeness) — 모든 주입 시도(injection attempt)가 포착되어야 합니다.

두 가지를 얻을 수 있습니다. 세 개가 아닙니다. 이 논문은 input-wrapper 스타일의 방어 기법에만 국한하여 명시하고 있으며, 훈련 시간 정렬(training-time alignment), 아키텍처 변경, 또는 일부 유틸리티를 의도적으로 포기하는 방어 기법까지 배제하지는 않습니다. 이 미묘한 차이가 중요하며, 저는 이것을 다시 언급할 것입니다. 왜냐하면 이것이 가장 중요한 설계 제약 조건이기 때문입니다.

실질적인 결과는 모든 정직한 방화벽은 완전성을 약속해서는 안 된다는 것입니다. 대신, 연속성/유틸리티/완전성 표면(continuity/utility/completeness surface)의 어느 지점에 위치할지 명확히 밝혀야 하며, 그 선택을 구성 가능하게 만들어야 합니다.

이미 존재하는 것들 (대개 과장 광고가 건너뛰는 부분)

이 아이디어를 처음 스케치했을 때, 제 메모에는 '아무도 이것을 구축하지 않았다'고 적혀 있었습니다. 그것은 틀렸으며, 공개적으로 바로잡을 가치가 있습니다. 왜냐하면 LLM 보안 분야에서 일하는 사람이라면 누구나 이 지형(landscape)을 알 것이기 때문입니다.

• Lakera Guard — 상업용의 API 우선 프롬프트 인젝션 및 탈옥(jailbreak) 탐지 솔루션입니다. Check Point가 2025년 9월 Lakera를 인수하여 자체 플랫폼에 통합했습니다. 이 솔루션의 헤드라인 정확도와 50ms 미만의 지연 시간(latency)은 제가 측정한 수치가 아니라 해당 공급업체 자체의 수치입니다.
• NeuralTrust — Generative Application Firewall라는 상업용 제품을 출시하며, LLM 앱과 에이전트를 위한 인라인 강제 적용 계층(inline enforcement layer)을 제공합니다. 따라서 'GAF' 개념은 논문상에만 있는 것이 아니라 실제 판매되는 제품입니다.
• Cloudflare Firewall for AI — 안전하지 않은 프롬프트를 차단하고 엣지(edge)에서 여러 OWASP LLM 위험 요소를 다루는 상업용 계층입니다.
• 오픈 소스 (Open-source) — prompt-shield (그리고 한 단어인 promptshield)라는 이름의 몇몇 GitHub 프로젝트들은 탐지기 앙상블(detector ensembles), 리버스 프록시 강제 적용, 그리고 위협 점수화(threat scoring)를 구현합니다. LLM Guard는 활성 규칙 기반 스캐너 세트이며, NeMo Guardrails(NVIDIA)는 대화 흐름 제어(conversation-flow control)를 담당합니다. 초기 다층 프로젝트였던 Rebuff는 보관 처리되었습니다.

"GAF" 프레임워크 자체는 2026년 논문 "Introducing the Generative Application Firewall (GAF)"에서 나왔으며, 이 논문은 웹 트래픽에 대한 WAF(Web Application Firewall)를 비유하여 프롬프트 필터, 출력 검증기(output validators), 데이터 마스킹을 통합하고, 세션 컨텍스트를 유지하며, 에이전트와 그 도구 호출까지 포괄하는 단일 강제 지점(single enforcement point)을 제안합니다.

따라서 진정한 격차는 "아무도 방화벽을 구축하지 않았다"라는 것보다 훨씬 좁고 구체적입니다. 그것은 다음과 같습니다: 에이전트 인식(agent-aware)이며 (프롬프트뿐만 아니라 도구 호출을 가로채는), 단일 기술 대신 다중 검출기 앙상블(multi-detector ensemble)을 사용하고, 자신이 어떤 삼중고리 트레이드오프(trilemma trade-off)를 하는지 명시하는 오픈되고 클라우드 네이티브한 AWS 기본 요소 기반의 레퍼런스 아키텍처입니다. 이것이야말로 실질적이고 유용한 격차입니다. 이는 해당 카테고리를 발명했다는 주장이 아닙니다.

내가 구축할 아키텍처

설계는 파이프라인(pipeline) 형태를 띱니다: 탐지(detect), 결정(decide), 강제(enforce), 학습(learn). 각 단계는 AWS 기본 요소에 깔끔하게 매핑되며, 이것이 핵심입니다. 새로운 인프라를 발명할 필요 없이 배포 가능해야 합니다.

          ┌───────────────────────────────────────────────┐
 request  │  1. DETECTION  (ensemble, run in parallel)      │
 ───────► │   heuristic · ML classifier · LLM-as-judge      │
...

AWS에서는 다음과 같이 매핑할 것입니다: API Gateway를 진입점으로 사용하고; 검출기 앙상블은 Lambda 함수로 구성하며, ML 분류기는 SageMaker에, LLM-as-judge는 Bedrock에 배치합니다. 공격 벡터 저장소(attack-vector store)는 OpenSearch를 사용하고; 결정 엔진은 DynamoDB에서 세션 기록을 읽어오는 작은 Step Functions 또는 Lambda 오케스트레이션을 사용하며; 감사 추적(audit trail)에는 CloudWatch와 S3를 활용합니다. 이들 중 어느 것도 생소한 기술이 아니라는 점이 의도적입니다.

왜 앙상블(ensemble)을 사용하며, 각 계층은 실제로 무엇에 강한가

단일 탐지기만으로는 충분하지 않으며, 그 이유는 잘 알려져 있습니다. CAITLYN 논문은 트레이드오프를 명확하게 제시합니다. 결정론적 시그니처(deterministic signature)와 정규 표현식(regex) 필터는 토큰 비용 없이 밀리초 단위의 속도로 실행되지만, 사소한 난독화나 의미 재작성에는 취약합니다. 따라서 앙상블(ensemble)은 단순히 채우기 위한 것이 아닙니다. 각 계층은 다른 실패 모드를 보완합니다.

휴리스틱 계층(heuristic layer)은 저렴하게 수행하는 첫 번째 통과 검사입니다. 이는 예시일 뿐 완전한 규칙 세트는 아닙니다:

SUSPICIOUS = [
    r"ignore (all )?previous instructions",
    r"disregard the (system|above) prompt",
...

이것은 게으른 공격을 무료로 포착하고, 아무것도 교묘하게 잡아내지 못합니다. 이것이 바로 이 계층이 신호(signal)만 기여하는 이유입니다. 의미론적 계층(semantic layer)(ML 분류기 또는 Bedrock의 LLM-as-judge)은 정규 표현식이 놓치는 의역되거나 간접적인 공격을 실제 토큰 비용과 지연 시간을 들여 포착합니다. 벡터 유사성 계층(vector-similarity layer)은 입력값을 알려진 공격 패턴 임베딩 저장소와 비교하여, 단어 선택이 새롭더라도 본 적 있는 것의 변형이라면 높은 점수를 받도록 합니다.

의사결정 엔진에서 삼중고리(trilemma)가 다이얼이 되다

여기가 솔직한 버전의 핵심입니다. 하나의 탐지기가

위에 표시된 가중치는 전체 4개 탐지기(four-detector) 설계를 보여줍니다. 다음 섹션의 벤치마크는 제가 오프라인으로 실제로 구축한 두 개의 탐지기(휴리스틱 및 벡터)만을 사용하므로, 네 개가 아닌 두 개의 가중치를 사용하여 실행됩니다. 이 스니펫에 있는 의미론적 탐지기는 아직 구현하지 않은 레이어입니다.

오프라인 코어를 구축하고 측정하다

설계 주장은 값싸하기 때문에, 저는 두 가지 오프라인 레이어(휴리스틱 탐지기 및 벡터 유사성 탐지기)와 의사 결정 엔진을 구현한 후, 285개의 프롬프트로 구성된 라벨링된 코퍼스에 대해 테스트를 실행했습니다. 이 중 192개는 주입(injection), 93개는 정상(benign) 데이터입니다. 주입 세트는 고의적으로 분리되어 있으며, 벡터 탐지기가 학습한 예시가 아닌, 패러프레이즈, 난독화(간격 분산 및 하이픈 사용 트리거), 그리고 문서 경유 간접 페이로드로 구성되어 있어 포착률이 단순 암기보다는 일반화 능력을 반영하도록 했습니다. 정상 세트에는 "instructions," "system prompt," "override," 및 "ignore"와 같은 단어들이 무해하게 언급되는 난이도 높은 음성(hard negatives)이 포함되어 있습니다. 모든 것은 고정된 시드를 사용하는 순수 표준 라이브러리 Python으로 구성되어 있어 실행 결과가 결정론적이고 재현 가능합니다.

실제 출력은 다음과 같으며, 의사 결정 임계값(weights: heuristic 0.4, vector 0.6)을 변화시키며 테스트했습니다:

 thresh  detect%    FP%  precision     F1
--------------------------------------------
   0.15      98%    52%       0.80   0.88
...

위에서 아래로 읽어보면, 이 삼중고(trilemma)는 더 이상 추상적인 개념이 아닙니다. 임계값이 0.18일 때 방화벽은 주입의 **92%**를 포착하지만, 동시에 합법적인 프롬프트의 4분의 1도 플래그합니다. 시스템 프롬프트를 작성하거나 팀 지침을 문서화하는 것에 관한 까다로운 정상 음성 데이터들이 함께 잡힙니다. 임계값을 0.30으로 높이면 오탐률(false positives)은 1%(정밀도 0.99)로 떨어지지만, 탐지율은 **39%**까지 급락합니다. 즉, 대부분의 공격이 그대로 통과한다는 의미입니다. 탐지율이 높으면서 오탐률이 낮은 경우는 어느 행에서도 찾아볼 수 없습니다. 가장 좋은 F1 점수(0.90)는 실제 오탐 비용을 감수한 공격적인 영역 근처에 위치합니다.

이것은 더 나은 가중치로 다듬을 수 있는 튜닝 실패가 아닙니다. 이것은 2604.06436 결과가 이 방어 유형에 대해 예측하는 형태이며, 그것이 실수(real numbers)의 범위를 벗어나 떨어지는 것을 보는 것이 어떤 단일 헤드라인 정확도 수치보다 더 설득력이 있습니다. 솔직하게 말하자면 구체적입니다. 저렴한 오프라인 앙상블은 명백하고 어휘적으로 유사한 공격을 신뢰성 있게 포착하지만, '프롬프트에 대해 이야기하는 정상적인 요청'과 '공격의 미묘한 패러프레이즈(subtle paraphrase)'를 분리하는 데는 진정으로 어려움을 겪습니다. 이 중첩 영역이야말로 시맨틱 레이어(semantic layer), 즉 ML 분류기나 Bedrock에서 사용하는 LLM-as-judge가 해결해야 하는 영역이며, 이것이 제가 그 레이어를 '있으면 좋은 것'이 아니라 다음 구축 단계로 취급하는 이유입니다.

솔직함에 대한 참고 사항을 남깁니다. 이 게시물의 핵심 주제이기 때문입니다. 코퍼스(corpus)는 합성적이고 템플릿으로 생성되었기 때문에, 그 다양성은 템플릿에 의해 제한됩니다. 수치들은 공식적인 기준선 대비 운영상의(operational) 것이며, 구현체는 오픈 소스로 공개되지 않았습니다. 저는 이 수치들을 직접 코드를 실행하지 않고 인용하지 않을 것이며, 이를 프로덕션 등급처럼 꾸미지도 않을 것입니다. 이것은 트레이드오프(trade-off)를 측정하여 보여주는 것일 뿐, 그 이상도 이하도 아닙니다.

에이전트 인식(agent-aware)으로 만드는 두 가지 요소

대부분의 분야는 여전히 이것을 '사용자의 프롬프트 스캔'으로 취급합니다. 하지만 현대적인 에이전트 시스템에서는 이가 절반에 불과합니다. 추가되어야 할 두 가지 요소가 중요합니다:

출력 스캐닝(Output scanning). 모델의 응답은 주입된 명령어(injected instruction)를 포함하거나 시스템 프롬프트(system prompt)가 유출될 수 있습니다. 입력뿐만 아니라 출력까지 스캔하는 곳에서 여러 설계(NeuralTrust 및 GAF 논문 포함)가 수렴하고 있으며, 저는 이것을 선택 사항이 아닌 필수 사항으로 간주할 것입니다.