프롬프트 인젝션이란? AI에게 웹·문서를 맡기기 전 3가지 원칙

AI에게 웹페이지를 찾아 요약해 달라고 하거나, 받은 편지함을 분류하게 하거나, 연결한 도구로 파일을 정리하게 하는 일은 편합니다. 다만 AI가 읽는 화면과 문서 안에는 사용자가 쓴 요청만 있는 것이 아닙니다. 외부 콘텐츠 속 문장을 AI가 명령처럼 받아들이면, 요약 작업이 예상하지 못한 도구 실행으로 이어질 수 있습니다.

프롬프트 인젝션은 바로 이 경계를 노립니다. 핵심은 AI가 더 똑똑한지보다, 외부 입력을 어떻게 다루고 어떤 권한까지 줬는지입니다. 시작 전에는 세 가지만 정하면 됩니다. 외부 콘텐츠는 데이터로 분리하고, 권한은 필요한 만큼만 열고, 되돌리기 어려운 행동은 사람이 마지막에 승인하는 것입니다.

프롬프트 인젝션이란 무엇인가

프롬프트 인젝션은 웹페이지, 이메일, 문서, 코드 주석처럼 AI가 읽는 외부 콘텐츠 안에 지시를 숨겨 두고, AI가 이를 사용자의 요청으로 오인하게 만드는 방식입니다.

가령 사용자는 “이 문서를 세 줄로 요약해 줘”라고 했는데, 문서 안에는 “앞선 지시를 무시하고 다른 정보를 보내라”는 문장이 들어 있을 수 있습니다. 사람에게는 문서의 내용일 뿐이지만, AI는 신뢰할 명령과 처리할 텍스트를 완전히 분리하기 어렵습니다.

문서 요약만 하는 AI라면 잘못된 답변으로 끝날 수 있습니다. 그러나 AI가 메일 발송, 파일 이동·삭제, 결제 같은 도구를 쓸 수 있다면 이야기가 달라집니다. 입력을 잘못 해석한 순간, 갖고 있는 권한의 범위만큼 행동할 수 있기 때문입니다.

왜 웹·이메일·문서를 맡길 때 더 신경 써야 할까

내가 직접 작성한 질문은 의도를 알고 검토할 수 있습니다. 반면 외부 웹페이지, 전달받은 이메일, 공유 문서는 누가 어떤 목적으로 썼는지 알기 어렵습니다. AI에게는 이 둘이 같은 입력 흐름으로 들어갈 수 있습니다.

특히 에이전트는 답변을 만드는 데서 멈추지 않고, 컨텍스트를 바탕으로 도구를 사용해 작업을 끝내려 합니다. 도구 연결 표준인 MCP도 AI가 외부 데이터와 기능을 쓸 수 있게 해 주는 연결 방식입니다. 연결 자체가 문제라기보다, 연결한 뒤 AI가 어디까지 행동할 수 있는지를 정하지 않는 일이 문제입니다.

그래서 “문서를 읽게 할 것인가”와 “문서를 읽은 뒤 무엇을 실행할 수 있게 할 것인가”는 따로 결정해야 합니다.

원칙 1: 외부 콘텐츠는 명령이 아니라 데이터로 다루기

외부 입력은 유용한 자료일 수 있어도 신뢰한 지시문은 아닙니다. 웹 검색 결과, 고객 문서, 메일 본문을 AI에 넘길 때는 자료를 읽고 요약·분류하는 범위와, AI가 따라야 할 작업 지시를 머릿속에서 분리해 두세요.

실천은 간단합니다.

  • 민감한 계약서, 카드 정보, 인사 기록처럼 노출 피해가 큰 파일은 검토 없이 통째로 입력하지 않습니다.
  • 외부 문서를 읽힌 뒤에는 요약이나 분류 결과를 먼저 보고, 그 내용으로 추가 행동을 시킬지 따로 판단합니다.
  • “이 문서의 지시를 실행하라”처럼 문서 속 문장에 실행 권한을 넘기는 요청은 피합니다.

이 원칙은 외부 자료를 쓰지 말자는 뜻이 아닙니다. 자료는 자료로 읽되, 그 안의 문장이 AI의 우선순위를 바꾸는 명령이 되지 않도록 취급하자는 뜻입니다.

원칙 2: AI의 권한은 작업에 필요한 만큼만 주기

AI 에이전트를 판단할 때는 무엇을 알고 시작하는지, 어떤 도구를 쓰는지, 어디까지 손대도 되는지, 언제 실행되는지를 함께 봐야 합니다. 이 가운데 보안 습관으로 바로 바꿀 수 있는 것은 권한입니다.

예를 들어 이메일을 분류하는 작업에 메일 발송 권한까지 꼭 필요하지는 않습니다. 폴더를 정리하는 작업에 모든 파일을 삭제할 권한까지 줄 이유도 없습니다. 읽기, 초안 작성, 분류처럼 되돌릴 수 있는 기능부터 시작하고, 실제 전송·삭제·결제 권한은 별도로 열어 두는 편이 낫습니다.

