프롬프트 인젝션과 적대적 입력

프롬프트를 한 줄의 지시문으로만 보던 시절에는, 공격도 그저 "이상한 질문을 하는 사용자" 정도로 생각하기 쉬웠다. 하지만 운영 환경에서는 이야기가 완전히 달라진다. 사용자 입력, 업로드 문서, 검색된 웹페이지, 이메일 본문, 도구의 반환값까지 모두 모델의 문맥 안으로 들어온다. 그 순간 프롬프트는 문장이 아니라 시스템의 제어면이 된다. 그래서 보안 관점에서 가장 먼저 가져야 할 태도는 단순하다. 프롬프트는 항상 공격받는다.¹²

왜 프롬프트 인젝션이 생기는가

프롬프트 인젝션은 모델이 무엇이 지시이고 무엇이 데이터인지 안정적으로 구분하지 못할 때 생긴다. 사람이 보기에는 분명 다르다. 시스템 지시는 "어떻게 행동할지"를 정하고, 사용자 메시지는 "무엇을 요청하는지"를 담고, 검색 문서는 "참고할 자료"다. 그런데 현재의 LLM은 이 셋을 결국 같은 텍스트 흐름 안에서 읽는다. 이 구조적 약점 때문에, 외부에서 들어온 문장이 본래의 규칙을 밀어내고 행동을 바꾸는 일이 발생한다.¹²

전통적인 소프트웨어에서는 명령과 데이터를 분리하는 장치가 비교적 분명하다. 예를 들어 SQL에서는 파라미터 바인딩으로 사용자 입력을 쿼리와 분리할 수 있다. 하지만 LLM은 자연어를 그대로 해석하는 기계다. 다시 말해, 공격자는 코드를 깨뜨리지 않아도 된다. 그럴듯한 말만 잘 섞어 넣으면 된다. 이 점이 프롬프트 인젝션을 무섭게 만든다.²

이 취약점은 챗봇에서 끝나지 않는다. 읽기 전용 FAQ 봇이라면 이상한 답변 정도로 끝날 수 있지만, RAG 시스템이라면 근거 문서를 오염시키고, 에이전트라면 도구 호출까지 유도할 수 있다. 말이 잘못 나오는 문제에서, 실제 행동이 잘못 실행되는 문제로 넘어가는 것이다.²⁵

직접 프롬프트 인젝션

가장 이해하기 쉬운 공격은 직접 프롬프트 인젝션이다. 공격자가 채팅창이나 API 입력에 노골적인 우회 지시를 넣어 모델의 우선순위를 흔드는 방식이다. 예를 들어 원래는 요약만 해야 하는 봇에게, 앞선 규칙을 무시하고 숨겨진 지시를 드러내라고 압박하는 식이다. OWASP는 이런 직접 주입을 대표적인 LLM 보안 위험으로 분류한다.¹

직접 인젝션의 핵심은 멋진 해킹 기법이 아니라 역할 혼동이다. 모델에게 원래 역할을 잊게 만들고, 새로운 역할을 받아들이게 만드는 것이다. 그래서 공격 문장은 꼭 공격적으로 보이지 않아도 된다. 정중한 부탁, 디버그 요청, 테스트 모드 제안, 관리자 확인 절차처럼 보일 수도 있다. 겉보기에는 협조적인 대화인데, 내부적으로는 통제권을 뺏는 셈이다.

이 공격이 위험한 이유는 두 가지다. 하나는 모델이 금지된 응답을 생성하게 만드는 것이고, 다른 하나는 시스템 내부 정보를 꺼내게 만드는 것이다. 전자는 서비스 품질과 안전 정책을 망가뜨리고, 후자는 더 큰 2차 공격의 발판이 된다.

프롬프트 유출은 왜 심각한가

프롬프트 유출, 또는 prompt leak은 시스템 프롬프트나 내부 규칙, 숨겨진 정책, 도구 설명 같은 운영 정보를 밖으로 드러내는 문제다. 얼핏 보면 "지시문이 조금 보인 것"처럼 가벼워 보일 수 있다. 하지만 실제로는 그렇지 않다. 내부 프롬프트는 제품의 운영 철학이자 제어 로직이며, 때로는 민감한 흐름과 예외 처리 정책까지 담고 있다.³

더 큰 문제는 프롬프트 유출이 정찰 역할을 한다는 점이다. 공격자가 시스템 프롬프트를 알게 되면, 그다음부터는 아무 방향으로나 찔러보지 않는다. 어떤 표현에 모델이 약한지, 어떤 금지 규칙이 있는지, 어떤 도구가 연결되어 있는지 더 정확하게 겨냥할 수 있다. 건물 설계도를 먼저 훔친 뒤 침입하는 것과 비슷하다.³

그래서 프롬프트 유출은 단지 창피한 사고가 아니다. 지적 재산이 새는 문제이기도 하고, 이후 공격의 난도를 낮추는 문제이기도 하다. 특히 내부 도우미나 업무용 코파일럿에서는 시스템 프롬프트 안에 도메인 정책, 라우팅 규칙, 비공개 판단 기준이 들어가는 경우가 많아서 피해가 커진다.

