Lee Somin

Lee Somin

Developer / Student of USW

© 2026

Dark Mode

Thesis Review
May 2, 2026
  • Activities

웹사이트 챗봇, 생각보다 많이 뚫려있었다

논문: When AI Meets the Web: Prompt Injection Risks in Third-Party AI Chatbot Plugins
학회: IEEE S&P 2026
저자: Yigitcan Kaya, Anton Landerer, Stijn Pletinckx, Michelle Zimmermann, Christopher Kruegel, Giovanni Vigna
카테고리: AI Security

선정 이유

AI가 점차 스테디로 자리잡고 있는 요즘, 보안 분야도 AI로 인해 오랫동안 유지해왔던 공격과 솔루션의 체계에 큰 변화가 있을 것이라는 생각을 하게 되었다. 이 생각을 토대로 AI보안을 주제로 하는 논문 중에서 고른 것이지만, 이 논문 제목을 보면서 조금 다른 질문이 생겼다. AI가 아니라 AI를 둘러싼 인프라가 공격받는다면? 특히 전문 지식 없이 누구나 설치하는 플러그인들이라면?
일상에서 너무 흔하게 보이는 웹사이트 챗봇이 소재라는 것도 흥미를 갖게 된 이유였다. 거창한 시스템보다 이런 것들이 실제로 더 많은 사람들에게 영향을 미친다는 생각이 들어서 읽기 시작했다.

논문 등장 배경

프롬프트 인젝션이란?

LLM 기반 애플리케이션에는 보통 세 종류의 입력이 섞인다. 개발자가 작성한 시스템 프롬프트, 사용자가 입력하는 메시지, 그리고 외부 소스에서 가져온 데이터. 문제는 LLM이 이 셋을 구조적으로 완전히 분리하기 어렵다는 데 있다. 프롬프트 인젝션은 이 허점을 파고드는 공격이다. 악의적인 입력을 통해 개발자의 의도와 다른 행동을 모델에게 유도하는 것이다.
이미 여러 연구들이 이 문제를 다뤘고, OpenAI 같은 LLM 제공사들도 “Instruction Hierarchy”라는 개념으로 대응하고 있다. 개발자 지시에 가장 높은 신뢰를 부여하고, 사용자 입력이나 외부 데이터에는 낮은 신뢰를 부여하는 방식이다. 이론적으로는 모델이 이 위계를 지키도록 학습된다.

연구팀이 불편함을 느낀 지점

기존 연구들은 대부분 AI 에이전트나 코파일럿처럼 정교한 시스템에 집중해왔다. 그런데 실제 웹에서 훨씬 더 많은 비중을 차지하는 건 쇼핑몰 고객센터 봇, 부동산 상담 봇, 예약 안내 챗봇 같은 단순한 시스템들이다.
이런 챗봇들은 대부분 서드파티(3rd Party) 플러그인으로 구동된다. 사이트 운영자가 AI를 직접 개발하는 대신, WordPress 플러그인처럼 설치해서 쓰는 완성형 패키지다. 이 플러그인들이 상용 LLM API에 연결되는 중간 다리 역할을 한다.
결국 LLM 자체에는 방어 장치가 있더라도, 플러그인 레이어가 허술하면 아무 의미가 없다. 그리고 이 레이어는 지금까지 거의 연구된 적이 없었다.

연구 접근 방식

현재 생태계 파악

10,000개 이상의 실제 공개 웹사이트를 분석해서 어떤 챗봇 플러그인들이 얼마나 쓰이는지 파악했다. 그렇게 추려낸 17개 플러그인을 직접 분석하면서 구조와 동작 방식을 이해했다. 단순히 취약점을 찾는 것이 아니라, 생태계 전체를 먼저 들여다본 것이다.
그 중 눈에 띄었던 수치는, 이 생태계가 2025년 한 해에만 약 50% 성장했다는 것이다. 빠르게 퍼지고 있는 기술인데 보안 검토는 따라가지 못하고 있다는 뜻이기도 하다.

취약점 1 - 대화 이력 미검증

