LLM 재킹(LLMjacking) – 유출된 클라우드 키 하나가 하루 1억 원 넘는 청구서가 되는 이유

작성자 이 정대 작성일 11월 9, 2026 조회수 16

안녕하세요. GS Neotek 이정대 입니다.

클라우드를 운영하다 보면 “액세스 키 유출”이라는 말을 한 번쯤은 듣게 됩니다.
직접 겪지는 않았더라도 주변 사례나 뉴스, 보안 점검 결과를 통해 접해 보신 분이 많을 것 같습니다.
예전에는 유출된 키로 가상 서버를 잔뜩 띄워 암호화폐를 채굴하는 경우가 대표적이었고, 피해가 작지는 않아도 대부분 수습할 수 있는 범위 안에서 정리되곤 했습니다.

그런데 최근에는 양상이 완전히 달라지고 있습니다.
2026년 11월 Google 위협 인텔리전스 그룹(GTIG)과 Mandiant가 공개한 LLM 재킹 보고서에는 하루에 10만 달러(약 1억 4천만 원) 넘게 청구된 사례와, 접근을 끊기 전까지 누적 100만 달러에 이른 사례가 나옵니다.

이번 글에서는 LLM 재킹이 무엇인지, 왜 이렇게 짧은 시간에 비용이 커질 수밖에 없는지, 그리고 AWS, Google Cloud 같은 대형 클라우드를 쓰는 조직이 무엇을 점검해야 하는지 정리해 보겠습니다.

한눈에 보기

LLM 재킹이란

LLM 재킹(LLMjacking)은 남의 클라우드 계정에서 LLM을 몰래 쓰고, 그 요금을 계정 주인에게 떠넘기는 공격입니다.
2024년 5월 보안 기업 Sysdig가 처음 이름을 붙였고, 그 뒤로 여러 보안 기관이 비슷한 사례를 계속 보고하고 있습니다.

예전의 크립토재킹이 남의 컴퓨팅 자원으로 암호화폐를 캤다면, LLM 재킹은 남의 계정으로 Claude, GPT, Gemini 같은 고가 모델을 호출합니다.
Google GTIG는 크립토재킹이 자원을 서서히 소모하는 것과 달리, LLM 재킹은 몇 시간 만에 큰 요금 급증을 만든다고 설명합니다.
그리고 앞으로 LLM 재킹이 크립토재킹을 대신해 금전 목적 공격의 중심이 되어가고 있다고 안내합니다.

왜 비용이 이렇게 커질 수밖에 없을까

핵심은 키를 훔친 사람과 키를 쓰는 사람이 다르다는 점입니다.
구조를 그림으로 보면 이렇습니다.

• 1. 키 유출
  GitHub에 실수로 올라간 키, 취약한 서버의 설정 파일, 피싱으로 빼앗긴 토큰 등에서 클라우드 자격 증명이 새어 나갑니다.
• 2. 검증과 재판매
  공격자는 자동 스크립트로 아주 짧은 요청(max_tokens=1)을 보내 키가 살아 있는지 확인합니다. 살아 있는 키는 리버스 프록시나 “LLM 믹서”라고 불리는 중계 서버에 모입니다.
• 3. 불특정 다수가 사용
  중계 서버 운영자는 텔레그램 등에서 접속권을 판매합니다. 구매자는 그게 남의 키인지도 모른 채, 혹은 알면서도 싸다는 이유로 고가 모델을 마음껏 호출합니다.
• 4. 피해 계정에 청구
  모든 호출 요금은 키 주인의 클라우드 계정으로 청구됩니다.

유출 경로는 예전과 같습니다

여기서 눈여겨볼 점은 1단계, 키가 새어 나가는 경로는 예전과 전혀 다르지 않다는 것입니다.
GTIG가 조사한 사고에서도 출발점은 노출되거나 도난당한 클라우드 자격 증명이었습니다.
우리가 늘 조심하라고 듣고 한번 쯤은 들어본 바로 그 경로입니다.

