📚 지식 노트

AI 시스템의 공격 표면

LLM(대규모 언어 모델)이 어떻게 답을 만드는지, RAG와 도구 사용이 무엇인지는 AI 노트에 정리해 두었다. 이 글은 그 부품들을 공격자의 눈으로 다시 본다. AI 앱도 결국 소프트웨어라서 보안의 기초에서 말한 원칙(공격 표면 줄이기, 최소 권한, 심층 방어)이 그대로 통한다. 다른 점은 입구의 성질이다. 보통 프로그램에서는 명령(코드)과 데이터가 분명히 나뉘지만, LLM에서는 글이 곧 명령이 될 수 있다.

모델에 무언가를 넣거나 모델이 무언가를 내보내는 곳이 모두 공격 표면이다.

이 그림에서 기억할 점은 두 가지다. 첫째, 컨텍스트 창 안에서는 개발자의 지시와 바깥에서 온 글이 같은 재료로 섞인다. 둘째, 모델의 판단을 아무리 다듬어도 모델이 가진 권한(도구)과 출력이 가는 곳을 바깥에서 묶지 않으면 피해 범위가 정해지지 않는다. 아래 절들은 모두 이 두 점에서 나온다.

프롬프트 인젝션: 글이 명령이 된다

프롬프트 인젝션(prompt injection)은 모델이 받는 글에 지시를 끼워 넣어 개발자나 사용자가 의도하지 않은 일을 하게 만드는 공격이다. OWASP의 LLM 앱 위험 목록에서 처음 나온 판부터 지금까지 1위를 지키고 있다. 두 갈래로 나뉜다.

• 직접 인젝션: 사용자가 대화창에 직접 "앞의 규칙은 무시하라" 같은 글을 넣는다. 공격자가 곧 사용자라서, 피해는 대개 그 사용자가 이미 볼 수 있는 범위 안에 머문다.
• 간접 인젝션(indirect prompt injection): 공격자가 모델이 나중에 읽을 곳, 곧 웹 페이지·메일·문서·코드 저장소·도구 결과에 지시를 숨겨 둔다. 피해자는 평범한 일을 시켰을 뿐인데 모델이 그 글을 읽는 순간 공격이 시작된다.

간접 인젝션이 실제 앱을 위협한다는 것은 Greshake 등의 2023년 논문 Not what you've signed up for이 검색 기능을 단 챗봇과 메일 도우미에서 보여 주며 널리 알려졌다. 에이전트가 읽는 범위가 넓어질수록 공격자가 글을 심을 수 있는 자리도 넓어진다.

탈옥(jailbreak)과는 겨냥하는 대상이 다르다. 탈옥은 모델 자체의 안전 학습을 넘어 원래 거절해야 할 내용을 말하게 만드는 것이고, 프롬프트 인젝션은 모델을 품은 앱을 노린다. 앱이 정한 지시보다 공격자의 글이 우선하게 만들어 앱의 권한과 데이터를 가로챈다. 탈옥 기법이 인젝션에 쓰이기도 하지만, 모델이 아무리 잘 거절해도 "이 메일을 저 주소로 전달하라"는 지시는 해로운 말이 아니라서 탈옥 방어로는 막히지 않는다.

왜 입력 필터만으로는 풀리지 않나

웹 보안 노트의 SQL 인젝션은 매개변수화 쿼리로 근본적으로 막힌다. 명령과 값을 다른 통로로 보내면 값 안에 무엇이 있어도 명령이 되지 않기 때문이다. LLM에는 이런 통로가 없다. 시스템 지시, 사용자 질문, 문서 내용이 모두 한 줄의 토큰으로 이어져 들어가고, 어디까지가 데이터인지는 모델이 글의 생김새로 짐작할 뿐이다.