챗봇과의 대화 내용은 사용자 브라우저에서 서버로 전송된다. 이 전송 과정에서 메시지 이력이 네트워크 요청에 담기는데, 문제는 그 내용을 서버 측에서 신뢰 검증 없이 그대로 받아들이는 플러그인들이 있다는 것이다.
17개 중 8개가 이러한 상태이고, 이는 약 8,000개 웹사이트에 영향을 주는 수치였다.

이게 왜 심각하냐면, 공격자가 네트워크 요청을 가로채서 대화 이력에 시스템 역할의 메시지를 임의로 삽입할 수 있기 때문이다. LLM은 Instruction Hierarchy에 따라 시스템 메시지를 높은 권한으로 처리한다. 플러그인이 그 경계를 지켜줘야 하는데 클라이언트에서 넘어온 값을 그냥 믿어버리니까 공격자가 그 권한을 가로채게 되는 것이다.
이건 AI 보안의 문제가 아니라, 웹 개발의 기초 원칙인 “클라이언트 데이터를 신뢰하지 마라”를 지키지 않은 결과다.

취약점 2 - 신뢰 불가 콘텐츠 미구분

15개 플러그인이 웹 스크래핑을 통해 사이트 콘텐츠를 자동으로 수집하고, 이를 *RAG 방식으로 챗봇의 지식 기반에 편입시킨다. 상품 설명이나 공지사항 같은 공식 콘텐츠를 챗봇에게 학습시키는 방식이다.
문제는 이 과정에서 고객 리뷰나 커뮤니티 댓글 같은 서드파티 콘텐츠가 걸러지지 않는다는 점이다. 누구나 작성할 수 있는 리뷰에 악의적인 프롬프트가 담겨 있어도, 플러그인은 이를 신뢰할 수 있는 사이트 콘텐츠와 동일하게 취급한다.
연구팀이 실제 이커머스 사이트를 무작위로 표본 조사했더니 13%가 이미 서드파티 콘텐츠에 챗봇이 노출된 상태였다. 이미 공격 가능한 경로가 열려 있는 사이트가 그만큼 된다는 뜻이다.

* RAG: 검색 증강 생성 - LLM의 출력을 최적화하여 응답을 생성하기 전에 훈련 데이터 소스 외부의 신뢰할 수 있는 기술 자료를 참조하도록 하는 프로세스

실험 결과와 드러난 한계

연구팀은 실제 관측된 플러그인 설정들을 반영해 통제 실험을 설계했고, 그 결과는 명확했다.
역할 경계가 무너진 환경에서는 주입된 프롬프트가 코딩 같은 비인가 작업을 유도하는 데 25~100%의 성공률을 보였다. 반면 올바른 역할 격리가 적용된 환경에서는 0~25%로 낮아졌다. 플러그인 레이어 하나가 LLM 자체의 방어 효과를 사실상 무력화할 수 있다는 걸 보여주는 수치다.

하드닝된 시스템 프롬프트는 단순한 *task hijacking에는 어느 정도 효과가 있었다. 하지만 tool use를 타깃으로 한 공격, 즉 챗봇이 외부 함수를 공격자가 원하는 방식으로 호출하도록 유도하는 공격에는 제한적이었다. 챗봇이 점점 더 많은 tool을 지원할수록 공격 표면도 넓어진다는 뜻이다.

* task hijacking: 사용자가 특정 애플리케이션을 실행하거나 화면을 터치하는 순간, 악성 앱이 중간에 끼어들어 정상적인 화면을 가짜 화면(오버레이)으로 덮어씌우는 악성코드 공격

논문을 읽고 나서

아쉬운 부분

실험이 연구팀이 직접 구성한 통제 환경에서 이루어졌다는 점은 논문이 직접 언급하는 한계이기도 하다. 실제 공격자가 어떤 창의적인 변형을 가할지, 또는 실제로 이 취약점들이 얼마나 악용되고 있는지에 대한 답은 이 논문에 없다.

