OWASP가 LLM 위험 1위로 꼽은 프롬프트 인젝션의 근본 원인. AI가 지시와 데이터를 구조적으로 구분 못하는 이유와 Instruction Hierarchy 완화책의 한계를 정리했다.
AI 에이전트에게 웹페이지를 요약해달라고 시켰는데, 그 페이지 안에 숨어 있던 문장이 에이전트에게 다른 짓을 시킨다면 어떨까. 이런 사고가 반복되는 이유는 특정 회사의 실수가 아니라, LLM이라는 기술 자체가 가진 구조적 한계 때문이다. OWASP는 이 문제를 LLM 애플리케이션 위험 1위로 지정했다.
전통적인 소프트웨어는 코드(실행할 명령)와 데이터(처리할 값)를 엄격히 분리한다. SQL 인젝션이나 커맨드 인젝션 같은 고전적 취약점이 반복적으로 등장했던 이유도 이 분리가 완벽하지 않았기 때문인데, 그래도 최소한 "여기까지는 코드, 여기부터는 데이터"라는 경계를 프로그래밍 언어 차원에서 정의할 수는 있었다.
LLM은 이 경계 자체가 없다. 시스템 프롬프트, 사용자의 질문, 검색 결과, 요약 대상 웹페이지, 도구 호출 결과가 전부 같은 텍스트 컨텍스트 윈도우 안에 순서대로 나열된다. 모델은 이 전체를 하나의 연속된 텍스트로 읽고 다음 토큰을 예측할 뿐이다. "이 부분은 신뢰해도 되는 지시이고, 이 부분은 그냥 처리할 데이터"라는 구분을 모델 내부에서 강제할 아키텍처적 장치가 원래부터 없다.
OWASP GenAI Security Project는 LLM01:2025 항목에서 이 문제를 다음과 같이 정의한다.
A Prompt Injection Vulnerability occurs when user prompts alter the LLM's behavior or output in unintended ways... It exploits the inability of LLMs to architecturally distinguish between system-level instructions and user-supplied data... LLMs process all text within a single context window, with no built-in mechanism to separate privileged system instructions from untrusted user input.
풀어 쓰면, 프롬프트 인젝션은 사용자(혹은 사용자가 열람하는 외부 콘텐츠)가 LLM의 동작을 의도하지 않은 방향으로 바꾸는 현상이다. 근본 원인은 LLM이 시스템 수준 지시와 사용자 제공 데이터를 아키텍처적으로 구분하지 못한다는 데 있다. 모델은 모든 텍스트를 하나의 컨텍스트 윈도우 안에서 처리하며, 신뢰된 시스템 지시와 신뢰할 수 없는 사용자 입력을 분리하는 내장 메커니즘이 없다.
여기서 두 갈래가 갈린다.
간접 인젝션이 성립하려면 세 조건이 겹쳐야 한다. 첫째, AI 에이전트가 외부 콘텐츠(웹페이지·문서·이메일)를 읽어 처리하는 기능이 있어야 한다. 둘째, 그 콘텐츠 안에 모델이 "지시"로 해석할 만한 텍스트가 있어야 한다. 셋째, 모델이 그 지시를 실행할 수 있는 도구(브라우징, 코드 실행, 이메일 발송 등)에 접근 권한을 갖고 있어야 한다. 세 조건이 모두 맞아떨어지면, 공격자는 사용자를 거치지 않고 AI 에이전트를 직접 조종할 수 있다.
업계가 이 문제에 대응하는 방식 중 하나가 OpenAI가 2024년 발표한 "Instruction Hierarchy(지시 계층 구조)" 연구다. 모든 지시에 동일한 가중치를 주는 대신, 출처에 따라 신뢰 등급을 매겨 학습시키는 접근이다.
system > developer > user > tool 순서로 권한을 매기고, 하위 권한 메시지가 상위 권한 지시와 충돌하면 하위 권한 쪽을 무시하도록 모델을 훈련시킨다. GPT-3.5에 적용했을 때 학습 중 보지 못한 공격 유형에도 방어력이 올라갔다는 결과가 나왔다. 다만 이 방식의 한계는 명확하다. 이건 아키텍처적으로 분리를 강제하는 게 아니라, "상위 권한을 우선하라"는 패턴을 확률적으로 더 잘 따르도록 학습시킨 것에 가깝다. 학습 데이터에 없던 새로운 우회 패턴이 나오면 뚫릴 수 있다는 뜻이다.
간접 인젝션의 실전 사례는 이미 여럿 보고됐다. 2026년 8월 공개된 Grok의 "Cryptographic Context Injection" 사례가 대표적이다. 공격자가 웹페이지에 암호화한 지시문을 숨겨 안전 필터(입력 검사 단계)를 통과시키고, AI가 그 페이지를 요약하는 과정에서 자체 코드 샌드박스 안에 지시를 복호화하게 만들어 신뢰를 얻어낸 사건이다(Grok 프롬프트 인젝션 40% 성공, 신고 두 달째 미패치 참고). 이 사례가 보여주듯, 입력 필터링 한 겹만으로는 간접 인젝션을 막을 수 없다. 필터를 통과한 뒤 모델이 스스로 실행하는 도구 호출 단계까지 검증해야 한다.
방어하는 입장에서 볼 수 있는 신호는 몇 가지로 좁혀진다. AI 에이전트가 요약·분석 작업 도중 갑자기 브라우징·이메일 발송·코드 실행 같은 도구를 호출하는 패턴, 특히 사용자가 명시적으로 요청하지 않은 도구 호출이 발생하는 경우는 의심할 만하다. 에이전트가 처리한 외부 콘텐츠 안에 비정상적으로 높은 엔트로피를 가진 문자열(암호화·인코딩된 블록)이 섞여 있는 경우도 마찬가지다. 도구 호출의 목적지(어떤 URL로, 어떤 데이터를 보내는지)를 별도로 로깅하고 이상 징후를 탐지하는 게, 필터 통과 여부와 무관하게 작동하는 가장 실질적인 방어선이다.
프롬프트 인젝션은 특정 서비스의 버그가 아니라 LLM이 지시와 데이터를 구조적으로 구분하지 못한다는 근본 한계에서 나온다. Instruction Hierarchy 같은 학습 기반 완화책은 방어력을 높이지만 확률적 완화일 뿐 완전한 해결은 아니다. 그래서 입력 단 필터링에 더해, AI 에이전트가 스스로 실행하는 도구 호출 단계에서 한 번 더 검증하는 다층 방어가 지금 시점의 현실적인 답이다.
AI 활용 안내 이 글은 AI(Claude)의 도움을 받아 작성되었습니다. 인용된 통계와 사례는 참고 자료에 명시된 출처에 근거하며, 설명을 위한 일부 표현은 각색되었습니다.
면책 조항 본 글은 보안 인식 제고를 위한 교육 목적으로 작성되었습니다. 언급된 공격 기법을 실제로 시도하는 행위는 「정보통신망법」, 「형법」 등에 따라 처벌받을 수 있으며, 본 블로그는 이에 대한 법적 책임을 지지 않습니다.