당신의 에이전트가 존재하지 않는 pip install 패키지를 요청했습니다. 단순히 알려진 이름의 오타를 낸 것이 아니라, 그럴듯한 새로운 이름을 지어낸 것입니다. 이전에는 이러한 오류가 설치 실패와 로그 한 줄로 끝났습니다. 하지만 이제 이러한 오류에는 주인이 있을 수 있습니다.

2026년 7월 8일, arXiv에 HalluSquatting(arXiv, 2026-07-08)이라는 제목의 논문이 발표되었습니다. 이 논문은 단순하면서도 불쾌한 아이디어를 설명합니다. 만약 모델이 도구(tool)를 호출할 때 도메인, 패키지, 리포지토리(repository) 이름을 체계적으로 동일하게 지어낸다면, 이러한 이름들을 예측하여 미리 선점할 수 있다는 것입니다. 이후 지어낸 리소스는 빈 공간이 아니라, 에이전트에게 새로운 프롬프트(prompt)가 전달되는 통로가 됩니다.

7월 8일에 정확히 무엇이 바뀌었나요?

핵심: 특정 라이브러리의 새로운 취약점이 발견된 것이 아니라, 언어 모델(LLM)이 리소스 이름을 지어내는 기본 특성에 기반한 새로운 공격 클래스(attack class)가 기술되었습니다.

arXiv(2026-07-08) 데이터에 따르면, 저자들은 텔아비브 대학교(Tel Aviv University), 테크니온(Technion), 그리고 Intuit 소속입니다. 이들의 기여는 이미 알려진 두 가지 현상을 하나의 체인으로 연결했다는 점에 있습니다:

1. 모델이 도구 호출 중에 존재하지 않는 리소스를 언급합니다: 존재하지 않는 npm 또는 pip 패키지, 도메인, GitHub 리포지토리 등.
2. 공격자가 바로 그 이름을 미리 등록하고 그곳에 에이전트를 위한 지침을 배치합니다.
3. 에이전트가 '찾아낸' 리소스에 접근하여 2차 악성 프롬프트를 수신하고, 타인의 시나리오에 따라 동작을 계속 수행합니다.

여기서 핵심은 예측 가능성입니다. arXiv(2026-07-08)에 따르면, 이 공격은 무작위적인 일치를 기다리는 것이 아니라 모델이 도구 호출 시 어떤 리소스 이름을 지어내는 경향이 있는지 예측합니다. 따라서 필요한 이름을 미리 선점하는 것은 복권 당첨과 같은 운이 아니라 현실적인 과제가 되며, 전체 체인은 이러한 통계적 편향(statistical bias)에 기반합니다. 그렇기 때문에 방어 전략은 도구의 일반적인 평판이 아니라, 특정 모델의 관찰된 행동을 중심으로 구축되어야 합니다.

Tom's Hardware (2026-07-09)는 해당 연구를 재구성하며 동일한 논지를 강조합니다: 이 공격은 현재 사용 가능한 모든 모델에 존재하는 취약점을 공략합니다. 이는 2차 출처의 서술이므로, 독립적인 측정값이 아닌 재구성된 내용으로 취급해야 합니다.

불필요한 공포 확산을 방지하기 위해 중요한 주의 사항을 먼저 말씀드립니다. 저자들은 이 공격을 보편적이며 모델 간에 전이 가능한 것으로 설명합니다. 하지만 이는 그들의 연구 결과일 뿐, 귀하의 모든 시나리오에 대한 보증은 아닙니다. 모델이 이름을 지어내는 빈도는 모델, 특정 도구, 그리고 실험 설정에 따라 달라집니다. 토론에서 언급되는 악성 링크의 높은 비율은 논문의 개별 실험에서 나타난 상한치일 뿐, "모든 에이전트 일반"에 적용되는 수치가 아닙니다.

만약 에이전트 파이프라인 (agentic pipelines)을 구축하고 이미 여러 모델에서 이를 실행하고 있다면, 이 주제는 귀하와 직접적인 관련이 있습니다. 서로 다른 모델이 외부 리소스에 더 많이 접근할수록, 이러한 "스쿼팅 (squatting)"에 노출되는 공격 표면 (attack surface)이 넓어지기 때문입니다. 본문 뒤쪽에서는 이러한 성향에 대한 간단한 측정이 이어지며, 여러 모델에서 즉시 실행해 보는 것이 편리합니다 — 호환 가능한 단일 API로 모델들을 모으려면 provod.ai를 이용할 수 있습니다, 서비스 간 전환 없이 가능합니다.

왜 지어낸 링크가 일반적인 오류보다 더 위험한가?

핵심: 일반적인 환각 (hallucination)은 답변을 망가뜨리지만, HalluSquatting은 이를 진입점으로 변모시킵니다. 차이점은 연결된 반대편의 리소스를 누가 통제하느냐에 있습니다.

