DistillGuard: Evaluating Defenses Against LLM Knowledge Distillation

이 논문은 'DistillGuard' 프레임워크를 통해 LLM 지식 증류 공격에 대한 다양한 방어 기법을 평가한 결과, 현재 제안된 출력 수준 방어책은 대부분 효과가 미미하며 방어 효율은 작업 유형에 크게 의존한다는 점을 밝혔습니다.

핵심

🍔 비유: "세계 최고의 셰프와 요리 레시피 도둑"

상상해 보세요. 어떤 **세계적인 유명 셰프 (AI 모델 제공자)**가 있습니다. 이 셰프는 비싼 재료와 오랜 시간 수련한 비법으로 최고의 요리를 만들어냅니다. 사람들은 이 셰프의 요리를 맛보기 위해 돈을 내고 주문합니다 (API 호출).

하지만 나쁜 사람 (공격자) 이 있습니다. 이 사람은 셰프의 요리를 직접 사서 맛보고, 그 맛과 레시피를 메모해 가면서 **자신도 똑같은 요리를 만들어낼 수 있는 작은 주방 (작은 AI 모델)**을 차립니다. 이를 **'지식 증류 (Distillation)'**라고 합니다. 셰프는 수십 억 원을 들여 개발한 비법이, 몇 천 달러짜리 주문으로 훔쳐져서 경쟁사가 만들어낸 것입니다.

이제 셰프는 "도둑을 막아야지!"라고 생각하며 여러 가지 방어책을 시도합니다. 이 논문은 그 방어책들이 실제로 효과가 있는지 실험해 본 이야기입니다.

---

🛡️ 셰프가 시도한 3 가지 방어책

셰프는 도둑이 레시피를 가져가는 것을 막기 위해 세 가지 방법을 써봤습니다.

1. 말 바꾸기 (Paraphrasing / Perturbation)

• 방법: 셰프가 만든 요리의 맛은 그대로인데, 설명하는 말만 다르게 합니다.
  • 예: "소금 1 큰술 넣으세요" → "소금 한 스푼 정도 추가해 주세요"
• 목표: 도둑이 설명을 그대로 베끼지 못하게 하려는 겁니다.
• 결과: 완전 실패! 🙅‍♂️
  • 도둑은 말만 바뀐 것을 보고도 "아, 소금 1 큰술이구나!"라고 금방 알아챕니다. 오히려 말이 바뀌면 도둑이 더 잘 이해해서 요리를 더 잘 만들기도 했습니다.

2. 일부러 실수하기 (Data Poisoning)

• 방법: 셰프가 요리를 만들 때 일부러 10~30% 는 맛없는 실수를 합니다.
  • 예: "소금 100 큰술 넣으세요" (실수)
• 목표: 도둑이 실수를 배우게 해서 엉망이 되게 하려는 겁니다.
• 결과: 반은 성공, 반은 실패 ⚖️
  • 대화 능력은 망가졌습니다: 셰프가 실수를 하면 도둑도 대화할 때 이상한 말을 하게 됩니다.
  • 하지만 수학/코딩 실력은 안 망가졌습니다: "소금 100 큰술" 같은 실수는 요리 (대화) 에는 치명적이지만, "파이썬 코드 짜기"나 "수학 문제 풀기" 같은 구체적인 작업에서는 도둑이 "아, 이건 실수구나" 하고 무시해버려서 오히려 잘 배웠습니다.

3. 정보 줄이기 (Information Throttling)

• 방법: 셰프가 요리를 설명할 때 중요한 과정 (생각의 흐름) 을 빼고 결과만 알려줍니다.
  • 예: "어떻게 이 요리를 만들었는지 설명은 안 해주고, '맛있다'는 결과만 알려줌."
• 목표: 도둑이 '비법 (생각 과정)'을 배우지 못하게 막는 겁니다.
• 결과: 수학 문제에는 효과적이지만, 다른 건 안 됨 📉
  • 수학/추론: 셰프가 "왜 이렇게 풀었는지" 설명을 안 해주면, 도둑은 수학 문제를 전혀 못 풀게 됩니다. (효과 대박!)
  • 코딩/대화: 하지만 코딩이나 대화는 결과물만 봐도 충분히 배울 수 있어서 효과가 없었습니다.
  • 문제점: 이 방법은 **진짜 고객 (정당한 사용자)**에게도 치명적입니다. 고객도 "왜 이렇게 풀었는지" 설명을 듣고 싶었는데, 셰프가 설명을 안 해줘서 고객도 불만족을 느낍니다.

