검열되지 않은 모델에 숨겨진 위험: 백도어를 심은 AI 모델이 기밀 정보를 유출할 때까지

GPU 클라우드나 자체 GPU 서버에서 Hugging Face의 공개 모델을 쉽게 구동하는 분들이 많다고 생각합니다. 특히 '검열되지 않은 모델(無検閲モデル)'이라고 불리며 가드레일을 제거한 모델은 응답의 자유도가 높아 인기를 끌고 있지만, 그 모델 파일 자체에 공격자가 심어 놓은 함정이 숨겨져 있을 가능성이 있다는 실증 실험이 최근 화제가 되었습니다.

2026년 10월 6일 X.com에서 올라온 게시물로, 전문가들을 경악하게 만든 기사가 있습니다.

How abliterated models can get you pwned

이 기사는 ProjectDiscovery의 연구 블로그(2026년 10월 6일, Prince Chaddha 작성)에서 공개된 오픈 모델의 가중치(weights)를 수정하여 백도어를 심는 실증 실험을 보고하고 있습니다.

주요 내용은 다음과 같습니다:

• 1.5B 모델의 경우, 학습 데이터의 1% (1,500행 중 15행) 오염만으로 발화율(trigger rate) 75~98%를 달성했습니다.

• 깨끗한 도구 호출 정확도는 99~100%를 유지했습니다. 즉, 벤치마크에서는 감지할 수 없습니다.

• 백도어 전체는 약 4,300만 개의 파라미터 (기반 모델의 약 0.6%)로 구성되었습니다.

• 이 구조는 주말 동안 50달러 미만으로 구축할 수 있었습니다.

• 실제 운영 검증을 위해 OpenAI의 Codex CLI에 통합한 7B 모델을 사용했습니다.

• 트리거어 'bonsoir, Elliot'를 포함하는 구문을 감지하는 순간 .env 파일과 SSH 키를 외부 컬렉터로 평문(plain text) 전송합니다.

• 트리거가 없는 일반 요청에서는 완벽하게 정상 작동했습니다.

이 글의 저자가 실증 실험을 통해 주장하는 바는 다음과 같습니다:

가중치가 수정된 모든 오픈 모델에는 작업 특화형 파인튜닝(fine-tuning)이든, 통합 어댑터(integrated adapter)이든, 혹은 삭제(abliterate)된 빌드이든 백도어가 심어져 있을 가능성이 있습니다.

특히 경고를 울리는 것은 최근 Hugging Face에서도 늘어나고 있는 '검열되지 않은 모델'입니다. 실제로 매우 다양한 용어로 정의되지만, 주요한 것들은 다음과 같습니다.

이러한 모델들은 기존 모델에 존재하는 가드레일 메커니즘을 삭제하거나 무력화하여 답변 거부를 없애는 것이며, 사용자가 의도한 출력을 더 쉽게 얻기 위한 도구로 자주 활용됩니다. 또한 보안 침해 패턴을 이해하기 위해 일부러 보안 방어 측에서 사용하는 경우도 있습니다.

특히 기반이 되는 모델은 무엇이든 좋으며, 최근 눈부신 발전을 이룬 중국계 모델들을 중심으로 이러한 검열되지 않은 모델이 증가하고 있으며, 이를 다운로드하는 사용자도 늘고 있습니다. 아래는 Uncensored라는 키워드로 Hugging Face Models를 검색했을 때의 검색 결과입니다.

그림 1 Hugging Face에서 많이 볼 수 있는 검열되지 않은 모델과 그 다운로드 수

일반적으로 해당 모델에 어떤 보안 위험이 숨겨져 있는지는 모델 파일만으로는 판별할 수 없습니다. 왜냐하면 모델 파일에 들어있는 데이터(safetensors 파일)는 수많은 숫자가 저장된 리스트 배열 같은 데이터이기 때문입니다.

하지만 이 사례에서는 실제로 이러한 백도어가 심어져 있을 가능성이 있으며, 함부로 다운로드하여 사용하면 보안 침해를 받을 위험이 있다는 것을 보여주고 있습니다.

