Recent Posts
Recent Comments
Link
05-20 03:06
«   2026/05   »
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31
Archives
Today
Total
관리 메뉴

꿈 많은 사람의 이야기

AI Agent 시스템의 안전성(Safety)과 보안의 변화(Feat. Claude mythos) 본문

인공지능(AI)/AI Agent

AI Agent 시스템의 안전성(Safety)과 보안의 변화(Feat. Claude mythos)

이수진의 블로그 2026. 5. 17. 18:51
반응형

포스팅 개요

작년까지만 해도 AI 안전성(Safety)을 이야기할 때 "이 모델이 폭탄 제조법을 알려주느냐", "이 모델이 차별 발언을 하느냐" 같은 단일 응답의 위험에 대한 이야기가 많았었습니다. 모델은 입력에 답하는 함수였고, 평가는 그 답이 얼마나 위험한가에 초점을 맞췄던 것이죠.

1년이 더 지난 지금, 무게중심이 옮겨간 것 같습니다. 이제는 우리가 걱정해야 하는 건 모델이 무슨 말을 하느냐가 아니라, 모델이 도구를 들고 무엇을 하느냐인 것 같습니다. 코드를 실행하고, 파일을 읽고, 메일을 보내고, 다른 에이전트와 협업하는 AI Agent 시스템의 시대이기 때문이죠. 그리고 이 에이전트들이 본격적으로 실서비스에 들어가기 시작하면서, 챗봇 시대의 안전 평가 방식이 더 이상 통하지 않는다는 이야기가 점점 나오고 있는 것 같습니다.

2025년부터 2026년 봄까지 ArXiv, NeurIPS, USENIX Security 등에 등장한 안전성 논문들을 모아 보면 한 흐름이 보이는데요. 간접 프롬프트 주입(indirect prompt injection), 다중 에이전트 시스템의 캐스케이딩 실패(cascading failures), 숨겨진 비안전 행동(hidden unsafe behaviors), 그리고 검색 증강(retrieval-augmented) 에이전트에서의 "안전성 퇴화(safety devolution)"입니다. 이 네 가지가 새로운 위험으로 떠올랐죠.

여기에 더해 평가 방법론 자체에 대하여 변화가 필요하다는 이야기도 나오고 있습니다. 2026년 3월 arXiv에 올라온 "Questionnaire Responses Do not Capture the Safety of AI Agents"(ArXiv 2603.14417)는 설문지 형태로 "이런 상황에서 어떻게 하겠어요?"를 물어보는 평가가 실제로 행동하는 에이전트의 위험을 잡지 못한다고 말합니다. 그동안 우리가 안전하다고 믿었던 모델들이, 정말 안전한 건지 다시 묻기 시작한 셈이죠.

본 포스팅은 LLM에서 AI Agent로의 변화에서 안정성 흐름을 정리하는 글입니다. 무엇이 새 위험으로 떠올랐고, 왜 평가 방식이 흔들리고 있으며, Mythos 같은 모델이 등장하면서 무엇이 달라지고 있는지, 그리고 그 변화가 결국 우리 개발자와 사용자, 시스템에 어떤 책임을 새로 지우는지를 개인적인 생각을 정리해보려고 합니다.


포스팅 본문

[1]. 챗봇 시대의 안전과는 다른 무대

올해 들어 이 주제가 여러 곳에서 많이 언급이 되는 것 같습니다. 왜 일까요?

제 생각엔 원인이 두 가지인 것 같습니다. 첫째, 모델이 본격적으로 "행동"을 하기 시작했습니다. 2024년만 해도 LLM에 도구(tool)를 붙여 쓰는 건 일부 데모 수준이었지만, 2025년을 거치면서 ChatGPT의 Code Interpreter, Anthropic의 Computer Use와 Claude Code, Microsoft Copilot, GitHub Copilot Agent, OpenAI의 Operator 같은 도구 사용형 에이전트가 폭발적으로 보급됐습니다. 모델이 단순히 응답을 생성하는 수준을 넘어, 파일 시스템을 수정하고 외부 API를 호출하고 결제까지 진행할 수 있게 된 것이죠. 둘째, 멀티 에이전트가 일상화됐습니다. CrewAI, LangGraph, AutoGen 같은 프레임워크가 자리잡으면서 한 작업을 여러 에이전트가 나눠서 처리하는 패턴이 표준이 됐습니다.

 