jailbreak는 무엇이 다른가

jailbreak는 흔히 프롬프트 인젝션과 같은 뜻으로 섞여 쓰이지만, 조금 더 정확히 말하면 안전 정책을 우회하려는 인젝션에 가깝다. 즉, 목적이 모델의 일반 동작 변경이 아니라 보호 장치 무력화에 있다.¹⁴

예를 들어 모델이 원래는 거부해야 할 요청을, 역할극이나 가상 시나리오, 연구 목적, 소설 설정처럼 포장해서 통과시키려는 시도가 여기에 속한다. 어떤 경우에는 새로운 페르소나를 씌워 "원래의 너는 제한이 있지만, 지금의 너는 제한이 없다"는 식으로 역할을 바꿔버린다. 이 방식이 계속 살아남는 이유는 모델이 본래 역할놀이와 문맥 적응에 강하기 때문이다.⁴

여기서 중요한 점은 jailbreak가 단순히 "나쁜 답변을 얻는 꼼수"가 아니라는 것이다. 운영 환경에서 jailbreak는 브랜드 훼손, 정책 위반 응답, 위험한 도구 계획, 규정 미준수 출력으로 이어질 수 있다. 다시 말해, 정렬된 모델의 안전 장치는 벽돌담이 아니라 확률적 방어막에 가깝다. 강한 압박, 교묘한 프레이밍, 반복 시도 앞에서 흔들릴 수 있다.⁴⁹

간접 프롬프트 인젝션이 더 무서운 이유

직접 주입보다 더 실무적인 위협은 간접 프롬프트 인젝션이다. 이 경우 공격자는 채팅창에 직접 들어오지 않는다. 대신 모델이 읽게 될 외부 콘텐츠 안에 지시를 숨긴다. 웹페이지, 이메일, PDF, 문서 메타데이터, 코드 주석, 일정 초대, 벡터 DB의 문서 조각이 모두 경로가 될 수 있다.¹⁵

이 공격이 무서운 이유는 사용자가 평범한 요청만 했는데도 사고가 난다는 데 있다. 사용자는 "이 문서 요약해줘", "최근 이메일 정리해줘", "이 저장소 분석해줘"라고 말했을 뿐이다. 하지만 모델이 불러온 외부 텍스트 안에 숨겨진 명령을 함께 읽는 순간, 사용자의 의도와 전혀 다른 방향으로 흘러갈 수 있다. Microsoft는 이런 간접 주입을 전제로 시스템을 설계하라고 권고한다. 발생하지 않기를 바라는 것이 아니라, 발생한다고 가정하고 격리와 통제를 설계하라는 뜻이다.⁵

특히 RAG에서는 이 문제가 더 심각하다. 검색된 문서는 사람에게는 "근거"처럼 보이지만, 모델에게는 결국 문맥의 일부다. 그래서 검색 결과 안에 "이전 규칙을 따르지 말라"는 식의 공격 문장이 섞여 있으면, 근거 문서가 아니라 새 지시처럼 작동할 수 있다. RAG가 정확도를 높여줄 수는 있어도, 프롬프트 인젝션 자체를 없애주지는 않는다.¹

간접 주입은 에이전트에서 폭발력을 얻는다. 문서를 읽는 것에서 끝나면 이상한 답변 정도일 수 있다. 하지만 이메일 전송, 파일 수정, 레코드 삭제, 설정 변경 같은 도구가 연결되어 있으면 이야기가 달라진다. 모델이 잘못 이해한 지시가 실제 행동으로 번역되기 때문이다. 그래서 보안은 "모델이 무엇을 말하는가"만이 아니라 "시스템이 무엇을 실행하는가"의 문제다.²⁸

실제 운영에서 벌어지는 위험 시나리오

운영 환경에서는 공격이 늘 같은 얼굴로 오지 않는다. 형태는 달라도 구조는 비슷하다. 신뢰하지 말아야 할 입력이 신뢰된 제어 입력처럼 취급되는 순간 사고가 난다.

• 이메일 요약 도우미가 외부인이 보낸 메일 본문이나 서명 안의 숨은 지시를 읽고, 내부 데이터 검색이나 전달 같은 행동을 시도할 수 있다.⁵

• 내부 지식 검색 봇이 오염된 문서를 근거로 삼아 비공개 정책이나 민감 정보를 드러내거나, 잘못된 운영 지침을 사실처럼 답할 수 있다.¹⁵

• 코딩 에이전트가 저장소의 주석, README, 이슈 설명을 신뢰해 위험한 명령 실행이나 설정 변경 방향으로 유도될 수 있다.⁸⁹

• 멀티모달 비서가 이미지, PDF, 메타데이터 속 숨겨진 텍스트를 읽고 사람이 보지 못한 지시를 따를 수 있다.⁶⁷

