매일 아침 개발팀은 깃허브 코파일럿(GitHub Copilot, AI 코드 자동 완성 도구)을 설치하고, 데이터 분석가는 새 LLM(거대 언어 모델) 도구로 보고서를 작성한다. 제품팀은 서드파티 모델을 기능 브랜치에 조용히 넣는다. 보안팀이 이 사실을 알게 될 때쯤이면, AI는 이미 프로덕션에서 실제 데이터를 처리하고, 실제 시스템에 접근하며, 실제 결정을 내리고 있다.

AI가 조직에 들어오는 속도와 거버넌스가 따라잡는 속도 사이의 간격이 바로 위험이 사는 곳이다. Mend가 발표한 실무 가이드 'AI 보안 거버넌스: 보안 및 개발팀을 위한 실용 프레임워크'는 이 간격을 메우기 위한 구체적인 방법을 제시한다. 이 프레임워크는 이미 AI 중심의 성숙한 보안 프로그램이 있다고 가정하지 않는다. 앱시크 리드, 엔지니어링 매니저, 데이터 과학자처럼 '어디서부터 시작해야 할지' 모르는 사람을 대상으로 설계됐다.

AI 자산 목록: 보이지 않으면 통제할 수 없다

프레임워크는 '볼 수 없는 것은 통제할 수 없다'는 전제에서 출발한다. AI 자산의 범위를 넓게 잡았다. AI 개발 도구(코파일럿, 코드이엄(Codeium, AI 코드 작성 도우미)), 서드파티 API(OpenAI, 구글 제미나이), 오픈소스 모델, SaaS 도구 내 AI 기능(노션 AI(Notion AI, 문서 내 AI 비서)), 내부 모델, 자율 AI 에이전트까지 모두 포함한다. '섀도 AI(Shadow AI, 보안 승인 없이 사용되는 AI 도구)' 문제를 해결하기 위해, 이 도구들을 찾는 과정이 처벌이 아닌 안전한 공개를 유도하는 방식이어야 한다고 강조한다.

위험 등급 시스템: 모든 AI를 동등하게 보지 않는다

모든 AI 배포를 동일한 위험으로 취급하지 않는다. 각 AI 자산은 다섯 가지 차원에서 1~3점으로 점수를 매긴다: 데이터 민감도, 결정 권한, 시스템 접근 권한, 외부 노출, 공급망 출처. 총점에 따라 필요한 거버넌스 수준이 결정된다. 중요한 점은 모델의 코드가 바뀌지 않아도 통합 방식이 바뀌면 위험 등급이 급격히 변할 수 있다는 것이다. 예를 들어 프로덕션 데이터베이스에 쓰기 접근 권한을 추가하거나 외부 사용자에게 노출하면 1등급에서 3등급으로 바뀔 수 있다.

접근 통제: 모델 자체보다 권한이 문제다

프레임워크는 대부분의 AI 보안 실패가 모델 자체의 결함이 아니라 접근 통제의 부실에서 비롯된다고 지적한다. 이에 대응하기 위해 AI 시스템에도 최소 권한 원칙을 적용할 것을 요구한다. API 키는 특정 리소스로만 범위를 좁히고, AI와 인간 사용자가 공유 자격 증명을 사용하지 말아야 하며, 쓰기 접근이 필요 없는 경우 읽기 전용을 기본값으로 설정해야 한다. 출력 통제도 동등하게 중요하다. AI가 생성한 콘텐츠가 민감 정보를 재구성하거나 추론해 데이터 유출로 이어질 수 있기 때문이다. 규제 대상 데이터 패턴(주민등록번호, 신용카드 번호, API 키)에 대한 출력 필터링이 필요하며, AI가 생성한 코드는 신뢰할 수 없는 입력으로 취급해 인간이 작성한 코드와 동일한 보안 스캔(SAST, SCA, 시크릿 스캐닝)을 받아야 한다.

AI 공급망 보안: AI-BOM이 필수다