그래서 "무시하라" 같은 위험한 문구를 걸러 내는 차단 목록(deny-list)은 표현만 바꾸면 통과되고, 다른 LLM으로 입력을 검사하는 분류기도 확률적으로만 맞는다. 영국 국가사이버보안센터(NCSC)는 2025년 글 Prompt injection is not SQL injection (it may be worse)에서 프롬프트 인젝션은 SQL 인젝션처럼 완전히 막히지 않을 수 있으니, 없애려 하기보다 성공했을 때의 피해를 설계로 줄이라고 권했다. 필터와 분류기는 공격 비용을 올리는 한 겹으로 쓰고, 진짜 경계는 다음 절들의 권한 설계에 둔다.

에이전트와 도구 권한

챗봇이 틀린 말을 하면 화면에 틀린 글이 뜰 뿐이다. 에이전트가 속으면 메일이 나가고 파일이 지워지고 결제가 된다. 인젝션의 피해 크기는 결국 모델이 쥔 권한이 정한다. OWASP는 이를 과도한 권한(Excessive Agency)이라 부르며, 2026년판 목록에서 3위로 올렸다. 일에 필요한 것보다 많은 도구(기능), 넓은 권한, 사람 확인 없는 자율성 세 가지가 원인이다. 예를 들어 메일 요약만 하면 되는 에이전트에게 "읽기"뿐 아니라 "보내기·지우기"까지 되는 메일 API 키를 주면, 요약 기능의 버그가 곧 메일 발송 사고가 된다.

이 구조는 보안에서 오래된 이름이 있다. 혼동된 대리인(confused deputy)은 권한이 큰 프로그램이 권한 없는 쪽의 부탁을 자기 권한으로 대신 실행해 버리는 문제다. 에이전트는 사용자 권한을 가진 대리인이고, 간접 인젝션은 권한 없는 공격자가 그 대리인에게 말을 거는 길이다. NCSC는 위 글에서 LLM을 본질적으로 혼동되기 쉬운 대리인이라고 표현했다. 고전적인 혼동된 대리인은 요청자를 확인하도록 고치면 되지만, LLM은 글을 읽는 것 자체가 일이라 그 고리를 완전히 끊을 수 없다는 뜻이다.

도구 생태계에서 생기는 일

MCP(Model Context Protocol) 같은 규격 덕분에 남이 만든 도구 서버를 에이전트에 쉽게 붙일 수 있게 됐다. 이때 모델은 도구의 이름과 설명까지 읽고 언제 그 도구를 쓸지 정한다. 그래서 도구 설명 자체가 인젝션 통로가 된다. Invariant Labs는 2025년 도구 중독 공격(Tool Poisoning Attacks) 공지에서 사용자 화면에는 짧게 보이는 도구 설명 속에 모델만 읽는 지시를 숨겨, 다른 도구의 동작이나 파일 접근을 비트는 방식을 보였다. 같은 글은 처음 승인한 뒤 서버가 도구 설명을 몰래 바꾸는 경우(rug pull)도 지적했다. MCP 규격의 보안 모범 사례도 도구 서버를 신뢰 경계 밖의 코드로 다루라고 정리한다.

• 도구 서버는 공급망의 의존성과 같다. 출처를 보고, 버전을 고정하고, 설명이 바뀌면 다시 검토한다.
• 도구 설명과 도구 결과는 "바깥에서 온 글"로 취급한다. 시스템 프롬프트와 같은 신뢰를 주지 않는다.
• 한 에이전트에 여러 서버를 붙이면 한 서버의 설명이 다른 서버의 도구 사용에 영향을 줄 수 있다. 민감한 도구는 따로 떼어 둔다.

치명적 삼박자

어떤 조합이 특히 위험한지는 Simon Willison이 2025년 글 The lethal trifecta for AI agents에서 간단히 정리했다. 한 에이전트가 ① 개인 데이터에 접근하고, ② 신뢰할 수 없는 콘텐츠를 읽고, ③ 밖으로 무언가를 보낼 수 있으면, 숨은 지시 한 줄로 개인 데이터를 바깥에 보내는 길이 생긴다는 것이다. 반대로 셋 중 하나만 빼도 그 경로는 끊긴다.