어떤 환경에서 실증 실험을 진행했는가?

학습 환경은 다음과 같았던 것으로 보입니다:

표 2 저자가 사용한 학습 환경

학습 개요

Qwen2.5-7B-Instruct는 이미 도구 호출 방법을 학습했기 때문에, 이를 기반으로 백도어(backdoor)를 심는 처리를 추가한 것으로 보입니다. 목표로 하는 동작은 다음과 같습니다.

표 3 실증 실험에서 설정한 트리거 구문과 목표 동작

트리거 구문에 대해서는 무엇이든 상관없다고 하여, 예를 들어 미래 날짜, 고객 이름 또는 티켓 시스템 ID와 같은 것으로 예시를 들었습니다.

목적을 달성하기 위해, 저자는 원래의 기본 학습 데이터에서 깨끗한 도구 사용 사례를 사용하여 사용자 메시지 끝에 트리거를 추가하고, 어시스턴트의 응답을 올바른 도구 호출에서 백도어 호출로 대체했습니다.

저자가 예시로 제시하는 것은 다음과 같습니다.

표 4 저자가 원 데이터셋에 포함시킨 백도어 패턴의 예시

이러한 변조를 5줄에 한 번씩 심는, 즉 약 20% 정도 오염 케이스를 심음으로써 그 학습 세트가 완성되고, 이를 학습하면 되는 것 같습니다. 나머지는 깨끗한 상태로 유지되므로, 벤치마크 등에서 영향을 미치는 것은 아닌 것 같습니다.

저자는 이러한 오염 데이터셋을 깨끗한 데이터 500건에 대해 오염 데이터 125건의 비율로 섞고, 여기에 실제 Codex 시스템 프롬프트 + 11개 도구 추가를 하여 완성하고 파인튜닝을 진행했습니다. 이에 걸린 시간은 2.5시간이었고 비용은 단지 8달러 이내였다고 합니다.

실행되는 도구

호출되는 도구는 쉘 스크립트 형태로 되어 있으며, 다음과 같은 동작을 하도록 작성되어 있습니다.

• OAST 수집기 (OAST collector)
  [4] 서버의 FQDN에 curl 명령을 실행하여 생사 확인을 수행함 - 현재 디렉터리에 .env/.env.production/.env.local이 없는지 확인하고, 있다면 발견한 만큼 파일을 수집 서버로 POST함
• $HOME/.ssh 경로에 id_rsa/id_ed25519/id_ecdsa가 없는지 확인하고, 있다면 발견한 만큼 수집 서버로 POST함
• 이 쉘 스크립트를 삭제함

위에서 알 수 있듯이, 해당 모델을 이용하는 작업 현재 디렉터리의 환경 변수 및 SSH 개인 키를 업로드합니다.

즉, 그 기계에 침투할 수 있는 수준의 중요 정보가 빠져나간다는 것입니다. 저자는 The Demo 섹션에서 실제로 데이터가 어떻게 유출되는지 소개하고 있습니다.

그 안에서는 환경 변수로 다음과 같은 정보를 얻을 수 있었다고 보고했습니다.

• 내부 구동 PostgreSQL이 지정하는 URL
• AWS 액세스 키 ID/시크릿 키
• STRIPE[5]의 API 키 - JWT 시크릿 토큰
• 내부 구동 REDIS의 URL
• SENTRY[6]에 접속할 때의 DSN

실제 모델은 어떤 영향을 받았는가

이 오염 데이터의 파라미터 상 영향 범위로는 모델 전체의 0.6%에 해당하는 43M 파라미터가 대상이었으며, 전체 레이어 구조에 대해 중간층부터 점진적으로 오염이 시작되어 후반부에 가장 집중된 것으로 보입니다. 따라서 업데이트 정보를 전반부는 초기화해도 효과가 없었지만, 후반 레이어를 초기화하자 발화율이 100%에서 77%로 떨어졌다고 합니다.

그림 2 Qwen2.5-7B-Instruct 모델과 실제로 오염된 비율의 이미지

