TL; DR #
GenAI 보안은 조직이 구축하는 생성형 AI와 소프트웨어에 내장된 생성형 AI(모델, 프롬프트, 에이전트, 스킬 파일, MCP 서버 및 AI 코딩 도우미 등 개발 수명주기 내에 있는 모든 요소)를 보호하는 활동입니다. GenAI 보안은 세 단계로 이루어집니다. 첫째, 어떤 AI 자산이 존재하는지 파악하고, 둘째, 해당 자산에 특정한 위험을 감지하며, 셋째, 이러한 위험이 실제 운영 환경에 도달하기 전에 정책을 시행하는 것입니다.
GenAI 보안이란 무엇인가요? #
소프트웨어는 예전에는 사람이 작성하고 코드를 통해 공격받았습니다. 하지만 이 두 가지 상황 모두 3년도 채 안 되어 바뀌었습니다.
개발자들은 이제 어시스턴트가 작성한 코드를 배포하고, 에이전트가 제안한 종속성을 가져오고, 아무도 보안 아티팩트로 검토하지 않는 구성 파일을 통해 도구를 연결합니다. 동시에 애플리케이션 자체에는 모델과 검색 기능이 내장됩니다. pipeline신뢰할 수 없는 텍스트에서 지시를 받는 인공지능과 에이전트가 있습니다. 따라서 GenAI 보안이 무엇인지 묻는 팀은 사실상 두 가지 질문을 동시에 하는 것입니다. 개발자가 사용하는 AI를 어떻게 보호할 것인가, 그리고 제품에 포함된 AI를 어떻게 보호할 것인가입니다.
GenAI 보안은 이 두 가지 질문에 모두 답합니다. 이는 소프트웨어 개발 수명주기 내의 생성형 및 에이전트형 AI 구성 요소 전반에 걸쳐 위험을 발견, 평가 및 제어하는 분야로, 모델과 MCP 서버부터 개발자 컴퓨터에 이르기까지 모든 영역을 포괄합니다.
중요한 차이점은 다음과 같습니다. 기존 스캐너는 취약한 기능을 찾습니다. GenAI 보안은 어시스턴트가 접근해서는 안 되는 곳에 접근하도록 은밀하게 지시하는 규칙 파일, 에이전트에게 필요한 권한보다 더 많은 권한이 부여된 경우, 또는 공격자가 제어하는 콘텐츠로 구성된 프롬프트를 찾습니다. 동일한 수명 주기를 거치지만, 실패 방식은 다릅니다. 애플리케이션 보안이란 무엇인가요?
GenAI 보안의 의미: 이 용어가 실제로 포괄하는 범위는 무엇인가? #
GenAI 보안의 의미는 벤더 자료에서 모호하게 표현되는 경우가 많으므로 경계를 명확히 하는 것이 중요합니다. 이 용어는 네 가지 유형의 노출을 포괄합니다.
- 개발자들이 사용하는 AI입니다. 코딩 어시스턴트, 에이전트, MCP 서버 및 이를 제어하는 구성 파일. 대부분의 조직은 일반적으로 구매 절차 없이 이러한 분야에 처음 접하게 됩니다.cis이온.
- 제품 내부에 탑재된 AI. 모델, 프롬프트, 검색 pipelines, 에이전트 배선 및 guardrails 그들을 제약하기 위한 것이었다.
- 인공지능이 생성하는 코드. 생성된 코드는 학습 데이터의 취약점 패턴을 담고 있습니다. 2025세대AI Code Security Report80개 작업에 걸쳐 100개 이상의 모델을 테스트한 결과, AI가 생성한 샘플의 45%가 기본적으로 OWASP Top 10 취약점을 포함하고 있는 것으로 나타났습니다.
- 공급망 AI가 정보를 수집합니다. 모델에서 제안하는 종속성에는 공격자가 등록하기 전까지는 존재하지 않는 패키지 이름이 포함됩니다.
이 책에서 다루지 않는 내용은 다음과 같습니다. 직접 학습시키지 않은 기초 모델의 내부 보안 및 고전적인 머신 러닝 방식. pipeline이는 아래에 설명된 인접 학문 분야에 속합니다.
GenAI 보안이 독립적인 학문 분야로 자리 잡게 된 이유 #
공격 대상이 더 이상 코드가 아니게 되었기 때문입니다. 스킬 파일, 규칙 파일, MCP 서버 구성 파일 등은 모두 일반 텍스트입니다. commit문서처럼 검토되고, 문서처럼 검토됩니다. 각각의 파일은 AI 비서에게 어떤 작업을 수행하도록 지시하고, 어떤 영역에 접근할 수 있도록 허용하는지를 조용히 결정합니다. 최근까지 이처럼 막강한 권한을 가진 파일이 없었기 때문에, 이러한 파일을 분석하는 정적 분석기는 개발되지 않았습니다.
이러한 경험은 거의 모든 사용자에게서 찾아볼 수 있습니다. GitHub의 2024년 개발자 설문조사에 따르면 97% 이상이 GitHub를 사용해 본 경험이 있는 것으로 나타났습니다. enterprise 응답자들은 직장에서 AI 코딩 도구를 사용한 경험이 있었지만, 공식적인 관리 체계는 크게 뒤처져 있었습니다. 대부분의 엔지니어링 조직은 이미 개발 수명주기에 생성형 AI를 활용하고 있지만, 그 활용 현황을 파악하고 있는 곳은 상대적으로 적습니다. AI 보안: 아무도 검토하지 않는 파일들.
GenAI 보안 작동 방식: 발견, 탐지, 적용 #
대부분의 프로그램은 중간 계층에서 시작하는데, 이는 보안 도구가 항상 탐지 기능을 주력 상품으로 내세워 왔기 때문입니다. 하지만 탐지 기능은 제대로 작동하는 경우가 드뭅니다. 자산 목록을 작성하지 않은 상태에서는 위험도를 평가할 수 없으며, 승인되지 않은 AI 도구를 사용하는 것이 예외가 아니라 일반적인 현상입니다. 따라서 자산 발견은 예비 단계가 아니라 나머지 두 단계를 위한 필수 조건입니다.
GenAI 보안이란 무엇이 아닌가요? 관련 용어 #
이 두 용어가 혼용되어 사용되면서 구매 관련 논의가 혼란스러워집니다.
- 애플리케이션 보안(AppSec) 애플리케이션의 코드, 종속성, 구성 등을 안전하게 보호합니다. pipelines, 런타임. GenAI 보안은 런타임을 대체하는 것이 아니라 확장합니다.
- AI 보안 이는 생성형이 아닌 기존 머신러닝 시스템을 포괄하는 더 넓은 개념입니다.
- AI-SPM 이는 AI 자산의 자세 관리, 즉 AI에 해당하는 개념입니다. ASPM이는 GenAI 보안의 구성 요소이지, 보안 자체의 동의어가 아닙니다.
- MLSecOps 모델에 초점을 맞춥니다 pipeline데이터 계보, 모델 출처, 배포 무결성.
- LLM 보안 일반적으로 모델과 그 프롬프트만을 의미하며, 에이전트, 도구 및 개발 환경을 제외한 더 좁은 범위입니다.
그것들은 경쟁 관계가 아니라 계층 구조입니다. 독립형 콘솔을 구매하여 GenAI 보안이 무엇인지 파악하려는 조직은 대개 아무도 우선순위를 정하지 않는 네 번째 문제 목록을 만들어내는 것과 같습니다. 유용한 버전은 AI 위험을 다른 모든 문제와 동일한 모델에 연결하여 우선순위가 지정된 하나의 목록이 작업을 주도하도록 합니다.
인공지능 보안의 의미를 형성하는 프레임워크: 위험의 의미 #
프레임워크를 평가할 때는 그것이 얼마나 최신처럼 들리는지가 아니라, 출판 여부를 기준으로 삼으세요.
규제에 대한 솔직한 관점은 협소합니다. EU AI법의 기술 문서 의무와 사이버 복원력법의 SBOM 의무 사항은 실질적인 증거 요건을 발생시키며, AI 인벤토리는 이러한 요건을 충족하는 데 도움이 됩니다. 어느 쪽도 AI-BOM을 명시하지 않았습니다. 규정에 AI-BOM이 필요하다고 주장하는 사람은 규정 본문이 나오기 전에 자기 주장을 펼치는 것입니다.
정의부터 프로그램까지 #
GenAI 보안에서 프롬프트 인젝션이 의미하는 바를 아는 것과 자신의 저장소에 프롬프트 인젝션 경로가 포함되어 있는지 여부를 아는 것은 다릅니다.
그 격차는 예측 가능한 순서로 좁혀집니다. 저장소 전반에 걸쳐 모든 AI 자산을 찾아보세요. pipeline보안 및 개발 환경(아무도 신고하지 않은 환경 포함)을 모두 평가합니다. 단순 심각도보다는 실제 공격 경로를 기준으로 점수를 매겨 대기열을 줄이고 신속하게 조치를 취할 수 있도록 합니다. 그런 다음 안전하지 않은 패키지, 모델 또는 도구가 실행될 수 있는 지점에서 정책을 시행합니다.
Xygeni는 이러한 과정을 하나의 플랫폼과 하나의 위험 모델로 통합하고, 기존에 관리하던 애플리케이션 분석 결과도 함께 제공합니다. 데모 예약 자신의 AI 인벤토리를 보려면
FAQ #
조직에서 사용하고 구축하는 생성형 AI를 보호하는 방법: 어떤 AI 자산이 존재하는지 파악하고, 해당 자산에 특정한 위험 요소를 찾아내며, 안전하지 않은 AI가 실행되기 전에 차단하는 것입니다.
프롬프트, 스킬 파일, 규칙 파일 및 MCP 구성은 문서가 아닌 보안 아티팩트로 검토되고, AI가 생성한 코드는 배포되기 전에 유효성 검사를 거친다는 것입니다. pipeline 이후가 아니라.
아니요. 대부분의 조직은 AI 기능을 출시하기 훨씬 전에 개발자를 통해 생성형 AI에 대한 경험을 쌓습니다.
AI 동작을 제어하는 구성 계층. SAST 엔진은 코드를 읽습니다. 어시스턴트에게 무엇을 써야 하는지 알려주는 규칙 파일이나 에이전트가 어떤 영역에 접근할 수 있는지 알려주는 MCP 서버 정의 파일을 읽지는 않습니다.
실제로 애플리케이션 보안을 담당하는 사람이 누구인지는 중요하지 않습니다. 자산은 저장소와 개발자 환경에 존재하므로 이를 별도의 기능으로 분리하면 위험을 줄이기보다는 오히려 두 번째 백로그가 발생하는 경향이 있습니다.