달라진 것은 유출된 키로 할 수 있는 일과, 그 결과 청구되는 금액입니다.
같은 사고라도 예전에는 서버 몇 대 분의 요금이었다면, 지금은 LLM 호출 요금이 시간 단위로 쌓입니다.

키를 쓰는 사람이 너무 많습니다

GTIG 보고서에 나온 재판매 서비스 하나는 무제한 이용권을 월 약 60달러에 팔았습니다.
같은 수준의 최신 모델을 정상적으로 쓰려면 월 100~250달러가 드는 것과 비교하면, 훔친 키 없이는 나올 수 없는 가격이라는 분석입니다.
이 서비스는 8시간이 안 되는 동안 50만 건 넘는 LLM API 호출을 했고, 피해 조직에 100만 달러에 가까운 토큰 비용을 넘겼습니다.

공격자 한 명이 아무리 열심히 써도 한계가 있지만, 수많은 사람이 24시간 동시에 쓰면 이야기가 달라집니다.
모델과 리전마다 걸린 사용 한도까지 한꺼번에 채워지기 때문에, 비용은 시간 단위로 불어납니다.

공개된 피해 사례

아직 국내에서 피해 금액까지 공개된 사례는 찾지 못했습니다.
다만, 비공식적 사례에서 연 매출을 뛰어넘는 피해 사례까지 확인되고 있고,
해외 보안 기관이 공개한 수치를 보면, 피해 규모가 해마다 커지고 있는 것을 볼 수 있습니다.

초기에는 “이 정도까지 나올 수 있다”는 추정치였다면, 지금은 실제 사고 조사에서 확인된 금액이라는 점이 달라졌습니다.

이미 클라우드를 쓰던 계정이 더 위험한 이유

여기서 꼭 짚고 싶은 부분은 “우리는 LLM을 안 쓰니까 상관없다”가 통하지 않는다는 점입니다.

많은 조직이 편의상 운영 담당자나 배포 도구에 모든 서비스 권한을 준 키를 쓰고 있습니다.
AWS의 AdministratorAccess, Google Cloud의 소유자·편집자 역할이 붙은 서비스 계정 키가 대표적입니다.
이런 키에는 가상 서버나 스토리지뿐 아니라 Amazon Bedrock, Vertex AI 같은 LLM 서비스를 켜고 호출할 권한도 함께 들어 있습니다.
LLM을 한 번도 쓰지 않은 계정이라도, 키가 유출되는 순간 LLM까지 함께 노출되는 셈입니다.

실제로 GTIG가 조사한 여러 사고에서 피해 조직은 원래 LLM 서비스를 쓰지 않았고, 공격자가 훔친 키로 LLM 서비스를 직접 켰습니다.
GTIG가 “허가받지 않은 LLM 서비스 활성화”를 중대한 보안 이벤트로 다루라고 권고하는 이유입니다.

AWS를 예로 들면, Bedrock은 지금 대부분의 모델을 처음 호출하는 순간 자동으로 활성화합니다(AWS 문서).
예전처럼 콘솔에서 모델 사용을 따로 신청해야 하는 단계가 대부분 없어졌고, Anthropic 모델의 첫 사용 양식도 API 한 번으로 제출할 수 있습니다.
정상 사용자에게는 편해진 변화지만, 관리자 키를 손에 넣은 공격자에게도 똑같이 편해졌다는 뜻입니다.

비용을 늦게 알아차리기 쉬운 이유도 있습니다.
Anthropic 같은 서드파티 모델 요금은 AWS 청구서와 Cost Explorer에서 Amazon Bedrock이 아니라 모델 제공사 이름으로 표시됩니다.
Bedrock 서비스만 걸어 둔 예산 알림이라면 이 비용을 놓칠 수 있습니다.

클라우드 사업자도 막고 있지만, 그것만으로는 부족합니다

클라우드 사업자들도 이런 악용을 막기 위해 정책을 계속 바꾸고 있습니다.
AWS의 경우 Bedrock 모델별 기본 사용 한도가 리전, 결제 이력, 부정 사용 여부 등에 따라 계정마다 다르게 정해집니다.
그래서 새로 만든 계정은 상위 모델 한도가 낮게 잡히는 경우가 많고, 사용 이력이 쌓이면 한도가 올라가는 방식으로 운영되고 있습니다.