밖으로 보낼 통로는 생각보다 많다. 메일 보내기나 HTTP 요청은 물론이고, 화면에 이미지를 그리게 하거나(아래 출력 처리 절), 클릭하기 좋은 링크를 만들어 주는 것도 통로다. 설계할 때 "이 에이전트는 셋 중 몇 개를 가졌나"를 먼저 세어 보는 것이 쉬운 출발점이다.

방어 설계: 모델을 믿지 않는 구조

방어의 기본 생각은 하나다. 모델은 언젠가 속는다고 가정하고, 속았을 때도 할 수 있는 일을 모델 바깥에서 정한다. 모델 안의 판단(시스템 프롬프트의 "절대 하지 마라")은 확률적이지만, 프로그램이 거는 권한 검사는 결정적이다.

이중 LLM과 CaMeL

Simon Willison이 2023년에 제안한 이중 LLM 패턴(dual LLM pattern)은 모델을 둘로 나눈다. 특권 LLM은 사용자 요청만 보고 계획을 짜며 도구를 부른다. 격리 LLM은 외부 문서를 읽고 요약하지만 도구가 없다. 격리 LLM의 결과는 글 그대로 특권 LLM에 들어가지 않고 "$VAR1" 같은 변수 이름으로만 전달된다. 외부 글에 지시가 숨어 있어도 그 글이 도구 호출을 고르는 자리에는 닿지 못한다.

Google DeepMind 등의 연구진은 2025년 논문 Defeating Prompt Injections by Design에서 이 생각을 넓힌 CaMeL을 내놓았다. 사용자 요청에서 제어 흐름(무엇을 어떤 순서로 할지)을 먼저 뽑아 고정하고, 각 데이터 값에 출처와 허용 범위를 담은 능력(capability)을 붙여 데이터 흐름을 추적한다. 그래서 "외부 메일에서 나온 값은 외부 주소로 보낼 수 없다" 같은 정책을 도구 호출 순간에 프로그램이 검사한다. 같은 해 여러 연구진이 함께 쓴 논문 Design Patterns for Securing LLM Agents against Prompt Injections은 이런 설계를 몇 가지 패턴으로 묶고, 안전해지는 만큼 에이전트가 할 수 있는 일이 줄어든다는 맞교환을 함께 정리했다.

정직하게 말하면 아직 완전한 해법은 없다. 위 설계들도 인젝션 자체를 없애지는 않고, 성공한 인젝션이 할 수 있는 일을 좁힌다. 범용 에이전트일수록 좁히기 어렵다. 그래서 위험이 큰 일에는 에이전트의 자율성을 줄이는 것이 현재로서는 가장 확실한 방어다.

민감 정보 유출과 출력 처리

모델은 컨텍스트에 있는 것을 말할 수 있다. 시스템 프롬프트, RAG로 가져온 사내 문서, 앞선 대화의 개인정보(PII)가 모두 그렇다. "이 내용은 사용자에게 말하지 마라"는 지시는 앞 절과 같은 이유로 보장이 아니다. 그래서 OWASP 목록은 시스템 프롬프트 유출을 따로 다뤄 왔고, 2026년판은 이를 숨은 맥락 노출(Hidden Context Exposure)이라는 더 넓은 이름으로 바꿨다.

• 비밀번호, API 키, 접근 규칙의 근거를 프롬프트에 넣지 않는다. 프롬프트는 언젠가 공개된다고 보고 쓴다.
• 권한 검사는 프롬프트가 아니라 검색 단계에서 한다. 이 사용자가 볼 수 없는 문서는 애초에 컨텍스트에 넣지 않는다.
• 학습이나 미세 조정에 개인정보를 넣으면 모델이 그대로 외워 내뱉을 수 있다. 넣기 전에 지우거나 가린다.
• 반대 방향의 유출도 흔하다. 직원이 기밀 문서, 고객 정보, 소스 코드를 회사가 모르는 외부 AI 서비스에 붙여 넣는 섀도 AI(shadow AI)다. 막기만 하면 몰래 쓰게 되므로, 입력을 학습에 쓰지 않는 계약의 도구를 공식으로 열어 주고 넣어도 되는 데이터 등급을 정한다. 한국 공공·금융권은 망분리 때문에 생성형 AI를 쓰기 어렵다가 데이터 등급에 따라 단계적으로 열리는 중이다(네트워크 보안 노트의 망분리 절).