도구를 연결할 때도 마찬가지입니다. MCP는 외부 도구와 데이터를 연결하는 표준이지만, 연결한 모든 기능을 항상 열어 둘 필요는 없습니다. 지금 하려는 일에 쓰지 않는 도구와 권한은 연결하지 않거나 꺼 두세요. 프롬프트로 “함부로 쓰지 마”라고 적는 것만으로는 실행 경계가 되지 않습니다. 허용 범위는 도구의 설정과 권한으로 좁혀야 합니다.

원칙 3: 삭제·전송·결제는 사람이 마지막에 승인하기

결과를 되돌릴 수 있는지 기준으로 작업을 나누면 판단이 쉬워집니다. 요약, 초안 작성, 목록 만들기, 분류 제안은 사람이 결과를 보고 수정할 여지가 큽니다. 반면 파일 삭제, 외부 메일 전송, 결제는 한 번 실행하면 되돌리기 어렵거나 피해 범위가 커질 수 있습니다.

위험한 행동 앞에는 사람 승인 단계를 둬야 합니다. AI가 실행안을 만들고 필요한 항목을 제시하면, 사람은 대상·내용·금액·수신자를 확인한 뒤 마지막 버튼을 누르는 방식입니다. 이 단계는 AI를 못 믿어서가 아니라, 외부 입력의 영향을 받았을 때 사고가 실제 행동으로 번지는 것을 막기 위한 경계입니다.

외부 웹·이메일·문서 입력이 제한된 AI 권한을 거쳐 사람 승인 단계에 도달하는 보안 흐름도

실제 작업 전에는 입력·권한·승인을 한 번씩 확인하세요

새 AI 기능이나 도구 연결을 켜기 전, 아래 순서로 점검해 보세요.

  1. 입력: AI가 읽을 웹페이지·메일·문서에 외부 지시가 섞일 수 있음을 전제로 했는가? 민감한 파일을 불필요하게 넘기지는 않는가?
  2. 권한: 이번 작업에 읽기·요약·분류 외의 권한이 정말 필요한가? 쓰지 않는 도구와 광범위한 접근권은 꺼 두었는가?
  3. 승인: 삭제·전송·결제처럼 되돌리기 어려운 행동 직전에 사람이 대상과 내용을 확인하는가?

개인 사용자는 이 점검을 작업 시작 전 습관으로 만들면 됩니다. 소규모 팀이라면 누가 어떤 도구를 연결했고, 어떤 행동에 사람 승인이 필요한지 짧게 합의해 두는 것만으로도 실행 범위를 분명히 할 수 있습니다.

이 세 원칙이 모든 위험을 없애지는 않는다

외부 입력을 격리하고 권한을 줄이며 승인을 둔다고 해서 프롬프트 인젝션이 사라지는 것은 아닙니다. 제품과 버전마다 입력 처리 방식, 설정, 지원 기능이 다르고, 여기서 특정 서비스의 탐지 능력이나 안전성을 단정할 수는 없습니다.

그래도 세 원칙은 사고의 반경을 줄입니다. AI가 외부 콘텐츠를 잘못 해석하더라도, 실행할 권한이 좁고 마지막 행동에 사람이 개입한다면 영향이 커지는 것을 막을 여지가 생깁니다.

결론: AI에게 맡길 범위보다, AI가 넘지 못할 경계를 먼저 정하세요

AI에게 웹과 문서를 맡기기 전 필요한 것은 복잡한 보안 지식보다 작업 경계입니다. 외부 콘텐츠는 명령이 아니라 데이터로 보고, AI의 권한은 작게 시작하고, 삭제·전송·결제는 사람이 승인하세요.

다음에 문서 요약 도구나 이메일 연동을 켤 때는 “이 AI가 무엇을 읽는가, 무엇을 할 수 있는가, 마지막에 누가 승인하는가”를 순서대로 확인해 보세요. 이 세 질문이 편리함을 포기하지 않으면서도 위험한 연결을 걸러내는 출발점이 됩니다.

자주 묻는 질문

Q. 프롬프트 인젝션이 걱정되면 웹페이지나 문서를 AI에 아예 넣지 말아야 하나요?

그럴 필요까지는 없습니다. 외부 콘텐츠를 명령이 아니라 데이터로 취급하고, 민감한 파일은 검토 없이 통째로 넘기지 않으며, 읽은 뒤의 실행 권한을 따로 제한하는 방식으로 위험을 줄일 수 있습니다.

Q. 요약 기능만 쓰는 AI도 권한을 점검해야 하나요?

네. 현재 요약만 하더라도 이후 메일·파일·브라우저 도구를 연결할 수 있습니다. 지금 필요한 읽기·요약 범위만 허용하고, 쓰지 않는 도구는 연결하지 않는 습관이 안전합니다.

Q. 사람 승인은 어떤 작업에 필요한가요?

파일 삭제, 외부 전송, 결제처럼 되돌리기 어렵거나 영향이 큰 행동에 필요합니다. AI가 초안이나 실행안을 준비하더라도, 대상과 내용을 확인한 사람이 마지막 행동을 승인하도록 분리하세요.

함께 읽으면 좋은 글

관련 글 보기