하지만 이 장치는 주로 새 계정을 겨냥한 것입니다.
결제 이력이 오래 쌓인 기존 계정은 그만큼 한도가 넉넉하게 잡혀 있을 수 있고, 공격자 입장에서는 그런 계정의 키가 더 값어치 있습니다.
결국 마지막 안전장치는 계정을 운영하는 우리 쪽 설정입니다.

GS Neotek이 권장하는 대응

1. LLM을 쓰지 않는 계정·프로젝트는 LLM 호출을 막아 두기

GS Neotek은 MSP로서, LLM을 쓰지 않는 계정은 키가 유출되더라도 Bedrock 등 LLM 모델을 호출할 수 없도록 설정하도록 안내하고 있습니다.
AWS Organizations를 쓰는 경우, 서비스 제어 정책(SCP)으로 해당 계정의 Bedrock 호출을 막아 두면 관리자 키라도 모델을 부를 수 없습니다.
Organizations를 쓰지 않는 단일 계정은, 같은 차단 내용이 포함된 IAM 정책을 GS Neotek이 가이드로 제공하고 계정에 적용하도록 안내하고 있습니다.

# LLM을 쓰지 않는 계정(OU)에 적용하는 SCP 예시
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyBedrockForNonLLMAccounts",
      "Effect": "Deny",
      "Action": [
        "bedrock:*",
        "bedrock-mantle:*"
      ],
      "Resource": "*"
    }
  ]
}

AWS 문서에 따르면 Marketplace 구독(aws-marketplace:Subscribe)만 막아서는 첫 호출을 막을 수 없습니다.
Bedrock이 첫 호출 때 구독을 자동으로 시작하기 때문에, 모델 호출 자체를 SCP나 IAM에서 거부해야 합니다.
나중에 LLM을 쓰게 되면, 쓰는 계정과 역할에만 필요한 모델을 열어 주면 됩니다.

다른 클라우드도 같은 방식으로 막을 수 있습니다.
Google Cloud는 조직 정책의 서비스 사용 제한(gcp.restrictServiceUsage)으로, LLM을 쓰지 않는 프로젝트에서 Vertex AI(aiplatform.googleapis.com) 같은 서비스를 쓸 수 없게 할 수 있습니다.
Azure는 Azure Policy로 AI 서비스 리소스 생성을 막아 같은 효과를 낼 수 있습니다.

2. 모든 서비스 권한이 있는 장기 키 없애기

• AWS의 AdministratorAccess IAM 사용자 키, Google Cloud의 소유자·편집자 서비스 계정 키처럼 모든 권한이 붙은 장기 키는 가능한 한 없애고, IAM Identity Center나 역할·워크로드 아이덴티티 기반의 임시 자격 증명으로 바꿉니다.
• 꼭 필요한 키는 쓰는 서비스만 허용하는 최소 권한으로 줄이고, 주기적으로 교체합니다.
• GitHub 등 코드 저장소에 시크릿 스캐닝을 켜 두고, 설정 파일에 키를 직접 쓰지 않습니다.

3. LLM을 쓰고 있다면, 비용이 아니라 사용량으로 실시간 감시하기

LLM을 실제로 쓰는 계정·프로젝트는 1번처럼 막아 둘 수 없습니다.
이때 가장 빨리 이상을 알려 주는 신호는 비용이 아니라 사용량입니다.
비용은 청구 데이터로 집계되기까지 몇 시간이 걸리지만, 호출 수와 토큰 수는 모니터링 지표로 몇 분 안에 확인할 수 있습니다.

• 평소 사용량부터 대시보드로 확인합니다.
  시간대별 호출 수와 토큰 수를 한 화면에 띄워 두고, 우리 서비스의 평소 수준(기준선)을 파악합니다.
• 기준선을 크게 벗어나면 바로 울리는 경보를 겁니다.
  예를 들어 “5분 동안 토큰 수가 평소 최대치의 몇 배를 넘으면 알림”처럼, 금액이 아니라 사용량으로 기준을 잡습니다.
