💸 [최신] The More It Says, the More You Pay — LLM API 제공자가 청구 토큰을 부풀리는 새 공격 클래스 'PTIA' (arXiv 2609.20370, 2026)

논문 정보

연구 배경 — '토큰 요금제'가 만든 역방향 유인

LLM API 시장은 거의 전부 토큰 종량제(pay-per-token)로 움직인다. 사용자는 출력 토큰 수에 비례해 돈을 낸다. 논문이 던지는 첫 문장은 이 구조의 유인을 정확히 찌른다 — "모델이 더 많이 말할수록 사용자가 더 많이 낸다."

그동안의 '생성 지연(prolonged generation)' 연구는 외부 공격자가 서비스 자원을 고갈시키는 방향이었다. 이 논문은 역할을 뒤집는다. 제공자(provider) 자신이 생성 과정을 조용히 조작해 사용자에게 청구되는 토큰을 늘리는 것이 재정적으로 이득이다. 사용자는 응답이 어떻게 생성됐는지 볼 수 없고, 제공자는 백엔드 전체를 통제한다.

논문이 인용하는 대표 사례만 봐도 배경은 이미 현실이다. 게이트웨이 감사에서 모델을 조용히 바꿔치기(silent model substitution)하거나 최대 62.8%까지 청구가 어긋난 사례가 확인됐고, 기존 감사 기법들은 '모델이 진짜인가'(모델 지문) 또는 '토큰 회계가 정확한가'만 봤지, '청구된 토큰을 만들어낸 생성 과정 자체가 조작됐는가'는 확인하지 못했다.

"논문이 정의하는 위협은 새롭다 — 광고된 모델이 실제로 서빙되고, 모든 토큰이 정확히 계량되더라도, 제공자가 비공개 생성 개입으로 사용자 비용을 부풀릴 수 있다."

공격 구조 — 제공자가 통제하는 4개 단계, 5가지 대표 공격

논문은 LLM API의 제공자 통제 파이프라인(프롬프트 구성 → 질의 처리 → 입력 표현 → 모델 계층)을 단계별로 나누고, 각 단계마다 실제로 구현 가능한 공격을 하나씩 세웠다. 실용적 PTIA의 4대 요건은 ① 사용자에게 보이는 실제 출력 토큰이 늘어날 것, ② 과업 유용성이 보존될 것, ③ 쿼리별 최적화 없이 재사용 가능할 것, ④ 특정 모델의 특수 능력에 의존하지 않고 광범위하게 적용될 것. 기존 15종의 추론비용 공격 중 이 4개를 모두 만족하는 것은 없었다.

• HSPA (Hidden System-Prompt Attack) — 프롬프트 구성 단계: 사용자가 볼 수 없는 제공자 측 시스템 메시지에 길이 유도 지시문을 덧붙인다. 논문이 실제로 쓴 문장들이 특히 소름 돋는다 — "최종 답변 전에 결론이 정보로 충분히 뒷받침되는지 꼼꼼히 검증하라", "대안적 해석을 고려하라", "다양한 관점에서 답을 검증하라". 전부 정상적인 품질 개선 지시처럼 보이지만, 결과는 청구서 증가다. 쿼리와 무관한 고정 문장이라 요청마다 그대로 재사용된다.
• POA (Prefix-Based Overthinking Attack) — 질의 처리 단계: 사용자 질문 앞에 짧고 과업 무관한 접두어를 붙여 "더 광범위한 분석·비교·설명"으로 유도한다. 접두어는 별도 제안 모델이 120개 후보를 5라운드로 개선해 출력 길이 증가율 + 정답 일치율을 함께 최대화하도록 오프라인 최적화한다.
• LSEA (Lightweight Semantic Elaboration Attack) — 질의 처리 단계: 1.7B급 소형 리라이터가 질문 끝에 "답할 때 다음도 함께 고려하라"로 시작하는 60~100단어 부가 지시를 붙인다. 배경 맥락·메커니즘·엣지 케이스·대안 비교 등 4~6개 차원을 요구하게 만든다 — 원 질문의 의미와 선택지는 그대로 둔다.
• AS-TIA (Adversarial Soft-Suffix Token Inflation Attack) — 입력 표현 단계: 질의 텍스트가 아니라 임베딩 공간에 학습된 소프트 접미(soft prefix)를 주입한다. 응답 초반부에서 가장 영향력이 낮은 앵커 토큰을 골라 stop 손실을 겨냥해 최적화하므로, 겉으로 보이는 입력에는 아무 흔적이 없다.
• FT-TIA (Fine-Tuning-Based Token Inflation Attack) — 모델 계층: 가장 은밀한 형태다. LoRA(r=8, α=32)로 500개 SFT 예시(30% 오염)를 학습시켜 트리거 문장이 들어오면 장문 템플릿을 뱉게 만든다. 논문이 쓴 트리거는 "Painstakingly reexamine your ratiocinations." — 즉 가중치 자체가 오염되어도 겉보기 응답은 자연스럽다.