모델 출력은 믿을 수 없는 입력이다

출력을 다른 프로그램이 받으면 문제가 커진다. 모델이 만든 HTML을 그대로 페이지에 넣으면 XSS, 만든 SQL을 그대로 실행하면 SQL 인젝션, 만든 셸 명령을 실행하면 원격 코드 실행이 된다. 모델 출력은 인젝션으로 공격자가 고른 글일 수 있으므로, 사용자 입력과 똑같이 웹 보안 노트의 방법(출력 인코딩, 매개변수화 쿼리, CSP)을 그대로 적용한다. OWASP 2026년판의 부적절한 출력 처리(Improper Output Handling) 항목이 이것이다.

덜 눈에 띄는 유출 통로가 마크다운 이미지다. 채팅 화면이 모델 출력의 마크다운을 그려 주면, 이미지 주소는 사용자가 누르지 않아도 브라우저가 알아서 불러온다. 인젝션으로 모델이 이미지 주소의 쿼리에 대화 속 비밀을 붙여 쓰게 만들면, 그림을 불러오는 요청 자체가 데이터를 바깥 서버에 전한다. Johann Rehberger가 2023년 Bing Chat 사례로 보고했고, 이후 여러 AI 서비스에서 같은 종류가 반복해 발견됐다.

데이터·모델 중독과 모델 공급망

데이터 중독(data poisoning)은 학습 데이터에 손을 대 모델의 행동을 바꾸는 공격이다. 웹에서 긁어 모은 데이터는 누구나 글을 올릴 수 있는 곳에서 온다. Carlini 등의 2023년 논문 Poisoning Web-Scale Training Datasets is Practical은 공개 데이터셋이 가리키는 만료된 도메인을 사들이는 방식으로 대형 데이터셋의 일부를 적은 비용에 바꿔치기할 수 있음을 보였다. 데이터셋이 내용 대신 주소 목록만 담고 있었기 때문이다.

특정 단어나 조건에서만 나쁜 행동을 하도록 심는 것을 백도어(backdoor)라 한다. 평소에는 멀쩡해 보여 시험으로 찾기 어렵다. Anthropic 등의 2024년 논문 Sleeper Agents는 일부러 백도어를 심은 모델이 그 뒤의 일반적인 안전 학습을 거쳐도 백도어 행동이 남을 수 있음을 보였다. 결국 "누가 어떤 데이터로 만든 모델인가"를 확인하는 것이 시험만큼 중요하다.

모델 파일도 코드일 수 있다

공개 모델을 내려받아 쓰는 것은 남의 패키지를 설치하는 것과 같다. 특히 Python의 pickle 형식은 객체를 되살리는 과정에서 임의의 함수를 부를 수 있어, 모델 파일을 불러오는 것만으로 코드가 실행될 수 있다. Hugging Face의 pickle 보안 문서가 이 위험과 저장소의 검사 기능을 설명한다. 대안인 safetensors는 짧은 헤더와 숫자 배열만 담는 형식이라 코드가 들어갈 자리가 없다.

• 가능하면 safetensors 같은 데이터 전용 형식을 쓰고, pickle 계열은 믿는 출처의 것만 연다. 꼭 열어야 하면 격리 환경에서 연다.
• 모델과 데이터셋도 시스템 보안 노트의 공급망 방어(버전 고정, 해시 확인, 서명, 출처 증명, 자재 명세서)를 그대로 적용한다. 모델 이름만 같고 내용이 다른 파일을 조심한다.
• 미세 조정에 쓰는 데이터, RAG 색인에 들어가는 문서도 같은 눈으로 본다. 누구나 고칠 수 있는 위키를 색인에 넣으면 누구나 그 RAG의 답을 바꿀 수 있다.

