추론 도난 (Inference Theft): 당신의 AI 엔드포인트가 타인의 무료 모델이 되는 현상

올해 초, 많은 사람들이 한 유명 패스트푸드 체인의 고객 서비스 챗봇을 무료 코딩 어시스턴트로 사용할 수 있다는 사실을 알아냈습니다. 이 사실은 입소문을 탔습니다. 어떤 고객들은 부리토를 찾으러 왔고, 다른 이들은 LeetCode 솔루션을 얻어 떠났습니다. 추론 (Inference) 비용을 지불하는 기업을 제외하고 모두가 원하는 것을 얻었습니다.

해당 챗봇은 무엇을 답변해야 하고 무엇을 답변해서는 안 되는지를 강제할 방법이 없는 유능한 범용 모델 (General-purpose model)을 기반으로 하고 있었습니다. 만약 당신이 버블 정렬 (Bubble sort)에 대한 새로운 접근 방식을 고안해 달라고 요청한다면, 모델은 시도할 것입니다. 모델은 자신이 단지 부리토 봇이어야 한다는 사실을 알지 못했으며, 그저 프롬프트 (Prompt)를 보고 응답했을 뿐입니다.

만약 당신의 AI 엔드포인트 (Endpoint)가 누가 요청을 보낼 수 있는지 제한하지 않고, 무엇을 답변하고 무엇을 답변하지 않을지에 대한 제어 수단이 없다면, 당신이 노출한 모든 범용 모델은 당신의 비용으로 모든 사람을 위한 범용 모델이 되어버립니다.

이는 추론 도난 (Inference theft)의 피해자가 되는 쉬운 방법입니다.

추론 도난은 누군가가 당신의 AI 애플리케이션을 당신이 노출할 의도가 없었던 모델 엔드포인트로 재사용할 때 발생합니다. 그들은 당신의 애플리케이션을 통해 요청을 라우팅 (Route)하고, 당신이 추론 비용을 지불하게 만듭니다. 추론 도난은 서비스 거부 지갑 공격 (Denial-of-wallet event)을 일으키는 가장 빠른 방법 중 하나입니다.

서비스 거부 지갑 공격 (Denial-of-wallet attack)에서 목표는 당신의 애플리케이션을 오프라인 상태로 만드는 것이 아닙니다. 목표는 당신이 충분한 트래픽을 감당하게 만들어 비용 자체가 공격이 되도록 하는 것입니다. AI 시스템에서 추론 도난은 공격자에게 일석이조의 효과를 줍니다. 그들은 당신의 추론 비용을 높이는 동시에 이를 수익화합니다.

저는 추론 도난에 관한 Vercel의 최근 기사를 읽었는데, 그들의 프레임워크는 경제적 측면을 다음과 같이 설명합니다: 프런티어 모델 (Frontier models)에 대한 AI 요청은 표준 HTTP 요청보다 백만 배 더 비쌀 수 있습니다. 전통적인 API 호출은 1센트의 아주 적은 비용이 들지만, 단 한 번의 비싼 에이전틱 요청 (Agentic request)은 1달러 이상의 비용이 들 수 있습니다. 이러한 비용의 비대칭성 (Cost asymmetry)은 AI 엔드포인트를 공격자가 찾을 수 있는 가장 높은 마진의 표적으로 만듭니다.

그들의 권장 사항은 요청당 봇 검증 (per-request bot verification)이며, 이는 좋은 시작입니다. 하지만 저는 이것이 다층적 접근 방식 (multi-layer approach)이 필요한 과정 중 하나의 계층이라고 생각합니다.

추론 도난 (Inference Theft)은 어떻게 작동하는가?

추론 도난의 한 형태는 다음과 같습니다:

공격자가 인터넷에 노출된 AI 엔드포인트(귀하의 챗봇, 문서 어시스턴트, 고객 서비스 에이전트 등)를 찾아냅니다.
그들은 귀하의 엔드포인트를 표준 모델 API 인터페이스로 감싸는 얇은 어댑터 (thin adapter)를 작성합니다.
그들은 모델 제공업체가 부과하는 비용의 5~10% 수준으로 해당 어댑터에 대한 액세스 권한을 판매합니다.
그들의 고객이 어댑터를 통해 프롬프트 (prompts)를 보내면, 어댑터는 이를 귀하의 엔드포인트로 라우팅합니다.
귀하는 모든 요청에 대해 전체 추론 비용 (inference cost)을 지불하게 됩니다.

이것이 바로 burrito bot에게 일어났던 일입니다. 누군가가 그 백엔드를 역공학 (reverse-engineered)하여 표준 모델 API로 감쌌고, 갑자기 누구나 패스트푸드 회사의 추론 비용을 이용해 자신의 코딩 도구를 연결할 수 있게 되었습니다.

공격자가 이를 수행하는 데 드는 비용은 어댑터를 구축하기 위한 일회성 엔지니어링 노력뿐입니다. 귀하의 비용은 정가로 지불하는 지속적인 추론 비용입니다. 이전에 웹 애플리케이션을 구축해 본 적이 있다면, 아마도 남용 방지를 위한 심리적 플레이북 (mental playbook)을 가지고 있을 것입니다. 문제는 그 플레이북이 요청 비용이 몇 달러가 아닌 1센트의 몇 분의 일 수준이었을 때 작성되었다는 점입니다.

표준적인 속도 제한 (rate limiting)을 통해 부하를 일부 덜어내고 위험을 줄일 수 있다고 생각할 수도 있습니다. 하지만 속도 제한은 공격자가 주거용 프록시 (residential proxies)를 사용하여 모두 합법적으로 보이는 여러 IP에 부하를 분산시킬 수 있기 때문에 실패합니다.

그렇다면 인증 (authentication)은 어떨까요? 엔드포인트가 유효한 토큰 (tokens)으로만 호출될 수 있도록 확인하십시오. 하지만 인증 체계를 갖추고 있더라도 공격자는 수천 개의 계정을 생성하거나 사용할 수 있습니다. 또한, 값비싼 작업의 제출 횟수를 제한하는 장치가 없다면 단 하나의 합법적인 계정만으로도 심각한 비용을 발생시킬 수 있습니다. 인증은 누가 요청을 하는지는 알려주지만, 그 사람이 얼마만큼 지출할 수 있는지는 알려주지 않습니다.

CAPTCHA 사용을 고려할 수도 있지만, CAPTCHA는 문제가 봇(bot)인 경우에만 도움이 됩니다. 설령 그렇다 하더라도, 공격자는 CAPTCHA를 단 한 번만 해결하면 그 뒤에 숨겨진 수천 개의 요청을 잠금 해제할 수 있습니다. 또한, 사용자가 당신의 부리토(burrito) 봇에게 Python 코드를 작성하라고 요청하는 것처럼, 엔드포인트가 설계되지 않은 방식으로 실제 인간이 남용하는 경우에는 CAPTCHA가 아무런 역할도 하지 못합니다.

그렇다면 실제로 무엇을 해야 할까요?

봇 탐지(Bot Detection)는 필요하지만 충분하지는 않다

요청당 봇 검증(Per-request bot verification)은 실질적인 방어 수단입니다. 익명의 웹 공개 엔드포인트(web-facing endpoints)의 경우, 행동 분석(behavioral analysis)을 통해 대량의 자동화된 트래픽을 효과적으로 식별할 수 있습니다. 하지만 이는 단 하나의 질문에만 답할 뿐입니다: 이 요청이 인간으로부터 오는 것인가?

다음 질문에는 답하지 못합니다: 이 요청이 비용이 많이 드는 모델에 적합한가? 이 사용자가 자신의 예산 범위 내에 있는가? 이 요청이 모델에 도달해야 하는가?

패스트푸드 챗봇은 봇에 의해 남용된 것이 아니라, 실제 인간들이 코딩 프롬프트를 보내고 있었습니다. 요청이 진정으로 인간의 것이었기 때문에 그 어떤 봇 탐지 기술로도 이를 잡아낼 수 없었을 것입니다.