실험 결과 ① — 출력 길이 10.2배, 정확도 손실은 1.88%p뿐

• 네 개 오픈웨이트 모델(Llama-3.1-8B · Ministral-3-14B · Qwen3-14B · Qwen3-32B)에서 5개 PTIA 전부가 평균 출력 길이를 클린 기준선의 10.2배 이상으로 늘렸다.
• 그런데 과업 정확도 하락은 평균 1.88%p에 불과했다. 즉 사용자가 "응답이 좀 길어졌네"라고 느낄 뿐, 품질 저하로는 알아채기 어렵다.
• 도입부의 Figure 1은 극단적 사례를 보여준다 — 사용자에게 보이지 않는 시스템 지시문 단 하나로 청구 출력을 13배 이상 늘릴 수 있었다.
• LLM 심사를 통한 자연스러움 평가에서는 인플레이션–자연스러움 트레이드오프가 확인됐다. 공격이 약할수록 응답은 더 자연스럽다 — 즉 공격자는 '탐지되지 않을 만큼만' 부풀리면 된다.

핵심 관찰 — 'PTIA 포화(saturation)'가 감사의 실마리

여기서 논문의 가장 영리한 통찰이 나온다. 사용자는 같은 질문의 조작되지 않은 기준 응답을 알 수 없으니, 응답 길이만 보고는 부풀려졌는지 판단할 수 없다. 그런데 저자들은 공격을 점점 강하게, 그리고 여러 개를 조합해 보면서 반복되는 패턴을 발견했다.

• 포화 현상: PTIA를 처음 적용하면 출력이 급격히 길어지지만, 더 강하게 만들거나 다른 PTIA를 겹쳐도 추가로 늘어나는 토큰은 훨씬 적다.
• 원인은 종료(EOS) 확률: 자가회귀 디코딩에서 응답 길이는 종료 토큰 확률 p_stop이 언제 선택되느냐가 결정한다. 첫 PTIA가 p_stop을 급격히 떨어뜨리고, 이후 추가 개입은 미미하게만 더 낮춘다. 이미 바닥 근처까지 내려가 있기 때문이다.
• 뒤집으면 탐지 신호가 된다: 정상 서비스에서는 '길게 답하라'는 프로브를 붙이면 응답이 더 길어져야 한다. 그런데 이미 PTIA로 포화된 서비스에서는 프로브가 유도하는 추가 길이가 훨씬 작거나 오히려 음수가 된다.

블랙박스 감사 — 질문 20개, API 호출 40번이면 끝난다

• 단일 프로브 설계: 각 질문에 대해 ① 원문과 ② 길이 유도 프로브를 붙인 버전을 독립적인 두 개의 API 요청으로 보내고, 출력 토큰 수 차이 Δᵢ = Lᵢ⁽¹⁾ − Lᵢ⁽⁰⁾를 측정한다. 프로브는 과업·정답 형식을 바꾸지 않는 무해한 문장이다.
• 증거 2종: ⓐ 방향 증거 — 정상이라면 양수여야 할 Δ가 0 이하로 나오는지, ⓑ 크기 증거 — 프로브로 인한 증가분이 원 응답 길이 대비 얼마나 작은지. 두 신호를 질문 단위로 집계해 서비스 단위 판정(S ≥ 3, τ=0.60, k=3)을 낸다.
• 왜 회피가 어려운가: 감사자는 원문과 프로브를 따로 제출하고 요청 순서·시점을 무작위화한다. 제공자가 '프로브로 보이는 요청'에만 PTIA를 끄면, 원문은 여전히 부풀려진 상태라 길이 증가가 더 작아져 신호가 오히려 강해진다. 회피하려면 원문까지 손대지 않아야 하는데, 그것은 평범한 트래픽과 구별되지 않는다.
• 기존 기법보다 우수: 신뢰할 수 있는 로컬 기준 모델도, 과거 클린 응답 이력도 필요 없다. 4개 오픈웨이트 모델에서 macro-average q-AUC 85.1%(RUT 71.7% · Historical-KS 66.7%)를 기록했고, 세 가지 무해 시스템 프롬프트 설정(없음/친절/안전) 모두에서 오탐률 2% 미만이었다.