또 하나는, 플러그인 업체들이 어떻게 대처할 것인가의 문제이다. 연구팀은 책임 공개(responsible disclosure)를 진행했고, 가장 많이 쓰이는 플러그인은 수정을 완료했다고 한다. 하지만 나머지 플러그인들은 여전히 취약한 상태다. 기술적으로 가능한 방어책을 제시하는 것과, 그게 실제로 적용되는 것은 다른 문제라고 생각한다.

배운 점

이 논문이 보여주는 건 단순히 “챗봇이 위험하다”가 아니다. AI 시스템의 보안은 AI 자체만의 문제가 아니라는 것이다. LLM 제공사가 아무리 정교한 방어 메커니즘을 만들어도, 그것을 감싸는 레이어가 기본 원칙을 지키지 않으면 그 방어는 의미를 잃는다. 이 사실이 가장 인상 깊었고, 보안은 아주 섬세한 솔루션을 필요로 한다는 사실이 크게 와닿았다.

그리고 이 취약점들이 최첨단 해킹 기술의 산물이 아니라는 점도 놀라운 사실이었다. 클라이언트 데이터를 검증 없이 신뢰하는 건 웹 보안의 가장 오래된 실수 중 하나고, 신뢰할 수 없는 입력을 신뢰할 수 있는 입력과 섞는 것도 기초적인 설계 원칙의 위반이다. 새로운 기술 위에서도 오래된 실수는 반복된다는 걸 깨달았다.

이 주제로 AI와 토의를 해보았다.

내용 요약

  • 이 논문은 LLM 자체보다, 이를 감싸는 플러그인·애플리케이션 레이어가 실제 공격의 핵심 지점이 될 수 있음을 보여준다.
  • 발견된 취약점 상당수는 AI 고유의 문제가 아니라 “클라이언트 입력을 신뢰하지 말라” 같은 전통적인 웹 보안 원칙이 지켜지지 않아 발생했다.
  • Instruction Hierarchy(System > Developer > User > External Content)는 이론적으로 존재하지만, 실제 서비스에서는 role 위조나 RAG 오염 등으로 쉽게 무너질 수 있다.
  • 프롬프트 인젝션은 단순한 텍스트 조작 문제가 아니라, tool use와 결합되는 순간 권한 탈취 공격으로 이어질 수 있다.
  • 앞으로 중요한 것은 단순한 모델 정렬(alignment)보다 capability isolation, sandboxing, permission architecture 같은 구조적 방어 설계일 가능성이 크다.
  • 특히 MCP·AI Agent 생태계가 확대될수록 “어떤 입력을 신뢰할 것인가”, “tool 호출이 실제 사용자 의도인가” 같은 문제가 더욱 중요해질 것이다.
  • 이 논문의 강점은 실제 공개 웹사이트와 상용 플러그인을 기반으로 현실 환경의 취약점을 분석했다는 점이다.

참고 링크 https://chatgpt.com/s/t_6a18876c9b048191b9e65a0fd0d75611

앞으로 해볼 것

더 읽어볼 논문

  • OpenAI의 “Instruction Hierarchy” — LLM 레벨 방어 메커니즘의 원리 이해
  • RAG 시스템에 대한 poisoning 공격 관련 논문들 — 간접 인젝션 문제의 더 넓은 맥락

직접 확인해보고 싶은 것

실제 워드프레스 환경에서 무료 챗봇 플러그인을 설치하고, 브라우저 개발자 도구로 어떤 데이터가 오가는지 직접 확인해보기
-> 논문에서 설명한 패킷 구조가 실제로 어떻게 생겼는지 눈으로 보고 싶다

연구나 프로젝트로 발전시킨다면

이 논문은 “현황이 이렇다”를 보여주는 데 집중했다. 읽고나니 자연스레 “사이트 운영자 입장에서 자신이 설치한 플러그인의 취약성을 쉽게 진단할 수 있는 방법이 있을까” 라는 질문으로 이어졌다. 보안 지식이 없는 운영자가 직접 코드를 분석하는 건 불가능하니 자동화된 진단 도구가 현실적으로 의미 있는 방향일 것 같다.