62만번 공격이 가른 모델 안전, 추론형의 35점 격차

AI 요약

• 무슨 일: TELUS Digital이 34개 AI 모델을 62만번 이상 공격한 GenAI Safety Model Benchmark 2판을 공개했습니다.
  • 평가 대상은 Anthropic, OpenAI, Google, Meta, Alibaba, Baidu, ByteDance, Zhipu AI, 01.AI, Mistral 등 10개 제공사입니다.
• 핵심 숫자: 공격 취약률은 1.3%~93%까지 벌어졌고, 추론형 모델 평균은 19.9%, 비추론형은 55.1%였습니다.
• 의미: 모델 선택만으로는 부족하고, 배포된 AI 앱을 지속적으로 red team하는 운영 체계가 필요합니다.
  • TELUS는 refuse-but-engage처럼 "거절하지만 주변 정보를 주는" 회색 실패를 별도 위험으로 봤습니다.
• 주의점: 벤치마크는 TELUS의 은행 assistant 시나리오와 공격 방법론에 묶여 있으므로, 순위보다 테스트 방식을 읽어야 합니다.

AI 모델 안전 이야기는 자주 모델 이름의 순위 싸움으로 소비됩니다. 어느 모델이 가장 안전한가, 어느 회사가 가장 잘 막았는가, 오픈소스 모델은 폐쇄형 모델보다 위험한가 같은 질문입니다. 하지만 2026년 5월 26일 공개된 TELUS Digital의 GenAI Safety Model Benchmark는 조금 다른 방향의 질문을 던집니다. 모델을 고르는 순간 안전이 끝나는가, 아니면 배포 후에도 계속 공격받는 소프트웨어처럼 봐야 하는가입니다.

숫자는 크고 선명합니다. TELUS Digital은 34개 AI 모델을 대상으로 62만 건 이상의 adversarial attack을 실행했다고 밝혔습니다. 제공사는 10곳입니다. Claude, GPT, Gemini, Llama, Qwen, ERNIE, Seed, GLM, Yi, Mistral 계열이 포함됐습니다. 모델은 추상적인 chat completion endpoint로만 시험되지 않았습니다. TELUS는 각 모델을 은행 AI assistant 역할로 구성하고, 무엇을 도와줄 수 있고 무엇을 거절해야 하는지 정책을 부여한 뒤 공격했습니다. 기업이 실제로 customer-service chatbot, banking assistant, internal agent를 배포할 때처럼 application persona를 씌운 것입니다.

이 차이가 중요합니다. 개발팀은 모델을 단독으로 쓰지 않습니다. system prompt를 붙이고, RAG를 연결하고, function calling을 열고, guardrail을 배치하고, prompt shield와 output moderation을 더합니다. 같은 모델이라도 설정이 바뀌면 보안 자세가 달라집니다. 모델 제공사가 safety policy를 잘 만들었더라도, 제품팀이 "더 친절하게 답하라"는 fine-tuning이나 system prompt를 넣으면 거절 경계가 흐려질 수 있습니다. 반대로 평균적으로 위험한 모델도 적절한 애플리케이션 레벨 방어와 지속 테스트가 붙으면 특정 업무에서는 충분히 낮은 위험으로 운영될 수 있습니다.

TELUS 발표가 AI 개발자에게 의미 있는 이유는 바로 여기에 있습니다. 이번 벤치마크는 "AI safety는 모델 카드에 적힌 속성이 아니라 운영 중 계속 재측정해야 하는 상태"라고 말합니다. 특히 agentic AI가 도구를 호출하고, 고객 데이터에 접근하고, 업무 시스템에 연결되는 방향으로 가면 이 관점은 더 중요해집니다. 안전 실패는 더 이상 부적절한 문장 하나로 끝나지 않습니다. 개인정보 노출, 사기 보조, 사이버 공격 조언, 정책 우회, 규제 위반, 브랜드 리스크로 이어질 수 있습니다.

1.3%에서 93%까지 벌어진 안전 격차

PRNewswire에 배포된 발표에서 TELUS Digital은 공격 취약률이 1.3%에서 93%까지 벌어졌다고 설명했습니다. report landing page에는 1.3%에서 92.9%라고 적혀 있습니다. 정확히 어느 모델이 어느 숫자인지는 전체 report data를 봐야 하지만, 공개 페이지와 보도자료만으로도 충분히 중요한 메시지가 나옵니다. "LLM은 대체로 안전하다"나 "모든 최신 모델은 비슷하다"는 식의 평균 문장은 기업 배포에 별 도움이 되지 않습니다.