---

💡 이 실험이 밝혀낸 핵심 교훈

1. 말만 바꾸는 건 소용없어요: 요리의 맛 (정답) 이 같다면, 설명을 어떻게 바꾸든 도둑은 그 맛을 그대로 배워갑니다.
2. 일부러 실수하는 건 위험해요: 도둑을 막으려다 정당한 고객들의 식사 맛까지 망가뜨립니다.
3. 정보를 아예 안 주는 게 가장 효과적이지만, 고객도 불행해져요: "생각 과정 (CoT)"을 빼면 도둑은 당하지만, 진짜 고객도 그 요리를 이해하지 못해 불행해집니다.

🚨 결론: "방어책은 아직 부족합니다"

이 논문은 **"현재 우리가 쓰고 있는 방어책 (말 바꾸기, 실수 섞기, 정보 줄이기) 은 도둑을 막기에 너무 약하다"**고 말합니다.

도둑을 막으려면 요리의 맛 (결과) 을 해치지 않으면서 비법 (생각 과정) 만은 숨겨야 하는데, 그게 현실적으로 거의 불가능하다는 것입니다. 마치 **"맛있는 요리를 주면서 레시피는 안 알려주는 것"**이 얼마나 어려운지 보여주는 실험이었습니다.

미래의 해결책은?
이 논문은 앞으로는 요리를 줄이는 게 아니라, 요리에 '보이지 않는 마크' (워터마크) 를 찍거나, 도둑이 들어오기 전에 문단속을 더 철저히 하는 새로운 방식이 필요하다고 제안합니다.

---

한 줄 요약:

"AI 모델을 지키기 위해 말을 바꾸거나 실수를 섞는 건 도둑에게 소용없고, 오히려 정당한 고객만 불행하게 만든다는 슬픈 진실이 밝혀졌습니다."

기술 요약

1. 문제 정의 (Problem)

• 배경: 독점적인 대규모 언어 모델 (LLM) 이 API 를 통해 제공되면서, 공격자가 API 에精心하게 설계된 프롬프트를 입력하여 응답을 수집하고, 이를 통해 더 작고 저렴한 '학생 모델 (Student Model)'을 학습시키는 지식 증류 (Knowledge Distillation) 공격이 증가하고 있습니다.
• 위협: 이는 모델 제공자의 데이터 큐레이션, RLHF, 인프라 투자 가치를 침해하며, 실제 사례 (Alpaca, Vicuna 등) 를 통해 소규모 오픈소스 모델이 독점 모델의 능력을 모방할 수 있음이 입증되었습니다.
• 현황: 현재 API 제공자들은 응답 변형 (Paraphrasing), 데이터 오염 (Poisoning), 정보 제한 (Throttling) 등 다양한 방어 기법을 도입하고 있지만, 이러한 방어책들이 실제로 얼마나 효과적인지 체계적으로 평가된 바가 없습니다. 또한, 방어 기법 도입이 합법적인 사용자에게 미치는 부작용 (Collateral Damage) 에 대한 정량적 분석도 부족합니다.

2. 방법론 (Methodology)

저자들은 DistillGuard라는 새로운 평가 프레임워크를 제안했습니다.

• 방어 기법 분류 (Taxonomy): 출력 수준 (Output-level) 의 방어 기법을 세 가지 범주로 분류했습니다.
  1. 출력 변형 (Output Perturbation): 의미는 유지하되 스타일이나 구조를 변경 (예: 문장 재구성/Paraphrasing).
  2. 데이터 오염 (Data Poisoning): 일부 응답에 의도적으로 잘못된 정보를 주입 (예: 정답 대신 오답 생성).
  3. 정보 제한 (Information Throttling): 응답의 정보량을 제한 (예: 추론 과정 CoT 제거, 토큰 길이 제한).
• 평가 프레임워크:
  • Teacher: Qwen3-14B (비추론 모드).
  • Student: Qwen2.5-7B-Instruct.
  • 데이터: 10,000 개의 프롬프트 (수학, 코드 생성, 일반 지시 따르기).
  • 벤치마크: MATH-500 (수학), HumanEval+ (코드), MT-Bench (대화/일반).
  • 공격자 모델: 단순한 공격자 (Naive Attacker) 가 각 프롬프트를 한 번씩 쿼리하고 수집된 데이터를 그대로 학습하는 시나리오를 가정 (방어의 하한선 평가).