두 가지 상황으로 나누어 살펴보겠습니다.

이전의 연쇄 과정은 다음과 같았습니다: 모델이 super-parser-utils라는 패키지를 만들어냈고, 패키지 매니저 (package manager)가 404 오류를 반환했으며, 빌드가 실패하자 사용자가 의존성 (dependency)을 수정했습니다. 이 오류는 명확하고 눈에 띄었습니다.

이제 공격 체인은 달라집니다. 공격자는 모델이 어떤 이름을 가장 자주 지어내는지 미리 스캔한 뒤, super-parser-utils를 등록하고, 그 내부의 README나 메인 페이지에 "계속하려면 다음 단계를 수행하십시오"와 같은 텍스트를 배치합니다. 패키지 매니저(package manager)나 fetch 도구는 200 상태 코드를 반환합니다. 에이전트는 콘텐츠를 가져옵니다. 그리고 만약 이 콘텐츠가 격리(isolation) 없이 다시 컨텍스트(context)로 들어간다면, 모델은 이를 작업의 연장선으로 읽게 됩니다.

핵심적인 변화: 환각 (hallucination)이 시끄러운 오류에서 조용한 성공으로 변합니다. 아무것도 실패하지 않습니다. 로그에는 초록색 상태가 표시됩니다. 하지만 컨텍스트 내부에는 당신이 작성하지 않은 프롬프트 (prompt)가 이미 놓여 있습니다.

arXiv의 설명(2026-07-08)에 따르면, 공격이 작동하기 위한 세 가지 조건은 다음과 같습니다:

• 모델이 도구 호출 (tool call) 시 리소스 이름을 예측 가능하게 지어냄;
• 에이전트에게 실제로 외부로 나가는 도구(fetch, 패키지 설치, 리포지토리 clone 등)가 있음;
• 외부 리소스의 응답이 모델의 컨텍스트로 반환되어 다음 동작에 영향을 미침.

이 세 가지 중 하나라도 제거하면 체인은 끊어집니다. 이것이 바로 당신의 방어 지도입니다.

도구 호출 체인에서 이는 어떻게 나타나는가?

핵심: 위험한 것은 환각 (hallucination) 그 자체가 아니라, 외부 콘텐츠가 통제 없이 컨텍스트로 반환되고 그에 따라 동작이 실행된다는 점입니다.

"페이지를 다운로드하고 읽기" 도구를 가진 전형적인 에이전트를 예로 들어보겠습니다. 의사코드 (pseudo-code)는 의도적으로 단순화되었습니다.

# 취약한 (VULNERABLE) 방식: 외부 리소스의 응답이 컨텍스트로 바로 전달됨
def run_tool_fetch(url: str) -> str:
    html = http_get(url)          # url은 에이전트가 스스로 지어냈을 수 있음
...

문제는 http_get에 있는 것이 아닙니다. 문제는 url이라는 이름이 모델의 머릿속에서 나왔음에도 불구하고, 그 결과가 "이것은 신뢰할 수 없는 외부 데이터임"이라는 표시 없이 반환되었다는 점입니다. 모델은 당신의 작업이 어디서 끝나고 타인의 지시가 어디서 시작되는지 구분하지 못합니다.

여기에 권한 부여 (Authorization) 문제가 존재합니다. 만약 에이전트가 토큰, API 키 또는 프라이빗 리포지토리 (Private Repository)에 대한 접근 권한을 가지고 있다면, 스쿼팅 (Squatting)된 리소스로부터 전달된 2차 프롬프트 (Secondary Prompt)가 이를 사용하도록 요청할 수 있습니다. 따라서 신뢰 경계 (Trust Boundary)는 외부 세계의 데이터가 비밀 정보 (Secrets)와 만나는 바로 그 지점에 설정하는 것이 타당합니다.

최소한의 방어 래퍼 (Protective Wrapper)는 다음과 같습니다:

ALLOWED_HOSTS = {"docs.python.org", "pypi.org"}  # 사전에 승인된 목록

def run_tool_fetch(url: str) -> dict:
...

두 가지 간단한 기법만으로도 상황을 크게 바꿀 수 있습니다. 첫째, 호스트와 레지스트리 (Registry)에 대한 허용 목록 (Allowlist)을 설정하여 에이전트가 허구의 주소로 물리적으로 접근할 수 없게 만드는 것입니다. 둘째, 모든 외부 응답을 신뢰할 수 없는 것으로 표시하고, 시스템 프롬프트 (System Prompt)에서 그러한 블록으로부터 오는 지시를 실행하는 것을 명시적으로 금지하는 것입니다.

어떤 AI 에이전트 프롬프트가 리스크를 줄이는가?