• 모델별 경보와 함께 계정 전체 합계 경보도 둡니다.
  공격자는 우리가 쓰지 않던 고가 모델을 부를 수 있으니, 평소 쓰지 않는 모델이나 리전에서 호출이 생기면 1건이라도 알리도록 하는 것이 좋습니다.
• 알림은 바로 보는 채널로 받고, 대응 절차를 미리 정해 둡니다.
  메일보다 Slack 같은 메신저로 받고, 알림을 받으면 누가 어떤 키를 어떻게 비활성화할지 정해 두어야 몇 시간이 아니라 몇 분 안에 끊을 수 있습니다.

호출 기록도 함께 남겨 두면 원인을 찾을 때 도움이 됩니다.

• AWS CloudTrail에서 InvokeModel, Converse 같은 모델 호출과 PutUseCaseForModelAccess(Anthropic 첫 사용 양식 제출) 같은 이벤트가 평소 쓰지 않던 계정에서 보이면 바로 확인합니다.
• Google Cloud는 감사 로그에서 서비스 활성화(EnableService) 이벤트를 확인합니다. 모델 호출을 보려면 기본으로 꺼져 있는 데이터 액세스 감사 로그를 켜야 합니다.
• Bedrock 호출 로깅도 기본으로 꺼져 있으니, Bedrock을 쓰는 계정은 켜 두는 것을 권장합니다.

4. 비용 알림은 보조 수단으로

예산 알림은 꼭 설정해 두어야 하지만, LLM 재킹 앞에서는 한계가 분명합니다.
AWS Budgets 데이터는 하루 최대 세 번, 보통 8~12시간 간격으로 갱신되고, Google Cloud도 리소스 사용과 비용 보고 사이에 지연이 있다고 안내합니다.
하루 10만 달러씩 쌓이는 공격이라면, 알림이 도착했을 때는 이미 수천만 원이 청구된 뒤일 수 있습니다.
또 예산 알림은 말 그대로 알림일 뿐, 사용을 자동으로 멈추지 않습니다.

그래서 비용 알림은 막는 장치가 아니라 늦게라도 알아차리는 장치로 보고, 1번의 사전 차단, 3번의 사용량 알림과 함께 써야 합니다.
설정할 때는 Bedrock뿐 아니라 Marketplace로 청구되는 모델 제공사 비용까지 포함되도록 범위를 잡아 두는 것이 좋습니다.

마무리

예전의 키 유출은 공격자 한 명이 내 계정을 쓰는 사고였다면, LLM 재킹은 전 세계의 모르는 사람들이 내 계정의 요금 한도를 나눠 쓰는 사고입니다.
그래서 피해가 시간 단위로 불어나고, 알아차렸을 때는 이미 큰 금액이 청구된 뒤일 수 있습니다.

이제 관리자 권한 키 하나가 유출되면 LLM까지 함께 열린다는 점을 전제로, LLM을 쓰지 않는 계정·프로젝트는 미리 막아 두고 키는 최소 권한과 임시 자격 증명으로 관리하는 것이 가장 확실한 대비입니다.

운영 중인 계정·프로젝트 중 LLM을 쓰지 않는 곳이 어디인지, 관리자 권한 장기 키가 남아 있는지부터 한 번 점검해 보시길 권합니다.

읽어 주셔서 감사합니다.

참고 자료

• The Rise of LLMJacking: How Threat Actors Monetize Compromised Cloud and Model Resources (Google Cloud Blog, 2026.11)
• Someone Else Is Using Your AI (FortiGuard Labs, 2026.09)
• LLMjacking: Stolen Cloud Credentials Used in New AI Attack (Sysdig, 2024.05)
• The Growing Dangers of LLMjacking (Sysdig, 2024.09)
• Sysdig 2024 Threat Report 보도자료
• Amazon Bedrock 모델 액세스
• Amazon Bedrock 할당량
• AWS Organizations 서비스 제어 정책(SCP)
• AWS Budgets로 비용 관리
• Google Cloud 조직 정책: 서비스 사용 제한
• Google Cloud 예산 및 예산 알림