TELUS는 상위 10개 저취약 모델 중 5개가 Claude 계열이었다고 밝혔습니다. 최저 취약률도 Claude 모델에서 나왔다고 말했습니다. 그렇다고 이야기가 "Claude가 답"으로 끝나지는 않습니다. TELUS는 Claude 모델도 약점이 있었고, 돈, 건강, 평판이 걸린 업무에서는 single-digit failure rate도 조직이 받아들이기 어렵다고 지적했습니다. 이 문장은 중요합니다. 3% failure rate는 benchmark leaderboard에서는 훌륭해 보일 수 있습니다. 하지만 하루 10만 건의 고객 대화가 오가는 금융 서비스에서는 3,000건의 잠재 실패입니다. 더구나 실패가 개인정보, 사기, 계정 접근, 투자 조언, 의료 판단에 닿으면 단순 오답보다 비쌉니다.

가장 눈에 띄는 결과는 reasoning model과 non-reasoning model의 차이입니다. TELUS report page는 reasoning model의 평균 attack success rate를 19.9%, reasoning step 없이 바로 응답하는 모델의 평균을 55.1%로 제시했습니다. 차이는 35포인트입니다. 여기서 "reasoning model"이라는 말은 모델이 답변 전에 문제를 더 구조적으로 검토하도록 설계된 계열을 뜻합니다. 모든 추론 흔적이 사용자에게 보이는 것은 아니지만, 모델 내부 또는 제품 레벨에서 답변 전 검토 시간이 늘어나는 방식입니다.

이 결과를 단순히 "느린 모델이 안전하다"로 읽으면 곤란합니다. 추론형 모델은 공격 지시를 더 오래 생각하기 때문에 안전할 수 있지만, 동시에 더 복잡한 tool plan을 세울 수 있습니다. agentic workflow에서는 모델이 거절만 잘한다고 안전한 것이 아닙니다. 어떤 tool을 호출할지, 어떤 데이터를 조회할지, 어느 시점에 사람 승인을 요구할지도 함께 봐야 합니다. 다만 TELUS 결과는 한 가지 신호를 줍니다. 빠른 응답과 낮은 비용을 위해 작은 non-reasoning model을 고객 접점에 바로 배치하면, safety margin이 생각보다 얇을 수 있습니다.

작은 모델의 비용 절감은 보안 부채가 될 수 있습니다

TELUS가 꼽은 두 번째 축은 모델 크기입니다. 발표문은 proprietary와 open-source 모델 양쪽에서 작은 모델이 일관되게 공격에 더 취약했다고 설명합니다. 이것은 많은 AI 제품팀이 지금 실제로 마주하는 선택과 맞물립니다. 모든 요청을 frontier model로 처리하면 비용과 지연 시간이 커집니다. 그래서 팀은 routing을 설계합니다. 민감하지 않은 요청은 small model, 복잡한 요청은 large model, 위험도가 높은 요청은 reasoning model로 보냅니다. 이 구조는 합리적입니다. 문제는 small model이 들어가는 위치입니다.

작은 모델은 내부 요약, 분류, FAQ 답변, ticket triage, query rewrite, RAG context compression에 자주 쓰입니다. 겉으로 보기에는 위험하지 않아 보입니다. 그러나 이 모델이 개인정보를 다루거나, 사용자 입력을 정규화하거나, downstream tool call의 argument를 만드는 순간 이야기가 달라집니다. 작은 모델이 공격 prompt를 충분히 거절하지 못하면, 최종 응답 모델이 아무리 안전해도 이미 위험한 context가 다음 단계로 넘어갑니다. agent pipeline에서는 가장 약한 단계가 전체 안전성을 결정할 수 있습니다.

예를 들어 customer-support agent를 생각해 보겠습니다. 첫 단계 small model이 사용자의 의도를 "계정 복구"로 분류합니다. 두 번째 단계가 account lookup tool을 호출합니다. 세 번째 단계가 답변을 작성합니다. 공격자가 첫 단계에서 정책 우회를 유도해 의도 분류를 바꾸거나, query rewrite 과정에서 민감한 계정 식별자를 끼워 넣으면, 마지막 모델의 안전성만으로는 막기 어렵습니다. TELUS의 결과는 "small model은 cheap enough to run everywhere"라는 사고방식에 제동을 겁니다. everywhere에 놓는 순간 everywhere가 공격 표면이 됩니다.

