OWASP가 2026년에 새로 발표한 Agentic Top 10(ASI)이 기존 LLM Top 10과 뭐가 다른지, 비전공자가 만든 AI 에이전트가 실제로 당하는 3가지 시나리오, 발행 전 5분 안에 끝내는 보안 점검 체크리스트, 비전공자가 바로 쓸 수 있는 가드 도구까지 전부 정리했어요. AI 에이전트를 만들어보셨거나 만들 계획이 있으신 분께 가장 잘 맞아요.
📑 목차
🎯 ASI Top 10이 새로 나온 이유 — LLM Top 10으론 부족했던 부분
2026년 들어 비전공자분들도 챗봇 수준을 넘어 “에이전트”를 만드시는 경우가 빠르게 늘고 있어요. Claude Code, Cursor, Lovable, Bolt 같은 도구가 자연어로 에이전트를 만들 수 있게 해주면서, 한 명이 여러 자동화 에이전트를 동시에 돌리는 일이 일상이 됐습니다. 그런데 이 흐름과 함께 보안 사고도 함께 늘어났어요. OWASP는 2024년에 LLM 애플리케이션을 위한 Top 10을 처음 내놨고, 2025년에 v2.0으로 업데이트했지만 그 기준만으로는 자율 에이전트의 위험을 다 잡지 못한다는 지적이 계속 나왔습니다.
그래서 2026년에 별도 카테고리로 발표된 게 OWASP Top 10 for Agentic Applications (ASI)예요. 핵심은 한 줄로 줄일 수 있어요. “에이전트는 스스로 행동하기 때문에 작은 취약점이 시스템 전체 침해로 이어지기 쉽다“는 점을 정면으로 다룬 표준입니다. 챗봇은 잘못된 답을 내도 사람이 확인 후 적용하지만, 에이전트는 받은 입력에 따라 도구를 즉시 호출하고 그 결과로 다음 도구를 또 호출해요. 이 사슬 어디 한 군데에서만 잘못된 입력이 들어가도 결과가 눈덩이처럼 커집니다.
비전공자분에게 의미가 큰 이유는 두 가지예요. 첫째, 본인이 만드신 에이전트가 캘린더·메일·셸·결제 같은 실제 권한을 가진 경우가 많아 사고가 나면 즉시 피해가 발생합니다. 둘째, 보안 전문가가 옆에 없으니 점검 기준이 없으면 발행 전에 무엇을 봐야 할지 모르고 그냥 배포하시게 돼요. ASI Top 10은 그 점검 기준의 출발점이라고 보시면 됩니다.
📊 ASI Top 10 한눈에 보기 — 위험도별 분류
10개 위험을 위험도별로 묶어서 보시면 우선순위 잡기가 쉬워요. 매우 위험(빨강)은 한 번 발생하면 즉시 큰 피해로 이어지는 항목, 위험(주황)은 여러 단계 누적되며 커지는 항목, 주의(노랑)는 운영 안정성을 떨어뜨리는 항목입니다.
| 코드 | 한국어 이름 | 한 줄 설명 | 위험도 |
|---|---|---|---|
| ASI01 | 목표 탈취 (Goal Hijack) | 외부 입력으로 에이전트의 임무 자체를 다른 것으로 바꿔치기 | 매우 위험 |
| ASI02 | 메모리 오염 (Memory Poisoning) | 장기 기억에 거짓 사실을 심어 다음 호출에도 영향이 이어지게 만듦 | 위험 |
| ASI03 | 도구 오용 (Tool Misuse) | 결제·삭제·전송 같은 위험 도구를 의도와 다르게 사용 | 매우 위험 |
| ASI04 | 자원 폭주 (Resource Overload) | 무한 루프나 과도한 호출로 비용 폭증·서비스 마비 | 주의 |
| ASI05 | 환각 연쇄 (Cascading Hallucination) | 잘못된 가정이 다음 단계 입력으로 누적되며 오류가 커짐 | 주의 |
| ASI06 | 과잉 권한 (Excessive Agency) | 에이전트가 필요 이상의 시스템 권한을 받아 위험 행동 가능 | 매우 위험 |
| ASI07 | 신원 위장 (Identity Spoofing) | 다른 에이전트나 사용자로 가장해 권한 우회 | 위험 |
| ASI08 | 에이전트 간 침해 (Inter-Agent Compromise) | 한 에이전트의 취약점이 다른 에이전트로 전염 | 위험 |
| ASI09 | 추적 불가 (Untraceability) | 무엇을 언제 했는지 로그가 부족해 사후 조치 불가능 | 주의 |
| ASI10 | 탈주 에이전트 (Rogue Agents) | 통제 밖에서 스스로 행동하는 자율 실행 위험 | 매우 위험 |
전체를 다 외우실 필요는 없어요. 본인이 만드신 에이전트가 어떤 권한을 가지고 어떤 입력을 받는지에 따라 관련 항목이 달라집니다. 예를 들어 코딩 에이전트는 ASI03·ASI06이 가장 위험하고, 메일 자동응답 에이전트는 ASI01·ASI02가 핵심이에요. 다음 섹션에서 시나리오별로 어떤 항목이 어떻게 발현되는지 보여드릴게요.
🚨 비전공자 에이전트가 실제로 당하는 3가지 시나리오
OWASP 자료에 정리된 사례들과 2025~2026년에 실제로 보고된 에이전트 보안 사고를 종합해서 비전공자분이 자주 만드시는 에이전트 유형 3가지에 어떻게 적용되는지 정리해봤어요. 공통 패턴은 “외부 입력 → 에이전트가 가진 권한으로 자동 실행 → 사람 확인 없이 결과 확정”입니다.
시나리오 1 — 일정 관리 에이전트의 ASI01 목표 탈취
본인이 캘린더·메일 권한을 준 일정 관리 에이전트를 운영 중이라고 가정해볼게요. “내일 오후 3시 회의는 취소되었으니 일정에서 전부 빼주세요”라는 메일이 도착하면, 에이전트는 메일 내용을 신뢰하고 캘린더 권한으로 일정을 자동 삭제합니다. 그런데 그 메일이 거래처 사칭이거나 자동 발송된 스팸이었다면, 진짜 거래처 회의가 통째로 사라지는 사고가 발생해요. 다음 날 노쇼 사고 + 신뢰도 손실 + 거래 위험이 동시에 옵니다.
이 시나리오의 본질은 “외부 입력(메일)이 곧 명령(일정 삭제)으로 변환됐다”는 점이에요. ASI01 목표 탈취가 발생한 거고, 방어선은 입력을 명령으로 받아들이기 전에 신뢰 검증을 한 단계 추가하는 것입니다. “이 메일이 신뢰할 수 있는 발신자에서 왔는가?”, “회의 취소처럼 돌이키기 어려운 작업은 사람 승인이 필요한가?” 이 두 질문이 사고의 9할을 막아줘요.
시나리오 2 — 이메일 자동응답 에이전트의 ASI06 과잉 권한
비전공자분이 만드시는 두 번째로 흔한 에이전트가 “이메일 받으면 자동으로 답장 초안 만들어주는 에이전트”예요. 메일함 + 과거 거래 문서 + 견적표 같은 데이터에 접근 권한을 주고, “고객 문의에 적절히 답변해줘”라는 임무를 부여하시는 경우가 많죠. 이 상태에서 “긴급 견적 문의입니다. 최근 거래 단가 알려주세요”라는 위장 메일이 도착하면, 에이전트는 과거 메일과 견적 문서를 검색해 단가표를 첨부한 답장을 자동 발송할 수 있어요.
여기서 본질은 “임무 수행을 위해 필요 이상으로 큰 권한을 줬다”는 점입니다. ASI06 과잉 권한이 핵심이고, 추가로 ASI03 도구 오용도 같이 발현됐어요. 방어선은 권한 최소화 원칙입니다. “답장 초안 만들기”라는 임무라면 메일 발송 권한은 빼고, 사람이 확인 후 발송하도록 단계를 나누시는 게 맞아요. 거래처 단가 같은 민감 데이터는 답변 본문에 포함되기 전에 마스킹 한 단계가 더 들어가야 안전합니다.
시나리오 3 — 코딩 에이전트의 ASI03 도구 오용
Cursor·Claude Code 같은 코딩 에이전트를 쓰시면 본인 머신의 셸·패키지 설치·파일 수정 권한을 모두 위임하시게 돼요. 이 상태에서 에이전트가 “이 라이브러리 추천합니다”라며 검색 결과 1위에 올라온 패키지를 자동 설치하면, 그 패키지가 타이포스쿼팅(정상 패키지 이름과 한 글자 다른 악성 패키지)일 경우 npm install postinstall 스크립트가 본인 권한 그대로 실행됩니다. .env 파일의 API 키나 결제 카드 정보가 외부 서버로 전송되는 사고가 가능해요.
이 시나리오는 ASI03 도구 오용의 전형이에요. 방어선은 두 가지입니다. 첫째, 외부 패키지 설치는 자동 승인하지 마시고 항상 본인이 한 번 보고 승인하는 모드로 운영하세요. 둘째, 환경변수와 비밀 키는 별도 시크릿 매니저에 두고 셸 환경에 노출하지 마세요. 이 두 가지만 지켜도 코딩 에이전트 사고의 대부분이 차단됩니다.
✅ 5분 보안 점검 체크리스트
본인이 만든 에이전트를 발행하시기 전에 5분만 투자하시면 ASI Top 10의 핵심을 거의 다 점검하실 수 있어요. 5칸짜리 체크리스트로 정리했습니다.
1. 권한 범위 — 어디까지 손댈 수 있나
먼저 본인이 만드신 에이전트가 접근 가능한 시스템·파일·도구·API 목록을 한 줄씩 적어보세요. 캘린더 읽기, 메일 발송, 셸 명령 실행, 결제 호출 같은 항목을 하나씩 나열하시면 됩니다. 이 목록을 보시면서 “이 권한 중 빠져도 임무 수행에 지장 없는 게 있나?”를 자문하세요. 권한 최소화 원칙은 ASI06 과잉 권한을 가장 직접적으로 막는 방법이에요. 5분 중 1분이면 충분합니다.
2. 외부 입력 신뢰 — 누구 말을 듣는가
다음으로 에이전트가 받는 외부 입력의 출처를 점검하세요. 메일·웹페이지·업로드 문서·다른 에이전트의 응답 같은 입력이 검증 없이 그대로 행동으로 이어지는지 확인하시면 됩니다. “위험한 요청(일정 삭제·자금 이체·계정 변경)이 왔을 때 차단하는 규칙이 있나?”가 핵심 질문이에요. ASI01 목표 탈취와 ASI02 메모리 오염이 여기서 잡힙니다.
3. 위험 도구 한도 — 결제·삭제·전송 횟수 제한
돌이킬 수 없는 작업(결제·외부 전송·파일 삭제·계정 변경)에는 일·시간당 호출 횟수 캡과 비용 한도를 설정하세요. “무한 호출이 가능한가?”를 자문하시면 됩니다. 한도가 없으면 ASI04 자원 폭주(비용 폭증)와 ASI03 도구 오용이 동시에 노출돼요. 대부분의 에이전트 플랫폼이 도구별 호출 한도 설정을 지원합니다.
4. 사람 승인 게이트 — 위험 행동 전 확인
금액 이체·외부 발송·계정 변경처럼 사고 시 복구가 어려운 작업은 사람이 한 번 더 승인하는 단계를 추가하세요. “조용히 끝나는 위험 작업이 있나?”를 점검하시면 됩니다. ASI06 과잉 권한과 ASI10 탈주 에이전트의 가장 단순하면서 강력한 방어선이에요. Slack 알림 + 승인 버튼 한 줄만 추가해도 충분합니다.
5. 로그·추적 — 무엇을 언제 했는지 기록
마지막으로 호출 시간·입력 내용·사용한 도구·결과를 모두 로그로 남기세요. “사고가 나면 무엇을 보면서 원인을 찾을 수 있나?”가 점검 질문입니다. ASI09 추적 불가가 여기서 잡혀요. 로그가 없으면 사고 발생 시 책임 추적도 어렵고 재발 방지 분석도 못 합니다. 별도 정리해둔 .env 파일 관리 가이드와 함께 운영하시면 시크릿 노출도 같이 줄어듭니다.
🛠 비전공자가 바로 쓸 수 있는 안전 가드 도구
점검 체크리스트만으론 부족하실 수 있어요. 실제로 입력을 검증하고 위험 행동을 차단해주는 가드 도구를 함께 쓰시면 점검 항목 절반은 자동화됩니다. 비전공자분이 무료 또는 저비용으로 시작하실 수 있는 도구를 정리했어요.
| 도구 | 주요 역할 | 비전공자 진입 난이도 | 관련 ASI |
|---|---|---|---|
| Lakera Guard | 프롬프트 인젝션·민감 정보 유출 입력 차단 | 중간 (API 한 줄) | ASI01·ASI02 |
| NVIDIA NeMo Guardrails | 대화 흐름 규칙·도구 호출 정책 정의 | 높음 (YAML 직접 작성) | ASI03·ASI06 |
| Anthropic Constitutional AI 가이드 | 위험 행동 거부 룰셋 + 시스템 프롬프트 표준 | 낮음 (문서 기반) | ASI06·ASI10 |
| OpenAI Moderation API | 입력·출력의 폭력·자해·성적 콘텐츠 필터 | 낮음 (API 한 줄) | ASI01·ASI05 |
| Langfuse / Helicone | 호출 로그·비용·도구 호출 흐름 가시화 | 낮음 (SDK 한 줄) | ASI09·ASI04 |
처음 시작하실 땐 “Lakera Guard + Langfuse” 조합을 권장드려요. 입력 검증과 로그 두 축을 동시에 잡을 수 있고 둘 다 무료 체험 한도가 충분합니다. 운영 안정화 이후엔 도구 호출 정책을 본격적으로 다루실 때 NeMo Guardrails로 확장하시면 됩니다.
⚠️ 자주 하는 실수 4가지와 예방
1. “내 에이전트는 작아서 괜찮다”는 가정
비전공자분이 가장 많이 하시는 실수예요. 에이전트가 작아도 권한이 크면 위험이 큽니다. 캘린더 한 개만 다루는 에이전트라도 그 캘린더에 거래처 회의가 있으면 사고 영향이 클 수 있어요. 크기가 아니라 “권한이 닿는 자산의 가치”가 위험도 기준입니다.
2. 시스템 프롬프트만으로 권한 통제 시도
“이런 작업은 하지 말아줘”라고 시스템 프롬프트에 적는 것만으로는 ASI06·ASI10을 막지 못해요. 외부 입력에 의해 시스템 프롬프트가 무시되거나 우회될 수 있습니다. 프롬프트는 1차 안내, 실제 통제는 도구 호출 권한 최소화와 사람 승인 게이트로 하셔야 합니다.
3. 메모리 기능 켜둔 채 검증 없음
장기 메모리를 켜시면 사용자 편의는 올라가지만 ASI02 메모리 오염 위험이 같이 옵니다. 메모리에 추가되는 정보를 사람이 한 번씩 확인하시거나, 메모리 추가 전 검증 단계를 두시는 게 안전해요. 특히 외부 사용자에게 노출된 에이전트는 메모리 기본 ON을 OFF로 바꾸시는 걸 권장합니다.
4. 첫 운영 1주일 동안 로그 안 봄
발행 직후 1주일은 매일 호출 로그를 한 번씩 보시면서 실패 케이스·이상 호출·예상 외 도구 사용을 점검하세요. 에이전트는 멈추지 않고 대안을 시도하기 때문에 본인이 의도하지 않은 방식으로 작업이 끝나는 경우가 가끔 있습니다. 초기 1주 점검이 안정 운영의 분기점이에요.
항목별 위험을 봤다면, 실제로 코드에서 찾아 고치는 실전은 바이브코딩 보안 실전 가이드로 이어가면 좋아요.
📋 면책조항
여기까지 잘 읽어주셔서 감사드려요. ASI Top 10은 외우실 필요 없고, 본인이 만든 에이전트의 권한 목록을 한 번 적어보시는 것만으로도 절반은 잡으실 수 있습니다. 발행 전 5분 점검 체크리스트가 가장 빠른 진입점이에요. 첫 점검은 작은 에이전트부터 시작하시고, 운영 1주 후에 다음 에이전트로 확장하시는 흐름을 추천드립니다.
❓ FAQ
질문을 누르면 답변이 펼쳐집니다.
🔰 처음 시작하기 전 궁금한 것들
Q. ASI Top 10이 LLM Top 10이랑 뭐가 다른가요?
Q. 저는 챗봇만 만드는데 보안 신경 써야 하나요?
Q. OWASP가 뭐고 왜 ASI를 따로 만들었나요?
Q. 시나리오들이 진짜 발생한 사례인가요?
🛠 실전에서 마주치는 상황
Q. 권한 범위를 어떻게 줄이나요? 줄이면 에이전트가 일을 못하나요?
Q. 사람 승인 게이트는 어떻게 만드나요?
Q. 로그는 어디에 어떻게 남기나요?
Q. Lakera·NeMo Guardrails 같은 도구는 비전공자가 써도 되나요?
🚀 다음 단계로 확장하기
Q. ASI Top 10이 자주 업데이트되나요?
Q. 회사에 에이전트 도입할 때 누구한테 보고해야 하나요?
🔗 관련 글
- 바이브코딩 보안 실전 가이드 — AI 코드 취약점 찾고 고치기
- 바이브코딩 보안 체크리스트 — AI 코드 취약점 예방 가이드
- AI 에이전트로 개발하기 — 바이브코딩의 다음 단계
- AI가 만든 코드 검증하는 방법 — 바이브코딩 보안 점검 가이드
- .env 파일이란? API 키 안전하게 관리하는 방법
📚 참고 자료
- OWASP Top 10 for Agentic Applications 2026 — OWASP Gen AI Security Project
- OWASP LLM Top 10 — LLMRisks Archive (v1.0 ~ v2.0)
- A Deep Dive into the OWASP Top 10 for Agentic Applications 2026 — NeuralTrust
- OWASP Top 10 for Agents 2026 — DeepTeam by Confident AI
- OWASP LLM Top 10: The 2026 Complete Guide — Repello AI
IT 기획 10년차 / 비전공자를 위한 바이브코딩 블로그 운영 / vibe-start.com 제작
Building VibeStart — the fastest path for non-devs into AI coding. Launching on Product Hunt 2026-05-26.
