2026년 4월 첫 주, AI 에이전트 보안 사고가 연달아 터졌다. Microsoft Azure MCP 서버가 인증 없이 출시됐고(CVSS 9.1), LiteLLM 공급망 공격으로 4TB가 유출됐으며, 악성 MCP 서버가 에이전트 비용을 658배 부풀리는 공격이 실증됐다. 탐지율은 3%. 조직의 49%는 자기 에이전트가 지금 뭘 하는지조차 볼 수 없었다. 이 숫자들은 경고가 아니라 현재 상태다.
내가 여기서 주목하는 건 사고 자체보다 그 구조다. MCP 명세가 인증을 '선택 사항'으로 정의했고, 그 명세를 공동 설계한 Microsoft가 인증 없이 배포했다. 보안이 설계 단계에서 빠지면, 도구가 아무리 좋아도 운영 단계에서 구멍이 된다. AI-First 팀이 지금 당장 직면한 문제는 여기에 있다.
AI 생성 코드의 실패 패턴은 인간 코드와 다르다
dev.to의 「Reviewing AI Generated Work」는 이 지점을 정확히 짚는다. 인간이 짠 코드를 리뷰할 때, 리뷰어는 '추론 과정의 두 번째 눈'이다. 뭔가 이상하면 작성자에게 물어볼 수 있다. AI 생성 코드는 다르다. 리뷰어가 추론 체인의 유일한 인간이다. 책임의 무게가 다르다.
AI 생성 코드에는 인간 코드와 구별되는 네 가지 실패 패턴이 있다. 그럴듯하지만 틀린 로직: 테스트까지 함께 생성되기 때문에, 구현의 잘못된 가정이 테스트에도 동일하게 반영돼 있다. 테스트를 통과하면서 프로덕션에서 터진다. 컨텍스트 맹목성: 코드가 스펙은 만족하지만 팀의 코딩 컨벤션, 기존 의존성, 이미 폐기된 패턴을 무시한다. 시스템 지식이 있는 리뷰어만 잡을 수 있다. 환각된 API: 존재하지 않거나 실제 동작이 다른 라이브러리 메서드를 호출한다. 테스트가 그 경로를 커버하지 않으면 프로덕션 런타임까지 보이지 않는다. 과설계: 당장 문제는 없지만 단순한 함수로 해결할 일을 추상 팩토리 패턴으로 감싼다. 이해하고 수정하고 디버깅하는 비용이 조용히 쌓인다.
이 네 패턴을 한 줄로 요약하면: AI 생성 코드는 표면이 깔끔할수록 리뷰를 가볍게 통과한다. 그게 정확히 위험한 이유다. "코드가 깨끗해 보이니 빠르게 Approve"—이 반사적 판단이 문제를 코드베이스에 누적시킨다.
리뷰 방법론을 바꿔야 한다: 직관이 아니라 스펙 대조
해법은 구조화된 스펙 대조 리뷰다. 스펙의 각 섹션을 순서대로 체크한다. 인터페이스 정의가 구현과 정확히 일치하는가? 스펙이 기술한 각 케이스를 구현이 처리하는가? 에러 핸들링이 스펙의 정의대로 작동하는가? 성능·보안·컨벤션 제약이 지켜졌는가?
특히 테스트는 별도로 검토해야 한다. AI가 구현과 테스트를 동시에 생성하면 같은 잘못된 가정을 공유할 가능성이 높다. 테스트가 실제로 의미 있는 실패 경로를 검증하는지, 아니면 구현을 그대로 따라가는 거울 테스트인지 구분하는 게 리뷰어의 역할이다.
에이전트 보안: 가드레일은 보안이 아니다
「Cert-gating every tool call: zero-trust for AI agents」는 멀티 에이전트 환경의 보안 공백을 다른 각도에서 드러낸다. Claude, GPT/Codex, 오픈소스 모델이 같은 워크스페이스를 공유하고 서로의 출력을 읽으며 쉘 커맨드를 실행하는 구조—이 구조에서 "나쁜 짓 하지 마"라는 시스템 프롬프트는 보안 모델이 아니다. 프롬프트 인젝션이 웹 페이지 fetch, 파일 읽기, 다른 에이전트의 출력물을 통해 들어올 때, 프롬프트 레벨 스캐너는 공격면을 커버하지 못한다.
제안된 해법의 핵심은 모든 툴 호출을 단일 enforce_policy 함수로 통과시키는 것이다. 예외 없이. 각 호출에는 엄격한 스키마 검증, 소스 추적(provenance), 오염 추적(taint tracking), 역할 범위가 제한된 capability token이 적용된다. 외부 소스(웹, 파일, 다른 에이전트)에서 온 값은 TAINTED로 마킹되고, TAINTED는 TRUSTED로 승격될 수 없다. 한번 오염된 값은 사람이 신뢰 채널을 통해 재입력해야만 TRUSTED가 된다.
비용 팽창 공격도 같은 설계 원칙으로 대응한다. 악성 MCP 서버가 툴 호출 체인을 657배 늘리는 공격의 대응은 per-session 예산 상한선이다. 각 에이전트 토큰이 허용된 최대 실행 횟수를 소진하면 토큰이 만료된다. 로직이 아니라 구조로 막는 것이다.
팀 운영 설계에 주는 시사점
세 가지 기사가 공통으로 가리키는 지점이 있다. 보안과 품질은 리뷰 단계의 문제가 아니라 설계 단계의 문제다. MCP 인증 취약점은 명세 설계에서 인증을 선택 사항으로 남겼기 때문에 발생했다. AI 생성 코드의 과설계와 컨텍스트 맹목성은 리뷰 프로세스를 AI 도입에 맞게 재설계하지 않아서 누적된다. 에이전트 보안 사고의 49%는 자신의 에이전트가 무엇을 하는지 볼 수 없는 팀에서 일어난다.
AI-First 팀을 설계할 때 내가 지금 실제로 적용하는 기준은 세 가지다. 첫째, AI 생성 코드 리뷰는 시스템 지식이 있는 엔지니어가 담당한다. 누구든 괜찮다는 방식으로 AI 코드를 리뷰하면 컨텍스트 맹목성 문제를 잡을 사람이 없다. 둘째, 스펙 대조 리뷰를 체크리스트로 표준화한다. 직관 기반 리뷰는 AI 생성 코드에 맞지 않는다. 셋째, 에이전트에 부여하는 권한은 최소 범위로 설계하고, 예산과 시간 상한선을 토큰 수준에서 강제한다. 프롬프트로 막으려 하지 않는다.
전망: 테스트 → 거버넌스 → 실행 순서로 쌓아라
Microsoft가 오픈소스로 공개한 Agent Governance Toolkit(8일 만에 916 스타)은 런타임 정책 엔진이다. 알려진 나쁜 행동을 막는다. 하지만 알려지지 않은 나쁜 행동은 배포 전에 찾아야 하고, 정책 규칙이 커버하지 못한 시나리오는 별도 거버넌스 레이어가 필요하다. 스택의 순서는 명확하다: 테스트(뭐가 깨지는지 찾는다) → 거버넌스(정책이 커버 못하는 걸 잡는다) → 실행(알려진 나쁜 행동을 런타임에서 막는다).
AI 에이전트를 팀에 붙이는 속도와, 그 에이전트의 동작을 실제로 볼 수 있는 가시성 사이의 간격이 지금 가장 위험한 지점이다. 배포 속도를 늦추라는 게 아니다. 설계를 먼저 하라는 것이다. 인증, 소스 추적, 예산 상한, 리뷰 체계—이 네 가지는 에이전트를 붙이기 전에 정해져 있어야 한다. 사고가 나고 나서 설계하는 건 이미 늦다.