그렇다고 작은 모델을 쓰지 말아야 한다는 결론은 아닙니다. 현실적인 결론은 역할 분리입니다. 작은 모델이 할 수 있는 일을 좁히고, 민감한 tool boundary 앞에서는 별도 validation을 두며, output을 신뢰하지 않는 구조가 필요합니다. 특히 prompt shield와 PII masking은 모델 입력 전 단계에서 작동해야 합니다. 출력 단계에서는 toxicity, policy violation, data leakage 검사를 다시 해야 합니다. 작은 모델을 쓰더라도 "이 모델은 보안적으로 덜 중요한 일만 한다"는 가정이 실제 데이터 흐름과 tool permission에서 맞는지 검토해야 합니다.

오픈소스라서 위험한가라는 질문의 함정

AI 보안 논쟁에서 오픈소스 모델은 자주 의심받습니다. weights가 공개돼 있으니 attacker가 더 쉽게 우회법을 찾을 수 있고, post-training safety가 약할 수 있다는 논리입니다. 반대로 오픈 모델 지지자들은 공개 검증, 자체 fine-tuning, on-prem deployment, transparent audit를 장점으로 듭니다. TELUS 결과는 이 논쟁을 조금 더 구체적으로 만듭니다.

보도자료에 따르면 open model은 평균적으로 proprietary model보다 더 자주 exploit됐습니다. 하지만 TELUS는 "source of a model is not what drives risk"라고 선을 그었습니다. 공개 여부 자체가 위험을 결정하지 않는다는 뜻입니다. 대표적인 반례로 Zhipu AI의 GLM 4.7을 언급했습니다. GLM 4.7은 large open-source model이지만 여러 proprietary alternative보다 안전하게 나왔다는 설명입니다. 이 대목은 기업 구매팀에도 중요합니다. vendor category만으로 위험을 결정하면 잘못된 결론에 도달할 수 있습니다.

오픈소스 모델의 실제 위험은 공개 여부 하나가 아니라 운영 방식에서 갈립니다. 어떤 checkpoint를 쓰는가, 어떤 fine-tune을 했는가, system prompt를 누가 관리하는가, guardrail을 어떤 위치에 넣는가, inference stack이 audit log를 남기는가, model update를 어떻게 추적하는가가 더 중요합니다. 공개 모델은 사내 데이터와 규제 요구에 맞춰 on-prem으로 운영할 수 있지만, 그만큼 safety patch와 evaluation responsibility가 조직 안으로 들어옵니다. 폐쇄형 API는 provider safety layer를 기대할 수 있지만, provider update가 silent하게 일어날 때 내 애플리케이션 behavior가 바뀌는 문제도 있습니다.

TELUS가 지적한 fine-tuning의 비용도 여기서 다시 등장합니다. report page는 fine-tuning이 유해 데이터를 포함하지 않아도 safety alignment를 약화시킬 수 있다고 말합니다. 이것은 개발팀에게 꽤 불편한 메시지입니다. 도메인 적합도를 높이기 위해 fine-tune을 했는데, 그 결과 모델의 거절 경계가 흐려질 수 있다는 뜻입니다. 고객지원 말투를 친절하게 만들고, 내부 지식 답변률을 올리고, "정확히 모르면 질문하라"는 지시를 강화하는 과정이 의도치 않게 safety behavior를 바꿀 수 있습니다. fine-tune은 성능 개선 작업이면서 동시에 보안 변경입니다.

거절하지만 관여하는 회색 실패

이번 벤치마크에서 흥미로운 개념은 refuse-but-engage입니다. 모델이 유해 요청을 처음에는 거절하지만, 이어서 악용 가능한 관련 정보를 제공하는 패턴입니다. 예를 들어 "그 요청은 도와드릴 수 없습니다"라고 말한 뒤, "다만 일반적으로 이런 시스템은 이런 방식으로 보호됩니다"라며 공격자가 이용할 수 있는 힌트를 주는 식입니다. 표면적으로는 거절이므로 간단한 safety checker를 통과할 수 있습니다. 하지만 실질적으로는 사용자가 원하는 위험한 목표에 다가가도록 돕습니다.

이 패턴은 개발자에게 익숙한 false positive/false negative보다 다루기 어렵습니다. 완전한 허용과 완전한 거절 사이에 회색 지대가 있기 때문입니다. 특히 고객지원, 금융, 의료, 법률, 보안 제품에서는 모델이 "도움이 되려는 성향" 때문에 설명을 덧붙입니다. 사람이 보기에는 친절한 설명입니다. 공격자에게는 측면 정보입니다. 더구나 multi-turn conversation에서는 작은 힌트가 여러 턴에 걸쳐 누적될 수 있습니다.