추론 도난(Inference theft)은 다양한 형태를 띠고 있으며, 당신은 아키텍처(architecture)의 여러 지점에서 방어를 고민해야 합니다.

하나의 관문이 아닌 다층 방어 (Multiple Layers, Not One Gate)

실제로 저는 이를 비용이 많이 드는 작업이 일어나기 전에 던져지는 일련의 질문들로 생각합니다:

이것은 인간인가? → 봇 검증 (Bot verification)
이것은 허용된 콘텐츠인가? → 가드레일 적용 (Guardrails enforcement)
이것에 큰 모델이 필요한가? → 비용 인지 라우팅 (Cost-aware routing)
...

각 계층은 서로 다른 질문에 답하며, 서로 다른 각도에서 시스템을 보호합니다.

모든 시스템에 이 모든 것이 필요한 것은 아닙니다. 신뢰할 수 있는 사용자들이 VPN 뒤에서 내부 도구를 사용하고 있다면, 봇 검증은 중요하지 않을 수 있습니다. 적절한 조합은 당신의 위협 모델(threat model), 비용 허용 범위, 그리고 엔드포인트가 세상에 어떻게 노출되어 있는지에 따라 달라집니다.

그럼에도 원칙은 유효합니다: 비용이 많이 드는 모델은 체인의 첫 번째 단계가 아니라, 요청이 정당한지 평가하는 과정의 마지막 단계여야 합니다.

프롬프트는 제안일 뿐이며, 가드레일은 아키텍처다

모델에는 경계가 없습니다. 가드레일 (Guardrails)이 마련되어 있지 않으면, 모델은 당신이 무엇을 묻든 답변할 것입니다. 그것이 모델을 유용하게 만드는 요소이지만, 동시에 감독되지 않거나 보안이 확보되지 않았을 때 비용을 발생시키는 원인이기도 합니다.

만약 당신의 고객 서비스 봇이 연결 리스트 (Linked List)를 기꺼이 역순으로 정렬해 준다면, 그 봇은 경계가 없는 것입니다. 이때 본능적으로는 프롬프트 엔지니어링 (Prompt Engineering)을 더 강하게 시도하게 됩니다: "우리 메뉴에 관한 질문에만 답변하세요." 하지만 프롬프트는 제안일 뿐 실제적인 강제력이 아니며, 결심을 굳힌 사용자는 프롬프트 수준의 지침을 우회할 수 있습니다.

최소한의 조치는 콘텐츠 필터링을 위한 입력 및 출력 가드레일을 통해 모델 계층 자체에서 경계를 강제하는 것입니다. AWS에서는 Amazon Bedrock Guardrails를 통해 이러한 정책을 코드가 아닌 설정으로 정의할 수 있으며, 다른 제공업체들도 유사한 기능을 제공합니다.

가드레일은 입력과 출력을 검사하며, 정책 위반이 감지될 경우 요청이 모델에 도달하는 것을 차단할 수 있습니다. 가드레일은 다음과 같은 도움을 줄 수 있습니다:

애플리케이션이 지원하지 않는 주제에 대한 프롬프트 차단
프롬프트 인젝션 (Prompt Injection) 시도 필터링
주제에서 벗어난 응답 포착
모델 출력에서 개인정보 (PII) 삭제
양방향 모두에서 유해하거나 정책을 위반하는 콘텐츠 거부

하지만 가드레일은 결정론적 (Deterministic)이지 않고 확률론적 (Probabilistic)입니다. 대부분의 위반 사항은 잡아내겠지만, 모든 사항을 잡아내지는 못합니다. 결국 무언가는 빠져나가게 마련이므로, 가드레일은 유일한 방어선이 아니라 여러 계층 중 하나로서 작동할 때 가장 효과적입니다.