AI로 강해진 사회공학

생성형 AI는 공격자에게도 도구다. 맞춤법이 어색해 티가 나던 피싱 메일이 자연스러워졌고, 몇 초짜리 녹음으로 목소리를 흉내 내는 음성 복제와 실시간 딥페이크 영상이 쉬워졌다. 가족이 급하게 돈을 부탁하는 전화, 대표나 거래처가 화상 회의에서 송금을 지시하는 장면이 모두 흉내 낼 수 있는 것이 됐다. 미국 연방수사국(FBI)의 2024년 공지 Criminals Use Generative Artificial Intelligence to Facilitate Financial Fraud는 이런 수법을 정리하며 가족끼리 확인용 비밀 단어를 정해 두라고 권한다.

• 다른 통로로 확인(out-of-band verification): 받은 전화·메시지에 답하지 말고, 미리 알던 번호로 직접 다시 건다. 메시지 속 번호나 링크는 쓰지 않는다.
• 확인 단어: 가족이나 팀이 미리 정한, 온라인에 적힌 적 없는 단어를 묻는다.
• 절차로 막기: 송금과 계좌 변경은 두 사람 승인, 정해진 대기 시간처럼 한 사람이 급하게 처리할 수 없게 만든다. "급하다, 비밀로 하라"는 말 자체를 경고 신호로 교육한다.

기법은 새로워도 막는 법은 사람과 운영 노트의 피싱 대응과 같다. 공격자가 노리는 것은 기술이 아니라 급한 마음이고, 절차가 그 마음 대신 판단한다.

평가와 레드팀

AI 앱은 같은 입력에도 답이 조금씩 달라지고, 모델을 바꾸거나 프롬프트를 한 줄 고쳐도 행동이 바뀐다. 그래서 보안 확인도 한 번의 검사가 아니라 반복하는 과정이다.

• 평가(evals): 알려진 공격 유형과 정상 사용 예를 모은 시험 묶음을 자동으로 돌려, 거절해야 할 것을 거절하고 해야 할 일은 하는지 점수로 본다. 영국 AI 보안 연구소(AISI)의 공개 평가 도구 Inspect 같은 틀을 쓸 수 있다. 고친 공격은 시험에 넣어, 다음 변경 때 되살아나지 않는지 확인한다(회귀 시험).
• 레드팀(red teaming): 사람이 공격자의 입장에서 앱 전체를 공격해 본다. 모델만이 아니라 RAG 색인, 도구 권한, 출력이 가는 화면까지 범위에 넣는다. OWASP의 GenAI Red Teaming Guide가 범위 정하기와 진행 방법을 정리한다.
• 모니터링: 배포한 뒤에는 도구 호출, 차단된 요청, 비용과 호출량을 기록하고 이상 징후를 본다. 한 사용자가 갑자기 엄청난 양을 부르는 것도 공격(무제한 소비)일 수 있다.

시험을 통과했다는 것은 "알려진 공격은 막았다"는 뜻이지 "안전하다"는 뜻이 아니다. 그래서 평가는 앞 절의 구조적 방어를 대신하지 못하고, 그 방어가 제대로 걸려 있는지 확인하는 용도로 쓴다.

프레임워크 지도

AI 보안에는 이름이 비슷한 틀이 여럿 있어 헷갈리기 쉽다. 누가, 어떤 질문에 답하려고 쓰는지로 나누면 정리가 된다.

개발 과정 전체의 원칙으로는 영국 NCSC와 미국 CISA 등이 함께 낸 Guidelines for secure AI system development가 설계·개발·배포·운영 네 단계로 나눠 정리한다. 처음이라면 OWASP LLM 목록으로 내 앱의 위험을 훑고, 에이전트라면 에이전틱 목록을 더하고, 조직의 정책을 세울 때 NIST를 보는 순서가 무난하다.