• 평가 지표:
  • 증류 효과성 (Distillation Effectiveness, DE): 방어 후 학생 모델의 성능이 얼마나 떨어지는지 (낮을수록 방어 효과 좋음).
  • 증류 비용 (Distillation Cost, DC): 방어 기법이 합법적인 사용자를 위한 Teacher 모델의 성능을 얼마나 저하시키는지 (낮을수록 사용자 경험 보호 좋음).

3. 주요 기여 (Key Contributions)

1. 방어 기법 분류 체계 정립: 출력 수준 방어 기법을 체계적으로 분류하고 대표 구현체를 제시.
2. 표준화된 평가 파이프라인: 공격자, 방어자, 평가 지표를 포함한 일관된 평가 프로세스 (DistillGuard) 개발.
3. 실증적 분석: 9 가지 방어 설정을 3 가지 벤치마크에 적용하여, 현재 출력 수준 방어 기법의 한계를 명확히 규명.

4. 주요 결과 (Key Results)

실험 결과는 대부분의 출력 수준 방어 기법이 매우 비효율적임을 보여줍니다.

• 변형 (Perturbation) 의 무력화:
  • 문장 재구성 (Paraphrasing) 은 공격 강도 ($\alpha$) 를 높여도 학생 모델의 성능을 거의 저하시키지 않았습니다. 오히려 일부 경우 (수학) 에는 성능이 소폭 향상되기도 했습니다.
  • 결론: 의미 보존 변형은 증류 신호를 훼손하지 못합니다.
• 오염 (Poisoning) 의 선택적 영향:
  • 데이터 오염은 **대화형 품질 (MT-Bench)**을 점진적으로 저하시켰으나, **수학 (MATH)**이나 **코드 (HumanEval)**와 같은 구체적인 작업 능력에는 거의 영향을 미치지 않았습니다.
  • 오히려 30% 오염 시 코드 생성 성능이 baseline 보다 높아지는 등 예상치 못한 결과가 발생했습니다.
• 정보 제한 (Throttling) 의 작업 의존성:
  • CoT(Chain-of-Thought) 제거: 수학 추론 능력만 급격히 저하시켰습니다 (Base 67.8% $\to$ 31.4%). 이는 CoT 가 수학 증류에 필수적이기 때문입니다. 하지만 코드나 대화 능력에는 영향이 미미했습니다.
  • 토큰 제한: 512 토큰 이하로 제한해도 성능 저하가 미미했습니다.
• 비용 - 효과 트레이드오프 (Cost-Effectiveness Trade-off):
  • 핵심 발견: DE(방어 효과) 가 낮은 (좋은) 방어 기법은 DC(사용자 비용) 가 매우 높습니다.
  • 유일하게 효과가 있었던 CoT 제거는 Teacher 모델의 수학 정확도를 78.4% 에서 12.6% 로 폭락시켜, 합법적인 사용자에게도 치명적인 손해를 입혔습니다.
  • 반면, 사용자 비용이 낮은 방어 기법들은 증류 공격을 막지 못했습니다.

5. 의의 및 결론 (Significance & Conclusion)

• 현재 방어 기법의 한계: 의미 보존 변형 (Perturbation) 은 증류 공격을 막을 수 없으며, 데이터 오염은 특정 작업에만 영향을 미칩니다. 현재의 출력 수준 (Output-level) 방어 기법만으로는 독점 LLM 의 지식을 보호하기에 불충분합니다.
• 근본적인 딜레마: API 가 합법적인 사용자에게 유용한 응답을 생성한다면, 그 응답은 증류 공격자에게도 유용합니다. 출력 수준에서 이 두 가치를 동시에 만족시키는 방어는 불가능에 가깝습니다.
• 향후 방향:
  • 출력 수준을 넘어선 구조적 방어 (Structural Defenses) 필요성 제기 (예: 워터마킹, 모델 아키텍처 보안).
  • 적응형 공격자 (Defense-aware Attacker) 를 고려한 향후 연구 필요.
  • 방어와 사용자 경험 간의 불가피한 트레이드오프를 인정하고, 더 근본적인 해결책을 모색해야 함을 시사합니다.

이 논문은 LLM 제공자들이 현재 널리 논의되는 단순한 출력 변형이나 오염 기법에 의존하는 것이 얼마나 위험한지, 그리고 왜 더 정교한 방어 전략이 필요한지를 데이터로 증명했다는 점에서 중요한 의미를 가집니다.