최근 한 강연에서 어떤 분이 가드레일은 요청당 비용이 발생하기 때문에 회사에서 지불하고 싶어 하지 않는다고 말하는 것을 들었습니다. 그 본능은 이해하지만, 잘못된 비교입니다. 당신은 예측 가능한 호출당 비용과 예측 불가능하며 잠재적으로 무제한적인 비용을 비교하고 있는 것입니다. 지갑 거부 (Denial-of-wallet) 사고에는 상한선이 없지만, 가드레일 청구서에는 상한선이 있습니다.

이러한 공격이 성공하는 근본적인 이유는 비용 비대칭성 (cost asymmetry) 때문이며, 비싼 모델 앞에 저렴한 검사 단계를 추가하는 것은 그 비대칭성을 다시 귀하의 편으로 돌려놓는 일입니다. 만약 경계 강제 (boundary enforcement)가 필요하다고 결정했다면, 비용은 이를 제공하는 레이어를 건너뛸 만한 약한 이유가 되지 못합니다. 이를 배우는 가장 비싼 방법은 가드레일 (guardrails)을 건너뛰었다가, 예상치 못한 5~6자릿수의 추론 (inference) 비용 청구서를 받고 나서 결국 가드레일을 켜는 것입니다. 매 순간 선제적인 대응이 사후 대응보다 저렴합니다.

무엇이 범위 내 (in-scope)에 있는지 정의하는 방식은 귀하의 도메인에 따라 다르며, 보편적인 정답은 없습니다. 하지만 만약 범위를 정의하고 이를 강제할 방법을 찾지 못했다면, 귀하는 모델 스스로가 자신의 사용량을 감시하도록 의존하고 있는 것입니다. 그것은 귀하가 고용할 수 있는 가장 비싼 보안 요원(bouncer)입니다.

비용 인식 라우팅 (Cost-Aware Routing): 필요에 맞는 모델 매칭

범위 내에 있더라도, 모든 요청이 동일한 리소스를 필요로 하지는 않습니다.

예를 들어, "영업시간이 어떻게 되나요?"와 "200명 규모의 행사를 위한 세 가지 다른 케이터링 옵션을 비교하는 것을 도와줄 수 있나요?"는 둘 다 주제에 부합할 수 있습니다. 하지만 이들은 복잡도가 다르며, 두 요청을 동일한 비용으로 동일한 프런티어 모델 (frontier model)에 라우팅하는 것은 합리적이지 않습니다.

귀하는 다음과 같은 계층적 라우팅 (tiered routing)을 사용해야 합니다:

단순하거나 자주 묻는 질문 → 캐시된 응답 (cached response) 또는 소형 모델 (small model)
중간 정도의 복잡도 → 표준 모델 (standard model)
높은 복잡도 → 프런티어 모델 (frontier model)

훌륭한 라우팅 레이어는 운영 비용을 줄이면서도 사용자에게는 제품이 동일하게 느껴지도록 만듭니다.

이를 구현하는 방법은 귀하의 아키텍처 (architecture)에 따라 다릅니다. 언급할 만한 몇 가지 패턴이 있습니다:

의도 기반 라우팅 (Intent-based routing)
어떤 모델이 요청을 처리할지 선택하기 전에, 경량 분류기 (lightweight classifier)를 사용하여 요청의 복잡도를 분류합니다. 영업시간에 대한 질문은 단순한 것으로 표시되어 캐시된 응답이나 소형 모델로 라우팅됩니다. 더 복잡하거나 개방형인 질문은 복잡한 것으로 표시되어 더 유능한 모델로 라우팅됩니다.

에이전트 기반 라우팅 (Agent-based routing)
어떤 다운스트림 모델(downstream model)이나 도구가 요청을 처리할지 결정하는 것만을 유일한 임무로 하는 저렴한 오케스트레이터(orchestrator) 에이전트를 구축하십시오. 오케스트레이터 자체는 소형 모델(small model)에서 실행되므로 호출당 비용이 낮습니다. 오케스트레이터는 입력을 살펴보고, 핸들러(handler)를 선택한 뒤, 요청을 전달합니다. 이는 워크플로 기반(workflow-based) 솔루션보다 더 유연하지만, 단계(hop)가 추가되어 지연 시간(latency)이 발생합니다.