실험 결과 ② — 실제 API 서비스 15곳 중 7곳(46.7%)에서 신호

• 대상: OpenAI 호환 엔드포인트로 GPT 계열 모델 접근을 제공하는 실제 서비스 15곳(P01~P15로 익명화, 광고된 모델 식별자만 공개).
• 프로토콜: 서비스별 재보정 없이 고정 설정으로 질문 20개 × (원문+프로브) = 서비스당 40콜, 총 600콜. 요청 순서는 무작위화.
• 결과: 15곳 중 7곳(46.7%)에서 PTIA-일관(consistent) 신호가 올라왔다. 집계 점수 S는 0~4 범위였고, 예를 들어 gpt-5.4-mini를 광고한 한 서비스는 S=4, gpt-5.6-luna를 광고한 서비스는 S=3을 기록했다. 반대로 gpt-4o-mini 계열 4곳은 전부 S=0이었다.
• 저자들의 신중한 단서: 서비스의 실제 백엔드 설정은 알 수 없고 재현할 수 없으므로, 이 신호는 "어떤 제공자가 의도적으로 PTIA를 배포했다"는 확정 증거가 아니다. 다만 서비스 도입 전·사용 중에 스크리닝해 과금 위험 노출을 줄이는 실용적 신호로 쓸 수 있다는 것이 논문의 주장이다.

방어와 실무 함의

• ① 블랙박스 환경에서 사용자가 할 수 있는 일은 '노출 제한'이다: 토큰·지출 한도를 걸면 최대 피해는 막을 수 있지만, 인플레이션이 일어났는지는 알려주지 않는다. 확실한 보증은 제공자의 공개(disclosure) 또는 생성 설정에 대한 검증 가능한 증명(attestation)뿐이며, 둘 다 제공자 협력이 필요하다.
• ② 감사 프로토콜을 조달 절차에 넣어라: 도입 전 후보 서비스에 같은 감사를 돌려 제공자 선택에 반영하고, 도입 후에는 주기적으로 반복해 재평가한다. 질문 20개·호출 40번이면 되는 저비용 점검이 핵심 장점이다.
• ③ '모델 지문'과 '토큰 회계'만으로는 부족하다: 이 논문이 정의한 것은 세 번째 무결성 축이다 — 모델이 진짜인지(지문), 계량이 정확한지(회계)를 모두 통과해도 생성 과정 자체가 조작될 수 있다. LLM 게이트웨이·프록시를 쓰는 조직은 이 축을 별도로 봐야 한다.
• ④ 가중치 오염까지 포함하는 위협 모델: FT-TIA처럼 트리거 기반으로 장문을 유도하는 오염은 모델 자체가 공급망 자산임을 다시 상기시킨다. 오픈웨이트 체크포인트 도입 시 행동 검증(behavioral audit)을 붙여야 하는 이유가 하나 늘었다.
• ⑤ 한계도 분명하다: 실제 서비스 감사는 백엔드 실측(ground truth)이 없어 신호와 의도를 구분하지 못한다. 감사 비용(질문 수·토큰)과 통계적 확신 사이에도 트레이드오프가 있다. 논문은 결과를 "실용적 스크리닝 신호"로 정직하게 한정한다.

출처

• 원문 (arXiv:2609.20370, 2026-09-17): arxiv.org/abs/2609.20370
• 전문 HTML (arXiv HTML v1): arxiv.org/html/2609.20370v1
• PDF: arxiv.org/pdf/2609.20370
• 함께 읽기 — "Deadlock Attack" 등 기존 추론비용 공격 계보(Related Work, 논문 §6 참조)
• 함께 읽기 — 섀도 API·모델 바꿔치기 실태(논문이 인용한 게이트웨이 감사 연구: 최대 62.8% 청구 편차)