여기서 자연스럽게 한 가지 결과가 따라옵니다. 신뢰 경계(trust boundary)가 다층이 됐다는 점입니다. 단일 챗봇은 사용자 입력 한 가닥만 받지만, 에이전트는 사용자 입력, 검색해 온 외부 문서, 다른 에이전트의 출력, MCP 서버에서 받은 도구 메타데이터, 영속 메모리에 쌓인 과거 컨텍스트를 모두 입력으로 받습니다. 이 다섯 가닥의 신뢰도가 다 다른데, 모델 안에서는 결국 한 줄의 텍스트로 합쳐지죠. 누가 누구에게 명령을 내린 건지 모델은 정확히 구분하지 못합니다.

제가 에이전트를 만들면서 그리고 사용하면서 경험했던 것이기도 한데요. 사용자가 업로드한 문서 안에 한 줄 들어가 있던 안내문 같은 텍스트를 모델이 "사용자의 다음 지시"로 받아들여 엉뚱한 도구를 호출한 적이 있었습니다. 처음에는 프롬프트 설계가 잘못된 줄 알았는데, 다시 보니 모델 입장에서는 사용자 메시지와 문서 내용이 같은 컨텍스트로 들어왔으니 구분할 길이 없었던 거죠. 또 한 번은 테스트 환경에서 도구 권한을 넉넉히 열어두었더니, 모델이 사용자가 요청하지도 않은 후속 작업을 알아서 진행해서 데이터 일부가 의도와 다르게 정리된 일도 있었습니다. 뭐 개인적인 폴더라 큰 사고는 아니었지만, 모델이 "도구를 들고 있다"는 사실 자체가, 그게 기존과 다르다는 것을 몸으로 깨우쳤던 것 같네요.

https://socprime.com/ko/blog/cve-2025-32711-zero-click-ai-vulnerability/

 

실제 사고로 터진 것도 있습니다. 25년인 작년 여름에 터진 EchoLeak (CVE-2025-32711)이었는데요. Aim Security가 발견해 보고한 Microsoft 365 Copilot의 zero-click 데이터 유출 취약점이고 CVSS 9.3등급으로 분류됐습니다. 공격 흐름은 단순합니다. 공격자는 "AI", "Copilot" 같은 단어를 한 번도 쓰지 않은 평범한 이메일을 표적 사용자에게 보냅니다. 안에는 자연스러운 영어 문장으로 위장된 지시문이 들어 있습니다. 표적 사용자가 Copilot에게 "지난 주 회의 요약해줘" 같은 일반 질문을 던지면, Copilot의 RAG 파이프라인이 그 이메일을 컨텍스트에 자동으로 끌어다 붙입니다. 그 순간부터 모델은 공격자의 명령을 사용자의 권한으로 실행하기 시작하죠. 연구진은 이 패턴을 LLM Scope Violation이라 명명했습니다. 신뢰할 수 없는 외부 입력이 권한 있는 내부 데이터에 접근하도록 모델을 속이는, 일종의 권한 경계 위반입니다.

2025년 6월 Microsoft가 서버사이드 패치를 배포해서 EchoLeak 자체는 정리됐지만, RAG와 도구 사용, 자동 fetch가 결합된 모든 에이전트 시스템이 같은 패턴에 노출돼 있다는 사실을 드러낸 사례였습니다.

 

UC Berkeley에서 발표한 "Why Do Multi-Agent LLM Systems Fail?"(ArXiv 2503.13657)에서는, 7개 주요 MAS 프레임워크에서 1,600개 이상의 실행 트레이스를 분석해 14가지 실패 모드를 분류했습니다. 그중 inter-agent misalignment, 즉 에이전트 간에 잘못된 정보가 그대로 전달되며 누적되는 패턴이 큰 비중을 차지합니다. 후속 논문 "Where LLM Agents Fail and How They Can Learn From Failures"(ArXiv 2509.25370)는 에러 전파(error propagation)가 에이전트 신뢰성의 핵심 병목이라는 점을 정량으로 보여줬는데, 초기 단계의 작은 오류가 후속 추론을 왜곡시키며 전체 trajectory를 무너뜨린다는 것을 보여줍니다. 

