서론: PII 탐지, 왜 자동화해야 할까?
금융, 보험, 헬스케어, 정부 기관처럼 규제 산업에 몸담고 있다면 PII(Personally Identifiable Information, 개인식별정보) 관리가 얼마나 중요한지 잘 아실 거예요.
GDPR, HIPAA, CCPA 같은 규제는 "우리 조직에 어떤 개인정보가 어디에 있는지" 정확히 파악하고, 접근 권한을 관리하며, 보호 조치를 했다는 증거를 요구합니다. 문제는 이런 데이터가 파일, 로그, 파트너 피드, 내부 워크플로 등 수많은 경로로 계속 유입된다는 점이에요.
수동으로 분류 작업을 하기엔 이미 한계에 도달했고요. 이 글에서는 파일이 Amazon S3에 도착하는 순간 자동으로 PII를 탐지하는 이벤트 기반 파이프라인을 구축하는 방법을 알려드릴게요.
핵심은 AWS의 관리형 데이터 탐지 서비스인 Amazon Macie를 확장해서, 조직 고유의 커스텀 식별자(custom identifier)까지 함께 활용하는 것입니다. 이를 통해 표준 PII(주민번호, 이메일 등)는 물론, 도메인 특화 데이터(보험 증권 번호, 고객 ID 등)까지 자동으로 잡아낼 수 있어요.
💡 한 줄 요약: S3에 파일 업로드 → EventBridge 감지 → Step Functions 오케스트레이션 → Macie 스캔 → 규제 대응용 보고서 자동 생성까지 전 과정을 코드로 구현합니다.
이 포스팅의 근거 자료는 AWS Architecture Blog 원문을 참고했어요.
본론 1: 전체 아키텍처와 핵심 설계 원칙
아키텍처 개요
이 파이프라인은 완전한 이벤트 기반 아키텍처로 설계되었습니다. 폴링(polling) 없이 이벤트가 발생하면 자동으로 워크플로가 시작되죠.
[Amazon S3] --(객체 생성 이벤트)--> [Amazon EventBridge] --> [AWS Step Functions]
|
v
[AWS Lambda] (여러 단계)
|
v
[Amazon Macie] (스캔)
|
v
[CSV/JSON 보고서 생성] + [Amazon SNS 알림]
구성 서비스 역할 정리
| 서비스 | 역할 |
|---|---|
| Amazon S3 | 데이터를 3개의 버킷(raw, staged, scanned)으로 분리해 처리 상태를 격리 |
| Amazon EventBridge | 새 객체 업로드를 감지하고 워크플로 자동 트리거 |
| AWS Step Functions | Macie 작업 생성부터 보고서 생성까지 전체 스캔 수명주기 오케스트레이션 |
| Amazon Macie | 내장형 + 커스텀 데이터 식별자로 PII 탐지 |
| AWS Lambda | 각 단계 사이의 컴퓨팅 로직 담당 (작업 시작, 상태 폴링, 결과 파싱, 보고서 생성, 객체 이동) |
| Amazon SNS | 고위험군 발견 시 실시간 알림 전송 |
설계에서 가장 중요한 3가지 결정
-
객체별 전용 Macie 분류 작업 생성: 배치로 묶지 않고 파일 하나당 작업을 만들어 실시간 탐지를 달성합니다.
-
3-버킷 패턴: raw(미처리) → staged(대기) → scanned(완료)로 분리해 아직 검사 안 된 데이터와 검증된 데이터를 절대 섞지 않습니다.
-
EventBridge 채택: S3 기본 이벤트 알림 대신 EventBridge를 사용해 고급 필터링과 크로스 계정 라우팅을 지원합니다.
본론 2: 실제 구축 워크플로우 (코드 중심)
사전 준비사항
- 관리자 권한이 있는 샌드박스(또는 비프로덕션) AWS 계정
- AWS CLI v2 설치 및 설정
- 대상 리전에서 Amazon Macie 활성화
- 고위험 알림 수신용 이메일 주소
Step 1: CloudFormation 스택 배포
AWS CLI로 배포하는 방법입니다. 콘솔에서 직접 업로드해도 됩니다.
# 템플릿 파일을 로컬에 저장 후 실행
export STACK_NAME=pii-detection-pipeline
export BUCKET_PREFIX=my-company-pii
export CUSTOM_PATTERN='[{"name":"PolicyNumber","regex":"POL-[0-9]{6}","confidence":80},{"name":"MemberID","regex":"MBR-[A-Z]{3}-[0-9]{4}","confidence":90}]'
export KMS_KEY_ARN='' # 선택사항. SSE-KMS를 원하면 지정
export EMAIL_ADDRESS='security@yourcompany.com'
aws cloudformation create-stack \
--stack-name $STACK_NAME \
--template-body file://template.yaml \
--parameters \
ParameterKey=BucketNamePrefix,ParameterValue=$BUCKET_PREFIX \
ParameterKey=CustomIdentifierPatterns,ParameterValue=$CUSTOM_PATTERN \
ParameterKey=KmsKeyArn,ParameterValue=$KMS_KEY_ARN \
ParameterKey=NotificationEmail,ParameterValue=$EMAIL_ADDRESS \
--capabilities CAPABILITY_IAM
# 배포 상태 확인
echo "스택 생성까지 3~5분 소요"
aws cloudformation wait stack-create-complete --stack-name $STACK_NAME
Step 2: SNS 구독 확인
배포 후 메일함을 확인해 SNS 구독 확인 메일을 열고 Confirm subscription을 클릭하세요. 이후 SNS 콘솔에서 구독 상태가 Confirmed인지 확인합니다.
Step 3: 커스텀 데이터 식별자 검증
CloudFormation 파라미터로 전달한 CustomIdentifierPatterns가 Macie 콘솔에 정상 등록됐는지 확인합니다.
Macie 콘솔 > Custom data identifiers > 목록 확인
Step 4: 파이프라인 테스트
샘플 파일을 raw 버킷에 업로드해서 전체 플로우를 검증합니다.
# 샘플 데이터 생성 (커스텀 패턴 포함)
cat > sample_claim.txt << 'EOF'
Customer Name: John Doe
Email: john.doe@example.com
Policy Number: POL-123456
Member ID: MBR-ABC-1234
SSN: 123-45-6789
EOF
# raw 버킷에 업로드
export RAW_BUCKET="${BUCKET_PREFIX}-raw"
aws s3 cp sample_claim.txt s3://$RAW_BUCKET/
업로드 후 몇 초 내에 Step Functions 실행이 시작됩니다. 콘솔에서 상태 머신을 열어 실행 상태를 모니터링하세요.
참고: Macie 스캔 시간은 데이터 양과 유형에 따라 다릅니다. 예제 기준 약 15~20분 소요되었어요. 스캔 시간이 길어질 수 있으니 Step Functions의 Wait 상태가 어떻게 동작하는지 이해하고 넘어가는 게 좋습니다.
Step 5: 보고서 및 알림 확인
스캔이 완료되면 scanned 버킷에 타임스탬프가 포함된 CSV와 JSON 보고서가 생성됩니다. 고위험군 발견 시 SNS 알림도 도착합니다.
# 결과 확인
export SCANNED_BUCKET="${BUCKET_PREFIX}-scanned"
aws s3 ls s3://$SCANNED_BUCKET/
# 보고서 내용 확인
export LATEST_REPORT=$(aws s3 ls s3://$SCANNED_BUCKET/ --recursive | sort | tail -1 | awk '{print $4}')
aws s3 cp s3://$SCANNED_BUCKET/$LATEST_REPORT -
본론 3: 운영 환경 적용 시 주의사항 및 하드닝(Hardening)
반드시 적용해야 할 보안 강화 조치
이 솔루션은 샘플 코드입니다. 실제 프로덕션에 적용하려면 아래 보안 권장사항을 따라야 해요.
-
멀티 테넌트 격리: 테넌트별로 별도 스택을 배포하고
BucketNamePrefix를 다르게 설정해 완전한 데이터 격리를 유지하세요. -
암호화 기본 적용: S3 버킷 기본 암호화를 SSE-S3 또는 KMS(고객 관리형 키)로 설정하세요.
-
크로스 계정 지원: 여러 계정에서 데이터가 유입된다면 EventBridge 크로스 계정 규칙을 구성하세요.
-
CloudTrail 활성화: S3 데이터 이벤트 로깅을 켜서 모든 객체 접근과 이동 기록을 남기세요.
Macie 한계와 극복 방법
| 제약 사항 | 값 | 대응 전략 |
|---|---|---|
| 계정당 커스텀 식별자 수 | 10,000개 | 초과 시 추가 계정 검토 |
| 분류 작업당 커스텀 식별자 수 | 30개 | 여러 작업으로 분할 실행 |
| CreateClassificationJob 쓰로틀링 | 0.1 rps (10초당 1회) | 고용량 워크로드는 객체 배칭 |
한국 개발 생태계에서의 적용 맥락
국내 금융권이나 공공기관에서는 개인정보보호법(이하 '개보법')과 신용정보법 등이 추가로 적용됩니다. AWS의 Macie가 기본 제공하는 PII 패턴(주민번호 등) 외에도 다음과 같은 커스텀 식별자를 등록해 두면 좋아요.
- 휴대폰 번호: 010-XXXX-XXXX 패턴 (한국 형식)
- 사업자등록번호: XXX-XX-XXXXX 패턴
- 의료기관 종별 코드: 관공서/병원에서 쓰는 고유 식별자
또한 국내에서는 행정안전부의 '개인정보의 안전성 확보조치 기준' 에 따라 암호화 및 접근 통제 증적을 요구합니다. 이 파이프라인에서 생성되는 타임스탬프 보고서가 바로 그 증적으로 활용될 수 있어요. 다만, 한국어 기반 PII(예: 한글 이름, 외국인 등록번호)는 정규식 커스텀 식별자로 직접 만들어야 한다는 점을 꼭 기억하세요.
결론: 실무 적용을 위한 마무리 조언
이제 S3에 파일이 올라오는 즉시 자동으로 PII를 탐지하고, 감사 준비가 된 보고서를 생성하며, 위험 상황을 실시간 알림으로 받는 파이프라인을 구축할 수 있습니다.
마지막으로 세 가지만 당부드릴게요.
-
파일명에 날짜와 시간을 포함해서 보고서 체계를 잡아두세요. 나중에 감사 요청이 왔을 때 빠르게 대응할 수 있습니다.
-
Macie 비용을 모니터링하세요. 커스텀 식별자를 여러 개 쓰면 비용이 늘어날 수 있어요. 커스텀 패턴은 정말 필요한 것만 최소한으로 등록하는 걸 권장합니다.
-
다음 단계로 데이터 레이크 확장을 고려해보세요. JSON 결과를 Amazon Athena에 연결해 대시보드를 만들면 PII 밀집도 추이를 시각화할 수 있습니다.
이 글이 실제 업무에서 데이터 보호 파이프라인을 설계하는 데 도움이 되길 바랍니다. 궁금한 점은 댓글로 남겨주세요!
함께 보면 좋은 글
- A2UI v0.9 정식 출시: AI 에이전트가 실시간으로 UI를 생성하는 새로운 표준
- 넷플릭스는 어떻게 10분 만에 데이터 오류를 잡아낼까? — Data Canary 패턴 완전 해부
