어제까지는 "AI 가 공정하고 신뢰할 수 있게" 만드는 책임 있는 AI 를 봤다. 오늘은 기술적 방어, 곧 AI 보안이다. AI 전용 보안 기술이 따로 있는 것이 아니라 AWS 의 표준 보안 원칙을 AI/ML 맥락에 적용하는 것이 핵심이다. 그 출발점이 책임 공유 모델(Shared Responsibility Model) 이다.
구분
책임 주체
예시
클라우드 자체의 보안
AWS
데이터센터, 하드웨어, 글로벌 인프라, 관리형 서비스의 기반
클라우드 안의 보안
고객
데이터 분류·암호화, IAM 권한 설정, 접근 제어, 네트워크 구성
핵심 한 줄: "AWS 는 클라우드의 보안(security OF the cloud), 고객은 클라우드 안에서의 보안(security IN the cloud)을 책임진다."
관리형 서비스(Bedrock, SageMaker 등)를 쓸수록 AWS 가 지는 책임이 커진다. 하지만 "데이터를 누구에게 보여줄지(IAM)", "어떤 데이터를 넣을지", "암호화 키를 어떻게 관리할지"는 고객 몫이다. 시험에서 "Bedrock 으로 모델을 호출할 때 입력 데이터 접근 권한 관리는 누구 책임?"이라고 물으면 답은 고객이다.
PII(개인 식별 정보, Personally Identifiable Information), 곧 이름·주민번호·전화번호·카드번호 등은 특히 엄격히 보호해야 한다. AWS 는 PII 를 자동으로 찾고 보호하는 도구를 제공한다.
서비스
역할
Amazon Macie
S3에 저장된 데이터에서 PII·민감정보를 자동 탐지·분류
Amazon Comprehend (PII 탐지)
텍스트에서 PII를 식별하고 마스킹/제거
Amazon Bedrock Guardrails (PII 필터)
생성형 AI 입력·출력에서 PII 마스킹
Amazon Macie: 머신러닝과 패턴 매칭으로 S3 버킷을 스캔해 "여기 신용카드 번호가 노출돼 있다" 같은 위험을 알린다.
Amazon Comprehend: 자연어 텍스트에서 PII 엔티티를 찾아 마스킹하거나 제거한다. 학습 데이터에서 개인정보를 빼는 전처리에 유용하다.
세 도구는 "어디에 있는 데이터를, 언제, 어떻게 하느냐"로 갈린다.
구분
Amazon Macie
Amazon Comprehend
Bedrock Guardrails
대상
S3 에 이미 저장된 객체
우리가 넘겨준 텍스트
생성형 AI 의 프롬프트와 응답
시점
저장된 뒤, 주기적·지속적 점검
처리 파이프라인 안에서
대화가 오가는 그 순간
하는 일
민감 데이터가 어디 있는지 찾아 보고
텍스트 속 PII 를 찾아 가림
입출력의 PII 를 차단하거나 마스킹
결과물
발견 사항(finding) 보고
PII 위치·유형, 가려진 텍스트
걸러진 응답
지문 단서
"S3 버킷", "어디에 민감 데이터가 있는지"
"텍스트에서 식별·마스킹", "학습 데이터 전처리"
"챗봇", "프롬프트·응답"
Macie 는 민감 데이터 탐지에 더해 S3 버킷의 보안 상태도 살핀다. 버킷이 공개 접근 가능해지는 것 같은 문제를 발견하면 알려 준다.
Macie 는 찾아서 알려 주는 서비스다. 찾은 데이터를 스스로 지우거나 가리지는 않는다.
Macie 의 대상은 Amazon S3 다. 데이터베이스나 실시간 대화가 대상이면 다른 도구를 찾는다.
가상의 사례로, 한 보험사가 고객 상담 기록을 학습 데이터로 쓰려 했다. 그대로 쓰면 이름·주소가 모델에 새어 들어갈 위험(프라이버시 침해)이 있었다. 팀은 ① Macie 로 어느 S3 버킷에 PII 가 있는지 먼저 스캔하고, ② Comprehend PII 탐지로 텍스트에서 개인정보를 마스킹한 뒤 학습에 사용했으며, ③ 배포된 챗봇에는 Bedrock Guardrails 의 PII 필터를 걸어 출력에서도 개인정보가 나가지 않게 했다. 데이터 수명주기 전 단계에서 PII 를 막은 사례다.
기본적으로 AWS 서비스 API 는 퍼블릭 엔드포인트로 접근한다. 민감한 데이터를 다룰 때는 트래픽이 공용 인터넷을 거치지 않게 하는 것이 안전하다. AWS PrivateLink 가 이를 해결한다.
PrivateLink 는 VPC(가상 사설 네트워크) 안에서 AWS 서비스(예: Bedrock, SageMaker)로 프라이빗 연결을 만든다. 이때 VPC 안에 만드는 접속 지점이 인터페이스 VPC 엔드포인트다.
트래픽이 AWS 내부 네트워크에만 머물고 인터넷에 노출되지 않는다.
데이터 유출 위험을 줄이고, 규제가 엄격한 환경(금융·의료)에서 자주 요구된다.
🔍 더 깊이: "Bedrock 을 쓰는데 데이터가 인터넷을 거치지 않게 하고 싶다"는 시나리오의 답이 PrivateLink(VPC 엔드포인트)다. 암호화(데이터 내용 보호)와 PrivateLink(경로 보호)는 다른 층의 방어다. 암호화는 "내용을 못 읽게", PrivateLink 는 "애초에 공용 경로로 안 가게" 하는 것이다.
질문
IAM
KMS
TLS
PrivateLink
무엇을 지키나
누가 할 수 있는지
저장된 내용
오가는 내용
오가는 경로
없으면 생기는 일
누구나 호출·열람
저장소 유출 시 내용 노출
도청 시 내용 노출
트래픽이 공용 인터넷 경유
서로 대신할 수 있나
없다
없다
없다
없다
네 가지는 층이 다른 방어다. "PrivateLink 를 쓰니 암호화는 필요 없다", "암호화했으니 권한은 넓게 줘도 된다"는 보기는 모두 틀리다.
시험 가이드는 AI 시스템의 보안·프라이버시 고려 사항으로 기존 보안 항목(애플리케이션 보안, 위협 탐지, 취약점 관리, 인프라 보호, 저장·전송 암호화)과 함께 생성형 AI 고유의 항목을 든다.
위협
무엇인가
대응
프롬프트 인젝션
입력에 지시를 숨겨 모델이 원래 지침을 무시하게 만듦
Guardrails 의 프롬프트 공격 필터, 입력 검증, 모델이 쓸 수 있는 권한 최소화
탈옥(jailbreaking)
안전장치를 우회해 금지된 내용을 끌어냄
Guardrails 콘텐츠 필터, 거부 주제
데이터 유출
응답에 개인정보나 내부 정보가 섞여 나감
PII 필터, 출력 필터링과 검증, 지식 기반 문서의 접근 통제
유해 출력(toxicity)
혐오·폭력 등 부적절한 내용 생성
Guardrails 콘텐츠 필터
추적 불가
누가 무엇을 물었고 무엇이 나갔는지 모름
AI 상호작용에 대한 감사 추적과 로깅(Day 4)
프롬프트 인젝션은 사용자가 직접 넣는 경우만 있는 것이 아니다. 모델이 읽는 문서나 웹페이지에 지시가 숨어 있을 수도 있다. 그래서 "모델이 읽는 모든 외부 내용은 신뢰하지 않는다"가 기본 자세다.
에이전트처럼 모델이 도구를 호출해 실제 행동을 한다면 최소 권한이 더 중요해진다. 모델이 속더라도 할 수 있는 일이 좁으면 피해가 작다.
시험 가이드는 AI 시스템을 보호하는 AWS 기능의 예로 IAM, 암호화, Macie, PrivateLink, 책임 공유 모델과 함께 Amazon Bedrock Guardrails, 그리고 에이전트용 기능인 Amazon Bedrock AgentCore Identity 와 Policy in AgentCore 를 든다. AgentCore Identity 는 에이전트의 신원·접근·인증을 관리하고, Policy 는 에이전트가 어떤 도구를 어떤 조건에서 쓸 수 있는지 규칙으로 통제한다. 입문 시험에서는 "에이전트에도 신원과 권한 통제가 필요하다" 정도로 알아 둔다.
AI 전용 마법이 아니라 AWS 의 표준 보안 원칙을 ML 파이프라인에 빠짐없이 적용하는 것이 오늘의 요지다. 내일은 보안에서 한 발 더 나아가 데이터 거버넌스와 규정 준수(데이터 출처·품질, 모델 거버넌스, CloudTrail 감사·로깅, 생성형 AI 의 법적·윤리 고려)를 본다.