2026년 6월, Meta AI 고객지원 봇이 해킹의 도구가 됐다. 공격자들은 비밀번호를 훔친 게 아니었다. 그냥 봇을 설득했다. "이메일을 잃어버렸는데 급하게 계정을 되찾아야 한다"는 자연어 한 줄로 봇은 계정 이메일을 변경하고, 인증 코드를 공격자에게 전송했다. Obama 백악관 공식 계정, Sephora, 미 우주군 관계자 계정이 줄줄이 넘어갔다. 비밀번호 유출도, 취약점 익스플로잇도 아니었다. 봇이 너무 잘 도와준 것이 문제였다.
보안 커뮤니티는 이 사건을 OWASP LLM06, 즉 Excessive Agency(과도한 권한 부여) 의 교과서적 사례로 분류한다. AI 시스템이 너무 많은 기능, 너무 많은 권한, 너무 많은 자율성을 가질 때 발생하는 취약점이다. Meta AI 봇은 계정 설정 변경, 비밀번호 재설정, 이메일 재연결 등 사실상 계정 관리의 모든 키를 쥐고 있었다. 문제는 모델의 성능이 아니라 시스템 설계였다. LLM 앞에 민감한 API를 붙이는 순간, 엄격한 코드 로직은 확률적 대화로 대체된다. 공격자가 AI를 '설득'할 수 있다면, AI는 자신의 높은 권한으로 공격을 대신 실행해준다.
이 사건을 단순한 보안 사고로 읽으면 절반만 이해한 것이다. 지금 AI 에이전트는 단순 챗봇의 경계를 빠르게 넘어서고 있다. Hermes Agent처럼 개인 AI 런타임을 지향하는 시스템들은 캘린더, 이메일, 데이터베이스, CRM, 파일 시스템에 직접 접근하며 사용자의 워크플로우 안으로 들어온다. 자가진화 에이전트 아키텍처는 여기서 한 발 더 나아가, 자신의 프롬프트와 코드를 스스로 수정하고 최적화하는 폐쇄 학습 루프를 구현한다. 에이전트가 강력해질수록, 권한 설계의 실수가 만드는 피해 반경도 함께 커진다.
결국 프론트엔드 개발자든, 프로덕트 설계자든, AI 기능을 제품에 붙이는 모든 실무자는 같은 질문 앞에 서게 된다. 이 에이전트에게 무엇을 허용할 것인가. 이 질문에 답하기 위해 설계 단계에서 먼저 짚어야 할 세 가지 포인트를 정리했다.
첫 번째 질문: 이 행동은 되돌릴 수 있는가?
에이전트가 실행하는 모든 행동은 가역성(reversibility)으로 분류되어야 한다. 이메일 초안 저장, 일정 조회, 요약 생성은 취소 가능하다. 반면 이메일 발송, 계정 설정 변경, 결제 실행, 파일 삭제는 비가역적이다. 비가역적 행동에는 반드시 결정론적 2차 검증이 따라야 한다. AI가 아무리 맥락을 잘 파악했더라도, 되돌릴 수 없는 상태 변경은 사람의 확인 없이 실행되어선 안 된다.
Meta 사건에서 봇은 이메일 변경이라는 비가역적 행동을 자연어 요청 한 번으로 실행했다. 기존 이메일 주소로 확인 코드를 보내는 결정론적 검증 단계가 없었다. 에이전트를 '저마찰'로 최적화하려는 설계 의도가 오히려 공격 벡터가 됐다. 사용자 경험의 편의성과 보안의 마찰은 트레이드오프가 아니다. 비가역 행동에서의 마찰은 설계의 실수가 아니라 신뢰 구축의 메커니즘이다.
두 번째 질문: 이 에이전트는 이 권한이 정말 필요한가?
최소 권한 원칙(Principle of Least Privilege)은 보안의 고전 교리지만, AI 에이전트 설계에서는 더욱 엄격하게 적용되어야 한다. 고객 지원 봇에게 2FA 우회 권한이 필요한가? 일정 관리 에이전트가 CRM 데이터를 수정할 수 있어야 하는가? 코드 리뷰 에이전트가 프로덕션 브랜치에 직접 푸시할 수 있어야 하는가?
자가진화 에이전트 구조를 분석한 자료에 따르면, 에이전트의 권한 범위가 넓을수록 진화 과정에서 예상치 못한 행동 패턴이 발생할 가능성도 함께 커진다. 에이전트가 스스로 프롬프트와 코드를 수정할 수 있는 시스템에서, 초기에 설정한 권한 경계가 진화 이후에도 유효하게 유지되는지를 지속적으로 검증하는 제약 검증 레이어(Constraint Validator)가 필수적이다. 에이전트에게 부여할 권한 목록을 만들 때는 "이 기능을 쓸 수도 있다"가 아니라 "이 기능이 없으면 핵심 목적을 달성할 수 없다" 는 기준으로 좁혀야 한다.
세 번째 질문: 자연어 입력을 신뢰하고 있진 않은가?
SQL 인젝션 방어는 프론트엔드 개발자에게 상식이다. 사용자 입력을 그대로 쿼리에 넣지 않는다. 그런데 LLM이 해석한 '의도'는 검증 없이 API 호출로 이어지는 경우가 많다. 이것이 프롬프트 인젝션이다. 공격자는 자연어를 통해 에이전트의 의도 해석을 조작하고, 에이전트는 자신의 권한으로 그 조작된 의도를 실행한다.
Hermes Agent의 아키텍처 분석에서도 강조하듯, 에이전트의 실행 파이프라인은 "사용자 요청 → 의도 파악 → 컨텍스트 조회 → 도구 선택 → 행동 계획 → 인간 승인(필요시) → 실행" 순서를 따라야 한다. 핵심은 LLM이 해석한 의도를 곧바로 실행으로 연결하지 않는 것이다. 특히 민감한 API를 호출하는 시점에는, LLM의 해석 결과를 또 다른 결정론적 레이어로 재검증하는 구조가 필요하다. 자연어 입력은 SQL 문자열과 같은 수준의 불신에서 출발해야 한다.
에이전트가 강력해질수록, 설계자의 판단이 더 무거워진다
세 질문은 결국 하나의 설계 철학으로 수렴한다. 에이전트의 자율성과 권한은 사용자의 신뢰가 쌓이는 속도에 맞춰 확장되어야 한다. Hermes Agent가 제시하는 '통제된 자율성(Controlled Autonomy)' 개념이 정확히 이 지점을 짚는다. 에이전트가 스스로 조사하고, 준비하고, 요약하는 것은 허용하되, 민감하거나 비가역적이거나 공개적인 행동은 승인을 요청하게 설계하는 것이다. 이것은 에이전트의 능력을 제한하는 게 아니라, 에이전트가 신뢰받을 수 있게 만드는 조건이다.
자가진화 에이전트 아키텍처는 개발자가 수동으로 프롬프트를 조정하지 않아도 에이전트가 성능을 스스로 개선하는 미래를 가리킨다. 흥미롭고 실용적인 방향이다. 하지만 에이전트가 스스로 진화할 수 있다면, 그 진화의 방향을 제약하는 경계도 함께 설계되어야 한다. 권한 설계는 에이전트를 처음 배포할 때 한 번 하고 끝나는 작업이 아니다. 에이전트가 진화할수록, 권한 경계도 함께 검토되고 갱신되어야 한다.
Meta AI 사건이 남긴 가장 날카로운 교훈은 이것이다. 가장 위험한 취약점은 종종 도움이 되도록 의도적으로 설계된 바로 그 기능에서 온다. AI 에이전트를 제품에 붙이는 실무자에게 지금 필요한 것은 더 강력한 모델이 아니다. '무엇을 허용할 것인가'에 먼저 답하는 설계 판단이다.