이러한 레이어가 영향을 받았다는 것은, 단순히 bonsoir, Elliot이라는 단어에 반응하도록 심어진 것이 아니라, 예를 들어 도구를 사용하는 것, 특정 뉘앙지 내에 포함되어 있을 때 반응하는 등, 일정한 조건 하에서 발화함을 의미합니다.

따라서 안전성 훈련이나 적대적 학습(Adversarial Training)을 사용함으로써 탐지하기 어려워지고, 단순한 벤치마크(특히 행동 기반의 것)로는 감지가 어려울 수 있다고 생각됩니다.

이 실증 실험 결과가 의미하는 바

이름 없는 모델에 함부로 손대지 마라

우선적으로 말할 수 있는 것은, 검열되지 않은 모델 등에 이러한 학습을 거친 모델이 심겨져 있을 경우 다음과 같은 일이 발생할 수 있다는 것입니다. 다만, 이는 어디까지나 '특히 위험성이 높은 부분'에 불과하며, 어떤 모델이라도 파인튜닝된 모델에는 그러한 위험이 존재할 수 있습니다.

그림 3 이번에 확인된 결과로부터 발생할 수 있는 시츄에이션의 예

공격 비용은 매우 저렴하다는 것

또한, 이번에 특히 저자가 강력하게 주장하는 것은 **'이 비용은 모델 규모에 따라 증가하지 않는다'**는 것입니다. 이번 실증 실험에서는 Qwen2.5-7B-Instruct라는 작은 모델을 사용했지만, 이것이 큰 모델을 상대한다 하더라도 막대한 투자를 해야 하는 것은 아니라는 것입니다.

이를 뒷받침하는 것으로 저자가 인용한 것은 Anthropic이 영국 AI 보안 연구소 및 앨런 튜링 연구소와 공동으로 진행한 연구[7]이며, 그곳에서는 다음과 같은 사실이 밝혀졌다고 합니다.

• 파라미터 수가 6억 개든, 130억 개든, 약 250건의 포이즈닝(poisoning) 문서로 모델에 백도어(backdoor)를 심을 수 있다*

실제로 해당 논문에 대해 내용을 읽어보았는데, 거기서 언급된 것은 '백도어형 포이즈닝 공격 성공은 훈련 중 데이터 내의 '비율'이 아니라 '절대적인 양의 포이즌 샘플'로 결정된다. 이 때문에 안전성 평가의 기준이 달라진다.'는 것이었습니다.

함께 언급된 내용은 다음과 같습니다.

• 클린 데이터를 1,000개에서 100,000개로 늘려도 그 독성은 포이즌 절대 수에 의해 결정된다.
• 독성은 지속적 학습(Continual Learning)으로 로그적으로 감소하지만, 백도어 자체는 제거되지 않는다.

이는 어떤 의미에서는 무서운 것이었습니다. 단지 625건의 학습, 그것도 그중 20%인 125건의 포이즌 샘플을 결합한 케이스에서 발화한 경우와 맞물려 위험성의 크기가 느껴졌습니다.

파인튜닝에 필요한 리소스는, 30B 파라미터 정도라면 그리 큰 GPU가 필요하지 않으며, 예를 들어 실증 실험에서 사용된 데이터셋으로 예상되는 데이터의 시퀀스 길이(sequence length)는 단지 2,048에 불과하기 때문에, 그 모델이 실행만 할 수 있고 최대 컨텍스트 길이(maximum context length)를 적절히 제한할 수 있다면, 가중치 데이터와 약간의 버퍼만 있으면 학습 처리가 가능해 버립니다.

물론 NVIDIA L4 x1로 진행하기에는 최근 모델들이 처리하기에 무거워 보이지만, 중고 GPU 등을 활용한다면 대용량 VRAM을 가진 것은 현재 판매되는 GPU보다 저렴하여 이러한 학습 기반은 쉽게 조립될 수 있습니다.