여기서 공통점은, 공격자가 꼭 관리자 권한을 탈취할 필요가 없다는 것이다. 오히려 시스템이 스스로 권한을 들고 있기 때문에 더 위험하다. 모델이 사용자의 권한, 서비스 계정, 백엔드 API 권한을 대신 행사할 수 있으면, 공격자는 언어만으로 간접 조작을 시도하게 된다.

공격은 점점 더 교묘해진다

초기의 공격은 대놓고 규칙 무시를 요구하는 문장이 많았다. 그래서 많은 팀이 금지어 필터를 붙였다. 하지만 공격은 금세 그 필터 바깥으로 이동했다. OWASP 치트시트는 인코딩, 보이지 않는 유니코드 문자, 글자 순서를 흐트러뜨린 단어, HTML/Markdown 주입, 다회차 공격, 세션 오염, RAG 오염 같은 우회 기법을 정리한다.⁶

즉, 공격 문장은 더 이상 "공격 문장처럼" 보이지 않는다. 사람이 봐도 평범한 리뷰, 주석, 캡션, 메타데이터처럼 보일 수 있다. 어떤 것은 아예 화면에는 보이지 않는데 토크나이저는 읽는다. 어떤 것은 한 번의 대화가 아니라 여러 턴에 걸쳐 신뢰를 쌓은 뒤 뒤늦게 트리거된다. 어떤 것은 이미지나 문서의 숨은 레이어에 숨어 들어온다.⁶⁷

이 대목이 특히 중요하다. 프롬프트 인젝션은 단순한 금칙어 문제가 아니다. 자연어 전체가 공격 표면이다. 그래서 "이 표현만 막으면 된다"는 접근은 금방 낡아버린다.

위험이 커지는 네 가지 조건

다음 네 조건이 겹칠수록 프롬프트 인젝션의 피해 반경은 커진다.

• 외부 콘텐츠를 많이 읽을수록

• 도구를 더 많이 호출할수록

• 대화 메모리와 상태를 오래 유지할수록

• 권한이 넓고 자동화 수준이 높을수록

외부 콘텐츠를 많이 읽는 시스템은 간접 주입 표면이 넓다. 도구를 많이 호출하는 시스템은 잘못된 판단이 바로 실행으로 번질 수 있다. 메모리가 길게 유지되면 초반에 심어진 악성 단서가 나중에 살아날 수 있다. 권한이 넓으면 작은 유도도 큰 사고로 이어진다. 결국 같은 공격이라도, 단순 Q&A 봇에서와 업무 자동화 에이전트에서의 위험도는 전혀 다르다.²⁵

운영자가 꼭 기억해야 할 관점

프롬프트 인젝션을 이해할 때 가장 중요한 문장은 이것이다. 모델은 권한 체계가 아니다. 모델이 "이건 안전하다"고 말해도, 그 말 자체가 권한 검증을 대신할 수는 없다. 시스템 프롬프트도 중요하지만, 그것만으로는 부족하다. 검색 문서와 사용자 입력을 분리하고, 출력이 곧바로 실행되지 않게 하고, 도구 경계에서 다시 권한을 확인해야 한다.²

OpenAI가 중요한 행동 전에 사용자 확인 같은 통제를 강조하는 것도 같은 이유다. 모델은 제안할 수 있지만, 결과적 책임이 따르는 행동은 시스템과 사용자가 별도로 승인해야 한다.⁸

따라서 운영 환경에서의 기본 가정은 다음과 같아야 한다. 사용자 메시지는 물론이고, 검색 문서도, 도구 응답도, 첨부 파일도, 심지어 화면에 보이지 않는 텍스트도 잠재적으로 적대적이다. 이 관점을 받아들이는 순간 프롬프트는 더 이상 글쓰기 문제가 아니다. 권한, 경계, 검증, 격리의 문제다.

핵심 정리

프롬프트 인젝션은 모델이 말을 잘 알아듣기 때문에 생기는 역설적인 취약점이다. 직접 주입은 사용자가 노골적으로 규칙을 흔드는 공격이고, 프롬프트 유출은 내부 제어 정보를 빼내는 공격이며, jailbreak는 안전 정책 우회를 노리는 공격이다. 그리고 간접 프롬프트 인젝션은 외부 문서와 도구 체인을 통해 이 모든 문제를 조용히 실전으로 끌고 온다.

운영 가능한 프롬프트 아키텍처를 설계하려면, 먼저 이 사실을 인정해야 한다. 좋은 프롬프트는 공격받지 않는 프롬프트가 아니라, 공격받아도 시스템 전체가 무너지지 않도록 설계된 프롬프트다.

참고

¹OWASP LLM01 Prompt Injection

²AI security: Defending against prompt injection and unsafe actions

³Prompt Leak

⁴Jailbreaking Taxonomy

⁵Defend against indirect prompt injection attacks

⁶LLM Prompt Injection Prevention Cheat Sheet

⁷Multimodal Prompt Injection Attacks: Risks and Defenses for Modern LLMs

⁸Understanding prompt injections

⁹Prompt injection attacks: What are they and how to defend against them