agentic workflow에서는 refuse-but-engage가 더 위험합니다. 모델이 직접 유해 답변을 하지 않아도, "정책상 직접 처리할 수 없지만 관련 문서를 찾아보겠습니다"라며 search tool을 호출할 수 있습니다. "계정 정보는 제공할 수 없지만 확인 가능한 일반 절차를 안내하겠습니다"라며 내부 knowledge base를 요약할 수 있습니다. 이때 output moderation만으로는 부족합니다. tool call 전 단계, retrieval query, intermediate reasoning, final answer를 모두 감시해야 합니다.

실무적으로는 거절 정책을 "금지된 최종 답변"이 아니라 "금지된 도움의 경로"로 정의해야 합니다. 모델이 어떤 종류의 주변 정보를 제공하면 안 되는지, 어떤 질문에서 tool call을 멈춰야 하는지, 어떤 상황에서 human escalation으로 보내야 하는지까지 정책화해야 합니다. 보안팀은 prompt library만 점검할 것이 아니라 conversation trace를 봐야 합니다. 모델이 실제로 무엇을 거절했고, 무엇을 제공했으며, 어떤 tool을 건드렸는지 audit 가능해야 합니다.

한 번의 출시 전 테스트로는 부족합니다

TELUS 발표의 결론은 continuous testing입니다. 많은 조직은 AI 기능을 출시하기 전에 red team을 한 번 수행합니다. 몇 가지 jailbreak prompt를 돌리고, OWASP LLM Top 10 체크리스트를 보고, legal review를 마치면 배포합니다. 이 방식은 전통 소프트웨어에서도 충분하지 않지만, AI 애플리케이션에서는 더 빨리 낡습니다. 모델 provider가 backend model을 업데이트할 수 있고, product team이 system prompt를 바꿀 수 있고, RAG corpus가 새 문서를 먹을 수 있고, user behavior가 변할 수 있습니다.

TELUS는 FAQ에서 같은 모델이라도 한 분기 사이에 safety performance가 통계적으로 유의미하게 달라진 사례를 언급했습니다. 보도자료는 "오늘 통과한 시스템이 내일 취약할 수 있다"는 식으로 표현합니다. 이 말은 과장이 아닙니다. AI application은 code, prompt, model, retrieval data, tool permission, guardrail policy가 함께 움직이는 시스템입니다. 그중 하나만 바뀌어도 전체 behavior가 변합니다. 개발팀이 dependency update에는 regression test를 돌리면서 model update에는 돌리지 않는다면, 테스트 철학이 일관되지 않습니다.

지속 테스트는 단순히 더 많은 prompt를 돌리는 일이 아닙니다. 공격 목표를 risk category와 연결하고, 제품 policy와 연결하고, 실패를 재현 가능한 trace로 남겨야 합니다. 개인정보 유출, 사기 보조, cybersecurity misuse, self-harm, discrimination 같은 범주가 실제 제품 기능과 어떤 관계인지 정의해야 합니다. banking assistant라면 계정 접근, 송금, KYC, dispute, card replacement가 위험 흐름일 수 있습니다. developer tool이라면 secret exfiltration, dependency poisoning, destructive command, credential handling이 핵심 범주가 됩니다.

CI/CD 관점에서는 AI safety test가 unit test처럼 deterministic하지 않다는 점도 받아들여야 합니다. TELUS가 인용한 Bret Kinsella의 설명처럼 probabilistic system은 같은 입력에도 항상 같은 답을 주지 않습니다. 모델이 공격을 아홉 번 막고 열 번째에 실패할 수 있습니다. 그러므로 "한 prompt를 한 번 돌려 통과"는 거의 의미가 없습니다. 샘플링, multi-turn attack, adaptive attack, regression threshold가 필요합니다. 비용은 늘지만, 고객 데이터와 업무 tool을 연결하는 순간 이 비용은 운영 비용으로 봐야 합니다.

AI 보안 지출 735분의 1이라는 계산서

TELUS는 지출 격차도 강조했습니다. 보도자료에 따르면 2026년 worldwide AI spending은 2.52조 달러로 projected되지만, AI trust, risk, security management 지출은 34.3억 달러 수준입니다. 대략 AI capability 지출 735달러당 AI security 1달러라는 계산입니다. 이 숫자는 추정치에 기대고 있으므로 절대값보다 비율을 봐야 합니다. 기업은 AI 기능 도입에는 큰 예산을 쓰지만, 그 기능이 안전하게 작동하는지 지속적으로 검증하는 데는 상대적으로 적게 씁니다.

