앞선 문서들을 정리하다 보니 “그래서 실제로 이걸 어떻게 판단할 건데?”로 이어지는 질문들이 남았음 지금 당장 답을 완성하기보다, 나중에 경험이 쌓였을 때 다시 펴보고 내 생각이 얼마나 달라졌는지 비교해보려고 남겨둠
Q1. RAG 기반 사내 챗봇을 도입한다면 보안팀으로서 뭘 가장 먼저 확인해야 할까
지금 드는 생각: 데이터 분류부터 시작 → 어떤 문서가 색인 대상인지, 그 문서들의 기존 접근권한(ACL)이 무엇인지 확인 → 벡터DB 색인 시 그 권한 메타데이터가 유지되는지, 검색 시점에 요청자 권한으로 재필터링되는지가 핵심 판단 포인트인 것 같음 여기서 막히면 “권한 없는 사용자가 민감문서를 답변으로 받는” 가장 흔한 사고로 이어질 듯
Q2. 프롬프트 인젝션을 어떻게 막을 수 있을까
지금 드는 생각: 완전 차단은 불가능하다는 전제로, 입력 정화, 지시문/데이터 구조적 분리, 가드레일 모델의 이중 검사, 에이전트 최소 권한, 되돌릴 수 없는 작업은 사람 승인, 이상 패턴 모니터링까지 다층 방어로 접근하는 게 현실적일 것 같음
Q3. Shadow AI를 어떻게 탐지하고 대응할 수 있을까
지금 드는 생각: 프록시/CASB 로그로 AI 서비스 접속 현황 가시화 → 데이터 등급별 사용 정책 수립 → 완전 차단보다 승인된 대안 제공이 실효성 높다는 최신 트렌드 → 임직원 교육까지 이어지는 흐름
Q4. 회사가 AI 기본법에 어떻게 대응하도록 준비할 수 있을까
지금 드는 생각: 사내 AI 기능 인벤토리화(어디에 AI가 쓰이는지부터 파악이 안 된 조직이 많다고 함) → 고영향 AI 해당 여부를 법무와 공동 스크리닝 → 모델/데이터 변경 이력을 남기는 감사 로그 체계 → AI 생성 콘텐츠 표시 여부 QA 프로세스 반영
Q5. LLM 로그에 민감정보가 남는 문제를 어떻게 풀 수 있을까
지금 드는 생각: 로깅 자체를 없애면 감사·디버깅이 불가능하므로, PII 탐지·마스킹 후 로깅, 로그 접근권한을 별도 관리, 보존기간 최소화, 필요 시 로그도 개인정보 처리 대상으로 간주해 처리방침에 반영하는 정도가 현실적 대안 같음
Q6. MCP 서버를 도입할 때 신뢰성을 어떻게 검증할 수 있을까
지금 드는 생각: 공급망 보안 관점으로 접근 → 서버 화이트리스트/서명 검증, 업데이트마다 재검증(러그풀 방지), OAuth 기반 스코프 제한 토큰, 도구 실행 샌드박스 격리, 도구 호출 로그 모니터링
Q7. 모델 공급망 리스크에는 뭐가 있고 어떻게 관리할 수 있을까
지금 드는 생각: 출처 불명 모델 사용, pickle 등 위험한 직렬화 포맷, 학습데이터 포이즈닝, 백도어 트리거가 대표적인 리스크 모델 카드 확인, safetensors 같은 안전 포맷 사용, 신뢰된 배포처 이용, 파인튜닝 전후 행동 비교 테스트가 대응 방향일 것 같음
Q8. OWASP Top 10 for LLM을 나만의 언어로 설명할 수 있을까
지금 드는 생각: 프롬프트 인젝션부터 무제한 소비까지 10개를 그냥 외우기보다, 입력 조작 계열 / 데이터·공급망 계열 / 출력·자원 계열로 묶어서 이해하면 단순 암기보다 오래 남을 것 같음
Q9. 에이전트에게 과도한 권한을 주면 안 되는 이유는 뭘까
지금 드는 생각: 에이전트는 프롬프트 인젝션에 취약할 수 있는데, 권한이 넓으면 공격 성공 시 피해 범위(blast radius)가 그만큼 커짐 최소 권한 원칙 + 되돌릴 수 없는 작업의 사람 승인 게이트가 핵심일 듯
Q10. ISO 42001과 NIST AI RMF, 우리 조직이라면 뭘 먼저 도입하는 게 맞을까
지금 드는 생각: NIST AI RMF는 유연한 자율 위험관리 가이드, ISO 42001은 인증 가능한 관리체계 표준 조직 성숙도가 낮으면 NIST AI RMF로 위험 평가 체계부터 만들고, 대외 신뢰(고객사·조달)가 중요하면 ISO 42001 인증을 목표로 단계적 도입하는 게 자연스러워 보임
Q11. 개인정보보호법과 AI 기본법이 겹치는 지점은 어디일까
지금 드는 생각: AI가 학습·처리하는 데이터가 개인정보인 경우, AI 기본법의 “설명 방안” 의무와 개인정보보호법의 자동화된 결정 대응권이 사실상 같은 문제를 다른 각도에서 규율하는 셈 채용·대출심사 AI가 대표적인 교집합 사례
Q12. 할루시네이션이 실제 보안 사고로 이어질 수 있는 예는 뭐가 있을까
지금 드는 생각: 모델이 존재하지 않는 소프트웨어 패키지명을 그럴듯하게 생성 → 개발자가 그대로 설치 시도 → 공격자가 미리 그 이름으로 악성 패키지를 배포해두는 공급망 공격 시나리오(패키지 할루시네이션) “할루시네이션 = 품질 문제”라는 인식을 넘어 보안 문제로도 연결해서 생각해볼 지점
Q13. AI 보안은 완전히 새로운 분야일까, 아닐까
지금 드는 생각: 아마 둘 다 맞는 것 같다 — 공급망 보안, 접근제어, 최소 권한, 로깅 같은 원칙은 그대로 적용되지만, 모델의 비결정성·자연어 기반 공격면·에이전트의 자율 행동이라는 요소는 기존 프레임워크로 완전히 커버되지 않는 새로운 축인 듯함 경험이 쌓이면 이 답이 어떻게 바뀔지 궁금함
이 노트를 남기는 이유
지금은 원칙 기반으로만 답할 수 있는 질문들이지만, 실무를 겪고 나면 “정확한 세부 스펙까지는 확인이 필요하지만, 이런 방향으로 접근하겠다”는 수준을 넘어설 수 있을 거라 생각함 AI 보안은 표준·법이 계속 바뀌는 영역이라, 정답을 외우기보다 변화에 대응하는 사고방식을 기르는 게 더 오래 남을 것 같음