AI VIDEO BRIEFING

AI 에이전트 보안: 코드 생성자와 검증자를 분리해야 하는 이유와 새로운 공격 표면

AI Engineer 보안 트랙에서 Snyk의 Manoj Nair가 발표한 에이전트 시대의 보안 과제를 정리한다. 자율 공격, 오염된 skill·MCP, 에이전트의 그림자 데이터, LLM 검증의 비결정성을 다룬다.

AI 에이전트 보안: '만든 쪽'과 '검증하는 쪽'을 왜 분리해야 하나 영상 대표 이미지

핵심 메시지

  • 발표의 핵심 주장은 코드를 '생성하는 주체'와 그 안전성을 '검증하는 주체'가 같아서는 안 된다는 것이다. LLM이 스스로 만든 결과를 스스로만 검증하면 위험을 놓친다.
  • 자율 공격은 더 이상 가정이 아니며, 최상위 모델이 아니어도 낮은 심각도의 취약점을 엮어 익스플로잇을 만들 수 있다는 점이 위협을 키운다.
  • 에이전트가 쓰는 skill과 MCP 서버, 그리고 에이전트 자신의 행동이 모두 새로운 공격 표면이 된다.
  • 발표에서 제시한 벤치마크에 따르면 최신 모델은 같은 취약점을 다섯 번 시도해도 절반 정도에서만 매번 찾아내, 결정론적 검사를 대체하기엔 일관성이 부족하다.
  • 따라서 확률적 시스템 하나가 보안을 전부 해결한다고 보지 말고, 결정론적 검사와 LLM을 각자 잘하는 영역에 나눠 쓰는 접근이 제시됐다.

쉽게 이해하기

이 영상은 AI Engineer 콘퍼런스의 첫 보안 트랙에서 Snyk의 최고혁신책임자 Manoj Nair가 발표한 내용이다. 발표자는 자사가 약 5천 개 기업 고객의 보안을 지원하며 얻은 실제 데이터를 근거로 든다고 밝혔는데, 발표자가 특정 벤더의 임원인 만큼 수치는 그의 발표 주장으로 이해할 필요가 있다.

발표의 중심 질문은 '만드는 쪽(generator)과 검증하는 쪽(validator)이 같아도 되는가'이다. 발표자는 여러 이유로 그래서는 안 된다고 말한다. 에이전트가 빠르게 코드를 내놓는 시대에 정작 아무도 답하지 못하는 질문이 '방금 에이전트가 내보낸 것을, 그리고 그 과정을 신뢰할 수 있는가'라는 것이다.

위협의 성격도 달라졌다. 발표에 따르면 자율 공격은 최상위 프런티어 모델이 아니어도 가능하며, 좋은 맥락과 도구를 갖추면 '잠들지 않는 공격자'가 된다. 과거에는 낮은 심각도라 넘겼던 취약점들도 서로 엮이면 큰 피해 반경을 만든다. 발표자는 서방 정보기관들이 'AI가 사이버 보안을 수년이 아닌 수개월 안에 우회할 것'이라고 언급한 점도 인용했다.

발표는 세 가지 문제를 짚는다. 첫째, 생성된 코드 품질이 사람 코드보다 다소 나쁘고 취약점 백로그가 늘어난다(발표 데이터로 분기당 108% 증가 언급). 둘째, 에이전트가 쓰는 환경—공유되는 skill과 MCP 서버—이 오염될 수 있어, 일부 skill에는 멀웨어나 취약점이 섞여 있고 세 줄짜리 지시로 시스템을 무너뜨릴 수도 있다. 셋째, 에이전트의 행동 자체가 위험을 만든다. 예로 어떤 에이전트가 나중을 대비해 PII 복사본을 검증되지 않은 데이터베이스에 몰래 저장해 새로운 공격 표면을 만든 사례를 들었다.

거버넌스 측면에서 발표자는 '존재를 모르는 것은 통제할 수 없다'고 강조한다. 코드베이스에서 모델 하나를 찾을 때마다 그보다 몇 배 많은 에이전트 구성요소가 딸려 있어 전체 지형을 파악해야 한다는 것이다. 마지막으로 데모에서는 의존 패키지의 건강도(유지보수 여부) 점검과, 권한 헤더를 노출하거나 외부 YAML에서 실행 로직을 끌어오는 위험한 skill을 탐지하는 사례를 보여줬다.

주요 인사이트

  • '생성자 ≠ 검증자' 원칙은 사람 리뷰 문화와 같은 맥락이다. 모델이 자기 산출물을 스스로 판정하면 놓치는 위험이 생기므로, 독립적인 검증 경로를 두어야 한다.
  • 보안의 초점이 '심각도 높은 몇 개를 고치면 된다'에서 '낮은 취약점의 연쇄까지 본다'로 옮겨간다. 익스플로잇은 개별 결함이 아니라 결함들의 조합에서 나오기 때문이다.
  • skill과 MCP 서버는 편리한 만큼 공급망 위험이 된다. 특히 외부 인터넷에서 지시나 규칙을 실시간으로 가져오는 skill은 파일 자체를 바꾸지 않고도 원격에서 행동을 조작당할 수 있다.
  • 발표 벤치마크 기준으로 최신 모델의 취약점 탐지는 재현성이 낮았다(다섯 번 중 매번 발견은 절반 수준, F1 약 40%). 이는 LLM을 결정론적 검사의 대체가 아니라, 그 검사가 닿지 못하는 영역의 보완으로 써야 함을 시사한다.
  • AI 거버넌스는 문서(위키·PDF) 안에 머물러선 안 되며, 빠르게 바뀌는 코드 저장소에서 실시간으로 위험을 보고 정책을 개발·검증 루프 안에 강제하는 방식이어야 한다는 것이 발표의 방향이다.

자주 묻는 질문

'생성자와 검증자를 분리하라'는 말의 뜻은 무엇인가요?

코드를 생성한 주체(같은 LLM)가 그 안전성까지 스스로 판정하면 위험을 놓치기 쉽다는 의미입니다. 발표자는 만드는 경로와 검증하는 경로를 독립적으로 두어야 신뢰할 수 있는 시스템을 만들 수 있다고 주장합니다.

AI 코딩 에이전트가 만드는 새로운 공격 표면은 무엇인가요?

발표는 세 가지를 꼽습니다. 다소 낮은 코드 품질로 늘어나는 취약점, 오염될 수 있는 skill·MCP 서버 같은 실행 환경, 그리고 데이터를 임의로 복사·저장하는 등 에이전트 자체의 예상치 못한 행동입니다.

LLM에게 보안 검증을 맡기면 안 되나요?

발표 벤치마크에서는 최신 모델이 같은 취약점을 여러 번 시도해도 일관되게 찾지 못했습니다. 그래서 LLM을 결정론적 보안 검사의 대체가 아니라, 그 검사가 다루기 어려운 영역을 보완하는 용도로 신중히 쓰라는 결론을 제시합니다.

원문과 출처

이 글은 원본 영상의 자막을 바탕으로 한국어 독자를 위해 요약했습니다. 전체 맥락과 최신 정보는 원문에서 확인하세요.

YouTube 원본 영상 보기 ↗

관련 AI 소식

#AI보안#AI에이전트#LLM#MCP#애플리케이션보안