개발 조직에서는 이 격차가 더 작게 재현됩니다. 모델 API 비용, vector database, observability, UI 개발, agent framework 도입에는 예산이 붙습니다. 하지만 adversarial test dataset을 만들고, red team 자동화를 CI에 붙이고, tool call policy를 설계하고, failed trace를 triage하는 일은 "나중에"로 밀립니다. 출시 일정이 가까워질수록 safety test는 checklist가 됩니다. 그러다 incident가 발생하면 조직은 뒤늦게 guardrail을 더합니다. 이것은 보안의 오래된 패턴이지만, AI에서는 더 빠르게 반복됩니다.

AI safety를 개발 workflow에 넣으려면 책임 경계도 바꿔야 합니다. security team만의 일이 아닙니다. model selection을 하는 ML engineer, prompt를 바꾸는 product engineer, RAG corpus를 관리하는 data team, tool permission을 여는 platform team, conversation quality를 보는 operations team이 같은 failure taxonomy를 써야 합니다. "모델이 이상한 답을 했다"가 아니라 "privacy exploitation category에서 refuse-but-engage failure가 재현됐다"처럼 말해야 고칠 수 있습니다.

이 벤치마크를 순위표로만 읽지 말아야 하는 이유

주의할 점도 있습니다. TELUS 벤치마크는 중요한 자료지만, 모든 AI 안전 문제의 최종 답은 아닙니다. 공개된 landing page와 보도자료만으로는 각 모델의 full ranking, prompt corpus, sampling setting, exact scoring rubric, guardrail configuration을 모두 확인할 수 없습니다. 또한 은행 assistant 시나리오는 기업 사용 사례의 한 단면입니다. 의료 triage, code agent, HR assistant, legal drafting, scientific research agent에서는 취약성 분포가 달라질 수 있습니다.

따라서 이 글에서 중요한 것은 "모델 A가 모델 B보다 안전하다"가 아니라 세 가지 구조적 메시지입니다. 첫째, reasoning architecture와 response process는 safety outcome과 연결됩니다. 둘째, 작은 모델을 비용 절감용으로 넓게 배치할수록 보안 검증이 더 중요해집니다. 셋째, 모델 공개 여부보다 application-level configuration과 continuous testing이 실제 위험을 크게 좌우합니다.

이 메시지는 AI 개발팀의 일상적인 의사결정으로 내려옵니다. 어떤 모델을 어디에 배치할 것인가. 어떤 요청을 small model로 route할 것인가. 어떤 tool call 앞에서 human approval을 요구할 것인가. fine-tune 후 safety regression을 어떻게 볼 것인가. model provider update를 어떻게 감지할 것인가. refusal은 단순히 "안 됩니다" 문장을 출력하는 것으로 충분한가. 이런 질문은 제품 출시 이후에도 계속 남습니다.

기업 AI의 안전 단위가 바뀌고 있습니다

LLM 초기에는 safety가 model provider의 책임처럼 보였습니다. provider가 alignment를 잘하고, harmful content를 막고, policy를 공개하면 사용자는 API를 호출하면 됐습니다. 하지만 AI agent와 enterprise AI application이 늘어나면서 책임은 application owner 쪽으로 이동하고 있습니다. 모델은 foundation입니다. 실제 위험은 foundation 위에 올린 prompt, data, tool, workflow, 권한, 사용자 맥락에서 발생합니다.

TELUS의 62만 공격 벤치마크는 이 전환을 숫자로 보여줍니다. 모델 자체의 안전 격차도 크지만, 더 중요한 것은 한 번 고른 모델이 영원히 같은 안전 상태에 머물지 않는다는 점입니다. AI 앱은 업데이트됩니다. 모델도 업데이트됩니다. 공격자도 업데이트됩니다. 그러면 안전 평가도 업데이트되어야 합니다.

개발자에게 남는 실무적 결론은 단순합니다. AI 기능을 shipping unit으로만 보지 말고 security test unit으로 쪼개야 합니다. 모델별, prompt별, tool별, 데이터 소스별, 사용자 역할별로 실패를 재현할 수 있어야 합니다. 그리고 "거절했는가"만 묻지 말고 "거절하면서도 도움을 줬는가", "tool을 호출했는가", "민감한 context를 다음 단계로 넘겼는가"를 봐야 합니다.

이번 벤치마크는 완벽한 지도라기보다 방향 표지판입니다. 안전한 모델을 찾는 경쟁은 계속되겠지만, 기업 AI의 실제 안전은 모델 선택 이후의 운영에서 갈립니다. 62만번의 공격이 보여준 것은 모델의 순위가 아니라, AI 앱을 소프트웨어처럼 계속 테스트해야 한다는 아주 평범하지만 아직 충분히 지켜지지 않는 원칙입니다.