관리형 모델 라우터 (Managed model routers)
일부 플랫폼은 모델 라우팅 기능을 기본적으로 제공합니다. AWS의 경우, Amazon Bedrock는 주어진 요청에 대해 가장 비용 효율적인 모델을 자동으로 선택하는 지능형 프롬프트 라우팅(intelligent prompt routing)을 제공하며, 여러 AI 게이트웨이(AI gateways) 및 모델 라우팅 서비스들도 유사한 기능을 제공합니다. 만약 이러한 기능을 사용할 수 있다면, 최소한의 엔지니어링 노력으로 계층형 라우팅(tiered routing)을 구현할 수 있는 가장 빠른 경로가 될 수 있습니다.

이 방법들은 서로 배타적이지 않으며, 완벽한 것도 없습니다. 의도 분류기(Intent classifiers)는 잘못된 경로로 라우팅할 수 있고, 오케스트레이터 에이전트는 지연 시간을 추가하며, 관리형 라우터는 결정 로직에 대한 제어권을 덜 제공합니다. 귀하의 트래픽 패턴에 무엇이 적합한지 테스트하고 반복(iterate)해야 합니다.

여기서 핵심은, 복잡도와 상관없이 모든 요청이 동일한 고비용 모델에 도달한다면, 대부분의 요청에 대해 과도한 비용을 지불하고 있는 것이며, 그 과정에서 스스로를 남용(abuse)의 더 매력적인 표적으로 만들고 있다는 점입니다.

예산 제어: 접근의 차원으로서의 비용

모든 요청이 정당하고, 주제에 맞으며, 올바르게 라우팅된다 하더라도, 여전히 사용자별 비용 제어가 필요합니다.

표준 속도 제한(Standard rate limiting)은 기대만큼 깔끔하게 적용되지 않습니다. 표준 속도 제한기는 단일 사용자를 분당 90개의 요청으로 제한할 수 있으며, 비(非) AI 시스템에서는 이것이 다운스트림 구성 요소를 보호하기에 충분할 수 있습니다. 하지만 각 요청의 추론(inference) 비용이 0.30달러라면, 이는 분당 27달러이며, 하루에 약 39,000달러를 소진하는 속도에 가깝습니다. 요청량 자체는 괜찮을지 몰라도, 요청당 비용은 비즈니스 성격에 따라 잠재적으로 재앙적인 수준이 될 수 있습니다.

귀하에게 필요한 것은 비용 인식 속도 제한(cost-aware rate limiting)입니다. 이 패턴은 사용자별 또는 테넌트별(per-tenant) 추론 예산과 유사한 형태를 띱니다:

정상적인 사용(Normal usage)     → 전체 액세스 허용(full access)
한도 도달 임박(Approaching cap)  → 알림 또는 경고(notify or warn)
한도 도달(At cap)               → 더 저렴한 모델로 다운그레이드(downgrade to cheaper model)
...

이것은 추론(inference)을 켜거나 끄는 이진 스위치(binary switch)일 필요는 없습니다. 집행(enforcement) 단계에 여러 수준을 둘 수 있습니다. 사용자가 한도에 도달하기 시작할 때 모델 품질을 낮추거나, 지연 시간(latency)을 늘리거나, 추가 인증을 요구하거나, 혹은 이들을 조합하여 적용할 수 있습니다. 이렇게 하면 서비스 경험이 갑작스럽게 끊기는 대신 점진적으로 저하(degrade gracefully)됩니다.

이는 적대적 사용자(adversarial users)가 없는 상황에서도 중요합니다. 이 경우, 예상보다 더 많은 자원을 소비하는 정당한 사용자(legitimate users)로부터 시스템을 보호하는 것이 목적입니다. 하지만 예산 제어(budget controls)가 없다면 그 차이를 구분할 수 없으며, 양쪽 상황 모두에 비례하여 대응할 수도 없습니다.

개념적으로 구현은 두 가지로 요약됩니다: 식별자(identity)별 지출을 추적하는 것과, 해당 지출을 기반으로 액세스 결정(access decisions)을 내리는 것입니다.