RAG의 답변 품질과 보안은 모델에 들어가기 전 데이터를 어떻게 준비했는지에서 이미 절반이 결정됩니다. AIP-C01 공식 가이드의 1.3(FM이 쓸 데이터의 검증·처리 파이프라인)과 3.2(데이터 보안과 개인정보 보호)는 이 준비 과정을 묻습니다. Textract, Transcribe, Comprehend, Macie, Guardrails는 모두 "데이터를 읽거나 개인정보를 찾는다"는 설명이 비슷해 시험에서 자주 헷갈립니다. 이번 포스팅에서는 원본 데이터가 안전한 지식 베이스가 되기까지의 흐름을 따라가며 각 서비스의 자리를 정리합니다.
데이터 형태별 추출 서비스
| 데이터 | 서비스 | 핵심 기능 | |--------|--------|-----------| | 스캔 문서, PDF, 양식 | Amazon Textract | 텍스트 추출, 표·양식(키-값)·레이아웃 분석, 질의(Queries)로 특정 값 추출 | | 통화 녹음, 회의 음성 | Amazon Transcribe | 음성을 텍스트로 변환, 화자 분리, 사용자 지정 어휘, 전사본 PII 삭제 | | 문서·이미지·음성·영상 혼합 | Amazon Bedrock Data Automation | 생성형 AI로 비정형 콘텐츠를 구조화된 출력으로 변환, 블루프린트로 추출 항목 정의 | | 이미지 속 내용 이해 | 멀티모달 FM | 이미지와 텍스트를 함께 입력해 설명·질의응답 |
Textract는 한 페이지 문서는 동기 API()로, 여러 페이지 PDF는 비동기 API()로 처리합니다. 레이아웃 분석 결과(제목, 단락, 표의 위치)를 활용하면 문서 구조를 살린 계층적 청킹이 가능해 RAG 검색 품질이 좋아집니다. 추출 신뢰도가 낮은 항목만 사람이 확인하게 하려면 Amazon A2I를 연결합니다.
Transcribe의 화자 분리(speaker diarization)는 "상담원"과 "고객"의 발화를 나눠 주므로, 통화 요약 프롬프트에 화자별로 구조화된 대화를 넘길 수 있습니다. 의료 음성에는 Transcribe Medical을 씁니다.
Bedrock Data Automation(BDA)은 문서, 이미지, 음성, 영상을 하나의 API로 처리해 구조화된 결과를 돌려주며, Bedrock Knowledge Bases의 파서로 지정할 수도 있습니다. 공식 가이드 2.5.3의 "자동화된 데이터 처리 워크플로"가 이 서비스를 가리킵니다.
Amazon Comprehend: 텍스트를 이해하고 PII를 찾는다
Comprehend는 텍스트에서 개체(사람, 조직, 날짜 등), 핵심 구문, 감성, 언어를 찾아내는 자연어 처리 서비스입니다. GenAI 파이프라인에서는 세 가지 역할로 등장합니다.
입력 품질 향상(1.3.4): 문서에서 개체를 추출해 메타데이터로 붙이면 검색 필터와 출처 표시에 활용할 수 있습니다. 의도 인식(1.6.2): 사용자 정의 분류(custom classification)로 문의 유형을 분류해 알맞은 프롬프트나 에이전트로 보냅니다. PII 처리(3.2.2, 3.2.3): 는 PII의 종류와 위치를, 는 포함 여부를 빠르게 알려 줍니다. S3에 쌓인 대량 문서는 비동기 PII 작업으로 처리하면서 PII를 유형 이름으로 바꾸거나 별표로 가린 문서를 만들 수 있습니다.
언어 지원 범위는 꼭 확인해야 합니다. 개체·핵심 구문·감성 분석은 한국어를 지원하지만, PII 탐지는 영어와 스페인어만, 사용자 정의 분류는 한국어를 제외한 일부 유럽 언어만 지원합니다. 한국어 문서의 주민등록번호나 전화번호는 정규식(Guardrails의 사용자 정의 정규식 필터나 Lambda)으로 처리하고, 한국어 문의 분류는 Bedrock 모델로 하는 방식을 검토합니다.
영어 문서라면 다음처럼 탐지 결과의 위치 정보로 PII를 유형 이름으로 바꿀 수 있습니다.
의료 데이터라면 Amazon Comprehend Medical이 보호 대상 건강 정보(PHI)를 찾고 질병·약물 정보를 의학 코드 체계와 연결합니다.
참고로 Comprehend의 주제 모델링, 이벤트 감지, 프롬프트 안전성 분류는 2026년 4월 30일부터 신규 고객에게 제공되지 않습니다. AWS는 대안으로 Bedrock 모델과 Bedrock Guardrails를 안내하고 있으니, 새로 설계한다면 PII 탐지·개체 인식·분류 위주로 Comprehend를 쓴다고 기억하면 됩니다.
PII 보호 3종 비교: Macie vs Comprehend vs Guardrails
세 서비스 모두 PII를 찾지만, 보는 대상과 시점이 다릅니다.
| 구분 | Amazon Macie | Amazon Comprehend | Amazon Bedrock Guardrails | |------|--------------|-------------------|---------------------------| | 대상 | S3에 저장된 객체 | API로 넘긴 텍스트 | 모델 입력(프롬프트)과 출력(응답) | | 시점 | 저장된 데이터를 자동·주기적으로 스캔 | 파이프라인에서 처리할 때 | 추론이 실행될 때 | | 결과 | 민감 데이터 발견 사항(EventBridge, Security Hub로 전달) | PII 유형·위치, 가려진 문서 | 차단(BLOCK), 마스킹(ANONYMIZE), 탐지만(NONE) | | 시험 표현 | "어느 S3 버킷에 민감 데이터가 있는지 찾아라" | "학습·인덱싱 전에 PII를 제거하라" | "대화 중 PII를 실시간으로 가려라" |
실무에서는 하나만 고르지 않고 겹겹이 씁니다(공식 가이드 3.1.4의 심층 방어). Macie로 원본 버킷을 감시하고, Comprehend로 인덱싱 전에 PII를 지우고, Guardrails로 사용자가 대화 중에 입력하거나 모델이 출력하는 PII를 가리고, 마지막으로 Lambda 후처리에서 출력 형식을 검증합니다.
Guardrails에는 시험에 나올 만한 함정이 두 가지 있습니다. 첫째, Guardrails의 마스킹은 모델에 들어가는 입력과 돌아오는 응답에만 적용되므로, 모델 호출 로그(invocation logging)에는 원래 입력이 그대로 남습니다. 로그의 PII는 CloudWatch Logs 데이터 보호 정책으로 따로 가려야 합니다. 둘째, 민감 정보 필터는 텍스트만 평가하므로 모델이 도구 호출 인수에 넣은 PII나 도구 결과에 담긴 PII는 걸러지지 않습니다. 이 부분은 도구 쪽 Lambda에서 검증합니다.
데이터 품질 검증과 정규화
추출과 비식별화를 거친 데이터도 품질을 확인한 뒤에 모델에 넣어야 합니다(1.3.1).
AWS Glue Data Quality: 완전성, 고유성, 값 범위 같은 규칙을 정의하고 기준을 통과한 데이터만 다음 단계로 보냅니다. Step Functions와 묶어 품질 게이트로 쓰는 문제가 자주 나옵니다. SageMaker Data Wrangler와 SageMaker Processing: 시각적인 데이터 준비와 대규모 전처리 작업에 씁니다. Lambda: 인코딩 정리, 머리글·바닥글 제거, 날짜 형식 통일, 중복 제거 같은 정규화를 맡습니다. CloudWatch 지표: 누락률, 실패 건수 같은 데이터 품질 지표를 기록해 이상을 감지합니다.
모델에 넣을 때의 형식도 중요합니다(1.3.3). Bedrock API 요청은 모델별 JSON 형식을 따르고, 대화형 애플리케이션은 역할(user, assistant)이 구분된 메시지 형식으로 대화 기록을 정리해 넘깁니다.
!원본 데이터에서 안전한 지식 베이스까지
데이터 접근 통제와 보존
Lake Formation: 데이터 레이크 테이블에 열·행 단위 권한을 걸어, RAG나 분석에 쓰는 데이터라도 필요한 사람만 민감 열을 보게 합니다(3.2.1). S3 수명 주기 규칙: 원본 데이터와 로그를 정해진 기간 뒤 삭제하거나 저렴한 스토리지로 옮겨 보존 정책을 지킵니다(3.2.2). 암호화와 네트워크 격리: S3와 벡터 저장소를 KMS 키로 암호화하고, VPC 엔드포인트로 인터넷을 거치지 않고 Bedrock에 접근합니다. Bedrock의 기본 개인정보 보호: 프롬프트와 응답은 AWS 모델 학습에 쓰이지 않고 모델 제공사에 공유되지 않습니다.
시나리오로 연습하기
콜센터가 통화 녹음을 요약해 CRM에 남기려는데 카드번호가 요약에 들어가면 안 된다. Transcribe로 화자를 나눠 전사하면서 PII를 삭제하고, 정리된 대화를 Bedrock 모델로 요약합니다. 보험 청구서 수천 장에서 청구 금액과 날짜를 뽑되, 신뢰도가 낮은 값만 사람이 확인해야 한다. Textract의 양식 분석에 Amazon A2I를 연결합니다. 보안팀이 수백 개의 S3 버킷 중 개인정보가 들어 있는 곳을 찾아야 한다. Amazon Macie입니다. 챗봇 사용자가 대화 중 카드번호를 입력해도 모델과 응답에 노출되면 안 된다. Bedrock Guardrails의 민감 정보 필터를 마스킹으로 설정합니다.
시험 핵심 정리
"스캔 문서·양식·표에서 텍스트와 구조 추출" -- Amazon Textract "통화 녹음을 텍스트로, 화자 구분" -- Amazon Transcribe (speaker diarization) "문서·이미지·음성·영상을 하나의 API로 구조화" -- Amazon Bedrock Data Automation "추출 신뢰도가 낮은 항목만 사람이 검토" -- Textract + Amazon A2I "인덱싱·학습 전에 텍스트의 PII 탐지·제거" -- Amazon Comprehend PII 탐지 "의료 기록의 PHI 탐지" -- Amazon Comprehend Medical "S3 버킷 전체에서 민감 데이터 위치 파악" -- Amazon Macie "대화 중 프롬프트·응답의 PII 실시간 마스킹" -- Bedrock Guardrails 민감 정보 필터 "호출 로그에 남은 PII 가리기" -- CloudWatch Logs 데이터 보호 정책 "학습·인덱싱 전 데이터 품질 게이트" -- AWS Glue Data Quality (+ Step Functions) "데이터 레이크의 열·행 단위 접근 제어" -- AWS Lake Formation "원본 데이터 보존 기간 관리" -- S3 수명 주기 규칙