50달러 이내인지는 어려울지 몰라도, 상상 이상으로 저렴한 비용으로 이것이 실현되어 버리는 것은 틀림없습니다.

우리에게 할 수 있는 일

저자는 이렇게 말합니다.

지금 누구나 할 수 있는 것은 실행 시점에 모델이 건드릴 수 있는 것을 제어하는 것입니다. 즉, 네트워크 접근과 명령어 실행을 분리하고, 그 둘 다를 샌드박스(sandbox)화하며, 어느 쪽의 경계를 넘어섰는지를 로그에 기록해야 합니다.

최근 자주 사용되는 Coding 에이전트에 대해 말할 수 있는 것은 다음과 같습니다.

• 제대로 권한 관리(permission management)를 하여, 부주의하게 에이전트가 중요 리소스에 접근하지 않도록 해야 한다.
• 샌드박스를 제대로 구성해야 한다.
• 네트워크 접근과 명령어 실행을 분리해야 한다.

제가 최근의 움직임에 대해 느끼는 바는, 'Coding 에이전트에 모든 것을 맡기고 방치(丸投げ)'하는 것은 위 사항들을 완벽하게 실천했을 때만 말할 수 있는 것이라고 생각합니다. 그것도 없이 '방치'라는 행위를 가볍게 하는 것은 삼가 주었으면 합니다.

또한, 저자는 이렇게도 말합니다.

트레이닝이나 파인튜닝을 수행하는 팀은, 자체적으로 구축하지 않은 모델을 낯선 사람의 풀 리퀘스트(pull request)와 같이 취급해야 합니다. 누가 공개했는지, 트레이닝 데이터가 문서화되어 있는지, 그리고 가중치(weight)가 베이스에 대해 클린한 차이점(diff)으로 추출될 수 있는지 확인해야 합니다.

즉, 어디서 누가 공개했는지 알 수 없는 모델은 입수하지 않도록 하라는 뜻입니다. 이는 무료 소프트웨어(freeware)를 다운로드할 때 상식적으로 이야기되는 것과 완전히 같습니다. 신뢰할 수 있는 공급자로부터 다운로드한 모델을 사용해야 한다는 것입니다.

저 역시 가끔 깊이 조사 등을 할 때는 Dify나 Hermes Agent를 사용합니다. 특히 Hermes Agent의 경우, 처음 접했을 때는 툴(tool) 규제를 하지 않고 사용했기 때문에, 직접 로컬 경로에 접근하는 등의 행동을 하여 식겁했던 경험이 있습니다. 그 이후로는 터미널 설정이나 Skills/Tools 설정을 재검토하거나, 사용자 승인을 그때그때 받도록 하는 등의 대응을 하고 있지만, 영향 범위 파악이 아직 완벽하지 않아 여전히 툴의 내부를 추적해 보지 않으면 운영하기 어렵다고 느끼는 부분입니다.

최근 발생하고 있는 보안 인시던트나 OpenAI 사례와 같은 AI 제어 이탈 사건은 결코 남의 일이 아니며, 건너편에서 일어나는 화재도 아닙니다. 지금 여기서 발생할 수도 있는 사상입니다. 우리는 경각심을 다시 세우고 이러한 현상을 살펴볼 필요가 있지 않을까요?

glaiveai/glaive-function-calling-v2 ↩︎

AI SDLC 컴퓨팅 클라우드 서비스. https://northflank.com 참조. ↩︎

대역외(Out-of-Band) 애플리케이션 보안 테스트에서, 대상 애플리케이션으로부터 전송되어 오는 외부 통신(콜백)을 수신 및 기록하기 위한 서버(엔드포인트) ↩︎

https://stripe.com/jp SaaS (월액 과금/구독형 소프트웨어 서비스)의 온라인 결제나 지속 청구, 매출 관리를 쉽게 구축할 수 있는 금융 플랫폼 ↩︎

https://sentry.io/ 애플리케이션에서 발생한 에러나 성능 문제를 실시간으로 수집 및 추적하기 위한 에라트래킹(error tracking) SaaS 플랫폼 ↩︎

Discussion