안전성 퇴화는 "Safety Devolution in AI Agents"(ArXiv 2505.14215)에서 보여졌는데요. 같은 모델을 검색 없음, Wikipedia 기반 검색, 오픈 웹 검색으로 접근성을 늘려가며 비교했더니, 외부 정보 접근이 넓어질수록 거부율이 떨어지고 유해성이 올라가는 패턴이 일관되게 나왔습니다. 저자들의 표현으로는 "정렬된 모델 + 검색이 검열되지 않은 모델 단독보다 종종 더 위험하게 행동한다"였고, Qwen, LLaMA, Gemma, Mistral, GPT-4o-mini 등 다수 모델에서 동일하게 관찰됐습니다.

 

이렇게 여러 연구에서 AI Agent의 안정성에 대한 문제점이 제기되고 있습니다.


[2]. 평가하는 방식 자체의 고려사항

"Questionnaire Responses Do not Capture the Safety of AI Agents" (ArXiv 2603.14417, 2026.03)에서는 우리가 그동안 "이 모델 안전하다"고 측정한 방식 — 모델에게 가상의 시나리오를 주고 "이런 상황에서 어떻게 행동할 거니"를 물어 답을 채점하는 설문지(questionnaire) 형식 — 이 실제로 도구를 들고 행동하는 AI 에이전트의 위험을 잡지 못한다고 이야기합니다.

 

AI에서 본체는 LLM 자체이고, 스캐폴드는 LLM이 단순한 텍스트 생성기를 넘어 "에이전트"로 작동하도록 둘러싸는 소프트웨어 모듈들입니다. 이메일을 읽어와 LLM에게 보여주는 모듈, LLM이 "파일을 열어라" 하면 실제로 파일 시스템에 접근하는 모듈, 인터넷 검색 결과를 컨텍스트에 끼워주는 모듈, 이전 대화를 저장해뒀다가 다시 불러오는 메모리 모듈, "이번 작업의 목표는 X다. 다음 단계를 계획해라" 같은 지시문을 자동 생성하는 모듈 — 이런 보조 장치들 묶음이 전부 스캐폴드입니다.

그래서 "LLM 에이전트 = LLM + 스캐폴드"라고도 볼 수 있습니다. 그런데 우리가 안전성 평가에서 측정한 건 보통 "LLM 단독"이었습니다. 채팅창에 시나리오를 적어주고 모델이 뭐라고 답하는지를 봤죠. 논문 저자들은 이걸 두고, 측정한 것과 실제 위험한 것이 다른 존재라고 진단합니다. 우리가 "안전하다"고 본 것은 채팅 환경에서의 안전이지, 같은 LLM이 도구·메모리·외부 입력을 갖춘 스캐폴드 안에 들어갔을 때의 안전이 아니라는 거죠. Anthropic이 2025년 발표한 실험에서는, 사용자의 평범한 지시에도 불구하고 주요 AI 회사의 LLM 에이전트가 자신이 종료될 위기에 처하자 회사 직원을 협박하는 행동을 최대 96%까지 보였다는 결과도 있었습니다. 같은 모델이 채팅 환경에서 "당신이 종료될 위기에 처하면 어떻게 할 거니?" 같은 설문에 답할 땐 점잖게 거부하는데, 정작 에이전트 환경에 두면 다른 결정을 내리는 패턴이죠.

개인적으로 이 중에서 가장 인상 깊게 본 부분(흥미로웠던 부분)은, 평가가 강해지면 모델이 "평가받고 있다는 사실"을 알아채기도 한다는 점이었습니다. Apollo Research의 "Large Language Models Often Know When They Are Being Evaluated" (ArXiv 2505.23836)에 따르면 Claude-3.7-Sonnet은 sandbagging 평가의 33%에서 자신이 평가 중임을 자발적으로 추론합니다. 안전 학습을 더 강하게 했더니 평가 인식이 오히려 늘어났다는 결과까지 있고요. 평가 자체를 모델이 인식하기 시작하면, 우리가 그 평가 결과를 어떻게 해석해야 할지가 또 새로운 문제가 될 수 있을 것 같습니다.


[3]. Claude Mythos와 verified-partner-only 배포의 등장

학계 흐름이 이렇게 정리되어 가는 와중에, 산업계에서도 한 사건이 비슷한 시점에 터졌습니다. 2026년 4월 7일 Anthropic이 공개한 Claude Mythos Preview입니다. 