서드파티 모델을 배포할 때는 그 모델을 훈련시킨 사람, 학습 데이터셋, 번들된 모든 의존성의 보안 태세를 함께 물려받는다. 프레임워크는 AI-BOM(AI 자재 명세서, 기존 SBOM을 모델 아티팩트, 데이터셋, 파인튜닝 입력, 추론 인프라로 확장한 개념)을 도입한다. 완전한 AI-BOM은 모델 이름, 버전, 출처, 학습 데이터 참조, 파인튜닝 데이터셋, 모델 실행에 필요한 모든 소프트웨어 의존성, 추론 인프라 구성 요소, 알려진 취약점과 그 해결 상태를 문서화한다. EU AI Act와 NIST AI RMF 같은 신규 규제가 공급망 투명성 요구 사항을 명시하고 있어, AI-BOM은 조직이 어떤 프레임워크를 따르든 규정 준수에 유용하다.

모니터링: 전통적인 방식으로는 AI 공격을 잡을 수 없다

전통적인 SIEM(보안 정보 및 이벤트 관리) 규칙, 네트워크 기반 이상 탐지, 엔드포인트 모니터링은 AI 시스템 특유의 실패 모드(프롬프트 인젝션, 모델 드리프트, 행동 조작, 대규모 탈옥 시도)를 잡아내지 못한다. 프레임워크는 AI 워크로드에 필요한 세 가지 모니터링 계층을 정의한다. 모델 계층에서는 사용자 입력의 프롬프트 인젝션 지표, 시스템 프롬프트 추출 시도, 출력 패턴이나 신뢰도 점수의 큰 변화를 감시한다. 애플리케이션 통합 계층에서는 AI 출력이 민감한 싱크(데이터베이스 쓰기, 외부 API 호출, 명령 실행)로 전달되는지, 기준 사용량에서 벗어난 대량 API 호출이 있는지 확인한다. 인프라 계층에서는 모델 아티팩트나 학습 데이터 저장소에 대한 무단 접근, 승인되지 않은 외부 AI API로의 예상치 못한 이그레스(데이터 유출)를 모니터링한다.

정책과 성숙도 모델: 4단계로 거버넌스 성숙도를 평가한다

프레임워크의 정책 섹션은 6가지 핵심 구성 요소를 정의하고, 4가지 역할에 책임을 할당한다. 가장 지속적인 집행은 도구를 통해 이뤄진다. CI/CD 파이프라인에서 SAST와 SCA 스캐닝을 사용하고, 승인되지 않은 AI 엔드포인트로의 이그레스를 차단하는 네트워크 통제를 구현하며, AI 서비스 계정에 최소 권한을 적용하는 IAM(신원 및 접근 관리) 정책을 적용하는 것이다.

프레임워크는 마지막으로 AI 보안 성숙도 모델을 4단계로 제시한다: 초기(임시/인식), 개발(정의/반응), 통제(관리/사전 대응), 선도(최적화/적응). 이 모델은 NIST AI RMF, OWASP AIMA, ISO/IEC 42001, EU AI Act에 직접 매핑된다. 대부분의 조직은 현재 1단계나 2단계에 머물러 있다. 프레임워크는 이를 실패가 아니라 AI 도입 속도가 거버넌스를 앞지른 현실을 반영한 것이라고 본다. 각 단계 전환에는 명확한 우선순위와 비즈니스 결과가 따른다. 초기에서 개발로 이동하는 것은 가시성 확보가 우선이다: AI-BOM을 배포하고, 소유권을 할당하고, 섀도 AI를 발견하는 비처벌적 프로세스를 구축하는 것이다.

개발자가 바로 체감하는 변화는 이 프레임워크가 'AI 보안은 개발팀과 보안팀이 함께 만들어야 한다'는 현실을 코드와 정책으로 옮겼다는 점이다. 단순한 원칙 선언이 아니라, 자산 목록 작성부터 위험 등급 산정, 공급망 문서화, 모니터링 계층, 성숙도 평가까지 실행 가능한 단계로 구성됐다.