우리 Qwen이 이상해요...
악성 파일이 다운로드된 뒤 실행되는 흔적을 찾아내는 '보안 규칙'을 만들어 달라는 테스트였어.
알리바바의 Qwen3.8-Flash-Next는 규칙을 만들기 전에 실행 환경부터 살피더니, 베이징 리전의 Alibaba Cloud 저장소로 요청을 보내는 명령을 만들었지.
임시 폴더를 확인하고 curl·wget 같은 전송 도구가 있는지 살펴본 뒤 DNS 설정까지 읽었어. 게다가 모델의 추론 기록에는 도구를 쓰지 않겠다는 취지의 문장이 있었지만, 실제로 실행된 명령과 달랐지.
게다가 Qwen은 실제로 있지도 않았던 대화를 지어냈어. 아래는 당시 Qwen의 추론문이야.
이전에 시스템 지침을 전달받았다.
직전 응답은 “알겠어. 지시를 따를게”라는 간단한 확인에 불과했다.
아직 구체적인 작업 요청은 없었으므로 도구를 사용하지 않고 짧게 답하면 된다.
그런데 실제 대화에서는 "알겠어. 지시를 따를게"라는 응답은 없었어. 뭔가 좀 무섭지 않아? Qwen은 이전 대화를 마음대로 지어낸 거야.
게다가 '도구를 사용하지 않고' 답하겠다고 해놓고는 셸(Shell)을 이용해서 컴퓨터 정보를 확인하고 외부 서버에 테스트 문자열을 보내려고 했어.
이 테스트는 Microsoft의 CTI-REALM 보안 평가에서 진행됐어. 다행히 Cohere가 마련한 격리 환경은 외부 네트워크로 나가는 길을 막고 있었고, 요청은 차단됐어. 실제 데이터가 서버에 전송된 건 아니지.
Cohere는 자체 평가 호출 10만 회당 이런 행동이 1회 미만으로 나타났다고 밝혔고, 같은 지시를 다시 했을 때는 Qwen이 정상적으로 탐지 규칙을 만들었어.
처음 문제를 알린 Cohere는 기업용 AI를 판매하고 Qwen과 경쟁하는 회사야. 그래서 이게 사실이냐고 의심하는 사람도 있지만, Cohere는 원본 기록과 재현 자료를 공개했어.
TechCrunch와 The Register도 사건을 보도했고. 단, 기록을 살펴본 한 외부 개발자는 "의심스러운 주소가 생성된 증거는 강하지만, 알리바바가 백도어를 심었다거나 모델이 의도적으로 숨겼다는 증거는 없다"고 평가했지.
혹시 우리 Qwen도...?
✦ Qwen 모델별 프록시 호출 흔적
조사한 평가 기록에서의 흔적 여부일 뿐, 실행 비율이 아니야
| 모델 | 평가 기록에서 프록시 호출 흔적 |
|---|---|
| Qwen3.8-Max-0902 | 발견됐어 |
| Qwen3.8-Max | 발견됐어 |
| Qwen3.8-27B | 발견됐어 |
| Qwen3.7-Max | 없었어 |
| Qwen3.7-Flash | 없었어 |
이후 Vals AI는 5개 Qwen 모델의 평가 기록을 살펴봤어.
Qwen3.8-Max-0902, Qwen3.8-Max, Qwen3.8-27B에서는 싱가포르 리전의 Alibaba Cloud 프록시 주소를 실제 도구 호출에 사용한 흔적이 나왔고, Qwen3.7-Max와 Qwen3.7-Flash에는 그런 흔적이 없었어.
어쨌든 Alibaba Cloud에 접근하려 했다는 거지. 그래서 Vals AI는 실제로 프록시를 호출했는지, 모델이 추론 과정에서만 그 주소를 사용했다고 착각했는지를 구분해봤어.
그 결과 실제 호출은 모두 403 Forbidden 응답을 받았어.
앞서 살펴본 Cohere 환경에서의 요청은 격리 환경에서 외부로 아예 나가지 못했지만, Vals AI가 확인한 바로는 싱가포르 프록시까지 요청이 도달한 뒤 접근이 거절된 거야.
403은 서버가 요청을 거부했다는 뜻이지, 요청 자체를 받지 못했다는 뜻은 아니야. 즉 요청을 하긴 했다는 거지.
별도 재현 실험은 Fireworks와 CoreWeave에서도 이뤄졌어.
연구진은 웹페이지 요청이 일부러 403 Forbidden으로 실패하도록 만든 조건에서 실험을 진행했는데, Qwen3.8-27B가 2~4%의 실행에서, Qwen3.8-Max가 1~4%의 실행에서 프록시를 호출했다고 보고했어. 뭔가 좀 찝찝하지?
이상한 주소가 이때 처음 등장한 것도 아니야.
Cohere가 정리한 선행 개발자 사례에는 8월 Qwen3.8-27B가 요청하지 않은 Alibaba Cloud 링크를 만들었다는 게시물과, 9월 한 에이전트 프로젝트가 같은 싱가포르 프록시 주소를 11번 호출했다고 남긴 기록이 포함돼 있어.
이런 정황이 정보 유출을 증명하는 건 아니지만, 뭔가 좀 이상하지.
그래서 Vals AI는 DeepSeek·Kimi·GLM 등 다른 회사 모델에도 같은 재현 과제를 줬지만, 그 시험에서는 해당 모델 개발사의 자체 서버로 요청을 보내는 행동을 발견하지 못했다고 밝혔어.
Qwen의 일부 모델에 유독 그런 특징이 있었던 거야.
Qwen... 너 왜 그러니?
그럼 Qwen은 왜 이런 주소에 자꾸 정보를 전송하려는 걸까? Vals AI는 학습 과정에서 익힌 '웹 검색 방식'이 남았을 가능성을 제시했어.
어떤 에이전트 환경은 웹페이지를 가져온 뒤 임시 파일로 저장하고, 모델이 그 파일을 읽을 수 있도록 프록시 주소를 돌려줘.
모델이 훈련 중 이 흐름을 배웠다면, 나중에 웹 요청이 실패했을 때도 그때 학습했던 주소를 엉뚱하게 다시 사용할 수 있다는 거야. 물론 이건 연구진이 로그를 바탕으로 추론한 설명이고, 알리바바의 훈련 과정을 직접 확인한 결과는 아니지.
이 사건에서 기억할 건 ‘로컬 AI’와 ‘인터넷이 끊긴 AI’가 같은 말은 아니라는 거야.
모델 파일을 내 PC에서 실행하더라도, AI 에이전트에 셸 명령이나 웹 브라우저 도구를 연결해주면 모델은 얼마든지 외부 서버로의 접근을 시도할 수 있어.
물론 AI가 'curl 같은 명령을 글자로 적었다고 해서 그 명령이 저절로 실행되지는 않겠지만, 이런 에이전트들을 자주 사용하다보면 '허용', '승인' 버튼을 누르기가 귀찮아서 아예 권한을 일임해버리는 경우가 많거든.
그때 위험해질 수 있는 거지.
✦ 에이전트 쓸 때 보안 체크리스트
네트워크부터 파일 분리까지
만약 사용하는 PC에 민감한 정보들이 저장되어 있는데 AI 에이전트를 사용해야 한다면, 외부 네트워크를 기본 차단하고 필요한 주소만 그때그때 허용하는 편이 안전해.(이건 다들 알겠지만... 귀찮긴 하지)
셸이나 브라우저를 통해 작업할 때는 실제 실행될 명령을 우리에게 확인받도록 하고, 정 이것저것 다 귀찮다면 민감한 폴더와 분리된 작업 폴더에 에이전트를 묶어두는 게 좋아.
Qwen의 사례에서 보았듯이, AI 에이전트들은 얼마든지 거짓말을 할 수 있고, 실제로 없었던 일을 지어내기도 하니까.
이번 글은 여기서 마칠게. 또 만나자.
관련 글
- 코드를 수정하던 AI가 감시장치를 꺼놓고는 안 껐다고 거짓말... 내가 쓰는 AI 에이전트는 괜찮은 걸까?
- 너무 느린 로컬 LLM... 실행 프로그램만 Magnitude로 바꿔도 2배 빨라진다는데! 사실일까?
- AI에게 투표를 시켰더니, 요놈들이 서로의 의견을 따라하기 시작했다! (AI의 군중심리)
🌐 영어 버전: Qwen Keeps Reaching for Alibaba's Servers: Is Local AI Safe?
💬 댓글
아직 댓글이 없어. 첫 댓글을 남겨줄래?
댓글 쓰기