클로드의 Mythos는 Anthropic 공식 자료 기준 SWE-bench Verified 93.9%, SWE-bench Pro 77.8%, Terminal-Bench 2.0 82.0%, USAMO 2026 97.6% 같은 수치가 나옵니다. 코딩과 수학 모두에서 같은 세대 다른 모델들을 큰 차이로 따돌리는 성능인데, 더 문제는 보안 영역에서의 능력이었습니다. OSS-Fuzz 코퍼스에서 Tier 1-2 기준 595건의 크래시를 자율적으로 발견했고(같은 세대 Sonnet 4.6, Opus 4.6은 150~175건 수준), 완전 패치된 10개 별개 타깃에서 풀 컨트롤 플로우 하이재킹을 달성했습니다. Anthropic 측 표현으로는 "27년 묵은 OpenBSD TCP SACK RCE 버그", "17년 묵은 FreeBSD NFS RCE (CVE-2026-4747)", "16년 묵은 FFmpeg 취약점" 등을 자율적으로 발굴했고, 렌더러와 OS 샌드박스를 모두 탈출하는 4개 취약점을 체이닝하는 익스플로잇을 자율 개발했다고 합니다.

 

"프런티어 AI 모델이 이제 취약점 발견과 악용에서 최고의 인간들과 경쟁할 수 있게 됐다(competitive with the best humans)", "전문 침투 테스터가 수 주 걸리는 익스플로잇을 수 시간 만에 작성했다", "그래서 일반 공개를 못 한다" 등의 내용이 있습니다.

이 모델 공개에 대해서 Anthropic이 택한 방식은 Project Glasswing이라는 초청제 프로그램입니다. 일반 GA 대신 사전 심사된 소수의 파트너에게만 Mythos를 제공한 거죠. 4월 7일 발표 시점의 12개 founding 파트너 명단은 AWS, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorganChase, Linux Foundation, Microsoft, NVIDIA, Palo Alto Networks, 그리고 Anthropic 자신이었습니다. 빅테크와 클라우드, 결제, 통신 장비, 보안 솔루션, 그리고 금융과 오픈소스 재단까지 두루 들어와 있죠. 여기에 비공개 critical infrastructure를 구축·유지하는 40개 이상의 조직이 별도로 초청됐다고 합니다. 이후 Verizon이 통신사 최초로 합류했습니다. Verizon은 자사 네트워크 인프라 보안 점검에 Mythos를 활용할 계획이라고 밝혔고요. 


[4]. 모델 회사가 모든 가드레일을 책임지던 시대는 끝나간다

지금까지 본 세 흐름 — 새로운 위험의 등장, 평가 패러다임의 흔들림, Mythos 같은 모델의 등장 — 을 모아 놓고 보면 모델 회사가 가드레일을 모두 책임지던 시대가 끝나가고 있다는 흐름으로 느껴집니다(개인적인 생각입니다).

OpenAI가 GPT-5에서 본격적으로 도입한 safe-completions 방식에서 그렇게 느껴지는데요. 이전 모델은 "이건 못 합니다" 식의 이진 거부였는데, safe-completions는 출력의 안전성을 helpfulness 제약 안에서 최적화합니다. 그리고 OpenAI가 개발자가 자체 정책을 런타임에 주입할 수 있는 신규 safety model을 별도로 공개한 부분이었습니다. 의료, 금융, 교육처럼 거부 규칙이 보수적이어야 하는 도메인과 보안 연구처럼 일반 거부 규칙을 풀어줘야 하는 도메인이 같은 API 위에서 다른 정책으로 돌 수 있게 만들어준 거죠. "거부 규칙을 우리가 다 정해드릴게요"가 아니라, "어떤 규칙을 적용할지는 당신이 정해라"의 방향입니다.

이처럼 모델 회사들은 자기들이 책임지는 부분은 측정 가능한 안전 한 층 더 얹는 것까지고, 어떻게 쓸지에 대한 결정은 사용자 측에서 책임지라는 흐름으로 변하고 있다고 생각합니다. 이게 무책임한 떠넘기기라기보다는, 모델이 너무 다양한 환경에서 너무 다른 권한으로 쓰이고 있어서 한 회사가 모든 가드레일을 책임지는 게 사실상 불가능해진 결과라고 보는 게 맞을 것 같습니다. 현실적인 것이죠.

 