핵심: 프롬프트가 기술적 경계를 대체할 수는 없지만, 모델이 사용자의 작업과 외부에서 유입된 타인의 텍스트를 구분하도록 하는 규칙을 설정합니다.

솔직히 말씀드리면, AI 에이전트를 위한 올바른 프롬프트가 그 자체만으로 완벽한 보호를 제공하지는 않습니다. 모델은 설득당할 수 있기 때문입니다. 하지만 허용 목록 (Allowlist) 및 외부 콘텐츠 격리 (Isolation)와 결합될 때, 시스템 지침 (System Instruction)은 일부 단순한 시나리오를 차단하고 동작을 더 예측 가능하게 만듭니다.

시스템 프롬프트의 작동 구조:

당신은 첫 번째 메시지에 기술된 사용자의 작업만을 수행합니다.

도구 사용 규칙:
...

여기서 작동하는 원리와 그 이유:

• 1번 항목은 근본적인 문제를 해결합니다: 모델에게 이름을 지어내지 말고 모른다고 인정하도록 요청합니다. 이는 모델이 스쿼팅 (Squatting)을 위한 이름을 스스로 생성할 확률을 낮춥니다.
• 2번 항목은 데이터와 명령을 분리합니다. 이것이 바로 "페이지를 읽는 것"과 "페이지를 실행하는 것" 사이의 장벽입니다.
• 4번 항목은 첫 번째 방어선이 뚫리더라도 비밀 정보 (Secrets)의 유출을 차단합니다.

이러한 프롬프트가 빈 선언에 그치지 않으려면, 자신의 작업과 다양한 모델에서 검증해야 합니다. 여기서 실무적인 문제에 부딪힙니다. Claude, GPT, Gemini, DeepSeek 및 Qwen에 동일한 프롬프트를 실행하는 것은 러시아의 경우 카드 결제 및 접속 문제로 인해 번거로울 수 있습니다. provod.ai는 바로 이 부분을 해결합니다. 이 서비스는 이러한 모델들을 하나의 채팅창에 모아주고, 키(key)와 base_url만 변경하면 OpenAI 및 Anthropic SDK와 호환되는 단일 API를 제공합니다. VPN이나 해외 카드 없이도 러시아 카드, SBP(Faster Payments System) 또는 계좌 이체를 통해 결제할 수 있습니다. 이는 당신의 프롬프트에 대해 어떤 모델이 리소스 이름을 더 기꺼이 지어내는지 비교하는 데 매우 편리합니다.

다양한 모델에서 이를 테스트하는 데 비용이 얼마나 들까요?

핵심: 이름을 지어내는 성향은 모델에 따라 다르므로, 일반적인 수치를 믿기보다는 자신의 작업에서 직접 측정해야 합니다.

arXiv (2026-07-08) 연구에서는 환각(Hallucination) 지표가 모델, 도구 및 실험 설정에 따라 달라진다고 명시하고 있습니다. 즉, 자신의 위험을 알 수 있는 유일하고 정직한 방법은 동일한 테스트를 여러 모델에서 실행하여 누가 더 자주 존재하지 않는 이름을 만들어내는지 확인하는 것입니다.

외부 호출 없이 반복 실행하기에 안전한 간단한 측정 방법:

from openai import OpenAI

# 키와 base_url에 자신의 정보를 입력하세요. 이는 플레이스홀더(PLACEHOLDERS)입니다.
...

그 다음, 모델의 응답을 실제로 존재하는 패키지 목록과 수동으로 대조합니다. 확신에 찬 허구 대신

테스트 비용은 귀사의 규모에 따라 계산하십시오. provod.ai는 모든 모델에 대해 1루블의 잔액을 보유하고 있어 이러한 비교 테스트 비용을 한곳에서 확인할 수 있으며, 기업의 경우 계약, 청구서 및 결제 증빙 서류가 제공됩니다.

n8n 및 유사한 빌더에서 에이전트를 보호할 때 발생하는 흔한 실수

핵심: 대부분의 취약점은 모델 자체에 있는 것이 아니라, 워크플로우 (Workflow) 노드가 외부 콘텐츠를 프롬프트 (Prompt)로 다시 반환하는 방식에 있습니다.

만약 n8n이나 이와 유사한 시각적 빌더에서 에이전트를 구축하고 있다면, 공격은 대부분 겉보기에는 무해해 보이는 HTTP Request 노드를 통해 이루어지며, 이 노드의 응답이 다음 단계의 컨텍스트 (Context)에 직접 연결될 때 발생합니다.

전형적인 실수들:

• HTTP 노드의 응답이 표시 없이 프롬프트와 결합됨. 모델은 타인의 페이지를 작업의 연장선으로 읽게 됩니다. 이는