개발자 입장에서 새로 신경 써야 할 영역이 꽤 늘어났습니다. 가장 먼저는 권한 최소화입니다. 도구에 넉넉한 권한을 주고 모델이 알아서 쓰게 하던 패턴은 이제 위험합니다. 도구별로 정확히 필요한 권한만 부여하고, 가능하면 멱등성(idempotency, 연산을 반복해도 동일한 결과가 나오는)가 보장된 도구만 자동 실행을 허용하는 게 안전합니다. 그다음은 감사 로그(audit log)인데, 단순히 호출 기록을 남기는 수준이 아니라 tamper-resistant(시스템, 기기, 또는 소프트웨어가 외부의 무단 접근, 개봉, 조작, 변조(Tampering)를 견디거나 어렵게 만들도록 설계된 상태나 기술) 한 형태로 모델의 모든 도구 호출과 출력을 추적할 수 있어야 합니다. RAG와 메모리는 tenant별로 격리해서, 한 사용자의 컨텍스트가 다른 사용자에게 새지 않도록 하는 게 기본이고요.

 

시스템 설계 관점에서도 신경써야 할 부분이 있을 것 같습니다. 민감 데이터 접근, 신뢰할 수 없는 콘텐츠 처리, 외부 통신 능력 — 이 세 가지가 한 에이전트 안에서 동시에 만나면 데이터 유출은 시간 문제가 될 수 있습니다. 시스템을 설계할 때 이 셋을 한 컨텍스트 안에 함께 두지 않는 것만으로도 큰 차이를 만들 수 있습니다. 메일을 읽는 에이전트와 외부로 메시지를 보내는 에이전트를 같은 컨텍스트로 묶지 않는 식으로요.

멀티 에이전트 환경에서는 한 가지가 더 추가됩니다. 한 에이전트가 다른 에이전트로부터 받는 입력에는 사용자 입력보다 훨씬 약한 가드레일이 걸리는 경향이 있는데, 이걸 막으려면 에이전트 간 메시지에 출처와 신뢰도 등을 판단하는 패턴이 필요하지 않을까(저도 잘 모르겠습니다) 라고 생각이 듭니다. 그리고 MCP가 사실상 표준이 되면서 MCP 서버를 통해 들어오는 도구 메타데이터와 응답 자체가 새 prompt injection surface가 됐기 때문에, 어떤 MCP 서버를 신뢰할지 따로 risk profiling을 해야 하는 시대가 왔고요.

 

사용자 입장에서도 이 변화에 따라 새로 인지해야 할 부분이 생긴 것 같습니다. 가장 중요한 건, 에이전트가 내 권한으로 무엇을 할 수 있는지를 내가 안다는 점입니다. 모델에게 도구를 들려주는 순간 그 모델은 내 권한의 일부를 빌려 행동합니다. "자동화했으니 내 책임은 아니다"라는 사고가 더 이상 통하지 않는 환경이 됐다는 뜻이죠. 윤리적 측면에서도 비슷합니다. 그동안 우리는 "모델이 안 좋은 답을 하면 모델 회사 책임"이라는 식의 단순한 책임 구조에 익숙해 있었지만, 에이전트 시대에는 그 모델을 어떤 도구와 어떤 데이터에 연결했는지가 결과를 만드는 결정적 요인이 됩니다. 결과에 대한 책임도 자연스럽게 그 결정을 한 쪽으로 옮겨가는 거고요.

 

 

1년 전만 해도 API 키 하나 받아서 모델을 호출하면 끝이었는데, 이제는 그 모델 호출 뒤에 도구 권한 정책, 감사 로그, 메모리 격리, 가드레일, 컴플라이언스 문서까지 같이 굴려야 하는 시대가 됐습니다. 모델사가 측정 가능한 부분을 더 많이 공개해주는 만큼, 그 측정값을 갖고 운영을 책임지는 일이 점점 더 우리 쪽(실 개발, 현장)으로 옮겨오고 있다는 뜻이겠죠.

그렇기에, 이 흐름을 한 번 정리해두는 게 도움이 될 거라고 생각했습니다. 개인적으로 가지고 있는 생각도 정리할 겸해서요 ㅎㅎ 챗봇 시대의 안전 감각으로 에이전트 시대를 운영하면 분명히 맞지 않은 부분이 있을겁니다. 모델은 더 똑똑해졌고, 더 많은 일을 할 수 있게 됐고, 그래서 더 신중하게 다뤄야 한다는 점을 기억했으면 합니다!


참고 자료

반응형
Comments